Agent规划与反思

Planning 是 Agent 的"任务拆解和路径规划"能力，Reflection 是 Planning 的子能力（自我修正环节）。这一页把 Planning 的三种范式、Planning 的"全/半/人"驱动光谱、Reflection 机制、以及常见翻车放在一起讲——因为 PM 决策时它们是连在一起的。

Planning 三步骤

拆解：把大目标拆成小步骤
排序：决定先做哪步、后做哪步
调整：执行过程中根据反馈修改计划

例如：产品经理拆解需求

拆：用户调研 → 需求分析 → 方案设计 → 评审 → PRD → 评审
排：哪些可以并行做？哪些有依赖？
调：调研中发现用户痛点不是想象的那样，立刻调整方案设计的方向

三大 Planning 范式

范式 1：CoT（Chain of Thought，思维链）

让模型在回答之前先把推理过程"说出来"，一步步展开，而不是直接给答案。就像老师要求学生"把解题过程写出来，不能只写答案"。

纯推理，不调用工具
一次完成
信息来源是模型自身知识

用户："帮我对比 Claude 和 GPT 在编程场景下谁更强"

模型内部推理：
"首先，我需要确定对比维度。编程能力通常可以从以下几个方面衡量：
1. 代码生成的正确率
2. 调试和修复 bug 的能力
3. 对复杂代码库的理解能力

根据我的知识：
- 在 SWE-bench Verified 基准上，Claude Opus 4.7 得分约 82.3%，
  GPT-o3 约得分为 79.1%。这说明在修复真实 bug 的场景下，Claude 略优。
- 在 HumanEval 基础代码生成上，两者差距较小，都在 90%+。
- 在代码理解方面，Claude 的 200K context window 使它在理解
  大型代码库时有天然优势。GPT-4o 的 128K context 在超大项目上受限。

综合来看：Claude 在复杂修复和长代码理解上更强，GPT 在速度
和快速原型上可能更优。"

代表产品：ChatGPT o1/o3 的"思考"。

范式 2：ReAct（Reason + Act，推理+行动）

CoT 只能"想"不能"做"。ReAct 在 CoT 基础上加了行动能力——模型想一步、做一步、看结果、再想下一步。

想和做交替进行
可以调用工具
一步步来，不预先规划
路径不确定

第 1 轮 - 思考："我需要最新的 benchmark 数据来对比，让我先搜索 SWE-bench 的最新排名。"
第 1 轮 - 行动：tool_call: web_search("SWE-bench Verified leaderboard 2026")

第 2 轮 - 观察：搜索结果：SWE-bench Verified 排行榜显示
                Claude Opus 4.7: 82.3%
                GPT-o3: 79.1%
                Devin: ~40%
                ...
第 2 轮 - 思考："拿到了 benchmark 数据，但我还需要了解实际开发者体验的差异，
                而不只是跑分。让我再下一步评测。"
第 2 轮 - 行动：tool_call: web_search("Claude vs GPT coding developer experience 2026")

第 3 轮 - 思考："现在有了 benchmark 数据和开发者反馈两方面的信息，
                我可以综合这些信息给出对比结论。"
第 4 轮 - 回答：综合 benchmark 数据和开发者实际体验：...

代表产品：LangChain Agent。

ReAct 本质上就是 OODA 环的简化版——把 Observe-Orient-Decide-Act 压成 Reason-Act-Observe。

范式 3：Plan-and-Execute（先计划再执行）

先让模型做出一个完整的任务计划（列出所有步骤），然后按计划逐步执行。执行过程中可以根据反馈调整计划——最"像人类项目经理"的范式。

先出全局计划
计划可以调整
有 todo.md 做注意力控制
用户可以看到并干预预计划

Phase 1 — 制定计划：

todo: 任务计划：
  1. 搜索 SWE-bench 等 benchmark 的最新排行数据
  2. 搜索 HumanEval 等基础代码生成基准数据
  3. 找 3-5 个开发者真实体验对比的博文/评测
  4. 从复杂 bug 修复、快速原型、大代码库理解、性价比四个维度整理数据
  5. 生成最终对比报告
（已保存到 todo.md）

Phase 2 — 按计划执行（每步都是 ReAct 循环）：

Step 1: 搜索 benchmark 数据 → 拿到 SWE-bench 排行 → 记录到笔记
        更新 todo.md：✓ Step 1
Step 2: 搜索 HumanEval 数据 → 发现数据不够新 → 决定补充检索
        → 找到 2026 年的最新评测 → 记录
        更新 todo.md：✓ Step 2
Step 3: 搜开发者体验 → 打开 3 篇博文阅读 → 提取关键评价
        更新 todo.md：✓ Step 3
Step 4: 整理数据时发现"性价比"维度数据不足
        → 动态调整新增 Step 4.1 "搜索两者 API 定价"
        → 搜索定价 → 补充数据
        更新 todo.md：✓ Step 4
Step 5: 读取所有笔记文件 → 合并 → 生成报告
        更新 todo.md：✓ Step 5 → 全部完成

Phase 3 — 交付报告

代表产品：Claude Code / Kimi K2 探索 / Manus。

