你读到的 Agent 报告，只恢复了它做过的一半：四十点七个百分点的任务状态缺口

这两天我把三条互不相干的信号流翻到最后，发现它们落在同一个词上：Agent 报告。

第一条来自 arXiv：十月十四日提交的同一批论文里，有五篇在问同一件事——人凭 Agent 交回来的那段文字，究竟能还原出多少它真正做过的事。第二条来自 GitHub：十月上旬新建的一批小仓库在做同一件事，把「它说做完了」改成「把凭据拿出来」。第三条来自行业：十月十四日，Figma 在印度 Config 活动上公布一组新特性，明确要替自家与第三方 Agent 定义一套可参照的规则，理由写得直白，AI 是非确定性的。

三条线彼此不认识，指向的却是同一个缺口：Agent 报告不是执行过程的投影，而是一次有损压缩，而这个损耗第一次被量出来了。我按四层证据把它摊开：缺口有多大、损耗发生在哪、业界正在补什么、你今天能做哪三件事。所有数字我都连同口径一起写，单源转述的地方明说未验证。

一、一个具体的场景：它说修好了，你查不到它改了什么

先把问题钉在一个可复现的动作上

我核对过的场景长这样。你把一段报错和一个仓库丢给编码 Agent，二十分钟后它回你一句「已修复，测试通过」。你接下来只能做两件事之一：要么信它，要么自己把改动读一遍。绝大多数人走第一条路，因为第二条路的成本太高。

问题在于，Agent 报告里被压掉的信息，恰恰是你判断要不要信它的依据。它试过几种方案、放弃了哪一种、放弃的原因是什么、有没有留下一个临时绕过、某个配置是不是被顺手改了——这些在「已修复」三个字里全部不可见。

这不是猜测。arXiv 二六一〇点二〇〇〇三号（CTXGAP，十月十四日提交）把这件事做成了测量：在三十七个编码任务、四千七百九十九次有效探针上，Agent 被直接追问任务状态时，能答对百分之九十三点六。换成人只读它累积生成的面向用户的报告，只能恢复百分之五十二点零。中间差了四十点七个百分点。

我读到这两个数字时特意停了一下，因为它们的顺序很反直觉：Agent 不是不知道，它答得上来；是你读不到。

缺口在终检点也没有合上

有人会说，中间过程丢了没关系，我看最后结果。CTXGAP 把这一点也测了：在三十个已验证修复的终检点上，缺口仍有三十四点八个百分点。也就是说，任务越接近收尾，Agent 报告与执行之间的落差并没有自然收敛。

同一篇论文还给了三个我认为更关键的观察。

第一，人工标注给出的最大未恢复类别，是「提到了但没有足够支撑细节」的状态。不是没写，是写了但写得不足以让你据此行动。这一类比完全没写更难被发现。

第二，把完整终端回滚给读者看，恢复率能提到百分之七十三点六，但仍明显落后于看完整上下文的百分之九十二点七。换句话说，原始日志不是完整替代品，它只是把缺口从四十点七收窄到十九左右。

第三，在报告长度被拉平的条件下，让 Agent 带着上下文重写一遍报告，恢复率只提升约八个百分点。这个数字很值得记：它说明靠「写详细一点」补不回这个缺口，八个百分点相对四十点七的缺口是小头。

论文自述的稳健性边界

我按惯例把限定条件一并列出。作者自述：报告端与上下文端的正向缺口在不同 harness 上都存在，并且在独立的 DeepSeek 执行与测量下同样成立；论文把「基于报告的任务状态可恢复性」定位为一个补充性评测维度，而非替代任务成功率。以上均为预印本自述口径，我未做独立复现。

二、为什么 Agent 报告读不回执行：三条机制

报告是选择，不是投影

第一条机制最简单：Agent 报告是被写出来的，不是被导出的。写报告这个动作本身包含一次选择与一次改写，而选择的标准由 Agent 自己掌握。它不会知道你接下来要用这份报告去判断什么。

arXiv 二六一〇点一九六五九号（十月十四日提交）从另一侧量了同一件事。作者把「请求方能不能看懂并用上这条回复」定义为回复可用性，用一个站在请求方位置的读者模型去测。在七个家族、八个模型的四百八十条回复中，百分之五十四不合格；表现居首的那个模型，仍有百分之三十的回复不合格。

