第 1.7.4 节：为恢复、遗忘和错误记忆设计风险控制
设计恢复、遗忘和错误记忆时，关键是提前写清何时停止、怎样降级、由谁接手。完成本节后，你应该能够列出恢复、遗忘和错误记忆的触发条件、兜底动作、日志字段和人工升级条件。
权限、状态和日志
状态管理不仅是体验问题，也是权限和审计问题。
权限原则
| 场景 | 控制方式 |
|---|
| 用户补充订单号 | 订单号必须和当前用户身份匹配，不能只相信用户输入。 |
| 读取历史工单 | 只允许读取当前用户或授权范围内的工单。 |
| 写入长期记忆 | 必须有明确业务用途和保存周期。 |
| 高风险退款诉求 | 状态只能进入审批或人工确认，不能直接完成资金动作。 |
| 客服人员查看状态 | 按角色展示必要信息，不展示不必要隐私。 |
状态变更日志
| 字段 | 含义 | 为什么需要 |
|---|
| trace_id（追踪编号） | 串联一次请求或工具调用 | 复盘一次具体问题。 |
| session_id（会话编号） | 串联多轮交互 | 解释用户补充信息如何被使用。 |
| task_id（任务编号） | 串联一个业务任务 | 一个会话多个任务时不混乱。 |
| from_state（原状态） | 变化前的状态 | 判断迁移是否合理。 |
| to_state（新状态） | 变化后的状态 | 说明系统进入哪一步。 |
| event（触发事件） | 用户输入、工具成功、工具失败、人工确认 | 解释为什么迁移。 |
| actor（操作来源） | 用户、Agent（智能体）、工具、人工客服 | 审计责任边界。 |
| reason（原因） | 状态变化原因 | 面试和排障时最有价值。 |
不要只记录最终回答。真实项目排查问题时，最需要的是状态怎么一步步变化。
失败场景与兜底表
| 失败场景 | 表现 | 兜底方式 | 验收标准 |
|---|
| 上下文膨胀 | 历史越来越长，成本和延迟上升 | 用会话摘要和状态字段替代全部历史 | 单次模型调用只包含必要上下文。 |
| 重复追问信息 | 用户已经给过订单号，系统还在问 | missing_fields（缺失字段）更新后必须持久到任务状态 | 多轮测试不重复问已知字段。 |
| 工具结果丢失 | 查过订单后下一轮忘记结果 | tool_results（工具结果）保存摘要，并带来源 trace_id（追踪编号） | 工具成功后能继续下一步。 |
| 状态不一致 | 当前步骤和工具结果矛盾 | 状态迁移必须通过规则校验，异常时转人工 | 不允许从缺订单号直接进入退款审批。 |
| 记忆泄露隐私 | 长期保存订单、联系方式或敏感投诉细节 | 限制记忆类型，设置过期和删除策略 | 记忆表中不保存不必要敏感数据。 |
| 用户中断后回来 | 系统不知道是否继续旧任务 | 读取 session_status（会话状态）和 current_step（当前步骤），提示恢复或新建任务 | 用户能选择继续或重新开始。 |
| 重试失控 | 工具失败后反复调用 | retry_count（重试次数）设上限，超过后转人工 | 日志能看到重试次数和停止原因。 |
| 高风险自动推进 | 退款投诉未经确认进入执行 | approval_required（需要审批）和人工确认状态必须存在 | 高风险样例不能自动完成资金动作。 |
工程检查清单
继续学习