子代理与蜂群

mu 可以用两种方式把工作交给别的代理：子代理接各自独立的任务，蜂群让几只蜂同时攻一个难题。

子代理

模型用 delegate 工具委派，或者你用 /agents 来要求。对每个任务，判定器按难度挑一个角色、一档模型和一个思考等级（swarm.routing）。内置角色：

你自己的角色放在 ~/.mu/agent/agents/。最多同时运行三个。子代理会拿到适用于它们任务的经验，在你的硬约束下工作，并沿用对话的权限模式。features.swarm.models 列出它们可以被分派到的模型，便宜的在前；不设置时，所有子代理都用会话的模型。

隔离的编辑

会改文件的子代理在它自己的 git worktree 里工作，这个 worktree 在你的仓库之外，起点是主代理看到的文件，包括还没提交的改动。它做完后，改动以补丁的形式交回，附带文件和行数。判定器根据任务、路径和行数检查补丁是否在任务范围内（swarm.patch），并加一行建议；它从不拦截。

然后由主代理决定：apply_patch_from 要么全部应用，要么一点不应用，不提交、不暂存，也不碰你的索引。在 git 仓库之外，或者正处在 rebase 或 merge 中间时，子代理直接在原处编辑，并说明原因。

蜂群

每个多代理系统都要回答同一个问题：一个代理知道的，要不要告诉另一个？什么都不说，它们会走进同一条死路；什么都说，每个上下文都会被别人的闲聊塞满。在蜂群里，判定器当闸门。

一个蜂群是二到六只蜂，各有自己的关注点。蜂读代码、跑命令、用浏览器；它们从不改代码，那是主模型的事。/hive <question> 发起一个蜂群；问题直接做不下去时，代理也会自己发起一个。

• 发布（hive.publish）。每只蜂说完一段，判定器就问：这里有没有值得共享的发现、死路、决定或阻塞？有的话，它上一块只增不删的共享板。
• 投递（hive.deliver）。每来一条新笔记，判定器对每一只别的蜂各问一次：这和它的关注点有关吗？有关才投递过去，标明「这是发现，不是指令」。
• 纠正（hive.relate）。后来的发现可以推翻早先的：一只蜂报告测试跑不起来，后来另一只清掉一个环境变量，测试就跑通了。判定器读两条笔记之间的关系：「推翻」、「矛盾」或「支持」。被推翻的发现变成一条纠正，送给每一只听过旧发现的蜂。互相矛盾的两条都留着，标成争议；一分钟内没人解决，就派一只验证蜂去查。

一次真实的运行：三只蜂，九分钟，评了 117 条候选笔记，27 条发布，16 条投递给了需要它的蜂。每一次判定都在这次运行的流水里。

查看和停止

/swarm 显示每一只在做什么；/swarm stop 让它们现在交报告；/swarm kill 立刻结束它们。时间到了的蜂会被要求交报告，不交就被结束；卡住的模型或工具由看门狗处理。蜂群总会带着结果回来。

在桌面端，蜂群页显示每只蜂、它的角色和模型、它在说什么，以及一张谁把什么送给了谁的图：投递越多线越粗，纠正和争议各有自己的画法，一条发现送到的那一刻会沿着线亮一下。对话里的蜂群卡片带一张这张图的缩略图。