多智能体团队配置
这篇适合“一个任务里固定使用多个角色协作”的场景，例如：
- 需求拆解 -> 技术方案 -> 审核总结
- 多视角评审
- 并行分析后汇总
如果你要的是多个 IM 机器人入口，而不是固定工作流，请看 多机器人独立配置。
先理解团队和多机器人的区别
多智能体团队更像一套可复用的工作流模板：
- 团队里有多个成员
- 每个成员有自己的角色、任务或视角
- 团队按固定模式协作
- 整个团队可以拥有一套团队级模型配置
当前支持的三种协作模式
| 模式 | 适合什么 |
|---|---|
pipeline | 串行流程，前一个成员的输出交给下一个成员 |
graph | 有依赖关系的并行流程 |
council | 多视角并行分析，再做综合 |
一个简单判断方式：
- 任务步骤明确，选
pipeline - 多路并行后汇总，选
graph - 多观点讨论和评审，选
council
第一步：创建团队
入口有两个：
- 聊天页顶部的
多智能体 设置 -> 多智能体
创建团队时，最关键的字段是：
团队名称团队描述协作模式是否启用技能系统是否启用交叉评审，仅council常用
建议：
- 团队名称直接写用途，不要太抽象
- 如果团队会长期复用，描述里把输入和输出写清楚
第二步：添加成员
每个成员的核心字段如下：
| 字段 | 作用 | 常见模式 |
|---|---|---|
id | 团队内唯一标识 | 全部 |
role | 成员角色名 | pipeline / graph |
task | 当前成员要完成的任务 | pipeline / graph |
perspective | 分析视角 | council |
system_prompt | 长期角色约束 | 全部 |
depends_on | 依赖哪些成员先完成 | graph |
condition | 条件执行规则 | graph |
几个实用建议：
id用稳定英文标识，例如analyst、architect、reviewertask写这一步要做什么system_prompt写这个成员长期遵守什么原则council模式优先写清楚perspective
第三步：给团队设置独立模型
路径：
- 进入某个团队详情
- 点击编辑
- 切到
模型配置 - 打开
为此团队使用自定义模型
团队级模型配置通常会覆盖：
providermodeltemperaturemax_tokensthinking_enabledapi_keyapi_base
适合这样用：
- 文档分析团队用偏长文本理解的模型
- 代码评审团队用偏代码能力的模型
- 决策评审团队用偏推理的模型
当前实现边界
这一点很重要，实际使用时不要过度理解：
- 当前支持的是“团队级独立模型”
- 不是“同一团队里每个成员各自不同模型”
也就是说：
- 团队 A 可以用模型 A
- 团队 B 可以用模型 B
- 但同一个团队里的成员不会分别配置三套完全不同的模型
从当前实现看，团队运行时会稳定继承团队级的 provider、model、temperature、max_tokens、thinking_enabled 和 API 配置。
另一个边界是：
- 编辑器里会出现
max_iterations - 但团队成员运行时的迭代上限目前仍建议按全局设置理解
如果你需要“每个成员独立模型”，那已经超出当前现成配置路径。
保存后怎么调用团队
当前主要有两种调用方式：
方式一：在聊天里直接 @团队名
例如：
@文档深度分析 请总结这份 PRD，并指出关键风险。
方式二：显式使用 /team
例如：
/team 文档深度分析 请总结这份 PRD，并指出关键风险。
如果只输入：
/team
系统会返回当前可用团队名称列表。
团队必须处于激活状态
只有 is_active = true 的团队才会被识别。
排查团队无法触发时，优先检查：
- 团队是否启用
- 团队名称是否完全匹配
- 当前消息是否真的用了
@团队名或/team 团队名 任务
一个推荐起步模板
如果你第一次配置团队，先从这个 pipeline 模板开始最稳妥：
| 成员 ID | Role | Task |
|---|---|---|
analyst | 需求分析师 | 拆需求、列边界、识别风险 |
architect | 技术架构师 | 给出方案和模块划分 |
reviewer | 评审专家 | 审核方案并指出缺口 |
summarizer | 汇总专家 | 汇总前面结果并给出结论 |
先把这个模板跑通，再去尝试 graph 和 council。