当日志或 trace 文件增长到数百 GiB，普通文本编辑器往往已经无法打开。即使使用 grep、rg 等高性能搜索工具，每次分析也可能需要重新扫描大量内容。更麻烦的是，AI Agent 很难通过稳定、可分页的接口读取指定行、限制搜索范围并导出原始片段。

trace-search-mcp 正是为这一场景设计的。

trace-search-mcp 是一个使用 Rust 编写的超大文本文件查询服务，面向 800 GiB 以上、只读、按行组织的日志或 trace 文件。

它不会把整个文件加载或映射到内存，而是在第一次打开文件时顺序扫描一次，为文件建立体积很小的持久化行号索引。索引完成后，MCP 客户端便可以：

项目仅通过 MCP Streamable HTTP 提供能力，因此特别适合接入支持 MCP 的 AI 客户端、自动化分析系统或远程日志分析工具。

传统文本搜索工具擅长快速扫描内容，却通常不维护“行号到文件偏移”的持久化关系。

例如，要读取一个超大文件的第 10 亿行，仅仅知道行号并不能直接得到它在文件中的字节位置。程序通常需要从文件开头重新统计换行符，或者提前维护额外的索引。

trace-search-mcp 默认每隔约 8 MiB，在下一个行边界记录一条：

查询指定行时，程序先在内存中二分查找距离目标最近的检查点，然后只扫描后续一小段数据。

按照项目 README 给出的性能模型，一个 800 GiB 文件大约产生 102,400 条记录，每条记录 20 字节，索引主体约为 2 MiB。它没有为每一行建立索引，因此能在索引体积与随机定位速度之间取得平衡。

需要注意的是，这不是全文倒排索引。任意正则仍然需要扫描指定范围内的原始内容，但服务能够先定位搜索范围，再利用多个独立文件句柄并行扫描，而不是为了定位起始行而从文件开头处理。

同为 Rust 编写的 ripgrep 是开源社区中最优秀的文本搜索工具之一。它支持递归搜索目录、自动处理 .gitignore、Unicode、文件类型过滤和可选 PCRE2，非常适合源代码仓库以及大量普通文件的即时搜索。

但 trace-search-mcp 与 rg 解决的并不是同一个问题。

如果只是搜索代码仓库中的函数名，rg 更简单、更成熟；如果面对的是一个数百 GiB 的离线 trace，并且需要反复跳转到指定行、分页搜索和交给 AI 分析，trace-search-mcp 更贴合这一工作流。

它不是为了取代 rg，而是补足 rg 并不打算提供的“超大单文件随机行访问和服务化查询”能力。

ugrep 提供了非常丰富的搜索能力，包括交互式界面、布尔搜索、模糊搜索、压缩包搜索以及多种文档格式支持。

它更像一个功能全面的现代 grep。trace-search-mcp 的功能范围更窄，但重点放在持久化行定位、超大文件的受控读取以及 MCP 服务集成上。

The Silver Searcher（ag） 主要面向源代码搜索，通过忽略规则、多线程和内存映射提升代码仓库中的搜索效率。

它适合开发者在终端和编辑器中搜索代码，但没有为数百 GiB 单文件提供可恢复的行索引、分页 MCP 查询或安全导出机制。

Loki、Elasticsearch 等系统适合持续采集、多用户查询和分布式日志管理，但通常需要部署采集器、存储服务及索引集群，还可能要求先导入或重新组织数据。

trace-search-mcp 更适合已经存在于本地磁盘上的大型日志快照：

如果需求是长期收集多个服务的实时日志，应优先考虑 Loki 或 Elasticsearch；如果需求是分析单个巨型离线 trace，trace-search-mcp 的部署成本更低。

项目对区分大小写的字面量搜索使用预编译 SIMD memmem，其他模式使用 Rust regex 引擎，不存在灾难性回溯。

搜索接口要求调用方明确提供：

服务返回的 next_line 可以用于继续下一页搜索。这种设计尤其适合 AI Agent，因为它能防止一次请求返回过多内容，也可以让分析过程逐段推进。

对于大范围内容，项目没有要求客户端接收庞大的 HTTP 响应，而是提供 export_lines。导出时只定位首尾字节偏移，再通过固定大小缓冲流式复制；目标文件在临时文件写入并同步成功后才发布，避免留下不完整结果。

首先构建 release 版本并设置 Bearer Token：

服务的 MCP 地址为：

MCP 客户端配置示例：

客户端应使用 Streamable HTTP，而不是 stdio。基本操作流程为：

该项目尤其适合：

它不适合多文件代码仓库搜索、持续变化的日志文件、复杂全文检索排名或分布式实时日志采集。

rg、ugrep 和 ag 追求的是“把文件内容快速找出来”；Loki、Elasticsearch 解决的是“把日志持续采集并集中管理”；trace-search-mcp 关注的则是另一个更具体的问题：

如何让程序和 AI 在不加载整个文件、不建设重型日志平台的前提下，稳定地访问和分析一个数百 GiB 的文本文件。

通过稀疏持久化行索引、限定范围搜索、流式原子导出和 MCP Streamable HTTP 接口，它为超大离线 trace 提供了一层轻量、可控且适合自动化调用的查询能力。

GitHub：e39K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6m8L8X3c8J5L8$3W2V1f1X3g2$3k6i4u0K6k6i4u0Q4x3X3c8f1k6i4y4@1i4K6u0r3N6s2u0S2j5$3g2Q4y4h3k6K6k6h3q4J5j5$3R3`.

(行号, 字节偏移)

cargo build --release

$env:TRACE_SEARCH_BEARER_TOKEN = "replace-with-a-long-random-token"

target\release\trace-search-mcp.exe `
  --bind 127.0.0.1:8080 `
  --index-dir D:\trace-index `
  --export-root D:\trace-export