Harness Engineering正在彻底改变软件开发的游戏规则。从OpenAI的百万行代码实验到Anthropic的长任务Agent框架，这项技术让AI成为主力开发者，而人类转向设计控制框架。本文深度解析这一颠覆性趋势如何重构产品经理的角色定位，以及为何产品决策能力将比编程能力更具价值。

最近这段时间，如果你在技术圈子里混，不管是刷Twitter、逛Hacker News还是翻LinkedIn，你大概率会被一个词不断刷屏——Harness Engineering。

说实话，第一次看到这个词，我愣了一下。Harness？不就是”马具”吗？这跟写代码有啥关系？

但是当我花了整整一周时间，把OpenAI的原文、Anthropic的技术博客、Martin Fowler团队的分析、Bret Taylor的播客访谈，还有一堆社区讨论全翻了一遍之后，我确信：

这个概念，可能是2026年软件行业最重要的认知升级。

而且它不仅仅是给程序员看的。作为一个AI产品经理，我觉得这事儿跟我们产品人的关系，比跟程序员的关系还要大。

为什么这么说？别着急，听我慢慢讲。

一、先搞清楚：Harness Engineering到底是个啥？

要理解这个概念，先忘掉所有高大上的定义，咱们打个最通俗的比方。

你养过马吗？没养过也没关系。想象一下：你有一匹特别厉害的千里马，跑得飞快，力气也大。但是你直接骑上去，它可能往东跑也可能往西跑，可能一激动把你甩下来，也可能跑到一半突然停下来吃草。

怎么办？你需要一套完整的装备——缰绳、马鞍、马镫、嚼子，这一套东西合在一起叫”harness”，也就是马具。有了这套东西，千里马的力量还在，但方向你说了算，速度你能控制，安全也有保障了。

Harness Engineering说的就是这回事。

AI编程Agent就是那匹千里马。GPT-5也好，Claude也好，Codex也好，这些大模型已经能写代码了，而且写得越来越好。但是你让它自己撒欢跑，结果往往不可控——它可能写出一堆看起来对但其实有bug的代码，可能跑着跑着就偏离了你要的方向，也可能干到一半就觉得”差不多了”然后停下来。

Harness Engineering就是给这匹AI千里马设计和打造那套“马具”的工程学科。

它包括：你给AI什么工具用、什么信息看、什么规矩守、什么反馈收，以及人在什么时候介入。

用稍微专业一点的话说就是：设计AI Agent运行的环境、约束、反馈回路和控制系统，让Agent能在这个框架里稳定、可靠、持续地产出高质量工作成果。

Martin Fowler的团队说得好：这东西本质上是”元工程”——不是在做工程，而是在做“让工程发生的环境”。

二、这事儿为什么突然火了？

其实”给AI设定规矩”这个想法不新鲜。Prompt Engineering搞了好几年了，大家都知道要给AI写好的提示词。但Harness Engineering之所以在2026年初突然炸了锅，是因为几个标志性事件同时发生了。

第一炸：OpenAI的百万行代码实验。

2026年2月，OpenAI发布了一篇博客，标题翻译过来大概是”Harness Engineering：在Agent优先的世界里用好Codex”。这篇文章讲了一个让整个行业都震了一下的故事：一个小团队，在五个月内，用Codex Agent写了一个包含大约100万行代码的产品——没有一行代码是人手敲的。

你没看错，零行人写代码。所有的应用逻辑、测试、CI配置、文档、监控工具、内部开发者工具，全是Agent写的。工程师们干的事情就是写prompt、给反馈、做review。

他们说这个速度大概是纯人工开发的十倍。

第二炸：Anthropic的长任务Agent框架。

差不多同一时间，Anthropic的团队也发布了关于长时间运行Agent的harness设计研究。他们的核心发现是：让AI写一个小功能不难，难的是让它持续工作好几个小时甚至好几天，跨多个上下文窗口地推进一个大项目。

他们的解决方案是一套精心设计的多Agent架构——规划Agent、执行Agent、评估Agent，各司其职，通过结构化的中间产物互相传递上下文。关键词就是harness design。

第三炸：Martin Fowler的背书。

当Martin Fowler这样的软件工程思想领袖在Twitter上说”Harness Engineering是AI辅助软件开发一个有价值的框架性概念”的时候，整个技术社区就知道这不是一阵风，而是一个真正值得认真对待的方向。

