企业官网建设流程全解析

我最早跑通第一个 Agent 项目时，觉得这玩意儿太神奇了——一个大模型节点挂着几个工具，就能完成资料整理、信息检索、邮件草拟这些活儿。但真把它丢进业务流里，问题一个接一个：单个 Agent 处理不了需要跨三个系统、过两道人工审批的事情；会话一长上下文就爆炸；最关键的是，它干到一半断电了，另一个 Agent 根本接不上手。后来我逐渐明白，企业级 Agent 落地，难点根本不在单个 Agent 的推理能力，而在多个 Agent 怎么协作、怎么交接、出了问题怎么追责。这就是 A2A 协议和人机责任链要解决的核心问题。

这篇文章是我踩了几个月坑之后整理出来的设计方案，方向集中在三个点：A2A 协议到底怎么用、协同引擎怎么搭、人机责任链怎么落地。适合已经在做 Agent 开发、正准备往生产环境推的团队参考，也能给刚接触 Agent 架构的同学一个整体认知框架。

1. 单 Agent 跑不通生产，协同系统到底要解决什么

先泼一盆冷水：你本地跑得飞起的单 Agent，离生产环境还差着十万八千里。单 Agent 的本质是什么？一个入口、一个上下文窗口、一组工具、一个权限边界。你让它在你的笔记本上帮你查个资料、生成个周报，很爽。但放到企业场景里，一个真实的业务流程往往是这样的：用户提交申请 → 系统校验资质 → 风控判断风险 → 财务确认预算 → 主管审批 → 执行变更 → 结果归档。串起这一条链路，至少涉及四五个不同角色、三四个不同系统，中间还有明确的人工审批节点。

这不是单 Agent 能搞定的。靠一个 Agent 硬撑，会出现三个无解的问题。

上下文无限膨胀。你让 Agent 处理一个工单，它需要先看用户历史记录，再查库存，再读合同模板，再和用户确认细节。这些都堆进一个上下文窗口里，很快就把窗口撑爆。企业业务线一多，每个会话都这样搞，性能成本和 token 成本都不可控。你会发现最耗时的不是 Agent 思考，而是它不断把旧信息翻出来重读。

权限边界模糊。单个 Agent 拿着所有工具的访问权限，在企业里就是灾难。它既能查库存，又能改价格，还能给用户发邮件，一旦模型幻觉发作，误调用了某个写操作，没人能拦得住。我在生产环境见过一次 Agent 把测试环境的配置写进了生产数据库，排查了半天，根因就是权限粒度太粗。

任务无法交接。单 Agent 一旦会话中断、超时、或者模型输出格式错误，整个任务就废了。换个 Agent 来接手，它不知道前面发生了什么、做到哪一步了、哪些步骤已经完成。企业流程不可能容忍这种状态丢失。

协同系统的本质，就是解决这三个问题的。往细了说，它要提供四件事：

• 任务分包：把一个大目标拆解成多个子任务，每个 Agent 负责自己最擅长的那一块，各干各的，互不干扰。
• 任务契约：Agent 之间不是靠含糊的对话衔接，而是靠结构化的任务描述、输入输出定义、完成标准来交接，像工厂里的工单一样清晰。
• 状态管理：任务当前在哪个环节、谁在负责、哪些步骤在等审批、哪些已经完成，全局可见、可查询。
• 责任追踪：任何一个操作都能追溯到发起人、执行 Agent、审批人，出了问题不会互相踢皮球。

这四个需求，恰恰决定了你在技术选型上需要什么。任务契约和状态管理，对应的是 A2A 协议里的任务生命周期和 Agent Card；任务分包和责任追踪，对应的是协同引擎的编排能力和人机责任链的设计。所以别急着写代码，先把这几个需求想清楚，架构才是自然的。

