毫秒级叫停：实时监控让AI代理不烧冤枉钱

AI代理在自动处理订票、交易等任务时，一旦误操作或反复调用工具，失控成本往往远超预期。本文介绍 OnTrack 这套AI代理监控 方案，通过结构比对实现实时安全刹车，在损失发生前提前止损。

AI代理的"自动驾驶"隐患

现在很多 LLM 代理已经在自动处理订票、股票交易、IT 故障分类等任务。它们像自动驾驶汽车一样，大部分时间靠模型自己决策，只有极少的规则兜底。一旦在某个环节做出不可逆的误操作，比如误卖了股票或删了生产配置，代价就是真金白银和宝贵时间。更常见的情况是，代理在一个错误路径上反复调用工具，白白消耗 token，等管理者发现异常时，成本已经失控。

已有的安全方案要么每一步都用一个"守护代理"把关，太贵太慢；要么事后分析日志，等发现问题时，token 已经烧完，损失已经造成。这正是 OnTrack 要解决的问题。

OnTrack：把"事后复盘"变成"实时刹车"

OnTrack 的核心思路并不复杂：既然很多代理任务都有历史上成功的执行轨迹，那就让监控模块实时把当前代理的步骤和依赖关系拿去做"结构比对"，而不是简单的关键词匹配。它用流式结构感知的最优传输来度量当前轨迹与成功轨迹的差异，一旦发现偏离、循环或停滞，就在约一毫秒内发出告警或直接阻断操作。

更实用的是，OnTrack支持三种数据权限模式：

**完全参考：**有历史成功轨迹和工具 schema，能识别计划违背，最准。
**中等参考：**只有工具 schema，还能发现循环、停滞等异常。
**零先验：**仅根据当前生成的 step logs，也能识别重复调用和"原地打转"。

这意味着即使没有大量历史数据，也能获得基础的实时监控能力。

实测效果：省钱与准确率双赢

在 SWE-bench 轨迹上，OnTrack 用前 8 步就能比"内容相似度"方法更早地区分失败轨迹，AUROC 高了 0.057。配合中止策略，可节约约 18% 本来会浪费在失败运行上的算力，而且被中断的运行中有 83% 确实会失败。换句话说，它能在"误杀"很少的情况下，提前止损。

下面用一段 Python 伪代码展示 OnTrack 的核心结构比对逻辑：通过最优传输度量当前轨迹与成功轨迹的差异，并在差异超过阈值时触发告警或阻断。

python 复制代码

import numpy as np

def compute_trajectory_distance(current_steps, success_steps):
    """
    用最优传输（Wasserstein 距离）度量当前轨迹与成功轨迹的结构差异。
    current_steps: 当前代理已执行的步骤序列
    success_steps: 历史上成功的执行轨迹
    返回: 归一化后的差异分数，越小表示越接近成功轨迹
    """
    # 将步骤编码为特征向量（如工具类型、参数结构、依赖关系等）
    cur_features = encode_steps(current_steps)
    ref_features = encode_steps(success_steps)

    # 计算两个分布之间的最优传输代价
    cost_matrix = pairwise_cost(cur_features, ref_features)
    transport_plan = solve_optimal_transport(cost_matrix)
    distance = np.sum(transport_plan * cost_matrix)

    # 按轨迹长度归一化，避免长轨迹天然产生更大距离
    return distance / max(len(current_steps), len(success_steps))

def monitor(current_steps, success_steps, threshold=0.35):
    """
    实时监控入口：计算差异并判断是否触发告警或阻断。
    threshold: 差异阈值，超过则判定为偏离成功轨迹
    """
    score = compute_trajectory_distance(current_steps, success_steps)

    if score > threshold:
        # 偏离过大：可能是计划违背、循环或停滞，立即告警
        alert(f"轨迹偏离风险: score={score:.3f}, threshold={threshold}")
        if score > threshold * 1.5:
            # 严重偏离：直接阻断当前操作，避免不可逆损失
            block_current_action()
        return "blocked"
    else:
        # 差异在安全区间内，允许代理继续执行
        return "allowed"

上述代码中，compute_trajectory_distance 负责把当前步骤与成功轨迹映射到同一特征空间，再用最优传输计算结构差异；monitor 则根据归一化后的分数与阈值比较，决定是仅发出告警，还是在严重偏离时直接阻断操作，从而在"误杀"很少的前提下实现实时止损。

我的观点：效率的下一步，是"可控的自动化"

过去几年，我们追求让AI代理做更多事，但忽视了"失控成本"。OnTrack提醒我们：真正的效率提升不只是更快地完成任务，还包括更少地浪费资源。实时监控相当于给自动化加上一个"经济车速限制器"，让代理在安全区间内全速前进。我尤其喜欢它"分权限降低监控能力"的设计------现实环境中并非总有历史数据，但这种优雅的降级却保证了安全底线。

当然，这只是一个研究方向，基于历史轨迹的比对可能难以覆盖所有新场景。但方向是对的：未来的自动化系统，应该像现代股票交易一样，有熔断机制。毕竟，比"跑得快"更重要的，是"别翻车"。