Agent上线后，监控要覆盖行为与成本

AI Agent 显示任务完成，不等于事情做对了。接口返回正常、延迟没有超标，也可能藏着参数传错、资料过期、执行一半就报成功的问题。原文的核心主张是：监控已部署的 Agent，必须同时看行为、可靠性、成本和安全，不能只沿用 API 的健康检查。

这篇值得读的地方，是把链路追踪、结果核验、持续评测和代码限额串成了一套闭环。它给出了监控思路，但没有提供落地案例的对照数据，文中引用的行业预测也需要与实际证据分开看。

仪表盘全绿，为什么任务还会做错

传统 API 监控擅长回答「服务是否可用」。Agent 多了一层麻烦：它会选择工具、组织参数，并主动修改状态。请求顺利结束，只能证明执行流程走完，不能证明决策正确。

原文列出的失败都很具体：工具选对了，参数却错了；检索拿到旧文档，却当成当前事实；查询已经无效，仍不断重试，直到预算耗尽。这些问题未必抛异常。

因此，四个维度需要一起看：行为关注任务是否做对，可靠性关注能否完成，成本关注消耗了多少资源，安全关注是否越界。

Agent 自报成功，必须有独立的结果检查来核验。

作者特别强调两者的「不一致率」。例如，一个多步骤任务中间失败，Agent 最后仍报告完成，只看最终回复就会漏掉这类静默的部分成功。

原文引用 Gartner 的预测：到 2027 年底，40% 的 agentic AI 项目将被取消，原因涉及成本、投资回报不清晰和风险管理不足。这是行业预测，不是作者实测的项目失败率，也不能据此认定监控不足造成了全部取消。

先把一次运行串起来，再谈指标有没有用

作者建议为每次运行建立一条 trace，并给每次模型调用、工具调用、检索和决策点记录 span。可以把 trace 理解为一次任务的执行档案，span 则是其中某一步的记录。

这里推荐 OpenTelemetry 的 gen_ai 约定，用统一格式记录数据，把 token 数量放到对应 span，并用同一个 run ID 关联链路、指标和评测。采用厂商中立的格式，是为了更换监控后端时保留埋点。

记录之前还要处理数据边界：密钥和个人信息先脱敏，再存储；prompt 可能包含机密内容，保留期限也应事先明确。

有了执行记录，指标才有解释空间。作者建议关注比例和单位结果的消耗：

• 总费用随请求量上涨未必异常，每个成功结果的成本上涨才更值得排查。
• 工具错误率和重试率要按工具分别统计，避免整体平均值掩盖某个集成的问题。
• 步数要结合上限观察，才能识别运行是否越来越接近失控。
• 任务成功率、延迟、token 成本、工具成功率和步数可以组成起始仪表盘，但还需要结果核验。

原文没有说明怎样定义「成功结果」，也没有给出独立检查器的实现。这恰好是落地时最需要补齐的部分：没有稳定的成功标准，单位成功成本和不一致率都会失真。

评测负责发现退化，代码负责拦住越界

作者把评测视为持续运行的健康指标。先建立覆盖代表性任务的黄金测试集（golden set），每次更换模型、prompt 或工具都重新执行；上线后再抽样评分，因为全量评测通常成本过高。评分下降应成为阻止部署的信号。

如果使用 LLM judge，也就是让模型给结果打分，需要先校准。原文引用 Zheng 等人在 2023 年的研究：GPT-4 作为评委，与人类判断的一致率超过 80%，接近人类评委之间的一致程度。

但平均一致率不能保证它识别得出你的关键失败。作者还指出，模型评委可能偏爱更长的回答及自身模型家族的输出，因此需要定期复查，不能把未经校准的评分直接当作测量结果。

对于循环和预算，则不能只靠评分或 prompt 约束。原文要求在编排层设置确定性的熔断措施：硬性步数上限、每个工具的重试计数，以及由代码执行的成本上限。

system prompt 可以表达规则，代码中的限额才负责执行边界。

告警也要分层。错误率、循环率、单任务成本和评测下降，适合在滚动时间窗口内观察；安全违规、提示注入到达高权限工具、运行突破成本上限，则应立即通知人工并触发熔断。每条告警都要附执行链路和处置手册，进入人工处理的生产故障还应回填黄金测试集。

我的判断

我认同这套思路里最重要的两个取舍：用结果核验补足可用性监控，用代码限制补足模型指令。它们分别解决「看起来完成了」和「答应遵守了」不够可靠的问题。

但原文更接近工程经验清单。它没有给出接入前后的故障检出率、告警误报率或监控成本，也没说明抽样比例、评分下降阈值和安全模式如何判定。不能把这些建议直接当成已经验证有效的完整方案。

与只看日志、HTTP 状态和延迟相比，这套方案覆盖了任务质量；与每次运行都交给模型评分相比，独立结果检查通常更适合能明确验收的任务。模型评委更适合补充判断开放式输出，具体效果仍需校准。

一般团队可以先覆盖高频任务和高权限工具。监控本身也会增加采集、存储、评测和人工处置成本，覆盖范围需要结合业务价值决定。

能拿来做什么

• 给现有 Agent 补上统一 run ID，串起模型、检索和工具调用，先确保一次失败能够完整回放，再增加聚合指标。
• 对会修改代码、文件或业务状态的 AI 编程任务，定义可独立检查的完成条件，并统计它与 Agent 自报成功的不一致率。
• 在 Node 编排服务中落实步数、工具重试和费用上限，让触发上限后的停止行为由代码控制。
• 将人工处理过的生产故障整理成回归用例，在模型、prompt 或工具变更时重跑，并让告警携带对应 trace 和处置步骤。