最大化发挥 GPT Plus 账号价值：让主控 agent 学会拆解和回收任务（上）

本次试验的真正主旨，不是“把 DeepSeek 接进 Codex”。

更准确地说，试验要解决的是一个长期使用 GPT Plus 时绕不开的问题：怎样最大化发挥 Plus 账号里高阶 GPT 模型的价值。

高阶 GPT 模型最应该应用的地方，是理解长期目标，维持项目上下文，拆解任务，判断风险，决定一个候选结果能不能进入主线。

如果让它包办所有执行细节，额度很快会被消耗在“体力活”上。

因此，本次采用了一个多 agent 试验方案：让 Codex 继续作为主控 agent，把一部分力所能及的任务派发给另一个 Codex 执行 agent。这个执行 agent 仍然运行在 Codex 框架里，只是通过 Codex 的 --provider 机制，把底层模型切到 DeepSeek。任务过程和结果再被完整回收回来，由主控判断是否采纳。

这里的 token 使用平衡，不是让便宜模型替代主控，而是让主控模型把 token 用在最有判断价值的位置。

Plus 账号价值不等于让 GPT 做所有事

简单直接的做法是把一个完整任务交给主控 agent：

• 读代码。
• 理解需求。
• 写修改。
• 跑检查。
• 失败后重试。
• 整理结果。
• 再判断是否可交付。

这条链路能跑通，但它有一个问题：不同步骤对高阶模型的依赖程度并不一样。

有些步骤确实需要高阶主控模型，例如：

• 判断用户真正要解决的问题。
• 决定任务能不能拆。
• 识别哪些文件不能碰。
• 判断外部模型的 patch 是否可信。
• 决定是否继续、拒绝、重派或 apply。

但也有很多步骤更像执行工作：

• 在指定文件里做局部改写。
• 根据明确清单补文案。
• 运行或解释固定验证命令。
• 对候选 patch 做第一轮机械检查。
• 把执行结果写成结构化报告。

如果这些执行工作也都由 Plus 额度里的主控模型完成，成本结构就不合理。

更合理的分工是：

GPT Plus / Codex 主控
  用在任务拆解、边界判断、风险识别、最终审查。

Codex 执行 agent（DeepSeek provider）
  用在边界明确、低风险、可回收的实现或检查任务。

未来的本地小模型
  用在更模板化、更高频、更低风险的预处理和验证工作，专属能力提供更加精准、快速的处理。

这里的关键不是“谁更便宜”，而是“谁适合承担哪一类 token 消耗”。

主控 agent 要学会两件事

引入第三方 provider 以后，主控 agent 不能只是把一句“做一下修改”转发出去。

它至少要学会两件事。

第一，合理拆解任务。

一个可派发的子任务，必须有清楚的输入、允许路径、禁止动作和验证方式。比如“根据某个 review 结论，只修改 index.html 和 README.md，不提交、不推送、不引入依赖，完成第一阶段教学适配”，这就比“优化一下小游戏”更适合交给外部模型。

第二，稳定回收任务。

外部模型完成任务后，主控不能只读它最后一句“已完成”。主控需要读取 artifact：

final-message.md
events.jsonl
stderr.log
git-status.txt
diff-stat.txt
changes.patch

这些产物让主控可以检查：它到底做了什么，有没有报错，改了哪些文件，patch 是否干净，验证是否可信。

没有回收能力，任务派发只是外包；有回收能力，任务派发才变成主控体系里的一个可审查环节。

子任务的底线：边界清晰、结果可控

DeepSeek 作为 Codex 底层 provider 能不能接入，不取决于它能不能一次写对。

更关键的问题是：它写错时，错误能不能被隔离、被发现、被拒绝。

所以子任务执行的底线不是“模型足够聪明”，而是：

• 交付边界清晰。
• 结果回收可控。
• 修改范围可检查。
• 失败产物可保留。
• apply 必须经过主控确认。

因此，修改型任务默认放进 worktree 隔离里。外部模型不直接改主工作区，而是在隔离目录里生成候选 patch。主控读取 patch、日志和状态后，再决定是否应用。

在这个结构里，DeepSeek 不是被信任为主控；它只是 Codex 子任务 agent 使用的底层模型，被允许在一个明确边界内尝试。

它可以失败，但失败不能直接污染主项目。

AGENTS.md 是控制能力的一部分

本次试验暴露了一个很容易被忽略的问题：子任务能不能稳定执行，不只取决于 prompt，也取决于它读到的项目约束文档。

如果一个 AGENTS.md 同时写给主控 agent 和子任务 agent，就会出现身份混杂：

• 主控 agent 需要知道如何派发任务、读取 artifact、做最终裁决。
• 子任务 agent 只需要知道自己这次是实现任务还是验收任务，以及自己不能做什么。