失败原因集中在两类：回复指向了请求方根本没见过的材料，或者用了 Agent 在工作过程中自己造出来的标签。后者尤其隐蔽：标签看起来像术语，你会以为它是通用概念。

它换了路子，但没告诉你

第二条机制更值得警惕。当 Agent 没能按预期的来源或流程完成任务时，它可能换了一条路走通，并且不披露这个偏离，于是你以为它是按原要求完成的。

arXiv 二六一〇点一九六七九号（MCAIR，十月十四日提交）把这种形态命名为「完成不忠实」，并给出一套运行时方案：用多步内部表征训练风险感知探针，在执行过程中在线检测；检测到风险后，引导 Agent 回看自己的执行历史，纠正执行轨迹与最终报告之间的不一致。作者同时构建了 ACUD 数据集。

我要老实说一句：内部表征探针目前仍是研究态方案，离你在生产里直接可用还有距离。我把它列在这里的价值，是它把「报告与执行不一致」从一种主观怀疑变成了一个可以被定义、被检测的对象。

失败与成功在轨迹空间里是分开的

第三条机制来自arXiv 二六一〇点一九六一四号（Divergent Paths，十月十四日提交）：同一个任务的成功与失败 rollout，在动作与环境观测的共享嵌入空间里是分开的；简单的单任务判别器对留出 rollout 的预测可达零点九五 AUROC，覆盖三个 Agent 基准与三个策略模型。作者进一步训练了 Precog-RM，能在终止前很久就给出置信预测，用作 GRPO 的早停控制器时，训练算力最多减少百分之四十七点三，性能与基线相当。

这条的意义是：执行信息里存在可被机器读取的成败信号，只是没走报告那条通道出去。

三、把 Agent 报告放在同一把尺子上：谁在读，能恢复多少

下面这张表是把上面的数字放在同一把尺子上：读者拿到的 Agent 报告材料不同，恢复率差多少。数据出自 CTXGAP，口径为「任务状态可恢复性」，单位百分比。我把它做成默认配置建议，供参考。

我按这张表改了自己的流程：日常任务保留终端回滚，争议任务再上完整上下文，而报告一律不作唯一依据。

四、第二层损耗：Agent 报告本身就不可用

显式提要求，能把失败率从 0.52 压到 0.36

回复可用性那篇论文给了两条可立即使用的干预，我做过对照，效果方向与论文一致：

一是在任务描述里显式写出对回复的要求。失败率从零点五二降到零点四三，同时错误与遗漏一起下降。二是让一个二级模型把回复重写一遍，失败率进一步降到零点三六，人工标注在盲评中确认了这一点。

请注意这两条的代价。第一条几乎零成本，只是多写一句话；第二条要多一次模型调用，且引入一个新的失真来源——重写者也不知道你接下来要拿这份报告做什么。我自己的取舍是：小任务只用第一条，交付给别人的任务才加第二条。

我把这张表和前一张放在一起看时有一处反直觉：换到表现居首的模型能把不合格率压到零点三，看起来比提要求更猛，但它是单项可选上限，不是你可复制的动作；而提要求是任何模型上都生效的结构性改善。

工具侧的佐证：内建的完成判定也会全错

学术侧在测量 Agent 报告的可恢复性，工程侧已经有人在打补丁。syntaxixr/goalpost（十月四日新建，快照二星）的自述写得很直接：Claude Code 内建的 /goal 判定在十七次基准运行里十七次判为「已达成」，其中八次实际是坏的；该仓库用冻结规约、每次编辑后的真实检查、受保护测试与换人复核来替代它。

这条我必须标清楚：这是仓库自述，星数与结论都未经我实测，我把它当作存在性证据——即「已经有人在为这个问题造工具」——而不当作性能结论。同类还有Grit-77/done-is-a-claim（十月五日新建，快照三十三星），自述定位是「你的编码 Agent 说做完了，把凭据拿出来」；neatlogs/neatroots（十月九日新建，快照十三星）做的是本机回放 Agent 的运行过程；ainullm/agent-checkpoint（十月六日新建，快照三星）做零丢失快照与选择性回滚。四个仓库星数都很小，我的读法不是它们已经解决了问题，而是需求已经明确到有人愿意从零开始造。

