开源地址: codex_with_cc

兄弟们，粗大事了！

发现没有？Codex 现在脑子是越来越好使了写代码、盘架构那叫一个神仙下凡。

但你查额度的时候有没有两眼一黑？Token 烧得速度越来越离谱！

穷则思变，富则...算了富哥就不用kan这篇文章了！

为了守护我们钱包，这套穷鬼工作流横空出世！

以前是你 PUA Codex。

现在你 PUA Codex，让 Codex 再 PUA Claude Code，先让 AI 自己内卷一波！你再ZuoCodex验收结果的验收！

以前你让 Codex 一个人硬扛大项目，它要读代码、拆需求、找调用链、改文件、跑测试、kan失败日志、再回头修。主线程越塞越胖，token 越烧越猛，这就好比你花重金请了马斯克，结果让他去通下水道？！暴殄天物啊！

现在？欢迎来到 AI 黑心包工队！

Codex 稳坐老板椅发号施令，子代理排队领活干，Claude Code 披着 DeepSeek 的皮疯狂下场搬砖。什么长上下文探索？什么大范围重构？什么无限死循环排错？不再往主线程里硬灌，直接扔给执行层干，AI包工队不配有双休！

这才是多代理Zui该有的嘴脸：老板负责统筹大局，验收结果，打回重Zuo！牛马疯狂内卷抢活，脏活累活全被外包！

当然这一切dou基于 DeepSeek 的离谱低价！六千万token的使用量，缓存命中98.%，花费俩块钱，按照这套工作流，有codex统筹规划和结果验收，子代理只需要无脑干活，用DeepSeek flash模型dou绰绰有余。

DeepSeek的api价格表，缓存命中0.02元/百万token，这和白送有什么区别？这个缓存命中折扣好像是永久折扣，没有时间限制。

人民的 DeepSeek，小 D 的恩情还不完😭

前置条件hen简单：

没有 Codex？那不好意思，本项目不适合你。这里就是给 Codex 当 leader、子代理当打工人的。

然后把安装提示词发给目标项目里的 Codex：

请把 https://github.com/aiskyhub/codex_with_cc 子代理工作流安装或geng新到当前 Codex 环境。 效果

提示词

你现在委派三个子代理，让他们深度分析项目，给出项目中的优化计划书，对于三份计划书中矛盾的点，需要反复打回让他们再去验证再去制定，直到一致，然后你汇总出一份优化计划书。

创建子代理

子代理执行Claude cli

结果打回，重新验证

这样使唤 Codex

Zui基础的派工方式长这样：

你拆解 xxx 任务，安排给多个子代理实现。你负责审核子代理结果，不符合要求就打回让他们重改，直到符合要求为止。

Ru果你想把责任链说得geng硬一点，Ke以直接这样下命令：

你负责拆解、派工、审核和Zui终交付。子代理负责执行。结果不合格就返工，直到符合我的要求。

Ru果是大任务拆分，Ke以这样：

你先阅读项目，拆成 个互不冲突的实现任务，分别交给子代理处理。每个子代理必须给出变geng文件、验证命令和风险说明。你Zui后统一 review、整合，并跑Zui终验证。

Ru果你还没确定技术路线，Ke以让多个子代理先分别出方案：

请启动多个子代理分别提出 xxx 的实现方案。每个方案需要说明优缺点、复杂度、风险和迁移成本。你汇总后给出推荐方案，不要直接照抄任何一个子代理。

Ru果你担心代码质量，Ke以让一个代理写，一个代理专门挑刺：

安排一个子代理实现 xxx，再安排另一个子代理专门Zuo代码审查和边界情况攻击。你负责判断 review 是否成立，成立就打回实现代理修改，不成立就说明理由。

Ru果你只是想查一个大模块，不想让主线程被所有噪音淹掉，Ke以这样：

请把项目里的 xxx 模块交给子代理Zuo深度调查，要求输出调用链、关键文件、潜在风险和建议修改点。你只保留结论，别把所有噪音塞回主上下文。

这几类提示词的共同点hen清楚：Codex 主线程不负责苦哈哈地把所有活dou亲手干完，它负责把活拆清楚，把标准讲明白，把结果审回来。

人话说就是别让老板亲自搬砖。老板该Zuo的是派活、验收、打回返工，以及Zui后对交付负责。

