Day 03 - Task Decomposition and Planning

今日目标

能把模糊任务拆成可执行步骤，理解 planning 的粒度与按反馈动态调整。

学习安排

时间	模块	做什么
0-10 分钟	核心概念	通读当天术语表，圈出 3 个你最想在工作里用上的概念。
10-25 分钟	阅读输入	精读第 1 章 Agent 循环、任务规划、行动反馈部分，只抓问题、思路、结论。
25-45 分钟	实践任务	完成「Nginx CPU 排查」任务拆解表，必须产出一份可复用计划。
45-55 分钟	追问与反思	回答追问练习，标记卡住的概念。
55-60 分钟	复盘与作业	整理自检清单，定下明天要复习的一点。

核心概念

术语	中文解释	应用场景
planning	规划：把目标拆成有序步骤，确定每步做什么、需要什么信息。	排查 Nginx CPU 前先定 5 步计划
decomposition	任务分解：把模糊的大任务拆成可执行的子任务。	把「分析性能问题」拆成查指标、查日志、下结论
sub-task	子任务：分解后每个可独立执行的小步骤，有自己的输入输出。	「查询 10:00-11:00 的 access log」
goal	目标：任务的最终交付物与验收标准。	产出带证据的 Nginx CPU 分析报告
feedback	反馈：工具返回结果或执行结果，驱动下一步决策。	日志为空时，反馈触发调整查询条件
replan	重规划：根据反馈调整原计划，而不是死守计划。	发现数据不足，追加查询 upstream 日志
over-decomposition	过度拆解：拆得太细，步骤多、开销大、容易偏离目标。	把「读文件」再拆成「打开-读取-关闭」
under-decomposition	拆解不足：步骤太粗，一步塞太多事，无法执行和定位。	「分析所有问题」这种一步到底的计划
uncertainty	不确定性：执行前无法预知的信息缺口，需要假设与验证。	不确定时间窗口时先做默认假设
information sufficiency	信息充分性：判断当前信息是否足够得出结论，不足则继续收集。	拿到指标和日志后才下结论，否则标注待验证
dependency	依赖：步骤之间信息的先后关系，决定执行顺序与拆解粒度。	查 upstream 耗时依赖先确定时间窗口
stop condition	终止条件：计划何时停止执行、何时输出结论的规则。	证据足够或达到重试上限时停止

阅读重点

对应章节：第 1 章中 Agent 循环、任务规划、行动反馈相关内容。
关注点：
为什么复杂任务需要规划：模型单次输出无法承载长链推理，需要分步执行。
计划的粒度：步骤之间的信息依赖关系决定拆多细。
计划是动态的：工具反馈与预期不符时触发 replan。
Agent 如何判断信息是否充分：证据足够才收敛，否则继续收集或标注待验证。
补充材料：
Anthropic 文档 Building Effective Agents 中「工作流与 Agent」一节，对照计划与执行的关系。
OpenAI Agents SDK 文档中 agent loop 的描述，看计划如何驱动多轮执行。

理解检查

为什么复杂任务需要规划？单次让模型直接输出结果会出什么问题？
计划应该一次性写死，还是根据反馈调整？什么情况下必须改计划？
Agent 如何判断当前信息是否足够？举一个「信息不足还硬下结论」的例子。
任务拆解过细有什么问题？拆解过粗有什么问题？

实践任务

背景：线上出现「Nginx CPU 升高」告警，你要设计一个 Agent 来分析原因。用户只给了模糊的一句话，Agent 需要把它变成可执行计划。

步骤：

写下任务目标与验收标准：什么算「分析完成」。
按下面 5 步骨架拆解，每步补充需要的工具、期望输出和失败处理。
标注步骤之间的依赖关系：哪一步必须先完成，哪一步可以并行。
至少标注 1 个可能的 replan 触发点：哪一步结果异常时需要改计划。
写清「信息充分性」判断：什么条件下可以下结论。
产出：任务拆解表，保存下来，Day 04 状态表直接复用。

输出模板

任务目标：[xxx]
验收标准：[xxx]

| 步骤 | 子任务 | 需要的信息/工具 | 期望输出 | 失败或不确定时 |
|---|---|---|---|---|
| 1 | [动作] | [信息/工具] | [输出] | [replan 策略] |
| 2 | [动作] | [信息/工具] | [输出] | [replan 策略] |
| 3 | [动作] | [信息/工具] | [输出] | [replan 策略] |

信息充分性检查：
- 可以下结论的前提：[前提条件]
- 需要继续收集的情况：[情况]
- 只能给假设的情况：[情况]
- 直接终止的情况：[目标达成或用户撤回任务]
- 需要用户确认的情况：[哪些结论必须由用户拍板]

示范输出

任务目标：分析 Nginx CPU 升高原因
验收标准：输出含证据、假设、待验证项的 Markdown 报告

| 步骤 | 子任务 | 需要的信息/工具 | 期望输出 | 失败或不确定时 |
|---|---|---|---|---|
| 1 | 收集时间窗口 | 用户输入 | 明确的时间范围 | 未提供时回问用户，或默认近 1 小时 |
| 2 | 查询 Nginx access log | query_logs 工具 | 请求量、状态码分布 | 日志为空，扩大时间窗口重查 |
| 3 | 查询 upstream 响应时间 | query_metrics 工具 | upstream 耗时序列 | 数据缺失，标注「待验证」继续 |
| 4 | 对比 WAF 开关前后 | 配置变更记录 | 开关前后指标对比 | 无变更记录，记为信息缺口 |
| 5 | 汇总结论和待验证假设 | LLM 生成 | Markdown 报告 | 证据不足时结论降级为假设 |

信息充分性检查：
- 可以下结论的前提：日志与指标都拿到，且时间窗口对齐
- 需要继续收集的情况：日志为空、时间窗口不明确
- 只能给假设的情况：多个原因并存，且无法通过现有数据区分
- 直接终止的情况：确认是误报或用户撤回任务

追问练习

你的计划里哪一步最可能失败？失败后 replan 的代价是什么？
信息不足时，Agent 应该继续收集还是先给「待验证」结论？如何权衡？
如果执行到第 3 步发现用户的目标本身有问题（例如告警是误报），计划该怎么调整？
拆解到什么粒度算「刚好」？你的判断标准是什么？

常见误区

把计划写死：工具返回与预期不符时仍然硬走原计划，导致结论失真。
拆解过细：每步都调用一次模型，成本和延迟成倍上升。
拆解过粗：一步塞多个动作，失败时无法定位是哪一步出的问题。
信息不足就下结论：这是编造的常见来源，证据不足时必须标注「待验证」。

进阶扩展

生产系统里 planning 常输出结构化步骤（如 JSON 列表），便于审计、重放与失败定位。
长任务需要 checkpoint：每步中间结果落盘，进程中断后可从断点继续。
评估 planning 质量：对比计划步骤与实际执行轨迹，度量偏差与额外开销。

今日作业

保存任务拆解表，明天做状态表时要复用这 5 步。
用一句话写出「信息充分性」的判断标准，明天开始前复述。
记录一次你工作中「计划被反馈推翻」的真实经历。
在你的拆解表里找出 1 处「可能过度拆解」的地方并说明理由。

自检清单

我能把模糊任务拆成 5 步左右的可执行计划。
我能解释 over-decomposition 与 under-decomposition 的问题。
我能说明计划为什么需要根据反馈动态调整。
我能判断当前信息是否足够下结论。
我知道明天要复习哪一点。