第四炸：Bret Taylor的公开讨论。

OpenAI的董事长、Sierra的创始人Bret Taylor在近期的播客里也反复提到了harness engineering。他说了一句很有意思的话，大意是：他正在强迫自己不要对代码产生感情依恋——因为以前他是以自己写的代码的优雅为荣的，但现在游戏规则变了。

这四件事凑到一起，harness engineering这个概念就彻底出圈了。

三、Harness到底包含什么？拆开来看看

好，概念知道了，背景也知道了。那一个harness到底长什么样？里面都有啥？从我读到的各种资料来看，一个完整的harness大致包含以下几个核心组件。

1.上下文工程（Context Engineering）

这是harness里最关键的一块。

Agent的上下文世界 —— 代码仓库就是它的全部世界

AI Agent只能”看见”你喂给它的东西。你在Slack群里讨论的架构决策、你脑子里想的产品逻辑、你在Google Docs里写的需求文档——如果这些东西没有进入Agent的上下文窗口，对Agent来说就等于不存在。

OpenAI的团队发现了一个很深刻的道理：对Agent来说，代码仓库就是它的全部世界。 任何你希望影响Agent行为的知识，都必须被”物质化”——写成代码仓库里的文档、Schema、配置文件或者可执行的计划。

这就好比你带一个新员工入职。你跟他口头说”我们的代码风格比较偏函数式”，他可能左耳进右耳出。但如果你给他一份详细的代码规范文档、一套自动化的lint规则、一组参考示例，他就能快速上手了。对AI也是一样的道理，甚至对AI来说这一点更加重要——因为人好歹还能主动去问，Agent不会。

而且他们还发现，一开始大家喜欢搞一个巨大的AGENTS.md文件，把所有规矩都写在里面。结果发现完全不行：上下文是稀缺资源，一个巨无霸文件会挤占真正重要的信息；当所有东西都”重要”的时候，什么都不重要了；而且这种大文件会迅速过时，变成一个规则的坟场。

正确的做法是把AGENTS.md当成一个目录，大概就100行左右，里面放的是指向各个具体文档的指针。真正的知识库分门别类地放在结构化的docs目录里。

2.架构约束（Architectural Constraints）

这块听起来很抽象，但其实逻辑很简单：你不能光跟AI说“写好代码”，你得用机器可以自动检查的方式来定义什么是“好代码”。

OpenAI的团队做了一件很有意思的事：他们建立了一套非常严格的分层架构。在每个业务领域内，代码的依赖方向是单向的：Types → Config → Repo → Service → Runtime → UI。跨领域的东西只能通过Provider进入。

关键来了——这个规则不是写在文档里让人自觉遵守的，而是在CI层面强制执行的。如果你的代码违反了这个依赖方向，直接构建失败。

更绝的是，写这些lint规则的人是谁？是Codex Agent自己。

他们说了一句让我印象很深的话：这种架构约束通常是一个公司有了几百个工程师之后才会去做的事情，但在Agent优先的工程范式里，它变成了一个前置条件。 因为约束才是让速度不造成混乱的关键。

如果你细想，这其实很反直觉。我们以为给AI更多自由它会更强，但实际上，缩小AI的解空间反而能让它更高效——因为它不用浪费token去探索死胡同了。

约束即自由 —— 缩小解空间反而更高效

3.反馈回路（Feedback Loops）

这是让harness变成一个“活的系统”而不是一套死规矩的关键。

OpenAI团队的核心原则是：当Agent遇到困难的时候，不要想着”再试一次”或者”换个prompt试试”。正确的反应是——去找出是什么能力缺失了，然后把它补回到仓库里。而且这个”补”的动作，也让Agent自己来做。

这形成了一个持续改进的飞轮：Agent犯错 → 人类诊断根因 → 定义解决方案 → Agent把解决方案编码到仓库里 → 以后所有Agent都不会再犯同样的错。

Anthropic的方案更进一步。他们设计了一个类似GAN（生成对抗网络）的多Agent结构：有一个生成Agent负责写代码，有一个评估Agent负责打分审查。评估Agent不是简单地说”好”或”不好”，而是按照预定义的评分维度给出结构化的反馈。

为什么要单独搞一个评估Agent？因为他们发现了一个有趣的现象：让一个Agent评价自己的作品时，它几乎总是会自我表扬——哪怕在人看来质量很一般。这跟人一样，自己review自己的代码总是觉得挺好的。所以必须有一个”第三方”来做质量把关。

