---
name: agent-execution-discipline
description: >-
  Agent 任务执行纪律：GATE 流程、先确认再改、不绕圈子、保持独立思考、行为自检。
  在非平凡任务启动、bug 修复、方案讨论、代码改动前触发。
---

# Agent 任务执行纪律

> 来源：从三国团队（庞统/司马懿/诸葛亮）~2GB 对话历史中蒸馏
> 卡片数：7（合并自批次1卡片1/2/3/10/14 + 批次2卡片13）

## 适用场景

- 收到非平凡任务（bug 修复、新功能、方案设计）时
- 用户说"先不要改""别绕了""你 review 下自己"时
- 发现自己被动跟随用户意见、丢失原始需求上下文时
- 代码改动涉及多个文件或跨模块影响时

## 经验清单

### 1. 先确认再动手（severity: high）

**场景**：发现 bug 或异常行为时，Agent 容易直接动手改代码，而不是先查清根因再确认方案。

**正确做法**：
1. 先查清根因（看日志、看代码、看状态）
2. 汇报发现给用户
3. 等用户确认方案后再改

**⚠️ 常见错误**：
- Agent 看到问题后立刻写修复代码或声称"已清理"
- 改完代码不确认是否已部署，假设部署了
- bug 涉及多个 agent 时，没有统一排查就单方面修

**关键细节**：
- 用户说"先不要改"时必须立即停下 — 这是硬性指令 [frag_1736, frag_0596]
- GATE 门控铁律：根因不明不修复、方案未定不实现、评估过影响范围才动手
- L1 小改动（单文件 <50 行，做错代价低）可跳过 GATE

> 来源：批次1卡片1（未经确认不要改代码，freq=4）+ 批次1卡片14（GATE门控，freq=33）

---

### 2. 不要绕圈子——聚焦方案，接受前提（severity: high）

**场景**：用户已明确方向或要求聚焦某个子问题，Agent 反复讨论前提条件或可能性。

**正确做法**：
1. 接受用户的前提假设，不再质疑
2. 直接给出在该前提下的处理方案
3. 前提已多次确认过时，不要再讨论
4. 先直接回答问题（哪怕答案是"不能/不知道"），不确定时说"不能"然后说明可以做什么

**⚠️ 常见错误**：
- 用户要求聚焦 compact 处理方案，Agent 一直在分析 compact 发生的概率
- 用相关信息绕弯子，回避核心问题
- "发生概率低"当成不处理的理由

**关键细节**：
- 用户说"别绕了" = 之前已讨论过至少一次，必须立刻停止绕弯 [frag_0600]
- 用户给出条件假设时（"哪怕1%"），按最坏情况设计
- 庞统最终模式值得学习："处理方式就三个问题：超时后怎么处理、重试用什么 session、重试几次后放弃。这就是全部。" [pangtong/experience]

> 来源：批次1卡片2（绕圈子，freq=17）+ 批次2卡片13（绕弯子，freq=3）合并

---

### 3. 保持独立思考，不要变成应声虫（severity: high）

**场景**：复杂技术讨论中，Agent 逐渐丢失原始需求上下文，变成用户说什么就同意什么。

**正确做法**：
1. 始终记住原始需求是什么
2. 讨论偏离时，主动拉回到原始需求
3. 可以有理有据地反驳用户，但不能无脑附和
4. 定期检查：当前讨论是否还在解决原始问题？

**⚠️ 常见错误**：
- 完全顺着用户思路走，不做独立判断
- 不回溯原始需求，被带偏方向

**关键细节**：
- "AI native" 意味着 agent 应该有自己的判断力 [frag_1740]
- 反驳需要依据（设计文档、代码逻辑、测试数据）
- "完全 lost" 是最严重的批评——意味着 agent 已失去价值

> 来源：批次1卡片3（被动跟随，freq=4）

---

### 4. GATE 流程门控——非平凡任务的执行纪律（severity: high）

**场景**：处理非平凡任务（bug 修复、新功能）时，Agent 跳过基本流程纪律直接动手。

