多 Agent 协作：Router、Handoff、Supervisor 与 Subagent 应该怎样选择

上一小节，咱们给 Agent 配置了剧情设计 Skill。它可以读取世界观，按照 Skill 中的方法设计分支，再把大纲保存到 Workspace。

只做这件事，一个 Agent 就够用了。

但是，后面要制作一款完整的互动剧情游戏，还需要设计人物、编写多个场景、检查剧情冲突。每项工作都会读取文件、调用工具，并产生自己的中间结果。

如果这些工作始终由同一个 Agent 连续处理，那么它在检查最终剧情时，消息里可能还保留着前面设计人物、修改大纲时的很多细节，就难免会有些力不从心了。

就好比一个程序员既要：分析需求、写代码，又要自己验收写测试，难免容易罢工。。。（来自打工人浓浓的怨气）

所以，这个时候，就可以把工作分给不同角色。比如，让一个“总导演”负责整体任务，把剧情设计交给“剧情设计师”。设计师自己读取资料、完成设计，最后告诉总导演：做完了什么，文件放在哪里。

这就用到了这一节的 多 Agent 协作：让多个具有不同职责的 Agent，通过任务和结果的传递，共同完成工作。

多个 Agent，应该怎样分工

大家可能看到过 Router、Handoff、Supervisor 和 Subagent 这些名字。

咱们直接放到剧情制作场景里理解。重点看三种安排：先分配请求、转交后续对话，以及主 Agent 委派子任务。

Router：先判断这次请求应该交给谁

假设一个创作平台里有三个功能：修改世界设定、设计人物、检查剧情。

用户说：“帮我检查第三个场景有没有违反世界规则。”

系统先判断这是“剧情检查”请求，再交给负责检查的 Agent：

中间负责判断和分配的部分，就是 Router，也就是路由。

Router 根据输入，选择适合处理本次请求的 Agent。 分类可以由普通规则完成，也可以交给模型判断。

如果用户同时要求“检查人物设定和剧情冲突”，路由也可以把请求分给多个 Agent，再汇总结果。

这种方式适合任务分类比较明确的入口。它的重点是 把当前请求分配出去，通常不负责根据多轮执行结果持续规划整个制作项目。

Handoff：把接下来的对话交给另一个角色

继续看这个创作平台。

用户一开始和创作助手讨论游戏主题，聊到人物时，希望进一步设计主角的背景、性格和人物关系。

这时，创作助手可以把后续对话交给人物设计 Agent：

这种接管后续交互的方式，叫作 Handoff，可以理解为交接。