4.工具编排（Tool Orchestration）

Agent的能力取决于它能用什么工具

Harness的一个重要职责就是定义Agent能访问哪些工具、怎么调用、需要什么权限。

这包括文件系统访问、Shell命令、API调用、数据库查询、浏览器自动化等等。比如Anthropic的方案里，评估Agent可以启动一个浏览器，实际去”看”前端页面渲染出来的效果，然后基于视觉观察给出评分。

好的工具编排有一个原则：Agent必须清楚地知道它能做什么、不能做什么、什么需要人类批准。

5.生命周期管理和熵对抗

这是最容易被忽视但可能最重要的一环。

任何大型软件项目都会随着时间推移变得混乱——文档过时、代码风格漂移、架构边界模糊。OpenAI的团队专门设计了”垃圾回收”Agent，定期扫描整个仓库，找出文档里的不一致、架构约束的违反、以及各种腐化的迹象。

这些Agent就像是代码仓库的”保洁阿姨”，定时打扫卫生，防止技术债务悄悄堆积。

多Agent协作 —— 规划者、执行者、评估者

四、从产品经理视角看：这事儿跟我有什么关系？

讲到这里，可能有些产品经理朋友要问了：你说了半天，这不就是一个工程实践吗？跟我们做产品的有什么关系？

关系可大了去了。我甚至觉得，Harness Engineering这个趋势对产品经理的冲击，比对程序员的冲击还要大。

产品经理的新角色 —— 从催进度到定方向

1.产品经理可能成为”Harness的设计者”

还记得Bret Taylor说的那个概念吗？Sierra的客户们把自己的客户体验运营人员改名叫”AI Architect”（AI架构师）了。

在harness engineering的世界里，人的核心工作从”写代码”变成了”设计环境、表达意图、构建反馈回路”。

等一下，”意图表达“——这不就是产品经理天天在干的事情吗？

想想看，一个好的产品需求文档（PRD），本质上就是在”表达意图”——我要这个产品解决什么问题、为谁解决、解决到什么程度、有哪些边界条件。如果未来的开发流程是人写意图、Agent写代码，那写意图的那个人不就是产品经理吗？

更重要的是，Anthropic的研究发现，让Agent生成高质量的产品，关键不是技术细节的描述，而是产品级别的规划——要有野心但不要过度具体的技术实现细节，因为过度具体的技术描述反而会导致错误级联。

这意味着什么？意味着产品经理那种”说清楚要什么但不规定怎么做”的能力，可能变成了最值钱的技能。

2.”代码量”指标将彻底失效

做过产品的都知道，我们经常会用各种指标来评估开发进度和效率——提交了多少代码、完成了多少Story Point、修了多少Bug。

在harness engineering的世界里，一个三人小团队可以通过Agent每天合并三四个PR，五个月写出百万行代码。这时候你再用传统的代码量或者Story Point来衡量，就完全失灵了。

未来的产品管理，需要更关注的是产出质量而不是数量——功能是不是真的解决了用户问题？体验是不是真的流畅？架构是不是真的可维护？

而且有一个很现实的问题：当开发效率提升十倍的时候，产品方向的对错就变得十倍重要了。以前方向错了，团队花三个月做出来，虽然心疼但还能承受。现在方向错了，Agent一周就能做出来一个完整产品——效率是高了，但如果方向是错的，你只是更快地到达了一个错误的目的地。

所以，产品决策的质量，成为了瓶颈。 产品经理的判断力，变得前所未有地重要。

3.产品验收方式需要彻底重新设计

传统的产品验收是什么？产品经理写完需求，开发完成后自己测一测，或者让QA走一遍测试用例。

在Agent写代码的世界里，这个流程需要根本性的改变。为什么？因为Agent写出来的代码，可能在技术上完全正确、所有测试都通过，但在产品层面完全不对——它可能理解了你说的每一个字，但没有理解你真正想要的东西。

Anthropic的研究团队发现了一个很有意思的现象：在前端设计领域，Agent在没有任何额外干预的情况下，会产出”技术上没问题但视觉上很无聊”的结果——能用，但不出彩。这就是典型的”正确但不好”。

解决方案是什么？他们设计了一套评分标准，把主观判断转化成了可量化的维度：设计质量、原创性、工艺水平、功能完整性。其中特别强调设计质量和原创性，对”AI味儿太重的通用模板风格”做了惩罚性扣分。