业内常拿 A2A 协议和 MCP 协议放在一起比较。我的理解是：千万别把它俩放在对立面。MCP 解决的是 Agent 怎么调用外部工具和数据源，是纵向打通；A2A 解决的是 Agent 之间怎么互相通信和协作，是横向打通。一个 Agent 要干活，需要 MCP 去拿数据、执行动作；多个 Agent 要协作，需要 A2A 来互相发任务、传结果。一套企业级系统里，两个协议通常是共存的，各管一段。想清楚了这一层，后面的架构选型就不会跑偏。

2. A2A 协议 1.0：Agent Card、目录服务与任务生命周期

聊 A2A 协议之前，先说说它的来龙去脉。A2A 最早是 Google 在 2024 年底提出的，目标很简单：给不同厂商的 Agent 定义一个通用通信语言，让它们能互相发现、互相调用。2025 年项目移交给了 Linux 基金会，以 Agent Communication Protocol（ACP）的名义继续演进，并推出了 1.0 版本。版本跃迁的背后，是整个协议从“实验性的白皮书”走向“可落地的工业标准”的过程。

我见过不少团队，嘴上说着“我们用 A2A”，实际只是让两个 Agent 互相发了几个 HTTP 请求，完全没有吃透协议的核心机制。A2A 真正值钱的地方在三个机制：Agent Card、Agent Directory Service、以及标准化的任务生命周期。

2.1 从 0.3 到 1.0：Agent Card 是怎么进化的

Agent Card 可以理解成每个 Agent 对外展示的“服务说明书”或者“简历”。别的 Agent 或者编排平台想看你能不能干活、能干什么活、以什么方式跟你交互，第一件事就是读你的 Agent Card。

0.3 版本的 Agent Card 更像一张电子名片，信息相对单薄——基本是 Agent 的名字、描述、入口 URL，顶多加一点简单的能力标签。实际用起来你会发现，光靠这点信息很难做精准的任务路由。你想找一个“能处理发票 OCR 并抽取金额字段”的 Agent，名片上只写“发票处理”，根本不够判断它能不能满足你这条链路的准确率要求。

1.0 版本的 Agent Card 可以说是脱胎换骨，结构上更接近一份完整的“能力清单 + 服务协议”。核心字段包括：

这个演进背后其实反映了 A2A 定位的变化：0.3 是“让 Agent 之间能打个招呼”，1.0 是“让 Agent 能被精准地发现、评估和调用”。对企业来说，后者才是能进生产环境的底线。

实际部署时，Agent Card 一般放在 Agent 服务根路径下的.well-known/agent-card.json，这样外部系统通过标准路径就能拉取到卡片。举个例子，一个负责合同评审的 Agent Card 大概长这样：

{ "name": "contract-review-agent", "description": "负责合同条款的风险审查，输出风险点清单与修改建议", "url": "https://agent.internal.example.com/contract-review", "skills": [ { "id": "risk-scan", "name": "合同风险扫描", "description": "识别合同中的付款、违约、保密条款风险" }, { "id": "clause-suggest", "name": "条款修改建议", "description": "针对风险条款生成修改建议文本" } ], "capabilities": { "historySupport": true, "inputModes": ["text", "file"], "streaming": true }, "security": { "auth": "mtls", "targetAudience": "internal" } }

你注意这个卡片的几个细节。skills 是给路由用的，能让编排层知道这个 Agent 更适合干哪一类活；capabilities 决定调用方式，比如它支不支持流式、接不接受文件；security 则是接入策略，企业级环境里这块直接决定你能不能放它进内网。写卡片的时候有个建议：description 和 skills 一定要基于真实能力来写，宁可保守也不要夸大。因为下游的 Agent 会拿这个卡片做任务匹配，写得太宽，任务就分错；写得太窄，有活也接不到。

2.2 Agent Directory Service：从点对点寻址到集中式目录

0.3 时代，Agent 之间的发现基本靠点对点——你知道对方的地址，直接去拉它的 Agent Card。这种模式在演示环境里没问题，Agent 就三五个，地址写死在配置文件里就完了。但企业里 Agent 数量一多，环境一复杂，点对点的方式立刻崩溃：新上线一个 Agent，所有调用方都得改配置；Agent 迁移了 IP，全部依赖它的系统跟着断链。

