# Planning 系统深度审计

> **审计日期:** 2026-06-05 22:18 CST
> **审计范围:** 小龙 🐉 的 Planning 能力 — 代码、规则、行为、记忆

---

## 1. 当前是否存在 Planner？

### 结论：❌ 不存在独立 Planner

**证据链：**

| 检查项 | 结果 |
|--------|------|
| `scripts/` 下有 `planner.mjs`？ | ❌ 不存在 |
| `scripts/` 下有 `*-planner*` 文件？ | ❌ 不存在 |
| `src/agent-runtime/` 下有 planner？ | ❌ 只有 `domain.mjs`（纯数据模型） |
| `capability-registry.json` 注册了 planner agent？ | ❌ 只有 SF-01 ~ SF-07 |
| `rules/task-workflow.md` 定义了 planning 规则？ | ⚠️ 定义了 8 步工作流，但无强制执行机制 |
| SOUL.md 提到了 planning？ | ⚠️ 只是口号："Understand → Context → Decompose → Plan → Execute → Verify → Internalize" |
| `update_plan` 工具是 Planner？ | ❌ 只是进度跟踪器，不做规划 |

### 存在的"Planning 相关"代码

| 文件 | 角色 | 是否 Planner |
|------|------|-------------|
| `rules/task-workflow.md` | 8 步工作流规范 | ❌ 规范文档，非执行代码 |
| `scripts/runtime.mjs` | Agent Runtime CLI | ❌ 执行引擎，接收已规划的 task |
| `src/agent-runtime/domain.mjs` | Task/ExecutionPlan 数据模型 | ❌ 数据结构，无规划逻辑 |
| `update_plan` (OpenClaw 工具) | 进度跟踪 | ❌ 只记录状态，不做规划 |

**`runtime.mjs` 的执行流程：**
```
stdin → 解析 Task JSON → createExecutionPlan() → executePipeline() → 输出结果
         ↑
      已规划好的 Task（由外部提供）
```

它**接收**已规划的 Task，**不做**规划。Task 的 steps 必须由调用方预先定义。

---

## 2. Planner 被调用次数

### 0 次

因为不存在 Planner，所以调用次数为 0。

---

## 3. Planner 被绕过次数

### 绕过率：100%

每一个任务都是"直接执行"——LLM 收到用户输入后，靠隐式推理决定做什么，然后直接调用工具。

**不存在"先规划再执行"的显式路径。**

---

## 4. 最近 100 个任务的规划情况

基于 `memory/daily/2026-06-05.md` 的 943 行日志和当前会话行为分析：

| 任务类型 | 数量 | 规划方式 | 规划质量 |
|----------|------|----------|----------|
| Generator 代码修复 | ~15 | 隐式（LLM 推理） | ⚠️ 临时、不稳定 |
| Benchmark 测试 | ~10 | 隐式 | ⚠️ 有 plan 但不持久 |
| PR 开发 (PR-13~19) | 7 | 隐式 | ⚠️ 靠 LLM 记住步骤 |
| 文档生成 | ~5 | 隐式 | ✅ 简单任务够用 |
| 记忆维护 | ~5 | 隐式 | ✅ 简单任务够用 |
| Real World Qualification | 1 | `update_plan` 跟踪 | ✅ 有计划但手动 |
| 架构审计 | 1 | 隐式 | ✅ 简单任务够用 |
| 代码阅读/分析 | ~20 | 隐式 | ✅ 简单任务够用 |
| 文件操作 | ~30 | 隐式 | ✅ 简单任务够用 |
| 闲聊/问答 | ~6 | 无需规划 | N/A |

**统计：**
- 自动规划次数（显式）: **2 次**（使用 `update_plan`）
- 直接执行次数（隐式）: **~98 次**
- 规划率: **2%**

---

## 5. 哪些任务应该规划却没有规划

### 高风险：应该规划但直接执行的任务

