多智能体协作编排师

它解决的问题

把一个复杂任务全塞给单个 Agent，最常见的失败模式是「半成品」：前面收集的信息到后面写结论时已经丢了，跨领域时模型在不熟悉的一环凭印象编，于是反复返工。根因不是模型能力不够，而是缺少职责划分与交接契约——协作过程像接力传话筒，每一棒都靠自然语言描述「我大概拿到的是啥」，信息逐级衰减。

这个技能把多智能体编排当作架构工作来做：先画任务依赖图，再给每个 Agent 划定单一职责，最后用结构化协议锁住交接点。

它如何工作

整个流程分四步，产出固定格式的编排方案。

步骤 1 · 拆解任务图

把大任务拆成可独立交付的子任务，标出依赖关系（A 完成才能做 B，还是 A/B 可并行）。编排模式从 references/patterns.md 里选：流水线、并行、评审-修订、主从。

步骤 2 · 定义 Agent 职责边界

每个子任务对应一个 Agent，明确写清它的输入是什么、输出是什么、不做什么。这一步专门用来防止职责重叠导致的互相覆盖——比如检索和分析都去「补一点数据」，最后结论就没人负责了。

步骤 3 · 定交接协议

按 references/patterns.md 的模板给出每个交接点的固定格式，包含必含字段与约束。强调一点：交接物必须是结构化文本或文件，不能是口头摘要。

步骤 4 · 输出编排方案

严格输出三块内容：【任务拆分图】、【Agent 职责表】、【交接协议】，块名不可改。

适用边界与红线

适合多步骤、跨领域、需要并行的复杂任务。单一明确的小任务不要拆，一个 Agent 更省事——拆分本身也是成本。

三条红线值得单独列出来：

• 禁止硬拆需要统一判断的任务。整体创意方向这类东西必须留一个主 Agent 守着，否则前后矛盾。
• 禁止让 Agent 在交接中自由发挥。上游结论一旦被下游「顺手优化」过，整条链就失控了，必须用结构化协议锁死。
• 禁止过度拆分。拆得太碎，交接损耗会超过并行带来的收益。

最后一点：它产出的是编排方案，实际执行仍依赖你所在平台的多 Agent / Team 能力。方案给的是契约和结构，跑起来的是执行层。