昂贵模型不写代码：多智能体编排新范式

过去一年，大多数开发者使用编码智能体的方式几乎一样：选一个模型，开一个对话窗口，盯着它一行一行地写。模型能力强，账单就高得吓人；模型便宜，就得全程盯着，随时纠偏。

Orchestro 的作者提出了一种截然不同的做法。他同时跑多个项目，而整套系统里最贵的那个模型，一行代码都不写。14 天里，他的会话按 API 价格消耗了约 2100 美元的 token，但实际只付了 100 美元的订阅费。这个数字背后，是一套把"思考"和"打字"彻底拆开的多智能体编排架构。

三个角色，各司其职

这套架构把工作拆成三层，每个角色只负责一件事。

战略师（Strategist） 由 Claude Code 驱动，以高推理强度运行。每 5 分钟（通过 /loop 5m）检查一次编排器在做什么：选了哪个任务、交付了什么、卡在哪里。它不写代码，只判断方向对不对。

编排器（Orchestrator） 持有待办队列，挑选下一个任务，交给执行器，并记录结果。

执行器（Executor） 是一个跑在固定订阅上的便宜编码智能体，比如 Muse。它干实际的活：拉分支、改代码、跑测试、提 PR、只在验证通过时合并、最后确认变更已上线。

关键在于，编排器不关心执行器用哪个模型。项目自己声明用 Claude、Codex、Grok 还是 Muse，这意味着当一个供应商配额耗尽，任务不会被卡死——它留在队列里带着证据，换个执行器接着干。

什么是 /loop 命令？ 在一些编码智能体 CLI（如 Claude Code 的社区扩展或类似工具）中，/loop 是一种让智能体按固定时间间隔自动重复执行某个任务的指令。/loop 5m 表示每隔 5 分钟触发一次。它的价值在于把"监督"从人工操作变成自动化心跳：战略师不必持续在线，只需在每次被唤醒时读取当前编排器状态、判断方向是否需要调整。这种"定时代理"模式与传统的"事件驱动"不同，成本可预测、逻辑更简单，但也意味着它大部分时间在检查一个安静的系统，可能错过两次检查之间发生的瞬时故障。

什么是模型级联 / 混合模型？ 模型级联（model cascade）指在同一工作流中组合不同能力与价位的模型，让贵模型做高价值决策、便宜模型做批量执行。核心假设是：任务的不同阶段对推理深度的需求差异巨大。本架构中，战略师用高推理强度的 Claude 负责方向判断，执行器用订阅内的便宜模型完成拉分支、改代码、跑测试等长链条操作。这样既避免了用昂贵模型做机械劳动，也把成本锚定在固定订阅而非按 token 计费的 API 上。

让整套系统转起来的一条规则：分清两种问题

当战略师发现问题时，第一个要问的是：这是谁的问题？

项目问题（一个 bug、优先级排错、遗漏的待办项）：战略师直接修待办队列，执行器下一轮就会接上。

框架问题（编排器选错任务、卡死、永远不关闭工作）：战略师不去打补丁绕过它，而是把问题报告给另一个会话——那个会话唯一的职责就是维护编排器。它修好核心逻辑，再把新版本推送到所有项目。

作者举了一个真实案例：10 月 14 日，战略师发现博客内容管线自切换到轻量编排器后，整整一天没有任何东西被验证过。工作照常交付，但编排器只记录了"已交付"，从没记录"已验证"，所以验证器根本没看到这些变更。这不是博客的问题，是框架的问题——它被送到了框架会话，而不是在本地写个临时补丁糊过去。

每个项目都在测试框架，框架的每个修复又惠及所有项目。作者并不提前规划编排器的改进，"是真实项目自己找出来的"。

什么是"编排器"与"待办队列"？ 编排器（Orchestrator）是这套系统里的调度中枢，它本身不写代码，而是维护一个待办队列（backlog queue），从中挑选下一个任务、指派给执行器、并把执行结果（成功、失败、证据）记录回队列。待办队列使任务与执行器解耦：当某个供应商配额耗尽，任务不会丢失，而是带着已有证据留在队列中，等待下一个可用执行器继续。记录结果而不只是记录"已派发"，是这套架构能发现"已合并≠已验证"问题的前提，因为证据链让独立验证器可以在事后复核每一项变更。

