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