很多讨论会把 “planning / research” 混在一起：有人说“要先规划”，有人说“要边做边想”。其实这两个词在工程语境里指向不同维度：
- planning：描述的是计划产物的结构化深度（shallow vs deep）。
- research：描述的是执行过程是否形成闭环（linear vs iterative/replan）。
把这两个维度拆开，你会发现“先规划再执行”和“边执行边重规划”并不矛盾，它们可以组合成四种常见工作流。
1. 概念定义
shallow planning/no planning（浅规划）
- 含义：规划粒度粗、结构弱，通常是“给出大致步骤/方向”，不显式建模依赖关系、工具选择、输入输出与验收标准。
- 典型产物：一段自然语言步骤（非结构化），或仅在模型内部隐式存在。
可以把它理解为：“我大概知道要做什么，但不先把任务拆干净，也不写清楚每一步的边界与完成标准。”
deep planning（深规划）
- 含义：在执行前把目标拆成结构化、可调度的子任务集合，明确依赖（DAG）、每步用什么工具、参数（inputs）、预期产出（outputs）与完成标准（done criteria）。
- 典型产物：
tasks[]/DAG（例如每个 task 含requires/tool/para/status等字段），便于调度、追踪与重试。
可以把它理解为：“先把路修好：每一步的输入、输出、工具、依赖、验收都写清楚，方便执行与回滚/重试。”
research
- 含义：一次规划 + 一次执行 + 最终总结的线性流程。
- 典型流程：规划执行 -> 执行 -> 总结（通常不会在执行中系统性重规划）。
重点是“线性”：即使中间遇到问题，也倾向于临时修补后继续走完，而不是把过程显式地变成多轮“状态评估 -> 重规划 -> 再执行”的循环。
deep research
- 含义：研究过程中的“闭环”：执行过程中持续根据新信息/失败原因/进度进行重规划，并再次执行，直到满足终止条件后总结。
- 典型流程：规划执行 -> 执行 ->（基于当前状态重规划 -> 执行）× N -> 总结。
重点是“迭代闭环”：把“不确定性”当作常态，把重规划当作流程的一部分，而不是意外事件。
2. 两个维度，一张四象限图
你可以用两个问题快速判断自己处在哪个象限：
- 计划产物是否结构化、可调度、可验收？（shallow vs deep）
- 执行过程是否显式进入多轮“评估->重规划->再执行”？（research vs deep research）
四种组合分别适合不同的不确定性水平与工程约束。
3. 四种组合
3.1 shallow planning + research：粗计划直跑一遍，最后总结
场景：一下午做个 RAG demo 给同事演示。
浅规划（非结构化步骤）：
- 找一份公开文档当知识库
- 做分段和向量化
- 接个检索 + LLM 生成
- 简单评估一下效果
- 写个总结
执行方式（线性）：按顺序实现，遇到分段不合理就“顺手调几下参数”，不回头显式重构整体流程。
输出：能跑的 demo + 粗略体验结论。
适用（什么时候选它更划算）：
- 目标清晰且范围小（“做出来就行”），对可复现/可扩展要求不高
- 单人快速交付或试水验证，可接受局部返工
- 不确定性低：你大致知道用哪些组件/参数能跑通
- 失败成本低：做错了最多丢掉几个小时，不会影响长期工程资产
3.2 deep planning + research：先出任务清单/DAG，再按计划执行一遍
场景：同样是 RAG demo，但你希望“可复现、可交付”，给出清晰的验收标准。
深规划（结构化 tasks/DAG 示例）：
tasks:
- id: T1
name: 选取数据与许可校验
outputs: [docs_corpus_v1]
done: "数据来源/许可证记录在 README"
- id: T2
name: 文本清洗与分段策略
requires: [T1]
tool: "python + tokenizer"
outputs: [chunks_v1]
done: "chunk 长度分布符合阈值；抽样可读"
- id: T3
name: 向量化与索引构建
requires: [T2]
tool: "embedding_model + vector_db"
outputs: [index_v1]
done: "索引可重建；构建耗时记录"
- id: T4
name: 检索与生成链路实现
requires: [T3]
outputs: [rag_pipeline_v1]
done: "固定 10 个问题可稳定返回答案"
- id: T5
name: 最小评估集与指标
requires: [T4]
outputs: [eval_report_v1]
done: "命中率/主观评分记录；失败样例归档"
执行方式（线性）：严格按 DAG 执行一次；完成标准达成就进入下一步。
输出：demo + 可追踪的构建记录 + 一次性评估报告。
适用（什么时候“先规划”收益最高）：
- 交付/协作要求高：需要对齐边界、责任、接口、验收口径
- 复现成本高：数据/实验代价大，最好一次走对、可追踪可回滚
- 依赖多：数据、模型、服务、权限、部署等存在明显前置条件
- 过程可预期：你基本确定要做哪些步骤，只是需要把它写清楚、做稳
3.3 shallow planning + deep research：不先出完整任务图，靠执行中即时重规划推进（偏 ReAct）
场景：你不确定该用哪种分段、embedding 或检索策略，可能需要不断试错；但你也不想一开始就写完整任务拆分（因为大概率会推翻）。
浅规划（起步方向）：
- 先快速做一个 baseline
- 发现失败点就针对性修
- 循环直到效果够用
执行中的闭环（典型节奏）：
- 跑 baseline，发现回答经常“胡编”
- 诊断：检索返回的 chunk 不相关 -> 立刻改分段/检索 top-k
- 再跑，发现相关但不完整 -> 加 rerank 或改 prompt 引用策略
- 再跑，发现延迟太高 -> 缓存/缩短 chunk/换更快 embedding
这里的关键不是“有没有计划”，而是：计划很轻，但重规划很频繁且显式，每轮都有“基于失败原因的下一步动作”。
适用（什么时候“不写 plan 反而更快”）：
- 搜索/探索空间大：选项多、组合爆炸，提前写完整任务图容易浪费
- 输入条件动态变化：用户/环境不断提供新约束，导致计划频繁失效
- 反馈回路短：每次试验都能快速得到信号（成功/失败原因/误差方向）
- 目标是“尽快找到可用解”，而不是立刻沉淀成可复用工程资产
例子：搜索任务（你提到的场景）
我们在做搜索/检索时，查询条件和条件组合往往会不断变化（例如：新增筛选、放宽条件、改权重、改排序规则）。这类任务更像是在一个搜索空间里做探索：
- shallow planning / no planning：不要求 agent 先给出完整 plan（因为条件会变、计划会迅速过期）
- deep research（闭环）：agent 每轮根据搜索结果反馈（命中/缺失/噪声/覆盖度），调整条件并再次搜索，直到满足终止条件
一个典型闭环可以是：搜索 -> 读取结果与失败原因 -> 改写/扩展/收缩条件 -> 再搜索，并以“找到满足约束的候选集合/Top-N 质量达到阈值/达到预算上限”为终止条件。
3.4 deep planning + deep research：先出 DAG，并在执行中根据进度/失败做 replan（最工程化的 deep-research）
场景：你要把 RAG 做成内部可复用组件（不仅是 demo），并且你已经预期会多轮迭代，但希望迭代是“可管理”的：每轮迭代都有明确的变更范围、对照与回滚。
深规划（带迭代与重规划钩子）：
- 先定义可调度的任务图（数据、索引、链路、评估、部署）
- 再定义“触发重规划”的条件与版本化产物（例如
index_v1/v2、eval_set_v1/v2） - 每轮迭代固定：
评估 -> 归因 -> 更新任务图/参数 -> 执行 -> 记录对照
执行中的闭环（示例）：
eval_report_v1显示某类问题命中率低- 归因到“chunk 过长导致稀释”，触发重规划：新增任务
T2b: chunking ablation，并将T3/T4/T5标记为需要重跑 - 产出
chunks_v2/index_v2/eval_report_v2，对照 v1 记录改进幅度
适用（什么时候需要“既深规划又闭环”）：
- 既要探索又要沉淀：你预期会迭代 N 轮，但每轮都要可度量、可对照
- 多人协作或跨团队依赖：需要任务拆分、状态可见、责任明确
- 回滚/审计要求：产物要版本化，失败可定位，可复现可回滚
- 终止条件明确：例如达到指标阈值、预算上限、或覆盖特定 case 集
4. 怎么选：按不确定性与成本做决策
一个实用的选择框架是：不确定性越高，越需要 deep research（闭环）；协作/交付成本越高，越需要 deep planning（结构化）。
- 目标清晰、一次性任务、失败成本低：优先
shallow planning + research - 目标清晰但交付要求高：优先
deep planning + research - 目标不清晰、需要大量试错：优先
shallow planning + deep research - 既要交付又要探索（现实中最常见）：优先
deep planning + deep research
5. 一句话总结
- planning 关心“计划长什么样”：越结构化越能调度、追踪与协作。
- research 关心“过程怎么走”：越闭环越能拥抱不确定性与试错。
- 把它们拆成两个维度，你就能更清晰地设计团队/个人的工作流，而不是陷入“到底要不要先规划”的二元争论。