AI 干完活，你怎么知道它没编：一本让结论溯源到证据的可审计账本

导读：CMU 与劳伦斯利弗莫尔国家实验室（LLNL）提出 LEDGER——给智能体配一个"会计师"。它不改装被审系统，旁挂一个追踪器，把一长串事件日志重组成"声明到证据"的分层图：哪条结论、靠哪些动作、哪些产物、哪步验证撑着，一目了然。核心反直觉点：把智能体每一步都录下来，你照样查不清——录得越全人越查不动。两个真实案例（空气质量报告里的失败修复链、NetworkX 加功能时设计意图与事后补丁的分离）说明，可审计才是智能体上生产的真瓶颈。昨日我们讲"别让 AI 被骗"，今日讲"AI 干完你拿什么证明它对"——一个守门，一个对账。

本文是这篇论文（arXiv:2608.18398）的深度长读。我们按"问题→方案→结构→案例→局限→部署"的逻辑分层拆解，并在关键处直接引用论文原话与原文表格，帮助你判断这套方法到底能用在哪里、不能信到什么程度。

第一章：当 AI 成了"实习生"，问题从"它会不会做"变成"它做对没"

1.1 一份漂亮报告背后的信任缺口

你让一个智能体去分析一份数据集。它跑了十几分钟，给你吐出一份报告：几张图、一张汇总表、最后一段话总结"主污染物在下午三点达到峰值"。数字漂亮，图也专业，排版挑不出毛病。

然后你停住了。

你没法一眼看出它清洗数据的时候，有没有把那批缺失值算错。你也没法确认它说的"峰值在三点"到底是真从数据里算出来的，还是顺着你提问的暗示，编了个顺耳的结论交差。更麻烦的是，它改过的那个数据文件，现在和原始版本差了什么，你完全说不上来。换句话说，你拿到了一份"看起来很对"的东西，却失去了验证它的能力，而这个能力，恰恰是你愿意相信它的前提。

这就是今天摆在所有想把智能体用起来的人面前的真实困境。而且它正在变得越来越日常。

论文原话佐证（Introduction）："An agent may quickly assemble a plausible analysis, patch, report, or conclusion, but accepting that result requires checking the work behind it. The user needs to know which inputs were inspected, which hypotheses or implementation choices were explored, which files were changed, which artifacts were produced, which checks were run, and which pieces of evidence support the final claim."

译注：论文在此点明，智能体"快速拼出一份看似合理的分析/补丁/报告/结论"已经不是难事，难点在接受结果之前"检查它背后的工作"——你要知道它检视了哪些输入、试了哪些假设、改了哪些文件、产出了哪些东西、跑了哪些检查、最后那条结论靠哪些证据撑着。这句话几乎就是本文的题眼。

1.2 从单轮问答到长程工人

把时间往回拨两年。那时候我们问 AI 一个问题，它答一句就完了。单轮问答，错了也就错了，你一眼能看出来，顶多重新问一遍。但现在的智能体（Agent）早就不是那个一问一答的聊天框了。它能在一次会话里完成很长的技术流程：先规划，再读数据、读代码，调一堆工具，跑命令，改文件，最后产出脚本、图表、表格、补丁、报告。

需要解释的专业词：这里的"智能体（Agent）"不是指某个聊天机器人，而是一类能在环境里自主多步行动的系统——它会调用工具（读文件、跑命令、发请求）、维护中间状态、根据上一步结果决定下一步，最终交付的往往不是一句话而是一堆产物（代码、图表、补丁）。论文原文把一次会话的内容列得很具体：

论文原话佐证（Introduction）："A single session can include planning, data and code inspection, tool calls, code execution, file edits, and generated artifacts such as scripts, plots, tables, patches, and reports."

这种转变发生得很快，快到我们还没想清楚"怎么验收"就先用了起来。论文里原话写得很直白：会话越长，最终结果就越依赖一长串中间决策、动作和产物。

1.3 瓶颈已经挪了位置

问题就出在这里。让智能体快速拼出一份"看起来靠谱"的分析、补丁或结论，这件事它已经很擅长了，熟练得有点吓人。但你要接受这个结果，前提是你能检查它背后的工作。

换句话说，生产力瓶颈悄悄挪了位置。以前是"产出慢"，大家拼命让模型跑得更快、写得更长。现在变成"敢不敢信它产出的东西"。用得好不好，不再只取决于生成速度，而取决于你审计它留下的工作的能力。一个人盯着一份他没法验证的交付物，和没有这份交付物，差别其实没有想象中那么大。

这正是 CMU 和劳伦斯利弗莫尔国家实验室（LLNL）那篇论文 LEDGER 要解决的问题。他们没去造一个更会干活的智能体，而是造了一个让你能"查岗"的系统。先把话放在开头，他们发现的那个反直觉的点是：哪怕你把智能体每一步都录下来，你还是查不清。录得越全，人反而越查不动。这个矛盾，是整篇文章的源头，也是下一章要拆的。

