这个设计灵感来源于 Unix 系统的 fork() 系统调用,可以把它想象成:
-
你(主线程):正在和 Codex 进行一场深入的对话,讨论一个大型项目的重构方案。
-
Fork(分叉):你希望在不打断当前对话的情况下,让 Codex 同时去后台研究三个不同的备选方案。这时,你就可以对 Codex 说"帮我分叉出三个线程,分别去调研方案A、B、C"。于是,Codex 就从当前的对话中"fork"出了三个独立的"分身",各自去执行任务。
🤔 为什么要用 Fork,而不是让它自己处理?
这是为了应对 AI 编程助手在实际使用时面临的一个核心挑战:上下文窗口(Context Window)有限。
-
如果不用 Fork:Codex 在一个会话里处理的任务越多,对话历史就越长,很快就会把上下文窗口塞满。这会导致:
-
费用增加:每次请求都要带上庞大的历史记录,消耗更多 Token。
-
处理能力下降:AI 可能"记不住"或"忽略"早期的关键信息,影响最终结果。
-
速度变慢:处理大量上下文会拖慢响应速度。
-
-
使用 Fork 的好处:
-
共享上下文,快速上手 :新 fork 出来的"分身"会直接继承父任务完整的对话历史和系统提示。这意味着它不需要你重新解释一遍背景,立刻就能明白要做什么,省时又省力。
-
并行处理,效率翻倍:多个"分身"可以同时工作,互不干扰。一个去读文档,一个去写测试,一个去检查 Bug,齐头并进。
-
节省成本 :由于所有"分身"共享同一个"前缀"(System Prompt 和对话历史),API 提供商(如 DashScope、OpenAI)的提示缓存(Prompt Caching) 机制就能生效。缓存一次,多个分身复用,能节省 80% 以上的 Token 费用。
-
Fork 和 Subagent(子代理)的区别
你可能会看到 Subagent 这个词,它和 Fork 不同,常见于 Claude Code 或 Qwen Code 这类工具中。
| 特性 | Fork (分叉任务) | Subagent (子代理) |
|---|---|---|
| 上下文 | 完整继承父任务的对话历史 | 通常重新开始,不带父任务的历史 |
| 运行方式 | 在后台异步运行,不阻塞主任务 | 通常同步运行,会阻塞主任务直至完成 |
| 主要用途 | 处理需要完整上下文的并行任务,如同时研究多个方案 | 执行需要特定专业知识的独立子任务,如专门的代码审查员或测试员 |