原文：Infrastructure for Agentic Rust （2026-10-05，作者 Jonathan Ellis）

Agentic Rust 的基础设施

我的大半个职业生涯都在 Java 和 Python 这类托管运行时语言中度过，所以转向 Rust 时，等着我的是几颗新地雷 。到现在，我以 Rust 为主要语言写代码已经大约六个月了——或者更准确地说，是"让代码被写出来 "——我想我终于快到雷区的另一头了。

以下是我踩过的一些地雷。如果你还生活在 2023 年、一行一行手写代码，它们大多只是小烦恼；但当它们被十几个同时撞上来的 agent 一放大，就绝对能毁掉你的一天。

地雷 #1：Cargo 是个糟糕的室友

即使是我这样的 Java 程序员也知道 rustc 很慢。但我不知道的是，cargo 默认就会让 target/ 越涨越大，直到磁盘被写爆（ENOSPC）。

解法 #1：MBX

Rustaceans 用 sccache 和 cargo-sweep 已经很多年了，而最近 Jeff Dickey 做出了 Mr. Boxington （即 mbx），带来了一批 Rust 专属的体验升级。毫不夸张地说：只要你还在调用 rustc，你就应该用 mbx。它为你做了这些事：

  1. 自动清理 target/。
  2. 用 reflink 在多次构建之间共享已编译的依赖，所以无论同时跑着多少个 worktree 或 agent，依赖都只需要构建一次。（但请读一读 share_workspace_root 相关的细则。）
  3. 同样用 reflink 共享已完成的 crate，细则见下文。
  4. 还有一个服务端版本，能把第 2、3 项部署到 AWS 上，让整个团队受益。
  5. （与大多数构建缓存不同）它和增量构建相处得很好。
  6. 当 Cargo 试图耗尽你的磁盘时，给你一个统一的"咽喉"可以掐住。
  7. 可以按需限制构建占用的 CPU 和内存，减少资源争抢、防止 OOM。

地雷 #2：Rust 构建产物大得吓人

这与第 1 条相关但又不同：即使你的 target 目录修剪得整整齐齐、没有早期构建留下的垃圾，cargo 的工作集依然大得惊人。我投入时间最多的 Rust 项目是 Bifrost ，它一个正常的 target 目录就有 52GB。（我希望能有位 Ward Cunningham 附体的人出面告诉我，怎么把它砍到五分之一甚至十分之一；但据 Fable 和 Astra 告诉我的，在 Rust 这片地界，事情就是这样。是的，我们已经开启了 line-tables-only。）

要是有哪个 agent 决定改动 feature 或包集合，那就求上帝保佑了——这些组合的哈希各不相同，每多一个变体，最多又要多花 52GB！

（用 agent 写过代码的人都知道：它们对"别他妈动 feature 集合"这类指令的重视程度，也就只比万年不变的"别犯任何错误"高那么一点点。）

解法 #2：ZFS

Rust 二进制唯一的好消息是：用不太吃 CPU 的 zstd 或 lz4，它们能压掉大约 70%。所以——看来我这辈子注定要作为反面教材警示后人——我把 mbx 的构建卷重新格式化了三次：

先换成 XFS，因为 ext4 还困在 90 年代，至今没有 reflink ——而 reflink 正是让 mbx 共享同一份 Cargo 产物的关键。（不过有细则说，如果你愿意接受一些妥协，mbx 在 ext4 上也能用硬链接。）

然后换成 Btrfs，因为 XFS 不支持压缩。

最后（切到 Btrfs 一小时后）换成了 ZFS，因为对任何有并发写入的工作负载来说，Btrfs 都是一袋子破碎的悲伤；而 Btrfs 的开发者显然觉得这种场景罕见得足以搁置多年不管 。

现在，我工作站上 3TB 的物理卷估计能装下 10TB 的 Cargo 输出；有 mbx 负责打扫，就算是一群极度亢奋的 agent 也填不满它。

  • 你可能会和我当初一样想：既然 mbx 的 reflink 已经解决了空间问题，为什么还需要压缩？问题在于，reflink 只对完全相同的输出有效——而这只占我构建输出的约 7%。即使算上 ZFS 的完整块级去重，也只能提升到 11%，因为二进制里只要插入或删除第一个字节，其后的一切就都成了唯一块。所以压缩才是你唯一的指望。

左：逻辑视图。右：物理视图。彩蛋：worktree 的压缩效果也很好！

地雷 #3：rustc 很慢

是的，这颗雷我是睁着眼睛踩下去的，但这并不能减轻它的问题：我等 Cargo 的时间，是等 LLM 推理时间的 4 倍。（这是我 harness 日志里的真实生产比例。）这里我没什么长篇故事可讲，谁都知道它慢——这就是零成本抽象要付出的代价 。Nightly 能让你回血大约 10%，代价是编译器里那些不可预测的 bug；不了，谢谢。

解法 #3a：mold

据说默认的 rust-lld 已经比过去那些糟糕的年代快了很多，但 mold 仍然还要快 50%–100%。所以你应该用 mold（mbx 为它提供了方便的钩子），至少等到 wild 支持增量为止。但更快的链接器解决不了主要问题——主要问题在 rustc 本身。

解法 #3b：Mjolnir

Mjolnir 是一个面向编码 harness 的控制平面，让你能跨 profile（甚至可以是异构的，从 Claude 到 Codex 再到 DeepSeek）和跨机器（“targets”）迁移会话。这样，你就能把那些嗷嗷待哺的 rustc 构建会话分散到所有机器上，或者突发扩容到 EC2。

左：Mjolnir TUI。中：Mjolnir targets 详情。右：Mjolnir 的 mbx 配置详情。

数量本身就是一种质量

这些问题并不新鲜，但二十个 agent 同时跑构建，是现有基础设施设计时从未考虑过的场景。我很高兴看到新一代工具正在被造出来，解决"在 agent 规模下写 Rust"这个问题。