MongoDB Atlas Agent Engine 将数据库推向 AI 运行时

MongoDB 于 2026 年 9 月 29 日发布了三款相互关联的产品，其中包括 MongoDB Atlas Agent Engine，这是其直接进军 AI 智能体生产基础设施的举措。此次发布结合了性能更快的数据库、弹性的 Atlas 架构，以及面向智能体记忆、执行、检索、身份和治理的托管服务。

各项功能本身很重要，但更重要的是背后的整体布局。MongoDB 希望企业不再将运营数据与智能体基础设施视为彼此割裂的系统。该公司认为，智能体应当在其已使用的实时记录附近检索上下文、保留状态并执行受治理的操作。

这一定位使 MongoDB 与组合式智能体技术栈展开竞争。许多团队目前会连接数据库、向量存储、编排框架、记忆服务、模型提供商和治理层。AWS、Google Cloud 和 Databricks 也在将这些功能打包为托管平台，因此 MongoDB 进入的是一个竞争激烈的市场，而非一片空白。

MongoDB 三部分平台扩展包含哪些内容

MongoDB 正将数据库性能、弹性容量和智能体运营整合为同一架构的组成部分。

第一部分是 MongoDB 9.0，该版本随公告正式全面推出。它为 Atlas、Enterprise Advanced 和 Community Edition 提供底层支持，因此这些性能变化不仅与 MongoDB 的托管云服务相关。

MongoDB 表示，在大型实例上，9.0 版本的吞吐量最高可达 MongoDB 8.0 的两倍。该公司还称，find-one 查询速度最高提升 35%，而 update-one 查询最高提升 30%。

事务型工作负载则获得了另一项宣称最高可提升 20% 吞吐量的改进。这些数据来自 MongoDB 对 8.0 版本的内部比较，因此买家应将其视为厂商基准测试结果。

该公司的性能公告还介绍了原始速度之外的变化。MongoDB 9.0 扩展了 Queryable Encryption，使应用程序无需先向数据库暴露明文值，即可搜索受保护字段。

扩展后的系统支持对加密信息进行前缀、后缀和子字符串搜索。这项能力面向涉及姓名、标识符或其他敏感文本的工作负载，而应用程序仍需要定位这些信息。

MongoDB 还新增了 Intelligent Workload Management。该功能旨在当集群接收到超出其常规处理能力的工作量时，保障短时操作的正常运行。

这很重要，因为一个智能体可能产生远多于传统用户交互的数据库活动。一次请求可能会带来规划步骤、检索调用、工具执行、写入操作，以及对当前状态的反复检查。

MongoDB 表示，单个智能体即可产生数百次操作。因此，数千个并发活跃的智能体会形成与普通应用请求明显不同的流量模式。

第二部分是 Atlas Infinite，这是一项处于公开预览阶段的新 Atlas 部署选项。它将存储与计算分离，使客户能够独立扩展每种资源。

Atlas Infinite 首先在 AWS 上推出。MongoDB 计划在该服务正式全面推出后扩展至更多云平台，但尚未提供最终日期。

在新的命名体系下，现有 Atlas 部署将称为 Atlas Core。客户可根据工作负载特征使用 Atlas Core、Atlas Infinite，或同时使用两者。

第三部分是同样以公开预览形式推出的 MongoDB Atlas Agent Engine。它提供记忆、检索、托管运行时、智能体身份、追踪、评估和策略控制。

MongoDB 表示，Agent Engine 保持对不同模型、框架和云平台的开放。这一定位很重要，因为企业很少希望其运营数据战略永久绑定于某一家模型供应商。

这些发布共同构成了真正的新闻。MongoDB 不再将 AI 检索定位为数据库的附属功能，而是试图让 Atlas 成为生产级智能体之下的运行层。

MongoDB 9.0 性能瞄准智能体活动的隐性成本

MongoDB 9.0 的性能改进针对每一次可见的智能体请求背后不断倍增的数据库工作量。

传统应用通常将一次用户操作映射为一系列有限且可预测的数据库操作。智能体软件则可能将一条指令转化为不断变化的读取、写入、搜索和工具调用链。

