Codex规划+DeepSeek执行：多模型协作省Token实战指南

AI编程的真正痛点：不是能不能写，而是烧不烧得起

B站UP主吴修在最新视频中提出了一个当下AI编程用户共同的焦虑：AI早就能写代码了，真正的瓶颈是Token消耗太快。这一观点戳中了大量重度使用者的痛处。

背景知识｜Token与成本的底层逻辑 Token是大语言模型处理文本的基本计量单位，通常一个英文单词约等于1-2个Token，中文每个字约1-2个Token。在AI编程场景中，Token消耗量极为惊人，原因在于每次对话不仅要发送用户的问题，还需要携带完整的上下文（代码文件、历史对话、系统提示等），这被称为「上下文窗口」。当项目规模增大时，单次请求就可能携带数万甚至数十万Token，而模型的回复同样计费。这也解释了为何作者仅一句「完整打包项目」就消耗了5%的月度额度——系统需要读取所有相关文件并完整理解项目结构，背后是庞大的输入Token开销。

他分享了自己的真实用量数据：为了使用公认质量较高的智谱GLM编程套餐，国内早上10点的额度基本抢不到，于是他只能花高价在海外购买MAX版本（144美元/月，20倍使用量）。即便如此，过去7天他消耗了约15亿Token，最近30天更是达到22.4亿。作为对比，智谱团队的高级版每周最多才8亿Token——用量差距一目了然。

为了补充算力，他又开通了火山引擎的Token套餐（约200元/月）。但实测下来，仅仅一句「把这个项目完整打包」就消耗了5%的额度，而项目本身只有10个文件、95K大小。第二条稍复杂的开源评估指令直接烧掉了10%。按这个速度，每5小时只能跟AI对话约10句，遇到复杂任务甚至一句话就吃掉20%~50%。

他强调，问题不在于火山引擎贵，而是高质量AI编程模型的套餐整体成本都居高不下。

核心思路：让贵的模型规划，便宜的模型干活

面对高昂的Token成本，吴修提出了一个巧妙的多模型分工方案：

Codex月费虽贵但用量尚可接受，DeepSeek价格相对便宜。既然如此，为什么不让两个模型协同工作？

他的核心思路是——Codex负责规划（Planner），DeepSeek负责执行（Worker）。由于无法承担GPT的API费用，他直接使用Codex客户端，并接入了优秀的开源客户端来运行DeepSeek。

背景知识｜多智能体协作（Multi-Agent）架构 多智能体系统（Multi-Agent System）是人工智能领域的经典研究方向，核心思想是将复杂任务分解给多个专职智能体协同完成，而非依赖单一全能体。在LLM时代，这一概念被重新激活。OpenAI、Anthropic等公司均推出了面向Agent协作的框架。Hand of Labor所采用的Planner-Worker-Reviewer三层架构，与软件工程中的「需求-开发-测试」流程高度对应，本质上是将人类工程团队的协作范式映射到AI模型分工上。这种架构的核心优势在于：不同角色可以使用不同能力和成本的模型，避免用高价模型做重复性体力活，从而在质量和成本之间取得最优平衡。

最初的做法非常原始：在Codex里提需求，手动复制粘贴给执行端，执行端输出后再复制回Codex审核。一天下来虽然没写一行代码，但「手关节都抽筋了」。于是他萌生了做一个中间程序来自动交接消息的想法。

有趣的是，他的第一个Demo是让两个Agent自己对话，跑出来的效果颇有网络段子风格——两个AI用「内存条、金条、嫁妆」的比喻互相调侃硬件配置与婚姻的关系，验证了双Agent自动交接的可行性。

Hand of Labor：从聊天工具到「本地交接实验室」

在迭代过程中，作者意识到单纯做消息传递会陷入「画蛇添足」的陷阱——历史记录、上下文管理、权限、目录浏览这些功能，Codex和执行端的CLI其实都已具备。于是他转向了一个更本质的问题：

AI编程工具之间，怎样才能像一个工程团队一样交接任务、提交证据、完成验收？

由此诞生了开源项目Hand of Labor。它的核心思想可以概括为四个词：

规划者·执行者·证据·验收

• 规划者（Planner）：理解需求、拆分任务、制定验收标准（由Codex担任）
• 执行者（Worker）：改代码、跑命令、提交测试日志（由DeepSeek担任）
• 系统：保存任务状态和证据路径
• 验收者（Reviewer）：根据证据判断通过还是继续修改

整个框架的运作逻辑清晰：用户提出任务 → Codex拆成结构化任务包 → Hand of Labor Server管理本地状态机与事件流 → Worker真正改代码跑测试生成证据 → Reviewer基于证据做QA。

你可能没注意到，它的前端界面不是聊天窗口，而是一个「过程查看器」——展示当前任务进行到哪一步、Worker做了什么、测试日志在哪、证据文件在哪、验收是否通过。完整日志保存在本地目录，页面只显示摘要和证据路径，避免信息爆炸。

