1. 先搞清楚一个根本问题：多 Agent 协作到底在协作什么？

这两年“多 Agent 协作”这个概念热得发烫，从技术社区的 Demo 到企业级的发布会，几乎人手一个 Agent 平台。但我在实际接触大量项目后发现一个尴尬的事实：大部分团队把多个 Agent 放在一起之后，效果并没有变得更好，反而常常出现互相覆盖文件、重复执行任务、责任边界模糊的混乱局面。

问题出在哪？出在我们把“协作”理解得太浅了。

1.1 Agent 不是什么“会聊天的机器人”

很多刚接触 Agent 开发的人，会把 Agent 理解成一个“更智能的 ChatGPT”。这个理解方向是错的，而且错得很要命。Agent 的本质是一个自主执行单元——它有目标、有计划、有行动能力、有对结果的观察和反馈，是一个完整的闭环系统。你可以把它想象成一个入职第一天的实习生：你给他一个任务描述，他自己拆解步骤，自己去查资料、写代码、跑测试，做完之后还回来跟你汇报成果。

这个类比虽然不太严谨，但比“聊天机器人”要准确得多。因为一旦你接受了“Agent = 实习生”的设定，你就会明白一个关键问题：两个实习生放在一起，不等于他们就会好好配合。他们需要明确各自负责什么、信息怎么同步、成果怎么交接、出了问题听谁的。

这就是多 Agent 协作的真正起点。

1.2 协作的本质是分工和交接，不是“聊两句就好”

我见过不少团队做多 Agent 协作，做法是让 Agent A 把结果通过自然语言“交给” Agent B，比如“我把代码写好了，你帮我测试一下”。这种方式在小 Demo 里看着挺像那么回事，一旦进入真实项目就会翻车。因为自然语言本身是模糊的，Agent A 说的“写好了”和 Agent B 理解的“写好了”可能完全不是同一个状态。

真正常态化的 Agent 协作，需要解决的问题是四个：

• 目标一致性：多个 Agent 是否在朝同一个目标努力，还是各说各话；
• 上下文共享：Agent B 需要哪些信息才能接手 Agent A 的成果；
• 能力边界：谁负责代码、谁负责测试、谁负责部署，边界划在哪；
• 信任与授权：Agent A 凭什么可以调用 Agent B 的接口，能调用到什么程度。

这四个要素，其实就是后来所有 Agent 协作协议（包括 A2A）试图标准化处理的东西。理解这一点之后，我们再去看 Codex 的内部机制，就会有一个非常清晰的参照系。

1.3 多 Agent 的两个反面模式，劝你先避开

在深入到具体技术之前，我想先泼两盆冷水。

第一个反面模式是“为了堆 Agent 而堆 Agent”。一个任务单 Agent 就能干完，非要拆成五个 Agent 各干一段，结果光是协调和传递中间状态的时间，就超过了直接干活的成本。Agent 不是免费的，每一个 Agent 背后都是模型调用、上下文消耗和出错概率。每多一个 Agent，系统整体出问题的可能性不是线性增加，而是乘法式增加。

第二个反面模式是“把多 Agent 当万能灵药”。有些团队自己的单 Agent 流程还没跑通，就急着上多 Agent 框架，结果问题的根因根本不是“一个 Agent 不够”，而是模型选择不对、Prompt 没写好、工具链没打通。先跑通单 Agent，再谈多 Agent 协作，这是我反复跟团队强调的一句话。

有了这些前提，我们现在可以去看一个非常典型的单 Agent 参考实现——OpenAI 的 Codex。

2. Codex 内部机制拆解：单 Agent 的完整工作链条为什么可靠

很多人认识 Codex，是因为它在写代码、修改仓库、跑命令这些场景里表现得像“一个会自动干活的全栈工程师”。但它真正值得学习的地方，并不仅仅是模型本身的能力，而是它作为一个 Agent 的内部结构设计。这套设计把一个模糊的“AI 帮我写代码”的愿望，变成了一条可监督、可中断、可恢复的工程链路。

