人们遍布整个“自己的DeepSeek Harness”，那我们为啥还在给Claude Code们充会员？

嘉宾（按出场顺序）| 唐刘、茹炳晟、Remy、天猪 “你如果不能在几个小时内重建 Cursor，下次面试会非常艰难——那不过是 300 行代码的一个 while 循环。” Ralph Loop 创造者 Geoffrey Huntley把软件工程师的底线划在 300 行。看似离谱，但大家发现，他可能是对的。 过去一年，Claude Code、Codex、Antigravity等大厂产品底层路径越来越相似：Agent Loop 读写上下文、调用工具、反复执行，用测试和权限兜底。上下文、工具、Loop、记忆和多 Agent，逐渐成为一套公开的标准牌面。 大厂之外，个人 Harness 项目也在疯狂涌现。 如今已经拥有庞大社区的 Pi 和 Aider，也都是从个人项目起步：Pi 由 41 岁的奥地利软件工程师 Mario Zechner 独立开发，Aider 由约 54 岁的加拿大软件工程师 Paul Gauthier 一人发起。面向 DeepSeek 优化的 Reasonix，则由游戏引擎开发者 YHH 个人发起，随后迅速发展成拥有数万 Star 的社区项目。 DeepSeek 宣布招募 Harness 内测后，评论区很快变成了一场“个人 Harness 展销会”。社区整理了帖子下的上千条回复，其中有数百个开源仓库，覆盖 Coding Agent、记忆、Skills、评测和安全等方向。几乎每个人都带着自己搭建的 Harness 前来自荐。 世界就是这么奇妙：几个月前大家的差异还在“AI辅助开发者生产力提升2倍还是100倍”，现在的差异已经变成“能不能写一套自己的 Harness”。 但当模型可以替换、Harness 可以复刻、常见组件已经趋同，连个人开发者都能拼出一套可用系统时，Coding Agent 还能靠什么打出差距？为此，我们采访了 TiDB 唐刘、腾讯研究院茹炳晟、Floatboat Harness 架构师 Remy，以及字节 Trae 天猪。 追模型不如搭 Harness？ 今年，多位知名Coding工具创始人都开始谈论一个话题：日常编程任务上，模型已经拉不开差距了。 Amp联合创始人Thorsten Ball说 "：“模型已经死了。”近距离管理单个模型的行为，回报已经越来越低。我们不需要再不断调整、试验不同模型——它们最终都会发展到“按下按钮，就能得到一个John Carmack”的水平。 OpenCode联合创始人Dax Raad的感受类似 "：模型公司在可用性方面找到了某种完美区域，用过更新的模型，再回头看这一代，会觉得它们彼此都差不多，“用哪个都一样”。 Pi 创始人 Mario Zechner认为如今模型不仅到顶峰了 "，新版本能力甚至还会倒退。能力越强，厂商越难保证旧能力不退化——真实世界的用例太多，评测根本覆盖不完。所以模型厂商会选择推自家 Harness，因为 Harness 是唯一能控制的部分，至少能把变化锁住。 几个月前，有国内 Coding 工具专家对 InfoQ 说过一句话：“（国产）模型不行，就只能靠工具补。模型负责决策，真正的编码、调试和重构，交给 Harness 里的工具完成。” 但现在情况变了。模型已经能应付大多数日常工作的复杂度。当日常任务根本触及不到模型的能力上限时，谁的上限更高，也就没有之前那么重要了。 既然模型拉不开差距，竞争就进入 Harness层。 Harness也在趋同，但趋同不是终点 Harness 不是新东西。早在2022 年 ChatGPT 刚问世时，4000 Token 的上下文窗口逼着开发者用工具调用、MCP、RAG 来管理上下文——Cursor、Windsurf、Cline、Aider 都是那个时期的产物。后来上下文窗口大了，任务也长了，Agent 跑几个小时就开始压缩总结、遗漏关键信息。有人引入 Sub-agent，有人搞 Agent Swarm，本质上都在做同一件事：为底层模型搭一个更好的运行环境。 “Harness”这个说法在 2026 年初广泛流行起来，但不过半年，大家的发展方向已经趋于一致。 最内层的 Agent Loop ，负责模型循环、文件读写、上下文管理和安全控制， 可以只有约 200 行代码 "。Amp 联合创始人 Thorsten Ball 则用 315 行 Go 代码 "从零写出了一个能够在终端读取、搜索和编辑文件的 Coding Agent。 虽然核心只有几百行代码，但一套完整的 Harness 仍要向外叠加大量组件。Planner、Coder、Reviewer、Search、Edit、Shell、Sub-agent、MCP——TiDB 团队唐刘列了一串名字，然后说：“这些东西慢慢都会变成标准部件。” 他拿数据库打了个比方：MySQL、TiDB、PostgreSQL、Snowflake 都有 SQL，都有 Optimizer，都有 Storage Engine，但没有人会觉得它们一样。真正的差距从来不在“有没有这个组件”，而在于这些组件怎么组成一个真正能解决问题的系统。 具体怎么做，TiDB 团队有自己的答案。他们的新产品 TiDB Cloud Filesystem "。项目本身是一次探索——团队边推进边迭代，在与 AI 的协作过程中，同步打磨出了一套 Harness。它不是提前设计好的，而是在项目不断遇到瓶颈、定位问题、调整执行方式的过程中，被一步步“逼”出来的。这套 Harness 的成形甚至早于 Claude Code 动态 Workflow 的发布。 他们没有从零写最内层的 Agent Loop，主要基于开源项目 Pi。但任务编排、权限、持久状态、Sandbox、失败恢复，是自己动手做的。设计哲学是一句话：薄 Agent Loop，厚 Control Plane。 为什么不自己写 Loop？因为 Agent Loop 是变化最快、也最容易同质化的一层。模型协议、Tool Calling、Streaming、Reasoning 一直在变，LLM 公司和云厂商迟早会把它做得越来越好。“我们没有必要在这里内卷。站在巨人的肩膀上就可以了。” 真正需要自己动手的，是数据库团队过去二十年一直在解决的问题：状态怎么持久化，权限怎么收口，副作用怎么控制，失败以后怎么恢复，一个结果到底怎么证明是真的，出问题以后怎么审计和复盘。 这样设计的主要好处是一旦换模型、换 Agent Core 不用推倒重来。他们最开始用 OpenCode，后来换成 Pi，但不管上面的Agent怎么换，下面的Sandbox、权限、状态和控制面都不需要跟着重写。模型能力越强，越可以放宽Sandbox里的探索空间，但完全没有必要同时放宽对真实生产系统的副作用边界。 这很像数据库。SQL、Optimizer这些组件可以越来越聪明，但 Transaction、Privilege、Durability 这些边界不能因为“上层更聪明”就消失。Agent Framework 可以不断变化，但状态、权限和副作用的边界必须稳定。 这套 Harness 最终支撑 TiDB Cloud Filesystem 在三个月内完成开发并上线。跨 Session、San