11｜构建 Agent Runtime 的实时可观测性

《可观测性工程》延伸讲义 · 第 11 讲

传统可观测性经常用于事后排障，但 Agent Runtime 还需要在任务执行过程中感知风险：工具连续超时、规划陷入循环、Token 即将耗尽、Memory 召回置信度过低。这些信号如果只能在任务结束后看到，就无法帮助本次任务成功。

从记录过程到保护过程

Runtime 可以利用本地实时信号实施保护：限制最大步骤数、设置 Token 预算、校验工具结果、隔离故障工具、切换模型、降级流程或请求人工介入。

执行 → 观测状态 → 判断风险 → 调整策略 → 继续或安全终止

这里要区分两条链路：本地控制信号必须快速、可靠，不能依赖远程观测后端；完整遥测则可以异步发送，用于事后分析和评估。

一个简单案例

研究 Agent 连续三次调用同一个搜索工具，却得到相同空结果。Runtime 检测到“相同工具、相同参数、相同结果”的重复模式，不再盲目重试，而是切换备用数据源，并在 Trace 中记录降级原因。

这次任务的成功，依赖的不只是模型推理，而是 Runtime 对执行状态的实时观察和干预。

现实挑战：观测系统本身不可靠

Collector 过载、网络中断和后端限流都可能导致遥测延迟或丢失。如果 Runtime 必须等远程 Trace 写入成功才能继续任务，观测系统反而会成为任务失败的新来源。

现象—假设—证据—判断

现象：观测后端故障时，Agent 响应时间同步升高。假设包括模型变慢、网络共享故障、同步遥测导出阻塞。证据显示模型和工具延迟正常，关闭同步 Exporter 后任务恢复。判断：Runtime 错误地把非关键遥测放进了同步执行路径。

正确设计是本地生成状态和保护决策，遥测通过有界队列异步导出；队列满时优先保护 Agent 任务，同时记录丢弃计数。

高可靠需要哪些信号

• 步骤数、循环模式和剩余时间预算；
• Token 使用量、窗口余量和截断位置；
• 工具超时、Schema 校验和重复结果；
• Memory 召回数量、得分和新鲜度；
• 模型限流、结束原因和接口兼容错误；
• Collector 队列、拒收、导出失败和数据丢弃。

这些信号要配合熔断、重试预算、幂等、防重复执行和人工接管机制，才能真正提高任务成功率。

小结

实时可观测性不是让 Runtime 等待仪表盘，而是让执行系统随时知道自己处于什么状态，并在失控前采取措施。高可靠的 Agent 需要两套互补能力：本地实时保护保证当前任务，异步完整遥测支撑排障、评估和长期改进。

---

可观测性工程系列：上一篇：10｜可观测性是评估工程（Eval.）的基础

原文：LandX