我构建了一个任务编排器，然后删掉了它最棒的数字
ORA 发布了：一个单一的 Go 二进制文件，它接受一个任务，将其拆分为子任务，将每个子任务路由到能实际完成它的最廉价模型，执行它们，并调和结果。它可以与 Claude Code、Codex、Pi、Cursor、Cline、Hermes 配合使用——也可以独立运行。
go install github.com/vystartasv/ora/cmd/ora@latest
ora "build a login system with JWT"
ora "refactor the API to use async handlers and add tests"
ora "design the database schema for a multi-tenant SaaS" --plan
以上就是公告。更有用的是：README 的开头原本展示了一个更好的数字，而我在发布前两天把它删掉了。
那个数字
最初的 README 声称一次运行比把所有内容发送给旗舰模型便宜 68%。看起来棒极了。你的目光会首先被它吸引。它也是假的——不是欺诈意义上的假，而是更糟糕的：它是一个经过精心设计的例子，悄悄地将自己提升为了一个衡量标准。一个廉价子任务，三个中等子任务，一个旗舰子任务。成本系数分别为 1、2 和 10。总共 17 个单位，而不是 50。66%，在某个地方四舍五入到了 68%，之后再也没被质疑过。没有人测量过任何东西。README 中的图表就是证据。
为什么修正不是修正
第一直觉：记录模型，使其可复现。我添加了一个成本系数表，这样任何人都可以重新计算并得出相同的结果。然后一个显而易见的问题出现了——我本应该先问自己的：旗舰模型不仅每个 token 更贵——它每个 token 能做更多工作。一个廉价模型可能需要 2000 个 token，搞错了，再重试两次。一个旗舰模型可能只花 400 个 token 就能做对。每个子任务的成本系数假设这些是同一回事。所以这个指标不仅仅是不精确。它在衡量错误的东西，而且方向对我有利。ORA 做出的每一个路由决策看起来都像在省钱，因为“省钱”被定义为“没有使用昂贵的那个”。那不是基准测试。那是一面镜子。
我构建了一个任务编排器，然后删掉了它最好的数字
用什么替代了它
什么都没替代，从节省的角度来说。ORA 中不再有节省百分比。我从 report 结构体中删除了该字段，从 orchestrate.go 中删除了计算逻辑，从 README 中删除了表格。取而代之的是更小、更真实的数据：实际运行成本。每个子任务的真实 token 用量来自 API。乘以模型的实际单位价格。打印出运行成本。
5 个子任务 · 4 个模型 · $0.0038
没有反事实对比。没有想象中的旗舰专属运行来比较。只有你实际花费的金额。这是一个更平淡的数字，但它严格来说更有用——如果你在决定是否采用这个东西，你需要知道它要花你多少钱，而不是理论上相对于你根本不会运行的配置能省多少钱。
背后的规则
任何需要想象一个从未发生的运行的指标，都是故事，而不是度量。节省声明本质上就是反事实的。目前 AI 工具中大多的"快 X%"和"便宜 Y%"的数字也是如此——包括你这个月读过的很多。它们把一个实际发生的事件与某人假设会发生的事件进行比较，而这个假设总是由发布消息的人来选的。实际成本、实际 token、实际延迟：这些你可以直接打印出来。你的 README 中的数字应该达到的标准是：一个陌生人可以在不相信你说的任何话的情况下复现它。
ORA 实际做了什么
既然没有什么可以过度推销的了：
- 分解——大语言模型（LLM）将你的任务拆分为独立、可验证的子任务
- 路由——每个子任务被发送到适合其类型的最便宜的模型层级（查询和研究走便宜层；代码生成和审查走中间层；调试和架构走旗舰层）
- 委派——生成子代理或调用 CLI 代理，在图允许的情况下并行执行
- 压缩——从提示和输出中剔除填充内容
- 协调——验证、合并，报告到 .ora-report.json
- 将 ORA.md 放入任何读取规则文件的代理中，它就能学会同样的工作流——CLAUDE.md、.cursor/rules/、.clinerules/、Copilot instructions、Hermes skills。
我构建了一个任务编排器，然后删除了它最好的编号
路由（Routing）是整个思路的核心。并非每个子任务都需要世界最好的模型，而路由决策是你本来每次都要手动做、并且做得很糟糕的事情。
GitHub: vystartasv/ora — MIT 许可，单一 Go 二进制文件，v0.1.0。
是容忍、坚韧，还是只是累了？都不是——这个及时被发现了。勉强算吧。