使用 AI Agent 处理真实项目时，经常会遇到一种很明显的低效：

它一直在找代码，却迟迟不开始改。

常见表现包括：

• 已经找到相关文件，又继续搜索整个项目；
• 同一个函数、关键词反复搜索好几次；
• 读取一个文件以后，又顺着调用链打开十几个文件；
• 一个很小的Bug，花大量时间“理解项目”；
• 明明已经知道问题可能在哪里，却还在不断补充上下文；
• 最后真正修改代码只用了几分钟，前面搜索却花了很久。

这类问题不是 Agent 不会使用搜索工具。

恰恰相反，很多时候是：

它太容易认为“再多找一点信息会更安全”。

但搜索如果没有边界，就会从帮助决策变成拖慢决策。

一、为什么Agent天然容易“再确认一下”？

面对一个Bug，Agent最开始并不知道完整调用关系。

所以它可能先搜索：

• 报错关键词；
• 函数名；
• 接口调用；
• 测试；
• 配置。

这些步骤都很合理。

问题是，当它已经找到一条足够可信的路径以后，仍然可能继续想：

会不会还有别的调用方？

于是再搜一次。

找到更多文件以后，又会想：

这里是不是还有隐藏依赖？

结果就变成：

搜索 → 阅读 → 发现新线索 → 再搜索 → 再阅读。

如果没有停止条件，这个循环可以持续很久。

二、真正的问题不是搜索多，而是不知道什么时候已经“够了”

搜索的目标应该是：

为下一步行动提供足够证据。

例如要修一个按钮点击后报错的问题，已经确认：

• 报错发生在哪个组件；
• 对应函数在哪里；
• 可以稳定复现；
• 相关测试也找到了。

这时候其实已经具备了做一个最小修改的条件。

继续把整个仓库相关关键词全部搜完，并不一定明显提高正确率。

反而可能把：

必要信息

淹没在：

可能相关的信息

里面。

三、可以给搜索设置一个明确边界

例如一个任务开始时，先规定：

第一轮只搜索：

1. 报错位置；
2. 直接调用方；
3. 对应测试；
4. 一个上游和一个下游依赖。

如果这些信息已经能够解释问题，就先停止扩展搜索。

只有出现：

• 根因解释不通；
• 修改影响到公共模块；
• 测试结果与假设冲突；
• 找不到真实调用路径；

再扩大搜索范围。

这样搜索就从：

无限探索

变成：

按证据逐层扩展。

四、“工具预算”可以减少无效循环

Agent有搜索、文件读取、终端、测试等很多工具。

问题是工具越多，不代表每个任务都要大量使用。

可以给任务设置一个简单预算：

在第一次修改之前，优先控制在有限次数的搜索和文件读取内。如果已经找到明确根因和最小修改位置，就进入验证，不要为了“更完整”继续扫描整个项目。

这个预算不是死限制。

它真正的作用是提醒Agent：

搜索本身不是成果。

如果每一次工具调用都不能显著改变下一步决策，就应该考虑停止。

五、什么时候说明已经达到“行动阈值”？

可以用一个很简单的判断。

如果Agent已经能够回答：

问题在哪里？

为什么会发生？

准备改哪里？

修改以后怎么验证？

这四个问题，就已经基本达到行动阈值。

例如：

问题出在 user.service 的状态判断；当前判断遗漏了 disabled 状态；只需要修改该分支并补对应测试；完成后运行相关单测验证。

这种情况下，再去读十几个无关文件，价值通常已经很低。

应该先：

小范围修改 → 快速验证。

六、行动以后再决定要不要继续搜索

搜索和修改并不是：

先把所有信息找完，再一次性开始执行。

更稳的方式是：

搜索到足够证据 → 做最小修改 → 看结果 → 决定是否扩大搜索。

如果测试通过、原Bug消失，说明前面的搜索已经足够。

如果结果不符合预期，再继续往下一层查。

这样整个任务会形成：

搜索 → 行动 → 验证 → 必要时再搜索

而不是：

搜索 → 搜索 → 搜索 → 搜索。

七、重复搜索同一个东西通常是一个警告信号

如果Agent连续多次：

• 搜同一个函数名；
• 打开同一份文件；
• 反复查看同一条调用链；

往往说明它没有把已经获得的信息压缩成明确状态。

这时候可以让它输出：

已确认：
已经知道什么。

仍未知：
真正还缺什么。

下一步：
哪个动作最可能验证当前假设。

如果“仍未知”已经没有关键项，就不应该继续搜索。

八、长任务更需要防止搜索范围无限扩大

大型项目尤其容易出现这种情况：

搜索一个Service，发现公共工具；

打开公共工具，又发现配置；

查看配置，又发现另一个模块。

最后Agent已经离原始Bug越来越远。

所以搜索时最好始终保留一个问题：

当前正在读取的这个文件，会不会改变我对原始问题的判断？

如果不会，就应该谨慎继续。

否则“理解项目”很容易变成没有终点的任务。

九、可以直接这样约束Agent

以后遇到这种情况，可以要求：

先围绕当前问题建立最小搜索范围，只查报错位置、直接调用链、相关测试和必要配置。每轮搜索后总结“已知、未知、下一步”。如果已经能明确根因、预计修改位置和验证方式，就停止继续扩大搜索，先做最小修改并验证。只有验证失败或出现新的关键证据时，再扩大搜索范围。

这样能够明显减少Agent：

为了确认而不断确认。

最后

AI Agent总在“搜索代码、读取文件、再搜索”里打转，本质上不是搜索能力太弱。

而是：

工作流缺少一个明确的“什么时候信息已经够了”的判断。

真正高效的Agent执行不应该追求：

把整个项目都看懂再开始。

而应该做到：

找到足够证据 → 达到行动阈值 → 做最小修改 → 快速验证 → 必要时再扩大搜索。

Agent真正的效率，也不只是：

一分钟能调用多少次工具。

更重要的是：

它能不能知道什么时候应该停止找，开始做。

---

持续更新 Codex、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。