企业级 Agent 协同系统设计——从 A2A 协议到人机责任链

摘要

企业采用 Agent 的真正瓶颈从来不是"单个 Agent 有多聪明"，而是"多个参与者（人、Agent、系统）如何协同"。本文提出协同四象限模型（P2P / P2A / A2P / A2A），并以 ooderAgent 的真实实现为证据，论证一个核心命题：

协同的本质，是责任的"可移交、可追溯"属性。每一次象限之间的跃迁都是一次责任移交；而每一次移交都必须同时完成三件事——上下文传递、权限校验、问责记录（CAA 三元组）。

ooderAgent 把这个抽象模型变成了可运行、可持久化、可审计的工程系统——从流程引擎的 HUMAN 暂停节点，到 A2A 协议服务的 MQTT 跨节点桥，再到权限行（RT_ACTIVITY_PERSON）状态机，构成了一条完整的责任链基础设施。

需要强调：协同四象限并不是"只能长在某套代码上"的私有设计。只要一个系统能表达三件事——"暂停下来等人"、"把等待人工的结果接回来"、"给每一次动作留痕"——这套模型就能投影上去。因此本文把 ooderAgent 的实现当作一份可移植的设计蓝图来讲解，而不是对某个旧系统的考古记录。

图 1　原理：每一次象限跃迁都是一次责任移交，须同时完成 CAA（上下文-权限-问责）三元组

第一部分 问题域：为什么企业级 Agent 试点会卡在协同

1.1 单一 Agent 的三重天花板

结论：企业场景要的是多参与者协同，而不是一个全知全能的 Agent。

1.2 企业真实诉求：三种跨界

• 跨部门：一次报销涉及员工、经理、财务、出纳——责任在人之间流转（P2P）
• 跨系统：一次决策要调用 ERP、CRM、OA、数据库——责任在人、系统、能力之间切换（P2A）
• 跨人机边界：Agent 自动化 80%，20% 需要人签字——责任来回振荡（A2P / P2A）

1.3 协同的三重鸿沟

• 语义鸿沟：Agent A 说的"客户"和 Agent B 说的"客户"是同一个吗？上下文如何无损且可控地传递？
• 信任鸿沟：这次操作是谁授权的？身份如何确立？如何阻断越权放大？
• 时间鸿沟：Agent 毫秒级完成，人可能要数天。长运行的异步状态如何保存与恢复？

1.4 主流方案盘点与局限

结论：现有方案各自解决一小块。企业落地需要一套统一框架，既能表达自动化的 Agent 间流转，又能表达人机责任往返。

第二部分 理论框架：协同四象限模型

2.1 象限定义

2.2 一条责任梯度，而非平面分类

P2P（人全程持有）→ P2A（人发起、机器执行）→ A2P（机器产出、人裁决）→ A2A（机器自闭环）。

一个业务过程会反复穿越全部四个象限。报销示例：员工提交（P2A：委派 Agent 解析发票）；Agent 发现金额异常（A2P：请求人工确认）；经理审批（P2P）；审批通过，自动记账（A2A）。

2.3 核心命题：CAA 三元组

每一次象限跃迁都是一次责任移交。只有以下三者同时成立，移交才有效：

1. 上下文传递：接收方获得足以承担责任的上下文。给得太少——责任悬空；给得太多——安全与性能风险。
2. 权限校验：发送方是否有权移交？接收方是否有权接收？未授权的移交必须被阻断。
3. 问责记录：移交这件事本身必须被记录——谁在何时、基于什么，把责任交给了谁。

三者合称协同三元组（上下文-权限-问责，CAA）。ooderAgent 的设计就是 CAA 的工程化展开。

2.4 象限跃迁矩阵

图 2　一个报销流程穿越全部四个象限——自动化程度逐级抬升

第三部分 实现解剖：ooderAgent 中的四个象限

3.0 分层底座：南北向架构

SDK 采用南北向分层架构（agent-sdk NORTHBOUND_SOUTHBOUND_ARCHITECTURE.md）：

• 核心抽象层：统一接口与模型（连接、身份、消息、权限、事件）
• 南向服务层：对内、简单确定——HTTP、MCP 端点、JWT、离线操作、确定性网络
• 北向服务层：对外、复杂灵活——UDP/P2P、Gossip、复杂路由、域级安全、P2P 加密
• 互联层：命令桥接、异步状态管理、事件驱动同步

