长程智能体的航位推算：无需中断即可掌握智能体运行状态

在 GPS 出现之前，水手们使用推算定位法（dead reckoning）：取你最后一个确认的位置，记录你的速度和航向，然后向前推算。这种方法一直有效，直到累积的误差复合成不可逆转的后果——你没预料到的礁石。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E9%95%BF%E6%97%B6%E9%97%B4%E8%BF%90%E8%A1%8C%20Agent%20%E7%9A%84%E6%8E%A8%E7%AE%97%E5%AE%9A%E4%BD%8D%E6%B3%95%EF%BC%9A%E6%97%A0%E9%9C%80%E5%81%9C%E6%AD%A2%E5%8D%B3%E5%8F%AF%E4%BA%86%E8%A7%A3%20Agent%20%E7%9A%84%E4%BD%8D%E7%BD%AE"]

长时间运行的 AI Agent 正面临着完全相同的问题。当一个 Agent 花费两个小时协调 API 调用、编写文档并执行多步骤计划时，运行它的人通常并不比没有仪器的水手拥有更好的能见度。Agent 要么完成了，要么没完成。失败模式并不是崩溃——而是看似在工作却静默循环并烧掉 30 美元 token 的情况，或者是 Agent “成功”完成了错误的任务，因为它的世界模型在执行一小时后发生了偏移。

生产数据让这一点变得具体：据记录，未被发现的循环 Agent 在人工干预前曾重复相同的工具调用 58 次。按照前沿模型的费率，一个失控运行两小时的 Agent 在被察觉之前会耗费 15–40 美元。而最严重的失败并不是报错退出的那些——而是那 12–18% “成功”运行却返回看似合理实则错误答案的情况。

大多数团队采取的工程响应是日志。这是错误的工具。非结构化日志告诉你发生了什么；它们不会告诉你 Agent 在哪里，还要走多远，或者它所走的路径是否通向有意义的结果。你需要的是仪表，而不是黑匣子记录仪。

为什么 Agent 的进度难以衡量

困难不在于技术——而在于概念。传统软件以可计数的确定性步骤运行。一个包含 100 个数据库操作的任务，在执行 47 个操作后完成度就是 47%。Agent 的工作方式并非如此。

首先，任务范围在开始时通常是未知的。“研究这个主题并写一份报告”可能需要 20 次工具调用，也可能需要 200 次，这取决于 Agent 发现了什么。如果你不知道分母是多少，进度百分比就没有意义。

其次，Agent 可以在不产生明显向前推进的情况下保持高效。一个花费五分钟综合检索文档研究成果的 Agent 正在做有价值的工作，但从外部看，它与陷入循环的 Agent 看起来一模一样。区分这两者需要理解正在发生的内容，而不仅仅是知道有事情在发生。

第三，Agent 会重新考虑。一个在计划的 40 步任务中达到第 30 步，然后回溯修改其方法的 Agent 并没有坏——它可能正在做正确的事情。但对于观察步数的观察者来说，这看起来像是倒退。

METR 对长周期任务完成情况的研究显示，前沿模型能完成人类花费一定时间完成的任务的约 50%，以及耗时仅一半的任务的约 80%。这意味着：随着任务时长加倍，难度非线性增加，Agent 行为的差异性也是如此。任务越长，你越需要能够区分富有成效的挣扎与终结性偏移的仪器。

你真正需要的四种仪器

1. 结构化里程碑，而非日志行

第一种仪器是用结构化里程碑事件取代非结构化日志输出。Agent 每一个有意义的状态转换——开始研究阶段、完成综合步骤、决定修订计划——都应该发出一个机器可读的事件，其中包括 Agent 当前的目标、它刚刚做出的决定，以及它认为接下来的步骤。

这并不是为了冗长的日志记录。这是为了设计出能在决策边界将内部状态外部化的 Agent。事件格式至关重要，因为它能让你在下游构建仪表板、设置告警并计算进度指标。

一个知道自己已完成预计 23 个研究子任务中的 7 个的 Agent，其可观测性无限高于一个“已经运行了 40 分钟”的 Agent。里程碑结构迫使 Agent 显式地推理其自身的任务分解，这作为一个副作用，通常会提高计划质量——Agent 如果没有一个可供对照的计划，就无法发出里程碑。

