业界顶级烧 token 的多 agent harness - Spexcode 开源了！

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

最近大家越来越对 lights-off software factory （黑灯软件工厂）关注了，这边咱先不争论软件工厂的可行性问题，先展示一下 spexcode 的烧 token 能力。

一天不到。以下账号全为 codex 200$ 账号。战损如图

还有个用掉了一半的 Claude Code 200$ 账号。

我个人 codex + cc 账号总数是每月 8 个左右，之前 codex 经常时不时重置所以苟住了，现在看来还是不够。

接下来我来介绍实现此效果的工具，Spexcode。

其实 Spexcode 并非一个 harness，而是一个多层级的 vibe coding 开发工具链，包括 spec-code 持续对齐，Agent 层级监督，worktree 管理等功能。直接使用用户自己安装的 cc, codex, pi, opencode 等作为个体 Agent 来调用。为了方便大家理解，我把架构拆成三层来说明，每层都有自己独立的用途，大家可以根据自己的场景来决定怎么用。

L0

就像多人协作需要版本管理一样，多 agent 协作需要意图管理。

Spexcode 的出发点不是 workflow 也不是 skills 合集，而是一套基础工具，定位为 agent 时代的 git。 (ps. 这个不是…而是…是我自己写的，不是 AI 写的 ^-^) Spexcode 通过 spec.md 构建 spec 的树状结构，frontmatter 中通过 code: 声明管辖的文件。有了这个结构，加上 git，“文档跟不上代码”就变成了一个能够机械计算的问题。具体地，如果代码在 spec 最后一版又动了，lint 的时候就会报错

drift: spec-cli/src/graph.ts is 1 commit(s) ahead of spec 'graph-lean' (v12) — may be stale

这就是 L0 层的核心机制。就像 git 自称自己为 the stupid content tracker（愚蠢的内容追踪器）一样，这里的机制我们也特意设置为简单的，可能误报的，但是又具备充足的表达力和门控功能。spex cli 的整体引导，函数追踪和 spec 树的 rag 算法我们都已做了充足的试验，并在不断改进中。

机制图解：

同样的机制不仅用在 spec 上，我们还用在测试场景的定义上。Vibe coding 有经验的朋友可能有体会，如果你有一套固定的测试代码，Agent 非常容易 overfit 到它，各种 mock 和 fallback，一个功能装模作样的就过了。其实我们这里有个理论就是，自然语言比代码更难 overfit - 道理很简单，因为自然语言就是在定义目标本身，如果你排除其它上下文，它就不会被曲解。而代码呢？测试代码最明显的反馈信号就是简单的通过/不通过，因此 agent 自然会朝着通过测试去优化，去曲解本来的目的。

所以用 spec 管理测试的话（spexcode 中是定义在伴随 spec.md 的 eval.md 中），就可以少写一些固定的测试代码，很多地方可以让 agent 根据 spec 临时一步步地手测，写完测试脚本就扔掉，只留下结果归档记录。当然不是所有事情都这么简单，实际工程中很多疑难杂症会出现，因此 spexcode 中每个测试场景也有 code：锚定，既可以链接功能代码也可以链接测试代码，这使得我们能够实现增量测试，使得测试的成本大大降低：发版之前，只要被检测过期了的场景即可。

我们自己在做的生产 app 中，spexcode 管理了 2000 多个端到端测试场景，每次发版之前会有约 200~300 个场景过期，我们视具体情况让 Agent 根据 spec 端到端手测，或跑预设的测试脚本。

L0 层是后续应用能成立的基础。没有 spec 和场景对齐的话，大规模 agent 并行只会让代码库越改越乱。

L1

L1 解决的问题是，一个需求从提出到被 agent 接受，写出代码并测试，维护项目 spec 的完整生命周期。

Spexcode 提供的 Agent 层级监督和跨 harness 通讯系统就是在这一层。这一层中，我们深入目前市面上百花齐放（实则大差不差）的 agent harnesses，设计了一个通用的 adapter，让 agent 在合适的时机自报状态，以及互相监听对方的状态变化，准确率基本 100%，包括完整的错误状态捕捉。当意外来临，例如模型额度用完，用不着你提醒，各个 session 就会去打探他们兄弟的情况：

这边我是用“session”这个词而不是"agent"，是因为我们容易给 agent 赋予一个较为持久、恒定的身份，而这和 spexcode 的设计理念相违背。我们认为目前最好的 vibe coding 模式是让每一个 session 速战速决，而 harness 自带的 compact 不是一个认真的 context 管理机制，只是偶尔防止停摆的一个补救罢了。

我们知道人的注意力是最昂贵的资源，为了不事必躬亲地指挥 agent 团队，我们必然要走向分层监督、让 agent 来管理 agent 的模式，spexcode 让这一过程变得非常自然，你会看到你的 agent 将一个任务委派给多个 session，每个 session 在自己的 worktree 中工作，并自主完成自己的测试流程，在结束前清理掉相关资源占用，通过监督 agent 的审计后面板上的 session 记录和 worktree 一起消失。

总结一下，L1 在 L0 的基础上引入了 harness 适配，基于 tmux 的 session 管理和 git worktree 并行开发的模式。实际生产中，这一层往往被应用于 CR、CI 等自动化流程之中。你可以把它当做积木搭建起自己的开发流水线。

L2

L2，一个参考的前端仪表盘实现，也是一个轻量的 vibe coding 工作台，多种主题可选，可以全键盘操作。

由于是网页 APP，如果你将一个项目开放在局域网里（有一个简单的权限系统），你可以像在 github 里面一样通过复制给同事一个 issue/scenario 的链接，同样的，你也可以复制自己的 session 的链接给他的 session（如果他也用 spexcode 的话），然后他们就可以相互对话！

整个 dashboard 里面各个输入框都有统一的 spec 节点引用和 session 引用记号，即 [[ 和 @，以及 spexcode 的一些专属增强 command，通过 / 展开。

所以目前是一个 agent 自动化和人机工程学并举的模式。允许我用一个梗图结尾

项目链接：

交出你的 token，释放生产力吧！

ps. 对于软件工厂的失败模式，我推荐大家看一下这个演讲