多 Agent 审完架构方案，仍漏了产品目标

一份 2.2 万词的架构计划，经过 12 个 Agent 近两小时的协作，接受了审查提出的全部 51 条意见，涉及代码的判断还附有文件和行号。第二天，负责人只问了两个问题，就发现它需要重写。问题不在代码事实，而在两个从未明确说出口的产品要求。

这次经历最有价值的地方，是揭开了 AI 规划的一种盲区：它可以认真核对你说过的话、当前运行的代码，却把「系统今天的样子」当成「未来必须保留的样子」。多加审查还不够，得先审查计划赖以成立的假设。

为什么查对了代码，仍然会做错计划

作者负责 GoodBarber 的工程工作，需要为生产系统的一次大型变更制定分阶段架构计划。他没有公开具体系统，也没有展示完整计划，因此能讨论的是流程及其失误，无法独立判断方案质量。

起初，常规模型根据目录名、URL 路由、提交信息和 docstring 描述了相邻服务。作者要求它只信代码。模型重新核查后，把下面的规则交给了后续所有 Agent：

- Read only: you modify, create and delete nothing. You run no server,
  no migration, no script that touches a database or the network.
- Only executable code is evidence (cite file:line). Markdown files,
  docstrings, comments, commit messages and folder names are leads to verify.
- You can't ask the owner questions during this work: every uncertainty
  becomes an open question, with the assumption you made.

这段约束解决的是调查边界和证据标准。尤其要看最后一行：工作流不能中途提问，所有不确定性都应登记为问题，并注明采用的假设。

需求也有防失真措施。常规模型逐字记录作者的要求与回答，再用 12 个编号要点复述理解，提出 4 个会改变方案的歧义问题。作者回答后，才形成约 2500 词的任务说明。

但这些检查都绕着已有材料转：需求审查对照作者说过的话，事实审查对照代码。没人明确要求检查「作者没说过、却足以改变架构的事情」。

遗漏的两个要求，计划其实已经用当前代码的行为替作者作了决定。常规模型把现有边界写成系统事实，规划模型进一步把它们当成架构保证。后来它还承认，代码里存在 3 个相关的弱信号，自己记录了，却没有转成问题。

事实正确，不代表它有资格成为未来的约束。

需求检查器也并非完全不会推断。它主动问过：客户迁入新系统之前，新系统是否必须具备旧系统的全部能力？但这个问题紧挨着明确需求。真正漏掉的两项只被轻轻带过，现有代码又朝相反方向实现，更容易被默认过去。

多模型审查能纠错，但评分和引用都要复核

作者把常规模型用于访谈、代码调查、编排、验证及后续执行，把最强的昂贵模型用于规划，并要求作者模型不要独自审查自己的方案。

昂贵模型的每 token 价格是常规模型的 2.5 倍。作者认为，一次性计划会影响数周工作，这个差价可以接受；速度慢在日常交互中难受，在一次规划中相对次要。原文没有披露具体模型名、总 token 或总费用。

架构阶段用不同切入角度并行生成完整方案：

const plans = await parallel(ANGLES.map(a => () =>
  agent(`${RULES}\n${READ_BRIEF}\nYou are architect ${a.key}. Your starting angle: ${a.title}. ` +
        `The angle is a starting point, not a limit: your plan covers the whole deliverable.`,
        { label: `architect:${a.key}`, model: COSTLY_MODEL, effort: 'xhigh' })))

要看最后一行的 model: COSTLY_MODEL 和 effort: 'xhigh'：作者在每次 agent() 调用中指定模型和推理强度。这是其 Claude Code 工作流脚本的写法，原文没有提供完整运行环境，不能当成可直接复制的通用 SDK 示例。

初轮有 3 名架构师、2 名裁判、综合步骤及 3 名使用另一模型的审查者。首次结果被截断后，常规模型从记录中重建出 13 个里程碑和 32 个开放问题。

裁判的表现尤其值得看。一位偏好安全优先方案，另一位偏好迁移最稳妥的方案。按每位裁判的 6 项评分相加，前两名只差 1 分，而且两位裁判都没有选择自己总分最高的方案。评分表提供了讨论材料，却没有自动消除判断偏好。

