Agent 正在越来越多地直接访问数据库，它会发起多少查询、生成多复杂的 SQL、是否并发执行或反复重试，往往要到任务运行时才确定，计算资源消耗可能在短时间内大幅变化。负载突然放大时，线上业务或其他 Agent 的计算资源可能被挤占，进而出现查询变慢、超时或不必要的资源弹升；多个 Agent 同时修改一批数据和对象，还可能引发 Schema 冲突和测试数据混用，让任务失败或结果不可信。
阿里云瑶池旗下的云原生数据库 PolarDB 提供 Resource Control 和多租户能力，让 Agent 直接操作数据库时，可以按需要建立计算资源边界或独立数据工作区，减少资源争抢和数据、对象之间的相互干扰。
图 1：Agent 直接操作数据库时的风险与能力总览
当多个 Agent 共享业务库、开发库或测试库时，可以通过 Resource Control 按 User 或 Database 设置计算资源边界；当不同 Agent 需要独立修改 Schema、写入测试数据或创建中间对象时，则可以通过多租户提供独立的数据库和用户命名空间，并分别配置计算资源。
一、共享数据：Resource Control 控制计算资源
在多个 Agent 需要共享同一套数据和数据库对象的场景中，可以使用 Resource Control 为不同 Agent 或任务设置计算资源边界，无需改变现有账号、数据库和对象空间。
Agent 发起的查询数量、复杂度和并发度往往要到运行时才确定，单次全表扫描或复杂 JOIN 就可能突然占满计算资源。PolarDB 可以按 User、Database 等维度限制请求可使用的 CPU，并将请求调度到相应线程组，平台也可根据实际负载动态调整额度。
Resource Control 客户实践
以某电商 SaaS 服务商为例，其自研 Agent 平台承载客服、导购和数据分析等智能体，为数万商家提供服务。平台为不同租户分配独立数据库和账号，并通过 Resource Control 按 1C/2C 精确设置 CPU 配额，避免单个 Agent 的高负载查询影响其他租户；相关资源的创建、绑定、解绑和回收均通过 OpenAPI 自动完成，从而以一套集群规模化承载海量 Agent 租户，无需按租户单独创建实例。
图 2：Resource Control 如何为多个并行 Agent 限制计算资源
使用 Resource Control 功能可以在多个场景下避免 Agent 异常请求或负载带来的影响。
第一，Resource Control 为 Agent 请求建立可预期的安全边界。为 Agent 专用 User 或承载 Agent 请求的 Database 设置 max_cpu 后，无论 Agent 临时生成多少 SQL、并发执行多少查询，计算资源消耗都会被控制在设定范围内，线上业务可以保留稳定余量。
第二，发现正在运行的重查询后，可以通过更细的规则及时收紧计算资源，而不必直接 KILL。查询会降速执行，既减小对线上业务的影响，也避免长事务回滚带来的额外压力。
第三，Resource Control 还可以保护 Serverless 场景下的资源预算。异常的 Agent 查询如果持续拉高负载，可能触发不必要的 PCU 弹升。
二、独立工作区：多租户隔离数据与资源
当 Coding Agent、测试 Agent 和数据 Agent 并行修改 Schema、写入测试数据或创建中间表时，仅分配不同账号仍无法避免对象和数据相互干扰。PolarDB 多租户在集群和数据库之间增加 tenant 层，为每个 Agent 提供独立工作区：
集群 → tenant → 数据库 / 用户
实例原有的数据库和用户位于系统 tenant，Agent 工作区可放入普通 tenant。每个普通 tenant 拥有独立的数据库和用户命名空间，即使使用相同的库名、用户名或表名，也会被识别为不同对象，彼此不能直接访问。
图 3：多个 Agent 在同一实例中的独立 tenant 工作区
平台可以按项目、开发分支或测试任务创建 tenant，准备数据库、用户和资源配置，并将连接信息交给 Agent；通过 resource_config 为各 tenant 设置 CPU 边界，避免一个工作区挤占其他工作区。任务结束后，可沿 tenant 整体回收数据库、账号和表，无需逐项核对对象归属。
Agent 场景下多租户使用示例
例如，团队需要并行验证某个功能的两种实现方案时，平台可以为两个 Coding Agent 分别创建 tenant，并准备相同的数据库结构、账号和基线数据。两个 Agent 可在各自工作区创建同名表、修改 Schema、写入测试数据，彼此不受影响；完成后再对性能、正确性和实现成本进行比较，选择更合适的方案。未采用的工作区可随 tenant 整体回收，无需逐项清理临时表和账号。
图 4：tenant 资源配置如何进入线程池
多租户不会为每个 Agent 启动一套完整数据库。计算和存储仍由同一个实例承载，隔离主要发生在数据库与用户命名空间，以及线程池的 CPU 调度上。对于频繁创建和回收环境的 Agent 平台，这比每个任务单独准备数据库实例更轻，也比仅仅靠账号和命名约定更清晰。
三、面向 Agentic Database
Resource Control 和多租户解决的是 Agent 直接操作数据库后出现的两类问题：一类是动态负载带来的计算资源争抢，另一类是并行任务对数据和对象的相互干扰。
在多个 Agent 需要共享同一个业务库、开发库或测试库的场景中，Resource Control 可以按 User 或 Database 设置计算资源边界，让 Agent 保持对同一套数据和对象的访问，同时避免某个 Agent 的突发负载挤占线上业务或其他任务的资源。它解决的是共享数据库场景下的资源可控问题。
在多个 Agent 需要并行开发、测试或验证不同实现，并且会分别修改 Schema、写入测试数据的场景中，多租户可以为每个 Agent 准备独立工作区。不同 tenant 可以使用同名数据库、用户和表，并分别配置计算资源，既避免数据和对象互相覆盖，也便于任务结束后整体回收。它解决的是并行任务之间的数据、对象和生命周期隔离问题。
进入 Agentic 时代，数据库面对的请求将更加动态、并行和短生命周期。PolarDB 将持续向「Agentic Database」方向演进，让数据库不仅能够被 Agent 直接使用，也能够更好地承接 Agent 产生的负载、数据工作区和自动化管理需求。
👇点击查看「PolarDB Agentic Database」系列文章：
