杰夫·香槟，Cribl 的 Field CTO – 采访系列

杰夫·香槟，Cribl 的 Field CTO，拥有丰富的经验，跨越了可观察性、企业数据、产品策略和技术架构等领域。在加入 Cribl 之前，他曾担任 Databricks 的产品管理总监，并在 Splunk 任职超过七年，担任高级领域产品、架构和全球系统工程等职务。他的背景还包括在 BNY ConvergEx 担任系统架构领导、在 Premier Technology Solutions 担任高级工程工作，以及在 Assist-2-Sell 担任早期工程领导，这使他对企业如何在大规模上收集、管理、分析和利用运营数据有了深刻的理解。

Cribl 是一家企业遥测公司，专注于帮助 IT、安全、SRE 和 DevOps 团队在不受单一供应商限制的情况下收集、处理、路由、存储和分析可观察性和安全数据。该公司将自己定位为“遥测的 AI 平台”，其产品包括用于实时遥测收集、减少、丰富和路由的 Cribl Stream；用于供应商中立端点遥测收集的 Cribl Edge；用于就地搜索数据的 Cribl Search；以及用于存储的 Cribl Lake。其更广泛的使命是为企业提供更多的控制、灵活性和效率，因为遥测量在增长，AI 驱动的运营需要更干净、更易访问的数据。

您曾在 Splunk、Databricks 和 Cribl 工作，拥有对企业数据、可观察性和基础设施的独特视角。在这种视角下，代理 AI 创建的可观察性挑战与传统挑战有什么不同之处？

在应用程序可观察性中，我们一直处理复杂的分支执行路径，跟踪请求通过微服务，并在分布式系统中关联日志。在安全操作中，我们处理了大量的、不同的数据源，以检测系统中的威胁，这些系统虽然复杂，但仍然以可预测的方式运行。代理 AI 并没有重新发明这些问题；它同时扩大了这些问题。

代理根据决策链、调用外部工具和动态生成子代理的方式进行操作，这些方式在编写时并没有预先确定。执行图不仅复杂，而且每次都可能完全不同，需要重建实际发生了什么的遥测量也呈指数级增长。收集所有必要的遥测数据以使代理系统可观察，必须既容易仪表化，又具有成本效益，以便在规模上运行。否则，企业将做出相同的权衡，减少可见性以控制成本——这正是去盲的错误时机。

当企业将自主代理嵌入工作流时，代理被要求做什么和实际发生的事情之间的最大可见性差距在哪里？

代理完成看似成功的工作流，但实际上却悄悄地进行了错误的工具调用、产生了幻觉或偏离了原始目标。后果通常在其他系统中几个小时后才会显现出来。

脱节通常从解释开始：原始指令中的微小模糊性会根据代理从内存中检索的内容、可用的工具或前一步骤对其上下文的影响而以不同的方式解决。您还必须仪表化代理依赖的下游系统，因为代理可以进行完美的数据库调用，但如果上游的 ETL 作业失败，导致基础表未更新，仍然会返回错误的答案。

代理做了它被告知要做的事情；它信任的数据只是过时的。

为什么传统的可观察性工具通常不适合监视代理 AI 系统？

首先，它们是围绕刚性、专有的模式和可预测的数据形状构建的。代理跟踪不符合这些期望——它们具有大量的、结构可变的数据类型，例如完整的提示文本、模型推理链和工具调用有效负载，这些都是传统工具没有设计来处理的。像 OpenTelemetry 的 GenAI 语义约定的开放标准正在出现，以解决这个问题，但许多传统平台没有被设计来利用它们。

第二，规模和成本方程很快就会破裂。处理生产工作负载的单个代理可以在一小时内生成比整个应用程序堆栈一天产生的遥测数据还要多的数据，大多数传统平台按摄取和存储的数据量收费。这会产生一个不可能的权衡——要么仪表化一切并面临失控的成本，要么减少对最需要可见性的系统的可见性。

当 AI 代理失败时，组织如何确定根cause 是模型、检索层、API 依赖、权限问题还是下游基础设施问题？

在各个层次中隔离根cause 是一个排除过程。只有当您的遥测数据跨越所有这些层时，它才有效。模型跨度的延迟和错误信号表明了 LLM 本身的问题。检索跨度告诉您上下文是否相关或过时。工具调用跨度暴露了失败的 API 依赖或权限错误。

如前所述，您还需要代理依赖的下游系统的遥测数据，因为代理可以进行完美的调用，但如果它信任的数据从未更新，仍然会产生错误的答案。没有单一信号可以告诉您整个故事，这就是为什么在一个地方关联所有这些层的数据是区分能够快速调试代理失败的团队和仍然在猜测的团队的关键。

当企业试图在规模上理解代理行为时，什么类型的遥测数据变得最重要？

基础仍然是 MELT — 指标、事件、日志和跟踪 — 但当您转向代理系统时，重点会显著转移。指标告诉您出了问题，日志给您提供了发生了什么的原始记录，但两者都无法重建代理遵循的推理链以得出错误的答案。跟踪成为最关键的信号。

在传统的分布式系统中，跟踪显示请求如何通过服务。 在代理系统中，它显示模型如何推理问题、调用了哪些工具、检索了哪些上下文、分支以及每一步做出了什么决定。没有这种跟踪，您只能看到输出，而无法解释如何得出这个结论。

其他 MELT 信号不会消失；令牌使用和延迟的指标对于成本和性能很重要，下游系统的日志仍然是必不可少的。但是，跟踪使代理行为在规模上可读。

