CapSeal架构：基于能力密封实现AI代理间安全秘密共享

1. 项目概述：当AI代理需要“说悄悄话”时

最近在折腾一个挺有意思的玩意儿，我把它叫做“CapSeal”。这名字听起来有点玄乎，其实核心想法很简单：让多个AI代理在协作时，能安全、可控地分享“秘密”。这里的“秘密”不是指什么惊天阴谋，而是指那些不应该对所有代理都公开的敏感信息，比如用户的个人身份数据、某个代理独有的核心算法逻辑、或者一次协作中需要临时生成的、仅限部分参与者知晓的中间结果。

想象一个场景：你设计了一个由多个AI代理组成的客服系统，一个负责理解用户情绪，一个负责查询知识库，一个负责生成最终回复。用户问：“我上周买的那个订单，物流到哪了？” 要回答这个问题，查询代理需要知道用户的订单号，这个信息对生成回复的代理是必要的，但对于情绪分析代理来说，它只需要知道用户“在询问物流状态”这个意图就够了，完全没必要接触到具体的订单号。如果所有信息在所有代理间明文广播，不仅增加了数据泄露的风险，也让每个代理的职责边界变得模糊。

CapSeal要解决的，就是这个“选择性秘密分享”的问题。它不是一个具体的算法，而是一套架构设计，其核心是“能力密封”。你可以把它理解为给信息或功能加上一个带锁的盒子（密封），只有持有特定“钥匙”（能力）的代理才能打开。这个架构的目标，是在不引入一个中心化、全知全能的“上帝视角”中介的前提下，实现代理间安全、高效、可审计的秘密传递与计算。

2. 核心设计思路：从“全知中介”到“能力门卫”

传统的解决思路，往往是引入一个中心化的“秘密中介”或“可信执行环境”。所有代理都把秘密交给它，由它来决定谁能看、谁能用。但这带来了单点故障、性能瓶颈和巨大的信任成本——你必须完全信任这个中介不会出错、不会被攻破。

CapSeal的设计走了另一条路：去中心化的能力密封。它的核心思想不是集中保管秘密，而是定义和分发“能力”。

2.1 什么是“能力密封”？

我们可以用一个生活中的类比来理解：公司公章。一份文件（信息）本身可能并不敏感，但盖上公章后，它就具备了法律效力（能力）。这个“盖章”的过程，就是一种“密封”。只有持有公章（特定能力）的人才能完成这个操作。而验证文件真伪的人，并不需要知道公章具体是什么样子，只需要通过一套公认的机制（比如在公安局备案的印鉴）来验证这个“章”的有效性即可。

在CapSeal中：

• 能力：是一个经过密码学签名的、不可伪造的令牌。它声明了持有者（某个代理）被允许执行什么操作（如“读取用户A的订单数据”、“调用算法X的v2版本”）。
• 密封：是将一段信息或一个计算任务，与一个或多个“能力”进行绑定的过程。绑定后，只有展示出相应能力的代理，才能解封（访问）信息或执行任务。
• 秘密中介：在这里不是一个实体，而是一个逻辑角色和协议。它负责能力的签发、验证和传递路线的协调，但它本身不接触、不存储任何被密封的秘密内容。它更像一个“邮局”或“公证处”，只处理“信封”和“授权书”，不拆看里面的信件。

2.2 架构的四大核心组件

基于这个思路，CapSeal架构可以分解为四个逻辑层，它们共同工作，实现安全的秘密中介。

2.2.1 能力管理中心

这是整个系统的信任锚点。它负责：

• 能力定义：根据业务策略，形式化地定义各种能力。例如，cap_query_order:user_id=<uid>表示查询特定用户订单的能力。
• 能力签发：为经过身份认证的代理签发能力令牌。这通常基于公钥基础设施，使用非对称加密进行签名。
• 能力撤销：维护一个能力撤销列表或使用短时效令牌，确保泄露的能力能及时失效。

实操心得：在初期，可以用一个简单的配置文件定义能力，并使用一个自签名的根证书来签发。但在生产环境，务必集成到现有的身份与访问管理系统中。能力的粒度设计是关键，太粗则安全性不足，太细则管理开销巨大。建议从“角色”维度开始，再细化到具体操作。

2.2.2 密封与解封引擎

这是每个代理都需要内置或可调用的客户端组件。

