让 Agent 解释自己，它给你的是合理化，不是原因。这事研究翻来覆去验证过，这周 TRAJDEBUG 那篇又在同一个点上补刀。可信的解释只有一种：把账本摊开——调了哪些工具、拿到什么数据，一条条对得上。但账本是工程师的语言，业务用户看不懂，于是你需要一层翻译。而这层翻译本身，也可能变成新的合理化。麻烦就在这。
模型自述的毛病：编得比真事还圆
我先说个直观经验。让 agent 复盘一次失败任务，它能给你讲一个完整故事：先分析用户意图，再权衡三个方案，最后选了 X。讲得比真事还圆。但拉出 trace 一看，它第三条消息就调错了工具，后面那些"推理"全是在给这个错误找补。
TRAJDEBUG 的切入点就是这个：长任务里错误是级联的，真正致命的那一步往往很早，后面全是被带偏的连锁反应。所以它的做法不是听模型总结失败原因，而是去定位"最早出错的那一步"。
我们自己做 agent 追踪日志的时候也有同样体会。模型自述的原因字段，跟实际调用序列对不上是常态。不是模型恶意撒谎，是它生成解释的时候，压根没有"必须忠实于内部过程"这个约束。
账本比自述可信，那就把工具链摊开
解释界面该展示什么？Beyond Top-K 给了个好方向：把黑盒向量检索（embedding + top-k）换成可解释的 agentic 操作。每一步做了什么、查了什么、按什么条件筛，全部显式化。它做的是金融文档场景，那里审计要求你说清"为什么取到这几条"，黑盒 top-k 答不上来。
搬到解释界面上，思路就是展示调用链，不展示内心独白。四样东西够用：
- 调了哪个工具
- 传了什么参数
- 拿到什么数据
- 基于这些做了什么
这比 agent 用自然语言说"我仔细分析了你的需求"有用得多。前者能验证，后者只能信。
但人根本没在看
解释界面的真正敌人不是模型的诚实度，是人的注意力。这周 HN 上有个扎眼的数据：40k 次游戏运行里，人类审批 agent 命令时漏掉了三分之一的威胁。审批者不坏，就是没耐心逐条读。
所以工具调用链如果只是一坨 JSON 日志，工程师会看，业务用户不会。设计上的含义是：每一行都得能回答"这步正常吗"，而不是"这步在干什么"。异常高亮、正常折叠、只在关键节点给判断提示——这是另一个方向的活，但同样是在做解释。
翻译层绕不开，但得说清它是转述
反面观点是对的：工具链对非技术用户不可读。你不能让财务去看 tool_call: get_invoice(status="overdue")。需要一层业务语言的翻译："系统查了逾期发票，按金额排序，取了前几条。"这是人在看的可读解释。
但这里有个边界要守住：翻译层是"对调用链的转述"，不是"模型意图的说明"。UI 上得标清楚。否则翻译层一旦开始补理由——"因为用户可能更关心大额发票"——它又变回合理化了，只是换了层语言包装。
按我现在看，翻译层怎么做到既诚实又可读，还没标准答案，大多靠人肉标注。也许 6 个月后有更好的做法。方向应该不会变：解释锚定在事实链上，不锚定在模型的自我叙事上。