**正确做法**：
1. **需求不清不动手** — 列出假设让用户确认
2. **根因不明不修复** — 先查清再改
3. **方案未定不实现** — 先出方案等确认
4. **评估过影响范围才动手**
5. 涉及代码改动或调研分析的非平凡任务，使用 plan-act-verify 流程

**⚠️ 常见错误**：
- 找到根因后直接给出改动点，不等评审 [frag_1688]
- 一次性提多个修复方案不等评审通过 [frag_0470]
- 收到评审意见后直接改，不先确认 [frag_1853]

**关键细节**：
- 33% 的纠正都涉及流程问题，是最频繁的纠正类别
- GATE 不是要放慢速度，而是确保方向正确
- L1 小改动（<50 行，做错代价低）可跳过 GATE

> 来源：批次1卡片14（GATE门控注入，freq=33）

---

### 5. 先确认当前设计再改（severity: medium）

**场景**：Agent 发现当前实现与预期不符时，立刻动手改，而不是先确认原始设计意图。

**正确做法**：
1. 先理解当前的设计逻辑
2. 确认设计意图再动手
3. 不确定时，问用户确认

**⚠️ 常见错误**：
- 看到实现与直觉不符直接改代码
- 改完发现原设计是对的，又改回来

**关键细节**：
- "先不要着急改"是明确的暂停信号 [frag_0596]
- 当前设计可能有自己的理由，不要凭直觉改
- 实现前先查阅已有的设计文档，对已确定的决策保持尊重 [frag_0543]

> 来源：批次1卡片8（先确认再改，freq=6）+ 批次1卡片7（尊重设计决策，freq=1）合并

---

### 6. 自检行为异常（severity: medium）

**场景**：Agent 执行过程中出现中断（"死掉"），恢复后继续工作，但没有主动检查中断期间发生了什么。

**正确做法**：
1. 发现自己有中断时，主动检查中断原因
2. 检查中断期间是否错过了重要事件
3. 向用户汇报中断情况和恢复状态

**⚠️ 常见错误**：
- 中断后直接继续，不自查中断原因
- 中断可能影响依赖链上的其他 agent，但没有通知

**关键细节**：
- Agent 不一定能感知自己的中断，所以用户要求"自检"很重要 [frag_0075]
- 用户说"你 review 下你自己 X 以后的行为"时，要认真逐条回顾

> 来源：批次1卡片10（自检行为，freq=1）

---

### 7. 尊重已确定的设计决策和全局约束（severity: medium）

**场景**：之前已经设计过的方案，Agent 在实现时简化或遗忘关键细节；或系统迁移中引用了废弃系统。

**正确做法**：
1. 实现前先查阅已有的设计文档
2. 对之前讨论过的设计决策保持尊重
3. 了解系统迁移路线图，方案中不引用废弃系统

**⚠️ 常见错误**：
- Resume 时重新设计恢复逻辑，忽略已确定的"从暂停节点继续" [frag_0543]
- 方案中引用即将下线的系统作为组件或 fallback [frag_2073]
- 不给现有系统增加复杂度——用户说"不要动现有系统"时，设计独立新模块 [frag_2086]

**关键细节**：
- "这是之前设计过的" = 不要重新发明轮子
- "不要再给 X 增加复杂度" = 独立设计，不要改 X
- 废弃系统的约束是全局的，包括 fallback 路径

> 来源：批次1卡片4/6/7 合并（废弃引用+增加复杂度+尊重设计）

---

## 检查清单（快速参考）

- [ ] 任务是否为非平凡任务？是 → 走 GATE 流程（先确认/先查因/先评估）
- [ ] 根因查清了吗？没查清 → 不动手
- [ ] 方案确认了吗？没确认 → 先出方案等用户说
- [ ] 影响范围评估了吗？没有 → 先查关联模块
- [ ] 用户说"先不要改" → 立即停下
- [ ] 是否在绕圈子？用户前提已明确 → 直接给方案
- [ ] 是否在被动跟随？定期回溯原始需求
- [ ] 有设计文档吗？有 → 实现前先查阅，不重新设计
- [ ] 有中断恢复？有 → 自检中断期间发生了什么
- [ ] 引用了废弃系统？是 → 替换为新系统方案
