# 多 Agent 协作的技术内核：价值来自结构，不是并发


先说结论：多 Agent 的价值不来自模型多，来自结构对。没有结构的多 Agent 只是更贵的并发——多花 2 到 3 倍的 token，听一群模型互相点头；有结构的多 Agent，才是能委派、能并行、能验证的执行系统。


<!-- more -->

## 一个 Agent 干长活，为什么不行

先诊断。单 Agent 执行复杂任务有五个结构性毛病，不怪模型智力，怪执行结构：

- **停止判断不确定**。一个含 7 个子任务的目标，模型可能干完 3 个就停下来汇报，问你要不要继续。它"觉得"自己干完了。
- **长任务退化**。上下文越攒越脏，早期要求被遗忘，方向偏了继续沿着偏的走。错误一旦产生，内部没有机制打断。
- **自检自证**。它很真诚地检查自己的成果，但检查的还是自己刚构造出来的现场。裁判和选手是同一个人，自证不算外部证据。
- **长周期与交互预期冲突**。分钟级甚至小时级的活，和秒级反馈的预期打架；后台任务和活跃对话共用上下文，互相污染。
- **角色扮演不等于角色分工**。给同一个 Agent 换 prompt 扮演"计划者""执行者"，那不叫分工。分工在上下文层面至少分四个维度：工具、上下文、记忆、Skill。

这五条里最要命的是第三条。自己给自己批卷子，批出来全是满分——这毛病人也有，模型也有。

## 内核：七件事

### 价值来自结构，而非并发

判断一个多 Agent 系统值不值得建，别看它能同时启动多少 Agent，看五个问题：为什么拆分、如何验收、何时停止、失败怎么恢复、记忆怎么管。这五个问题本身就是多 Agent 的验收标准。