1.0 版本引入的 Agent Directory Service 解决的就是这个问题。所有 Agent 启动后都向目录服务注册自己的 Agent Card，调用方只需要问目录服务：“我要找一个能做发票识别的 Agent”，目录服务就会返回符合条件的 Agent 列表和它们的 Card。这套机制跟微服务架构里的服务注册发现如出一辙，做过后端的人都熟。

落地的时候我建议把目录服务做成企业内部的一个基础组件，可以挂在我们已有的注册中心旁边。Agent 发布流程变成这样：新 Agent 部署 → 发起注册请求 → 目录服务校验 Agent Card 格式与安全策略 → 写入目录 → 对外发布。下线同理，注销后路由层就不会再给它派任务。

目录服务的引入还带来了一个额外的好处——它天然成了一个管控点。你可以在目录服务上做版本管理、环境隔离、灰度策略。比如新版本 Agent Card 先注册到测试目录，跑通后再切到生产目录；或者按业务线把 Agent 划分到不同的目录命名空间，互不干扰。这些能力在 Demo 阶段用不上，但生产环境绝对离不开。

2.3 任务生命周期：协同系统的“信号灯”

Agent Card 解决了“谁能干活”的问题，接下来是“活干得怎么样了”。A2A 协议里定义了标准的任务状态，类似我们熟悉的订单状态机：submitted（已提交）、working（执行中）、input-required（需要补充输入）、completed（完成）、failed（失败）、canceled（已取消）。

这六个状态就是整个协同系统里所有任务的通用“信号灯”。为什么统一状态这么重要？因为企业级协同里，一个任务往往要经过多个 Agent 接力，每个环节都要知道自己接手时任务处于什么状态、自己完成后应该把状态更新成什么。如果没有这个标准，A 系统管它叫“处理中”，B 系统叫“执行中”，C 系统叫“运行中”，最后汇总数据时一片混乱。

A2A 协议支持两种交互模式：同步请求和异步任务。同步适合短任务，发起方等结果返回；异步适合长任务，发起方提交任务后，通过轮询或者 webhook 回调获取状态更新。设计协同引擎时，我强烈建议所有任务都按异步模式来设计，哪怕任务本身只需要几秒。原因很简单：异步模式天然支持超时重试、任务持久化、断点续跑，一旦业务流程变长，不会因为同步等待导致整个链路阻塞。

任务运行过程中还有一个容易忽略的机制——artifact。Agent 执行任务产生的结果、文件、结构化数据，都通过 artifact 来承载。任务完成时，最终的 artifact 里既要有结果本身，还建议带上 Agent 的推理摘要和关键决策理由。这不是可有可无的元数据，后面讲责任链的时候你就知道，这些信息是追责和审计的命根子。

3. 协同引擎的骨架：路由、编排、状态持久化与容错

协议层面通了，接下来是系统设计的重头戏——协同引擎。我把它理解成整个多 Agent 系统的大脑和血管：负责把任务派给对的 Agent、控制执行流程、盯住每个任务的状态、出了故障还能自愈或者安全降级。

这一层业界有两种实现路线：一种是用现成的 Agent 编排平台，比如 Dify、LangGraph、Coze 这类；另一种是基于 A2A 协议自己搭一套。我的观点是：产品原型期用现成平台效率最高，但上了企业级生产环境，尤其是涉及敏感数据和复杂审批流时，自研协同引擎往往是躲不掉的。核心原因有三个：一是现成平台的权限模型未必能匹配你公司的组织架构；二是审计要求决定了你不能把关键链路数据放在第三方平台里；三是现成平台的扩展性很难适配你已经存在的存量系统。

不管自研还是用平台，协同引擎的设计都必须覆盖四块：目录与路由、编排模式、状态持久化、故障容错。

3.1 目录路由：根据 Agent Card 做智能派单

路由层做的核心事情是：拿到一个任务，根据任务类型、所需技能、负载情况，决定把它派给哪个 Agent。

