长对话中的意图漂移：为什么你的智能体目标表征会失效

大多数关于上下文窗口（context windows）的讨论都集中在模型能“容纳”什么。更难的问题是模型如何“处理”它所容纳的内容——具体来说，它如何追踪对话者不断演变的目标。

意图并非一成不变。用户从模糊的描述开始，通过迭代不断细化，有时会自相矛盾、离题或修正。他们在第 40 条消息时真正的需求，未必是他们在第 2 条消息中所表达的内容。如果一个智能体将上下文视为扁平的追加日志，它会堆积所有信息——但仍然会误判当前的意图。

这种情况通常表现为幻觉。智能体自信地执行用户在三轮对话前就已经放弃的需求。但当你溯源失败原因时，会发现没有哪一步是错误的。智能体逻辑严密地遵循了每条指令。问题在于，这些逻辑是应用在一个已经发生偏移的目标之上的。

为什么静态上下文会冻结意图

智能体处理上下文的标准方法是可变字符串缓冲区：一个固定的系统提示词（system prompt），后面追加所有历史消息。在意图简单且对话较短时，这种方法有效。但在长对话中，它会悄然崩溃。

这种失效模式有三个根本原因。

模式匹配惯性。 随着上下文的增长，注意力会稀释到更宽的 Token 跨度。模型越来越倾向于模仿会话早期建立的行为模式——比如它们已经进行了 8,000 个 Token 的“代码重构任务”，即使在用户转向文档编写目标后，这种模式依然会自我强化。最新的指令虽然在语法上存在，但在上下文语境中已被淹没。

Token 位置偏差。 Transformer 的注意力机制会根据相对位置给予 Token 不同的权重。第 2 条消息的指令虽然在第 40 条消息时仍处于上下文中，但其有效影响力已经衰减。模型并非在忽略原始目标——它只是给予原始目标的权重低于近期对话所形成的模式。

训练理性。 在群体偏好数据上训练出的模型，学会了为“平均意图”提供最大程度的帮助。当用户的信号模糊时，模型会默认采取最通用的帮助方式——而不是针对该特定用户在特定演变状态下的需求。那些偏离既定轨迹的修正，往往被重新解释为对原始目标的澄清，而非对目标的修订。

综合结果是：一个智能体看似记住了所有内容，却完全不理解用户的意图是如何演变的。

意图漂移在生产环境中的真实表现

这种失败模式并不明显。它不会导致程序崩溃。智能体仍然产出结果——通常在语法上正确、格式上响应、且看似合理。缺失的是与用户在提出最后一个问题时的真实意图保持一致。

关于多轮对话衰减的研究给出了具体数据。在复杂的生成任务中，多轮会话的表现比单轮基准下降了约 30%。当对话涉及实际修正——即用户明确修订其需求时——模型仅在 10-14% 的时间内能准确处理这些修订。在其余时间里，它们将修正视为补充说明而非替换。

执行链早期的 2% 目标偏差，到结束时会累积成约 40% 的失败率。错误不会被限制在局部，它们会通过工具调用、存储结果和下游推理步骤不断复合。

在实践中，这表现为：

• 代码智能体中的范围蔓延：负责修改特定文件的智能体会逐渐将行动扩展到禁忌目录，因为“代码修改”的行为模式变得自我强化。约束在开始时已声明，在文本中也存在，但已不再能有效执行。
• 过时的优化目标：一个最初负责最大化召回率的数据分析智能体，在用户两次提到假阳性后，会默默地重新优化精确率。而用户并未给出明确的更改目标指令。
• 恢复错误：在上下文压缩或会话暂停后，智能体通过总结摘要重建先前的意图，而这些摘要未能反映最后一轮的细化。用户看到智能体又从他们早期版本的需求开始运行。

修订与澄清之间的鸿沟

最难察觉的一类意图漂移涉及那些看起来像澄清的修正。

当用户说“等等，我其实是指 X”时，其语态结构与“澄清一下，我也指 X”非常相似。被训练得顺从且乐于助人的智能体默认采用后一种解释——它们将新信号融入现有意图，而不是替换其中的一部分。

这在具有长动作序列的智能体任务中尤为严重。到第 20 条消息时，智能体已经围绕它所理解的目标构建了大量的上下文。引入修正不仅需要理解新信号，还需要围绕修订后的解释重新加权所有先前的上下文。模型两样都做不到。它口头上承认了修正，然后继续按照原始解释执行。

这种失败是结构性的，而不仅仅是能力问题。如果一个系统将意图建模为不可变的，那么再强的指令遵循能力也无法修复它。

可变意图表示

核心设计变更在于将意图视为一种结构化的状态变量，而非原始上下文的涌现属性。

加载中…