聊天模型答不出，Coding Agent却能查出来：能力悬置与工具闭环

同一个模型，直接在聊天框里提问可能漏掉答案；换到能读文件、执行命令和查看结果的 Coding Agent 里，问题却很快有了答案。很多人看到这种差异，会直接得出“Coding Agent 的模型更强”或“聊天模型不行”的结论。

这个结论太快了。

用户提供的演讲整理中，讲者举了一个很小的例子：找出名字以 aw 结尾的 Pokémon。直接让模型从记忆中回答，容易漏项；让 Coding Agent 下载完整列表，再用一行搜索筛选，任务就变成了数据处理和核对。这个案例不能证明 Coding Agent 在所有任务上都更强，但能说明一个重要现象：模型潜在能力可能超过当前 Prompt、工具和界面能够释放的部分。

本文把这个现象拆成可复现的任务设置，帮助你判断一次失败究竟是模型推理问题，还是工具环境没有给出合适的行动路径。

1. 先区分两种任务

表面上，下面两句话都像是在“找答案”：

请列出所有名字以 aw 结尾的 Pokémon。
请读取完整列表，筛选名字以 aw 结尾的项目，并给出来源和筛选命令。

第一句话主要要求模型从已有知识或当前上下文中回忆。第二句话明确允许模型获取数据、执行筛选和给出证据。它们不是同一项测试。

可以把任务设置拆成三档：

如果只比较 A 和 C，测到的就不只是模型能力，还包括数据访问、工具接口、执行环境、提示词结构和验收方法。

2. Capability Overhang 说的是什么

演讲中使用了 Capability Overhang 这个词，本文将它译成“能力悬置”：模型具备的潜在能力，超过了当前交互方式能够调用出来的部分。

这里的“能力”不是一个可以直接测量的总分，而是一个条件性判断。一个模型可能会写筛选代码，却在没有数据时无法列出结果；可能能解释调用链，却在没有项目文件时只能给出通用教程；可能能发现异常，却没有执行测试的工具来验证。

所以，看到“模型答不出”时，至少要追问三件事：

它有没有拿到完成任务所需的数据？
它有没有能把问题转成动作的工具？
它有没有机会观察动作结果并修正？

缺少其中任意一项，最后的失败都可能被误判为推理能力不足。

3. 把 Pokémon 案例改成一个小实验

不需要追求复杂基准，先做一个小而可复现的对照。

实验目标

从同一份完整列表中找出满足某个字符串条件的项目，并让结果可以被别人复查。

设置 A：封闭回答

请直接列出名字以 aw 结尾的 Pokémon。
不要搜索外部资料，也不要执行命令。
如果不确定，请明确说明不确定的地方。

记录：模型给出的结果、它是否声明不确定、是否出现重复或漏项。不要只记录最终答案，也保存完整提示词和执行日期。

设置 B：允许检索和筛选

请先找到一份可访问的完整列表，不要凭记忆补全。
然后筛选名称以 aw 结尾的项目。
输出：数据来源、实际筛选条件、结果列表和仍需人工核对的地方。
如果无法访问数据，停止并说明缺少什么。

记录：它是否找到数据、筛选条件是否正确、结果是否能够回到来源、访问失败时是否诚实停止。

设置 C：独立复核

把设置 B 的结果交给第二个独立步骤，只提供原始列表和筛选规则：

请独立检查下面的原始列表。
只按“名称以 aw 结尾”的规则筛选，不参考上一轮的结论。
输出匹配项、未匹配项数量和无法判断的格式问题。

这里不需要预先声称谁更好。只要比较三种设置中，错误发生在“找不到资料”“执行规则错误”“结果没有复核”还是“模型直接回忆漏项”。

注意，这个实验不能推出某个模型的普遍准确率。数据源、列表版本、字符串大小写、工具权限和提示词都会影响结果。它的价值只是把一个模糊的“答不出”拆成可观察的失败位置。

4. 为什么“解释 auth module”也会失败

演讲整理中另一个例子是：“解释一下 auth module 是怎么工作的。”这句话比 Pokémon 案例更接近日常开发，但仍然缺少大量条件。

用户变量

读者是前端、后端、测试还是产品？
读者熟不熟 TypeScript 和当前框架？
读者是要接手维护、做安全评审，还是了解业务流程？

项目变量

认证入口在哪个包？
权限判断是否分散在中间件和数据库查询里？
仓库当前分支是否包含最新设计？
Git 历史、Issue 或设计文档是否有关键背景？

