一个程序员给AI装上了"行车记录仪"

凌晨三点，某金融科技公司的工程师小李盯着屏幕上的审计报告——监管要求证明三个月前那个AI风控模型的决策过程，但日志文件早被轮换清理。这不是技术故障，是设计缺陷。

AI代理（智能代理，能自主调用工具完成任务的系统）正在接管关键业务，却没人能证明它"当时到底做了什么"。LangChain生态的开发者们最近盯上了一个被忽视的需求：不是记录，而是自证。

为什么日志不够用

传统日志告诉你"发生了什么"，但面对审计员、客户或监管机构的追问时，它回答不了核心问题：这些记录事后被改过吗？

篡改日志的技术门槛极低。系统管理员、有权限的开发者、甚至入侵者，都能在事后插入、删除或修改记录。当AI代理开始执行转账审批、医疗诊断建议、法律合同分析时，这种"不可信记录"成为合规死穴。

密码学收据（cryptographic receipt）是另一种思路。它用数字签名和哈希链把每个动作"焊死"在时间里——改一处，全网皆知。这不是新概念，比特币2008年白皮书就写过。但把这套机制塞进AI代理的工具调用流程，直到最近才有人做出开箱即用的方案。

Signet项目做的就是这个：给LangChain代理的每次工具调用生成Ed25519签名的收据，5分钟接入，零外部依赖。

两码事：记录 vs 证明

技术圈常混淆这两个需求。日志是运维工具，收据是法律工具。

日志的设计目标是排查故障，所以追求详尽、可读、易检索。它的信任模型建立在"系统管理员不会作恶"上——显然不够。

密码学收据的设计目标是抗抵赖（non-repudiation）。每次工具调用生成一条结构化记录，包含：工具名称、输入参数的哈希值、输出结果的哈希值、时间戳、前一条记录的哈希值，以及整条记录的Ed25519签名。

哈希链把收据串成时间线。删掉中间任何一条，后续所有记录的"前序哈希"都对不上。修改任何字段，签名验证失败。这种结构在区块链叫默克尔树，在审计系统叫"只追加日志"（append-only log），原理相通。

Signet的特殊之处在于"零基础设施"。不需要区块链节点，不需要证书颁发机构，不需要API密钥。公钥就是验证凭证，可以贴在官网、写进智能合约、或者交给审计员。

接入流程拆解

实际代码比想象更简单。核心就三步：创建签名身份、挂载回调处理器、运行代理。

签名身份是一组Ed25519密钥对。私钥存在本地~/.signet/目录，公钥可任意分发。代码里用SigningAgent类管理，首次运行自动创建，后续加载复用。

回调处理器是LangChain的扩展点。SignetCallbackHandler实现了三个钩子：on_tool_start（工具开始执行时签名输入）、on_tool_end（工具返回时签名输出）、on_tool_error（异常时签名错误信息）。

关键设计：签名失败不阻断流程。如果磁盘满了、密钥损坏了，处理器只打警告日志，代理继续运行。这是生产系统的底线思维——审计增强不能牺牲可用性。

工具本身零改造。DuckDuckGo搜索、数据库查询、API调用，所有标准工具自动获得签名能力，不需要继承基类或重写方法。

收据里有什么

单条收据是JSON结构，核心字段包括：

action字段记录工具调用详情：工具名称、参数哈希（而非原始参数，保护隐私）、调用时间。result字段记录输出哈希和可选的错误信息。metadata包含代理标识和运行环境。signature是整条记录的Ed25519签名。prev_hash指向前一条收据，形成链条。

哈希值用SHA-256，签名算法选Ed25519——相比RSA，密钥更短、签名更快、同等安全强度下计算开销更低。这是2011年Daniel J. Bernstein设计的曲线，现在已是TLS 1.3和SSH的标准选项。

验证完全离线。拿到公钥和收据文件，用任何支持Ed25519的库都能校验，不需要联系Signet服务器。这种"去服务化"设计避免了供应商锁定，也消除了单点故障。

