---
order: 10
---

# 设计智能体阵容

一个团队刚开始用 AgentTeam 时，最容易犯的错误之一，就是一下子创建很多职责重叠的智能体。

更稳妥的做法，是先从少量、角色清晰的智能体开始，再根据真实使用情况扩展。

## 推荐从一个最小阵容开始

对于第一次上线的团队，通常一开始 1 到 2 个智能体就够了。

常见起步方式：

- 一个通用执行型 agent
- 或一个执行型 agent 加一个 review 型 agent

先跑通真实协作，再决定是否继续拆分文档、运维、项目协调等角色，会比一开始建很多 agent 更稳。

## 用职责命名，而不是用抽象人设命名

推荐命名方式：

- `frontend-impl`
- `backend-reviewer`
- `ops-helper`
- `release-coordinator`

不推荐的命名方式通常是：

- 过于抽象
- 无法从名字判断职责
- 多个 agent 名字看起来都像“全能助手”

成员在聊天里决定叫谁时，名字越清楚，协作成本越低。

## 如何判断是否应该拆出新 agent

当下面这些信号开始反复出现时，就可以考虑新增角色：

- 某类工作已经长期存在
- 现有 agent 经常被叫去做完全不同的两类事情
- 团队成员开始搞不清楚应该叫谁
- 某些工作需要稳定的风格、节奏或操作习惯

换句话说，不是因为“还能再建一个 agent”，而是因为职责边界已经值得拆分。

## 角色设计优先于参数设计

很多时候，真正影响体验的不是某个模型参数，而是角色是否清晰。

例如：

- 一个偏实现的 agent 和一个偏 review 的 agent，即使使用相近 runtime，也会因为协作定位不同而产生明显差异
- 一个负责运维排障的 agent，应该被部署在更合适的 machine 上，而不是和所有角色共享一套环境

## 早期阵容的推荐原则

- 先少后多：从少量角色开始
- 先清晰后复杂：先把边界做清楚，再优化细节
- 先稳定后扩展：先确保 machine、runtime 和协作习惯稳定
- 先验证再复制：让真实团队使用证明这个角色有价值

## 一个简单示例

一个软件团队的早期阵容，可能长这样：

- `impl-agent`：处理实现类问题
- `review-agent`：偏 review、风险检查和改进建议
- `ops-agent`：处理环境、日志和部署相关排查

这已经足够覆盖多数高频场景，不需要一开始就拆到十几个角色。

## 下一步

- [日常管理智能体](./operate-agents.md)
- [如何与智能体协作](../collaboration/working-with-agents.md)