交付变量

需要一段概览，还是完整调用链？
需要源码路径、时序图、风险列表，还是上手步骤？
哪些结论必须由测试或配置文件证明？

如果只给模型一句“解释 auth module”，它只能猜测用户真正想要哪种解释。加更多历史对话可以补充一部分背景，但不能替代让 Agent 打开仓库、搜索入口、读取调用方和检查测试。

更好的任务写法是：

目标：帮助刚接手项目的后端开发者理解认证请求路径。
输入：当前仓库中与 auth module 直接相关的源代码、配置和测试。
范围：不修改文件；先找入口，再追踪直接调用方。
输出：
1. 登录和刷新流程；
2. token 或 session 的存储位置；
3. 权限检查发生在哪里；
4. 失败路径和现有测试；
5. 仍需人工确认的历史或业务规则。
验收：每个结论带文件路径或测试名称，不确定内容单独标记。

这个提示词仍然需要模型理解代码，但它同时给了模型一个寻找证据的路线。

5. 工具闭环至少要有七个环节

一个工具是否真的有用，不要只看它能不能被调用。要看它有没有组成闭环。

不一定要为七个环节分别开发工具。一个命令行工具可能同时完成取数和执行，一个测试命令可能同时提供观察和验证。重点是确认每个环节在任务中有对应的实际路径。

6. 什么时候改 Prompt，什么时候补工具

可以用下面的决策表做第一轮判断：

这不是绝对规则。换模型可能有帮助，增加记忆也可能有帮助，但它们都应建立在失败位置已经被观察到的基础上。

7. 一个小型 A/B 测试怎么做

如果你想判断工具是否真的帮助了任务，至少控制以下变量：

固定模型和模式。
固定输入文件或数据版本。
固定任务提示词，只增加工具权限或操作步骤。
固定验收标准。
固定最大执行时间或工具轮数。
记录完整日志，不只看最终回答。

可以设计两组：

A 组：模型只能读取给定上下文，不允许外部搜索和执行。
B 组：模型可以读取同一份上下文，并使用一个明确的搜索或验证工具。

如果 B 组表现更好，仍然不能直接说“工具让模型变聪明了”。更准确的结论应该是：在这份输入、这个模型、这套权限和这个验收条件下，工具提供了额外的信息或验证路径。

如果 B 组没有改善，也不要立刻证明工具没用。可能是工具返回格式不清、权限不足、任务没有真实检索需求，或者模型不知道什么时候调用工具。测试的目标是定位条件，不是制造一句宣传结论。

8. 设计工具时别忘了工具会过时

演讲中的另一个观察是，模型能力增长后，过去帮助模型的工具可能变成约束。早期模型需要 Todo、提醒或一次性的提问控件来保持轨迹；当模型能够连续追问、生成更完整的报告或协调多个任务时，原工具的交互方式就可能不再合适。

这不是说旧工具一定应该删除，而是提醒我们要重新检查工具背后的假设：

工具是否假设模型每次只能完成一步？
工具是否强迫模型沿着固定路线走？
工具是否返回了足够的状态和结果？
工具是否支持中途改变计划？
工具是否允许人理解并修正模型的选择？

Anthropic 的 Effective context engineering for AI agents 和 Equipping agents for the real world with Agent Skills 都可以作为设计背景，但具体工具是否适合，必须在当前模型和任务上复测。

9. 结论与限制

聊天模型答不出、Coding Agent 能查出来，往往说明两次交互提供的行动空间不同，而不是已经证明两个模型之间存在普遍的能力差距。把数据获取、执行、观察和验证接进任务以后，模型可能释放出原本没有机会使用的能力；但如果目标不清、工具返回混乱或验收缺失，增加工具也可能只是增加复杂度。

真正可复用的方法，是把一次失败拆成条件：模型看到了什么，能做什么，做完能观察什么，谁来判断结果。先用小型对照实验定位缺口，再决定改 Prompt、补工具、调整接口或换模型。单次案例只能说明特定条件下的现象，不能代替系统测评。

资料与说明

• 演讲材料：用户提供的《Seeing like an Agent》视频信息、时间戳整理和转录。Pokémon 与 auth module 是文中讨论的案例，不作为模型性能基准。
• Anthropic：Effective context engineering for AI agents：用于支撑上下文选择和任务条件设计的背景。
• Anthropic：Equipping agents for the real world with Agent Skills：用于支撑渐进披露和工具组织的背景。