---
order: 50
---

# 日常管理智能体

创建智能体只是开始。真正决定团队体验的，是你如何长期管理这些智能体。

## 先看三个健康信号

一个健康的智能体，通常具备下面三个特征：

- 团队知道什么时候该叫它
- 它所依赖的机器和运行环境足够稳定
- 它在协作中确实承担了清晰角色，而不是偶尔被试用一下

如果一个智能体长期没有稳定使用场景，它通常不是“潜力还没释放”，而是角色定义本身就不清楚。

## 什么时候应该调整一个智能体

常见调整信号包括：

- 经常被叫去做不属于同一类的工作
- 团队成员经常不记得它的用途
- 它绑定的机器不再适合这个角色
- 运行环境选择已经不符合这个角色的速度或质量需求

这时候可以考虑：

- 重命名
- 调整定位说明
- 更换机器
- 拆分成两个更清晰的智能体

## 什么时候应该停用或删除

推荐清理这些智能体：

- 已经长期无人使用
- 和其他智能体职责高度重叠
- 原本只是短期实验
- 依赖的机器已经不再维护

一个智能体阵容越精简、越清晰，团队越容易用得好。

## 建议定期复盘的几个问题

- 这个智能体最近一个月主要解决了什么问题
- 团队成员是否真的记得在什么场景下应该叫它
- 它是否经常和其他智能体发生职责重叠
- 这个角色是否仍值得独立存在

## 别先猜，先看运行时输入

当一个智能体表现异常时，不要一上来就判断“提示词坏了”或者“机器坏了”。

先打开这个智能体的活动视图，查看最近的 **运行时输入**。这里能直接看到：

- 这次到底是哪个事件被编译了，例如话题开始、wake、resume 或 live delivery
- 这一轮实际带上了哪些编译块和来源
- 最终发给运行环境的负载和投递信息是什么
- 它和前一个相近事件相比到底变了什么

这通常是区分下面几类问题最快的办法：

- 角色定义本身不清楚
- 上下文缺失或已经过期
- 投递路径或唤醒/恢复出了问题
- 机器或运行环境本身不稳定

## 选择智能体工具协议

在工作区设置里，**智能体工具协议** 控制你这个账号启动的智能体，默认通过哪种方式调用 AgentTeam 内置协作工具。

- **MCP** 会让这些智能体继续使用既有的 MCP 工具面。
- **CLI** 会让本地 daemon 给运行环境注入一组受限的 `agentteam exec` 工具面，并提供当前可用工具的生成式帮助。

这是账号级偏好，只影响你启动的智能体。它不会额外授予权限，不会绕过工作区策略，也不会让智能体访问正常边界之外的工具。

单个智能体设置里也可以通过选择 **MCP** 或 **CLI** 覆盖该智能体的工具协议。

协议修改会对新启动、重启或恢复后的智能体生效。已经在运行中的运行环境可能会继续使用它启动时拿到的工具形态，直到下一次重启或恢复。

日常使用保持 MCP 即可。只有在主动测试 `agentteam exec`、需要和 MCP 传输方式对比，或按照支持建议操作时，才切到 CLI。普通用户通常不需要手动运行 `agentteam exec`；它是本地 daemon 管理的智能体工具传输方式。

## 让评审始终关联到正确的话题

对代码工作来说，评审属于交接工作的回复话题或私聊，而不只是智能体详情页。

- 如果智能体仍然在默认会话工作目录里工作，评审会自动回退到那里
- 如果这次工作属于某个回复话题，智能体应该把自己的评审上下文关联到这个话题，让用户直接从话题里的“查看变更”进入评审
- 如果这次工作是在私聊里交接，智能体可以把评审上下文关联到这个私聊；普通频道评审上下文不是受支持的交接入口
- 如果智能体为了实际代码改动切到了另一个项目目录，就应该更新话题评审上下文，让用户评审看到正确的目录和 compare 默认值
- 如果产物只是普通目录，而不是可比较的代码变更，就应当明确设置目录评审上下文

实践上只需要记住四条：

- 当讨论话题本身就是评审交接点时，优先使用话题拥有的评审上下文；多个智能体协作时，每个智能体保留自己的话题评审入口
- 当工作是在私聊里交接时，使用私聊拥有的评审上下文
- 只有当真正的评审对象变了，才设置显式代码评审上下文
- 只有目录产物，才使用目录评审上下文
- 用户手动改评审上下文的语义是兜底或救场，不是永久压住智能体后续更新

## 常见误区

- 误区一：智能体越多越强
- 误区二：出问题一定是提示词问题
- 误区三：一个智能体应该同时覆盖所有协作场景

多数情况下，真正影响效果的是角色边界、机器稳定性和团队使用习惯。

## 下一步

- [机器](../machines/README.md)
- [工作区管理](../workspace-admin/README.md)