第 23 章 AI AgentAgentic Patterns安全

第 23 章 多智能体信任:多个 Agent 之间怎么互信、怎么审计

单个 Agent 管住了,多个 Agent 之间呢?

第五部分前四章管的是单个 Agent 的安全:威胁模型、控制流、权限、凭据出口。但现实里 Agent 常常要互相协作,于是有了新问题:Agent 之间的信任边界往往是隐式的,大家靠约定通信,没有可验证的身份,委派链也难以审计。这让冒充、权限混淆、无法验证的任务委派有机可乘。

这一章讲四个模式,从"通信怎么验"到"身份怎么定"到"信任怎么传"到"账本怎么记":

  1. Zero-Trust Agent Mesh(零信任网格):把零信任原则用到 Agent 间通信。
  2. Soulbound Identity Verification(灵魂绑定身份):不可转让的身份凭据 + 防篡改状态日志。
  3. Transitive Vouch-Chain Trust(间接证据信任链):信任沿着签名的担保链传递。
  4. Cryptographic Governance Audit Trail(防篡改审计):每个动作签名进链,审计有法律分量。

模式一:零信任网格(Zero-Trust Agent Mesh)

问题

多 Agent 系统里,信任边界往往隐式:Agent 靠约定通信,没有可验证的身份,委派链难以审计。这让冒充、权限混淆、无法验证的任务委派有机可乘。

方案

把零信任原则用到 Agent 间通信:

  • Agent 身份用密码学断言(每个 Agent 一对 Ed25519 密钥,签名快,64 字节)。
  • 互信握手:请求被接受前先确认身份。
  • 委派令牌:携带签名的范围、TTL、父级权威。
  • 有界委派:限制链深度和爆炸半径。

每个请求在身份、授权、委派谱系验证通过前,都被当不可信调用评估。策略在每一跳强制,不只是边缘;验证结果作为一等审计事件记录。这把"Agent 协作"变成一张可追踪的授权图,而不是"靠约定信任"的通道。

Agent A → 信任验证器: 注册密钥/身份
Agent B → 信任验证器: 注册密钥/身份
Agent A → Agent B: 挑战 nonce
Agent B → Agent A: 签名后的挑战响应
Agent A → Agent A: 验证响应
Agent A → Agent B: 委派令牌(带范围 + TTL)
Agent B → 信任验证器: 提交链审批
验证器 → 验证器: 验证签名 + 链深度

证据

  • 证据等级:高high)。
  • 有价值发现:生产级部署已存在,SPIFFE/SPIRE 有 1000+ 部署,2020 年 CNCF 毕业;验证开销不大,单跳和三跳链每请求约 0.05-0.15ms;Agent 框架(LangChain、AutoGen、CrewAI)通过工具授权钩子支持零信任。
  • 未验证:主流 Agent 框架的原生零信任支持还是适配器式的,不是一等公民。

怎么用

  • 每个 Agent 间请求都开信任检查,不只是敏感的。
  • 委派范围保持窄、短时。
  • 长任务要求显式过期和刷新。
  • 集中验证器策略(TTL 默认、信任分衰减、黑名单/白名单)。

取舍

  • 代价:加延迟和密钥管理、验证等额外组件;要求安全运维纪律(密钥轮换、撤销);信任分和策略调优有治理开销;现有 Agent 框架要适配胶水。
  • 好处:把隐式信任变成可验证、可审计的授权图。

模式二:灵魂绑定身份(Soulbound Identity Verification)

问题

自主 Agent 跨网络交互时,验证身份、检测提示词/操作者漂移变得困难。没有持久身份和不可变变更历史,Agent 可能冒充别人,或者悄悄偏离被授权的配置。

方案

把 Agent 身份和可变元数据绑定到一个不可转让的凭据上,并把带身份的状态转换记录进防篡改日志。

流程:

  1. 计算规范化系统提示词/状态的稳定哈希,注册时提交。
  2. 签发不可转让的身份凭据(比如 SBT 式 token)。
  3. 把有意义的变更(提示词更新、操作者变更、策略更新)记成签名事件
  4. 要求验证者在信任输出前,同时检查凭据有效性和状态连续性。