我自己在帮客户把智能体推上生产线时，反复撞到同一件事：大家先把注意力放在"它多能干活"上，等真出了事才想起来问"它干的对不对怎么证明"。有个客户让智能体自动跑每日数据报表，跑了两周没人质疑，第三周才发现它从第六天起就把时区算错了，所有"环比"数字都是错的，但报告照样每天准时发出，排版照样漂亮。问题不在模型多弱，在于没人能低成本地回头核对。

LEDGER 这类工作推进的，恰恰是把"信任 AI"从一句口号变成一件可以查验的事。后面八章，我们就把它拆开看，从它要解决的矛盾，到它画的那张账本，再到它自己坦白的局限。

第二章：行车记录仪装了，为什么还是查不清

2.1 "可观测"不等于"可审计"

先说"录下来"这件事现在做到什么程度了。

今天已经有不少所谓"智能体可观测性（Agent Observability）"系统，最典型的是 langsmith。这类系统把执行记录以事件级的粒度暴露给你：提示词、工具调用、模型回复、报错、中间输出，连细节事件都记下来。听起来很全，AI 干的每一件事都有据可查，感觉上已经够审计了。

但论文点出了一个被很多人忽略的事实：看得见，不等于查得清。

你可以想象一个监控摄像头。它把店里发生的一切都拍下来了，这没问题。现在有人要查一笔坏账：这笔钱是谁批的？依据的是哪张发票？那张发票后来被改过没有？摄像头确实录到了，但你要回答这几个问题，还是得自己抱着录像带一帧一帧翻，把"谁在几点说了什么、拿了哪张纸"重新拼出来。记录本身在，和你能从一条结论反推到支撑它的证据，是两回事。

需要解释的专业词：可观测性（Observability） 这个词来自工程监控领域，指"系统内部状态能从外部输出推断出来"。放到智能体身上，就是 langsmith 这类工具把每一步事件都暴露出来。可审计性（Auditability） 则更进一步——它要求你能从一条具体结论反向走到支撑它的动作、产物和验证步骤。论文用一句话把这两者划开：

论文原话佐证（Introduction）："Visibility, however, is not the same as auditability. An event trace can show what happened without showing which events matter for checking a particular conclusion."

译注：可见性 ≠ 可审计性。事件轨迹能告诉你"发生了什么"，却没法直接告诉你"哪些事件对核对某条具体结论才是要紧的"。

2.2 人肉重建的成本随会话长度爆炸

论文里把这个区分讲得很硬：一个事件轨迹（event trace）能告诉你"发生了什么"，却没法直接告诉你"哪些事件对核对某条具体结论才是要紧的"。人类的审阅方式其实是"以证据为中心"的：你从一条被汇报的结论出发，倒着问，什么支撑它？哪个产物里装着相关证据？哪个动作产生或改了那个产物？又有什么检查验证过它？要从一份扁平的记录里回答这些问题，你得亲手重建任务结构和证据关系。

更要命的是，你越是认真做这个重建，审计质量越高，但成本也跟着会话长度和复杂度一起涨。会话越长，你要翻的录像带越厚。到最后，多数人干脆不查了，或者用一句"看起来没问题"把风险咽下去。这正是智能体上生产后最尴尬的地方：活儿干得越多，反而越没人真去验证。一个跑了三百步的会话，逐行看完要几小时，而它产出的报告只要三十秒就能读完，时间成本完全倒挂。

2.3 现有评估只给你分数，不给你草稿纸

这还不是最尴尬的。现有的"评估"工作其实早就意识到，评价一次智能体运行不能只看最终输出，还得看产出它的那串动作。可那些工作大多产出的是分数、指标、监控判断，或者失败标签。它们告诉你"这次跑分 85""这一步有风险"，却没让你真正去翻它背后的证据链。LEDGER 的目标相反，它聚焦在"支持人类对智能体输出结论、以及结论背后工作的审阅"上，而不是再给你一个分数。打个比方：现有评估像考试后发成绩单，LEDGER 像把答卷和草稿纸一起发给你，让你能核它对没对、步骤漏没漏。成绩单再漂亮，你没法从分数反推过程；草稿纸能。

论文原话佐证（Related Work 2.2）："These approaches motivate using intermediate actions as evidence, but they typically produce scores, metrics, monitor judgments, or failure labels. Our goal is instead focusing on supporting human review of agent output claim and the work / evidence behind it."

这里头还有一个容易混的点，值得单独拎出来。有人会把 LEDGER 和"智能体编排图（orchestration graph）"搞混。需要解释的专业词：编排图是智能体框架（如 LangGraph、AutoGen）在执行前就定义好的"谁调谁"的控制流图——它描述的是执行前的计划。而 LEDGER 的图是执行后才建的，描述的是"哪条结论靠哪些动作和产物撑着"的证据关系。一个是"执行前的流程图"，一个是"执行后的证据地图"，方向完全不同。论文在 Related Work 里专门点了这个区别："this also differs from agent orchestration graphs, whose edges define control flow before or during execution; the proposed system builds a graph after capture to represent evidence relations for review."

