智能体团队

CountBot 支持把一组角色固定为一个“团队模板”，在聊天、Web 页面或工具调用时反复复用。团队不是简单的提示词集合，而是完整的多智能体工作流配置，包含协作模式、成员定义、交叉评审、技能开关，以及可选的团队专属模型配置。

这章解决什么问题

团队和普通单 Agent 会话有什么区别
团队成员有哪些字段，分别在什么模式下生效
团队 API 是否完整，如何增删改查
会话自定义模型、团队自定义模型、全局模型三者谁优先
workflow_run 如何调用预定义团队，如何直接传入自定义 agents
IM 渠道里的 /team 和 @团队名 是怎么工作的

团队是什么

一个团队由以下核心字段组成：

name：团队名称，必须唯一
description：团队说明
mode：协作模式，支持 pipeline、graph、council
agents：成员列表
is_active：是否启用
cross_review：是否启用交叉评审，主要用于 council
enable_skills：是否允许子智能体使用技能系统
use_custom_model：是否启用团队专属模型配置

团队配置保存在 /api/agent-teams，团队模型覆盖单独保存在 /api/agent-teams/{team_id}/config。

三种协作模式

`pipeline`

按顺序串行执行，后一个成员会看到前面成员的结果。适合：

规划 -> 实现 -> 复核
调研 -> 起草 -> 编辑
拆解 -> 编码 -> 测试

`graph`

按依赖关系执行，没有依赖冲突的节点可以并行运行。适合：

多条工作线并行推进
需要显式依赖的复杂任务
某一步满足条件后才进入后续步骤

`council`

多个成员先并行给出观点，再做综合。适合：

多视角分析
方案辩论
审阅、评审、争议性判断

如果 cross_review=true，成员在第一轮独立分析后，还会在第二轮互相评议；如果为 false，则只做并行分析，不做交叉评审。

成员字段

每个团队成员都来自同一个结构：

{
  "id": "reviewer",
  "role": "Reviewer",
  "system_prompt": "你负责识别回归风险和边界条件。",
  "task": "审查实现结果并指出潜在问题。",
  "perspective": "质量与风险",
  "depends_on": ["coder"],
  "condition": {
    "type": "output_contains",
    "node": "tester",
    "text": "通过"
  }
}

字段含义：

id：团队内唯一 ID，供依赖和条件引用
role：角色名，主要用于 pipeline 和 graph
system_prompt：该成员的系统提示词
task：该成员的任务描述，主要用于 pipeline 和 graph
perspective：分析视角，主要用于 council
depends_on：依赖哪些成员先完成，主要用于 graph
condition：条件执行规则，主要用于 graph

模式与字段关系

字段	`pipeline`	`graph`	`council`
`id`	必需	必需	必需
`role`	常用	常用	可选
`system_prompt`	可用	可用	可用
`task`	常用	常用	通常不用
`perspective`	通常不用	通常不用	常用
`depends_on`	不用	常用	不用
`condition`	不用	可用	不用

团队 API

团队 CRUD

方法	路径	说明
`GET`	`/api/agent-teams/`	获取团队列表
`GET`	`/api/agent-teams/{team_id}`	获取团队详情
`POST`	`/api/agent-teams/`	创建团队
`PUT`	`/api/agent-teams/{team_id}`	更新团队
`DELETE`	`/api/agent-teams/{team_id}`	删除团队

创建或更新团队时，主体字段包括：

{
  "name": "开发评审团队",
  "description": "用于需求拆解、实现和代码审查",
  "mode": "pipeline",
  "agents": [
    {
      "id": "planner",
      "role": "Planner",
      "system_prompt": "你负责拆解需求。",
      "task": "把任务拆成明确的开发步骤。"
    },
    {
      "id": "coder",
      "role": "Coder",
      "system_prompt": "你负责编码实现。",
      "task": "根据规划完成实现。"
    },
    {
      "id": "reviewer",
      "role": "Reviewer",
      "system_prompt": "你负责找出风险。",
      "task": "审查实现结果。",
      "depends_on": ["coder"]
    }
  ],
  "is_active": true,
  "cross_review": true,
  "enable_skills": false
}

团队模型配置 API

方法	路径	说明
`GET`	`/api/agent-teams/{team_id}/config`	获取团队当前生效的模型配置
`PUT`	`/api/agent-teams/{team_id}/config`	保存团队专属模型配置
`DELETE`	`/api/agent-teams/{team_id}/config`	清空团队专属模型配置，恢复全局默认

团队模型配置字段：

provider
model
temperature
max_tokens
api_key
api_base

示例：

{
  "provider": "openai",
  "model": "gpt-5",
  "temperature": 0.3,
  "max_tokens": 16000,
  "api_key": "",
  "api_base": ""
}

GET /config 返回的不是“原样存储值”，而是“生效配置”：

model_settings：全局默认与团队覆盖合并后的结果
global_defaults：系统全局默认值
use_custom_model：当前团队是否启用了团队专属模型

会话配置、团队配置、全局配置的优先级

这是多智能体文档里最容易写错的一块，当前实现可以概括为：

普通聊天会话

普通聊天时，运行时配置优先级为：

会话自定义配置
全局 Provider 配置
Provider 元数据默认值，例如默认 api_base

会话配置接口：

