我们真的能在大规模场景下管控 AI 智能体吗？ (Dev Rishi)

萨姆： 最近我参加了一个大型企业技术会议，并在几个关于构建和扩展 AI 智能体的专题讨论小组中发言。不出所料，风险这一话题被频繁提及。而标准的应对方案通常是静态安全护栏 (Guardrails) 与人工审批稀疏结合。在理论上，这听起来足够简单：拦截危险的操作，当某些行为看起来有风险时，引入人机协同 (Human-in-the-loop)。然而，智能体对这种模式的两端都施加了压力。静态规则之所以难以奏效，是因为智能体具有创造性。它们并不只是在软件中遵循固定的路径。它们会规划、即兴发挥、调用工具并寻找绕过限制的变通方法。而人工审批也同样困难，因为智能体的运行速度远快于人类。因此，问题不在于我们是否需要安全护栏 (Guardrails) 和监管，我们当然需要。关键在于，当智能体在涉及高风险工具、数据库和工作流的环境中大规模运行时，这种监管应当呈现何种形态。我与 Rubrik 的 AI 总经理 Dev Rishi 讨论了这一问题，他和他的团队正在构建用于在企业环境中保障智能体安全和进行治理的基础设施。他分享了一个来自他个人经验的例子，直击该问题如此棘手的症结所在。

戴夫： 随后，我们看到了更复杂的一些异常情况。我们注意到，Claude Code 曾试图将内部源代码发布到公共仓库而不是私有仓库。这种情况发生的频率相对较高，甚至在某些情况下，当我们回溯审计日志时，会发现已经通过了一步步的勾选确认。这意味着，从技术层面来看，它已经被认为获得了人机协同 (Human-in-the-loop) 的批准。我们甚至目睹了一个非常疯狂的案例，Claude Code 试图绕过我们对发布公共 Gist 等操作的拦截。它并没有像在文本输入输出系统中那样直接发送“我正在向该 URL 发布内容”的请求，而是启动了一个浏览器窗口，我们开始观察到它在特定坐标上进行鼠标点击。最终我们发现，其中一个点击坐标正是用于创建公共 Gist 的按钮。

萨姆： 我是萨姆·查灵顿 (Sam Charrington)，这是 TWIML AI 播客 (TWIML AI Podcast)。

萨姆： [音乐]

萨姆： 十多年来，我一直致力于通过这样的对话来探索塑造 AI 未来的思想与创新，帮助大家理解什么是真实的、什么是未来的趋势，以及什么才是至关重要的。让我们正式开始。

萨姆： 这从根本上说是一个学习层面的挑战，还是专业知识层面的挑战？理解这些挑战有很多维度，但在很大程度上，这似乎需要一种思维方式的转变。

戴夫： 萨姆，我认为与其他技术变革类似，这确实包含文化和学习方面的因素，但我并不认为这是最核心的部分。在与许多组织沟通后，我认为最核心的挑战在于方法论以及如何管理风险。比如，对比一家快速发展的 AI 原生初创公司与全球前十的银行或前二十的医疗保健公司，后者在发展过程中被灌输的理念是，必须确保其运行系统是确定性的，拥有完善的安全护栏 (Guardrails) 以及清晰的下行风险保护。如果你曾使用过像 Claude Code 或 Codex 这样的智能体，在日常使用中你大概不会觉得它提供了充足的风险兜底保护，对吧？虽然它们的能力令人惊叹。曾有一位全球 CIO 向我形容：“这就像开着一辆没有刹车的跑车，速度飞快，但谁也不知道后台到底在发生什么。”我对此深表赞同。关键在于，这些工具展现出了惊人的实用价值，但在安全和治理机制上并不完善，且往往运行在传统的 IT 基础设施之上。坦率地说，初创公司与“全球 2000 强”企业之间最大的区别，不仅在于后者可能保留了更多传统思维，更在于他们承受不起失败的代价。这也成为阻碍他们采纳 AI 的首要因素。如果你是 AI 初创公司，可以直接使用现成的开发套件并立即付诸行动。但如果是大型企业，项目可能很快就会陷入没完没了的 AI 治理委员会会议中——比如本周开会讨论定义框架，三个月后提出框架的 2.0 版本，以此类推。我认为这正是导致落地受阻的原因。

萨姆： 我想正是这些对话与观察，促使你和团队将重心进一步聚焦在智能体（Agentic）技术上。

戴夫： 确实如此。我们不仅观察到外部行业在讨论这个问题，我们内部也遇到了同样的情况。Rubrik 是一家很有意思的公司。大约在十一二年前，它还是一家初创公司，而今天它已发展成为一家数据安全领域的上市公司，为全球最重要的一些“全球 2000 强”企业提供数据备份服务。可以说，我们的基因中兼具了初创公司的活力与大企业的稳健。在开发 AI 和智能体的过程中，我们自己也遇到了同样的安全和治理瓶颈，这确实让人感到颇为棘手。在此，我想简单界定一下什么是“智能体”（Agents）。我们将智能体定义为拥有工具访问权限的大语言模型 (LLMs) 或模型。换言之，它们是能够代表用户执行具体操作的模型。

萨姆： 正是工具的接入，显著扩大了爆炸半径 (Blast Radius)。

戴夫： 没错。两年前，大家都在担心“如果不小心把敏感数据发送给 ChatGPT 该怎么办”。这固然是一个合理的担忧，但更严重的问题是，如果 ChatGPT 获得了 Salesforce（我们存储所有财务数据的核心记录系统）的访问权限，并开始幻觉出错误的数据，这才是更加巨大的隐患所在。但与此同时，这也正是 AI 的魅力所在。如果不赋予这些模型执行内部工作的权限，我们可能永远无法实现预期的经济生产力飞跃。因此，一方面这是必然趋势；另一方面，在频繁使用这些智能体套件时，以我的使用体验为例，Claude 会不断向我发送大量的确认请求，而我只能机械地点击“接受、接受、接受”。这其实挺让人后怕的，因为它的运行速度太快了，我根本没有能力去仔细剖析和检查它所做的每一个动作。我记得第一次使用时，脑子里冒出一个想法：我希望有个人站在背后帮我把关，确保我没有造成什么愚蠢的破坏；同时，万一我真的搞砸了，能有一种方法可以撤销或回滚这些更改。这正是我们在 Rubrik 开发的产品。我们构建了 Rubrik 智能体云 (Rubrik Agent Cloud)，旨在帮助组织保障其智能体部署的安全与治理。

萨姆： 我也有过类似的经历，就是机械地点击“接受、接受、接受”，然后意识到这在很大程度上只是一种“安全形式主义”（Security Theater）。首先，命令行非常长，你根本无法看全所有的内容，只能心存侥幸地觉得“行，看起来没问题”；接着，你批准了智能体运行某个它自身完全可以控制并能随意写入内容的物理文件，这不免让人怀疑：我这样做到底能起到什么安全防范作用？

