ooderAgent 多机多人多 LLM 协同统一方案

ooderAgent多机多人多 LLM 协同统一方案

从割裂的 HUMAN 与 McpAgent 机制，到统一的企业级协同工作平台 — 产品架构与设计构思

📑 目录

1. 协同工作的时代背景
2. McpAgent 通讯机制剖析
3. HUMAN 与 McpAgent 机制对比
4. 产品架构构思：四层统一模型
5. L1 配置层：统一办理人描述
6. L2 路由层：统一分派引擎
7. L3 协同服务层：五种协同策略
8. L4 UI 层：三色任务卡
9. 会签/或签/顺序协同
10. 多机多端拓扑
11. 典型协同场景
12. 产品演进思考

🎯一、协同工作的时代背景

1.1 协同范式的三次演进

企业级协同工作经历了三次范式演进，每一次都伴随着"办理人"概念的扩展：

📈 协同范式演进

• 1.0 纸质协同（1990s）：办理人 = 人。公文流转、签批单，依赖物理传递
• 2.0 数字协同（2000s-2010s）：办理人 = 人 + 系统。OA/BPM 系统兴起，待办列表成为统一入口，但系统任务和人工作业仍然割裂
• 3.0 智能协同（2020s）：办理人 = 人 + Agent + LLM + 远程机器。AI 能力深度融入业务流程，协同的边界从组织内扩展到跨机跨组织

我们正处在 3.0 智能协同 的黎明期。在这个时代，一次审批可能需要人确认、Agent 巡检、LLM 分析三者会签；一次代码合可能需要人评审、自动化 Agent 执行测试、LLM 生成变更说明三者协同。传统的"待办列表只服务人"的假设已经失效。

1.2 为什么需要统一

在 3.0 时代，企业内部的协同系统往往同时存在两套并行的机制：

• HUMAN 节点机制：成熟的 BPM 工作流，支持待办、会签、或签、委派，但只服务"人"
• McpAgent 机制：远程多机 Agent 通讯，支持 A2A 协议、跨机调度，但任务不进待办列表，用户无感知

这两套机制在配置、路由、待办、UI 上完全割裂，导致一系列体验问题：

⚠️ 割裂带来的痛点

• 用户无感知：Agent 任务不进待办列表，用户在工作台看不到 Agent 正在执行的任务
• 协同策略缺失：Agent 节点无会签/或签/顺序办理机制，无法支持多 Agent 协同决策
• 办理人推导割裂：HUMAN 用 PerformerDerivationService，Agent 硬编码 agentId
• 权限上下文不完整：routeTo 接口只填充 USERID，未传递下一办理人
• 配置字段不对齐：Agent 配置缺 endpoint/protocol/delegateStrategy 字段

1.3 产品愿景

本方案的产品愿景是：让所有类型的协同任务在同一套框架下可见、可控、可协同。

具体而言，我们希望构建一个统一协同平台，使得：

• USER 人工任务、AGENT 自动化 Agent 任务、LLM 智能分析任务、REMOTE_MACHINE 远程机器任务，四类办理人在同一待办列表中可见
• 五种协同策略（单人/会签/或签/顺序/候选池）跨办理人类型通用 — 可以"1个人 + 1个Agent + 1个LLM"三方会签
• 用户在工作台统一掌控所有协同进度，不再需要在多个系统间切换

📡二、McpAgent 通讯机制剖析

McpAgent 采用 三层通讯架构，实现远程多机自治与 Agent 间协同。

图 1 · McpAgent 三层通讯架构 — L3 A2A 协议 / L2 事件桥接 / L1 REST 自治

McpAgentNode 启动后形成完整的自治闭环：

// 启动序列
启动 → registerToNetwork       // 1. 向 AiServer 注册节点
     → login                   // 2. 获取 sessionId
     → reportSkills            // 3. 上报已安装 Skill 列表
     → reportResourceStatus    // 4. 上报 CPU/内存
     → joinSceneGroup          // 5. 加入场景组
     → startHeartbeat (10s)    // 6. 心跳保活
     → startResourceReporter (60s)
     → startCommandProcessor (1s poll)

