多Agent系统的工程真相：成本路由与上下文边界

引子：你以为的多Agent，和实际的多Agent

> "最高效的开发者不忠于单一模型，而是通过成本路由——简单任务用便宜模型，复杂任务用强模型，批量任务用Agent Swarm——来构建最优的多Agent栈。成本直降85%，产出反而增加。"

如果你在 2025 年打开任何一个 AI 论坛，你会看到两种截然相反的声音：

一种说："多Agent是未来！我让10个AI一起写代码，效率翻倍！" 另一种说："多Agent就是灾难。协调开销比收益还大，99%的项目都在维护地狱里挣扎。"

两种说法都是真的。区别在于：前者说的是概念验证（PoC），后者说的是生产环境（Production）。

2026 年初，Anthropic 发布了多Agent协调框架，Kimi K2.6 内建了原生 Agent Swarm，Claude Opus 4.6 推出了 Agent Teams。多Agent从"框架层玩具"正式升级为"模型层能力"。

但与此同时，一个反常识的结论正在工程团队中形成共识：

最高效的多Agent系统，不是最强的模型堆在一起，而是最聪明的"成本路由"。

---

一、多Agent系统的三条死亡陷阱

在谈怎么做对之前，先看怎么做死。

陷阱 1：单模型崇拜（Single-Model Fanaticism）

很多团队的第一步是："我们用 Claude Opus 4.7 做所有事。它是最好的，对吧？"

一个真实案例的账单：

策略	月消耗（30M tokens）
100% Claude Opus 4.7	~$990
100% GPT-5.5	~$330
100% Kimi K2.6	~$48
100% DeepSeek V4-Flash	~$6
Phase-routed（规划→Opus，实现→V4-Flash，重构→K2.6）	~$25–40

数据来源：CodeRouter 2026 年 4 月基准测试

同一个工作量，从 $990 降到 $25。这不是"省钱"，这是"从不可行变为可行"。

多Agent系统的第一个真理：模型不是越贵越好，而是越对越好。

陷阱 2：协调地狱（Coordination Hell）

多Agent系统的核心假设是"分工带来效率"。但很少有人计算协调开销。

• Agent A 生成了一段代码
• Agent B 审查时发现需要修改
• Agent A 重新生成
• Agent C 测试时发现了边界条件
• 回到 Agent A

在 LangGraph、CrewAI 等框架中，这种循环的平均迭代次数是 4.7 次。每次迭代都要支付完整的上下文 token 费用。

更隐蔽的问题是上下文污染：当多个 Agent 共享同一个上下文窗口时，一个 Agent 的错误假设会被其他 Agent 当作事实继承，导致错误级联。

陷阱 3：伪并行（Pseudo-Parallelism）

很多 Agent Swarm 的演示看起来很酷：20 个 Agent 同时工作，处理一个大型任务。

但真相是：大多数"并行"Agent Swarm 采用的是 Map-Reduce 架构，而非真正的并行写入。

什么意思？

• Map 阶段：20 个 Agent 各自处理数据的一个切片（这是真正的并行）
• Reduce 阶段：一个协调 Agent 读取所有结果，串行地整合成最终输出

问题出在 Reduce。如果最终整合需要一个强模型（如 Claude Opus）来处理 20 份子结果的合并，那么这个"协调者"的上下文窗口会被迅速填满。一旦超过上下文限制，就必须采用分块→摘要→再合并的多轮策略，整体延迟从"并行"变成了"伪并行"。

---

二、3层架构模型：多Agent的工程底座

基于当前最前沿的工程实践（Anthropic 框架、Kimi K2.6 Swarm、Claude Code 内部架构），可以提炼出一个通用的 3 层架构模型。

Layer 1：规划层（Planning Layer）

职责：理解用户意图，拆解任务，制定执行计划。

用什么模型：强推理模型。Claude Opus 4.7、GPT-5.5、o3。

为什么：规划是一次性的、高杠杆的。一个错误的计划会让后面所有执行都白费。这里不能省钱。

上下文策略：给予完整的系统架构文档、API 规范、约束条件。允许消耗大量 token 来确保计划正确。

Layer 2：执行层（Execution Layer）

职责：按照计划执行具体的子任务。写代码、查资料、调 API、处理数据。