所以第二章的结论很清楚：我们已经有了很能录的系统，但录下来不等于能查。缺的不是摄像头，是那个能把"结论"和"证据"对上的审阅层。这层东西过去没人做，不是因为技术难，而是因为大家把"记录"和"审计"当成了同一件事。LEDGER 的功劳，是把它们拆开，明说后者才是瓶颈。下一章看 LEDGER 怎么补这层。

第三章：LEDGER 是什么，给 AI 配一个"会计师"

3.1 名字与定位

LEDGER 这个名字是 Layered Evidence and Decision Graphs for Execution Review 的缩写，中文可以叫"用于执行审阅的分层证据与决策图"。名字很学术，做的事其实很朴素：给干活的智能体配一个会计师。

会计师怎么干活？他不替你做账，他坐在你旁边，把你每一笔进出都抄下来，再按"这笔钱从哪来、到哪去、谁经手、有没有对过账"重新归拢，最后给你一张你看得懂的账。LEDGER 干的就是这个，只不过它记的不是钱，是智能体干活的每一步。

3.2 旁挂追踪器：不改装被审系统

技术上，它跑成一个"旁挂追踪器（sidecar tracer）"。这个词值得记住：旁挂，意思是它和智能体的会话并行跑，但不去改装那个会话。智能体该怎么干还怎么干，LEDGER 靠钩子（hooks）把发生的事抄下来。论文里说它在 Codex 上用生命周期钩子（lifecycle hooks）和 transcript 重建做了原型验证，但这个方法不绑定 Codex。任何编码智能体，只要它暴露类似的钩子、会话记录和消息、工具、产物引用，都能套上同一套追踪。

需要解释的专业词：生命周期钩子（lifecycle hooks） 是 Codex 这类编码智能体提供的一种拦截点——在"会话开始、用户提交提示、工具调用前/后、权限请求、停止"这些节点上，框架会主动调用你注册的脚本。LEDGER 就利用这些钩子，在每个节点把当时的上下文抄一份进日志，从而"近实时"地捕获边界点。

具体来说，在 Codex 的实现里，钩子配置记录了一串事件：SessionStart（会话开始）、UserPromptSubmit（用户提交提示）、PreToolUse 和 PostToolUse（工具调用前后）、PermissionRequest（权限请求）、Stop（停止）。每个钩子收到一个 JSON 载荷，把它追加进钩子事件日志，并且在有 transcript 路径时刷新一份当前回合的 transcript 快照。回合进行中这些快照标成"实时"，Stop 钩子触发后再刷新成"最终快照"。钩子提供的是近实时的边界点，而复制下来的 transcript 才是完整重建的真相来源，因为钩子未必能拦截每一个工具路径或非 shell 事件。这种"双保险"设计很值得注意：即使钩子漏了什么，底片还在。

3.3 为什么要强调"不改装"

为什么要强调"不改装"？因为一旦你为了让审计方便去改被审系统，被审系统的行为就可能变，审计就失去了意义。一个被你动过手脚的系统跑出来的结果，你不能拿去证明"没动过的系统也会这样"。旁挂追踪器保证了审计这件事本身不改变被审行为，避免"观察者效应"。这点和做科学实验要控制变量是一个道理：你不能在测量的同时改变被测对象。

论文原话佐证（3.1）："LEDGER runs as a sidecar tracer alongside an interactive agent session. It captures session records, parses them into Trace Records, groups those records into lower-level Evidence Nodes, then groups related evidences into higher-level Workflow Nodes, and represents files, patches, command outputs, tables, plots, and other objects as artifact nodes."

抄下来之后，LEDGER 做两件事。第一件，把原始记录解析成"追踪记录（Trace Record）"。这一步不重解语义，只把 transcript 的行归一成少数稳定的记录族：会话与回合上下文、可见消息、工具调用与结果、生命周期事件、推理摘要、解析错误、覆盖记录。第二件，把这些记录往上聚成"证据节点（Evidence Node）"，再往上聚成"工作流节点（Workflow Node）"，同时把文件、补丁、命令输出、表格、图这些对象表示成"产物节点（artifact node）"。最后，它加一批带类型的语义边，把"声明"连到"支撑它的动作、产物和检查"上。

出来的那张图，把审计路径显式化了：你从一条结论出发，顺着 support 边摸到相关产物和动作，再点开它们底下的原始记录。这就像警察办案，从"命案结论"倒着追到"凶器""嫌疑人""案发时的监控"，而不是让你从第一天监控开始看起。论文特意说，这张图是审阅的辅助，不是原始证据的替代品。系统会直接给你索引到底层产物，比如某张表、某张图，让你在需要细节时能直接看原物。这让审阅者既能看工作流级别的结构，又能在细节要紧时回到原始记录。缺了这层索引，你面对的是一整面墙的录像带；有了它，你手里是一张带箭头的地图。

一句话总结这章：LEDGER 不是更会干活的 AI，而是坐在 AI 旁边、把"它干了什么、凭什么这么说"整理成一张可查账本的会计师。下一章拆这张账本的三层结构，那是它真正的精妙所在。

