Performance | Francis Du

wcode v0.6.2：我不再拿 SLOTS 当性能了

Sat, 12 Sep 2026 05:32:00 +0800

前几天我一直盯着 wcode 的并发面板看。

SLOTS 32，PEAK 看起来也不低，但实际跑起来还是有一种很奇怪的感觉：数字挺忙，任务不一定真快。

我把执行链拆开看了一遍，问题就清楚了。

外层 Tool Slot 只表示请求已经准入。CPU、文件 I/O、cargo、git、Language Server 还有各自的线程池或队列，外面 32 个槽位全亮，并不代表里面 32 份工作都在向前跑。

0.6.2 先把这些资源分开计量和限制。

SLOTS、CPU、I/O、子进程是四件事#

现在我更愿意把执行路径看成：

Tool admission
      ↓
Foreground CPU budget
      ↓
Bounded file I/O pool
      ↓
Child process / Git probe queues

它们有不同的瓶颈。

前台 CPU 工作线程会取硬件并行度、8 个线程、内存推导上限和请求并行度的最小值。阻塞线程池上限提高到 64，是为了不让大量独立阻塞请求被隐藏的较小线程上限卡住。

独立文件修改走共享、有界的 I/O Pool；固定形式的 Git 状态和差异检查走独立 Probe Queue，不再和重型编译器进程抢同一组名额。

默认资源预算下，重型子进程仍然是很小的并发数。因为同时启动 20 个 cargo 不会 magically 变快，只会把机器打爆。

我专门撤回过一个“看起来更并行”的优化#

这轮有一件事我觉得挺重要：我试过把热读取也放进更宽的线程池，结果本地配对实验更慢。

所以撤回了。

做 Agent Runtime 很容易有一种冲动：

线程更多 = 更快
队列更深 = 吞吐更高
并发数更大 = Agent 更强

配对结果不好看就撤回。0.6.2 后面的资源调整也基本按这个标准做：先把不同类型的工作隔开，别靠调大一个统一并发值解决所有问题。

32 个命令排队时，我还希望 Read 能进去#

如果所有 Tool Slot 都被执行进程占满，Agent 连 read_file、状态查询这种轻操作都进不来，系统就会出现另一种死锁感。

所以执行进程类工具在拿总 Tool Slot 前，还要先拿一层 Execution Admission。

总量是 32 时，执行类请求最多占 28 个槽位，给非执行工具留四个受控余量。单槽位配置则保留一个可用名额，不会把自己完全饿死。

它不保证固定延迟，但编译队列再长，read_file 和状态查询至少还有机会进来。

明确的错误位置，不应该先全仓搜索#

性能不只在 Scheduler。

我调真实任务时发现另一个很浪费的路径：模型已经拿到了这种信息：

error[E0308] at src/runtime/harness/context_budget.rs:33:9

结果 agent_context 还先做一遍广域符号检索，再回来读这个明确位置。

这顺序反了。

现在带文件和行号的诊断会先经过 Workspace 保护解析，然后直接保留对应源码原文、行范围和 SHA 编辑前置条件。简单位置查询可以暂缓 Repo Graph 扩展；调用方、Impact、架构或显式 Scope 查询仍然走深入路径。

缺失位置也不会先把一堆无关文件索引起来再告诉我“没找到”。

这类任务现在先吃掉已有的精确位置，只有问题真的需要跨文件关系时才继续扩图。

同一个冷索引也不应该被重复建 10 次#

并发 Agent 很容易同时问同一个文件。

以前多个冷查询可能一起发现“没有索引”，然后各自开始建。

现在同一 Workspace、同一文件的冷查询会共享正在进行的索引构建。不同文件仍然可以独立执行；失效和版本变化会阻止旧构建结果晚到后重新污染缓存。

这里没有做增量 Tree-sitter，也没有引入全仓快照，只是把同一份冷索引的重复构建合掉。

