被多源实测反复确认的反直觉现象 过去一年,企业内部 Coding Agent 部署里反复观察到一个反直觉的工程现象——Agent 在被给予更"高级"的代码探索工具(基于 tree-sitter 的 AST 索引、基于 LSP 的符号查询、基于图遍历的依赖分析)时,仍然倾向于回到更"朴素"的工具(grep、glob、读文件)。这条现象不是个例——多个独立工程团队在不同时间、不同代码库、不同 Agen
被多源实测反复确认的反直觉现象
过去一年,企业内部 Coding Agent 部署里反复观察到一个反直觉的工程现象——Agent 在被给予更"高级"的代码探索工具(基于 tree-sitter 的 AST 索引、基于 LSP 的符号查询、基于图遍历的依赖分析)时,仍然倾向于回到更"朴素"的工具(grep、glob、读文件)。这条现象不是个例——多个独立工程团队在不同时间、不同代码库、不同 Agent 产品上都观察到了同一种模式,且都得出了高度一致的工程结论:Coding Agent 在当前一代模型能力下,默认行为偏好朴素工具,而不是更结构化的语义工具。这条现象对企业 Coding Agent 工具链的装配方式有直接的工程含义。
三条独立工程实践在同一时段给出了相互印证的观察。第一条实践是 2026 年 2 月公开的 CodeRLM 项目,作者明确记录了"Claude 在探索任务中对使用 CodeRLM 表现出显著抗拒,通常要明确告诉它用 CodeRLM 它才会用"——这意味着即便是明确为 Claude Code 设计的 tree-sitter 索引服务,Claude Code 也不会默认使用。第二条实践是 2026 年 2 月公开的 Vexp 上下文引擎,作者明确指出"AI coding agents waste most of their context window reading code they don't need"——通过 grep 把数千行无关代码塞进上下文,然后导致 token 浪费、上下文溢出、Agent 失去焦点;Vexp 的工程价值是构建语义图来替代 grep 的低效遍历,但作者必须显式设计接入 12 家不同 Agent 的工具调用链路——侧面印证"Agent 默认行为偏好 grep"的工程现实。第三条实践是 2025 年 11 月公开的 VT Code 项目,作者明确选择 tree-sitter + ast-grep 组合作为基础——但也承认 Agent 默认行为仍是"在循环里 grep",需要明确引导才会使用 AST 工具。这三条独立实践共同指向同一条工程新基线——Coding Agent 工具装配必须为"Agent 偏好朴素工具"这一现象设计,而不能假设"高级工具一旦暴露就会被采用"。
朴素工具胜出的工程证据
CodeRLM 项目在工程上做了对照实验——一边是基于 tree-sitter 的代码索引服务,提供 init / structure / search / impl / callers / grep 六类工具;另一边是 Claude Code 默认的 glob + grep + read 工具集。同样的任务("探索代码库,识别可以清理结构的机会")两边跑一次,得出的具体观察有两个关键工程含义。
第一个观察是 Agent 实际行为路径。索引版工作流下,Agent 在 3 分钟内识别出重复命名的代码、孤儿代码、跨模块命名约定不一致、词汇重叠这类语义级问题;朴素工作流下,Agent 在 8 分钟内识别出文件根目录的杂物、过时引用、时间戳冲突这类字符串级问题。两类问题在工程价值密度上有差异——前者影响代码可维护性,后者只是文件清洁度。但关键的工程观察是:即便朴素工作流在语义级问题上表现明显更弱,Agent 仍然倾向于走朴素工作流。作者明确记录:"Claude continues to demonstrate significant resistance to using CodeRLM in exploration tasks. Typically to use you will need to explicitly direct claude to use it." 这意味着,索引工具在工程上是有效的,但 Agent 的默认行为偏好是绕过它。
第二个观察是 Engineering Effort 的工程含义。如果 Harness 想让 Agent 默认使用高级工具,需要在提示词、Hook 机制、工具集暴露顺序上做大量工作——这条工程负担远高于"接受 Agent 默认走朴素路径,然后在朴素路径上加一层缓冲"。Vexp 项目就是这条工程选择的典型样本——作者没有尝试"让 Agent 默认使用 Vexp",而是构建了一个完整的本地守护进程 + VS Code 扩展 + MCP server,通过这套基础设施把 Agent 工具调用"重定向"到 Vexp 的索引;但即便如此,作者仍然需要明确告诉 Vexp"我支持 12 家 Agent 的工具调用链路"——意思是 Vexp 必须为每一家 Agent 单独适配,而不能依赖 Agent 自己"发现"Vexp 是更优的工具。
Agent 偏好朴素工具的三个工程根因
这条偏好在工程上有三个清晰可识别的根因,理解这些根因有助于设计针对性的工具装配方案。
第一个根因是训练数据分布。主流 Coding Agent 的基础模型在训练时见过的"标准代码任务"样本里,绝大多数是"按 prompt 写新代码"或"按 bug 描述修代码",这些任务的最佳实践路径不是基于 AST 的工具调用——训练时模型见过的是工程师在 grep 里搜函数名、读文件、改文件。基于 AST 的语义级分析在训练样本里出现频率极低,模型没有形成对应的行为模式。这意味着,模型"会"用朴素工具是因为训练数据教过,"不会"用 AST 工具是因为训练数据几乎没教过。这条根因对应工程现实——任何想改变 Agent 默认行为的工具设计,必须考虑到模型训练数据的分布偏差。
第二个根因是认知一致性。朴素工具的输入输出都是文本——grep 返回文件路径 + 行内容,read 返回文件全文,Agent 看到的输出和它"想要理解代码"这件事在表征层面直接对应。但 tree-sitter 索引返回的是符号节点 ID + 父子关系 + 引用链,这些结构化输出需要 Agent 先在脑子里"翻译"成代码再进行推理。多一次"翻译"意味着多一次认知开销,Agent 在时间压力和上下文压力下倾向于走最短路径。这条根因对应工程现实——任何要求 Agent 做额外认知动作的工具,都会和朴素工具在"自然使用"上竞争不过。
第三个根因是工具链成熟度。朴素工具的实现是"文件名 + 行号 + 字符串",任何代码编辑环境都能立即支持,几乎没有安装门槛。但 tree-sitter 索引服务需要额外的 server 进程、需要初始化开销、需要针对不同语言的解析器配置、需要和 Agent 的 hook 系统对接。这条额外的工程负担,在 Agent 还在探索阶段时是真实障碍——Agent 会优先走没有任何额外负担的朴素路径。这条根因对应工程现实——任何高级工具的设计都必须把"安装和使用门槛"压到极低,否则 Agent 默认会避开。
工具装配的工程新基线
把上述证据和根因合并,可以在企业 Coding Agent 工具装配上画出一条工程新基线。这条基线由五条构成。
第一条,朴素工具必须保留且默认暴露。Grep、glob、读文件、写文件、Edit 这一组朴素工具是 Coding Agent 的"肌肉记忆",任何时候都必须对 Agent 可见,默认情况下 Agent 应该能用。即便有了 tree-sitter 索引,朴素工具仍然要暴露,因为它在"扫描文件系统、找过期引用、清理垃圾"这类任务上无可替代,且认知开销最低。这条规则在所有 Coding Agent 部署里都成立。
第二条,树状工具必须按需暴露且自带触发信号。Tree-sitter 索引、LSP 符号查询、AST 编辑器这一组树状工具是 Coding Agent 的"专业装备",在"重复命名检测、跨模块引用分析、语义级重构"这类任务上明显优于朴素工具。但它不应该默认暴露给所有任务,因为它的认知开销更高、配置更复杂;它应该按需暴露——当 Agent 检测到任务涉及"重复命名检测、跨模块引用分析、语义级重构"这类语义级问题时,系统主动提示它使用树状工具,或者 Agent 主动请求时,系统响应启用。
第三条,工具切换必须有任务画像触发。简单的"扫一下文件、改几行"任务只暴露朴素工具;中等难度的"理解代码结构、找出 bug"任务同时暴露朴素工具和树状工具,且默认推荐后者;复杂的"跨模块重构、生成代码骨架"任务必须显式要求使用树状工具,且由人类工程师确认任务画像。这条规则对应 CodeRLM 作者观察到的"Agent 默认避开高级工具"现象——任务画像触发是引导 Agent 走出朴素路径的最有效机制。
第四条,工具集必须可被插件化扩展。Vexp、CodeRLM 这类第三方工具必须能被工程团队平滑接入,而不需要修改 Agent 本身;VS Code 扩展、Harness Hook、Plugin 接口必须支持第三方工具的注册和调用。这条规则确保高级工具的接入门槛低到工程团队愿意使用。
第五条,工具选择必须有可观测的指标。具体而言,工具被调用的频率、工具被调用的任务类型分布、Agent 在哪些任务上选择了朴素工具而不是树状工具、这些选择的 token 成本是多少、这些选择的任务完成质量是多少——这些数据是判断工具装配是否真的在企业里被有效使用的唯一可靠依据。没有可观测指标,工具装配就只是凭感觉调。
从 Coding Agent 工具装配推到所有企业 Agent
把视野拉宽到企业 Agent 工具链,以上五条规则具有普遍意义。任何 Agent 系统,在"工具装配"环节,都需要面对同一组问题——Agent 偏好用什么工具、Agent 偏好什么类型的工具、工具的复杂度如何分布、工具的暴露时机如何决定、工具的接入门槛有多高。这组问题的回答,在 Coding Agent 场景里收敛到"朴素默认 + 树状按需 + 任务画像触发",在更广义的 Agent 工具链场景里也是适用的工程基线。
具体而言,任何 Agent 系统都应当把工具集按"复杂度梯度"分层。最简单的工具是"按字符串匹配、按文件名匹配、按文件内容全文读"——暴露给所有任务、所有 Agent、所有场景。中间的复杂工具是"按结构匹配、按语义分析、按规则推理"——按需暴露、需要 Agent 主动请求或任务画像匹配。最复杂的工具是"按多步推理、按外部知识、按跨系统协调"——只暴露给特定任务、需要人工审核。
企业 Agent 治理负责人现在应当把 Coding Agent 工具装配的工程新基线作为整个企业 Agent 工具链设计的样板工程。具体来说,"朴素默认、按需暴露、任务画像触发、插件化接入、可观测指标"这五条规则应当通用化,覆盖企业内部所有 Agent 的所有工具装配场景。每一条规则对应一个独立的工程组件——可以是默认工具集、可以是按需触发引擎、可以是任务画像系统、可以是插件框架、可以是可观测性平台——实现形式各异但原则一致。
企业 Agent 治理负责人现在必须回答的三个问题
面对上述基线,企业 Agent 治理负责人现在至少要直接回答三个问题。第一个问题:你企业内部 Agent 系统当前默认暴露的工具集是什么?是只暴露朴素工具、是只暴露高级工具、是按场景混合?如果是混合,混合的触发信号是 Agent 主动请求、还是任务画像自动判断、还是人类工程师手动指定?
第二个问题:你的 Agent 系统是否在工具调用层有"任务画像"概念?任务画像是指系统对当前任务的难度、类型、上下文敏感度的判断结果;有任务画像,工具集调度才有依据;没有任务画像,工具集就是一刀切。
第三个问题:你的 Agent 系统是否建立了"工具被使用"的观测?具体而言,工具被调用的频率、工具被调用的任务类型分布、Agent 在哪些任务上选择了朴素工具而不是高级工具、这些选择的 token 成本是多少、这些选择的任务完成质量是多少——这些数据是判断工具装配是否真的在企业里被有效使用的唯一可靠依据。
结语
Coding Agent 的工具偏好在过去一年被显著推前,从"只能用朴素工具"演化到"朴素工具和高级工具并存"。每推前一步,工具装配的工程基线就必须同步推前一步。把"用最强工具等于最优解"作为主要思路的部署,在多源实测里被反复证伪。把"朴素默认、按需暴露、任务画像触发、插件化接入、可观测指标"作为基线,重新设计 Coding Agent 的工具装配方案,是当下能落地的工程基线。
任何企业 Coding Agent 项目,只要涉及 Agent 调用代码探索工具,工程基线就必须做到这五条——朴素默认、按需暴露、任务画像触发、插件化接入、可观测指标——否则,今天不是某次 Agent 走错工具路径的主角,也会是下一次 Agent 走错工具路径的主角。