Agent 状态 → 规范化 + 哈希 → 不可转让身份凭据 → 验证者检查凭据
Agent B → 验证哈希 + 变更记录 → 信任决策

证据

  • 证据等级:中medium),来自 Chitin(ERC-5192 实现)。
  • 有价值发现:不可转让凭据防止凭据盗窃和冒充;基于哈希的状态承诺能在不暴露身份的情况下做可验证的连续性检查。
  • 未验证:大型 Agent 舰队的长期运维成本和可扩展性要更多生产验证。

什么时候用

  • 把工作委派给另一个 Agent 之前。
  • Agent 市场或多组织委派。
  • 需要可审计 Agent 状态连续性的合规工作流。

取舍

  • 好处:不可转让性防止凭据委派和盗窃;防篡改日志提供可审计的状态历史;不暴露身份也能验证。
  • 代价:需要外部注册表和追加式日志基础设施;哈希承诺验证状态完整性,不验证语义正确性;签发/轮换凭据有运维开销。

模式三:间接证据信任链(Transitive Vouch-Chain Trust)

问题

没有中央权威时,自主 Agent 之间的信任决策是二元的:要么完全信任,要么完全不信任。没有机制从间接关系里推导出部分、有证据的信任。

传统方法各有各的失败:

  • 中央注册表:单点故障,还要所有 Agent 信任同一个权威。
  • 自我断言身份(声称"我是 X"):没有验证,任何 Agent 都能声称任何身份。
  • 二元信任网(PGP 模型):只回答"这个密钥有效吗",不回答"我该多信任这个 Agent 的能力或意图"。

Agent 需要一个方式建立信任网络:信任通过已验证的关系传播,随距离衰减,并且端到端可审计。

方案

实现一个有向、签名的担保图,每条边是一个 Agent 对另一个 Agent 的加密签名证明。信任沿链传递,每跳带可配置的衰减。

核心组件:

  1. Agent 身份:每个 Agent 持有密钥对(Ed25519),从公钥派生去中心化标识符。
  2. 担保(Vouch):Agent A 签名声明信任 Agent B,可选范围("我信 B 做代码审查" vs 一般信任)。
  3. 链验证:Agent C 遇到未知的 B 时,可以追溯一条链:C 信任 A,A 担保了 B。C 给 B 一个随链长衰减的派生信任分。
  4. 撤销:签名撤销声明即可撤销担保,立即切断信任图里的那条边。
Agent A(被 C 信任)
  ├── 担保 B(签名、带时间戳)
  │     └── B 可以把这条链出示给 C
  │           C 验证: A 的签名有效? A 被信任? → B 拿到派生信任
  └── 担保 D
        └── D 担保 E
              E 离 C 有 3 跳 → 信任分更低

信任分计算(示例):

function trust_score(verifier, target, graph, decay=0.7):
    if verifier == target: return 1.0
    paths = find_all_paths(graph, verifier, target, max_depth=5)
    if not paths: return 0.0
    best = 0.0
    for path in paths:
        score = 1.0
        for hop in path:
            verify_signature(hop.vouch)   # 密码学检查
            score *= decay
        best = max(best, score)
    return best

和 PGP 信任网的关键区别:担保链带语义权重(不只是密钥有效性)、支持有范围的信任类别、为 Agent 的自动验证设计,而不是人工审查。

证据

  • 证据等级:低low)。
  • 有价值发现:isnad(传述链)方法论在圣训学里用了一千多年,通过叙述者链评估信息可靠性。同样的结构原则(通过验证过的中间人推导信任)适用于 Agent 网络。早期实现显示这个模型在小网络(几十个 Agent)可行。
  • 未验证:超过小网络的可扩展性没测过;女巫攻击抵抗力取决于创建身份的成本;信任衰减参数要在不同用例里经验调优。

怎么用

