为什么模型越来越强，AI Coding 反而更依赖工程系统？|agent|上下文|代码|工程系统|新论文|调用

AI Coding 的瓶颈正在从模型能力转向工程环境的设计。Harness Engineering 作为一套可运行、可约束、可验证、可演化的工程支架，将决定 AI Agent 能否稳定完成复杂任务。本文将深入解析 Harness 如何解决状态持久性、目标一致性等核心挑战，并探讨工程师角色在 AI 时代的关键转变。

最近，我一直在反复琢磨网上刷到的一段话。它并非我的原创判断，但我非常认可。更准确地说，我觉得它把AI Coding和Agent系统里两个最关键的问题，压缩成了一组非常凝练的判断。

AI Coding的效率不取决于模型的能力，而取决于所使用的架构是否支持多工作树、低冲突合并；AI的能力边界也不取决于模型的能力，而取决于工程过程可被token化的范围边界在哪里。

如果只停在这句话本身，它像是一个架构判断。但结合最近关于Harness Engineering的讨论，再回头看这句话，我觉得它其实说的是同一件事：AI Coding的真实瓶颈，正在从“模型能不能写代码”，转向“我们有没有为Agent建好一套可运行、可约束、可验证、可演化的工程环境”。而这个“工程环境”，正是 Harness Engineering 试图命名和系统化的东西。它不是为了给 Agent 增加一个新名词，而是为了回答一个更现实的问题：当模型已经足够会写代码之后，我们到底要怎样组织环境、工具、状态和反馈，才能让它稳定地完成真实工程任务？

一、Harness到底是什么

Harness 不是某个单一产品，也不是传统制造业里的线束工程，更不是把 Workflow 换个名字。它更像Agent外侧的一整套工程支架：环境、工具链、权限、上下文、状态、验证、观测、反馈、回滚、清理和人类介入机制。

如果用一个公式概括，就是：Agent=Model+Harness。模型提供能力，Harness决定这种能力能不能稳定落地。

这也是为什么“马、马具与骑手”的隐喻很有解释力。模型像一匹能力很强的马，速度快、力量大，但如果没有马具、缰绳、路线、反馈和骑手，它并不会自动奔向业务目标。人类工程师也不再只是亲自写每一行代码的人，而是那个设计路线、设置边界、观察偏差并持续调校系统的人。

Harness工程把Agent放进环境、工具链、约束、验证与反馈闭环中

二、Prompt、Context、Harness不是并列关系

但仅仅知道Harness是“工程支架”还不够。因为在实际讨论里，它很容易和Prompt Engineering、Context Engineering混在一起。如果不先理清三者的层级关系，后面谈多工作树、RAG、验证闭环时，就容易把不同层面的问题混为一谈。很多人容易把Prompt Engineering、Context Engineering和Harness Engineering当成三种并列方法。但更准确的理解是，它们是逐层包裹的关系。

Prompt Engineering解决的是表达问题：我要怎么说，模型才更容易理解我的意图。Context Engineering解决的是信息问题：我要让模型在正确时间看到哪些事实、约束和背景。Harness Engineering解决的是执行问题：当任务变成长链路、可操作、低容错的真实工程任务时，系统如何保证它持续正确、可恢复、可验证。

所以，Prompt是入口，Context是燃料，Harness是运行系统。只靠Prompt，你得到的是一次回答；加上Context，你得到的是更接近真实环境的判断；真正进入Harness，你才开始拥有一个能持续工作的Agent。

这正好对应两个判断：多工作树低冲突合并，是Harness的执行层问题；工程过程可被token化，是Harness的信息层问题。两者合在一起，才构成AI Coding真正的生产力基础。

三、为什么模型越强，系统问题反而越明显

如果说上一节是在说明 Harness 的位置，那么接下来要看的就是：为什么它会在今天变得如此重要。答案并不复杂——因为模型越强，越会把原本隐藏在工程流程里的系统问题暴露出来。过去两年，很多团队经历过同一种幻觉：模型升级之后，工程效率应该自然上升。更高benchmark、更长上下文、更强推理能力，听起来足以解决问题。但现实通常没有这么简单。