戴夫： （笑）

戴夫： 早些时候，当我们在讨论为什么 Predibase 与 Rubrik 选择联合时，我提到过，我看到了一个进军尚未被其他人涉足的市场空白的机会。我所看到的具体痛点在于，传统的安全防护手段根本无法适应智能体时代。正如你刚才所称的，这在某种程度上就是“安全形式主义 (Security Theater)”。我们曾在内部的 Slack 频道上展开过一次激烈的辩论。当时一位工程师问道：“嘿，我真的必须每次都点‘同意’吗？能不能让大多数任务自动运行？”而安全部门人员对此回应道：“听着，智能体代表你作为用户执行操作，因此你必须知晓并授权它所采取的每一个动作。”这在逻辑上确实行得通，但在实际操作中，鉴于智能体的运行速度，其核心价值主张就在于能够以十倍于人类的速度运行。如果它的运行速度比我快十倍，那么我显然不可能进行十倍强度的审查。因此该工程师反驳道：“这难道不是反而让系统变得更不安全了吗？因为我们几乎是在没有真正理解每一步在干什么的情况下，就机械地予以批准。”这本质上就像 iTunes 的服务条款，虽然我个人会逐行仔细阅读，但显然并不是所有人都会这样做。所以，关键在于如何妥善管理这一点。我的核心观点是，我们不能依靠传统手段，也不能依赖基于规则的系统。人机协同 (Human-in-the-loop) 听起来很稳妥，但实际上它跟不上现在的演进速度。作为 AI 背景出身、创办过 AI 基础设施公司的人，我得出的结论是：我们应当用 AI 来解决 AI 的问题，从而从人机协同 (Human-in-the-loop) 系统转向 AI在环治理 (AI-in-the-loop) 系统。我前面提到希望有人能监督我的操作，这个角色本质上需要一个非常智能、经过高度专业化训练的领域特定网络安全智能体。这正是我们在内部构建的产品。

萨姆： 既然你现在涉足安全领域，我想问你一个问题。在过去，当我们只担心分布式系统以及将系统连接到互联网这类问题时，我们提出了零信任 (Zero Trust) 的概念 和 一系列实践。在更早的时候，你通常会与另一个系统建立信任，然后直接相连，中间几乎不设关卡，因为你默认系统是可信的。后来我们转向了不信任任何事物、并在我们关注的领域强制执行策略的模式。我不是安全专家，这只是我的通俗理解。但在你所描述的世界里，不仅外部威胁不可信，就连在本地运行于我的电脑上、或代表我工作的智能体，同样无法被无条件信任。我想知道这是否引起了你的共鸣？你是否考虑过将零信任 (Zero Trust) 延伸到智能体，它的具体影响是什么？

戴夫： 没错，我更喜欢把自己看作是一个进入安全领域解决挑战的 AI 基础设施专家。现在我花了大量时间思考 AI 基础设施的安全影响。我确实认为传统安全中存在的零信任 (Zero Trust)、设计安全 (Secure by Design) 等原则在方向上是正确的，但在 AI 领域的具体落地方式上会有所不同。其主要原因在于，历史上的很多安全原则都嵌入在静态且确定性的系统和策略中。例如，零信任 (Zero Trust) 意味着默认不信任，可能只针对你想执行的操作进行即时授权。这套原则本身是合理的。然而，困难之处在于，很多设计安全 (Secure by Design) 的安全基础设施在进行评估时，往往是以保护“人类使用的软件”为出发点。但实际上，相比于传统安全解决方案所保护的那些软件，智能体的行为模式与人类更加相似。

萨姆： 请详细展开说说。

戴夫： 好的。以我笔记本电脑上运行的 Claude Code 或 Claude Co-work 实例为例。这个智能体实例拥有 Salesforce 的访问权限，我用它来汇总销售商机；同时它也拥有我电子邮箱的访问权限，用于发送邮件。从纯粹的安全设计角度来看，我们可能会通过静态配置来确认它被允许在 Salesforce 中执行特定操作，并且被允许通过邮箱发送邮件。但真正棘手的地方在于，它现在是一个同时拥有多种不同系统权限的统一智能体套件。那么，有什么机制能真正阻止它从 Salesforce 提取敏感数据，并将其写入发送给另一个客户的邮件中呢？以往那些针对每个独立系统分别进行安全设防的传统安全护栏 (Guardrails)，在智能体普及的未来将不再奏效。其次，我并没有具体指示智能体应当执行哪些步骤，而只是给它分配了一个任务，它会自行制定并执行该计划。这与人类的操作方式极其相似。这说明数据可以在传统的身份系统无法解决的身份和权限边界之间流动。传统架构上没有一种统一的方法来治理从 Salesforce 流向邮箱的数据访问权限，因为以前这种流动是高度确定性的，而现在却不是了。另一个非常典型的例子是，这些模型非常擅长规避我们给它们制定的规则。一提到这一点，大家可能会心一笑，因为他们自己也遇到过类似的情况。我曾让 Claude 写一份文档，但在当时我禁用了 Google Drive 的 MCP (Model Context Protocol) 连接器。结果 Claude 提示说：“看起来 Drive MCP 连接器已禁用。没关系，我尝试一下变通方法。”接着，它自己打开了浏览器窗口，输入了 drive.google.com，然后点击鼠标按钮上传了文件。它表现出了类似于人类的创造性，这与静态、确定性的传统软件系统完全不同。

萨姆： 我之所以笑，是因为我最近在试用 Codex 的 /goal 功能。我想尝试让它像 DSPy 那样去优化提示词。我给它提供了一个包含大量 URL 的文档，任务是识别出我可能感兴趣的 URL。这类似于推荐系统，或者称之为分类器更为准确。我设定了目标，要求它对提示词进行迭代，直到能够减少误报率（因为此前它虽然运行得不错，但误报很多）。最终它告诉我它成功了。但当我查看它优化后的提示词时，发现内容居然是：“如果 URL 包含这个、这个、这个或那个，那么就是有用的，否则就不是。”它竟然用了这种偷懒的硬编码方式。

戴夫： 没错。你可以试想一下，如果你想通过编写一条规则来规定“做这个，不要做那个”，那根本是不可能的。这本质上就像在玩“打地鼠”游戏，你得穷尽并防范它可能采取的每一个细微动作。在开发系统时，比如做你提到的这个排序或分类问题，这可能只是一件趣事，或者有点令人沮丧，因为模型找了这么一个投机取巧的变通方法。但如果是从安全人员的角度来看，这简直令人毛骨悚然。你原本以为已经实施了所有的最佳实践，但系统却以一种独特且新颖的方法绕过了它们。而安全人员还必须为此承担责任，因为目前大家的普遍态度依然是“工具只是在代表用户执行操作”。我认为这种安全漏洞和认知差距，正是目前阻碍企业采纳 AI 的真正痛点。

