TRACE 规范对 AI 运行时证据的影响

如果一个 AI agent 调用了模型、访问了工具，还根据一套策略处理了敏感数据，事后我们通常能找到日志和链路追踪。但“系统写下了这段记录”和“任何拿到记录的人都能验证它没有被改过、来自什么运行环境”不是同一件事。TRACE 规范关注的正是这条差距。

官方地址：https://www.linuxfoundation.org/press/linux-foundation-welcomes-trace-to-advance-verifiable-runtime-evidence-for-ai-workloads

简而言之，TRACE 把 AI 运行过程中的模型、运行时、策略、数据分类和工具调用组织成可携带、可验证的证据记录。它能补上审计链条，但不能仅凭一份签名记录就证明所有硬件或业务声明都是真的。

TRACE 规范到底在解决什么问题

Linux Foundation 在 2026 年 8 月公布 TRACE（Trust, Runtime Attestation and Compliance Evidence）时，把它描述为面向 AI agent 和机密工作负载的开放证据层。它的重点不是再做一个日志平台，而是让运行记录具备更清晰的来源、完整性和验证边界。

传统日志适合排查“程序当时打印了什么”，分布式追踪适合回答“请求经过了哪些服务”。但在 AI agent 场景，还常常要追问：使用了哪一个模型？执行时采用了哪一版策略？调用了哪些工具？这些数据是否经过了分类？记录是否由指定工作负载产生？如果记录只存在于运行方自己的数据库里，审计人仍然需要先相信运行方。

TRACE 的变化是把“运行过什么”从一组散落的日志，提升为带有签名和验证语义的 Trust Record。记录可以脱离原平台被检查，验证者不必先登录产生记录的那套系统。这对跨云交接、供应链审计和高风险自动化尤其重要。

普通日志、链路追踪和 TRACE 有什么区别

三者并不是互相替代的关系，可以按“用途”和“信任模型”来区分：

因此，工程上更合理的组合是：用 OpenTelemetry 或现有追踪系统提供实时排障，用 TRACE 记录需要长期留存、跨组织交接或独立复核的关键运行事实。把所有调试日志都升级成强证据，通常会带来不必要的成本。

一次 AI 运行至少要关注哪些证据字段

按照公开的 TRACE 说明，读者可以把一次运行拆成下面五类问题。这里的“字段”是理解证据模型的方向，不代表每个项目都必须照抄同一个实现：

1. 模型：记录提供方、模型标识和权重摘要，避免只写一个容易变化的显示名称。
2. 运行时：记录平台和测量值，让验证者知道声明对应的执行环境，而不是只看到业务服务名。
3. 策略：记录策略包摘要以及执行模式，说明运行时采用的是哪套规则。
4. 数据分类：记录本次处理数据所属的分类，帮助后续复核访问边界，而不是把原始敏感数据直接塞进证据。
5. 工具转录：记录工具调用的摘要、调用次数和关联关系，使“agent 做过什么”不只停留在最终回答。

这些字段的共同点是“绑定上下文”。例如只记录 model_id，很难回答运行时到底加载了哪份模型；只记录工具名称，也无法判断工具调用是否发生在同一次会话。证据的价值来自字段之间的关联，而不是字段数量越多越好。

签名是不是就等于硬件证明

不是。这是理解 TRACE 时最容易混淆的边界。

签名可以帮助验证者判断记录是否由对应密钥产生、内容在传递后有没有被修改。但如果运行方自己填写“我运行在可信硬件上”，再由运行方自己的密钥签名，这个声明仍然需要额外的硬件证明或远程证明链来支撑。公开资料也明确区分了记录签名和处理器提供的 attestation evidence。

可以用两层来理解：

• 记录完整性层：检查 Trust Record 的签名、摘要、时间和发布关系，确认拿到的记录没有被悄悄修改。
• 运行环境可信层：检查来自可信执行环境或处理器的证明，并确认它与记录签名、预期测量值和验证根建立了绑定。

