AI热榜 过去一段时间，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 现在的样子？
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接