AI Agent Engineer

AI Agent Engineer

对话历史、状态与记忆

6 min read

对话历史、状态与记忆

本节目标

区分原始聊天记录、任务状态、会话摘要和长期记忆，避免无限回放与错误记忆扩散。

四种对象

  • 原始历史：用户和助手实际消息，适合审计，但冗长且可能含过期计划。
  • 结构化状态：当前目标、约束、已完成动作、未决问题、授权范围，是 Agent 推进任务的事实源。
  • 会话摘要：为节省空间压缩的叙述，属于派生数据，可能遗漏或误写。
  • 长期记忆：跨会话保留的稳定偏好或事实，需要明确写入条件、来源、权限、更新和删除机制。

不要从一句随口表达自动推断长期偏好。模型生成的摘要也不应直接覆盖经用户确认的状态。

长期记忆要有写入策略：什么信息足够稳定、由谁确认、保存多久、谁能读取、如何纠正和删除。记忆检索出来后仍是上下文数据，必须重新经过权限、时效和提示注入检查；“以前记住了”不等于“现在仍正确且允许使用”。

状态机比长聊天更可靠

{
  "goal": "预订一次差旅",
  "constraints": {"budget_cny": 3000, "refundable": true},
  "confirmed": ["出发日期"],
  "pending": ["目的地机场"],
  "completed_actions": [],
  "state_version": 4
}

字段阅读（严格 JSON 中不插入注释，避免学习者复制后得到无效状态）：

  • goal 是当前任务的可读目标；它应由用户或受控流程确认，而不是从闲聊自动推断。
  • constraints 保存仍有效的硬约束；示例同时记录预算上限和是否必须可退款。
  • confirmed 与 pending 分别列出已确认信息和仍需澄清的信息，让系统不会把未知值当成已知事实。
  • completed_actions 记录已产生的动作，供幂等、防重复和恢复流程核对；空数组表示尚未执行动作。
  • state_version 是并发更新时的版本号；写入前后应比较它，避免后来的请求静默覆盖别人刚确认的状态。

每次工具调用前读取当前版本，调用后以事件更新；发生并发修改时拒绝静默覆盖。聊天可以解释状态，但不能成为唯一数据库。

历史裁剪规则

优先保留：最新用户目标、仍有效约束、未解决问题、工具结果的必要摘要、最近的确认与拒绝。可以移除寒暄、重复解释和已被结构化状态取代的中间推理。任何裁剪都要保留“谁确认了什么”和关键证据 ID。

供应商可能提供服务端会话或响应链功能，也可由应用手动重放消息。两种方式都不应假设历史免费、永久存在或自动携带所有高层指令；当前计费、保留与继承语义必须查官方文档。

一个当前供应商示例

按 2026-07-21 的 OpenAI 文档，Responses API 常见三种状态管理方式是：用 previous_response_id 让服务端引用先前响应、把先前输出 items 手动传回下一次请求，或使用持久 conversation 对象。previous_response_id 不会自动继承上一次顶层 instructions，而响应链中的先前输入 token 仍按输入计费。这个例子说明：会话被保存、指令被继承、上下文被计费是三件不同的事。其他供应商的语义必须分别核对。

练习与自测

把十轮“选酒店”对话转成结构化状态，保留预算、日期、取消政策、已拒绝选项和待确认项。然后删去原历史，判断能否安全继续下一步；若不能，列出缺少的事实与来源。

掌握检查

  • 我能区分原始历史、结构化状态、派生摘要和长期记忆。
  • 确认、拒绝、未决事项与外部动作都有版本和来源，不只存在于聊天文字中。
  • 并发状态更新使用版本检查，不会静默覆盖另一轮或另一 Agent 的结果。
  • 记忆写入、读取、更正、过期与删除都有权限和审计规则。
  • 我会核对所用 API 的状态继承、存储和计费语义，不假设“续聊”自动带回全部指令。

下一步

进入 裁剪、摘要、压缩与缓存。

参考资料

Backlinks