第 1.7.1 节：区分状态、会话和记忆在 Agent 中各自负责什么
本节围绕“区分状态、会话和记忆在 Agent 中各自负责什么”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够用对比表判断状态、会话和记忆的适用条件、职责边界和取舍理由。
本章要解决什么问题
第 1.5 章完成了客服问题分流 Agent（智能体）的最小切片，第 1.6 章讲清了 Tool Calling（工具调用）如何把“下一步动作”接到查订单、查售后政策、创建工单等业务工具。到这里，读者会遇到第二个真实工程断层：多轮任务不是一次回答，也不是一次工具调用。Agent 必须知道自己做过什么、还缺什么、下一步是什么、什么时候停止。
客服场景很容易暴露这个问题。用户第一句话可能只说“我要退款”，没有订单号。系统追问订单号后，用户第二轮补充“是 20260701001”。Agent 查订单后发现已发货，又要查售后政策；政策显示需要人工审核，系统需要创建工单草稿并等待用户确认。如果没有状态管理，Agent 会出现这些问题：
- 重复追问已经提供过的订单号。
- 忘记上一轮已经查过订单。
- 工具失败后不知道是否该重试。
- 用户补充信息后无法从断点继续。
- 高风险退款请求没有审批状态。
- 对话历史越来越长，成本和错误一起增加。
- 长期记忆保存了不该保存的隐私信息。
本章通过状态、会话与记忆的工程设计，讲清：
- 状态、会话、记忆分别解决什么问题。
- 客服 Agent 工作台需要哪些状态字段。
- 哪些内容进入短期上下文，哪些内容可以持久化，哪些内容绝不能记。
- 如何设计状态迁移、恢复策略、停止条件和审计日志。
- 面试时如何把“记忆”讲成工程治理，而不是玄学能力。
学习目标
学完本章后，读者应该能做到：
- 用人话解释状态、会话、记忆的区别。
- 设计客服 Agent 的任务状态字段。
- 区分短期上下文、会话状态、长期记忆和业务数据库。
- 设计状态迁移表，说明从“缺订单号”到“查订单”再到“创建工单”的流程。
- 设计会话恢复策略：工具失败、用户中断、输出无效后如何继续。
- 设计停止条件：有效完成、需要补信息、需要审批、失败次数过多、转人工。
- 设计记忆权限、保存周期和隐私边界。
- 回答面试官关于上下文膨胀、记忆泄露、状态不一致和恢复机制的问题。
贯穿业务场景
继续使用“企业客服知识库与工单 Agent 工作台”。
典型多轮对话如下：
| 轮次 | 用户或系统行为 | Agent 应该记录的状态 |
|---|---|---|
| 1 | 用户说“我要退款，你们客服一直没人理我” | intent（意图）为 refund_request（退款请求）和 complaint（投诉），risk_level（风险等级）为 high（高），missing_fields（缺失字段）包含 order_id（订单号）。 |
| 2 | 系统追问订单号 | current_step（当前步骤）为 waiting_for_order_id（等待订单号），stop_reason（停止原因）为 need_info（需要补充信息）。 |
| 3 | 用户提供订单号 | missing_fields（缺失字段）清空，current_step（当前步骤）变为 ready_to_check_order（可查订单）。 |
| 4 | Agent 请求查订单工具 | used_tools（已用工具）记录 get_order_status（查订单状态），tool_attempts（工具尝试次数）加 1。 |
| 5 | 工具返回订单已发货 | tool_results（工具结果）记录订单状态，next_action（下一步动作）变为 search_policy（查售后政策）。 |
| 6 | 查政策后发现需要人工审核 | approval_required（需要审批）为 true，current_step（当前步骤）变为 prepare_ticket（准备工单）。 |
| 7 | 用户确认创建工单 | ticket_draft（工单草稿）转为 create_ticket（创建工单）动作，状态记录人工确认。 |
| 8 | 工单创建成功 | stop_reason（停止原因）为 completed（已完成），final_summary（最终摘要）记录处理结论。 |
这张表说明：状态不是“把历史聊天都塞给模型”。状态是把任务执行过程中对系统有用的事实沉淀下来。
新手为什么会卡住
| 常见误解 | 项目后果 | 正确理解 |
|---|---|---|
| 状态就是聊天记录 | 上下文越来越长，模型反而更容易混乱 | 聊天记录是原始材料，状态是提炼后的任务事实。 |
| 记忆越多越智能 | 保存过多隐私，权限和合规风险上升 | 记忆必须有用途、权限、周期和删除机制。 |
| 会话恢复靠模型自己理解 | 用户中断后无法从断点继续 | 恢复要依赖明确的 current_step（当前步骤）、missing_fields（缺失字段）和 tool_results（工具结果）。 |
| 工具结果直接写进 Prompt（提示词）就行 | 多工具、多轮后上下文膨胀 | 工具结果要摘要、结构化保存，并只把必要部分放进上下文。 |
| 停止条件只要“回答完” | Agent 可能无限追问或重复调用工具 | 停止条件要覆盖完成、缺信息、审批、失败、转人工和超范围。 |
| 长期记忆可以替代业务数据库 | 记忆中保存的订单状态可能过期或错误 | 订单、工单、退款状态必须以业务系统为准，记忆只能保存偏好或摘要。 |