以评估退款的客户服务智能体为例。它可能需要检索客户记录、查看近期交易、核实配送状态、查阅政策文件，并写入已批准的操作。

每个步骤都可能产生额外的推理和检索。工具调用失败可能触发再次尝试，而证据不明确则可能让智能体转向另一条路径。

这会给数据层带来两方面压力：一是增加总操作量，二是使这些操作的发生时机更难预测。

MongoDB 9.0 所宣称的性能提升瞄准了第一种压力。更快的点读取可帮助智能体检索实时账户或库存记录，更快的更新则有助于其记录决策和结果。

当智能体操作必须在关联记录之间保持一致时，更高的事务吞吐量同样重要。支付、预订或权益变更不能安全地依赖过时或仅部分更新的状态。

MongoDB 的观点是，模型质量无法弥补运营上下文的滞后。模型可能基于收到的信息做出了正确推理，却仍会因信息已经过时而采取错误行动。

库存智能体就是一个直接的例子。如果它看到的是昨日的库存水平，便可能承诺提供一件实际上已无货的产品。

金融智能体带来的后果更为严重。过期余额、失效权限或缺失交易记录，都可能将看似合理的建议变成未经授权的操作。

这正是 MongoDB 强调访问实时运营记录，而不是定期副本的原因。将数据复制到独立检索平台可能引入延迟、额外的安全边界，以及另一个需要协调的系统。

该公司的平台概览将数据新鲜度视为能够执行操作的智能体的必要条件，而不仅是回答问题的要求。它也将检索与事务数据并列，而非将其视为独立的管道。

这一方法建立在 MongoDB 既有的搜索策略之上。Atlas 已将文档存储与文本搜索、向量搜索相结合；向量搜索通过语义意义的数学表示来查找记录。

MongoDB 在 2025 年收购 Voyage AI 后增加了更多检索技术。其嵌入模型将内容转换为向量，重排序模型则根据相关性重新排列候选结果。

该公司随后正式全面推出了嵌入与重排序服务。其检索 API让应用程序可在 Atlas 内部托管访问这些模型。

这些组件让 MongoDB 得以主张，智能体能够从同一平台同时获得最新的结构化记录和相关的非结构化上下文。更少的数据副本，意味着信息出现不一致的机会也更少。

不过，接近数据并不能保证准确性。检索质量取决于文档准备、索引、嵌入选择、过滤器、访问控制和评估方法。

MongoDB 9.0 的性能声明同样需要针对具体工作负载进行测试。点查询的提升并不会自动在以向量搜索或长时间聚合为主的应用中产生同等收益。

这些公布的数字仍具有参考价值，因为它们显示了 MongoDB 认为压力正在形成的位置。智能体的普及使数据库效率成为 AI 运营成本的一部分，而不再只是后台基础设施问题。

Atlas Infinite 扩展以弹性取代容量规划

Atlas Infinite 通过将计算扩展与存储扩展分离，应对不可预测的需求。

传统数据库集群通常将存储和计算决策绑定在一起。需要更多处理能力的团队，最终可能配置了其数据量实际上并不需要的资源。

反向问题同样存在。不断增长的数据集即使常规计算需求保持稳定，也可能迫使基础设施发生变化。

Atlas Infinite 将这些维度分离。MongoDB 表示，该架构可从原型扩展至 PB 级部署，无需客户在每个增长阶段重新设计应用程序。

该公司称，Atlas Infinite 将扩展时间缩短逾 96%。它还表示，每个分片可容纳的存储量达到此前的十倍。

分片是分布在基础设施上的大型数据库分区。提升每个分片可用的存储量，可以减少团队对不断增长的数据集进行重新分区的频率。

MongoDB 表示，Atlas Infinite 与 Atlas Core 使用相同的驱动程序、API、工具、控制措施和安全态势。因此，客户在符合条件的工作负载之间切换部署选项时，不应需要修改应用程序代码。

这种兼容性是该方案的核心部分。如果团队在使用弹性基础设施前必须重写数据访问逻辑，其吸引力就会大幅下降。

公告包含早期客户成果，但相关数据由 MongoDB 和参与客户提供。据称，巴西金融科技公司 PicPay 在两小时内承受了正常峰值流量四倍的负载，且未发生故障。