原因在于，模型能力提升会放大单次输出质量，却不一定降低系统整合成本。一个更强的Agent可以生成更大、更复杂、更自信的改动；如果工作树隔离、任务边界、验证协议和合并机制没有跟上，它带来的不是吞吐量提升，而是更大的冲突面。

这就是Harness Engineering出现的现实背景。Agent不是不够聪明，而是在真实工程环境里会暴露五个根本问题：状态难以持续、目标容易漂移、行动难以验证、系统会熵增、人机边界不清。模型越强，这些问题越不能靠“再试一次”解决。

真正的工程策略不是让Agent try harder，而是把每一次失败转化为Harness的一部分：错过架构边界，就写成lint或结构测试；忘记历史决策，就放进可检索、可版本化的知识库；功能看似完成却没有验证，就补上端到端测试、日志、截图、指标和审查循环。

四、AI 工程范式的五次推进

这些失败并不是某个团队的偶发现象，而是整个 AI 工程范式推进到一定阶段后必然遇到的问题。换句话说，Harness 不是突然冒出来的概念，它是前面几轮能力演进之后必然出现的工程补课。Harness不是突然冒出来的概念，它是前面几轮能力演进之后必然出现的工程补课。

第一阶段是生成时代。ChatGPT、Copilot、代码补全、文档问答，让模型第一次大规模进入开发流程。但它主要解决“生成内容”的问题，人类仍然负责拆任务、跑环境、验证结果和合并代码。

第二阶段是连接时代。插件、函数调用、早期MCP、工具调用开始出现。模型不再只是回答，而是可以连接外部系统。但连接本身并不等于可靠执行，工具越多，错误路径也越多。

第三阶段是推理时代。CoT、规划、Claude、DeepSeek 等能力让模型可以拆解复杂任务。问题也随之变成：它能想清楚，不代表它能在长期任务里保持状态、遵守边界、完成验证。

第四阶段是行动时代。Codex、Operator、Manus 一类系统开始让Agent进入真实工作流，打开浏览器、写代码、跑命令、提PR。此时最大的瓶颈不再是能不能行动，而是行动后如何被约束、被观察、被纠错。

第五阶段就是治理时代，也就是Harness Engineering开始成为主线。行业的核心问题从“能不能让Agent干活”，转成“怎样让Agent在系统里稳定、可控、低成本地干活”。

五、Agent 的五个根本挑战

那么，所谓“稳定、可控、低成本”，具体会卡在哪里？如果把Agent放进真实工程链路，而不是只看一次性Demo，最核心的问题大致可以拆成五类。

第一是状态持久性。Agent的上下文窗口不是可靠记忆，长任务里最容易丢掉的是中间决策、未完成事项、失败原因和下一步计划。Harness要做的不是把所有历史塞进上下文，而是建立 durable state surfaces：计划文件、进度记录、决策日志、任务状态表、已验证事实列表。

第二是目标一致性。Agent很容易在执行过程中被局部任务吸引，最后做出一个“看起来完成”的半成品。Decomposition and Plans的价值就在这里：把大目标拆成可验收的小目标，把每一步的完成标准写清楚，并让计划成为可更新、可交接的制品。

第三是行动可验证性。AI Coding最大的危险不是写错代码，而是写错之后看起来没错。Harness必须把验证从“模型自我感觉良好”变成外部信号：测试、日志、trace、浏览器操作、截图、性能指标、CI、审查Agent。

第四是熵增抑制。完全自主的Agent会复制代码库里已有的坏模式，重新实现已有功能，制造重复抽象，让文档变旧，让边界变模糊。Entropy Control的意义，是让清理速度跟上生成速度：后台清理任务、质量评分、架构违规扫描、文档新鲜度检查，都应该进入常态。

