我们让AI代理无人值守地处理工单到拉取请求。成功的关键不是更好的提示，而是删除了一个工具。

背景供参考：小团队，真实生产代码库，运行约四个月，从接收到合并PR的63个工单。我发布设计而非代码仓库，是为了找出漏洞，而非追求星标。 我实际遇到的问题是代理很能干，但它总是停下。每个歧义都变成一个问题，所以一个'40分钟的无人值守运行'实际上分散在下午的六次中断，每次上下文切换的成本都比它问的问题更高。自主性并非受限于能力，而是受限于交互模式。 因此，目标归结为一句话：运行执行到完成，仅在流程中声明的停止点暂停。功能有一次停顿。热修复有两次，一次在花费资源前，一次在不可逆发布前。其他任何情况都不能阻塞。 1. '被阻塞'是一个状态，而非停顿。'询问用户'工具从每个流程代理的工具列表中移除，不是禁止使用，而是直接移除。当代理遇到歧义时，它记录问题、应用的默认值和影响评级，然后继续运行： adw question <runId> --q "rate-limit window unspecified in REQ-API-011" --default "60s sliding, matching PAT-API-002" --impact low 所有积累的问题在人工关卡处一起出现。六次中断变成一次审查。整个系统中价值最高的改变大约只有四行配置。 2. 假设预算，因为单独使用第一点很危险。无限自主权加上静默应用的默认值会让运行在被检查前偏离很远。因此，超过N个高影响假设会触发早期人工关卡。系统在发现猜测过多时升级，而不是在结束时展示一堆猜测。 3. 传输和判断是独立的层。编排脚本了解扇出、有界重试、关卡顺序、工作树、恢复。它们不了解规范是否良好，这存在于关卡代理中。不同的变化率：传输是机械且稳定的，判断不断变化。当它们混合时，改变审查规则意味着编辑编排器，这就是为什么你会害怕改变审查规则。 4. 失败的关卡是有界修复循环，而不是停止。阻塞反馈到创作和重新审查，三次尝试。关卡保持完全拒绝的权力，只是不需要人工将裁决传回作者。 5. 完成是机器检查的。运行仅在所有关卡通过、PR存在、提交已记录、知识库已写回、假设已审查、工作树干净时完成。其他任何情况都是被阻塞或失败。没有安静的部分成功，这曾是我最常见的失败：某事报告成功，两周后发现可追溯性从未发生。 主观部分：两个测试角色，而非一个。一个代理回答'是否绿色？'。另一个独立代理回答'绿色是否有意义？'——每个验收场景是否映射到实际断言它的测试，以及是否有任何测试被削弱以达到绿色。第二个问题在绿色CI运行中完全不可见。审查面板基于测量的爆炸半径，从只读侦察通过，而非工单自身的描述。安全审查仅在差异达到认证、密钥、敏感数据或出站调用时触发。一行小杂务不应为六个代理面板付费。 热修复在三个不同策略（最小补丁、根因、防御性防护）下的三个沙箱中竞赛。我尝试让相同的代理竞赛，但毫无用处：三个几乎相同的差异，选择器无从选择。多样性是竞赛的全部产物。选择是一个仲裁者阅读实际差异，而非首先达到绿色获胜。到达时间选择奖励以最便宜方式达到绿色的代理，而最便宜的绿色路线是削弱失败的测试。任何松散或跳过断言的东西都被直接取消资格，'这些都不应发布'是一个有效裁决。热修复承担债务，而非豁免。它跳过规范关卡，因此运行在追溯规范补回前拒绝关闭。服务恢复的那一刻是每个人停止关心的时候，而那是推理仍在某人脑中的唯一时刻。 通过ID而非文件路径进行追溯。无聊，但比任何提示改变都重要。我们的追溯最初引用文件路径。我根据覆盖20个已发布史诗的约3200行知识库进行了审计：184个引用 - 0个解析到确切需求，16个解析到无，39个解析到11个候选，10个解析到19个候选。路径命名文档，文档包含多个断言，因此'参见auth-spec.md'对代理几乎没有信息。我还发现69个推理块埋在机器可读注册表的YAML注释中，纯粹因为没有其他地方放置决策，以及一堆原位'被取代'块，每个更正都附加到被更正的内容。当前真相隐藏在三层撤销之后。通过移动到具有稳定ID的原子节点来修复，第一行是整个断言，取代写入新节点链接回来，因此撤销保持在答案路径之外，CI在悬挂引用上失败。 我如何检查管道本身，这是我最希望被撕碎的部分。在某个时候，我意识到我有一个审查代码的系统，而没有任何东西审查系统。因此有一个检查电池（'挑战'）包含三条规则： 1. 一切每次都运行。从不只是失败的那一个。一个循环只重新检查它触及的东西会收敛到每个检查在某个时间点通过但从未同时通过的状态。看起来完成。其实不是。 2. 回归被标记。'曾绿，现在红'是不同于'仍然红'的信息，需要不同的响应。先前运行的结果保存在磁盘上纯粹是为了做出这个区分。 3. 绿色意味着绿色。不允许已知失败。不应阻塞的检查就不是检查。在循环模式下，它在一轮不产生净改进时停止，而不是燃烧预算假装它收敛。 一些检查是结构性的，我发现异常高效：没有代理声明'询问用户'工具——自主合约在CI中是grep，而不是文档中的一段话；每个声明的工作流阶段实际上是可达的——捕获了两个阶段（发布和热修复债务补回）在元数据中声明但从未执行。两者都静默无事。运行看起来成功。没有辅助函数被定义但从未调用——捕获了一个文档整理函数连接到无。每个流程调用的代理实际存在。运行状态根据其模式验证，使用一次性夹具。 目前14个绿色 out of 17，我在修复前写了三个红色，因为修复后编写的检查只编码我已经做的事情：流程将完整负载嵌入提示而非指针（4个地方）。设计的核心声称编排器上下文在代理发现的内容中保持O(1)。目前是错误的。51个shell命令通过生成代理运行。我有一个辅助函数生成廉价模型，其全部工作是运行一个命令并回显stdout。它工作，它荒谬，它是每次运行开销的大部分。关卡3在第一次失败时升级，而关卡1和构建/测试自动修复3次。这是我自我说服称为设计选择的不一致。 计分板：学习只有在数字移动时才真实，因此有一个指标命令在基线日期拆分运行并显示前后，特别为了批准的改变可以被判断而非假设。头条指标是人工覆盖率。还跟踪：关卡1拒绝率（高表示规范编写不良），假设覆盖率（高表示我的默认值错误），平均构建尝试和重试预算用尽的频率，中位小时。