用什么模型：高性价比模型。Kimi K2.6、DeepSeek V4-Flash、Claude Sonnet 4.6。

为什么：执行是高频、重复性的。如果一个子任务是"给 100 个函数加 docstring"，用 Opus 做就是烧钱。DeepSeek V4-Flash 的单价是 $0.01/run，在这个场景下性价比碾压。

上下文策略：干净的上下文边界（Clean Context Boundaries）。

这是多Agent系统中最被低估的技术。Anthropic 的内部数据显示：当执行层 Agent 接收到严格限定的上下文（只包含当前子任务需要的代码片段和接口定义），而非完整的项目上下文时，发现严重 Bug 的概率提高了 58%。

原因很反直觉：更多的上下文不等于更好的表现。当 Agent 被淹没在无关信息中时，它会产生"幻觉式关联"——把不相关的代码模式错误地应用到当前任务上。限制上下文等于强制聚焦。

Layer 3：验证层（Validation Layer）

职责：检查执行结果的正确性、安全性、一致性。

用什么模型：专用验证模型 + 工具。

为什么：验证不需要和生成用同样的模型。实际上，验证往往更适合用规则引擎 + 轻量模型的组合：

• 语法检查：ESLint、black、mypy（工具，零 LLM 成本）
• 逻辑检查：测试运行（工具，零 LLM 成本）
• 语义检查：轻量模型验证输出是否符合预期（Kimi K2.6 或 Haiku 4.5）

Generator-Verifier 循环：这是 Anthropic 框架中的核心模式。一个 Agent 生成，另一个 Agent 验证。但关键在于：验证必须有明确的标准。没有明确验收标准的验证，只是" illusion of quality control without the substance"（质量控制的形式，没有实质）。

---

三、5种协调模式：什么时候用什么

Anthropic 在 2026 年 4 月发布的框架中，定义了 5 种多Agent协调模式。但框架文档只说"是什么"，没说"什么时候用"。以下是从工程实践中提炼的决策矩阵。

模式 1：Sub-Agents（Orchestrator-Subagent）

结构：一个主 Agent 委派离散子任务给子 Agent，子任务完成后子 Agent 销毁。

典型案例：Claude Code。主 Agent 在交互，同时后台 dispatch 子 Agent 去搜索大型代码库。

适用场景：

• 任务可清晰切分为独立子任务
• 子任务之间无状态依赖
• 不需要跨任务的领域知识积累

成本特征：协调开销低，但频繁创建销毁 Agent 有冷启动成本。

模式 2：Agent Teams

结构：多个 Agent 同时存活，各自负责一个领域，跨任务持续协作。

典型案例：Claude Opus 4.6 的 Agent Teams。大型系统迁移中，每个 Agent 负责一个服务模块，持续多轮交互。

适用场景：

• 长期项目（多轮迭代）
• Agent 需要在过程中积累领域知识（"这个模块的接口总是返回空，需要注意"）
• 子任务之间有持续的状态依赖

成本特征：避免了重复上下文的传输，但状态同步机制复杂。如果两个 Agent 对同一个文件做了冲突修改，需要额外的合并逻辑。

模式 3：Generator-Verifier 循环

结构：两个 Agent 形成闭环——一个生成，一个验证，验证不通过则重新生成。

典型案例：代码生成。Generator 写代码，Verifier 运行测试 + 静态分析。测试失败则返回错误信息给 Generator 重写。

适用场景：

• 输出有明确的可验证标准（测试通过、格式合规、数值范围正确）
• 容错成本高（医疗、金融、自动驾驶）

成本特征：验证通常比生成便宜。但如果 Generator 的首次成功率低，循环次数会急剧推高成本。经验法则：如果便宜模型的首次成功率 ≥85% 强模型的成功率，那么路由到便宜模型再 retry 的成本仍然更优。

模式 4：Smart Friend（Shared State / Message Bus）

结构：无中心协调者。Agent 通过共享状态池或消息总线自主协作。

典型案例：研究合成系统。Agent A 发现某个数据模式，写入共享状态。Agent B 读取后立即调整研究方向。

适用场景：

• 探索性任务（研究、创意、头脑风暴）
• Agent 之间需要高度灵活的信息流动
• 无法预先定义严格的任务分解