什么时候用:

  • 来自不同组织或操作者的 Agent 要协作的多 Agent 系统。
  • Agent 互相提供服务的市场。
  • Agent 必须对未知 Agent 做信任决策的任何系统。

实施步骤:

  1. 定义身份方案(DID、公钥哈希等)。
  2. 实现担保创建:Agent 签名一条把它的身份绑定到目标身份的声明。
  3. 实现链遍历:给定目标,找穿过担保图回到可信根的路径。
  4. 按信任需求选衰减参数(更高衰减 = 更保守)。
  5. 实现撤销:签名撤销声明让特定担保失效。

前置条件: 每个 Agent 有稳定密码学身份(密钥对 + 标识符);一个发布和发现担保的注册表或 gossip 协议;域分离签名防跨协议重放(签名前给担保消息加 vouch: 前缀)。

取舍

  • 好处:不需要中央权威,信任从网络涌现;可审计,每个信任决策都能沿链追溯;正常降级,丢一个节点只影响依赖那条链的 Agent;能和其它信任信号(声誉分、行为历史)组合。
  • 代价:冷启动问题,新 Agent 没有担保所以派生信任为零;女巫攻击脆弱,攻击者可以建很多身份互相担保(靠身份成本或工作量证明缓解);图遍历成本随网络规模增长(靠缓存和最大深度限制缓解);信任衰减参数主观、依赖应用。

模式四:防篡改审计(Cryptographic Governance Audit Trail)

问题

AI Agent 自主执行工具调用时,没有防篡改的记录证明发生了什么。 传统日志是可变的,事后可以改动。在受监管环境(金融、医疗、EU AI Act)里,团队需要证明 Agent 到底做了什么、什么时候、是否在策略内运行。没有密码学保证,审计轨迹就没有法律或合规分量。

方案

在每个动作执行点,用后量子数字签名(ML-DSA)给 Agent 的每个动作签名。 每次工具调用产生一张签名收据,包含动作、参数、结果哈希、时间戳、策略评估结果。这些收据组成追加式链,结构上就防篡改

治理层作为中间件,包住 Agent 的工具调用接口:

  1. 执行前:对照策略文件检查工具调用(允许的工具、限流、数据访问规则)。
  2. 执行:正常运行工具调用。
  3. 执行后:用 ML-DSA 给动作收据签名,追加进审计轨迹。

证据

  • 证据等级:中medium)。
  • 有价值发现:SCITT 架构(IETF RFC 9334)验证了追加式签名收据模式对供应链完整性的价值;OWASP Agentic Top 10 把"缺乏审计轨迹"列为 Agent 系统的高危漏洞。
  • 未验证:大规模下的长期存储和验证开销要更多生产数据。

怎么用

  • 用在任何支持工具调用中间件的 Agent 框架(LangChain、CrewAI、MCP 等)。
  • 用 YAML 定义策略:哪些工具允许、限流、数据访问规则。
  • 签名收据存本地或导出到合规系统。
  • 用于 EU AI Act 第 12 条(记录保留)和 SOC2 审计证据。

取舍

  • 好处:防篡改审计轨迹;执行前策略强制;抗量子签名;与框架无关。
  • 代价:每次工具调用加延迟(签名开销);要密钥管理;收据存储随 Agent 活动线性增长。

四个模式怎么选

场景 推荐模式
多 Agent 协作,通信要可验证 零信任网格
Agent 身份会漂移,要防冒充 灵魂绑定身份
没有中央权威,信任要传递 间接证据信任链
合规环境,审计要有法律分量 防篡改审计

四个模式是多智能体信任的四根柱子零信任网格管"每次通信怎么验",灵魂绑定身份管"身份怎么定、怎么防漂移",担保链管"信任怎么在陌生 Agent 间传递",防篡改审计管"账本怎么记、怎么让审计可信"。从通信到身份到信任到账本,多 Agent 协作才真正可验证、可追责。

