\n\n本文探讨了可观测性平台向 AI 审计工具转型的必然性。随着代理式 AI 工作负载进入生产环境，企业需通过决策审计和链路追踪来确保 AI 的安全、合规与高效。
译自：Why observability platforms are becoming AI auditing tools
作者：Jennifer Riggins
当 AI 代理代表我们行事时，“未知的未知”被赋予了全新的含义。到目前为止，自主型 AI 舰队会注入更多 Bug，并以更难预测、更难追踪的方式导致更多的长期代码异味和技术债。
在创新实验室中“足够好”的监控，无法扩展到企业的各部门孤岛和 GPU 资源中。随着企业将自主、动态的 AI 工作负载从实验阶段过渡到生产环境，代理式 AI 工作负载的可观测性成为企业面临的最紧迫问题之一。
传统的底层架构和应用性能监控 (APM) 不仅无法跟上这种代码涌入的速度，而且无法洞察 AI 的“密封盒”。作为回应，支持 AI 的可观测性平台正在进化，从简单的指标监控转向复杂的、可操作的决策审计。
Gopal Vogety，HPE OpsRamp Software 的软件工程高级总监告诉 The New Stack，AI 工作负载的管理方式存在差异。
“可观测性平台正在成为审计平台，这样当人类参与其中时，他们既能掌握大局，也能了解最底层的技术细节。”
Vogety 表示：“AI 工作负载必须以不同于常规工作负载的方式进行观察、监控和管理。它们需要一种特定于 AI 工作负载的监控数据呈现方式，以帮助这些新的运营角色。”
“可观测性平台正在成为审计平台，这样当人类参与其中时，他们既能掌握大局，也能了解最底层的技术细节。”
AI 审计平台使站点可靠性工程 (SRE) 团队能够以可证明的方式启用更多注入 AI 的应用、代理和工程师，从而让业务领导层有信心最终扩大其 AI 项目的规模。但是，就像所有与 AI 相关的事物一样，需要大量的流程和人员变革来支持您的运营团队。以下是让您的运营团队和领导层在代理式 AI 方面达成共识所需的内容。
运营职权的被迫扩展
现在，弄清楚不仅是什么出了问题，还有故障发生在何处、为什么、哪个代理做了什么，以及当然，如何修复它并防止它再次发生，都比以往任何时候都难。
目前，已经有三分之二的企业对实时威胁检测和响应能力缺乏信心。云原生、分布式环境一直很复杂，因此我们需要一个新的形容词来描述 SRE 在面对 AI 时所面临的情况。在一个集群内，可能会有多个依赖于多个大语言模型 (LLM) 的 AI 应用。
2025 DORA 报告发现，较高的 AI 采用率与吞吐量增加和不稳定性增加均相关。如果开发者陷入了与 AI 的“猜想-检查”循环中，那么我们可以想象运营团队的体验，他们通常离监管 AI 舰队又远了一步——有时甚至是几英里。
而且，不仅仅是工程部门在部署 AI 代理集群。在各个行业，市场和销售等团队已经积极地将代理式 AI 集成到他们的工作流程中。这些团队需要特定于其垂直领域的洞察。
Vogety 说，他们“确实需要监控方面的帮助，以了解这些代理在其垂直领域中做出的推理和决策”是否符合其业务目标，甚至是否准确。
与此同时，运营管道问题依然存在。在安全、站点可靠性工程和 DevOps 角色中，甚至在这些代码和代理大量涌入之前，公司就很少有足够的运营专业人员来进行观察、监控和审查。更不用说复杂的 AI 生成的网络安全攻击正在增加。
新出现的解决方案被 Vogety 称为“AI 工厂”，企业将 AI 作为跨所有业务部门的共享资源，在控制 Token 和 AI 工具扩张的同时，确保必要的安全、隐私和质量防护栏到位。在这个工厂之上运行着一个可观测性 AI 审计平台，使人类 SRE 能够安全地在企业规模上部署 AI。
对全新词汇表及翻译器的需求
SRE 和其他运营团队必须适应全新的 AI 原生词汇，而 AI 审计平台使这成为可能。
为了解决哪里出了问题以及如何修复，Vogety 表示运营团队需要回答新的以 AI 为中心的问题，包括：
- 代理使用了 LLM 的哪些部分？
- 代理经过了怎样的推理过程？
- 代理在做出最终决定之前采取了哪些步骤？
- 它访问了哪些数据？
- 它与什么样的工具进行了交互？
这些答案中的许多都依赖于以平台为中心的决策监控方法，平衡在必要时深入研究技术指标的需求与确保首先呈现最具操作性信号的需求。
Vogety 解释说，合适的 AI 审计平台将“对其进行分层，使得从输入提示词进入到做出最终决定的过程清晰可见，并试图帮助企业客户了解代理经历了哪些 LLM 部分和推理步骤，以及它访问了哪些数据、与哪些工具进行了交互，以及最终做出的决定。”
就像它们的内部开发者平台前辈一样，以 AI 为中心的可观测性平台应该在业务和技术利益相关者之间创建一种共同语言。
运营商仍然必须回应软件开发和基础架构部门的同事，后者需要新的监控要求，以了解 AI 工作负载在已经复杂的企业 IT 栈中是如何共存的。
Vogety 解释说：“监控这些 LLM 在幕后运行的性能和整体延迟，不仅可以从成本角度提供帮助，还可以帮助开发者优化用于各种代理应用的代理代码模型。”
他继续说道，许多终端用户可能并不关心所有这些技术复杂性。他们优先考虑的是：我的 AI 质量如何？
决策监控对于受到严格监管的行业以及任何在欧盟拥有客户或用户的组织尤为重要，因为欧盟严格要求 AI 的可审计性。
合规团队并不是唯一要求这种程度的可追溯性的业务利益相关者。随着 FinOps 和 CloudOps 在规模化 AI 阶段相遇，了解 Token 使用情况也将变得越来越重要。有了合适的平台，可观测性团队还可以帮助确定哪些工作负载应该留在云端，哪些应该迁移到通常成本效益更高的本地。
这些业务和技术利益相关者中的每一个，都需要在其 AI 工作负载和领域的背景下拥有各自简化的数据表示。而且它需要适合这个新世界的指标。
当然，像平均恢复时间这样的 DORA 指标对运营团队来说仍然至关重要。可观测性团队现在还必须检查代理式工作负载的趋势（如 P95），回答 95% 的交易的平均 Token 使用量是多少。
AI 原生可观测性平台“应该向运营商提供关于整体、应用、模型或任何需要他们关注的特定警报的所有信息，”Vogety 说，“在 AI 的世界中，日志起着非常关键的作用，并驱动着后台发生的任何决策。”
追踪提示词的生命周期
正如在整个软件开发生命周期中进行优化与高效团队的成功直接相关一样，理解和优化代理式 AI 生命周期将决定 AI 时代的下一个赢家。
每一个 AI 代理的部署者都需要能够访问以下洞察：
- LLM 选择
- 数据访问
- 工具交互
- 最终做出的决策
这些步骤共同被称为 AI 的追踪（trace）。像 HPE 的 OpsRamp Software 这样的工具弥补了代理推理路径、物理硬件与最终决策及行动之间的鸿沟。
Vogety 举了一个关于贷款批准或拒绝的高度重要因素的例子。“假设你想因为 XYZ 原因拒绝贷款，所有原因都应作为最终决定的一部分列出来。”
你希望这种新型的 AI 运营人员能够监控在特定时间段内每个应用产生了多少此类提示词，并在任何地方出现峰值时发出警报。
“假设时间是晚上 11:30——那个峰值可能非常奇怪。模型可能已经漂移到给出错误的响应。”
Vogety 继续说道：“在那个时间点，交易量不应该那么高，而且这些模型和 GPU 非常昂贵，所以你也希望显示 Token 的使用情况。”
如果这些 GPU 是在本地消耗的，那是一回事，但如果这些 Token 是在公共模型上使用的，那么 Token 使用量就直接对应于成本。这种异常峰值也可能预示着漏洞风险的增加。根据不同的组织阈值，这种异常可能很微小，也可能需要唤醒 SRE 来进行调查。
对于像 HPE OpsRamp 这样的 AI 可观测性平台，你可以缩小视野查看这一趋势，也可以向下钻取到最细的粒度，即每个 LLM 的每次调用。与传统监控一样，它还会向你展示哪些 AI 应用运行在哪些集群上。
代理式可观测性的风险
将 AI 用于可观测性也并非万能灵药。
面对运营端的所有这些瓶颈，工程师们正在使用 AI 来审查 AI。这面临着引发独立研究员兼工程师 Christos Zietsman 所称的同质化陷阱的风险，即生成代理和审查代理共享相同的训练分布。这可能导致关联错误，使审查代理漏掉与生成代理相同的边缘案例。他写道，这使得 Bug 对自动化管道和人类操作员来说变得不可见。
斯坦福大学最近的研究发现，这种同质化陷阱导致多代理系统经历了 37.8% 的性能损失，因为代理的共识寻求行为——即代理为了保持一致性而就错误答案达成一致——推翻了单个工程师的经验。
虽然这项研究就像这些 AI 驱动的行业变革一样尚处于起步阶段，但它确实证明了寻求“第二意见”的必要性。通过使用不与生成代理共享相同底层架构和模型的第三方可观测性平台，你可以降低这种关联失败的风险。它还有助于避免供应商锁定，从而在多供应商 AI 工厂中实现统一视图。
如果部署得当，早期在运营中使用 AI 代理已将根因分析所需的时间缩短了一半。随着这项技术的进化和自我学习，自愈式运营的机会也进入了视野。全 工智能