据称，Icon Solutions 在 Atlas Infinite 上每秒处理的交易量最高增加了 55%。MongoDB 还表示，其内部测试显示，Atlas Infinite 每单位支出的吞吐量比 Atlas Core 高 189%。

这些结果说明了预期的工作负载类型。身份验证激增、交易峰值、病毒式传播的产品发布，以及活跃智能体集群，都可能造成短时的高强度需求。

它们不应被解读为普遍结果。应用设计、查询模式、区域配置、索引、数据分布以及预览阶段的限制，都可能显著影响性能。

公开预览状态带来了另一层边界。与正式全面推出的产品相比，预览服务通常可用范围更窄、运营保障仍在演变，且集成能力不完整。

Atlas Infinite 初期仅在 AWS 上运行。已标准化采用其他云平台的组织尚无法在其首选环境中测试该服务。

这种按量消费模式也只是转移运营责任，而非将其消除。快速扩展能够保护响应能力，但失控的智能体循环仍可能造成不必要的使用量。

当一次用户请求产生数百次下游操作时，这一风险会变得更加重要。弹性容量可以容纳失控活动，同时让其资源消耗持续增长。

团队需要在数据库层之上设置限制，包括请求预算、工具调用限制、执行超时、并发控制，以及针对异常智能体行为的告警。

Atlas Infinite 因此解决的是一个比无约束自主性更狭窄的问题。它旨在当合理需求突然变化时提供容量，而不是决定每一次代理操作是否都应执行。

这一差异对买家至关重要。更快的扩缩容可避免基础设施规划成为眼前的瓶颈，但应用治理仍决定相关工作是否恰当。

MongoDB 更大的平台主张取决于能否谨慎地整合这些职责。Infinite 负责应对变化的容量需求，而 Agent Engine 则应负责治理产生这些需求的执行主体。

MongoDB Atlas Agent Engine 挑战拼装式代理技术栈

MongoDB Atlas Agent Engine 让这家数据库供应商成为代理运行时与控制基础设施的提供商。

Agent Engine 将多项功能引入 Atlas。记忆功能可在交互之间保留有用信息，而检索功能则选择与当前任务相关的上下文。

运行时负责执行代理工作负载。身份管理控制谁或什么正在执行操作，治理功能则将策略应用于这些操作。

追踪功能记录执行过程中发生的事项。评估功能帮助团队判断代理是否在既定测试用例中产生了可接受的结果。

MongoDB 并未将这些能力定位为新的基础模型。该产品瞄准的反而是模型周边的基础设施：生产系统必须在这里保存状态并控制访问权限。

这一区别解释了“有状态代理”这一说法。一个实用的企业代理必须记住先前活动、理解当前权限、检索相关证据，并记录其工作带来的后果。

无状态聊天机器人可以根据相互独立的提示生成每一条回答。运营型代理则需要连续性，因为一次操作可能影响下一步中哪些行为仍然有效。

MongoDB 首选的架构是让这类状态靠近运营数据。该公司认为，这能够减少集成点、安全边界和重复数据集。

拼装式替代方案让团队能更自由地选择专业组件。一家公司可能将 PostgreSQL、向量数据库、编排框架、外部记忆服务和云运行时组合起来。

这种设计可以最大化组件选择空间，但也可能要求工程师在多个系统之间同步数据、传递权限、观察故障并调查行为。

Agent Engine 试图吸收大量这类协调工作。MongoDB 希望现有 Atlas 客户能够在同一平台上构建代理，而不必创建一套并行的 AI 数据架构。

庞大的客户基础为这一策略增添了分量。MongoDB 表示，其客户超过 70,000 家，逾 75% 的《财富》100 强企业使用其软件。

其 2026 年 9 月的投资者资料称，约 40% 的 Atlas 年度经常性收入来自至少拥有一个已识别 AI 用例的客户。该公司对这一类别的定义较为宽泛。

工作负载只要使用向量搜索、AI 相关驱动程序，或参与 MongoDB AI 项目，便可能符合这一标准。因此，该指标反映的是客户接触 AI 的程度，而非完全由已部署代理产生的收入。