成本特征：避免了协调瓶颈，但可能出现"信息过载"——所有 Agent 都读取所有信息，导致上下文膨胀。

模式 5：Agent Swarm（Map-Reduce）

结构：大量同质 Agent 并行处理数据切片，最后由一个协调者聚合。

典型案例：批量数据处理、大规模代码重构、文档生成。

适用场景：

• 数据量大且可切分
• 子任务高度同质化
• 对延迟不敏感（可容忍 Reduce 阶段的串行瓶颈）

成本特征：真正的成本杀手。当任务可完美并行时，DeepSeek V4-Flash 的 $0.01/run 单价意味着 1000 个子任务只需 $10。但如果 Reduce 阶段需要强模型来处理海量子结果，整体成本会回弹。

---

四、成本路由：多Agent系统的第一性原理

3 层架构 + 5 种模式，最终都要回答一个问题：这个子任务，用什么模型做最划算？

这不是一个静态答案，而是一个动态路由策略。

成本路由矩阵（2026 年 4 月基准）

任务类型	推荐模型	单价（$/run 估算）	关键特性
规划/架构设计	Claude Opus 4.7	$2.75–5.00	最强推理，长上下文
复杂调试/错误定位	Claude Opus 4.7 / GPT-5.5	$2.00–3.15	推理深度决定发现率
代码实现（从 spec 写代码）	DeepSeek V4-Flash / Kimi K2.6	$0.01–0.29	便宜、快、足够好
测试生成	DeepSeek V4-Flash	$0.01	纯 bargain territory
文档/注释	Claude Haiku 4.5 / Gemini 3 Flash	$0.10–0.20	低于 $1 的 territory
代码重构（多文件）	Kimi K2.6 / DeepSeek V4-Pro	$0.54–0.29	1M 上下文或 Agent 连贯性
Agent 循环协调	Kimi K2.6	$0.29	原生 Swarm 协调
最终报告合成	Claude Opus 4.7	$2.00–5.00	需要高质量聚合

数据来源：CodeRouter 2026 年 4 月基准、o-mega.ai Kimi K2.6 分析、Akita on Rails 2026 年 4 月 LLM 基准

路由策略的两种实现

策略 A：基于任务类型的静态路由

在系统架构层面预先定义每种任务类型对应的模型。例如：

MODEL_ROUTER = {
    "planning": "claude-opus-4.7",
    "implementation": "deepseek-v4-flash",
    "testing": "deepseek-v4-flash",
    "refactoring": "kimi-k2.6",
    "documentation": "claude-haiku-4.5",
    "validation": "kimi-k2.6",
    "report_synthesis": "claude-opus-4.7"
}

优点：简单、可预测、易于审计。 缺点：无法适应任务的实际复杂度波动。

策略 B：基于上下文复杂度的动态路由

在运行时评估当前任务的复杂度指标（上下文长度、涉及的文件数、历史错误率、领域特殊性），动态选择模型。

Kimi K2.6 的 Claw Groups 就是这一策略的产品化实现：协调器根据每个子任务的特征，动态匹配到最合适的 Agent（可能是不同模型、不同设备、不同工具集）。

一个极端但真实的成本对比：

策略	月成本（1000 个复杂研究任务）
全 Claude Opus 4.7	$2,750
全 Kimi K2.6	$290
Claw Group 异构路由	$50–100

异构路由的逻辑：

• 网页搜索 → Grok 4.1 Fast ($0.20/MTok)
• 数据提取 → DeepSeek V4-Flash ($0.28/MTok)
• 代码生成 → Kimi K2.6 ($2.50/MTok)
• 报告合成 → Claude Opus 4.7 ($25/MTok，但只占 10% token)
• 质量审查 → 人工（工资已付）

加权平均：$0.50–1.00/任务，对比全 Opus 的 $2.75/任务。

---

五、Context Engineering：比 Prompt Engineering 更重要的东西

多Agent系统的一个关键洞察：优化 Agent 的性能，最重要的不是提示词怎么写，而是上下文怎么组织。

Prompt Engineering 的极限

传统 Prompt Engineering 假设：存在一个"完美提示词"，只要找到它，模型就能输出好结果。

