做 Agent 开发这两年我越来越确认一个判断单 Agent 是工程问题多 Agent 是协议问题。从 OpenAI 的 Codex 把 Agent 循环做到产品级到 Google 牵头把 A2AAgent2Agent协议推进 Linux 基金会再到各种 agent 框架、编排平台层出不穷大家都在回答同一个问题——几个 Agent 凑在一起凭什么能把活干完而不是互相添乱这篇文章不打算跟你聊“Agent 的未来有多宏大”那没意思。我想把底层拆开看Codex 内部那套“计划—执行—观察—修正”的机制到底怎么转A2A 协议为企业级多 Agent 协作解决了哪些单机模式解决不了的问题以及从单 Agent 迁到多 Agent 落地时哪些坑你一定会踩。适合正在做 Agent 开发、或者想把 Agent 协作体系引到业务里的人看。不要求你有多深的技术背景但如果你写过几行代码读起来会更过瘾。1. 先聊清楚Agent 凭什么“自己干活”1.1 Agent 不是聊天机器人核心是“闭环”严格点的说法是Agent 是一个能感知环境、做决策、采取行动、再根据行动结果修正下一步动作的软件系统。大白话讲它不是那种“你问一句、它答一句”的聊天框而是一个拿到任务后自己拆解、自己想办法、自己动手干、干完还会自己检查的“数字员工”。这里面最值钱的一个词是“闭环”。你可以回想一下普通大模型应用的差距给 ChatGPT 发一句“写个爬虫”它给你一段代码任务就算交代完了剩下的装依赖、跑起来、修 bug 全是你的活。但一个 Agent 拿到同样的指令会先判断需求有没有歧义然后列出执行计划打开终端装依赖写代码跑一遍看到报错再改再跑直到交出一份可用的结果。这套“计划—执行—观察—修正”的循环才是 Agent 和普通大模型应用的分水岭。我见过太多人做 Agent 的第一个版本就是把模型 API 包一层壳然后跟老板说“我们上 Agent 了”。实际上那只是带温度参数的聊天机器人。判断一个系统是不是真 Agent就看两件事第一有没有工具调用能力能不能真的去操作外部系统第二有没有根据执行结果自动调整下一步的循环逻辑。两条缺一条都只能算“装了插件的聊天机器人”离 Agent 还差着十万八千里。这个闭环听起来简单真落地全是细节。模型选型、工具怎么定义、上下文怎么裁剪、错误重试策略、沙盒安全边界每一环都能把你的精力耗干净。这也是为什么 Codex 这类产品一亮相就让开发者兴奋它把整个 Agent 闭环做到产品级你看到的不是一个“会写代码的大模型”而是一个会开终端、会改文件、会查资料、会自己验证结果的完整工作流。1.2 为什么单 Agent 会撞墙——多 Agent 出现的真正原因既然一个 Agent 已经能干活了为什么还要折腾“多 Agent”这种听起来就不太可控的事答案很简单真实业务场景的复杂度远超单个 Agent 能承载的范围。举个最典型的例子企业内部智能客服。单 Agent 方案长这样——一个 Agent 接收用户问题理解意图然后查订单、查库存、走退货流程、发通知全包了。听起来很全能对吧跑起来你很快就会撞上三堵墙。第一堵墙是上下文爆炸。Agent 的上下文窗口是有限的你要让它同时掌握客服话术、订单查询接口、库存规则、退货流程、用户历史记录还没开始回答窗口已经满了一半。第二堵墙是职责冲突。退货规则和营销推荐是两个完全不同的知识域硬塞进同一个提示词模型很容易“精神分裂”——上一句还在严肃讲退货政策下一句就开始热情推荐新品。第三堵墙是故障扩散。所有环节都压在一个 Agent 上它一挂整个客服系统全瘫。多 Agent 的思路就是拆一个 Agent 负责接待和意图识别一个负责查订单一个负责走退货流程一个负责对外发通知。每个 Agent 只维护自己那一小块知识域和工具集合互相之间通过标准接口通信。拆完之后上下文压力小了职责清晰了单个 Agent 挂了只影响一个环节其他部分还能继续跑。但拆完不等于万事大吉。多 Agent 真正的难题恰恰全压在这两个字上“协作”。几个 Agent 之间怎么互相找到对方怎么传达任务怎么确认任务做完了A 告诉 B 一个结果B 怎么判断该不该信这些问题在单 Agent 时代根本不存在一进多 Agent 就变成绕不过去的核心命题——而且你会发现“让它们用自然语言随便聊”这个最直觉的方案恰恰是最不靠谱的。这个坑我后面专门讲。2. Codex 内部机制一个能写代码的 Agent 是怎么转起来的2.1 Codex 的本质不是“补全代码”是“执行任务”Codex 是 OpenAI 推出的编程 Agent主打终端使用。很多人第一次用时会产生一个误解这不就是个代码补全工具吗跟 Copilot 差不多吧。真不是。Copilot 的定位是“在你写代码时给建议”核心动作是补全ChatGPT 网页版的定位是“帮你生成代码片段”核心动作是产出文本Codex 的定位是“帮你把整个任务干完”核心动作是执行。这三者差一个量级。Codex 拿到需求后会在一个受控的沙盒环境里自己开终端、自己读写文件、自己跑测试跑挂了就自己看日志修修完再跑直到完成任务或者明确告诉你“做不了”。它本质上是一个“长在终端里的数字程序员”模型只是它的大脑工具链路才是它的手脚。从技术实现上说它走的是 Responses API也就是/responses这个端点。你可能在报错里见过类似codex endpoint /responses的字样那就是它在请求模型接口时留下的痕迹。整个交互不是一次“问答”而是多轮“动作—反馈”的循环模型给出下一步动作CLI 负责执行执行结果再喂回给模型。这里我想强调一个容易被忽略的点Codex 的“任务执行”本质上是一个有状态的过程。它不像普通 API 调用那样“请求一次、返回一次”就完事而是像一个人坐在工位前连续工作好几个小时。理解了这一点你就明白为什么 Agent 系统的并发、上下文、状态管理会这么难——这已经不是“接口设计”的范畴而是“运行时设计”的范畴了。2.2 Agent 循环请求、计划、工具调用、观察、迭代Codex 的核心运行机制学术上有个名字叫 ReAct也就是 Reason推理加 Act行动的循环。翻译成人话就是模型先想一想“现在该干什么”然后决定“调用哪个工具干什么事”工具执行完模型看到结果再想“接下来干什么”如此反复。具体拆开看一轮典型的 Codex 会话长这样用户输入自然语言任务比如“帮我把这个仓库里所有 TODO 注释整理成一份报告”。模型先做计划可能是“先用 grep 找到所有 TODO再逐个看上下文最后生成报告”。模型发起第一次工具调用比如执行grep -rn TODO src/。CLI 在沙盒中执行这条命令把输出结果返回给模型。模型看到输出判断“信息够了开始写报告”然后发起文件写入操作。CLI 执行写入生成报告文件。模型再做一次检查确认文件内容符合要求会话结束。这个循环的每一步都是“生成动作—执行动作—观察结果”的微循环。我实际用下来的感受是Codex 最厉害的地方不是它一次能写出多长的代码而是它很擅长“边干边调整”。你丢给它一个没说清楚的需求它会先探索环境、收集信息再动手。这种“先侦察再干活”的习惯是 Agent 能不能处理真实任务的分水岭。很多普通模型接入工具链后表现很差核心原因就是只有“一次生成”没有“观察—再生成”这个迭代回路。这个机制带来的工程启示是做 Agent 开发第一步不是优化提示词而是先把“工具调用结果如何反馈给模型”这条链路打通并且把工具的输出格式整理干净。工具输出一团糟模型再聪明也白搭。2.3 沙盒与执行环境为什么代码必须“跑起来”才算数Codex 默认不会直接在你的电脑上为所欲为。它把命令执行放在一个隔离的沙盒环境里模型对文件系统的修改会以“变更集”的形式呈现由你审阅后再决定要不要合入本地工作区。你如果看到终端提示“更新 agent 沙盒”别慌那基本就是环境在同步状态、刷新某个变更属于正常行为。为什么要这么设计道理很朴素模型有可能执行危险命令比如rm -rf跑错目录、下载来源不明的依赖、或者修改不该动的配置。如果不加沙盒一次误操作就能把本地环境搅得天翻地覆。有了沙盒模型可以放手去试错风险被控制在隔离区内最终合不合并由人说了算。从架构上说沙盒不是虚拟机更像“受限执行环境加文件差异跟踪”。它的价值有两条一是安全隔离二是可审计。每一次命令执行、每一个文件改动都有记录你随时可以回看“这个 Agent 刚才到底干了什么”。这一条对企业落地尤其重要——如果 Agent 的行为完全不可审计那它再能干也没人敢在生产环境里放它出来。所以这里给做 Agent 系统的人一个建议无论你用不用 Codex你的工具执行层一定要有沙盒意识。不需要一上来就搞全套容器隔离但至少要做到“工具执行结果可回滚、可记录、可审核”。没有这层兜底Agent 的能力越强你的风险越大。2.4 上下文管理Agent 的“记忆力”到底怎么存Agent 的记忆问题是很多人忽略但逃不掉的一关。很多人以为“记忆力”就是把聊天记录全塞进上下文窗口实际根本不是那回事。Codex 处理长任务时有一套相当务实的策略它不会把整个仓库的全部文件都读进上下文而是“按需读取”——先用 grep 定位相关代码再读片段。文件内容也不是一字不差全塞进去而是提取关键信息。做长任务时早期对话会被压缩成摘要只保留跟当前步骤相关的残留信息。你看这些机制本质上都是在对抗同一个物理限制上下文窗口是有限的而真实任务的信息量是无限的。我自己在做一个类似机制时最深刻的体会是上下文管理的好坏直接决定 Agent 能不能做“超过单次对话长度”的任务。如果所有工具输出都原样塞进上下文三轮之后模型就开始“失忆”——它记不得最开始的任务目标是什么。所以做 Agent 开发至少要规划三件事对话历史的摘要策略、工具输出的大幅裁剪、以及任务关键信息的持久化存储。这三点做好你的 Agent 才算有“长期记忆”的雏形。顺带提一句记忆不仅是性能问题还是安全问题。业界已经出现针对“Agent 记忆投毒”的攻击研究思路是往 Agent 依赖的外部记忆里注入恶意内容诱导它在后续任务中按攻击者意图行事。我记得有一个叫 a-memguard 的研究方向就是专门做“面向大模型 Agent 记忆的前置防御框架”的。多 Agent 场景下记忆共享面更大这个风险只会更严重后面讲安全时我再细说。3. 从单 Agent 到多 Agent协作到底靠什么3.1 多 Agent 的三种协作模式多 Agent 系统里“怎么组织”是第一个要回答的问题。虽然实现花样百出但抽象到最后就三种模式编排者-执行者、对等协作、流水线接力。编排者-执行者Orchestrator-Worker是最好理解也最常用的模式一个“老大”Agent 负责把大任务拆成子任务分发给一组“小弟”Agent 执行小弟把结果交回来老大再汇总、再判断、再分发。好处是控制集中、逻辑清晰、出了问题容易定位坏处是老大容易成为瓶颈而且它自己要承载大量的上下文和调度压力。企业里很多客服机器人团队就是这么组织的一个主管分配多个专员干活。对等协作Peer-to-Peer则是让 Agent 之间可以自由互相发消息、互相请求。灵活度高适合几个能力相当的 Agent 需要协商的场景比如一个写方案、一个做评审来回讨论。但它的问题也很明显没有中心节点协调成本高消息满天飞的时候很容易出现“两个 Agent 互相踢皮球”的死循环。流水线接力Pipeline则是把任务切成固定顺序的环节A 做完交给 BB 做完交给 C像工厂流水线。职责单一、吞吐高但整条链路上任何一个环节挂掉整条线就卡住所以每个环节都要有重试和容错。选型上我的经验是能力强弱不均、需要统一调度的场景用编排模式几个 Agent 水平相当且需要互相讨论的用对等模式任务流程天然分阶段固定的用流水线。开头别想着把三种模式都做了先选一种跑通后面再演进。3.2 分工不是靠“聊天”是靠“协议”现在到了我最想说的话题。网上很多多 Agent 的炫酷演示都是两个 Agent 用自然语言你来我往地“聊天”一个说“你能帮我做一下数据清洗吗”另一个回“好呀我这就去”。第一次看确实很震撼但你要把这套东西放进企业生产环境会发现它是灾难。为什么因为自然语言的信息熵太高了。A 说“帮我处理一下数据”B 大概率理解出五个版本的结果。而且自然语言没有契约性——没有明确的字段、没有错误码、没有重试依据。A 发给 B 一个任务B 干到一半挂了A 怎么知道该不该重发B 给 A 的回复里哪一段是结论、哪一段是闲聊审计的时候你怎么跟合规部门解释“系统自己跟系统聊天聊出了这个结果”所以真实的多 Agent 协作分工不是靠聊天而是靠协议。说得直白点Agent 之间交换的每一句话都应该是结构化消息包含任务 ID、动作类型、参数、期望输出格式、回调地址。就像 REST API 是程序之间通信的规范一样Agent 之间也需要这样一套“通信规范”。这个认知是理解 A2A 的前提。你可能还听说过 MCPModel Context Protocol它解决的是“Agent 怎么调用外部工具和数据源”而 A2A 解决的是“Agent 怎么和其他 Agent 通信”。两者不是竞争关系而是互补关系。打个比方MCP 是给 Agent 装上 USB 接口让它能插外部设备A2A 是给 Agent 装上网络协议让它能和其他计算机互发消息。一个管“接入”一个管“连接”。3.3 进度同步与任务状态机企业场景最容易被忽略的环节多 Agent 协作里最容易被初学者忽略、但企业落地时一定会被反复拷问的问题就是“任务现在到底进行到哪一步了”。你以为是一句废话实际上这条信息在多 Agent 系统里极其容易失控。设想一个退款场景用户找客服 Agent A 申请退款A 把退款请求发给负责执行退款流程的 Agent BB 去调支付系统接口。如果 B 在处理过程中超时了A 不知道A 重发了一次请求结果 B 其实已经退成功了一笔于是用户收到了两笔退款。这种事故不是纸上谈兵是多 Agent 生产环境里最常见的“重复执行”事故。所以多 Agent 系统必须有一个明确的任务状态机。A2A 里定义的那套状态就很典型任务提交submitted、执行中working、需要补充输入input-required、完成completed、失败failed、取消canceled。所有 Agent 对状态的认知必须一致状态变更要通过结构化消息同步。在此基础上还要做两件事幂等性和超时。幂等性保证“同一个任务被重复送达时不会重复执行”超时保证“对方没响应时系统知道该怎么办而不是无限等下去”。很多团队做多 Agent 时先选框架、先调模型却忘了先画一张状态机图最后上线全是状态对不上的问题。我强烈建议任何多 Agent 项目的第一张设计图应该是任务状态流转图而不是架构拓扑图。4. A2A企业级 Agent 协作协议是怎么设计的4.1 A2A 解决了什么问题A2A 全称 Agent2Agent是 2025 年上半年由 Google 提出、随后捐给 Linux 基金会维护的开放协议。它出现的核心动机就一句话Agent 越来越多但每个 Agent 都是“信息孤岛”彼此之间没有通用的交流方式。你可以这样理解HTTP 协议让任何两台服务器能互相通信A2A 想让任何两个 Agent 也能互相通信。有了它公司 A 的客服 Agent 可以直接把任务发给公司 B 的物流 Agent而不需要互相提前定制接口。套用前面那个比喻——如果说 Agent 是一个个“数字员工”那 A2A 想做的就是给这些数字员工发一本通用的“职场沟通手册”规定好怎么自我介绍、怎么接活、怎么汇报进度、怎么交接成果。对于企业来说这套标准化的价值在于你不再被某一家厂商的 Agent 生态绑死。你今天用 A 厂商的 Agent 做客服明天想换成 B 厂商的 Agent只要双方都支持 A2A替换成本就大幅降低。这其实和当年浏览器都支持 HTTP、服务器都支持 TCP/IP 是同一个逻辑——标准化是生态繁荣的前提。A2A 和 MCP 的关系也需要理清。MCP 管的是“Agent 和工具/数据之间的连接”A2A 管的是“Agent 和 Agent 之间的连接”。一个 Agent 可以同时使用 MCP 去访问数据库又通过 A2A 去请求另一个 Agent 的协助。它们是解决不同层次问题的互补协议不是二选一的关系。4.2 Agent Card怎么告诉别人“我能干什么”A2A 协议里有一个特别精巧的设计叫 Agent CardAgent 卡片。你可以把它理解成每个 Agent 对外发布的“电子简历”或“能力清单”。它通常是一个 JSON 文件放在一个固定的公开地址上惯例是/.well-known/agent.json里面写清楚这个 Agent 是谁、提供哪些能力、每个能力需要什么输入、会产生什么输出、通过哪个端点访问、需要什么样的认证。一个简化后的 Agent Card 大概是这种感觉{ name: order-agent, description: 处理订单查询与状态更新, skills: [ { id: order_query, name: 订单查询, description: 根据订单ID返回订单状态与物流信息 }, { id: order_update, name: 订单更新, description: 更新订单备注或预约时间 } ], endpoints: [ https://api.example.com/agent/order ], security: { auth_type: oauth2, scopes: [orders:read, orders:write] } }这个设计解决的是多 Agent 协作里的“可发现性”问题。在没有任何目录服务的前提下别的 Agent 怎么知道你存在、你能干什么、怎么调用你Agent Card 就是答案。它把“发现能力”和“描述能力”标准化了任何一个 Agent 只要拿到另一个 Agent 的卡片就能判断“它能不能帮我干这个活以及我该怎么叫它干活”。我尤其喜欢它把“能力”显性化这个做法。企业里评估一个外部系统能不能接入最烦的就是对方文档不全。Agent Card 相当于强制每个 Agent 输出一份机器可读的能力说明书这对集成效率的提升是实打实的。4.3 任务生命周期从提交到完成的状态流转A2A 最核心的抽象是 Task任务。两个 Agent 之间的所有协作最终都落到“一个 Agent 向另一个 Agent 发起一个任务直到任务终结”这条主线上。而任务的核心就是前面提到的状态机。任务提交后进入 submitted 状态接收方开始处理则变为 working。如果处理过程中发现信息不够比如退款需要用户确认身份任务会进入 input-required 状态其实就是卡住等人补材料。材料补齐后回到 working。最终要么 completed成功产出结果要么 failed失败要么 canceled被取消。这套状态机的妙处在于它让“异步长任务”变得可以被管理。Agent 之间协作往往不是秒回一个任务可能跑几分钟甚至几小时。如果没有状态机发起方只能干等有了状态机发起方可以随时查询任务状态接收方也可以通过流式更新A2A 支持基于 SSE 的流式推送主动汇报进度。对企业业务来说input-required 这个状态尤其重要。因为真实业务流程里“等人工确认”是常态。A2A 没有回避这一点而是把它设计成了第一等公民——任务可以在人和 Agent 之间来回交接这比那种“Agent 一跑到底、绝不回头”的理想化设计接地气多了。4.4 消息、流与工件协作中的“语言”说完任务状态再说说 A2A 里“消息”长什么样。A2A 的消息基于 JSON-RPC 风格设计所有通信都是结构化的包含消息 ID、任务 ID、消息类型、发布时间这些基础字段。这种设计的好处是机器可解析、可追踪、可审计。除了消息本身A2A 还有一个概念叫 Artifact工件指的是任务执行过程中产生或更新的“成果物”。比如一个数据分析 Agent 处理完任务后生成了一份报告文件这份文件就可以作为一个 Artifact 返回给发起方。Artifact 和状态更新是分开推送的——发起方既能知道“任务到哪一步了”又能拿到“实际产出了什么”。基于流的事件推送则让 A2A 特别适合长任务场景。比如一个 Agent 让另一个 Agent 生成一份季度经营分析报告后者生成到一半前者已经能收到“正在汇总财务数据”“正在生成图表”这些中间事件而不是干等着最终结果。这种“可观测的异步协作”是企业级系统非常看重的能力——因为你看得到进展就知道系统没死、没卡、没在瞎跑。4.5 安全与身份多 Agent 协作的底线多 Agent 协作的最后一个支柱是安全。企业里两个 Agent 通信绝不能像两个人在路边悄悄递纸条一样没有凭据。A2A 在设计上把安全放得很重Agent 之间的访问需要通过身份认证常见方式包括 OAuth 2.0、API Key以及更严格的客户端证书mTLS。每个 Agent 暴露能力时要声明所需权限范围比如“只读订单”和“可改订单”是不同级别的授权。这里我说个容易被忽略的点多 Agent 场景下的安全风险不只是“被外部攻击”还有“内部 Agent 被攻破后互相传染”。如果一个 Agent 被恶意提示词劫持它可能会向协作伙伴发送精心构造的恶意请求。更阴险的是共享记忆投毒——如果多个 Agent 共享同一个记忆存储攻击者攻破一个 Agent 后往共享记忆里注入误导信息其他 Agent 后续决策都会受影响。这也是前面提到的 a-memguard 这类“Agent 记忆防御框架”存在的意义。所以在企业落地多 Agent 时我建议从一开始就贯彻三条安全原则最小权限每个 Agent 只能访问完成任务必需的最小范围、全量审计所有 Agent 之间的通信都要留痕、默认不信任任何外部 Agent 的请求都要过认证和鉴权。宁可多写几个中间件也别贪图省事裸奔上线。5. 实操从 Codex 单机到 A2A 企业服务落地时怎么选5.1 什么时候该上多 Agent说了这么多最后聊点实操。我见过不少团队被“多 Agent”这个词蛊惑一上来就规划十几个 Agent 协同作战结果几个月后连第一个都没跑通。所以先给一个冷静的判断框架你到底需不需要多 Agent判断维度单 Agent 能扛建议上多 Agent知识域数量单一领域需求边界清晰多个冲突知识域如客服营销上下文压力一次会话能装下所有信息任务需要跨长时间、大量资料故障影响挂了重启就行挂了会阻断生产流程需要局部容错并发要求一次处理一个任务大量独立任务需要并行消化团队协作不存在跨系统协同要接外部系统/多个部门流程说白了多 Agent 是复杂度到一定程度才需要的“外科手术”不是装饰品。单 Agent 能跑通的场景强行拆成多 Agent只会给自己增加协调成本。记住一句话多 Agent 存在的唯一理由是解决某个单 Agent 的硬瓶颈而不是因为它听起来更高级。5.2 落地路径建议先跑通单 Agent再谈协作如果你确认需要上多 Agent我的建议是按四步走别跳级。第一步先把单 Agent 的闭环做到稳定。任务拆解、工具调用、错误重试、上下文管理这四件事哪一个不过关多 Agent 只会放大问题而不是解决问题。你可以在 Codex 这类产品上找找手感也可以用开源框架自己搭一个最小闭环。第二步先定义任务状态机和消息格式再选技术栈。很多人上来就选 LangGraph 还是 CrewAI其实框架只是工具状态机才是灵魂。自己先用 JSON 定义一套消息格式哪怕不用任何框架手动实现两个 Agent 的协作你对“协作到底难在哪”的理解会深得多。第三步小规模试点。先上 2 到 3 个 Agent用一个真实业务流程验证。不要贪多三个 Agent 的协作复杂度和两个不是一个量级十个更是灾难级。第四步再考虑接入 A2A 这类标准协议。当你的 Agent 数量超过内部“手拉手直连”的承受范围时协议的价值才会真正显现。至于要不要用 Agent Card 对外发布能力要结合安全和合规要求评估别为了标准而标准。在模型配置上也顺带提一点Codex CLI 本身支持配置自定义模型供应商。如果你用的是 OpenAI 兼容接口的第三方服务可以在配置里切换端点地址和模型名。注意几点密钥要妥善管理不要写死在公开仓库里端点配置变更后最好重启 CLI 再试很多诡异报错源于配置未生效。5.3 高频报错与排查速查表下面这些是我和身边同事在实际使用 Codex 和类似 Agent 工具时碰到过的高频问题整理成速查表给你现象可能原因排查方向codex auth token is unavailable登录态过期或密钥未配置检查是否完成官方登录/认证流程重新获取凭据并确认环境变量配置cc switch local proxy failed while handling codex endpoint /responses切换模型供应商/端点配置时网络环境或代理设置导致请求失败检查 endpoint 地址是否正确、网络连通性是否正常、CLI 是否已重启加载新配置任务执行中途报execution terminated due to error任务超时、资源受限、上下文超限或工具调用异常把大任务拆成小任务分段执行检查上下文长度确认工具输出是否过大显示“更新 agent 沙盒”后无响应沙盒正在同步状态或资源占用较高稍等片刻必要时重启会话确认磁盘空间和内存充足并发一高就频繁报错模型 API 限流、工具执行线程不够、请求队列未加控制加限流熔断用消息队列做任务缓冲按需水平扩展多个 Agent 实例多 Agent 消息重复处理没做幂等控制同一个任务被重复消费为任务生成唯一 ID在接收侧做去重任务处理前先检查当前状态这里面我想重点说两个。第一个是cc switch local proxy failed这类问题它本质上是“配置切换后请求没有按预期走通”。你在排查时不要只盯报错信息本身先确认三件事endpoint 地址对不对、网络通不通、配置是否真正加载了。很多次问题就出在改了配置但没重启进程。第二个是并发问题这也是“AI Agent 怎么扛并发”这个高频疑问的答案。Agent 系统的瓶颈通常不在 CPU而在模型 API 的速率限制。所以策略不是盲目加机器而是客户端任务进来先进队列控制并发数量在 API 限流阈值内超出部分排队等待。工具调用层再配合线程池和超时熔断基本就能稳住。5.4 我对 Agent 协作的几条个人经验文章最后分享几条我自己真实撞过墙之后总结出来的经验。第一别让 Agent 用自然语言“自由聊天”。我最早做多 Agent 演示时也是让两个 Agent 互发长文效果确实惊艳。但一旦任务复杂起来你根本没法控制谈话走向。后来全部改成结构化消息加状态机问题立刻少了一大半。第二永远给 Agent 协作留“人工断点”。企业流程里关键操作付款、删数据、对外发公告一定要经过人确认再放行。这既是安全要求也是合规要求。A2A 里那个input-required状态就是为这个设计的——任务卡在等人工确认时不慌、不乱、状态明确这才是可用的企业级协作。第三多 Agent 系统的价值词不是“强”而是“可恢复”。单 Agent 很强但它挂了就是全挂多 Agent 单个不强但任何一个环节坏了都能被替换、被降级、被重试。做企业服务稳定比惊艳重要得多。至于未来我觉得 A2A 这类协议如果能普及Agent 之间就像当年的网页服务器一样各自提供服务、互相引用、组成一张庞大的服务网络。到那时候“Agent 生态”才真正从一个营销词汇变成每个开发者都能接入的基础设施。这篇文章只算我个人的阶段总结很多设计细节还在快速演进欢迎你带着实际踩坑的经验来找我交流。
做 Agent 开发这两年我越来越确认一个判断单 Agent 是工程问题多 Agent 是协议问题。从 OpenAI 的 Codex 把 Agent 循环做到产品级到 Google 牵头把 A2AAgent2Agent协议推进 Linux 基金会再到各种 agent 框架、编排平台层出不穷大家都在回答同一个问题——几个 Agent 凑在一起凭什么能把活干完而不是互相添乱这篇文章不打算跟你聊“Agent 的未来有多宏大”那没意思。我想把底层拆开看Codex 内部那套“计划—执行—观察—修正”的机制到底怎么转A2A 协议为企业级多 Agent 协作解决了哪些单机模式解决不了的问题以及从单 Agent 迁到多 Agent 落地时哪些坑你一定会踩。适合正在做 Agent 开发、或者想把 Agent 协作体系引到业务里的人看。不要求你有多深的技术背景但如果你写过几行代码读起来会更过瘾。1. 先聊清楚Agent 凭什么“自己干活”1.1 Agent 不是聊天机器人核心是“闭环”严格点的说法是Agent 是一个能感知环境、做决策、采取行动、再根据行动结果修正下一步动作的软件系统。大白话讲它不是那种“你问一句、它答一句”的聊天框而是一个拿到任务后自己拆解、自己想办法、自己动手干、干完还会自己检查的“数字员工”。这里面最值钱的一个词是“闭环”。你可以回想一下普通大模型应用的差距给 ChatGPT 发一句“写个爬虫”它给你一段代码任务就算交代完了剩下的装依赖、跑起来、修 bug 全是你的活。但一个 Agent 拿到同样的指令会先判断需求有没有歧义然后列出执行计划打开终端装依赖写代码跑一遍看到报错再改再跑直到交出一份可用的结果。这套“计划—执行—观察—修正”的循环才是 Agent 和普通大模型应用的分水岭。我见过太多人做 Agent 的第一个版本就是把模型 API 包一层壳然后跟老板说“我们上 Agent 了”。实际上那只是带温度参数的聊天机器人。判断一个系统是不是真 Agent就看两件事第一有没有工具调用能力能不能真的去操作外部系统第二有没有根据执行结果自动调整下一步的循环逻辑。两条缺一条都只能算“装了插件的聊天机器人”离 Agent 还差着十万八千里。这个闭环听起来简单真落地全是细节。模型选型、工具怎么定义、上下文怎么裁剪、错误重试策略、沙盒安全边界每一环都能把你的精力耗干净。这也是为什么 Codex 这类产品一亮相就让开发者兴奋它把整个 Agent 闭环做到产品级你看到的不是一个“会写代码的大模型”而是一个会开终端、会改文件、会查资料、会自己验证结果的完整工作流。1.2 为什么单 Agent 会撞墙——多 Agent 出现的真正原因既然一个 Agent 已经能干活了为什么还要折腾“多 Agent”这种听起来就不太可控的事答案很简单真实业务场景的复杂度远超单个 Agent 能承载的范围。举个最典型的例子企业内部智能客服。单 Agent 方案长这样——一个 Agent 接收用户问题理解意图然后查订单、查库存、走退货流程、发通知全包了。听起来很全能对吧跑起来你很快就会撞上三堵墙。第一堵墙是上下文爆炸。Agent 的上下文窗口是有限的你要让它同时掌握客服话术、订单查询接口、库存规则、退货流程、用户历史记录还没开始回答窗口已经满了一半。第二堵墙是职责冲突。退货规则和营销推荐是两个完全不同的知识域硬塞进同一个提示词模型很容易“精神分裂”——上一句还在严肃讲退货政策下一句就开始热情推荐新品。第三堵墙是故障扩散。所有环节都压在一个 Agent 上它一挂整个客服系统全瘫。多 Agent 的思路就是拆一个 Agent 负责接待和意图识别一个负责查订单一个负责走退货流程一个负责对外发通知。每个 Agent 只维护自己那一小块知识域和工具集合互相之间通过标准接口通信。拆完之后上下文压力小了职责清晰了单个 Agent 挂了只影响一个环节其他部分还能继续跑。但拆完不等于万事大吉。多 Agent 真正的难题恰恰全压在这两个字上“协作”。几个 Agent 之间怎么互相找到对方怎么传达任务怎么确认任务做完了A 告诉 B 一个结果B 怎么判断该不该信这些问题在单 Agent 时代根本不存在一进多 Agent 就变成绕不过去的核心命题——而且你会发现“让它们用自然语言随便聊”这个最直觉的方案恰恰是最不靠谱的。这个坑我后面专门讲。2. Codex 内部机制一个能写代码的 Agent 是怎么转起来的2.1 Codex 的本质不是“补全代码”是“执行任务”Codex 是 OpenAI 推出的编程 Agent主打终端使用。很多人第一次用时会产生一个误解这不就是个代码补全工具吗跟 Copilot 差不多吧。真不是。Copilot 的定位是“在你写代码时给建议”核心动作是补全ChatGPT 网页版的定位是“帮你生成代码片段”核心动作是产出文本Codex 的定位是“帮你把整个任务干完”核心动作是执行。这三者差一个量级。Codex 拿到需求后会在一个受控的沙盒环境里自己开终端、自己读写文件、自己跑测试跑挂了就自己看日志修修完再跑直到完成任务或者明确告诉你“做不了”。它本质上是一个“长在终端里的数字程序员”模型只是它的大脑工具链路才是它的手脚。从技术实现上说它走的是 Responses API也就是/responses这个端点。你可能在报错里见过类似codex endpoint /responses的字样那就是它在请求模型接口时留下的痕迹。整个交互不是一次“问答”而是多轮“动作—反馈”的循环模型给出下一步动作CLI 负责执行执行结果再喂回给模型。这里我想强调一个容易被忽略的点Codex 的“任务执行”本质上是一个有状态的过程。它不像普通 API 调用那样“请求一次、返回一次”就完事而是像一个人坐在工位前连续工作好几个小时。理解了这一点你就明白为什么 Agent 系统的并发、上下文、状态管理会这么难——这已经不是“接口设计”的范畴而是“运行时设计”的范畴了。2.2 Agent 循环请求、计划、工具调用、观察、迭代Codex 的核心运行机制学术上有个名字叫 ReAct也就是 Reason推理加 Act行动的循环。翻译成人话就是模型先想一想“现在该干什么”然后决定“调用哪个工具干什么事”工具执行完模型看到结果再想“接下来干什么”如此反复。具体拆开看一轮典型的 Codex 会话长这样用户输入自然语言任务比如“帮我把这个仓库里所有 TODO 注释整理成一份报告”。模型先做计划可能是“先用 grep 找到所有 TODO再逐个看上下文最后生成报告”。模型发起第一次工具调用比如执行grep -rn TODO src/。CLI 在沙盒中执行这条命令把输出结果返回给模型。模型看到输出判断“信息够了开始写报告”然后发起文件写入操作。CLI 执行写入生成报告文件。模型再做一次检查确认文件内容符合要求会话结束。这个循环的每一步都是“生成动作—执行动作—观察结果”的微循环。我实际用下来的感受是Codex 最厉害的地方不是它一次能写出多长的代码而是它很擅长“边干边调整”。你丢给它一个没说清楚的需求它会先探索环境、收集信息再动手。这种“先侦察再干活”的习惯是 Agent 能不能处理真实任务的分水岭。很多普通模型接入工具链后表现很差核心原因就是只有“一次生成”没有“观察—再生成”这个迭代回路。这个机制带来的工程启示是做 Agent 开发第一步不是优化提示词而是先把“工具调用结果如何反馈给模型”这条链路打通并且把工具的输出格式整理干净。工具输出一团糟模型再聪明也白搭。2.3 沙盒与执行环境为什么代码必须“跑起来”才算数Codex 默认不会直接在你的电脑上为所欲为。它把命令执行放在一个隔离的沙盒环境里模型对文件系统的修改会以“变更集”的形式呈现由你审阅后再决定要不要合入本地工作区。你如果看到终端提示“更新 agent 沙盒”别慌那基本就是环境在同步状态、刷新某个变更属于正常行为。为什么要这么设计道理很朴素模型有可能执行危险命令比如rm -rf跑错目录、下载来源不明的依赖、或者修改不该动的配置。如果不加沙盒一次误操作就能把本地环境搅得天翻地覆。有了沙盒模型可以放手去试错风险被控制在隔离区内最终合不合并由人说了算。从架构上说沙盒不是虚拟机更像“受限执行环境加文件差异跟踪”。它的价值有两条一是安全隔离二是可审计。每一次命令执行、每一个文件改动都有记录你随时可以回看“这个 Agent 刚才到底干了什么”。这一条对企业落地尤其重要——如果 Agent 的行为完全不可审计那它再能干也没人敢在生产环境里放它出来。所以这里给做 Agent 系统的人一个建议无论你用不用 Codex你的工具执行层一定要有沙盒意识。不需要一上来就搞全套容器隔离但至少要做到“工具执行结果可回滚、可记录、可审核”。没有这层兜底Agent 的能力越强你的风险越大。2.4 上下文管理Agent 的“记忆力”到底怎么存Agent 的记忆问题是很多人忽略但逃不掉的一关。很多人以为“记忆力”就是把聊天记录全塞进上下文窗口实际根本不是那回事。Codex 处理长任务时有一套相当务实的策略它不会把整个仓库的全部文件都读进上下文而是“按需读取”——先用 grep 定位相关代码再读片段。文件内容也不是一字不差全塞进去而是提取关键信息。做长任务时早期对话会被压缩成摘要只保留跟当前步骤相关的残留信息。你看这些机制本质上都是在对抗同一个物理限制上下文窗口是有限的而真实任务的信息量是无限的。我自己在做一个类似机制时最深刻的体会是上下文管理的好坏直接决定 Agent 能不能做“超过单次对话长度”的任务。如果所有工具输出都原样塞进上下文三轮之后模型就开始“失忆”——它记不得最开始的任务目标是什么。所以做 Agent 开发至少要规划三件事对话历史的摘要策略、工具输出的大幅裁剪、以及任务关键信息的持久化存储。这三点做好你的 Agent 才算有“长期记忆”的雏形。顺带提一句记忆不仅是性能问题还是安全问题。业界已经出现针对“Agent 记忆投毒”的攻击研究思路是往 Agent 依赖的外部记忆里注入恶意内容诱导它在后续任务中按攻击者意图行事。我记得有一个叫 a-memguard 的研究方向就是专门做“面向大模型 Agent 记忆的前置防御框架”的。多 Agent 场景下记忆共享面更大这个风险只会更严重后面讲安全时我再细说。3. 从单 Agent 到多 Agent协作到底靠什么3.1 多 Agent 的三种协作模式多 Agent 系统里“怎么组织”是第一个要回答的问题。虽然实现花样百出但抽象到最后就三种模式编排者-执行者、对等协作、流水线接力。编排者-执行者Orchestrator-Worker是最好理解也最常用的模式一个“老大”Agent 负责把大任务拆成子任务分发给一组“小弟”Agent 执行小弟把结果交回来老大再汇总、再判断、再分发。好处是控制集中、逻辑清晰、出了问题容易定位坏处是老大容易成为瓶颈而且它自己要承载大量的上下文和调度压力。企业里很多客服机器人团队就是这么组织的一个主管分配多个专员干活。对等协作Peer-to-Peer则是让 Agent 之间可以自由互相发消息、互相请求。灵活度高适合几个能力相当的 Agent 需要协商的场景比如一个写方案、一个做评审来回讨论。但它的问题也很明显没有中心节点协调成本高消息满天飞的时候很容易出现“两个 Agent 互相踢皮球”的死循环。流水线接力Pipeline则是把任务切成固定顺序的环节A 做完交给 BB 做完交给 C像工厂流水线。职责单一、吞吐高但整条链路上任何一个环节挂掉整条线就卡住所以每个环节都要有重试和容错。选型上我的经验是能力强弱不均、需要统一调度的场景用编排模式几个 Agent 水平相当且需要互相讨论的用对等模式任务流程天然分阶段固定的用流水线。开头别想着把三种模式都做了先选一种跑通后面再演进。3.2 分工不是靠“聊天”是靠“协议”现在到了我最想说的话题。网上很多多 Agent 的炫酷演示都是两个 Agent 用自然语言你来我往地“聊天”一个说“你能帮我做一下数据清洗吗”另一个回“好呀我这就去”。第一次看确实很震撼但你要把这套东西放进企业生产环境会发现它是灾难。为什么因为自然语言的信息熵太高了。A 说“帮我处理一下数据”B 大概率理解出五个版本的结果。而且自然语言没有契约性——没有明确的字段、没有错误码、没有重试依据。A 发给 B 一个任务B 干到一半挂了A 怎么知道该不该重发B 给 A 的回复里哪一段是结论、哪一段是闲聊审计的时候你怎么跟合规部门解释“系统自己跟系统聊天聊出了这个结果”所以真实的多 Agent 协作分工不是靠聊天而是靠协议。说得直白点Agent 之间交换的每一句话都应该是结构化消息包含任务 ID、动作类型、参数、期望输出格式、回调地址。就像 REST API 是程序之间通信的规范一样Agent 之间也需要这样一套“通信规范”。这个认知是理解 A2A 的前提。你可能还听说过 MCPModel Context Protocol它解决的是“Agent 怎么调用外部工具和数据源”而 A2A 解决的是“Agent 怎么和其他 Agent 通信”。两者不是竞争关系而是互补关系。打个比方MCP 是给 Agent 装上 USB 接口让它能插外部设备A2A 是给 Agent 装上网络协议让它能和其他计算机互发消息。一个管“接入”一个管“连接”。3.3 进度同步与任务状态机企业场景最容易被忽略的环节多 Agent 协作里最容易被初学者忽略、但企业落地时一定会被反复拷问的问题就是“任务现在到底进行到哪一步了”。你以为是一句废话实际上这条信息在多 Agent 系统里极其容易失控。设想一个退款场景用户找客服 Agent A 申请退款A 把退款请求发给负责执行退款流程的 Agent BB 去调支付系统接口。如果 B 在处理过程中超时了A 不知道A 重发了一次请求结果 B 其实已经退成功了一笔于是用户收到了两笔退款。这种事故不是纸上谈兵是多 Agent 生产环境里最常见的“重复执行”事故。所以多 Agent 系统必须有一个明确的任务状态机。A2A 里定义的那套状态就很典型任务提交submitted、执行中working、需要补充输入input-required、完成completed、失败failed、取消canceled。所有 Agent 对状态的认知必须一致状态变更要通过结构化消息同步。在此基础上还要做两件事幂等性和超时。幂等性保证“同一个任务被重复送达时不会重复执行”超时保证“对方没响应时系统知道该怎么办而不是无限等下去”。很多团队做多 Agent 时先选框架、先调模型却忘了先画一张状态机图最后上线全是状态对不上的问题。我强烈建议任何多 Agent 项目的第一张设计图应该是任务状态流转图而不是架构拓扑图。4. A2A企业级 Agent 协作协议是怎么设计的4.1 A2A 解决了什么问题A2A 全称 Agent2Agent是 2025 年上半年由 Google 提出、随后捐给 Linux 基金会维护的开放协议。它出现的核心动机就一句话Agent 越来越多但每个 Agent 都是“信息孤岛”彼此之间没有通用的交流方式。你可以这样理解HTTP 协议让任何两台服务器能互相通信A2A 想让任何两个 Agent 也能互相通信。有了它公司 A 的客服 Agent 可以直接把任务发给公司 B 的物流 Agent而不需要互相提前定制接口。套用前面那个比喻——如果说 Agent 是一个个“数字员工”那 A2A 想做的就是给这些数字员工发一本通用的“职场沟通手册”规定好怎么自我介绍、怎么接活、怎么汇报进度、怎么交接成果。对于企业来说这套标准化的价值在于你不再被某一家厂商的 Agent 生态绑死。你今天用 A 厂商的 Agent 做客服明天想换成 B 厂商的 Agent只要双方都支持 A2A替换成本就大幅降低。这其实和当年浏览器都支持 HTTP、服务器都支持 TCP/IP 是同一个逻辑——标准化是生态繁荣的前提。A2A 和 MCP 的关系也需要理清。MCP 管的是“Agent 和工具/数据之间的连接”A2A 管的是“Agent 和 Agent 之间的连接”。一个 Agent 可以同时使用 MCP 去访问数据库又通过 A2A 去请求另一个 Agent 的协助。它们是解决不同层次问题的互补协议不是二选一的关系。4.2 Agent Card怎么告诉别人“我能干什么”A2A 协议里有一个特别精巧的设计叫 Agent CardAgent 卡片。你可以把它理解成每个 Agent 对外发布的“电子简历”或“能力清单”。它通常是一个 JSON 文件放在一个固定的公开地址上惯例是/.well-known/agent.json里面写清楚这个 Agent 是谁、提供哪些能力、每个能力需要什么输入、会产生什么输出、通过哪个端点访问、需要什么样的认证。一个简化后的 Agent Card 大概是这种感觉{ name: order-agent, description: 处理订单查询与状态更新, skills: [ { id: order_query, name: 订单查询, description: 根据订单ID返回订单状态与物流信息 }, { id: order_update, name: 订单更新, description: 更新订单备注或预约时间 } ], endpoints: [ https://api.example.com/agent/order ], security: { auth_type: oauth2, scopes: [orders:read, orders:write] } }这个设计解决的是多 Agent 协作里的“可发现性”问题。在没有任何目录服务的前提下别的 Agent 怎么知道你存在、你能干什么、怎么调用你Agent Card 就是答案。它把“发现能力”和“描述能力”标准化了任何一个 Agent 只要拿到另一个 Agent 的卡片就能判断“它能不能帮我干这个活以及我该怎么叫它干活”。我尤其喜欢它把“能力”显性化这个做法。企业里评估一个外部系统能不能接入最烦的就是对方文档不全。Agent Card 相当于强制每个 Agent 输出一份机器可读的能力说明书这对集成效率的提升是实打实的。4.3 任务生命周期从提交到完成的状态流转A2A 最核心的抽象是 Task任务。两个 Agent 之间的所有协作最终都落到“一个 Agent 向另一个 Agent 发起一个任务直到任务终结”这条主线上。而任务的核心就是前面提到的状态机。任务提交后进入 submitted 状态接收方开始处理则变为 working。如果处理过程中发现信息不够比如退款需要用户确认身份任务会进入 input-required 状态其实就是卡住等人补材料。材料补齐后回到 working。最终要么 completed成功产出结果要么 failed失败要么 canceled被取消。这套状态机的妙处在于它让“异步长任务”变得可以被管理。Agent 之间协作往往不是秒回一个任务可能跑几分钟甚至几小时。如果没有状态机发起方只能干等有了状态机发起方可以随时查询任务状态接收方也可以通过流式更新A2A 支持基于 SSE 的流式推送主动汇报进度。对企业业务来说input-required 这个状态尤其重要。因为真实业务流程里“等人工确认”是常态。A2A 没有回避这一点而是把它设计成了第一等公民——任务可以在人和 Agent 之间来回交接这比那种“Agent 一跑到底、绝不回头”的理想化设计接地气多了。4.4 消息、流与工件协作中的“语言”说完任务状态再说说 A2A 里“消息”长什么样。A2A 的消息基于 JSON-RPC 风格设计所有通信都是结构化的包含消息 ID、任务 ID、消息类型、发布时间这些基础字段。这种设计的好处是机器可解析、可追踪、可审计。除了消息本身A2A 还有一个概念叫 Artifact工件指的是任务执行过程中产生或更新的“成果物”。比如一个数据分析 Agent 处理完任务后生成了一份报告文件这份文件就可以作为一个 Artifact 返回给发起方。Artifact 和状态更新是分开推送的——发起方既能知道“任务到哪一步了”又能拿到“实际产出了什么”。基于流的事件推送则让 A2A 特别适合长任务场景。比如一个 Agent 让另一个 Agent 生成一份季度经营分析报告后者生成到一半前者已经能收到“正在汇总财务数据”“正在生成图表”这些中间事件而不是干等着最终结果。这种“可观测的异步协作”是企业级系统非常看重的能力——因为你看得到进展就知道系统没死、没卡、没在瞎跑。4.5 安全与身份多 Agent 协作的底线多 Agent 协作的最后一个支柱是安全。企业里两个 Agent 通信绝不能像两个人在路边悄悄递纸条一样没有凭据。A2A 在设计上把安全放得很重Agent 之间的访问需要通过身份认证常见方式包括 OAuth 2.0、API Key以及更严格的客户端证书mTLS。每个 Agent 暴露能力时要声明所需权限范围比如“只读订单”和“可改订单”是不同级别的授权。这里我说个容易被忽略的点多 Agent 场景下的安全风险不只是“被外部攻击”还有“内部 Agent 被攻破后互相传染”。如果一个 Agent 被恶意提示词劫持它可能会向协作伙伴发送精心构造的恶意请求。更阴险的是共享记忆投毒——如果多个 Agent 共享同一个记忆存储攻击者攻破一个 Agent 后往共享记忆里注入误导信息其他 Agent 后续决策都会受影响。这也是前面提到的 a-memguard 这类“Agent 记忆防御框架”存在的意义。所以在企业落地多 Agent 时我建议从一开始就贯彻三条安全原则最小权限每个 Agent 只能访问完成任务必需的最小范围、全量审计所有 Agent 之间的通信都要留痕、默认不信任任何外部 Agent 的请求都要过认证和鉴权。宁可多写几个中间件也别贪图省事裸奔上线。5. 实操从 Codex 单机到 A2A 企业服务落地时怎么选5.1 什么时候该上多 Agent说了这么多最后聊点实操。我见过不少团队被“多 Agent”这个词蛊惑一上来就规划十几个 Agent 协同作战结果几个月后连第一个都没跑通。所以先给一个冷静的判断框架你到底需不需要多 Agent判断维度单 Agent 能扛建议上多 Agent知识域数量单一领域需求边界清晰多个冲突知识域如客服营销上下文压力一次会话能装下所有信息任务需要跨长时间、大量资料故障影响挂了重启就行挂了会阻断生产流程需要局部容错并发要求一次处理一个任务大量独立任务需要并行消化团队协作不存在跨系统协同要接外部系统/多个部门流程说白了多 Agent 是复杂度到一定程度才需要的“外科手术”不是装饰品。单 Agent 能跑通的场景强行拆成多 Agent只会给自己增加协调成本。记住一句话多 Agent 存在的唯一理由是解决某个单 Agent 的硬瓶颈而不是因为它听起来更高级。5.2 落地路径建议先跑通单 Agent再谈协作如果你确认需要上多 Agent我的建议是按四步走别跳级。第一步先把单 Agent 的闭环做到稳定。任务拆解、工具调用、错误重试、上下文管理这四件事哪一个不过关多 Agent 只会放大问题而不是解决问题。你可以在 Codex 这类产品上找找手感也可以用开源框架自己搭一个最小闭环。第二步先定义任务状态机和消息格式再选技术栈。很多人上来就选 LangGraph 还是 CrewAI其实框架只是工具状态机才是灵魂。自己先用 JSON 定义一套消息格式哪怕不用任何框架手动实现两个 Agent 的协作你对“协作到底难在哪”的理解会深得多。第三步小规模试点。先上 2 到 3 个 Agent用一个真实业务流程验证。不要贪多三个 Agent 的协作复杂度和两个不是一个量级十个更是灾难级。第四步再考虑接入 A2A 这类标准协议。当你的 Agent 数量超过内部“手拉手直连”的承受范围时协议的价值才会真正显现。至于要不要用 Agent Card 对外发布能力要结合安全和合规要求评估别为了标准而标准。在模型配置上也顺带提一点Codex CLI 本身支持配置自定义模型供应商。如果你用的是 OpenAI 兼容接口的第三方服务可以在配置里切换端点地址和模型名。注意几点密钥要妥善管理不要写死在公开仓库里端点配置变更后最好重启 CLI 再试很多诡异报错源于配置未生效。5.3 高频报错与排查速查表下面这些是我和身边同事在实际使用 Codex 和类似 Agent 工具时碰到过的高频问题整理成速查表给你现象可能原因排查方向codex auth token is unavailable登录态过期或密钥未配置检查是否完成官方登录/认证流程重新获取凭据并确认环境变量配置cc switch local proxy failed while handling codex endpoint /responses切换模型供应商/端点配置时网络环境或代理设置导致请求失败检查 endpoint 地址是否正确、网络连通性是否正常、CLI 是否已重启加载新配置任务执行中途报execution terminated due to error任务超时、资源受限、上下文超限或工具调用异常把大任务拆成小任务分段执行检查上下文长度确认工具输出是否过大显示“更新 agent 沙盒”后无响应沙盒正在同步状态或资源占用较高稍等片刻必要时重启会话确认磁盘空间和内存充足并发一高就频繁报错模型 API 限流、工具执行线程不够、请求队列未加控制加限流熔断用消息队列做任务缓冲按需水平扩展多个 Agent 实例多 Agent 消息重复处理没做幂等控制同一个任务被重复消费为任务生成唯一 ID在接收侧做去重任务处理前先检查当前状态这里面我想重点说两个。第一个是cc switch local proxy failed这类问题它本质上是“配置切换后请求没有按预期走通”。你在排查时不要只盯报错信息本身先确认三件事endpoint 地址对不对、网络通不通、配置是否真正加载了。很多次问题就出在改了配置但没重启进程。第二个是并发问题这也是“AI Agent 怎么扛并发”这个高频疑问的答案。Agent 系统的瓶颈通常不在 CPU而在模型 API 的速率限制。所以策略不是盲目加机器而是客户端任务进来先进队列控制并发数量在 API 限流阈值内超出部分排队等待。工具调用层再配合线程池和超时熔断基本就能稳住。5.4 我对 Agent 协作的几条个人经验文章最后分享几条我自己真实撞过墙之后总结出来的经验。第一别让 Agent 用自然语言“自由聊天”。我最早做多 Agent 演示时也是让两个 Agent 互发长文效果确实惊艳。但一旦任务复杂起来你根本没法控制谈话走向。后来全部改成结构化消息加状态机问题立刻少了一大半。第二永远给 Agent 协作留“人工断点”。企业流程里关键操作付款、删数据、对外发公告一定要经过人确认再放行。这既是安全要求也是合规要求。A2A 里那个input-required状态就是为这个设计的——任务卡在等人工确认时不慌、不乱、状态明确这才是可用的企业级协作。第三多 Agent 系统的价值词不是“强”而是“可恢复”。单 Agent 很强但它挂了就是全挂多 Agent 单个不强但任何一个环节坏了都能被替换、被降级、被重试。做企业服务稳定比惊艳重要得多。至于未来我觉得 A2A 这类协议如果能普及Agent 之间就像当年的网页服务器一样各自提供服务、互相引用、组成一张庞大的服务网络。到那时候“Agent 生态”才真正从一个营销词汇变成每个开发者都能接入的基础设施。这篇文章只算我个人的阶段总结很多设计细节还在快速演进欢迎你带着实际踩坑的经验来找我交流。