• 发送方（密封）：当代理A需要向代理B发送秘密时，它调用密封引擎。引擎会：
  1. 向能力管理中心申请或使用已有的、针对本次通信的“解封能力”。
  2. 用代理B的公钥（或会话密钥）加密秘密内容。
  3. 将加密后的密文、本次通信所需的“解封能力”标识符，以及用发送方私钥签名的元数据（发送者、时间、用途）打包，形成一个“密封容器”。
• 接收方（解封）：代理B收到容器后，解封引擎会：
  1. 验证容器的签名和完整性。
  2. 向能力管理中心（或本地缓存）验证“解封能力”是否有效且授权给代理B。
  3. 如果验证通过，则用代理B的私钥解密内容。

2.2.3 秘密路由总线

这是代理间通信的管道。它可以是消息队列（如RabbitMQ、Kafka）、服务网格（如Istio）的虚拟网络，或者简单的HTTP/gRPC调用框架。它的特殊职责在于：

• 基于能力的路由：可以根据密封容器头部的“所需能力”标签，将消息路由到拥有该能力的代理群组，实现发布/订阅模式下的安全多播。
• 审计日志：记录所有密封容器的路由元数据（谁在何时向谁发送了何种能力的请求），但不记录容器内的密文，以满足合规性要求。

2.2.4 策略执行点与审计器

这是一个监控和保障层。

• 策略执行点：可以部署在路由总线或每个代理旁，实时检查通信是否符合预定义的安全策略（例如，“只有具备cap_financial能力的代理才能发送含有‘金额’字段的容器”）。
• 审计器：定期分析审计日志，检测异常模式，比如某个代理突然请求大量高权限能力，或者解封失败率异常升高，这可能是代理被入侵或出现故障的信号。

3. 核心环节实现：从理论到代码

光有架构图不够，我们来看看几个关键环节如何落地实现。这里我会用一个简化的、基于Python和数字签名的示例来说明核心流程。

3.1 能力令牌的设计与签发

能力令牌需要包含足够的信息且防篡改。我们采用JWT作为令牌格式，并用非对称加密签名。

import jwt import datetime from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import serialization, hashes # 1. 能力管理中心初始化（仅示例，实际应安全保存私钥） private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048) public_key = private_key.public_key() # 2. 定义并签发一个能力令牌 def issue_capability(agent_id: str, capability: str, expires_hours: int=1): payload = { 'iss': 'capability-authority', 'sub': agent_id, # 持有者ID 'cap': capability, # 能力声明，如 "read:order:12345" 'iat': datetime.datetime.utcnow(), 'exp': datetime.datetime.utcnow() + datetime.timedelta(hours=expires_hours) } # 使用私钥签名 token = jwt.encode(payload, private_key, algorithm='RS256') return token # 为代理“order_processor”签发一个查询订单12345的能力，有效期1小时 cap_token = issue_capability('order_processor', 'read:order:12345', 1) print(f"能力令牌: {cap_token}")

3.2 信息的密封过程

发送方代理在发送秘密前，需要构造密封容器。

import json from cryptography.hazmat.primitives.ciphers.aead import AESGCM import os import base64 def seal_message(receiver_pub_key_pem: str, secret_data: dict, capability_token: str, sender_priv_key): """ 密封消息 receiver_pub_key_pem: 接收方的公钥(PEM格式) secret_data: 要加密的敏感数据 capability_token: 本次通信所需的能力令牌 sender_priv_key: 发送方的私钥，用于签名 """ # 1. 生成随机会话密钥（用于加密数据） session_key = os.urandom(32) # AES-256 nonce = os.urandom(12) # GCM nonce # 2. 用会话密钥加密数据 aesgcm = AESGCM(session_key) secret_json = json.dumps(secret_data).encode('utf-8') ciphertext = aesgcm.encrypt(nonce, secret_json, None) # 3. 用接收方的公钥加密会话密钥（密钥封装） receiver_pub_key = serialization.load_pem_public_key(receiver_pub_key_pem.encode()) encrypted_session_key = receiver_pub_key.encrypt( session_key, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) # 4. 构造容器头部（明文，包含元数据和能力令牌标识） container_header = { 'version': '1.0', 'sender': 'agent_a', 'receiver': 'agent_b', 'required_capability': capability_token, # 这里放置的是能力令牌本身或其标识符 'encrypted_key': base64.b64encode(encrypted_session_key).decode('utf-8'), 'nonce': base64.b64encode(nonce).decode('utf-8'), 'timestamp': datetime.datetime.utcnow().isoformat() } # 5. 对容器头部进行签名（确保头部不被篡改） header_json = json.dumps(container_header, sort_keys=True).encode('utf-8') signature = sender_priv_key.sign( header_json, padding.PSS( mgf=padding.MGF1(hashes.SHA256()), salt_length=padding.PSS.MAX_LENGTH ), hashes.SHA256() ) # 6. 组装最终密封容器 sealed_container = { 'header': container_header, 'signature': base64.b64encode(signature).decode('utf-8'), 'ciphertext': base64.b64encode(ciphertext).decode('utf-8') } return json.dumps(sealed_container)

