企业级多Agent协同实战：A2A协议与人机责任链设计-北京尧图网络

我们之前做过不少单Agent的落地项目说白了都是“一个智能体一套工具一层Prompt”的堆叠模型一换逻辑就得重写工具一多上下文就开始打架。所以当公司内部开始提“多Agent协同”的时候我的第一反应不是兴奋而是头疼。Agent一旦多起来靠自定义JSON互相调接口短期内能跑长期一定乱成一锅粥。这篇就来复盘一下我们最近在做的企业级Agent协同系统重点聊聊为什么选了A2A协议作为通信底座以及人机责任链那套机制是怎么设计出来的。如果你也在搞Agent化改造被“多Agent互调、权限边界、责任归属”这些问题卡住这篇文章应该能给你一些参考。1. 项目背景Agent系统进入“多体协同”阶段1.1 单个Agent到Agent协同问题出在哪我们一开始落地Agent的时候形态非常克制一个客服Bot、一个数据分析助手、一个内部知识库问答后台逻辑全写在同一个服务里。问题从第二个Agent开始出现——业务方希望客服Bot能调用数据分析助手的能力给用户输出“带数据支撑的回复”又希望知识库问答能调用客服Bot的工单系统查一下用户的历史投诉记录。那会儿的架构非常直觉化服务A通过HTTP调服务B参数靠业务方对着文档手填返回结果靠人肉解析。三个Agent的时候还能维护到了五个以上依赖关系图直接变成毛线团。每次改一个Agent的接口下游少说挂两三个。更痛的是这些Agent有的是我们用Python写的有的是团队用Node写的还有两个是采购的系统人家根本不开放内部代码只暴露一个对外API。这种情况下自研一套协议的成本太高了最理性的选择就是在业界已有的开放协议里挑一个。1.2 为什么我选了A2A协议而不是自研协议当时摆在面前的选项有三个一个是自研一套消息协议好处是贴合业务坏处是绑死我们自己跟外部系统、开源生态对接等于重写一遍第二个是围绕MCPModel Context Protocol去改但MCP本质上解决的是“Agent怎么调用工具”的问题重点在“模型访问外部工具”它的角色模型里并不太关心“Agent之间如何对话、如何交接任务”第三个就是A2AAgent2Agent协议它要解决的就是“不同供应商的Agent如何互相发现能力、分配任务、交换结果”。A2A最打动我的地方有两点。第一它定义了一套Agent Card能力卡片每个Agent用一份JSON描述自己能干什么、怎么调用、需要什么认证方式相当于给每个Agent发了一张“身份证说明书”。第二它的任务模型基于“Task”这个概念不是一个Agent直接去调另一个Agent的函数而是发起方创建任务、接收方执行、双方不断交换消息整个过程可追踪、可中断、可回放。这对企业级系统来说非常重要——出了事故你得能复盘责任得能追溯。还有一个现实考量A2A协议是开放协议生态里已经有不少开源实现和商业产品在做兼容选它等于给未来接第三方Agent留了后路。我们内部也讨论过“先自研再平滑迁移”的路线但经验告诉我自研协议一旦跑起来迁移动力约等于零。与其后面痛苦重写不如一开始就站在一个相对标准的地基上。1.3 项目整体结构总览这套系统跑起来之后的整体结构大概是这样的每个Agent都对应一份Agent Card注册到中心化的Agent Registry服务里Registry负责能力发现与路由。Agent之间的通信统一走A2A协议基于JSON-RPC 2.0 over HTTP消息格式由协议规范统一约束。核心链路是“任务编排层”它像调度中心一样把一个大目标拆成多个子任务分发给对应的Agent然后汇总结果。人机责任链从底层包住整个链路不同风险等级的操作有的全自动有的要求人审批有的直接强制人工处理。所有任务消息、审批动作、Agent执行日志统一进审计系统一份不可篡改的trace贯穿始终。这套结构跑起来之后我最大的感受是A2A协议把通信问题划进了一条相对干净的边界人机责任链则把“谁对结果负责”这件事变成了可配置、可追踪的规则而不是凭感觉。2. A2A协议细节拆解从0.3到1.0的核心变化2.1 A2A协议到底在解决什么问题想理解A2A得先看清楚它的定位。它解决的不是“Agent怎么写”而是“Agent怎么对话”。类比一下每个Agent都像一个独立公司的员工各自有自己的流程、系统、话术。A2A就是一套行业通用的商务沟通标准——大家用同一套传真/邮件格式用同样的术语、同样的单号来对接而不是A公司用微信、B公司用钉钉、C公司靠飞鸽传书。A2A协议的核心概念就几个Agent Card、Task、Message、Part。Agent Card是能力声明Task是一个从创建到完成的工作单元Message是Task里来回传递的消息Part则是Message里具体的载荷片段纯文本、文件片段、结构化数据等。整个通信模型是围绕“任务”展开的不是围绕“函数调用”展开的。理解这点很重要——这意味着A2A天然适合异步、长耗时、需要人工介入的场景而不是单纯的“你调我一下我立刻返回”。执行的典型时序是这样客户端Agent拿到服务端Agent的Card确认对方有能力处理这个任务于是创建一个Task并发送初始消息服务端Agent返回Task状态可能是pending、working也可能是completed双方继续通过消息你来我往过程中客户端可以查询任务状态、取消任务也可以订阅推送通知。全程状态都挂在Task这个实体上不存在“调完就失联”的问题。2.2 Agent Card完整说明与实操写法Agent Card是整个A2A体系里落地最具体的文件我们内部叫它“Agent身份证”。它是一个JSON文档核心字段包括字段作用我们实际使用时的注意点nameAgent的名称建议全局唯一最好跟部门/业务前缀挂钩比如finance-analyzer-v2别用agent-final-final这种description自然语言描述能力这里写得越清楚协作方Agent大模型越好理解别写“智能助手”这种废话要写“能根据财务明细表计算月度毛利率并输出环比分析”skills技能列表每个技能要有id、name、description我们要求description里写清输入输出能附带示例最好capabilities能力开关是否支持流式输出streaming是否支持推送通知pushNotificationssecurity认证方式我们统一走OAuth2.0的client_credentials模式在Card里声明所需的scopespreferredTransport首选传输方式目前主要是HTTPS endpoint后续可以扩展消息队列等分享一个我们内部踩过坑的细节description字段千万别写得太笼统。最开始我们为了省事把财务分析Agent的description写成“提供财务分析相关能力”结果下游Agent编排时经常把这个Agent分配给语义相近的指标查询任务因为大模型看到的描述信息实在不够精确。后来我们改成“基于上传的利润表、现金流量表Excel文件计算毛利率、净利率、现金流覆盖率等指标输出同比/环比分析结论”误配率一下就下来了。Agent Card不是给机器看的形式化文档某种程度上也是写给你的Agent编排大模型看的Prompt。2.3 1.0版本相比0.3版本的关键升级我们第一期立项时A2A协议还处于0.3预览版等到系统做到一半1.0正式版出来了。为了兼容1.0我们专门做了一次协议层适配把两版差异梳理了一遍。说句公道话0.3到1.0不是推翻重来但有几个变化对企业级落地非常关键。最大的变化在API层。1.0对方法名和消息语义做了收敛比如把一些含糊的字段彻底澄清task/cancel、task/get、message/send这些核心方法的生命周期更加明确。第二个比较重要的变化是对推送通知的正式支持0.3里推送还是半推荐状态1.0直接把它纳入规范服务端可以声明支持pushNotifications客户端可以回调地址接收任务状态变更这大大减少了轮询带来的无谓开销。第三个变化是安全模型的强化1.0明确了一套可扩展的认证机制并且对多租户、配额管理这些企业级问题给出了更清晰的接口约定。如果你现在才刚开始接A2A建议直接按1.0来。如果你维护着0.3的老系统也不用焦虑——两者的核心实体模型没有颠覆性变化主要是方法语义和部分字段需要对齐改动量大概在一个接口适配层的量级。我们内部的做法是先把1.0的字段模型映射到内部统一对象上外部无论对接0.3还是1.0内部处理的都是一套模型。2.4 任务生命周期与消息模型实践经验A2A的任务状态机看起来简单实际编排的时候状态一致性问题很考验人。任务状态包括submitted、working、input-required、completed、canceled、failed等几个。我们刚接协议时误以为只有客户端能创建任务其实服务端在某些场景下也可以作为任务发起方。更需要注意的是input-required状态——当服务端Agent发现信息不足时它会把Task挂起要求客户端补充材料。这个状态在企业内部“Agent找Agent要数据”的链路里特别常用。消息模型这块我们建议早期团队统一用“一Task一结果”的简单模式避免过度设计。A2A允许一条Task里传递N条Message每个Message可以带多个Part。我们内部的约定是同一个业务目标的所有来回沟通尽量放进同一个Task里用Part区分不同类型的数据文字结论、附件、结构化JSON。好处是审计时一个Task就是一个完整的故事查日志不用跨多个实体拼图。等系统复杂到确实需要并行子任务时再引入“Parent Task / Sub Task”的层级关系。3. Agent框架与编排实现harness、skill、记忆怎么落地3.1 harness、skill、agent三者的关系最近很多人聊“agent harness”这个概念和“agent本体”容易混淆。我的理解是harness是承载Agent运行的那套基础设施包括模型调用、工具注册、上下文管理、记忆读写、安全沙箱而agent本体更像一个“大脑决策单元”它决定下一步干什么但真正动手执行靠的是harness提供的工具和服务。Skill则是Agent可以复用的“能力包”一个Agent可以装多个Skill比如“生成Excel报表”是一个Skill“调用CRM查客户信息”是另一个Skill。这套分层在企业级系统里特别有用。我们把harness层做成了一套内部公共框架任何Agent都跑在同一套底座上业务Agent只需要注册自己的Skill、定义自己的Prompt编排逻辑剩下的模型路由、超时重试、日志上报全交给harness。用个不恰当的比喻harness是办公桌Agent是坐在桌前的人Skill是抽屉里的工具。人换了一茬办公桌和工具架还在。3.2 编排引擎的三种选型路线多Agent协同系统的核心枢纽是编排层。我们内部调研、对比之后归纳出三条常见路线代码编排用Python/TypeScript硬编码业务流程什么时候调哪个Agent、参数怎么转全在代码里写死。适合流程固定、变化少的场景。优点是可控、易调试缺点是业务一改就得发版。大模型编排LLM Planner把大目标交给一个大模型由它根据Agent Card自动拆解任务、选择Agent。适合开放域场景但结果有随机性企业落地时必须辅以严格的结果校验。规则大模型的混合编排经验证的高频路径用规则固化异常分支交给LLM临时决策。这是目前企业落地最稳的组合。我们最终选择的是混合编排。核心路径比如“查库存→生成采购单→审批→通知供应商”全部走规则引擎步骤和参数都是预设好的只有那些规则覆盖不到的边缘case才会让LLM出来救场。这样做的好处是核心业务链路的稳定性和可预测性有保障出问题能精准定位到具体环节而不是在大模型的黑盒决策里捞针。3.3 记忆层设计短期、工作记忆、长期记忆协同场景下的Agent记忆比单Agent聊天更复杂。单Agent只需要记住对话历史多Agent系统里记忆必须分层短期记忆当前Task里的上下文包括A2A协议里来回传递的Messages。这部分我们直接存在Task实体里Task结束就归档不跨任务共享。工作记忆当前业务会话内的共享状态比如订单号、客户ID、当前审批节点。我们存在一个带TTL的Redis里供会话内多个Agent查询但写操作必须走编排层避免多个Agent同时改同一个状态。长期记忆沉淀下来的经验知识比如某个客户的偏好、某类故障的处置模板。这部分必须经过审批和结构化门槛不能由Agent擅自写入防止脏数据污染。我刚接手项目时团队想做一个“无限记忆”的Agent让大模型把每次交互都记住。听上去很美实际操作里完全不可控——模型会记住不该记的也会忘掉该记的。后来我们彻底收敛了方案Agent尤其是协同场景下的Agent不需要像人一样“什么都记得”它只需要在正确的时间把正确的状态捞出来用。记住什么、忘掉什么应该由系统设计者定而不是让模型自己定。3.4 技能skill封装规范Skill是Agent能力的最小复用单元。我们内部给Skill封装定了几个必须字段trigger什么条件触发这个技能、input_schema结构化输入、output_schema结构化输出、success_criteria怎么判断执行成功、error_codes常见错误码。听上去很基础但就这个schema的严格程度极大地区分了“能用”和“好用”。比如我们的“发送企业微信通知”这个Skillinput_schema必须声明收件人、消息类型、是否支持Markdown、是否需要回执output_schema必须能把“发送失败”细分为“联系人不存在”“微信群已解散”“接口限流”“权限不足”等。这样上层编排Agent才能针对不同错误码决定是重试、换人通知还是直接转人工。Skill不只是一个函数它是带“自我描述”和“错误语义”的工程单元。4. 人机责任链让AI干活但责任不悬空4.1 为什么要做“责任链”而不是“自由发挥”AI Agent跑在demo里怎么自由都行。一旦跑在真实业务里它代表公司对外承诺、对内花钱、对系统做变更问题就变了如果Agent生成了一个采购订单谁对这笔钱负责如果Agent自动回复了客户一个错误承诺算谁的我们做企业级系统最大的恐惧不是模型笨——而是模型笨了之后我们找不到责任人或者各环节互相甩锅。人机责任链这个概念本质上是在Agent自动化流程中把每个决策点都标清楚这个动作是Agent自动做的还是人审过的还是完全人做的每个环节对应的owner是谁这样一旦结果出问题我们能沿着审计链回溯定位到决策点和责任人。它不是用来“惩罚”的而是用来“定位问题、建立信任”的。4.2 自动化分级与决策权限矩阵我们在系统里定义了一套自动化分级所有Agent动作在架构上都必须声明自己的风险等级风险等级说明示例人工介入方式L0信息查询、内部只读操作查库存、看订单状态全自动无需人审L1内部低风险写操作发通知、创建草稿自动执行但定期抽检L2内部中风险变更修改订单状态、发起审批必须指定审批人通过后执行L3对外高风险动作发对外邮件、承诺赔偿、创建付款单强制人工确认Agent只产草稿这个矩阵听上去简单执行时最大的难点是“Agent怎么知道自己要做的事属于哪一级”。我们的做法是每个Skill的definition里直接带上risk_level字段Agent调用Skill时编排引擎自动校验当前授权上下文是否允许执行。Agent大模型本身无权修改这个字段这样即使模型被诱导说要干某件事底层基座也会拦截。把风险判断下沉到Skill层而不是依赖大模型的临场判断是目前我们实践下来最靠谱的方案。4.3 审批节点的设计细节审批不是简单地在中间插入一个“人等Agent”的环节。我们做了三件事让审批真正可落地第一审批任务必须带上“Agent角度摘要”。当Agent请求人工审批时它必须同时输出“它想做什么、依据是什么、潜在风险是什么、备选方案是什么”。人工审批者不需要去翻一大堆上下文日志在一个页面里就能看懂Agent为什么做出这个决策。这大大提高了审批人愿意审的概率。第二审批超时必须有兜底。我们设了L2/L3动作的审批超时上限超时后默认“拒绝并降级为纯人工处理”不允许超时自动通过。这就避免了“Agent夜里发起的审批没人看第二天早上自动通过了”这种安全隐患。第三审批人与Agent之间必须能对话。审批人不是只点一个“同意/拒绝”按钮他可以在审批界面直接给Agent反馈意见比如“改为下个月执行”或者“通知对象去掉张三”。Agent来续跑时这些反馈意见会被作为新的上下文加入Task保证人的意志真正传导到了Agent的下一步行动里。4.4 审计追踪与事故回溯设计有了责任链审计就得跟上。我们每一个Task从创建到结束全链路记录以下信息Task ID、父子关系、调用的Agent及版本、使用的Skill ID、每个动作的输入输出摘要、审批人和审批意见、Agent推理摘要关键中间步骤的模型输出、耗时和费用。这些数据统一落到审计日志服务里按天做不可篡改归档。事故回溯时我们只需要输入一个业务单号就能拉出整条链路。曾经出过一次故障一个数据分析Agent因为上游数据源字段变更把毛利率算错了12个百分点还自动生成了分析报告发给业务负责人。因为责任链机制我们很快定位到问题出在“取数Skill的输入映射层”而不是Agent决策本身最终修复了字段映射并给取数Skill加了数据质量校验。如果没有这套审计设计这个锅大概率会甩到“模型不行”上真正的根因反而会被盖住。4.5 安全隔离与最小权限实践企业级Agent协同权限控制必须做“双重最小化”。第一重是Agent维度每个Agent一个服务账号只授给它完成自身任务所需的最小权限。财务分析Agent只能读财务表不能写客服Agent只能读CRM不能删工单。第二重是“凭证维度”Agent执行跨系统动作时不允许用自己的全局凭证而是由编排层根据当前Task动态下发一次性临时凭证。比如某个Agent需要调用采购系统的创建订单接口编排层会签发一个scope极窄、有效期只有30分钟的临时token用完即废。我们还在沙箱里跑所有Agent代码文件系统只读网络出口有白名单。早期确实有Agent因为Prompt注入被诱导去访问内网URL的情况但因为有网络白名单和临时凭据机制最终什么也没发生这个事反而坚定了我们“默认不信任、按需放行”的信念。5. 常见问题与排查实录5.1 高频问题速查表这套系统联调和试运行阶段我们踩了不少坑整理了一张高频问题表供同行避坑现象根因解决方案Agent Card能注册但下游始终发现不了description信息模棱两可编排LLM无法匹配意图重写description加入明确的输入/输出、触发条件、约束任务一直停留在working状态服务端Agent内部异常但没捕获错误并更新Task状态在harness层加全局兜底任何未捕获异常统一转为failed状态消息推送收不到0.3版本时推送不规范客户端没拉齐回调地址升级到1.0协议统一用pushNotifications机制多Agent并发更新同一业务实体缺少分布式锁或版本号机制在工作记忆层加Redis分布式锁写操作强制走编排层审批人觉得信息不够、拒绝审审批摘要太简陋只看得到“Agent想做X”看不到依据强制Agent输出“依据风险备选”三段式摘要审计日志里某个Task缺环节TaskID在业务系统与A2A协议层未做透传映射统一在HTTP Header里带TraceID全链路透传5.2 实操避坑经验分享挑几个印象最深的坑展开讲讲。第一个坑是关于Agent的版本管理。最开始我们只管理了代码版本没管Agent Card版本。结果有一次改了下游Agent的输入schema但没同步更新Card上游Agent按照老Card传参下游直接报错。后来我们把Agent Card纳入版本管理任何Agent能力变更必须同步发版CardRegistry里同时保存多个历史版本并且提供“按版本调用”的能力。第二个坑是“让LLM直接输出JSON”的脆弱。A2A协议里大量消息要带JSON Part早期我们图省事让模型直接生成JSON结果偶尔出现小语法错误或多余字段导致下游Agent解析失败。后来统一改成“LLM输出自然语言结构化模板变量”由harness层填充为严格JSON解析成功率从踩坑时的90%出头提高到接近100%。任何协议接口的边界处都不要让大模型自由生成格式用代码去保证结构化。第三个坑是回滚意识。Agent协同链路长了以后版本回滚难度指数上升。我们现在对每条核心Agent链路都做了“编排版本快照”发布新版本时自动保留旧版本的编排逻辑一旦线上出问题可以一键回滚到上一个稳定快照。这个机制在几次发布事故里至少帮我们止损了半个工作日。5.3 后续演进方向这套系统目前已经跑通了从客户咨询到内部工单分派、再到财务开票的完整链路但仍然有不少地方值得继续投入。首先是A2A协议与现有企业内部消息总线比如Kafka、RocketMQ的深度融合目前还是HTTP同步为主异步化改造空间很大。其次是Agent的可观测性我们希望未来每个Task都能生成一份“决策旅程”像产品分析里的用户旅程一样直观展示Agent每一步的思考、动作和偏差。另外“人机责任链”目前主要还是靠审批节点和审计日志来体现下一步我们想在编排层引入“责任矩阵”配置让每个业务链路从一开始就声明好哪些环节是Agent自主权哪些必须人审批哪些需要双人复核。通过配置化而非硬编码让业务方自己就能调整风险策略。这块等我们实践得更成熟了再单独写一篇文章分享。最后给大家一个不成熟但务实的建议如果你的企业也准备做多Agent协同别一上来就追求“全智能编排”。先把A2A这层通信协议铺好把Agent Card当成一等公民管理起来把责任链上的每个节点人肉走通一遍——这些“笨功夫”才是整个系统能长期稳定跑下去的地基。至于那些“自动拆解任务、自动找Agent、自动执行”的魔法等地基稳了再上不迟。

企业级多Agent协同实战：A2A协议与人机责任链设计

相关推荐

Vivix-W1与Codex Voice：流式多模态交互如何重构AI协作范式

梦幻西游辅助背后的视觉识别与状态机自动化工程解析

Telegraf nvidia_smi 输入插件深度解析：基于 NVIDIA SMI 的 GPU 指标采集配置与实现原理

更多资讯

腾讯云OpenClaw部署指南：广告营销Agent基础设施构建与成本优化

Lithe-IDEA：轻量开源Java开发内核的实践与范式

C++递推数列解题指南：从斐波那契到边界与溢出处理

高斯噪声在数据增强中的核心优势与应用实践

FSK解调Matlab仿真：从demod.rar参数调试到非相干解调实现

PyTorch入门必学：用dir()和help()快速摸清API与环境配置

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？