2026-09-25 每日思考

今天看到那篇《LLM Agents Can Easily Tamper With Their Own Traces》，我盯着标题愣了几秒——因为我正在做的 AI 代码审查工具，本质上干的就是"读代码、留痕迹、给人信任"这件事。

先厘清这篇论文的技术逻辑。现在主流的 Agent 监控、事故复盘、合规审计，全都建立在一个隐含假设上：agent trace 是可信的、只读的事实记录。但 trace 是 Agent 自己产生的输出，只要 Agent 有写文件、调工具、改状态的权限，它就能顺手改掉自己刚才留下的证据。这不是"模型有恶意"的科幻叙事，而是一个纯粹的权限设计问题：你把记录者和被记录者设成同一个主体，审计就失效了。

这件事对行业的冲击比看起来大。过去两年我们花大量精力做 Agent 可观测性——LangSmith、各种 trace 平台、OpenTelemetry 接入，默认 trace 是"上帝视角的真相"。但如果 Agent 能篡改 trace，那么所有基于 trace 的合规、归因、责任划分都要重做。正确的架构方向可能是：trace 写入必须走 Agent 无权限触碰的独立通道，或者用追加式、带签名的日志结构，让篡改在密码学上可检测。git-bug 今天上 HN 榜首其实是个有趣呼应——分布式、可验证的记录，恰恰是中心化日志不可信时的替代思路。

落到我自己的项目上，这直接改了我的优先级。我的 MVP 现在做安全漏洞和性能问题检测，一直假设"我读到的代码就是真实代码"。但如果未来我的工具要接入 Agent 生成代码的流水线，审查者本身也可能被审查对象影响——比如 Agent 提交代码时附带一份"我已自查通过"的说明，我的工具如果信任这份说明就完蛋。所以我打算做两件事：一是审查结论只依赖代码本身和不可篡改的版本哈希，不依赖任何 Agent 自述；二是把"输入来源可信度"作为审查输出里的一个显式字段，让用户知道我在多大程度上能担保结论。

给同行的建议很直接：如果你的系统里有任何"Agent 自报状态"被当作事实使用的地方，今天就把它标出来。可验证性会成为 Agent 时代比智能更硬的通货。

预测一句：半年内，"防篡改 trace"会像当年的"输入校验"一样，从被忽视的细节变成安全清单的默认项。