3.3 信息的解封与验证

接收方代理收到容器后，需要验证并解封。

def unseal_message(sealed_container_json: str, receiver_priv_key, authority_public_key): """ 解封消息 receiver_priv_key: 接收方的私钥 authority_public_key: 能力管理中心的公钥，用于验证能力令牌 """ container = json.loads(sealed_container_json) header = container['header'] signature = base64.b64decode(container['signature']) ciphertext = base64.b64decode(container['ciphertext']) # 1. 验证头部签名 header_bytes = json.dumps(header, sort_keys=True).encode('utf-8') # 这里需要发送方的公钥，可以从header['sender']查找或从预置信任库获取 sender_pub_key = get_public_key_by_agent_id(header['sender']) # 假设的函数 try: sender_pub_key.verify( signature, header_bytes, padding.PSS( mgf=padding.MGF1(hashes.SHA256()), salt_length=padding.PSS.MAX_LENGTH ), hashes.SHA256() ) print("头部签名验证通过") except Exception as e: raise ValueError("容器头部签名无效，可能被篡改") from e # 2. 验证能力令牌 capability_token = header['required_capability'] try: # 使用能力管理中心的公钥验证JWT签名和有效期 decoded_cap = jwt.decode(capability_token, authority_public_key, algorithms=['RS256']) # 检查令牌中的主体(sub)是否与当前接收者匹配（或是否被授权） if decoded_cap['sub'] != 'agent_b': # 这里应根据策略灵活检查 raise ValueError(f"能力令牌主体不匹配。期望‘agent_b’，得到‘{decoded_cap['sub']}’") print(f"能力验证通过: {decoded_cap['cap']}") except jwt.ExpiredSignatureError: raise ValueError("能力令牌已过期") except jwt.InvalidTokenError as e: raise ValueError(f"能力令牌无效: {e}") # 3. 用接收方私钥解密会话密钥 encrypted_session_key = base64.b64decode(header['encrypted_key']) session_key = receiver_priv_key.decrypt( encrypted_session_key, padding.OAEP( mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None ) ) # 4. 用会话密钥解密数据 nonce = base64.b64decode(header['nonce']) aesgcm = AESGCM(session_key) plaintext_bytes = aesgcm.decrypt(nonce, ciphertext, None) secret_data = json.loads(plaintext_bytes.decode('utf-8')) return secret_data

注意事项：以上是高度简化的示例。在生产环境中，你需要处理密钥管理、令牌格式标准化、错误处理、性能优化（如会话密钥缓存）等一系列复杂问题。此外，JWT作为能力令牌可能包含过多信息，可以考虑更轻量的自定义格式。

4. 架构的部署模式与选型考量

CapSeal是一种逻辑架构，它可以适配不同的物理部署模式。

4.1 部署模式对比

我的建议：对于大多数AI代理系统，边车模式是一个平衡点。它利用了云原生生态（如Istio、Linkerd），将安全逻辑从业务代码中解耦。你可以先在一个关键的数据流上试点，比如负责处理用户PII（个人可识别信息）的代理与其他分析代理之间的通信。

4.2 关键组件技术选型参考

• 密码学库：Python首选cryptography，Go用crypto标准库或golang.org/x/crypto，Java用Bouncy Castle。绝对不要自己实现加密算法。
• 令牌格式：JWT足够通用，但注意其默认载荷是明文的。对敏感信息，可使用JWE（JSON Web Encryption）或自定义二进制格式。
• 消息总线：根据一致性要求选择。高吞吐、最终一致用Apache Kafka；复杂路由、保证交付用RabbitMQ；简单RPC用gRPC并集成密封逻辑。
• 策略与审计：可使用Open Policy Agent定义策略，用Elasticsearch + Kibana或Loki + Grafana来收集和可视化审计日志。

