Day 04 - Agent State and Feedback

今日目标

能把 Agent 理解为多轮状态机，说清状态、历史、阶段结果与工具反馈的关系。

学习安排

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

核心概念

术语	中文解释	应用场景
state	状态：Agent 当前所处阶段及已积累的关键信息。	当前处于「查询数据」阶段，已拿到时间范围
state machine	状态机：Agent 在预定义状态间迁移的执行模型。	收集需求 → 查询数据 → 分析 → 输出
conversation history	对话历史：与用户的所有轮次消息记录，是上下文的组成部分。	用户补充了 WAF 开关时间，写入历史
intermediate result	中间结果：某步骤产生、供后续步骤使用的数据。	查询工具返回的原始日志片段
tool feedback	工具反馈：工具执行后的返回结果或错误信息。	query_metrics 返回「无数据」
context window	上下文窗口：模型一次能容纳的 token 上限，决定放多少历史。	长日志需要截断或摘要后才能放入
retry	重试：工具失败后按策略重新执行，常设次数上限。	数据库连接超时后间隔重试 2 次
error recovery	错误恢复：从失败状态回到可继续执行的路径。	日志工具失败时降级为读取摘要文件
human intervention	人工介入：高风险或不确定场景交给人工决策。	报告含高风险结论时人工确认
audit trail	审计轨迹：记录每步动作、输入输出，可追溯。	记录每次工具调用的参数与返回摘要
state transition	状态迁移：从当前状态进入下一状态的触发条件。	拿到明确任务描述后从「收集需求」进入「查询数据」
fallback	降级路径：主路径失败时启用的替代方案。	实时指标查询失败时改用昨日缓存数据

阅读重点

对应章节：第 1 章中执行循环、上下文、工具反馈部分。
关注点：
Agent 是多轮状态机，不是单次请求：每一步都改变状态。
状态与上下文的区别：状态是结构化的关键信息，上下文是模型视角的全部文本。
工具反馈如何回流：不是全量塞回上下文，要有选择地摘要和截断。
失败处理与人工介入的触发条件：什么时候重试、什么时候降级、什么时候叫人。
补充材料：
Anthropic 官方文档多轮 Tool Use 说明，看反馈如何进入下一轮模型调用。
LangGraph 官方文档的 State 概念页，看工程上状态如何存储与更新。

理解检查

Agent 为什么需要保存中间状态？如果每轮都从零开始会怎样？
状态和上下文有什么区别？各自保存什么信息？
工具返回结果应该全部塞回上下文吗？为什么？
失败重试需要记录哪些信息？重试和错误恢复有什么不同？

实践任务

背景：把 Day 03 的「Nginx CPU 排查」5 步计划升级为状态机。Agent 不能只是按顺序跑一遍，还要能回答「我现在在哪一步、手上有什么、下一步做什么」，并且能在失败后回到可继续的状态。

步骤：

复用 Day 03 的 5 步计划，归纳出 4 个状态：收集需求、查询数据、分析、输出。
给每个状态填四列：状态、输入、动作、输出。
明确状态迁移条件：什么情况下从 A 状态进入 B 状态。
标出异常迁移：分析时发现数据不足，允许回退到查询数据。
给最可能失败的状态补一条失败处理规则。
产出：状态表，保存下来，Day 05 设计文档直接使用。

输出模板

Agent：[xxx]
状态集合：[状态 1] -> [状态 2] -> [状态 3]

| 状态 | 输入 | 动作 | 输出 |
|---|---|---|---|
| [状态名] | [进入该状态需要的信息] | [执行的动作] | [产出并传递到下一状态的数据] |
| [状态名] | [进入该状态需要的信息] | [执行的动作] | [产出并传递到下一状态的数据] |
| [状态名] | [进入该状态需要的信息] | [执行的动作] | [产出并传递到下一状态的数据] |

失败处理：
- [状态名] 失败时：[重试/降级策略]
- [状态名] 数据不足时：[回退或补充查询]
- 重试上限：[次数]，超过后：[动作]
- 人工介入点：[触发条件]
- 审计记录：[需要记录什么]

示范输出

Agent：Nginx CPU 排查 Agent
状态集合：收集需求 -> 查询数据 -> 分析 -> 输出
异常迁移：分析时数据不足，回退到查询数据

| 状态 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 收集需求 | 用户原始问题 | 追问时间窗口，或按默认值解析 | 明确的任务描述（目标 + 时间范围） |
| 查询数据 | 时间范围/指标名 | 调用 query_logs、query_metrics | 原始日志摘要与指标序列 |
| 分析 | 查询结果 | LLM 对比、归因、形成假设 | 带证据的假设列表 |
| 输出 | 分析结果 | 生成 Markdown 报告 | 含证据、假设、待验证项的报告 |

失败处理：
- 查询数据失败：重试 2 次，仍失败则询问用户是否继续
- 分析时数据不足：回退到查询数据，扩大时间窗口重查
- 人工介入点：报告含高风险结论，或需要修改配置时
- 审计记录：每次工具调用的参数、返回摘要、重试次数

追问练习

工具返回结果应该全部塞回上下文吗？你会按什么规则取舍？
失败重试需要记录哪些信息？重试 3 次都失败后，Agent 应该做什么？
什么时候应该让人介入？「没人看」和「看不过来」哪个风险更大？
你的状态表里，哪两个状态之间最可能来回跳转？这说明了什么？

常见误区

把状态和上下文混为一谈：状态是精简的结构化信息，上下文是模型看到的全部文本，两者分开管理。
把工具结果全量塞回上下文：噪声增加、成本上升，应该摘要或只保留关键部分。
失败就无限重试：要设置重试上限与降级路径，避免空转浪费。
全程无人确认：涉及发送、删除、写库等高风险动作必须 human-in-the-loop。

进阶扩展

生产系统里状态要可持久化（如数据库或 Redis），进程重启后能恢复，长任务不怕中断。
audit trail 是排查「哪一步引入错误」的依据：每一步动作留痕，问题可回溯。
状态设计影响可测试性：状态越清晰，越容易构造单元测试和故障演练。

今日作业

保存状态表，Day 05 设计文档直接复用。
用一句话写出「状态和上下文的区别」，明天开始前复述。
给状态表补一行失败处理，写清最可能失败的一步怎么恢复。
想清楚你的 Agent 哪些动作必须人工确认，明天写进设计文档。

自检清单

我能把 Agent 描述成多轮状态机。
我能说清状态、历史、中间结果、工具反馈的关系。
我能为每个状态定义输入、动作、输出。
我能设计重试、降级与人工介入规则。
我知道明天要复习哪一点。