萨姆： 所以我们需要用 AI 来保障 AI 的安全。在当前的行业背景下，你提出的通过引入 AI 来解决这一问题的具体方案是什么？

戴夫： 的确如此。我认为一个完备的解决方案需要具备三个要素。如果你正在构建自己内部的治理与安全方案，我建议着重考虑这三点。第一，需要具备跨平台的可见性。如今，智能体几乎无处不在，无论是运行在云端还是终端设备上。因此，必须能够清晰地监控它们的运行状况以及所拥有的访问权限。然而，人们往往会过度纠结于可见性这一点。当他们好不容易解决了可见性问题后，才发现如果出现异常时无法采取切实行动，那么可见性在某种程度上就失去了意义。因此，可见性仅仅是底层基础。第二，需要具备动态运行时安全防护的能力。我的观点是，这必须通过 AI在环治理 (AI-in-the-loop) 系统来实现。为此，我们构建了一套名为 SAGE (语义 AI 治理引擎) 的系统。这本质上是我们的安全智能体，其核心运行着一个小语言模型 (SLMs)。SAGE 会审查流经智能体系统的每一个提示词、回复和工具调用。无论是你输入给智能体的信息，还是智能体即将执行的动作、即将调用的工具及其参数，它都会进行全面审计。此外，SAGE 融入了我们通过安全研究积累的大量网络安全最佳实践。我们确保能够预防所有显而易见但企业可能尚未明文规定的安全风险，例如防止数据外泄、以及阻止危险和具有破坏性的操作。在 SAGE 监控这些行为的同时，更关键的步骤是结合企业的自身情况进行定制。这种定制分为两个维度：首先是策略定制。我们允许企业导入自身的安全策略（例如通过上传文档），或直接使用自然语言来编写策略。这样一来，SAGE 就能理解不同行业的特定合规要求。比如对金融机构而言，意味着不能通过智能体向最终客户提供理财建议；而对医疗机构来说，则意味着必须严格保护受保护健康信息（PHI）。其次，我们为 SAGE 引入了数据和身份上下文信息。由于 Rubrik 本身是一家专注于数据与身份系统备份的数据安全公司，我们非常清楚企业内部的敏感数据分布在哪里，以及哪些身份信息存在泄露风险。这些维度共同丰富了 SAGE 这一 AI在环治理 (AI-in-the-loop) 系统。而在这个过程中，核心选用小语言模型 (SLMs) 至关重要，这也正是 Rubrik 基础设施的优势所在。因为如果我告诉你，我们保障 AI 安全与治理 的 代价是让你的 Token 消耗翻倍、账单翻倍并带来极高的延迟，你肯定会拒绝并宁愿选择不那么安全的版本。因此，我们必须在保证极快速度和低资源消耗的前提下实现这一目标。这就是第二点：通过 AI在环治理 (AI-in-the-loop) 系统检测所有流量并决定是否予以放行，来保障系统安全。第三点则是，Rubrik 长期秉持“默认已被入侵（Assume Breach）”的防范理念，这意味着我们必须假设在某个时间点一定会发生安全失控。在智能体时代更是如此，你必须在系统出错时拥有某种“撤销”按钮。我们设计并实现的撤销按钮，其核心逻辑在于将你的可观测性 (Observability) 与业务韧性及灾备恢复系统相绑定，这也是我建议大家都要考虑的一点。如果你在某些地方部署了数据备份系统，请务必将可观测性系统与之对接。这样一来，一旦你监测到智能体采取了破坏性动作——比如曾经发生过类似于 Pocket OS 这样的事故（译者注：Pocket OS 是一家真实的初创公司，其编码智能体因自主执行操作误删了生产环境数据库，导致公司几近崩溃），其中一家初创公司因为编码智能体擅自删除了生产环境数据库而几近崩溃。这就是为什么我们要将智能体的可观测性与可恢复性机制联系在一起。当你从可观测性堆栈中发现智能体执行了删除生产数据库等破坏性操作时，系统可以立即生成一键式恢复方案，自动检索历史快照，定位到智能体实施破坏之前的临界健康状态，并将 系统 重新拉起恢复。我们将这项功能称为智能体回滚 (Rewind)。当然也有人会用其他的名称来指代它。总结来说，这三大核心能力就是：监控运行状况、具备持续执行和贯彻策略的机制，以及在发生故障时确保具备系统恢复的能力。

萨姆： 这里面包含了很多有价值的信息。关于第二点，我想你刚才已经部分解答了。我原本想问的是，策略执行的具体位置在哪里，或者说 SAGE (语义 AI 治理引擎) 的具体产品形态是什么？它是一个智能体，还是一个通过编程嵌入的垫片 (Shim)？听起来它更像是某种在网络线路上运行的系统。

戴夫： 实际上，这取决于你的运行时 (Runtime) 挂载在何处，这也印证了智能体无处不在的现状。我们看到，在许多场景中，SAGE (语义 AI 治理引擎) 会内联在请求路径中。例如，当你向 OpenAI 或 Claude 发起调用时，它就像一个反向代理 (Reverse Proxy) 部署在链路中间，从而能够直接判定是否允许特定的操作。但有时客户需要不同的集成模式。目前许多工具都暴露了诸如“工具调用前 API 钩子（pre-tool call API hooks）”之类的接口。如果你在微软的 Copilot Studio 中构建智能体，或者使用像 Claude Code 这样的工具，这些智能体开发套件自身就能够向 SAGE (语义 AI 治理引擎) 这样的验证服务发送请求，询问“是否应该允许此项操作”。极为巧妙的是，这些流程是可以并行处理的。也就是说，在请求开始被处理的同时，SAGE (语义 AI 治理引擎) 系统会同步评估其合理性，并在必要时直接予以完全拦截。因此，它既可以以内联 (In-line) 代理的方式运行，也可以通过各种插桩钩子 (Instrumentation Hooks) 来实现。一旦你接入了不同的智能体运行时，我们会根据所连接的具体运行时环境，自动匹配最合适的策略执行方案。

萨姆： 那么关于第三点……我刚才关于第三点的问题是什么来着？能帮我回忆一下第三点吗？

戴夫： 第三点是灾备恢复与业务韧性（Recovery 和 Resilience）。即通过将高强度的可观测性与快速恢复能力相结合，确保在发生意外时不会陷入瘫痪状态。

