我们构建了一个代理，在开启PR之前自动评分其输出——架构解析与三大挑战

预先声明：我参与了这个项目。这是一个商业产品（KeplerCrew，由AiChargeLabs开发）。我很乐意讨论架构，而且我宁愿在这里被批判，也不愿在六个月后的销售会议上。 在代理编码中，我们不断遇到的问题并非生成质量。生成质量没问题。问题在于，在人工审查之前，循环中没有任何东西能告诉我们输出是否真正正确。因此，每个更改仍然需要排队等待审查者，而审查者现在要阅读的代码比以前更多。净吞吐量几乎没有提升。打字更快，但关卡相同。 我们最终构建的是五个阶段，共有十六个阶段分布其中： 理解 — 读取代码库、其约定和任务意图 计划 — 将工作分解为有序、安全排序的计划 执行 — 根据计划编写代码和测试 验证 — 根据验收标准对结果评分；失败则循环回修复流程，而不是直接暴露 交付 — 验证后的差异作为拉取请求提交 我认为第四阶段才是真正重要的。标准在每个关卡都被评分，而不是在最后一次性评分，失败的关卡会重新进入流水线，而不是直接交给人工，附上一句'这是我的尝试，祝你好运。'目标不是移除审查者——而是审查者不应该成为发现问题的那个人。 三件事比我们预期的更难： 安全排序计划。天真分解产生的步骤单独有效但整体破损——每个都通过，组合却不。我们大部分的规划工作都用于排序和依赖检测，而不是分解本身。 成本可预测性。开放式代理循环默认在财务上无界。一个通过重试达到正确的任务可能花费十倍于昨天类似任务的成本，这使得整个事情无法预算。在不牺牲质量的前提下限制每项任务的花费，比我们做的其他任何事都需要更多调整。 无出口运行。我们的许多买家受监管，他们的代码不能离开网络，因此我们支持自托管和完全离线部署。这对这些交易有利，但对系统中那些悄悄假定可以调用API的每个部分都是痛苦的。 我真正想征求意见的开放问题是：在停止信任自动化评分之前，你认为有多少审查负担可以转移到自动评分上？我们选择了'人工仍然批准PR，但不应该是第一道防线。'我不确定这是否正确，我更想听听你的看法。 我很乐意深入探讨任何阶段、评分模型或离线设置。