AI Agent 时代重新发明文件搜索：Cursor 建正则索引、Everything 技能开源，fsearch 站上风口

AI Agent 时代重新发明文件搜索Cursor 建正则索引、Everything 技能开源fsearch 站上风口【免费下载链接】fsearchWhole-disk file search for macOS: fuzzy names, typo tolerance, indexed content grep. ~1 ms over 8M files.项目地址: https://gitcode.com/gh_mirrors/fsea/fsearch2026 年的软件生态出现了一个耐人寻味的信号当所有人都在讨论大模型的推理能力时顶级的 AI 工具链却开始回头补「基础设施课」。Cursor 官方博客放出为 Agent 构建文本索引的正则搜索方案社区里出现把 Everything 封装成 AI Agent 技能的「文件检索速度翻倍」教程Windows 11 也把系统搜索重构成可被命令调用的形态。这些看似零散的事件指向同一个结论——文件检索正在从「给人用的工具」变成「给 Agent 用的基础设施」而本地毫秒级搜索则是这条基础设施上最关键的一块拼图。本文以 macOS 全盘搜索工具 fsearchRust 实现约 1ms 检索 800 万文件为切入点结合其源码拆解「秒搜」能力的工程原理以及它如何以守护进程、Socket API、Rust crate 三种形态被 Agent 工具链直接复用最后给出对本地搜索生态的判断。Agent 侧的事实正则索引与技能开源两个方向性信号先看两个社区情报里的关键事件。其一是 Cursor 博客的「快速正则搜索为 Agent 工具构建文本索引」。作为 AI 编程 IDE 的代表Cursor 的 Agent 需要频繁在代码库中定位符号、阅读文件、理解上下文。它给出的方案不是简单的rg封装而是为 Agent 构建专门的文本索引——因为 Agent 的搜索模式与人类截然不同人类搜索是低频、高意图的Agent 搜索是高频、机械式的它会在一次任务里执行几十上百次检索每次都要求确定性的毫秒级返回否则整个任务的时间预算就被 IO 拖垮。其二是社区涌现的「开源 Everything 搜索技能AI Agent 文件检索速度简单翻倍」。Everything 在 Windows 上的地位无需赘述——预建索引 毫秒全盘检索——如今它的能力正被封装成 Agent 技能Skill本质上是在告诉生态Agent 的 tool 调用里需要一对「本地快速检索」的双手而这双手不应该让每个 Agent 各自造轮子而应该由成熟的开源搜索工具直接供给。把这两个信号叠在一起看趋势就很清楚Agent 工具链对本地文件检索提出了硬性要求——极低延迟、确定性结果、可编程接口——而满足这些要求的工程存量恰好是 fsearch 这类「Everything 式」工具深耕多年的领域。fsearch 正是为 macOS 填补 Everything 空白的存在它的 README 第一行就写着Whole-disk file search for macOS按文件名检索约 1 毫秒容忍拼写错误还能索引文件内容做 grep。需求侧Agent 工作流为什么离不开本地快速检索Agent 的工作流与传统 IDE 补全有本质区别。一次典型任务包含定位入口文件、搜索符号定义、扫描相关目录、读取上下文文件、对比版本差异。这些步骤里「找到文件」是最频繁且最被低估的一环——它决定了 Agent 后续所有读取、编辑、执行的起点。本地快速检索对 Agent 的价值体现在三个维度第一是 token 经济。Agent 的每一步工具调用都要经过大模型一次慢搜索意味着一次阻塞等待而毫秒级搜索意味着 Agent 可以连续发起多次检索而无需等待把「猜路径」变成「遍历候选」用工具调用的确定性替代模型推理的不确定性。第二是上下文质量。一个能容忍拼写错误、支持模糊匹配、能按 mtime/size/类型过滤的搜索引擎可以让 Agent 在检索时就把「最可能的文件」排到前面。fsearch 的查询语言正好提供了这套表达力exact精确匹配、^prefix前缀、suffix$后缀、!exclude排除配合ext:type:kind:in:size:mtime:re:path:grep:regex:sym:limit:等过滤器Agent 可以用一行查询表达复杂的检索意图。第三是实时性。文件系统是活的Agent 自己写文件、改文件、建目录搜索结果必须反映当下的状态。fsearch 通过 FSEvents 保持索引实时新文件约 0.1 秒内可见并在 src/fsevents.rs 中实现了可重放的目录级事件流——这正是「索引永远新鲜」的保障。fsearch 的机会秒搜能力如何被 Agent 工具链复用fsearch 最有意思的地方在于它的设计从一开始就面向「复用」一个常驻守护进程 三种调用方式。三种调用方式CLI、Socket、Rust crate最轻量的是 CLI。构建后安装到~/.local/bin/fsearch即用即查cargo build --release ./target/release/fsearch install # - ~/.local/bin/fsearch fsearch fsearch main # find files by name fsearch ext:rs grep:apply_dir # search inside files关键设计是守护进程CLI 只是瘦客户端真正干活的是一个常驻的fsearch serve守护进程所有调用者共享同一个索引。这从根上解决了 Agent 工具链的并发问题——CLI、编辑器插件、脚本、Agent全部连同一个索引不会出现「每个进程各建一份索引」的重复开销。守护进程的协议是 Unix Socket 上的 JSON Linessrc/server.rs{q: fsearch main, limit: 20} {op: grep, pattern: apply_dir, in: ~/Developer}fsearch stdio还提供标准输入输出上的 JSON Lines 通道——这对被 subprocess 拉起的 Agent 工具是天然契合的Agent 工具以stdio模式启动 fsearch逐行发送查询 JSON逐行接收结果无需任何 SDK 依赖。返回里甚至带took_us字段Agent 可以据此判断每次检索的成本。更深入的是作为 Rust crate 嵌入README.md 中的 API 示例let engine fsearch::Engine::start(fsearch::Options { dir: fsearch::default_dir(home), home: home.clone(), skip: None })?; let hits engine.search(fsearch::Query::parse(fsearch main, home)?)?;Engine是完整的进程内搜索引擎启动后台建索引、从 FSEvents 持续同步、随时应答查询。想给 Agent 平台写原生集成的开发者可以直接 link crate把搜索能力编译进自己的二进制。多进程共享索引Agent 生态的关键设计src/engine.rs 里有一个对 Agent 工具链至关重要的机制owner与follower。多个进程守护进程、嵌入式 app、CLI同时运行时通过flock竞争索引文件的写权限第一个进程成为 owner 拥有索引其他进程作为 follower 只读跟随、定期检查 owner 的落盘更新并在 owner 退出后接管// A follower takes over the index files once their owner is gone. fn try_upgrade(s: ArcShared) - bool这意味着无论 Agent 平台以什么形态接入守护进程、嵌入库、子进程都能共享同一份索引不会因为「我的 Agent 自己建了一份索引」而相互打架。索引文件本身是 mmap 的单一扁平 blobsrc/index.rs任何进程都可以直接映射读取无需反序列化。性能底牌从源码看秒搜是怎么炼成的fsearch 的性能不是营销数字而是一系列工程决策的自然结果。README 在 M4 Max、770 万文件的实测数据是场景性能全盘按名找文件p50 1.3 ms文件内容搜索p50 9 ms新增/重命名/删除文件可见~0.1 s首次全盘爬取~20 s一次性守护进程内存30-135 MB第一层是枚举层的零 stat 设计src/walk.rs用getattrlistbulk(2)一次系统调用批量返回数百条目录项名称、类型、大小、mtime、标志全带上没有 per-file stat目录在 rayon 线程池上扇出子目录用openat()相对父目录 fd 打开路径从不重建。注释里写着实测openclose 约 19μs/目录getattrlistbulk 约 14μs8 线程后内核侧不再扩容。第二层是索引布局的 range 化src/index.rs条目按目录块 DFS 顺序排放每个目录的子树是连续区间dir_start..dir_end于是in:限域搜索是一个区间下界而不是逐条过滤750 万条目共享约 200 万去重名字名字做 interning查询先打分去重名字约 200 万次再按「携带该名字的条目」二次落盘避免对每条目逐一打分。第三层是查询层的向量化扫描src/query.rs每个 token 编译成 64 位字符掩码fits判断是分支无关的位运算全盘名字扫描保持向量化模糊评分用 fzf-v1 风格的 leftmost-ending 匹配加边界/camel/连续命中奖励5 字母以上单词容忍一次拼写错误mian.rs能找到main.rstypo 匹配经由one_edit_prefix单编辑前缀判定且 typo 命中会被TYPO_COST扣分、排在同质量干净匹配之后。第四层是内容索引的 trigram 架构src/content.rs文本文件建 trigram 倒排索引segment 是不可变 mmap 文件posting list 用 delta varint稠密时切换 bitset查询变成 trigram 的 AND/OR 求交匹配行永远从磁盘新鲜读取索引只负责筛候选所以结果永不过期——这对 Agent 的「读文件内容」场景至关重要因为 Agent 刚写入的文件必须立刻可搜。此外还内置符号索引sym:apply_dir能直接定位函数定义DEFINES 关键词表regex 查询会被编译成 trigram 计划来裁剪候选集避免全量扫描。这些数字拿到 Agent 工具链里的含义是一次检索的成本从「几百毫秒到秒级」压到「1-10 毫秒」Agent 可以放心地把搜索当原子操作反复调用。与同类工具 fff 的实测对比Chromium 509k 文件见 demo/vs_fff.py 与对比视频 demo/fsearch-vs-fff.mp4更能说明量级按名搜索 1.1ms vs 13.8ms内容搜索 5.6ms vs 53ms拼错仍命中第一名的比例 98% vs 88%启动到就绪 50ms vs 2.5s内存 50MB全盘vs 358MB单文件夹。生态判断本地搜索正从「给人用」转向「人机共用」把前面的信号拼起来可以提炼出本地搜索正在发生的结构性迁移从 GUI 交互到协议交互。Everything 时代的搜索是给人敲键盘的交互单位是「窗口 输入框」Agent 时代的搜索是给程序调用的交互单位是「请求-响应」。fsearch 的 socket JSON Lines 与 stdio 协议本质上把搜索降维成了像 DNS、HTTP 一样的可编程原语。从单进程工具到共享基础设施。传统搜索工具每个进程各自为政fsearch 的 owner/follower 机制证明一个索引可以被守护进程、嵌入式 app、CLI、Agent 工具共同持有「一次建索引、处处复用」在工程上是可行的。Cloudflare 博客把「AI Search」称为智能体的搜索原语本地这一端同样需要一个原语级的实现。从结果展示到上下文供给。给人用的搜索以「列出结果」为终点给 Agent 用的搜索以「提供上下文」为起点——结果路径、匹配行、时间戳、评分都要结构化地交给下游程序。fsearch 的 JSON 返回里自带kind、size、mtime、score内容搜索返回line与text这正是 Agent 需要的上下文形态。fsearch 的时机恰好Cursor 们在为 Agent 造索引证明需求Everything 们在被封装成技能证明供给而 fsearch 已经把「全盘秒搜 内容索引 拼写容忍 可编程接口 多进程共享」在 macOS 上完整落地。当本地搜索进入「人机共用」时代像 fsearch 这样把性能、实时性与接口设计同时做对的开源工具会从开发者玩具变成 Agent 工具链的默认组件——这或许就是「重新发明文件搜索」的真正含义。【免费下载链接】fsearchWhole-disk file search for macOS: fuzzy names, typo tolerance, indexed content grep. ~1 ms over 8M files.项目地址: https://gitcode.com/gh_mirrors/fsea/fsearch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考