你让 AI 帮客户退款。它调用了订单系统，写回数据库，最后报告“处理完成”。监控面板也一片绿色：工具没报错，响应不慢，每一步都正常。可它退错了订单。问题在于，系统只确认流程跑完，没有确认事情办对。
这正是 Agent 上线后最容易被忽略的变化。Agent——让模型反复观察、决策并调用外部工具的程序——把一次模型回答变成了一串会影响真实业务的行动。Mostafa Ibrahim 根据自己运行的一套多步骤审查流水线提出：传统 MLOps 监控沿用的五项假设，到了 Agent 系统里可能逐项失效。这里的证据主要来自作者个人案例和单一供稿，适合用来检查监控思路，不能直接当作全行业结论。
全绿，不等于办成了
MLOps 是部署、监控和更新机器学习模型的一套工程流程。传统系统常看准确率、延迟和数据漂移——也就是线上输入是否偏离训练或参考数据。模型以前多半只负责给出预测，人再决定怎么做；Agent 却会自己选工具、跨过多个步骤，甚至直接修改业务系统。
作者遇到的第一次错误结果，就带着一条“全绿”的 trace：trace 是任务轨迹，记录 Agent 做过哪些操作。当时每个 span 都成功、延迟也正常。span 可以理解为轨迹中的一个步骤，例如调用工具或制定计划。基础设施没有发现异常，但最终判断错了。
这不说明 Agent 追踪工具都失效。恰恰相反，作者认为追踪是进步：OpenTelemetry 的 GenAI 语义约定已经定义 create_agent、invoke_agent、execute_tool 和 plan 等 Agent span，不过文中称该规范仍处于 Development 状态。Langfuse、LangSmith、Arize Phoenix、W&B Weave 和 AgentOps 也能以某种形式记录工具调用、返回结果与成本。
真正的问题是，许多团队只在旧监控上加了轨迹，却没有重审底层规则。漂移监控继续运行，重训练阈值没有改变，告警仍守着一次请求的单一边界。于是新日志越来越丰富，旧指标却仍可能把失败判成健康。
五个旧假设，被循环逐一拆掉
作者归纳的五项假设是：不同运行的输出可以直接比较；推理没有跨请求状态；一次请求只经过一个决策边界；最终会得到可核对的真值标签；模型和实际后果之间有人把关。
Agent 循环改变了这一切。同一张客服工单，周一可能顺利退款，周四却可能卡在客户早已提供的订单号上。前一步出错，后面即使每一步都“正确执行”，也可能沿着错误路径继续走。此时缺陷可能在步骤如何连接，而不在某个模型输出；单纯重训练模型未必有用。
多步骤还会放大风险。假设每一步成功率都是 85%，看起来不低；但十步全部成功的概率只有：
逐步面板显示的是 85%，用户真正经历的却可能接近五次只成功一次。这说明监控不能只问“每一步有没有报错”，还要看端到端任务成功率——最终业务结果是否满足要求。
最难监控的是“它真的做对了吗”
传统模型常能等到标签，再把预测与正确答案比较。Agent 执行的是动作：建工单、更新 CRM、发送回复。真正的判断可能几天后才由人完成，也可能永远没有人检查。自动验证器可以补位，却可能只做表面检查，例如确认程序能编译，而不确认实际运行是否正确。
Zapier 在 AutomationBench 中采取了更直接的办法：不给 Agent 的自我汇报打分，而是让它经营一家虚拟小公司，最后检查数据库里的业务状态。该团队报告，在 Opus、Gemini 和 GPT-5.4 的失败案例中，分别有 72%、91% 和 84% 伴随错误自信，也就是嘴上说办完了，实际没有办成。这正好点出监控边界：程序成功退出，只能证明它停止了，不能证明目标完成了。
为什么现在值得关注
据文中转述，Gartner 预计到 2027 年底，超过 40% 的 agentic AI 项目会被取消，原因包括成本上升、价值不明确和风险控制不足。这是项目取消预测，不是已经发生的失败率，也不能归因于监控这一项问题。
但作者提出的检查方向很实用：上线 Agent 时，别只增加 tracing，还要重新定义什么叫成功、在哪里告警、哪些失败能靠重训练解决。监控对象已经从“一次模型输出”变成“整条行动轨迹及其业务后果”。
局限与未知
- 五项假设与“全绿仍失败”主要来自作者的方法论归纳和个人流水线案例，尚不足以证明所有 Agent 系统都如此。
- 供稿没有提供 Gartner、OpenTelemetry 规范及所引基准的原始材料，相关数字和状态仍需回查原始来源。
- 全绿 trace 只说明基础设施层步骤和延迟没有暴露业务语义错误，不等于所有 Agent 可观测性工具都失效。