在2026 年之际，团队与团队之间的差距，做项目别先问它接的是谁家的模型，别先问它支持几个 Agent，别先问它有没有自动化闭环。先问更底层的东西：它让模型怎么做 context 管理，能动什么，不能动什么；它怎么做权限隔离；它怎么接工具；它怎么测试结果对不对；它怎么把失败变成以后不再复发的规则；它怎么控制成本；它在什么地方必须把决定权还给人——它给模型搭了一套"怎样的执行体系"——这些问题一旦问出来，很多表面的热闹会自动褪色。模型在商品化，Harness 在资产化。
前阵子Anthropic 的 Claude Code 曾在公开发布的 npm 包里误带出一个 .map 文件，外界据此可还原出大量 Claude Code CLI 源码。很多人第一反应都差不多：去看 Prompt，去看系统提示词，去看它到底藏了什么“祖传秘方”。但这次真正值得研究的，其实不是 Prompt，也不是模型参数，而是执行体系。这种反应也很正常。过去两年，大家已经被训练形成了一种条件反射了，只要看到一个牛逼的Agent，先怀疑它是不是写了什么神Prompt，或者偷偷接了什么更强的模型。
你会发现，真正让一个 coding agent 像个“系统”而不是“聊天框”的能力，几乎都不在模型里。它在文件系统怎么挂载，在终端命令怎么跑，在上下文怎么压缩，在权限怎么管控，在测试结果怎么回传，在失败以后怎么回滚，在什么时候必须停下来等人验收。换句话说，最有工程含量的部分，恰恰是很多人以前最容易忽略的那一圈“模型之外的东西”。
这也是为什么，从2025中旬到2026年，AI Agent 领域出现了一个很重要的概念收束：Harness。
如果说前两年大家还在争 Prompt Engineering、Context Engineering 谁更重要，那么这两年更现实的问题已经变成了另一句：为什么模型越来越强，但很多不可思议的能力反而诞生于模型之外？
这个问题，不解释清楚，就很难真正理解 Harness这种东西到底是做什么的。
这类误解之所以普遍，不是因为大家不懂技术，而是因为模型演示太容易让人产生幻觉。你看见的是一句话生成一段代码、一个任务自动分解成几步、一个网页被 Agent 点完流程。你以为问题已经从“模型搞不搞得定”变成“产品什么时候发”。但实际跑起来，最先塌掉的往往不是推理，而是执行。
一个 Agent 回答得很像回事，不代表它真的能工作。它可能不知道本地项目怎么打开，不知道该读哪份文档，不知道哪个命令危险，不知道测试失败该停还是该重试，不知道这个 PR 到底算不算完成。它甚至可能一路做对了 80%，最后死在一个再普通不过的验收问题上：谁来确认结果是对的？用什么标准确认？确认错了谁负责？
这也是为什么 OpenAI 那个故事“三个人、五个月、百万行代码”，真正该看的不是数字本身，而是另一个更扎眼的事实：底模虽没有跟着突变式升级，产能却发生了迅猛变化。差距不在模型，在环境，这些主要来自文档体系、架构约束、自定义 lint、UI 与日志反馈、持续重构这些模型之外的东西。
这件事如果说得更直接一点，就是：不是模型突然会“自己做软件工程”了，而是有人给它搭了一个能做软件工程的私域。让它知道了——它怎么管理上下文，怎么编排工具，怎么控制命令执行，怎么把结果重新格式化给模型消费，怎么在长任务里做压缩和续写，怎么把一个很聪明但并不稳定的推理引擎，约束成一个合格的worker。
以前大家最先卡在“模型听不懂”。现在越来越多团队真正卡住的，是“模型听懂了，但系统接不住”。
接不住，往往不是因为一句话没说好，而是因为环境没建对，工具没封好，权限没收住，上下文没喂准，反馈没闭环，验收没定义，成本没算明白，协作没分清…
这就是 Harness 开始变重要的背景。它不是一个新词突然火起来那么简单，它更像是行业终于给这堆“模型之外的东西”起了一个统一名字。
如果前面那些问题都不存在，Harness 这个词也不会这么顺利地粉墨登场。正因为大家开始系统性地撞上“模型之外”的墙，这个词才突然重要起来。它不是为了发明一个新术语，而是为了给过去两年 Agent 工程里最难讲清楚的部分起个名字。
我很喜欢 Harness 这个命名，通俗易懂，它有“马具”的意思。简而言之，这是给模型/agent这类烈马套的东西，做Harness Engineering 的，就是研究怎么给模型搭一个能长期工作的执行环境。不是只让它会答题，而是让它能拿状态、用工具、受约束、收反馈、过验收、被停止、被交接。它不是 API 外面那层薄薄的包装壳，更像一整套运行的”秩序”。
后来有人把这件事说得更清楚了，LangChain 把 harness 解释为“除模型本身之外的所有代码、配置与执行逻辑”，在《The Anatomy of an Agent Harness》中把 harness 拆得很具体：system prompts、tools / skills / MCP、文件系统与沙箱、编排逻辑、hooks / middleware，这些都属于 harness；
Martin Fowler 则进一步把它抽象成“Guides” 与 “Sensors”：前者负责先把路栏出来，别让 Agent 一上来就乱跑，后者负责在它行动之后不断告诉它，哪里偏了，哪里错了，哪里该停；
OpenAI 的实践里，AGENTS.md、文档体系、架构约束、自定义 lint、UI 和日志反馈、持续“垃圾回收式”重构，也都属于harness。
公开案例已经反复说明：当模型不变时，性能差距依然可以非常大；差距往往就出在 Harness。
可以看下面这张表，汇总的是 截至2026 年上半年几组最有代表性的公开案例：
即便模型变强之后，最先暴露出来的不是“模型能不能办”，而是系统接不住它的行动。它不知道该先读哪份文档，不知道哪个命令危险，不知道失败后该停还是该重试，不知道什么时候该把决定权还给人。于是，问题就不再是“模型够不够强”，而是“你有没有给它搭好一套能长期工作的执行系统”。
话也要说回来，即使Harness 很重要，但它也绝不是一切问题的终点，甚至很容易发展成新的问题。
你加一个 evaluator，再加一个 rubric，再加一层 tool guardrail，再加一个 review agent，系统看起来越来越稳，实际上也可能越来越像控制塔迷宫。传感器多，不代表关键风险都被覆盖；控制多，也不代表维护成本能承受。
Martin Fowler 的文章本身也承认，行业现在仍缺少足够成熟的办法去衡量 harness 覆盖得是否到位。
Anthropic 的案例已经给了一个很直白的提醒：从 20 分钟、9 美元到 6 小时、200 美元，这套Muti-Agent 生成评估结构，也不是小团队随便就能接受的现实代价，质量提升是真的，但开销也是真的。
Harness 的世界观很正确，不等于每个场景都值得上最重的 Harness。很多时候，短链路、简单规则、人工复核，反而是更好的产品答案。
今天很多 Harness 都紧紧嵌合在具体代码库、具体文档结构、具体权限模型、具体数据 schema 上。离开原来的环境，它就不一定还能工作。这也是为什么很多团队看别人案例很激动，自己照着搭却跑不动。你抄得到框架名，抄不到组织内部那套成熟的体系。
Anthropic 在同一篇文章里也写得很清楚：每个 harness 组件，其实都编码了一个假设——“模型自己做不好这件事”。但模型在变强，这些假设会过时。
Harness 一旦做得太厚，模型会被塞进一个过窄的通道里，最后不是更强，而是更僵。更麻烦的是，很多控制逻辑其实编码的是“上一代模型的局限”。模型一升级，这些补丁可能就从护栏变成噪音，从安全层变成技术债。好的 Harness 团队，除了知道该加什么，也要不断问一句：现在还能删掉什么。
环境、工具、上下文、权限、评测、反馈、验收、成本、协作这些东西，决定了模型能力到底能兑现成多少生产力，这是我理解 Harness的真正入口。
这也是“同模不同命”开始变得越来越常见的原因。一个模型，放进简陋流程里，可能只是个会说话的外包实习生；放进一套成熟 Harness 里，结果能像换了一个物种。
更关键的是，Harness 里装的不是”通用聪明”，而是组织自己的规则、口味和风险承受方式。你的代码规范、审批流程、知识结构、失败预算、业务边界、验收标准、协作习惯，最后都不是挂在墙上的文化口号，而是被编码进 Harness 里的。模型换了也许还能跑，Harness 换了往往就像换掉一整套业务神经。
从这个角度看，所谓“模型之外的一切”，恰恰是企业最难抄的部分。因为那里面不只是工程，还有组织经验，还有人类长期积累出来的 taste。什么该自动，什么该卡住；什么能放权，什么必须人工兜底；什么值得多花 token，什么宁可退回简单规则。真正的护城河，不是你比别人更早接到模型，而是你更早把这些判断固化成可运行、可治理、可迭代的系统。
因为模型可以换，API 也可以迁移，但你公司自己的代码规范、权限体系、知识结构、评审方式、容错边界、成本预算、协作路径，并不会自动跟着模型一起长出来。真正难抄的，不是“你接了哪家模型”，而是“你把这些组织经验编码进系统没有”。
从这个角度看，所谓“模型之外的一切”并不是边角料，反而是企业最难复制、也最容易沉淀为壁垒的部分。
如果一个团队开始认真经营这些东西，那它做的就已经不是“把模型接进业务”。它做的，是把业务本身，翻译成一套模型能够长期活在里面的秩序。
本文由 @梅万枢 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自AI生成，由作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。