最简单的实现就是基于 Agent Card 里的 skills 做关键词匹配。比如任务描述里带“发票”和“OCR”，路由就把任务派给声明了这两个技能的 Agent。但生产环境很快就会遇到一个问题——多个 Agent 都有类似技能，选谁？这时候就得引入评分机制，综合考虑技能匹配度、当前负载、历史成功率、响应延迟多个维度。

还有一个经验是：每个 Agent 一定要有全局唯一的 ID，并且要带版本号。因为 Agent 升级之后行为可能发生变化，如果路由层不区分版本，会出现同一个任务有时派给 v1、有时派给 v2，行为不一致，排查问题时非常痛苦。我们现在的做法是在注册时绑定版本，路由层只派当前激活版本，旧版本可以保留用于回滚。

3.2 流程编排：确定性流程与意图驱动编排的混合模式

编排层是整个引擎最难设计的地方。行业里讨论最多的一个问题：到底让 LLM 自主决定任务执行路径，还是用代码把流程写死？我的答案是：两者结合，而且结合的原则要非常明确——LLM 负责理解与决策，确定性代码负责执行与兜底。

具体来说，凡是涉及写操作、金额变动、权限变更、数据删除的高风险动作，一律走确定性代码流程，不允许 LLM 自由发挥。LLM 可以判断“这个任务需要调用退款接口”，但“退款接口怎么调、传什么参数、要不要审批”，必须由代码控制。LLM 可以做的是拆解任务、分析文本、生成内容、做分类判断这类低风险活动，在这些活动里它的弹性是优势。

我见过一个反面案例：某个团队让 LLM 直接调用数据库更新语句，结果模型的输出里带着一个多余的过滤条件，一次性把一整批数据改错了。那之后我们定了一条铁律：LLM 永远不直接碰写操作，它只能生成操作意图，由编排层去执行。“生成意图”和“执行动作”的分离，是协同引擎里最不能省的一道墙。

编排模式上，我推荐采用“管道 + 状态机”的组合。管道解决的是任务顺序问题，上一个 Agent 的输出作为下一个 Agent 的输入；状态机解决的是分支和异常问题，比如某个节点需要人工审批，状态机就把它推进到 waiting-for-approval 状态，等审批通过才继续流转。这种组合的好处是逻辑清晰、容易实现、出问题也好定位。

3.3 状态持久化：任务数据库与幂等性

多 Agent 协同里，任务不仅仅是 LLM 的一次响应，它是有生命周期、有状态、可以被查询和干预的实体。所以必须有一个任务数据库，把每个任务的完整状态存下来。

任务表的核心字段包括：任务 ID、流程 ID、当前节点、当前状态、调度历史、输入输出快照、以及关联的追踪 ID。这里最容易被忽视的是“输入输出快照”。很多团队只存任务结果，不存过程数据，等出了问题想回溯就抓瞎了。我的建议是，每个节点处理完，把输入摘要、输出摘要、以及 Agent 的决策理由（reason）一并存下来。存储成本会有增加，但换来的排查效率是绝对值得的。

还有一个必须从第一天就解决的问题——幂等性。A2A 协议里，同一个任务可能会因为网络超时被发起方重试，如果接收方不处理幂等，同一个操作就会执行两次。比如一个“发送账单给客户”的任务被重试了，客户就收到两封一模一样的账单，业务方直接火大。解决办法是要求每个任务都携带全局唯一的任务 ID，接收方在处理前先查重，已处理过就直接返回上次的结果，不再重复执行。

3.4 故障容错：超时、重试、熔断与人工兜底

生产环境里，Agent 不可用、响应超时、返回格式错误，都是家常便饭。协同引擎的容错设计决定了一个故障是小波澜还是大事故。

我的参数设计经验是这样：外部 Agent 调用的同步超时设置 30 秒，超过就切换异步轮询模式；异步任务的整体超时设置要看业务类型，普通数据处理 2 小时，涉及人工审批的 24 小时；重试次数设置为 3 次，重试间隔采用指数退避——1 秒、4 秒、16 秒，避免故障时所有任务同时打向同一个 Agent 造成雪崩。