这套评分标准是谁应该来设计的？产品经理。

因为只有产品经理最了解用户期望什么、市场上什么是差异化的、什么样的体验才是”好的”。把这些主观判断提炼成Agent可以理解和执行的评估框架，这是一个全新的、极其有价值的产品能力。

4.产品迭代节奏会被彻底重构

以前我们做产品规划，一个季度的Roadmap排得满满的，每个Sprint两周，按部就班地推进。这个节奏很大程度上是被开发产能决定的。

当开发产能被Agent十倍放大之后会发生什么？

首先，你的Roadmap可能需要更有弹性。因为很多之前需要排期好几个Sprint的功能，Agent可能一两天就搞定了。你不能还按照老节奏来规划。

其次，你可能需要更多地做”探索性开发”——让Agent快速做出原型，验证假设，然后决定走不走这条路。以前原型开发成本高，大家习惯了先分析再动手；现在原型成本极低，可能先做出来看看效果更划算。

最后，A/B测试的颗粒度可以变得更细。以前你可能只能同时跑两三个实验版本，因为每个版本都需要开发资源。现在Agent可以帮你快速生成多个变体，你的实验矩阵可以大幅扩展。

五、Harness Engineering的一些争议和冷思考

虽然这个概念很火，但我觉得作为产品经理，保持冷静的头脑很重要。有几个问题值得我们认真思考。

争议一：百万行代码到底意味着什么？

OpenAI说他们五个月写了百万行代码。但Martin Fowler团队的人敏锐地指出了一个问题：他们只谈了内部质量（代码结构、可维护性），却没怎么谈产品级别的功能验证和用户行为验证。

说白了就是——代码写得多不代表产品做得好。百万行代码如果做的东西用户不需要，那就是百万行废话。

而且Fowler的人还说了一句有点扎心的话：OpenAI有动机让我们相信AI写的代码是可维护的——因为这直接关系到他们产品的核心价值主张。我们不能完全照单全收。

争议二：这是真正的新范式还是旧瓶装新酒？

有人指出，Harness Engineering做的事情——设定代码规范、建立CI/CD流水线、写自动化测试、维护技术文档——这些不都是好的工程实践一直在做的事情吗？

确实有道理。但我觉得区别在于，以前这些是”最佳实践”，是锦上添花的东西，做了更好，不做也能凑合。而在Agent优先的世界里，这些变成了前置条件——不做这些，Agent就没法好好干活。

就好比以前没有导航的时候，你开车也能到达目的地，地图只是一个辅助工具。但自动驾驶出来之后，高精地图就变成了必需品——没有精确的地图数据，自动驾驶系统根本没法工作。

从这个角度说，Harness Engineering确实是把旧的工程实践提升到了一个新的重要性级别。

争议三：普通团队能复制这个模式吗？

OpenAI的实验是在一个非常特殊的环境下做的——他们有最好的模型、最强的工程团队、而且是从零开始建一个新项目。

但现实世界里大多数团队面对的是什么？是遗留系统、是技术债务、是混乱的文档、是各种历史包袱。在这种环境下直接搞”全Agent开发”，恐怕没那么简单。

而且不是每个团队都有能力去设计一套精细的harness的。这本身就需要很强的工程能力。

所以我觉得比较务实的路径是：不要想着一步到位，先从小处着手。比如先让Agent来做一些重复性的工作——写测试、做代码迁移、生成文档。在这个过程中逐步积累harness设计的经验，然后再扩大范围。

争议四：产品功能的创意从哪里来？

这是我最关心的一个问题。

Harness Engineering目前主要在”怎么把想法变成代码”这个环节发力，解决的是效率问题。但”该做什么想法”这个问题，目前还是完全依赖人的判断。

当开发效率不再是瓶颈的时候，产品创意和方向判断就成了真正的稀缺资源。你可以用Agent一天做出三个产品原型，但决定做哪三个、以及做出来之后选哪一个——这还是需要人的洞察力、品味和判断力。

六、给产品经理的几个具体建议

说了这么多，给同行们几个实际可操作的建议：

1.学会写”Agent可读”的产品文档

以前我们的PRD是写给人看的，可以有模糊的地方，可以有”你懂的”式的默契。但在harness engineering的世界里，你需要开始考虑：这份需求文档如果交给一个Agent来读，它能不能准确理解？

