你正在让 AI 修复一个构建错误，过程中又想到：“顺便把这套逻辑整理成一篇设计说明。”

直接发送，新要求会进入当前会话，和正在进行的修复争夺上下文；加入队列，它只能等待前一个任务结束；另开空白会话，则要重新解释项目背景、技术约束和已经做过的判断，还可能让 Agent 重新搜索代码、读取文件和追踪调用链。

**Fork & Send 解决的是第四种需求：保留当前对话的有效背景，但把新消息作为一个独立任务立即发往新会话。**继承相同历史不仅让新任务少做重复 Explore，稳定的提示词前缀还有机会命中模型提供商的缓存，降低首轮延迟和缓存输入 Token 成本。

这不是简单的“新建聊天并复制文字”，也不是 Git 的 fork。它同时处理对话历史、任务状态、工作区绑定，以及可选的 AIVCS 分支隔离。

为什么只有“发送”和“排队”还不够

长任务中的新想法通常分为三类：

1. 补充当前任务：例如“错误发生在 Windows 上”，适合引导正在运行的 Agent。
2. 等待当前任务完成后继续：例如“修完后再补一组测试”，适合排队。
3. 基于现有背景开始另一项工作：例如“沿用刚才的分析，另做一个重构方案”，适合 Fork & Send。

第三类消息与当前对话有关，却不属于当前任务。如果把它塞进原会话，Agent 需要同时维护两套目标，待办列表和收敛条件也会混在一起；如果从零开始，用户又必须重复背景。

Fork & Send 把“共享背景”和“共享任务”拆开：背景可以继承，任务必须重新开始。

一个典型例子：发现了新问题，但修复依赖当前上下文

假设一个会话正在排查“用户登录后偶发跳回登录页”。Agent 已经读过认证中间件、刷新令牌服务和前端请求拦截器，分析了日志，并确认当前任务的根因是刷新令牌续期失败。修复正在进行时，用户从同一批日志里又发现一个独立问题：多个浏览器标签页会同时发起续期请求，造成令牌轮换竞争。

这是一个新任务，因为它有自己的复现步骤、修复方案和验收测试；但它又强烈依赖当前上下文——认证链路、相关文件、日志字段和令牌轮换规则都已经在现有对话中梳理清楚。

此时几种操作的结果不同：

• 直接发送：新问题会进入当前会话，Agent 可能在第一项修复尚未收敛时切换目标，两个根因、待办和测试容易混在一起。
• 加入 Queue：上下文得以保留，但新问题只能等待；如果两个修复可以并行推进，就浪费了时间。
• 新建空白会话：任务能够并行，但用户必须重新描述认证架构、日志结论、相关文件和已经排除的假设。
• 手动 Fork 后再发送：可以做到，但用户要先选择分叉点、创建并切换会话，再重新输入和发送新问题；如果希望继承的是当前最新分析，而不是回到某个较早节点，这些步骤只是额外操作。
• Fork & Send：用户直接写下“修复多标签页同时续期导致的令牌轮换竞争”并选择 Fork & Send。新会话继承已经确认的认证背景，却以独立的freshTask、待办和验收条件立即开工；原会话则继续完成“续期失败”的修复。

这个例子体现了 Fork & Send 最典型的判断标准：新问题可以独立交付，但解决它所需的背景已经存在于当前会话，而且现在就值得并行处理。

继承上下文还意味着更少的重新 Explore

如果从空白会话开始，Agent 不仅要听用户重新讲一遍背景，往往还要重新搜索入口、读取同一批文件、追踪相同调用链、核对日志并再次排除已经否定的假设。真正昂贵的并不只是重复输入几段文字，而是整套 Explore 工具调用、文件读取和推理过程。

Fork & Send 继承已经提交的对话历史，因此新会话一开始就知道“看过哪些文件、发现了什么证据、哪些方向已经排除”。在上面的例子中，它可以直接研究多标签页续期竞争，而不必重新定位认证中间件、刷新令牌服务和请求拦截器。这会直接减少重复 Explore 的轮次、工具调用与等待时间。

