六个角色，不是六个窗口：一套长期项目的多 Agent 协作架构

多加几个 Agent，问题不会自动消失

一个 Agent 从需求分析一直做到编码、测试、审阅和最终判断，流程很短，却容易出现两个问题：执行者证明自己的实现正确；上一轮的猜测经过几次总结，变成下一轮的“已知事实”。

把任务交给更多 Agent 也不一定更好。如果每次分歧都请用户决定，每个角色都重新阅读整个项目，协作成本可能超过它发现的问题。

因此，这套架构的目标不是增加模型数量，而是为长期软件项目划定三种边界：谁负责推进、谁有资格验证、谁有权决定。

六个角色，各自回答一个问题

六个角色不是六个常驻窗口，也不必对应六种模型。Lead 维护项目主线；Coder、Validator 和 Reviewer 在任务需要时启动。Advisor 处理重大取舍；Auditor 在里程碑或系统性问题出现时，从更大的范围独立审阅。

这个拓扑在一个项目阶段内保持固定。不能因为某次任务难，就临时把子代理改为独立窗口，再让所有人重新适应交接方式。

单个任务如何闭环

常规开发由用户给出目标和约束，Lead 将它们转成可检查的范围与验收条件。需要实现时，Lead 把局部任务交给 Coder；实现后先运行适当的自动化检查，再由新的 Validator 上下文核对原始需求、实际代码差异和测试结果。

Reviewer 不是第二个 Validator。Validator 关注“这次实现是否满足要求”；Reviewer 仅在关键变更触发时，关注“这次变更是否破坏了其他模块所依赖的约定”。没有行为变化的简单文档调整，不必机械地经过全部角色。

Auditor 更不进入每个任务的循环。它审的是阶段目标、反复发生的问题和重要决策，包括 Lead 或 Advisor 先前的判断。Auditor 的原始报告应由用户和 Lead 直接取得，不能只留下被审阅者写的一段摘要。

整套交互可以拆成三条相连的路径，而不是让六个角色排队检查每个任务：

① 任务线：Lead 负责闭环

用户 → Lead（定范围与验收条件）
       ├─ 无行为变化：Lead 检查 → 交付用户
       └─ 需要实现：Coder → Lead 核对变更、运行检查
                         → Validator 独立验收
                           ├─ 未通过：Lead → Coder 修复 → 重新验收
                           └─ 通过：Reviewer（按变更风险触发，可跳过）
                                      ├─ 阻断：Lead 组织修复与复核
                                      └─ 通过／未触发：Lead 交付用户

② 决策线：阻碍回到有决策职责的角色

Lead（重大取舍／实施中新证据）→ 暂停受影响动作
  → Advisor 核证并裁决
     ├─ 原授权范围内：Lead 继续
     └─ 用户边界变化：Advisor 说明事实、风险和推荐
                       → 用户拍板 → Advisor 定案 → Lead 执行

③ 阶段线：独立于单次任务

里程碑／系统性问题 → 用户发起，或 Advisor 在已授权范围内发起
  → Auditor 独立核对原件 → 原始报告直达用户与 Lead
  → Lead 组织受影响部分的修复；新技术取舍回到 Advisor

图中的 Reviewer 只审本次变更，Auditor 只在阶段或系统问题触发时介入；“通过”均限于各自审阅范围，不表示用户已经授权执行。触发条件在任务开始前确定，不由 Lead 在收尾时临时增减质量闸门。

决策不能和授权混为一谈

日常、可逆的实现选择由 Lead 或任务范围内的 Coder 处理。影响长期兼容性、跨模块职责或返工成本的重大技术选择交给 Advisor。

用户决定的是另一层问题：产品目标、优先级、关键风险接受，以及超出既有范围的执行授权。Advisor 可以对技术方案给出明确裁决，却不能因为“方案已经选好”，就推断“用户已经批准部署”。

重大决策进入实施后，还会遇到一种中途状态：新证据推翻了裁决依据。此时 Lead 停下受影响的动作，把原裁决、已执行状态、新证据和待决问题交回 Advisor。Advisor 修订裁决；若修订仍在用户已确定的边界内，Lead 可以继续。若方向、风险或授权范围发生变化，则由 Advisor 带着事实、风险和明确推荐请用户重新拍板。

这避免了两种错误：Lead 私自改方案；或者把未经整理的技术难题抛给并不了解实施现场的用户。普通编码和测试错误仍由开发闭环处理，不必每次都升级。

长期状态是索引，不是事实的原件

长项目不能依赖一个无限增长的聊天上下文。项目状态可以记录当前目标、候选版本、已确认事实、假设、未知、风险和决策，但每条关键结论必须能回到原始依据：是哪份代码、哪个制品、什么环境、何时采集的什么结果，又有哪些路径没有覆盖。

例如，“隔离测试通过”和“生产目标路径已验证”是两个不同结论；“用户批准执行”和“原因已经查明”也不能互相推导。新证据推翻旧判断时，应追加更正并复核真正依赖它的下游决定，而不是悄悄改写历史。

角色之间也使用统一的任务与消息标识，区分请求、接手、执行结果、技术建议和独立审阅。消息写入不等于接收者已读，技术建议不等于验收通过，验收通过不等于执行授权。

独立会话当前可以由人提醒读取消息；自动通知和权限隔离属于需要另行接入、另行验证的运行机制。文档写了“只读”，并不能证明某个工具真的拒绝写入。

怎样判断这套架构是否值得保留

这仍是一套候选设计，不是已经证明更优的公式。多一次独立检查可能减少返工，也可能增加 Token、等待和误报；短生命周期子代理节省长期上下文维护，却可能反复读取相同代码。

真正需要观察的是单位项目进展的总成本：有效发现了多少问题、误报多少、返工几轮、用户被要求介入几次、交付耗时多久。权限边界还需要在隔离环境中验证：被禁止的操作是否真的会被工具拒绝，而不只是 Agent 自己声明“不会做”。

这套方案可以提炼成几条原则：

1. 角色拓扑在一个阶段内固定，不因任务难度临时改交接方式。
2. 技术裁决与执行授权是两回事——Advisor 定方案，不等于用户批准部署。
3. 长期状态是索引，不是事实原件；每条结论都要能回到原始依据。
4. 消息写入≠已读，技术建议≠验收，验收通过≠授权。
5. 用单位进展的总成本判断架构是否值得保留，而不是角色数量。

这套方案的核心，不是六个漂亮的角色名称。它试图让一项工作在长期推进中始终回答清楚：当前事实从哪来，下一步由谁判断，谁能验证结果，以及什么事情必须由用户决定。