Agent 编码环境：文件系统与并行 I/O 吞吐

背景

Agent 编码循环的时间往往耗在 读仓库、写补丁、跑测试，而不是模型思考本身。并行多个 Agent 时，文件系统成为共享瓶颈：同一目录上的大量小文件读写、锁竞争、以及缓存冷启动，都会让「开了 N 个线程」却几乎不加速。

环境选择（本地磁盘、网络盘、容器层、远程开发机）会放大或缓解这些问题。这里不比较品牌优劣，只谈可复用的工程事实：并行度必须匹配 I/O 隔离与任务独立性。

要点

1. 热点文件：lockfile、巨型生成物、单一巨型模块——多写者并行必冲突。
2. 小文件风暴：递归读整仓再过滤，比「按路径白名单读」贵一个数量级很常见。
3. 缓存与工作区：重复冷启动依赖安装；持久化缓存或复用 worktree 能稳住吞吐。
4. 产物落点：日志与中间文件写到独立目录，避免污染源码树触发无关监听器。

吞吐优化首先是 减少无意义 I/O，其次才是加并行度。

怎么做

实用清单：

1. 缩小读集：规格里写清允许读取的目录；默认排除 node_modules、构建产物、.git 大对象。
2. 并行按模块切分：前端 / 后端 / 文档分工作区；共享契约文件设单写者。
3. 批量优于抖动：一次读相关文件再推理，避免「读一行 → 想 → 再读一行」的往返。
4. 测量再调：记录每阶段 wall time（读仓 / 生成 / 测试）；用体积工具看产物是否异常膨胀。
5. 合并阶段集中 I/O：并行期少做全仓搜索；合并后再统一 format / lint。

任务 A 工作区（只碰 pkg/a） ║ 任务 B 工作区（只碰 pkg/b）
            ╲                 ╱
             ╲  合并 + Diff  ╱
              ╲             ╱
               总验收（一次）

若测试套件本身是 I/O 重的，优先给测试分片与缓存，而不是盲目加 Agent 数。

和本站工具

• 字节大小：判断产物与日志是否异常变大。
• Diff：合并并行改动前做对齐。
• 查找替换：批量整理路径或标记。
• JSON：汇总各线程耗时与文件计数。

入口：Tools 首页。

实践中还有两类隐蔽成本：编辑器或文件监视器因中间文件抖动而反复索引；以及测试框架在每个分片里重复拉起浏览器。前者把临时目录指到工作区外并加入忽略列表；后者复用浏览器上下文或做 setup 缓存。这些与「换更快的磁盘」相比，往往ROI更高。

远程开发机场景下，延迟会放大每一次「读小文件」的往返。策略是提高单次工具调用的信息密度：一次返回目录树摘要与相关文件切片，而不是几十次细碎读取。并行线程数应随观测到的 I/O 等待比例调节——等待高就先减负，而不是再加线程抢同一块盘。

把「并行度」写进仪表盘：同时运行的 Agent 数、每秒文件操作次数、锁等待时间。数字说话之后，调参才不是玄学。

小结

并行 Agent 的吞吐上限，常常卡在文件系统与任务切分，而不是模型参数量。缩小读集、隔离写路径、测量各阶段耗时，再决定加不加线程——这是稳定可复用的工程习惯。