实践
关于与 LLM agent 协作，有一种常见的说法：有些人"就是会去追问模型"，而另一些人则接受第一个答案。这种表述把审问当作一种性情。事实并非如此。审问是一种评审方法：一组定义明确的问题，在输出被允许算作结果之前对其提出。这一区分很重要，因为方法可以被写下来、被分配、被抽样、被审计、被改进。性情则不能。
方法很直接。评审者不是读完生成的答案后判断它听起来对不对，而是向 agent 追问答案背后的证据、它考虑过的其他方案、它所述置信度的依据，以及什么会证伪它。这些不是修辞性问题。每一个都有正确的答案形态，而一个无法给出这种形态的 agent，暴露的是其 pipeline 中的缺口，而非其行文中的缺口。
这与一次优秀的代码评审所做的如出一辙。一个 pull request 被合并，不是因为 diff 看起来合理，而是因为作者能解释为什么是这处改动而非另一处、它依赖什么、以及它将如何被测试。agent 的输出值得同样的对待，而近期关于团队审问模型输出而非信任首次响应的报道，描述的正是这一纪律在扩散，而非某种性格类型的出现。
审问究竟在问什么
一次有用的审问包含四个问题，它们可跨任务类别通用：
- 证据：这个答案依托于哪些来源、工具结果或数据？
- 备选方案：还考虑过哪些其他分支，为什么被否决？
- 置信度依据：具体是什么让这个答案更确定或更不确定——来源的覆盖度、工具之间的一致性、请求中的歧义？
- 证伪：什么观察会让这个答案出错，而该观察是否可得？
第四个问题是区分评审与安慰的那一个。一个无法被任何可得观察证伪的答案不是主张，而是意图陈述。评审者应据此对待它。
只有当 agent 能呈现中间产物时，这一方法才奏效。如果检索、工具使用和分支选择都发生在黑箱内部，只输出最终文本，审问就无从下口。评审者只能退而要求模型自我内省，而这产生的是看似合理的叙述，而非证据。因此，工程要求位于评审的上游：运行必须被埋点，使这些产物存在、可供展示。
为使其可行必须捕获什么
三类记录使审问成为可能。若这一方法要不止于表演，它们没有一类是可选的。
检索溯源。 对每一段检索到的文本：文档标识符、文档版本或哈希、span 偏移量、将其召回的查询，以及它到达时的排名。版本很重要，因为文档可能在运行与评审之间发生变化，而将答案与当前文本比对的评审者，可能是在与错误的文本比对。span 偏移量很重要，因为引用整篇文档不是证据；引用一个段落才是。
工具调用记录。 对每一次工具调用：工具名称、确切的输入、确切的输出、时间戳，以及错误状态（如有）。一个成功标志不是记录。评审者需要看到工具被要求了什么、返回了什么，因为 agent 失败中有很大一部分是输入构造失败——工具被正确调用，却被要求了错误的东西。
被否决的分支及其原因。 当 agent 探索一个方案并将其丢弃时，被丢弃的方案及丢弃它的原因应被保留。这正是让评审者看到搜索空间而非仅存路径的东西。没有它，评审者无法分辨 agent 是考虑过那个显而易见的备选方案并基于证据否决了它，还是压根没考虑过。这两种情形在最终输出中看起来一模一样，其含义却截然不同。
一个具体机制：在输出旁一并发出结构化运行记录，上述每一类各占一节，并让评审界面将该记录渲染在答案旁边。评审者的工作就变成同时阅读两份产物，而非对一份进行猜测。
将其转化为评审关卡
当这一方法成为关卡而非习惯时，它就被制度化了。需要三个组成部分。
第一，为每个任务类别定义一小组审问问题。检索密集型的问答任务需要溯源和版本问题。规划任务需要备选方案和证伪问题。工具密集型任务需要输入构造和错误处理问题。保持问题集小——每类三到五个——这样回答它们就是常规步骤，而非一个项目。
第二，在运行被标记为完成之前要求给出答案。这是一个状态转换，而非建议。一个无法回答其类别问题
体的东西。
第三，以固定比例抽样运行进行人工审问。自动化关卡捕获结构性失败；人类捕获语义性失败。固定的抽样比例——高后果类别中每次运行都抽，较低类别中抽一部分——使人工评审负载可预测，覆盖情况诚实。
这一关卡最有价值的产出不是单个判定。而是反复出现的无法回答的问题。当同一个问题在许多次运行中都失败时，修复属于检索或工具链，而非 prompt 补丁。一个让 agent 叙述一个它并不拥有的答案的 prompt 补丁，比失败更糟，因为它移除了信号。
局限与权衡
自我报告的置信度不是证据。当 agent 说它有信心时，那是一段生成的 token 序列，而非一次测量。该方法依赖于外部产物——检索到的 span、工具输出、分支记录——而在这些不存在的地方，审问就退化为要求模型对自身进行刻画。这种刻画应被记录为一项主张，而非当作一项发现。
审问还会增加延迟和成本。生成结构化运行记录、保留被否决的分支、回答关卡问题，都会消耗算力和存储，人工抽样则消耗评审者时间。这就是为什么该方法应首先用于高后果路径：逆转代价高昂的决策、触达客户的输出，或触及生产系统的操作。较低后果的路径可以以较轻的埋点运行，直到实践确立、工具链足够便宜可以扩展。
诚实的总结是：审问是一种评审纪律，有真实的成本，也有真实的回报。它改变了被记录的内容，因为关卡没有溯源和工具记录就无法运作。它改变了被评审的内容，因为评审者阅读的是运行记录，而非仅最终文本。它也改变了被交付的内容，因为一个无法回答其类别问题的运行不会通过。采纳它的团队并非在性情上更怀疑。他们只是把怀疑移进了 pipeline，在那里它可以被测量和维护。
这对评审流程意味着什么
应当退休的框架是：有些工程师会审问模型，另一些不会。应当采纳的框架是：审问是一个关卡，有定义明确的问题、定义明确的产物和定义明确的升级。这个关卡就是评估实践与个人意见之间的区别。它也是这一实践中唯一能在人员变动、模型变动或任务类别变动后存续的版本——也就是说，唯一值得构建的版本。
封面照片：panumas nikhomkhai / Pexels。