这份稳定的历史前缀还有机会命中模型提供商的提示词缓存，计为缓存输入 Token。当新会话沿用相同模型、聊天模式和大段相同历史时，提供商可能复用已经处理过的前缀，从而进一步降低首轮响应延迟与输入成本。缓存是否命中仍取决于具体模型、提供商策略、缓存有效期以及最终请求前缀是否一致，因此它是可观测的性能收益，而不是 Fork & Send 对所有模型的硬性保证。

手动 Fork 同样可能复用其所选历史节点的前缀；Fork & Send 的额外价值在于，它默认携带当前最新的有效背景并立即发送新任务。与空白会话相比，两者都能节省重新 Explore；与手动 Fork 相比，Fork & Send 更适合不需要回退历史、只想基于当前结论立即并行开工的场景。

一次 Fork & Send 发生了什么

用户可以从发送按钮的菜单选择 Fork & Send，也可以对排队消息或 steer 消息直接执行该操作。两种入口最终遵循同一条主线：先创建新会话，再向新会话发送消息。

1. 复制的是已确认背景，不是尚未执行的意图

新会话会继承源会话已有的对话历史，使 Agent 能理解前面讨论过的代码、约束和结论。但 Fork & Send 会排除尚未消费的 queue / steer 用户消息，避免同一条未来指令同时出现在两个任务里。

对排队消息执行 Fork & Send 时，系统会先成功创建新会话并发送消息，然后才从源队列删除那一条消息。这个顺序很重要：如果新会话创建或发送失败，原消息仍留在源会话，不会因为一次失败的分叉而丢失。

2. 继承工作环境，但重置任务状态

新会话沿用源会话的工作区、模型、聊天模式、参与者和必要的插件会话扩展。因此，它不是一个失去环境的空白聊天。

但新会话会被标记为freshTask：源任务的 todo 列表、收敛状态和 nudge 状态不适用于它。系统会清空继承的待办，并通过隐藏的分叉边界消息告诉 Agent：复制的历史只是背景，应根据接下来的新请求建立自己的任务计划。

这条边界避免了最危险的错觉——“看到了旧待办，所以应该继续完成旧待办”。

3. 在需要时一起分叉文件状态

如果源会话没有启用 AI 会话隔离，Fork & Send 仍可创建独立的对话任务；两边只是继续使用同一个工作区，因此并发写入仍需要用户或 Agent 自己协调。

如果源会话已经绑定可分叉的 AIVCS 分支，AnyPal 会为新会话分叉对应的 AIVCS 分支。此时，两边不仅拥有不同的会话目标，也拥有独立、可恢复的文件状态。源会话继续修复构建错误，新会话可以同步撰写文档或尝试另一种实现，而不会直接覆盖对方的未合并修改。

因此，Fork & Send 与 AIVCS 的关系是增强而非前置条件：

• 没有 AIVCS 隔离：分开的是会话和任务状态；
• 启用 AIVCS 隔离：会话、任务状态与文件状态一起分叉。

它与几个相似操作有什么不同

普通发送

普通发送把消息交给当前会话。它适合延续同一个目标，不会创建新的会话，也不会建立新的任务边界。

Queue 与 Steer

Queue 表示“稍后在当前会话做”，Steer 表示“影响当前正在运行的任务”。两者都默认当前会话仍是正确的执行容器。Fork & Send 则表达：“这些背景有用，但这是一项新的并行工作。”

Fork & Send 和“手动 Fork 后再发送”有什么区别

两种操作最终都会得到一个新会话，但表达的意图不同。

手动 Fork 是“从历史节点另走一条路”。用户先在某条消息上选择 Fork，AnyPal 复制截至该消息（含该消息）的历史并切换到新会话。分叉完成后，新会话停在这个历史节点，等待用户检查上下文、编辑输入，再手动发送下一条消息。原消息之后的讨论不会进入新会话。

Fork & Send 是“把现在想到的新任务立即拆出去”。用户先写好新指令，再执行 Fork & Send。AnyPal 从当前有效背景创建一个freshTask会话，排除尚未消费的 Queue / Steer 消息，重置源任务的待办语义，并立即把新指令和附件发送到新会话。用户不需要先分叉、等待切换，再重复一次发送操作。