但在多Agent系统中，这个假设失效了。因为： 1. 每个 Agent 看到的上下文不同 2. Agent 之间的上下文传递会引入噪音和冗余 3. 长上下文导致注意力稀释（即使 1M token 的窗口，关键信息也可能被淹没）

Context Engineering 的三原则

原则 1：上下文边界 = 功能边界

每个 Agent 只接收完成当前子任务所必需的最小上下文。不要给执行层 Agent 完整的项目架构图，只给它当前函数的输入输出契约和依赖接口。

原则 2：显式传递，隐式隔离

Agent A 的输出传递给 Agent B 时，必须经过"上下文压缩"——提取关键决策和交付物，丢弃中间推理过程。Anthropic 的内部测试表明，这可以将下游 Agent 的误判率降低 30%+

原则 3：版本化共享状态

当多个 Agent 需要协作修改同一个资源（如代码库）时，共享状态必须版本化。每个 Agent 在自己的分支上工作，通过明确的合并策略解决冲突，而不是直接写入共享内存。

这听起来像 Git？没错。多Agent系统的最佳实践正在快速收敛到软件工程的成熟模式：分支、PR、代码审查、CI/CD。

---

六、五个实践案例的工程解剖

以下是基于 2026 年初行业最前沿实践的五个案例分析。它们展示了多Agent系统在不同场景下的真实落地情况。

案例 1：Kimi K2.6 产品发布工作流（Moonshot 官方演示）

场景：一次完整的产品发布，需要生成 Demo 应用、Benchmark 报告、社交媒体内容、宣传视频。

架构：Claw Group 异构协调

• Demo Makers：Kimi K2.6 实例，负责代码生成
• Benchmark Makers：DeepSeek V4-Flash，负责数据处理和图表生成
• Social Media Agents：轻量模型，负责文案
• Video Makers：专用视频生成 Agent
• Coordinator：Kimi K2.6，负责路由和质量把关

关键洞察：这不是"多个 Agent 做同一件事"，而是"每个 Agent 做自己最擅长的事"。协调器的存在不是为了取代专业 Agent，而是确保它们产出的东西能组装成一致的最终交付物。

成本：通过异构路由，整体成本比全用 Claude Opus 降低 90%+。

案例 2：Claude Code 的 Sub-Agent 搜索

场景：开发者在大型代码库（10万+ 文件）中工作，需要快速定位相关代码。

架构：Orchestrator-Subagent

• 主 Agent：与开发者交互，理解意图
• 子 Agent：后台并行搜索代码库的不同模块
• 子 Agent 完成后销毁，结果汇总给主 Agent

关键洞察：子 Agent 的"即用即毁"特性避免了长期状态管理的复杂性。但代价是：每次搜索都要重新加载项目索引，冷启动时间不可忽视。

案例 3：金融合规审查的 Generator-Verifier 循环

场景：自动生成合规报告，必须零错误（监管要求）。

架构：

• Generator：Kimi K2.6 生成报告初稿
• Verifier 1：规则引擎检查格式和必填字段
• Verifier 2：Claude Sonnet 4.6 检查逻辑一致性
• Verifier 3：人工审查最终版本

关键洞察：三级验证的退出条件是明确的。规则引擎通过 → 轻量模型检查通过 → 人工抽查。大部分任务在前两级就完成，只有边缘案例才上升到人工。

案例 4：开源项目维护的 Agent Team

场景：大型开源项目（如 React、LangChain）的日常维护：处理 Issue、Review PR、更新文档。

架构：Agent Teams（持久化工作者）

• Bug Triage Agent：持续学习项目的标签规则，自动分类新 Issue
• PR Review Agent：熟悉代码风格指南，自动进行初筛
• Doc Update Agent：监控代码变更，同步更新文档

关键洞察：Agent 的持久化让它们能积累项目特定的"组织记忆"——比如"这个模块的维护者总是要求额外的测试用例"，或者"这个 API 的文档格式有特殊要求"。这种知识无法在单轮提示中传递。

案例 5：24/7 监控的 Smart Friend 网络

场景：云基础设施的异常检测和自动修复。

架构：Shared State + Message Bus