// 运行期：远程命令异步处理
commandQueue.poll() →
  INSTALL   → SkillInstallProcessor.install()
  UNINSTALL → SkillInstallProcessor.uninstall()
  INVOKE    → 本地 Skill 执行 → A2A 回调
  REPORT    → 状态同步

// 停止序列
停止 → leaveSceneGroup → deregisterFromNetwork → VfsSyncService.stopSync

AgentEventBridge 五种受众模式

AGENT_EVENT 节点执行时，通过 AgentEventConfig.audienceType 指定事件订阅范围：

⚖️三、HUMAN 与 McpAgent 机制对比

图 2 · HUMAN 与 McpAgent 机制对比矩阵 — 优势互补但能力割裂

🔍 核心洞察

HUMAN 方案在待办管理、协同策略、办理人推导、UI 可见性上完善，但缺乏远程能力；McpAgent 方案在远程多机、A2A 协议上独有优势，但无待办、无协同策略、UI 割裂。两者正好互补，是统一的天然基础。

🏛️四、产品架构构思：四层统一模型

采用 四层统一模型，自下而上逐层抽象：

图 3 · 四层统一协同架构 — 自下而上逐层抽象，每层独立演进

⚙️五、L1 配置层统一

UnifiedPerformerConfig 统一结构

扩展 ActivityExtensionConfig.performerList 结构，同时支持四种办理人类型：

{
  "performerType": "USER | AGENT | LLM | REMOTE_MACHINE",
  "performerId": "zhangsan | mcp-node-01 | gpt-4 | remote-studio-01",
  "performerName": "张三 | NLP节点01 | GPT-4 | 远程工作室01",

  // 远程通讯配置
  "endpoint": "http://192.168.1.10:8099",
  "protocol": "LOCAL | HTTP_REST | A2A | MCP_STDIO | MCP_SSE | LLM_API",
  "auth": {
    "type": "SESSION | TOKEN | API_KEY | NONE",
    "credentials": "${vault:agent-cred-01}"
  },

  // 协同策略（与 HUMAN 对齐）
  "delegateStrategy": "SINGLE | SIGN_OFF | OR_SIGN | SEQUENTIAL | CANDIDATE_POOL",
  "candidateUsers": ["user1", "user2"],
  "candidateGroups": ["patent-examiner"],

  // 类型特化配置
  "llmConfig": { "provider": "openai", "model": "gpt-4", "temperature": 0.7 },
  "agentConfig": { "skillId": "patent_form_review", "timeout": 30000 },

  // SLA 管理
  "sla": {
    "dueTime": "2026-07-22 18:00",
    "priority": "HIGH | MEDIUM | LOW",
    "escalation": { "onTimeout": "notify_manager", "escalateTo": "lisi" }
  }
}

AgentConfigDTO 字段补齐

在 AgentConfigDTO.java 中补齐 8 个字段，使其与 HUMAN 节点的 performerList 对齐：

🔀六、L2 路由层：统一分派引擎

resolveUnifiedPerformer — 统一办理人推导

新增 RouteToEngine.resolveUnifiedPerformer() 方法，按 performerType 统一分派：

public Map<String, Object> resolveUnifiedPerformer(ProcessInstance instance,
                                        ActivityDefinition actDef) {
    List<Map<String, Object>> performerList = extractPerformerList(actDef);
    if (performerList == null || performerList.isEmpty()) {
        return defaultUserPerformer(instance);  // 默认当前用户
    }

    if (performerList.size() == 1) {
        return performerList.get(0);  // 单一办理人
    }

    // 多办理人：根据 delegateStrategy 决策
    String strategy = (String) performerList.get(0).getOrDefault("delegateStrategy", "SINGLE");
    switch (strategy.toUpperCase()) {
        case "SIGN_OFF":     // 会签：返回全部办理人
        case "OR_SIGN":      // 或签：候选池
        case "SEQUENTIAL":   // 顺序：返回序列
            return buildMultiResult(strategy, performerList);
        case "CANDIDATE_POOL":
            return buildPoolResult(performerList);
        default:
            return performerList.get(0);
    }
}