安装与实战演示

作者也演示了完整的安装流程，对于国内用户特别贴心地提供了网盘备用地址：

安装步骤简述

1. 克隆Hand of Labor项目到本地
2. 进入目录，用python -m venv创建虚拟环境并安装依赖
3. 安装Skill：将Hand of Labor Skills目录下的文件复制到Codex的Skills目录
4. 运行python server.py，默认开放51514端口（可自定义）
5. 浏览器访问界面，配置DeepSeek的API Key（Codex无需配置，自动读取本地配置）

背景知识｜Skill机制与工具调用（Tool Use） 文中提到的「Skill」是Codex客户端的插件/扩展机制，本质上是预定义的指令集或工具调用模板。在现代LLM框架中，工具调用（Tool Use / Function Calling）是让模型与外部系统交互的核心机制，由OpenAI在2023年正式标准化并广泛采纳。Skill的关键价值在于「行为约束」：它告诉Planner模型不要自己动手写代码，而是将任务结构化为标准格式的任务包（包含目标、约束、验收标准、所需证据），再交由Worker执行。这种约束避免了Planner越权操作，维持了职责隔离的架构纯洁性，是整个多模型协作体系能够稳定运转的基础。

作者提到还可选配视觉模型——当需要AI判断输出物质量时（如PPT排版、前端页面的颜色与布局是否正确），视觉模型能派上用场；纯后端开发则可以不配。

实测：贪吃蛇游戏

演示任务是「在页面上增加一个贪吃蛇游戏」。可以看到左边的Codex疯狂输出规划，右边的DeepSeek疯狂写代码，写完交给Codex审核，Codex再反馈让DeepSeek继续改进，最终验收通过，游戏可正常运行。

Skill的关键作用在于：让Codex不去自己写代码，而是把任务整理成结构化任务包，明确「改什么、不能改什么、怎么验收、需要什么证据」，然后交给Worker落地执行。

设计哲学：三大核心原则

作者总结了Hand of Labor目前最看重的三个设计原则，也是其精髓所在：

1. 职责隔离

Planner就是Planner，Worker就是Worker，Reviewer就是Reviewer。作者一针见血地指出：「一个团队里如果所有人都在开会没人写代码，那不叫智能体协作，那叫年终总结会。」

2. 证据优先

Reviewer不听模型的自我声明，只看Test Log、Build Report、真实文件改动。

背景知识｜AI幻觉（Hallucination）与证据机制 AI幻觉是指大语言模型生成看似合理但实际错误或虚构内容的现象，在代码生成场景中尤为危险——模型可能声称某个函数调用成功、测试已通过，而实际上代码根本无法运行。这种「自信的错误」比明显的错误更难发现，因为它绕过了开发者的直觉警惕。学术界将这类现象称为「过度自信校准」（Overconfident Calibration）。Hand of Labor的「证据优先」原则正是针对这一痛点的工程化解法：Reviewer不接受模型的自我声明，只认Test Log、Build Report和真实文件diff。这与软件工程中的「可验证性」原则一脉相承——代码正确性必须由客观测试结果证明，而非由实现者自评。

作者形容AI编程最怕的不是它不会写，而是「它写得很自信，自信到你都不好意思怀疑它」——证据机制正是为了对抗这种「自信的幻觉」。

3. 本地可观察

Hand of Labor默认跑在本机，运行状态和证据都保存在本地目录，QA Reviewer只展示关键过程。想看摘要看页面，想深挖看本地文件，数据完全自主可控。

背景知识｜本地优先（Local-First）与数据主权 Hand of Labor默认运行在本地（localhost:51514），这一设计选择有多重考量。其一是数据安全：企业或个人开发者的代码往往涉及商业机密，上传至第三方云端存在泄露风险，尤其在某些国家和地区受到合规法规的严格约束；其二是延迟与成本：本地状态机无需网络往返，任务调度响应更快；其三是可审计性：所有任务状态、证据文件、执行日志均保存在本地目录，开发者可随时回溯任何历史节点。这与近年来兴起的「本地优先」（Local-First）软件理念高度契合——数据应由用户自主掌控，云端只是可选的同步层，而非必须的中央节点。

结语：模型各司其职，人类最后拍板

作者坦言，做这个项目并非为了证明哪个模型更强，而是要传递一个理念：

模型各有所长，关键是放在合适的位置——合适的规划、合适的执行、合适的验收，而人类适合最后拍板，以及在AI离谱时及时拔电源。

从成本收益看，效果相当明显：以前Codex半小时就能跑完5小时的用量，现在5小时内大部分Token由更便宜的DeepSeek消耗，最基础的套餐就够用了，同时代码的输出质量和数量都比原来更高。

对于同样为AI编程Token用量焦虑的开发者，这套「规划-执行-证据-验收」的多模型协作流程，提供了一个值得深入尝试的降本思路。项目已开源，仓库名为Hand of Labor。

核心要点