一、产品定位
当业务流程跨越多个系统、多个专业角色、需要质检与审批时，单一 Agent 必然触顶——Vodafone、Schneider Electric 等企业的规模化经验表明：复杂场景需要任务专用 Agent 分工协作，而非一个「万能员工」。
长境 Multi-Agent 协作引擎（CJ-MAE）是面向此类场景的编排与运行底座，提供 Agent 注册发现、异步消息总线、任务分解与冲突仲裁、Checkpoint 持久化、人工接管（HITL）及全链路 Trace，支持 Supervisor / Pipeline / Swarm 三种拓扑，并可对接企业 BPM、Kafka、审批流与 MCP/A2A 协议。
二、三种协作拓扑详解
2.1 Supervisor（主管模式）
Hub-and-Spoke 结构：Supervisor Agent 负责意图理解、任务分解、子 Agent 委派、结果质检与汇总。适合「分析→查数→风控→写报告」等需统一质量把关的流程。ForgeFlow、LangGraph 官方 Multi-Agent 模板均采用此模式。
执行示例：用户「生成 Q3 风险报告」→ Supervisor 派 Research Agent 检索 → Analytics Agent SQL 取数 → Compliance Agent 合规审查 → Writer Agent 成稿 → Supervisor 终审。
2.2 Pipeline（流水线模式）
固定 DAG，节点顺序执行，前一节点输出为后一节点输入。适合 ETL、工单流转、标准审批链。支持条件分支（金额>100万走加审）、并行分支（同时查库存与物流）。
2.3 Swarm（蜂群模式）
多个 Agent 并行探索同一问题，最后投票或 LLM 合并结论。适合策略 brainstorm、方案比选、创意生成。需设置最大并行度与 Token 预算，避免成本失控。
三、引擎核心组件
| 组件 | 技术实现 | 作用 |
|---|---|---|
| 注册中心 | etcd / PostgreSQL | Agent 能力、版本、SLA 注册 |
| 消息总线 | Redis Streams / Kafka | 异步事件、任务队列、Dead Letter |
| 编排器 | LangGraph StateGraph | 状态机、interrupt_before HITL |
| Checkpoint | PostgreSQL Saver | thread 级快照、失败恢复 |
| 共享记忆 | Redis + pgvector | 会话/任务/组织三级记忆 |
| 仲裁器 | 规则 + LLM Judge | 多 Agent 结论冲突处理 |
| 观测 | OpenTelemetry | Agent 拓扑图、耗时、Token |
四、可靠性设计
- 至少一次投递：消息 ACK + 重试 + 幂等 tool_call_id
- 超时熔断：单 Agent 超时自动 Fallback 或升级人工
- Checkpoint 恢复：LangGraph pending writes 保留已成功节点，失败仅从断点续跑
- 预算守卫：任务级 Token/费用上限，触顶暂停并告警
- Circuit Breaker：下游工具连续失败时打开熔断，避免雪崩
五、Human-in-the-Loop（人工接管）
对转账、合同签署、数据删除等敏感操作，引擎在 LangGraph 节点设置 interrupt_before，任务暂停并推送至 Slack/企业微信/审批系统。人工批准则 resume 继续，拒绝则 rollback 或转工单。
六、典型落地场景
6.1 金融信贷审批
采集 Agent → 征信 Agent（MCP 调征信 API）→ 规则 Agent（评分卡）→ 反欺诈 Agent → 合规 Agent → 人工终审。全程 Trace，单笔可审计。
6.2 供应链智能调度
需求预测 Agent ∥ 库存 Agent → 路由 Agent 排线 → 异常 Agent 监控在途 → 通知 Agent 推送司机。
6.3 政务「一网通办」
材料 OCR Agent → 政策匹配 RAG Agent → 表单填充 Agent → 窗口系统 MCP 对接。
七、与 Single-Agent 选型
| 维度 | Single-Agent | Multi-Agent |
|---|---|---|
| 工具数量 | ≤5 个 | 可拆分，各 Agent ≤5 工具 |
| 流程复杂度 | 线性、≤5 步 | 分支、并行、≥6 步 |
| 质检需求 | 低 | 需专职 Compliance/Review Agent |
| 运维成本 | 低 | 中（需 Trace 拓扑） |
长境建议：MVP 用 Single-Agent 验证 ROI，当评测触顶或工具>8 时再演进 Multi-Agent。
八、协议与集成
- MCP：各 Agent 工具统一 MCP 化，Gateway 鉴权
- A2A（可选）：跨组织 Agent 发现与任务委派
- BPM：Camunda / 自研审批流 Webhook 对接
- API：POST /orchestration/run 提交任务，SSE 推送进度
九、消息协议与状态机
9.1 Agent 间消息格式
{ "task_id": "uuid", "from_agent": "research", "to_agent": "analytics",
"intent": "delegate", "payload": { "query": "..." }, "trace_id": "otel-span" }9.2 LangGraph 状态字段
- messages：Agent 间消息历史（可压缩）
- plan：Supervisor 分解的子任务列表及状态 pending/running/done/failed
- artifacts：中间产物（SQL 结果、检索片段、报告草稿）
- approval：HITL 节点等待状态与审批人 ID
十、观测指标与告警
| 指标 | 说明 | 建议阈值 |
|---|---|---|
| task_success_rate | 端到端任务成功 | ≥85% |
| agent_step_p95_ms | 单 Agent 步延迟 | <15s |
| hitl_rate | 人工接管比例 | <20% |
| token_cost_per_task | 单任务 Token 成本 | 按预算设定 |
| dead_letter_count | 死信队列堆积 | 告警 >10/min |
十一、长境落地案例参考
某城商行信贷 Agent 集群：5 个子 Agent（采集/征信/评分/合规/成稿），Pipeline+Supervisor 混合，日均处理 1200 笔初审，人工复核率从 100% 降至 35%，单笔平均耗时从 45 分钟降至 8 分钟（含人工）。
某制造集团巡检 Agent：边缘视觉 Agent + 云端诊断 RAG Agent + 工单 Agent，Multi-Agent 消息总线对接 Kafka，非计划停线率下降 18%。
十二、实施 checklist
- 绘制业务流程 BPMN，标注 Agent 切分点
- 每个 Agent 工具 ≤5 个（Vodafone 经验：工具过多反而降低成功率）
- 定义子 Agent 输入输出 JSON Schema
- 建立 20+ 条端到端评测任务（非单轮对话）
- 接入 OpenTelemetry，Grafana 看拓扑
- 配置 HITL 节点与审批 SLA
十三、技术栈与部署
Go/Java 控制面 + LangGraph Python 运行时；Redis Streams / Kafka；PostgreSQL Checkpoint；Prometheus + Jaeger + Grafana Agent 拓扑面板。
K8s 部署：Supervisor Pod 与 Worker Pod 分离伸缩；每 thread_id 串行保证状态一致。
十四、FAQ
Q：Multi-Agent 是否一定比 Single 好？
A：否。工具>8 或需并行/质检时才值得引入，否则增加调试复杂度。
Q：能否与现有 RPA 共存？
A：可以。RPA 步骤封装为 MCP 工具，由 Agent 编排调用。
