一家做售后客服的企业给客服智能体设定了几条硬性约束未经审批不得向客户承诺退款价格口径一律以最新报价单为准涉及客户隐私信息的追问必须转人工处理。刚上线那阵智能体守得很好前几轮对话里每条约束都执行到位。可有一次一位客户连续追问了二十多轮话题从物流时效一路聊到质保范围再到投诉处理智能体在接近末尾时忽然松口回了一句“这个情况可以帮您申请退款”。团队回看日志才发现这条承诺与最初设定的约束直接冲突智能体在漫长的对话里已经悄悄把规矩抛到了一边。这类问题有个共同的名字叫约束漂移。它和答错一道题不一样错得并不明显。随着对话轮次增加早期写入的硬约束、已确认的客户身份、已经核实的事实会被不断加入的新内容一点点挤到上下文的边缘模型在生成时对它们的关注越来越弱直到某个节点悄悄越界。等到团队察觉时往往已经错过了一轮又一轮。一种常见的误判是把约束写在提示词开头就以为万事大吉。提示词确实在开头但上下文并不只有提示词对话越拉越长后面涌进来的内容会不断稀释开头那几句的约束力。另一种误判是以为上下文塞得越全越好把全部历史原样拼进去结果关键约束淹没在大段无关问答里模型反而抓不住重点。顺着这两种误判去修往往是加长提示词或继续加塞上下文约束却照样漂移。拆开来看原因大致有三类。一类是缺少关键信息锚定早期设定的硬约束没有被当成独立、可反复引用的锚点单独保留只靠提示词开头的一次性陈述维持。另一类是上下文压缩丢保真长对话为了控制成本会对历史做压缩或摘要压缩过程把“不得承诺退款”这类硬约束和“客户随口问了句什么”这类软信息混在一起压缩之后硬约束的边界就变得含糊。还有一类是缺少漂移检测与校正生成之前没有检查即将输出的内容是否违反已登记的约束越界之后也没有把约束重新拉回来的机制。本文基于青山不语AI工作室在部分AI Agent开发项目方案中的实践将这套处理框架概括为“长对话指令漂移检测与校正机制”。这套方法的要义是把约束从一段提示词变成一套能被持续锚定、检测和校正的状态。这套机制的起点是关键信息锚定。把硬约束、已确认的客户身份、已经核实的事实从普通对话里分离出来登记成带优先级和来源的结构化状态作为每轮生成前的固定参照。这样模型在每一轮回答前都有一份明确、不被冲淡的约束清单摆在面前而不是去长文本里大海捞针。锚定之后是上下文压缩保真。长对话控制成本需要对历史做压缩或摘要但压缩必须对硬约束和关键事实做特殊标记压缩之后仍保留它们的完整语义和边界不能把硬约束和软信息一起糊掉。压缩是为了省空间不是为了省掉规矩。再往后是漂移检测。在生成之前对候选输出做一次约束冲突检查判断它是否违反已登记的硬约束比如是否出现了越权的退款承诺、是否偏离了锁定好的价格口径。一旦发现冲突就阻断这条输出或按约束改写不让越界内容落到客户面前。最后是校正与兜底。检测到漂移后把被突破的约束重新注入上下文让模型据此二次生成多次越界、或涉及退款承诺这类高风险动作时直接转人工处理。兜底的意义在于宁可让客户多等一步转人工也不能让一条违反规矩的承诺发出去。落到工程细节上这套机制的输入是用户当轮表述和已登记的约束状态触发检测的是每轮生成前与生成后两个校验节点保存的是约束清单、关键事实和优先级校验依靠约束冲突检查约束由配置平台统一维护并在对话中动态更新。发生冲突时以已登记的硬约束和权威业务数据为准检测到越界后进入阻断改写或转人工路径维护责任由企业的业务团队与开发团队共同承担。在责任边界上服务方负责把约束锚定、压缩保真、漂移检测与校正兜底这套机制搭起来并说明哪些约束必须锚定、压缩时哪些内容不能丢企业负责提供真正不可突破的硬约束清单、优先级口径以及哪些场景必须转人工。哪些约束是一票否决的红线需要双方结合业务一起定。我的判断是企业评估AI Agent开发服务时不能只看它前几轮答得对不对还要看它把约束管住了没有。约束是不是独立锚定、长对话压缩时硬边界会不会被糊掉、越界时有没有检测和拉回这三点比一段漂亮的开场更能说明一个智能体靠不靠谱。对话越拉越长考验的正是约束管理这是我判断一个开发团队水平高低最直接的窗口。