更关键的是熔断机制。连续失败达到阈值，比如 10 分钟内一个 Agent 失败 5 次，就把它的状态标记为不健康，停止向它派新任务，等它恢复健康再重新启用。这个机制能有效防止一个出故障的 Agent 拖垮整个协同链路。

最后是人工兜底。所有重试都失败的任务，不能直接丢进死信队列就完事，必须有一个“人工处理通道”。我见过最稳妥的做法是：失败任务自动进入待人工处理列表，并通知相关的值班人员。这意味着协同引擎需要维护一个人工任务队列，这也是天然的人机协同接口，连着后面的责任链设计。

4. 人机责任链设计：审批节点、追踪 ID 与可追责的自动化

聊完了系统怎么“跑得快”，接下来是最容易被跳过、但企业落地时最致命的一环——怎么确保出了问题有人负责。很多人以为 Agent 出错了，是模型能力问题，写个更好的提示词就能解决。真实情况是：只要你把决策权交给了一个概率模型，它一定会犯错，只是时间和场景的差异而已。提示词能降低错误率，但永远消除不了错误。

所以企业级系统的设计逻辑不是“让 Agent 不犯错”，而是“Agent 犯错时，我们能及时发现、安全止损、准确追责”。这就是人机责任链的全部意义。所谓责任链，说白了就是每一件事都能找到责任人：是谁发起的、是谁执行的、是谁审批的、是谁该监督的。

4.1 责任链的四个角色：发起人、执行体、审批主体、审计主体

任何一次由 Agent 完成的操作，都必须能对应到四个责任实体：

• 任务发起人：业务链路里实际提出需求的人，通常是某个员工工号。Agent 的所有权限都继承自发起人，不能超出发起人的权限边界。
• 执行 Agent：具体干活的智能体，它有全局唯一 ID 和版本号。权限上必须遵循最小化原则——只授予完成当前任务所需的工具和系统访问权。
• 审批主体：对高风险操作进行确认的人。审批人的选择要落在具体的组织角色上，不能笼统地写“管理员”。
• 审计主体：通常指审计系统或合规系统，它负责记录全部关键动作，且日志不允许被普通用户篡改。

这四个角色要落实成代码里的强制约束，而不是流程文档里的建议。设计的时候要有技术强制力。

4.2 权限继承与收敛：Agent 永远不能超过人的权限

责任链的第一道闸门是权限。我们的原则是：Agent 的权限等于任务发起人的权限，但绝不能超过发起人的权限。更严谨地讲，还要叠加最小化约束——即使发起人有 A 和 B 两个系统的权限，Agent 执行特定任务时也只能用到完成这个任务所需的那一部分，而不是全部。

落地时我们做了两层：第一层，任务创建时绑定发起人的身份，整条责任链共享这个身份上下文；第二层，每个 Agent 有独立的服务账号，与工具系统的接口鉴权采用短时令牌，令牌有效期一般 15 分钟，有效期内只能访问白名单资源。就算某个 Agent 被攻破，影响范围也被限制在一个任务、一段时间、一组资源以内。

这个设计看起来增加了不少工程复杂度，但它能直接避免一个最可怕的事故场景——Agent 拿着全能账号在系统里横冲直撞，出事了连是谁的权限都说不清。

4.3 审批链：风险分级与审批令牌

不是所有 Agent 操作都需要人类审批。如果一个操作也要审批，一个自动生成周报的也要审批，那 Agent 的效率优势就全被审批流程吃掉了。合理的做法是按风险分级：

高风险操作的技术实现很关键。我在系统里定义了一个“审批令牌”机制：Agent 遇到高风险操作，先向审批服务发起审批请求，状态机推进到 waiting-for-approval；审批人在系统里看到申请，审核通过后，审批服务签发一个审批令牌；Agent 拿着令牌才能调用高风险接口，令牌一次性有效，附带审批人 ID、审批时间、有效期。这套机制保证高风险动作不可能绕过审批私自执行，而且事后能清楚知道是谁批的。

