管理 15 万 AI Agent 对数据库团队的挑战与变革

未来的数据库管理员花在建库上的时间会大幅减少。

这听起来有些矛盾，但 AI 代理正在接管这项工作。几十年来，DBA 一直从事着手工式的数据库维护工作——保障数据库可用、性能、安全且经济可承受。他们负责扩容配置、排查慢查询、管理迁移，并在问题不可避免地出现时介入处理。

AI 已经在承担其中部分工作。与此同时，它也在催生规模大得多的数据基础设施集群需要管理。

其结果很可能是 DBA 这一角色将发生根本性转变：不再亲力亲为地照料每一个数据库，而是将更多时间花在监督那些替他们执行这些操作的自主系统上。

恭喜，你现在管的是机器人了

这一转变始于一个熟悉的问题：需要管理的基础设施超过了可用的人力。

数据库自动化并非新鲜事物，但代理有潜力走得比 DBA 已经在用的脚本和规则更远。代理不必将一项任务预设为自动化，而是能够检查正在发生的情况、判断需要关注的问题、使用工具采取行动，并验证其干预是否有效。

这改变了 DBA 与数据库的关系。曾经需要人工翻阅指标、定位问题查询、再决定如何应对的性能问题，现在可以越来越早在代理介入调查后就处理掉，无需人工参与。

但这并没有把 DBA 从等式中移除。仍然需要有人决定代理可以做什么、在哪里需要人工审批、以及代理出错时该如何处理。只不过工作上移了一层——DBA 不再亲自执行每一项运维任务，而是开始管理执行这些任务的系统。

在任何人过于安于这一想法之前，这些系统的数量可能会变得极其庞大。

15 万个代理走进一个数据库……

Gartner 预测，到 2028 年，全球财富 500 强企业平均将使用超过 15 万个 AI 代理，而 2025 年还不足 15 个。目前仅有 13% 的组织认为已建立了正确的治理体系来管理这些代理。

并非每个代理都需要自己的数据库，但相当多的代理会需要。它们会创建状态、检索数据、记住之前的交互、并与其他代理交换信息。许多代理的行为也与 DBA 习惯支持的应用截然不同：快速启动、长时间空闲、在有工作时突然变得繁忙。

没有人会雇佣 15 万个 DBA 来管理它们。

这正是 Yugabyte 借助 YugabyteDB AMP（Agentic Multitenant PostgreSQL，代理式多租户 PostgreSQL）所要解决的规模问题。AMP 不是将每个新的代理工作负载视为又一个需要管理员配置和看护的数据库，而是将数据库作为集群来管理。

该平台将数百个小型的 Postgres 工作负载打包到共享的分布式基础设施上，同时保持其数据库隔离。生命周期操作（包括配置、分支、扩容、迁移和拆除）可以通过 MCP 暴露给代理。Yugabyte 还为配置、迁移、性能调优和集成构建了专门的代理。

在这个模型中，DBA 不再是去配置第 14,372 号数据库。有意思的工作变成了设置规则——让第 14,372 号数据库在无需人工参与的情况下被配置、运行和调优。

用更少资源做更多事（这次是认真的）

规模只是问题的一半。总得有人为这一切买单。

代理工作负载使得传统的容量规划变得尤为别扭，因为许多代理是突发性的且经常处于空闲状态。给每个实验性代理永久配置基础设施，可能导致公司为许多大部分时间都在做很少事情的数据库付费。

这就是为什么 consolidation 既是运维问题，也是经济问题。

AMP 的方案是 serverless multitenancy 和 scale-to-zero。多个小型工作负载共享底层分布式基础设施，而客户按 CPU 分钟计费，空闲代理不消耗计算资源。资源治理可以对单个工作负载施加 CPU 限制，防止一个过于积极的代理耗尽分配给其他邻居的资源。

人的因素同样重要。如果常规的配置、迁移、调优和其他数据库操作可以越来越多地委托出去，那么更小的数据库团队可能就能够维护大得多的数据资产。

这并不意味着公司可以解雇 DBA、把钥匙交给机器人。这意味着宝贵的数据库专业知识可以花在架构、治理和真正困难的问题上，而不是反复做那些软件就能搞定的工作。

你 2028 年的数据库问题从现在开始

更难的问题是：当没有人真正知道两年后企业 AI 资产会是什么样子时，该在此基础上构建什么。

今天作为实验开始的代理可能在下个月就消失了。另一个代理可能突然成为整个业务使用的生产应用。为廉价实验和严肃工作负载分别构建基础设施栈，每次实验成功时都可能会制造出迁移问题。

Yugabyte 赌的是这段旅程的两端应该坐在同一个基础上。

YugabyteDB AMP 允许工作负载从 serverless Postgres 起步，随着规模和关键性提升过渡到完全分布式的 YugabyteDB，无需重写应用或将数据迁移到不同的数据库平台。

然后还有单个数据库之上的问题：代理需要记住发生了什么，而且不是局限在孤岛上。

这正是 Meko 在 Yugabyte 堆栈中的用武之地。Meko 是一个面向多代理 AI 系统的代理原生上下文引擎。它提供持久化记忆、共享知识、决策追踪和跨多代理的可审计性，而不是让每个代理从自己孤立的上下文中工作。一个代理可以获取另一个代理学到的信息，而无需重新检索或重新启动推理过程。

综合来看，这为代理的整个生命周期提供了单一数据栈：Meko 处理代理间共享的上下文，YugabyteDB AMP 以代理方式管理 Postgres 数据库集群，分布式 Postgres 兼容的 YugabyteDB 承载那些超越了 serverless 起步阶段的工作负载。

当然，不能保证 2028 年一定会与今天的预测完全一致。这恰恰是重点所在。最安全的架构赌注可能是：无需提前知道今天哪些小型 AI 实验会成为明天关键应用的架构。

在这个世界里，DBA 仍然至关重要，但工作形态会有所不同。未来的 DBA 可能直接管理的数据库会更少，同时承担责任的数据库却会多得多。他们转而管理执行管理工作的自主系统。