长时 Agent 会话中的人格漂移：为什么你的 Agent 会忘记自己是谁
大多数生产环境中的 Agent 故障看起来像是模型错误。Agent 在会话开始时能正确响应系统提示词——维持正确的语气，遵守工具约束，遵循定义的工作流程。然后，在第 30 或 40 轮左右，情况悄然发生变化。Agent 开始在本应直接的地方含糊其辞，调用了它被告知应避免的工具，甚至推翻了它在 15 轮前做出的决定。系统提示词没有改变，但 Agent 的行为已经变了。
这就是人格漂移：由于 Transformer 对越来越深埋的上下文的注意方式，Agent 实际行为与其原始系统指令之间产生的渐进式偏差。研究对此进行了精确量化——经过 8–12 轮对话后，人格自一致性指标下降超过 30%。单轮 Agent 的任务准确率约为 90%；在运行相同任务的多轮 Agent 中则降至约 65%。这 25 个百分点的差距并非一个可以通过调整提示词来解决的模型质量问题，而是注意力机制在长序列上工作方式的架构特性。而大多数团队只有在上线某个功能、该功能悄无声息地降级数小时后才被用户发现时，才意识到这个问题。
漂移的真正原因
人格漂移有三个根本原因，大多数调试过程都将这三者混为一谈。
"迷失在中间"问题。 Transformer 注意力机制在 token 位置上呈 U 型分布：模型对上下文开头和结尾的注意力最强，中间存在明显的低谷。你的系统提示词位于位置 0，这意味着它在会话早期能获得强烈的注意力。随着对话历史的增长，系统提示词仍处于相同的绝对位置，但它现在距离最近的用户消息已有数千个 token 之遥。原本处于上下文窗口边缘的指令现在落入了注意力低谷。模型在第 5 轮还在遵守的约束，到第 40 轮时接收到的梯度信号已经明显减少。
近因效应与错误传播。 模型被校准为对近期 token 赋予更高权重——这对于跟随对话流程是有用的特性，但对于长时一致性则是毁灭性的。随着会话积累大量工具输出、中间推理步骤以及 Agent 自身的历史回复，近期内容开始挤占原始指令的位置。Agent 并非在任何有意义的层面上"遗忘"，它只是在关注最近的内容。更糟糕的是，Agent 基于自己之前的推理进行推理。第 10 轮中稍微偏差的框架成为第 20 轮回复的基础，又成为第 30 轮的基础。微小的偏差会不断累积：研究表明，对话早期 2% 的偏差到会话末尾可以演变为 40% 的失败率。
自我参照的行为锚定。 Agent 会适应自己之前输出的风格和内容。如果 Agent 在第 15 轮产生了一个冗长的回复，对话的"基调基线"就会向冗长方向偏移，后续输出也会随之漂移。这不是指令遵循——这是训练目标产生的统计动量。模型学会了产生上下文连贯的延续，而在长时会话中，与近期输出的连贯性变得比与遥远系统提示词的连贯性更具主导地位。
这三种机制相互作用。一个 40% 填满了工具输出的上下文窗口会将系统提示词埋得更深。Agent 最近的回复锚定了行为基线。当指令与近期上下文发生冲突时，指令会输——不是因为模型不能遵守它，而是因为注意力分布使得该指令在功能上比周围的 token 权重更轻。
检测盲区
人格漂移最隐蔽之处不在于它的存在，而在于它对常规监控是多么不可见。
错误率仪表板无法捕捉漂移。Agent 仍在成功完成工具调用并返回结构化响应。延迟监控是干净的。从每一个团队所监控的运营指标来看，会话都在"正常工作"。变化的是行为层面：Agent 对所赋予约束的遵守、推理风格的一致性、它本应维持的领域人格的准确性。
漂移通常表现为：
- 约束的渐进松弛。 一个被告知"永远不要推荐具体金融产品"的 Agent 开始说"一些从业者使用 X，但我不能正式推荐"。技术上没有违规。行为上已经漂移。
- 跨轮次的矛盾推理。 Agent 在第 12 轮支持方案 A，在第 35 轮却在不承认转变的情况下隐含地反对它。
- 语气和风格衰减。 一个经过训练以产生简洁、技术性回复的 Agent，随着会话的延长开始产生更长、更模糊、更口语化的文本。
- 工具使用模式变化。 一个在会话早期正确避免昂贵工具的 Agent，到会话后期开始默认使用它们。
当用户报告"AI 行为异常"时，会话往往已经漂移了很多轮。由于每个单独的回复看起来都是合理的——Agent 没有产生明显的错误——这些信号很容易被当作噪声忽视。
三种真正有效的模式
定期指令重新注入。 解决注意力低谷漂移最直接的方法就是重复指令。在固定间隔或由轮次计数触发时，重新注入关键约束的精简版本——行为规则、工具限制、人格锚点。这不是变通方案，而是对长上下文注意力是一个物理问题而非配置问题的认可。模型在设计上对近期 token 赋予更高权重，所以定期将你的指令放入近期 token 中。
实现细节很重要：不要逐字重新注入完整的系统提示词。大块内容的重复在某些模型中会触发注意力抑制。相反，找出最容易漂移的五到十个约束——通常是工具限制、人格框架和输出格式规则——并注入仅这些内容的精简版本。将其框架为会话中途提醒而非纠正："继续你的分配角色：[关键约束]"。
锚定上下文压缩。 不要让上下文窗口自由填充，而是实施定期压缩，明确保留行为锚点。从生产经验中得出的关键洞察是，朴素的摘要会使漂移加速——摘要本身成为另一层近期加权的上下文，可能将已经漂移的行为编码为新的基线。
有效的压缩遵循锚定结构：将会话历史压缩为固定格式的块，该块始终以"角色：[原始人格]"和"约束：[不可谈判的规则]"开头，然后再总结发生了什么。人格和约束字段从原始系统提示词逐字复制，而非重新总结。后续推理 从这个锚点出发，而不是从完整历史的累积漂移开始。针对此模式的研究表明，它在跨压缩周期保留技术细节方面得分最高——文件路径、错误消息和约束违规在锚点明确时都能更好地保留。
带重新锚定触发器的行为漂移监控。 最稳健的方法将检测与纠正结合起来。按固定间隔对照行为不变量检查清单对 Agent 行为进行采样——一组 Agent 应始终表现的属性，你可以通过快速的次级 LLM 调用或确定性规则来检查。当某个属性失败时，触发重新锚定：暂停，重新注入核心约束，并在恢复前从干净的锚点总结近期上下文。
使这在生产中有效的是让漂移检测变得廉价。在每轮之后运行完整的评估过程是不可行的。相反，为代理信号添加监控：回复长度趋势（持续增加通常预示语气漂移）、按工具名称统计的工具调用频率（偏离基线频率表示工具使用漂移）以及约束违规短语模式（正则表达式可检测的模糊表达、限定语或禁止引用）。当两三个代理信号同时超过阈值时，这就是你的触发条件。
上下文工程框架
团队最终达成的底层洞察是：人格漂移是一个上下文工程问题，而非提示词工程问题。你的系统提示词定义了 Agent 的身份。但模型在第 40 轮实际关注的内容，取决于此时上下文窗口的全部内容——而系统提示词只是该窗口中一个很小、位置处于劣势的片段。
长时 Agent 的上下文工程意味着主动管理每一轮窗口中的内容：
- 捍卫系统提示词的有效位置。 不要让它被埋没。定期重新锚定 。
- 将历史压缩至其决策相关的最小值。 长工具输出是最大的罪魁祸首。将它们精简为下游推理实际需要的字段。
- 将行为基线视为可变状态。 知道它正在漂移并明确检查它，而不是假设系统提示词在被动地维持它。
- 设计具有自然压缩点的会话。 具有清晰阶段（计划 → 执行 → 验证）的长时任务比无定形的开放式会话更容易在阶段边界处重新锚定。
一个值得采用的生产模式：通过在系统提示词中放入复述指令，使重新锚定成为 Agent 的明确责任。例如："在每第十个回复之前，在简短的内部说明中重述你的角色和三个最重要的约束。"这是元认知脚手架——你在要求 Agent 主动维护其自身的行为一致性，而不是假设静态系统提示词会被动地做到这一点。它不能消除漂移，但它给了模型一个明确的钩子来对抗近因偏差。
框架差距
大多数流行的 Agent 框架在默认配置上对漂移的处理不足。标准实现将对话历史视为只追加的数组，从不质疑该数组是否在第 50 轮时产生可靠的行为。
LangGraph 的检查点和状态持久化为你提供了实现重新锚定的原语，但何时以及如何重新锚定的决定并不由框架替你做出。CrewAI 每 50 轮的情景记忆整合是朝正确方向迈出的一步——在固定间隔自动压缩和重新锚定会话历史。AutoGen 的群聊通过对话压缩器支持显式上下文管理，但默认配置并不应用它们。
生产团队面临的框架成熟度问题是：你的框架是否允许你在会话中途的任意位置注入内容、按计划压缩历史，以及在轮次计数超过阈值时触发自定义逻辑？如果不能，你就在应用代码中手动管理漂移，并且很可能以惨痛的方式发现这个问题。
对长时系统的影响
构建在长时 Agent 之上的生产团队——编码 Agent、研究 Agent、处理复杂多会话案例的客户支持 Agent——需要将人格漂移视为一流的可靠性属性。
实际含义是：会话长度是你的可靠性所依赖的一个参数，你应该对其进行度量。追踪你的会话长度分布。在整个会话生命周期中为行为代理信号添加监控。在超过 20–30 轮的会话自然发生之前，就将压缩和重新锚定构建进去。
那些晚发现漂移的团队，是那些只监控"请求是否成功"而非"Agent 在整个过程中行为是否一致"的团队。两个问题都很重要，但只有第二个能捕捉到漂移。Agent 在偏离其约束后完成任务仍然是一种失败模式——只是在有人审查记录之前，它看起来像是成功。
你的监控系统应该对你的 Agent 在第 5 轮与第 50 轮的行为有明确的判断。如果没有，你就在大部分有趣的失败发生的那部分会话中盲目飞行。
人格漂移不是一个需要修复的 bug——它是大型语言模型处理长序列方式的特性。那些构建可靠长时 Agent 的团队，是将漂移视为需要管理的预期现象而非需要预防的边缘情况的团队。这种框架的转变——从"模型应该直接遵循指令"到"上下文窗口是我负责管理的状态"——是使 Agent 在数百轮中保持连贯的团队与那些悄然停止成为你所要求的角色的 Agent 之间的区别 。
