持续蜂群

主 AI 正在处理一项工作，你又想到其他可以独立推进的事项。持续蜂群让这些新指令进入后台工作，结果完成后回到当前对话。

它适合“边做边追加”。如果从一开始就要把同一个目标拆成几路，先用 普通蜂群。

哪种追加适合并行

假设主 AI 正在根据审阅意见修改发布说明：

判断重点是材料是否已经可用、文件范围是否冲突。把依赖主任务结果的工作过早交出去，后台拿到的可能还是旧版本。

开启持续蜂群

在支持的编码会话中，从输入框的附加选项里开启「持续蜂群」。它与普通「蜂群 开 / 关」是不同的控制：普通蜂群组织当前目标，持续蜂群接收之后追加的工作。

开启后，发送一项可以独立理解的指令。未启用递归任务时，当前流程按行拆分工作；一行写完整的一项任务，不要把同一任务的背景、范围和验收拆成多行。

把上下文写进任务

后台工作单元不会自动拥有你与主 AI 的完整聊天。“按照刚才的要求改”缺少可执行的信息，应改成具体材料、动作和交付标准。

例如分别追加这两项只读检查：

检查 docs/setup.md 的安装命令是否与 package.json 中的脚本一致；只报告不一致的位置和建议，不修改文件。

检查 docs/help 目录的站内链接；报告来源文件、链接目标和无法访问的原因，不修改文件。

文件名仅用于示例，请换成项目中的真实路径。每一项都能独立理解，不需要另一位工作者猜测“刚才”指的是什么。

涉及修改时，再补上允许改哪些文件、哪些内容必须保留、完成后如何验证。例如：

只修改 docs/help/faq.md 中已确认的断链，不改正文含义和其他文件；完成后列出替换前后的地址，并检查目标页面能否打开。

提交后看哪里

发送后的状态先说明请求有没有被确认，再说明是否已有工作运行。请求处于待确认时，不要把它理解成任务已经开始；状态不确定时，也不代表任务必定失败。

后台结果会回到当前对话。阅读结果时核对任务范围、检查依据和未完成项，然后决定是否让主 AI 使用它。例如：

使用刚才的链接检查结果修正帮助文档；先列出准备修改的文件，不要改当前发布说明。

这样才把后台发现与主任务的后续动作连接起来。结果回传不等于主 AI 已经完成整合。

关闭、停止和重试

关闭持续蜂群会改变后续消息的处理方式，不会撤销已经提交的工作。需要中止执行时，使用相应的停止操作，再确认实际状态。

界面上的请求重试用于处理发送失败或回执不确定，不能据此认定它会从任务中断的具体步骤恢复。恢复前先看已留下的文件与结果，具体流程见 恢复与追加。

目标还需要继续拆解时

如果追加的不是一件独立小事，而是一项需要多层规划的大目标，可以进一步使用 递归任务。

持续蜂群回答“新工作什么时候交进去”，递归任务回答“这个目标内部怎样继续拆开”。两者解决的是不同问题。