moshcode work：50个AI代理，一个验证器，一个收件箱

当人们运行数千个AI代理来证明数学定理时，他们并没有在盯着数千个代理。证明检查器才是那个盯着的人。Lean对每一次尝试给出是或否，错误的尝试被丢弃，人类只看两件事：通过了什么，以及卡在了哪里。

我们过往的代理工具走的是另一条路。一个“herd”是每个代理一个终端窗格，一个“swarm”是几个窗格。这上限取决于一个人能读多少个窗格，大约十个。

于是moshcode 0.117.0新增了moshcode work。每个任务携带一个verify命令，退出码0是“完成”的唯一定义。工作进程是无头进程，每个都在自己的git工作树中。引擎对自己工作的评价会被记录，但从不被采纳。

moshcode work from-tests fix-tests                 # 每个失败的测试文件一个任务
moshcode work run fix-tests -n 50 --engine claude  # 五十个工作进程
moshcode work status fix-tests                     # 数字，而非转录文本
moshcode work inbox fix-tests                      # 只显示每次尝试都失败的任务
moshcode work apply fix-tests                      # 合并通过的补丁

一次失败的尝试会带着验证输出重新回到队列，进入下一次提示。三次失败后，任务会连同其工作树一起进入收件箱。一个已经通过的任务只需要一次验证，不消耗token。任务认领是原子性的文件重命名，因此同一个队列上的多个运行可以拆分任务。每次运行都记录为一个OpenFleet swarm。

首次运行：在moshcode自身上的实践

我们有139个测试在本地失败但在CI中通过。from-tests对每个文件单独运行，发现只有一个真正失败。其余138个是PWA测试，当PWA自身的依赖未安装时会崩溃，而不是像它们的邻居那样跳过。

那是19个任务。每个PWA文件的验证运行了两次：没有依赖时（必须跳过）和有依赖时（必须通过）。50个Claude工作进程并行处理它们。

19个任务全部在第一次尝试中通过。收件箱保持为空。没有添加或删除任何断言。本地失败从139个降到了0。

那唯一真正的失败是最佳的发现。一个moshcode mcp install的测试继承了宿主机的PATH和HOME，因此机器上安装的任何编码引擎都会加入运行，并对我自己的配置执行真实的mcp add。工作进程让它只使用存根引擎。

下一个队列需要一个不同于测试的验证器：类型检查错误、必须返回200的URL，最终是Lean。

moshcode upgrade self可以获取它。源代码和PRD：https://github.com/moshcoder/moshcode/releases/tag/v0.117.0

PWA（Progressive Web App，渐进式Web应用）测试的特殊性在于其依赖环境：当PWA自身的依赖未安装时，测试通常会跳过而不是失败，但某些情况下会直接崩溃。文中提到的138个PWA测试失败正是因为依赖缺失导致崩溃，而验证条件要求“无依赖时必须跳过，有依赖时必须通过”，从而确保测试在不同环境下行为一致。这种双重验证策略避免了环境差异造成的误报，是验证器驱动的关键设计之一。

核心设计：验证器驱动，而非人类监督

moshcode work的设计哲学直接借鉴了数学证明领域的实践。在那里，人类不需要审查每一个代理的推理过程，因为Lean证明检查器提供了客观的、不可协商的通过/失败信号。moshcode将这一模式移植到软件开发任务中：verify命令就是你的Lean。

这意味着代理的自我评估被刻意边缘化。引擎可能会说“我完成了”，但只有退出码0才算数。这种设计消除了代理过度自信或幻觉完成的风险。失败尝试的验证输出会反馈到下一次尝试的提示中，形成一种基于客观信号的迭代改进循环。

Lean是一个交互式定理证明器，同时也是编程语言。它的核心特性是能够对数学证明进行机器检查：用户编写证明，Lean 逐行验证其正确性，最终返回“通过”或给出错误位置。这种检查是客观且不可协商的，不依赖于证明者的自我评估。在数学形式化领域，Lean 已被用于验证复杂定理（如费马大定理的片段），其严格的检查机制确保了证明的可靠性。moshcode work 将这一范式移植到软件开发，用 verify 命令（如测试运行、类型检查）模拟 Lean 的检查器角色，从而将代理的自我评估降级为参考信息。

并行化与任务拆分

通过使用git工作树隔离每个工作进程，moshcode work避免了代理之间的文件冲突。任务认领通过原子文件重命名实现，使得多个运行可以安全地共享同一个队列。这为水平扩展提供了基础：你可以运行50个、100个甚至更多工作进程，而瓶颈不再是人类的阅读能力，而是验证命令的执行速度。

收件箱机制是另一个关键设计。只有那些用尽所有尝试（默认三次）仍然失败的任务才会进入收件箱，并保留其工作树供人类检查。这确保人类注意力集中在真正困难的问题上，而不是被大量成功案例淹没。

Git 工作树（worktree）允许在同一个仓库中同时检出多个分支到不同目录，每个工作树拥有独立的工作区和索引，但共享同一个 .git 目录。这使得多个进程可以并行修改代码而互不干扰，且提交历史保持统一。在 moshcode work 中，每个工作进程都在自己的 git 工作树中运行，任务完成后通过 apply 命令合并补丁。这种隔离方式避免了文件冲突，同时保留了完整的版本控制上下文，便于失败时检查工作树状态。

实际效果与启示

在moshcode自身的测试套件上，50个Claude工作进程并行处理19个任务，全部一次通过，将本地失败从139个降至0。更重要的是，它发现了一个隐藏的测试缺陷：一个测试意外地继承了宿主机的环境变量，导致真实的mcp add操作被执行。这种问题在传统的人工审查中很容易被忽略。

这个案例展示了验证器驱动代理工作流的两个核心优势：规模化和发现深层问题。当验证是客观的，你可以放心地并行化；当人类只检查失败案例，你可以发现那些被成功掩盖的缺陷。

下一个挑战是将验证器从测试扩展到类型检查、HTTP状态码检查，最终到形式化证明。每一步都需要不同的验证策略，但核心模式保持不变：一个客观的验证器，大量无头工作进程，以及一个只显示真正卡住的任务的收件箱。