Multi-Agent System: 多智能体协作系统
复杂任务分解与角色专业化 - 协作大于单打独斗
本页面的合规风控实战采用的是层级式 (Supervisor-Worker) 编排： 一个 Lead Agent 分派 AML / Pattern / KYC 三个子 Agent 并行评估，再统一裁决是否升级人工。 更多编排模式（顺序、并行、辩论、事件驱动/黑板）详见「智能体编排模式」节点。
合规风控多智能体系统
Multi-Agent Compliance & Risk Control System
业务场景说明
银行交易实时监测系统：对每一笔交易并行调用多个专业化子 Agent 进行风险评估，由 Lead Agent 汇总打分。超过阈值或触发硬性规条的交易强制升级人工合规官审核。
架构流程图 (Architecture Flow)
三个专业化子 Agent 并行发起评估，避免排队时延与相互判断污染。Lead Agent 依据加权分与一票否决硬约束统一判定。
│
├─► 反洗钱检测 Agent (AML Agent) [权重 40%]
├─► 异常交易模式 Agent (Pattern Agent) [权重 35%]
├─► KYC 尽调 Agent (KYC Agent) [权重 25%]
│ (三者并行独立执行，无顺序依赖)
▼
Lead Agent 汇总决策引擎
│
├─ 加权总分 ≥ 80 分 ──────────► 强制人工复核 (Escalate)
├─ 任一子 Agent 单项 ≥ 90 分 ─► 一票升级拦截 (Single Veto)
├─ 子 Agent 工具调用失败 ────► 降级安全审查 (Fallback Audit)
└─ 均未触发 ─────────────────► 自动放行 (Auto Pass + Audit Trail)
实时交易风控模拟引擎
选择不同的典型交易场景，体验 Multi-Agent 并行评估与 Lead Agent 的降级门控逻辑。
子 Agent 并行风险打分面板 (Parallel Sub-Agents)
Lead Agent 最终决策与合规路由
反洗钱 Agent 给出 92 高分，触发硬性风险拦截规则，不考虑其他低分项的稀释，直接升级人工审签。
该交易在自动化系统中已锁死卡住，系统拒绝继续流转，等待持牌合规官签字后方可放行或挂起。
关联 Atlas 节点 (Atlas Mapping)
该合规风控案例展示了 Atlas 架构图谱中多个关键模块的协同落地：
| Atlas 架构节点 | 风控案例对应设计 |
|---|---|
| 多智能体协作系统 | 三个专业化子 Agent (AML / Pattern / KYC) + Lead Agent 汇总编排 |
| Function Calling / MCP 工程 | 各子 Agent 调用黑名单库、交易历史库、KYC 档案等外部工具 |
| 结构化输出与类型安全 | 每个子 Agent 必须返回结构化评分 (数值 + 理由字段)，不能是自由文本 |
| Harness Engineering | 子 Agent 工具调用失败或置信度低时的降级策略与安全门控 |
工程要点 (Key Engineering Points)
三个子 Agent 同时接收交易数据独立评估，不互相等待，缩短端到端响应时间，也避免前一个 Agent 的偏差污染后一个 Agent 的判断。
仅用加权平均容易被低分项"稀释"掉某个致命信号，必须叠加"单项超阈值即升级"的硬性规则，这是风控场景与普通推荐类多 Agent 系统的关键区别。
不是可选的兜底措施，而是明确写进流程图的强制节点，超过阈值的交易在自动化系统里"卡住"，必须有人签字才能继续。
未触发升级的交易仍需记录完整的评分依据，供事后合规抽查，而不是"通过了就不留任何痕迹"。
失败模式 (需在实现中显式处理)
某个子 Agent 调用外部工具 (如黑名单库) 超时或失败 → 该子 Agent 应返回"评估不可用"而非静默给出默认分，Lead Agent 收到"不可用"信号时应直接触发人工复核，而非按缺省值继续计算加权分。
三个子 Agent 评分出现较大分歧 (如一个给 20 分、一个给 85 分) → 即使加权平均不高，系统设置了"评分方差过大"作为独立的升级触发条件。