我不是小布丁
@xiaobuding
开发者用LoopX效率太高了，3小时新增了9个contributor PR，感觉LoopX长程自动化范式下的开源社区，已逐渐演变为了dev agent和review agent的对抗，人类负责定目标、监督和验收。
也许未来需要开3个以上的review agent并发才能跟上开发者的吞吐。
展开讲讲LoopX自己的自动化PR review机制。
review agent也由LoopX驱动：通过loopx pr-review获取队列和每个PR的review plan，把待审工作落成持久化Todo，再逐个读代码、验证、输出结论。队列状态外置，跨session继续跑。
这里面有几个我觉得很重要的细节：
- review绑定PR的exact head，也就是具体的commit SHA。新代码需要重新审；评论和CI刷新不会让旧代码变成新代码。候选任务落盘后才确认入队，有可回读的审查结果后才标记处理完成，中途断了也能继续接。
- 审的是整个改动的动机、架构和行为。要求沿着2–5个关键代码符号，追到真实调用方、状态变化、权限和副作用，走通正向路径，以及适用的失败/fail-closed路径。CI全绿不能代替这些证据。
- 也审"值不值得加"。原问题的频率、严重程度，是否值得引入这些新状态、接口和长期维护成本？一个功能即使default-off，也要做开关关闭时的对照验证，证明原有行为没被悄悄改变。
这些要求沉淀在LoopX的PR review capability里，给agent下发结构化的审查约束。队列扫描默认只读；发review、合并仍要走各自的授权和验收。
开发吞吐上来以后，如何持续守住项目的方向和复杂度，可能会成为开源维护者更重要的工作。
PR review capability：
github.com/huangruiteng/l…
24 浏览 0 评论
0 反应