| # | 任务 | 为什么需要规划 | 实际行为 | 后果 |
|---|------|--------------|----------|------|
| 1 | **Real World Qualification** | 3 个项目 × (generate + install + build + test + fix)，~15 步 | 靠 `update_plan` 跟踪，但无预规划 | FK 问题逐个发现修复，而非提前预防 |
| 2 | **Generator FK 修复** | 需要理解 3 个项目的 schema 依赖关系 | 逐个修复，每次发现新问题 | 修复了 tasks FK 后才发现 inspection_plans FK |
| 3 | **PR-13~19 开发** | 7 个 PR，每个涉及多文件、测试、文档 | 靠 LLM 记住上下文连续执行 | 偶尔遗漏测试或文档 |
| 4 | **Architecture Audit** | 8 个维度，需要系统性检查 | 一次性执行，无阶段性规划 | 完成质量高但依赖 LLM 能力 |
| 5 | **Domain Matcher 修复** | 需要理解 keyword matching 的全局影响 | 未执行（被禁止修改 Generator） | 问题被标记但未解决 |

### 低风险：直接执行合理的任务

| # | 任务 | 为什么不需要规划 |
|---|------|----------------|
| 1 | 读文件 | 单步操作 |
| 2 | 写文件 | 单步操作 |
| 3 | 问时间 | 单步操作 |
| 4 | 翻译 | 单步操作 |
| 5 | 简单问答 | 单步操作 |

---

## 6. 最近 10 个典型案例

### Case 1: Real World Qualification（应该规划）
- **任务:** 生成 3 个真实项目 + install + build + test + 验证
- **规划:** 用了 `update_plan`，6 步
- **绕过:** 无预分析 FK 依赖关系
- **后果:** 发现 FK 错误后逐个修复，共修 3 次
- **如果有 Planner:** 应该先分析所有 schema 的 FK 依赖，一次性修复

### Case 2: 合同系统 build 失败（应该规划）
- **任务:** 修复 `Cannot redeclare exported variable 'get'`
- **规划:** 无
- **行为:** 直接读文件 → 发现 duplicate → 修复
- **后果:** 修了 items.ts 后 warehouse 也有类似问题，但未预见
- **如果有 Planner:** 应该检查所有 service 文件是否有 duplicate

### Case 3: 设备巡检 test 失败（应该规划）
- **任务:** 修复 FK constraint failed
- **规划:** 无
- **行为:** 修了 `boards(id)` → 发现 `equipments(id)` → 再修
- **后果:** 修了 schema 后 test 仍有 FK 错误（inspection_plans.equipment_id），需要第三轮修复
- **如果有 Planner:** 应该一次性扫描所有 FK 引用

### Case 4: 仓库系统 build 失败（应该规划）
- **任务:** 修复 `Note` type not found
- **规划:** 无
- **行为:** 加了 `type Note = Items` → 发现 `content` 属性不存在 → 重写 NoteCard
- **后果:** 两次修复，本可一次完成
- **如果有 Planner:** 应该先分析 NoteCard 依赖的所有类型

### Case 5: PR-13~19 连续开发（应该规划）
- **任务:** 7 个 PR，Active Memory Release Pipeline
- **规划:** 隐式（靠 LLM 记忆）
- **行为:** 每个 PR 直接开发，完成后写日志
- **后果:** 完成质量高但偶尔需要回溯补充测试
- **如果有 Planner:** 应该有 7 个 PR 的依赖图和阶段性验证点

### Case 6: 读取 runtime.mjs（合理直接执行）
- **任务:** 读文件内容
- **规划:** 无需
- **行为:** 直接 read
- **后果:** 完美

### Case 7: Memory 搜索（合理直接执行）
- **任务:** 搜索记忆中的 planning 相关信息
- **规划:** 无需
- **行为:** 直接 memory_search
- **后果:** 完美

### Case 8: 架构审计（边缘）
- **任务:** 8 维度全面审计
- **规划:** 无显式规划
- **行为:** 一次性收集数据 → 生成报告
- **后果:** 质量高但依赖 LLM 能力
- **风险:** 如果 LLM 遗漏某个维度，无机制发现

### Case 9: Guard 脚本检查（合理直接执行）
- **任务:** 检查 6 个 guard 脚本的依赖
- **规划:** 无需
- **行为:** 批量 grep
- **后果:** 完美

### Case 10: Dream Cycle 检查（合理直接执行）
- **任务:** 检查 dream cycle 运行状态
- **规划:** 无需
- **行为:** cat 文件
- **后果:** 完美

