有些团队3个人就能交付百万行代码，有些团队连一个稳定的重构都跑不出来。 很多人以为差别在模型——用GPT-5还是Claude Opus，调多少温度参数，写多完美的Prompt。
但真相远比这简单：差别不在模型，不在Prompt，而在Harness。
很多人对Harness有误解，以为它是system prompt、是API包装，或是Prompt模板——这些都不对。
Harness，是语言模型运行的完整设计环境，包含工具调用、信息格式、历史压缩、错误护栏和任务交接脚手架，是让AI Agent稳定产出的“底层操作系统”。
普林斯顿SWE-Agent论文给出了最直接的证明：用同一个GPT-4，只修改接口设计（也就是优化Harness），性能从3.97%提升到12.47%，相对提升64%。
要知道，没有任何一次模型升级，能带来这么大的性能飞跃。
就像IDE没有让人变聪明，却能减少摩擦、及时呈现信息、及早捕获错误——语言模型本身相差不大，但Harness这个“接口”，决定了AI能发挥出多大价值。
行业大佬早已达成共识：
☑️ OpenAI（Codex）：瓶颈从来不是模型能力，永远是环境设计
☑️ Anthropic（Claude Code）：Harness架构决定Agent能否持续进步
☑️ 普林斯顿（SWE-Agent）：接口设计带来的提升超过任何模型升级
OpenAI、Anthropic、普林斯顿三大顶级团队的Harness实践，虽场景不同，但核心逻辑高度一致，整合其精髓可形成可直接复用的实战模板：三大团队均通过优化Harness环境，在不升级模型的前提下，实现了AI Agent生产力的跨越式提升。
普林斯顿SWE-Agent靠搜索限流、100行文件查看器、带Lint的编辑器、上下文管理4个简单组件，让同一GPT-4模型性能提升64%；Anthropic用“初始化+编码”两阶段架构，搭配JSON格式任务清单、浏览器自动化，破解上下文过载难题；OpenAI Codex更实现3人团队5个月交付百万行零手写代码，核心在于结构化docs目录+短AGENTS.md的渐进披露模式、独立应用实例与全链路可观测性接入。
三者的共性经验的是：无需追求复杂模型，通过合理的环境设计（信息管控、架构约束、反馈闭环），就能让AI Agent稳定高效产出，这正是Harness的核心价值所在。
光说不练假把式，这3个顶级团队的实践，完美诠释了Harness的力量，也给出了可直接借鉴的路径。
整个Harness生态被清晰分为七层，从下到上价值递增，也能帮我们看清：真正的核心竞争力在哪里。
第1层（编码Agent）：Claude Code、Codex等，属于“商品级”，大家差距不大；
第2层（框架和运行时）：包含渐进披露、子Agent、结构化上下文，以及持久记忆、定时执行等能力；
第3层（Agent编排器）：支持多Agent并行，用Git Worktree隔离，让每个Agent在独立沙箱工作，互不干扰；
第4层（任务运行器）：连接Issue Tracker和编码Agent，实现“人创建Issue→运行器分配→Agent交PR→人审查”的闭环；
第5层（全生命周期平台）：端到端管理从需求到交付的全流程，集成AI提议、人类验证门和子Agent编排；
第6层（规格工具）：把人类想法变成结构化规格和任务DAG，AI提议任务图，人类只做验证和审批；
第7层（人类监督）：工程师审批方案、Review PR、设定优先级，核心是设计环境，而非亲自写代码。
关键结论：底层编码Agent是商品，上面六层Harness，才真正决定AI Agent的最终效果。长期护城河，从来不在模型，而在Harness。
不管是OpenAI、Anthropic还是普林斯顿，他们的Harness设计，都离不开这五个反复出现的核心模式，可直接复用：
1.渐进披露
不要一次给Agent所有信息，而是给最小定向信息+指向深层内容的指针。上下文开头的信息影响力最大，短小聚焦的入口，比全量倾倒更有效。
典型应用：OpenAI的docs/架构、SWE-Agent的搜索限流。
2.Git Worktree隔离
一个Agent一个worktree，拥有独立目录、独立分支、独立环境，让并行Agent互不干扰。变更在隔离环境验证后，再合并到主分支，避免风险扩散。
3.Spec First（规格优先）
规格和架构决策，必须编码到仓库的机器可读文件里。如果Agent从仓库读不到，对它来说就等于不存在——避免Agent依赖“人类脑子里的想法”，减少偏差。
4.机械式架构强制
人类Review跟不上Agent的产出速度，改用自定义linter+结构测试+CI替代，强制不变量，不管具体实现。而且linter错误消息要专为Agent设计，包含修复指令，让Agent能自主修正。
5.集成反馈循环
让错误在产生瞬间被捕获：语法错误由编辑时的linter捕获，运行时错误由可观测性工具查询，UI bug由浏览器自动化验证。行动和后果之间的间隔越短，Agent表现越好。
Harness不是遥不可及的复杂架构，搭建最小可行版本，今天就能开始，核心就4步：
1.持久进度文件
每次会话开始时读，结束时写，记录“上次做了什么、完成了什么、留下什么状态”，防止Agent“提前宣布胜利”，避免半途而废。
2.结构化任务清单
不是模糊描述，而是具体、可枚举、可验证的完成标准，每项都有状态标记，验证后才更新。防止“做了一半看起来做完了”的无效内耗。
3.Git版本控制
每次会话以git commit结束，保留回退机制——改坏了就revert到上次好的状态，版本控制就是Agent的“认知脚手架”，避免错误扩大。
4.浏览器自动化
只看代码的Agent和只看代码的开发者一样盲目，大多数重要bug只在运行时可见。让Agent能像用户一样操作应用，才能真正验证代码效果。
关键提醒，当Agent表现不好时，先做环境审计，而不是换模型：
-
Agent缺什么信息？→ 加工具或文档
-
哪里经常卡住？→ 缺什么反馈循环
-
上下文被什么污染？→ 改上下文管理策略
-
什么约束靠Agent判断？→ 改成机械检查
每个失败，都是环境需要优化的信号。
AI时代的工程师，最大的思维转变，就是放弃旧思路，拥抱Harness思维：
核心区别：投入在更好的Prompt上，只能解决这一个问题（临时、局部）；投入在更好的工具和环境上，能预防一类问题（永久、通用）。
而Harness，就是这份“永久投资”的存放之处。
｜结语
很多人痴迷于追逐更强的模型，却忽略了最基本的真相：模型是推理引擎，Harness决定推理引擎能完成什么。
AI Agent的竞争，早已经从“模型之争”，变成了“环境之争”。
对每一位AI时代的工程师来说，不用再纠结于Prompt的细节，不用盲目追求更强的模型——从搭建最小Harness开始，优化环境、完善规则、构建闭环，才能真正释放AI的生产力。
今天，就从创建一份结构化任务清单、提交第一次Git commit开始，开启你的Harness构建之旅吧。