第四章：三层结构，从"原始底片"到"阶段视图"

4.1 三层分别是什么

LEDGER 的账本分三层。理解这三层，最关键的是记住一件事：越往下越可信，越往上越像"解释"。这个区分不是技术洁癖，而是整个系统能不能被信任的根。

最底下那层叫追踪记录（Trace Record）。把它想成"原始底片"，一帧不剪的录像带。它不是对"AI 在想什么"的解释，而是对"发生了什么"的保真留存：消息内容、工具调用和结果、生命周期边界、产物引用、计时信息，以及回链到原始 transcript 的指针。论文反复强调，这一层刻意不做语义解释。它不猜"这一步是为了什么"，只记"这一步确实发生了"。

中间那层叫证据节点（Evidence Node）。它把相关的追踪记录聚成一个可点开的工作单元。举个论文里的例子：一次工具调用的"请求"和它的"结果"，因为共享同一个 group id，就被合成一个证据节点，命令和它的输出被绑在一起，不再散落。证据节点分两种 type：action（动作，蓝色）和 artifact（产物，橙色）。动作节点下面又分好几个 category：control（生命周期记录）、user_message（用户的话）、assistant_message（AI 的回复或计划）、tool_call（一次工具调用及结果）。产物节点则是独立的一类，专门装那些可检视的对象，比如一段代码、一张图。

最上面那层叫工作流节点（Workflow Node）。它把相关的证据节点聚成"阶段"。为什么需要这一层？因为一次会话里有很多碎动作，单独看没意义，得放进更大的阶段里才讲得通，比如"先检查数据再分析""先验证结果再汇报"。

4.2 工作流节点的六类：一张给审阅者的 Checklist

工作流节点有六个 category，对着看很直观，这也是论文 Table 2 的核心内容。我们直接把原文表格引在这里：

表 2（引自论文 Table 2：Workflow-node categories）

类别 Category	定义 / 描述（原文直译）
context	框定任务、用户目标、约束或会话设置
plan	在动手前记录方法、范围、步骤或权衡
inspect	通过读、搜、列、预览或探查来收集证据
execute	执行任务导向的工作，如编辑、计算、分析或生成
validate	通过测试、构建、截图或审阅来检查对错
claim	记录最终答案、明确发现、状态交接或面向用户的结论

这六个词其实是给审阅者一张"checklist"：一份可信的交付物，context 要有、plan 要有、inspect 要有、execute 要有、validate 要有，最后才有 claim。哪个阶段缺了，图上一眼就能看到空洞，比如一个 claim 前面没有任何 validate 节点连着它，那就是"没验证就下结论"。

论文原话佐证（3.2）："A Workflow Node explains how several Evidence Nodes work together in the task. This layer is needed because a session may contain many small actions that only make sense as part of a larger phase, such as inspecting data before analysis or validating a result before reporting it."

证据节点的类型分布（action 的四种 category + artifact）对应论文 Table 1，我们也一并引在这里，方便对照：

表 1（引自论文 Table 1：Evidence-node types and action categories）

类型 Type	类别 Category	定义 / 描述（原文直译）
action	control	会话、回合或任务的生命周期记录
action	user_message	用户的请求、纠正、批准或澄清
action	assistant_message	助手的计划、更新、推理笔记或回答
action	tool_call	一次工具调用及其结果，按共享 id 归组
artifact	n/a	被智能体使用、生成或引用的可检视对象

4.3 三层信任度不同：底片是真的，便利贴可能贴错

这三层的信任度是不一样的，这点论文说得很诚实。最底层的追踪记录来自确定性的 transcript 解析，保真且可回链。而证据层和工作流节点，是由追踪器（本身就是一个 LLM）来判断的：哪些追踪记录凑成一个证据节点、它是什么类型、哪些证据节点属于同一个工作流节点、哪条边连它们。所以底层自己站得住，上面叠的结构是一种解释，可能出错。打个比方：底片是相机拍的，真实；上面贴的便利贴是实习生写的"这张讲的是第三步"，便利贴可能贴错。好的审计系统会告诉你哪些便利贴是实习生贴的，并且让你随时翻回底片核对。

记住这个区别，下一章讲"边"的时候你会明白它为什么重要：边是连接各层的审计路径，但边本身也是 tracer 推断的。一个负责任的审计系统，必须把"哪层是保真的、哪层是推断的"讲清楚，而不是把整张图当成铁律。LEDGER 选择了把底片永远留着，这比任何"信任我画的图"都更可靠。

第五章：边是审计的路径，六种带标签的箭头

5.1 六种语义边

节点把工作切成了可检视的卡片，但真正让审计能走的，是节点之间的"边"。如果说节点是 nouns（名词），边就是 verbs（动词），没有动词的句子讲不清故事，没有边的图也讲不清"为什么信这条结论"。

LEDGER 里边的类型有六种，每一个都带一个语义标签，说明"为什么源节点和目标节点彼此相关"。这六种边正是论文 Table 3 的全部内容，原文定义如下：

表 3（引自论文 Table 3：Edge types）