2.1 从任务列表到执行循环：Codex 的核心不是模型，是状态

Codex 目前的形态包括 CLI、网页版云端环境以及 IDE 插件，你给它一个自然语言任务，比如“把项目里的日志模块改成异步写入，并补上对应测试”，它会自己拆解、执行、验证。

它内部的第一步，是把你的任务解析成一份显式的Task List（任务列表）。我在使用 Web 版 Codex 时，侧边栏能看到这个列表，里面一条一条列着待办事项，比如“定位现有日志实现”“设计异步方案”“修改代码”“运行测试”。执行过程中，它会把状态更新为 in progress、completed，如果遇到问题还会回到上一步重新处理。

这个设计的价值怎么强调都不为过。因为任务列表本质上是 Agent 的“显式工作记忆”，它让 AI 不会在长链路操作中忘记自己做到哪一步，也让你作为人类，可以随时介入和纠偏。你可以中途打断它：“停，这里方向不对”，它就能回到任务列表调整后续步骤。

执行循环本身也很经典：读取当前代码状态 → 修改或新建文件 → 在沙盒中运行命令 → 读取输出结果 → 自我检查 → 更新任务列表 → 进入下一步。这个“行动 - 观察 - 反思 - 再行动”的循环，是当前几乎所有编码 Agent 的底层范式，Codex 只是把它做得非常完整。

2.2 沙盒机制与权限分层：自由不是无代价的

Codex 另一个值得拆解的设计，是它的执行沙盒和权限控制。你让它“跑一下测试”，它真的会在环境里执行命令，这就有安全问题：万一它执行了一个危险命令怎么办？

Codex 的做法是两种沙盒。一种是本地沙盒，在本地机器上隔离运行命令，限制文件系统访问范围、限制网络；另一种是云端沙盒，跑在隔离的 Cloud VM 里，适合浏览器操作、大范围网络访问等场景。

同时，CLI 里有不同的权限模式：自动批准（直接应用代码改动并执行命令）、建议模式（只给出建议，由你手动确认）、构建模式（允许跑命令，但不直接改文件）、只读模式（只看不改）。这个权限分层的思路，我认为是 Agent 能进入生产环境的先决条件之一。没有权限分层的 Agent 就是一个没有驾照的人开着你的车，技术再好你也不敢让他上路。

2.3 Plan 模式与人工闸门：靠谱的 Agent 先给方案再动手

新版本的 Codex 引入了一个非常重要的交互变化——Plan 模式。在真正开始修改代码之前，它会先输出一份执行计划，等你确认之后才开始动手。你在界面里可以看到它“准备做什么”“改动哪些文件”“用什么方案”。

我做了一个小项目重构，进行到一半发现原始需求理解有偏差。那次我让它先出计划再执行，它给出的方案里包含“修改 API 返回值结构”这一项，我立刻发现这会影响另一个模块，于是当场拦下，纠正了方案，之后它调整计划后才继续执行。

在企业或者团队里，Agent 直接闷头干到底是非常危险的。“先计划、再确认、后执行”的人工闸门机制，才是多 Agent 协作能够成立的基础。如果单个 Agent 连人类这一关都过不了，它去跟别的 Agent 协作，传递出去的只能是错误。

2.4 Codex 的边界：模型兼容层带来的工程复杂性

很多团队用 Codex 时并不直接用 OpenAI 默认模型，而是希望通过配置切换不同的模型供应商，比如接入成本更低的第三方模型（例如 DeepSeek 这类开源模型）。这个方向本身没问题，但实际做起来比想象中复杂。

社区里常见的做法是通过配置 Provider 网关来切换模型接口。我在尝试这个方向时碰到过不少报错，比如“当前模型不受 Codex 支持，无法用于 Responses 接口”之类的提示。这类问题通常不是模型本身不可用，而是模型与 Agent 框架之间的接口协议、参数格式、工具调用能力不匹配。

