使用蜂群

把一个清楚的目标交给蜂群，让各路分别处理其中一部分，再回到当前对话汇总。本篇用“审阅发布说明”说明从发送任务到阅读结果的完整过程。

准备材料

把需要审阅的文档加入当前会话，或提供当前工作区内可读取的文件。指明以哪个版本为准，以及这次是只读检查还是允许修改。

例如，只审阅发布说明时，不需要顺便重写产品文档。范围越清楚，各路输出越容易合并。

开启并发送

在输入框底部打开「蜂群」，确认显示「蜂群 开」，然后发送目标。只想在这一轮使用时，也可以直接在消息里明确要求“用蜂群”，不必长期打开开关。

用蜂群审阅这份发布说明。一路检查功能描述是否前后一致，一路检查操作步骤是否缺少前提或入口。每项问题给出原文位置、原因和修改建议。最后合并重复项，无法确认的内容单独列出。先不要修改文件。

这条指令同时说明了分工和交付格式。只说“多开几个智能体帮我看看”，可能得到几份关注点相似、却难以合并的结果。

查看执行进度

下面使用虚构的发布说明演示完整流程。打开蜂群并点击发送，查看两路审阅、合并和最终回复；左右箭头可以逐步查看，关系图与列表可切换。演示仅在本页运行，不会发送真实任务。

关系图适合看整体：主智能体把工作交给各路，节点状态展示哪些仍在运行。候选结论尚在等待时，不能把其中一路完成当作最终汇总已经完成。

列表适合逐项读：对照任务名称、工作器和当前状态，打开记录查看该路实际检查了什么。示例中的“功能描述”已完成，“操作步骤”仍在进行，两种视图表达的是同一组任务。

右侧说明帮助你理解现在谁在做、是否需要等待其他分支，以及下一步会发生什么。图例中的颜色深浅表达用量，不代表结果质量。

安排先后顺序

不是所有步骤都适合一起开始。继续上面的审阅任务，如果还要生成修订稿，应让修订稿等待两路审阅结束：

可以这样说明：

两路审阅可以同时进行。等它们都结束后再整理修订建议；有冲突的意见列出依据，由我确认，不要直接选择一方改文件。

这就是依赖关系的用途：需要前置结果的工作等它完成，无关的工作继续推进。普通任务也可能有依赖，不是出现先后顺序就必须使用递归任务。

让结果能被下一路使用

“等待上游完成”和“参考已经完成的结果”是两件事。前者决定能否开始，后者决定开始时有哪些材料可读。

例如术语核对可以参考已经完成的功能审阅摘要，但摘要共享不等于共享整段对话，也不会让正在运行的任务自动重新读入所有新结论。如果术语核对必须覆盖两路最终结果，就明确要求它等待两路结束。

需要这种结果参考时，把要求写进任务，并在执行记录中核对是否实际采用：

为后启动的术语检查提供已经完成的功能审阅摘要。没有现成结果时先独立检查；最终汇总时再统一核对全部意见。

如果两项检查同时开始，可能还没有已完成摘要可用。必须使用完整上游结论的工作，应明确安排在上游结束之后。

交接完整产物时，要写明文件或材料位置、版本和要使用的部分。不要只说“照上一位的结果处理”。

收到结果后怎么做

先要求主智能体合并，而不是把各路回答原样拼在一起：

按原文位置合并这次建议。重复问题只保留一项；不同意见列出各自依据。最后区分可以直接修改、需要我确认和暂时无法核实的内容。

检查引用是否存在，建议是否改变原意，未完成的分支是否被遗漏。确认后再授权修改，并复核整份文档。

如果多路要直接修改项目，提前划分文件范围。它们可能使用同一个工作目录，不会自动各自获得隔离副本。部分失败时，按 恢复与追加 处理，不必一上来重跑全部任务。

任务描述不是文件访问权限边界。共享工作区前，先移开无关凭据和私人文件，只提供各路分工需要的材料。