多Agent协作这个词近一年被我身边做AI应用的朋友反复提起。很多人以为只要把几个Agent丢在一起给一个总目标它们就能像一支团队那样默契配合、自动拆解、彼此补位。但真正把Codex跑起来、调试过它的内部循环又去研究企业级Agent互联协议A2A之后我的体会完全不一样多Agent能不能跑出实际价值关键不在于Agent数量而在于几件常常被忽略的事——任务边界怎么划、上下文怎么共享、消息怎么定义、权限怎么管控。这篇文章就想从Codex的内部机制说起再延展到A2A协议在企业服务中的落地聊聊多Agent协作到底靠什么。如果你是AI应用开发者、企业技术架构师或者手头正好有一个“多个Agent需要配合干活”的需求这篇文章应该能帮你少走不少弯路。我不会堆概念也不会只讲PPT层面的架构而是从实际安装、配置、踩坑到协议层面的核心设计一层层拆开看。1. 多Agent协作的底层逻辑四根柱子1.1 第一根柱子角色与任务边界先说一个最反直觉的结论多Agent协作里最重要的不是Agent多聪明而是每个Agent的职责范围是否足够清晰。拿现实团队来类比一个开发团队要高效运转PM、后端、前端、测试必须知道自己的边界。如果每个人都想插手需求决策那项目大概率陷入无休无止的争论。Agent也是一样你让一个Agent既负责写代码又负责最终发布判断它往往会陷入“自己的代码必须是对的”这种自我确认偏差。我见过很多失败的多Agent项目根因就是角色重叠。两个Agent的能力圈高度重合接到同一个子任务时各自生成了不同方案然后互相“说服”最后产出了一个谁都不满意的折中结果。这不是模型能力不够是任务边界没有设计好。正确做法是给每个Agent一个明确的“职责声明”你是代码生成者你是安全审查者你是测试执行者。每个角色只对自己那一亩三分地负责不要越界。更关键的是任务边界要落到数据结构上。比如子任务描述里必须包含“输入文档路径”“期望输出格式”“验收标准”。没有这些Agent就会自由发挥而自由发挥在多Agent场景里等于灾难。1.2 第二根柱子上下文共享与状态同步第二个容易被低估的问题是上下文。单Agent模式下所有信息都在一个上下文窗口里模型自己能处理关联。但到了多Agent场景每个Agent的上下文是独立的它们彼此看不到对方的临时记忆。如果你不能让它们在同一个共享知识层上工作就会出现一个我常说的现象上下文漂移。上下文漂移怎么理解Agent A从一期需求文档里提炼了一个结论把它写进了自己的输出Agent B接收到这个输出时因为缺少原始文档的约束把它理解得夸张了一点等传到Agent C那里最初的结论已经被扭曲得面目全非。这个过程非常像我们以前玩过的传话游戏一句话经过五个人意思完全变了。要解决这个问题不能只靠“把完整历史全发给每个Agent”那在token成本和计算延迟上都不现实。更务实的方案是引入一个共享状态层比如一个结构化的黑板Blackboard或知识库所有Agent只往上面写经过校验的事实而不是依赖“对话记录”传递信息。每个Agent需要读数据时从共享层按需拉取而不是把整个会话历史塞进上下文。这样即使某一个Agent跑偏其他Agent也能从共享层找回原始依据。另一个实战细节是状态同步必须包含进度信息。比如任务执行到哪一步了、有哪些产物已经生成、有哪些请求还在等待。没有进度状态机的Agent协同就像几个人用同一个网盘却不知道谁在编辑哪个文件迟早撞车。1.3 第三根柱子消息协议与任务状态机有了角色和共享状态Agent之间怎么“说话”这是第三根柱子。很多人想当然地认为Agent之间通信就是“自然语言聊天”看起来高级实际执行起来最容易翻车。自然语言灵活但模糊同一个词汇在不同Agent面前可能产生完全不同的理解。所以在多Agent系统里消息协议必须尽量结构化。每个消息至少要包含发送方、接收方、消息类型、关联任务ID、载荷数据、时间戳。我甚至建议明确消息的“影响范围”这条消息是知会性、请求性还是命令性如果A告诉B“代码已经写完”B应该理解为“你可以开始测试了”而不是“你需要帮我改代码”。任务状态机同样必不可少。一个标准的任务生命周期最好包括待处理pending、执行中running、等待输入waiting、已完成completed、失败failed、已取消cancelled。每个Agent在汇报工作时不是简单说“我做完了”而是把任务状态从running改成completed并附上产物ID。这种设计让整体系统变得可预测、可追踪也方便人工随时介入。A2A协议之所以对企业有吸引力本质上就是把“消息协议”和“任务状态机”这两个被反复踩坑的环节标准化了。后面我会专门展开讲。1.4 第四根柱子信任与权限控制最后一根柱子是安全很多人到生产环境才想起来补课。多Agent协作不是把一堆自动化流程串起来而是把多个能自主决策的程序接在一起。如果权限设计不清晰一个被注入恶意指令的Agent有可能把整个流水线带崩。我比较推荐最小权限原则每个Agent只能访问它完成任务所需的最小资源集合。写代码的Agent不需要数据库生产环境权限发布Agent不需要读源码仓库里的密钥。权限模型要独立于Agent的组织逻辑你不能因为Agent A是“主Agent”就把所有权限给它。另外信任是分级的。同一个Agent在开发环境可以允许修改文件在预发环境只能执行只读操作。跨Agent调用时接收方必须验证发送方的身份和授权。A2A协议里对Agent Card做了能力声明其实也是在解决“我凭什么信任你”的问题——至少我们知道对方是做什么的、能做到什么程度。2. Codex内部机制拆解一个Agent如何工作2.1 Agent运行循环规划-工具-检查要理解多Agent最好先理解单个Agent的运转方式。Codex是我在这段时间用得最多的编码Agent之一它的内部运行逻辑非常典型。Codex的工作方式可以抽象成一个循环读取当前状态、形成规划、调用工具、观察结果、再形成下一步规划。比如你给它一个任务“修复某个测试用例失败”它不会一次性输出一大段代码然后结束而是会先查看失败日志判断可能原因修改对应文件再运行测试命令根据新的输出判断问题是否解决。这个循环的严谨程度决定了它能不能在复杂仓库里稳定干活。这里我想强调“规划”的重要性。Codex不是一股脑把所有操作塞给模型而是在每一步明确当前目标、预期结果和回退方案。这种结构化的循环其实是所有Agent产品都应该具备的基础能力。多Agent场景下每个个体Agent都必须能独立“规划-行动-观察”否则协作时根本没法预测它什么时候会交出什么结果。2.2 沙箱机制与工具调用边界Codex在实际执行时默认把文件系统、命令执行都包在沙箱里。沙箱并不是为了限制模型能力而是为了约束它可能造成的破坏。它只允许Agent在临时目录或指定项目目录内进行操作系统关键路径则被隔离在外。我曾在给Codex配置项目环境时看到它提示“更新Agent沙盒”意思是本次任务需要更大的文件访问权限需要我确认后才会扩大沙箱边界。这个设计对多Agent协作非常有启发每个Agent的能力边界不能只靠提示词约束必须在基础设施层面做隔离。否则一个Agent误删了共享资源整个系统都要遭殃。在企业的多Agent架构里每个Agent最好跑在独立容器或沙箱里只有通过明确接口才能访问外部资源。还要提醒一句沙箱不是万能的。它能限制文件系统和网络调用但挡不住提示词注入。如果Agent收到一段恶意文本它可能会在沙箱范围内做出符合攻击者意图的操作。所以在设计多Agent系统时必须假设Agent可能被“带偏”在它可能访问的敏感资源前方加重鉴权而不是全靠沙箱兜底。2.3 上下文窗口与记忆管理Codex在长时间任务里会面对一个很现实的约束上下文窗口是有限的。即便当前模型的上下文已经很大塞满一个大型代码库的全部文件也不现实。所以Codex需要主动管理记忆它不会把所有文件内容都读一遍而是按需读取相关文件把每一轮操作后的上下文控制在可处理范围内。这种按需记忆模式放在多Agent里更明显。如果一个Agent把整个共享对话历史全部传给协作对象那很快就会被Token成本击穿。我们在设计多Agent系统时需要区分“长期知识”和“短期任务状态”。长期知识放进向量库或知识图谱里按需检索短期状态则放进结构化的任务记录中。不要试图让模型用上下文硬记所有事情它是语言模型不是数据库。2.4 从Codex看多Agent协同的原型严格来说Codex在当前版本下仍然是一个单体Agent不是原生多Agent系统。但通过它处理复杂任务的方式可以反推出多Agent协同的雏形。我在用Codex完成一个跨多个文件的改造任务时发现它会天然地把任务拆成若干阶段先梳理调用链再修改核心接口接着更新调用方最后跑回归测试。每个阶段之间有明显的信息传递前一个阶段的结论会作为后一个阶段的输入。这种“阶段化推进”其实就是一个串行Agent流水线的逻辑。如果把“阶段”换成“独立Agent”每个Agent只负责其中一个阶段并显式定义输入输出格式那我们就得到了一个粗粒度的多Agent流水线。Codex给我的启发是Agent内部必须先有清晰的“阶段分界”外部协作才有可能稳定。如果单个Agent自己做事都是东一榔头西一棒槌那多Agent协作只会放大这种混乱。3. 把Codex拉起来安装、配置与常见坑3.1 安装Codex CLIWindows与macOS实操代码层面的道理讲完了我们来点能直接上手的内容。先把Codex跑起来你才能真正感受到一个Agent内部循环的“手感”。Codex的CLI现在是通过npm发布的安装命令很简单npm install -g openai/codex。macOS和Linux环境一般一路顺畅Windows上需要注意一个细节如果你在某个版本遇到了“start the windows daemon from a non-elevated terminal”的报错那基本是因为你用了管理员权限的终端启动。Codex的Windows守护进程比较挑它要求从非提升权限的终端启动否则共享目录和文件监听会有权限冲突。我第一次遇到时一脸茫然后来干脆新建了一个普通权限的PowerShell窗口问题立刻消失。安装完以后首次运行会让走一遍登录流程填入认证信息有时候会要求手机号验证这个按提示走就行。如果碰到登录不上优先检查你的网络环境是否能正常访问相关服务以及账号所在组织是否正确。3.2 通过CC Switch接入DeepSeek等模型Codex默认绑的是OpenAI原厂模型。但很多团队为了成本和合规考虑会想把它切换到国内模型比如DeepSeek。这里我用得比较顺的工具是CC Switch它本质上是一个API端点管理工具可以帮你在不同模型供应商之间切换。实际操作不复杂在CC Switch里填好DeepSeek的API地址和密钥创建一个新配置然后把Codex对应的配置指向这个端点。这样Codex发出去的请求会走到DeepSeek的模型上。需要注意Codex对模型的指令遵循能力有一定要求你至少要选择推理能力够用的模型普通小模型跑起来容易出现“规划正确但执行变形”的情况。CC Switch还有一种“本地转发模式”会在你本机起一个端口来转发请求。这个模式偶尔会报错常见的是端点处理失败或者返回异常。我的排查顺序是先看目标API地址是否填错再看本地端口是不是被占用最后确认请求头里的鉴权信息有没有被CC Switch改坏。绝大多数时候都是配置细节问题换一个端口或者重建配置就能恢复。3.3 必踩的坑登录、组织设置、沙盒更新用Codex这段时间我积累了几个高频坑列出来给大家参考。第一个是“无法加载组织设置”。这个多半和账号权限有关不是网络问题。如果你是个人账号去组织设置页面确认一下账号归属如果是企业账号需要管理员在后台把你加到对应项目里。第二个是模型兼容性。我确实遇到过“the gpt-5.6-sol model is not supported when using Codex with a ChatGPT account”这样的报错。这说明某些模型只能在API账号下用ChatGPT订阅账号并不包含对应模型权限。解决办法也不难要么换支持范围内模型要么用API账号接入。第三个就是沙盒更新提示。Codex在执行需要更高权限的任务时会要求你确认并更新沙盒配置比如允许写入某个目录、允许执行某条命令。不要无脑拒绝也不要无脑允许。正确做法是看清楚它要访问什么资源再做最小授权。这和你给多Agent系统划权限是同一个思路。3.4 本地转发失败与配置排查CC Switch的本地转发模式虽然方便但也是问题重灾区。遇到转发失败时我建议先做这几步首先检查目标模型服务商的API是否连通直接curl一下健康检查端点排除服务商侧故障。其次确认CC Switch的配置文件里base URL有没有包含多余的空格或斜杠这类问题最容易让请求路径变成异常拼接。再次看Codex的日志里返回了什么样的错误体如果是401那就是密钥问题如果是404那多半是路径配置错如果是超时那就需要看网络链路和超时时间设置。还有一种情况是“Codex is ignoring 1 unrecognized configuration setting”这个一般是因为你走了旧版本Codex配置项新版本已经不认了。清理掉过期配置项就行不影响主功能。4. 当Agent开始协作多Agent编排模式4.1 编排者-执行者模式把一个个Agent比作能独立干活的“能人”之后下一个问题是谁来分配活目前落地效果最稳的是“编排者-执行者”模式。在这个模式里有一个主Agent专门负责理解用户目标、拆解子任务、分发任务、收集结果。执行Agent则只负责自己那一块完成后把产出提交给编排者。这种模式的好处是控制点集中出了问题能很快定位到是哪个子任务出的岔子。坏处是编排者容易成为瓶颈如果所有消息都要经过它整体延迟会很高。我在实际项目里比较推荐“动态指派”编排者不要事无巨细地管而是把任务发给一个“执行组”由组里的Agent根据自身能力认领再向编排者汇报。这样既保留了集中协调的优点又减轻了单点负担。当然这需要Agent具备一定的自我选择能力不是所有模型都扛得住你得先测一下。4.2 流水线模式与结果汇合另一种常见的模式是流水线。Agent A的输出直接作为Agent B的输入。这种模式非常适合阶段性任务比如“数据清洗-数据分析-报告生成”。每一步都有一份明确产物下一步只关心上一份产物不关心上游的完整历史。流水线的优点是可解释性强每一步的输入输出都清晰可见出了问题可以直接重跑当前阶段。缺点也很明显如果前面的Agent产出了错误格式后面所有Agent都会被带偏。所以我通常会在每个阶段之间加一个“格式校验器”不一定要调用大模型用一个普通Rule-based校验脚本就能挡住90%的格式问题。还有一种情况需要多个Agent并行执行然后汇总结果。这种模式像“各路专家会诊”代码安全审查Agent、性能分析Agent、可读性评估Agent同时看一段代码最后有一个整合Agent把意见合并成一份报告。并行模式对资源共享要求比较高如果几个Agent同时操作同一个仓库需要注意锁机制避免互相覆盖文件。4.3 多Agent失败场景死锁、幻觉传播、上下文漂移写多Agent系统不要把精力都放在“怎么让它工作”上而要认真分析“它会怎么失败”。第一个典型失败是死锁。Agent A在等Agent B的输出Agent B又在等Agent A的确认。两个Agent都不会主动终止资源被白白占住。解决方法是给所有跨Agent调用设超时和超时后的回退动作要么跳过要么用默认值要么上报人工。第二个失败是幻觉传播。一个Agent在信息不足时“脑补”了一个结论另一个Agent没能力校验把这个结论当真继续往下传。等传到最终结果那里事实基础已经没了。要对抗幻觉传播关键还是我在第一根柱子里说的共享状态层所有关键结论都要能追溯到原始证据没有证据的结论默认标记为“待验证”。第三个失败是上下文漂移。这个问题在长链路协作里特别明显。每个Agent都有自己的上下文窗口模型在处理时可能过度关注最新信息忽略了早期约束。建议在任务接口里把不可变更的约束项单独拎出来每一轮交互都作为固定Prompt前缀传给Agent而不是混在长对话历史里。4.4 一个多Agent代码审查实例说一个我实际跑过的场景。任务是对一个微服务进行上线前代码审查。我把流程拆成了四个角色代码结构Agent、安全Agent、测试Agent、整合报告Agent。代码结构Agent负责梳理模块依赖、扫描循环引用和死代码。安全Agent关注是否有注入风险、硬编码密钥、不安全的依赖版本。测试Agent根据PR里的改动范围生成执行建议并且尝试跑最小的冒烟测试。这四个Agent共享同一个Git仓库但通过不同的工作目录隔离操作避免写冲突。最后整合报告Agent从共享状态层读取三份结论合并成一份带优先级的上线建议。在这个流程里我发现安全Agent输出的一个高风险项其实是代码结构Agent没更新依赖图导致的误报。如果没有共享状态层这个误报会一路溜进最终报告。后来我在共享状态里加了一条“同一模块的分析结果必须互相引用版本快照”这个误报立刻就消失了。5. A2A协议企业级Agent互操作从标准开始5.1 为什么企业不能只用供应商私有协议企业内部一旦开始规模化使用Agent很快会遇到“鸡同鸭讲”的问题。你的发票处理Agent是供应商A的你的客服答疑Agent是供应商B的你的内部知识库Agent是自研的。它们各自能用但一旦需要协同各家有各家的消息格式和API风格集成成本瞬间爆炸。这就是A2A协议出现的背景。A2A是Google在2025年推动的Agent互操作协议全称是Agent2Agent。它的目标是让不同厂商、不同技术栈的Agent能通过一套通用语言发现彼此、调用彼此、完成跨Agent协作。说白了这是给Agent世界定的统一“普通话”。企业采购决策里供应商锁定是很大的风险。如果你所有Agent都依赖同一家厂商的私有协议那今后的每一次能力升级都绕不开这家厂商。A2A这种开放标准不一定完美但它给了企业一个“去锁”的抓手至少多Agent协作不会被任何一家商业供应商卡住脖子。5.2 A2A核心概念Agent Card、Task、MessageA2A协议里有几个核心概念值得先搞明白。第一个是Agent Card相当于Agent的“个人名片”。它用JSON描述这个Agent是干什么的、支持哪些技能、接受什么输入、产出什么格式、如何调用。任何协作方拿到Agent Card就能判断这个Agent适不适合当前任务以及该用什么样的参数去调用。第二个是Task。A2A把一次协作目标建模为一个Task而不是简单的一问一答。一个Task有完整的生命周期提交、执行中、需要更多输入、已完成、已失败、已取消。这种任务状态机和我在第一根柱子里讲的状态同步完全是一回事只是被协议标准化了。第三个是Message它是Agent之间交换数据的单位。Message会绑定到某个Task里面可以带文本内容也可以带文件引用或结构化Artifact。Artifact指的是Agent产出的最终作品比如一份报告、一段代码补丁、一张图表。有了Artifact概念Agent协作的结果被显式物化而不是淹没在聊天记录里。5.3 A2A与MCP的分工现在做AI应用的人大概率听过MCP。MCP解决的是Agent连接外部工具和数据源的问题一个模型通过MCP访问数据库、文件系统、第三方API。它管的是“Agent与世界”的连接。A2A管的则是“Agent与Agent”的连接。它不关心一个Agent内部是用什么模型、怎么调用工具的它只关心Agent对外暴露什么样的协作接口。你可以这样理解MCP是给Agent接好鼠标键盘显示器A2A是给Agent之间拉好网线。两者并不冲突反而互补。一个基于A2A的企业Agent网络里任何一个Agent都可以通过MCP去对接底层服务同时通过A2A去响应其他Agent的协作请求。比如一个数据分析Agent通过MCP连接数据仓库又通过A2A把分析结果推送给报告生成Agent。设计时把这两层分开系统会清晰很多。顺便提一句不要迷信“用了A2A就能解决所有Agent协作问题”。协议只规定了通信规则Agent自身的可靠性、推理质量、任务边界设计仍然要你自己搞定。协议是高速公路路况好不好还得看车。5.4 企业服务中落地A2A的最小架构如果要在企业内部落地A2A我的建议是从最小骨架开始不要一上来就上复杂平台。第一步建一个Agent注册中心。所有Agent启动时把自己的Agent Card注册到这里并定期上报健康状态。注册中心可以是一个简单的数据库加HTTP接口甚至暂时用一个共享的JSON文件也可以。第二步确定Agent之间的通信链路。最简单的是HTTP回调A2A的标准实现也是走HTTP。每个Agent提供一个端点接收其他Agent发来的Task和Message请求并返回状态。企业内网里做服务发现和鉴权用现有的服务网格或者API网关就能实现。第三步定义你的任务流程。用一张表格把常见的跨Agent协作场景列出来什么角色发起点什么任务、任务传给谁、中间需要什么校验、超时怎么办。不需要一开始就实现所有场景挑两个高频场景跑通把日志和指标收集起来再逐步扩展。第四步安全与审计。所有Agent之间的消息都经过统一网关网关负责身份认证、权限校验和消息审计。这样一旦出了问题能回溯是哪个Agent在什么时间向谁提交了什么请求。这套最小架构不复杂但已经覆盖了Agent Card、Task、Message、安全审计这些核心要素。我见过不少团队一开始就想做“完美平台”结果半年过去连一个Agent都没接进来。先跑通端到端再封装平台是更现实的路子。6. 写在最后一个从业者的体会真把Codex跑起来、研究完A2A协议之后我对“多Agent协作”的最大感受是它从来不是一个纯技术问题而是一个组织问题、工程问题、治理问题。我自己在实际项目中踩过最深的坑是把所有Agent看得太“平”。觉得只要它们之间能传消息协作就会自然发生。后来发现一个Agent如果不知道自己该干什么、该产出什么、在什么条件下该退出那再好的协议也救不了它。A2A把消息格式和任务状态机定得很清楚但这只是地板不是天花板。天花板仍然取决于每个Agent的内在质量以及你对任务模型的设计。还有一个很朴素的建议做多Agent系统永远保留人工介入的安全阀。即便是号称“全自动”的流程也要在关键节点留出Confirm入口。这不仅是为了安全也是为了收集人类反馈来迭代整个流程。我试过完全自动的多Agent流水线结果一次误报被放大成三次全链路修复白白浪费了一整天的计算资源。后来我学乖了高风险操作一律先暂停等人确认再继续。多Agent协作的未来一定不是造一堆更聪明的Agent而是建立更清晰的边界、更规范的语言、更可控的流程。工具会变模型会变但“角色-上下文-协议-信任”这四个词会一直是这门手艺真正的骨架。