Coding Agent 差距已从模型层转向工程层：300 行 while 循环论之后
“你如果不能在几个小时内重建 Cursor，下次面试会非常艰难——那不过是 300 行代码的一个 while 循环。”
Ralph Loop 创造者 Geoffrey Huntley 把软件工程师的底线划在了 300 行。听着离谱，但大家发现，他可能是对的。
过去一年，Claude Code、Codex、Antigravity 等大厂产品的底层路径越来越相似：Agent Loop 读写上下文、调用工具、反复执行，用测试和权限兜底。上下文、工具、Loop、记忆和多 Agent，逐渐成为一套公开的标准牌面。
大厂之外，个人 Harness 项目也在疯狂涌现。Pi 和 Aider 都是从个人项目起步：Pi 由奥地利软件工程师 Mario Zechner 独立开发，Aider 由加拿大软件工程师 Paul Gauthier 一人发起；面向 DeepSeek 优化的 Reasonix，由游戏引擎开发者 YHH 发起，随后迅速发展成数万 Star 的社区项目。DeepSeek 宣布招募 Harness 内测后，评论区很快变成“个人 Harness 展销会”——上千条回复里覆盖数百个开源仓库，几乎人人都带着自己搭的 Harness 前来自荐。
几个月前，大家的差异还是“AI 辅助开发者生产力提升 2 倍还是 100 倍”；现在的差异已经变成“能不能写一套自己的 Harness”。
当模型可以替换、Harness 可以复刻、常见组件已经趋同，连个人开发者都能拼出一套可用系统时，Coding Agent 还能靠什么打出差距？本文综合 TiDB 唐刘、腾讯研究院茹炳晟、Floatboat Harness 架构师 Remy，以及字节 Trae 天猪的观点。
模型“已死”，Harness“当立”
今年，多位知名 Coding 工具创始人都开始谈论一个话题：日常编程任务上，模型已经拉不开差距了。
- Thorsten Ball（Amp 联合创始人）：“模型已经死了。”近距离管理单个模型的行为，回报已经越来越低。模型终会发展到“按下按钮，就能得到一个 John Carmack”的水平。
- Dax Raad（OpenCode 联合创始人）：模型公司在可用性方面找到了某种完美区域，“用哪个都一样”。
- Mario Zechner（Pi 创始人）：模型不仅到顶了，新版本能力甚至还会倒退。真实世界的用例太多，评测根本覆盖不完，能力越强，厂商越难保证旧能力不退化。模型厂商推自家 Harness，是因为 Harness 是唯一能控制的部分，至少能把变化锁住。
几个月前，还有国内工具专家说“模型不行，就只能靠工具补”。现在情况变了：模型已经能应付大多数日常工作的复杂度。当日常任务根本触及不到能力上限时，“谁上限更高”已经没那么重要。竞争进入 Harness 层。
Harness 在趋同，但趋同不是终点
Harness 不是新东西。2022 年 ChatGPT 刚问世时，4000 Token 的上下文窗口就逼着开发者用工具调用、MCP、RAG 来管理上下文——Cursor、Windsurf、Cline、Aider 都是那个时期的产物。“Harness”的说法在 2026 年初广泛流行，但不过半年，发展方向已趋于一致。
最内层的 Agent Loop（模型循环、文件读写、上下文管理、安全控制）可以只有约 200 行代码；Thorsten Ball 更是用 315 行 Go 代码从零写出了能在终端读、搜、编辑文件的 Coding Agent。核心虽短，完整 Harness 仍要向外叠加大量组件：Planner、Coder、Reviewer、Search、Edit、Shell、Sub-agent、MCP。唐刘说：“这些东西慢慢都会变成标准部件。”
标准部件人人都有，真正的差距在于组件怎么组成一个能解决问题的系统。他拿数据库打比方：MySQL、TiDB、PostgreSQL、Snowflake 都有 SQL、Optimizer、Storage Engine，但没有人会觉得它们一样。
TiDB 团队的答案是 TiDB Cloud Filesystem。项目本身是一次探索，Harness 不是提前设计好的，而是在边推进边迭代、不断遇到瓶颈和定位问题的过程中被“逼”出来的——成形时间早于 Claude Code 动态 Workflow 的发布。他们没有从零写 Agent Loop，主要基于开源项目 Pi，任务编排、权限、持久状态、Sandbox、失败恢复是自己动手做的。设计哲学一句话：薄 Agent Loop，厚 Control Plane。
为什么不自己写 Loop？因为 Agent Loop 是变化最快、也最容易同质化的一层——模型协议、Tool Calling、Streaming、Reasoning 一直在变，LLM 公司和云厂商迟早会把它做得越来越好。“没有必要在这里内卷，站在巨人的肩膀上就可以了。”真正要自己动手的，是数据库团队过去二十年一直在解决的问题：状态怎么持久化、权限怎么收口、副作用怎么控制、失败以后怎么恢复、结果怎么证明是真的、出问题怎么审计复盘。
这样设计的好处是换模型、换 Agent Core 不用推倒重来。他们最开始用 OpenCode，后来换成 Pi，Sandbox、权限、状态和控制面都不需要重写。模型能力越强，越可以放宽 Sandbox 里的探索空间，但完全没有必要同时放宽对真实生产系统的副作用边界。这就像数据库：SQL、Optimizer 可以越来越聪明，Transaction、Privilege、Durability 的边界不能消失。
这套 Harness 最终支撑 TiDB Cloud Filesystem 在三个月内完成开发并上线。跨 Session、Sandbox 和 Executor 的持久 Workspace，版本、分支、Checkpoint、Rollback、权限、配额与多租户隔离全部由 Agent 完成，人类没有写一行代码，也没有审一行 PR。上线后已承载超过数百万个 Agent Workspace。
差距藏在看不见的地方
LangChain 联合创始人 Harrison Chase 看到了同样的趋势，但多了一层判断：收敛会收成一个连续的光谱。一端是现成的通用产品，另一端是完整的定制认知架构，中间是无数通过 Hook 或中间件实现定制的状态。推动人们走向定制端的往往不是性能，而是可预测性和控制力，比如金融行业——客户宁愿牺牲一点智能，也要换回可控性。
具体到 Coding Agent，腾讯研究院茹炳晟认为，知识工程决定了能力高低。绝大多数 AI 编程工作不是从 0 到 1，而是在现有代码上增加功能或修 Bug。他把好的 Harness 需要做到的事情拆成三层。
**第一层：理解存量系统。**很多项目代码本身比较杂乱，光读代码不够，最好把原始需求、系统设计、代码结合起来，理解“为什么长这样”。大型项目不可能一次性把全部代码塞进上下文，需要 Harness 做顶层建模、Code Graph 机制，在需要时定位相关模块，再在模块内用 grep 等方式找到更细的代码片段。
**第二层：项目约束与推理。**模型要具备软件工程能力，还必须了解具体项目和代码仓的约束。Harness 要让规则对模型可见，确保执行中遵守规则，完成后检查规则是否落实。但光在 Prompt 里写“遵守规则”不够——还需要检查规则和反思机制，反思可能不止一轮，多轮结果合并再迭代，直到满足约束。
**第三层：确定性验证。**代码生成只是起点，Agent 说“我修好了”没有意义，得用外部不变量证明它是对的。因此 Coding Harness 要与持续集成体系打通，覆盖测试生成、测试执行、结果分析、错误反馈，再根据运行结果修正代码。这要求 Harness 具备单元测试环境、容器化测试环境、编译运行、结果分析和结果展示能力。代码生成之后如何编译、运行、拉起环境并判断结果，都可以用确定性工程手段完成。
多 Agent 编排：听着高大上，实际是“分布式内耗”
Boris Cherny 最常挂在嘴边的是他那套几千个 Agent 同时跑、忙时上万的多 Agent 能力。Claude Code 把这种玩法产品化为 Dynamic Workflows：用户给个目标，Claude 自己拆任务、调度数百个子 Agent 去搜索、编码、验证、汇总。2026 年被称为“Agent 编排之年”。
这套剧本十年前演过一次。2016 年也叫“编排之年”，主角是容器。Docker 标准化了应用，大家发现跑一个容器不难，难的是管几千个，于是 Kubernetes、Swarm、Mesos 打成一团，最后赢的是控制平面。现在 Agent 走在同样的路上，大模型厂商、云厂商、企业软件巨头、开源框架、治理层平台全部涌了进来，每家都想成为那个“管理 Agent 的控制层”。
这个判断并不新鲜。早在 2025 年，《Vibe Coding》作者、前 Google 和 Amazon 工程师 Steve Yegge 就去找过 Anthropic 高层，建议做“Agent 的 Kubernetes”——Claude Code 只是一个构件，真正的战场在上面。没人理他，于是他 8 月自己动手，做出了 Gas Town。按他的说法，Gas Town 可以让一个人持续管理 20 到 30 个并发 Coding Agent。
但唐刘有一个“暴论”：Agent 编排的未来，可能是越来越少的编排。一两年前，让 Agent 做复杂任务得手把手教：第一步干什么、第二步干什么、Planner 怎么工作、Coder 怎么工作、Reviewer 怎么工作。现在很多时候只需告诉 Agent“我要这个结果”，它自己就能完成大量内部规划。模型越强，一部分显式编排就一定会消失。这很像数据库演进：早期要告诉数据库“怎么 Join、从哪张表开始”，后来 Optimizer 越来越强，人只管说“我要什么”。Agent 也会从命令式编排走向声明式目标。
做分布式系统这么多年，唐刘对一件事越来越敬畏：Communication is complexity（通信即复杂度）。十个组件频繁通信的系统，大概率难 Debug、性能也不好。Agent 也一样——如果完成任务要靠 A 问 B、B 问 C、C 改完通知 A 和 D、大家不停同步状态，这个系统在设计上可能已经出问题了。
所以 TiDB 在多 Agent 上反而很克制，甚至有点反潮流。他们更信 Unix Philosophy：一个 Agent 做好一件事，靠清晰 Input/Output 解耦，尽量减少高频聊天。上层可以有一个 Agent 或 Workflow 分配任务、汇总结果，但整体拓扑尽量简单。“复杂性永远有成本。不要因为我们‘可以’做一个复杂系统，就一定要做复杂系统。我不觉得未来一定是一百个 Agent 在 Slack 群里开会的软件公司。真正好的多 Agent 系统，反而可能看起来非常安静——每个 Agent 在自己的边界里完成工作，最后通过明确的状态和结果协作。”唐刘说。
茹炳晟对此十分赞同。他认为多 Agent 不是默认选项，是单 Agent 搞不定了才用的补充方案。行业里常见的顺序、并行、路由等十来种固定模式，大多只描述了 Agent 如何连接和执行，算不上真正的智能体设计模式。作为 Agent Design Patterns Society（ADPS）的创始人之一，他把智能体设计模式拆成两个维度：认知能力（感知、记忆、推理、行动、反思、协作、治理）和执行拓扑（链式、路由、并行、循环、层级、编排），两者拼成二维矩阵，每个交点都可能是一种模式，远不止十来种，且不一定天然属于多 Agent——有些模式在单 Agent 内部就能完成。
但无论选哪种模式，都有一个原则：只要单 Agent 能搞定，就不要引入多 Agent。复杂度不会消失，只会转移。从单体拆成微服务，服务间通信和状态管理成了新难题；从单 Agent 拆成多 Agent，协作、状态同步、结果汇总、系统治理全是新坑。很多人觉得多 Agent 能降低复杂度，其实只是把问题从一个地方挪到了另一个地方。
目前值得付出这笔成本的主要是两个场景：一是缓解上下文压力——单 Agent 扛全链路任务，上下文窗口很快耗尽，把子任务拆给子 Agent，主 Agent 只收结果；二是交叉验证和发散探索——一个模型完成任务，另一个负责检查，在对话中碰撞出新的想法。
回应“编排热”：大家都在抢同一个入口，但这个入口真的存在吗？还是说，一场由模型厂和云厂商联手催熟的“编排热”，正在让行业集体走入“为了复杂而复杂”的陷阱？
长程是分水岭
如果通用 Coding Agent 的差距不在多 Agent 编排，那就换一个问题：一个 Agent 连续跑 50 个小时，它还知道自己干过什么吗？
这是通用型 Agent 框架的“终极考场”。如今 Harness 核心模块已高度标准化：上下文管理、任务拆解、工具调用、记忆整合，各家大同小异。“大的方向上，基本就这些东西了。”架构趋同之后，拼的是模块之间怎么配合。单点暂时领先可以，长期优势一定来自整体协作——单点上的实现细节，经过几十轮执行后会累积成完全不同的结果。
因此多位从业者判断：长程稳定性，会是下一代 Agent 产品的核心分水岭。很多 Agent 前十几步表现不错，四五十步就开始跑偏。但“长程”不只看步数——调用 50 次同一个稳定 API，未必比修改 7 个相互依赖的文件更长程。Floatboat 团队指出，真正决定难度的是依赖链深度、状态跨越的时间和工具数量、目标开放程度、操作可逆性，以及错误被发现之前要经过多少轮反馈。
所以这不是“模型能不能咬牙坚持跑完”的问题。真正的问题是：一个小错误出现以后，系统能不能在它变成故障之前拦住它。错误很少突然爆发。模型本身有概率性，用户需求常是模糊的，Harness 在长链条里还会把目标稀释、上下文压变形、工具调出问题、反馈不及时——这些缠在一起，早期一个不起眼的偏差被写进环境，等到验证环节才发现，已经晚了。既然问题是“错误发现得太晚”，解法就是让错误尽早暴露。
这和分布式系统的逻辑一模一样。网络会断、磁盘会坏、机器会挂，所有分布式系统都会失败。真正危险的不是失败本身，而是不断 Retry 把小故障放大成雪崩。唐刘越来越相信一句话：重试很危险，快速失败的价值却常被低估（Retry is dangerous. Fail fast is underrated）。
Fail Fast 不等于放弃任务，它只是把问题的暴露时间点从“五十步之后”提前到“十步”。Agent 在第十步犯错不等于任务失败；真正可怕的是第十一到五十步还在错误前提上继续跑，错误信息越攒越多，后面的 Agent 把旧错误当事实，最后根本不知道从哪一步开始错的。所以 Fail Fast 必须搭配另外两个能力：限制错误传播、从最近一个可信状态恢复。
唐刘的解法来自数据库研发经验：要有 Checkpoint，要有持久状态，要能换一个 Agent、换一条路径继续干。Transaction Log、Checkpoint、Rollback、Failover——我们不会设计一个假设“这台机器永远不会坏”的数据库，同样也不该设计一个假设“这个 Agent 永远不会犯错”的系统。
这个方向已成行业共识。Pi 的 Harness v2 正在把执行状态拉入持久化范围：操作意图、执行步骤、Tool 状态、消息队列全部落盘，进程崩溃后根据 Operation Log 判断安全恢复点，和数据库 WAL 一个思路——状态可以丢，但日志不能丢，丢了日志就丢了真相。可靠性从来不是不失败，而是失败之后仍然能保持系统正确。
再往前走一步：能恢复，能不能自改？可以，但必须是受控闭环——发现问题、生成改动、隔离评测、灰度发布、保留回滚。没有版本管理和可观测性，自进化只是在积累技术债。关键不在“能不能改自己”，而在如何证明改得更好、代价可控、随时能退。
要做到这些，对底层技术栈的控制力是绕不开的前提。Floatboat 是一家面向通用工作场景的 Agent 公司，他们选择全栈自研的原因正在于此。这个“全栈”不止 Harness，也包括模型层的理解和训练能力。他们自研了 Runtime、Agent Loop、Tools、Infra 和自进化系统 FloatSail，还构建了原生文件协议、GUI-Agent 双向协议等能力。对创业公司来说这条路很重，但他们认为这是必要的：如果连系统内部发生了什么都不知道，长程收敛就无从谈起。
Remy 指出，模型决定“每一步判断的上限”，Harness 决定“这些判断能否在长路径上积累成结果”。他们的验证逻辑是：同一个模型，任务越长、状态越复杂、验证越稀疏，Harness 拉开的差距就越大。实测下来，长程任务上 Harness 能多贡献 23%——模型不变，差别在模型之外的那一半系统。
这种控制力也体现在自进化上。产品级 Harness 不能让模型随便改自己，得有一个受控闭环：先发现问题，生成改动，在隔离环境跑一遍，过了质量、成本、时延和安全门槛再灰度上线，同时保留回滚能力，并始终保持 Human-Centric——起初是人在环中，逐渐增多人在环上的模式：大量局部优化自动完成，人主要负责目标、边界、例外和系统级治理。
编程之战结束了吗
编程只是 Harness 最早跑通的场景，不是终点。
从 2026 年初开始，国内大厂的 AI 资源就在从编程向办公场景倾斜。据《晚点》等媒体持续追踪报道，春节后字节高层调整了 AI 资源分配策略，重心从消费产品转向企业服务；阿里在年初成立 ATH 事业群统一调度算力，7 月完成多条智能体产品线整合；腾讯则从 3 月开始全力押注 WorkBuddy，资源被形容为“一路绿灯”。半年左右，三家大厂都完成了同一件事：把算力、人才和预算集中到 AI 办公主线。
这场转向不是从零开始。腾讯的路径最有代表性：CodeBuddy 和 WorkBuddy 原本出自同一团队，据《晚点》报道，Claude Cowork 发布后，四人团队只用一个周末便做出了 WorkBuddy；原 CodeBuddy 负责人带队转入 WorkBuddy，团队扩编，Coding Harness 的能力被完整带入办公场景。字节 Trae Work 和 Trae IDE、阿里 Qoder 和 Qoder Work 也是类似的“一面两体”，都是从 Coding Harness 泛化到 Work 场景。OpenAI 也明确表示，ChatGPT Work 与 Codex 的底层 Harness 完全共享：“用的是同一套 Harness。”
道理其实不复杂。字节 Trae 团队的天猪之前聊过一个趋势：IDE 正在经历“能力原子化”，那些为人类操作设计的界面和功能，正被拆解成一个个细粒度的 Tool 交给 Agent 按需调用。办公场景也一样——邮件、文档、日历、审批这些熟悉的操作界面，一样会被拆成 Agent 可调用的接口。今年飞书开源的那套 CLI，本质就是一套 Skill + CLI，把消息、文档、日历、审批、聊天记录封装成 Agent 可调用工具，上线后很快爆火。
因此，这两类产品现在都共享同一套 Harness 核心，区分的是调用工具：IDE 产品操作代码仓库和终端，Work 产品进入文档、网盘和邮箱。底层逻辑还是一样——理解目标、选择工具、执行多步任务、维护状态、验证结果。
但“相同”不意味着“完全等价”。Coding 场景的交付标准相对明确：代码能否编译、测试是否通过、类型是否正确，对错分明。通用任务更多发生在开放世界：一封邮件是否得体、一次跨应用操作是否符合权限规范、一份研究是否抓住了重点，这些涉及情境、审美和判断。Coding Harness 主要管理技术复杂性，通用 Harness 还要管理社会复杂性（InfoQ 另有一篇关于 Floatboat 全栈自研策略的专文，题为《自研 Runtime、Agent Loop、Infra：一家通用 Agent 公司的全栈赌注》）。
两者的关键分界线，是交付标准能否在任务开始时被充分形式化。能写成测试的任务，核心是可靠执行；不能的，系统还要在执行中帮用户发现自己真正要什么。这意味着编程 Agent 过去几年积累的能力——上下文管理、任务规划、工具调用、状态持久化、错误恢复——正在从一个垂直场景，变成一套通用的工作基础设施。编程为这套 Harness 提供了最早的训练场和商业化验证，Work 则把它推向更大的市场。
延续阅读
- 相关主题报道（纯文字索引，原载于 InfoQ 公众号，可搜索标题查阅）：《Cisco 给 9 万员工配上个人 Agent：记住你的一切，还能替你跨系统办事》《腾讯混元 Hy4 preview 开源，WorkBuddy 实测：有了小型团队交付实力，但还得有人盯》《Meta 用一整年证明 Agent 无法取代员工：事故增四成，工程师救火多七成》
- 会议信息：QCon 全球软件开发大会·2026（上海站）聚焦“Harness AI 时代的工程实践”，议题方向包括 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型。大会邀请全球技术社区与产业一线实践者，分享 AI Native 时代最具价值的工程经验。
- 本文内容基于 InfoQ 原创报道整理，访谈对象包括唐刘（TiDB）、茹炳晟（腾讯研究院）、Remy（Floatboat Harness 架构师）、天猪（字节 Trae）及多位海外实践者。