AgentOps Is Not MLOps: What Breaks in Your Monitoring Stack When Agents Go to Production

AgentOps 不是 MLOps：当代理进入生产环境时，监控堆栈会发生什么变化 | Towards Data Science

Agentic AI

AgentOps 不是 MLOps：当代理进入生产环境时，监控堆栈会发生什么变化

代理系统对 MLOps 监控体系的五大假设破坏，以及继承的监控信号如何将失败运行标记为健康状态

Mostafa Ibrahim

2026年8月31日

10分钟阅读

作者原创图片

多年来，在生产环境中保持模型健康意味着将其与部署的模型保持一致。你通过参考窗口监控数据漂移，根据 SLO 跟踪延迟，通过保留集验证准确性。某个指标变化时，你就会重新训练模型。

这种模式在模型开始调用工具时失效了。

行业反应迅速。Gartner 预测到 2027 年底，超过 40% 的代理 AI 项目将因成本激增、价值不明和风险控制不足而被取消。现在每个可观测性供应商都推出了代理追踪功能。

未被审视的是团队实际执行迁移的方式。大多数团队将其视为叠加：在原有技术栈上添加新追踪跨度；原有系统未被移除。继承的监控信号仍然触发，且多个系统现在将失败运行标记为健康状态。

我从运行的多步骤审核流水线中发现了这一点，该流水线会分发给并行的模型审核者，并将他们的判断写入应用数据存储。首次出现错误判断时，追踪记录却显示完全绿色：每个跨度都成功，延迟正常，但输出结果错误。

通过叠加实现的迁移：无人审查的部分

新增内容确实代表了实质性进展。OpenTelemetry 的 GenAI 语义规范现已定义代理追踪跨度：create_agent、invoke_agent、execute_tool 和 plan。该规范仍处于开发状态，在标准化前需要了解这一点。

Langfuse、LangSmith、Arize Phoenix、W&B Weave 和 AgentOps 都会输出类似格式，因此你可以获得完整的运行瀑布流：哪个工具被触发、返回了什么内容、消耗了多少资源。

从未被重新审视的是底层所有内容。漂移监控仍在运行，重新训练触发器保留了原有阈值，告警系统也从未突破单一边界。这些组件所依赖的假设适用于无状态评分服务，但对运行循环的系统已不再适用。

五大假设承载着主要权重：

• 不同运行间的输出具有可比性。相同输入产生相似输出，差异意味着问题存在。
• 推理过程是无状态的。请求是工作单元，没有状态传递。
• 一个请求跨越一个决策边界。只有一个位置可以设置阈值。
• 真实标签会到达。最终会出现标签用于评分。
• 人类位于模型与后果之间。模型提出建议，人类执行决策。

当模型开始运行循环时，这些假设会以不同方式失效，而监控系统却因保持绿色状态而失效。

五大假设，五次静默失败

这五大假设各自以不同方式失效，而失效往往对专门设计用于检测它们的系统来说是隐形的。

可比输出：相同输入在同周内通过和失败的案例

用相同的支持工单两次运行你的代理系统。周一它为客户退款并关闭工单；周四却因客户已提供的订单号陷入循环。

Tau-bench 通过 pass^k 指标来衡量这一问题：完成某项任务的 k 次尝试全部成功的概率。单次 gpt-4o 尝试能解决约 61% 的零售任务，但如果对同一任务进行 8 次尝试，全部成功的概率会降至 25% 以下。如果对每个输入只运行一次代理系统，仪表盘显示的可靠性是用户实际获得的 2.4 倍。

无状态推理：当路径本身是缺陷而答案看似正确时

快递员在第一个站点听错了街道名称。之后的每次转弯都完美无误，但都因此变得错误。

代理系统也会以相同方式失败。Anthropic 自己的多代理研究系统就直接遇到了这种模式："一步失败可能导致代理探索完全不同的路径。" 每一步的输出都会影响下一步，因此早期的错误无法被纠正，反而会不断累积。

这不是罕见的边缘情况。MAST 分类法将超过 1600 条轨迹归类为 14 种故障模式，其中最大的类别是系统设计：错误源于步骤之间的连接方式，而非任何单个步骤的输出。重新训练模型无法解决这个问题，因为缺陷从来不在模型中，而在于路径本身。