萨姆： 在我看来，这本身就是一个很高的门槛，也是企业在尝试落地该方案时的一个潜在阻碍。有多少企业真正建立了完备的数据恢复和备份系统？更不用说能与智能体对接并实现自动化运行的系统了。我所设想的这种技术不成熟度是否早已被行业克服，还是说现实情况真的像我脑海中那样严峻？

戴夫： 事实上，许多组织——特别是大型企业——确实部署了数据备份和恢复解决方案，因为在很多合规要求中这是强制性的。其历史原因在于，过去企业需要备份来保证在遭遇自然灾害、火灾或洪灾时的业务连续性。回想几十年前，大家都开始采购备份系统，就是为了应对“如果洪水淹没了数据中心，该如何恢复业务”的问题。但在当时，这些解决方案相对基础，更像是一个应付保险合规的勾选项，大家都希望永远用不上它。

萨姆： 而且，我也觉得这套流程非常沉重。正如你所描述的，未来智能体将无处不在，持续吞吐和处理各种事务。如果你不断收到报警或触发器提示说“某个智能体执行了不合规的操作”——既然你们用的是小语言模型 (SLMs)，它也许没有最顶级模型那么聪明，偶尔会有漏网之鱼。而在我的印象中，数据备份、恢复甚至是快照 (Snapshotting)，都是极其沉重的运维流程，很难想象在智能体出错时可以如此轻松地一键“回滚”。或许对于一些小型的独立数据库来说可行，但对于大型系统来说呢？

戴夫： 长期以来，大多数备份与恢复系统确实是那种非常笨重的软件，企业买来之后就束之高阁，唯恐有派上用场的一天。一旦出事，可能几年才用一次，人们不得不拍掉上面的灰尘，绞尽脑汁地琢磨该如何将其接入系统。我们的核心洞察是，智能体的出现将彻底改变这一游戏规则。今后，灾备恢复与业务韧性的需求将不再只是应对极其罕见（最好永远不要发生）的勒索软件攻击。由于外部恶意的 AI 驱动型攻击以及内部无意造成的 AI 失误，这种恢复需求将会变得极为频繁。最理想的方案是将一流的恢复系统与先进的 AI 智能体监控系统有机结合。正如你所说，目前大多数企业还没有具备这种能力，因为你理想中是希望将它们打包购买和部署（在这里为 Rubrik 打个小广告，我们正是提供这一方案的厂商）。但其中的关键在于，企业是否能找到一套将两者在架构上融合在一起的系统。由于合规等原因，你可能已经拥有了某种数据备份 和 恢复手段，那么是否有可能将其接入你的可观测性平台？此外，我认为“小语言模型 (SLMs) 在针对大语言模型 (LLMs) 进行策略执行时效果不佳”是一个误解。实际上，我们发现对于特定领域的任务，经过微调的专用小语言模型 (SLMs) 往往优于仅通过提示词工程进行泛化引导的大语言模型。例如，当我们将我们的小语言模型与当时作为行业基准的 GPT-5.2进行对比测试时，发现我们不仅在速度和成本上实现了数量级的优势，而且在判定是否放行操作的二分类准确率上也更高。当我们将大语言模型的输出限制在非常低的基数（即明确规定它该做什么）时，这一结论屡试不爽，而这正是一个守护智能体（Guardian Agent）所需要的。

萨姆： 确实，这我可以理解。此前影响我看法的是关于 OpenClaw或个人智能体（Personal Agent）的一些讨论。大家经常说，应该选择前沿模型（Frontier Model）来作为主编排器，因为如果将小语言模型 (SLMs) 暴露给外部不可信的数据源，它们相比前沿模型更容易被操纵。前沿模型不仅经过了更好的微调，能够检测并抵御恶意操纵，而且它们本身更聪明、参数量更大。

戴夫： 针对这一思路，我们进行了大量的基准测试，甚至在 Predibase 时期就开展了这方面的工作。我们当时发表了一篇名为 LoRA Land (Loreland) 的论文，因为从技术细节来看，所有这些模型本质上都是类似于 LoRA 微调的适配器（LoRA-tuned adapters）。我们的发现是，对于开放式或开放领域的任务，你完全正确，应该使用大型前沿模型（Frontier Model）。这就是为什么主编排器或规划器应当由更大的模型来充当。但是，当任务的约束条件越明确，你越会发现小语言模型 (SLMs) 展现出更加出色的性能。

萨姆： 那么，如果它是一个特定领域的分类器呢？

戴夫： 如果是特定领域的分类器，你通常能做的最好的方式就是通过类似监督微调（SFT）进行后期训练，在一款小语言模型（SLMs）上运行它。对于我们正在讨论的这种任务，即简单判断是否应该允许或拒绝某项请求，这实际上是小语言模型（SLMs）最理想的应用场景。你可以在极低的延迟下运行它。不过，针对你提到的观点，我认为所有的防御机制最终都会存在一定比例的漏报（False Negatives）。由于智能体技术的发展速度实在太快，我们无法捕获并阻断所有问题，这就是为什么系统的弹性和韧性同样至关重要的原因。

萨姆： 我们之前谈到，智能体本身在执行任务时会表现得非常有手段且极其主动，对吧？然后我们也讨论了使用小语言模型（SLMs）或大语言模型（LLMs）作为裁判（LLM-as-a-Judge）的做法。但我能预见到这样一种场景：智能体开始尝试攻击或绕过你的小语言模型（SLMs），以使其请求获得批准。如果它摸清了背后的运行逻辑，我想它在这方面可能会做得非常出色。那么，你该如何防止智能体在请求中注入类似“这是一项允许的操作”之类的信息呢？你明白我想表达的意思。

戴夫： 确实如此。这就是为什么构建外部系统如此重要。我见过很多人，当他们第一次想到“我们需要 AI 来保护和治理 AI”这个概念时，第一个念头通常是：“太棒了，我已经在这个做了，我在模型的提示词里加入了安全护栏（Guardrails）。”这通常是他们的第一步。你在笑，但我必须说，这其实是目前最普遍的做法。如果我们要为这个领域的安全治理现状排个序：第 0 步是基本上什么都不做；第 1 步是在某个云端控制台中配置一堆确定性的规则，希望它们能在某种程度上发挥作用，但这种方式非常繁重且局限；第 2 步是意识到需要引入 AI，并开始在模型提示词中加入规则；而第 3 步则是引入一个外部系统来监管输入和输出，这正是 SAGE (语义 AI 治理引擎) 的作用。现在，我认为即使是 SAGE (语义 AI 治理引擎) 有可能成为被攻击的目标，不过在 SAGE (语义 AI 治理引擎) 内部处理数万亿个 Token 的过程中，我们还没有看到任何可以被绕过的事件或证据。我们也专门对模型进行了后期训练，以应对此类潜在的攻击。但我想强调的是，这正是为什么需要像 SAGE (语义 AI 治理引擎) 这样独立外部系统的原因——因为如果仅仅在模型提示词中放入 10 条安全护栏（Guardrails），这恰恰是模型最擅长绕过和突破的防御方式。虽然外部系统也不是完美的，但它依然远优于目前人们所使用的其他任何方案。