这给我一个很深的教训：Agent 框架的能力上限，是由它依赖的模型能力决定的。你可以在工程层面把流程、状态、权限都做得很好，但最终给结果的是模型本身。Codex 之所以强，模型能力占了大头；如果你给一个自身工具调用能力很弱的模型套上 Agent 框架，它照样干不了活。

3. Codex 的边界：为什么单 Agent 完不成的任务，必须交给多 Agent

说完了 Codex 值得学习的地方，也得诚实地谈它的局限。Codex 再强，本质上仍然是单 Agent 架构。把它逼到极限之后，你会撞上几堵真实的墙。

3.1 上下文窗口的物理极限

第一堵墙是上下文窗口。任何一个模型，一次能“记住”的内容都是有限的。一个真实企业项目的代码库可能是几十万行，再加上文档、issue、操作记录，单一 Agent 的上下文根本装不下。

我做过的长任务实测里，Codex 在持续运行十几分钟后，偶尔会出现前后不一致的情况，比如已经改过的代码位置，后续步骤又对它做了一次重复修改。这就是长上下文衰减的典型表现。人工作久了会累，模型的注意力在这种长链路中同样会稀释。

3.2 权限隔离与职责分离

第二堵墙是权限。如果所有任务都由同一个 Agent 处理，意味着这个 Agent 需要同时拥有代码库的写权限、测试环境的执行权限、以及生产环境的操作权限。这在安全上是一个大忌。

多 Agent 架构天然适合做职责分离：代码 Agent 只读代码仓库，测试 Agent 只在沙盒里执行，运维 Agent 才能碰部署环境。这样即使某个 Agent 被提示词注入攻击，它的破坏半径也被限制在最小范围。这就是我在第一章里强调的“能力边界”，单 Agent 做不了这种隔离，因为它什么都能干。

3.3 并行与专精：人海战术的价值

第三堵墙是并行度。单 Agent 是串行工作的，再做多少任务，也是一条流水线。但企业场景中，经常需要同时处理多个独立模块的修改和验证，串行的代价是时间成本成倍增加。

更重要的其实是“专精”。一个 Agent 如果要同时精通前后端代码、数据库调优、DevOps 脚本、业务逻辑，那它的 Prompt 和工具配置必然臃肿。而多个 Agent 各带一套精简的 Prompt、工具集和上下文，反而能在各自领域做深做透。

所以我们在看 A2A 的时候要知道，A2A 设计的初衷，恰恰是为了承接这种“单 Agent 做不了、同构框架做不广”的分布式智能体协作需求。

4. A2A 协议：把“Agent 互相聊天”变成一门可治理的工程

2025 年 4 月，Google 发布了 A2A（Agent2Agent）开放协议，紧接着在 6 月把它移交给 Linux 基金会托管。这个动作本身的信号意义很强：它不是一个公司的私有标准，而是要作为行业公共协议来发展。很多我身边做企业服务的人，从那时起开始认真讨论 A2A 的落地价值。

4.1 A2A 的定位：Agent 世界的 HTTP

A2A 解决的核心问题，是让不同厂商、不同技术栈的 Agent 之间，能够以标准化的方式互相发现、通信和协作。你可以把它类比成 HTTP 之于 Web 服务：以前两个系统要对接，得写专门的适配代码；有了统一协议之后，大家按规则通信，就能大幅降低集成的成本。

A2A 与 MCP 经常被放在一起讨论，但两者解决的问题完全不同。MCP（Model Context Protocol）解决的是“模型如何调用外部工具和数据源”，相当于给 Agent 接上了手脚；A2A 解决的是“Agent 之间如何对话、如何协作”，相当于给 Agent 装上了语言。两者是互补关系，不是替代关系。一个典型的企业架构里，Agent 内部用 MCP 接工具，Agent 之间用 A2A 互相协作。

4.2 A2A 的核心概念逐条拆解

A2A 规范里最核心的几个概念，我用大白话解释一下。