这一区别可以归纳为一句话：手动 Fork 选择“从哪里重新开始”，Fork & Send 选择“把什么现在就拆出去做”。

什么时候应该手动 Fork

• 回到决策发生之前：后续讨论已经走偏，希望从某条较早消息重新推演。
• 比较历史分支：保留相同起点，分别尝试方案 A 与方案 B，并确保后来的结论不会影响新分支。
• 先检查再行动：需要确认新会话中究竟复制了哪些历史，再决定下一条指令。
• 修改原问题的问法：想从旧节点重新提问，而不是基于当前完整背景增加新任务。

例如，团队先选择了 REST，随后讨论了大量 REST 实现细节。现在要严谨比较 gRPC，应在“选择协议”之前的消息上手动 Fork；如果使用 Fork & Send，后续 REST 结论仍可能作为背景进入新任务，并不适合做干净的反事实比较。

什么时候应该使用 Fork & Send

• 从修复工作中拆出文档任务：保留当前故障分析，但不打断修复链路。
• 把排队消息提前执行：无需等待当前长任务结束，也不用复制粘贴上下文。
• 从研究中拆出实现任务：研究会话继续补证据，新会话立即按已有结论动手。
• 拆分可并行的交付物：例如一个会话处理 Electron，另一个会话处理 Web。
• 带着附件立即开工：当前输入、图片及上下文附件随新指令一起进入分叉会话。

例如，Agent 正在修复登录故障，而完整原因已经分析清楚。此时要根据同一背景补写事故说明，使用 Fork & Send 最直接：修复会话继续执行，文档会话立刻收到新任务；没有必要先寻找某条历史消息、手动 Fork，再重新输入和发送。

什么时候两者都不该用

如果消息只是修正当前 Agent 的理解，应使用 Steer；如果它必须等待当前改动完成，应留在 Queue；如果两个任务会同时修改同一组权威文件且没有隔离或合并策略，盲目分叉只会把等待变成冲突。

Git branch 或 Git worktree

Git branch 管理代码版本，Git worktree 提供多个 Git 工作目录。Fork & Send 和手动 Fork 管理的是 AI 会话及其任务语义。只有当源会话启用了 AIVCS 隔离时，它们才会额外分叉文件状态；即便如此，分叉的也是AIVCS 分支，不是自动创建一个普通 Git branch。

可靠性来自操作顺序

Fork & Send 的产品体验看起来只有一次点击，但正确性依赖几个明确的顺序约束：

1. 先验证源会话和待发送文本；
2. 创建新会话，并在需要时完成 AIVCS 分支分叉；
3. 写入经过过滤的历史，重置新任务待办；
4. 切换到新会话并发送新消息；
5. 仅在发送成功后，删除源会话中的对应排队消息；
6. 如果新会话构造失败，回收已创建的会话和隔离分支；如果发送失败，向用户显示错误，并保留源会话中的对应排队消息。

这个顺序让 Fork & Send 具备接近“移动任务”的用户语义，同时避免用先删后建的方式制造消息丢失窗口。

从线性聊天到任务图

传统聊天把工作组织成一条时间线：上一条完成，下一条才开始。对人类协作和 AI 编程来说，真实工作更像一张任务图：一些步骤有依赖，另一些步骤只共享背景，可以并行推进。

Fork & Send 是把线性对话转成任务图的一个小入口。它让用户无需重新描述上下文，就能明确表达三件事：

• 这项工作与当前讨论有关；
• 它不是当前任务的延续；
• 它现在就可以独立开始。

结语：Fork & Send 不是为了制造更多聊天窗口，而是为了给“共享背景、独立目标、立即执行”一个准确操作。继承上下文让新会话复用已经完成的探索，避免重复搜索、阅读和推理；相同的历史前缀还可能命中提供商缓存，进一步降低响应延迟与输入成本。当它与 AI 会话隔离和 AIVCS 分支结合时，一次分叉不仅复制理解，也为新的工作流准备独立的文件状态——让并行协作从对话层一路延伸到代码层。