我给 Windows Codex 换了这套工具，它速度终于飞起来了

如果你在 Windows 上用 Codex，经常看到它反复读文件、处理编码、修改 PowerShell 命令，这些时间不一定全花在理解代码上。

路径转义、GBK 和 UTF-8、输出截断、分页读取，都可能让一次简单操作多绕几圈。

先说清楚：Windows 上的 Codex 慢，不一定都是终端造成的。模型推理等级、项目规模、杀毒软件、沙箱、网络和其他 MCP，都可能影响速度。

但是，如果任务时间线里反复出现 Shell 命令重试，工具调用层很可能就是你眼前的一个瓶颈。

一、我遇到的麻烦，你可能也见过

我前阵子在 Windows 上让 Codex 改一段老项目代码。

任务并不复杂：读几个文件，搜一个函数，改两处逻辑。真正动代码之前，它却在文件读取和命令处理上来回折腾。

GBK 和 UTF-8 轮流踩。路径里出现空格，再踩一次。输出长一点，又要确认结果有没有被截断。

这些问题 PowerShell 当然都能解决，只是模型临时拼命令时，需要同时顾着语法、转义、编码和输出格式。

我当时最直接的感受是：代码还没看明白，工具细节已经吃掉不少时间。

二、FastCtx 到底做了什么？

FastCtx 是一个用 Rust 编写的本地 MCP 工具运行时。

项目地址：https://github.com/yc-duan/fastctx

截至 2026 年 7 月 24 日，FastCtx 最新版本是 v0.2.1，一共提供 9 个 MCP 工具。

1. 默认开放的四个文件工具

• read：按行读取文本，也能处理图片、PDF 和十六进制视图
• grep：搜索文件内容，支持上下文、过滤和分页
• glob：按路径模式查找文件
• replace：执行机械式批量替换，支持 dry-run 预览

2. 开启 Bash 后增加的五个工具

• run：在前台执行 Bash 命令
• run_background：启动后台任务
• job_output：读取后台任务的新输出
• job_list：查看运行中或已经结束的任务
• job_kill：停止后台任务及其进程树

模型只要提交路径、行号、正则、编码等参数，FastCtx 负责目录遍历、编码检测、分页和输出边界。

我对 FastCtx 的评价是：它没有给模型换脑子，只是帮模型少干一点终端脏活。

三、Windows 上怎么装？

1. 先检查两个环境

如果使用 npm 安装，需要 Node.js 18 或更高版本。

如果要开启 run 和后台任务等 Bash 工具，还要安装 Git for Windows，并确认电脑上可以找到 Git Bash。

Git Bash 通常随 Git for Windows 一起安装，不需要寻找一个固定叫“安装 Git Bash”的勾选项。

2. 全局安装 FastCtx

在 PowerShell 或 CMD 中执行：

npm install --global fastctx
如果遇到镜像源尚未同步导致的 404，可以临时改用 npm 官方源：

npm install --global fastctx --registry=https://registry.npmjs.org/

3. 打开控制终端

fastctx
第一次启动会进入全屏 TUI，界面支持中文。

几个主要选项：

1. Output Tier：默认用 Standard 即可；更高档位会返回更多内容，也会占用更多上下文
2. Bash terminal：需要执行 Bash 命令时再开启
3. Search CPU：默认自动并行，上限为系统可用并行度与 16 中的较小值；也可以手动限制
4. 后台任务设置：没有明确需求时先保留默认值

确认 Apply 前，先看看它准备修改哪些配置。

Apply 会把稳定二进制复制到 ~/.fastctx/bin/，并配置 Codex 或 ChatGPT App。它还会管理 ~/.codex/config.toml、~/.codex/AGENTS.md 里的 FastCtx 条目，以及部分输出限制设置。

这也是为什么 npm 缓存被清理以后，已经 Apply 的运行时仍然可以继续工作。

4. 新开一个 Codex 会话

Codex 会在会话启动时连接 MCP。Apply 完成后，新开一个会话再检查：

fastctx status
重点是确认关键项目均为 [PASS]，并且没有 [FAIL]。看到其中一个 [PASS]，不代表所有配置都已经通过。

四、它能不能让你快一半？

这句话我不敢替所有人保证。

FastCtx 官方说明的是“减少工具调用步骤、提高上下文效率”，没有公布一套能够证明 Windows 用户普遍提速 50% 的独立基准。

项目、文件编码、任务类型、模型版本和推理等级不同，最后的时间差可能很大。

真想知道它对你有没有用，最靠谱的办法是自己做一次对照：

1. 选一个以前容易卡住的小任务
2. 固定同一个项目、模型和推理等级
3. 原生工具与 FastCtx 各跑几次
4. 记录总耗时、工具调用次数和重试次数

如果原来的主要问题就是 GBK 文件、长输出和 PowerShell 命令重试，FastCtx 更有机会带来明显改善。

如果时间本来就花在长时间推理、联网查询或大型构建上，它不会凭空把这些步骤变快。

五、几个必须提前知道的坑

1. Codex 会更愿意调用，但不保证每次都调用

Apply 会向 Codex 的 AGENTS.md 写入带标记的使用指引，让模型优先考虑 FastCtx。

实际选哪个工具仍取决于任务和当前会话。装完以后，最好从任务时间线里确认它是否真的调用了 mcp__fastctx。

2. 风险不只来自 Bash

FastCtx 的 Bash 工具默认关闭，但 replace 默认开放，而且具有文件写入能力。

官方文档明确说明：FastCtx MCP 运行在宿主文件系统沙箱之外，并继承启动它的进程权限。

如果你希望所有写入和命令执行都先经过确认，可以在 Codex 配置现有的 [mcp_servers.fastctx] 区块中加入：
default_tools_approval_mode = "writes"

需要审核每一次 FastCtx 调用时，可以改成：
default_tools_approval_mode = "prompt"
重要仓库里，审批模式比“我小心一点”更可靠。

3. “本地运行”不等于“永远不联网”

FastCtx 的 MCP 运行时不会把仓库路径和文件内容上传出去，也没有工具调用遥测。

不过，TUI 默认会访问 npm 和 GitHub 检查新版本；你主动运行的 Bash 命令也可能联网。

所以更准确的说法是：仓库操作在本机执行，文件内容不会被 FastCtx 上传。

4. 乱码时再手动指定编码

read 和 grep 支持自动检测，也允许手动指定：

{"encoding": "gbk"}
编码不明确时，FastCtx 会报告候选编码和重试方式。别看到乱码就直接批量转换原文件。

5. 批量替换先 dry-run

{"dry_run": true}
先确认匹配了哪些文件、多少处内容，再执行真正写入。

6. 长任务可以放到后台

用 run_background 启动，再通过 job_output、job_list 和 job_kill 管理。

后台任务可以跨 FastCtx 服务器和 Codex 会话继续运行，别忘了检查仍在运行的任务。

7. 回退前知道它会删除什么

fastctx unapply --yes
Unapply 会停止 FastCtx 管理的进程，移除它管理的配置和数据。你后来手动修改过的共享设置，FastCtx 会按写入归属尽量保留。

六、最后一句话

GPT-5.6 Sol 已经足够强，但模型能力和工具调用是否顺手，是两件事。

如果你的 Windows Codex 经常卡在读文件、搜内容、处理编码和拼 Shell 命令上，FastCtx 值得做一次对照测试。

别先相信“提速一半”，先看自己的任务时间线。

跑完以后，工具调用更少、重试更少、总耗时更短，这才是它对你真正有用的证据。

转自：https://mp.weixin.qq.com/s/ha6h6fj7TvOIhRlNA2ickQ