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