“薄代理循环，厚控制平面”：TiDB 用数据库思维重做 Harness

过去一段时间，TiDB 团队启动了一项面向 Agent 的基础设施尝试—— TiDB Cloud Filesystem "。它把 Workspace 从 Session 和 Sandbox 的生命周期中独立出来：Agent 仍然通过熟悉的文件系统接口工作，背后则提供数据库级的持久化、版本、分支、回滚和权限控制。即使 Sandbox 被回收，新的 Executor 也能接管同一份文件和状态继续任务。TiDB Cloud Filesystem 保存的不是一台机器，而是 Agent 的工作现场。目前，它已经承载超过数百万个 Agent Workspace。 这次极限测试的背后，是 TiDB 在实践中逐渐形成的一套 Harness。彼时 Claude Code 已经出现，但今天用于大规模多 Agent 编排的 Dynamic Workflows 尚未发布。TiDB 没有从零编写 Agent Loop，而是借助开源项目完成最内层核心，将更多精力放在任务编排、权限、Sandbox、持久状态和失败恢复上——这些恰恰是数据库团队过去二十年最擅长的领域。 这套 Harness 的设计哲学被 TiDB 唐刘概括为 “薄 Agent Loop，厚 Control Plane” ：Agent Loop 是变化最快、最易同质化的一层，完全可以站在开源巨人的肩膀上；但状态、权限和副作用的边界必须保持稳定。“这就像数据库，”唐刘强调，“SQL 可以越来越聪明，Optimizer 可以越来越聪明，但 Transaction、Privilege、Durability 这些边界不能因为‘上层更聪明’就消失。” 在接受 InfoQ 专访时，唐刘从数据库的可靠性哲学出发，分享了 TiDB 在构建 Harness 过程中的一系列独特思考： 数据库行业天然就在做 Harness——对于开源数据库而言，真正的护城河往往不是 GitHub 上的开源代码，而是背后庞大的测试体系；测试代码、故障注入、随机测试和线上 Case 积累本身，就是 Harness。 Agent Orchestration 的未来是越来越少的编排——正如数据库从手写 Join 顺序演进到声明式 SQL，模型越强，显式编排就越会从命令式走向声明式。 多 Agent 系统不该像一百个 Agent 在 Slack 群里开会——通信即复杂度，好的多 Agent 系统应像 Unix 哲学一样安静，通过状态共享而非消息广播来协作。 “Fail Fast”比“Retry”更重要——这是分布式系统最深刻的教训：真正危险的不是一个 Agent 犯错，而是错误被不断 Retry 后放大成系统雪崩。 以下是 InfoQ 与唐刘的完整对话。 InfoQ：你们做 Harness 的时候，是基于某个开源框架搭的，还是完全从零写的？当时为什么做这个选择？这个选择后来怎么塑造了你们 Harness 现在的样子？ 唐刘：坦白来说，我们 TiDB 内部并没有一个所谓“完整的 Harness 最佳实践”。我们现在的系统是混合的：最内层的 Agent Loop 没有从零写，主要基于开源项目 Pi；但是任务编排、权限、持久状态、Sandbox、失败恢复这些部分，很多是我们自己做的。 当时的判断其实很朴素。Agent Loop 是今天变化最快、也最容易同质化的一层。模型协议、Tool Calling、Streaming、Reasoning 这些能力一直在变化，而且我相信长期来看，无论是 LLM 公司还是云厂商，都会把这一层做得越来越好。 所以我们没有必要在这里内卷。站在巨人的肩膀上就可以了。 我们真正熟悉的，是数据库团队过去二十年一直在解决的问题：状态怎么持久化；权限怎么收口；副作用怎么控制；失败以后怎么恢复；一个结果到底怎么证明是真的；出问题以后怎么审计和复盘。 所以如果一定要总结我们的设计哲学，我会说是：薄 Agent Loop，厚 Control Plane。 这个设计有两个好处。第一，我们很容易换模型、换 Agent Core。实际上我们现在用 Pi，也是后来替换掉了最开始使用的 OpenCode。但不管上面的 Agent 怎么换，下面的 Sandbox、权限、状态和控制面并不需要一起推倒重来。第二，模型能力越强，我们越可以放宽它在 Sandbox 里的探索空间，但完全没有必要同时放宽它对真实生产系统的副作用边界。 这其实很像数据库。SQL 可以越来越聪明，Optimizer 可以越来越聪明，但 Transaction、Privilege、Durability 这些边界不能因为“上层更聪明”就消失。 所以我们越来越相信一句话：Agent Framework 可以不断变化，但状态、权限和副作用的边界必须稳定。 InfoQ：当市面上大多数 Harness 是在“让 AI 写通用代码”这个场景中打磨出来的，你们的 Harness 是在“让 AI 写分布式数据库”这个场景中被逼出来的。在你们构建 Harness 的过程中，哪些环节迫使你们做出了跟主流 Harness 不一样的设计选择？ 唐刘：其实我个人并不觉得我们跟主流 Harness 有多么不一样。反过来，我甚至觉得数据库行业天然就在做 Harness，只是以前没有用这个词。大多数 Coding Harness 的默认路径是：先读代码，再改代码、跑测试，最后生成 Patch。对于很多日常开发任务，这已经够用了。但对数据库来说，远远不够。 因为数据库是 Mission Critical System。我们发布一个版本，不只是要求“代码能运行”，还要保证：客户数据不能损坏；服务不能中断；新旧版本能够兼容；异常发生以后能够恢复；一个正常 Case 通过，不能代表整个系统就是正确的。所以在 Harness 这个概念流行之前，数据库公司其实早就在构建各种 Harness。 我一直有一个观点：对于开源数据库来说，真正最深的护城河往往不是 GitHub 上那些开源代码，而是背后没有被完整公开出来的测试体系。TiDB 也一样。我们的测试代码、故障注入、随机测试、兼容性测试、性能测试以及各种线上 Case 积累，本身可能比数据库内核代码还要庞大。这些东西其实就是 Harness。 你可以把数据库代码看成“被测试的对象”，而围绕它构建的整个验证体系，才决定这个系统敢不敢被放到生产环境里。这一点也非常符合我们设计分布式系统的哲学：不要相信一个组件说自己是正确的，要用外部不变量证明它是正确的。 Agent 也是一样。Agent 说：“我已经修好了。”对我们来说没有意义。真正的问题是：哪个 Commit？什么测试？什么输入？什么故障条件？什么 Evidence？换一个人能不能重现？所以 AI 时代最大的变化不是我们突然发明了一套测试体系，而是 Agent 可以开始更深地进入这套体系，把过去大量人工完成的验证、分析和反馈连接起来。 当然，我们现在远远没有解决所有问题。代码测试其实是相对简单的一环。真正更难的是 Cloud Service。发布数据库软件时，你还能在实验室里反复测试；但云服务升级是在真实客户流量下做的。这个就是我们经常说的：开着飞机换引擎。 这时候怎么设计 Harne