这一差异很重要，因为 MongoDB 仍须将兴趣转化为对 Agent Engine 的持续使用。现有数据库合作关系可以缩短评估周期，但无法消除技术比较的必要性。

AWS 已提供 Bedrock AgentCore，其中包括托管运行时、记忆、身份、网关、工具和可观测性功能。其 AgentCore Runtime支持多种框架，并可与企业身份提供商集成。

Databricks 同样从数据平台角度切入代理市场。其代理框架通过更广泛的 Databricks 环境整合开发、评估、托管服务、监控、搜索和治理。

Google Cloud 则通过 Vertex AI Agent Engine 及相关身份和治理服务提供另一条托管路径。每家竞争对手都可以宣称，其现有平台是企业代理的天然归宿。

MongoDB 的差异化优势在于运营数据库。Databricks 以分析和受治理的企业数据为核心，而超大规模云服务商则将代理连接至其更广泛的云服务。

MongoDB 则认为，代理记忆和控制机制应当位于代理持续读取和修改的应用记录旁边。这可能吸引已将 Atlas 用作记录系统的团队。

ElevenLabs 的案例展示了这一预期模式。MongoDB 表示，这家 AI 音频公司使用 Atlas Search 和 Vector Search 实现长期代理记忆与知识检索。

但客户案例并不能终结这场架构之争。企业通常将运营数据分布在多个数据库、数据仓库、文档系统和软件服务之中。

跨这些系统工作的代理仍需要连接器和统一授权。将其记忆保留在 MongoDB 中，并不会自动简化所有外部边界。

这正是此次发布背后的核心竞争。MongoDB 必须证明，运营数据的引力足以胜过从主力云服务商或分析供应商采购代理基础设施的便利性。

集成式技术栈仍需要独立的生产证据

MongoDB 的统一架构减少了活动部件，但其最新层级仍缺乏广泛的生产证据。

三项已宣布产品中有两项仍处于公开预览阶段。MongoDB 9.0 已正式发布，而 Atlas Infinite 与 MongoDB Atlas Agent Engine 仍是较早期的服务。

这种成熟度差距使评估更加复杂。数据库性能变化可以立即接受生产测试，但新的扩缩容和代理层需要更长时间的观察。

首个不确定性涉及基准测试的可迁移性。MongoDB 公布的性能结果是在内部测试条件下对比 9.0 版和 8.0 版。

真实工作负载很少能与供应商基准完全一致。它们包含不均匀的文档大小、混合操作、自定义索引、网络延迟、区域限制以及应用特定的重试行为。

因此，团队应测量完整任务延迟，而非仅关注数据库操作。代理在等待模型、外部工具或检索管道上花费的时间，可能比点查询更多。

第二个不确定性涉及隔离与治理。将代理记忆置于实时运营数据附近可以提升新鲜度，但也会提高授权错误的后果。

代理需要的不仅是一条有效的数据库连接。它需要按用户、任务、资源、操作和当前上下文收窄的权限。

审计日志必须显示代理访问了什么、调用了哪些工具、哪些数据影响了其决策，以及哪个身份授权了结果。

MongoDB 表示，Agent Engine 提供身份、追踪、评估和策略控制。买家仍需要关于策略粒度、故障行为、保留机制及与现有安全系统集成的详细证据。

第三个不确定性涉及检索新鲜度。原生向量搜索减少了数据移动，但新建或更新的文档未必会在写入的确切时刻变得可搜索。

对于低风险推荐，短暂的索引延迟可能可以接受。但对于库存、认证或财务决策，应用可能需要在行动前针对当前记录进行事务性检查。

合理的设计可以使用语义检索来获取上下文，并使用直接数据库查询来确认权威状态。Agent Engine 需要向开发者明确这一边界。

第四个不确定性是可移植性。MongoDB 表示，该引擎支持任何模型、框架或云环境，这降低了一种形式的依赖。

然而，应用仍可能受制于 MongoDB 特有的记忆结构、追踪格式、策略、部署 API 和检索行为。仅有模型选择自由并不能保证架构可移植性。

第五项关注点是成本控制。MongoDB 声称集成式检索可减少不必要的 token，这一说法具有合理性，因为更好的上下文选择能够缩小模型输入。