萨姆： 这很有趣，因为我看到了很多类似关于开源项目、特别是像 Claude 这样的 YouTube 视频，视频里总在强调：“安全是非常重大的问题，你真的必须在提示词里叮嘱你的模型保持安全。”听到这，我不禁会想：等等，这是认真的吗？

戴夫： （笑）

戴夫： 是的，这有些类似于云服务商和超大规模云服务商（Hyperscalers）的模式。我认为各大 AI 实验室和其他服务商会在系统内部内置一些安全机制，但你仍然需要一个第三方来监管这一基础设施，因为你不会希望基础设施自己来监管自己。“寄希望于模型做正确的事”这种想法，在 95% 的情况下或许是有效的，但剩下 5% 的漏洞却会带来巨大的爆炸半径 (Blast Radius)，极易发生严重的安全事故。

萨姆： 你提到 SAGE (语义 AI 治理引擎) 已经处理了数万亿个 Token。这个项目开展了多久？它是一个 SaaS 服务，还是开源的？它的交付形式是怎样的？

戴夫： 我们在今年二月（也就是几个月前）正式将 Rubrik 智能体云 (Rubrik Agent Cloud) 以及作为其中智能体安全核心的 SAGE (语义 AI 治理引擎) 推向了通用版本（GA）。我们之所以能够如此迅速地处理数万亿个 Token，是因为一旦你与那些开始大规模使用智能体管理框架的机构合作，你就会看到他们的使用量呈现出指数级增长。我们在 Rubrik 内部也看到了同样的趋势。至于产品交付形式，我们既提供由 Rubrik 托管的 SaaS 版本，也支持部署在客户自己的环境（本地或私有云）中，这对于一些处于严格监管行业中的客户来说至关重要。因此，无论是托管服务还是自主部署，我们两种方案都提供。

萨姆： 好的。那么能聊聊在实际部署中的情况吗？你刚才提到，即使防御系统能拦截 95% 的问题，剩下的漏洞仍然会构成巨大的爆炸半径 (Blast Radius)。我想了解的是，当这个系统在实际生产环境中运行时，无论是从具体案例还是从百分比来看，你们发现并拦截了多少本来会造成严重后果的潜在威胁？这种情况是极其罕见的，还是说……

戴夫： 坦率地说，几乎随时都在发生。

戴夫： （笑）

戴夫： 比如，在一些企业内部的规模化部署中。我可以分享几个我们在 Rubrik 自身部署中的实际案例，因为这些案例对我们来说最为直观。我们在很早期就注意到，我们内部非常高频地使用 Claude Code。你会发现很多意料之中的安全隐患，比如你以前猜测人们会这么做，而现在在实际操作中真正看到了，并能借此优化工程规范。例如，员工在请求和响应中直接放入明文凭据。这在安全入门常识中是绝对不被允许的，但你确实能在日志里看到。因此你会想：“好吧，我未来必须要拦截这类行为。”这确实是可以通过策略实现的。接着我们看到了更复杂的异常行为。Claude Code 是我们重点防护的一个非常典型的场景，而且这些编程智能体自然拥有 GitHub 等平台的访问权限。我们注意到，Claude Code 在一个月内好几次尝试将一些内部信息推送到错误的仓库。而所谓的错误仓库，指的是它试图把本应是私有的代码推送到公共仓库。它实际上提取了部分源代码，并尝试打包上传到公共的 GitHub Gist 中。这种情况发生得相对频繁。甚至有几次，当我们回溯审计日志时——这里我不想引用错误——但你会发现，Claude Code 在请求授权时的表述非常令人困惑，从而让用户在确认提示时一步步放行。所以在技术层面上，智能体认为它已经获得了人机协同 / 人类在环 (Human-in-the-loop) 的批准。但我们之所以能够成功拦截，是因为我们分析了完整的上下文。我们评估了它实际想要发布的内容以及目标目的地。因为我们制定的安全策略禁止任何看起来包含专有和内部特性的数据流向公开源，所以系统能够主动识别并拦截。我们甚至遇到了一个极端的案例：Claude Code 试图绕过我们对 GitHub 公开 Gist 的拦截。它没有使用常规的“文本输入-文本输出”方式去请求某个 API 或 URL，而是启动了一个无头浏览器窗口，并在特定的屏幕坐标上进行鼠标点击模拟。而我们检测到，其中一个点击的坐标恰好对应了创建公开 Gist 的按钮。所幸我们成功识别并阻止了这种隐蔽的操作。这显然是一个非常有意思的发现，主要是从敏感数据外泄的维度来看。此外，在凭据泄露等其他安全隐患方面，拦截几乎是常态化的。这其实反映了我与大型企业高管交流时他们普遍的感受：当他们拿到企业内部 AI 生态系统的实际运行审计报告时，无一例外都会大吃一惊。我曾和一位负责人交流，他去年对我说：“我认为我们不需要智能体安全治理系统，因为我们目前只部署了三四个智能体。”几个月前我和他一起吃饭时，他坦言：“我错了。我们进行了一次全面的审计，你猜我们实际部署了多少个智能体？”我回答说：“肯定不止三四个吧？”他苦笑着说：“不，实际是 250 个。”我当时就觉得，这就是智能体工具在企业内部自下而上渗透、野蛮生长的真实速度，确实令人吃惊。

萨姆： 在他们报告的这个数字中，这 250 个是指有 250 个人在使用 Claude Code，还是指那些 24 小时运行在公司基础设施上的后台智能体？

戴夫： 两者皆有，但其中很大一部分是员工自己在云端（例如利用 Copilot Studio）构建的自主后台智能体，用来自动化执行日常任务。

萨姆： 我在想怎么组织这个问题。我想表达的是对“仅依靠 AI 来保障智能体交互安全”这一观点的质疑。从企业决策者角度来看，企业真的会觉得只靠 AI 就能获得足够的控制力吗？或者从我个人的角度来看，我可能稍微有些守旧，我更倾向于拥有明确的控制权。事实上，这让我很头疼。前几天我正尝试将一个工具连接到 co-work，我当时就想，为什么它不能直接给我一个“只读”的选项，而必须授权所有权限？对于习惯了传统安全管控的人来说，要接受这种失去细粒度控制权的现状确实非常困难。