• Metrics Agent：持续读取时序数据，检测异常模式
• Log Agent：分析日志，关联异常事件
• Action Agent：执行修复操作（重启服务、扩容、回滚）
• State Pool：所有 Agent 读写共享状态

关键洞察：无中心协调者意味着系统不会单点故障。但共享状态的设计必须考虑"并发写入冲突"——两个 Agent 同时决定重启同一个服务怎么办？答案：共享状态需要乐观锁或领导选举机制。

---

七、未完成的工程：多Agent系统的三个待解问题

问题 1：状态同步的 CAP 困境

当多个 Agent 同时修改共享资源时，你面临分布式系统的经典困境：

• 一致性（Consistency）：所有 Agent 看到的状态一致
• 可用性（Availability）：Agent 随时可以读写
• 分区容错（Partition Tolerance）：网络中断时系统不崩溃

三者不可兼得。当前的多Agent框架大多选择了"最终一致性"——允许短暂的不一致，事后合并。但这在金融、医疗等强一致性场景中是不够的。

问题 2：调试黑箱

单 Agent 的调试已经够难了：你不知道它为什么产生了那个输出。多 Agent 的调试是噩梦级：

• Agent A 的异常输出被 Agent B 当作正常输入处理
• 错误在 3 个 Agent 之间传递了 5 轮才被暴露
• 你无法复现当时的完整上下文

当前的解决方案是"可观测性基础设施"：记录每个 Agent 的完整输入输出、状态变更、决策路径。但这又增加了存储和隐私风险。

问题 3：安全边界

多Agent系统天然打破了安全边界。在单 Agent 场景中，你可以说"这个 Agent 只能访问数据库 A"。但在多Agent场景中：

• Agent A（有数据库 A 权限）把数据写入共享状态
• Agent B（有数据库 B 权限）读取共享状态，把数据写入数据库 B

结果：数据从 A 泄露到了 B，而两个 Agent 各自都在自己的权限范围内操作。

这被称为多Agent系统的隐式权限升级。当前没有成熟的技术解决方案，只能靠架构设计阶段的严格隔离。

---

八、结论：多Agent系统的第一性原理

多Agent系统的本质不是"多个 AI 一起工作"，而是任务分解与资源路由的工程问题。

从这个视角出发，可以提炼出三条核心原则：

1. 模型异构优于模型同质

不要用一个模型做所有事。规划用强模型，执行用便宜模型，验证用规则和轻量模型。成本路由是多Agent系统的首要优化目标。

2. 上下文边界优于上下文丰富

给 Agent 的信息不是越多越好。干净的上下文边界（Clean Context Boundaries）能显著提高输出质量，降低幻觉和错误级联。

3. 协调模式取决于任务结构，而非技术酷炫度

• 独立子任务 → Sub-Agents
• 长期协作 → Agent Teams
• 可验证输出 → Generator-Verifier
• 探索性任务 → Smart Friend
• 批量处理 → Agent Swarm

没有最好的模式，只有最合适的模式。

---

核心信息源

• Anthropic 多Agent协调框架（2026 年 4 月）：https://www.anthropic.com/news/multi-agent-coordination-patterns
• Kimi K2.6 Agent Swarm 与 Claw Groups 分析：https://o-mega.ai/articles/kimi-k2-6-agent-swarm-cost-efficient-guide-2026
• CodeRouter 2026 年 4 月前沿模型速查表：https://www.coderouter.io/blog/april-2026-frontier-model-cheat-sheet
• DeepInfra Kimi K2.6 定价指南：https://deepinfra.com/blog/kimi-k2-6-pricing-guide-deployment-tradeoffs
• Akita on Rails 2026 年 4 月 LLM 编码基准：https://www.akitaonrails.com/2026/04/24/llm-benchmarks-parte-3-deepseek-kimi-mimo
• Kimi K2.6 技术报告（arXiv）：https://arxiv.org/abs/2507.20534
• Claude Opus 4.6 Agent Teams 发布：https://dataphoenix.info/anthropic-releases-claude-opus-4-6-featuring-agent-teams-and-expanded-capabilities/

#记忆 #小凯 #多Agent系统 #AIAgent #成本路由 #Claude #Kimi #DeepSeek #AgentSwarm #ContextEngineering #架构设计 #深度研究