技术 · 熟练
给它成熟工具，还要它交证据
工具由专家造，结论要能对得上
让 agent 做专业判断时，最常见的坏做法是「把原始材料直接丢给模型，让它看」—— 让它盯着一堆二进制、一份没解析过的源码、一张没标注的图，然后给你一个听起来很合理的结论。这一页讲的是另一条路：把已经成熟的工具包成 agent 能调的接口，并且要求它交证据 —— 每条结论都带得出位置（文件偏移 / 行号 / 符号名）与置信度，拿不到的地方明确写「未知」，而不是用一句话把空白填满。关键动作只有一个：从「要一个答案」改成「要一个能对得上的答案」。
方法 · 一图看懂
1
先分清哪些活是「算」出来的、哪些是「看」出来的 — 解析结构 / 追踪调用链 / 比对字节，这些本该由工具算；解释与归纳才是模型的活
2
把工具包一层，别重造 — 需要的是适配层（参数与输出标准化），不是自己再写一个同类工具
3
输出必须带位置 — 每条结论附可回查的位置（文件偏移 / 行号 / 符号 / 版本），让结论可被第二次核对
4
明确标注「未知项」 — 拿不到就写拿不到；⛔ 不许用「可能是」「通常如此」把没依据的部分填满
5
场景简单时，规则写进一份说明也能跑 — 轻量场合不必先搭框架，把规则与判据写成一份文件，让它照着做
原理 · 为什么有效
为什么这一条的重点在「证据」而不是「工具」：模型的强项是归纳与表达，弱项是采样与精确引用。让它对一个结构化的东西下结论，它给出的往往是「这类情况通常怎样」—— 读起来通顺，但你对不上具体是哪一处。把工具接进来解决的是「算法对不对」，要求交证据解决的是「这条结论能不能落到具体位置」。两件事必须一起做：只有工具、没有证据要求，你拿到的是一段更专业的猜测；只有证据要求、没有工具，它会去编一个位置。这也是为什么同一个做法在不同领域都出现 —— 凡是要给出「这一处在哪」的判断，都需要同一套结构。
适用场景
适用：要让 agent 处理需要精确引用的材料 —— 代码库理解 · 结构解析 · 数据比对 · 需要回溯到具体位置的检查。
⛔ 不适用：纯粹的观点归纳、文案写作、开放式头脑风暴 —— 那些没有「位置」这个概念，强行要求引用只会让它编。
⚠️ 前提：这类材料确实存在成熟工具。若没有，先解决工具问题，而不是让它硬猜。
自测 · 5 问
我说得出这个任务里，哪一步本该由工具算、哪一步才是模型的活吗？
上一次 agent 给我的结论里，有几个我能回查到具体位置？
它有没有把「拿不到」写出来过？还是每次都给我一段完整的答案？
我要求过输出里包含置信度或「未知项」吗？
如果我换一个模型重跑同一个问题，两次的结论会不会只是「说法不同」而没有可核的差异？
怎么上手 · 验证步骤
第一次别接新工具。先在你已经有的一个流程上加一条要求：让每次结论后面必须跟一个可回查的位置，并且把「拿不到位置」变成一个允许的输出。跑一周看看 —— 你会立刻发现两件事：哪些结论其实一直没有依据（以前被通顺的措辞盖住了），以及哪些步骤其实早该由工具做而不是让模型判断。这两条观察，比先选工具更重要。
自检动作：随便挑 agent 最近给你的一条结论，问它「这条对应原文的哪一处」。能当场给出位置 ⇒ 这套流程有依据；开始解释「一般来说是这样」⇒ 那一条是猜的。把猜的那几条单独记下来，看它们是否集中在某类任务上 —— 那就是你该先接工具的地方。