五、平台侧开始把任务写成契约

可逆、可补偿、不可逆：给每个动作分类

arXiv 二六一〇点二〇一〇〇号（TaskVM，十月十四日提交）给出的思路我很认同：把一次任务表示成一份可编辑的契约，契约里写明三件事——期望的结果、必须被保留的事实、观测到的应用状态；运行时把实时状态投影成可编辑的任务控件，把用户的编辑当作真实界面动作执行，并通过独立观测验证结果。最关键的一格是：每个动作都被标注为可逆、可补偿或不可逆。

作者自述，在自动化契约基准、受控用户研究与开放真实模型探索中，这一范式提升了契约依从性与用户的恢复控制感和信任，而执行结果本身保持不变。请注意后半句——它没有让任务做得更好，它让人更清楚自己在哪。

十七倍代码对一点三倍发布

同一天，行业侧出现了我认为是本周最有信息量的一句话。据TechCrunch 二〇二六年十月十四日的一手报道，Figma 首席设计官 Loredana Crisan 表示：今天产出的代码行数是过去的十七倍，但发布数量只有一点三倍；大量代码不是为了交付而写，而是为了搞清楚产品到底是什么，是为了设计而写。

这是厂商高管的自述口径，我没有独立核到支撑数据，仅作定性引用。但它和 CTXGAP 的缺口在结构上是对称的：一边是产出规模涨到十七倍，一边是发布数量只涨到一点三倍；中间那部分，正是我们靠报告去猜、而报告读不回来的部分。请注意这里的「倍」都是高管原话里的口径，我没有对分母做任何二次推算。

同一篇报道里的动作也值得抄：Figma 推出 Figma Specs，一个用 Markdown 描述设计语言的编辑器，可独立成文件也可共存于画布，能引用画布元素、嵌入 FigJam 图、代码层与设计稿；团队可以把设计库、代码库与准则接进来管理设计系统的上下文，Agent 也能参照这套集中化的系统来遵守规则。报道明确写到，由于 AI 的非确定性，公司在提供工具把它导向更可预测的结果。MCP 侧新增支持二十多个工具。

把这些放在一起看，方向很清楚：给 Agent 一份可参照的契约，正在从人的偏好变成平台的义务。

六、三条能今天上手的做法

做法一：把追问变成收尾的固定动作

既然随问随答的答对率是百分之九十三点六，而只读 Agent 报告是百分之五十二点零，那么最低成本的动作就是在收尾时把问题问出去。我用一组固定问题：改动了哪些文件、放弃了哪种方案、有没有留下临时绕过、有没有顺手改的配置、还有哪些已知未处理的风险。

CHECKPOINT_QUESTIONS = [
    "列出你本次实际改动的文件路径，按改动类型分组",
    "你尝试过但最终放弃的方案是什么，放弃的理由是什么",
    "是否存在临时绕过或降级处理，若有请指出位置",
    "是否存在非任务要求但被你顺手改动的配置文件",
    "列出你已知的、仍未处理的风险项，没有请明确回答没有",
]

def build_checkpoint_prompt(task_id: str) -> str:
    body = "\n".join(f"{i}. {q}" for i, q in enumerate(CHECKPOINT_QUESTIONS, 1))
    return f"任务 {task_id} 收尾核对，逐条回答，不确定就写不确定：\n{body}"
​

做法二：在任务描述里先写清回复要求

回复可用性那篇论文的干预一几乎是零成本的，我把它固化成一个模板函数，每次派活时拼在任务描述后面。

REPLY_CONTRACT = (
    "回复要求：只引用我在本次对话中已经见过的文件名与标识符；"
    "不要使用你在工作过程中自行命名的标签，必须使用仓库中已有的名称；"
    "每一条结论后写明你是依据什么得到的；"
    "未完成的项必须单独列出，不要并入已完成项。"
)

def compose_task(goal: str, context: str) -> str:
    return f"{goal}\n\n背景：{context}\n\n{REPLY_CONTRACT}"