为什么重要：南向保证信任域内的确定性协同；北向处理跨信任域的、概率性的、联邦化自组织协同。四个象限天然落在这条切分上。

3.1 P2P——人的责任链（完全人工）

定义：人到人、完全人工流转——发送、委派、撤回、退回、抄送、会签、已读办结。

实现载体：BPM 引擎 WorkflowClientServiceImpl + IOTRightEngine（RT_ACTIVITY_PERSON 权限行）。五个子引擎共用一个事务外观：

P2P 责任操作族——业务语义是第一视角，状态机是实现手段：

底层原理：上述每一种操作最终都落在"当前办理人/阅读人"行的归档与重建上（详见 5.2 权限行状态机），而不是改一个状态字段。因为责任在"行"上而不在"字段"上，退回、撤回、追责才真正成立。

图 3　审批待办界面示意：操作条由服务端按当前办理权生成（P2P 责任链）

3.2 P2A——委派执行者，立即执行

定义：人发起，选择执行者（技能/能力/LLM/Agent），立即执行。

实现要点：

• 北向通道：一条面向"人发起"的委派队列，提供同步投递与异步投递（异步返回回执，可等待执行结果）。它同时服务两类人机消息——用户到 Agent（P2A）与用户到用户（P2P），并有独立的度量计数。
• 执行路由：到 TASK（按技能执行，技能注册表以 skillId 定位执行器）或 LLM_AGENT（直接驱动大模型代理）
• 执行者选择四要素：skillId + activityToolIds、capabilityRefs、llmPluginRef（llmMode）、performerList（UnifiedPerformerConfig：USER/AGENT/LLM/REMOTE_MACHINE）
• 持久化：AgentEngine 维护 RT_ACTIVITY_AGENT（启动时 AGENT_STATUS=WAITING；转发删除并插入候选；结果经 persistAgentExecutionResult 持久化；归档到 RT_ACTIVITYHISTORY_AGENT）

P2A 设计教训：委派给执行者时，"选了什么技能或 Agent、为什么"这件事本身必须作为一次可审计操作被记录——否则责任链里就有一个沉默环节。

3.3 A2P——Agent 产出由人裁决（人在环内）

定义：Agent 执行，人复核 / 确认 / 补表单 / 委派。

实现要点：

• 暂停语义：ActivityDispatcher.executeHumanActivity——活动进入 PAUSED，置 _pausedHumanActivityId，注入 HUMAN 模式上下文（HumanContextHelper），发出 HUMAN_CONFIRM_REQUIRED SSE
• 操作集（单一来源）：HumanOperationEngine.getAvailableOperations + resolveOperationPermissions → HumanBehaviorAssembler 把 availableOperations 与 operationPermissions 同时挂到 human_confirm 与 flow_step(paused) 事件上
• 恢复路径：/confirm（FORM 校验、FORM_SUBMIT → CONFIRM 归一化、必填字段后端强制）与 /human-op（特殊发送、撤回、退回、委派、审批、异常干预）→ ResumeService.resumeActivity → RouteToEngine
• 异常干预：SkillFlowEngine.handleHumanEscalation / HumanEscalationService（合成干预活动）
• 强制人工护栏：强制置顶横幅（rad-chat-human-banner-mandatory）、服务端下发 availableOperations（客户端无默认值）、超时经 fallbackStrategy 兜底（auto_accept 或 ESCALATE_HUMAN）

设计边界（与具体引擎无关）：HUMAN 不是"底层引擎里的某种特殊节点"，而是协同模型的一等参与者。它的四种模式——确认（CONFIRM）、补单（FORM）、审批（APPROVAL）、转派（DELEGATE）——由场景层解释并驱动；被调用的流程服务只需要回答一个问题："这份单据当前停在哪个办理状态、由谁持有"。决策逻辑与持久化分离，业务规则就能在不更换底层流程引擎的前提下独立演进——这是"模型可移植"的关键。

A2P 业务规则：凡涉及钱、合同、对外承诺的活动，默认必须停在人工确认点。自动通过只能在流程配置里被显式声明——任何"超时自动放行""强度参数"都不得越过这条业务边界。理由很朴素：让一个本该把关的人失去把关机会，比流程慢几小时严重得多。