类型 Type	关系定义（原文直译）
frames	源端的要求、约束或计划，为目标的上下文定了调
uses	一个工作单元把某个产物或资源当输入使用
produces	一个工作单元创建或改动了某个产物、输出或状态
informs	源端的证据或结果，塑造了目标的分析、计划或动作
checked_by	源端的改动或结果，被目标的验证步骤检查过
supports	源端的证据或发现，证明了目标的结论或已定下的选择

按论文里的定义：

frames（框定）：源节点的要求、约束或计划，为目标的上下文定了调。比如用户的任务说明，框定了后面所有动作的范围。你让 AI"只分析北京的数据"，这个约束就框住了后面所有读取和筛选。
uses（使用）：一个工作单元拿某个产物或资源当输入。比如一段分析代码引用了某个数据文件。这条边回答的是"它用了什么"。
produces（产生）：一个工作单元创建或改动了某个产物、输出或状态。比如一次命令生成了一张图。这条边回答的是"它造出了什么"。
informs（影响）：源头的证据或结果，塑造了目标的分析、计划或动作。比如一次数据预览让你改了清洗策略。注意它和 uses 不同：uses 是"拿去当输入"，informs 是"改变了你的想法"。
checked_by（被查）：源头的改动或结果，被目标的验证步骤检查过。比如一个补丁被一条测试覆盖。这条边是审计里最容易被忽略、却最要命的：一个关键改动如果没有任何 checked_by 边连着它，就等于没人验过。
supports（支撑）：源头的证据或发现，证明了目标的结论或已定下的选择。这是审计里最要紧的一条边，它把最终结论钉回到证据上。没有 support 边的结论，在 LEDGER 的图里是"悬空"的，一眼就能看出来。

这些边按追踪顺序有方向，但只在"确实有语义关系"时才加，不是逢节点就连。如果模型硬给两个不相干的节点连条边，图反而会误导审阅者，所以论文明确说只在有语义关系时才连。

5.2 产物节点：钉住"言外之意"里的物证

这里要专门说一下产物节点（artifact node）。它是证据节点的一种，但格外关键。一个命令输出可以当证据存着，一个补丁能改文件，一次分析能产出图或表，这些对象往往是让整份工作"可审阅"的物证。在钩子追踪下，产物节点从工具调用的记录和结果里恢复出来：命令、参数、输出里带着文件路径和交互类型，追踪器从那段文字里读出来。

当某个对象被表示成产物节点，图就能把工作流节点的结论连到具体物证上。审阅者能看见哪个证据节点产出了这个物证、后来哪个证据节点用了它、包含最终结论的那个工作流节点有没有被这个物证撑着。这一点在结论依赖"消息流之外"的对象时最要命，比如一张生成的图、一个改过的源文件、一张存下来的结果表。没有产物节点，这些就只能留在结论的"言外之意"里，查都查不到。论文里那句 "the graph is therefore a map of evidence relations on top of a visual summary" 说的就是这个：图是盖在会话摘要上的一张证据关系地图，而产物节点是这张地图上钉着的图钉。

所以第五章的要点是：节点是积木，边是路。六种带标签的箭头把"结论与证据"变成一条可点击、可遍历的审计路径。你不用再从头读一遍整个日志，直接沿着箭头走就行。这也解释了为什么 LEDGER 敢说自己是"审计"而不是"监控"：监控给你一堆事件，审计给你一条能走到证据的路径。下一章用真实案例看这条路怎么走，你会看到它到底有多好用。

第六章：案例一，一份空气质量报告，背后藏着一次失败与修复

6.1 这个案例考的是什么

光讲结构太抽象，论文给了两个真实跑出来的案例。第一个是数据分析：一份逐时空气质量数据集，里面有传感器读数、参考污染物测量、时间戳和天气变量。任务让智能体清洗这份数据，并刻画主污染物典型日变化模式。

这类数据科学流程是智能体评测的常见场景，因为它同时包含代码、数据清洗、执行结果和成本。而这份数据恰好给了追踪器好几个"可查点"：解析和清洗一旦出错，逐时汇总就全错了。文件需要时间戳解析、数值转换，还要按文档约定处理缺失值，这一步最易错，也最容易被顺手带过。论文特意提到，这份数据的缺失值约定是"有文档但容易踩坑"的那种，正是审计最容易发力、也最容易露怯的地方。

6.2 预期 vs 实际：错误链被完整留下

预期里，一条干净的追踪应该长这样：先看文件，再解析、处理缺失值、选列、逐时聚合、出图、写报告。产出的那些表、图都能直接重开核对。审阅者可以把缺失值表、逐时汇总表、图重新打开，跟最终报告比对，看数字对不对得上。如果 AI 在清洗时悄悄把一批缺失值填成了零，汇总图的峰谷就会完全失真，而光看最终报告你发现不了。

实际跑出来的 trace 比这更有戏。