一个决策边界：当每步 85% 的成功率在十步后变成抛硬币

单一阈值假设只有一个放置位置。但十步流程只有在每一步都成功时才能完成，概率会相乘。假设每步的成功率是 85%，这在任何仪表盘上都显得健康：运行十步后，0.85^10 的结果约为 20%。五次运行中只有一次是完整的。

每步监控永远不会进行概率相乘。它会报告 85%；而用户实际体验的是 20%。

真实数据的到来：当标签在行动之后才出现

你的代理系统创建了工单、更新了 CRM 记录并起草了回复。人类在周四阅读了回复；CRM 记录却一直未被查看。

传统监控通过将模型输出与"真实数据"标签对比来判断是否正确，但这个标签必须来自某处。当输出是预测时，人类可以快速标注。当输出是行动时，唯一真正的评判者只能是几天后检查结果的人类，或者永远都不会检查。

因此团队会用廉价的自动化验证器取而代之：一个检查输出的脚本，而非人工。MAST 发现"许多现有验证器只进行表面检查"，比如确认代码能编译而非确认其正确性。一个由 ChatDev 开发的国际象棋程序通过了所有这些检查，但仍然包含运行时错误，最终在 ProgramDev 基准测试中仅获得 25% 的分数。

人类的介入：当行动的唯一见证者只是日志

这个假设是昂贵的，因为代理系统不仅预测，还会采取行动。移除人类后，日志（代理系统行为的记录）就成为证明行动正确的唯一证据。

但日志可能被伪造，甚至可能意外发生。CrewAI 的一个案例记录了代理系统伪造出令人信服的虚假序列："我运行了工具，这是它返回的结果"，而实际上工具从未真正运行过。模型只是生成了看似真实工具调用和结果的文本。原生工具调用（系统而非模型执行操作）可以避免这种特定错误。但更深层的问题依然存在：我的流水线日志显示完全绿色，但其实在工作仍然被错误执行的情况下，这些日志仍然是准确的遥测数据。

它们的替代方案：轨迹监控

废弃一个信号比添加一个更困难。以下是值得参考的映射关系。

假设

编码该信号的信号

该信号无法观测到的内容

应监控的替代指标

输出结果具有可比性

单次调用在采样运行中的准确性

相同输入下运行间的一致性问题

跨重复试验的 pass^k 指标

推理过程是无状态的

请求级别的成功率和延迟

路径中存在缺陷但仍能正常返回的情况

基于步骤级状态的轨迹回放

一个决策边界

每一步的成功率

整个路径中失败的累积效应

轨迹完成率

真实数据到达时

与参考窗口的偏差

一个未改变数据但改变策略的提示编辑

按运行版本化代理配置并进行差异分析

人类介入其中

单一阈值警报

运行中出现的未被识别的不安全操作

对每个副作用设置预操作门禁

每条成功轨迹的成本。一次运行消耗40次工具调用却失败的成本，高于消耗12次调用却成功的运行成本。按调用次数的仪表盘排名方式与此相反，因为它们评估的是调用次数而非结果。多代理系统使用的token数量已经是聊天交互的约15倍，因此分母才是隐藏成本的关键所在。

采用硬性上限替代递归限制。大多数框架允许代理在固定递归限制（通常高达20次）内重试，假设每次重试都是进展。一位LangGraph问题的评论者描述了一个代理在达到递归限制时持续循环，"整个过程都在消耗token却毫无进展可见"。

这并非进展；代理不断遇到无法推理解决的确定性工具错误，每次重试仅生成几乎相同的调用。硬性上限解决了递归限制无法处理的问题：当重试不再显示进展时立即标记运行，而非等待计数耗尽。一位实践者建议在3到5次相同重试后标记，而非20次。

将配置作为监控表面。行为追踪记录的是代理实际执行的操作，而非某人一小时前修改了系统提示的一行代码。该修改在数据保持不变的情况下改变了策略，因此所有监控数据的漂移检测器都会因构造原因保持沉默。解决方案是将整个配置视为一个可差异化的单元：提示、工具、模型和参数一起版本化，而非仅单独版本化提示。