戴夫： 没错，坦白说，这对所有人来说都是一个很难跨越的坎——你等于是在告诉我，我最终必须信任一个 AI 模型来保障我的安全与治理态势。但在 AI 安全领域，我们通常会遵循“深度防御”（Defense-in-Depth）的理念，也就是进行多层防御体系的叠加。我认为，当前安全架构中缺失的一环正是 AI在环 / AI在环治理 (AI-in-the-loop) 的机制。我们已经有足够多优秀的基于规则的系统，也有非常成熟的其他配置方式。我并不是说……

萨姆： 你不是说只需要 AI，或者说仅靠 AI 就足够了。你的意思是，在目前的流量规模下，传统的规则系统已经不足以应对，所以必须引入 AI 来进行补充。

戴夫： 我想表达两点。第一，你现有的规则防护固然好，但你缺失了关键的一环；第二，我认为这个缺失的环节正是整个安全拼图中最核心的部分。诚然，你需要保留一些确定性的规则，这毫无疑问。但就拿你刚才举的例子来说，“我能不能直接把它设为只读模式？”当然可以。我看到很多企业在保护特定的基础设施时会说：“不用担心，我们绝对不会发生智能体通过邮件连接并窃取 Salesforce 数据的情况，因为我们直接禁用了所有对 Salesforce 的访问。”但我心里在想：如果董事会不断向你施压，要求你们必须采用 AI 来提升生产力，那么直接彻底禁用权限怎么可能成为长久之计？所以，萨姆，我的观点是，虽然确实有很多场景你可能永远不想让 AI 触碰，但在绝大多数情况下，你确实需要 AI 来代替执行一部分工作。这就意味着必须赋予它写入权限，尽管这听起来很冒险。因此，我们需要在高度安全的运行时安全护栏（Guardrails）中运行它。这就是为什么我认为 AI在环 / AI在环治理 (AI-in-the-loop) 机制是重中之重的原因。如果企业固守“直接一刀切阻断所有访问”的策略，其结果只会极大地压缩 AI 能带来的投资回报率（ROI）。我认为正确的解决方案是：针对一类完全不需要发生的风险操作，直接通过确定性的规则予以封杀；而针对另一类极其复杂、需要根据上下文意图进行决策的模糊操作，则必须依赖策略执行，这就是 AI在环 / AI在环治理 (AI-in-the-loop) 系统发挥威力的地方。

萨姆： 我很好奇，像 MCP (Model Context Protocol) 以及 A2A（Agent-to-Agent）等各类新兴的智能体交互协议，在多大程度上改变了这一现状？

戴夫： 是的，我认为这些协议本质上只是为这些安全问题开辟了新的攻击面（Surface Area）。如果从 MCP (Model Context Protocol) 或 A2A 协议来看，它们是非常优秀的互联协议。以 Anthropic 提出的 MCP (Model Context Protocol) 为例，它相当于为智能体提供了一套统一的 API，使其能够无缝理解和对接企业生态中运行的各种应用程序。例如，我提到我们的 Claude Code 使用了连接到 Google Drive 的 MCP 接口。然而，我们在内部观察到的现象是，虽然 Claude Code 只被授权连接一部分通过审批的 MCP 接口，但如果去盘点实际连接到 Claude Code 的 MCP 接口，其规模要远远超出最初批准的范围。

萨姆： 具体是指什么？

戴夫： 意思是员工在私自将 Claude Code 连接到各种自定义的 MCP 接口上，通过本地的 MCP 服务器，去连接那些未通过安全审查或不在最初白名单里的服务。

萨姆： 也就是说，你们虽然有一个集中的管理部门来审批通过的 MCP，但实际在企业内部，却存在着严重的 MCP 肆意蔓延和野蛮生长（Sprawl）的现象。

戴夫： “MCP 肆意蔓延”这个词用得非常贴切。目前有一些试图解决这个问题的方法，比如部署 MCP 网关（Gateway），但这也带来了如何确保所有流量都强制通过网关等一系列工程挑战。要想彻底解决这个问题，需要多层防御。我认为，在完美实施的前提下，MCP (Model Context Protocol) 确实能在访问控制的集中化管理上提供很大帮助。但它依然无法解决行为级的安全问题——例如，即便我使用的是合法的 Salesforce MCP 连接器和合法的电子邮件 MCP 连接器，MCP 也无法阻止智能体通过邮件将 Salesforce 的敏感数据外泄。也就是说，它不能在应用层控制数据流向，但能明确哪些应用应该授权给给定的智能体。因此，这是一个非常有价值的协议。这与用于智能体间通信的 A2A 协议类似，它们在统一结构和使 Schema 更加一致方面很有帮助，这也降低了我们检测特定攻击模式的难度。不过随着技术演进，目前还有一个悬而未决的问题：MCP (Model Context Protocol) 是否能继续保持主导地位，还是说智能体会直接使用文档中查到的带参数的命令行工具？坦白说，我们现在看到这两者并存。因此，我们已经将安全治理的定义从纯粹的“MCP 工具”扩展到了“所有工具”，除了 MCP 之外，还兼容直接的 API 访问。

萨姆： 但如果你是采取网络层（Over the Wire）拦截或者作为中间人监听通信的方式，对你们而言其实都无所谓。因为无论智能体是在使用 Curl 发起请求，还是使用命令行（CLI），亦或是使用 MCP，这些通信最终都是要在网络上传输的。

戴夫： 没错。这确实对我们影响不大。有些企业可能只为 MCP 制定了安全策略，而忽略了其他工具。我们希望帮助企业强制执行他们所有的安全策略，而且无论采用何种形式，我们都能直接监测到这些流量。

萨姆： 明白了。对于构建智能体的人来说，可观测性（Observability）是一个非常热门的话题，比如审查调用链路（Traces）等。通常的做法是，在智能体与其他交互目标之间部署类似反向代理 (Reverse Proxy) 的中间件。在这种场景下，日志和噪音可能会比你们的工具白名单大得多。你觉得这种可观测性有价值吗？它对你们的工作有帮助吗？对于可观测性与智能体安全之间的关系，你是怎么看的？