5. 实战中的挑战与应对策略

在实际搭建和运行CapSeal架构时，你会遇到一些预料之中和预料之外的挑战。

5.1 性能开销与优化

加解密、签名验证都是CPU密集型操作。在AI代理高频交互的场景下，可能成为瓶颈。

• 挑战：每个消息都进行非对称加密（封装密钥）和签名验证，延迟显著增加。
• 优化策略：
  1. 会话复用：在建立安全通信后，为两个代理之间协商一个临时的对称会话密钥，用于加密后续一系列消息，而非每条消息都做非对称加密。这类似于TLS中的会话恢复。
  2. 硬件加速：在服务器上启用AES-NI等CPU指令集，大幅提升对称加密速度。对于签名验证，考虑使用支持椭圆曲线算法（如Ed25519）的硬件安全模块。
  3. 异步与非阻塞：将密封/解封操作放入单独的线程池或使用异步IO，避免阻塞主业务逻辑。
  4. 选择性密封：并非所有通信都需要密封。可以定义清晰的数据分类（公开、内部、秘密、绝密），只对“秘密”及以上级别的数据应用CapSeal。

5.2 能力令牌的生命周期管理

能力令牌发出去容易，管好难。

• 挑战：令牌泄露、过期时间设置不合理、细粒度能力导致令牌爆炸。
• 管理策略：
  1. 短时效与自动续期：默认签发短时效令牌（如5-15分钟）。同时，设计安全的续期协议，允许持有有效令牌和刷新令牌的代理获取新令牌，而无需重新认证。
  2. 撤销机制：除了依赖过期时间，必须实现撤销列表或基于OCSP协议的在线状态检查。当检测到代理异常或密钥泄露时，能立即撤销其所有能力。
  3. 能力组合与委托：支持将多个细粒度能力组合成一个“复合能力”令牌进行签发。同时，在严格策略控制下，允许代理将其部分能力安全地委托给另一个代理（例如，任务分解），避免所有能力都从根CA签发。

5.3 调试与监控的复杂性

当通信被加密和密封后，传统的日志调试和网络抓包几乎失效。

• 挑战：问题排查困难，无法直观看到代理间传递的数据。
• 可观测性设计：
  1. 结构化审计日志：强制要求每个密封/解封操作都生成结构化的审计日志，记录消息ID、发送者、接收者、使用的能力、时间戳、结果（成功/失败及错误码）。切记，只记录元数据，不记录密文或明文秘密。
  2. 追踪标识传播：在密封容器头部注入唯一的追踪标识（如OpenTelemetry的Trace ID），该标识在后续所有相关操作中传递。这样可以在分布式追踪系统（如Jaeger）中，将一次涉及多个代理的秘密传递全过程串联起来，即使看不到内容，也能看清流程和性能瓶颈。
  3. 模拟与测试环境：搭建一个独立的测试环境，其中能力管理中心的私钥是公开的，或者使用一个“透明解封”的调试代理。这样可以在测试时解密和查看所有流量，但此环境必须与生产完全物理隔离。

5.4 与现有AI代理框架的集成

你的AI代理可能是基于LangChain、AutoGen、CrewAI等框架构建的。

• 挑战：如何无侵入或低侵入地将CapSeal能力注入到代理的交互中。
• 集成模式：
  1. 包装器模式：为代理的“发送消息”和“接收消息”核心函数创建包装器。在发送前自动密封，在接收后自动验证和解封。这是对现有代码改动最小的方式。
  2. 中间件/钩子模式：如果框架支持中间件或生命周期钩子（如LangChain的CallbackHandler），可以编写一个CapSeal回调处理器，在消息流转的特定节点插入密封/解封逻辑。
  3. 自定义工具/能力：将“密封发送”和“验证解封”本身设计成AI代理可以调用的“工具”。代理在需要传递秘密时，主动调用这些工具。这种方式将控制权交给了代理的推理逻辑，更灵活但也要求代理具备相应的“安全意识”。

6. 一个完整的场景推演：安全的多代理协作审批

让我们通过一个虚构但贴近实际的场景，把CapSeal的运作串起来。

场景：一个企业费用报销审批流程，涉及三个AI代理：

