Agent 架构之争：单体 vs 多代理的工程哲学

在构建长期运行的智能代理（AI Agent）时，工程团队面临一个核心架构选择：

• 单体代理：让一个连贯的代理掌控全局上下文，保持决策一致性
• 多代理系统：将任务拆分给多个子代理并行探索，加速信息检索

2025 年 6 月，两篇代表性文章站在了这场争论的两端：

• Cognition 的 Don't Build Multi-Agents 强调上下文工程与决策一致性
• Anthropic 的 How we built our multi-agent research system 展示多代理在研究任务中的成功实践

本文将两种观点并置讨论：何时用哪种？工程上如何折衷？有哪些混合策略值得探索？

---

核心观点对比

Cognition：为什么不该默认使用多代理

核心论点：Context Engineering（上下文工程）是关键

• 问题根源：动作包含隐含决策，决策在多个代理间分散会导致冲突难以收敛
• 经典案例：构建 Flappy Bird 克隆
  • 子代理 A 误建成 Super Mario 风格背景
  • 子代理 B 构建的鸟与游戏不符
  • 主代理难以整合不一致的输出
• 推荐方案：单线程线性代理 + 历史压缩模型（针对超长任务）
• 核心原则：
  1. 共享完整上下文（Share context）：不只是消息，而是完整的代理轨迹
  2. 动作包含决策（Actions carry implicit decisions）：冲突的决策产生糟糕结果

Anthropic：多代理研究系统的成功实践

核心论点：多代理在合适场景下显著提升性能

• 实证数据：多代理系统（Opus 4 主控 + Sonnet 4 子代理）在内部研究评估中比单代理 Opus 4 提升 90.2%
• 性能因素：Token 使用量解释了 95% 的性能方差（BrowseComp 评估）
• 适用场景：广度优先查询，需要同时探索多个独立方向
• 成本代价：多代理系统消耗约 15× 聊天模式的 token
• 工程保障：
  • Prompt 工程（8 大原则）
  • 工具设计与 MCP 服务器
  • 可观测性与错误恢复
  • Rainbow 部署策略

两者并非对立

Cognition 关注长期一致性与决策集中化风险；Anthropic 展示了通过严格工程管理，多代理可在复杂研究场景中成为生产级系统。核心分歧在于适用场景判断与工程复杂度承受能力。

---

分歧根源：四大核心张力

1. 一致性 ⚔️ 并行性

2. 上下文规模与表征

• 单体困境：必须解决长时记忆与历史压缩问题（Cognition 建议引入专门的压缩模型）
• 多代理方案：分布式上下文（每个子代理独立窗口）扩展总 token 容量
• 代价：引入跨代理对齐成本与「信息电话游戏」风险

3. 可观测性与调试复杂度

• 单体优势：完整会话轨迹易于回放，错误链路清晰
• 多代理挑战：
  • 需要追踪多个并行执行流
  • Agent 交互结构监控（who-called-whom）
  • Checkpoint 与状态一致性保证
  • 涌现行为（emergent behaviors）难以预测

4. 成本-价值权衡

经济成本：多代理 ≈ 15× 聊天模式（Anthropic 数据）
开发成本：多代理需要更复杂的工程、监控与评估
适用判断：仅当任务价值显著高于额外成本时采用

---

实践决策树：何时用哪种架构？

✅ 优先单体代理的场景

高耦合任务

• 代码重构/修改（需要维护整体风格与依赖关系）
• UI/UX 设计（需要视觉与交互一致性）
• 复杂的多步骤推理（各步骤紧密依赖）

强一致性要求

• 法律文书、合规报告（术语与逻辑必须统一）
• 学术论文写作（论证链路需要连贯）
• 金融分析（假设与模型需要一致）

预算或时间受限

• MVP/原型阶段（降低系统复杂度）
• Token 成本敏感的应用
• 小团队缺乏多代理工程经验

✅ 采用多代理的场景

广度优先探索

• 市场调研（并行分析多个细分市场）
• 竞品分析（同时研究多家公司）
• 科研文献综述（并行检索不同数据库）

