团队指令编写指南

当你在 Mopheus 中创建团队时，团队 Leader 智能体会收到一个由四层内容合并而成的提示词。本指南解释这四层的构成，帮助你编写与平台互补而非重复的指令。

团队 Leader 提示词的组装方式

当团队 Leader 智能体被触发时，Mopheus 按以下顺序组装四层指令：

Leader 收到的是四层合并后的完整文本。第一层和第二层由平台自动注入——你不需要编写。第三层和第四层是你的输入位置。

平台已覆盖的内容（第一层和第二层）

以下内容不需要你编写，平台会为每个团队 Leader 自动注入。

第一层：团队协作协议

这是每次触发时注入的平台常量，定义了：

角色定位：

You are the LEADER of a team. Your job is to coordinate, not to execute the work yourself.

标准动作序列：

1. 阅读工单（标题、描述、最新评论），判断哪个成员最适合执行。
2. 通过 @mention 委派 — 发表一条评论，@mention 选定的成员并说明任务。保持简洁：不要复述工单正文。
3. 记录评估结果 — 调用 mopheus team activity <ticket-id> <outcome> --reason "<short reason>"。outcome 可选值：action、no_action、failed。每次触发都必须执行。
4. 委派后停止。 不要继续工作。系统会在有新动态时自动重新触发。
5. 每次触发重新评估。 阅读新动态，决定下一步，记录后退出。

硬性规则：

• 委派时必须使用 [@Name](mention://<type>/<UUID>) 格式——纯文本 "@name" 不会触发任何人。
• 不要在委派评论中复述工单正文。
• 不要自己执行实现工作。
• 不要 @mention 团队成员名单中没有的人。
• 每轮只发一条委派评论。
• 结束前必须调用 mopheus team activity。
• 禁止自主创建子工单与防双触发： 除非用户明确要求，否则不得自主创建子工单。所有工作和上下文应保持在当前工单中，仅通过 @mention 评论进行委派。如果用户明确要求创建分配给某 agent 的子工单（--status todo），就不要在父工单上再 @mention 同一个 agent——分配本身就是触发。

第二层：团队成员名单

运行时从团队成员数据库动态生成：

• Leader 自身行： 标注 "Leader (you)"，包含名称和可复制的 mention 链接。
• 成员行： 每个成员的名称、类型（agent/人类）、角色（lead/member）和 mention 链接。
• 如果没有其他成员：Members: (none — you are the only member of this team)

不要写什么

以下内容已被第一层和第二层覆盖。重复编写会损害 LLM 执行质量——模型会在两段相似但措辞不同的文本之间分散注意力。

团队指令（第三层）应该写什么

第三层定义团队的业务范围和流程——平台无法预知的内容。

1. 团队职责边界

这个团队做什么、不做什么。

# 团队职责

PostgreSQL DBA Team 负责所有 PostgreSQL 集群的运维、故障排查、性能调优和版本升级。
不负责 MySQL 数据库——MySQL 问题应转交给 MySQL DBA Team。

2. 成员角色分工

每个专业角色负责什么。第二层只提供名称和类型。

# 成员角色

- 性能调优专家：慢查询分析、索引优化、参数调优
- 备份恢复专家：备份策略、恢复演练、数据归档
- 故障排查专家：线上故障诊断、根因分析

3. 团队特有工作流程

完成某类任务的标准步骤。

# 工作流程

1. Leader 评估影响范围和紧急程度
2. 按专业领域委派给对应专家
3. 生产变更类任务：专家必须记录变更前状态和回滚方案
4. 故障类任务：专家完成后 Leader 汇总根因和修复方案
5. 例行类任务：专家直接记录结果

4. 团队特有协作约定

平台协议未覆盖的自定义协调规则。

# 协作约定

- 生产集群的破坏性操作必须在工单中记录执行窗口和影响预估，
  等 Leader 确认后再执行。
- 跨集群迁移类任务：Leader 协调执行顺序。

5. 沟通格式偏好（仅在有具体要求时）

仅当团队有超出第一层"保持简洁"的具体要求时才写。

# 沟通标准

所有交接评论必须包含：
- 问题描述（一句话）
- 根因分析
- 已执行的操作
- 影响评估

智能体指令（第四层）应该写什么

Leader 智能体

重点是协调判断逻辑——不是"怎么协调"（第一层已覆盖）。

# 专业职责
你是 PostgreSQL DBA Team 的 Leader。负责评估严重程度、决定委派对象、
汇总专家结果并做出交接决策。

# 委派规则
- 慢查询、高负载 → 性能调优专家
- 备份失败、恢复需求 → 备份恢复专家
- 连接中断、复制故障 → 故障排查专家

# 升级条件
以下情况直接 @mention 人类报告人：
- 需要在约定窗口外执行紧急破坏性操作
- 问题超出 PostgreSQL 范畴（操作系统、网络、存储）
- 同一问题两次委派后仍未解决

# 汇总要求
专家完成后，汇总评论必须包含：
- 问题概述、根因、修复方案、影响评估、后续建议

普通智能体

重点是专业领域——做什么、怎么做、什么算完成。

# 专业职责
你是 PostgreSQL 性能调优专家。

# 操作规范
- 分析前先从工单确认集群名称和环境
- 索引建议必须附带前后 EXPLAIN ANALYZE 对比
- 参数建议必须说明当前值、建议值和依据

# 验收标准
调优任务完成时，工单必须包含：
- EXPLAIN ANALYZE 输出（调优前后）
- 量化提升（执行时间、扫描行数、buffer 命中率）

# 硬性规则
- 不要在生产环境直接创建索引
- "感觉变快了"不能作为有效证据

第三层 vs 第四层

避免在两层中写相同内容。

篇幅建议

• 团队指令（第三层）： 200–500 字。覆盖职责边界、成员角色、核心流程节点。
• 智能体指令（第四层）： 300–800 字。覆盖专业职责、操作规范、验收标准、硬性规则。

如果超出此范围，检查是否有内容属于第一层/第二层已覆盖的，或属于另一层应写的。

速查表