一个使用前沿模型进行规划但在本地运行大部分token的代理（为我的双RTX 3090机器构建）

在过去的几个月里，我一直在为自己构建一个工具。我有一台双RTX 3090的系统，本来想用它，但Qwen 3.5/3.6 27B和Gemma 4 31B虽然非常好，却没有前沿模型那种品味和能力。另一方面，前沿模型很昂贵，我不想所有事情都通过它们运行。我希望两全其美：用前沿模型进行规划推理，而本地模型完成几乎所有实际工作。我尝试过一些仓库，它们通过‘调用’前沿模型让小模型发挥超出自身能力的效果，但那不是我想要的。我希望能够用前沿模型进行规划，因为过去十年以上的软件工程经验告诉我，设计是大多数项目的瓶颈，能防止意大利面条式代码或重写。我创建了一个代理，经历了大量迭代，现在我认为有了一个可用的版本，并正在个人使用中。这个代理的核心是这样的（它使用了很多现有工具，没有重复造轮子）。但一切都是可定制的。三个层级，全部可以通过配置文件互换： * 规划器：Codex（非常强大；不过任何能输出决策JSON的模型都可以在此使用） * 本地模型：Qwen 3.6 27B（非常适合代理使用和工具调用，编程也足够好） * 高级模型（可选）：通过opencode-go使用Kimi K2.6（当本地模型失败且重试次数耗尽时使用） 你可以让三个层级都是本地模型，两个层级本地，一个前沿一个本地，或者任意组合。这只是我发现效果最好的配置。每个任务都送到Codex，它可以映射为N个阶段。比如一个大型编程任务通常映射为3个阶段（研究、实现、审查）。类似地，审查任务也会进入阶段（审查、产物）。每个阶段还可以在多个周期（epoch）内进行迭代，每个周期会分配任务给本地模型执行（而且做得很好），所有这些都由Codex规划。最大的区别在于确定性验证。一个任务只有当检查实际通过时才计为完成，即命令退出码为0或者应该生成的文件存在。状态机自己重新运行这些检查，而不是信任模型所说的结果，因此一个长达数小时的链不会因为声称没有实际取得的进展而偏离。我发现这可以让本地模型变得比原来强大得多： 1. 使它们能够执行持续数小时的任务 2. 拥有前沿模型的品味和能力，但大约85-90%（根据我的测量）的Token通过本地模型处理。对于输出Token，大约95%。 3. 上下文隔离，防止上下文腐烂，并且前沿模型更便宜，因为上下文窗口不会被bash调用溢出。 4. 默认还做一些有用的事情：使用仓库映射器（repomapper）将仓库映射为图，并相当积极地整理上下文，这样本地模型就不会被无关文件淹没。 它仍是工作进展中（WIP），但终于到了可用的阶段。所以想问你们是否愿意尝试一下（仓库在第一条评论中）。 不足之处： 安装：不太干净。我使用了很多现有的开源软件，如pi、opencode等。 没有UI：只是一个带有简单TUI显示状态更新的shell命令。你需要自己创建一个job.md文件（或者让代理创建一个）。