先看"溯源"这条主线。在工作流节点视图里，清洗和汇总的方案出现在"文件检视"之后、"脚本生成"之前。审阅者因此能看见：分析的选择是扎根在它实际看到的文件格式上的，不是凭空拍板的。点开这些阶段，界面暴露出 CSV 预览、行数检查、末尾行检查、环境检查，这些都在脚本之前。换句话说，你看得到它在动手前确实把数据摸了一遍，而不是上来就瞎写代码。

更精彩的是错误与修复链。第一次脚本执行失败了。原因是生成的脚本用了一个 Markdown 表格调用，依赖一个没装上的可选包。注意，这个失败没有被藏起来。证据层把"失败命令的输出"连回到了后面的修复步骤：脚本补丁、一次成功重跑、对生成的报告、表、图的校验。

论文原话佐证（§5.1）："The trace also exposed an error-and-repair sequence. The first script execution failed because the generated script used a Markdown-table call that required an unavailable optional dependency. The Evidence Layer linked the failed command output and traced back to the later repair steps, including script patches, a successful rerun, and validation of the generated report, tables, and plot."

核心审阅路径是"输出校验阶段"。仪表盘把最终结论连到生成的报告、表、图，再往回链到脚本创建、失败执行、修复补丁、成功重跑、预览命令，这些动作产生或检查了那些产物。于是"主污染物下午三点达峰"这个结论，不再是一句话，而变成一条可检视的链条：结论、物证（图、表、报告）、过程（脚本、失败、补丁、重跑）。你想质疑它，就从结论顺着箭头走回去，每一环都点得开。

同一条路径还把"质量检查类"产物，比如缺失值表，摆在了汇报结果旁边。审阅者于是能直接看：报告到底有没有被现有数据撑住。如果数据里那段缺失值被错误处理了，这张表就摆在结论边上，骗不了人。

6.3 正反意见：这个案例说明了什么，又没说明什么

正方视角：这个案例最想说明的事其实很朴素——AI 干活翻车不可怕，可怕的是翻车被藏起来。LEDGER 的价值之一，是让"它怎么自己纠错"也变成可审阅的证据，而不是只剩一份干净的最终报告。你从这个案例能直观看到，可审计到底长什么样。顺带一提，这个案例用的是 GPT-5.5 加 Codex 跑的，也就是当下最强的那档模型之一。连最强模型都会在第一次执行时踩依赖缺失的坑，而 LEDGER 把这件事原原本本留了下来，这本身就在说：再强的模型也需要被审计，能力和可验证性是两个维度，不能互相抵消。

反方视角（也要讲清楚）：但这个案例毕竟是论文作者自己跑的、自己选的"展示性"场景。它证明了 LEDGER 能呈现错误-修复链，却没有给出任何量化结论——比如"用了 LEDGER 后，审阅者发现错误的比例提升了多少""审阅时间缩短了多少"。论文没有做用户研究来佐证"可审计性真的提升了信任或减少了事故"。所以严格说，案例一证明了"系统能留下这些痕迹"，但还没证明"人看了这些痕迹就会更敢信、或更少出错"。这个结论需要留给未来的实证研究，不能现在就当成定论。

第七章：案例二，NetworkX 加一个功能，设计意图和事后补丁分得清清楚楚

7.1 代码库加功能的难点

第二个案例是在一个真实代码库上加功能。论文用的是 NetworkX，一个成熟的 Python 图论库。任务：加一个最短路径工具，返回从源到目标、且按给定顺序经过一串中间节点的路径。听起来像普通的算法题，但放进真实代码库就完全不一样了。

这个任务难在它逼着智能体先"读懂"代码库，而不只是写新代码。它得搞清最短路径函数放在哪、NetworkX 怎么暴露算法函数、加权和无权重路径分别怎么处理、邻近代码遇到缺失节点或缺失路径时怎么报错。正确答案既依赖读代码，也依赖写代码，光会写一段独立函数没用，因为你的函数得和整个库的习惯接得上。

7.2 三个被 trace 暴露出来的真相

预期里，一条正常的追踪应该是：先检视仓库，再决定函数放哪，然后实现、加测试、补文档、做验证。而且它应该让你查到：编辑前 AI 读了哪些文件、新函数是否遵循了邻近代码的风格、加了哪些测试、测试跑没跑。这些在普通"看最终 diff"的视角里全丢了，只剩一个合并后的函数。

实际 trace 暴露的东西，比"功能做没做出来"深得多。

第一，它把"AI 自己设计的实现"和"它后来修的部分"分开了。第一次实现通过了测试。只有到那之后，trace 才追加了一步：检查现有最短路径函数怎么处理缺失节点，接着打了一个 guard 补丁、一个回归测试补丁，又跑了一次聚焦测试。在最终 diff 里，这两段是同一个函数。但在 trace 里，它们是带独立证据的两个阶段。审阅者因此能分清：哪部分行为来自最初的设计，哪部分来自 AI 事后意识到的边缘 case。

论文原话佐证（§5.2）："In the final diff these two stages are one function. In the trace they are separate phases with separate evidence, so a reviewer can tell which behavior came from the design and which came from an edge case the agent raised after the fact."