`symbol_context` 开始对自己返回的版本负责#

另一个一致性问题是：索引说 Symbol 在 A，但真正读正文时文件已经变了。

如果这时还把旧签名和新正文拼成一个结果，Agent 会拿到一个内部自相矛盾的 Context。

现在 symbol_context 会核对符号信息和正文是不是同一文件版本。发现旧索引最多重新获取一次；文件持续变化、拿不到稳定版本时，就明确失败。

我宁愿返回“现在无法稳定读取”，也不想返回一个看起来完整的 Frankenstein Context。

验证计划不能静默只跑前八项#

0.6.2 还修了一个更严重的问题。

混合语言仓库里，完整验证可能推导出十几项检查。旧路径有一处会静默只取前八项。

这类优化最危险的地方不是少跑了几个命令，而是上层可能还把已经执行的前缀描述成“完整验证”。

现在先构造完整计划，整体上限是 32。超限就在派发前失败，明确告诉调用者没有执行检查，而不是偷偷截断。

验证历史也会在一次请求里共享代码 Revision 和 Evidence Snapshot，减少重复扫描；结果要同时匹配 Code 和 Design State 才能展示为当前有效。

窄范围检查不能把宽范围失败抹掉，时间戳冲突按失败关闭。Evidence 缺失或扫描截断，也不能被解释成通过。

`verify_project` 可以断线以后再查#

项目验证现在还复用了 MCP Tasks 扩展。

客户端支持 Tasks 时，服务端可以先持久化任务并返回 taskId，验证继续由 Runtime 管理。客户端断线后，可以拿同一个 ID 查询状态。

这里我刻意没有加一个模型可见的 async=true 参数，也没有把断线等同于自动重试。

因为对带副作用的系统来说，最危险的一句话就是：

没收到响应，那再执行一遍吧。

完成状态只表示底层工具返回了结果，不等于检查通过；调用者还必须读真正的 passed / error 状态。

配置终于开始收敛#

wcode 可调参数越来越多以后，另一个问题也很明显：高级参数是给调试和特殊机器用的，不应该逼所有人启动时手写一排数字。

所以现在有三档常用性能配置：

balanced
fast
light

也可以先预览：

wcode setup --performance fast --dry-run
wcode --show-config

真的执行 Setup 才会保存审核过的启动选项。

同时新增了：

wcode help-all
wcode help-all setup
wcode help-all --json

它直接从真实 CLI Parser 生成完整命令和参数目录，包括隐藏高级选项、短参数、别名、默认值和枚举值。

普通 --help 继续保持短。我不想为了“可发现性”把日常帮助页重新塞成说明书。

WebUI 首屏也一起收了#

Observatory 这轮主要改首屏信息层级。

现在执行活动、待批准请求、工作树变更、当前有效验证结果分开显示。Architecture 入口改成可搜索组件卡片和详情 Inspector，Design / Implementation / Overlay 图仍然保留，但不再要求用户先读一张很大的图才能知道项目现在发生了什么。

活动刷新也和慢项目刷新拆开。页面隐藏时停止轮询；共享进程资源和当前项目任务分开标记；“没有采样”不再画成“0”。

我主要想避免一件事：没有数据时别画成一个看起来很健康的数字。

做完以后，我给自己留了几条检查项#

我最后给自己留下几条明确的检查项：

Slot 数不等于吞吐；
拿到文件和行号，先读明确位置；
Verification mapped 和 executed 分开；
Task completed 和 checks passed 分开；
断线不自动重放；
没有采样就显示 unknown。

0.6.2 没有一个单独的大功能，更多是在把这些边界钉死。对我来说，这比再加一批 Tool 更实际。

我把 wcode 写代码这条链又压快了一轮

Wed, 26 Aug 2026 23:40:00 +0800

最近我拿 wcode 去几个别的项目里实际写代码，最明显的感受不是“功能还缺什么”，而是还不够快。

