Harness Engineering的本质，是把你的工作方法和判断标准，变成AI能理解和执行的环境。模型包含智能，Harness让这个智能变得有用。AI产品经理的核心竞争力，正在从"会用AI"转向"会给AI搭环境"。这个转变不需要等到你换工作、换项目，从你下一个AI任务开始，就可以实践。
2026年初，硅谷流传着一个让很多工程师感到震撼的案例：OpenAI内部有一个3人团队，用了5个月时间，一行代码没有手写，全程指挥AI写代码，最终交付了一个100万行代码量的真实产品——有内测用户在用，有bug要修，有功能要加，整个开发流程完整跑通了。
与此同时，大多数人用AI的日常是：让它写个方案，改了三遍还是不满意；让它帮忙分析数据，结果一会儿对一会儿错；用了一段时间之后，慢慢就只剩下”帮我润色一下这段话”这种低强度需求了。
同样是用AI，差距为什么这么大？不是因为那3个工程师用了什么神秘的提示词技巧，也不是因为他们用的模型更贵，答案只有一个：他们给AI搭了一套能真正干活的工作环境。这套环境，有个专门的名字，叫做 Harness。
LangChain的工程师Vivek Trivedy给出了一个简洁的公式：Agent = Model + Harness。Model（模型）提供智能，Harness让这个智能能真正被用起来。
Harness这个词直译是”马具”。一匹马再强壮，没有马鞍、缰绳、马镫，你骑不了它。AI模型也是一样，它再聪明，你得给它一套”装备”，它才能真正干活。这套装备包括系统提示词、工具、文件系统、沙箱环境、编排逻辑、各种检查机制……听起来很复杂，但本质上只回答三个问题：AI在哪干活？用什么干活？怎么知道干得对不对？
这三个问题解决了，AI就能持续工作；解决不了，AI就只能陪你聊天。
对AI产品经理来说，这个公式意味着一个认知升级：以前评估一个AI产品，你只会问”用的是哪个模型”、”提示词写得好不好”。但现在，你应该问的是”它的Harness设计得怎么样”——这才是真正决定一个AI产品能不能落地的东西。模型是外购的，提示词是可以快速复制的，但一套经过打磨的Harness，才是真正的护城河。
Harness这个概念不是空中楼阁。2026年初，OpenAI和Anthropic几乎同时发布了各自的工程实践文章，把他们在内部怎么搭Harness、踩了什么坑、怎么解决的，都讲清楚了。这两份文章加在一起，是目前最有参考价值的Agent工程实践资料。
OpenAI团队在做那个100万行代码项目的时候，一开始犯了一个很典型的错误：把所有东西都塞进了一个叫AGENTS.md的文件里——系统说明、架构规范、代码风格、注意事项，全在里面。结果AI被信息淹没了，性能反而下降。
后来他们意识到，AI跟人一样，需要的是一个整理好的工作台——需要的时候能找到东西就行，不需要一开始就把所有东西堆在眼前。他们把AGENTS.md精简到100行，只做”目录”，真正的内容放在结构化的docs/目录里：设计文档、架构文档、计划文档分开存，AI需要什么信息就去对应的文件夹找。
除了文件系统，他们还做了一件很有意思的事：花了好几个小时重写Linter的错误信息。Linter是一种检查代码规范的工具，它的报错信息原本是写给人类工程师看的。他们把这些报错信息改写成AI能看懂的格式，让AI能从错误信息里直接知道”哪里错了、怎么改”。这个细节背后有一个很深的洞察：Harness的受众不是人，是AI，你搭建的每一个环节，都要从”AI能不能理解和使用”这个角度来设计。
对产品经理的启示： 这和你设计用户引导流程其实是同一个逻辑。好的新手引导不会在用户第一次打开App的时候把所有功能介绍塞给他，而是在用户需要某个功能的那个时刻给出对应的提示。你在设计AI产品的知识库结构、系统提示词的时候，也应该遵循同样的原则：分层组织，按需加载，而不是把所有信息一股脑塞进去。
Anthropic的工程师发现了一个更根本的问题：AI评估自己的工作完全不靠谱。不管做得好不好，AI给自己的评价永远是”很好”，这在设计类任务上尤其明显——一个页面是精致还是平庸，单个AI根本看不出来。
他们的解决方案是把生成和评估拆成两个AI来做。生成器负责做东西，评估器拿到一个工具，能实际操作生成的产出物：点按钮、填表单、截图、检查功能，然后对照四个维度打分——设计质量、原创性、工艺、功能性。评估器给出详细反馈，生成器根据反馈改进，来回迭代5到15轮。
有一个案例特别能说明这套机制的价值。Anthropic让AI做一个荷兰艺术博物馆的网站，第9轮的时候，AI做了一个干净的深色主题页面，看起来还行。但到第10轮，AI突然推翻了整个设计，做了一个3D空间：用CSS透视渲染了一个带棋盘地板的房间，艺术品挂在墙上，用户通过”门”导航到不同展厅。这种创意的跃升，靠单个AI反复问自己”好不好”是不可能出现的，必须有一套外部的、可量化的评估机制在驱动。
对产品经理的启示： 你在做AI产品的验收标准时，不能只写”AI生成高质量内容”这种模糊的表述。你需要像Anthropic一样，把”质量”拆解成具体的可检查维度，并且把”评估”这件事从”生成”里单独拆出来设计——让评估有自己独立的执行路径，而不是让生成和评估混在一起互相干扰。
理念讲清楚了，接下来是更重要的一步：Anthropic把Harness从”你自己搭”变成了”我帮你托管”。
2026年4月，Anthropic正式发布了Claude Managed Agents，一套用于构建和部署云托管Agent的可组合API套件。它的逻辑很简单：搭建一套生产级的Harness需要处理沙箱执行、状态管理、权限控制、端到端追踪，这些基础设施工作可能耗费数月，而用户根本看不到这些”幕后工程”。Claude Managed Agents把这些复杂性全部接管。你只需要定义三件事：任务（Agent要做什么）、工具（Agent可以用什么）、护栏（Agent的边界和限制），剩下的运行、编排、安全、状态管理，全部由Anthropic的基础设施来处理。
它包含四个核心能力：生产级Agent（安全沙箱、身份验证、工具执行全部托管）、长运行会话（Agent可以自主工作数小时，断线不丢状态）、多Agent协调（主Agent可以派生子Agent并行处理复杂任务）、可信治理（权限控制、身份管理、执行追踪全部内置）。
几个已经在用这套服务的团队给出的反馈很能说明问题。Sentry把他们的调试Agent Seer和一个Claude驱动的Agent配对，后者负责写补丁、开PR，开发者从标记的bug到可审查的修复，整个流程一气呵成——而这个集成原本预计需要数月，用Managed Agents只花了几周。Vibecode的联合创始人说得更直接：以前用户必须手动在沙箱中运行LLM、管理生命周期、配备工具并监督执行，这个过程可能需要数周甚至数月；现在只需要几行代码，就能以至少10倍的速度启动相同的基础设施。Atlassian则把Agent直接嵌入了Jira工作流，让客户可以从Jira里直接给Agent分配任务。
这背后有一个值得关注的商业模式转变：Anthropic的定价从”按token付费”变成了”按token付费 + 每会话活跃小时0.08美元”。这是一种更接近基础设施服务的计费方式，类似于云主机按运行时长计费。Anthropic正在从”卖脑子”变成”卖整个人”——它不再只是一个模型提供商，而是在做云服务商做的事。
说了这么多行业动态，最关键的问题是：这些跟你的日常工作有什么关系？答案是：关系很大，而且是那种”认知不升级就会被淘汰”的那种大。
以前设计AI产品，你的核心工作是”选哪个模型、写什么提示词、设计什么交互”。这些当然还重要，但现在你需要多问三个问题：AI在哪干活（执行环境设计）？AI用什么干活（工具选择与组合）？怎么验证干得对不对（评估机制设计）？这三个问题的答案，才是你的AI产品能不能真正从Demo走到生产的关键。一个Demo可以靠好的提示词撑起来，但一个生产级的AI产品，必须有一套完整的Harness在支撑。
以前做Agent产品，工程团队必须花几个月时间搭基础设施，这道门槛让很多产品卡在原型阶段出不来。现在有了Claude Managed Agents这类托管服务，这道门槛大幅降低了。作为产品经理，你需要在立项阶段就评估清楚：自建Harness的工程投入，是否真的带来了竞争壁垒？还是只是在重复造轮子？如果是后者，把节省下来的工程资源放在真正有差异化价值的地方——Agent能做什么、怎么做、边界在哪——往往比自己搭基础设施更值得。Sentry的工程总监说得很清楚：Managed Agents让他们能够专注于构建无缝的开发者体验，而不是维护定制Agent基础设施的持续运营开销。
Anthropic的实践证明，AI自评不可靠。这个结论对产品经理的工作有直接影响：你在写PRD的时候，不能只写”AI生成高质量内容”或者”AI准确理解用户意图”这种模糊的验收标准。你需要把”高质量”拆解成具体的可检查维度，设计可操作的检查机制，而不是依赖主观感受或者让AI自己评价自己。更进一步，你需要在产品流程里为”评估”设计独立的路径——谁来评估、用什么标准评估、评估结果如何驱动下一轮迭代，这些都应该在产品设计阶段就想清楚，而不是等到上线之后发现效果不对再临时补救。
看到这里，可能有人会想：OpenAI和Anthropic讲的这些都是大厂的实践，我一个普通的产品经理，能用上吗？答案是完全可以。Harness Engineering的核心思想，可以直接迁移到你每天的AI使用场景里，不需要你会写代码，也不需要你有什么工程背景。
第一步，整理你的“工作台”。 选一个你每周都要重复做的AI任务，花一个小时建立清晰的文件结构和规范：背景资料放哪里，参考模板放哪里，历史输出放哪里。不要把所有信息塞进一个提示词，而是分层组织，让AI在需要的时候能找到对应的信息。OpenAI的教训很清楚：信息堆砌不等于信息有效，整理好的工作台才是高效输出的前提。
第二步，设定你的“验收单”。 明确什么叫”完成”。不是”写一篇好文章”，而是”800字、包含3个真实案例、数据有来源、结尾有明确的行动建议”。Anthropic用的四个维度——质量、原创性、工艺、功能——可以迁移到任何创作任务。设定可检查的标准，让AI对照标准自查，而不是让它凭感觉交差。
第三步，建立你的“返工机制”。 让AI能”看到”自己的输出结果。设定检查点，分阶段验收，不要一口气让AI完成所有任务再统一检查。每次AI出错，不是重新开始，而是告诉它”哪里不对、怎么改”，并且把这个修正固化成你的工作流的一部分。Mitchell Hashimoto（HashiCorp联合创始人）对Harness Engineering的定义很简洁：每当Agent犯了一个错误，你就花时间设计一个解决方案，使Agent永远不再犯同样的错误。
最重要的一个心态转变是：每次AI出错，不是责怪它，而是问“我的环境里缺了什么”。 这一句话，就是Harness Engineering的精髓。
本文由 @睿气少女的小想法 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Claude官网截图
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。