• 票据识别代理：接收用户上传的发票图片，识别出金额、商户、日期等结构化信息。它需要接触敏感的发票图像。
• 合规校验代理：根据公司财务政策，校验报销金额是否超标、商户是否在许可名单内。它需要知道金额和商户，但不应看到原始发票图像。
• 审批决策代理：综合合规结果、员工历史报销记录等信息，做出最终审批决定。它需要知道合规结果和员工ID，但不应看到具体的票据细节。

没有CapSeal的问题：如果三个代理在一个共享的聊天频道里明文通信，合规代理和审批代理都会接触到发票图像（隐私泄露），审批代理也会看到具体的商户信息（可能涉及商业敏感）。

使用CapSeal的流程：

1. 能力签发：能力管理中心为三个代理签发初始能力。

   • 票据识别代理：cap_receipt_ocr（可调用OCR服务）。
   • 合规校验代理：cap_access_amount（可访问金额字段）、cap_access_merchant（可访问商户字段）。
   • 审批决策代理：cap_access_compliance_result（可访问合规结果）、cap_access_employee_metadata（可访问员工元数据）。

2. 秘密传递：

   • 用户上传发票。票据识别代理处理图像，得到结构化数据{“amount”: 500, “merchant”: “XX科技”, “date”: “2023-10-1”, “image_hash”: “abc123”}。
   • 票据识别代理需要将amount和merchant发给合规校验代理。它向能力管理中心申请一个临时的一次性能力令牌，该令牌声明：“持有cap_access_amount和cap_access_merchant能力的代理，可以解封本次消息”。
   • 票据识别代理用合规校验代理的公钥，仅加密amount和merchant字段，与临时能力令牌一起密封，发送出去。
   • 合规校验代理收到密封容器。验证令牌有效且自己拥有所需能力，解封得到数据，进行校验，生成结果{“is_compliant”: true, “rule_applied”: “policy_v2”}。
   • 合规校验代理现在需要将结果发给审批决策代理。它申请一个新的临时令牌，声明需要cap_access_compliance_result能力。然后用审批代理的公钥加密结果并密封发送。
   • 审批决策代理验证、解封、获取结果，并结合员工历史数据（通过另一个密封请求获取）做出最终决定。

3. 全程可见性：审计日志记录了完整的链条：“票据识别代理”使用临时令牌T1向“合规校验代理”发送了密封消息；“合规校验代理”使用临时令牌T2向“审批决策代理”发送了密封消息。策略引擎可以验证每个步骤都符合预定义的数据流转策略（如“金额数据仅能从票据代理流向合规代理”）。

在这个流程中，发票图像始终只存在于票据识别代理的上下文中；具体的金额和商户信息只被合规代理看到；审批代理只看到抽象的合规结果。每个代理都只接触完成其职责所必需的最小信息，实现了“最小权限原则”在AI代理协作中的落地。

7. 总结与个人体会

CapSeal这类基于能力密封的架构，本质上是在为AI代理的协作引入一种“契约”和“边界”。它回答了一个关键问题：在智能体自主性越来越强的未来，我们如何确保它们之间的交互是安全、可控且合规的？

从我自己的实践来看，引入这套架构最大的收益不是技术上的，而是思维上的转变。它迫使你在设计代理交互协议之初，就必须仔细思考：“这个代理到底需要知道什么？它应该被允许做什么？” 这个过程本身就能发现很多潜在的数据滥用风险。

当然，它绝不是银弹。最大的代价是复杂性。系统的调试、监控、密钥管理都变得更具挑战。我的建议是：

1. 渐进式采用：不要试图一次性在所有代理间铺开。从最敏感的一两条数据流开始，比如涉及用户个人数据或支付信息的交互。
2. 工具链先行：在写业务逻辑之前，先花时间搭建好密钥管理、令牌签发、审计日志收集和可视化的基础工具。没有良好的可观测性，这套系统在出问题时就是噩梦。
3. 平衡安全与便利：安全措施过强会扼杀协作效率。定期回顾你的能力定义和策略，看看是否有过度限制的地方。安全策略应该像一件合身的衣服，既提供保护，又不妨碍活动。

最后，CapSeal的设计理念其实超越了AI代理。任何需要处理微服务间敏感数据传递、跨组织安全计算的场景，都可以从这种“基于能力的访问控制”和“无中介秘密共享”的思想中汲取灵感。它代表了一种将信任从中心实体转移到可验证的、细粒度的凭证上的趋势，这或许是构建未来大规模、异构、自主系统协作信任基石的一个可行方向。