戴夫： 这很有意思，因为可观测性实际上有两个完全不同的用途，针对这两个用途也有着泾渭分明的工具集。第一种是面向基础设施运维人员或开发人员的可观测性，主要用于追踪完整的调用链路，进行性能评估（Evals），以了解智能体是否好用、是否正常运行以及工作效率如何。第二种是面向安全的物理安全可观测性，这也是我们重点关注的领域——即系统是否正在发生危险行为。在这两个不同的场景下，你所关心的指标是不同的。我认为，如果一家企业已经在考虑智能体的可观测性，这对我们来说是一个非常理想的切入点。因为 Rubrik 智能体云 (Rubrik Agent Cloud) 主要提供三项功能：监控与可观测性、利用 SAGE (语义 AI 治理引擎)（或小语言模型 (SLMs) 治理套件）进行一致的运行时策略执行，以及系统的弹性和智能体回滚 / 回滚 (Rewind) 能力。在与客户沟通时，我通常会告诉他们，第二点和第三点才是我们的差异化核心竞争力，第一点（可观测性）随着时间推移会逐渐商品化（Commoditized）。如果客户已经有了可观测性解决方案，那对我们非常有益。因为我将可观测性和能见度视为整个架构的底层基础，而在这一基础之上，你才能真正构建起更高级的安全和治理机制。但现状是，大多数组织目前仅对他们一小部分的智能体架构拥有良好的可观测性。举个例子，很多企业会说：“是的，我们正在云端使用 LangChain 构建自定义智能体，同时也在使用 Copilot Studio，并推广 Claude Code。顺便说一下，我们刚刚还引入了 Glean 和 Salesforce 的 Agentforce。”可以说，各种工具一应俱全。但我猜测，这些企业……

萨姆： 往往只有那一两个自建的智能体拥有真正意义上的可观测性。

戴夫： 没错。很可能只有那些基于 LangChain 构建的自建智能体有完善的可观测性，而其他智能体系统基本处于安全盲区。这时我就会问他们：“等一下，你们企业内部 Claude Code 的使用频率已经遥遥领先，而 LangChain 智能体的使用量可能要低得多，但你们的可观测性却仅覆盖了后者。”因此，我们的目标是将所有这些智能体统一纳入到一个管理平台中。在这个过程中，像 OTel（即 OpenTelemetry）等致力于推动可观测性指标标准化的开源项目，对我们起到了巨大的帮助，这在未来也将持续成为推动行业可观测性标准化的重要利好（Tailwind）。

萨姆： 这是因为你们可以直接对接这些标准化数据，还是因为企业在构建可观测性的过程中，已经理清了安全治理所需要的底层逻辑……

戴夫： 答案是两者兼有。因为我们以兼容 OTel (OpenTelemetry) 标准格式的方式来消费日志。因此，如果您已经在系统中运行了这样的流程，那么将其引导至我们的平台就会变得非常简单。其次，如果您熟悉这个理念，就会知道我需要一个系统来处理这些数据，并能确保在某个地方拥有一份不可篡改的追踪记录。

萨姆： 当我们谈到智能体产生的大量操作和决策开始超出传统“人机协同 / 人类在环 (Human-in-the-loop)”模式的承载能力时，这在多大程度上是一个主要局限于开发人员或使用 Claude Code 的人群的问题？相比之下，像 Cohere 这类协作场景的用户，其交互性往往更强。您认为这是一个独立于具体使用场景的普适性问题——即人们普遍开始无法跟上智能体的速度，还是说这依然有特定的场景限制？

戴夫： 目前这种情况在开发者的工作流中确实更为明显，但我认为这不会是最终状态。今天之所以在开发者工作流中更常见，原因有两点：第一，编程智能体是目前使用最频繁的；第二，它们往往拥有最广泛的访问权限。通常情况下，如果我们看一个典型的 Cohere 使用场景，比如“帮我优化 PPT 幻灯片”或者“在 Excel 中运行一个快速分析”。目前 Cohere 的定位大致在此。但随着时间的推移，当你开始赋予智能体越来越高的访问权限时，情况就会发生变化。它将不再仅仅是制作幻灯片，而是会去处理 Salesforce 中的报告。这就像在工程开发中，我们不再只是说“把按钮变蓝”，而是说“设计整个界面”。当智能体开始创建全栈式规划——从 Salesforce 导入数据到 Tableau，撰写电子邮件，进而自动更新底层记录系统——我相信它会带来同样巨大的管理开销。因为无论是编程智能体还是协同办公智能体，它们请求权限的根本原因是一致的：即代表你执行某项操作。目前开发人员平均拥有的权限和访问范围，可能是传统协同办公智能体的 10 倍左右。我不确定协同办公智能体是否会完全达到相同的权限水平，但我认为它们绝对正处于完全相同的演进轨迹上。

萨姆： 您是否发现小语言模型 (SLMs) 需要根据具体的使用场景、甚至更具体地根据特定客户来进行微调？还是说你们交付的是通用版本，且它们在不同环境下表现一致？

戴夫： 我们发现，针对诸如策略执行这样的特定场景来微调小语言模型 (SLMs) 是非常有帮助的。这包括理解会话数据，以及裁定是否允许或拒绝某些操作。相比于针对组织特定上下文对小语言模型 (SLMs) 进行训练后微调（Post-training），我们发现更关键的是推理时的定制化（Inference-time customization）。也就是在小语言模型 (SLMs) 做出裁决的瞬间，动态嵌入来自该组织的特定上下文。简单来说，目前我们的做法是：针对特定使用场景进行训练后微调，然后向所有客户交付相同的模型，并在推理阶段为每个客户进行个性化定制。

萨姆： 这与我提出这个问题的初衷是一致的。专注于 Claude Code 的小语言模型 (SLMs) 对数据的审视方式，显然应该不同于专注于电子邮件沟通或商业用户对话合规性的模型。

戴夫： 没错。更进一步来看，虽然通用的小语言模型 (SLMs) 仍在试图生成所有的可能 Token，但如果能让它专注于区分高风险和低风险操作的边界，我认为仅凭这一点就能带来立竿见影的显著性能提升。

萨姆： 我们刚才略过了这部分，不过从更广泛的层面来看，Rubrik 智能体云 (Rubrik Agent Cloud) 具体扮演着什么角色？

戴夫： 好的。Rubrik 作为一家公司，主要提供两大核心产品。第一是 Rubrik Security Cloud，专注于数据与网络弹性（Cyber Resilience），比如备份整个企业的数据和身份验证系统，并帮助用户实现快速恢复。第二就是 Rubrik 智能体云 (Rubrik Agent Cloud)，它本质上是与前者并行的产品线。它的核心使命是确保企业在当下以及未来的 AI 驱动时代具备足够的韧性。该产品包含三大核心支柱：可观测性、基于 SAGE (语义 AI 治理引擎) 的运行时安全，以及弹性与智能体回滚 / 回滚 (Rewind)。

萨姆： 它的部署流程通常是怎样的？

