做企业级Agent协同系统之前我一直以为最难的会是模型选型和推理优化这类“硬核”问题真正动手之后才发现最扎心的是Agent之间怎么说话、出了问题到底该找谁。A2A协议Agent2Agent Protocol解决的是前半截人机责任链解决的是后半截。这篇文章不聊空泛概念直接讲我落地这类系统的完整思路从A2A协议的Agent Card、消息对象、任务状态机到怎么把人工审批嵌进Agent工作流里再到注册中心、路由编排、超时熔断这些藏在真实业务里的细节。适合正在设计多Agent平台的架构师也适合准备把Agent接进核心业务流程的技术负责人。1. 企业级Agent协同为什么协议层不能自己拍脑袋1.1 多个Agent不等于协同系统很多团队做多Agent第一步就是各自定义一套通信方式结果项目跑两三个月就会发现变成了“方言大会”。A调B用的是HTTP加自定义JSONB调C走的是消息队列C调D直接塞了个内部SDK每个Agent之间都靠“人情文档”维系改一个字段要拉一个会。我见过一个真实案例三个Agent组成的“协同系统”联调整整花了一个季度。问题根本不是模型回答不好而是A发给B的消息B根本解析不出来因为两边的字段名都叫orderId但一个传字符串一个传对象。更麻烦的是任务执行到一半下游Agent挂了上游Agent还在傻等也没有状态概念全靠互相ping。这种集成方式本质上还停留在“把多个服务用脚本粘起来”的阶段不是协同。企业级协同的第一件事就是把通信协议定死让每个Agent都按照同一套规则声明自己会什么、怎么调用、任务执行到哪一步了。这就是A2A协议出现的意义。它解决的是Agent和Agent之间的“握手”问题让不同团队、甚至不同厂商开发的Agent能在同一个体系里互相发现、互相协作。1.2 A2A协议为什么值得押注A2AAgent2Agent是Google在2025年牵头推出的开放协议目标就是给Agent之间通信定标准。它基于JSON-RPC 2.0走HTTP传输核心思路是“任务驱动”一个Agent发起任务另一个Agent处理任务整个生命周期都有明确状态。这个设计思路和我们做企业集成的经验很对路因为任务有状态、有结果、有失败重试才能纳入运维体系。可能有同学会说我们自己定义一套协议不也挺好短期看确实可以但长期有三个问题绕不开一是招人成本高每个新人都要重新学你的“独有方言”二是生态兼容性差你没法直接接第三方Agent能力也没法被别的平台集成三是协议设计中的坑比如幂等、状态迁移、消息格式定义你都得自己踩一遍。A2A协议至少要帮你把这些通用问题兜住。这里要专门说一句A2A和MCPModel Context Protocol不是替代关系而是互补关系。MCP解决的是Agent怎么调用工具、怎么访问数据A2A解决的是Agent和Agent之间怎么协作。打个不精确的比方MCP是给Agent装上手和眼睛A2A是给Agent配上对讲机。两者在真实项目里往往同时出现别把它们搞混。版本上A2A从0.3演进到1.0最直观的变化是Agent Card这类元数据的规范更严格了安全与授权方面的要求也更明确。对企业用户来说这是好事因为协议越严谨越适合用来承载真实的业务链路。2. 把A2A协议掰开看Agent Card、消息模型与任务状态机2.1 一张Agent Card搞定能力发现A2A协议里每个Agent都要对外发布一张“身份证”叫Agent Card。这是一份JSON文档描述了Agent的基本信息、能力列表、调用地址和安全要求。其他Agent拿到这张卡就知道“对方能干什么、该怎么调用”。Agent Card里的关键字段我按落地经验排个优先级nameAgent的名字注册中心里做唯一标识命名规范一定要早点定。description用自然语言描述这个Agent擅长处理什么场景比如“负责查询订单状态并处理售后申请”。别小看这段描述其他Agent在做任务路由时很可能就是靠它判断要不要把任务交给你。urlAgent服务的访问地址注册中心和调用方都靠它找上门。capabilities声明Agent支持的能力比如是否支持流式输出、是否支持主动推送通知。这决定了调用方能不能用长连接模式做实时交互。skills更细分的能力列表每个skill可以有自己的描述和输入输出模式适合做大能力拆解。authentication/authorization说明调用这个Agent需要的身份认证方式企业环境里几乎是必填项。在企业内部落地时Agent Card除了做注册更实用的价值是充当“能力目录”。开发新Agent之前先查一遍现有Agent Card很多时候会发现你要的能力已经有了直接调用就行不用再重复造轮子。我看过很多团队内部有六七个Agent功能互相重叠就是因为大家压根不知道别人做了什么而Agent Card能把这种重复建设成本压下来。2.2 消息、任务、Part与Artifact四个对象怎么协同A2A协议的核心数据模型有四个对象刚开始接触容易绕我用一个订单查询场景把它们串起来。首先是Task也就是一次完整的工作单元。比如“查询订单OD20250618001的物流状态”这条Task从客服Agent发给订单Agent就开启了一段协作。Task里装着MessageMessage是Agent和Agent之间对话的基本单位里面带role字段标识是哪个Agent发的。每个Message又由若干Part组成Part可以是TextPart一段文本、FilePart文件引用、DataPart结构化JSON数据。这一步的灵活度很关键因为Agent之间既要传递自然语言也要传递结构化数据。订单Agent处理完Task之后会生成Artifact也就是任务的产出物比如处理完的订单数据、生成的报表文件。Artifact和普通消息的区别在于它代表任务执行的“完成品”后续Agent可以直接拿去做下一步处理。这四个对象的协作关系简单说就是发起方创建TaskTask里包含MessageMessage由多个Part组成执行方处理完后产出Artifact。设计得比较干净没有引入复杂的概念但覆盖了Agent协作的大部分场景。2.3 任务状态机如何支撑人机协作我之所以觉得A2A协议适合企业级场景很大原因是它把任务状态定义得足够清晰。一个Task从创建到结束会经历这几个状态submitted已提交、working执行中、input-required等待额外输入、completed已完成、failed失败、canceled已取消。这里面最有价值的是input-required状态。它表示Agent执行到一半碰到需要外部输入才能继续的情况。放到企业场景里这个状态就是天然的“人工介入点”。比如退款Agent计算出一笔退款金额按照公司授权规则超过5000元需要部门总监审批这时Agent就可以把任务状态置为input-required然后等待人类审批通过后再继续执行。有了状态机我们还可以做两件重要的事一是任务状态持久化每个状态变更都写入日志审计可以随时回放某个Task从创建到结束的完整轨迹二是异常处理比如Task卡在working状态太久可以触发超时机制把任务标记为failed并发告警。所以在我的架构里A2A的状态机不只是协议的一部分它还是整个责任链系统的地基。后面要讲的人工审批、超时升级、熔断全是靠这套状态机支撑的。3. 人机责任链把“谁来负责”写进系统3.1 为什么需要责任链AI越强责任越不能模糊企业环境和个人玩Agent最大的不同就是出了事必须有人负责。用户投诉了、财务损失了、监管问询了系统不能一脸无辜地说“这是Agent干的”。Agent只是工具但使用工具的过程和结果必须映射到具体的人和流程上。人机责任链这个概念我理解为把系统中每个Agent可执行的动作都对应到明确的授权边界、审批节点、回退策略和审计日志上。简单说就是给Agent画一个圈圈内它可以自己跑圈外必须有人点头。我常跟团队打个比方企业里的Agent定位应该像个能力很强但还没转正的实习生。你交给它查资料、写草稿、算数据它干得又快又好但如果它要对外承诺客户、操作资金变动、删除生产数据你就必须给它配一个“带教导师”重要事项签字确认全程留痕。责任链就是把“带教导师”这套机制数字化、流程化。3.2 责任链的分层设计操作层、审批层、审计层我落地责任链时习惯把整个体系分成三层来看。第一层是操作层对应Agent能自主执行的动作。这类动作的特点是影响范围可控、可回退、不涉及重大利益比如查询信息、生成报告草稿、做数据统计分析。这层追求的是效率目标是让Agent尽量少打扰人。第二层是审批层对应需要人类介入才能执行的动作。这类动作的特点是影响面大、不可轻易回退比如对外发送正式报价单、执行退款、删除用户数据、发布生产配置。这层追求的是控制Agent负责把方案准备好人来拍板。第三层是审计层对应全流程的留痕。所有Agent动作、任务状态、审批记录、参数变更都写入不可篡改的审计日志。这层追求的是可追溯任何时间点我们都能回答“这个决定是谁在什么条件背景下做出的”。举几个真实动作的分层示例业务动作责任层级说明查询客户历史订单操作层Agent自主执行生成退款金额建议操作层Agent产出建议但不生效执行退款金额阈值内审批层按规则自动审批或转人工执行退款金额超阈值审批层 审计层必须人工审批并全量审计批量删除用户数据审批层 审计层双人复核全程留痕这个表不是死的每家企业要根据业务风险来定义哪些动作属于哪个层级。但整体的设计原则是一致的能自动的尽量自动不能自动的坚决人工所有操作必须可审计。3.3 用input-required状态嵌入人工审批责任链怎么和A2A协议结合起来答案是直接利用input-required状态。当Agent流程运行到需要人类决策的节点时责任链引擎会介入做三件事第一把当前任务的状态置为input-required第二通过企业IM、邮件、审批系统等渠道通知对应的审批人附上Agent准备好的上下文信息比如退款金额、客户历史记录、风险提示第三等待审批结果。审批人通过审批之后引擎把人类的决策以Message的形式回传给原先的任务任务状态恢复为workingAgent继续往下跑。如果审批人驳回任务会转成failed状态同时触发后续的异常处理流程比如通知下游Agent不再执行、记录驳回原因。这套机制我强烈建议配合两个策略一起用。一个是审批超时升级比如二级审批两小时没响应自动升级到一级审批人避免单点阻塞。另一个是审批上下文聚合不要让审批人只看到孤立的一条“请审批”要把Agent决策的依据、候选人、相关业务数据一起打包给他否则审批人不敢点同意还是得去翻系统效率一样低。4. 企业级架构落地注册中心、路由编排与系统拓扑4.1 最小可行架构Registry Broker 责任链引擎聊完协议和理论讲一讲我在企业里实际落地的架构。一套能用起来的多Agent协同系统我建议至少要包含四个部分。第一部分是入口网关负责接收来自业务前台、用户对话、定时任务等各种来源的请求做初步的身份认证和负载分发。第二部分是Agent Registry注册中心用来管理所有Agent Card。Agent启动时把自己的Card注册上来Registry做健康检查、能力索引和运行时路由查询。其他Agent要找人帮忙先来Registry查卡拿到对方的url和授权要求再发起调用。第三部分是任务编排层我习惯叫它Broker或者编排引擎。它负责按业务流程编排多个Agent的执行顺序处理任务的路由、状态跟踪、重试和结果聚合。这一层相当于整个协同系统的中枢神经业务规则写在这里而不是散落在各个Agent里。第四部分是责任链引擎单独拆出来作为一个服务。它负责判断当前任务是否需要人工审批、需要哪个角色审批、超时之后怎么升级同时把审批动作和审计日志打通。这里要特别强调一个设计原则不要在Agent内部写复杂的业务流程编排。Agent只负责自己领域内的专长比如订单Agent只处理订单相关逻辑流程怎么串是编排层的事。否则一旦业务链路调整你得改好几个Agent并重新发布排错成本极高。4.2 技术选型与关键参数配置参考技术选型上如果团队没有太重的历史包袱我建议直接采用主流做法Agent服务用Python或Java都没问题重点是Agent之间的通信统一走A2A协议。传输层用HTTP JSON-RPC需要实时流式交互的场景再加一道WebSocket。下面给出一份我在项目中用过的参数配置参考具体数值按业务量调整但思路可以复用配置项建议值说明Agent调用超时10s单次Agent调用超过10s就触发重试或降级Agent调用重试次数3次重试需要配合幂等键防止重复执行副作用任务整体超时30min超过后视为异常任务进入人工处理队列人工审批超时2h超过后触发升级流程审批升级次数上限2级避免无限升级刷屏消息体大小限制1MB内联Part大文件用FilePart引用不内联传输并发任务上限按Agent配置防止单个Agent被打垮配置里最容易被忽视的是幂等。A2A协议里每个Task有唯一的taskId调用方在重试时要带上这个ID接收方要做去重。比如退款Agent收到一条Task中途网络断了重试时又发一条一模一样的Task如果没有幂等判断就会发生重复退款的事故。这块一定要在Agent端做扎实。4.3 一个完整场景工单处理链路的端到端实现空讲架构不如跑一个真实场景。以“客户投诉工单自动处理”为例完整链路走一遍。业务流程是这样客户提交一条投诉工单内容包括“我上月买的订单还没收到货我要退款”。系统需要联动客服Agent、订单Agent、财务Agent和人工审批。第一步客服Agent接到工单先做意图识别判断这是一个售后退款请求。然后它去Registry查一下看哪个Agent能处理订单查询发现订单Agent的Card描述匹配就发起一条Task任务内容是“查询订单号XXX的物流状态和退款资格”。第二步订单Agent接收Task状态从submitted变成working。它执行完毕后把订单状态、支付金额、物流轨迹封装成Artifact返回。客服Agent拿到结果发现订单确实超过预计送达时间符合退款条件。第三步客服Agent调用财务Agent计算退款金额。财务Agent算完给出退款建议金额比如298元。这时责任链引擎介入根据规则判断298元低于5000元的审批阈值按正常授权应该可以自动放行。但这里我们设置了另一个条件——该客户近30天内有两次退款记录属于高风险用户所以退款必须人工审批。于是任务状态从working变为input-required责任链引擎生成一条审批通知推送给客服主管。通知里包含工单上下文退款金额、客户历史、风险标记、退款方案。主管审核后点通过引擎把审批意见回传给财务Agent任务恢复working财务Agent执行退款完成后任务进入completed状态全程审计日志自动归档。这个场景走完你会发现A2A协议承担的是“通信状态传输”责任链引擎承担的是“决策控制人工介入”各司其职不互相干扰。而最终的退款审批记录、Agent执行记录、状态变更记录都能在审计系统里一键导出满足合规要求。5. 常见问题与排查技巧实录5.1 高频问题速查表多Agent系统跑起来之后日常运维会碰到不少问题我把高频问题整理成了速查表现象可能原因排查建议Registry里搜不到某个AgentAgent服务未注册或健康检查失败检查Agent的url是否能通、注册是否带对了Agent Card任务一直卡在working下游Agent超时或死锁查看任务状态变更日志定位阻塞Agent审批节点长时间无响应审批人没收到通知或IM通知失败检查通知渠道配置设置超时自动升级消息体过大导致超时内联了过多文本/文件内容改用FilePart的URI引用减少内联传输重试后产生重复执行缺少幂等处理确认Agent端是否用taskId做去重Agent之间误调Agent Card描述不精确路由判断错误细化description和skills加上明确的触发条件第一条是很多团队最容易踩的。Agent Card里的description字段你别写得太抽象比如“提供客户服务支持”这种别的Agent根本判断不了什么场景该调用你。要写成“处理客户订单查询、物流跟踪、售后申请输入参数为订单号输出为订单状态与物流轨迹”这样才能减少路由误判。5.2 几条实战避坑经验最后分享几条我从项目里踩出来的教训希望你能绕开。第一条别让一个Agent承担太多职责。我最早把订单查询、物流跟踪、退款计算放在一个Agent里想着省事儿结果发现任务状态一复杂排查问题就要翻它内部的长链路日志。后来拆成三个Agent每个都只做一件事不仅调试容易责任边界也更清楚了。第二条人工审批节点一定要有超时和备选通道。我踩过一个坑审批消息只发了企业IM结果审批人出差没看到整个工单链路卡了一整天。后来所有审批节点都加了超时升级机制超过30分钟自动邮件短信通知超过2小时升级到上级审批人再也没出现过任务卡死的投诉。第三条审计日志从第一天就要设计好别等项目大了再补。A2A任务状态、Agent调用参数、审批人操作记录这些都要带上时间戳和唯一流水号。别等出事再想着“能不能追溯”那时数据早被覆盖了。审计日志也不建议只存在数据库里定期归档到对象存储保留至少一年是企业级的基本要求。第四条先小范围试跑再横向铺开。不要一上来就规划十个Agent协同的宏大蓝图。我习惯先选一个真实业务链路用两个Agent加一个审批节点跑通验证A2A协议、责任链和审计流程都能正常运转再逐步扩展。这样每次加新Agent都是在验证过的骨架上加肌肉出问题的概率小很多。这套体系我实际落地过几次最深的体会是Agent协同系统的瓶颈从来不在模型能力而在组织能不能接受“让机器跑得快、让人管得住”这个分工。A2A协议给了技术上的共同语言责任链给了业务上的安全感。如果你正准备做类似规划我的建议是先别急着上十个Agent的大秀老老实实把两个Agent通过A2A协议跑通再塞一个审批节点进去完整走一遍端到端流程。走到那个节点你一定会对这套体系产生完全不一样的理解。
