大模型应用正在从 Chatbot 走向 Agent。Chatbot 的主要工作是理解问题、检索信息并生成答案；Agent 则会进一步拆解任务、调用工具、读取数据、执行操作、验证结果，并根据执行反馈不断调整策略。这意味着，数据库在 Agent 系统中的角色也发生了变化。

过去，数据库主要负责保存业务数据和最终结果；现在，它还需要承载 Agent 的任务状态、中间数据、实验结果和执行过程，甚至成为 Agent 直接开展工作的空间。

1、当 Agent 需要直接修改数据库

越来越多的场景需要让 Agent 直接访问甚至是修改数据库：我们需要 Coding Agent 不只写代码，还要在真实数据形态上验证数据及 Schema 变更；需要客服或订单 Agent 自动完成订单的创建及状态的修改；需要数据分析 Agent 在真实的业务数据上，进行复杂的多轮迭代分析等。今天真正在落地的 Agentic 场景，几乎都需要 AI 直接动手改数据——它可能是对的，但它一定也会犯错。矛盾就摆在这里：AI需要一个能放开手脚试错的地方，而生产数据恰恰是最不能试错的东西。

举个更具体的场景：一个游戏团队希望让多个 Agent 基于真实的业务数据，验证不同的运营策略。需要这些 Agent 在一份和线上一模一样的真实业务数据上，把自己的策略真的写进去、模拟跑一遍，看留存和付费到底怎么变，好就采纳、不好就整个扔掉，并且它们谁都不能真的修改生产数据。

2、我们真正需要什么？为什么传统方案给不了

我们期望的状态，其实很清晰：每个 Agent 都有一份属于自己的数据空间，它看到的是完整、真实、和生产一致的数据；它可以自由读写、随便折腾；它的写操作对生产和其他 Agent 都不可见；用完了直接扔掉，不留任何清理债务。多个 Agent 同时开工，各干各的，谁也不影响谁。在传统的数据库中有几个可能的选项：

• 备份恢复新实例：给每个 Agent，通过备份还原生成一个独立的实例。这种方式有有一系列的问题，生成慢：备份的拷贝及日志的重放会消耗大量的时间，Agent 只能等待；运维重：起实例、配网络、配账号等繁重的运维工作；高成本：每个实例都拥有一份独立的实例和数据带来大量的成本。
• 当前实例 Copy 库表：这种方式虽然消除了独立实例的运维和使用成本，但由于需要数据完整拷贝，仍然会很慢，会占用成倍的空间。同时 Copy 大表会在短时间占用大量的 IO，可能影响实际业务。

随着数据量上升以及 Agent 数量的增加，这些方案的劣势会达到无法承受。可以看出，AI真正需要的是易用、快速创建、低成本、可随用随弃的沙箱。

3、PolarDB Branch 是怎么解决的

PolarDB Branch 给出的答案是：在当前实例，用一条SQL语句，秒级创建，不额外占用空间，可以随时丢地的独立空间。

首先，在当前实例，通过CREATE BRANCH语句派生一个或多个分支，不管源库多大都可以秒级完成，每个分支在创建时不做数据拷贝，不占用额外的空间，只会随着后期的修改按需的分离属于自己分支的数据。

CREATE BRANCH agent_a;                      -- 派生一个包含当前所有库的分支
CREATE BRANCH agent_b WITH DATABASE orders; -- 或只 fork 指定的库

然后，不同的Agent通过SET branch切进自己的分支，无需新建连接、切换端点、更换账号。接下来所有 SQL 都自动作用在分支上，库名表名一切照旧，应用完全无感知:

SET branch = 'agent_a';

USE app_db;
UPDATE users SET status = 'test' WHERE id < 100;  -- 只影响 agent_a 分支
ALTER TABLE orders ADD COLUMN risk_score INT;     -- DDL 也只影响 agent_a

最后，用完后一条命令清干净：

DROP BRANCH agent_a;

下面幅图能最直观地说明 Branch 的用户体感，同一个实例内，不同目标的Agent各自基于自己的视角，看到的是各自独立的数据形态：

回到上面的游戏运营策略分析 Agent 场景，使用 Branch，多个 Agent 各建一个分支，秒级就绪，底层通过写时复制共享同一份真实玩家数据，这些分支一开始几乎不占额外空间，只有各自写进去的活动配置、分群、模拟发放才落到自己名下。不同策略在不同分支上真正并行跑，写操作彼此隔离、对生产完全不可见。跑完对比留存和付费曲线，选出最优策略，之后分支直接删掉，不留任何清理债务。

算一笔实在的账。假设你的 AI Agent 平台有 50 个并发 Agent，每个都需要基于生产库（假设 1TB）开一个自己的沙箱。传统方案和 Branch 的差距是数量级的：

4、PolarDB Branch 是怎么实现的

PolarDB Branch 能做到“秒级+独立+零侵入”，靠的其实是一个很朴素的思路：按需而不是立即拷贝数据。在实现上，PolarDB Branch 可以划分成不同设计目标的三层：

1、命名空间层：换个名字，不换代码。SET branch = 'agent_a' 之后，逻辑库名会被映射成分支对应的物理库名。这样库名表名对应用完全照旧，应用 SQL 一个字都不用改。CREATE BRANCH 本质上就是对目标库里的一批表，做一次时间点一致的批量派生。

2、数据层：共享，写时复制(COW)。 分支创建时不真的拷贝任何数据，分支和源库共享同一份物理存储。所以派生是秒级的，初始几乎不占额外空间，读没写过的数据直接走源库共享的那一份，写的时候才在改动前复制出自己的副本。

3、版本存储层：独立维护，对源库零侵入。分支的历史数据由一个独立的 PVS(Page Version Store)存储引擎管理。源库要配合做的只有一件事，在某一页被改动之前，顺手把它的旧版本交出去，除此之外照常读写。复杂牢牢收敛在缓冲池与 IO 路径这一小块，不扩散到事务、DDL、复制等其他子系统。

5、Fork：把底层能力单独开放给你

对于不需要 Branch 抽象，类似于 Create Table Like 的对库表的快速拷贝的场景，也可以直接使用 PolarDB Branch 的下层 COW 能力，秒级完成数据库库表的拷贝。我们提供了可以针对某张库表的 Fork 语句。

-- Fork表
CREATE TABLE t1_dev FORK FROM TABLE t1;

-- Fork库
CREATE DATABASE app_dev FORK FROM DATABASE app;

从用户视角看，这条语句返回后t1_dev表和app_dev库即可独立读写，与普通库/表无异。

6、写在最后

当 AI 开始真正动手操作这个世界时，我们不得不把他推到生产数据面前，要么用只读权限绑住他的手脚，要么放开他，然后为每一次幻觉提心吊胆。试错的自由与生产的安全，不该再是一道单选题。而让智能既大胆、又安全地生长，正是 PolarDB Branch 想为这个时代铺下的那块基石。