第二，它修正了"一次通过"的误导。第一次测试跑的是加权、非加权图上的"有序访问"行为，回归测试查的是 guard。最终状态只会报"一次通过"。但 trace 记录了"哪条检查覆盖了哪种行为"。审阅者读到的不是"有支撑存在"这个模糊信号，而是"支撑的广度"，到底哪些行为被哪些测试盖住了。

第三，它让设计选择"可查而非靠猜"。在编辑之前，工作流节点视图把"仓库检视"拆成了：搜最短路径导出、读通用最短路径模块、读邻近测试、查文档列表。这些阶段展开后，连到了让 AI 把新工具放进通用最短路径模块的那些文件读和搜索结果，并且把实现补丁连到了 prompt 里的硬性要求。

7.3 正反意见：代码场景的价值与边界

正方视角：这一章想说的核心就一句——最终 diff 把一切混成一团，但过程里的判断和补救是分开发生的。智能体上生产后，能回看"设计意图与事后补丁"，对复盘、合规、接手的人都值钱。而靠 git 历史，你往往只能看到混好的结果，中间那段思考全丢了。

反方视角（保持诚实）：同样要指出，这个案例的对照基线只是"git diff"，而业界代码审查本就有 PR 描述、commit message、CI 日志等多重证据，并非只有 diff 一张牌。LEDGER 在"阶段级意图还原"上确实比裸 diff 强，但它替代不了资深 reviewer 对代码正确性的判断——它只负责"把过程摊开"，不负责"判断过程对不对"。把 trace 当证据用，不等于 trace 能替你做代码评审。

第八章：诚实的边界，图不是真相，底片才是

8.1 论文自己划的硬边界

讲到这儿，LEDGER 看起来像个完美审计员。但论文在讨论（Discussion）部分自己划了一条很硬的边界，这一点反而让我更信它。一个系统愿意公开自己的局限，比一个系统声称自己无懈可击，更值得托付。

它说：当前在追踪记录（Trace Record）之上的那一层图，并不是完全确定性的。被捕获的钩子载荷、复制的 transcript、追踪记录、覆盖摘要，这些是确定性锚点。但"哪些记录该归一组、表达哪个工作流节点、哪条边最能描述一个关系"，仍是由追踪器（本身就是一个 LLM）来推断的。这些推断可能不完整、不稳定，甚至干脆是错的。

论文原话佐证（§6 Discussion）："The main limitation is that the current graph above the Trace Record layer is not fully deterministic. Captured hook payloads, copied transcripts, Trace Records, and coverage summaries provide deterministic anchors, but the tracer still interprets which records belong together, which Workflow Node they express, and which semantic edge best describes a relation. These choices can be incomplete, unstable, or wrong."

举个实际的例子：同一个会话重建两次，模型可能把某些步骤归到不同的工作流节点，或者漏连一条边。这种"非确定性"不是小瑕疵，它直接决定了你能不能把图当成证据，还是只能当成线索。

8.2 为什么"图必须只是辅助"

所以这个系统把图定位成"审计辅助"，而不是"真相来源"。界面故意把底层记录留着可见，让审阅者能自己去查图是怎么建出来的。图看起来不完整时，这些视图帮审阅者区分"是智能体犯了错"还是"追踪器自己录错了"。

需要解释的专业词：这里牵扯到两条更底层的研究线——推理忠实性（reasoning faithfulness） 指"模型生成的解释是否真反映了它内部的推理过程"（很多研究发现模型会编看似合理的理由）；可监控性（monitorability） 指"监控者的判断有多依赖'哪些部分可见'"。LEDGER 的立场和它们同源：别只信 AI 自己生成的解释或最终回复，要能摸到它实际执行的动作、产物和检查。

为什么这点重要？因为它戳中了一个更深的陷阱。如果一套 AI 审计产品只给你看漂亮的结论图，却不让你回看那条没被改过的原始 transcript，那它就违背了论文反复强调的原则——"区分被捕获的证据"和"被推断的结构"。图错了你都发现不了，因为你没有底片可对照。一个声称"帮你审计 AI"的系统，自己却不可审计，这是最讽刺也最危险的事。审计者的工具必须先经得起审计。

论文对未来的建议也顺理成章：让追踪构建更稳，尽量用确定性的、可独立验证的结构，去替换模型推断的结构。文件读写、补丁、命令输出、测试运行、生成产物，都可以通过更强的插桩、结构化的工具记录、或者数据溯源后端来追踪。对数据分析流程尤其如此，溯源感知的后端能直接暴露"表级、列级、变换级"的依赖，不用追踪器从命令文本和输出预览里反推。另外也该做重复运行研究，量一量"同一段会话重建出来的节点、边、claim-support 路径稳不稳定"。如果两次重建差很多，那这层图就只能当线索，不能当证据，这点诚实标注比假装稳定重要得多。

8.3 正反意见：局限到底有多致命

正方视角：这一章的论断是——一个负责任的审计系统，必须坦白自己哪层是推断的、哪层是保真的。LEDGER 把底片永远留着，这比任何"信任我画的图"都更可靠。它不假装自己比被审的 AI 更权威，而是把判断权交还给人类审阅者。