引用也不能直接当真。裁判抽查了 71 次 file:line 主张，其中包含重复检查：58 次完全成立，13 次需要修正或补充限定。最严重的是，模型把计划新增的字段写成了代码里已经存在的字段，还给出精确位置。

这支持保留引用抽查，但不能据此推出所有引用的错误率。它是抽样结果，且样本并不完全独立。

真正改变计划的是提问和交锋

发现遗漏后，作者没有接受补充附录，而是让模型判断：新要求是否推翻原方案？昂贵模型的两次独立评估，加上常规模型的挑战审查，均认为需要重写。第二轮检查又提出 44 条意见，其中 3 条阻塞、27 条重大、14 条轻微。

第三版开始记录被拒绝或被限定的审查意见，并解释原因。作者更信任这种修订者，因为初版接受了 51 条中的全部 51 条，而中间版本确实曾过度采纳审查结论。

此时计划增至约 4.5 万词，问题从 32 个增至 69 个，其中 14 个专门追问未被表达的盲区。作者让常规模型逐个询问会改变架构的问题，再按主题分批提问。每题提供代码背景、规划假设和可选建议，回答保留原话。

69 个问题用了约 70 分钟，并问出了任务说明里没有的 3 条原则：与旧系统并行部署且不销毁现有内容；只改一个部分；依赖其他团队时写清需求，由对方决定实现。第四版吸收回答后，又提出 14 个问题。

之后，来自另外两个模型家族的审查者各从两个角度检查，提出 30 点。常规模型逐项查代码，确认 26 点，舍弃 4 点。昂贵模型在新会话中重新核验，结论一致，但对修复建议只认可 1 项，认为 1 项过度、其余 28 项不完整，并对 7 条发现中的具体论断提出异议。

它还挑战了作者约十几个回答。最尖锐的一项要求，作者团队曾有意否决过两次，理由就在代码里。作者修改了多数被质疑的回答，保留并细化了其中一个。最后一晚又讨论了 30 个问题，多数分成 5 组。

负责人需要决定产品取舍，模型需要把这些取舍的代价讲清楚。

资源也成了现实限制。28 个 Agent 并行核验，约半小时就撞上会话限额，数小时后改为每次 3 个继续。第五版写作又触及用量上限，常规模型保留已写好并审查的 11 部分，审查第 12 部分，再以每次 2 个 Agent 补完余下内容，最终合成约 11.5 万词的文件。

我的判断

最值得采用的是把「当前事实」「未来要求」「尚未确认的假设」分开。代码适合证明现在怎么运行，负责人负责决定什么必须保留，两者之间需要显式提问。

逐字需求记录、引用抽查、允许修订者反驳审查者，也都有明确价值。它们分别减少转述漂移、事实幻觉和盲目接受建议的风险。

但这仍是一份经验记录。作者没有提供单模型、少量 Agent 或人工评审的对照，也没公开最终实施结果，不能证明这套复杂流程更省钱、更快或更可靠。模型对自身失误的解释同样是事后分析，不能单独作为原因已被证实的依据。

11.5 万词也不等于更好的计划。原文已经展示了长文档的阅读负担：69 个问题放在文末，很可能无人回答。一般团队更适合先做短的假设确认，再决定是否需要多模型对抗。审查资源应跟着决策风险走，而不是跟着文档长度走。

能拿来做什么

• 给 AI 布置前端、Node 或全栈迁移任务时，先要求它提交「你没有说、但我准备默认成立的假设」，确认后再生成架构计划。
• 把现状边界逐项标成「必须保留的要求」或「允许挑战的事实」，尤其检查迁移范围、数据位置、部署归属及用户身份这些容易被默认的问题。
• 保存需求原话，并抽查关键 file:line 引用，重点核验那些会决定数据结构、兼容策略和迁移顺序的判断。
• 让模型先询问会改变架构的问题，再按主题处理其余问题；最终修订应能追溯到具体回答或审查发现，被拒绝的意见也要留下理由。