executeRouteToWithAssignee — 增强路由入口

在原 executeRouteTo 基础上增加 nextAssigneeUserId 参数，传递给 BPM 引擎：

public Map<String, Object> executeRouteToWithAssignee(ProcessInstance instance,
                                           String fromActivityId,
                                           String toActivityDefId,
                                           String nextAssigneeUserId) {
    // null 时回退到当前用户（向后兼容）
    String resolvedAssignee = nextAssigneeUserId != null
        ? nextAssigneeUserId
        : instance.getUserId();

    // 委托给 RemoteWorkflowBridge → WorkflowClientServiceImpl.routeTo
    // fillInUserID 会将 resolvedAssignee 写入 RightCtx.USERS / CONTEXT_WAITPERFORMER
    return workflowBridge.routeTo(
        remoteActivityInstId, toActivityDefId, resolvedAssignee);
}

fillInUserID 增强 — 补充下一办理人 CTX

在 WorkflowClientServiceImpl.fillInUserID() 中补充 USERS / PERFORMERS / CONTEXT_WAITPERFORMER 字段：

✅ 向后兼容设计

仅在 ctx 未显式设置对应字段时才填充默认值（当前用户），避免覆盖外部传入的指定办理人。这意味着：

• 旧代码不传 ctx → 默认当前用户（与原行为一致）
• 新代码传 ctx.put(RightCtx.USERS, "zhangsan") → 尊重外部指定

🤝七、L3 协同服务层 — UnifiedCollaborationService

新建 UnifiedCollaborationService.java，将 Agent/LLM 任务也纳入 TodoService 管理，让用户在工作台可见所有类型的协同任务。

核心枚举设计

统一任务创建流程

图 4 · 统一任务创建流程 — 按 performerType 分派，统一进 TodoService

🎨八、L4 UI 层：三色任务卡

工作台统一展示人/Agent/LLM 任务，用色彩区分类型，用图标点缀：

图 5 · 工作台三色任务卡 — 蓝(人)/橙(Agent)/紫(LLM)/黄(会签组)

🎨 视觉规范

• 👤 蓝色 人工任务（USER）
• 🤖 橙色 Agent 任务（AGENT）
• ✨ 紫色 LLM 任务（LLM）
• 👥 黄色 会签/或签组（MULTI）
• 🌐 青色 远程工作室任务（REMOTE_MACHINE）

🔗九、会签/或签/顺序协同

会签（SIGN_OFF）— 多办理人并行，全部完成才能路由

或签（OR_SIGN）— 任一完成即路由

使用 AtomicBoolean.compareAndSet(false, true) 实现抢先式完成，第一个完成者胜出，其他自动取消：

public boolean notifyOrSignTaskCompleted(String groupId, String winnerTodoId, String winnerAssigneeId) {
    AtomicBoolean completed = orSignCompleted.get(groupId);
    boolean isWinner = completed.compareAndSet(false, true);
    if (isWinner) {
        log.info("Or-sign winner: {}, todoId={}, assignee={}", groupId, winnerTodoId, winnerAssigneeId);
        // TODO: 触发 routeTo 下一节点
        // TODO: 取消同组其他 todo（status → CANCELLED）
        orSignCompleted.remove(groupId);
    }
    return isWinner;
}

顺序办理（SEQUENTIAL）— 链式推进

第一个办理人完成后，从 metadata 中读取下一个办理人，自动创建新的 todo：

图 7 · 顺序办理流程 — 链式推进，每步完成后自动创建下一步

🌐十、多机多端拓扑