三范式对比表

维度	CoT（思维链）	ReAct（推理+行动）	Plan-and-Execute（先计划再执行）
核心模式	纯推理，不动手	想一步做一步	先规划全局，再逐步执行
能调工具吗	不能	能	能
有全局计划吗	没有	没有（走一步看一步）	有（一开始就列出所有步骤）
典型步骤数	1-5 步（一次输出）	5-20 步	10-50+ 步
中途能调整方向吗	不能	能（但容易迷失）	能（有计划做锚点）
用户能看到过程吗	看到推理过程	看到每步动作	看到完整计划 + 每步进展
用户能干预吗	不能	只能事后看	可以修改计划
成本	低（1 次 LLM 调用）	中（5-20 次调用）	高（10-50+ 次调用）
代表产品	ChatGPT o1/o3 的"思考"	LangChain Agent	Claude Code / Kimi K2 探索

Planning 的三种"驱动度"（产品哲学层）

PM 在设计 Agent 产品时必须做的一个决策——Planning 的主动权交给谁？

策略	特点	适合场景	例子
全自动 Planning	Agent 自己做计划、自己执行、不给人看	标准化任务、用户不需要参与	Devin（Cognition Labs，2024.3 发布，基于自研模型 + GPT-4）：自己改代码、自己跑测试
半自动 Planning	Agent 做计划、展示给用户、用户可以改后再执行	用户有判断力、想要控制权	Kimi K2 探索：展示计划面板，可以点击修改
人驱动 Planning	用户列步骤，Agent 按步骤执行	用户非常明确要做什么	Cursor（基于 GPT-4 / Claude Sonnet）：开发者自己决定让 AI 做什么

这三种本质上是"信任度 × 控制欲"两轴上的不同站位。

PM 决策框架（两个核心问题）

1. 计划是否需要给用户看？

给看 = 用户有信任感、能干预 → 推荐
不给看 = 体验更"无感"但翻车时用户没法救

2. 用户能不能修改计划？

能改 = 协作型产品（Cursor）
不能改 = 委派型产品（Devin）

观察你用过的 Agent 产品（Claude / Kimi / 豆包），搜索一个复杂问题，看它的 Plan：

是显式列出来给你看的？
是藏在"思考过程"折叠面板里的？
还是完全不展示，只展示最终结果？

这是 PM 在 Agent UI 上必须做的设计选择。

Reflection — 让 Agent 审查自己的输出

Reflection 是 Planning 的子能力（Anthropic 把 Planning 拆为 Reflection / Self-critics / Chain of thoughts / Subgoal decomposition）。

它能 work 的根本原因：模型的"鉴赏力"比"创作力"强——它能写出一篇 70 分的文章，但给它一篇 70 分的文章它能指出"这里逻辑不连贯、那里数据没引用、开头太平淡"。

流程

生成 → 审查 → 反馈 → 修改 → 再审查 → ...

两种实现方式

	单 Agent 自反思	双 Agent（生成+批评）
机制	同一个 Agent 先生成，然后换一个 prompt 让它"现在你是质检员，检查刚才的输出"	一个 Agent 负责生成，另一个独立的 Agent 负责批评
优点	简单、成本低	批评方更客观，不护短
缺点	可能"自我认同"（对自己太宽容）	成本翻倍

什么时候不用 Reflection

Reflection 是一把好锤子，但不是每个任务都是钉子。只在"质量要求高 + 评估标准明确 + 用户能等"的场景下使用：

情况	为什么不该加	例子
简单任务	本来一次就能做对，加了反思只是浪费	"翻译一句话"、"提取一个数据"
实时交互场景	用户等不了你反思两轮再回答	聊天机器人、客服即时回复
评估标准不清	如果连"什么算好"都说不清，反思也只是在"随机改"	创意写作、开放式讨论

Planning 常见翻车

翻车 1：过度拆解

早期 AutoGPT 经常陷入这种状态：把"买一杯咖啡"拆成 30 步——

用户："帮我调研 boss 上的岗位"

× 过度拆解的 Plan：
1. 打开浏览器
2. 在地址栏点击
3. 输入 "b"
4. 输入 "o"
5. 输入 "s"
6. ...
50. 关闭浏览器

它会在第 15 步因某个网站加载超时就卡死循环。Token 消耗从合理范围（几千）暴涨到几十万，成本增加 10 倍，而且每步都可能出错。

翻车 2：计划僵死

Claude Code 在处理长任务时也会遇到这个问题。改了 10 个文件后忘了最初要修哪个 bug。

Plan：
1. 从 BOSS 直聘搜薪资数据
2. 从猎聘搜薪资数据
3. 整理报告

执行到第 1 步发现 BOSS 直聘封了 API，返回全是错误码，
Agent 仍然死板地执行第 2 步、第 3 步。
最终报告里第 1 步的数据全是乱码，但 Agent 依然把它写进了报告。

解决方案是在对话中定期回顾原始目标，确认当前操作是否还在正确的方向上。Plan-and-Execute 范式最隐蔽的坑就是"假装成功"——Agent 继续往前走但其实早就偏离目标。