先说本周圈里两件对着干的事。
8月15日，有人问唐刘——PingCAP一号员工、现任TiDB首席AI官——TiDB内部在用什么Multi-Agent系统。他的回答很不"政治正确"：其实我们在刻意避免Multi-Agent，能一个Agent干完的，就一个Agent干；实在要拆，最多上面放一个Coordinator，下面几个边界非常清楚的Agent。微博理由很"数据库人"：分布式系统做久了，对多组件协作有PTSD——Agent一多，通信来了、状态来了、retry来了、context丢了，最后还不知道到底谁背锅。他还引用了Anthropic的经验：很多团队花几个月搭复杂Multi-Agent，最后发现把单个Agent的prompt和tools做好，效果差不多，而Multi-Agent通常要付出大约成倍的token代价。
五天后的8月20日，TiDB社区北京站线下活动，舞台上是另一番景象：Kimi的工程师田鹏飞首次公开，他们的AI业务里跑着海量独立Agent，衍生出百万级轻量"租户"，每个租户背后都是一个生命周期极短、流量完全不可预测的小数据库。团队把SQLite和各种Postgres部署方案都比了一遍，最后选了TiDB。知乎
一边说Multi-Agent能不用就不用，一边把数据库的未来押在Agent身上。看懂这个"矛盾"，基本就看懂了TiDB这个夏天的全部动作。
线一：AI管数据库，知乎把巡检干掉了80%
先说"AI替DBA干活"这条线，最完整的一手案例是知乎。
知乎从2019年开始用TiDB，现在的盘子是：60多套集群、500多个数据库、高峰时上千台服务器，已用存储接近600TB；最大的单集群200多个TiKV节点、100多个TiDB server节点，差不多400个节点扛着近500TB数据。知乎集群数量还在线性增长，靠堆人运维这条路已经走不通了。
知乎的解法分三步，顺序很讲究：
第一步标准化。全面跑在TiDB Operator上，用K8s管集群，做到5分钟一键部署、在线弹性扩缩容、零感知滚动升级，故障自愈压到5分钟以内。知乎
第二步平台化。自建数据库运维平台，把部署、扩缩容、升级、备份恢复、监控告警全部收敛成一套集中的OpenAPI。知乎这一步的价值是：运维经验不再锁在某个DBA的历史命令里，新人能调，AI也能调。
第三步才是智能化。在API底座上叠Claude大模型加自研Skill技能库，自动生成查询、变更、监控巡检三类运维能力，每天自动跑集群巡检，DBA巡检耗时降了80%，还能用自然语言直接下发扩容、SQL查杀、数据备份。知乎知乎数据库架构负责人代晓磊现在的日常，是早上在大模型平台里敲一句"昨天有没有活跃的TiDB报警？Top 10慢SQL列一下"，AI几秒就把结果推回来。知乎
这里要泼一句冷水：很多人只看到"AI当DBA"想抄最后一步，但如果运维动作还散落在各个终端和YAML文件里，AI根本没有介入点。先标准化、再平台化、最后智能化，前两步才是这道题的真正门槛。
线二：数据库喂AI，Kimi的百万租户只是开始
另一条线是反过来的：不是AI服务数据库，而是数据库服务AI。
Kimi这个案例之所以值得细看，是因为它点破了一类新需求：AI原生应用的存储不是"一个大库越用越大"，而是"百万个小库生生死死"。Agent会批量产生轻量租户，流量没有规律，库的生命周期可能以天甚至小时计。传统选项都有硬伤——SQLite单文件模型扛不住并发和租户隔离；给每个租户开独立Postgres成本失控，共享部署又有租户互相干扰的问题。微信公众号
TiDB的思路是存算分离加虚拟数据库：底层共享一套KV存储，上面套逻辑库，调度层秒级完成逻辑库的创建、扩缩容和销毁，闲置计算资源自动释放，专治"租户百万级、长尾极长"。知乎另外MySQL兼容也是加分项——现在AI Agent自动写SQL，基本默认就是MySQL方言。
这条线上还有两个配套动作。一个是TiDB Cloud Zero，3月就开了Public Preview：1秒拉起一个分布式实例，先体验、先给Agent用，想正式保留再一键Claim成持久集群——这几乎就是照着Agent工作流设计的产品。另一个是平凯数据库（TiDB企业版）的更新方向：RPO=0物理复制、两节点高可用之外，原生带上了向量加全文的混合检索，明牌对着Agent记忆和RAG场景。知乎PingCAP副总裁刘松去年在36氪访谈里那句话，现在看就是剧本：AI即将重塑数据库，未来为Agent而生。
那个"矛盾"，其实是分工
回到开头的问题：唐刘反对Multi-Agent，和TiDB全力押注Agent，冲突吗？
不冲突，这是两个层面的判断。做应用编排时，现阶段单Agent加好工具就够了——这正是唐刘和Anthropic共识的部分，复杂的多Agent编排带来的是成倍的token成本和分布式系统那套老麻烦；但做数据底座时，必须默认Agent数量会爆炸，所以要提前备好"一秒钟开一个库、用完即焚"的能力。
一句话总结：编排可以保守，存储必须激进。这可能是今年AI基础设施领域最务实的一条工程判断，也解释了为什么平凯一边推多Agent协作框架Loop，一边首席AI官劝你少用Multi-Agent——框架是给未来规模留的口子，不是建议你现在就上。
谁该跟进这波，谁可以无视
对号入座一下：
还在"MySQL单机不到1TB、毫无痛点"阶段的，不用动。这波跟你暂时没关系，强行上分布式只会平添运维负担。
已经被分库分表折磨的——大表DDL慢、扩容复杂、主从延迟、跨库查询难——这批案例值得认真看。学科网阅卷系统就是对比OceanBase之后选的TiDB，迁移后磁盘占用降了一半，主从延迟风险直接消除；挚文集团也是弃了MySQL分库分表转投TiDB。知乎迁移方案上，这次北京站分享里给了两条成熟路线：DM同步加短暂不一致窗口（可快速回滚），或者双写强一致切换，各有适用场景。但要提醒一句：这些案例都出自TiDB社区活动，天然有幸存者偏差，社区里也不乏"只看到从TiDB迁去OB"的反向声音，选型还是拿自己的真实业务SQL去压测，别拿别人的发布会当依据。
在做AI Agent产品的，"一Agent一库"是正在发生的真实痛点。动手选型前可以把SQLite、PG多租户方案和TiDB Cloud Zero这类Serverless入口放一起比一比成本和隔离能力，后者1秒起实例，试错成本很低。微信公众号
DBA的话，这波最值得学的不是"AI巡检"这个结果，而是知乎那条路径本身：先把运维动作API化，再把经验写成Skill喂给大模型。这套能力不管你们家用的是TiDB、OB还是MySQL，未来几年都会是硬通货。
后面盯这几个信号
继续观察的线索也列一下：TiDB Cloud Zero在社区外开发者里的真实采用情况；企业版向量混合检索在真实RAG场景的口碑；平凯Loop的落地进展；以及OB和TiDB在信创与互联网两条战线上的竞争态势。有新变化再来更新。
最后聊五毛钱的：你团队的数据库现在走到哪一步了——还在分库分表里挣扎，还是已经让AI接管巡检了？评论区见。
