Atlas 代理引擎如何助力 MongoDB 的内部 AI 战略

我在技术领域从业超过 25 年，这意味着我很少对新技术感到惊讶——通常在公众接触到新技术之前，我就已经对其有了近距离了解。作为一名 IT 领导者，我从不会孤立地评估一项新功能；而是始终结合实际企业使用案例以及随之而来的风险来进行权衡。如今，我常对人们说，在 AI 时代担任 CIO 意味着要身兼两职：既是加固大坝的工程师，又是不管怎样都必须打开水闸的操作员。

本周，MongoDB 宣布推出 Atlas 代理引擎的公共预览版，对于它将为客户带来的前景，我感到无比激动。Atlas 代理引擎提供了一种在生产环境中构建、部署和治理 AI 代理的安全方式。由于具备内置的记忆与检索功能，Atlas 代理引擎可以在企业数据所在的位置对其建立索引，并实时提供精准的上下文，从而在降低令牌费用的同时提高准确性。其在设计上也兼具开放性与灵活性，这意味着团队可以自由选择所需的 LLM 和框架进行构建（并且很快就能在他们选择的任何环境中进行构建）。

客户已经对 Atlas 代理引擎为其业务带来的前景感到兴奋。例如，Paysafe 利用 MongoDB Atlas 构建了一个代理系统，用于对事务数据进行自然语言到 SQL 的查询——这是 Paysafe 计划构建的一系列可复用工作流管道中的首个，这些管道将作为模板用于未来的用例。

目前，该公司的 Snowflake MCP 设置仅让 API 客户端对根本的数据模式有有限的了解。MongoDB Atlas 的灵活文档架构和可靠的扩展支持一个代理，该代理旨在用一个更强大、可重复使用的管道替换该设置，API 客户端可以使用自然语言直接查询该管道。

Paysafe 支付工程高级副总裁 Jana Janarthanan 表示：“目前，在我们的支付网络中调查异常活动，意味着我们的分析师必须在时间紧迫的情况下，手动整合来自多个系统的数据。我们很高兴看到，基于 MongoDB Atlas 代理引擎构建的智能代理能够缩短从发现问题到团队采取行动的时间，让我们的分析师有更多时间专注于最关键的判断。”

当 MongoDB 团队第一次向我展示 Atlas 代理引擎时，“默认安全和治理”这一短语立即引起了我的注意。因为如果有任何事情让我彻夜难眠，那就是想到代理在 MongoDB（或我们的客户）的系统中横冲直撞。

代理管理不仅仅是我关心的问题。这不仅见诸报端，更是整个行业的 CIO 都在努力解决的问题。与同行的每一次交流都在强化同一个观点：整个企业对代理的需求持续增长，但 IT 领导者需要一种既安全又稳妥——而不仅仅是快速——的部署方式。

从本质上讲，这是一个集中化与分散化的故事。开发者希望拥有自主权，能够以最小的阻力快速交付代理；而 IT 领导者则希望对代理在大规模运行时的行为拥有集中控制、可见性以及成本优化手段。能够妥善解决这一问题的组织将构建出兼顾两者的架构。

软件正日益走向无头化和代理驱动，CIO 现在就需要选择。换句话说，未来已来，而我们的职责是以负责任的方式塑造未来。

零号客户：我们的内部 AI 策略实践

MongoDB 实现这一目标的方式之一是充当产品的“零号客户”。行业中有许多不同的名称来形容这种做法（“自用自研”和“喝自己的香槟”是两个例子），但含义是相同的。在发布产品之前，我们会作为自己的客户来测试生产环境中的软件，并使用真实的使用案例和情况。

例如，当公司在 2024 年发布 MongoDB 8.0 时，我的同事 Jim Scharf 写了一篇博客文章，介绍了 8.0 版本对团队性能的提升有多大。

通过 Atlas 代理引擎，我们采取了“自用自研”的方式，构建了 Holly：这是一个统一的代理工作区，它为 MongoDB 的销售人员提供了一个一体化的工作平台，无需再在七个不同的工具之间来回切换。在 Holly 出现之前，准备单个帐户意味着在七个互不关联的工具之间来回切换，这些工具之间无法共享任何背景信息——在每个账户、每个交易周期上，仅工具使用成本就浪费了 4 到 6 小时。Holly 改变了这一切。七个工具变成了一个代理体验，代表们可以将节省下来的时间花在更重要的地方：与客户互动。