图 4　HUMAN 强制人工界面示意：不可跳过的确认与人工路由选择（A2P）

3.4 A2A——Agent 到 Agent，完全自动化

实现分三层：

1. 事件自活（引擎内）：ActivityDispatcher.executeAgentEventActivity——AGENT_EVENT 活动注册订阅，进入 EVENT_WAITING（不阻塞），预注册事件分支；事件到达时由 AgentEventBridge 恢复活动；主线经 RoutingService PARALLEL_TRIGGER 旁路。定时器与 cron 触发形成自活闭环（Bridge 自产触发事件、本地订阅匹配、resumeActivity）。
2. A2A 协议服务（A2AProtocolService / A2AProtocolServiceImpl）：消息传递、处理器注册表、会话、路由规则、组广播、统计（totalMessages、activeConversations、registeredAgents、routingRules）。
3. MQTT 跨节点桥（E4 消息系统）：连接集群 EMQX；订阅 ooder/p2p/{agentId}/inbox（定向）与 ooder/event/A2A/#（组广播）；只处理 protocol=a2a 的载荷；优雅降级——MQTT 故障绝不阻塞本地 A2A。

A2A 设计教训：完全自动化的协同需要三样东西同时到位——事件自活机制（让 Agent 不等即动）、带请求-响应闭环的消息协议（让 Agent 会对话而不是只广播）、以及一座让流程引擎以对等节点身份接入 Agent 网络的桥。

第四部分 跨节点、跨域协同机制（深潜）

4.1 跨节点与跨域指什么

• 跨节点：多套流程服务与 Agent 实例分布在多主机、多可用区，同一套协议要在实例之间完成寻址、投递与应答——无论它们跑在开发机、生产集群还是公网接入层
• 跨域：多个 SceneGroup（业务域，如报销域与采购域）、信任域（内网服务与公网 Agent）、网络区（内网与 DMZ）

4.2 寻址模型：五类受众

AgentEventConfig.AudienceType 定义了五层寻址模型：

设计教训：寻址粒度映射信任粒度——SAME_PROCESS 继承流程信任；BROADCAST 需要最强的把关。

4.3 传输：MQTT 主题与协议信封

A2A MQTT 桥在规划好的主题空间中订阅与发布：

信封：protocol=a2a、version=1.0，消息体含 messageId、conversationId、sceneGroupId、fromAgentId、toAgentId、messageType、payload、priority、timestamp、headers、traceId。

跨节点请求-响应闭环：sendMessage 发布 TASK_REQUEST，在 pendingRequests 中以 requestId 为键存一个 CompletableFuture<A2AResponse>；远端处理并回 TASK_RESPONSE + header.requestId；桥的 dispatchMqttMessage 完成该 future。调用方阻塞或在 future 上恢复——在发布-订阅之上实现了完整的跨节点 RPC。

降级：broker 连接失败置 mqttTransport=null，退化为进程内处理器 + 消息队列的本地 A2A。绝不阻塞流程。

4.4 上下文传递：四种模式（解决语义鸿沟）

上下文随 A2ACommand.contextTransfer 传输：

上下文四个核心部分：用户上下文（身份、角色、偏好；默认排除凭证）、知识上下文（知识库引用、RAG 结果）、函数上下文（可用工具）、记忆上下文（会话历史）。

命令示例：

A2ACommand：header（commandId、commandType=LLM_CONTEXT_SHARE、sourceAgent=agent-a、targetAgent=agent-b），contextTransfer（transferMode=SELECTIVE、includedParts=USER KNOWLEDGE FUNCTIONS、contextReference 含 contextId、skillId=recruitment-skill、sessionId=sess-xxx）

图 5　上下文传递四种模式：传多少、传什么由业务场景决定

4.5 网络底座：P2P Gossip 自组织

MQTT 之下，北向层还提供自组织 P2P 网络（agent-sdk network/p2p）：

• PeerDiscovery：UDP 广播发现，带对等超时、清理与发现监听
• GossipProtocol：跨节点的流行病式信息扩散
• UdpGossipTransport：gossip 消息的 UDP 传输
• DhtNode：分布式哈希表，做去中心化查找

为什么需要两套传输？EMQX 上的 MQTT 在信任边界内提供受管、可靠、有序的投递；Gossip 与 UDP 在动态或不可信边缘提供无托管、有韧性、自组织的发现。企业部署通常两者并用：EMQX 在集群内，Gossip 在边缘。

