AI Coding 的瓶颈正在从模型能力转向工程环境的设计。Harness Engineering 作为一套可运行、可约束、可验证、可演化的工程支架，将决定 AI Agent 能否稳定完成复杂任务。本文将深入解析 Harness 如何解决状态持久性、目标一致性等核心挑战，并探讨工程师角色在 AI 时代的关键转变。
最近，我一直在反复琢磨网上刷到的一段话。它并非我的原创判断，但我非常认可。更准确地说，我觉得它把AI Coding和Agent系统里两个最关键的问题，压缩成了一组非常凝练的判断。
AI Coding的效率不取决于模型的能力，而取决于所使用的架构是否支持多工作树、低冲突合并；AI的能力边界也不取决于模型的能力，而取决于工程过程可被token化的范围边界在哪里。
如果只停在这句话本身，它像是一个架构判断。但结合最近关于Harness Engineering的讨论，再回头看这句话，我觉得它其实说的是同一件事：AI Coding的真实瓶颈，正在从“模型能不能写代码”，转向“我们有没有为Agent建好一套可运行、可约束、可验证、可演化的工程环境”。而这个“工程环境”，正是 Harness Engineering 试图命名和系统化的东西。它不是为了给 Agent 增加一个新名词，而是为了回答一个更现实的问题：当模型已经足够会写代码之后，我们到底要怎样组织环境、工具、状态和反馈，才能让它稳定地完成真实工程任务？
Harness 不是某个单一产品，也不是传统制造业里的线束工程，更不是把 Workflow 换个名字。它更像Agent外侧的一整套工程支架：环境、工具链、权限、上下文、状态、验证、观测、反馈、回滚、清理和人类介入机制。
如果用一个公式概括，就是：Agent=Model+Harness。模型提供能力，Harness决定这种能力能不能稳定落地。
这也是为什么“马、马具与骑手”的隐喻很有解释力。模型像一匹能力很强的马，速度快、力量大，但如果没有马具、缰绳、路线、反馈和骑手，它并不会自动奔向业务目标。人类工程师也不再只是亲自写每一行代码的人，而是那个设计路线、设置边界、观察偏差并持续调校系统的人。
Harness工程把Agent放进环境、工具链、约束、验证与反馈闭环中
但仅仅知道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 工程范式推进到一定阶段后必然遇到的问题。换句话说，Harness 不是突然冒出来的概念，它是前面几轮能力演进之后必然出现的工程补课。Harness不是突然冒出来的概念，它是前面几轮能力演进之后必然出现的工程补课。
第一阶段是生成时代。ChatGPT、Copilot、代码补全、文档问答，让模型第一次大规模进入开发流程。但它主要解决“生成内容”的问题，人类仍然负责拆任务、跑环境、验证结果和合并代码。
第二阶段是连接时代。插件、函数调用、早期MCP、工具调用开始出现。模型不再只是回答，而是可以连接外部系统。但连接本身并不等于可靠执行，工具越多，错误路径也越多。
第三阶段是推理时代。CoT、规划、Claude、DeepSeek 等能力让模型可以拆解复杂任务。问题也随之变成：它能想清楚，不代表它能在长期任务里保持状态、遵守边界、完成验证。
第四阶段是行动时代。Codex、Operator、Manus 一类系统开始让Agent进入真实工作流，打开浏览器、写代码、跑命令、提PR。此时最大的瓶颈不再是能不能行动，而是行动后如何被约束、被观察、被纠错。
第五阶段就是治理时代，也就是Harness Engineering开始成为主线。行业的核心问题从“能不能让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清理，而不是等技术债变成大问题。
模型能力决定潜在上限，架构层与信息表达层决定实际吞吐量。
当这些事情逐步建立起来之后，开头那句话里的两个关键词“低冲突合并”和“工程知识token化”也就不再只是抽象判断，而会变成一套具体的工程系统。现在再看最初那句话，我会把它改写成一个更完整的版本：现在再看最初那句话，我会把它改写成一个更完整的版本：
AI Coding的效率不取决于模型能力本身，而取决于Harness能否把模型能力转化为低冲突、可验证、可持续的工程吞吐；AI的能力边界也不取决于模型理解力本身，而取决于组织能把多少工程知识、状态、约束和反馈表达成Agent可以读取、执行和校验的系统。
模型当然重要。没有足够强的模型，很多任务根本不会启动。但一旦模型能力跨过某个门槛，真正决定生产力的就变成系统。这个系统包括架构、上下文、工具、验证、状态、反馈、熵管理和人机边界。换句话说，就是Harness。
所以，如果你现在正在搭AI Coding系统，我不会先问你用了哪个模型。我会先问：你的Agent 在哪里运行？它看见什么？不能做什么？怎么知道自己错了？错了之后怎么恢复？它的输出怎么合并？系统如何防止每天高速产生的新代码变成明天的技术债？
这些问题的答案，比模型benchmark更能预测系统真实跑起来的样子。
工具会持续进化，但真正的门槛，往往藏在那些没有被充分表达、没有被机制化约束、没有被持续验证的地方。Harness Engineering的意义，就是把这些过去靠人脑、经验和默契维持的东西，变成 Agent 可以依赖的工程系统。
本文由人人都是产品经理作者【诗说红豆】，微信公众号：【诗说红豆】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。