如果用一个词概括过去一年AI工程圈最明显的变化我会选多Agent协作。OpenAI开源的Codex这类编码智能体已经能在一个终端里自主完成从读代码、改代码到跑测试的完整流程而Google牵头推进的A2A协议又在尝试把无数个这样的Agent变成企业内部可发现、可调用、可协作的数字同事。这两件事看似不在一层但本质上回答的是同一个问题Agent与Agent之间到底靠什么协同先说我自己的一段实测经历。上个月我丢给Codex一个任务把项目里的下单接口拆成独立模块并且补上单元测试。它没有一次性给出整个改造方案而是像一位特别较真的同事——读文件、改代码、跑测试、根据失败信息再回头修几个来回之后才告诉我任务结束。这个过程的背后是一套被反复验证的任务循环机制。而一旦把这套机制放到企业内部你就得面对另一个更棘手的问题一个Agent可以靠循环自己搞定一件事那十个Agent怎么搞定十件事它们之间靠API硬拼靠人写胶水代码还是靠一套标准协议这篇文章我想把这几年攒下的Agent工程化经验摊开讲。你会看到Codex内部到底怎么运转、为什么单Agent在企业场景里一定会碰到天花板、A2A协议究竟解决了什么、以及一个可以照抄的落地参考架构。文末还整理了我实际踩过的Codex配置和排错记录安装、登录、端点切换这些坑基本都能对号入座。1. Codex 内部的工作循环从一次生成到多次行动1.1 它比我预想的更像一个实习生很多人第一次用Codex会觉得它像个高级自动补全给一段需求它呼啦一下吐出一大堆代码。但只要你把任务复杂度拉上去就会发现它根本不是靠一次生成完成工作的而是靠反复执行一个循环先理解现状再决定下一步执行一个动作观察结果然后继续。我让Codex拆订单模块时它的行为路径大致是这样的先列出项目目录找到下单接口所在的文件读取文件内容理解现有逻辑设计模块边界生成一个重构方案用补丁形式修改代码而不是整文件重写跑测试发现两个用例失败根据失败堆栈定位问题修复再跑全部通过后向我汇报变更摘要整个过程十几个来回中间没有任何一次是一次性输出最终结果。这其实是Agent类工具和传统Copilot类工具最本质的区别Copilot补全你的下一个tokenAgent补全你的整个任务。如果你用过Cursor的Composer或者GitHub Copilot Workspace会发现底层逻辑大同小异。但Codex CLI胜在把整个循环的透明度做得很好每一步在做什么、改了哪个文件、为什么这么改都摆在台面上。作为工程师你能看到它的推理过程而不是面对一个黑盒吐出一坨代码。1.2 任务循环的四步推理、行动、观察、再推理Codex的Agent Loop可以拆成四个阶段推理Reasoning基于当前上下文和任务目标模型决定下一步该做什么。这一阶段是隐式的你只能从它的输出里间接看到。行动Action调用工具。Codex的工具集包括读写文件、执行shell命令、通过apply_patch修改代码、调用MCP外部工具等。观察Observation读取工具返回结果。比如shell命令的输出、文件读取的内容、测试的失败信息。再推理Next Reasoning把观察结果纳入上下文决定下一步动作。这个循环最狠的地方在于工具使用是和模型能力深度绑定的。Codex不是能调用工具而是工具就是它感知世界的器官。它看不到屏幕但可以通过读取文件看到代码它没法手动操作但可以通过执行命令触达系统。所以它写出的代码不是凭空编的而是基于真实代码库现状生成的。这里有一个非常关键的设计apply_patch。Codex修改代码时生成的不是整个文件的新版本而是一个类似git diff的补丁只包含增删的那几行。好处有三层改动量小、每步可审计、随时能回退。我当时看着它一步步应用补丁脑子里冒出的想法是这才是Agent落地的正确姿势——不是让它重写世界而是让它像人类工程师一样做最小必要修改。沙盒机制也值得一提。在macOS和Linux上Codex默认跑在只读沙盒里写文件、执行有风险的系统命令都需要审批。这种设计让放权变得可控你可以让它全自动干活但默认情况下它不能乱动你的环境。想彻底放飞可以用--dangerously-bypass-approvals-and-sandbox这个参数但名字里就带着dangerous我反正是只在一次性容器里才这么干。1.3 为什么 Codex 能接 DeepSeek 这类第三方模型早先的Codex是个封闭云端服务模型和工具链绑死。但CLI版本开源之后情况变了Codex把模型访问抽象成了provider层只要服务商提供OpenAI兼容接口你就能把底层模型换掉。这就是Codex接入DeepSeek能成为搜索热词的原因——Codex的核心价值是那个任务循环和工具链模型反倒成了可替换的零件。我自己实测过接入DeepSeek的方案配置文件~/.codex/config.toml里加一段model deepseek-reasoner model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat配置前先导出环境变量export DEEPSEEK_API_KEYsk-xxxxx几点经验wire_api字段决定Codex使用哪种协议和服务商通信。DeepSeek的OpenAI兼容端点走的是/chat/completions所以设成chat。如果服务商支持/responses协议可以设成responses。model名称一定要和服务商的模型列表对齐写错的话启动就报错后面第五章会细说。换模型后记忆和上下文管理能力会变化长任务的表现可能和用官方模型时不一样。跨模型切换不是零成本。提示config.toml里出现拼写错误时Codex启动会提示类似ignoring unrecognized configuration setting但它不会拒绝启动只会忽略那行配置。如果你发现某个配置项没生效第一反应应该是回去检查key名有没有拼错。2. 单 Agent 的瓶颈与多 Agent 协作的典型分工2.1 一个 Agent 再强也有三堵墙单Agent在单个任务上可以很强但放到复杂工程里它一定会撞上三堵墙。第一堵墙是上下文窗口。Agent的上下文是Token计费的一个Agent既要当大脑又要当笔记本任务一长几十轮交互下来它很容易忘掉前面的约定。我试过让Codex一口气完成重写订单模块优化数据库索引给团队写接口文档三个连续任务。前两个还好到第三个时它就开始出现幻觉引用了不存在的函数。不是模型变笨了是上下文塞太满了早期信息被挤出去了。第二堵墙是单一视角。一个Agent只有一套系统提示和一组目标你很难让它同时站在需求方实现方质检方三个立场上看问题。你可以在提示词里让它先写代码再自己review但效果通常不如一个专门写代码的Agent加一个专门挑刺的Agent。角色混着干最后往往两头都不精。第三堵墙是单点故障。Agent是有自主性的它的行为带有概率性。一个长任务链条上只要中间某一步方向性判断错了后面所有努力都会白费。单Agent模式下没有第二双眼睛帮它纠偏错了就是错了。2.2 三种主流的多 Agent 协作模式我不是说单Agent不能用而是说在复杂项目里多Agent的容错和分工优势会逐渐显现。我实际用下来协作模式大致有三类。协作模式一句话描述典型场景主从调度一个主Agent拆任务、分派、汇总大型重构、PRD到方案到代码到测试的串联流程流水线上一个Agent的输出是下一个Agent的输入数据清洗、特征工程、模型训练、评测报告的逐级处理协商协作多个Agent就同一产出物互相评论、修改代码评审、方案辩论、安全扫描主从调度是我最常用的。一个Orchestrator主Agent负责理解总目标拆成子任务分发给多个Worker子Agent收集结果合并产出。这个模式下主Agent不需要很懂具体技术它更像项目经理Worker们则各自专注自己的领域。好处是上下文天然隔离每个Worker只需要关心自己的那一段不背全局包袱。流水线模式适合那些流程固定的场景。每个Agent只做一件事输出给下一个每一环上下文都干干净净。代价是链路变长任意一环挂了就需要重试或重启流水线。协商协作是我处理高风险改动时用的方式。让一个Agent写实现另一个Agent专门从找茬的角度做评审然后把问题清单丢回给实现Agent去改。这种红蓝对抗比单Agent自说自话靠谱得多。2.3 什么任务才值得上多 Agent多Agent不是银弹它引入了一个很现实的代价协调成本。每次Agent间通信都要消耗Token和时间调度不当比单Agent更慢更贵。我自己判断要不要上多Agent就看三条任务能不能并行如果任务是一个完整的、依赖度极高的链路比如从零写一个模块单Agent反而更合适如果是对十个文件做同类修改多Agent并行绝对香。是不是需要不同角色视角有设计-实现-测试-评审这种多角色诉求的任务上多Agent会明显更稳。上下文是否已经扛不住了任务长到单Agent上下文即将爆掉拆泳道就是唯一解。提示我踩过的最大教训是——别在单Agent都没跑通的流程上强行上多Agent。多Agent的前提是你已经能用单Agent把标准操作流程跑通然后再考虑通过编排获得并行和容错能力。连基本循环都跑不稳编排只会放大混乱。3. A2A 协议到底做了什么Agent 网络的握手与传话3.1 每个 Agent 都是孤岛A2A 是那个拆墙的协议多Agent协作如果只停留在我在代码里硬编码调用另一个Agent的API这种层面走不远。企业内部今天有一个客服Agent明天有一个工单Agent后天再来一个BI分析Agent每个Agent都有自己的接口风格、鉴权方式、消息格式。让它们互相调用就要给每对组合写胶水代码N个Agent就需要N(N-1)/2条集成链路工程师会疯掉的。所以行业里需要一个公共的语言。Google在2025年4月推出了Agent2Agent协议也就是A2A之后捐给Linux基金会微软、Salesforce这些厂商都在跟进。A2A的定位和MCP正好互补MCP解决的是Agent怎么连工具A2A解决的是Agent怎么连Agent。两者不是替代关系而是上下层关系——Agent通过MCP使用工具通过A2A调动别的Agent干活。你可以把A2A想成Agent界的HTTP。HTTP出现之前每个系统都有自己的RPC、有自己的报文格式互联全靠点对点的定制。HTTP把请求-响应这个范式统一了于是Web时代才真正开始。A2A想做的事情就是给Agent之间定一个统一的应用层协议让大家不再为集成而写胶水。3.2 三个核心组件Agent Card、任务生命周期、消息协议A2A协议里有三个我印象最深的核心设计。第一个是Agent Card。每个Agent对外开放时会发布一份JSON格式的名片内容包括这个Agent是干什么的、入口URL在哪、需要什么样的鉴权、支持哪些能力、希望以什么方式被调用。企业内部可以搞一个Agent目录服务新Agent上线时去注册其他Agent要找人帮忙时就查目录、看名片、发起调用。这个设计解决的核心痛点就是能力发现以前想知道一个服务能不能干某件事要翻文档、问人、看源码现在Agent自己就能在目录里找到答案。第二个是任务生命周期。A2A不把Agent间的交互简单理解成一次请求-响应而是把每次协作建模成一个有状态的任务。任务会经历提交、执行、等待补充信息、完成、失败、取消这些状态。任务可以被查询进度、可以被取消、可以推送状态更新支持异步执行和长时间运行。这个设计解决的核心痛点是长任务和断点续传——两个Agent协作如果一方中途挂了另一方可以通过查询任务状态恢复协作而不是从头再来。第三个是消息协议。A2A基于JSON-RPC 2.0 over HTTP定义了标准的Agent间消息格式包括普通消息、任务状态更新、任务产物更新等并且支持用SSE做流式推送。选JSON-RPC而不是更花哨的协议我理解是为了最大兼容性——它的格式足够简单任何语言都能轻松实现企业接入成本最低。对企业来说A2A带来的核心变化是从点对点集成变成注册-发现-调用。新增一个Agent时不需要和老Agent们一一联调只需要按协议暴露Agent Card目录服务一注册整个网络里的Agent都能发现并调用它。3.3 一个常见的 A2A 落地画面为了说清楚这个协议在企业里长什么样我描述一个比较典型的画面。假设一家电商公司有三个系统客服系统、CRM、工单系统。它们各自被封装成一个Agent都启用了A2A协议并且在一套内部Agent目录里登记了Agent Card。现在来了一个客诉我买的东西两周没发货我要投诉顺便查一下我的积分。一个客服主管Agent收到这个请求后先从Agent目录查询发现三个Agent的能力客服Agent能接待用户、CRM Agent能查订单和积分、工单Agent能创建投诉工单。于是它把任务拆成三个子任务客服Agent负责跟用户交互收集诉求CRM Agent查询订单状态和积分余额工单Agent创建内部投诉工单。每个子任务在各自的Agent里跑状态由A2A任务生命周期统一管理。客服主管Agent等所有子任务结束后汇总成一句完整的答复给用户。整个过程里没有一个Agent需要知道另一个Agent的代码细节它们只通过Agent Card发现能力、通过A2A消息协议协作。这就是A2A想实现的企业Agent网络。4. 企业里落地从 Codex 终端到 A2A Agent 网络的参考架构4.1 三层架构执行、协作、平台分开聊完理论和协议说点能落地的。我现在的实践是把企业内部Agent体系拆成三层每层各司其职不要把多个职责混在一个组件里。执行层跑在终端或CI里干具体活。典型代表就是Codex这类编码Agent或者在服务器上跑的自动化运维Agent。它们的特点是任务明确、动作具体。协作层跑在服务器上干编排调度。负责Agent发现、任务路由、状态同步、鉴权校验。这是A2A网关该待的位置。平台层企业内部现有的系统和数据服务比如CRM、ERP、工单系统、知识库。它们不感知Agent的存在只是被包装成可调用的服务。这个分法的核心逻辑是执行层管能不能干协作层管找谁干、怎么干、干得合不合规平台层管干什么。三层分开之后每一层的演进都是独立的。今天你可以用Codex做执行层明天换成其他Agent工具只要仍然通过A2A网关对外暴露上层几乎无感。4.2 按这四个步骤把 Agent 网络搭起来如果从零开始搭一套我会建议按下面四步来每一步都有它存在的理由。第一步把内部系统的能力封装成可调用服务。别一上来就让Agent直接连数据库太危险。先给每个系统定义一组粗粒度的API再在API外面包一层MCP Server如果服务商兼容或者直接暴露REST接口。这里的核心原则是Agent不访问原始数据只访问服务化能力。比如查订单是服务跑一条SQL查订单表就不应该是Agent能做的事。第二步给每个Agent生成Agent Card并注册到统一目录。这份JSON名片里要写明Agent名称、功能描述、入口URL、鉴权方式、支持的调用模式。目录服务可以很轻量一个内部Web服务加一张数据库表就够。这步解决的是别人怎么找到我。第三步部署A2A网关做统一入口。网关负责接收Agent发来的任务请求解析Agent Card路由到正确的Agent同步任务状态统一处理鉴权和审计。这个位置不要用业务代码去实现直接用现成的A2A参考实现或者企业内部网关改造都行。第四步把Codex这类工具接入协作网络。Codex本身是单机Agent可以通过MCP协议暴露自己的技能也可以通过A2A网关把自己注册成编码执行类Agent。这样团队在协作平台上发起一个编码任务A2A网关会把任务路由到CodexCodex跑完再把结果作为任务产物回报给网关。4.3 比技术更先要定的三件事权限、成本、审计在多层Agent网络里技术架构反而是相对容易的那部分真正难的是治理。我有三条特别想强调的经验。**权限模型必须和人对齐。**Agent的令牌不能是全库通吃必须遵循最小权限原则。每个Agent能访问哪些服务、哪些数据要先和对应的业务负责人确认。更关键的是高危操作要保留人工审批环节Agent可以发起操作请求但真正执行前要过审批。我在企业里见过不少Agent被无限制授权导致的事故这个闸门必须留。**成本要设配额。**多Agent并发调用模型Token消耗是线性甚至指数级涨的。我给每个Agent设了月度Token预算超过配额就降级为人工处理。成本观测也要做到任务级别一个任务花了多少钱必须可查否则月底账单会让你怀疑人生。**一切动作留痕。**A2A任务ID要贯穿全链路所有Agent的决策记录、工具调用、产物变更都要进日志。这不是为了追责而是为了复盘——Agent错了不可怕可怕的是不知道为什么错。提示执行层的Agent比如Codex在企业内网环境里跑的时候强烈建议用审批模式只对低风险操作放行写文件、执行命令这类高风险动作全部走审批。全自动模式看着爽出事的成本会远高于省下的那点人力。5. Codex 环境配置和真实排错记录5.1 安装、登录类问题速查热词里关于Codex安装和登录的问题特别多这些问题我基本都撞过。整理了一个速查表都是亲测有效的解法。现象常见原因快速解法安装卡死、安装包下载慢网络拉取安装包不稳定用包管理器安装如Homebrew、winget不要手动下载安装包桌面版一直正在重新连接登录态过期或本地daemon进程僵死先重新登录再杀掉全部Codex进程重启提示auth token is unavailable没有登录或环境变量没注入执行codex login或者在环境里配好API Key无法加载组织设置登录态和本地缓存不一致codex logout后重新登录必要时清掉本地登录缓存Windows桌面版设置未完成本地daemon未就绪或组件缺失确认以普通用户身份启动更新组件后重试提示windows daemon需要non-elevated terminal用管理员权限启动了应用换成普通用户身份的终端重新打开除了这些还有一个安全提醒目前官方桌面版界面只有英文网上有不少第三方汉化包虽然能覆盖部分热词需求但我不建议装来路不明的补丁——它们可能改动本地文件或注入脚本。中文任务输入本身没有障碍等官方多语言支持比冒险替换文件靠谱。5.2 端点切换与模型接入的报错三板斧定位法接入第三方模型或者切换端点时报错信息往往让人一头雾水。我自己见过一个高频报错大概长这样用端点切换工具把Codex指到自建网关后请求直接失败提示failed while handling codex endpoint /responses。表面看是端点问题实际排查下来原因五花八门。后来我总结了一套三板斧定位法遇到这类报错按顺序查看端点地址Codex请求会打到base_url /responses路径上。先确认base_url写对没有——少了版本前缀、多了一个尾部斜杠、把http写成了https都是最常见的翻车点。用curl直接请求一次端点接口能通就说明网络和地址没问题。看鉴权信息检查环境变量名是否和config.toml里的env_key一致API Key是否正确注入。很多莫名失败最后都发现是Key没导出或者Key绑定的环境不对。看模型名称模型名必须和服务商列表严格一致。热词里the gpt-5.6-sol model is not supported这类报错就是这么来的——配置了一个不存在的模型名Codex发出请求后服务商直接拒绝。尤其当你用ChatGPT账号登录却又在config里写了非官方模型名时最容易触发这类错误。这个顺序其实是有讲究的先排除外部因素再排查身份问题最后才怀疑模型本身的可用性。5.3 沙盒和本地 daemon 的坑Codex的安全机制和本地daemon也贡献了不少报错。我说两个最典型的。一个是沙盒导致无法执行命令。在某些系统环境下Codex的daemon组件没就绪你发消息时它会一直卡在更新Agent沙盒的状态无法继续。遇到这个先确认沙盒组件版本再重启应用。实在不行检查一下是不是有旧的Codex进程残留导致新进程起不来。另一个是Windows端常见的daemon报错提示要从非提权终端启动Windows daemon。原因是Codex需要在本地起一个后台服务来跟前端通信如果用管理员身份运行终端或应用UAC环境和本地服务监听策略会干扰daemon正常启动。解法很简单关掉管理员权限用普通用户身份重新打开终端再启动。提示如果系统同时存在老版本和新版本Codex的进程很容易出现旧daemon占着端口、新进程起不来的问题。排错时先用任务管理器把所有Codex相关进程清掉再重新启动能省掉一半的无谓排查。5.4 一个完整的一直正在重新连接排查链路最后分享一次完整的排错经历你可以直接拿去复用。前阵子Codex桌面版一直显示正在重新连接怎么都发不出消息。当时我的第一反应是重装但想了想还是按部就班排查。第一步确认CLI是否正常敲codex --version没问题第二步检查登录态执行codex whoami发现是已登录状态第三步看本地进程打开任务管理器赫然发现好几个残留的Codex daemon进程躺在那里第四步把这些进程全部结束第五步重新打开桌面版问题直接消失。整个过程没有动配置文件没有重装没有清空目录。事后复盘根因就是旧daemon僵死导致新进程无法接管本地服务端口。这个坑在各类工具里出现的频率极高所以后来我养成了习惯遇到连接异常先杀进程再重启而不是一上来就卸载重装。经验就是逐层排查的思路比任何操作都值钱。先确认登录态再看本地进程然后看版本差异和日志最后才考虑重装。这串顺序能应对Codex绝大多数打不开连不上转圈类问题。回过头看多Agent协作的关键从来不是把更多的模型实例并排放在一起。Codex教给我们的是一个Agent需要完整的感知-决策-行动-校验闭环A2A想解决的是当一个组织里真的有几十个这样的闭环时它们如何发现彼此、传递状态、交接任务。我现在的做法是能用协议解决的绝不用胶水代码能单Agent完成的绝不硬上编排。在给项目引入多Agent之前先问一句——这个任务里的协作到底发生在什么层级是同一个上下文里的分步推进还是不同服务之间的任务交接。想清楚这一层方案就不会差太多。最后再分享一个小技巧也是我踩过坑之后养成的习惯在项目根目录放一个AGENTS.md把项目约定、常用命令、目录结构、编码规范都写进去Codex启动时会读取它作为项目级上下文。多Agent协作时这个文件就是所有Agent共享的项目共识。我观察过大多数Agent协作的混乱根源都是上下文不一致——每个Agent拿到的是不同版本的项目理解。一个AGENTS.md能解决一大半这种问题。