什么是"框架问题"与"项目问题"的分野？ 这是作者反复强调的归因原则。项目问题指某个具体项目的缺陷或优先级错误，修复动作局限在该项目的待办队列内；框架问题指编排器自身的逻辑缺陷，例如选错任务、卡死、工作永不关闭。区分二者的意义在于避免"局部打补丁"掩盖系统性缺陷。框架问题会被上报给一个专职会话——它唯一的职责就是维护编排器核心逻辑，修好后推送到所有项目。这种"归属路由"把一次修复的收益放大到所有项目，也让框架在真实项目的使用中被动进化，而非提前规划。

混合模型的真正理由：成本与恢复能力

为什么要混用模型？答案有两层。

成本逻辑很清晰：思考贵，打字便宜。贵模型每 5 分钟读一次状态，便宜模型跑长时间的连续任务。所有调用都走官方 CLI，用订阅的原生配额，而不是按 token 计费的 API key。

从 3 日到 16 日，作者的 Claude Code 会话消耗了约 1700 万输出 token 和 70 亿缓存输入 token。按公开 API 价格算，大约是 2100 到 2250 美元，折合每月约 4500 美元。而他实际支付的是每月 100 欧元的订阅费——这还只是 Claude 的开销，执行器的用量还没算进去。

但作者很诚实地指出了前提：一个每 5 分钟重读上下文的循环，在订阅制下便宜，在 API 计费下昂贵——API 等价账单里，65% 会是缓存读取。这个模式之所以成立，恰恰因为用的是固定订阅，而且要在它们的限制范围内运转。如果某个供应商改变了对自动化用量的计费方式，这些数字就会变。

恢复能力是另一层价值。当某个供应商配额用尽（那周是 Codex），工作不会停。任务带着证据留在队列里，换个执行器继续。

为什么缓存读取会占到 API 等价账单的 65%？ 现代大模型 API 通常对输入 token 区分"缓存命中"与"未命中"两档价格：缓存命中（即此前发送过的上下文被复用）价格远低于未命中。本架构中，战略师每 5 分钟就重读一遍编排器的状态与历史，绝大多数输入都是重复的旧上下文，因此产生巨量的"缓存读取"token（作者报告 70 亿缓存输入 token），而真正新增的内容很少。在按 API 计费时，这些缓存读取虽然单价低，但因体积巨大，最终累积成账单的主要部分。在固定订阅制下，这部分开销被订阅费吸收，这正是模式成立的关键前提——一旦供应商对自动化用量改变计费方式，经济性可能瞬间反转。

目前的数据，包括那些不好看的

作者公开了三个维度的数据：

• 博客内容管线，3–14 日：独立验证器发出 95 项裁决，87 项通过，7 项失败，1 项无法结论。
• 编排器自己的仓库，同期：63 次合并，独立验证通过数为 0（8 项失败，13 项无法结论）。
• 13 日切换到轻量编排器后：博客第一天没有任何验证记录，直到战略师抓到了那个 bug。

作者反复学到的教训是："已合并"不等于"已验证"。一个只统计合并次数的系统，看起来会很漂亮，但对你说谎。

还没解决的问题

这套架构并非没有短板，作者列出了三条：

执行器仍然会在没做完时说"做完了"。这就是为什么战略师读的是状态，而不是消息。

每 5 分钟检查一次的战略师，大部分时候在检查安静的系统——"每次有效修复对应多少次检查"这个数字，他还没测出来。

同一台机器上跑两个重负载构建会互相打架。目前用一个共享锁来串行化，但作者承认这是权宜之计，不是设计。

这不算全新，但组合方式是新的

作者坦承，规划器/执行器拆分、监督智能体、模型级联这些概念早已存在。他没见过的是这个组合：按固定时钟运行的便宜监督者、按"归属"（项目问题还是框架问题）路由问题、以及一个独立的会话来从真实项目暴露的故障中改进编排器。

如果你已经在用类似方式工作，或者用别的方法解决了同样的问题，作者提出了三个问题：你的监督者多久检查一次，具体看什么？你怎么判断一个问题是项目问题还是工具问题？你每个"已验证"变更的真实成本是多少，而不是每个合并的成本？

Orchestro 目前处于很小的私有测试阶段，主要用在他自己的项目上。