Harness 成 Coding Agent 新战场：模型趋同下的差异化之路

Coding Agent 的战场，已经悄悄从模型层转移到了 Harness 层。过去一年，Claude Code、Codex、Antigravity 等主流产品底层路径越来越相似：Agent Loop 读写上下文、调用工具、反复执行，用测试和权限兜底。当模型可以替换、Harness 可以复刻、常见组件已经趋同，竞争的重心正在被重新定义。

模型趋同，Harness 登场

今年，多位知名 Coding 工具创始人都开始谈论一个共同话题：在日常编程任务上，模型已经拉不开差距。Amp 联合创始人 Thorsten Ball 直言「模型已经死了」，近距离管理单个模型行为的回报越来越低。OpenCode 联合创始人 Dax Raad 也有类似感受：用过更新模型再回头看，会觉得它们彼此都差不多，「用哪个都一样」。

Pi 创始人 Mario Zechner 认为模型不仅到了顶峰，新版本能力甚至还会出现倒退。能力越强，厂商越难保证旧能力不退化。模型厂商选择力推自家 Harness，恰恰是因为 Harness 是唯一能控制的部分。一位国内 Coding 工具专家此前对 InfoQ 表示：「（国产）模型不行，就只能靠工具补。」但当模型已经能应付大多数日常工作复杂度、当日常任务根本触及不到模型上限时，谁的能力上限更高也变得不那么重要了。

Harness 在趋同，但不是终点

Harness 并非新概念。早在 2022 年 ChatGPT 刚问世时，4000 Token 的上下文窗口就逼着开发者用工具调用、MCP、RAG 来管理上下文，Cursor、Windsurf、Cline、Aider 都是那个时期的产物。随着上下文窗口扩大、任务变长，Agent 跑几个小时就开始压缩总结、遗漏关键信息，Sub-agent、Agent Swarm 等方案被引入——本质上都在做同一件事：为底层模型搭一个更好的运行环境。

最内层的 Agent Loop 负责模型循环、文件读写、上下文管理和安全控制，核心代码约 200 行。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 的实践：薄 Agent Loop，厚 Control Plane

TiDB 新产品 TiDB Cloud Filesystem 的开发过程中，团队边推进边迭代，逐步打磨出一套 Harness。这套 Harness 的成形甚至早于 Claude Code 动态 Workflow 的发布。

Agent Loop 层：基于开源项目 Pi，没有从零重写。唐刘认为 Agent Loop 是变化最快、最容易同质化的一层，没有必要在这里内卷。
Control Plane 层：任务编排、权限、持久状态、Sandbox、失败恢复全部自己动手做。
设计哲学：「薄 Agent Loop，厚 Control Plane」，核心是把数据库团队二十年积累的状态持久化、权限收口、副作用控制、失败恢复、审计复盘能力沉淀进来。

这样做的好处是一旦换模型、换 Agent Core 不用推倒重来。团队最初用 OpenCode，后来换成 Pi，但 Sandbox、权限、状态和控制面不需要跟着重写。这套 Harness 最终支撑 TiDB Cloud Filesystem 在三个月内完成开发并上线，上线后已承载超过数百万个 Agent Workspace。

差距藏在看不见的地方

LangChain 联合创始人 Harrison Chase 认为，收敛是收敛了，但它会收成一个连续的光谱：通用 Harness 在基础任务上已经够用，但任务越不常规，越需要定制 Harness。促使人们走向定制端的，往往不是性能，而是可预测性和控制力——比如金融行业宁愿牺牲智能也要可控。

腾讯研究院茹炳晟认为 Coding Harness 的能力高低取决于知识工程。他把一套好的 Harness 拆成三层：

理解存量系统：把原始需求、系统设计和代码结合，理解原有功能与业务逻辑。这涉及知识接入、Code Graph 建模、模块定位与代码片段检索等工作。
项目约束与推理：让模型了解项目和代码仓的约束，并在完成后检查规则是否真正落实。光写「遵守规则」的 Prompt 不够，还需要多轮反思机制。
确定性验证：Agent 说「我修好了」没有意义，必须用外部不变量证明正确性。Harness 要与 CI 体系打通，覆盖测试生成、执行、结果分析与反馈，覆盖单元测试、容器化测试、编译运行等能力。

多 Agent 编排：分布式内耗？

Boris Cherny 在多个场合推崇 Anthropic 的多 Agent 能力——几千个 Agent 同时跑，Claude Code 的 Dynamic Workflows 也把这种玩法产品化。2026 年被业内称为「Agent 编排之年」。

这套剧本十年前演过一次。2016 年也叫「编排之年」，主角是容器；Docker 把应用标准化后，Kubernetes、Swarm、Mesos 打成一团，最后赢的是控制平面。十年后，Agent 在走同样的路。Steve Yegge 早在 2025 年就建议 Anthropic 做「Agent 的 Kubernetes」，未被采纳后自己做了 Gas Town，让一个人可以持续管理 20 到 30 个并发 Coding Agent。

唐刘的判断听起来像暴论：Agent 编排的未来，可能是越来越少的编排。模型越强，一部分显式编排就一定会消失——从命令式编排走向声明式目标，就像数据库从手动指定 Join 走向 Optimizer 自动决定执行计划。

唐刘对分布式系统的敬畏是「Communication is complexity」。TiDB 在多 Agent 上反而很克制，更信 Unix Philosophy：一个 Agent 做好一件事，Agent 之间靠清晰的 Input/Output 解耦，尽量减少高频聊天。「我不觉得未来一定是一百个 Agent 在 Slack 群里开会的软件公司。」他说，「真正好的多 Agent 系统，反而可能看起来非常安静。每个 Agent 都在自己的边界里面完成工作，最后通过明确的状态和结果来协作。」