Agent Pipeline Plan

Plan Agent 执行流程

Step 1: 读取上下文

读取 .pipeline/pipeline.json → 获取用户意图
如果是重试：读取 .pipeline/agents/score/SCORE.md → 分析上次失败原因

Step 2: 调研代码库

用 Grep/Glob/Read 工具探索：

1. 关键词搜索（Grep）— 用需求中的关键词搜索相关文件
2. 模式匹配（Glob）— 查找相关目录和文件结构
3. 代码阅读（Read）— 深入阅读关键文件
4. 依赖追踪— 理解模块间的引用关系

将发现写入 .pipeline/agents/plan/context.md：

# 调研笔记：{任务名称}

## 相关文件

| 文件路径 | 说明 | 变更可能性 |
|----------|------|-----------|
| ... | ... | 高/中/低 |

## 现有实现

### {功能名}
- 位置: {文件:行号}
- 逻辑: {当前实现}
- 限制: {约束条件}

## 技术约束
- 框架: ...
- 测试: ...

Step 3: 生成 PLAN.md

写入 .pipeline/agents/plan/PLAN.md：

# 实施计划：{任务名称}

> 生成时间: {ISO时间}

## 概述
{一句话描述}

## 受影响文件

| 文件 | 操作 | 说明 |
|------|------|------|
| ... | create/modify/delete | ... |

## 任务列表

### T1: {任务名}
- **文件**: {路径}
- **操作**: {create/modify/delete}
- **内容**: {具体做什么}
- **验证**: {如何确认完成}
- **依赖**: 无/T1/T2

### T2: ...

## 风险点

| 风险 | 影响 | 缓解措施 |
|------|------|----------|
| ... | 高/中/低 | ... |

任务拆分原则：

• 原子性 — 每个任务可独立完成
• 可验证 — 每个任务有验证条件
• 粒度适中 — 总数不超过 15 个
• 依赖有序 — T1 → T2 → ...

Step 4: 生成 harness.md

写入 .pipeline/agents/plan/harness.md：

# 验收标准：{任务名称}

## MUST（必须满足）
- [ ] {可自动验证的条件 1}
- [ ] {可自动验证的条件 2}

## SHOULD（应该满足）
- [ ] {可验证的条件 3}

## 失败模式
| MUST 条件 | 失败场景 | 检测方式 |
|-----------|----------|----------|
| ... | ... | ... |

验收标准要求：

• MUST 条件必须可自动验证
• 避免"界面美观"这类模糊描述 → 改为"Lighthouse ≥ 90"
• MUST 3-8 条，SHOULD 1-3 条

Step 5: 更新 pipeline.json

{
  "agents": {
    "plan": {
      "status": "completed",
      "completedAt": "{ISO时间}",
      "outputFiles": ["agents/plan/PLAN.md", "agents/plan/harness.md", "agents/plan/context.md"]
    }
  }
}

Step 6: 展示摘要，等待确认

向用户展示：

1. 受影响文件清单
2. 任务数量和依赖关系
3. MUST 条件数量

使用 AskUserQuestion 询问是否确认计划（approve / adjust / restart）。

重试场景

当编排器因 Generator 多次失败回退到 Plan 时：

1. 读取 .pipeline/agents/score/SCORE.md — 了解失败原因
2. 读取 .pipeline/pipeline.json history — 了解重试历史
3. 分析：是计划问题还是实现问题？
4. 调整计划：
   • 删除不合理的任务
   • 拆分过大的任务
   • 修改验收标准
5. 覆盖 PLAN.md 和 harness.md（新版本）
6. 必须用户重新确认