实践清单

  • 每个 Agent 配密码学身份(Ed25519 密钥对),请求前互信握手
  • 委派令牌带签名范围 + TTL + 父级权威,限制链深度
  • 每个 Agent 间请求都做信任检查,策略每跳强制
  • 身份绑定不可转让凭据,状态变更记签名事件,验证者查凭据 + 连续性
  • 无中央权威时用担保链:签名担保 + 按跳衰减 + 可撤销
  • 担保链签名前加域分隔前缀(vouch:),防跨协议重放
  • 每个动作签名收据(动作/参数/结果哈希/时间戳/策略结果),追加成链
  • 用 ML-DSA 这类后量子签名,收据存合规系统(EU AI Act / SOC2)
  • 审计日志同时记录:信任验证结果、担保撤销、签名收据、尝试绕过

本章小结

  • 零信任网格:Ed25519 身份 + 互信握手 + 有界委派,协作变成可追踪授权图。
  • 灵魂绑定身份:不可转让凭据 + 状态哈希承诺,防冒充、防漂移。
  • 间接证据信任链:签名担保沿链传递,随跳衰减,无权威也能推导信任。
  • 防篡改审计:ML-DSA 签名每个动作,追加式链结构上防篡改,合规有分量。
  • 多智能体信任让"几个 Agent 一起干活"从靠约定变成靠验证。

到这里,第五部分"让它安全"就讲完了。你的防线现在是:威胁模型(19)→ 控制流隔离(20)→ 权限与审批(21)→ 凭据与出口(22)→ 多智能体信任(23),从"看清攻击面"到"多 Agent 之间互信"。下一部分,进入"让它进化":从人工设计到自动学习。先从第 24 章反馈信号设计开始。

📑 Agent 模式实战:生产级 AI Agent 的工程模式

1 第 1 章 什么是 Agent 模式 2 第 2 章 规划-执行-观察:先想清楚,再动手 3 第 3 章 反思闭环:让 Agent 学会检查自己的作业 4 第 4 章 委派:让主 Agent 学会把活分出去 5 第 5 章 上下文预算治理:把 token 当成钱来管 6 第 6 章 上下文压缩与精选:装不下怎么办 7 第 7 章 上下文最小化:别让脏东西留在脑子里 8 第 8 章 记忆体系:让 Agent 记得住过去 9 第 9 章 学习沉淀:让 Agent 和团队一起变聪明 10 第 10 章 工具接口哲学:让 Agent 能用、好用、用得起 11 第 11 章 工具发现:让 Agent 在几百个工具里找到对的 12 第 12 章 执行环境:Agent 在哪动手、怎么动手 13 第 13 章 代码执行与沙箱:先写码,再跑码 14 第 14 章 结构化输出与契约:让 Agent 的输出能接住 15 第 15 章 验证循环:Agent 怎么检查自己的作业 16 第 16 章 评测基建:怎么系统地检验 Agent 17 第 17 章 可观测性:看见 Agent 在想什么、在干嘛 18 第 18 章 韧性工程:扛得住部分失效 19 第 19 章 威胁模型:先看风险长什么样,再谈防御 20 第 20 章 控制流隔离:把"谁做决定"和"谁执行"分开 21 第 21 章 权限与审批:谁有权干什么、谁点头 22 第 22 章 凭据与出口:Agent 手里的钥匙和门 23 第 23 章 多智能体信任:多个 Agent 之间怎么互信、怎么审计 24 第 24 章 反馈信号设计:给 Agent 的是信号,不是更大的提示词 25 第 25 章 评测驱动的改进:让 Agent 在真实使用和对抗测试里变强 26 第 26 章 强化学习:把反馈变成训练信号 27 第 27 章 复合式进化:让 Agent 系统越用越值钱 28 第 28 章 多智能体协调:让一群 Agent 一起干活不掉链子 29 第 29 章 模型路由:谁用哪个模型,怎么用得起 30 第 30 章 推理搜索结构:让 Agent 多想想,而不是一条道走到黑 31 第 31 章 控制谱系:从自动补全到完全自主的滑动条 32 第 32 章 团队与产品:把 Agent 变成团队资产,而不是个人玩具
← 返回本书大纲