你的代理跑偏时不会崩溃，它只是继续向你收费

它不会抛出异常。它不会返回格式错误的JSON。它只是悄悄地停止执行你要求的任务——失去线索、重复自己、回答无人提出的问题——并且在此后的每一步都继续消耗令牌。约束解码保证了输出的形状。它对于代理是否仍在执行任务没有意见。因此，我为此构建了一个检测器并开源了它： from driftguard import AgentWatch watch = AgentWatch(task="the objective you gave the agent") for step in loop: out = agent.step() if watch.observe(out).drifting: halt() 两个信号，都根据代理自身历史进行衡量：相关性——输出是否仍与给定任务相关？自漂移——输出分布是否偏离了该代理在工作时产生的分布？两者都不需要外部的“正确”概念。唯一的假设是你的代理曾经是自洽且切题的——这是你无需人工干预就能实际检查的唯一事情。漂移不是单个坏步骤。单个坏输出是噪声。漂移是相对于该代理自身基线的上升率，以标准误差衡量，仅在连续25个窗口中持续违规时触发调用。一个更早的单窗口版本会在健康代理上触发——这正是需要此要求的原因。实测：400步代理，在第200步脱轨 → 在第228步检测到漂移（28步调用延迟）；健康代理，600步 × 3次试验 → 零误报。限制，事先说明：相关性默认是词袋模型——无模型、无API调用、每步零成本。如果你的代理在语义上漂移但词汇上保持切题，可替换为嵌入；下游的统计相同。约28步调用延迟是实现零误报的代价。在单步调用的检测器也会在健康代理上触发——这是实测的，不是假设的。它告诉你停止。它不修复代理。发布的演示使用标准库文档字符串与源代码对比，因此没有依赖，且两者仅相差约1.6倍——这使得演示的延迟看起来比实际数字更差。这在README中而非隐藏。无依赖，Python 3.10+，离线运行。我最不确定的参数是25窗口保持——对于短代理运行可能过于保守。如果你运行少于100步的循环，我真的很想知道你想要什么。