上下文分叉：节省时间、花费与麻烦

上下文分叉是一种强大的编码代理基本操作，它允许你积累高质量的上下文，然后多次复用。

许多编码代理（如OpenCode、Pi、Claude Code 等）都支持上下文分叉，尽管它们通常有不同的名称：回退、时间旅行或分支——但这些都属于同一概念的不同变体。

本文是一篇战术指南，介绍如何使用上下文分叉来节省时间、token、金钱，以及避免大量挫败感。

将上下文窗口视为操作系统堆栈

我喜欢将代理上下文窗口概念化为向下增长的堆栈，灵感来自操作系统的堆栈：

来自 https://wiki.osdev.org/Stack

来自 https://wiki.osdev.org/Stack

在操作系统堆栈中，当新例程被调用时，其栈帧会被追加到堆栈底部。你可以将上下文窗口理解为类似的结构：每次用户消息-助手消息的轮次就相当于一个新的例程，附带一个新的栈帧：

和堆栈一样，编码代理的上下文窗口通常禁止随机访问。你可以通过发送用户消息将内容推入末尾，也可以从末尾弹出（移除）内容。

但就像操作系统堆栈随着新例程的调用和栈帧的压入而向下增长一样，上下文窗口只允许你从历史记录的最新端进行推入或弹出。你只能与它的末端交互。

不允许随机访问的原因有几个：

• 可能导致推理 API 出现昂贵的缓存未命中

• 可能搞乱已积累的重要上下文

• 可能干扰编码代理的内部状态

大多数编码代理都有内部状态，用于跟踪代理已读取和/或写入的文件（以及其他信息）。当代理尝试编辑文件时，这种状态使框架能够提示并强制代理在尝试修改文件之前先读取它。

在上下文窗口中间擦除或添加工具调用需要对编码代理的上下文以及任何内部状态进行精细操作，而代理通常不支持这一点。

上下文分叉如何工作？

上下文分叉允许你从上下文窗口堆栈底部弹出 1 条或多条消息，以将状态恢复至更早的版本。

就像操作系统堆栈一次压入和弹出整个帧一样，你通常只能在用户消息轮次的边界处回退上下文窗口，而不能在工具调用序列中间进行：

通常，你可以多次执行此操作——从同一个上下文窗口以多种不同方式进行分叉。

不同代理的界面和实现细节各不相同。有些代理允许你在回滚对话状态时同时回滚代码和磁盘的状态。另一些代理则会在执行此操作时创建新的分支或工作树。

何时应该分叉上下文窗口？

回退以纠正代理的方向错误

一个常见的用例是当代理在实现某个功能时遗漏了某些内容时，通过回退对话来纠正：

分叉以探索不同的设计路径

我经常在任务的设计阶段发现自己会分叉会话。

一旦我积累了关于代码库和要解决的问题的高质量上下文，我就会分叉对话，以探索不同的设计和架构路径。

然后我会审查结果，决定从哪个会话继续推进——或者需要更多研究！

分叉以保留上下文窗口，避免上下文低效操作

分叉的另一个绝佳用途是：在代理执行了上下文低效的操作后，回退对话以保留已建立的高质量上下文。

一个例子是当代理读取一个大文件或运行一个生成大量输出（数万 token）的命令时。大多数编码代理框架都有钩子或其他安全机制来防止这种情况，方法是将输出写入文件，只向代理显示文件路径，并指示代理自行搜索。但有时，代理会一次一个块地读取全部 40,000 个 token，从而填满上下文窗口：

幸运的是，我们可以通过分叉来挽救对话！

让我们总结一下：

• 编码代理的上下文窗口可以概念化为向下增长的堆栈。你可以从底部推入或弹出，但通常不能交互地修改堆栈的中间或顶部

• 上下文分叉可用于回退上下文窗口，以便在代理遗漏某些内容时重新引导

• 上下文分叉可用于分支并探索多种不同的设计或实现路径

• 上下文分叉可用于恢复上下文窗口到添加大量低质量上下文之前的状态