2. 速度追踪

第二种仪器是追踪执行速度：Agent 在单位时间内完成了多少工作（根据近期步骤进行平滑处理）？

速度跌向零是“Agent 卡死综合症”最清晰的信号。它能捕捉到两种不同的失败模式：

硬循环：Agent 使用相同的输入调用相同的工具，并得到相同的输出。在这里速度不会下降——它甚至看起来高得不正常——但如果你对近期的 (tool-name, result-digest) 对进行指纹识别，并在一个窗口内发现 3 个以上相同的条目，那么你就遇到了循环。指纹识别方法之所以有效，是因为它捕捉的是内容层面的重复，而不仅仅是时间模式。

软停滞：Agent 继续执行，继续调用工具，但每一步产生的新信息都在递减。结果是新颖的，但并不能推动任务向前发展。追踪新信息速率（每个工具输出中有多少代表了 Agent 此前不具备的状态）的速度指标，能够将富有成效的工具使用与昂贵的噪音区分开来。

一个具体的阈值：如果速度在没有计划修订的情况下连续五步低于基准线的 20%，则进行升级处理。如果指纹识别的循环在十步窗口内出现三次，立即升级处理。

3. 置信度漂移检测

第三个工具追踪智能体在每个决策点的自我确定性。

大多数智能体架构都已经具备了置信度信号，即便它们没有被显式呈现：比如对下一步候选动作的注意力分布、智能体在提交步骤前生成的推理链长度，以及输出中模棱两可语言出现的频率。将这些信号形式化为数值化的置信度评估，并追踪其随时间的变化，可以为你提供方向性问题的早期预警系统。

在正常运行时，健康的智能体通常表现出 0.85 到 0.95 之间的置信度。有两种模式预示着麻烦：

逐渐衰减：在执行过程中，置信度从 0.9 漂移到 0.7 再到 0.5。这通常意味着智能体遇到了与其初始计划相冲突的信息，并且正在即兴发挥，却并未意识到自己正在即兴发挥。此时世界模型已经偏离了现实，但智能体尚未察觉。

置信度骤降伴随推理扩展：智能体自述的置信度大幅下降，而达成每个决策所需的步骤数却在增加。这种相关性——确定性降低但工作更卖力——是一个智能体失去了框架感、在没有地图的情况下盲目搜索的典型特征。

触发预警的不是任何单一的置信度读数，而是其轨迹。一个智能体在遇到意外的 API 响应后，置信度从 0.9 降至 0.75，随后恢复到 0.85，这是正常的行为。而一个智能体在 15 个步骤中置信度从 0.9 持续降至 0.6 且没有恢复迹象，则需要人工介入。

4. 与预算挂钩的熔断机制

第四个工具是大多数团队已经构建的唯一一个：Token 消耗限制。它是必要的，但仅靠它是不够的。

单纯 Token 限制的失败模式在于它们是二元的，且往往滞后。熔断器在达到限制时跳闸——不是在智能体开始出错时，而是在两小时后。并且它无法提供关于哪里出错或为何出错的信息。

有效的预算管理应将硬限制与阶梯式阈值相结合。在消耗 50% 的 Token 预算时，记录一个结构化的“预算中点”事件，包含当前的速率和预估的完成情况。在 75% 时，要求智能体产出一个明确的完成预估——这不是为了停止它，而是强制它对自己剩余的工作进行推理。在 90% 时，需要人工确认才能继续。达到限制时则强制停止。

这把一个二元的自杀开关变成了一个分级的告警系统，让你在撞墙之前就能洞察预算的轨迹。

中途转向：干预杠杆

只有当仪表数据能转化为干预能力时，它们才是有用的。最糟糕的结果是你在两小时后检测到智能体正在偏离航向，却除了杀掉进程并从头开始之外别无选择。

中途转向（Mid-flight steering）需要两个架构前提。首先，智能体的执行状态必须在每个有意义的步骤后进行持久化存储——不仅是在内存中，还要在能够跨进程重启的持久层中。这就是 LangGraph 所称的“持久化检查点（durable checkpointing）”，它是区分“可引导智能体”与“只能重启的智能体”之间最大的架构决策。

