Sol 指挥 Luna 干活:Codex 里的甲方乙方分工术

Sol 指挥 Luna 干活:Codex 里的甲方乙方分工术

在Codex里用Sol拆任务审代码、Luna负责具体实现,用甲方乙方分工模式省下80%额度,同时保住86%的智能水平。

发布于 2026/08/03
16 分钟阅读
0 次阅读

故事是这样的。

前两天我在 Codex 里跑一个中型项目重构,Sol 开着 high reasoning,干了大概四十分钟,回来一看,周额度从 100% 掉到了 69%。

我当时的反应是,等等,什么??

翻了一下 session 日志才搞明白,Sol 自己拆了七八个子任务,每个子任务它又 spawn 了一个子代理来执行。问题是,这些子代理全部继承了父线程的模型和 reasoning 等级。也就是说,七八个 Sol High 在后台同时烧钱,干的却是「改个变量名」「跑个 lint」这种活。

这就好比你让总监亲自去复印文件,还开着奔驰去的。

不是我一个人遇到这个问题。GitHub 上 OpenAI Codex 仓库的 Issue #31814 标题直接就是「GPT-5.6 Sol cannot specify subagent models, forcing all subagents to also be Sol instances」,评论区有人更惨,说 Sol 递归 spawn 子代理,20 分钟烧了十亿 token。

所以当我看到阿易分享的那个玩法,让 Sol 在配置文件里创建一个 Luna 子代理,Sol 负责拆任务和审代码,具体实现全部委托给 Luna Max,我第一反应是,这不就是互联网公司的甲方乙方吗。

甲方想清楚要什么,乙方埋头把活干了。

而且这个「乙方」,干活水平其实已经很强了。

我来解释一下为什么。

GPT-5.6 家族有三个模型,Sol、Terra、Luna,分别对应旗舰、均衡、轻量。7 月 30 号 OpenAI 降价之后,Luna 的定价是每百万输入 token 0.2 美元,输出 1.2 美元。Sol 是 5 美元和 30 美元。Luna 的价格是 Sol 的二十五分之一。

但有趣的是性能差距远没有价格差距大。

有人做了很细致的对比测试,Luna 搭配 max reasoning effort(社区叫它「Luna Max」),在 Artificial Analysis 的智能指数上拿到 51 分。Sol Max 是 59 分。8 分的差距,价格差了接近 5 倍。

换一个更直观的说法,Luna Max 用 Sol 大约 20% 的成本,买到了 Sol 大约 86% 的智能水平

这个比例让我想起了一个经济学里的老概念,帕累托效率。你花前 20% 的钱能解决 80% 的问题,剩下 80% 的预算都在为那最后 20% 的提升买单。大多数日常编码任务,写个函数、改个 bug、跑个测试,根本不需要那最后 20% 的智能。

所以真正聪明的用法不是「用最贵的模型干所有事」,而是「用最贵的模型想清楚要干什么,然后让便宜的模型去执行」。

这就是 Codex 里的「甲方乙方」。

顺着这个思路再聊聊具体怎么操作。

Codex 官方文档里其实已经写了子代理的配置方式。你在 ~/.codex/agents/ 目录下放一个 TOML 文件,定义 name、model、reasoning effort 和 developer instructions 就行。比如这样

name = "luna-worker"
description = "Luna agent for bounded implementation tasks"
model = "gpt-5.6-luna"
model_reasoning_effort = "max"

developer_instructions = """
Handle only the bounded task delegated by the parent agent.
Work independently, keep the scope narrow, and return a concise summary.
Do not delegate further work unless explicitly asked.
"""

理论上,Sol 就能把具体的实现任务委托给这个 Luna 子代理,自己只负责拆解、审核和最终整合。

但坦率的讲,我自己试的时候踩了坑。

GPT-5.6 发布后,Multi-Agent V2 默认把 hide_spawn_agent_metadata 设成了 true,结果就是 Sol 的 spawn_agent 接口里根本看不到 model 和 reasoning_effort 这两个字段。你让 Sol 用 Luna 子代理,它会很诚实地告诉你「当前 API 没有暴露模型选择器」,然后继续用自己的配置 spawn。