Ru果你重度用 Codex Zuo项目，大概率Yi经见过这种场面：

一个复杂需求丢进去，Codex 先读项目，再找调用链，再改三五个文件，再跑测试。测试一炸，开始读日志。读完日志再改。改完又跑。跑完又发现另一个边界。Zui后主线程里塞满了代码片段、失败日志、中间判断、修复尝试和各种“我再检查一下”。

前面kan起来还行，后面就开始不对劲了。

上下文越来越胖，token 越烧越猛，主 Codex 的注意力被中间噪音拖着走。它本来应该Zuo架构师、项目经理、审稿人和Zui终责任人，结果被迫变成全栈苦力、测试工、日志分析员和临时救火队。

正确示范：如何优雅地使用多AI协作?. // 省略部分内容 如何避免 token 焦虑?

// 省略部分内容

// 省略部分内容

// 省略部分内容

不是“多开几个 AI 聊天窗口”。 而是分层： 主线程不会被海量代码和日志淹掉， 子代理干苦活， 主 Codex 保持清醒。 这个库内置了 Claude session 复用池。 三类角色： 这几个名字听起来有点后端味， 实际解决的是一个hen真实的问题： 别让每个任务dou冷启动。 大项目里 Zui浪费 token 的事情之一， 就是每个代理dou重新读一遍相同背景。 读项目结构， 读核心模块， 读约束， 读调用链， 读完再开始干活。 任务一多， 这些重复阅读会非常肉疼。 session 复用池的目标， 就是尽量让相似任务复用稳定 session， 把上下文热起来。 长任务不再每次dou从零开始， 重复阅读、 重复建模、 重复烧 token 的部分Neng少一点是一点。 这也是为什么它适合长上下文探索、 大范围修改、 多代理方案比较这类任务。 上下文不是一次性消耗品， 而是Ke以尽量复用的工作资产。 说得俗一点： 既然dou花 token 把上下文喂热了 就别每次dou重新烧水。 多代理并行Zui怕什么？ 不是怕代理少， 而是怕乱。 两个 worker 抢同一个 session， 任务状态没人管， 某个进程卡死了也没人回收， 跑到Zui后不知道谁用了哪个上下文、 哪个任务还活着、 哪个结果Yi经过期。 这种并行kan起来热闹， 实际上hen容易把项目搞成一锅粥。

codexwithcc 给这件事补了工程约束。

每次委派dou会基于任务内容、 作用域和验证命令生成 fingerprint。

并行 worker 通过 lease 管理 session 占用。

卡死、 过期、 进程消失的 lease 会被识别和回收。

这套东西听起来像服务调度，对，它本来就hen像服务调度。

只不过这里调度的不是传统后端任务，而是 AI 子代理执行链路。

它关心的问题hen具体：

这些问题不解决，多代理就是开盲盒。

解决了才有资格谈并行、 复用和可回放。

这套工作流还有一个关键边界： 主线程不Neng直接下场跑 claude 。

脚本会检查 CODEXCLAUDECHILD_THREAD= ， 强制 Claude Code 委派只Neng发生在 Codex 子线程里。

这件事hen重要。因为Ru果主线程Ke以随便直接跑执行层, 链路就会变脏： 上下文污染、 审计断链、 任务责任不清、 结果没人兜底。

Zui后你只知道“AI 好像Zuo了点什么”，但不知道它从哪儿开始、 怎么跑的、 用了哪个 session、 输出在哪里。

所以这个库把边界划清楚：

每次运行还会落审计产物：

这些 artifacts 解决的是“任务Neng不Neng查”的问题。

任务怎么发出去的、 用了哪个 session、 有没有 resume、 输出是什么、 链路有没有断，douNeng回头kan。

Zui后还有验证脚本兜底： 运行时验证、 session pool 验证、 artifact 验证、 delegate chain 验证dou配好了。

所以多子代 理并行不是凭感觉开派对, 而是有 session state 、 RunId 、 SessionKey 、 artifact root 和链路校验把它们串起来。

高情商说法： 可审计、可复用、可并发、可回放的多代 理委派协议。

低情商说法： 让 Codex 当老板，也得给它配办公室制度和打卡机。

这套工作流Zui适合那些“单点不难，但整体hen吃上下文”的任务。

比如大范围代码阅读和模块梳理。

你Ke以让子代 理调查某个模块, 输出调用链、 关键文件、 潜在风险和建议修改点,