第五是人机边界。Harness不是为了让人消失，而是把人放到更高杠杆的位置。人类应该负责目标、边界、品味、优先级和风险判断；Agent负责执行、验证、修复和整理。人什么时候介入、介入什么、介入后如何沉淀成系统规则，是Harness成熟度的重要标志。

六、六个真正该建设的工程构件

也正因为这些挑战都不是单靠提示词能解决的，Harness最终必须落到具体的工程构件上。它需要把“记忆、计划、反馈、可读性、工具使用和熵管理”变成系统能力，而不是靠某次对话里的临时提醒。我会把生产级Coding Agent Harness拆成六个具体建设方向。

第一，Durable State Surfaces：为长任务建立可持久化的状态表面。不要指望模型记住一切，要让计划、决策、失败、验收条件和剩余工作都落到文件、issue、PR 描述或结构化数据里。

第二，Decomposition & Plans：把任务拆解变成一等公民。优秀的 Harness 不只是让 Agent 写代码，而是让它先形成可审查的执行计划，再按小步推进，并在每一步留下可交接记录。

第三，Feedback Loops & Sensors：让环境主动反馈，而不是让模型自己猜。日志、指标、trace、浏览器自动化、单元测试、端到端测试、静态分析，都是 Agent 的传感器。传感器越好，Agent 越容易纠错。

第四，Legibility：让系统对 Agent 可读。过去我们强调代码对人可读，未来还要强调代码、文档、目录结构、错误信息、工具输出对 Agent 可读。一个 Agent 看不懂的系统，对它来说就像不存在。

第五，Tool Mediation：工具不能只是暴露接口，还要被调解。哪些工具可以用，什么时候用，输出如何压缩，错误如何解释，权限如何收敛，成本如何控制，都属于Harness设计。

第六，Entropy Control：把清理、去重、重构、文档同步和架构守恒做成持续机制。AI 系统真正的危险不是某一次错，而是小错以高吞吐速度累积成结构性漂移。

RAG 的关键不是堆资料，而是把隐性知识转成可检索、可引用、可操作的信息

在这六个构件里，最容易被误解的其实是“知识系统”。很多团队一提到知识系统，就会立刻想到RAG、向量库、文档切片和检索增强。但在Harness语境下，RAG的意义不只是帮模型多看几篇资料，而是把工程知识变成Agent可以调用的记忆层和约束层。

我之前说，AI的能力边界取决于工程过程可被token化的范围。放到Harness语境下，这句话可以说得更准确：知识库不是给模型看的资料仓库，而是Harness的记忆层和约束层。

真正有价值的RAG，不是把PDF转成文本，也不是把所有文档扔进向量库。它要回答的是：哪些信息必须进入Agent的工作环境？哪些经验必须从人脑和聊天记录里迁移到可版本化的知识系统？哪些规则必须从文档升级为机械化检查？

OpenAI的实践给了一个很好的启发：不要把AGENTS.md写成千页手册，而应该把它当成地图。入口文件保持短、稳、可维护，详细规则放进docs/、架构文档、执行计划、质量评分、设计原则和工具说明里，按需加载。

这就是渐进式披露。Agent不需要在第一秒看完世界，它需要知道哪里能找到正确的信息。上下文不是越多越好，而是越相关、越结构化、越可验证越好。

多Agent并行不是重点，边界、验证和合并协议才是重点

如果说RAG解决的是Harness的信息层问题，那么多工作树解决的就是执行层问题。前者决定Agent能不能看到正确的知识，后者决定Agent能不能在低冲突、可隔离、可验证的环境里行动。再回到多工作树。很多人把多Agent并行理解成“让更多模型同时写代码”，这其实只看到了吞吐，没有看到合并。真正的多工作树Harness，不只是给每个Agent一个分支，而是给它一个隔离的运行环境。

一个成熟的工作树应该包含独立依赖、可启动应用、任务级日志、可查询指标、测试命令、浏览器自动化入口、PR模板和合并协议。这样Agent才能在自己的沙箱里完成“实现—验证—修复—再验证”，而不是把半成品丢给人类收拾。

