之前关于多 Agent 架构，我更多是在讲边界、上下文和协作方式。这次我做了一个小型实验平台 Agent Architecture Lab，把不同 Agent 架构放到同一批任务下面跑了一遍。
实验规模不大，但结论很明确：复杂架构不是质量放大器，而是成本、上下文和失败面的放大器。只有当任务确实需要拆解、审查或多立场权衡时，多 Agent 才可能值得。
实验怎么做
实验任务分成四类：生成平台方案、扩展详细设计、审查详细设计，以及从审查报告里选择一个最有取舍的问题给出技术判断。
我比较了四种架构：single、planner_executor、planner_executor_reviewer 和 debate。观察指标包括耗时、token 消耗、估算成本、是否截断、最终答案可用性，以及中间过程是否有复盘价值。
这不是严格的大样本实验，但它足够暴露工程运行中的典型问题。
Single Agent 仍然是强基线
实验里，single 是成本和延迟最低的架构，稳定性也最好。四个任务都没有截断，在简单方案和明确技术取舍任务中，输出质量并不弱。
这说明 Single Agent 不是过时方案，而是所有复杂架构必须证明自己值得超过的基线。如果任务边界清楚、输入充分、输出结构明确，引入多个 Agent 很可能只是增加过程成本。
Planner 有用，但要管住输出
planner_executor 在审查类任务中效果不错，因为审查天然需要覆盖多个维度。Planner 先拆检查项，Executor 再逐项执行，确实有助于提高覆盖度。
但 Planner 也会制造输出膨胀。在详细设计任务中，它推动 Executor 覆盖更多章节，最终出现 finish_reason=length。Planner 不应该只是让模型多想一点，还应该管理章节预算、长度约束和输出边界。
Reviewer 的价值必须被看见
planner_executor_reviewer 成本最高、延迟最高，但这次没有带来稳定的质量跃迁。即使引入 Reviewer，详细设计任务仍然截断。
Reviewer 的价值不在于多一次模型调用，而在于能留下证据链：草稿是什么，审查意见是什么，最终答案改了什么。如果这些信息没有被结构化呈现，用户只能看到最终答案，那 Reviewer 就只是昂贵的形式主义。
Debate 只适合真实取舍
debate 在技术取舍判断中最有意义。比如 Snapshot Mode vs Chain Mode，一个强调公平、隔离和可复现，另一个强调连续性、状态传递和真实工作流，这种任务天然适合多立场辩论。
但 Debate 不适合所有任务。没有真实分歧的任务里，它往往退化成一个 Agent 给方案、另一个 Agent 补风险、Judge 做汇总，成本增加了，但不一定带来真正的对抗性思考。
复杂架构的代价很具体
这次实验里，planner_executor 的成本约为 single 的 2.42 倍，debate 约为 3.90 倍，planner_executor_reviewer 约为 6.17 倍。
这还只是模型调用成本。实际工程里，还要考虑结果存储、中间过程展示、失败重试、超时处理、前端可视化、人工复盘成本和更复杂的调试路径。
写在最后
多 Agent 架构的价值不是让模型突然变强，而是把复杂任务里的不确定性组织起来。Planner 组织任务结构，Reviewer 组织质量反馈，Debate 组织立场冲突，Judge 组织最终合并。
但这些结构都有成本，也都有失败方式。真正的工程判断不是能不能加 Agent，而是加了以后，系统是否真的更可控、更可靠、更值得。