这个 bug 到现在为止 GitHub 上有至少五六个相关 Issue,社区也给出了一个 workaround,在 config.toml 里加

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

但即便加了这个配置,有些版本的 Codex 还是会报一个 reserved-schema 错误。Luna 甚至一度不在 spawn_agent 的可选模型列表里,因为 Luna 被标记为 Multi-Agent V1,而 Sol 和 Terra 是 V2,版本不兼容导致直接拒绝。

所以社区发明了一个更野的路子。

不走 spawn_agent 的官方接口,而是直接在 Sol 的 instructions 里写清楚分工策略。你在 AGENTS.md 或者系统 prompt 里告诉 Sol,对于所有实现类任务,创建一个 luna-worker.toml 配置文件,然后按 bounded task 的方式委托执行。Sol 不通过 API 级别的模型切换,而是通过「任务描述+约束」来模拟分工。

阿易分享的那个玩法本质就是这个思路。让 Sol 先在 ~/.codex/agents/ 下写好配置文件,然后在后续任务中引用这个子代理。虽然底层仍然有兼容性问题,但在 CLI 版本里(尤其是旧一点的 0.137 之前的版本或者官方修复后的新版),这条路确实能跑通。

说到这我想聊一个更大的问题。

我觉得这件事有意思的地方不在于「省钱技巧」本身。省钱当然好,但真正让我觉得值得写一篇文章来讲的,是它背后反映的一个趋势。AI 世界正在复刻人类组织的分工逻辑

你想想看,人类公司里最贵的资源是什么?是那些能做决策的人。CEO 不写代码,CTO 不亲自改 bug,产品总监不自己画原型。他们的核心价值是「想清楚要做什么」和「判断做得对不对」。具体的执行,交给成本更低但执行力够强的团队成员。

Sol 和 Luna 的关系一模一样。

Sol 的核心能力是什么?是分解复杂问题的能力、是在多种可能路径中选择最优解的能力、是审查结果发现问题的能力。这些能力需要深度推理,所以贵。

Luna 的核心能力是什么?是在明确指令下快速高质量地执行。它不需要思考「这件事应不应该做」,它只需要「把这件事做好」。这个能力在大多数场景下已经够用,所以便宜。

智能的分层,说到底就是决策和执行的分离。

这让我想起管理学里有个经典概念叫「认知分工」(cognitive division of labor),说的是组织效率的关键不在于每个人都聪明,而在于让最聪明的人只干需要最聪明才能干好的事。其他事交给「够聪明」的人就行了。

现在这个逻辑被完整地搬到了 AI agent 的世界里。

而且 DeepSeek V4 Flash 的出现让这件事变得更加极端。

DeepSeek V4 Flash 0731 的定价是每百万输入 token 0.14 美元,输出 0.28 美元。缓存命中的情况下输入只要 0.0028 美元。算下来单次任务的成本大概是 3 美分。

就。。。3 美分。

而且它在 Artificial Analysis 的智能指数上拿到 50 分,只比 GPT-5.6 Luna 低 1 分,比 Luna 还便宜 30%。

有人在推上说,DeepSeek V4 Flash 画了一条「斩杀线」。这是个游戏术语,在 MOBA 里,对手血量低于斩杀线就意味着你可以一套带走。DeepSeek V4 Flash 就是那条线,任何定价在它上面但智能水平差不多的模型,都需要解释「你凭什么贵」。

那结果就是,「乙方」的成本正在趋近于零。

回到 Codex 这个语境里想想。如果未来 Sol 可以丝滑地指挥 DeepSeek V4 Flash 级别的模型当子代理,那一个复杂项目的重构可能长这样

Sol 花 5 分钟分析代码库结构,拆出 20 个独立的重构任务。每个任务委托给一个 3 美分的子代理。20 个子代理并行执行,5 分钟全部完成。Sol 再花 2 分钟审核所有结果,merge 有问题的打回重做。

总成本?Sol 的分析+审核大概 1 美元,20 个子代理大概 60 美分。不到 2 美元完成整个重构。如果全部用 Sol 自己干,可能要 15-20 美元,而且不能并行,得一个个串行执行。