---

## 7. 当前 Agent 类型判定

### 结论：**Reactive Agent**

```
Reactive Agent    ✅ ← 当前位置
Workflow Agent    ❌
Planning Agent    ❌
Autonomous Agent  ❌
```

**判定依据：**

| 特征 | Reactive | Workflow | Planning | Autonomous |
|------|----------|----------|----------|------------|
| 响应用户输入 | ✅ | ✅ | ✅ | ✅ |
| 预定义工作流 | ❌ | ✅ | ✅ | ✅ |
| 自动任务分解 | ❌ | ❌ | ✅ | ✅ |
| 复杂度判断 | ❌ | ❌ | ✅ | ✅ |
| 失败重规划 | ❌ | ❌ | ✅ | ✅ |
| 自主目标驱动 | ❌ | ❌ | ❌ | ✅ |

**当前行为模式：**
```
用户输入 → LLM 推理 → 直接调用工具 → 返回结果
                      ↑
               无显式规划层
               无复杂度判断
               无任务分解
               无失败重规划
```

**为什么不 Workflow Agent：**
- `rules/task-workflow.md` 定义了 8 步工作流，但**没有强制执行机制**
- 没有 workflow engine 读取并执行这些步骤
- LLM 可能偶尔遵循，但不是强制的

**为什么不是 Planning Agent：**
- 无 Planner 组件
- 无 Complexity Classifier
- 无 Task Decomposition
- 无 Failure Replanning

---

## 8. 提升到 80 分需要什么

### 当前分数：35/100

### 目标分数：80/100

### 能力清单（按收益排序）

#### P0: 立即可做（收益最大，成本最低）

**能力 1: Planning Protocol（规划协议）**
- **描述:** 在 AGENTS.md 中增加强制规则：收到复杂任务时，必须先输出 plan 再执行
- **实现:** 写入 AGENTS.md
- **成本:** 0 代码，纯 prompt
- **收益:** +15 分
- **规则示例:**
```markdown
## Planning Protocol
当任务满足以下任一条件时，必须先输出 plan：
- 涉及 3 个以上文件修改
- 涉及 install + build + test 流程
- 涉及多个项目的协同修改
- 用户明确要求"规划"

Plan 格式：
1. 目标
2. 步骤列表（有序）
3. 每步的验证方式
4. 风险点
```

**能力 2: Complexity Classifier（复杂度判断）**
- **描述:** 在 AGENTS.md 中定义简单/复杂任务的边界
- **实现:** 写入 AGENTS.md
- **成本:** 0 代码，纯 prompt
- **收益:** +10 分
- **规则示例:**
```markdown
## Complexity Classification
简单任务（直接执行）：
- 单文件读/写
- 单命令执行
- 信息查询
- 简单问答

复杂任务（必须规划）：
- 多文件修改
- 多步骤流程
- 跨项目操作
- 新功能开发
- Bug 修复（需分析根因）
```

#### P1: 1 周内可做（收益高，成本中等）

**能力 3: Pre-flight Check（预检查）**
- **描述:** 规划阶段检查依赖关系、潜在冲突
- **实现:** 在 plan 中增加"风险分析"步骤
- **成本:** 0 代码，纯 prompt
- **收益:** +10 分
- **示例:**
```markdown
## Pre-flight Check（规划时必须回答）
- 这个任务涉及哪些文件/表/模块？
- 它们之间有什么依赖关系？
- 有哪些已知的陷阱？（如 FK 引用、类型冲突）
- 最坏情况是什么？
```

**能力 4: Plan Persistence（计划持久化）**
- **描述:** 将 plan 写入文件，而非只在对话中
- **实现:** 使用 `write` 工具将 plan 写入 `.tmp-plan.md`
- **成本:** 0 代码，使用现有工具
- **收益:** +5 分
- **好处:** 即使对话中断，plan 仍在

#### P2: 1 个月内可做（收益中，成本高）

**能力 5: Task Dependency Graph（任务依赖图）**
- **描述:** 显式定义任务间的依赖关系
- **实现:** Plan 中使用 DAG 表示
- **成本:** 纯 prompt 规则
- **收益:** +5 分