4.6 跨实例委派：凭"责任契约"远程启动流程

把跨实例委派想成企业里的"转办单"：它不能只是一句话，而必须是一份单据。ooderAgent 用四个要素构成这份契约：

• 出处要素：父流程实例（parentProcessInstId）与流程定义（flowDefinitionId）——知道这笔活从哪个流程来、按哪套规则办；
• 内容要素：共享上下文引用（contextVfsRef）与归属会话（ownerConvId）——接收方与发起方拿到的是同一份单据和上下文；
• 定位要素：注册表把契约路由到目标节点，目标节点按需实例化子流程（startExecution）并返回子流程实例标识；
• 存证要素：按 requestId 落一份持久化契约（a2a/{requestId}.json）到个人 VFS——节点重启、网络断开之后，仍能凭契约回放接续。

业务启示：跨实例委派不是"发一条消息"，而是"凭一份可持久、可回放的单据远程启动一个流程"。这保证跨部门、跨系统的单据在任何时刻都答得上三问：办到哪一步了、由谁在办、依据是什么。

图 6　结构：流程决策层经事件桥与跨节点协议服务接入 Agent 网络

第五部分 安全与治理：守住责任链

5.1 身份三元组

每一次协同 Operation 必须携带 USERID（操作的人）、OPERATOR_ID（执行主体）、AGENT_ID（执行体）。服务端禁止自报身份——身份必须来自已认证会话，绝不来自请求载荷。

5.2 权限行状态机：责任可逆的工程落点

单据的"办理权"不落在流程状态字段上，而落在独立的权限行上（RT_ACTIVITY_PERSON）。每一行回答三件事：谁能办（PERSON_ID）、以什么身份办（RIGHT_GRP_CODE：办理人 PERFORMER / 发起人 SPONSOR / 阅读人 READER / 历史办理人 HISTORYPERFORMER）、办到哪一步（PERSON_ACTIVITY_STATE：待办 WAITING / 正在办理 CURRENT / 办结 FINISH / 已读 READ / 已读办结 ENDREAD），外加一个供回退使用的恢复锚点（LAST_RIGHT_GRP）。

于是"退回"与"撤回"不是改状态，而是恢复权限行：撤回时把锚点行恢复为当前办理人；退回时从历史办理人行重建待办。行级承载让责任链真正可逆——这也是财务"冲正"、合同"收回"、单据"驳回重报"这些业务动作在工程上的统一落点。

图 7　办理权行状态机：责任移交与退回恢复都发生在"行"上

5.3 问责：操作记录

每一次协同动作都以操作记录（操作人、动作、对象、载荷）落库，同时写入个人文件空间的消息流（会话消息、人工决策、跨节点记录三类）与本地审计库。审批意见、委派理由、路由选择一并进入会话记录——事后追溯时顺着会话记录逐条翻看，责任链便完整可查。

5.4 上下文安全

SELECTIVE 模式默认排除 SECURITY_CREDENTIALS 与 INTERNAL_STATE。审批结果与审计轨迹落入流程上下文，而不进入面向用户的记忆。

第六部分 部署全景（面向实践）

6.1 拓扑

公网入口：subdomain.heb10010.com 端口 9890，经云 NAT 到内网 nginx 81，再分发到内网主机上的服务网格。

服务清单：studio 8099（流程决策与编排、会话、流程设计器）、aiserver 9004 与公网 9890（集群中心：认证、NLP/LLM、模板服务）、bpm-server 5340（业务流程持久化服务：单据实例 EI + 权限 RT 表）、vfs-namenode 5342 与 vfs-store 5341（虚拟文件系统）、org 5332（身份）、emqx 1883（MQTT broker，A2A 桥加集群 gossip）、lucene 5343（检索）。

6.2 象限到组件映射

6.3 启动顺序与依赖

1. 数据与消息层：MySQL 或 SQLite、EMQX
2. org 身份服务，然后是 aiserver 集群中心
3. vfs 先 namenode 后 store
4. bpm-server 业务流程持久化服务
5. studio 流程决策层与 UI，等待上述全部就绪
6. EMQX 就绪后 A2A MQTT 桥再接入；暂不可用则本地模式优雅降级