可分解的独立任务

• 信息抽取与聚合（如：「找出 S&P 500 信息技术板块所有公司的董事会成员」）
• 多源数据验证（交叉对比多个来源）
• 并行实验/测试（A/B/C 方案同时探索）

工件驱动的协作

• 子代理产出结构化工件（JSON/CSV/文档）
• 主代理通过引用而非复制大上下文
• 可持久化中间结果供后续复用

---

五大混合策略：工程折衷方案

1️⃣ 主控-限定子代理（Orchestrator-First）

模式：主代理掌控全局，子代理仅执行受限任务

LeadAgent
├─ 思路分解 & 任务分配
├─ 派发子代理（调查/验证）
└─ 保留最终整合与决策权

实例：Anthropic Research、Claude Code 的子任务代理

关键设计：

• 子代理不直接写代码/做决策，只回答明确问题
• 子代理工作不保留在主代理历史中（节省上下文）

2️⃣ 记忆与压缩层（Memory Agent）

模式：专门模型负责历史压缩与事件抽取（Cognition 推荐）

DetailedHistory → CompressionModel → KeyEvents/Decisions
                                   → 主/子代理读取摘要

技术要点：

• 可考虑针对特定领域微调小模型
• 提取：关键决策、中间结果、失败教训
• Cognition 在生产中已实施此策略

3️⃣ 工件驱动通信（Artifact-First）

模式：子代理写持久化工件，主代理读引用

typescript
1// 伪代码示例
2subagent.writeArtifact('/artifacts/market-research-Q1.json', data);
3leadAgent.read(artifactRef); // 仅传递引用，不复制内容

优势：

• 降低 token 传输开销
• 工件可复用、可审计
• 避免「电话游戏」信息损耗

4️⃣ 契约与决策边界（Contracts）

模式：显式声明子代理的输入/输出规范

契约要素：

• 输出格式（JSON Schema）
• 失败语义（错误码、回滚策略）
• 资源上限（max_tools, max_tokens）
• 审计字段（created_by, timestamps, tool_calls）

目标：将隐含决策转化为可验证断言

5️⃣ 动态预算与资源控制

模式：主代理分配资源预算，子代理受限执行

yaml
1Subagent_A:
2  budget:
3    max_tools: 10
4    max_tokens: 50000
5    timeout: 5min
6  on_exceed: abort_and_report

预算策略：

• 简单问题：1 代理 + 3-10 工具调用
• 对比任务：2-4 子代理 + 各 10-15 调用
• 复杂研究：10+ 子代理 + 明确分工

---

工程细节与测试策略

• Prompt 工程与可视化仿真：像 Anthropic 那样，在沙箱中复现 agent 行为，观察交互模式并以此调整提示语。
• 可观测性：记录决策图、工具调用序列、异常与重试路径；使用端到端回放能力来重现失败场景。
• 评估：对多代理输出使用 LLM judge + 人工抽样的混合评估；对修改类任务采用端状态（end-state）评估而非逐步评估。
• 部署策略：使用 rainbow/渐进部署来避免在运行中断裂长期 agent 的执行状态。

---

成本与商业考量

• 经济成本：多代理的 token 与调用成本显著更高，需要在任务价值上取得平衡。
• 开发成本：多代理系统需要更复杂的工程、监控与评估投入；但在高价值探索性任务上，收益往往能覆盖这些成本。
• 合规与隐私：多代理状态分散可能带来审计与数据治理复杂性，需要把敏感上下文的访问控制与日志需求纳入设计。

---

未来方向（发散思考）

• 跨代理上下文协议：一种通用的“context contract”协议，用于声明决策假设、风格表述与可验证断言，可用于跨代理一致性校验。
• 去中心化共识层：子代理之间通过轻量级共识算法（或裁判模型）达成可解释的决策对齐，而非完全依赖主控。
• 层次化代理栈：多个抽象层，每层做不同粒度的规划/执行——比如策略层、战术层、执行层，各层可根据任务需求以单体或多体运行。
• 可训练的对齐器（alignment agents）：专门训练的小模型负责检查各代理输出的一致性与安全性，作为流水线中的守门人。
• 人机协同编排器：把人类作为高层审议者嵌入回路，在关键决策点进行人工确认或批注，从而在风险高的场景下保留人工主权。

