穷鬼工作流
兄弟们，粗大事了！
发现没有？Codex 现在脑子是越来越好使了，写代码、盘架构那叫一个神仙下凡。
但你查额度的时候有没有两眼一黑？Token 烧得速度越来越离谱！
穷则思变，富则...算了，咱是穷鬼，富哥就不用往下看了！
为了守护我们钱包，这套穷鬼工作流横空出世！
以前是你 PUA Codex。
现在你 PUA Codex，让 Codex 再 PUA Claude Code，先让 AI 自己内卷一波！你再做Codex验收结果的验收！
以前你让 Codex 一个人硬扛大项目，它要读代码、拆需求、找调用链、改文件、跑测试、看失败日志、再回头修。主线程越塞越胖，token 越烧越猛，这就好比你花重金请了马斯克，结果让他去通下水道？！暴殄天物啊！
现在？欢迎来到 AI 黑心包工队！
Codex 稳坐老板椅发号施令，子代理排队领活干，Claude Code 披着 DeepSeek 的皮疯狂下场搬砖。什么长上下文探索？什么大范围重构？什么无限死循环排错？不再往主线程里硬灌，直接扔给执行层干，AI包工队不配有双休！
这才是多代理最该有的嘴脸：老板负责统筹大局，验收结果，打回重做！牛马疯狂内卷抢活，脏活累活全被外包，最后功劳全是老板的！把这套玩明白了，你的 Codex 才能真正爽到飞起！
当然了，作为指挥Codex的你，才是真正的大资本家！
这一切都基于 DeepSeek 的离谱低价！在加上缓存命中价格百万token俩分钱！长任务、多代理、大范围代码探索，给我往死里造！反正苦力便宜，Token 成本四舍五入等于不要钱！
人民的 DeepSeek，小 D 的恩情还不完😭
<img src="https://raw.githubusercontent.com/xdd666t/MyData/master/pic/flutter/blog/20260504115715483.png" alt="ChatGPT Image 2026年5月4日 11_53_50" style="zoom: 50%;" />
一句话安装工作流
前置条件很简单：
- 安装 Claude Code。
- 安装 CC Switch。
- 在 CC Switch 里把 Claude Code 的后端 API 切到 DeepSeek。
- 准备一个你想接入这套工作流的目标项目。
- 打开 Codex。
没有 Codex？那不好意思，本项目不适合你。这里就是给 Codex 当 leader、子代理当打工人的。
然后，把安装提示词发给目标项目里的 Codex（拉取更新工作流，也是下面的提示词）：
请把 https://github.com/xdd666t/codex_with_cc 调度子线程工作流集成或更新到当前项目。
接入之后，核心心法只有一句：
让 Codex 做 leader，让子代理当大头兵。
这句话不是装酷，它决定了你后面怎么下命令，也决定了这套东西为什么能把 Codex Plus 用出另一种爽感。
你不要再对 Codex 说“帮我把这个大需求做完”，然后让它在一个主线程里从需求分析、代码阅读、方案设计、文件修改、测试失败、返工修复一路扛到底。这当然能跑，但上下文会越来越肿，日志会越来越多，主线会越来越散。
更好的姿势是：让 Codex 拆任务，让子代理执行，让 Claude Code/DeepSeek 去啃高 token 苦活，让主 Codex 审核和兜底。
效果
你现在委派三个子代理，让他们深度分析项目，给出项目中的优化计划书，对于三份计划书中矛盾的点，需要反复打回让他们再去验证再去制定，直到一致，然后你汇总出一份优化计划书。
你作为leader，能力强，需要统筹好全局，你要对你的结果负责！
这样使唤 Codex
最基础的派工方式长这样：
你拆解 xxx 任务，安排给多个子代理实现。你负责审核子代理结果，不符合要求就打回让他们重改，直到符合要求为止。
如果你想把责任链说得更硬一点，可以直接这样下命令：
你负责拆解、派工、审核和最终交付。子代理负责执行。结果不合格就返工，直到符合我的要求。
如果是大任务拆分，可以这样：
你先阅读项目，拆成 3 个互不冲突的实现任务，分别交给子代理处理。每个子代理必须给出变更文件、验证命令和风险说明。你最后统一 review、整合，并跑最终验证。
如果你还没确定技术路线，可以让多个子代理先分别出方案：
请启动多个子代理分别提出 xxx 的实现方案。每个方案需要说明优缺点、复杂度、风险和迁移成本。你汇总后给出推荐方案，不要直接照抄任何一个子代理。
如果你担心代码质量，可以让一个代理写，一个代理专门挑刺：
安排一个子代理实现 xxx，再安排另一个子代理专门做代码审查和边界情况攻击。你负责判断 review 是否成立，成立就打回实现代理修改，不成立就说明理由。
如果你只是想查一个大模块，不想让主线程被所有噪音淹掉，可以这样：
请把项目里的 xxx 模块交给子代理做深度调查，要求输出调用链、关键文件、潜在风险和建议修改点。你只保留结论，别把所有噪音塞回主上下文。
这几类提示词的共同点很清楚：Codex 主线程不负责苦哈哈地把所有活都亲手干完，它负责把活拆清楚，把标准讲明白，把结果审回来。
人话说，就是别让老板亲自搬砖。老板该做的是派活、验收、打回返工，以及最后对交付负责。
为什么这东西香
如果你重度用 Codex 做项目，大概率已经见过这种场面：
一个复杂需求丢进去，Codex 先读项目，再找调用链，再改三五个文件，再跑测试。测试一炸，开始读日志。读完日志再改。改完又跑。跑完又发现另一个边界。最后主线程里塞满了代码片段、失败日志、中间判断、修复尝试和各种“我再检查一下”。
前面看起来还行，后面就开始不对劲了。
上下文越来越胖，token 越烧越猛，主 Codex 的注意力被中间噪音拖着走。它本来应该做架构师、项目经理、审稿人和最终责任人，结果被迫变成全栈苦力、测试工、日志分析员和临时救火队。
这时候最痛的不是“AI 不够聪明”，而是聪明的主线程被脏活拖住了。你花钱买的是 Codex 的判断力，结果它一半精力在翻日志，一半精力在重复读文件，最后还要从一堆上下文碎片里把主线捞回来。
而 DeepSeek 的快乐就在这里：让它去啃那些高 token、长上下文、重复阅读的体力活。缓存命中率一旦吃起来，体感上就像给多代理协作装了省钱外挂。不是说成本从此不存在，而是那种“每多试一次方案都心疼 token”的心理压力，会明显被按下去。
最难受的是，大项目里很多工作不是“聪明”就能省掉的。
你要读陌生模块，要扫文件，要比较方案，要看失败日志，要补测试，要查边界，要做 review。这些都是必要劳动，但它们不一定都该塞进主线程。
这就是 codex_with_cc 的切入点：把高 token、高噪音、高重复的执行型任务委派出去，让主 Codex 保持清醒，让小 D 去干它最适合干的苦活。
Codex 不是不能干活，Codex 是太适合当 leader 了。让它一直埋头搬砖，反而浪费它最值钱的能力：全局判断、任务拆解、风险裁决和最终验收。
这套工作流的爽点也在这里：
- 主线程不用吞下所有代码阅读和日志噪音。
- 子代理可以承接长上下文探索、实现、审查和返工。
- Claude Code CLI 负责执行具体任务。
- DeepSeek 负责消化大量重复上下文和高 token 工作。
- Codex leader 最后统一 review，结果不行就打回重改。
你真正想要的不是“多开几个 AI 看起来很热闹”，而是让每一层都有自己的职责。
主线程保持判断力，执行层负责燃烧体力。
这不是提示词玩具
很多所谓多代理工作流，其实只是把提示词写得更像公司制度。
“你是 A 代理，你负责开发。”
“你是 B 代理，你负责审查。”
听起来很正规，落地一看，全靠 AI 自觉。没有 session 管理，没有任务指纹，没有租约，没有审计产物，没有链路约束。任务怎么发出去的、用了哪个会话、有没有复用上下文、有没有跑验证、结果从哪里来，全都糊成一团。
codex_with_cc 不是这个路子。
它做的事情更朴素，也更工程化：把一套 Codex -> Codex 子代理 -> Claude Code CLI 的委派工作流复制进任意项目，让 Codex 当 leader，Claude Code/DeepSeek 当执行层。脏活累活、长上下文探索、大范围改代码、互相找茬，都扔给子代理；主 Codex 只管拆解、调度、验收、打回重改。
这就不是“请 AI 自觉点”的玄学了，而是把多代理委派做成有状态、有产物、有边界、有验证的工作流。
真正的含金量，藏在后半段。
工作流拆解
这套链路可以写成一行：
Codex 主线程 -> Codex 子代理 -> Claude Code CLI -> Claude Code 后端模型
每一层的职责不一样。
Codex 主线程负责理解需求、拆任务、创建子代理、审核结果、打回返工和最终交付。它是 Codex leader，是架构师，也是最后背锅的人。
Codex 子代理负责作为可追踪的对话树节点，调用委派脚本，把具体实现、调查、审查这些高 token 消耗任务交给 Claude Code CLI。它不是随便开的聊天窗口，而是主线程派出去的任务节点。
Claude Code CLI 负责执行被委派的具体任务。它可以做调查、改文件、运行验证，并输出结构化报告。
如果 Claude Code 后端通过 CC Switch 接到 DeepSeek，那么大量读代码、改代码、跑验证的苦活就可以交给 DeepSeek 去消化。README 里提到的重点体验，是 DeepSeek 的缓存命中率很夸张，重复阅读、重复建模、重复烧 token 的部分能少一点是一点。
所以这个链路的本质不是“让多个模型一起聊天”，而是分层：
- Codex 主线程负责判断。
- Codex 子代理负责承接任务节点。
- Claude Code CLI 负责执行。
- DeepSeek 负责高 token 工作的消化。
主线程不会被海量代码和日志淹掉，子代理干苦活，主 Codex 保持清醒。
Claude session 复用池
这个库内置了 Claude session 复用池。
README 里提到三类角色：
PrimaryReuse：负责串行主会话续跑。PrimaryAnchor：负责并行批次的上下文锚点。ParallelPool：负责独立支线任务的会话池化。
这几个名字听起来有点后端味，实际解决的是一个很真实的问题：别让每个任务都冷启动。
大项目里，最浪费 token 的事情之一，就是每个代理都重新读一遍相同背景。读项目结构，读核心模块，读约束，读调用链，读完再开始干活。任务一多，这些重复阅读会非常肉疼。
session 复用池的目标，就是尽量让相似任务复用稳定 session，把上下文热起来。长任务不再每次都从零开始，重复阅读、重复建模、重复烧 token 的部分能少一点是一点。
这也是为什么它适合长上下文探索、大范围修改、多代理方案比较这类任务。上下文不是一次性消耗品，而是可以尽量复用的工作资产。
说得俗一点：既然都花 token 把上下文喂热了，就别每次都重新烧水。
任务指纹、租约锁和会话回收
多代理并行最怕什么？
不是怕代理少，而是怕乱。
两个 worker 抢同一个 session，任务状态没人管，某个进程卡死了也没人回收，跑到最后不知道谁用了哪个上下文、哪个任务还活着、哪个结果已经过期。这种并行看起来热闹，实际上很容易把项目搞成一锅粥。
codex_with_cc 给这件事补了工程约束。
每次委派都会基于任务内容、作用域和验证命令生成 fingerprint。并行 worker 通过 lease 管理 session 占用。卡死、过期、进程消失的 lease 会被识别和回收。
这套东西听起来像服务调度，对，它本来就很像服务调度。只不过这里调度的不是传统后端任务，而是 AI 子代理执行链路。
它关心的问题很具体：
- 这个任务是谁发起的？
- 这个任务的作用域是什么？
- 它应该跑哪些验证？
- 它占用了哪个 session？
- session 是否还活着？
- lease 是否过期？
- 结果能不能追溯？
这些问题不解决，多代理就是开盲盒。解决了，才有资格谈并行、复用和可回放。
链路约束、审计产物和验证脚本
这套工作流还有一个关键边界：主线程不能直接下场跑 claude。
脚本会检查 CODEX_CLAUDE_CHILD_THREAD=1，强制 Claude Code 委派只能发生在 Codex 子线程里。
这件事很重要。因为如果主线程可以随便直接跑执行层，链路就会变脏：上下文污染、审计断链、任务责任不清、结果没人兜底。最后你只知道“AI 好像做了点什么”，但不知道它从哪儿开始、怎么跑的、用了哪个 session、输出在哪里。
所以这个库把边界划清楚：
- 主 Codex 负责规划、派工、review、返工裁决。
- Codex 子代理才是执行层入口。
- Claude Code CLI 执行具体任务。
- 最终仍由主 Codex 审核和交付。
每次运行还会落审计产物：
config_<RunId>.jsonstatus_<RunId>.jsonprompt_<RunId>.mdstream_<RunId>.jsonltrace_<RunId>.logclaude_<RunId>.md
这些 artifacts 解决的是“任务能不能查”的问题。任务怎么发出去的、用了哪个 session、有没有 resume、输出是什么、链路有没有断，都能回头看。
最后还有验证脚本兜底：运行时验证、session pool 验证、artifact 验证、delegate chain 验证都配好了。
所以，多子代理并行不是凭感觉开派对，而是有 session state、RunId、SessionKey、artifact root 和链路校验把它们串起来。
高情商说法：可审计、可复用、可并发、可回放的多代理委派协议。
低情商说法：让 Codex 当老板，也得给它配办公室制度和打卡机。
适合什么场景
这套工作流最适合那些“单点不难，但整体很吃上下文”的任务。
比如大范围代码阅读和模块梳理。你可以让子代理调查某个模块，输出调用链、关键文件、潜在风险和建议修改点，主 Codex 只保留结论，不把所有噪音塞回主上下文。
比如多文件实现任务。一个需求如果天然能拆成几个互不冲突的部分，就可以让多个子代理分别处理。每个子代理给出变更文件、验证命令和风险说明，主 Codex 最后统一 review 和整合。
比如多方案头脑风暴。你可以让多个子代理分别提出方案，说明优缺点、复杂度、风险和迁移成本，然后由主 Codex 汇总推荐。重点是主 Codex 不直接照抄任何一个子代理，而是做最终判断。
比如实现和审查分离。一个子代理写代码，另一个子代理专门做代码审查和边界情况攻击。主 Codex 判断 review 是否成立，成立就打回修改，不成立就说明理由。
再比如迁移、重构、补测试、查调用链。这些活未必难，但很耗上下文，也很容易产生大量中间噪音。交给子代理做，主线程只拿结果，会干净很多。
不适合什么场景
别什么都上多代理。
如果只是改一两行代码，直接让主 Codex 处理就行。为了一个小改动开委派链路，收益不一定覆盖沟通成本。
如果需求还在实时变化，也别急着扔给子代理。比如产品边界还没想清楚、交互细节需要来回确认、业务规则本身还在摇摆，这类任务应该先在主线程里把需求定稳。
如果文件冲突极高，也要谨慎并行。多个子代理同时改同一片区域，很容易互相踩脚。并行的前提不是“人多”，而是任务边界足够清楚。
所以它最适合的不是小修小补，而是大范围阅读、多文件实现、多方案探索、实现审查分离、迁移重构和测试修复这类脏活累活。
任务越大，主线程越容易爆；主线程越容易爆，这套分工越香。
最后
Codex 不是不能自己干活。
但在复杂工程里，Codex 最值钱的能力不是“亲自多改几个文件”，而是保持全局判断：需求怎么拆，任务怎么派，风险怎么收，结果怎么验，哪里该返工，哪里能交付。
codex_with_cc 做的事，就是把主控和执行拆开。
主 Codex 当 leader。Codex 子代理承接任务。Claude Code CLI 执行具体工作。DeepSeek 消化大量上下文和重复劳动。session 复用池把上下文热起来，fingerprint 和 lease 管住并行，审计产物和验证脚本把链路兜住。
这就不是“多开几个 AI 聊天窗口”。
这是在给 Codex 配一套能派工、能复用、能审计、能验证的执行层。
如果你已经被大项目里的 token 焦虑、上下文爆炸、重复读代码和日志海淹过，那这套工作流的价值很容易理解：别让主线程继续硬扛。
让 Codex 坐在 leader 位上。
让子代理去读、去改、去测、去互相找茬。
结果不合格就返工，验证不过就继续修，边界没说清就打回重写。
等这套分工跑顺之后，你会发现真正爽的不是“AI 干活更多了”，而是主 Codex 终于不用被脏活拖进泥里，可以一直保持清醒地判断、取舍和负责。
