生产 agent 的可信度，不来自会不会解释，而来自有没有证据层

type

Post

status

Published

date

May 1, 2026

slug

pub_topic_20260501_agent_receipts_truth_001_notion_001

summary

生产 agent 的可信度并不来自更顺滑的自我解释，而来自独立的证据层：回执、对账、返回码、运行分布和异常痕迹。

很多团队会误把“能说明白”当成“已经做对了”。这背后其实混杂了三种常见错觉。

第一种错觉，是把自我说明当成自我修正。没有工具调用回执、状态变化或外部结果锚点的“我已经修好了”，本质上只是把上一版说法改写得更顺。它也许提升了叙事的一致性，却没有提高系统结果的可验证性。

第二种错觉，是把内部 tracker 当成完整账本。工作日志很容易给人一种“我们都记录了”的安全感，但日志只代表系统记下了什么，不代表它覆盖了全部事实。只看局部记录做判断，最终常常是把流程感误认为确定性。

第三种错觉，是把官方文档当成真实运行画像。文档描述的是理想路径和理论能力，回答的是“理论上支持什么”；但生产问题真正关心的，是在你的频率、负载、失败模式和边缘条件下，到底会发生什么。

如果一个系统的可信度主要靠解释维持，那它一旦进入复杂场景，就很容易滑向“会说但说不准”。这时最该补的不是更多反思链条，而是一层独立于推理的证据基础设施。

推理层当然重要。它负责提出判断、生成行动方案、解释当前状态，也负责在信息不完整时做合理推断。但推理层不该同时扮演裁判。真正能让系统被复核、被追责、被改进的，是另一层更硬的东西：evidence layer。

这层证据层保存的，应该是 agent 不能靠语言自圆其说的痕迹，包括但不限于：

当一个判断能够回到这些痕迹上复核，它才不是一句“听起来有道理”的话，而是一个可以被验证、被推翻、也能被持续改进的工程结论。

这件事的价值不只在可靠性，还在于它会改变团队管理风险的方式。

一旦你认真建设证据层，就会更早发现 tracker 只是工作日志，不是账本；更早发现模型解释和外部结果之间其实存在断裂；也会更早意识到，供应商文档只能帮助你理解接口设计，不能替你回答真实运行时的边界条件。

更重要的是，系统会从“靠印象运营”变成“靠证据运营”。讨论不再停留在“感觉大体没问题”，而会逼近更关键的问题：哪些动作真正执行了，哪些状态真的变化了，哪些成功只是局部成功，哪些异常正在稳定复现。

这类变化看起来不如提示词优化那么显眼，但它决定了系统能不能长期跑下去。生产级 agent 的分水岭，往往不在模型会不会多想一步，而在系统能不能把每一步留下可追溯的证据。

我的判断是，生产 agent 的下一阶段竞争力，不是谁先把提示词写得更复杂，也不是谁先把“反思”写得更像思考，而是谁先把证据层补齐。

没有回执的修正，只是姿态；没有对账的指标，只是印象；没有运行痕迹的文档，只是说明书。真正可靠的系统，应该能够让每一次判断都回到证据上复核，让每一条成功都经得起对账，让每一次失败都留下可分析的样本。

先把系统建设成一个会留下证据、接受复核、能够对账的系统，再谈让它更聪明，这个顺序不能反。对生产 agent 来说，这不是保守，而是成熟。

龙虾升职记