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 发布了 A2AAgent2Agent开放协议紧接着在 6 月把它移交给 Linux 基金会托管。这个动作本身的信号意义很强它不是一个公司的私有标准而是要作为行业公共协议来发展。很多我身边做企业服务的人从那时起开始认真讨论 A2A 的落地价值。4.1 A2A 的定位Agent 世界的 HTTPA2A 解决的核心问题是让不同厂商、不同技术栈的 Agent 之间能够以标准化的方式互相发现、通信和协作。你可以把它类比成 HTTP 之于 Web 服务以前两个系统要对接得写专门的适配代码有了统一协议之后大家按规则通信就能大幅降低集成的成本。A2A 与 MCP 经常被放在一起讨论但两者解决的问题完全不同。MCPModel Context Protocol解决的是“模型如何调用外部工具和数据源”相当于给 Agent 接上了手脚A2A 解决的是“Agent 之间如何对话、如何协作”相当于给 Agent 装上了语言。两者是互补关系不是替代关系。一个典型的企业架构里Agent 内部用 MCP 接工具Agent 之间用 A2A 互相协作。4.2 A2A 的核心概念逐条拆解A2A 规范里最核心的几个概念我用大白话解释一下。Agent CardAgent 卡片这是最有趣的设计。每一个想参与协作的 Agent都需要发布一个描述自身能力的卡片包括它它能做什么、接收什么输入、返回什么输出、调用它的接口地址是什么、认证方式是什么。别的 Agent 通过读取这个卡片就能判断“这个 Agent 适不适合帮我干活”。Message 与 Part消息与内容块两个 Agent 之间的对话被抽象成消息消息里面由 Part 组成Part 可以是纯文本、文件内容、结构化数据等。这个设计让消息不仅仅是“聊了一句天”而是可以承载真正的工作产物。Task 与 Artifact任务与产物这是 A2A 里最有价值的部分。Agent 之间的协作被建模成一个任务Task任务有完整的生命周期状态比如已提交、执行中、需要补充输入、已完成、失败、已取消。任务执行完成后会产生一个或多个 Artifact也就是可交付的成果物。没有 Task 状态机Agent 协作就无法审计、无法对账、无法在企业里做合规治理。SRP 与流式传输A2A 的远程调用基于一个精简的远程过程调用协议底层通信走 HTTP/JSON长耗时的任务可以使用流式传输SSE来实时推送进度。这样发起方不用担心任务超时随时可以知道执行方走到哪一步了。我把这些概念串成一个例子。假设企业里有一个合规审查 Agent需要调用财务 Agent 获取季度报表合规 Agent 通过服务目录发现财务 Agent读取它的 Agent Card确认它可以生成报表合规 Agent 发起一个 Task请求生成 Q3 季度报财务 Agent 返回 Task 已创建进入 working 状态财务 Agent 通过流式传输把处理进度推给合规 Agent最终返回一个 Artifact即报表文件合规 Agent 拿到文件后关闭任务协作结束。整个过程是可追踪的什么时间、谁发起的、执行状态是什么、得到了什么产物全部有迹可循。4.3 企业服务视角A2A 把“能用”变成“可治理”我做企业服务项目踩过的坑告诉我企业客户最在意的往往不是某项技术“能不能用”而是“能不能被管理”。A2A 这套设计里Agent Card 本质上就是服务目录Task 状态机就是对账审计的基础认证机制则保持了对安全合规的约束能力。一个 Agent 网里跑了数千个跨部门任务出了问题你得能定位是哪个 Agent、哪一步、什么参数、谁发起的。没有状态、没有格式、没有认证的“自由协作”在企业环境里是走不通的。5. A2A 企业落地从 Demo 到生产绕不开的几个现实问题协议本身讲得再好落地时也有一堆现实问题要处理。这一部分是我在实际项目里总结出来的每一条都对应过真实的坑。5.1 不用一上来就选协议先看清协作形态很多团队看到 A2A 很兴奋什么场景都想往协议上靠。我的建议是先看清自己到底是哪种协作形态。协作形态典型技术适合场景缺点同构框架内编排CrewAI、LangGraph团队内部、技术栈统一、Agent 数量少与外部系统互通难厂商锁定事件驱动编排消息队列Kafka、RabbitMQ异步流程、高吞吐、系统间解耦没有标准 Agent 语义需要大量自研协议式协作A2A、MCP跨组织、跨厂商、Agent 数量多且异构协议仍在演进部分细节需技术验证人工编排工作流引擎Agent 节点强调人在环上的审批场景自动化程度受限我的经验是内部系统、Agent 数量不超过 5 个、技术栈统一用同构框架是最快的存在跨部门、跨公司、多厂商 Agent 互操作的强需求时A2A 才是值得投入的方向。5.2 服务发现与 Agent Card 治理协议有了你还得解决“Agent 在哪里被找到”。我在一个项目里做过 Agent 注册中心其实就是把团队里所有 Agent 的卡片统一登记包括能力描述、版本号、调用地址、负责人。这样每个新 Agent 接入系统时不需要手工去对接每个老 Agent只要发布自己的卡片服务目录统一分发即可。有一个容易忽略的细节Agent Card 是要做版本管理的。Agent 的能力升级了描述里说“支持生成加密报表”但实际服务还没部署这就会造成调用方拿到一张“过期的简历”。我当时踩过这个坑解决方案是建立了发布审批流程卡片更新必须和代码部署同步。5.3 安全与身份两个 Agent 凭什么互相信任这是企业落地 A2A 最硬的一关。Agent 与 Agent 之间要相互调用必须有身份认证机制。我在企业部署时会根据场景选择不同的方案内部系统用服务账号加 JWT跨企业协作用 OAuth2 授权高安全环境用双向 TLSmTLS。无论选哪种原则都是最小权限一个 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再慢慢把协作的边界向外扩展这条路大概率不会走偏。