1. 什么是 Agent Drift从一个真实故障说起如果你正在做 AI Agent 相关的开发或运维大概率遇到过这种场景昨天还跑得好好的智能体今天突然开始胡言乱语或者原本能正确调用的工具开始频繁报错又或者它开始“忘记”你之前反复强调的约束条件。你翻遍代码发现没有任何改动你检查 API一切正常你重启服务问题依旧。这种让人抓狂的现象就是Agent Drift中文可以理解为“智能体漂移”。Agent Drift 指的是 AI Agent 在持续运行或多次交互过程中其行为、输出风格、决策逻辑逐渐偏离初始设定或预期目标的现象。它不是某一次请求的偶发错误而是一种渐进式的、累积性的行为偏移。打个比方就像一辆车在高速上行驶方向盘没有锁死但路面有轻微倾斜你不去修正车就会慢慢跑偏最终偏离车道。这个问题之所以值得单独拿出来讲是因为它和传统的软件 Bug 有本质区别。传统 Bug 通常是确定性的——同样的输入必然导致同样的错误你可以通过断点调试、日志追踪精确定位。但 Agent Drift 往往是概率性的、上下文依赖的、多因素耦合的它可能只在特定对话轮次、特定工具组合、特定模型版本下才会显现。更麻烦的是它经常在你不注意的时候悄悄发生等到你发现时已经积累了大量错误输出甚至影响了线上业务。这篇文章适合三类人一是正在构建基于大模型的 Agent 系统的工程师二是负责 Agent 线上运维和监控的 SRE 或平台开发者三是对 AI 系统可靠性感兴趣的技术管理者。我会从成因、检测、缓解、预防四个维度展开结合我在实际项目中踩过的坑给出可落地的方案和参数建议。全文不会涉及任何敏感话题只聚焦技术本身。2. Agent Drift 的核心成因拆解2.1 上下文窗口的“记忆衰减”效应大模型的上下文窗口是有限的。当你和一个 Agent 进行长对话时早期的对话内容会逐渐被挤出窗口或者被压缩、摘要。这个过程看似无害实则暗藏杀机。假设你在第 3 轮告诉 Agent“所有金额单位必须用人民币”到了第 50 轮这条约束可能已经被挤出了有效上下文Agent 自然就开始用美元了。这不是它“故意”违反而是它“忘了”。更隐蔽的是即使使用了摘要机制摘要本身也可能引入偏差。比如摘要模型把“不要使用被动语态”概括成了“注意语言风格”信息就丢失了。我实测过一个客服 Agent在 30 轮对话后它对退款政策的引用准确率从 98% 降到了 72%原因就是早期的政策原文被摘要成了模糊表述。2.2 工具调用结果的“污染累积”Agent 经常需要调用外部工具比如搜索、数据库查询、代码执行。每次工具返回的结果都会进入上下文影响后续决策。如果某次工具返回了错误或异常数据这个错误就可能像病毒一样污染后续的推理链。比如一个股票分析 Agent某次 API 返回了延迟的行情数据Agent 基于这个数据给出了错误建议而这个错误建议又成了下一轮推理的前提偏差就这样一步步放大。我见过最严重的一次是一个自动化运维 Agent因为一次监控接口超时返回了空值它误判服务已下线触发了重启流程重启后服务确实短暂不可用它又进一步确认了“服务有问题”的判断最终陷入了反复重启的死循环。这就是典型的工具结果污染导致的 Drift。2.3 模型版本与推理参数的隐性变化很多人以为模型版本不变行为就不会变。但实际上即使你固定了模型版本号推理服务端的批处理策略、量化精度、温度参数、top-p 采样等都可能因为负载变化而动态调整。比如高峰期为了降低延迟服务端可能自动降低了推理精度这会导致模型输出的稳定性下降Agent 的行为随之漂移。另外如果你使用的是托管服务提供商可能在你不察觉的情况下更新了底层推理引擎或安全过滤器。这些变化不会体现在你的代码里但会实实在在影响 Agent 的表现。我建议每次发现 Drift 时第一件事就是记录当前的时间戳和模型服务版本方便后续对比。2.4 提示词与系统指令的“语义磨损”系统提示词是 Agent 的“宪法”但这部宪法在每次交互中都会被重新解释。随着对话轮次增加Agent 对系统指令的注意力权重会逐渐下降。特别是在多轮对话中用户的最新输入往往占据更高的注意力系统指令被“边缘化”。如果用户输入本身带有模糊性或诱导性Agent 就更容易偏离初始设定。举个例子你设定了一个“只回答技术问题”的 Agent前几轮它严格遵守。但当用户连续问了几轮闲聊后Agent 的“技术问题”边界就模糊了开始回答生活类问题。这不是它违反了规则而是它对规则的理解在上下文中被稀释了。3. 如何检测 Agent Drift从指标到实操3.1 建立行为基线没有基线就没有漂移检测 Drift 的前提是你知道“正常”是什么样。我建议在 Agent 上线初期用一批标准测试用例跑出基线数据包括输出长度分布、工具调用频率、关键实体出现率、情感倾向得分、任务完成率等。这些指标不需要很复杂但必须可量化、可复现。比如我为一个法律咨询 Agent 建立的基线包括每轮平均引用法条数量、拒绝回答率、追问率、用户满意度评分。上线后每天用同一批测试用例跑一次对比基线。如果某天引用法条数量突然下降了 30%那就说明 Agent 可能开始“偷懒”或“遗忘”了。3.2 实时监控的关键指标线上环境不可能每天跑全量测试所以需要实时监控。我通常关注以下几类指标指标类型具体指标异常阈值建议说明输出稳定性输出长度标准差超过基线 2 倍长度突变往往意味着行为异常工具调用工具调用失败率连续 3 次失败可能是参数漂移导致语义一致性与系统指令的语义相似度低于 0.75用嵌入模型计算任务完成端到端任务成功率下降超过 15%最直接的业务指标循环检测重复输出相似度连续 2 轮高于 0.9可能陷入死循环这些指标不需要全部上选 2-3 个最关键的即可。我一般先用输出长度和工具调用失败率做第一道防线因为这两个最容易实现且误报率低。3.3 用“影子测试”提前发现漂移影子测试是我最推荐的方法之一。具体做法是在正式上线新版本或新提示词之前让新 Agent 和旧 Agent 同时处理相同的请求流但新 Agent 的输出不返回给用户只用于对比。通过对比两者的输出差异可以提前发现潜在的 Drift。我通常会计算两个 Agent 输出的编辑距离、语义相似度、关键实体重合度。如果语义相似度低于 0.85就需要人工介入分析。这个方法帮我在一次提示词优化中提前发现了一个严重问题新提示词导致 Agent 在 20% 的情况下会忽略用户的安全约束。3.4 人工抽检与用户反馈闭环自动化指标再全也替代不了人工判断。我建议每天随机抽取 20-50 条对话记录由业务专家快速浏览标记“感觉不对”的案例。这些案例往往能揭示自动化指标无法捕捉的微妙漂移。同时建立用户反馈入口比如“这个回答有帮助吗”按钮把负面反馈和对话日志关联起来定期分析。我踩过的一个坑是早期只依赖自动化指标结果 Agent 的输出在语法和格式上完全正常但内容越来越“空泛”自动化指标完全没报警。后来加入人工抽检才发现Agent 开始用大量套话填充回答实际信息量下降了 40%。这种“软性漂移”必须靠人来发现。4. 缓解与修复 Agent Drift 的实操方案4.1 上下文管理定期“重锚”系统指令既然上下文稀释是主因之一那就要主动对抗。我的做法是每隔 N 轮对话就把系统指令重新注入一次上下文。N 的取值取决于任务复杂度一般 5-10 轮比较合适。注入时不要简单重复原文而是用一句简短的提醒比如“记住你是一个只回答技术问题的助手金额单位是人民币”。另外可以使用分层上下文策略把系统指令放在最高优先级工具结果放在中等优先级用户闲聊放在最低优先级。当上下文接近窗口上限时优先丢弃低优先级内容。这个策略需要你的 Agent 框架支持但实现起来并不复杂很多开源框架都有类似机制。4.2 工具调用的“熔断与校验”针对工具结果污染我建议在工具调用层加两道防线。第一道是熔断机制如果某个工具连续失败 3 次就暂时禁用该工具并让 Agent 明确告知用户“当前无法获取外部数据”。第二道是结果校验对工具返回的数据做基本 sanity check比如数值范围、字段完整性、时间戳新鲜度。校验不通过的结果不进入上下文而是返回一个标准错误提示。我实测过一个天气查询 Agent加入结果校验后因为 API 返回异常导致的 Drift 下降了 90% 以上。校验逻辑很简单温度必须在 -50 到 60 之间湿度必须在 0 到 100 之间时间戳必须是过去 24 小时内。就这几条规则挡住了绝大多数污染。4.3 提示词的“防漂移”写法写系统提示词时有几个技巧可以显著降低 Drift 概率。第一用肯定句而非否定句。不要说“不要回答政治问题”而要说“你只回答技术问题”。因为模型对否定词的处理往往不如肯定词稳定。第二把关键约束放在提示词的开头和结尾利用首因效应和近因效应。第三给约束加上优先级标记比如“【最高优先级】金额单位必须用人民币”。我还习惯在提示词里加入“自检”指令比如“在回答前先确认你的回答是否符合上述所有约束”。这个简单的自检步骤能让 Agent 在生成最终输出前多一次内部校验实测能减少约 30% 的约束违反。4.4 模型与参数的稳定性保障如果你用的是自部署模型尽量固定推理参数不要开启动态批处理或自适应量化。如果用的是托管服务选择那些提供版本锁定和参数固定选项的服务商。同时定期做回归测试用同一批输入对比不同时间点的输出一旦发现显著差异立即排查。我一般会维护一个“金标准”测试集包含 100-200 条覆盖核心场景的输入每周跑一次记录输出哈希和关键指标。如果某次跑出来的结果和上周差异超过阈值就会触发告警。这个方法帮我提前发现了一次服务端模型更新导致的 Drift当时服务商没有发公告但我们的测试集捕捉到了输出风格的变化。5. 常见问题与排查技巧实录5.1 Agent 突然开始重复同一句话怎么排查这是典型的循环漂移。首先检查上下文里是否有重复的工具结果或用户输入这会导致 Agent 陷入“复读”模式。其次检查温度参数是否被意外调高高温会增加随机性但也可能导致模型卡在某个模式里。我的经验是先把温度降到 0.1 以下如果问题消失那就是采样参数的问题如果问题依旧那就是上下文污染需要清理最近几轮的工具结果。5.2 输出格式从 JSON 变成了自然语言怎么办格式漂移通常是因为系统提示词中的格式约束被上下文稀释了。解决方法是在每轮生成前用一句简短的格式提醒重新锚定比如“请以 JSON 格式输出”。另外可以在后处理层加一个格式校验器如果输出不是合法 JSON就自动重试一次并在重试时加强格式指令。我一般会设置最多 2 次重试超过就返回标准错误。5.3 工具调用参数越来越离谱如何修复这往往是工具结果污染和上下文漂移的叠加效应。先检查最近几轮的工具返回是否包含异常值如果有清理掉这些轮次。然后检查工具描述是否足够清晰参数类型和范围是否明确。我建议在工具描述里加入示例调用比如“查询天气时city 参数必须是城市中文名如‘北京’”。示例能显著降低参数漂移的概率。5.4 如何区分 Drift 和正常的模型随机性这是一个关键问题。正常的随机性表现为同一输入的不同输出在语义上等价只是措辞不同。而 Drift 表现为输出在语义上偏离了预期比如遗漏关键信息、违反约束、逻辑矛盾。我的判断方法是用同一输入连续跑 5 次如果 5 次输出都偏离预期那就是 Drift如果只有 1-2 次偏离那可能是随机性。另外Drift 通常具有时间累积性越往后越严重而随机性不会。5.5 常见问题速查表现象可能原因快速排查修复动作重复输出上下文循环检查最近 3 轮清理重复内容降低温度格式错误约束稀释检查系统提示词位置重新注入格式指令工具参数错误描述不清检查工具定义补充参数示例和范围遗忘约束上下文溢出检查窗口占用启用分层上下文或重锚输出空泛软性漂移人工抽检加强具体性指令增加示例任务失败率上升多因素耦合对比基线指标逐项排查优先清理工具结果6. 预防胜于治疗构建抗漂移的 Agent 架构6.1 设计阶段把抗漂移纳入架构与其等 Drift 发生后再修不如在设计阶段就考虑。我建议采用模块化 Agent 架构把系统指令、工具调用、上下文管理、输出校验拆成独立模块每个模块都可以单独监控和调整。这样当 Drift 发生时你可以快速定位是哪个模块出了问题而不是在一大坨代码里大海捞针。另外尽量使用短会话而非长会话。如果业务允许每完成一个任务就重置上下文开启新会话。这能从根本上避免上下文累积导致的漂移。我做过对比短会话模式下 Drift 发生率比长会话低了 70% 以上。6.2 运维阶段建立 Drift 响应流程我建议团队制定一个简单的 Drift 响应流程发现异常 - 记录时间戳和上下文 - 对比基线 - 定位模块 - 应用修复 - 回归测试。这个流程不需要很正式但要让每个成员都知道。我见过太多团队发现 Drift 后第一反应是重启服务结果问题暂时消失但根因没解决过几天又复发。同时保留至少 7 天的完整对话日志和工具调用记录。这些日志是排查 Drift 的“黑匣子”没有它们很多问题根本无法复现。我一般会把日志按会话 ID 和时间戳索引方便快速检索。6.3 持续迭代把 Drift 当作常态最后想说一个心态问题Agent Drift 不是“如果”会发生而是“什么时候”会发生。大模型本质上是概率系统完全消除漂移是不现实的。我们能做的是把它控制在可接受的范围内并建立快速发现和修复的能力。我自己的经验是与其追求零漂移不如追求“漂移可观测、可解释、可修复”。做到这三点你的 Agent 系统就已经比大多数团队靠谱了。在实际项目中我每个月会花半天时间专门做“Drift 复盘”把当月所有异常案例过一遍总结规律更新监控指标和提示词。这个习惯坚持了半年后我们的 Agent 任务成功率从 82% 稳定到了 94% 以上。没有什么银弹就是持续观察、持续调整。 
长河君 · 2026/10/28 20:07:51 · 阅读 1.2k AI Agent漂移全解析：从成因检测到缓解预防的工程实践指南
1. 什么是 Agent Drift从一个真实故障说起如果你正在做 AI Agent 相关的开发或运维大概率遇到过这种场景昨天还跑得好好的智能体今天突然开始胡言乱语或者原本能正确调用的工具开始频繁报错又或者它开始“忘记”你之前反复强调的约束条件。你翻遍代码发现没有任何改动你检查 API一切正常你重启服务问题依旧。这种让人抓狂的现象就是Agent Drift中文可以理解为“智能体漂移”。Agent Drift 指的是 AI Agent 在持续运行或多次交互过程中其行为、输出风格、决策逻辑逐渐偏离初始设定或预期目标的现象。它不是某一次请求的偶发错误而是一种渐进式的、累积性的行为偏移。打个比方就像一辆车在高速上行驶方向盘没有锁死但路面有轻微倾斜你不去修正车就会慢慢跑偏最终偏离车道。这个问题之所以值得单独拿出来讲是因为它和传统的软件 Bug 有本质区别。传统 Bug 通常是确定性的——同样的输入必然导致同样的错误你可以通过断点调试、日志追踪精确定位。但 Agent Drift 往往是概率性的、上下文依赖的、多因素耦合的它可能只在特定对话轮次、特定工具组合、特定模型版本下才会显现。更麻烦的是它经常在你不注意的时候悄悄发生等到你发现时已经积累了大量错误输出甚至影响了线上业务。这篇文章适合三类人一是正在构建基于大模型的 Agent 系统的工程师二是负责 Agent 线上运维和监控的 SRE 或平台开发者三是对 AI 系统可靠性感兴趣的技术管理者。我会从成因、检测、缓解、预防四个维度展开结合我在实际项目中踩过的坑给出可落地的方案和参数建议。全文不会涉及任何敏感话题只聚焦技术本身。2. Agent Drift 的核心成因拆解2.1 上下文窗口的“记忆衰减”效应大模型的上下文窗口是有限的。当你和一个 Agent 进行长对话时早期的对话内容会逐渐被挤出窗口或者被压缩、摘要。这个过程看似无害实则暗藏杀机。假设你在第 3 轮告诉 Agent“所有金额单位必须用人民币”到了第 50 轮这条约束可能已经被挤出了有效上下文Agent 自然就开始用美元了。这不是它“故意”违反而是它“忘了”。更隐蔽的是即使使用了摘要机制摘要本身也可能引入偏差。比如摘要模型把“不要使用被动语态”概括成了“注意语言风格”信息就丢失了。我实测过一个客服 Agent在 30 轮对话后它对退款政策的引用准确率从 98% 降到了 72%原因就是早期的政策原文被摘要成了模糊表述。2.2 工具调用结果的“污染累积”Agent 经常需要调用外部工具比如搜索、数据库查询、代码执行。每次工具返回的结果都会进入上下文影响后续决策。如果某次工具返回了错误或异常数据这个错误就可能像病毒一样污染后续的推理链。比如一个股票分析 Agent某次 API 返回了延迟的行情数据Agent 基于这个数据给出了错误建议而这个错误建议又成了下一轮推理的前提偏差就这样一步步放大。我见过最严重的一次是一个自动化运维 Agent因为一次监控接口超时返回了空值它误判服务已下线触发了重启流程重启后服务确实短暂不可用它又进一步确认了“服务有问题”的判断最终陷入了反复重启的死循环。这就是典型的工具结果污染导致的 Drift。2.3 模型版本与推理参数的隐性变化很多人以为模型版本不变行为就不会变。但实际上即使你固定了模型版本号推理服务端的批处理策略、量化精度、温度参数、top-p 采样等都可能因为负载变化而动态调整。比如高峰期为了降低延迟服务端可能自动降低了推理精度这会导致模型输出的稳定性下降Agent 的行为随之漂移。另外如果你使用的是托管服务提供商可能在你不察觉的情况下更新了底层推理引擎或安全过滤器。这些变化不会体现在你的代码里但会实实在在影响 Agent 的表现。我建议每次发现 Drift 时第一件事就是记录当前的时间戳和模型服务版本方便后续对比。2.4 提示词与系统指令的“语义磨损”系统提示词是 Agent 的“宪法”但这部宪法在每次交互中都会被重新解释。随着对话轮次增加Agent 对系统指令的注意力权重会逐渐下降。特别是在多轮对话中用户的最新输入往往占据更高的注意力系统指令被“边缘化”。如果用户输入本身带有模糊性或诱导性Agent 就更容易偏离初始设定。举个例子你设定了一个“只回答技术问题”的 Agent前几轮它严格遵守。但当用户连续问了几轮闲聊后Agent 的“技术问题”边界就模糊了开始回答生活类问题。这不是它违反了规则而是它对规则的理解在上下文中被稀释了。3. 如何检测 Agent Drift从指标到实操3.1 建立行为基线没有基线就没有漂移检测 Drift 的前提是你知道“正常”是什么样。我建议在 Agent 上线初期用一批标准测试用例跑出基线数据包括输出长度分布、工具调用频率、关键实体出现率、情感倾向得分、任务完成率等。这些指标不需要很复杂但必须可量化、可复现。比如我为一个法律咨询 Agent 建立的基线包括每轮平均引用法条数量、拒绝回答率、追问率、用户满意度评分。上线后每天用同一批测试用例跑一次对比基线。如果某天引用法条数量突然下降了 30%那就说明 Agent 可能开始“偷懒”或“遗忘”了。3.2 实时监控的关键指标线上环境不可能每天跑全量测试所以需要实时监控。我通常关注以下几类指标指标类型具体指标异常阈值建议说明输出稳定性输出长度标准差超过基线 2 倍长度突变往往意味着行为异常工具调用工具调用失败率连续 3 次失败可能是参数漂移导致语义一致性与系统指令的语义相似度低于 0.75用嵌入模型计算任务完成端到端任务成功率下降超过 15%最直接的业务指标循环检测重复输出相似度连续 2 轮高于 0.9可能陷入死循环这些指标不需要全部上选 2-3 个最关键的即可。我一般先用输出长度和工具调用失败率做第一道防线因为这两个最容易实现且误报率低。3.3 用“影子测试”提前发现漂移影子测试是我最推荐的方法之一。具体做法是在正式上线新版本或新提示词之前让新 Agent 和旧 Agent 同时处理相同的请求流但新 Agent 的输出不返回给用户只用于对比。通过对比两者的输出差异可以提前发现潜在的 Drift。我通常会计算两个 Agent 输出的编辑距离、语义相似度、关键实体重合度。如果语义相似度低于 0.85就需要人工介入分析。这个方法帮我在一次提示词优化中提前发现了一个严重问题新提示词导致 Agent 在 20% 的情况下会忽略用户的安全约束。3.4 人工抽检与用户反馈闭环自动化指标再全也替代不了人工判断。我建议每天随机抽取 20-50 条对话记录由业务专家快速浏览标记“感觉不对”的案例。这些案例往往能揭示自动化指标无法捕捉的微妙漂移。同时建立用户反馈入口比如“这个回答有帮助吗”按钮把负面反馈和对话日志关联起来定期分析。我踩过的一个坑是早期只依赖自动化指标结果 Agent 的输出在语法和格式上完全正常但内容越来越“空泛”自动化指标完全没报警。后来加入人工抽检才发现Agent 开始用大量套话填充回答实际信息量下降了 40%。这种“软性漂移”必须靠人来发现。4. 缓解与修复 Agent Drift 的实操方案4.1 上下文管理定期“重锚”系统指令既然上下文稀释是主因之一那就要主动对抗。我的做法是每隔 N 轮对话就把系统指令重新注入一次上下文。N 的取值取决于任务复杂度一般 5-10 轮比较合适。注入时不要简单重复原文而是用一句简短的提醒比如“记住你是一个只回答技术问题的助手金额单位是人民币”。另外可以使用分层上下文策略把系统指令放在最高优先级工具结果放在中等优先级用户闲聊放在最低优先级。当上下文接近窗口上限时优先丢弃低优先级内容。这个策略需要你的 Agent 框架支持但实现起来并不复杂很多开源框架都有类似机制。4.2 工具调用的“熔断与校验”针对工具结果污染我建议在工具调用层加两道防线。第一道是熔断机制如果某个工具连续失败 3 次就暂时禁用该工具并让 Agent 明确告知用户“当前无法获取外部数据”。第二道是结果校验对工具返回的数据做基本 sanity check比如数值范围、字段完整性、时间戳新鲜度。校验不通过的结果不进入上下文而是返回一个标准错误提示。我实测过一个天气查询 Agent加入结果校验后因为 API 返回异常导致的 Drift 下降了 90% 以上。校验逻辑很简单温度必须在 -50 到 60 之间湿度必须在 0 到 100 之间时间戳必须是过去 24 小时内。就这几条规则挡住了绝大多数污染。4.3 提示词的“防漂移”写法写系统提示词时有几个技巧可以显著降低 Drift 概率。第一用肯定句而非否定句。不要说“不要回答政治问题”而要说“你只回答技术问题”。因为模型对否定词的处理往往不如肯定词稳定。第二把关键约束放在提示词的开头和结尾利用首因效应和近因效应。第三给约束加上优先级标记比如“【最高优先级】金额单位必须用人民币”。我还习惯在提示词里加入“自检”指令比如“在回答前先确认你的回答是否符合上述所有约束”。这个简单的自检步骤能让 Agent 在生成最终输出前多一次内部校验实测能减少约 30% 的约束违反。4.4 模型与参数的稳定性保障如果你用的是自部署模型尽量固定推理参数不要开启动态批处理或自适应量化。如果用的是托管服务选择那些提供版本锁定和参数固定选项的服务商。同时定期做回归测试用同一批输入对比不同时间点的输出一旦发现显著差异立即排查。我一般会维护一个“金标准”测试集包含 100-200 条覆盖核心场景的输入每周跑一次记录输出哈希和关键指标。如果某次跑出来的结果和上周差异超过阈值就会触发告警。这个方法帮我提前发现了一次服务端模型更新导致的 Drift当时服务商没有发公告但我们的测试集捕捉到了输出风格的变化。5. 常见问题与排查技巧实录5.1 Agent 突然开始重复同一句话怎么排查这是典型的循环漂移。首先检查上下文里是否有重复的工具结果或用户输入这会导致 Agent 陷入“复读”模式。其次检查温度参数是否被意外调高高温会增加随机性但也可能导致模型卡在某个模式里。我的经验是先把温度降到 0.1 以下如果问题消失那就是采样参数的问题如果问题依旧那就是上下文污染需要清理最近几轮的工具结果。5.2 输出格式从 JSON 变成了自然语言怎么办格式漂移通常是因为系统提示词中的格式约束被上下文稀释了。解决方法是在每轮生成前用一句简短的格式提醒重新锚定比如“请以 JSON 格式输出”。另外可以在后处理层加一个格式校验器如果输出不是合法 JSON就自动重试一次并在重试时加强格式指令。我一般会设置最多 2 次重试超过就返回标准错误。5.3 工具调用参数越来越离谱如何修复这往往是工具结果污染和上下文漂移的叠加效应。先检查最近几轮的工具返回是否包含异常值如果有清理掉这些轮次。然后检查工具描述是否足够清晰参数类型和范围是否明确。我建议在工具描述里加入示例调用比如“查询天气时city 参数必须是城市中文名如‘北京’”。示例能显著降低参数漂移的概率。5.4 如何区分 Drift 和正常的模型随机性这是一个关键问题。正常的随机性表现为同一输入的不同输出在语义上等价只是措辞不同。而 Drift 表现为输出在语义上偏离了预期比如遗漏关键信息、违反约束、逻辑矛盾。我的判断方法是用同一输入连续跑 5 次如果 5 次输出都偏离预期那就是 Drift如果只有 1-2 次偏离那可能是随机性。另外Drift 通常具有时间累积性越往后越严重而随机性不会。5.5 常见问题速查表现象可能原因快速排查修复动作重复输出上下文循环检查最近 3 轮清理重复内容降低温度格式错误约束稀释检查系统提示词位置重新注入格式指令工具参数错误描述不清检查工具定义补充参数示例和范围遗忘约束上下文溢出检查窗口占用启用分层上下文或重锚输出空泛软性漂移人工抽检加强具体性指令增加示例任务失败率上升多因素耦合对比基线指标逐项排查优先清理工具结果6. 预防胜于治疗构建抗漂移的 Agent 架构6.1 设计阶段把抗漂移纳入架构与其等 Drift 发生后再修不如在设计阶段就考虑。我建议采用模块化 Agent 架构把系统指令、工具调用、上下文管理、输出校验拆成独立模块每个模块都可以单独监控和调整。这样当 Drift 发生时你可以快速定位是哪个模块出了问题而不是在一大坨代码里大海捞针。另外尽量使用短会话而非长会话。如果业务允许每完成一个任务就重置上下文开启新会话。这能从根本上避免上下文累积导致的漂移。我做过对比短会话模式下 Drift 发生率比长会话低了 70% 以上。6.2 运维阶段建立 Drift 响应流程我建议团队制定一个简单的 Drift 响应流程发现异常 - 记录时间戳和上下文 - 对比基线 - 定位模块 - 应用修复 - 回归测试。这个流程不需要很正式但要让每个成员都知道。我见过太多团队发现 Drift 后第一反应是重启服务结果问题暂时消失但根因没解决过几天又复发。同时保留至少 7 天的完整对话日志和工具调用记录。这些日志是排查 Drift 的“黑匣子”没有它们很多问题根本无法复现。我一般会把日志按会话 ID 和时间戳索引方便快速检索。6.3 持续迭代把 Drift 当作常态最后想说一个心态问题Agent Drift 不是“如果”会发生而是“什么时候”会发生。大模型本质上是概率系统完全消除漂移是不现实的。我们能做的是把它控制在可接受的范围内并建立快速发现和修复的能力。我自己的经验是与其追求零漂移不如追求“漂移可观测、可解释、可修复”。做到这三点你的 Agent 系统就已经比大多数团队靠谱了。在实际项目中我每个月会花半天时间专门做“Drift 复盘”把当月所有异常案例过一遍总结规律更新监控指标和提示词。这个习惯坚持了半年后我们的 Agent 任务成功率从 82% 稳定到了 94% 以上。没有什么银弹就是持续观察、持续调整。