实际使用中要特别注意一个坑：审批超时。如果审核人长期不处理，任务一直挂在那里，会造成链路阻塞。我们的处理办法是：审批请求超时 4 小时后自动升级到上级主管，再超时 4 小时自动通知到业务负责人。同时给所有审批请求设一个总时限，超过时限未审批就直接标记为“已拒绝”，宁可让业务停下来，也不能让 Agent 在未授权状态下擅自行动。

4.4 追踪 ID：串起整条责任链的“线”

光有权限和审批还不够，审计追踪是责任链的最后一环。我见过一些团队，日志里各记各的，Agent A 的日志和 Agent B 的日志完全对不上，出事后想要还原整条链路，得人工去多个系统里翻半天。

标准做法是：任务创建时生成一个全局唯一的追踪 ID，这个 ID 要贯穿整个责任链——从发起人的请求、到编排引擎的分发、到执行 Agent 的处理、到审批人的审批记录、再到最终的操作日志，全部带上同一个追踪 ID。这样出了问题，只要拿追踪 ID 一查，整条链路的活动全部呈现出来。

每个关键动作的日志里，至少要包含这几个字段：

trace_id: e5f3a9c8-7b2d-4f6e-9a1c-3d8e2b7f4a6b operator: agent-contract-review-v3 requester: emp.zhang.san action: update_contract_amount target: contract_id=CT-2025-0193 approval_token: apv_9f8e7d6c5b4a decision_reason: "条款7.2存在未覆盖的赔付风险，建议修改赔付上限为10万" created_at: 2025-06-18T14:23:56+08:00

这里还缺一个关键动作——决策理由。这是最容易被忽视的地方。我们要求所有高风险动作的日志必须带上 Agent 的 decision_reason 字段，也就是它基于什么信息、什么逻辑做出这个决策。理由不必长篇大论，但一定要有。因为事后追责时，光知道它做了什么不够，还必须知道它为什么这样做，才能判断是模型幻觉、是数据污染、还是流程设计缺陷。

4.5 可关闭的自动化：每次人工介入都是一次流程优化

责任链设计的另一个价值是——它天然生成了大量“人工介入事件”。这些事件不是负担，而是优化 Agent 系统的最佳数据源。每个需要人工审批的节点，都说明当前 Agent 的能力还不足以安全处理那一类情况。要么是你对 Agent 的信任度设置太高了，要么是 Agent 本身的能力确实没到。

我们的做法是：每周复盘一次人工介入事件，归类分析。如果是 Agent 能力问题，就针对性地补充训练数据、优化工具；如果是流程本身就要求必须有人，那就调整风险分级策略，不要盲目追求全自动。企业级系统从来不该是“全自动”才是好的，合理的自动化和必要的人工介入相结合，才是最稳定可靠的方案。自动化不是目的，可控才是目的。

5. 从 Demo 到生产：实施路径、避坑清单与评估指标

最后说说怎么把纸面方案落进真实业务。我用一个我们内部的实际案例来拆解——IT 服务台的工单自动闭环系统。这个案例足够简单，但涵盖了 A2A 协同和责任链的全部要点。

5.1 案例拆解：IT 服务台工单自动闭环

整个系统的目标：员工提交 IT 工单后，系统自动分诊、自动处理常见问题、复杂问题自动转派专家并保留人工审批节点。

流程拆解下来是这样：

1. 员工提交工单，系统生成工单 ID，同时生成责任链追踪 ID。
2. 分诊 Agent（classifier-agent）读取工单内容，判断类型：密码重置、软件安装、网络故障、权限申请等。
3. 分诊 Agent 将任务分包给对应的处理 Agent。密码重置类任务走 password-reset-agent，软件安装走 software-install-agent。
4. 每个处理 Agent 拿到任务后，在自己的权限范围内尝试解决。密码重置这类低风险操作可以直接执行；涉及权限变更的，进入审批节点，由申请人的直属主管审批。
5. 处理完成，结果通过 artifact 回写，并附上处理摘要和决策理由。