试着在你的需求文档里加入更多结构化的元素：明确的验收标准、可量化的成功指标、清晰的边界条件、具体的用户场景描述。不是因为人类开发者看不懂模糊描述，而是因为未来执行这些需求的可能不只是人类了。

2.建立产品层面的评估框架

既然Agent写出来的东西需要产品级别的评估，那产品经理就应该主动去设计这个评估框架。

什么是好的用户体验？什么是有品味的设计？什么是真正解决了用户痛点的功能？把这些主观判断尽可能地拆解成可以打分、可以对比的维度。

这不仅对Agent有用，对人类团队也有用——它让你的产品标准变得更清晰、更可衡量。

3.拥抱”快速原型”的工作方式

当开发成本大幅降低的时候，最大的浪费不是做了一个错误的原型，而是花了三个月分析讨论然后最终什么也没做。

学会利用AI Agent快速验证想法。有一个功能不确定要不要做？让Agent花一天做个原型，内测一下，看数据说话。这可能比开三天会更有效率。

4.关注”人机协作”的产品设计模式

随着harness engineering的普及，会出现一大批新的产品设计模式。比如：用户界面里应该怎么展示AI Agent的工作进度？用户应该在什么节点介入Agent的工作？Agent的错误应该怎么优雅地呈现给用户？

这些都是全新的产品设计问题，目前还没有成熟的解决方案。谁先在这些问题上积累经验，谁就能建立竞争优势。

5.不要焦虑，但要保持学习

最后说句大实话：作为产品经理，我们不需要自己去搭建harness。但我们需要理解它的基本原理和对产品开发流程的影响。

这就好比你不需要会自己搭服务器，但你得知道云计算是怎么回事，才能做出合理的产品架构决策。同理，你不需要会写AGENTS.md，但你得知道harness engineering是怎么回事，才能在新的开发范式下做好产品规划。

七、展望：Harness Engineering之后会怎样？

如果让我预测一下未来一两年的走向，我有几个判断。

第一：harness会变成标准化的基础设施。

就像今天每个团队都用CI/CD一样，未来每个团队都会有自己的Agent harness。而且会出现一批”harness模板”或”harness即服务”的产品，让中小团队也能快速搭建自己的Agent工作流。

第二：“harness工程师”会成为一个真实的岗位。

这个角色介于传统的DevOps工程师和产品经理之间，核心职责是设计Agent的运行环境。一些前沿公司已经在招这样的人了。

第三：产品经理和工程师的边界会进一步模糊。

Bret Taylor说得好——”把产品和工程结合到尽可能少的人身上，有很大的力量。”在Agent优先的世界里，能同时理解产品逻辑和技术架构的”混合型人才”会变得极其抢手。

第四：开源项目的竞争力可能被重新定义。

以前开源项目比的是代码质量和社区活跃度。未来可能还要比谁的Agent harness做得好——一个项目如果天然对Agent友好、容易被Agent理解和扩展，那它就更可能在Agent时代获得更多采用。

第五：软件行业的商业模式会因此改变。

当开发成本大幅降低，”按人天收费”的外包模式就不太行了。取而代之的可能是”按结果收费”的模式。Bret Taylor在Sierra就在推这种outcome-based pricing，而且效果还不错。

回到最开始的问题：Harness Engineering为什么值得每一个产品经理关注？

因为它预示着一个根本性的变化：软件开发的瓶颈正在从“写代码”转向“想清楚要做什么”。

在过去几十年里，”想法多、实现少”是常态——产品经理脑子里有100个想法，但开发资源只够做10个。所以我们花大量时间在优先级排序、范围控制、资源博弈上。

但在harness engineering解锁了Agent高效开发能力之后，实现的成本大幅降低。100个想法可能真的都能快速做出来看看效果了。

这时候真正的瓶颈变成了：你的那100个想法里，哪些是真正有价值的？ 你的产品直觉、用户洞察、市场判断——这些”软能力”——突然变成了整条价值链上最稀缺的资源。

所以，对于产品经理来说，Harness Engineering不是一个需要焦虑的威胁，而是一个巨大的机遇。它让我们终于有机会把精力从”催开发进度”的琐事中解放出来，专注于我们最应该做的事情——想清楚，用户到底需要什么。

这匹千里马已经准备好了。现在的问题是——你准备好驾驭它了吗？