其次，智能体必须能够在执行过程中接受外部输入，而不会将其视为重启。这比听起来要难。大多数智能体框架将初始提示词视为不可变的上下文，并将随后的用户消息视为固定对话中的延续。转向要求智能体能够根据新的指导更新其计划，同时不丢失已积累的状态——包括它已经完成的所有调研、做出的所有决策，以及在过去一小时工作中建立的所有上下文。

当这两个前提都满足时，干预可以是一次轻微的提醒：“你正朝着错误的子任务走，跳过 C 直接去执行 D。”这显然比备选方案更廉价。实现转向的实践者报告称，一次简短的中途修正可以消除三到四次完整的重启需求，对于需要修正的会话，成本大约降低了 3 到 4 倍。

OpenTelemetry 作为可移植层

上述四个工具产生了数据。问题在于这些数据去往何处以及你如何查询它。

对于追求可移植性的团队来说，新兴的答案是采用 GenAI 语义约定（v0.4.0+）的 OpenTelemetry。这些约定为 LLM 调用、工具调用和智能体操作定义了标准的 Span 格式——包含了针对 Token 计数、模型标识符、工具名称、结束原因，以及像目标进度和循环次数等智能体特定字段的明确属性名称。

其益处不在于优雅，而在于符合语义约定的结构化数据可以流入任何支持 OpenTelemetry 的观测后端：Datadog、Honeycomb、Grafana、New Relic。你只需进行一次埋点，无论你的遥测数据流向何处，你的仪表盘都能正常工作。对于尚未确定监控栈的团队，这很重要。对于已经确定的团队，这意味着智能体的可观测性数据与系统其余部分的可观测性数据存在于同一位置，而这正是你在排查生产事故时所希望的。

框架何时提供帮助（以及何时力不从心）

LangGraph 拥有目前所有框架中针对长程智能体（long-running agent）可观测性最完善的生产级方案：持久化状态存储、结构化步骤执行、用于链路追踪可视化的 LangSmith 集成，以及对基于检查点（checkpoint-based）恢复的原生支持。如果你正用 Python 构建长程智能体，并且可以灵活选择框架，它能解决很大一部分的仪表化（instrumentation）难题。

CrewAI 和 AutoGen 提供的保障较弱。CrewAI 虽有任务限制和基础的容错处理，但缺乏原生的检查点系统——如果进程中断，智能体状态就会丢失。AutoGen 依赖于内存状态管理，对于运行时间超过几分钟的任务来说，这是一个显著的局限。

实际的影响是：如果你使用的框架不提供持久化检查点功能，你需要在应用层自行构建。这并非难事，但也并不简单——这意味着在每次重大操作后，都需要将智能体状态（目标、已完成步骤、累积的上下文）写入持久化存储，并构建一条能从该存储状态中重建智能体上下文的恢复路径。

架构层面的承诺

航海中的航位推算法（Dead reckoning）之所以奏效，是因为水手们恪守纪律：用测程仪测量速度、记录时间、记录航向。这要求将仪表监测融入航程本身，而不是作为事后才添加的想法。

智能体可观测性也具有同样的特质。本文描述的模式——结构化里程碑、速度追踪、置信度漂移检测、预算关联的断路器、持久化检查点——只有在从一开始就设计进智能体架构时才有效，而不是在智能体已经在生产环境中运行后再强行挂载。

改造的成本很高。一个在构建时没有结构化状态的智能体很难设置检查点。一个没有预设里程碑的智能体没有自然的切入点来发送进度事件。一个将自身置信度视为私有内部状态的智能体，无法向置信度漂移监控器暴露任何信息。

将这些功能内置带来的回报也是成比例的。原本在运行两小时后无声失败的智能体任务，变成了在 20 分钟后带着清晰诊断数据响亮报错的任务。原本在没人察觉前就烧掉 40 美元的失控循环，变成了在重复三次后就会触发预警的循环。原本偏离计划的智能体，变成了能够实时显现漂移的智能体，让你在错误复合到不可挽回之前，拥有一个纠偏的窗口。

长程智能体普及的速度将超过大多数团队的预期。可靠运行它们的工程规范现在已经可用——它只需要你将可观测性视为一等架构要素（first-class architectural concern），而不是在智能体“跑通”之后才考虑补救的事情。