单 Agent 假设
EU AI Act 是为单个 AI 系统设计的。第 6 条按系统分类风险。第 9 条按系统要求风险管理。第 14 条按系统规定人工监督。每条规定都假设单个 AI 系统做决策。
但企业不是部署单个 agent。他们部署的是舰队——销售 agent 交接给支持 agent，分析 agent 触发操作 agent，研究 agent 输入到报告 agent。多 agent 工作流已经是常态，而且在增长。
EU AI Act 没有填补的四个差距
对 EU AI Act 的法律分析揭示了多 agent 治理中的四个结构性差距：
**差距 1：没有多 agent 问责框架。**当 Agent A 将数据传递给 Agent B，后者触发 Agent C 采取导致伤害的行动——谁负责？EU AI Act 将责任分配给 AI 系统的”提供者”或”部署者”。但在多 agent 链中，没有跨 agent 追踪问责的机制。
**差距 2：没有级联故障条款。**如果 Agent A 向 Agent B 发送格式错误的输出，后者崩溃并向 Agent C 发送垃圾数据，故障级联。EU AI Act 要求单个系统的鲁棒性（第 15 条），但没有跨 agent 边界级联故障的条款。
**差距 3：没有 agent 对 agent 通信治理。**Agent 通过记忆、上下文窗口和直接消息共享数据。EU AI Act 要求数据治理（第 10 条），但没有涉及数据如何在 agent 之间流动——或谁治理该流动。
**差距 4：没有多 agent 编排监督。**当五个 agent 协作完成任务时，谁有监督权？第 14 条要求对 AI 系统的人工监督，但没有监督多个 agent 协同工作的编排框架。
为什么现在很重要
EU AI Act 在 2026 年 8 月 2 日达到全面执行。在欧盟部署多 agent 系统的企业将被要求遵守不是为其架构设计的合规标准。监管要求和多 agent 现实之间的差距既创造了风险也创造了机会。
风险：企业可能因落在当前合规框架之外的多 agent 行为面临执法行动。机会：现在建立多 agent 治理基础设施的企业将在修正案解决这些差距时走在监管曲线前面。
JieGou 如何解决每个差距
JieGou 的多 agent 治理基础设施是专门为 agent 舰队构建的：
| 差距 | JieGou 解决方案 |
|---|---|
| 没有多 agent 问责 | 按 agent 审计日志、角色推断、工作流中按 agent 的 GovernanceScore |
| 没有级联故障条款 | 循环检测防止无限循环；断路器隔离 agent 故障；DLQ 保留失败消息 |
| 没有 agent 对 agent 通信治理 | 共享记忆按 agent 范围隔离；升级协议在交接超过风险阈值时触发 |
| 没有编排监督 | 可视工作流画布实时显示每个 agent 节点、数据流、记忆覆盖和循环徽章 |
每项能力都映射到现有 EU AI Act 条款——将单系统合规扩展到多 agent 场景：
- 按 agent 审计日志将第 12 条（记录保存）扩展到 agent 链
- 循环检测将第 15 条（鲁棒性）扩展到级联故障
- 记忆隔离将第 10 条（数据治理）扩展到 agent 对 agent 数据流
- 工作流画布将第 14 条（人工监督）扩展到编排的 agent 舰队
在法规之前建设
监管机构将解决多 agent 治理。EU AI Act 的第 112 条委员会已经在审查新兴 AI 架构。NIST 扩展的 agent 计划包括多 agent 身份和授权。ISO/IEC 42001 可能会在未来更新中添加多 agent 条款。
现在建立多 agent 治理基础设施的企业获得三个优势：
- 合规就绪 —— 当多 agent 法规到来时，基础设施已经到位
- 风险降低 —— 无论法规如何，级联故障和问责差距都得到解决
- 竞争定位 —— 向客户、合作伙伴和审计师展示治理成熟度
EU AI Act 治理单个 agent。谁治理它们之间的对话？这是企业需要在 8 月 2 日之前回答的问题。
查看 多 Agent 治理 了解 JieGou 的完整多 agent 治理基础设施。了解更多关于 EU AI Act 合规。