Agent Card（Agent 卡片）：这是最有趣的设计。每一个想参与协作的 Agent，都需要发布一个描述自身能力的卡片，包括它它能做什么、接收什么输入、返回什么输出、调用它的接口地址是什么、认证方式是什么。别的 Agent 通过读取这个卡片，就能判断“这个 Agent 适不适合帮我干活”。

Message 与 Part（消息与内容块）：两个 Agent 之间的对话被抽象成消息，消息里面由 Part 组成，Part 可以是纯文本、文件内容、结构化数据等。这个设计让消息不仅仅是“聊了一句天”，而是可以承载真正的工作产物。

Task 与 Artifact（任务与产物）：这是 A2A 里最有价值的部分。Agent 之间的协作被建模成一个任务（Task），任务有完整的生命周期状态，比如已提交、执行中、需要补充输入、已完成、失败、已取消。任务执行完成后，会产生一个或多个 Artifact，也就是可交付的成果物。没有 Task 状态机，Agent 协作就无法审计、无法对账、无法在企业里做合规治理。

SRP 与流式传输：A2A 的远程调用基于一个精简的远程过程调用协议，底层通信走 HTTP/JSON，长耗时的任务可以使用流式传输（SSE）来实时推送进度。这样发起方不用担心任务超时，随时可以知道执行方走到哪一步了。

我把这些概念串成一个例子。假设企业里有一个合规审查 Agent，需要调用财务 Agent 获取季度报表：

1. 合规 Agent 通过服务目录发现财务 Agent，读取它的 Agent Card，确认它可以生成报表；
2. 合规 Agent 发起一个 Task，请求生成 Q3 季度报；
3. 财务 Agent 返回 Task 已创建，进入 working 状态；
4. 财务 Agent 通过流式传输，把处理进度推给合规 Agent；
5. 最终返回一个 Artifact，即报表文件；
6. 合规 Agent 拿到文件后关闭任务，协作结束。

整个过程是可追踪的：什么时间、谁发起的、执行状态是什么、得到了什么产物，全部有迹可循。

4.3 企业服务视角：A2A 把“能用”变成“可治理”

我做企业服务项目踩过的坑告诉我，企业客户最在意的往往不是某项技术“能不能用”，而是“能不能被管理”。A2A 这套设计里，Agent Card 本质上就是服务目录，Task 状态机就是对账审计的基础，认证机制则保持了对安全合规的约束能力。

一个 Agent 网里跑了数千个跨部门任务，出了问题，你得能定位是哪个 Agent、哪一步、什么参数、谁发起的。没有状态、没有格式、没有认证的“自由协作”在企业环境里是走不通的。

5. A2A 企业落地：从 Demo 到生产，绕不开的几个现实问题

协议本身讲得再好，落地时也有一堆现实问题要处理。这一部分是我在实际项目里总结出来的，每一条都对应过真实的坑。

5.1 不用一上来就选协议：先看清协作形态

很多团队看到 A2A 很兴奋，什么场景都想往协议上靠。我的建议是，先看清自己到底是哪种协作形态。

我的经验是：内部系统、Agent 数量不超过 5 个、技术栈统一，用同构框架是最快的；存在跨部门、跨公司、多厂商 Agent 互操作的强需求时，A2A 才是值得投入的方向。

5.2 服务发现与 Agent Card 治理

协议有了，你还得解决“Agent 在哪里被找到”。我在一个项目里做过 Agent 注册中心，其实就是把团队里所有 Agent 的卡片统一登记，包括能力描述、版本号、调用地址、负责人。这样每个新 Agent 接入系统时，不需要手工去对接每个老 Agent，只要发布自己的卡片，服务目录统一分发即可。

有一个容易忽略的细节：Agent Card 是要做版本管理的。Agent 的能力升级了，描述里说“支持生成加密报表”，但实际服务还没部署，这就会造成调用方拿到一张“过期的简历”。我当时踩过这个坑，解决方案是建立了发布审批流程：卡片更新必须和代码部署同步。