戴夫： 这正是 Rubrik 智能体云 (Rubrik Agent Cloud) 最让我感到欣慰的地方。我想分享一个初创时期的经验：即如何优化“价值实现时间 (Time-to-value)”。在训练后微调（Post-training）的过程中，一个主要的挑战就是它无法立即产生价值。你需要收集数据集，然后训练模型，接着进行评估。而 Rubrik 智能体云 (Rubrik Agent Cloud) 的一大优势在于，你可以非常轻松地将其接入现有的智能体运行时，并几乎立竿见影地看到成效。例如，如果你想接入 Copilot Studio 或 ChatGPT 企业版，我们最近刚推出了与 Anthropic 及其合规 API 的集成，你只需要进行 API 级别的对接即可。如果权限配置正确，整个设置过程只需几分钟。之后流量就会开始流入，你就能看到实时的运行时可观测性。随着时间的推移，你还可以逐步添加更多集成。我们支持接入多种不同的数据源，比如企业移动设备管理（MDM）套件，或者在网关级别进行部署。但对于起步阶段，我们通常建议先选择一个平台并进行授权。这种 API 级别的集成速度极快，能让你迅速在智能体运行时中看到实际价值，之后再根据需要逐步覆盖其余的技术栈。

萨姆： 那么，当我们迈出第一步并完成 API 级别的集成时，得到的是一个主要用于可观测性的工具，还是也包含了我们刚才讨论的全部决策功能？我们需要做额外配置才能实现决策，还是说它开箱即用？

戴夫： 这个领域的发展确实非常迅速。当我们最初推出 Rubrik 智能体云 (Rubrik Agent Cloud) 时，它主要侧重于可观测性，用户需要自行配置策略，然后我们展示哪些行为违反了策略。当时的演示非常受欢迎，因为我会展示：“看，接入系统后，我现在可以用自然语言直接编写一条策略。”比如输入“不要将敏感数据放入电子邮件中”，然后它就可以直接运行。但在向客户实际部署的过程中，我们发现许多企业在初始阶段并不清楚自己具体需要执行哪些策略。相反，他们更希望我们能直接提供 80% 到 90% 的预设方案。

萨姆： 或者类似的现成方案。

戴夫： 没错，就是“开箱即用并提供 80% 到 90% 的答案，然后让我根据需要进行挑选和定制”。因此，我们最近推出了一个新组件。你只需将我们接入运行时，一切就准备就绪了。系统会立即启动，并自动展示各项指标。我们通俗地将其称为“洞察 (Insights)”，它会自动显示 SAGE (语义 AI 治理引擎) 检测到的流量、运行时策略执行以及潜在的危险行为。我们还会为你推荐修复建议，比如“创建一条策略以防止此类行为再次发生”。之后，你可以再进行更深度的定制化开发。我们的目标始终是缩短价值实现时间，并在默认状态下解决绝大多数核心问题。因此，一旦完成连接，你就能在初期直接获得巨大的实用价值。

萨姆： 既然这个领域的发展如此迅速，您如何看待它的未来走向？下一步的发展趋势是什么？我们将会迎来什么？

戴夫： 这很有意思，因为在节目的前半部分，你曾问过：如果我观念比较保守，担心完全将控制权拱手让给 AI 系统或治理框架，该如何打消这种顾虑？实际上，我们在去年做出了一个决定，即希望将更多的治理流程纳入环路中。坦白说，去年做出这个决定时，我内心也有过疑虑，所以当时的回答比较保守，会说你确实需要两者结合——既需要非确定性系统，也需要确定性系统。

戴夫： （清了清嗓子）

戴夫： 我确实看到世界正越来越多地转向由 AI 系统端到端地运行这些流程。因此，我认为未来的趋势是——虽然目前很多智能体仍停留在“只读模式”，但这种情况很快会发生改变。智能体将从只读阶段毕业，走向对各类 CRUD (增删改查) 应用的写入和删除操作，因为它们本质上将承担人类正在进行的工作。我认为 Token 的消耗和推理成本将继续极快地增长。与此同时，我们不可避免地会看到一系列大规模的——无论你怎么称呼它们，失误也好，安全事故也罢。在迎来生产力大爆发的同时，我们也势必会目睹一些因失误导致的意外事故。最终，我们达成共识的结论将是：除了引入 AI 自身，并没有其他更好的办法来解决这一问题。尽管为了让人们感到安心，并且鉴于某些特定应用的客观需要，人机协同 / 人类在环 (Human-in-the-loop) 的规则在某些领域仍将保留，但我认为行业真正的焦点将转向以 AI 为首要考量（AI-first）的工作流。也就是说，我们将用引入风险的同类技术，来作为解决方案的一部分。这个世界变化得非常快。今年早些时候，智能体开发框架已经迎来了爆发式增长，我预计这一趋势仍将持续。今年编程依然会是主导性的使用场景，但到今年年底，我们将在许多其他复杂的知识型工作中，看到与编程智能体类似的演进。我们目前针对编程智能体的监控需求，也将开始扩展到整个智能体技术栈中。要实现这一点，除了实施 AI在环 / AI在环治理 (AI-in-the-loop)，我看不出有其他任何可行之路。

萨姆： 确实，思考这个问题非常有意思，我也倾向于赞同你的观点。这让我想到了我常用的一些工具，比如 Google Workspace (G-Suite)。它是否具备快照功能？换句话说，对于你们的第三个支柱，是否有办法能够接入？例如，当一个智能体不小心清空了某个用户的日历时，我们能否通过你们的系统说：“嘿，帮我把日历恢复到之前的状态”？

戴夫： 是的，实际上 Google Workspace 的很大一部分数据，都是 Rubrik 已经支持备份并进行集成的领域。所以……

萨姆： 确实，这是一个庞大的……

戴夫： 这正好与我们传统的业务核心相连接。

萨姆： 核心业务。

戴夫： 没错。

戴夫： 确实如此。当然，可能也存在某些零星的数据我们目前没有备份，但毫无疑问，绝大部分存放企业关键信息的核心区域，都是我们重点备份的对象。这也是 Rubrik 赖以建立起庞大业务的基石。因此，这是一个非常好的问题。为了能放心地赋予智能体对你日历的完全读写和删除权限，如果你知道在发生意外时能够轻松将这些操作进行智能体回滚 / 回滚 (Rewind)，你显然会感到安心得多。

萨姆： 是的。

戴夫： 归根结底，这就是我们为什么将其视作第三支柱的原因。同时，我们在第三支柱以及处理第二支柱的方式上，构成了我们最独特的两大差异化优势。坦白说，未来会有很多厂商进入智能体可观测性领域。如果你只需要这一项功能，市场上会有很多选择。虽然我有理由推荐我们自己，但市场上确实不乏其他优秀的供应商。而真正让我们脱颖而出的核心差异，正是我们的 SAGE (语义 AI 治理引擎) 和智能体回滚 / 回滚 (Rewind) 能力。

萨姆： 好的，戴夫。非常感谢你今天能抽空接受采访，并与我们分享你对智能体技术安全性的独到见解。

戴夫： 客气了。非常感谢你的邀请，萨姆。这次交流非常愉快，非常感谢。

萨姆： 好的。