分享一套我正在使用的 OpenClaw 双模型协作工作流，核心目标是：尽量省钱，同时在复杂项目上依然能做到稳定交付。
这套方案的思路很简单：
便宜模型负责执行（消耗最大、最省钱）
强模型负责规划和审核（回合更少、杠杆更高） 再用一个协调器把流程跑成闭环：执行 → 审核 → 修正，直到满足验收标准为止。
一、为什么要双模型：成本和质量的平衡
在真实项目里，“执行阶段”往往最耗 token：写文件、跑命令、反复修改、产出大量文字或结构化内容。 如果全部用强模型，会非常贵；但如果全部用便宜模型，复杂任务容易出现：
需求理解偏差、方案不稳
任务拆解不细，越做越乱
没有明确验收标准，最后难以判定“是否完成”
反复试错导致总 token 反而更多
因此我的策略是： 让便宜模型承担大部分执行，把强模型留给高杠杆环节：规划、拆解、审稿、把关、难点推理。
二、总体结构：三层父子关系（3-layer hierarchy）
我把 agent 分成三层，职责清晰，避免互相抢戏。
第一层：入口
main（MiniMax） 日常入口：简单问题、短任务、快速讨论都在这里完成。
第二层：兜底 + 调度
codex（Codex） 作为“聪明模型兜底”。当 main 遇到复杂推理、复杂设计、需要高质量文本或难点分析时，直接调用 codex。
coordinator（MiniMax） 作为“项目协调器”。当任务是多步骤、需要拆分与闭环推进的项目时，让 coordinator 来组织流程。
第三层：执行与审核分离（挂在 coordinator 下）
executor（MiniMax） 负责执行：改文件、跑命令、实现功能、产出结果。
smart（Codex） 负责规划与审核：拆任务卡、写验收标准、review 产出并给出修改清单。
这套分工的关键点是： executor 不负责“判断自己做得对不对”，smart 才是把关的人。
三、沟通方式：给 coordinator 单独一个群组 Session
为了把“日常对话”和“项目闭环”隔离开，我会：
给 coordinator 绑定一个单独的 group（session）（例如 Telegram group）
main 继续作为日常入口
一旦遇到复杂项目，我会直接去 coordinator 的群里发需求
这样做有两个好处：
main 的上下文不会被项目细节拖得很长
coordinator 的频道专注跑项目闭环，更稳定、更可控
四、提示词与 workspace 隔离：避免串味
我会给 coordinator / executor / smart 分别设置：
三个独立 workspace
各自独立的 http://agent.md（写入该角色的提示词）
原因很现实：多 agent 如果共享 workspace 或共享提示词，很容易出现：
executor 开始“指挥别人”，角色漂移
smart 变成“亲自下场执行”，不再做审稿
上下文/工具/文件混在一起，越跑越乱
独立 workspace + 独立 http://agent.md 能让每个角色更稳定，行为更符合预期。
五、两种使用模式：简单任务 vs 复杂项目
模式 A：简单任务（省钱、快速）
我直接跟 main（MiniMax）沟通：
能快速解决就当场解决
如果出现复杂推理或关键难点：main 直接调用 codex 处理高难部分
这种模式适合：短问答、小改动、单文件输出、简单脚本等。
模式 B：复杂项目（自动闭环交付）
当任务变成“项目”——多步骤、需要拆分、需要验收——我会在 coordinator 群里发起。
流程一般是：
我把需求发给 coordinator
coordinator 让 smart（Codex）先做规划：
需求拆解（必要时澄清）
任务卡列表（尽可能细）
文件目录/项目骨架建议
每张任务卡的验收标准
coordinator 把任务卡分派给 executor（MiniMax）执行
executor 完成后交付给 smart审核
如果不通过：smart 输出“修改清单”（越具体越好，比如文件路径/行号/命令/预期结果）
coordinator 让 executor 修正，smart 再审
循环直到所有任务卡 PASS
这就是一个标准的： 执行 → 审核 → 修正 的自动闭环。
只要任务卡拆得足够细、验收标准足够明确，这个闭环就会非常稳定。
六、为什么这套方法能省钱
总结一下成本结构：
MiniMax（便宜模型）承担“多数回合”和“执行阶段” 这些阶段 token 消耗巨大，用便宜模型最划算
Codex（强模型）只在“高杠杆节点”介入：规划、难点推理、审核把关 回合更少，但能显著提升质量、减少返工
最终效果是： 总成本下降，同时复杂项目的完成率和一致性反而更高。
七、想征求大家的建议
如果你也在用 OpenClaw 或类似多 agent 框架，我想请教大家：
你们怎么做 prompt/workspace 隔离？有没有更优雅的方式？
你们如何降低 spawn/session 的额外开销？
你们的验收标准（acceptance criteria）怎么写最有效？
有没有更好的层级/路由策略，让整个闭环更稳？
欢迎在评论区分享你们的实践。 如果反响不错，我也可以把我的 http://agent.md 模板、任务卡模板、验收标准模板整理成可复用的版本。