5.3 安全与身份：两个 Agent 凭什么互相信任？

这是企业落地 A2A 最硬的一关。Agent 与 Agent 之间要相互调用，必须有身份认证机制。我在企业部署时，会根据场景选择不同的方案：内部系统用服务账号加 JWT，跨企业协作用 OAuth2 授权，高安全环境用双向 TLS（mTLS）。无论选哪种，原则都是最小权限：一个 Agent 只能调用它任务所需的接口，不能因为“都是内部系统”就放开所有权限。

这里还要提一个很多人忽略的安全问题：多 Agent 协作会放大记忆威胁面。单一 Agent 的记忆被污染，影响的是一个 Agent；多个 Agent 共享上下文和中间产物，污染的扩散路径就会成倍增加。现在已经有研究团队在做针对 Agent 记忆的主动防御框架（比如 a-memguard 这类方向），核心思路是对 Agent 的长期记忆进行写入前检测和读取时隔离。这在多 Agent 架构里尤其值得关注。

5.4 可观测性与成本控制

我在交付企业 Agent 平台时，被问得最多的不是“智能不智能”，而是“我问什么能知道这个任务到底干了什么、花了多少钱”。所以多 Agent 平台一定要有能力记录：

• 每个 Agent 的输入摘要和输出摘要；
• 每次调用的模型、token 消耗和时间戳；
• 每个 Task 的状态流转历史；
• 失败重试的原因和次数。

没有这套东西，多 Agent 系统就是一个黑盒。任何一个企业客户都不会接受一个“只给结果、不给过程”的自动化系统，尤其在涉及资金、合规、客户数据等敏感场景时。

5.5 务实建议：从单 Agent 质量开始，逐步上协作层

最后给一个我自己验证过的落地顺序，一共三步。

第一步，先把单个 Agent 的质量做扎实。KPI 只有一个：单 Agent 在目标场景里的成功率。成功率低过七八成，先不要考虑协作。

第二步，做团队级别的 Agent 边界划分。明确每个 Agent 的职责、输入输出格式、交接协议，即使没有用 A2A，也要先约好内部接口。

第三步，当出现跨部门、跨系统、外部协作需求时，再引入 A2A 协议，配合注册中心、身份认证和可观测性平台一起建设。

这个顺序我跟三个不同体量的团队分享过，凡是按这个顺序走的，基本都平稳落地；凡是跳过第一步直接上多 Agent 的，后面几乎都在返工。

6. 回到标题：多 Agent 协作到底靠什么？

把前面的内容收拢一下，我对“多 Agent 协作靠什么”这个问题的回答其实很朴素：靠单 Agent 的质量、Agent 间的标准协议、以及治理机制，三者缺一不可。

Codex 教会我们的是单 Agent 的质量从哪来——显式任务列表、行动观察循环、沙盒权限隔离、人工闸门节点。这些机制保证了单个 Agent 的行为是可预测、可监督、可修正的。而 A2A 顺着往前走，把 Agent 之间的发现、通信、任务状态、成果交接变成了可治理的标准流程。底层做好了，上层才能立得住。

我自己的工作习惯是，看一个多 Agent 方案好不好，只问三个问题：单个 Agent 有能力独立完成任务吗？Agent 之间交接的格式和状态是清晰、可追踪的吗？系统里每一笔跨 Agent 调用都有身份和审计记录吗？这三个问题如果都能给出肯定答案，这个协作架构基本差不了。

关于“多 Agent”这个词，我还有一个额外的体会想分享。很多人以为多 Agent 是“多个聪明的模型在一起工作”，但实际跑起来你会发现，模型只是效率工具，真正让多个执行单元有序协同的，是流程设计、协议规范和工程治理。不要把想象力用在如何让 Agent 更智能上，而要把工程能力用在让 Agent 更可靠、更可控上。先跑通一个靠谱的单 Agent，再慢慢把协作的边界向外扩展，这条路大概率不会走偏。