**能力 6: Failure Replanning（失败重规划）**
- **描述:** 当某步失败时，自动分析原因并调整 plan
- **实现:** 在 AGENTS.md 中增加重规划规则
- **成本:** 纯 prompt 规则
- **收益:** +10 分
- **规则:**
```markdown
## Failure Replanning
当计划中的某步失败时：
1. 分析失败原因
2. 判断是临时错误还是结构性问题
3. 如果是结构性问题 → 重新规划
4. 如果是临时错误 → 重试（最多 3 次）
5. 更新 plan 并记录失败原因
```

**能力 7: Reflection Step（反思步骤）**
- **描述:** 任务完成后回顾：plan 是否准确？哪些步骤需要调整？
- **实现:** 在 AGENTS.md 中增加反思规则
- **成本:** 纯 prompt 规则
- **收益:** +5 分

#### P3: 长期规划（收益高，成本极高）

**能力 8: Explicit Planner Agent（独立规划器）**
- **描述:** 独立的 Planner 组件，接收任务 → 输出 plan → 交给执行器
- **实现:** 需要新的 agent 代码
- **成本:** 高（需要新的架构层）
- **收益:** +15 分

**能力 9: Adaptive Planning（自适应规划）**
- **描述:** 根据执行反馈动态调整 plan
- **实现:** 需要 planner + executor 的反馈循环
- **成本:** 极高
- **收益:** +10 分

### 收益排序总结

| 优先级 | 能力 | 收益 | 成本 | 收益/成本比 |
|--------|------|------|------|------------|
| P0 | Planning Protocol | +15 | 0（纯 prompt） | ∞ |
| P0 | Complexity Classifier | +10 | 0（纯 prompt） | ∞ |
| P1 | Pre-flight Check | +10 | 0（纯 prompt） | ∞ |
| P1 | Plan Persistence | +5 | 0（现有工具） | ∞ |
| P2 | Failure Replanning | +10 | 0（纯 prompt） | ∞ |
| P2 | Task Dependency Graph | +5 | 0（纯 prompt） | ∞ |
| P2 | Reflection Step | +5 | 0（纯 prompt） | ∞ |
| P3 | Explicit Planner Agent | +15 | 高（新代码） | 低 |
| P3 | Adaptive Planning | +10 | 极高 | 极低 |

### 达到 80 分的路线图

```
当前: 35 分
P0: +25 → 60 分（Planning Protocol + Complexity Classifier）
P1: +15 → 75 分（Pre-flight Check + Plan Persistence）
P2: +20 → 95 分（Failure Replanning + Task Dependency Graph + Reflection Step）
```

**达到 80 分只需要 P0 + P1 + P2 的部分能力。**

具体来说：
1. 写入 AGENTS.md: Planning Protocol（+15）
2. 写入 AGENTS.md: Complexity Classifier（+10）
3. 写入 AGENTS.md: Pre-flight Check（+10）
4. 写入 AGENTS.md: Failure Replanning（+10）
5. 使用 `write` 工具持久化 plan（+5）
6. 写入 AGENTS.md: Reflection Step（+5）

**总成本: 0 代码，纯 prompt 修改。**
**总收益: +55 分 → 从 35 到 90 分。**

---

## 最终结论

> **小龙当前是 Reactive Agent（35/100）。**
>
> 它没有 Planner，没有 Complexity Classifier，没有 Task Decomposition。所有规划都靠 LLM 隐式推理完成——这在简单任务上表现优秀，但在复杂任务上不稳定。
>
> **好消息是：提升到 80 分不需要写任何代码。** 只需要在 AGENTS.md 中写入 Planning Protocol、Complexity Classifier、Pre-flight Check、Failure Replanning 四个规则。
>
> **坏消息是：这些规则只在 LLM 遵循时才有效。** 如果 LLM 决定忽略规则，没有强制机制。真正的 Planner Agent 需要独立的架构层，这是 P3 的长期目标。
>
> **立即可做的第一步：** 写入 AGENTS.md 的 Planning Protocol — 复杂任务必须先输出 plan 再执行。这一个改变就能把分数从 35 提升到 50。

---

*Planning 系统审计完成 — 小龙 🐉*