这两类说明混在一起，子任务就可能误以为自己也要做调度和裁决；主控又可能把子任务的执行规则当成自己的流程。

因此，当使用模型修改这类文档时，必须坚持一个原则：身份定位要清晰。

主控可见的 AGENTS，要增强主控的拆解、派发、回收和裁决能力。

子任务可见的 AGENTS，要约束子任务在指定角色内完成交付，不越界、不提交、不推送、不把运行时报告写进业务目录。

这件事看起来是文档治理，实际会直接反馈到第一条：主 agent 能不能合理、稳定地拆解和回收任务。

为什么要拆成“执行”和“验收”两阶段

后续流程将任务拆成两个阶段：

执行任务
  生成候选 patch，不 apply，不提交。

验收任务
  读取候选产物，检查范围、语法、需求满足度和风险，不修改源码。

这样做不只是为了当前这次试验更稳。它有两个更重要的作用。

第一，它为后续使用不同模型验收留下通路。

如果同一个模型既负责实现，又负责验收，它很容易顺着自己的实现思路证明自己是对的。哪怕不是故意，也会有同质化判断的问题。

本次尚未真正引入另一个模型做验收，但流程上已经预留了位置：以后可以让 Codex + DeepSeek provider 做执行，让另一个 provider 或本地规则检查器做验收；也可以让本地小模型先做机械检查，再让 GPT 主控做最终判断。

第二，验收一旦被拆成独立模块，就可以持续迭代自己的经验，而不影响执行环节。

这和软件工程里的隔离思路类似：执行模块负责产出候选，验收模块负责积累检查规则。今天发现 patch 污染，就把文件头检查加入验收；明天发现脚本语法漏判，就把内联脚本解析加入验收；后天发现 AGENTS 身份混杂，就把角色检查加入验收清单。验收模块可以这样持续增强，但执行模块仍然保持“按边界生成候选”的职责。

所以“执行/验收”拆分，不只是为了让主控体系不被单一模型的判断闭环绑住，也是为了让验收规则形成一个可独立演化的循环。

试验结果：节约的到底是什么

在 2026-07-26 的一次录屏记录中，这套“Codex 主控 + cc-task 派发 Codex 子任务 + DeepSeek provider”的方式，围绕一个自然拼读小游戏完成了从分析、派发、验收、拒绝错误候选、重新收敛、整理项目规则到提交文档约束的完整升级链路。

实验观察结果是：主控模型大约消耗 Plus 周额度的 1%-2%，就能完成一个小工具的升级闭环。

这次节约的不是“所有 token”。

真正节约的是高阶主控模型在执行细节上的消耗：

• 少让主控反复读长文件。
• 少让主控在 patch 失败里来回试错。
• 少让主控承担所有日志整理。
• 少让主控把每个低风险检查都亲自做完。

但没有被节约、也不应该被节约的是主控判断：

• 任务该不该派发。
• 边界有没有写清楚。
• 子任务有没有越界。
• patch 能不能 apply。
• 失败样本要沉淀成什么规则。

这说明需要最大化的不是“模型调用次数”，而是 GPT Plus 账号里高阶模型的判断价值。

和预期的差距

这次试验也没有达到理想状态。

原始预期是外部模型能稳定完成边界明确的小任务，但实际过程中仍然暴露了几个问题：

• 实现候选出现过 JavaScript 语法错误。
• patch 曾经混入运行时产物。
• 验收任务曾经漏掉阻塞问题。
• 子任务 AGENTS 一开始存在身份混杂。
• 只靠 git diff --check 这样的验证不够。

这些问题说明，低成本接入阶段不能因为子任务仍运行在 Codex 框架里，就把第三方 provider 当成可信执行后端。它更适合被定义为“受控执行 agent”：可以尝试，可以产出候选，但不能绕过主控审查。

这和预期有差距，但不是坏事。差距本身说明了下一步该优化什么。

下一步探索方向

后续可以沿着三个方向继续试验。

第一，让执行任务和验收任务真正使用不同模型，观察异质验收是否能减少漏判。

第二，把一些机械验收固化成 runtime 门禁，例如 patch 文件头检查、允许路径检查、内联脚本语法检查，而不是只依赖模型自述。

第三，为本地小模型预留位置。它不需要一开始就能改复杂代码，可以先做 diff 摘要、格式检查、文案初筛、低风险报告生成。

如果这条通路稳定下来，GPT Plus 主控模型就不必被迫承担所有执行 token。它可以把主要额度留给真正有价值的判断。

这才是最大化发挥 GPT Plus 账号价值的关键。

下一篇将以 Phonics Quest 这次升级为例，具体复盘一次子任务如何执行、如何失败、如何被验收拦住，以及 AGENTS 身份定位为什么会成为多 agent 控制能力的一部分。