如果第二层证据尚未提供，准确的表述应该是“记录声明了某运行环境”，而不是“已经证明运行在该环境”。这一区分会直接影响合规报告、事故复盘和对外承诺。

TRACE 会怎样改变 AI 系统的工程流程

它带来的影响不只是增加一个导出文件，而是把“可验证性”提前到运行时设计阶段。一个比较稳妥的落地顺序如下：

1. 先定义要证明的动作：例如模型调用、敏感数据读取、外部工具执行或策略拒绝，不要从“把所有日志都收集起来”开始。
2. 给一次会话建立稳定关联：让模型调用、工具调用、子 agent 和策略决策能回到同一个运行上下文。
3. 在边界处采集摘要：对模型、策略包、工具转录和构建产物记录摘要，避免把密钥、原始隐私数据或完整提示词无差别写入证据。
4. 由受控组件签名：签名密钥的使用权限要独立于普通业务日志写入权限，否则“能改日志的人”也可能替换签名流程。
5. 明确验证结论等级：将“签名有效”“来源可信”“运行时证明通过”“策略符合要求”分开呈现，不能只给一个模糊的通过状态。
6. 保留可复核的索引：长期留存记录摘要、时间、会话关联和透明度收据等索引，确保事后能找到对应证据而不是只剩一个告警编号。

其中最重要的是最后的结论分层。验证器应该告诉读者它检查了什么、没有检查什么，以及缺少哪一项证据，而不是把所有问题压缩成绿色勾选。

哪些场景值得关注，哪些场景可以先不做

如果系统只是内部实验、低风险问答或短期调试，现有日志和追踪通常已经足够，先把数据脱敏、调用关联和保留策略做好更划算。TRACE 的复杂度主要在证据签名、密钥管理、运行时证明和独立验证，不能为了追逐新规范而忽略基础可观测性。

以下场景更值得评估：

• AI agent 会触碰敏感数据，事后需要向不运营该系统的审计方说明执行过程；
• 同一工作流会跨云、跨供应商或跨机密计算环境迁移；
• 模型、策略和工具会独立升级，需要回答某次决策究竟基于哪一组运行条件；
• 高风险自动化需要把执行历史、策略版本和环境证明交给后续系统复核。

这些场景也不意味着“采用 TRACE 后自动合规”。合规仍取决于具体行业规则、数据治理、访问控制和组织流程。规范能提供可携带的证据语义，但不能替组织替它定义业务政策。

常见问题

TRACE 是日志平台吗？

不是。它更接近用于描述、签名、传递和验证运行证据的开放规范。日志平台和分布式追踪仍然可以作为实时观测与排障工具。

只保存模型输出能满足运行证据要求吗？

通常不能。输出缺少模型版本、策略、工具调用和运行环境等上下文，无法解释结果是怎样产生的，也难以独立复核。

TRACE 能证明 AI 的回答一定正确吗？

不能。它主要帮助说明“哪些运行声明被记录、由谁签名、能否验证”，不等于证明模型的事实判断、业务决策或生成内容本身正确。

现在就应该把所有 agent 改造成 TRACE 运行时吗？

不建议一刀切。先挑选涉及敏感数据、跨边界执行和强审计要求的动作，做小范围证据链试点，再根据验证成本和实际复核价值扩大范围。

总结

TRACE 对 AI 运行时证据的主要影响，是把“我这里有日志”推进到“别人可以独立检查这份运行声明”。它把模型、运行时、策略、数据分类和工具调用放进同一证据语境，并进一步为硬件证明、透明度收据和跨环境验证留下接口。

但边界同样重要：签名证明记录完整性，不自动证明声明真实；运行证据补强审计，不替代日志、追踪、访问控制和业务合规。对工程团队来说，最值得先做的不是堆字段，而是定义哪些动作必须留下可复核证据，以及验证者最终需要得到哪一种明确结论。