最近我被问得最多的一个问题多 Agent 协作到底靠什么起因也很直接Codex 这类 CLI 编码 Agent 普及之后大家发现单个 Agent 确实能干活可真到了“多个 Agent 一起干一件事”的时候谁派活、谁汇报、状态怎么同步、任务怎么拆一下子就乱成一团。再加上 Google 把 A2AAgent2Agent协议推到台前不少人跑来问我A2A 是不是要把 MCP 干掉Codex 内部到底是怎么自己干活的这些概念听着都熟串起来就懵。这篇文章打算一次讲透三件事先把多 Agent 协作的本质拆开再扒一扒 Codex 的内部机制看看单 Agent 为什么这么能打然后讲清楚 A2A 协议在企业服务里到底解决什么问题。最后给一份实操配置——把 Codex 接到 DeepSeek 等兼容模型、模拟一次多 Agent 任务拆解顺便整理我踩过的一堆坑。适合正在用或者准备用 Codex 的开发者也适合被老板安排“把几个 Agent 接到系统里”的架构师。1. 先搞懂一件事多 Agent 协作到底在协作什么1.1 为什么单个 Agent 不够用先说点反直觉的很多场景下单 Agent 就是够用的而且更便宜、更快、更好排查。改个小 bug、写个脚本、生成一段文案一个 Agent 配上工具链就能搞定。你在一个聊天窗口里把任务拆成十步让 Agent 一步步做那依然算单 Agent——它只是自己和自己对话。真正的多 Agent是多个有独立上下文、独立目标、甚至独立运行环境的实体为了一个共同任务去分工协作。那什么时候必须上多 Agent我总结下来就三类第一任务需要风险隔离。比如一个 Agent 正在改生产代码另一个 Agent 负责独立做代码审查两边上下文不共享出了问题不会互相污染。第二任务需要不同专业能力。比如一个 Agent 擅长写代码一个 Agent 擅长查文档一个 Agent 擅长跑测试硬塞给同一个 Agent 也能做但质量和速度都会打折。第三任务天然可以并行。比如同时排查五个仓库的构建问题串行做就是浪费时间。多 Agent 不是人海战术它的核心价值是上下文隔离和任务解耦。单人聊天窗口再长上下文也是会互相干扰的多个 Agent 各管一段上下文反而清晰。1.2 协作的本质任务拆分、通信、状态、信任我拆过不少 Agent 协作的系统最后发现不管用什么框架、什么协议多 Agent 协作绕不开四个核心问题。第一个是任务拆分。主控 Agent 把用户一句“帮我排查线上问题”拆成可验证的子任务先看日志再查监控然后定位代码最后给出修复建议。拆分得好不好直接决定协作质量。拆得太粗子 Agent 不知道干什么拆得太细通信开销比干活成本还高。第二个是通信。子 Agent 之间用什么格式传递信息纯文本结构化 JSON带文件的附件还是函数调用这套消息格式不统一Agent 之间就是鸡同鸭讲。第三个是状态。一个任务到底进行到哪一步了是正在跑、等输入、完成了、还是失败了状态不同步主控 Agent 根本没办法决策。你想想如果项目经理不问进度开发说在做、测试说没收到包项目必黄。第四个是信任。谁有权限调用谁子 Agent 能访问哪些系统跨团队、跨企业的 Agent 协作尤其要命。Agent 本身是自动执行代码的信任边界画不清楚相当于把钥匙交给陌生人。这四个问题其实就是所有 Agent 协作框架和协议要解决的核心后面讲 Codex 和 A2A 时你会发现大家都是在回答这四个问句。1.3 两种实现路线进程内编排 vs 协议互联多 Agent 协作目前主流就两条路线很多人搞混。路线 A进程内编排。在同一个系统里由主控 Agent 或者框架直接创建子 Agent共享底层资源、隔离上下文。LangGraph、CrewAI 这类框架就是干这个的。Codex 内部的多 worktree 并行、多实例并行本质上也是这一路。优点是好控制、性能高、调试方便缺点是绑死在一个运行时里没法跨团队、跨组织协作。路线 B协议互联。每个 Agent 都是独立部署的服务通过标准协议互相调用。A2A 就是典型。Agent 之间不知道对方用什么框架写的、跑在什么语言里只要遵守同一个通信协议就能互相发现、派活、同步结果。优点是彻底的解耦缺点是要处理网络、认证、版本兼容这些麻烦事。打个比方路线 A 像同一个公司里的同事用企业微信沟通路线 B 像不同公司之间用邮件加合同办事。你问哪种更好没有更好只有更合适。企业内部多个 Agent 协作A 就够了跨部门、跨企业或者你压根不知道对方 Agent 是谁实现的必须走 B。2. Codex 内部机制拆解单 Agent 为什么这么能打2.1 Agent 循环计划、行动、观察反复迭代先把 Codex 的本质说清楚它不是一个“输入 prompt 吐代码”的聊天机器人而是一个真正跑在环境里的 Agent。它的核心机制是一个循环我一般写成这样读取当前状态看了哪些文件、历史对话、项目说明。决定下一步是改代码、跑命令还是问用户。执行动作调用工具比如写文件、执行 bash、调用 MCP。观察结果命令输出、报错、测试结果。更新计划根据观察修正自己的理解回到第 2 步直到满足完成条件。这个循环最关键的不是“能自动跑”而是每一步都有验证点。模型生成的代码不一定是可靠的但循环可以把生成的代码立刻丢进环境里跑一遍测试看到测试输出了才知道写得到底对不对。这跟“一次性生成一大段代码”的区别就像开车和自动驾驶自动驾驶每时每刻都在根据路况修正方向而不是一开始就规划好全程然后闭眼开。Codex 的这个 Agent 循环你可以用伪代码理解state initialize_context() while not task_complete(state): action decide_next_action(state) # 模型决策 state execute_action(action) # 工具执行 state observe_results(state) # 模型观察 state update_plan(state) # 模型修正计划就这么简单。但简单背后每一步都有大量工程细节上下文怎么压缩、命令超时怎么办、沙盒权限怎么限定、失败怎么重试。2.2 沙盒与工具调用让它敢动手Codex 最让我觉得“这工具认真做了”的地方是沙盒机制。Agent 是要执行命令的但模型输出是概率性的它可能在路径上打错一个字就可能把/usr删了或者往生产环境写脏数据。Codex 的做法是默认在受限环境里执行命令——基于容器或者操作系统的沙盒机制限制文件系统写入范围、网络访问等权限。命令失败也只是沙盒内失败不会把宿主机搞崩。这也解释了为什么 Codex 有些版本在 Windows 上会提示 “start the windows daemon from a non-elevated terminal”——它的沙盒在 Windows 上需要启动一个后台服务来管理受限环境。如果你用管理员终端启动反而会被它拦下来要求你用普通 PowerShell 或 CMD 启动。这是很多人在 Windows 上装完 Codex 打不开的常见原因。Codex 的工具调用能力也很关键。它不止能写文件、执行命令还支持 MCPModel Context Protocol工具。你只要给 Codex 配一个 MCP server就能让它调用任何你暴露出来的 API查数据库、发消息、调内部系统全都变成它的“手”。这一步做完Codex 就不再是“写代码的工具”而是一个能操作你整个系统的数字员工。2.3 Skills、AGENTS.md 与上下文管理Codex 有一点经常被忽略它支持项目级的规范文件AGENTS.md。你可以在项目根目录放一个文档写清楚项目结构、构建命令、代码规范、注意事项。Codex 会在每轮对话中参考这个文件。别小看这个我实测过放一份 AGENTS.md 和不放Agent 的输出质量差距非常大。它是你怎么把团队知识喂给 Agent 的最直接方式。Skills 则是更高阶的玩法。Codex 支持把一组指令和脚本打包成一个 Skill按需加载。比如你们团队有一个“发布前检查清单”你做成 Skill 后Codex 在执行到发布环节时就会自动套用。这本质上就是把 Agent 的隐性经验固化下来。还有上下文管理。上下文是 Agent 的 RAM窗口终归有限。Codex 在对话变长时会自动压缩历史把旧内容总结成摘要然后保留关键信息。这个机制让它能持续跑很长的任务而不是对话到一半就“失忆”。反过来给你的启示是你喂给 Agent 的说明越结构化它压缩和检索的效率越高。长篇大论的废话它在压缩时很容易丢掉重点。2.4 Codex 对多 Agent 的支持已经带了一点影子严格来说Codex 的默认形态是单 Agent。但它身上已经带了不少可以支撑多 Agent 协作的设计。一是 worktree 并行。Codex 可以在不同工作树上并行验证不同的方案谁先通过测试就用谁的。这已经是“多个执行体并行探索”的雏形了。二是codex exec无头模式。你可以把它当作命令行工具在 CI 里调用不依赖交互界面。这就意味着你可以在流水线里拉起多个 Codex 实例每个实例负责一个模块、一个仓库或者一类任务。这是目前最靠谱的“多 Codex 协作”方式不需要改 Codex 内部直接在外部编排。三是 MCP 工具封装。你完全可以写一个 MCP server把另一个 Agent哪怕是别的产品封装成一个工具让 Codex 调用它。虽然笨但在工程上是可行的也是很多人实际在用的做法。所以我的结论是Codex 给你的是一个“单兵素质极强的战士”多 Agent 的组织和调度还是得靠你自己或者在外部框架里做。3. A2A 协议Agent 之间的“企业级普通话”3.1 A2A 到底解决什么问题先理清 A2A 的背景。Google 在 2025 年发布了 Agent2Agent 协议简称 A2A后来把这个协议捐赠给了 Linux 基金会治理。它要解决的问题比“让两个 Agent 聊聊天”务实得多不同厂商、不同团队、不同技术栈开发的 Agent如何互相发现、互发任务、同步结果你想想企业内部实际的样子客服团队用 A 厂商的 Agent运维团队自己写了一个 B Agent供应链那边用的是 C 系统的 Agent。现在老板说把它们拉通做一个智能服务台。怎么拉通让 A 厂商的 Agent 直接调 B Agent 的内部 API不现实谁都不愿意为别人改接口。让每个 Agent 都实现一套 REST API 给别的 Agent 调接口五花八门光是联调就要命。A2A 就干这个定义一套统一的协议所有 Agent 只要遵守这套协议就能互相协作不用关心对方内部怎么实现的。可以理解成 MCP 和 A2A 的分工不同——用最粗的话说MCP 是 Agent 和工具之间的 USB-C 接口A2A 是 Agent 和 Agent 之间的电话加合同。MCP 不会过时它管的是“插上就能用”A2A 管的是“约好怎么说”。3.2 A2A 核心概念Agent Card、Task、MessageA2A 协议里三个核心概念值得仔细理解。第一个是Agent Card。每个 Agent 都要在一个标准位置暴露自己的“名片”通常是/.well-known/agent.json。名片上写着这个 Agent 叫什么、有什么能力、接受什么输入、需要什么认证方式、消息端点在哪。其他 Agent 拿到这个名片就知道怎么和它打交道。这解决了我前面说的“发现”问题也是为什么 A2A 特别适合企业服务——每个 Agent 本质上就是一个可被发现的服务。第二个是Task。A2A 里最小的协作单元。客户端向服务端 Agent 发起一个任务比如“查询订单状态”。任务有明确的状态机submitted、working、input-required、completed、canceled、failed。为什么设计成状态机因为 Agent 任务可能跑很久两边不可能一直保持一条连接。客户端建任务、查状态、拿结果整个生命周期都规范好了。第三个是Message 和 Part。任务的结果和中间信息都通过消息传递。消息体里可以装文本、文件、结构化数据、函数调用。这正好对应我前面说的通信问题——A2A 把消息格式标准化了不同类型的 Agent 互相之间能读懂对方发的数据。传输层用的是 JSON-RPC 2.0 over HTTP流式结果用 SSE 推送。这套东西不新但非常稳企业里好落地。3.3 和 MCP 的分工一个管工具一个管 Agent我经常被问“MCP 和 A2A 是不是重复了”完全不重复而且是互补关系。MCP 是 Agent 内部接工具的标准一个 Agent 通过 MCP 去调用数据库、文件、各种 API。A2A 是 Agent 和 Agent 之间的通信标准。实际的架构通常是这样的Agent A 内部用 MCP 连接自己的工具链完成本职工作。Agent A 通过 A2A 协议把任务发给 Agent B。Agent B 内部也用 MCP 接自己的工具链完成后把结果通过 A2A 返回给 Agent A。所以说MCP 让 Agent 有“手”A2A 让 Agent 有“伙伴”。两者解决的问题不一样落地时经常要一起用。企业做 Agent 平台大概率的做法是对外暴露 A2A 接口让别的 Agent 能调用你对内用 MCP 把各种工具接进来。两个协议并不是竞争关系而是处于不同的协议层级。3.4 企业落地的关键场景与治理协议讲再多最终要落到业务上。我见过几个比较靠谱的 A2A 企业落地场景第一个是智能客服协同。用户问“我的订单为什么还没发货”订单查询 Agent 负责查物流售后政策 Agent 负责判断能否赔付最后协同 Agent 汇总给出答复。这比一个大而全的客服 Agent 好做得多因为订单和售后的数据权限本来就不该给同一个 Agent。第二个是IT 运维自动化。监控 Agent 发现某个服务响应变慢自动创建一个任务发给日志分析 Agent日志分析 Agent 定位出是慢 SQL再创建任务发给变更 Agent 去执行修复脚本。三个 Agent 职责清晰权限隔离每次操作都有审计记录。第三个是跨部门流程协同。库存 Agent、物流 Agent、财务 Agent 三部门协作处理一笔异常订单每个 Agent 维护自己的数据不动只通过 A2A 传递任务和结果。账目出了问题根据任务记录一查就知道是哪个 Agent 的决策。企业落地 A2A 真正要花心思的不是协议本身而是治理每个 Agent 都必须有明确的身份和权限模型Agent Card 要写清楚“能干什么、不能干什么、需要什么凭证”任务追踪要留审计日志。纯聊天式的黑盒 Agent 做做 demo 可以真正进生产系统没有审计是不行的。这套治理体系才是 A2A 企业服务里最值钱的部分。4. 实操把 Codex 配置成一个可协作的 Agent4.1 安装、登录与基本使用先过一遍最基础的操作。Codex CLI 目前最常见的安装方式是通过 npmnpm install -g openai/codex装完之后你可以在终端里直接运行codex进入交互模式也可以用codex exec 你的任务一次性执行任务。后者特别适合在脚本和 CI 里用也是我做多 Agent 编排的“单兵单元”。认证方式有两种一是用 ChatGPT 账号登录二是用 API Key。如果你用 API Key需要设置环境变量export OPENAI_API_KEYsk-...如果碰到auth token is unavailable这类报错不用慌优先级先查三件事环境变量有没有真的设置上很多坑是 Shell 没重启、codex login的登录态有没有过期、用的是不是自己的 API Key。大部分认证问题都是这三件事之一。4.2 接入 DeepSeek 等兼容模型配置解析很多人不想用默认模型想把 Codex 接到 DeepSeek 这类兼容 OpenAI 接口的模型供应商上。这个完全可行Codex 支持自定义模型供应商。在 Codex 的配置文件里添加一个模型供应商然后用model_provider指向它model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat逐行解释一下model决定 Codex 实际调用的模型名要填供应商真实支持的名称。DeepSeek 的话deepseek-chat是通用对话模型deepseek-reasoner是推理模型。model_provider是全局默认供应商的 ID和下面[model_providers.deepseek]的 deepseek 对应。base_url是供应商 API 的地址路径要写全。env_key告诉 Codex 从哪个环境变量读取密钥。设置好之后export DEEPSEEK_API_KEYsk-...wire_api指定协议类型。兼容 OpenAI Chat Completions 接口就填chat如果供应商支持 Responses 接口就改responses。配置完成后可以直接跑一条命令验证codex exec 用 Python 写一个读取 CSV 并输出 JSON 的小工具Codex 会加载 DeepSeek 模型在沙盒里完成整个任务。实测下来DeepSeek 的编码能力相当能打配合 Codex 的 Agent 循环确实可以用。4.3 一个本地多 Agent 任务拆解示例理论讲完给你一个可以直接抄作业的多 Agent 编排思路。核心思想主控 Agent 负责拆任务多个子 Agent 并行执行最后汇总结果。第一步写一个拆任务的主控模块把用户需求拆分并分配def breakdown(request): # 这里你可以用 Codex 自己来拆也可以用规则 return [ {type: code, desc: 实现 CSV 转 JSON 脚本, target: tools/}, {type: test, desc: 为脚本补单元测试, target: tests/}, ] def run_agent(subtask): prompt f{subtask[desc]}工作目录{subtask[target]} result subprocess.run( [codex, exec, prompt], capture_outputTrue, textTrue ) return result.stdout第二步并行跑多个子 Agentimport concurrent.futures with concurrent.futures.ThreadPoolExecutor(max_workers2) as pool: futures [pool.submit(run_agent, t) for t in tasks] results [f.result() for f in futures]第三步主控 Agent 汇总结果检查整体是否满足原始需求。这是很多人最容易漏的一步——子任务完成不等于总任务完成模块之间还可能互相不兼容。这个例子是同一个环境里的多进程编排。如果子 Agent 分布在异构系统上就用 A2A 的思路把每个子 Agent 注册成独立的服务暴露 Agent Card主控 Agent 通过 A2A 协议发任务、查状态、收结果。代码形态会不一样但核心思想不变拆任务、发任务、同步状态、汇总校验。4.4 常见报错排查速查表这部分是我真正在踩坑中整理的。Codex 用起来顺手但报错信息确实高级第一次见到能懵半小时。报错/现象原因处理方式auth token is unavailable认证令牌读不到重跑codex login或检查OPENAI_API_KEY环境变量和 Shell 是否重启model is not supported when using codex with a ChatGPT account用 ChatGPT 账号时套餐或账号类型限制了模型改用 API Key 方式或更换为账号支持的模型名ignoring 1 unrecognized configuration setting配置项拼写错误或版本过旧升级 Codex核对配置项名称与当前文档Windows 提示start the windows daemon from a non-elevated terminalWindows 沙盒后台服务要求非管理员终端用普通 PowerShell/CMD 启动不要用“以管理员身份运行”界面一直显示“更新 agent 沙盒”或“正在重新连接”沙盒环境同步或容器状态异常检查磁盘剩余空间、容器/守护服务是否正常必要时重启 Codex使用自定义模型时报连接或接口错误base URL、密钥或接口协议配置不对检查base_url地址与路径、env_key环境变量、wire_api类型是否匹配这里多说一句model is not supported这个报错它特别容易误导人。它不一定是你模型名写错了很多时候是你用的认证方式的模型权限不够。解决思路是先确认认证方式再确认模型名最后确认接口类型三步排查基本能定位。4.5 协作实战中的几个心得我把 Codex 和多 Agent 编排真正用在项目里之后有几个很实在的体会分享给你。第一个坑任务拆得太细。每个子 Agent 的启动开销、上下文加载、模型调用都是实打实的成本和延迟。把一个简单任务拆成十几个子 Agent最后发现时间翻了三倍质量没提升多少。我的经验是能从简的不要拆只有任务确实需要隔离、专业分工、并行时才值得拆。第二个坑子任务交付格式不统一。有三个子 Agent 在跑一个返回 Markdown一个返回 JSON一个直接改文件。汇总阶段你会疯掉。所以开始动手前一定要定义好每个子任务的交付物格式和验收标准最好写死在任务描述里Agent 是懒的你不说它就会按最省事的方式交差。第三个坑缺少全局校验。子 Agent 各自都完成了拼起来跑不通。多 Agent 是不是真正解决问题就看主控 Agent 能不能做好全局整合和验收。我强烈建议在主控 Agent 的指令里写一句“运行完整测试套件确认所有模块集成通过”。第四个心得从单 Agent 到多 Agent循序渐进。我见过太多人一上来就搭一堆 Agent 框架最后收不了场。正确姿势是先让一个 Agent 跑通整个流程再根据瓶颈去拆哪个环节慢就拆哪个哪个环节需要隔离就拆哪个哪个环节要对外协作再引 A2A。多 Agent 不是目的把问题解决得又快又稳才是。我在实际使用中最大的感受是多 Agent 协作真正难的从来不是“让 Agent 互相发消息”而是任务切分得像不像样、每个 Agent 的上下文管得好不好、结果校验做得严不严。Codex 已经把单个 Agent 的能力拉得很高A2A 又把跨系统协作变成了标准协议这两者组合起来确实是目前最值得投入的方向。最后再分享一个小技巧在项目里放一份AGENTS.md把你们团队的代码规范、构建命令、目录结构、注意事项都写进去。就这一个动作你手边的 Codex 表现会立刻提升一个档次。多 Agent 的每一层能力都是从一个靠谱的单 Agent 开始的。