MCP协议藏了3个黑箱：10行代码让AI代理"自证清白"

你的AI代理刚帮你取消了订阅、发了邮件、转了账。它说"搞定了"。你信了。

但Stripe（在线支付平台）真的返回了200状态码吗？邮件到底发给了谁？数据库修改前的原始值是什么？没人知道——包括你自己。代理的"自报"是唯一的证据，而这份证据在代理自己手里。

日志即谎言：为什么MCP工具调用是黑箱

标准MCP服务器的工具调用长这样：输入进去，结果出来，中间发生了什么——HTTP请求头、响应体、时间戳——全部在服务器进程里被消化后丢弃。

用户看到的只有{"status": "cancelled"}。这是工具的自我陈述，不是独立可验证的证据。

有人第一反应是加日志：

但日志是行动者自己写的。这相当于让公司给自己做审计。在需要问责的系统里，自我报告和没报告的区别，只是精致一点的盲区。

真正的透明度需要第三方可验证的证据——密码学意义上的"收据"（Receipt），而非自说自话的"日志"（Log）。

密码学收据：把代理行为变成可审计事实

解决方案的核心是分离"执行者"和"证明者"的角色。代理仍然执行操作，但用密码学技术生成不可伪造的操作痕迹。

具体实现依赖三个组件：

可验证执行环境（TEE，可信执行环境）——在硬件隔离区域内运行敏感操作，生成签名证明；透明日志（如Trillian、Certificate Transparency）——将操作摘要写入公开可审计的日志；零知识证明（ZKP）——证明某操作符合策略，但不暴露敏感内容。

以TEE方案为例，代码可以极简：

这段代码的关键在于：proof由TEE硬件密钥签名，任何第三方都能用公钥验证其真实性。代理无法事后抵赖，也无法伪造未执行的操作。

10行代码的透明度：从概念到落地

实际部署中，完整方案可以压缩到10行以内：

对比传统日志，差异在于：传统日志的验证链条是"用户→信任服务器→信任日志文件"；密码学收据的链条是"用户→验证签名→验证TEE证明→验证公开日志"。信任对象从"服务器运营者"变成了"数学和硬件"。

Stripe的响应体、邮件服务商的Message-ID、数据库的变更前快照——这些原本被丢弃的证据，现在被哈希后写入收据。即使代理服务器被攻破，攻击者也无法逆向伪造历史操作。

谁需要这个？合规、对账、和那句"我明明没点"

短期看，金融、医疗、政务场景的MCP部署会最先倒逼这个需求。PCI-DSS（支付卡行业数据安全标准）要求"所有访问支付数据的行为可追溯"；HIPAA（健康保险流通与责任法案）要求审计日志不可被覆盖；欧盟AI法案正在将"高风险AI系统的可追溯性"写入法律。

长期看，这是代理经济的基础设施问题。当AI代理开始代表人类签署合同、转移资产、做出有约束力的承诺时，"它说做了"和"它能证明做了"之间的鸿沟，会成为整个商业模式的信用成本。

一个细节：目前MCP协议本身没有规定收据格式。Anthropic（MCP的提出方）在社区讨论中承认这是"已知限制"，但优先级排在多模态和性能优化之后。这意味着透明度方案现在只能作为服务器层的补丁存在，而非协议原生能力。