这个“慢”很容易全甩给模型。

但我看了一轮调用链以后，发现里面有不少完全是 Runtime 自己造成的等待。

模型可能已经知道要改哪几个文件了，结果后面还在重复遍历、重复强制落盘、串行扫描，或者一个一个发 Tool Call。

这些东西单次看都不大，Agent 连续改几十个文件时就很明显。

所以这一轮我没有继续加新的 Intelligence 能力，先把写代码的热路径压了一遍。

第一处：每个小编辑都 `fsync` 太贵了#

wcode 的文件写入一直比较保守。

已有文件不是原地 truncate，而是：

read + verify SHA
      ↓
create temp file in same directory
      ↓
write content
      ↓
atomic replace

这个设计我不准备改。

真正拖速度的是之前为了追求磁盘级耐久性，还会做：

temp file sync_all
rename
parent directory sync_all

也就是说，一个很小的 apply_edits 也可能触发两次强制刷盘。

在本地 SSD 上偶尔看不明显，但到了 macOS APFS、虚拟机、网络盘或者 Windows，一连串小 edit 的 latency 会直接堆起来。

这里我重新看了 Design State 的约束。

wcode 真正必须保证的是：

SHA stale-write protection
same-directory atomic replacement
create-new cannot overwrite raced target
path / symlink / hardlink safety

它不是数据库，也没有承诺“每一个 Agent 小编辑在机器突然断电后都必须已经物理落盘”。

所以现在交互式 Coding Path 去掉了每个小写入的强制 data + directory fsync。

Atomic Replace 还在。

这两个概念不要混在一起：原子性保留了，强制持久化延迟拿掉了。

第二处：`project_context` 原来有两个串行全仓库扫描#

Agent 进入一个新项目以后，我通常希望它先跑 project_context。

这里会做不少事情：

找 Manifest；
读 Repository Guidance；
推导 Verification Checks；
跑 Convention；
跑 Language Quality Matrix。

Profile 本身已经有 Cache。

但 Convention 和 Language Quality 之前还是串行执行。

这两个操作都可能扫一遍仓库。

Convention Scan
      ↓
Language Quality Scan

其实它们之间没有数据依赖。

现在直接 rayon::join：

        ┌─ Convention Scan
context ┤
        └─ Language Quality Scan

结果语义不变，但大仓库第一次进入时的 wall-clock 更合理。

第三处：搜索不应该先收集完整文件列表#

以前 search_code/search_many 的逻辑大致是：

WalkDir 整个目录
      ↓
收集 Vec<PathBuf>
      ↓
Rayon 并行读文件
      ↓
搜索

这意味着哪怕我要的前几十条结果很快就能找到，也要先把目录完整走完并分配一个 Path Vec。

现在改成了边遍历边送给 Rayon Worker：

WalkDir → par_bridge → read/search

一旦结果数量够了，后续 Worker 可以尽早退出。

大仓库里这类改动比在小 Fixture 上测出来的数字更有意义。

第四处：同文件多个 Edit 不应该重复建 Line Index#

apply_edits 支持一次对同一个原始 SHA 做多处编辑。

如果每个 Edit 都带 start_line/end_line，以前每一条都会重新遍历整份内容去算行首 Byte Offset。

也就是 N 个 Edit，可能做 N 次 Line Scan。

现在只要这一批里有人用了 Line Bound，就先建一次 Line Start Index，所有 Edit 共享。

对于几千行文件一次改很多位置，这属于很便宜但应该做的优化。

第五处：`read_file` 不需要为整份文件保存 `Vec<&str>`#

读取工具有 1 MiB 上限，所以以前直接：

let lines: Vec<&str> = content.lines().collect();

功能完全没问题。

但 Agent 大多数时候只拿 100～500 行。

现在先算总行数，再只对需要返回的 Range 做 skip/take。

不是一个惊人的 Benchmark，但这是典型的 Runtime Hot Path：每一次都跑，能少一次完整分配就少一次。

