Context forking 是一个强大的 Coding Agent 原语，让你先构建高质量的上下文，然后多次复用。
很多 Coding Agent（OpenCode、Pi、Claude Code 等）都支持 context forking，只是叫法不同：rewind、time traveling、branching——本质都是同一个概念。
上下文窗口 = 向下增长的栈
可以把 Agent 的上下文窗口想象成操作系统中的栈：
在 OS 栈中，新调用的函数会在栈底追加栈帧。上下文窗口同理，每一轮用户消息-助手消息的交互就是一个新的栈帧：
和栈一样，Coding Agent 的上下文窗口通常不支持随机访问。你可以通过发送用户消息往末尾 push 内容，也可以从末尾 pop 内容。但就像 OS 栈随着新函数调用向下增长一样，你只能和历史的最新端交互，被困在末尾。
随机访问不被允许，原因有几个：
- 会导致推理 API 的缓存未命中，成本飙升
- 可能破坏已累积的重要上下文
- 会干扰 Coding Agent 的内部状态
大多数 Coding Agent 都有内部状态，跟踪 Agent 已读/写的文件。当 Agent 尝试编辑文件时，harness 会提示并强制 Agent 先读取文件再修改。在上下文窗口中间擦除或添加工具调用，需要同时精确操作 Agent 的上下文和内部状态，而 Agent 通常不支持这种手术级操作。
Context Forking 是什么
Context forking 允许你从上下文窗口栈的底部 pop 掉一条或多条消息，将状态恢复到之前的版本。
就像 OS 栈一次 push/pop 整个栈帧一样，你通常只能在用户消息轮次边界处回退，而不是在一串工具调用中间：
通常，你可以多次从同一个上下文窗口分叉——向多个不同方向 fork。
不同 Agent 的接口和实现细节各异。有些 Agent 在回退对话状态时会同时回退代码和磁盘状态，有些则会创建新的分支或 worktree。
三大实战场景
1. 纠偏：Agent 遗漏了关键点
最常见的用法：在 Agent 实现功能的过程中，发现遗漏了某个需求，回退对话重新引导。
2. 探索：分叉尝试不同设计路径
在设计阶段尤其好用。当你已经累积了关于代码库和要解决问题的高质量上下文后，fork 对话来探索不同的设计和架构路径。然后对比结果，决定从哪个会话继续——或者发现还需要更多调研。
这是 Agent 时代的 A/B test：用同样的高质量起点，跑多条路径，选最优解。
3. 止损：回退上下文低效操作
另一个高价值场景：在 Agent 做了某种上下文低效操作后，回退对话以保留已构建的高质量上下文。
典型例子：Agent 读取了一个大文件或运行了一个产生海量输出的命令——几万 token 的那种。大多数 harness 会通过将输出写入文件、只给 Agent 看文件路径而非完整内容、并指示 Agent 搜索来防止这种情况。但有时 Agent 就是会逐块读取全部 40,000 token，把上下文窗口塞满。
这时候，fork 回退就能挽救对话。
核心要点
- Coding Agent 的上下文窗口可以看作向下增长的栈。你可以在底部 push 或 pop，但通常不能随意操作栈的中间或顶部。
- Context forking 可用于回退上下文窗口，在 Agent 遗漏某些东西时重新引导它。
- 可用于分叉探索多条设计或实现路径，然后选择最优分支继续。
- 可用于恢复上下文窗口到大量低质量上下文被添加之前的状态，避免一次大文件读取或命令输出毁掉整个会话。
Context forking 不是高级功能，是用好 Coding Agent 的基本功。