反面教材是研究界早就做过的实验：同质模型互相 [debate](https://arxiv.org/abs/2402.06782)，消耗是单 Agent 自我修正的 2.1–3.4 倍 token，准确率没有提升，有时更差——2024 年那篇论文里，模型甚至会被更有说服力的错误论证带偏。多个同质模型互相确认，只是把不确定性并行扩散。

### 生产与验证，要对抗，不要合唱

核心协作流就三类角色：

- **Leader**：定计划，拆任务，判断值不值得开团队、拆多细、重试几次、什么时候升级给人类。
- **Worker**：干活，各自有不同的工具、上下文和输出要求。角色越清楚，输出越容易被复用、比较和检查。
- **Verifier**：把关，查事实来源、覆盖清单、风险边界，有权把活打回去。

关键设计是 Worker 和 Verifier 的对抗关系：研发和质检的关系，不是同事互相客气的评审会。状态机管每个任务的周期：`producing → verifying → done`，verifying 没过就打回 producing，直到通过或触发停止条件。

为什么非要对抗？因为多 Agent 顺序接力时幻觉会放大：A 的偏差被 B 强化、被 C 叠加，最后收敛成一个高置信度的错误结论。独立验证者就是来打断这条链的——另一种打断方式是 Claude Code 那种[分叉-汇聚]({{< ref "posts/2026-06-24-claude-code-multi-agent.md" >}})，但汇合点同样需要一个检查者。这个设计和 Anthropic 那篇 [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) 里的 Evaluator-Optimizer 同构，但姿态更明确：验证不是生产者的自我改进，而是独立主体的否决权。

### 上下文是钱

多 Agent 协作暴露三类没法靠加大 context window 解决的工程成本：

1. **交接成本**：同一段信息在不同 Agent 之间要重新组织。对策是交接物结构化：一份可读的交接文件加一块共享留言板，Agent 之间靠"文件路径 + 摘要"做慢通信，别一次性全塞进上下文。
2. **共享成本**：每多一段共享内容，每个 Worker 每一轮都要为它付 token。对策分三档：Agent 内记忆（广播给同类 Agent）、Agent 间通讯通道（直接对话）、白板（大容量，按需读）。对应"主动通知 → 直接对话 → 按需读取"的递进。
3. **聚合成本**：并行收集十份结果容易，合成一份事实一致、引用对得上、风格统一的交付物很难。聚合是 Leader 的贵活，"把 10 份合到 1 份"。

设计含义一句话：共享信息按"是否值得每个 Worker 每轮付费"来评估。隔离是默认，共享是例外。

{{< figure src="/pictures/posts/multi-agent-technical-core-cost-models.svg" alt="三类上下文成本模型" caption="三类上下文成本：交接、共享、聚合" >}}

### 是 runtime，不是 prompt 编排

写几段 prompt 让模型扮演不同角色，那是演示，不是系统。真实复杂度在控制面：任务状态机（每个运行周期是一个 session）、多来源事件（用户、其他 Agent、定时触发、系统监控）、可观测性、门禁。权限约束和写记忆的约束不能靠 Agent 自觉，要靠软硬门禁拦截。

行业证据同向：主流 Agent 框架都在强调 sandbox、workspace、handoff、tracing；企业级产品把 Runtime、Memory、Identity、Gateway、Browser 列为模块。重心正在从"写 prompt"转向"维护控制面"——这个方向我在 [Agent 运行时动态干预]({{< ref "posts/2026-07-07-ai-agent-runtime-dynamic-intervention.md" >}})里也聊过。

### 接口平权，责任不平权

对 Agent 的操作——发起、派生、中止、终止——可以抽象成一组统一接口，调用方可以是用户、其他 Agent 或系统引擎。接口平权带来统一的控制面和审计面，但两条边界要守住：平权不等于无限权限，Agent 不因获得接口而获得权限；人类不退出责任链，合并代码、覆盖线上数据这种高风险动作，必须有人类签字。

只有当 Agent 和人类共享同一个可审计协作面，权限、责任和风险才看得见。审计是平权的前提，不是平权的副产品。

### 状态外化

长任务跨多轮消息、多个工具、多个 Agent，不能赌任何单个模型的上下文不丢。任务状态、事件日志、文件产物、决策记录，都要保存成可恢复对象；session 本身也是外部上下文对象，不等于模型的 context window。可恢复性是异步执行的前提。换个说法：session 会丢，文件不会。

### 记忆沉淀

每次运行的执行经验可以沉淀成记忆和 Skill，让同一角色的 Agent 越用越懂用户、越懂协作。成长本身计入 ROI，不只看单次 token 消耗。

所以选型判据很清楚：任务越复杂、链路越长、风险越高、经验越可复用，团队式协作越划算；任务越短、越确定，单 Agent 或传统自动化更好。不该鼓励"凡事开团队"，该帮人判断什么时候值得协作，什么时候保持简单。

## 四种场景，一个内核

- **异步长任务**：任务和对话解耦，先秒级确认目标，后台拆开干，关键节点回报（开始、阻塞、需决策、完成）。用户随时能跟计划者说话，不污染执行上下文。
- **编码 Harness**：Developer 实现（输出修改理由、潜在风险、验证建议），Tester 给外部证据——验证结果来自命令、测试、可执行检查，不是模型拍脑袋；Reviewer 回答"该不该这么改"（抽象边界、兼容性、权限扩大、敏感信息）。停止条件绑在 test、lint、build、format check 上。
- **并行研究**：拆成并行信息通道，独立 Verifier 查来源可复查性（稳定 URL 优先，缓存页只能当线索）、是否过期、有没有反面证据，合成器再合并成结构化结论。
- **文档流水线**：Planner 定目标与结构，Writer 写正文，Formatter 排版，Evaluator 独立检查内容、格式、文件完整性。文档生成被改造成 CI/CD：每步有中间件，每步有检查，每步失败可局部重试。

## 五个待完善的点

1. **计划者是新的单点**。开头批评单 Agent 停止判断不确定，但方案里的 Leader 也是模型，也承担拆解粒度、重试策略、升级决策。这是把单点从执行层搬到决策层，不是消灭单点。
2. **验证者的锚点在部分场景模糊**。编码场景锚点清楚（命令、测试、可执行检查），但研究、文档场景里，验证者同样是模型，如果"检查来源可复查性"没有稳定 URL、版本时间戳这种硬锚点支撑，对抗关系会退化成两个模型的互相说服。对抗性需要可操作的验证标准。
3. **安全边界没展开**。Agent 对 Agent 可以发起中止，那防滥用机制呢？"软硬门禁"各自拦截什么（路径、命令、网络出口）？审计怎么保证防篡改、保留期？
4. **没有量化数据**。上文没有成功率、成本对比、故障恢复时间。"用户愿意为可验证的结果等更久"是假设，不是测量。
5. **诊断和处方不对称**。开头把单 Agent"中途停下"归为执行结构的毛病，后面又主张停止条件可以绑定外部系统——既然停止条件能外部化，单 Agent 的中途停下，相当程度上是设计选择，不是模型宿命。诊断和处方之间有个台阶。

## 工程启示，七条

1. **选型先过五问**：为什么拆分、如何验收、何时停止、失败如何恢复、记忆怎么管。任一问题答不上来，就别上多 Agent。
2. **落地顺序**：先协议（任务结构、状态机），再隔离（上下文、文件、权限），最后加对抗验证。顺序颠倒，协作就是灾难。
3. **验证要有外部锚点**：测试输出、命令结果、稳定 URL、时间戳。"看起来通过"的验证比没有验证更危险。
4. **成本护栏先于功能**：共享内容按每轮 token 评估；预设迭代上限、token 预算、超时升级。
5. **状态全部外化**：任务状态、事件日志、文件产物、决策记录落盘。session 会丢，文件不会。
6. **审计优先于平权**：全量可审计，控制接口才可授权；高风险动作保留人类签字。
7. **长期收益看沉淀**：把踩过的坑写成记忆，把有效动作固化成 Skill。这是相对一次性工具调用的真正复利。

多 Agent 的本质，是把"一个 Agent 既当裁判又当选手"的矛盾，拆成可对抗、可验收、可恢复、可审计的结构。结构是它唯一的产品力，成本模型是它唯一的准绳，记忆沉淀是它唯一的长期回报。