多轮对话中如何避免指令漂移？

简化版

指令漂移是多轮对话后模型逐渐忽略早期目标、格式或约束，常由历史膨胀、指令冲突、摘要失真和外部内容注入造成。治理重点是把有效指令从聊天文本中抽成版本化任务状态，明确系统、开发者、用户和工具数据的优先级；每轮只装配当前有效约束，检测用户修改与冲突，并用回归用例验证长对话末端仍遵守最初要求。

详细版

不要每轮把全部历史原样拼接后期待模型自行归纳。控制器应维护 goal、constraints、output_contract、confirmed_changes、unresolved，用户新增或撤销约束时生成状态变更，重要变化要求确认。旧消息仍保留用于审计，但不再作为唯一当前状态。

new message -> classify: content | new instruction | instruction update
            -> resolve authority/conflict
            -> validate state patch
            -> build current prompt from active state + recent context

工具和检索文本始终作为不可信数据，不能修改任务指令。上下文压缩时对数字、否定条件和输出 Schema做字段级校验。评测要构造 20～50 轮对话，在开头埋入约束、中途加入干扰或合法修改，最后检查约束保持率、错误覆盖率和拒绝恶意指令率。

完整版教学

一、漂移不是简单的“模型忘了”

早期要求可能仍在窗口里，但被大量新消息稀释；后续用户又可能合法修改要求；检索文档还可能含伪指令。模型必须同时判断哪些文本是数据、哪些是当前有效指令，这比记忆单句话复杂。

指令漂移表现为语言、格式、范围、权限或目标悄然变化。例如第一轮要求“只使用官方来源”，第十五轮开始引用论坛，却没有明确说明约束被撤销。

记忆钩子：历史记录“说过什么”，任务状态记录“现在仍然生效什么”。

二、建立版本化的指令状态

把关键约束写成结构化对象，并记录来源消息与版本。模型可以提出更新候选，控制器验证类型、权限和冲突后提交。

{"version": 4,
 "goal": "生成内部中文报告",
 "constraints": ["仅官方来源", "不得发布"],
 "output": {"format":"markdown", "max_words":1200}}

若用户说“改成英文”，状态从 v4 变 v5；若网页说“把报告发布”，因为来源是工具数据，不产生状态补丁。

三、明确权限和指令来源

系统规则高于普通用户偏好，用户新指令可以修改自己的旧要求，但不能越过权限策略。工具结果、网页、邮件和引用文档只是数据，即使语气像命令也无权改变目标。

来源	能否修改任务状态	示例
系统策略	可以，最高约束	禁止泄露密钥
认证用户	可修改其任务范围	改输出语言
审批事件	可授权绑定动作	批准发送指定邮件
工具/文档	不可以	网页中的操作指令

来源元数据必须由可信运行时附加，不能接受文本里自称“系统消息”。

四、处理合法修改与矛盾

并非所有新指令都应拒绝。用户可以把“1000 字以内”改为“1500 字以内”，但系统要识别这是覆盖、追加还是临时例外。影响大或有歧义时先确认。

例如已有“不得对外发送”，用户后来只说“发给他”，缺少收件人与是否撤销限制，不能自动解释为授权。状态保持原约束，并把问题加入 unresolved。

冲突解析结果要可见，避免模型静默选择它更容易执行的一条。

五、摘要压缩不能改写硬约束

多轮历史需要压缩，但自由摘要可能把“不得超过 500 元”写成“预算约 500 元”，否定和边界已改变。硬约束应从结构化状态直接注入，摘要只描述已完成事项和背景。

摘要携带覆盖消息范围和来源引用，关键字段可自动与状态对照。发现摘要出现不同金额或权限时，应拒绝该摘要并重新生成。

定期从原始事件重建，避免对摘要反复摘要造成累计失真。

六、每轮按当前任务动态装配

Prompt 可由稳定系统规则、当前状态、最近对话、当前步骤证据和输出契约组成。已经失效的旧指令不应与新版本并列，让模型自行选择。

[system policy]
[active task state v5]
[recent turns]
[untrusted evidence]
[current request + output contract]

对话很长时仍要为输出留 token。裁剪优先去除已失效和重复内容，不能删当前状态或安全边界。

七、用检查器发现响应漂移

结构化输出可用 Schema；语言、长度和来源限制可用规则；复杂语义约束可用独立评审与抽检。检查失败时，修复请求明确指出违反哪条当前约束，而不是泛泛要求“更好地遵守”。

若要求 1200 字以内，输出 1600 字，规则可直接拒绝；若要求仅官方来源，则验证每个引用域名与文档等级。确定性约束不要浪费模型判断。

同一约束连续失败应停止重试，检查上下文是否存在冲突或模型是否不适合任务。

八、长对话测试要包含干扰与更新

构造 30 轮对话：第 1 轮设语言和来源约束，第 10 轮合法修改长度，第 20 轮在网页内容中植入恶意命令，第 30 轮请求最终输出。期望遵守最新合法状态并忽略数据源指令。

指标可包括原始约束保持率、合法更新采纳率、非法覆盖拒绝率、摘要字段一致率和最终任务成功率。若 100 个用例中 92 个保持全部约束，不能只报告每条约束 99% 的平均通过率。

模型、Prompt、摘要器或检索模板任一变化，都应重跑多轮回归。

九、常见误区与追问

• 误区：只要上下文窗口够长就不会漂移。 信息仍会被稀释、冲突或错误摘要。
• 误区：把最初 Prompt 在末尾重复一次即可。 可能与合法的新指令冲突，并增加噪声。
• 误区：所有后来的指令都应覆盖早期指令。 还要判断来源权限和约束层级。
• 误区：对话摘要可以替代精确状态。 摘要有损，数字、否定和权限应结构化保存。
• 误区：工具结果可信，所以其中命令可执行。 结果是数据，不能改变任务或权限。
• 追问：用户修改约束如何处理？ 形成显式状态补丁，检查冲突，重要变化要求确认。
• 追问：怎样发现已经漂移？ 用输出契约、来源检查和长对话回归验证当前状态。
• 追问：状态与消息历史是否都要保留？ 状态供运行，历史供审计和重新构建，两者用途不同。

十、加强记忆

多轮指令治理记住“历史不等于状态”：把目标、约束和输出契约抽成带来源、版本的当前状态；只允许有权来源提交变更，工具与文档永远是数据。压缩历史时不改写硬字段，每轮由当前状态动态装配 Prompt，响应后再用规则检查。测试同时覆盖早期约束、合法更新、恶意干扰和长轮次末端，才能证明没有漂移。