AI 多智能体系统落地：从上下文边界到 A2A 与 Harness 设计
AI 多智能体系统落地：从上下文边界到 A2A 与 Harness 设计
文章目录
- AI 多智能体系统落地：从上下文边界到 A2A 与 Harness 设计
- 1. 先别急着拆 Agent：复杂度本身也有成本
- 2. 多智能体真正有用的三类场景
- 2.1 上下文保护：不要让脏信息拖垮主任务
- 2.2 并行探索：收益是覆盖面，不一定是速度
- 2.3 专业化：工具太多时，先收窄工具面
- 3. 拆分边界：按上下文拆，不要按流程阶段拆
- 4. Workflow、Subagent、多智能体，不是一回事
- 5. Harness：把多 Agent 变成可运行的工程系统
- Sprint Contract：先约定“完成”再写代码
- Evaluator 不能只看代码，要真的使用系统
- Harness 的复杂度也要被审计
- 6. A2A 和 MCP：一个管工具，一个管 Agent 之间的协作
- 7. 一个实用决策表：我到底该选什么？
- 8. 常见坑：多 Agent 系统最容易错在这些地方
- 坑 1：用职位分工替代上下文边界
- 坑 2：Evaluator 早胜
- 坑 3：没有可观测性
- 坑 4：把协议当架构，把架构当能力
- 坑 5：不复测复杂度
- 总结：多智能体的第一性原理是“隔离、并行、专业化、验证”
- 参考
做 AI Agent 的人很容易掉进一个误区：一个 Agent 不够强，那就拆成多个 Agent；一个 Agent 会出错，那就加一个评审 Agent；任务复杂，那就 Planner、Coder、Reviewer、Tester 全都安排上。
这听起来合理，但工程上经常适得其反。
多智能体系统不是“把一个脑子切成几份”。它真正解决的是几个更具体的问题：上下文会不会互相污染？任务能不能并行探索？不同角色是否真的需要不同工具、提示词和领域知识？如果这些问题都不存在，多 Agent 只是在增加协调成本、Token 成本和调试难度。
本文把几篇资料和原文揉成一条落地路线：先判断单 Agent 是否足够，再判断是否需要 workflow、subagent、多智能体系统、A2A 协议，最后用 Anthropic 的 Harness 案例看一个真实的“生成-评估”多 Agent 系统应该怎么设计。
1. 先别急着拆 Agent：复杂度本身也有成本
一个可用的单 Agent，通常已经包含这些东西：
- 模型：负责理解、推理和生成。
- 系统提示词：规定角色、边界、输出风格和安全要求。
- 工具：通过 MCP、API、脚本、数据库、浏览器等方式访问外部世界。
- Skills：把领域知识、流程和可复用操作封装起来。
- 记忆或状态：保存长期偏好、阶段性结论、任务进度。
所以，单 Agent 不是“裸模型”。如果任务只是一个领域内的连续工作，先把单 Agent 的提示词、工具选择、Skill、上下文管理做好，往往比立刻上多 Agent 更便宜、更稳。
原文里有两个数字值得记住：
| 来源 | 成本提醒 |
|---|---|
| Anthropic 多智能体博客 | 多 Agent 在等价任务上常见会多用 3 到 10 倍 Token |
| Anthropic Agent 架构白皮书 | 企业架构决策中，多 Agent 可能约为单 Agent 的 10 到 15 倍 Token |
这两个数字不需要机械记死。它们提醒的是同一件事：多 Agent 的主要收益不是“免费变聪明”，而是用更多计算和工程复杂度换取更大的搜索空间、更清洁的上下文、更专业的工具选择。
因此第一原则很简单：
不是“能不能拆”，而是“拆开之后，是否消除了一个真实瓶颈”。
2. 多智能体真正有用的三类场景
2.1 上下文保护：不要让脏信息拖垮主任务
上下文污染是最典型的拆分理由。
比如一个客服 Agent 正在诊断设备故障，期间需要查询订单、物流、历史工单。如果每次查询都把几千个 token 的订单详情塞回主上下文，后面的故障分析就会被大量无关信息干扰。
多智能体的做法是：让一个子 Agent 专门处理“查询和过滤”，它可以吃下完整订单历史，但只把 50 到 100 token 的摘要交给主 Agent。
这里的关键不是“多一个 Agent 很高级”，而是把高噪声上下文关在边界外。
适合拆的信号：
- 子任务会产生大量上下文，尤其是超过 1000 token 的检索结果、日志、文档、列表。
- 主任务只需要其中很少一部分摘要。
- 子任务目标明确，知道应该提取什么、丢弃什么。
2.2 并行探索：收益是覆盖面，不一定是速度
第二类是可并行的研究或搜索任务。
比如“调研一个技术方案”，可以拆成安全风险、性能收益、生态成熟度、竞品实践、迁移成本几个方向。每个子 Agent 独立搜索，最后由主 Agent 汇总。
这类多 Agent 的收益是覆盖面，而不一定是速度。因为整体 Token 和调用次数变多，墙钟时间未必更短；但对于复杂研究，多个独立视角可以覆盖单 Agent 上下文里放不下的信息空间。
适合拆的信号：
- 子问题彼此独立，结果可以最后合并。
- 每个方向都有足够信息量，值得单独探索。
- 你更在意全面性，而不是低成本或低延迟。
2.3 专业化：工具太多时，先收窄工具面
第三类是专业化。
当一个 Agent 同时拥有 CRM、数据库、文件系统、部署、浏览器、邮件、表格、云平台等几十个工具时，它不只是“能力更强”，也更容易选错工具、混淆领域、把相似 API 当成同一个东西。
这时拆分成专业 Agent 有意义：
| 专业化类型 | 例子 | 收益 |
|---|---|---|
| 工具集专业化 | CRM Agent 只拿 CRM 工具，营销 Agent 只拿营销工具 | 降低工具选择错误 |
| 系统提示词专业化 | 客服要耐心，代码审查要挑剔 | 避免角色要求互相冲突 |
| 领域知识专业化 | 法务、医疗、财务、风控 | 避免把大量领域上下文塞给通用 Agent |
但专业化也有代价：你必须有一个可靠的路由器。路由错了，后面的专业能力再强也没用。
3. 拆分边界：按上下文拆，不要按流程阶段拆
很多多 Agent 设计失败，是因为把软件团队的职位分工直接搬进了 Agent 系统：
Planner Agent -> Coder Agent -> Tester Agent -> Reviewer Agent这看起来像工程流程，其实经常变成“电话传话”。Planner 的意图到了 Coder 处被压缩一次，Coder 的实现细节到了 Tester 处又丢一次，Reviewer 再基于不完整上下文给意见，最后大量 Token 花在解释、补充、同步上。
更稳的拆分方式是按上下文边界拆：
| 边界类型 | 适合拆吗 | 原因 |
|---|---|---|
| 独立研究方向 | 适合 | 每个方向上下文天然独立 |
| 有清晰接口的组件 | 适合 | 前后端、模块之间通过契约协作 |
| 黑盒验证 | 适合 | 验证者只需要产物和通过标准 |
| 同一个功能的规划/实现/测试 | 通常不适合 | 它们共享同一段设计和实现上下文 |
| 强耦合模块 | 不适合 | 频繁同步会吞掉收益 |
一句话判断：
如果两个 Agent 需要频繁解释“我为什么这么做”，它们大概率不该拆开。
4. Workflow、Subagent、多智能体，不是一回事
在落地时，先把几个词分清楚。
| 形态 | 核心特点 | 适合场景 |
|---|---|---|
| 单 Agent | 一个上下文里循环观察、决策、调用工具 | 单领域、流程不确定但上下文可承载 |
| Sequential Workflow | 路径预定义，按步骤接力 | 审批、内容管线、数据处理 |
| Parallel Workflow | fan-out / fan-in，多路并行后汇总 | 多维评估、风险检查、研究分面 |
| Evaluator-Optimizer | 生成者产出，评估者反馈，多轮改进 | 代码、文档、设计、翻译 |
| Orchestrator-Subagent | 主 Agent 动态分派子 Agent | 复杂开放任务、上下文隔离、专业化 |
| A2A | 跨系统、跨厂商、远程 Agent 通信协议 | 企业应用之间的 Agent 互操作 |
很多情况下，你需要的是 workflow，不是多 Agent。
比如“草稿 -> 审稿 -> 润色 -> 发布”这种路径明确的任务，用顺序工作流就足够。比如“同时做安全、合规、性能、可用性检查”，用并行工作流也足够。只有当任务会动态转向、需要自主分解、需要在多个独立上下文中探索时，多智能体系统才开始有价值。
5. Harness：把多 Agent 变成可运行的工程系统
Anthropic 的 Harness 案例很有代表性，因为它不是停留在“多个 Agent 协作”的概念层，而是把多 Agent 放进了一个可运行、可评估、可迭代的工程框架。
它的核心不是“让模型聊得更多”，而是把长时间任务拆成可验证的循环：
Planner 生成产品规格 -> Generator 按 Sprint 实现 -> Evaluator 用 Playwright MCP 像用户一样测试 -> 失败则带着具体反馈回到 Generator -> 通过则进入下一轮这个设计解决了两个很实际的问题。
第一，长任务会失控。上下文越来越长之后，模型可能开始保守、提前收尾，或者忘掉前面约定。Harness 用结构化交接文件、Sprint 边界、必要时的上下文重置，把“长任务”变成一段段可接续的短任务。
第二，自我评价不可靠。让同一个 Agent 一边生成一边判断自己的作品，很容易变成“看起来还不错”。Harness 把 Generator 和 Evaluator 分开，Evaluator 只关心是否满足标准、是否有 bug、是否真的能用。
如果你想把这套思路放进日常 Agent 工作流里，我也整理了一个可复用的harness-designSkill：
https://github.com/DE-PARTURE/codex-skills/blob/main/agents/skills/harness-design/SKILL.md
这个 Skill 的重点不是“强行起多个 Agent”，而是先用第一性原理判断任务是否真的需要 Harness：简单任务直接做；复杂但标准不清的任务，先和用户一起定义评估维度；只有当任务确实需要生成-评估循环时，再进入 Generator + Evaluator 的迭代模式。它适合前端页面、技术文档、代码生成、方案设计这类“好不好不能只靠一次生成判断”的任务。
Sprint Contract：先约定“完成”再写代码
Anthropic 的案例里，Generator 和 Evaluator 在每个 Sprint 之前会协商一份 Sprint Contract。它不是需求文档的重复，而是把高层需求翻译成可测试标准：
## Sprint 3 Contract 目标：实现关卡编辑器的矩形填充和实体删除能力。 完成标准： - 用户可以拖拽矩形区域并填充选中的 tile。 - 用户可以选中实体出生点并用 Delete 删除。 - 保存后重新打开，tile 和实体状态保持一致。 - Playwright 测试必须覆盖拖拽、删除、保存、刷新四个路径。 失败条件： - 只在拖拽起点和终点放置 tile。 - UI 显示成功但数据库状态未更新。 - API 返回成功但刷新后状态丢失。这一步非常关键。没有契约，Evaluator 只能凭感觉评估；有了契约，它就能像 QA 一样拿着清单验收。
Evaluator 不能只看代码，要真的使用系统
Harness 案例里 Evaluator 使用 Playwright MCP 点击真实页面，测试 UI、API 和数据库状态。这点比“读代码给建议”更重要。
很多 AI 生成的应用看起来完整，但一用就坏：按钮没连上、状态不保存、接口顺序匹配错误、刷新后丢数据。Evaluator 如果不运行系统，就很难发现这些问题。
Anthropic 的复古游戏制作器实验很直观：单 Agent 版本 20 分钟、约 9 美元，但核心游戏功能损坏；完整 Harness 版本跑了 6 小时、约 200 美元，但产物可用。这个例子不说明 Harness 永远划算，它说明复杂任务里“能跑通”本身可能值得更高成本。
Harness 的复杂度也要被审计
一个好的 Harness 不是越复杂越好。
模型能力变强后，之前必需的组件可能变成负担。Anthropic 在后续实验里也强调：每个 Harness 组件都代表一个假设，即“模型单独做不到这件事”。这个假设要定期复测。
工程上可以这样问：
- Planner 是否真的提升了规格质量，还是只是写了更多字？
- Evaluator 是否发现了人类也认可的问题？
- 每轮 Sprint 是否减少了返工，还是制造了更多交接？
- 上下文重置是否提高稳定性，还是让交接文件变得臃肿？
- 这套 Harness 的成本是否匹配任务价值？
6. A2A 和 MCP：一个管工具，一个管 Agent 之间的协作
A2A 很容易被误解成“多 Agent 框架”。更准确地说，它是一个 Agent-to-Agent 的互操作协议，解决的是不同框架、不同厂商、不同服务器上的 Agent 如何发现能力、交换消息、协作完成任务。
可以把 MCP 和 A2A 分成两层：
| 协议 | 解决的问题 | 典型对象 |
|---|---|---|
| MCP | Agent 如何连接工具、数据和上下文 | 文件、数据库、浏览器、API、内部系统 |
| A2A | Agent 如何和另一个远程 Agent 协作 | Client Agent、Remote Agent、Agent Card、Task、Artifact |
Google 在 2025 年 4 月发布 A2A 时，把它定位为 MCP 的补充：MCP 给 Agent 提供工具和上下文，A2A 让 Agent 之间能够跨平台协作。到 2026 年，A2A 项目已经从最初的 Google 主导，演进到 Linux Foundation 下的社区项目，并在 2026 年 3 月发布了 1.0.0。
A2A 的几个核心概念可以这样理解：
- Agent Card：远程 Agent 的能力名片，告诉别人自己会什么、怎么调用。
- Client Agent / Remote Agent：一个提出任务，一个处理任务。
- Task：协作围绕任务展开，任务有生命周期，可以立即完成，也可以长时间运行。
- Artifact：任务产出的结果。
- Parts：消息中的内容片段，可以是文本、表单、媒体或其他内容类型。
什么时候需要 A2A？
- 你的 Agent 要调用的是另一个团队、另一个供应商、另一个平台上的 Agent。
- 对方不应该暴露内部工具、记忆和提示词，只暴露能力和任务接口。
- 任务可能是长时间运行的，需要状态更新、通知和产物交付。
- 企业环境里需要标准认证、授权和互操作。
什么时候不需要？
- 只是本地程序里拆几个 subagent。
- 所有 Agent 都在同一个进程、同一个代码库、同一个权限边界里。
- 你真正缺的是工具访问能力，这时优先考虑 MCP。
- 你真正缺的是质量反馈闭环，这时优先考虑 Evaluator-Optimizer 或 Harness。
7. 一个实用决策表：我到底该选什么？
| 你遇到的问题 | 优先方案 | 不要一上来就做什么 |
|---|---|---|
| 单领域任务，Agent 偶尔答不好 | 改提示词、补 Skill、收窄工具 | 拆成多个角色 Agent |
| 工具有 20 个以上，经常选错 | Tool Search、工具分组、专业 Agent | 把所有工具继续塞给一个 Agent |
| 检索结果太长，主任务被干扰 | 查询/过滤子 Agent，只回摘要 | 把完整日志、订单、文档都塞回主上下文 |
| 研究任务有多个独立方向 | 并行 subagent，最后汇总 | 让一个 Agent 顺序查完整个世界 |
| 产物需要独立质量保证 | Verification / Evaluator Agent | 让生成者自己宣布通过 |
| 任务流程固定、可审计 | Sequential Workflow | 动态多 Agent 自由发挥 |
| 复杂应用需要长时间实现 | Harness：Planner + Generator + Evaluator + 契约 | 一次性让 Agent “做完整应用” |
| 跨厂商、跨系统 Agent 协作 | A2A | 自定义一套私有通信协议 |
如果只想记一个流程，可以按下面判断：
1. 单 Agent + Skills + MCP 能解决吗？ 能：不要拆。 2. 流程是否固定、可预定义？ 是：用 workflow。 3. 是否只是需要独立验收？ 是：加 verifier / evaluator。 4. 是否存在上下文污染、可并行探索、明确专业化？ 是：考虑 orchestrator-subagent。 5. 是否需要跨系统、跨厂商、远程 Agent 互操作？ 是：考虑 A2A。 6. 是否是长时间、高价值、可测试的复杂产物生成？ 是：考虑 Harness，并先算成本。8. 常见坑：多 Agent 系统最容易错在这些地方
坑 1：用职位分工替代上下文边界
Planner、Coder、Tester、Reviewer 并不天然合理。合理的是边界：谁需要什么上下文，谁可以只看产物和标准。
坑 2：Evaluator 早胜
验证 Agent 最大的问题是跑一两个测试就宣布成功。缓解方式很直接：写清楚必须运行完整测试、必须覆盖边界场景、必须报告失败、必须做负面测试。
坑 3：没有可观测性
多 Agent 出问题时，不看轨迹很难定位：是路由错了、工具错了、摘要丢信息了，还是 Evaluator 标准太松？生产系统至少要记录提示词版本、工具调用、子任务输入输出、Token 成本和最终判断链路。
坑 4：把协议当架构，把架构当能力
A2A 不是让 Agent 变聪明的魔法。MCP 也不是质量保证系统。协议解决连接问题，架构解决协作问题，模型能力决定上限，评估体系决定你能不能知道它是否真的有效。
坑 5：不复测复杂度
多 Agent 和 Harness 组件都应该被定期质疑。模型升级后，也许原来的 Planner 不再必要；上下文能力增强后，也许重置频率可以降低；工具搜索能力增强后，也许不必再拆工具 Agent。
总结：多智能体的第一性原理是“隔离、并行、专业化、验证”
多智能体系统最重要的不是 Agent 数量，而是边界设计。
如果你面对的是上下文污染，就用隔离；如果面对的是大范围搜索，就用并行；如果面对的是工具和领域混乱，就用专业化；如果面对的是质量不可信，就用独立验证；如果面对的是跨组织 Agent 协作，就考虑 A2A；如果面对的是长时间复杂产物生成，就把这些组合成 Harness。
最后仍然要回到那句工程判断：
先做最简单能工作的系统。只有当复杂度解决了真实瓶颈，并且收益能被观察和验证时，再把它加进去。
参考
- Anthropic：When to use multi-agent systems (and when not to)
https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them - Anthropic：Building Effective AI Agents: Architecture Patterns and Implementation Frameworks
https://resources.anthropic.com/hubfs/Building%20Effective%20AI%20Agents-%20Architecture%20Patterns%20and%20Implementation%20Frameworks.pdf - Google Developers Blog：Announcing the Agent2Agent Protocol (A2A)
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ - A2A Project GitHub
https://github.com/a2aproject/A2A - A2A Protocol Website
https://a2aprotocol.ai/ - Google Open Source Blog：A year of open collaboration: Celebrating the anniversary of A2A
https://opensource.googleblog.com/2026/04/a-year-of-open-collaboration-celebrating-the-anniversary-of-a2a.html - Anthropic Engineering：Harness design for long-running application development
https://www.anthropic.com/engineering/harness-design-long-running-apps - DE-PARTURE：harness-design Skill
https://github.com/DE-PARTURE/codex-skills/blob/main/agents/skills/harness-design/SKILL.md