实现上，分诊 Agent 用的是意图识别，处理 Agent 用的是技能路由，审批节点走的是风险评估 + 审批令牌机制。整个过程 A2A 协议贯穿始终：分诊 Agent 通过 Agent Card 发现处理 Agent 的能力，通过任务生命周期管理跟踪每个子任务的状态，最终的 artifact 汇总成工单的处理报告。

这个系统上线后，我们监控到的数据很直观：约 65% 的工单实现了全自动闭环，剩余 35% 涉及权限变更或更高风险的操作，都会经过至少一层人工审批。而人工审批的数据反过来又成了优化各 Agent 能力的数据源。

5.2 避坑清单：九条拿真实教训换来的经验

真正落地过程中，我们踩过不少坑。挑九个最典型的列出来，每条都是花时间换来的：

• Agent Card 内容没人维护，与真实能力脱节。上线后 Agent 升级了，卡片没同步更新，路由把任务派给了一个已经不存在的技能。处理办法：把 Agent Card 的更新写进 CI/CD 发布流程，Agent 发布新版本时强制要求更新卡片。
• 上下文无限制传递导致性能雪崩。上游 Agent 把所有历史消息一股脑传给下游 Agent，下游 Agent 的上下文迅速膨胀，响应时间成倍增加。处理办法：任务交接只传结构化摘要和必要字段，不要传完整历史。
• 重试导致重复操作。前面说过的幂等性问题，生产环境里真实发生过。处理办法：任务 ID 全局唯一，接收方处理前强制查重。
• 日志里没有决策理由。早期没要求 Agent 记录 decision_reason，出了事只能看到它做了什么，看不到为什么做。处理办法：Agent 开发规范里强制要求高风险动作输出决策理由。
• 权限模型太粗，Agent 一拿到就是全部。处理办法：独立服务账号 + 短时令牌 + 最小权限白名单，这个设计从第一天就要做，后面补非常痛苦。
• 审批流程没有超时机制，任务卡死。处理办法：审批超时自动升级 + 自动拒绝，宁可失败不可滞留。
• 只监控单 Agent 成功率，不监控链路整体。单看每个 Agent 都很健康，链路整体成功率却不高。处理办法：引入链路级监控，统计整个任务从提交到最终完成的闭环成功率。
• 重试风暴把故障 Agent 打死。没有熔断机制时，一个 Agent 报错后，所有分支任务同时重试，把它彻底压垮。处理办法：指数退避 + 熔断 + 健康状态标记，三层防护缺一不可。
• 测试环境和生产环境混用同一目录服务。新测试 Agent 注册后直接出现在生产发现列表里，被路由派了真实任务。处理办法：目录服务做环境隔离，不同环境的 Agent 注册到不同目录命名空间。

5.3 评估体系：怎么判断协同系统做得好不好

没有评估体系，协同系统就是个黑盒。我们最终沉淀出一套四维评估指标，每个维度都直接指导优化方向：

这几个指标不是孤立的。比如人工介入率降得太低，可能意味着风险分级过于宽松，需要结合误操作率一起看。我最早只看链路成功率，后来发现成功率上去了但人工介入率也暴涨，说明系统变稳定了但没有真正解决问题，90% 的活都推给人干了。后来把四个指标放在一起看，才有完整的感知。

坦白说，就算跑通了 IT 工单这一个场景，也只是协同系统落地的第一步。不同业务的协同需求和责任链设计差异很大，关键还是要把 A2A 协议的机制吃透，再根据自己业务流程的实际情况去设计方案。我自己的体会是，设计协同系统时，先把责任链画出来，再写路由和编排代码，这个顺序一定不要反。责任链决定了你的权限模型、审批节点、审计日志的骨架，有了骨架，协同引擎才知道任务该怎么流、故障该怎么兜。反过来做，先堆功能再补责任设计，到时候返工的成本是非常高的。