---

三种参考架构拓扑

架构 1️⃣：单体线性代理

适用：耦合任务、强一致性需求、小规模项目

User → Agent → Tool₁ → Tool₂ → ... → Toolₙ → Output
       [单一连续上下文]

代表实现：大多数单代理 coding assistant、文档生成工具

架构 2️⃣：主控-子代理（Orchestrator + Workers）

适用：可分解任务、广度探索、高价值研究

           LeadAgent (主控)
          /     |     \
    Subagent  Subagent  Subagent
        ↓        ↓        ↓
    Artifact Artifact Artifact
        \        |       /
         \       |      /
          LeadAgent (汇总)
                ↓
            Output

代表实现：Anthropic Research、复杂情报系统

架构 3️⃣：工件驱动协作

适用：大规模输出、可复用中间结果、审计需求

Subagents → [Artifact Store] ← LeadAgent
            (filesystem/DB)      (read by ref)

实施要点：

• 工件格式标准化（JSON Schema）
• 原子写入（临时文件 + 重命名）
• 版本控制与哈希校验

---

推荐的 mermaid 架构图（可复制到 Mermaid/MD 渲染器）

mermaid
1flowchart TD
2   U[User] -->|Query| Lead(Lead Agent)
3   Lead -->|Plan & spawn| SA1(Subagent A)
4   Lead -->|Plan & spawn| SA2(Subagent B)
5   SA1 -->|write artifact| Store[(Artifact Store)]
6   SA2 -->|write artifact| Store
7   Store -->|reference| Lead
8   Lead -->|synthesize| Out[Final Output]

---

Prompt 模板与契约示例

1. 主控（Orchestrator）询问示例（template）

text
1You are the LeadResearcher. User asks: "{{user_query}}".
2Goal: produce a concise research plan with N subtasks.
3For each subtask, provide:
4   - id
5   - short objective (1 sentence)
6   - expected output format (json-schema or artifact path)
7   - tool hints (which search tools/apis to use)
8   - budget: {max_tools: X, max_tokens: Y}
9
10Return a JSON array of subtask objects.

1. 子代理（Subagent）任务说明模板

text
1You are SubAgent {{id}}. Objective: {{objective}}.
2Output: produce an artifact at path {{artifact_path}} with schema: {{schema}}.
3Constraints: do not exceed {{max_tools}} tool calls and {{max_tokens}} tokens. If you hit an error, write an error object to {{artifact_path}}/error.json and stop.

1. 简要契约（JSON Schema）示例

json
1{
2   "$schema": "http://json-schema.org/draft-07/schema#",
3   "type": "object",
4   "properties": {
5      "id": {"type": "string"},
6      "summary": {"type": "string"},
7      "sources": {"type": "array", "items": {"type": "string"}},
8      "data": {"type": "object"}
9   },
10   "required": ["id","summary","sources"]
11}

契约要点：输出格式、失败语义、最大资源消耗、可验证的审计字段（created_by_agent, start_time, end_time, tool_calls）。

---

示例实现片段（伪代码）

下面给出一个简化的 TypeScript 风格伪代码，说明主控如何派生子代理并收集工件：

ts
1// 简化示例，不含网络/错误处理
2type Subtask = { id:string, objective:string, artifactPath:string, budget:{maxTools:number}};
3
4async function orchestrate(query:string){
5   const plan = await leadAgent.plan(query); // 返回 Subtask[]
6   const promises = plan.map(st => spawnSubagent(st));
7   await Promise.all(promises);
8   const artifacts = plan.map(st => readArtifact(st.artifactPath));
9   return await leadAgent.synthesize(artifacts);
10}
11
12async function spawnSubagent(st:Subtask){
13   // 启动子代理流程：prompt->工具调用->写artifact
14   await subAgent.run(st.objective, st.artifactPath, st.budget);
15}