第六处：默认并行度再往上提#

之前默认值是：

logical CPU × 8
clamp 64..128

现在改成：

logical CPU × 12
clamp 96..192

Harness 的硬上限仍然是 256，CLI 还是可以显式：

wcode -j 256

为什么不直接默认 256？

因为这个 Semaphore 不只有小文件 IO，还会承载一部分 CPU 和外部进程任务。

我希望默认更激进，但不是把所有机器都当成 32 核工作站。

8 核现在默认 96，10 核 120，16 核及以上最多到 192。

这个档位更适合 Agent 一次并行导航和修改多个文件。

第七处：连“统计响应有多大”也不该复制整份 JSON#

TUI 会展示请求、响应和 Token Economy，所以 Tool Runtime 要知道每次调用大概传了多少字节。

以前这个指标是这样算的：

Value
  ↓
serde_json::to_vec
  ↓
拿 Vec.len()
  ↓
Vec 丢掉

也就是说，真正响应以后，为了统计长度又临时分配并序列化了一份 JSON。

小结果没什么感觉，但 parallel_tools、Graph、Project Context 这类 structuredContent 大时，这就是纯粹的额外内存和 CPU。

现在改成一个只实现 Write 的 Byte Counter，让 serde_json::to_writer 流过去，只累加字节数，不保存第二份 Buffer。

协议内容完全不变，Monitor 指标也不变，但每个 Tool Call 少一次只为计数存在的临时分配。

单个函数快了还不够#

Runtime 再快，如果 Agent 还是：

read A
edit A
read B
edit B
read C
edit C

MCP Round Trip 一样会浪费很多时间。

所以 Project Context 的 Workflow 现在会明确提示：

同文件多个修改 → apply_edits
多个已知现有文件 → apply_file_edits
多个新文件 → create_files
已知互不依赖的任务 → parallel_tools
一次遍历能解决 → search_many / read_files

我越来越觉得 Tool Harness 的性能不是单个函数跑多快。

它至少有三层：

模型要不要一次提出足够完整的操作
            ↓
Tool Runtime 能不能批量/并行调度
            ↓
底层文件和索引操作有没有多余工作

只优化最后一层，体感还是会卡。

安全检查没有为了速度删掉#

性能优化最容易走到另一个极端：觉得 canonicalize、SHA、Symlink Check、Lock 都贵，干脆少查一点。

这轮我没有这么做。

保留的边界包括：

Workspace Root；
Protected Path；
Parent Traversal；
Symlink Component；
Unix Hard Link Write；
SHA-256 stale revision；
写锁后的路径重新解析；
Atomic Replace；
No-shell Command；
Pending Authorization。

我拿掉的是重复工作和不必要的同步，不是安全模型。

现在还剩什么可以继续优化#

这一轮之后，我觉得还有几块值得继续盯：

project_context 的两个仓库扫描虽然并行了，但未来最好共享一次 File Inventory，而不是各走一遍目录。
MCP Tool Result 为兼容 content + structuredContent 本身仍会保留两种表示；这和已经去掉的“仅为统计字节数再序列化一次”不是一回事，大结果仍有进一步优化空间。
Software Graph 第一次建立时，Language/Tree-sitter Parser 初始化和目录候选选择还可以继续做更细的缓存。
Monitor 的指标必须保持便宜，不能为了展示吞吐量反过来拖 Tool Call。
多 Workspace 同时工作时，需要继续观察 Rayon、Tokio spawn_blocking 和全局 Semaphore 三层调度会不会互相争资源。

我不准备为了追一个漂亮 Benchmark 把这些全部一次性复杂化。

我现在还是拿真实项目当标准：哪一步明显在等，就把那一步拆出来。

这也是我现在优化 wcode 的方式。

v0.3 的整体变化见 wcode v0.3：从本地代码桥到 Software Intelligence Runtime。