递归任务

有些目标开始时还无法列出所有步骤。整理一份项目上手指南，就需要先弄清真实功能与入口，再决定章节，随后编写、检查和汇总。递归任务用于这种需要逐层展开的工作。

如果已经知道“分别检查这两个文件”，普通蜂群通常就够了。递归不是增加并发数量的快捷方式。

先写清最终交付物

把完整目标、可用材料和完成标准放在同一条指令里，给规划留出空间，同时让结果可以验收：

根据当前项目整理一份上手指南。先核对安装方式、真实入口和必要配置，再组织章节、编写操作步骤并检查链接。只修改 docs/guide 目录；每个步骤要有预期结果。缺乏依据的功能列为待确认，不发布网页。最后交付指南、检查结果和未解决事项。

这里规定了最终要什么、能改哪里、如何确认完成，而没有假定系统必须拆成固定的三步或固定数量的智能体。

开启递归任务

在支持该功能的编码会话中，先开启「持续蜂群」，再启用「递归任务」，然后发送完整目标。功能不可用时，按界面提示检查运行时支持情况；不要把普通蜂群开关理解为同时开启了递归模式。

与普通持续蜂群按行分配工作不同，这里应提交一个连贯目标，让运行时组织其中的层级关系。

看懂任务如何展开

上手指南可能按下面的方式组织。它是一种示例，不是固定角色模板：

章节需要依赖事实核对，但不同章节未必互相等待。递归任务的重点是按需要细化工作和组织依赖，并非让每个节点无限创建更多分支。

执行时重点看什么

先看哪些任务已经完成、哪些正在运行、哪些等待前置结果。一个前置任务失败，可能让多个后续任务无法开始；这不等于后面的节点都各自执行失败。

再看已经完成的内容能否支持下一步。例如安装方式尚未确认时，即使章节目录已经生成，也不宜据此认定指南可以开始最终交付。

当界面展示预算或用量时，区分允许使用的范围与已经发生的消耗。任务树受深度、规模和运行时间等约束；触及限制后，应检查实际覆盖范围，而不是把返回结果一律理解为目标已经全部完成。

中断后继续

支持恢复的运行时会提供快照和「检查并恢复」入口。先读取当前状态，核对完成的成果、仍待处理的节点，以及可能已经发生的文件或外部操作，再决定恢复。

例如章节已写完但链接检查中断，可以先确认章节文件仍完整，再处理尚未完成的检查。不要因为最后没有汇总消息，就把全部章节重新生成一次。

恢复入口和能力取决于当前运行时；没有可靠状态时，先整理现有成果，再给出范围明确的后续任务。详见 恢复与追加。

验收整个目标

任务树结束后，回到最初的指令逐项检查：指南能否按步骤使用、每一步是否有预期结果、链接是否有效、待确认内容是否明确列出。

局部分支完成只能证明那一路有了结果。最终交付还需要消除章节间重复、术语冲突与前后矛盾。发布或部署仍需相应授权，不会因为启用递归任务而自动获得许可。