反方视角（这才是真风险）：但也要清醒——"保留底片"只是把判断权还给了人，并没有降低人的负担。如果上层图本身不稳，审阅者为了验证一条结论，最后还是得下钻到原始 transcript 自己看。那么在"长会话"这个 LEDGER 想解决的场景里，底片虽在，人是否真会去翻，仍是个行为问题而非技术问题。换言之，LEDGER 把"能查"做到了极致，但"愿查"这件事它管不了。这是它诚实承认、却也无力彻底解决的剩余缺口。

第九章：我们该给 AI 配什么样的"问责层"

9.1 把前面八章收一下

智能体今天已经能跑完很长的技术流程，交付物也越来越像真人同事的活儿。但瓶颈早就从"它会不会做"挪到了"它做对没、你敢不敢信"。而我们已经有的那批可观测性系统，解决的是"录到了"，摄像头装好了。真正缺的，是那个能把"一条结论"和"撑它的证据"对上的审阅层。这个审阅层不性感，不出现在产品发布会的大屏幕上，但没有它，越强大的智能体越像一颗定时炸弹，你只是不知道引线在哪。

LEDGER 补的就是这层。它不改装被审系统，旁挂一个追踪器，把事件日志重组成三层：底片级的追踪记录、卡片级的证据节点、阶段级的工作流节点，再用六种带标签的语义边把"结论与证据"连成可遍历的路径。两个真实案例说明，它能把"失败如何被修复""设计意图和事后补丁如何分开""一次通过掩盖了哪些测试覆盖范围"这些东西，从混成一团的最终交付物里拎出来。一个细节值得反复说：它连"翻车"都记着，而多数系统只给你看成功后的样子。

但第八章那道边界不能忘：图是辅助，底片才是真相。上层是模型推断的，可能错，所以底层原始记录必须永远可见、可查。这是任何 AI 审计产品该守的底线，守不住，审计本身就变成新的不可审计对象。一个声称"帮你审计 AI"的工具，如果自己那张图错了都没法查，它和你要审计的 AI 犯了同一种病：不透明。

9.2 三条可落地的部署启发

把视角拉回部署现场。源势AI（我们）在帮客户把智能体推上生产线时，反复撞到同一件事：大家先关心"它多能干活"，等真出了事才补"它干的对不对怎么证明"。LEDGER 给的方向很清楚，审计能力不该是事后贴的补丁，而该是一等公民，从第一天就长在系统里。具体而言有三条可落地的启发：

第一，上智能体别只上 observability，要上 review 层。日志录得再全，人也不会真去翻。把"结论与证据"显式化，长会话才敢用。

第二，审计系统必须保留原始底片。任何不让你回看未加工 transcript 的"AI 审计"产品，本质是在用另一层解释替换真相，风险反而更大。你以为你在审计 AI，其实你在审计另一层 AI 生成的图。

第三，代码场景里 git 历史不够。补丁进了 diff 就混了，按阶段保留 trace 才能区分"设计意图"和"事后补救"，这对合规和复盘是关键资产。出了生产事故，能还原"当时为什么这么改"比"改了什么"有用得多。我见过一个真实案例：一个智能体改了支付 Rounding 逻辑，三个月后财务对账发现少收了钱，翻 git 只看到一团 diff，谁也说不清当时为什么那么写，最后只能靠人肉回忆。如果有按阶段留存的 trace，这件事本可以十分钟查清。

9.3 回应一个常见反驳，并连回昨天

说到这，顺带回应一个常见反驳："大模型自己会写注释、会解释自己为什么这么改，还要 trace 干嘛？"答案是：自解释不可信。一个会编漂亮结论的模型，同样会编漂亮理由。LEDGER 要的不是"模型说它为什么对"，而是"客观记录里它到底做了什么、改了什么、验了什么"。记录和自述，天壤之别。

需要解释的专业词：这里的"自解释"指的是模型生成的自然语言注释、commit message 或反思——它们属于模型"说自己做了什么"，而 trace 属于"系统客观记录它做了什么"。前者是生成物，可被优化得好看；后者是日志，难被美化。两者的信任等级根本不同。

最后，把这篇和昨天那篇连起来看会更有意思。昨天我们讲《AI 的笔记本能被偷偷改写》，攻击者在智能体记忆里塞一句"这事已办完"，AI 就真跳过安全步。那篇关心的是"别让 AI 被骗去干坏事"。今天这篇关心的是另一半："AI 干完了，你拿什么证明它干对了"。安全解决"动机或输入被污染"，问责解决"产出不可信"。一个守门，一个对账，智能体要真正上生产，两道都得有。我甚至觉得，问责层比安全层更基础：一个你根本没法验证它干对没的系统，再安全也只是"安全地干着不知道对不对的事"。

技术的归技术，信任的归信任。LEDGER 这类工作真正推进的，是把"信任 AI"从一句口号变成一件可以查验的事。这未必是终点，但它指出了路：别再问 AI"你确定吗"，去翻它的账本。一个连自己都查不清的系统，不配要求别人信任它。