6.4 部署视角必须回答的业务问题

真正让协同系统上线后"不好用"的，往往不是 Agent 聪不聪明，而是下面六个业务问题在设计期没有被回答：

1. 跨部门单据，谁有权看、谁有权办？ 权限必须落在"单"上而不是"页面"上——同一页面、不同单据行能见到的操作不同（行级权限，见 5.2）。否则一跨部门就出现"越权"或"看得见办不了"。
2. 超出授权额度的单，如何分级？ 按金额与影响面分级路由：小额自动通过，超限强制升级到有对应授权的人；额度边界写进流程定义，而不是靠某个人自觉拦截。
3. 该确认的人不在（休假、出差、离职）怎么办？ 待办要可转移、可超时升级：可转派、可设委托，超时自动升级到上级或应急处理人，避免整条链卡死（见 3.3 的强制人工与超时兜底）。
4. 单据跨系统、断网、重启后还能不能接着办？ 关键单据必须有持久契约与回放能力（见 4.6）。业务不在乎技术细节，只在乎"我的单不能丢"。
5. 出了事找谁？ 每一次办理动作都记录"谁、何时、做了什么、依据是什么"，形成可回放的审计链（见 5.3）——这是业务追责与冲正的前提。
6. Agent 的自动动作会越权吗？ 机器人发起的一切写操作都要经过与服务端同一套权限校验；自动放行的边界只能由业务显式配置，而不是由模型"觉得可以"。

把这六个问题放进验收清单，比盯着单点技术指标更能判断一套协同系统是否真的能上生产。

图 8　部署拓扑与象限到组件的映射

第七部分 上线前业务闭环清单与雷区

从业务视角出发的闭环检查清单——每一条都对应一次责任移交的 CAA 三元组：

1. 四个切片可对得上：本地入口（单据从哪发起）、流程定义（按哪套规则）、远端状态（单据当前停在谁的待办里）、会话留痕（沟通过程可查）——随时能回答"这份单现在是什么状态"。
2. 界面上能点的、后台都有真实现：流程定义声明的每一步都有真实动作与记录；不存在"按钮能点、点了没下文"的假能力。
3. 用户看到的操作等于他有权限的操作：操作条只由服务端权限计算下发，无权限就不渲染，避免"点了没反应"或误以为自己已批过。
4. 服务重启不丢单：委派、退回、跨实例委派在重启后都能从记录恢复，业务不中断。

最容易踩的四个雷区：

• 把"自动通过"当默认：该人工确认的单被静默放行，用户根本没机会把关。原则：默认人工暂停，自动通过必须由业务显式声明。
• 操作条与真实权限"两张皮"：客户端自己拼按钮、服务端另有一套权限，用户点了没反应。原则：服务端权威，无数据不渲染。
• 单据不带契约裸奔：跨系统传递的单据既无引用也无存档，断网即丢。原则：每个跨节点动作按 requestId 落一份持久化记录。
• 业务术语各说各话：同一个词在不同部门含义不同（如"FC"在财务是金融能力、在研发是函数调用），机器理解与人工理解对不上。原则：全局业务术语表，口径唯一。

第八部分 结论与演进

1. 象限模型的价值：把协同从一句含糊的口号变成一份逐跃迁的检查清单（CAA 三元组），并且每个类型都有对应的工程载体。
2. ooderAgent 的取舍：决策本地化、持久化远端——业务决策层保持权威，底层流程服务只做状态镜像；HUMAN 模式停留在场景层，不绑定任何引擎的内部节点模型；A2A 协议服务优雅降级为本地模式，而不是阻塞流程。这套取舍的意义在于：模型可移植到任何能满足"暂停等人、接回结果、动作留痕"的流程底座上。
3. 演进方向：事件自活与分支合并为统一的路由语义；前端展示信息全面迁移到服务端下发的注册表，图标、文案、可用操作单一来源；子流程状态经生命周期事件桥实时回传父流程；跨实例委派一律按 requestId 携带持久、可回放的责任契约。

结语：四象限不是一套分类法——而是一套纪律。每当你为一个 Agent 新功能写代码，先问自己：这落在哪一次象限跃迁上？它完成 CAA 三元组了吗？如果完成了，它就能在生产里活下来；如果没有，它就会成为责任链上下一个缺失的沉默环节。