AI 代理出错、产生幻觉或发起破坏性 API 调用时，首先要问的是：它为什么这么做？安全与合规团队越来越常追问的是：你能证明吗？随着 AI 代理从实验沙箱走向生产环境，可观测性与可审计性之间的区别开始变得重要。对多数团队这是工程纪律问题；对欧盟 AI 法案下的高风险系统，则是有明确截止日期的可追溯性要求。
标准日志为何不够用：传统日志是可变的，任何有数据库访问权限的人或恶意脚本都能事后篡改历史。可被静默重写的追踪记录不能作为证据。即便无人触碰，常规追踪也绑定于可变的内存状态，很少捕获失败运行启动时的确切配置与上下文，因此无法重建更无法重放该运行。
审计代理需要记录完整执行上下文，而非仅最终输出或 token 数：输入（确切提示词、任务或消息负载，以及模型配置如 model、temperature、system prompt 版本）；推理过程（中间步骤，包括考虑过又放弃的路径，如 gf.reasoning.thought、gf.reasoning.considered、gf.reasoning.rejected，被放弃的路径与最终选择同样重要）；工具调用（传给外部工具的精确参数及返回结果，副作用发生于此）；输出与审批（原始补全、结构化决策及人工审批元数据）。
防篡改机制：每个动作作为独立条目追加到账本，条目携带由自身规范负载、时间戳及前一条目哈希计算出的 SHA-256 哈希，形成连续哈希链。过去记录中任何字节被改动、删除或重排，后续哈希即失配，验证立即失败。哈希链证明已捕获内容的完整性，不证明完整性——未插桩的运行无法被链补救。自托管账本上的封条仅证明内部一致性，要抵御「你重写了整条链」的质疑，需外部锚定（RFC 3161 可信时间戳），这是防篡改与防伪造的区别。
审计不得危及运行：代理绝不阻塞于记录层，span 异步导出、批量处理、失败时缓冲，后端缓慢或不可达只损失遥测延迟，不影响运行本身。接收侧故障隔离，编排器与证据层是分离系统，单向数据流。证据层只接收已发生的事实，不参与产生过程，记录因此可跨进程崩溃存活，也可在不同提示词、模型或代码的运行间做 diff。
合规锚点：欧盟 AI 法案第 12 条要求高风险 AI 系统可追溯与自动日志，附件 III 义务自 2027 年 12 月 2 日起适用；SOC 2 Type II 要求证明系统访问与修改经授权且可审计；NIST AI RMF（GOVERN）要求映射问责与透明追踪。
Span Chain 是该指南的参考实现，开源 AI 代理证据层，基于 Elixir/OTP 构建。它不运行或编排代理，执行完全留在你侧；后端被动接收 OpenTelemetry（OTLP/HTTP）span，每个运行隔离在独立进程中，每条目封入 SHA-256 哈希链，可随时用 verify_ledger 验证。Python SDK 批量发送 span 并在失败时缓冲，后端缓慢或不可达不会阻塞代理。它位于可观测性栈之下而非取代之：可观测性展示发生了什么，账本保存证明。
由于账本捕获每次运行的确定性记录，还支持 VCR 式回放：已记录运行可在本地零实时 LLM 调用重放，与基线做结构 diff 可定位确切偏差点。针对修改后代码的新对比运行是真实执行，成本与任何运行相同；重放已记录内容零成本。外部 TSA 锚定（RFC 3161）在路线图上，面向需要从防篡改升级为防伪造的受监管部署。支持 Docker Compose 自托管，MIT 许可。
github.com/ghostfactory-art/spanchain
#开发者 #工具 #AI代理 #可审计性 #哈希链 #OpenTelemetry #Elixir #欧盟AI法案 #SpanChain
@DevToolboxHub