grep（全局正则搜索）

grep 的历史与 Unix 本身紧密交织。Ken Thompson 在实现 ed 编辑器正则能力后，将「按模式打印所有匹配行」的逻辑写成独立过滤器，命名呼应 ed 的 g/re/p 子命令。早期动机包括在大体量文本（如《联邦党人文集》）中做模式检索，而 ed 的随机访问编辑模型不适合顺序扫描。

1973 年 前后 grep 进入 Unix 发行版，成为管道文化的核心组件之一——cat access.log | grep "500" 这类组合定义了「小工具组合完成大任务」的范式。后续衍生出 egrep（扩展正则，Alfred Aho 贡献语法）、fgrep（固定串，Aho–Corasick 算法）等变体；现代系统上 egrep/fgrep 多为指向 grep -E/-F 的兼容入口。

21 世纪 10 年代，ripgrep（rg） 以 Rust 重写、默认尊重 .gitignore、多线程并行，成为开发者与 AI 工具链的新默认；pgrep 等命令借 grep 之名做进程名正则匹配，体现其「文本过滤」隐喻在 Unix 命名体系中的深远影响。

grep 的核心模型是 逐行扫描 + 正则匹配：对输入文本的每一行应用模式，命中则输出该行（默认带文件名与行号，取决于参数）。基础用法 grep PATTERN FILE 使用基本正则；-E 启用扩展正则，-F 按固定字符串匹配，-i 忽略大小写，-r 递归目录，-n 显示行号，-l 只列文件名，-c 只计数。

与编辑器内搜索不同，grep 设计为 流式、低内存 过滤器，可处理远超 RAM 的日志文件。正则引擎的实现质量决定性能与语义——GNU grep、BSD grep、ripgrep 在字符编码、Unicode 边界与回溯行为上略有差异，跨平台 Agent 需注意可移植性。

在 Shell 管道中，grep 常与 awk、sed、sort、uniq 组合，构成文本处理「乐高」。对 AI Agent 而言，封装 grep 时要限制搜索路径、排除二进制、控制返回行数，避免把数万行匹配一次性灌入 LLM 上下文。

2024–2026 年，grep 从「人类开发者肌肉记忆」变为 Agent 工具箱的标准原语。Claude Code、Cursor、Devin 等系统均暴露终端或专用 Grep/Search 工具：模型生成查询模式与路径，运行环境执行后仅将命中片段回传，形成 ReAct 循环中的「观察」步骤。

与 语义搜索（向量检索、代码图索引）相比，grep 的优势是 零索引、确定性、符号精确——适合找函数名、错误码、配置键、TODO 注释；劣势是无法理解「登录逻辑在哪」这类意图型问题，且对同义词、注释改写不敏感。业界常见策略是：先用 grep/rg 缩小范围，再 read 文件或做 Embedding 精排。

工程上需防范的风险包括：过于宽泛的模式返回海量行导致 上下文爆炸；搜索 node_modules 等目录造成噪声（ripgrep 默认忽略可缓解）；以及 Agent 在循环中反复 grep 同一模式造成 Token 与延迟浪费。成熟 Agent 框架会对 grep 结果做行数上限、去重与摘要后再注入 Prompt。

除经典 grep 外，AI 与开发者生态中常见的相关工具有：ripgrep（rg）——速度快、默认 .gitignore、适合 monorepo；git grep——仅在 Git 跟踪文件中搜索；ag（The Silver Searcher）——早期更快的递归搜索工具；以及 IDE 内置索引搜索（不经过 Shell，但功能等价）。

在编程语言标准库中，Perl 将 grep 借为列表过滤高阶函数；JavaScript 的 Array.prototype.filter 承担类似角色——这反映了 grep「按条件筛选」隐喻的跨语言传播。

对术语表读者而言，理解 grep 不仅有助于手动运维日志，更是读懂 Agent 工具调用日志（如 Running grep...、tool: bash grep -rn）的前提——它是连接「自然语言任务」与「代码库物理结构」的桥梁工具。