背景与动机
Agent 的行为由模型、系统提示、工具和环境共同决定。只要其中任何一项变化，输出就可能变化。因此 Agent 定义应该像代码一样版本化。
不要把 Agent 配置当成随手修改的后台表单。生产环境里，配置变化也应该能审查、回滚和追踪。
Agent 定义包含什么
常见字段：
- 名称。
- 模型。
- 系统提示。
- 工具列表。
- 默认参数。
- 权限策略。
- 输出格式。
- 版本号。
这些内容共同决定 Agent 能力边界。
系统提示的四个维度
一个稳定的系统提示通常包含：
角色：你是谁能力：你能做什么约束：你不能做什么输出：你如何交付结果示例：
你是代码审查 Agent。你只指出 bug、回归风险和缺失测试。不要重写代码，不要夸奖实现。输出按严重程度排序，并附文件路径和行号。这种提示比“帮我 review 一下”更稳定。
不可变版本
推荐做法：
- 新配置生成新版本。
- 旧 Session 继续绑定旧版本。
- 新任务默认使用最新稳定版本。
- 出问题时可以回滚到上一版。
这样能避免一个正在运行的任务因为配置变化而行为突变。
配置即代码
如果可能，把 Agent 配置放进版本库：
agents/ code-review.yaml doc-writer.yaml bug-triage.yaml好处：
- 可以 code review。
- 可以看 diff。
- 可以回滚。
- 可以关联发布记录。
常见陷阱
- 直接在线修改系统提示，没有历史记录。
- 多个 Agent 共用一个过于宽泛的提示。
- 工具列表变化后不更新版本号。
- Session 不绑定版本，导致复现困难。
Agent 配置变更流程
修改 Agent 配置 ↓生成新版本 ↓跑最小回归测试 ↓新 Session 使用新版本 ↓旧 Session 继续绑定旧版本 ↓出问题时回滚默认版本这个流程比“直接改线上提示词”慢一点，但能换来可追踪和可复现。
一句话总结
Agent 定义应该像代码一样管理：可审查、可版本化、可回滚，并且不要让运行中的会话被配置变更打断。