低冲突合并的关键，也不是合并时更聪明，而是开始时切得更好。任务边界、输入输出契约、依赖方向、文件所有权和验收标准越清楚，最后的merge conflict越少。

这也是为什么Harness和Workflow不完全一样。Workflow更像预设流程，适合确定性链路；Harness更像可执行环境，既有确定性护栏，也允许Agent在边界内自主探索。该确定的地方确定，该灵活的地方灵活。

九、不要把验证交给同一双眼睛

但隔离执行并不等于正确执行。一个Agent即使在独立工作树里完成了实现，也仍然可能误解需求、漏掉边界条件，或者生成看似合理但不可用的代码。所以，工作树之后必须接上另一个问题：验证。Harness讨论里有一个很容易被忽视的问题：怎么验证Agent真的做对了事。很多团队会让AI写测试，再用AI写出来的测试验证AI写出来的代码。这当然有价值，但不能成为全部。

如果验证只来自同一个模型、同一个上下文、同一套假设，它很容易形成闭环幻觉。更可靠的方式，是让验证来自多个独立信号：确定性的lint、结构测试、真实浏览器操作、日志指标、用户路径replay、独立评估Agent、人类审查，以及线上反馈。

Anthropic的Planner、Generator、Evaluator 三角色拆分，本质上就是在把“做事”和“评价”分开。OpenAI把Chrome DevTools、日志、metrics、traces 暴露给 Codex，也是在让Agent 面对外部世界，而不是面对自己的解释。

所以，未来AI Coding的关键指标不会只是“模型一次能写多少代码”，而是“系统能用多少外部传感器验证它写的代码”。

十、工程师角色正在变化

一旦验证、反馈、约束和状态都被纳入Harness，工程师的角色也会随之改变。因为此时人的价值不只是亲手完成任务，而是设计一个让Agent更少犯错、更容易恢复、更能持续改进的系统。如果Harness成为主线，工程师的工作会发生一次很深的迁移。过去工程师主要写代码、调接口、修bug；现在越来越多的高杠杆工作，会变成设计环境、定义边界、编写规则、构建反馈回路、维护知识系统和治理熵增。

这不是工程师价值下降，而是价值层级上移。一个好的Harness工程师，不只是知道怎么让模型完成当前任务，还知道如何把这次任务中的经验沉淀成系统能力。

Agent犯错后，低水平做法是重新写prompt；中等水平做法是把正确答案告诉它；高水平做法是问：这个错误为什么在系统里能够发生？我能不能通过文档、工具、测试、lint、权限、状态记录或反馈闭环，让它以后更难发生？

十一、如果现在要落地，先做这几件事

当然，Harness Engineering听起来很大，但落地时不必一开始就做成完整平台。更现实的路径，是先从几个高频、低成本、收益明显的动作开始，把Agent最容易失控的地方先机制化。

第一，把AGENTS.md 或类似入口文件变成地图，而不是百科全书。它应该告诉Agent项目结构、关键边界、该去哪里找资料，而不是塞满所有规则。

第二，把团队知识仓库化。写在聊天记录、会议口头结论和个人脑子里的知识，对Agent来说等于不存在。关键决策、架构约定、测试策略、异常处理和产品原则，都应该进入可版本化、可检索的知识系统。

第三，先把约束机械化。依赖方向、文件命名、日志结构、schema 边界、API调用规范、测试覆盖要求，能用 lint、CI、结构测试表达的，就不要只写在文档里。

第四，给 Agent端到端验证能力。让它能启动应用、操作浏览器、读取日志、查询指标、复现bug、录制前后状态，而不是写完代码后只说“我已经完成”。

第五，建立熵管理节奏。定期让Agent扫描重复实现、过期文档、架构漂移、未关闭计划和低质量模式，持续开小PR清理，而不是等技术债变成大问题。