“薄 Agent Loop，厚 Control Plane”：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。发布数据库软件时，你还能在实验室里反复测试；但云服务升级是在真实客户流量下做的。这个就是我们经常说的：开着飞机换引擎。
这时候怎么设计 Harness，怎么让 Agent 帮你做逐步 Rollout、验证、观察、Fail Fast、Rollback，同时确保客户业务连续性，我觉得才是我们接下来真正值得探索的问题。
InfoQ：一些开发者，甚至一些 Coding 工具从业者，比如 PI、Devin、Factory 创始人，都认为在日常编程任务上已经感受不到主流模型之间的明显差距，甚至不少认为“模型到顶了”“模型已经死了”。你认同这个判断吗？
唐刘：我并不认为模型到顶了。
当然，在很多领域，尤其是通用编程领域，模型之间的差距确实越来越小。比如我们现在在用 Rust 重写 TiDB 的一些部分。这种工作里面有相当一部分，本质上是 Translation：理解现有实现，然后转换成另外一种语言和工程表达。这种任务中，几个主流模型之间的差距确实没有以前那么明显。
但是进入复杂系统以后，我还是非常希望模型能够更强一点。比如刚才说的 Cloud Service Upgrade。它不是一个 Repository 里的 Coding 问题。它涉及多个复杂系统、多个软件版本、不同客户环境、实时流量、灰度发布、故障恢复和业务连续性。
这里真正困难的早已超出“帮我写一段代码”：你敢不敢根据当前所有信息做出一个决策，并承担这个决策的后果？
这也是我觉得今天 AI 和人的一个很大差异。AI 越来越会做事情，但我们还很难让 AI 承担责任。
很多 Mission Critical 的工作，最终还是会有一个 Engineer 说“Go”，或者“Stop”，甚至“Rollback”。
为什么？因为最后承担结果的是这个人。所以我觉得模型下一阶段真正重要的突破，可能不只体现在 Coding Benchmark 再提高几个百分点，还在于模型能不能越来越可靠地处理不完整信息、不确定性、多目标权衡、风险、反事实和错误后果。
换句话说，等到模型不仅可以给建议，而且可以逐渐成为一个值得托付决策的主体时，模型能力才算又向前迈了一大步。
InfoQ：现在涌现了大量个人 Harness 项目，各家 Coding 工具在大方向上的做法也越来越像，AI Coding 工具的实现路径是否正在收敛？真正能拉开差距的环节是什么？
唐刘：我觉得可见的路径肯定是在收敛，而且这是一件好事。
Planner、Coder、Reviewer、Search、Edit、Shell、Sub-agent、MCP，这些东西慢慢都会变成标准部件。
这很像数据库。大家都有 SQL，都有 Optimizer，都有 Storage Engine。
但没有人会因此认为 MySQL、TiDB、PostgreSQL、Snowflake 都一样。真正的差距从来都不在“有没有这个 Component”，而是在这些 Component 最后怎么组成一个真正能解决问题的系统。
所以我觉得 Coding Agent 最终真正的差异，也一定会回到现实世界：你到底要解决什么问题？你敢让这个 Agent 做到什么程度？
我一直非常关注“责任”这个问题。AI 能力越来越强，但是如果 AI 不能承担责任，那么对于很多真正重要的场景，人类的经验、判断甚至魄力，还是有非常大的价值。
很多决定不是一个更聪明的实习生就能做出来的。比如线上出了问题：要不要 Rollback？要不要让一个大客户继续冒险？是性能退化还是数据风险更重要？什么程度的问题值得停止整个发布？这些都不是单纯依靠 Coding Ability 就能解决的问题。
这里其实还有一个我最近越来越担心的问题。
今天的新一代 Software Engineer 正在快速跳过我们过去经历过的大量“很烦、很笨、很无聊”的工程实践。
我们以前要手工 Debug、看 Core Dump、熬夜 Oncall、查几十 GB 日志、做线上恢复、为一个错误承担后果。现在 AI 很多时候直接把这些东西包起来了。表面上看，这是巨大的生产力提升。但问题是：那些看起来很低效的过程，其实也在训练工程师对系统的直觉。为什么我看到一个指标就觉得不对？为什么我看到某个 Retry 就知道后面可能雪崩？为什么我知道这个 Change 虽然理论上没问题，但今天晚上最好别上线？很多这类能力，很难从一本书里面学到。
当然，事情可能没有这么悲观。今天的程序员也不用像四十年前一样学汇编、手工管理寄存器，但一样可以用 Rust 写非常好的系统。
所以，另外一种可能是：AI 会让 Engineering 的抽象层继续向上移动。以后我们会少关注“这一行代码怎么写”，更多关注“这个系统应该具有什么性质”。如果真是这样，我觉得这反而是一次非常大的生产力释放。
InfoQ：2026 年被称为“Agent 编排之年”。从你的角度来看，过去一年的实质进展是什么？你们自己在这个方向上在探索什么？
唐刘：我这里可能有一个稍微暴论一点的观点：Agent Orchestration 的未来，可能是越来越少的 Orchestration。
一两年前，我们让 Agent 做一个复杂任务，需要明确告诉它第一步做什么、第二步做什么、Planner 怎么工作、Coder 怎么工作、Reviewer 怎么工作，还要写一大堆 Prompt 来告诉它该怎么协作。
但是现在大家应该已经明显感受到：很多时候我们只要告诉 Agent：“我要这个结果。”它自己就能够完成大量内部规划。所以模型越强，一部分显式编排一定会消失。
这其实非常像数据库。早期应用需要告诉数据库：“我要怎么 Join、从哪张表开始、怎么访问。”
后来 Optimizer 越来越强，人只需要告诉它：“我要什么结果。”至于怎么执行，让数据库自己决定。
我觉得 Agent 也会经历这个过程：从 imperative orchestration 走向 declarative goal。
当然，这并不是说编排不重要。尤其对于复杂系统，Context 仍然不是无限的，状态仍然需要持久化，错误仍然需要恢复，所以还是会存在更高层的任务边界。
我们现在主要探索几个方向。
第一个是并行探索。我们会让多个 Agent 独立解决同一个问题，然后选择更好的结果继续推进。这里其实和我们数据库自己的 Branch 能力很契合。每一个 Agent 都可以有自己的隔离 Workspace、自己的状态、自己的实现，最后再 Merge 或者淘汰。
我觉得未来 Agent 的并行探索很像数据库里面的 MVCC：不要让所有人去争抢同一个世界，而是先让每个人拥有自己的 Version。
第二个是 Context。我们后来为什么会基于 TiDB 做 Filesystem，其中一个很重要的原因就是我们发现：对 Agent 来说，File 是一个非常自然的 Interface。
Agent 很擅长 ls、grep、cat、修改文件以及通过目录理解世界。所以，从交互上来说，File 有时候比 Database 更适合 Agent。
但同时，Agent 又需要数据库的能力：检索、索引、Transaction、Version、Branch、Rollback 和 Query。所以我们开始思考：能不能让 Agent 看到的是 File，背后拥有的却是 Database 的能力？这其实就是我们做 Filesystem/drive9 这类产品背后的一个核心思路。所以，严格来说，我们并不是想去做一个更好的 Agent。
至于 Agent Core 怎么发展，我觉得主要还是模型公司的战场。我们更想做的是：给 Agent 构建更好的数据和状态基础设施。
InfoQ：你们在多 Agent 协作这件事上走到哪一步了？为什么 Kubernetes 能管上万个容器，多 Agent 管几十个就复杂得要命？
唐刘：Kubernetes 这个例子其实非常好。因为它恰好证明了一件事情：“一个系统在一个场景非常成功，不代表它天然适合另外一个场景。”Kubernetes 从一开始就是为了管理长期运行、声明式、相对稳定的 Service。
但是 Agent 的 Workload 很不一样。Agent 的很多任务是瞬时的、按需启动的，空闲时间非常长，活跃度非常符合二八原则，生命周期可能只有几十秒或者几分钟，状态的重要性甚至高于 Compute 本身。这些并不是传统 Kubernetes 最擅长的东西。
所以 Kubernetes 管 Agent 不那么优雅，并不能证明 Agent 做不到 Scale。这更多说明：Workload 变了，Runtime 也应该变化。
我们自己在多 Agent 方面，反而比较克制。可能有点让人意外，我们并没有特别追求很多 Agent 相互沟通协同。
这是因为我们做分布式系统这么多年以后，对一件事情越来越敬畏：Communication is complexity（通信即复杂度）。
如果一个分布式系统里面有十个组件，每个组件都需要频繁与其他九个组件通信，这个系统大概率会非常难 Debug，性能也不会特别好。
Agent 其实也是一样。
如果完成一个任务需要 Agent A 问 Agent B、Agent B 再问 Agent C、Agent C 修改结果以后通知 A 和 D，然后大家不断同步状态，这个系统在设计上可能已经有问题了。
所以我们现在的思路反而更接近 Unix Philosophy：一个 Agent 做好一件事情。Agent 之间尽可能通过清晰的 Input / Output 解耦，而不是高频聊天。当然，更上层仍然可以有一个 Agent 或 Workflow 去分配任务、汇总结果。但是整体拓扑要尽量简单。
这也是我们做 TiDB 时一直相信的一件事情：复杂性永远有成本。不要因为我们“可以”做一个复杂系统，就一定要做复杂系统。能够用一个 Agent 解决的问题，就不要用五个 Agent。能够通过状态共享解决的问题，就不要通过消息广播解决。能够异步完成的事情，就不要做同步依赖。
所以我不觉得未来一定是一家由一百个 Agent 在 Slack 群里开会的软件公司。
真正好的多 Agent 系统，反而可能看起来非常安静。每个 Agent 都在自己的边界里面完成工作，最后通过明确的状态和结果来协作。
InfoQ：很多 Coding Agent 前十几步表现很好，到了四五十步就开始跑偏。长程稳定性会不会成为下一代 Coding 工具最重要的分水岭？
唐刘：我认为会。
但我不太喜欢把 Long Horizon 理解成模型能不能咬牙坚持跑五十步、一百步。真正的问题不是它能不能跑得久，而是一个小错误出现以后，系统能不能在它变成故障之前把它拦住。这和分布式系统其实非常像。
一个系统发生错误，本身不可怕。所有分布式系统都会失败：网络会断，磁盘会坏，机器会挂，Timeout 一定会发生。真正危险的是一个系统把 Failure 当作普通事件以后，不断 Retry，最后把一个小故障放大成系统雪崩。所以我最近其实越来越相信一句话：“Retry is dangerous. Fail fast is underrated.”
但 Fail Fast 只是第一步。真正难的是 Fail 以后怎么办？这就是 Failover。对 Agent 来说也是一样。Agent 在第十步犯一个错误，并不一定意味着任务失败。真正的问题是第十一步到第五十步还在错误前提上继续执行；Context 里的错误信息越来越多；后面的 Agent 把旧的错误结论当成事实；到最后你已经不知道从哪一步开始错的。
所以真正重要的是三个能力。第一，尽早发现错误。不要等到第五十步才发现。第二，限制错误传播。错误不能自动变成后续步骤的事实。第三，从最近一个可信状态恢复。要有 Checkpoint，要有持久状态，要能够换一个 Agent、换一条路径继续。
这其实跟数据库非常像：Transaction Log、Checkpoint、Rollback、Failover。我们不会设计一个数据库，假设这台机器永远不会坏。同样，我们也不应该设计一个 Agent System，假设这个 Agent 永远不会犯错。
真正成熟的系统哲学应该是：“Assume failure, contain failure, recover from failure（假设失败必然发生，控制失败的影响范围，并从失败中恢复）”。
所以如果问我下一代 Coding Agent 最重要的分水岭是什么，我的答案会是：比起“谁可以连续工作更久”，更重要的是谁能在 Agent 犯错后限制错误继续扩大，并让系统快速回到正确轨道。
这其实可能也是我们数据库行业可以为 Agent 时代贡献的一个很重要的设计哲学：成熟的可靠性并不追求永不失败，它要求系统在失败以后仍然能够保持正确。