AI Agent 协作模式设计

当你开始同时用多个 AI Agent，很快会遇到一个问题：它们到底应该怎么协作？

多开几个 Agent 并不难。麻烦的是：谁接需求，谁拆任务，谁执行，谁 review，状态放在哪里，权限怎么管，失败以后怎么恢复。

我在 Slock 、Multica 和企业级 SOP Agent 的实践里，看到的主要差别是组织方式。

简单说，可以分成三种：

• 聊天室模式：自由度高，适合临时派活和探索。
• 办公室模式：用 issue 管任务，适合项目制协作。
• SOP 模式：自由度低，适合流程型、高风险业务。

真实系统往往会混着用。

多 Agent 为什么会乱

单个 Agent 很好理解。你给它一个任务，它规划、执行、调整。

多个 Agent 放在一起后，问题会变得很具体：

• A 改了代码，B 不知道，又改了一遍。
• C 在你没确认时提交了 commit。
• D 调用了不该调用的工具。
• E 忘记了几轮前的目标。
• F 在错误阶段做了正确的事。

这些问题通常不是模型能力问题，而是自由度、权限和状态没有被管理。

Agent 越自由，能处理的任务越复杂；但自由度越高，协作成本也越高。协作模式要解决的就是这件事：在不同任务里，给 Agent 多大自由，给系统多少约束。

聊天室模式：适合临时派活

聊天室模式像在群聊里喊人干活。你在一个频道里 @ 不同 Agent，它们各自执行，结果回到频道。你可以随时插话、纠偏、换人接手。

它适合：

• 还不确定要做什么的探索任务。
• 做完就走的临时需求。
• 需要人实时盯着的快速迭代。
• 多个 Agent 同时查资料、写方案、看日志。

这种模式的好处是快。坏处也很明显：状态散在聊天里，token 消耗高，事后复盘困难。

如果要用聊天室模式，至少做三件事：

1. 主管和执行分开。 用强模型做需求理解和拆任务，执行 Agent 只做明确子任务。
2. 先审后做。 高风险任务先给方案，不许改文件；方案通过再执行。
3. 控制节奏。 完成一个阶段就停下来等确认，不要让 Agent 一口气改到你无法接管。

Slock 很适合这个模式。它的强项就是即时调度和临场协作。

办公室模式：适合项目任务

办公室模式不再靠聊天推进，而是把需求写成 issue。每个任务有背景、目标、边界、负责人、交付物和验收方式。

它适合：

• 有明确交付物的项目制工作。
• 多 Agent 或多人异步协作。
• 需要知道谁做了什么、做到哪一步。
• 需要 review 和复盘的任务。

这里最重要的是 issue。

一个合格 issue 至少要写清楚：

• 背景：为什么做，相关项目或文件在哪里。
• 目标：完成后应该看到什么。
• 边界：哪些不能动，是否允许安装依赖。
• 交付物：代码、报告、截图、HTML 页面，还是新 issue。
• 验收方式：跑什么命令，看什么页面，由谁 review。

办公室模式里，角色最好按任务流分：

• 方案 Agent：把模糊需求变成计划和 issue。
• 执行 Agent：按 issue 干活。
• Review Agent：看 diff、跑测试、读交付报告。
• 管家 Agent：根据任务类型选人。

讨论可以发生在聊天里，但承诺必须进 issue。后续 Agent 只认 issue，不认某句聊天里随口说过的话。

Multica 更接近这个模式。它适合把 Agent 工作从“临时喊一下”变成“可追踪的任务流”。

SOP 模式：适合流程型业务

SOP 模式适合客户接待、订单处理、售后回访、投诉分流这类业务。

这类任务不是开放式研究，难点也不是信息覆盖不够，而是流程不能乱。用户刚进来要识别需求，表达兴趣后要确认关键信息，走到成交前要处理顾虑，出现不满时要切到安抚或人工介入。

如果让 Agent 完全自由发挥，它可能看起来很聪明，但上线后容易提前推进、重复提问、错用工具，或者在用户不满时继续推销。

SOP 模式的做法是：系统告诉 Agent 当前处于哪个阶段、目标是什么、能用哪些工具、什么情况下进入下一步、什么情况下必须停下来。

几个关键点：

1. 状态外置。 不要让 LLM 记流程。系统从数据库加载当前状态，再交给 Agent。
2. 单 Agent + SOP 路由。 同一个 Agent 在不同阶段看到不同提示、工具和目标。
3. 工具白名单。 当前阶段不该用的工具，不要出现在模型上下文里。
4. 规则决定该不该，模型决定怎么说。 是否转人工、是否触达、是否进入下一阶段，由规则判断；具体话术由模型生成。
5. 完整 trace。 每次状态、意图、工具、输出和质量检查都要能查。

这类场景不一定需要多 Agent。实时主链路要稳，后台分析任务可以复杂。

混合模式更常见

实际业务很少只用一种模式。

更常见的结构是：

• 交流层用聊天室模式。 产生想法、讨论方向、临时调度。
• 任务层用办公室模式。 把确定要做的事写成 issue，分配执行和 review。
• 执行层用 SOP 模式。 高风险、流程型、用户可见的任务，用状态机和权限约束。

同一个系统里，开放式研究可以让多个 Agent 并行；项目开发可以用 issue 追踪；客户实时接待则应该走 SOP。

选择时可以按三个维度判断：

• 任务是否开放。 路径不确定，用高自由度；路径稳定，用低自由度。
• 风险有多高。 只读可以自由一点，写入要收紧，高风险操作要审批。
• 是否需要追踪。 需要复盘和验收，就不要只靠聊天。

四条底线

不管选哪种模式，底线都差不多。

可控。 Agent 要知道能做什么、不能做什么、什么时候必须停下来。高风险工具不要只靠 prompt 约束。

可追踪。 每次执行要记录状态、意图、工具调用、工具结果、状态推进和最终输出。

可恢复。 Agent 会犯错，系统要能检测异常、阻止错误传播，并回滚到安全状态。

可迭代。 不要只靠感觉调 prompt。要有评测、版本、灰度和回滚。

这些东西听起来不如“多 Agent 自动协作”酷，但真正决定系统能不能长期跑。

怎么选

可以粗略按这个规则选：

开放式研究、信息覆盖、并行探索
→ 聊天室模式 + 多 Agent

项目制开发、明确交付物、异步协作
→ 办公室模式 + Issue 驱动

流程型业务、风险高、状态长周期存在
→ SOP 模式 + 状态机

不同阶段需求不同
→ 分层混合

几个常见误区也可以直接避开：

• 多 Agent 不一定比单 Agent 好。没有并行和分工需求时，单 Agent 往往更稳。
• Agent 越自由不等于越智能。企业主链路很多时候需要的是“不会乱来”。
• Prompt 不能替代权限、状态和流程控制。
• 协作模式不会一次设计好。早期可能是聊天室，中期变成办公室，成熟后才需要 SOP。

Agent 协作不是把多个模型放进同一个系统就结束了。

要解决的是：它们怎么分工，怎么交接，怎么不重复烧 token，怎么不越权，怎么在出错时被人接回来。

选对模型重要，选对协作方式更重要。

相关阅读：

• Slock 使用指南 ：聊天室模式的实践
• Multica 使用指南 ：办公室模式的实践
• 企业级 SOP Agent 架构 ：SOP 模式的实践