有人说pi本身会默认使用grep但是这个其实在庞大的codebase或者复杂场景下很低效且消耗更多token，你能不能全面解释下

这个说法有一部分道理，但把“默认用 grep”“大仓库低效”“更费 token”直接连起来，容易误判。 举个例子：在一个大型电商仓库里，找 PaymentService 的定义，文本搜索可能一次就定位了；但问“为什么取消订单后优惠券没退回”，代码未必出现“退回优惠券”这些字，可能分散在事件消费者、补偿任务和状态机里。此时反复猜关键词，才容易又慢又费 token。 关键不是仓库大就不能 grep，而是问题需要的检索能力，是否超出了文本匹配。 一、Pi “默认用 grep”到底指什么 Pi 作者在 2025 年 11 月的设计文章里，展示的是四个核心工具：read、bash、edit、write，并指导模型通过 bash 做 ls、grep、find 等操作。 当前官方使用文档则列出了 read、bash、edit、write、grep、find、ls 等内置工具，也允许通过扩展增加能力。 所以需要区分： 通过 bash 执行文本搜索。 调用名叫 grep 的专用工具。 模型在某次任务里选择了 grep 命令。 这不是同一回事。旧文章也不能单独证明当前每个版本的默认工具配置，更不能证明 Pi 每次都固定调用传统 grep。 可以确认的是：Pi 的设计偏向小核心和可扩展工具，而不是默认替你包办一套完整的代码理解系统。 二、搜索速度和 token 消耗，是两个问题 搜索工具在本机扫描了几百万行代码，不意味着模型读了几百万行。 假设扫描后只返回三个文件名，模型收到的主要就是这三个文件名；反过来，一个小仓库搜索“user”，把大量无关命中送进上下文，也可能很费 token。 因此要分开看： 本地检索成本：扫描范围、磁盘读取、是否使用索引。 模型上下文成本：实际返回多少内容、相关性如何。 交互成本：需要多少轮“搜索—阅读—再搜索”。 正确性成本：是否漏掉关键实现，导致改错和返工。 ripgrep 等工具可以改善文本扫描效率，但不能自动解决“关键词猜错了”和“搜索结果不相关”。 三、为什么复杂场景容易更费 token 最典型的是以下几种情况。 不知道业务概念对应什么名字。 用户说“退款”，实际实现叫 reversal；模型依次搜 refund、payment、cancel，读了很多无关代码才找到正确入口。这里浪费的是检索试错，不是 grep 执行本身。 同名结果太多。 搜索 execute、handle、status，会混入不同模块、测试、生成代码。文本匹配不知道哪个 execute 属于目标类型，模型只能继续读上下文消歧。 需要追踪跨文件关系。 “这个接口最终写了哪张表”，可能经过路由、依赖注入、服务接口、实现类和数据库封装。文本搜索能辅助追踪，但不天然提供可靠的符号引用或调用链。 搜索结果被截断。 输出上限可以避免一次塞入过多内容，但关键命中也可能不在返回部分。模型若把“没看到”误认为“不存在”，既可能答错，也可能重复搜索。 噪声留在后续上下文里。 无关结果不只影响当前这一轮，还可能继续随历史进入后续请求，直到被移除或压缩。缓存可以降低部分重复输入费用，但不等于这些信息不占上下文，也不保证模型不受干扰。 因此，“更费 token”往往来自低质量检索引发的多轮探索和返工，而不是文本搜索天然昂贵。 四、是不是换成向量检索就好了 也不是。不同工具适合不同问题。 找准确名字、错误字符串、配置项：文本搜索通常很合适。 找某个方法的定义、引用、类型关系：语言服务器或符号索引通常更精准。不过动态分发、反射、运行时注入仍可能难以完整解析。 按语法结构找代码，例如某类调用或特定写法：AST 搜索更合适。 只知道业务含义、不知道具体名字：语义检索有机会更快找到候选入口，但“语义相似”不等于“实际参与这条执行链”。 跨模块理解：仓库结构摘要、符号关系和依赖信息可以减少盲目探索。 定位运行时问题：日志、调用追踪和测试结果可能比继续搜代码更直接。 向量检索还有索引构建、更新、切块和召回遗漏的问题；找到几个相似片段，也不能证明已经覆盖全部相关实现。尤其是“重命名全部引用”“有没有遗漏权限检查”这类任务，不能只依赖相似度检索。 更合理的是组合使用，而不是把 grep 换成向量数据库就宣布解决了。 五、同样用文本搜索，策略也能差很多 还是“取消订单后优惠券没退回”这个例子。 低效方式是全仓搜索 cancel，读取大量命中，再全仓搜索 coupon，再猜 restore。 更合理的方式是先确定订单模块和取消入口，再沿取消事件找消费者，检查优惠券处理与相关测试，只读取需要的函数和上下文。 这里即使底层仍然主要靠文本搜索，进入模型的噪声也可能少很多。 常见的有效做法包括：先限定目录和文件类型，只需要候选文件时先返回文件名，确认入口后再展开正文；排除无关生成产物，但不能机械排除实际参与执行的代码。 所以真正重要的是“检索范围、返回粒度、探索路径”，不只是工具名称。 六、对 Pi 应该怎么评价 Pi 的极简设计，优点是工具面小、行为容易检查，也方便按需求扩展；代价是，面对复杂仓库时，更依赖模型自己的探索能力，以及使用者补充的项目知识和检索工具。 但“它工具少，所以总 token 一定更少”和“它用 grep，所以大仓库一定更费 token”，都缺少依据。 要证明后者，至少要在同一仓库、同一任务、同一模型和相近正确率下，比较完整任务的输入输出 token、缓存用量、耗时和返工，而不是只看一次搜索返回了多少行。 结论：这条批评真正成立的部分是，“仅依赖关键词搜索、缺少结构信息和良好检索策略，在复杂代码任务中容易增加探索成本”。把原因简化成“grep 很低效”，反而没有抓住问题。 来源： Pi 当前使用文档： https://pi.dev/docs/latest/usage 作者的原始设计说明，发表于 2025 年 11 月，适合了解设计动机，不应当作当前版本全部实现的证明： https://mariozechner.at/posts/2025-11-30-pi-coding-agent/