不过，更快的数据库和弹性计算也可能让约束不足的代理更容易执行更多工作。团队需要按代理划分的使用量可见性，而不只是集群级别的消耗情况。

这些关注点都不会否定这一策略。它们界定了 MongoDB 在产品走出预览阶段时必须提供的证据。

该公司选择了一个合乎逻辑的集成点。运营数据对代理具有价值，而企业已在应对重复上下文、脱节的权限和碎片化的可观测性方面挣扎。

更困难的问题在于，一个平台能否承担这些职责，同时不成为另一个庞大的控制界面。生产采用将取决于运营细节，而非架构图的吸引力。

三个信号将显示 MongoDB 的代理押注是否奏效

下一项考验是，MongoDB 能否将连贯的平台叙事转化为可重复的生产部署。

第一个信号是 Atlas Infinite 和 Agent Engine 的正式发布。仅有发布日期还不够。

买家应关注多云覆盖、已记录的服务限制、区域可用性、运营保障，以及从预览版迁移的稳定路径。这些细节揭示产品是否能支持受监管和关键任务部署。

对 MongoDB 的中立性主张而言，AWS 以外的支持将尤为重要。一项宣称可跨云开放的产品，需要在这些环境中具备相当的能力和运行行为。

覆盖范围广泛的正式发布将强化 MongoDB 的论点，即这三项产品共同构成一个生产平台。长期或受限的预览则会削弱这一结论。

第二个信号是独立的工作负载证据。客户测试应测量完整代理任务，而不只是数据库吞吐量。

有价值的评估将报告检索新鲜度、任务延迟、故障恢复、策略执行以及突发并发下的资源消耗。它们还应将模型延迟与数据库和运行时行为区分开来。

与拼装式架构进行独立比较将特别有价值。MongoDB 需要证明整合在何时能够提高可靠性，以及专业组件在何时仍具备更好表现。

受监管工作流的证据会带来额外分量。受治理的退款、账户更新或理赔流程所揭示的要求，远比仅生成文本的演示更有意义。

持续一致的生产结果将支持 MongoDB 关于实时数据和代理基础设施应当结合的主张。有限的基准披露会让最重要的论断仍依赖于供应商自身说法。

第三个信号是竞争响应和客户整合。AWS、Google Cloud 和 Databricks 已提供重叠的代理能力，而且各自掌握着不同的企业关系。

应观察现有 Atlas 客户是否采用 Agent Engine 来取代独立的记忆和运行时服务。也应观察新的 AI 应用是否因组合平台而选择 MongoDB，而不是仅将其作为一个组件加入技术栈。

MongoDB 自身的报告可以有所帮助，但对 AI 客户的定义必须更加精确。使用向量搜索并不必然意味着组织正在生产环境中运行自主代理。

未来若有与 Agent Engine 工作负载、活跃生产代理或多产品采用情况挂钩的指标，将提供更有力的证据。它将显示 MongoDB 是否正在获取代理技术栈中更大的一部分，而非仅仅受益于普遍的 AI 实验。

竞争对手的应对同样值得关注。云服务商可以进一步加深其运行时、身份系统、数据库与可观测性服务之间的集成。

数据库竞争对手可以增加托管式记忆或智能体控制功能。独立框架厂商则可以改进可跨多个数据系统运行的可移植治理能力。

MongoDB 已明确其立场：数据库应成为智能体控制平面的一部分。这次发布为这一主张提供了可信的组件，但预览产品和内部基准测试仍不足以证明其可行性。

对开发者而言，当前最直接的行动是在一个边界明确的工作流中测试这一架构。使用实时数据、明确的权限、可衡量的检索任务，以及一种失败场景。

对企业采购方而言，应比较运营边界，而非功能清单。需要询问状态存储在哪里、身份如何贯穿每项操作、索引何时更新，以及如何停止失控的工作负载。

负责管理密集技术证据的团队，也可以维护一个可搜索的工程知识库，用于保存评估结果、事故发现和架构决策。

MongoDB Atlas Agent Engine 值得关注，因为它将智能体操作连接到已进入许多企业内部的数据库。决定性问题在于，这种接近性是否能带来更安全、更简单的生产系统。你的团队将用哪个真实工作流来验证这一主张？