对话上下文

它是什么

对话上下文是模型在当前请求中能够参考的会话信息，包括先前用户与助手消息、当前问题、系统规则、工具结果和应用补充的状态。[S1][S2] 它描述的是“这一轮带进来的历史”，不是模型自动永久保存的个人记忆，也不等于应用数据库中的完整聊天记录。

为什么需要它

用户常用“它”“继续”“改成昨天那个版本”等省略表达。没有相关历史，模型无法知道指代对象、已作决定或尚未完成的步骤；历史过多或相互矛盾，又会让旧要求干扰新任务。明确对话上下文能让应用决定连续性来自哪里，并在可解释的位置修正状态。

它如何工作

许多消息 API 接收按角色排列的消息列表。应用保存先前轮次，在新请求中选择需要的历史并连同当前消息发送；模型输出随后可能成为下一轮输入。[S1][S2] 随着轮次增加，历史会持续占用上下文窗口，应用因此需要截断、摘要、检索旧消息或把确定状态迁移到结构化存储。

必须澄清的误会

对话上下文 ≠ 短期记忆。 短期记忆是以对话为单位保留的状态，通常实现为上下文或会话存储；对话上下文更强调「这一轮要带上哪些文本」。

对话上下文 ≠ 上下文窗口。 上下文窗口是容量上限，对话上下文是填进去的内容，前者决定后者能有多长。

真实例子

差旅助手先记录用户要去上海、预算上限 1200 元，随后用户说“改成周五晚出发”。若应用只发送最后一句，模型不知道目的地和预算；若发送全部闲聊，又会浪费窗口。更稳妥的做法是回传当前行程状态、最近相关轮次和修改请求，并把已作废日期标记为旧值。

什么时候适合与不适合

对话上下文适合保存当前任务的连续意图、约束和未完成事项，但不应无期限回传所有消息。历史可能包含隐私、过期结论、提示注入或错误的模型回答；“模型之前说过”也不是事实证据。应用必须区分原始记录、本轮实际输入和长期业务状态，并为删除、保留与更正建立规则。

亲自试一下

准备一段六轮对话和一个依赖前文的最终问题，分别用完整历史、仅最后一轮、人工摘要三种上下文运行。按“指代是否正确、约束是否保留、过期信息是否误用、Token 数”评分。再故意删除一条关键决定，记录哪种表示最容易发现状态缺失。

接下来学什么

阅读上下文窗口理解历史如何占用输入预算，再学习短期记忆和状态管理区分模型可见历史与应用持久状态；长对话则需要上下文压缩。

来源与修订

消息角色、内容列表和多轮请求方式参考 Anthropic Messages API [S1]；历史逐轮累积、工作记忆范围和窗口计数参考上下文窗口文档 [S2]。服务端是否保存会话、自动裁剪什么内容以及各模型的容量必须按实际产品版本复核。