便宜了 10 倍,还快了 4 倍。

当然,现在要实现这个理想状态还有很多坑。

第一个坑是我前面说的 Multi-Agent V2 的兼容性问题,spawn_agent 接口目前不太好用。第二个坑是跨厂商调度,Sol 是 OpenAI 的,DeepSeek 是 DeepSeek 的,你没法在 Codex 原生环境里让 Sol 直接调度 DeepSeek。第三个坑是上下文传递,子代理拿到的是一个 bounded task 描述,但有时候执行需要更多上下文,父代理需要决定传多少信息过去,传多了浪费 token,传少了子代理做不对。

但方向是清晰的。

我自己现在的日常工作流大概是这样的。

需要架构设计、大范围重构方案、复杂 debug 的时候,用 Sol High 或 Sol Max。它来想清楚「怎么做」。

具体的实现,改函数、写测试、调格式、跑 migration,交给 Luna Max 或者 Terra Medium。它们来「把事做完」。

如果是不需要太多推理的批量任务,比如给 50 个文件加 lint 规则、批量改导入路径,直接开 Luna Low 甚至 DeepSeek,反正就是机械执行。

这套分层下来,我的周额度从以前经常撞线变成了基本用到周末还剩 30%-40%。

说到底,这是一个思维方式的转变。

以前我们用 AI 的默认心态是「给最好的模型,让它全权处理」。就像创业公司早期只有三个人的时候,CTO 既写架构又改 bug 又部署上线,因为没有别的选择。

但现在模型生态丰富了。Sol、Terra、Luna、DeepSeek V4 Flash、Claude Sonnet、Gemini Flash,你有了一整个「团队」可以调度。问题不再是「哪个模型最强」,而是「谁负责什么」。

最近有篇论文让我印象很深。Meta AI 提出了一个叫「记忆智能体」的东西,用一个独立的 agent 定期审查主 agent 的行为,更新结构化记忆库,决定是否给主 agent 发提醒。说到底就是给干活的 agent 配了一个「项目经理」,防止它在长任务里跑偏。

你看,AI 世界里已经出现了「项目经理」「执行者」「审核者」的角色分化。

这不就是公司吗?

可能有人觉得,这也太折腾了吧,直接用一个最强的模型不就完了。

我完全理解这种感觉。如果你是个人开发者,项目不大,预算不敏感,确实没必要搞这么复杂。Sol 一把梭,体验很好,结果也好。

但如果你是团队用,如果你每天要跑几十个 agent 任务,如果你的月账单开始让你皱眉,那「谁负责想,谁负责做」这个问题就值得认真对待了。

而且我觉得这件事还有一层更深的意义。

经济学里有个著名的杰文斯悖论。19 世纪英国经济学家杰文斯发现,蒸汽机效率越高,煤炭消耗量反而越大。因为效率提升让使用成本下降,需求反而爆发式增长。

智能定价的下降也是一样。当 Luna 和 DeepSeek 把「执行层」的成本压到几乎为零,人们不会因此少用 AI,反而会用 AI 做更多以前「不值得」让 AI 做的事。

以前你不会用 Sol 去改一个逗号。但如果有个 3 美分的子代理能干这事,你会让它把整个项目所有文件的逗号问题都扫一遍。

便宜的执行力不会减少需求,它会创造需求。

所以未来的 AI 工作流大概率不是「一个超强模型包打天下」,而是「一个思考者 + 一群执行者」的团队模式。思考者负责理解意图、拆解问题、审核结果;执行者负责快速、廉价、高质量地完成每个子任务。

这跟人类社会的组织演化路径一模一样。从单打独斗到分工协作,从全能选手到专业化团队。

只不过这次,「团队成员」的边际成本正在趋近于零。

我也不知道这最终会演化成什么样。但我觉得有一点是确定的,未来最稀缺的能力不是「执行」,而是「知道要执行什么」。无论对人还是对 AI。

以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~

谢谢你看我的文章,我们,下次再见。

评论区

欢迎留下你的看法,支持匿名评论。

你的评论会公开展示,建议填写便于交流的昵称,并尽量提供有信息量的反馈。