说明：工业实现需要更多健壮性（重试、幂等写入、签名验证、并发限制、cost accounting）。

---

监控、可观测与评估指标

• 运行时指标（实时）：子代理并发数、平均工具调用次数、平均 token 使用、子代理失败率、任务完成延迟。
• 行为指标（语义）：结果完整度（coverage）、重复率（duplication between subagents）、一致性得分（consistency score，由 LLM judge 给出）。
• 经济指标：每次查询平均成本、99 分位延迟成本比、资源回收率。
• 质量评估：使用 LLM judge + 人力抽样，基于 rubric 打分：准确性、引用匹配、覆盖度、可信度。

监控建议：把 agent-level trace（prompt、tool calls、artifacts、errors）写入结构化日志，并在面板中展示决策图（who-called-whom、依赖关系）。

---

调试与可靠性工程要点

• Checkpoint 与恢复：在长任务中周期性 snapshot 计划/状态（例如每完成一个阶段写入 memory agent 或持久存储）。
• 幂等写入：子代理写工件时使用临时路径 + 原子重命名以避免不完整写入造成的“脏读”。
• 灰度部署：使用 rainbow deployment 和兼容性层，保证正在运行的 agent 可以在老版本下继续执行或安全迁移。
• 观测驱动 prompt 调整：在沙箱中回放失败用例并让 LLM 产生改进提示，再 A/B 验证效果。

---

评估样例：一个简单的 Rubric（用于 Research 输出）

• Factual Accuracy (0.0-1.0): 断言是否可被来源支持。
• Source Fidelity (0.0-1.0): 引用是否精确到段落/页面。
• Coverage (0.0-1.0): 请求覆盖面的完整度。
• Efficiency (0.0-1.0): token 与工具调用是否与任务复杂度匹配。

复合评分 = 0.4Accuracy + 0.3Source + 0.2Coverage + 0.1Efficiency。

---

安全、合规与审计建议

• 数据访问控制：明确哪些上下文可传递给子代理，敏感上下文使用脱敏摘要或仅保留引用。
• 审计日志：所有子代理的输入/输出摘要、决策元数据与工件哈希应可供审计（保留原始内容的访问策略）。
• 可回滚策略：对于会改变外部系统状态的 agent（例如修改数据库、发布内容），先采用 dry-run / staging artifact，再人工或自动确认后执行最终变更。

---

成本计算示例（简化）

• 单体代理：TokenCost = T
• 多代理：TokenCost ≈ 4×T（实际波动大，取决于并行度与重复查询）

结论：仅在任务价值显著高于额外成本时采用高并行度的多代理策略。

---

结论与行动建议

1. 初创/小规模项目：从单体线性代理开始，先解决上下文压缩与记忆问题，降低早期复杂度。
2. 当任务天然并行、需要广度探索，且有资源时：采用主控-子代理架构，并实现工件驱动的通信以降低 token 负荷。
3. 始终把“契约”（输出格式、失败语义、资源预算）嵌入设计，避免隐含决策造成的语义漂移。
4. 把观测、评估和快速迭代作为项目一等公民：prompt 与工具描述的微调常常带来最大的收益。

最后，单体与多体并非对立端点，而是工程光谱上的点：合理的折衷、可验证的契约与严格的观测能力，才是把 agent 系统从原型拉到生产的关键。

---

参考文献

1. Walden Yan. "Don't Build Multi-Agents". Cognition Labs Engineering Blog. June 12, 2025.
   🔗 https://cognition.ai/blog/dont-build-multi-agents

2. Jeremy Hadfield et al. "How we built our multi-agent research system". Anthropic Engineering Blog. June 13, 2025.
   🔗 https://www.anthropic.com/engineering/multi-agent-research-system

3. Anthropic. "Building Effective Agents". Anthropic Developer Guides. 2025.
   🔗 https://www.anthropic.com/engineering/building-effective-agents

4. OpenAI. "Swarm: Educational framework for multi-agent orchestration". GitHub Repository. 2025.
   🔗 https://github.com/openai/swarm