模型越强，为何工程重点转向Harness？
我们近期围绕Agent、Skills、OpenClaw等主题的探讨，实则始终在追踪一个核心议题：随着人工智能模型的能力日益增强，工程实践中的瓶颈究竟将向何处转移。
在之前的系列文章中，这一问题以分散的形式呈现。撰写《跟Cloudflare大佬学用 Claude Code》时，我们聚焦于如何将架构决策注入AI工作流；在《Skills 详解》中，我们剖析了如何将提示词与方法论体系化并纳入文件系统管理；而在《深度拆解 Clawdbot（OpenClaw）架构与实现》一文里，则深入探讨了队列、权限、回放、语义快照等机制如何提升Agent系统的稳定性和可控性。
经过近期对一系列材料的集中研读，我逐渐意识到，这些看似独立的主题，最终都汇聚到一个关键概念上：Harness。
OpenAI在讨论它，Anthropic在讨论它，Mitchell Hashimoto在讨论它，几乎每个从事Coding Agent开发的团队也都在讨论它。许多文章将其翻译为“壳”、“马具”或“操作系统”。这些译法各有其道理，但我所关注的焦点并不仅限于翻译本身。
Harness一词真正引人深思之处在于，它标志着AI工程的重心正在发生一次根本性转移：从“如何让模型给出更准确的答案”，转向“如何让系统更可靠地交付可用的结果”。
模型本身的重要性毋庸置疑。但恰恰因为模型已经强大到足以真正融入实际工作流程，包裹在模型之外的那一层系统工程才变得不容忽视，无法再以临时凑合的方式应对。
相同的模型，保持提示词与输入数据不变，仅仅改变其运行框架与协作方式，就能在编程基准测试中将成绩从42%提升至78%。Anthropic的研究也提供了类似的例证：同一个模型在单打独斗时看似完成了任务，实际运行后核心功能却存在缺陷；当换用一套包含规划、生成、验收环节的运行时框架后，虽然成本和时间有所增加，但最终产出的结果反而是真正可用的。
此事令人警醒的，与其说是某个具体的性能数字，不如说是背后所揭示的趋势性变化。
过去两年间，关于AI的讨论大多集中在模型本身：模型是否足够强大，上下文长度是否足够，推理能力有无实质性提升。
如今，这些问题依然关键。然而，一旦你真正开始尝试让Agent编写代码、阅读仓库、运行测试、操控浏览器、修复CI流水线，便会迅速发现，拖慢进度的往往不再是能力瓶颈，而是稳定性问题。Agent可能会偏离任务目标，会错误地判定自己已经完成工作，也会在你不经意间悄然改变输出的形态与质量。
而这些问题，多数发生在模型之外的系统层。
本文将尝试梳理这条脉络，探讨Harness究竟旨在解决什么核心问题，以及它与我们先前探讨过的那些主题之间存在着何种内在联系。
核心摘要
- • 若将《跟Cloudflare大佬学用 Claude Code》、《Skills 详解》、《深度拆解 Clawdbot（OpenClaw）架构与实现》等文章并列审视，可以发现它们实质上都在弥补模型之外的系统层能力。
- • Harness可以粗略地理解为“将模型接入真实工作流程的控制系统”，其内涵不仅包括工具调用，更涵盖状态管理、约束设定、反馈循环与结果验收。
- • 它当前变得如此重要，原因非常直接：一旦模型开始执行具有实际影响的操作，系统层的问题暴露速度将远超其能力不足的问题。
- • 具体的实现方法会随着模型本身的迭代而不断演进，但知识沉淀、硬性约束、反馈回路、完成标准等底层问题并不会自动消失。
- • 如果现阶段着手构建Harness，建议优先关注统一知识入口、硬性约束机制和验证闭环的设计，之后再考虑多Agent协作与复杂流程编排。
超越“外壳”：重新理解Harness
许多人初次接触Harness这个概念，会本能地将其理解为“包裹在模型外部的一层包装”。
这种理解并不算错，但远远不够全面。
如果只是为了构建一个简短的对话应用，你确实可以将其视为包装层。一个聊天界面，加上一个消息循环，再集成几个工具调用，系统便大致可以运行。
然而，一旦任务变得冗长、复杂且具备连续性，事情就不再是“简单包裹一层”这么简单了。
模型自身不具备持久化状态的能力，不会主动维护工作目录的完整性，无法自动判断某次输出是否已满足所有系统预设的约束条件，也缺乏对何时停止、何时继续、何时回滚的天然感知。它当然也不会自发搭建测试环境，更不会在代码编写完成后自觉地启动浏览器、进行页面交互、检查运行日志，并据此决定本次提交能否最终合并。
因此，我现在更倾向于将Harness理解为另一种存在：
它不是套在模型身上的僵硬外壳，而是将模型安全、可控地接入工程世界的那一套控制系统。
首先，通过一张图来直观展示其涵盖的范围：
这套系统通常包含以下几类核心组件：
- • 状态管理：如何保存和恢复任务执行的中间状态。
- • 工具暴露：如何以安全、可控的方式向模型提供操作能力。
- • 权限约束：如何划定模型的操作边界，防止越权行为。
- • 输出验证：如何对模型的产出进行自动或半自动的校验。
- • 上下文管理：如何高效组织与任务相关的信息和历史。
- • 任务续跑：如何在中断后准确地从断点恢复执行。
- • 完成标准：如何明确定义任务“真正完成”的客观条件。
将这几项拆解来看，你会发现它们并不新奇，甚至很多都是软件工程领域的常见概念。文件系统、测试套件、日志记录、浏览器自动化、代码规范检查（Lint）、计划文档、审批流程，这些原本就是软件开发中极为普通的基础设施。
但当执行主体从人类工程师转换为AI模型时，它们突然重新变得至关重要。
因为模型最擅长的是基于模式的生成与联想，最不擅长的则是在多重约束下稳定地收敛到唯一或有限的最优解。
若将我们近期探讨过的文章放在一起审视，这一轮廓已相当清晰。
在《Skills 详解》中，我们分析了Skill为何能实现稳定运行。它旨在解决提示词漂移、方法失传、工作流难以复用等问题。本质上，是将原本依赖临场对话发挥的内容，沉淀到文件系统和版本控制体系之中。
在《跟Cloudflare大佬学用 Claude Code》中，我们介绍了Boris所倡导的Research -> Plan -> 批注 -> Implement流程。这套方法最具价值之处，在于它通过机制化手段，确保了架构决策能够被有效地注入到后续的执行流程中。
在《深度拆解 Clawdbot（OpenClaw）架构与实现》中，我们探讨了lane queue、allowlist、JSONL回放、语义快照等机制。这些都是在回答另一类问题：如何构建一个可控、可回放、行为可解释的Agent系统。
分开来看，它们似乎是三个不同的技术话题。但放在一起观察，其实都在做同一件事：将原本依赖模型临场发挥、充满不确定性的部分，改造为可沉淀、可约束、可验证的系统性工程实践。
深入研读这一轮相关资料后，还有一个直观的感受：真正快速演进的，往往并非那个最核心的执行循环本身，而是环绕在循环外围、不断增厚的工程化设施层：知识如何被集成进来，状态如何被持久化保存，权限如何被严格卡控，验收结果如何被有效反馈。正因如此，当前关于Harness的讨论，越来越接近于系统架构设计，而非某个孤立的技巧或提示词优化。
Harness兴起背后的驱动因素
如果将时间回溯至两年以前，你会发现当时业界关注的焦点是提示词工程（Prompt Engineering）。
核心问题在于：如何清晰地表达指令，使得模型能够按照预期生成回答。
随着模型上下文长度的增加和任务复杂度的提升，大家开始讨论上下文工程（Context Engineering）。问题也随之演变，从“这一句怎么写”转变为“应该将哪些信息纳入上下文，又该排除哪些”。
发展至今，我们进入了当前这个新阶段。
提示词工程与上下文工程当然没有过时。更准确地说，它们被纳入了一个更宏大、更系统性的问题框架之中。
如今更令人困扰的问题发生了转变：模型能够理解需求，但在一个复杂的、真实的工作系统中，它能否将任务从头到尾稳定、可靠地完成？
这也是为何近期围绕Harness的讨论材料，普遍带有强烈的“实战导向”色彩。
Mitchell Hashimoto提出Engineer the Harness，其出发点非常具体：每当Agent犯下一个错误，不应仅仅针对这次对话进行修补，而应将修复方式沉淀到系统规则或约束中，防止同类错误再次发生。
OpenAI的Codex团队阐述得更为直接。他们在从零开始构建并维护一个大规模代码库后，总结出的重点落在了三件事上：如何将代码仓库作为统一的知识来源入口，如何通过机械化的手段强制执行架构边界，以及如何利用Lint规则和测试用例在提交（PR）环节卡住错误的方向。
Anthropic提供的材料同样具有代表性。其中有一个看似朴素却分量十足的发现令人印象深刻：模型并不擅长评估自身工作的质量。
这句话看似平淡，却深刻揭示了实践中普遍遭遇的困境。页面看起来似乎完成了，但交互逻辑并未打通；核心功能大体正确，但边界条件一经测试便暴露出问题；代码能通过部分单元测试，但在系统层面已悄然偏离了原始设计意图。
这些失败案例的根源具有一致性：系统缺乏强制性的验证环节。
这也解释了近期Harness讨论中一个微妙的转向：大家越来越关心 “如何防止Agent自信地执行错误操作”。
AI工程的重点，正从纯粹的能力提升问题，转向系统的可靠性保障问题。
若将这一变化落实得更具体，我认为近期撰写的几篇文章，恰好可以对应这条演进线上的不同层次。
《跟Cloudflare大佬学用 Claude Code》探讨的核心，实质上是“先让AI充分理解系统、制定可行方案，再着手编写代码”。这对应的是流程层的Harness，旨在规范工作流。
《Skills 详解》探讨的核心，是将提示词和方法论从临时的对话框会话迁移至可版本化的文件系统，以对抗提示词的随机漂移。这对应的是知识层的Harness，旨在实现经验的沉淀与复用。
《深度拆解 Clawdbot（OpenClaw）架构与实现》探讨的核心，是队列、权限、记忆、回放、浏览器语义快照等机制如何协同工作。这对应的是运行时层的Harness，旨在保障执行过程的可控与可观测。
换言之，Harness对我而言并非凭空出现的新概念，更像是近期终于找到了一个恰当的词汇，可以将这些原本分散但内在关联的问题统一收纳、进行体系化思考。
Harness的核心价值在于引导“收敛”
如果将讨论进一步具体化，我认为当前许多团队补强Harness的努力，本质上是在构建三种关键能力：
- • 将隐性约束显性化
- • 建立有效的失败信号反馈机制
- • 明确并固化任务完成的客观标准
这三者一旦缺失，模型能力越强，系统在某些方面可能反而越难以管理。
回顾许多Agent产品的介绍，很容易被带入“功能特性视角”之中：集成了多少工具、是否支持并发操作、能否协调子Agent、是否可以连接浏览器或MCP（模型上下文协议）等等。
这些特性固然重要。但如果仅从这个角度理解Harness，很容易使其变得越来越臃肿，最终沦为一张简单的功能清单。
我更认同的一种观点是：Harness最宝贵的价值，在于它能够更有效地引导模型收敛到正确的行动路径上。
这背后至少包含三层含义。
第一层，是实现隐性知识的显性化。
人类工程师在团队中协作时，大量的判断依据并未明确写在代码里。哪些模块属于核心禁区、哪些目录是只读的、哪些设计约定必须被复用、哪些测试用例不通过就绝对不能合并——这些知识往往分散在团队成员的实践经验与默契中。
模型不具备这些经验。
因此，你越是期望它能长期、稳定地参与工作，就越需要将这些知识推入文件系统、转化为自动化规则、体现在工具的可访问性控制中，或是集成到清晰的报错提示里。许多团队将代码仓库视为唯一可信的知识源，本质上正是因为它是最容易被版本化、被评审、被机器自动化读取的载体。
第二层，是主动缩小问题的解空间。
这一点听起来或许有些反直觉。人们本能地认为，赋予模型更多工具、更自由的操作权限、更丰富的上下文信息，它应该会表现得更为强大。
然而，众多实战案例恰恰指向相反的结论。
工具过多，可能导致模型陷入选择犹豫。
上下文过于庞杂，有时会干扰核心判断，导致性能退化。
操作边界过于宽松，模型可能会在错误的方向上持续探索，渐行渐远。
一个更高效的Harness设计，往往致力于将执行路径梳理得更加清晰、明确，而非一味追求宽泛的自由度。明确界定哪些事情可以做、哪些事情禁止做、做到何种程度才算完成、失败后应优先检查哪些环节——这些规则越明确，整个系统就越容易达到稳定状态。
第三层，是将单向“生成”转变为有反馈的“闭环”。
许多人对AI工作的默认想象，仍然是输入一个需求，等待它输出一个答案。
但真实世界的工程任务并非如此。
真实的工作更像一个持续的循环：读取上下文信息、做出判断决策、执行具体动作、观察产生的结果、根据反馈修正方向、然后继续推进。
如果没有日志记录、自动化测试、浏览器交互验证、代码规范检查、评审规则等反馈节点的支撑，模型的生成能力再强，其产出也很容易停留在“看起来差不多”的水平，而无法达到“确实可用”的标准。
因此，从工程视角看，Harness不仅是赋予模型“手”和“脚”（执行能力），更像是在为模型安装“感官系统”（感知反馈）和“安全护栏”（行为约束）。
Anthropic关于长效运行Agent的总结中，有一段设计特别值得借鉴。它将任务状态外化到feature list、progress log、git提交记录等外部工件中，避免让Agent试图一次性完成所有工作，而是推动其按照固定的检查循环逐步推进：
这套机制看上去并不“炫酷”或“智能”，但却非常“工程化”。它正在将AI从“一个即兴发挥的代码生成器”，向“一个能够在待办列表、提交记录和运行日志构成的体系中持续跟进并推进任务的工作主体”拉近了一步。
演进的本质：方法更替，问题永存
论述至此，很容易将Harness描绘成解决一切问题的终极答案。
我并不希望这样表述。
一方面，这与本轮资料所揭示的事实不符。另一方面，也容易使文章的论点显得过于绝对。
Noam Brown等人提出的观点具有参考价值：许多在今天看来非常精巧的脚手架设计，半年之后随着模型能力的增强，其必要性确实可能大打折扣。一些原本需要靠复杂工程来弥补的能力短板，很可能被更强大的模型内核直接吸收。
Anthropic的案例就颇为典型。在旧模型时代，为了对抗长程任务中可能出现的性能退化而设计的特定流程，到了新一代模型阶段，或许就可以被简化或移除。昨天你还认为不可或缺的某层“补丁”，明天也许就成了多余的复杂性。
因此，我并不同意Harness会无限膨胀的观点。
但我同样不认为它会彻底消失。
更可能出现的情况是：具体的实现技术与方法会不断被更新、替换，但那些底层的、系统性的工程挑战将持续存在。
例如：
- • 上下文管理的需求永远存在。
- • 运行环境必须受到约束。
- • 产出结果必须经过验证。
- • 失败教训需要形成反馈。
- • 核心知识必须得以沉淀。
这些问题不会因为某一代模型的重大升级而凭空消失。只要你试图让一个生成式模型进入真实的、复杂的生产系统，它们迟早都会以不同的形式显现出来。
模型能力的增强，改变的大概是“问题出现的具体位置”和“表现的严重程度”。
以前你可能需要花费大量精力教导模型如何保持长上下文中信息的一致性。未来，这件事或许变得简单，但你可能会开始让模型执行周期更长的任务、集成更复杂的周边系统、承担更高程度的自主决策责任。届时，新的边界定义问题和新的反馈控制机制需求又会浮现出来。
因此，如果必须为Harness的未来下一个更为温和的论断，我会这样表述：
Harness并非一套固定不变的终极解决方案，它更像是一类随着技术演进而持续移动、形态变化的工程问题集合。
实践路线图：建议优先构建的五项能力
行文至此，最实际的问题便是：究竟应该从何处着手？
如果你是一位个人开发者，或是一个刚开始尝试将Agent深度融入工作流程的团队，我建议优先从以下五项基础能力开始构建，而非一开始就追求复杂的多Agent编排或炫目的功能特性。
1. 确立统一的知识入口
尽可能将一切必要的知识沉淀到代码仓库中。架构设计文档、目录结构说明、关键约束条件、项目计划文件等，都应尽量实现文本化、版本化管理。
避免将关键知识散落在口头沟通、即时聊天记录或团队成员的个体记忆中。
2. 保持指令文件的简洁性与导向性
类似AGENTS.md、CLAUDE.md的指引文件很有用，但切忌将其写成冗长的制度手册或百科全书。
它更适合扮演“导航目录”的角色，清晰地告诉模型“遇到某类问题，应该去哪里查找相应信息”，而不是试图在一次提示中灌输所有知识。
3. 优先采用硬性约束，而非单纯依赖提示词
对于架构边界、目录访问限制、测试覆盖率要求、代码规范（Lint）规则等，如果能够通过自动化工具或系统权限进行强制检查，就不要仅仅在提示词中写上“请遵守”。
模型可能会遗忘或忽略软性提示，但系统级别的硬性规则不会。
许多成熟Coding Agent的运行时设计也印证了这一点。更稳健的做法通常是构建一条分层的安全流水线，而非将所有判断都寄托于模型自身：首先匹配已有的授权规则，低风险的编辑操作走快速通道，对只读工具的白名单访问直接放行，只有剩下的、不明确的操作才交给独立的分类器进行判断。
这背后的设计思路值得学习：不要只追问“模型这次会不会犯错”，而应优先确保“系统是否在更早的环节就挡住了潜在的错误”。
4. 构建反馈闭环，而非单向任务派发
在模型执行完代码编写等操作后，它应当能够即时看到自动化测试的结果、浏览器中的实际表现、系统运行时日志以及任何错误提示信息。
一个缺乏反馈机制的Agent，极易将“生成了一份外观符合预期的输出”错误地等同于“任务已成功完成”。
Anthropic所采用的generator（生成器）与evaluator（评估器）角色分离模式，本质上也是在弥补这一点。在系统内部设立一个专门负责“验收”的角色，将生成与验收职责分离，形成制衡。
5. 谨慎引入多Agent协作
许多任务，通过单个Agent配合清晰、严格的约束条件就足以有效解决。
多Agent协作固然有其价值，但它同时会将状态同步、职责划分、上下文一致性维持等问题成倍放大。在单线程任务都尚未能稳定、可靠运行的阶段，盲目引入并行与协作，通常只会让系统变得更加混乱和难以调试。
这一点与我们之前在相关文章中的判断是一致的。尽管前文更侧重于部署实践，本文更关注方法论，但核心理念相通：优先搭建稳固、可靠的单任务执行框架，之后再考虑基于此进行职责拆分与并发优化。
完成这五项基础能力的构建，系统未必立刻变得无比先进或功能繁多。
但它会首先变得更可靠、更可预期。
而在当前这个发展阶段，我认为“可靠一点”远比“花哨很多”更为重要，也更为根本。
结语
经过这一轮的资料梳理与思考，我对于Harness的最终感受，其实颇为朴素。
它并未神秘到如同一个全新学科的诞生，也未简单到仅是“包裹模型的一层薄壳”。
它更像是一个标志，标志着业界开始认真承认一个早已存在的事实：要将模型有效地融入真实的生产工作流，真正的挑战从来都不只在于模型本身的能力上限。
模型负责打开可能性，提供强大的生成与推理潜力。
而系统则负责定义边界、设立护栏、提供反馈、验收结果，最终决定这些潜力能否被转化为稳定、可重复的交付成果。
边界如何设定？反馈如何及时、准确地回流？何种状态算作“完成”？任务意外中断后应从何处可靠地恢复？这些问题，最终都需要由精心设计的系统层来承接与解答。
过去两年，竞争很大程度上聚焦于“谁的模型更强大”。
展望接下来的阶段，我更倾向于将差距的拉开点看作是另一件事：
谁更早、更系统地将模型之外的那一层支撑体系，当作一项严肃的、专业的软件工程来对待和构建。
这可能不是最吸引眼球的话题，但很可能是那些志在长远、追求实效的团队无法绕开的核心课题。