从智能体会话日志核验执行证据

同时派出 10 个子代理，收回来的回答都很自信，真正费劲的工作才刚开始：哪些结论有证据，哪些只是写得像完成了？作者提出，可以先读已有的运行记录，找出结论与证据脱节的位置，不必一上来就增加埋点。

他为此做了一个叫 agentrace 的工具，在一次会话的 152 次运行中标记出 36 次值得复查的记录。这篇最有用的地方，是给出了具体的检查线索，也明确承认：这些线索只能帮助分配注意力，不能证明答案正确。

已有的会话记录，能查出什么

作者以 Claude Code 为例：会话已经以 .jsonl 文件保存在磁盘上，其中包括任务委派及返回结果。按他的描述，分析这些记录不需要额外接入 SDK 或包装器，也能回头检查已经完成的运行。

这些记录至少提供三类信息：你要求做什么、代理返回什么、花了多长时间。把三者放在一起，就能发现不少单看最终回答容易漏掉的问题。

最便宜的检查是找空结果、极短结果和异常结束。作者分析的会话文件有 34MB，其中 152 次运行里，有 7 次出现了这类错误，包括执行途中触及会话限制。此前没人发现，因为一份很短的报告，看起来也可能像一份已经完成的报告。

另一类是措辞礼貌的放弃。例如「找不到任何开放岗位」，读起来像结论，却可能只是代理没有完成搜索。作者建议用 grep 搜索 I was unable to、I could not determine、no results were found，再逐条确认这些表述对应什么过程。

代理返回了文字，不等于任务已经完成。

耗时异常也可以作为入口，但原文没有给出统一阈值。长时间运行究竟是任务复杂、反复尝试，还是卡住了，仍要结合上下文判断。

最危险的错误，发生在结论被继续传递时

作者遇到的一个问题，是代理说某家公司「似乎在招聘」，传到后续决策时却变成了「正在招聘」。

原来的保留措辞没有错，错误发生在下游把不确定性删掉了。appears to be、likely、probably、I believe、could not verify 都承载着证据强度。汇总结果时，只保留结论、丢掉限定条件，就会把推测加工成事实。

另一个坑是把「没拿到数据」当成「对象不存在」。原文中的代理因为 API 返回空列表，就断言某家公司没有招聘；但这个 API 对不存在的账号也会返回 HTTP 200 和空列表。单靠状态码和空数组，无法区分这些情况。

因此，看到「没有任何 X」时，要回查它依据的究竟是什么：HTTP 200 配空响应、有效资源上的 404，还是一个需要 JavaScript 才能渲染内容的页面。它们可能都让代理看不到结果，背后的含义却不同。

链接也是如此。列出 20 个 URL，并不能证明逐个查过。如果记录里有大量链接，却没有抓取、检查、确认的迹象，就该进一步核实。

这里有两层检查：先确认代理有没有访问来源，再确认来源是否支持结论。作者的方法主要帮助定位前一层的疑点，后一层仍然需要判断。

提示词也要接受检查，但不能拿长度当标准

作者发现，那次会话里有 12 次被标记的运行，问题出在调用方：提示词没说清楚输出应该是什么样。

没有完成标准，就很难验收。只要求「查一下」，代理交回一段自由发挥的文字，调用方也缺少明确依据判断它是否合格。

但完成标准不能靠提示词长度来推断。作者早期的规则会标记所有少于 200 个字符的提示词，结果误伤了下面这句只有 113 个字符的任务：

run the suite and report every failing test as node ids with its assertion message

它虽然短，却说清了要运行测试，并按 node ids 和断言信息报告每个失败项，完全可以验收。作者随后收紧规则，关注「短且没说明怎样才算完成」，而不是单纯关注「短」。

他称，调整减少了噪声，没有丢失已有的真实发现。不过，这仍是作者针对已有记录的反馈，原文没有提供跨项目的评测数据。

这个细节影响工具能否长期使用。检查器如果频繁把正常任务报成问题，使用者最终会忽略整份报告。更合适的输出是「这里值得读一下」，而不是直接宣布「这里错了」。

我的判断

我认同把 transcript 当作验收材料来读。对于已经跑完、当时没有专门设计观测方案的任务，它提供了一个成本较低的复查入口。尤其是多代理汇总，限定措辞丢失、空结果被误读，都很容易藏在最终报告后面。

但「无需埋点」有明确前提：运行环境已经保存了足够完整、可读取的记录。原文以 Claude Code 为例，没有证明所有代理框架都具备同样条件。如果工具调用细节根本没有留下，事后阅读也补不回证据。

它与结构化日志、指标、追踪解决的问题也不完全相同。文本检查适合筛查放弃措辞、结论强度和任务约定；要定位服务延迟、重试次数或外部依赖故障，仍可能需要专门记录运行数据。

36 次被标记，不等于确认了 36 次模型错误。

原文没有给出误报率、漏报率，也没有与人工审查或其他工具做对照。这是一个有具体案例支撑的经验方法，可以借用，不能直接当成准确率承诺。作者自己也强调：格式规范、语气肯定、满足输出约定的回答，照样可能是错的。

能拿来做什么

• 给日常 AI 编程任务补上可验收的输出要求。例如检查测试失败时，要求返回失败用例标识、断言信息和实际执行结果，让后续复查有明确对象。
• 汇总多个代理的调查结果时，保留「可能」「未验证」「无法确认」及其原因，不要为了让报告简洁，把所有条目改写成确定结论。
• 在 Node 脚本或前端数据排查中，遇到空数组、HTTP 200、404 或页面无内容时，先检查接口约定和渲染条件，再接受「数据不存在」的判断。
• 从一次已有会话开始，手动筛查空结果、放弃措辞、未经验证的链接和异常耗时。确认哪些信号确实有用后，再把它们做成保守的自动检查规则。