许多 AI 讨论仍然大量关注幻觉。企业是否低估了操作失败，例如坏检索、断开集成、延迟峰值或缺失上下文？

生产环境中的大多数幻觉并不是模型故障；它们是伪装成操作故障。坏检索返回过时或不完整的上下文，模型用听起来合理的东西填补了空白。断开的集成意味着代理从一开始就没有获得它需要的数据来正确推理。缺失的上下文看起来像一个幻觉，但实际上是一个基础设施问题。

当团队无法看到区别时，他们会默认控制他们可以控制的东西，这通常是模型本身。他们迭代系统提示、添加防护栏和完善评估框架，虽然这些技术有真正的价值，但它们是在治疗症状而不是根cause。在我的经验中，最高效的投资几乎总是检索层的数据质量和新鲜度。一个有干净、最新数据的代理将比一个从过时或不完整的上下文中工作的、经过大量提示工程的代理表现得更好，每次都如此。

随着代理变得更加自治，企业团队应该记录、跟踪或监视什么，以便在不让自己被噪音淹没的情况下保持问责制？

基础仍然是 MELT，但代理系统的问责制需要在传统遥测之上添加一个评估框架。指标、事件和日志表明基础设施故障和可能损害代理行为的断开集成；跟踪给您提供了推理链，以了解它如何得出特定的答案。但是，这两者都无法告诉您答案是否实际上是正确的，这就是 LLM-as-judge 评估填补空白的位置。用于驱动代理的相同 AI 能力可以用于评估它们，评分输出的准确性、接地性和任务完成情况，规模远远超过人类审查过程。

在预生产中，它作为质量门，捕获在用户之前的回归。在生产中，它成为连续监视，采样实时流量并标记超出可接受阈值的响应。避免噪音的关键是认识到并非所有代理工作流都带有相同的风险，这意味着从统一监视转向人类在循环中的治理。您提前定义行为基线和置信阈值，让代理运行，并为异常保留人类干预。

遥测管道在帮助安全、SRE、数据和 AI 团队从代理行为的共享视图中工作方面可以发挥什么作用？

安全团队、SRE、数据工程师和 AI 团队都通过不同的工具以不同的方式查看同一个问题的不同切片，没有一个团队拥有完整的图景。遥测管道已成为现代企业数据架构的标准部分，因为它们解决了这个问题：一个单一的、治理良好的管道可以确保每个团队在没有为每个团队部署专用代理和收集器的情况下使用相同的规范化和丰富的数据。

这种灵活性在两个层面上都很重要。第一个是数据分层。一个设计良好的遥测管道可以让您将数据与正确的存储和分析策略相匹配，这样您就不会为仅需要长期合规性保留的数据支付分析级别的价格。第二个是随着 AI 工具的快速发展而来的选择性。围绕单个供应商的生态系统构建其可观察性策略的企业将面临昂贵的迁移项目，每当更好的工具出现时。

您看到企业在尝试将现有的监视实践改造为代理 AI 部署时犯了什么错误？

我看到的最常见的错误是伸手去现有的高级可观察性平台来收集代理跟踪，而没有先考虑成本影响。代理跟踪很大、可变且大量，这与传统的应用程序遥测不同，大多数高级平台按摄取和存储收费。账单可能在团队意识到之前就成为一个严重的问题，典型的回应是减少收集的内容。结果是最坏的两种情况：高成本和不完整的可见性。

第二个错误是将错误的思维模型应用于监视应该回答的问题。传统的基础设施监视询问“系统是否正常运行？”并在系统未运行时触发警报。这个问题是必要的，但对于代理系统来说，这还远远不够，在代理系统中，基础设施可以完美健康，而代理却悄悄地做出糟糕的决定、检索过时的数据或偏离其原始目标。将现有的仪表板和警报阈值改造为代理工作流的团队经常说服自己他们有覆盖范围，但实际上他们只在监视管道。

第三个错误是将仪表化视为事后补充。快速尝试代理并在没有考虑可观察性之前将其投入生产的企业最终会陷入昂贵的补救循环，在第一个重大生产故障后重建数据收集架构。成功扩展代理部署的团队在流量低、行为可预测时就开始仪表化，建立基线，并在需要之前构建评估框架，而不是在出现问题之后。

展望未来，基础设施可见性是否会成为企业 AI 采用的先决条件，就像云可观察性对于大规模云迁移至关重要一样？

与云的类比非常相似。最重要的事情我告诉客户，当他们将基础设施迁移到云时，是他们不是在进行提升和转移。他们正在部署一个全新的架构，具有新的能力。所有这些都需要以以前的工具可能没有设置好的方式进行仪表化和监视。跳过这一步的企业遇到了他们无法诊断的级联故障、无法解释的成本螺旋和无法预防的中断。可观察性成为使云规模可信赖的基础，同样的模式现在正在以更快的速度和更高的赌注重演，代理 AI 正在崛起。

代理需要这种监督的主要原因是它们被设计为非确定性的，其行为在运行时出现，其有效能力每次连接新工具时都会增长。静态的预部署认证无法涵盖其行为面在每次集成时都会发生变化的系统。代理将在定义的信任边界内运行，这些边界将随着可观察性、策略和评估基础设施的成熟而随时间扩展。边界本身永远不会消失，这也不是一个失败状态。这是世界上每个重要的自治系统的工作方式。

感谢这次精彩的采访，希望了解更多的读者可以访问 Cribl。