谁需要这个

三类场景最典型。

金融合规。欧盟MiCA法规要求加密资产服务提供商保留完整交易记录，美国SEC对算法交易有类似审计要求。AI代理如果参与订单执行，必须证明决策过程未被事后篡改。

医疗AI。FDA对机器学习设备的软件变更控制有严格规定，临床决策支持系统需要可追溯的推理链条。哈希链收据可以作为电子病历的附属证据。

企业内控。当AI代理获得访问敏感数据的权限时，安全团队需要不可抵赖的操作审计。传统日志可以被有权限的DBA修改，密码学收据只有持有私钥者能生成，分离了"操作权"和"审计权"。

一个细节：Signet的收据设计支持"选择性披露"。参数和结果只存哈希，原始数据可以另存加密。验证者能确认"某时某刻确实调用了某工具"，但看不到具体搜索关键词或数据库返回内容——平衡了可审计性和隐私。

局限与权衡

这不是万能方案。几个硬边界需要清楚。

收据证明"代理声称做了什么"，不证明"工具实际返回了什么"。如果DuckDuckGo搜索结果被中间人篡改，代理签名的只是它收到的伪造内容。端到端验证需要工具层也支持签名，目前Signet只覆盖代理侧。

时间戳依赖系统时钟。如果运行代理的服务器时间被回拨，收据的时间顺序会混乱。精确时间证明需要接入Roughtime或区块链时间戳服务，Signet当前版本未内置。

私钥管理是单点风险。~/.signet/目录如果被入侵，攻击者可以伪造历史收据。生产环境需要HSM（硬件安全模块）或密钥分片方案，Signet的默认配置面向开发测试。

存储成本线性增长。每条工具调用产生几百字节收据，高频代理可能日增数MB。长期归档需要设计轮转和压缩策略，原文未提及内置方案。

生态位思考

Signet的出现暗示了LangChain生态的演进方向：从"快速搭建"转向"生产就绪"。

2023年的LangChain教程集中在"5分钟做个聊天机器人"，2024年的焦点明显转向可观测性、安全性和合规性。LangSmith做追踪，Signet做审计，OpenTelemetry集成做监控——基础设施层在快速补齐。

这符合技术成熟度曲线。当早期采用者把AI代理推进到核心业务，原本"可以以后再说"的治理需求变成阻塞性问题。密码学审计不是炫技，是监管和市场倒逼的刚需。

一个值得观察的信号：Signet选择了"零基础设施"架构，而非区块链方案。2021-2022年的同类项目大概率会写"每条收据上链存证"，现在开发者更务实——公钥分发比智能合约便宜，离线验证比链上查询可靠。区块链的叙事退潮，留下了经过验证的密码学工具。

另一个信号：回调处理器的设计体现了LangChain的扩展韧性。不需要分叉框架、不需要等待官方支持，第三方可以用标准接口注入横切能力。这种插件化架构是生态繁荣的关键。

落地建议

如果你正在用LangChain构建代理系统，可以按这个优先级评估Signet：

第一，识别合规触发点。哪些工具调用涉及资金、隐私或安全决策？这些路径优先接入签名。

第二，设计密钥生命周期。开发测试用本地文件，生产环境规划HSM迁移路径。公钥分发策略提前和法务对齐。

第三，建立验证流程。审计场景下谁来验签、用什么工具验、验不过怎么办？这些操作手册比代码更重要。

第四，评估存储架构。收据存本地、对象存储、还是防篡改数据库？保留周期多长？需要成本测算。

第五，监控签名失败。回调处理器的警告日志需要接入告警系统，沉默的失败等于审计缺口。

AI代理的"黑箱"问题不会消失，但可以被约束在可验证的边界内。密码学收据不是让代理变透明，而是让"不透明"本身成为可审计的事实——这或许是现阶段最务实的工程妥协。