Holly：将工作时间从几小时缩短到几分钟

MongoDB 的 GTM 团队遵循标准化的分步方法，以了解客户的当前状态、目标以及实现这些目标所需的工作。销售代表称其为“辐条”，而且速度并不快；MongoDB 战略客户主管 Jack Bunkenburg 表示，辐条每周都要占用他一两天的时间。

问题出在工具，而不是流程。业务代表需要一个能够理解他们调用的全部数据语料的工具，以及一个能够在以往互不相通的系统之间保持记忆的工具。

如果没有它，使用七种不同的工具来管理帐户就像是因一种疾病去看七位专家，而他们中的任何一个人都无法看到其他人发现了什么。每次访问都会重新开始：您需要重新说明您的症状、病史以及上一位医生已经了解的情况。每个专家可能都很优秀。但系统仍然让您失望，因为上下文永远不会同步。只有您会这样做。

在构建任何内容之前，团队观察了实际工作的开展方式——用 Bunkenburg 的话来说，实际情况比纸面流程“要混乱得多”。单是客户调研就意味着要同时应付多种 AI 工具（ChatGPT、Claude、Gemini），这些工具彼此之间以及与 MongoDB 系统之间都不共享上下文，而且返回的都是千篇一律的通用回答。寻找佐证同样需要手动进行。筛选出真正重要的结果也是如此。

Holly 就是解决方案——Holly 提供了其他工具从未有过的共享上下文。一个界面，无需切换工具，汇集了销售人员研究、准备和执行所需的一切。在其底层，Atlas 代理引擎承担了繁重的工作（运行时、安全、身份、编排、状态、可观测性和生命周期管理），因此 Holly 的代理可以在生产中运行，而不只是在演示中运行。

图 1. Holly 的代理架构。

在实际工作中，这意味着 Holly 可以整理和总结会议转录内容、起草简报、找出销售代表尚未回答的问题，并协助撰写外联内容。结果：使用 Holly 的销售代表将研究和构建外呼潜在客户列表所需的时间减少了大约 95%，过去需要数小时的准备工作现在几分钟内即可完成。这意味着销售代表在参与每次对话时不仅行动更迅速，而且准备得更加充分。

“在使用 Holly 之前，我使用十多种不同的工具来进行研究和推广，因此在同一个界面中处理所有内容确实带来了很多价值，”Bunkenburg 说。“很多工具并不了解 MongoDB 的业务，也不了解我们试图通过这些工具实现的目标，但 Holly 了解这些。”

AI 时代的智能数据平台

展望未来，Holly 的愿景是成为一个完全集成的智能层，能够深入理解 MongoDB、我们的客户和各个账户，帮助整个 GTM 组织更有效地执行端到端工作流程。

最让我兴奋的是 Holly 本身之下的内容。Holly 目前运行着大约 30 个代理，所有这些代理都是在相同的 Atlas 代理引擎架构上构建的。当您向该架构添加代理时，它不会变得摇摇欲坠；它的设计理念是无论您运行 30 个还是 3,000 个代理，都能保持稳定。我们不仅仅为我们的 GTM 团队打造了一款工具。我们证明了一个蓝图，即在组织添加每个新代理时安全地扩展，而不是随着每个代理的增加而积累风险。

这就是 Atlas 代理引擎所代表的转变：从一次性代理转向受治理、可复用的平台，且无需绑定到单一云、模型或框架。 这就是寄希望于您的代理按预期运作与确信它们定会如此之间的区别，无论您正在运行多少个代理。

Atlas 代理引擎的发布是 MongoDB 本周发布的三项重要公告之一，其他两项是 MongoDB 9.0 和 Atlas Infinite。这些发布互为基础：MongoDB 9.0 强化了每个 MongoDB 客户已在其上运行的基础，Atlas Infinite 消除了该基础扩展方式的限制，而 Atlas 代理引擎则在两者之上利用 AI 代理进行工作，并以实时数据为基础对其进行治理。

构建者们一直选择 MongoDB，因为其 document model 非常适合应用程序数据的自然形态以及 AI 系统表示和交换信息的方式。这使应用程序可以更快地构建，更易于调整。越来越多的公司选择 MongoDB，因为它将这种原生适应性与实时操作数据、弹性扩展、在任何地方运行的自由，以及现在专为智能体时代构建的平台结合在一起。

一个平台。 任意数量的代理。利用 MongoDB 的智能数据平台，在数据所在的位置构建、部署和运行它们。