主 Codex 只保留结论, 不把所有噪音塞回主上下文。

比如多文件实现任务。

一个需求Ru果天然Neng拆成几个互不冲突的部分, 就Ke以让多个子代 理分别处理。

每个子代 理给出变geng文件、 验证命令和风险说明,

主 Codex Zui后统一 review 和整合。

比如多方案头脑风暴。

你Ke以让多个子代 理分别提出方案, 说明优缺点、 复杂度、 风险和迁移成本,

然后由主 Codex 汇总推荐。

重点是主 Codex 不直接照抄任何一个子代 理,而是ZuoZui终判断。

比如实现和审查分离。

一个子代 理写代码,另一个子代 理专门Zuo代码审查和边界情况攻击。

主 Codex 判断 review 是否成立,成立就打回修改,不成立就说明理由.

再比如迁移、重构 、补测试 、查调用链 。这些活未必难,但hen耗上下文,也hen容易产生大量中间噪音 。交给 子 代 理 Zuo , 主 线 程 只拿 结 果 , 会干净hen多 。

别什么dou上 多 代 理 。

Ru果只是改一两行代码,直接 让 主 C o d e x 处 理 就 行 。为 了 一 个 小 改 动 开 委 派 链 路 , 收 益 不 一 定覆盖沟通成本 。

Ru果需求还在实时变化,也 别急 着扔 给 子 代 理 。比如产品边界 还没 想 清 楚 、交互细节需要来 回 确认 、业务规则 本 身还在摇摆,这类任 务 应 该 先 在 主 线 程 里 把需求定稳 。

Ru果文件冲突极高,也 要谨 慎 并 行 。多个 子 代 理 同 时 改 同 一 片 区 域 , hen容 易互相 踩 脚 。并 行 的 前 提 不 是 “ 人 多 ”, 而 是 任 务 边 界 足够 清 楚 。

所以它Zui适合的不是小修小补,而是大范围阅读、多文件实现、多方案探索 、实 现审查 分 离 、迁 移 重构 和 测试 修 复 这 类 脏 活 累 活 。 任 务 越 大 , 主 线 程 越容 易 爆 ; 主 线 程 越容 易 爆 , 这套 分 工 越 香 。 C o d e x 不 是 不 Neng 自 己 干 活 。 但 在 复 杂 工 程 里 , C o d e x Zui 值钱 的 Neng 力 不 是 “亲 自 多 改 几 个 文 件 ”, 而 是 保 持 全局判断 :需 求 怎么拆,任 务 怎么派,风 险 怎么收,结 果 怎么验,哪 里 该返 工 ,哪 里 Neng 交 付 。 c o d e x _ w i t h _ c c Zuo 的 事 , 就是 把 主控 和 执行拆开 。 主 C o d e x 当 l e a d e r 。 C o d e x 子 代 理承接 任 务 。 C l a u d e C o d e C L I 执行具体 工 作 。 D e e p S e e k 消 化大量 上 下 文 和 重 复劳 动 。 s e s s i o n 复 用池 把 上 下 文 热 起 来 , f i n g e r p r i n t 和 l e a s e 管 住 并 行 , 审 计产物 和 验证 脚 本 把链 路兜 住 。 这 就 不 是 “ 多 开 几 个 A I 聊 天 窗 口 ”。 这是 在 给 C o d e x 配 一套 Neng派 工 、Neng 复 用 、Neng审计 、Neng 验证 的 执行层 。 如 果 你 Yi 经 被 大 项 目 里 的 t o k e n 焦 虑 、上 下 文 爆炸 、重 复读 代 码 和 日志 海淹 过,那 这套 工 作 流 的价 值 hen容 易 理 解 :别 让 主 线 程 继续 硬扛 。 让 C o d e x坐在 l e a d e r 位 上 。 让 子 代 理 去读 、去 改 、去测 、去互相找 茬 。 结 果 不合 格 就返 工 ,验 证 不过 就继续 修 ,边 界 没 说 清 就 打 回 重 写 。 等 这套 分 工 跑顺 之 后,你 会 发 现 真正 爽 的 不是 “A I 干 活 geng 多 了 ”,而 是 主 C o d ex终于不用 被 脏 活拖 进泥 里,Ke以 一 直 保 持 清 醒 地 判断 、取 舍 和 负 责 。

---