据作者现场录音整理，按讲者脉络转述，不是逐字稿。其中前半段（开场故事到 trace 规模）和中间约一分钟的分支比较部分据现场外部录音补全，未与本人录音对照。讲者是 TiDB 的 AI 产品负责人，中文演讲，讲完直接换场，没听到问答。

一句话

全场顺着一个用户请求往下走：agent 中断后要能接上进度，sandbox 回收后文件要还在，交付的应用要有自己长期在线的数据库，上线后要能分析效果和成本。每一步都把数据库推出一项新职责。她说没人一开始就计划建这么多 AI 基础设施，是用户需求推出来的，TiDB 想做的是让团队少维护基础设施，把注意力留给 agent 的下一次迭代。

论断

1. 一句用户请求背后的几项承诺

开场的请求是：把这些资料做成一个评审工作台，明天团队一起用，后面还要改。她拆出的承诺是：用户不会一直守在电脑旁，agent 要自己把事情推下去；同事明天会接手；代码和资料得在；工作台要上线并持续服务。

“这句话里面其实已经包含了非常重的承诺”

  • 她说这是 TiDB 作为一家数据库公司被 AI agent 公司一步步推着做出一套 agent data infra 的故事。客户包括线上和线下的 agent 公司，没点名。

2. agent 中断后要接上进度，量上来就撞上分片

进度靠 session snapshot 和 session event 两张表。snapshot 存每个 agent 的上下文、计划和工具调用痕迹；event 记录执行过程中的全部信息，逐步叠加，后面再汇入 trace 分析。每次用户操作用一个事务更新 snapshot、插入 event。

  • snapshot 单条 40–80KB 很常见；meta 总量从几 TB 到几百 TB 甚至 PB。
  • 她说评估 agent 数据层不能只看有多少用户，还要看每个用户让 agent 做多少事、历史留多久。
  • 某客户此前有 20 多个 DB，分片路由和跨库协调很复杂，应用里管数据分布的代码也在增长。改用 TiDB 后，统一 SQL 入口，数据分布和分布式事务由 TiDB 处理，agent 中断后能从元数据快速拉起。
  • 这些数字都没给比较对象，也没说是哪家客户。

3. sandbox 删了，项目文件要还在

agent 在 sandbox 里写代码，sandbox 挂 EBS；任务结束回收 sandbox 时，清理策略把 EBS 一起删了。靠备份恢复又很繁琐：要协调写入、创建快照、登记，恢复时找对快照、建卷挂载、把文件和 meta 对齐。

“那所以说为了省算力我们所有的用户的工作都删了吗。”

  • 她说平台真正想要的是能跨 sandbox 的持久存储层。TiDB 提供了一个文件系统，工作区独立于 sandbox：session A 写完可以释放 sandbox，session B 用同一份文件接着做。
  • 一个 project 一个独立空间，按最小权限鉴权，按 project 配 quota，她说能扩展到数百万、数千万（指什么的数量没说清）。
  • 她让大家记住一句话：“sandbox 删了但我们的项目依然可以保存”。

4. 代码生成越快，越需要跟得上的数据库服务

建站类 agent 平台交付的每个应用都要一个长期在线的数据库。用户几十万到上千万，每人平均建 1 到 2 个甚至 10 个应用，建库超时后不知道建没建成，重试会不会重建一份，回收会不会漏掉资源，都成了平台的事。

“所以我们代码生成越快我们平台越需要一套能够跟上交付速度的数据库的服务方式。”

  • TiDB 提供上千万个隔离的数据库，共享底层存储；平台只需建库并关联到应用，权限、用量和计算资源调度由 TiDB Cloud 处理。收尾时她对应的产品是 TiDB Cloud Starter。
  • 数字没给比较对象，也没说是哪家客户的实际情况。

5. 一条 trace 查清一次运行，一批 trace 才能定方向

应用上线后要说清 agent 效果怎么样、每个工具表现如何。客户常见的做法是把长任务拆成可关联、可查询的模型调用、工具调用和返回，再用运行标识把耗时、模型用量、业务验收和花费串起来。只看任务成败解释不了成本花在哪，agent 可能一直在重试。

“一条trace能够帮助我们查找一次查清楚一次运行但是只有我们要一批trace才能帮助去团队决定我们后面的优化方向”

  • 单条 trace 可到上百 MB、十万级步骤，单次任务两三个小时到十几小时；平台每天写入数百 TB 很常见。都没给比较对象。
  • 分析时按工具、按任务类型看重试、耗时、调用量，关联验收结果算成功率和含失败重试的单位成本，再筛代表任务做评测样本。
  • 她提醒调用多不等于有用，可能恰恰是效果不好被反复调用。

“某个工具调用多，不代表它的价值更高”

6. trace 量上来后，难点是持续查和算

“我们的最核心的关键就变成了我们整个数据的运维和我们持续查和算的能力。”

  • 原始 trace（JSON）持续加载，用 SQL 展开 JSON 做客户需要的检索和聚合，存在 TiDB Cloud 的 Lake 产品上，落对象存储。
  • 下面分两条链路：一条排障时快速定位 agent 运行到哪一步；一条做批量的质量和成本统计，并按负载量配计算。

7. 判断改动是否变好，要从同一个现场开分支

换了模型或工具后，如果每次都重新跑，工具输出和文件会变，结果差异分不清来自策略还是现场变化。要保留共同的起点：当时的 meta、文件、必要的输入配置，再创建独立分支，用同一个标准评估。

“然后 trace 它只能告诉我们，发生过什么”

  • 例子：从同一个 checkpoint 出发，一个分支连续调用工具，另一个分支调整工具选择策略，两个分支独立写入，最后比较正确性和总耗时。
  • 单个任务变好不代表整个 agent 变好。客户的做法是先验证代表任务，再看收益能否覆盖同类任务，再回归原本能成功的任务，并做重复实验处理模型的随机性；质量、成本、延迟的整体变化过了评测机制才上线。
  • 她把这个流程叫闭环：历史 case 发现问题，放回保存的现场，运行新做法，产生新的验证证据，再进入分析。

8. meta、event 和文件 checkpoint 绑在一起

客户把 TiDB 里的 meta 快照、event 和文件系统的 checkpoint 绑定。要恢复 agent 的某个历史状态时，用 checkpoint 和 event 恢复状态，再从文件系统取出当时的文件。

“可以从文件系统里面去获取出来一个当时一模一样的文件的内容”

  • 她给 agent 的数据层分了三块：lake 管分析，meta 管状态，file system 管文件。
  • 回到开场：用户第二天回来说要接着改昨天的工作台，meta 让记录接得上，文件系统让项目也接得上。

9. 没人计划，是用户需求推出来的

收尾她把四类增长和产品对上：meta 增长用分布式 SQL 和事务减少分片；项目增长用海量持久工作区；应用增长用 TiDB Cloud Starter 提供海量独立数据服务；tracing 增长用 Lake 做处理、清洗、检索、聚合。

“我们认为 AI 时代我们创业者的注意力是非常稀缺的”

  • 她说希望团队更少维护基础设施和支撑系统，把精力放在业务交付和 AI 迭代上。

存疑

  • trace 历史数据规模她说的是"从数百 TB 到数十 TB"，方向不清，可能是增长也可能指压缩，需回放。
  • 她说应用数据库这段是"三个生命周期"中的一段，但前后顺下来有进度、文件、应用数据库、trace 四段，“三个"指哪三个不清。
  • 两分支比较的指标里，除正确性和总耗时外还有一项（疑为关键路径耗时）没听清。