方法	路径	说明
`GET`	`/api/chat/sessions/{session_id}/config`	获取会话自定义配置
`PUT`	`/api/chat/sessions/{session_id}/config`	保存会话自定义配置
`DELETE`	`/api/chat/sessions/{session_id}/config`	清空会话自定义配置

当前会话配置主要分两块：

model
persona

示例：

{
  "model": {
    "provider": "openai",
    "model": "gpt-5",
    "temperature": 0.6,
    "max_tokens": 12000,
    "api_key": "",
    "api_base": ""
  },
  "persona": {
    "ai_name": "CountBot",
    "tone": "专业直接"
  }
}

预定义团队工作流

如果通过预定义团队执行 workflow_run(team_name=...)，模型优先级为：

团队专属模型配置
会话模型覆盖
全局模型配置
Provider 元数据默认值

也就是说：

团队启用了 use_custom_model 时，团队模型优先
团队没有专属模型时，工作流会继承当前会话的模型覆盖
会话 persona 主要作用于当前会话主助手；团队成员的职责和风格仍以 agents[].role、system_prompt、task、perspective 为主

自定义 inline agents 工作流

如果直接调用 workflow_run 并传入 agents，没有 team_name，那么：

必须显式传入 mode
不会加载团队数据库配置
可以继承当前会话模型覆盖

`workflow_run` 的两种使用方式

方式一：调用预定义团队

这是最推荐的方式，复用性最高。

{
  "team_name": "开发评审团队",
  "goal": "分析这个 PR 的风险并给出修改建议"
}

执行时系统会自动加载：

mode
agents
cross_review
enable_skills
团队专属模型配置

方式二：直接传入自定义 agents

适合临时一次性工作流。

{
  "mode": "pipeline",
  "goal": "为这个需求生成实现方案并给出测试点",
  "agents": [
    {
      "id": "planner",
      "role": "Planner",
      "task": "拆解需求并输出实施步骤"
    },
    {
      "id": "tester",
      "role": "Tester",
      "task": "根据实施方案列出测试点"
    }
  ]
}

如果既没有 team_name，也没有 agents，工具会直接报错。

Web、IM 和工具层的触发方式

Web Chat

当前实现支持显式团队命令：

/team 团队名 任务描述

行为规则：

/team：返回可用团队列表
/team 团队名：返回该团队的正确用法
/team 团队名任务：直接路由到 workflow_run

IM 渠道

IM 渠道里的 /team 行为与 Web Chat 一致，也是显式工作流入口。详细命令见 IM 命令。

`@团队名`

当前系统提示中还包含一条显式规则：当用户消息里出现 @团队名 时，模型应优先调用 workflow_run。这意味着除了 /team ... 之外，还可以通过自然消息触发团队工作流，例如：

@开发评审团队 帮我审一下这段实现方案

通过 `agent-team-manager` 管理团队

除了直接调用团队 API，当前还新增了 agent-team-manager 技能，适合在聊天中完成这些操作：

创建团队
修改团队模式
批量调整成员
设置团队专属模型
查看团队与成员详情

它的脚本入口是：

python3 skills/agent-team-manager/scripts/agent_team_manager.py <command> [args]

详细用法见 Agent Team Manager。

设计建议

角色职责尽量单一，不要在一个成员里塞过多目标
graph 模式只在确实需要依赖关系时再用，避免维护复杂度过高
council 模式更适合分析和评审，不适合强执行链路
团队模型覆盖只给少数关键团队启用，避免环境维护过重
如果只是临时任务，优先用 inline agents；如果会复用，建成预定义团队

智能体团队

这章解决什么问题

团队是什么

三种协作模式

`pipeline`

`graph`

`council`

成员字段

模式与字段关系

团队 API

团队 CRUD

团队模型配置 API

会话配置、团队配置、全局配置的优先级

普通聊天会话

预定义团队工作流

自定义 inline agents 工作流

`workflow_run` 的两种使用方式

方式一：调用预定义团队

方式二：直接传入自定义 agents

Web、IM 和工具层的触发方式

Web Chat

IM 渠道

`@团队名`

通过 `agent-team-manager` 管理团队

推荐的团队模板

开发团队

内容团队

客服团队

设计建议

相关文档

这章解决什么问题​

团队是什么​

三种协作模式​

pipeline​

graph​

council​

成员字段​

模式与字段关系​

团队 API​

团队 CRUD​

团队模型配置 API​

会话配置、团队配置、全局配置的优先级​

普通聊天会话​

预定义团队工作流​

自定义 inline agents 工作流​

workflow_run 的两种使用方式​

方式一：调用预定义团队​

方式二：直接传入自定义 agents​

Web、IM 和工具层的触发方式​

Web Chat​

IM 渠道​

@团队名​

通过 agent-team-manager 管理团队​

推荐的团队模板​

开发团队​

内容团队​

客服团队​

设计建议​

相关文档​

这章解决什么问题

团队是什么

三种协作模式

`pipeline`

`graph`

`council`

成员字段

模式与字段关系

团队 API

团队 CRUD

团队模型配置 API

会话配置、团队配置、全局配置的优先级

普通聊天会话

预定义团队工作流

自定义 inline agents 工作流

`workflow_run` 的两种使用方式

方式一：调用预定义团队

方式二：直接传入自定义 agents

Web、IM 和工具层的触发方式

Web Chat

IM 渠道

`@团队名`

通过 `agent-team-manager` 管理团队

推荐的团队模板

开发团队

内容团队

客服团队

设计建议

相关文档