Agent 网络拓扑视图，展示远程多机节点状态：

图 8 · Agent 网络拓扑视图 — 多机多端节点状态可视化

🎬十一、典型协同场景

场景 1：跨机协作（人 + Agent）

图 9 · 跨机协作场景 — 人/Agent/LLM 混合办理，跨机器跨网络

场景 2：会签协同（多人 + 多Agent + LLM）

实质审查节点配置 delegateStrategy: SIGN_OFF，3 个办理人并行：

1. 创建会签组：调用 createSignOffTask(groupId, [用户A, GPT-4, mcp-node-01], ...)
2. 并行执行：👤 用户A 收到待办（ASSIGNED），点击"接受"→"完成"，todo 状态 → COMPLETED✨ GPT-4 流式调用启动（IN_PROGRESS），完成后回调 → todo 状态 → COMPLETED🤖 mcp-node-01 通过 A2A 收到调用（IN_PROGRESS），事件回调 → todo 状态 → COMPLETED
3. 同步等待：每个完成时调用 notifySignOffTaskCompleted(groupId, todoId)，CountDownLatch.countDown()
4. 全部完成：latch 归零，触发 flowEngine.resumeActivity(activityInstId, {signOffCompleted: true})
5. 路由下一节点：流程引擎自动推进到下一个活动

🗺️十二、产品演进思考

12.1 设计哲学回顾

回看整个方案的构思过程，我们遵循了三条设计哲学：

✨ 三条设计哲学

• 统一不等于同一：四类办理人统一到同一框架，但保留各自语义差异（USER 需要认领、AGENT 自动执行、LLM 流式输出、REMOTE_MACHINE 跨机派发）
• 渐进式增强：不破坏现有 HUMAN 节点的成熟路径，新方法是可选入口，performerList 为空时回退到当前用户
• SPI 扩展点优先：外部协作能力（Agent 派发、LLM 调用、跨机调度）通过 SPI 接口暴露，空桩保证主流程可跑通，真实实现可按需替换

12.2 从"工作流引擎"到"协同平台"

传统 BPM 系统的核心是工作流引擎 — 它回答"流程下一步走到哪里"。而 3.0 时代的协同平台需要回答更复杂的问题：

这个转变的本质是：把"办理人"从单一的人，扩展为一个可寻址、可调度、可协同的抽象实体。

12.3 架构的可持续性

四层架构的设计考虑了长期的可持续演进：

• L1 配置层：通过 Map 结构的协同字段，未来可以无侵入地扩展新的办理人类型（如 IoT 设备、外部 SaaS 服务）
• L2 路由层：routeToWithAssignee 的 default 回退设计，保证新旧路由逻辑可以并存
• L3 协同服务层：五种策略基于通用的 AssigneeInfo 模型，新增策略只需扩展 DelegateStrategy 枚举
• SPI 扩展点：AgentDispatcher / LlmInvoker / RemoteMachineDispatcher 三个 SPI 隔离了外部系统变化，底层通讯协议升级不影响协同服务

12.4 产品价值的最终落点

技术架构的最终价值在于用户体验。在这个方案下，一个项目经理的典型工作日是这样的：

👤 用户故事：项目经理的一天

早上打开工作台，看到 12 条待办：3 条人工审批（蓝色徽章）、5 条 Agent 巡检报告（橙色徽章，已完成 3 条）、2 条 LLM 分析任务（紫色徽章，正在生成）、2 条远程机构建任务（青色徽章，排队中）。

他不需要打开 Agent 管理台看巡检状态，不需要打开 LLM 对话窗看分析进度，不需要 SSH 到构建机看构建日志 — 所有协同任务在同一列表中可见、可控。

这就是 3.0 智能协同时代的工作台。

★ 多机多人多 LLM 协同统一方案 v1.2 · 2026-07-21 · 产品设计与架构构思

本文档由 ooderAge 工程团队编写 · 转载请注明出处