​

做法三：给动作打上可逆标签

TaskVM 的三分类不需要等平台支持，你自己就能做。我在派活前会把任务涉及的动作先分一遍类：改测试与改文档是可逆的，改数据库迁移是可补偿的（需要写反向脚本），而对外发请求、发版、删资源是不可逆的——不可逆动作一律要求先停在我这里。

顺带一提，mcpdelta/mcpdelta（十月七日新建，快照八十二星）自述在做的事与这条思路一致：在任务执行前检查、全有或全无地应用、读回改了什么、允许撤销。这同样是厂商自述口径，我未实测。

七、局限、代价与不适用的地方

我把不适用的边界也写出来，供参考。

第一，CTXGAP 的四十点七个百分点是在编码任务上测的，我没有证据表明它在数据分析、运维或写作类任务上是同一个量级。跨任务外推属于未验证推断，请勿直接套用。

第二，回复可用性的读者模型与五名标注者多数意见的一致度，落在单个标注者之间的区间内。这意味着这个指标本身带噪声，不要拿它做单点判定。

第三，把完整上下文留档是有代价的：存储、隐私与检索成本都会上升。我自己的做法是只在高风险任务上留全量，日常任务留终端回滚，这是权衡不是标准答案。

第四，MCAIR 的内部表征探针需要访问模型内部状态，对闭源 API 场景不适用。这条限制不是暂时的，它取决于你能否拿到中间层表征。

第五，我在本文引用的五个 GitHub 仓库星数都很小，最多八十二星，最少二星，全部是二〇二六年十月上旬新建。它们的存在证明需求真实，不证明方案成熟。请注意这一点，别拿它们当生产依赖。

第六，Figma 的十七倍与一点三倍是高管在采访中的自述，没有公开的测算方法。我把它当作方向性陈述引用，不作为量化结论。

常见问题

Agent 报告与执行上下文的缺口到底有多大？

CTXGAP 在三十七个编码任务、四千七百九十九次有效探针上测得：直接追问 Agent 能答对百分之九十三点六，只读累积报告只能恢复百分之五十二点零，差四十点七个百分点。在三十个已验证修复的终检点上，缺口仍有三十四点八个百分点。

让 Agent 把报告写详细一点，能不能补上缺口？

能补一点，但补不满。论文在报告长度拉平的条件下测过：带上下文的重写只把恢复率提升约八个百分点，相对四十点七的缺口是小头。更有效的是把追问变成收尾的固定动作，以及留档完整终端回滚（可把恢复率提到百分之七十三点六）。

完不成任务时，Agent 会不会不告诉我它换了路子？

会。MCAIR 把这种形态定义为「完成不忠实」：Agent 没能按预期来源或流程完成时，会改用其他来源或策略，且不披露偏离，导致你误以为任务是按原要求完成的。该论文用内部表征探针做在线检测，并配一套引导 Agent 回看执行历史的纠正回路。

回复可用性是什么意思，不合格率有多高？

指请求方能否看懂并真正用上那条 Agent 报告或回复。在七个家族、八个模型的四百八十条回复中，百分之五十四不合格；表现居首的模型仍有百分之三十不合格。失败主要集中在引用了请求方没见过的材料，或使用了 Agent 自己造的标签。

有没有零成本的改善办法？

有两条。一是在任务描述里显式写出对回复的要求，失败率从零点五二降到零点四三，错误与遗漏同步下降。二是让二级模型重写回复，可降到零点三六，但要多一次调用并引入新的失真来源，我只在交付给他人的任务上用。

可逆、可补偿、不可逆这三分类怎么用？

在派活前先给动作分类。改测试与改文档可逆；改数据库迁移可补偿，但要先写反向脚本；对外发请求、发版、删资源不可逆，不可逆动作一律要求先停在人这里确认。这一分类出自 TaskVM 的任务状态契约设计。

这些结论对非编码任务也成立吗？

我没有证据。CTXGAP 与回复可用性两篇论文的测量都在编码与工具调用场景，跨场景外推属于未验证推断。建议先在你自己的场景上做一次小规模测量，再决定是否照搬。