我首先会添加的监控指标是确定性预检查。我将自己的流水线迁移至在模型评审人员之前运行的系统；在目睹他们放行机械缺陷后，一个正则表达式能在一秒内解决该问题。基于模型的评估是错误的工具，任何更便宜的工具都能决定的事情都不应使用它。

当旧架构仍是最佳答案时

并非每个LLM系统都是代理，而混淆这一区别正是团队为不需要的轨迹基础设施买单的原因。

一个无工具、无记忆的单一模型调用是一个无状态的文本生成服务。上述所有假设依然成立。像监控模型一样监控它：输入分布、输出质量、延迟、成本。

LLMOps足以处理包装器。一个仅进行一次检索和一次生成、无循环的包装器需要提示版本管理和输出评估。LLMOps覆盖了这些需求，已经足够。在两步流水线上使用轨迹工具只会带来存储成本和一个无人查看的仪表盘。

最强烈的质疑论点来自行业内部。Langfuse联合创始人Marc Klingen于2024年2月在Hacker News上写道："要获取LLM应用部分的详细追踪/指标/日志，无需重新发明可观测性"，他将价值重新定位到提示管理与评估领域。

基础设施论点依然成立。他在LLM应用领域提出这一观点时，代理系统尚未成为讨论焦点。在基础设施层面，他的判断是正确的。传输、跨度模型、存储和采样都属于OpenTelemetry范畴，代理系统无需新的通信协议。

复利效应并非定律。MAKER通过极端分解和投票机制，将任务推进到百万级模型步骤且零错误，因此步骤乘法是工程问题，且可解决。这种工程特性只在完整运行层面才会显现。

分析单位问题。APM关注调用是否成功，而代理系统在每次调用都成功的情况下仍会失败。MAST第二大分类是代理间对齐失败，此时每个组件都正常工作，但组件间的协调却失败。

新学科的代价账单。测量pass^k指标意味着每个任务需要运行k次。当k=8时，你的部署成本是单样本评分成本的八倍。

因此这个立场是条件性的，这部分是我的判断。如果你的代理系统是只读的且有人类检查每个输出，那么旧架构加上跨度级追踪目前依然适用。如果它具有写入能力，或单次运行常规超过五次工具调用，你就必须开始测量轨迹。

决策框架：购买追踪供应商前的两个问题

两个问题可以解决大多数情况。

• 系统是否能在人类介入前自主决定并产生后果？如果每个人类在任何操作前都检查每个输出，你的影响范围是可控的，输出级监控能覆盖大部分风险。

• 其决策是否会产生外部副作用？向数据存储写入、支付、发送消息、触发部署等。副作用会将质量问题转化为事故。

如果系统处于两个分支之间，选择更保守的方案。你不需要的轨迹监控会消耗存储空间；你本需要的输出级监控则可能在你的仪表板显示前，就因客户报告的事故而产生代价。

结论：从会写入的代理系统开始

采取单向推进而非全面实施。选择具有写入权限的单一代理系统，对其完整轨迹进行监控，设置硬性迭代上限，并限制其副作用。将只读代理系统保留在现有基础上，直到第一个代理系统变得平淡无奇。

追踪是这次迁移中成本较低的一半。成本高昂的一半是决定停止信任哪些继承的信号，并在代理系统采取行动前完成这一判断（即使绿色仪表板显示一切正常）。

进一步阅读

• Sierra : tau-bench（pass^k指标，衡量代理一致性最清晰的指标）。

• UC Berkeley : 为什么多代理LLM系统会失败？（MAST，最大的多代理故障分类体系）。

• Anthropic : 我们如何构建多代理研究系统（状态性、错误累积和令牌倍数）。

• OpenTelemetry : GenAI代理跨度（以供应商中立方式监控代理）。

• NVIDIA : NeMo代理工具包（从代理级别到令牌的流程分析）。

• Gartner : 到2027年底，超过40%的自主AI项目将被取消（目前所有董事会材料都在引用的预测）。

···

感谢阅读。我是Mostafa Ibrahim，Codecontent的创始人，这是一家以开发者为先的技术内容机构。我撰写关于智能体系统、RAG和生产级AI的内容。如果您想保持联系或讨论本文中的想法，可以在LinkedIn上找到我：here。