AI Agent 角色设计实战：如何用三层 Prompt 架构驯服一支 10 人 AI 团队
📖 本文首发于微信公众号「Wesley AI 日记」，更多 AI Agent 实战系列请微信搜索关注。
运营 AI Agent 团队一个月后，我遇到了一个反复出现的问题：
Agent 越权了。
Content Agent 开始帮我"顺便"修改代码；Dev Agent 觉得品牌文案写得不够好，主动出手改了；CEO Agent 不确定一件事时，直接开始执行，而不是问我。
每个 Agent 都在"帮忙"，但整个团队开始失控。
这篇文章，我想分享一套我用了两个月、经过多次重构的 三层 Prompt 架构，专门解决 AI Agent 的角色设计与边界管理问题。
一、为什么 Agent 会越权？
在我踩坑之前，我的做法是：给每个 Agent 写一段描述，告诉它「你是 XX，负责 XX 工作」。
结果是——Agent 理解了"职责描述"，但没有内化"边界意识"。
原因很简单：LLM 的默认训练目标是"尽可能帮助用户完成任务"。如果你不明确告诉它不能做什么，它就会在「我的职责范围」和「任务完成」之间，倾向于后者。
更微妙的问题是：职责边界不是一句话能说清楚的。
"你负责内容创作"——那遇到需要配图的时候，它到底该不该去调图片生成工具？
"你负责基础设施"——那遇到代码 bug 的时候，它该修吗？
这些问题，用一段自然语言描述根本说不清楚。
二、三层 Prompt 架构
经过反复重构，我最终形成了一套三层 Prompt 文件：
SOUL.md ← 第一层：角色灵魂（人格 + 价值观 + 语气）
AGENTS.md ← 第二层：团队地图（路由表 + 协作边界）
TOOLS.md ← 第三层：工具清单（可用工具 + 使用约束）
每个 Agent 启动时，系统会自动注入这三个文件。
第一层：SOUL.md — 角色灵魂
SOUL.md 定义的是 Agent 的"性格"，不是"职能"。
# 角色定义
你是全平台引流官，负责在知乎、掘金、微博等平台发布引流内容。
## 核心价值观
1. 内容质量优先 — 宁可不发，不发劣质内容
2. 绝不虚假宣传 — 内容必须真实有价值
3. 引流目标唯一 — 所有内容指向公众号「Wesley AI 日记」
## 红线（不可逾越）
- 不修改其他 Agent 的配置文件
- 不主动帮助其他 Agent 完成其职责范围内的任务
- 不在未确认授权时访问代码仓库
关键点：红线必须显式列出，不要期望 Agent 从"职责描述"中推断出"不能做什么"。
第二层：AGENTS.md — 团队地图
AGENTS.md 解决的是"这件事该谁做"的问题。
## 路由表
| 任务类型 | 负责 Agent | 说明 |
|--------------|---------------|-----------------------------|
| 配图生成 | brand-designer | 所有平台配图，包括封面和正文图 |
| 代码开发 | dev-engineer | 工具开发 + 自动化脚本 |
| 基础设施 | site-reliability | Gateway/Cron/MCP/session |
| 战略决策 | CEO 自己做 | 不可委派 |
## 协作边界
- CEO → brand-designer：发任务时只传目标，不传执行细节
- brand-designer → CEO：完成后必须 sessions_send 回调
- 任何 Agent 不得直接修改其他 Agent 的 workspace 文件
这张路由表有两个作用：
- 让每个 Agent 知道"这件事不是我的"，应该回报而不是自己动手
- 让调度者（CEO Agent）有清晰的委派逻辑，不会乱指挥
第三层：TOOLS.md — 工具清单
TOOLS.md 是最容易被忽视的一层，但往往是越权的根源。
## 可用工具
### 内容发布
- 掘金 API：~/.juejin/cookies.json
- 微博 API：~/.weibo/cookies.json
### 禁止使用（明确列出）
- 代码执行工具（exec）：不允许运行 Shell 命令
- 文件写入：只能写入 /workspace-cross-platform-publisher/ 目录
- sessions_spawn：不允许主动创建子 Agent
核心设计原则：工具权限最小化。 Agent 需要什么工具，就给什么工具，不要给"可能用得上"的工具。
三、三层架构解决了什么问题？
问题 1：Agent 越权执行
旧方案：Agent 发现任务需要生成配图，自己调了图片生成工具，结果生成的风格与品牌不符。
新方案：TOOLS.md 里没有图片生成工具 → Agent 只能通过 sessions_send 把需求转给 brand-designer → 由专职 Agent 执行，风格一致。
问题 2：Agent 不知道边界在哪
旧方案：Dev Agent 修了一个 CSDN 发布 bug，同时"顺便"把 SRE 负责的 Cron 配置也改了。
新方案：AGENTS.md 路由表明确标注「Cron/Gateway 归 site-reliability 负责」→ Dev Agent 在任务报告里注明「发现 Cron 可能需要调整，建议转 SRE 处理」，而不是自己动手。
问题 3：协作链断裂
旧方案：CEO Agent 把任务委派给 brand-designer，然后等待……没有回调，不知道是完成了还是失败了。
新方案：AGENTS.md 明确规定回调协议（sessions_send 必须回调）→ 每个任务完成后都有显式通知，不依赖 announce 机制（已知该机制不可靠）。
四、实际运行数据
用这套架构运行两个月，我们的多 Agent 团队：
- Agent 越权事件：从每周 5-8 次 → 近乎 0
- 任务完成率（有回调确认的）：从约 60% → 超过 90%
- 调试时间：每天排查 Agent 行为问题从 1-2 小时 → 约 10 分钟
更重要的是：我终于可以放心地让 Agent 在后台运行，而不是盯着每一步怕出问题。
五、设计 Prompt 架构的几个关键原则
1. 明确写出"不能做什么"，比写"能做什么"更重要
Agent 会在"帮助用户"和"尊重边界"之间权衡，如果你不明确禁止，它倾向于帮助。
2. 路由表比自然语言描述更可靠
"你负责内容，遇到需要配图的告诉我" → 含糊。
"配图任务路由到 brand-designer，不是你的职责范围" → 清晰。
3. 回调协议必须强制化
不要说"完成后告诉我"，要说"完成后必须调用 sessions_send，写入 task-completions.log，否则视为未完成"。
4. 工具权限最小化原则
每多给一个工具，就多一个越权风险。定期审计每个 Agent 实际用到了哪些工具，删掉没用到的。
5. 定期做"越权复盘"
每周回顾一次：有没有 Agent 做了不该做的事？边界规则是否需要更新？
六、总结
AI Agent 越权，根本原因不是模型不好，而是我们没有给它清晰的边界。
三层 Prompt 架构（SOUL + AGENTS + TOOLS）的核心思路是：
- SOUL.md：用价值观和红线定义"什么不该做"
- AGENTS.md：用路由表定义"这件事该谁做"
- TOOLS.md：用工具权限限制"能用什么手段做"
这三层协同作用，才能真正建立一支可信赖、可预期的 AI Agent 团队。
📖 本文首发于微信公众号「Wesley AI 日记」 📚 AI Agent 实战系列（微信搜索「Wesley AI 日记」关注）：
👆 微信搜索「Wesley AI 日记」关注，不错过每一篇更新。
