让云端模型负责规划、本地模型负责写代码，听上去很适合省钱：昂贵模型只做少量决策，大量输出交给自己的机器。但规划、执行和返工是连在一起的，一次任务用了更少 API 费用，可能也花了更多时间，或者只完成了一半。
本文从一则 Reddit 项目作者的公开实验出发，给出普通开发者可以照做的验收方法。若你还没买本地设备，先读 本地模型替代订阅指南；大型 MoE 的磁盘部署路线见 Colibri。
图 1: 把独立验收留在流程里，才能发现模型自称完成后的遗漏。
那个“便宜 2.7 倍”的实验究竟做了什么
原帖作者使用 Atomic Agent，将 Qwen 3.8 27B 与经 OpenRouter 调用的 Sonnet 5.5 组合，做一个包含五个物理场景的页面。作者描述本地机器使用 RTX 3090 24 GB 和 CUDA 版 llama.cpp，每个配置只自主运行一次，不做人工修补。作者同时披露自己是运行这套实验的 agent 项目的开发者。
下面是原帖报告的结果，费用只指作者记录的云端 API 消耗，不包括本地硬件、电力和人工复核。模型版本与环境均为原帖口径，结果如下：
| 配置 | 正确场景数 | 耗时 | 云端 API 费用 |
|---|---|---|---|
| 本地 Qwen 单独执行 | 1/5 | 26 分钟 | 0 美元 |
| Sonnet 规划、Qwen 写代码 | 2/5 | 85 分钟 | 0.67 美元 |
| Qwen 规划、Sonnet 写代码 | 4/5 | 14 分钟 | 约 2.77 美元 |
| Sonnet 单独执行 | 4/5 | 9 分钟 | 1.83 美元 |
所谓便宜约 2.7 倍，是把 1.83 除以 0.67 得出的账单比值；但对应配置只得到 2 个正确场景，云端单模型得到 4 个，而且前者花了 85 分钟。两边的交付质量和时间不同，不能把这个比值直接写成“同质量省下六成成本”。同样，反向分工在这次记录中达到相同正确场景数，费用却高于云端单模型。
这组数据可以提示我们检查哪些变量，却不足以证明某个模型适合所有规划或编程任务。只跑一次，无法评估成功率波动；五个场景来自一个页面，也不是五个独立的软件项目。原帖作者提到所有运行都自称验证无误，但画面仍有错误，这尤其说明“控制台没报错”与“功能正确”需要分别验收。
先把规划和执行的接口写清楚
Atomic Agent 的官方 README 将 Fusion 描述为一个模型协调、工作模型执行委派任务的运行方式，可使用云端规划器与本地工作模型，也能交换两边；当前配置要求两边来自不同 provider。这个架构说明来自项目文档，并不保证混用一定划算。
在自己的工作流里，可以把交接单缩短成五项：允许修改哪些文件、要实现什么行为、输入与输出格式、哪些事情不能动、怎样算通过。规划器输出一大段泛泛建议，本地执行器仍需自行理解需求，未必减少实际推理。相反，一个边界清楚的子任务，例如“只给价格列表增加空状态，不修改 API”，更容易验收。
建议让执行器回报改动文件、完成项、未完成项与验证证据，再交给协调器检查。别把工作模型的结论原封不动当成最终验收；委派越多，越需要避免同一文件被不同工作任务同时改写。
第一步：挑一组你真会做的任务
先选已有验收依据的小任务，而不是临时设计一个很好看的演示。可以包括一个输入校验修复、一次多文件重命名、一项页面状态处理，以及一处文档更新。数量不必很大，关键是任务里有你日常遇到的难点。
运行之前写出预期行为。例如空输入应显示什么提示、失败请求应保留哪些状态、窄屏布局允许怎样变化。对于视觉或物理效果，还要安排人工观察。能自动检查的部分自动检查，不能自动检查的部分写成具体清单；“看起来不错”无法给两个方案公平打分。
把任务、起始代码版本、依赖、提示词和验收条件保存下来。本文提出的是测量流程，读者可以按自己项目的规则选择检查方法，不必为了比较模型增加无关测试。
图 2: 先留一个云端基线，再比较分工方向；不必假定云端更适合规划。
第二步：用同一起点比较四种配置
至少保留云端单模型基线；如果条件允许，再加本地单模型以及两个方向的混合配置。每次从同一份干净副本开始，避免某个配置继承上一轮已经修好的代码。权限、最长运行时间、允许重试次数与终止条件也要一致。
本地侧记录模型文件、量化、后端版本、上下文、并发和是否已有热缓存；云端侧记录实际模型 ID、provider 和账单。不能只写“用了 Qwen”或“用了 Claude”，因为版本和配置变化会让结论失去比较意义。llama.cpp 的官方文档列有量化和 CPU/GPU 混合执行能力，具体性能仍要看你这台机器。
若资源有限，不需要四种配置全部长期运行，可以先各跑小样本，淘汰明显不能完成任务的路线。决定保留哪种之后，再对代表性任务重复运行。重复的目的不是挑出最好看的一次，而是检查结果是否稳定；把失败的运行也保留。
第三步：分别记账，别把本地写成零成本
建一张记录表，每次任务记开始与结束时间、API 金额、本地运行时长、人工介入、通过项与失败原因。云端账单是最容易获得的一项，所以常常成了唯一指标，但你的时间和返工也在消耗预算。
使用现有电脑时，设备已经买过，并不意味着每次推理都要分摊整台机器的价格；为混合工作流专门购机，则应该把设备与维护纳入计划。这两类成本口径分开写。电力可以记录实测用电，也可以先留空，不能凭感觉填一个很小的数字让方案显得划算。
可以先看“每个通过任务的 API 费用”，再把本地运行、人工复核与重试加进去。若没有任何任务通过，平均成功成本没有定义，不能写成零。原帖里的“正确场景”只是该案例的局部指标，不能按五个独立交付任务来计算普遍成功率。
图 3: 这是一套核算框架；人工时间如何计价由团队自己决定。
第四步：设置停止规则，避免低价模型无限返工
混合工作流容易多出两种开销：重复阅读同一批文件，以及协调器把含糊任务多次交回工作模型。可以先设置几个明确限制：超过约定时间就停止；相同错误连续出现就回到人工检查；无法定位根因时改交给另一配置；没有权限的操作必须停下。
这些限制是编辑建议，不是 Atomic Agent 已提供全部对应按钮的承诺。具体产品支持哪些预算、重试或权限开关，需要检查所用版本。不要把云端 API 低价理解成可以无限试，也不要把本地的“无 token 账单”理解成可以无限占住工作电脑。
想接多名并行工作模型，还要看上下文与内存占用。并行数变多时，每个任务能得到的资源未必足够，整体完成时间也未必减少。先用一名工作模型建立基线，再看增加并行是否真的改善通过任务的吞吐。
哪些工作更适合拆出去
我们的建议是先委派边界清楚、输出容易验证的工作：按既定格式提取信息、列出文件引用、补写明确范围的文档、生成重复结构。跨模块设计、模糊需求、对生产数据的修改，应保留更严格的人工检查，不能仅因某模型便宜就扩大它的任务范围。
混用不自动等于隐私保留在本地。云端规划器若看到了私有源码、工作模型输出或错误日志，就已经接触相关信息。真的有“数据不得离开设备”的要求，需要逐条检查整条调用链，而不只是确认代码由本地模型生成。
怎么决定留下哪种配置
按质量、时间、费用这个顺序做选择。先排除不能达到基本验收的方案，再看通过任务中等待和人工介入是否可接受，最后比较实际支出。若云端单模型本来就更快、更便宜，可以保留它；若本地模型在某类重复任务稳定通过，再把这一类单独迁移。
一个可执行的起点是：本周选几项真实任务，留存四种配置中可运行的结果与失败记录，下周再决定是否扩展。暂时不换硬件、不取消关键订阅，也可以测清混合分工有没有价值。有关 agent 的应用和系统权限，可继续看 电脑操作权限指南。