同一个模型，数据没换，提示词没换，只换了模型外面包的那层运行环境，编程基准的成功率从42%跳到了78%。这个数据来自独立研究者Nate B Jones的一项实验。变量只有一个：模型外面的壳。
3月，Anthropic发布了一篇工程博客，用自己的实验给了另一组数据：同一句提示词、同一个模型，跑20分钟花9美元，出来的东西核心功能是坏的；换一套运行方式，跑6小时花200美元，出来一个能玩的游戏。
这层壳，现在有了一个正式的名字：Harness。围绕它展开的工程实践，叫Harness Engineering。
什么是Harness Engineering
先说它不是什么。它不是提示词工程，不是模型微调，不是RAG，不是简单的Agent编排。
Harness的字面意思是马具——缰绳、鞍座、嚼子——一整套把一匹强壮但不可预测的马引导到正确方向的装备。用在AI领域，Harness指的是包裹在模型外面的完整运行系统：约束规则、反馈循环、架构边界、工具链、生命周期管理、验收机制。
模型负责推理。Harness负责其他一切。
Philipp Schmid（前HuggingFace）给了一个更直观的类比：模型是原始处理能力，上下文窗口是有限的工作内存，Harness是操作系统——管理上下文初始化、标准工具驱动、任务调度和资源分配。
这个词最早来自Mitchell Hashimoto——HashiCorp联合创始人、Terraform的缔造者。2026年2月，他写了一篇博客把自己使用AI编程的进化拆成六个阶段，第五个阶段叫"Engineer the Harness"。定义只有一句话：每当你发现Agent犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。
几天后OpenAI跟进了一篇博文，Martin Fowler团队的Birgitta Böckeler接着分析。几周之内，Harness Engineering这个词火遍了整个AI工程圈。
三代进化：从Prompt到Context到Harness
要理解Harness Engineering解决什么问题，得先看它的前两代。
2022-2024：Prompt Engineering。 核心关注是怎么写好一条指令。few-shot、chain-of-thought、角色扮演，本质上都在打磨单次输入。你和模型之间的关系是"写一封邮件"。
2025：Context Engineering。 Andrej Karpathy和Shopify CEO Tobi Lütke推了这个概念。单条prompt不够了，你得为模型动态构建整个上下文——相关文件、历史对话、工具定义、知识库检索结果——让模型做每一个决策时都能看到它需要的信息。你和模型之间的关系变成了"把相关附件都带上"。
2026：Harness Engineering。 Context Engineering是Harness的一个子集，但Harness在更高层面运作。它不只是给模型看什么信息，而是设计整个工作环境——让Agent能持续、稳定、高质量地工作。你和模型之间的关系变成了"搭建整个办公室"。
底层原理：为什么需要Harness
模型不会评价自己的工作
这是Harness存在的根本原因之一。Anthropic的工程师发现，当你让Agent自己评估刚写完的东西时，它会自信地表示写得很好——即使在人类看来，质量明显不行。
这个问题在主观任务上（比如前端设计）尤其严重，因为没有二元的对错标准。但即使在有客观标准的任务上，Agent的自我判断也不可靠。模型能力够了，但它对自己的能力没有准确的认知。
生成与评估分离
Anthropic的解法借鉴了GAN（生成对抗网络）的思路：把生成和评估拆成两个独立的Agent。一个generator负责写，一个evaluator负责评。evaluator不是看截图打分，而是用Playwright真的去点页面、查API、看数据库状态，像一个真人QA一样操作完再给反馈。
但evaluator也不是天生靠谱。Anthropic坦言，开箱即用的Claude是一个很差的QA Agent。早期的evaluator会发现问题，然后说服自己这不是大问题，接着就批准了。他们花了好几轮来校准evaluator的判断标准。关键洞察是：让一个独立的evaluator变得严格，远比让generator学会自我批评容易得多。 约束解空间反而提升生产力
Cursor团队发现了一个反直觉的规律：当模型可以生成任何东西时，会浪费token探索死胡同。当Harness定义了清晰的边界——架构规则、linter、AGENTS.md——Agent反而更快收敛到正确答案。本质上就是把无限可能的开放问题转化成有限范围的约束满足问题。
Vercel的经验更极端：他们砍掉了80%的Agent工具，效果反而更好。更少的工具意味着更少的步骤、更少的token、更快的响应、更高的成功率。
确定性节点包裹非确定性节点
Stripe的Blueprint架构最能说明这一点。工作流被拆成两类节点：确定性的（跑linter、推送代码、CI检查）走固定路径不调模型，非确定性的（实现功能、修bug）才让模型判断。用确定性的"骨架"把模型的不确定性限制在可控范围内。
谁在做：行业实践全景
OpenAI Codex团队
5个月，约100万行代码，1500个PR，全部由Agent生成。人类一行代码都没写。团队一开始只有3个工程师，后来扩到7个。平均每位工程师每天合并3.5个PR。
他们总结的核心原则：仓库是Agent唯一的知识来源；代码不仅要对人类可读，更要对Agent可读；架构约束不靠prompt，靠linter；如果PR需要大改才能合并，问题不在Agent，在Harness。
OpenAI团队给自己的角色定义是：我们现在最大的挑战在于设计环境、反馈循环和控制系统。不写代码了，写规则。
Anthropic
三Agent架构（planner + generator + evaluator）的提出者。Planner把一句话需求展开成完整的产品规格，generator按功能逐个实现，evaluator在每个阶段结束后真机验收。
从Opus 4.5到Opus 4.6的迭代中，他们砍掉了sprint结构——因为新模型长任务更稳定，旧约束变成了多余开销。但evaluator没有被砍掉，因为即使模型变强了，它的能力边界只是往外推了一些，边界本身并没有消失。
Anthropic的判断是：Harness的可能性空间不会随着模型进步而缩小，它会平移。
Stripe Minions
每周合并1300多个PR，全部由无人值守的Agent完成。架构核心是Blueprint编排系统，把工作流拆成确定性节点和Agentic节点交替执行。CI最多跑两轮，第一轮失败Agent自动修复再跑一次，还失败直接转交人类。
值得注意的细节：他们内部挂了大约500个MCP工具，但给每个Agent的只是精心筛选过的子集。因为他们发现：更多的工具并不等于更好的表现。
Stripe工程团队的总结：成功取决于可靠的开发者环境、测试基础设施和反馈循环，跟模型选择关系不大。
Cursor
"Self-Driving Codebases"研究走得最远——每小时约1000个commit，一周超过1000万次工具调用，启动后无需人工干预。
但他们走过的弯路本身就是Harness设计难度的证明：第一版单Agent，复杂任务扛不住；第二版多Agent共享状态文件，锁竞争严重；第三版结构化角色分工，太僵硬；第四版持续执行器，角色过载；最终版本是递归Planner-Worker模型。
6个月内重构了5次Harness。同一个模型，5套架构，每次重写都提升了可靠性和任务完成率。
LangChain
一年内重新架构了4次研究型Agent。用同一个模型（GPT-5.2-Codex），只改Harness，Terminal Bench 2.0成绩从52.8%升到66.5%，排名从30名开外直接进前5。同一个模型，同一个基准，排名差了28位。
数据汇总：Harness改变了什么
| | |
|---|
| | |
| 同一模型（GPT-5.2-Codex），换Harness | Terminal Bench排名30+ → Top 5 |
| | 20分钟/$9（功能坏）→ 6小时/$200（功能可用） |
| | |
| | |
所有数据指向同一个结论：在当前节点，优化模型外面的壳，回报率可能比等下一代模型更高。
反方观点：Harness只是拐杖？
OpenAI的Noam Brown在Latent Space的一次访谈中直接说：Harness就像一根拐杖，我们终将超越它。
他的理由是：在推理模型出现之前，开发者在GPT-4o上搭了大量复杂的Agentic系统来模拟推理能力——路由器、编排器、多Agent协作。然后推理模型一出来，这些东西一夜之间不需要了。
他给开发者的建议：别花六个月搭建一个可能六个月后就被淘汰的东西。
METR的数据也给了Harness阵营一记冷击。他们找了scikit-learn、Sphinx、pytest三个项目的4位活跃维护者，审查了296个AI生成的PR。维护者的合并率大约只有自动化评分通过率的一半——7倍的能力高估。
但Anthropic自己的实验给出了最好的回应：Opus 4.6确实让sprint结构变得多余了（Noam Brown说的"拐杖"被扔掉了），但evaluator没有被扔掉。模型变强了，旧的约束可以拆掉，但新的、更高阶的约束空间打开了。以前你要教Agent怎么管理上下文窗口，现在不用了；但你可以开始让它做四小时的自主开发任务，那就需要新的反馈和验收机制。
Harness不会消失，它会平移。
我的实践与思考：从编码之外看Harness Engineering
以上所有案例——OpenAI、Stripe、Cursor、Anthropic——全部集中在编码Agent这个场景。但Harness Engineering的核心原理并不局限于写代码。
我在运营ChooseAI的过程中，用OpenClaw（龙虾）构建了一套多角色工作坊系统，试图解决一个更通用的问题：怎么让AI从一句话需求出发，经过方案讨论，最终输出可执行的交付物。
在实践中我发现了一个更底层的认知：
共识是执行质量的前提条件
在任何真实的工作场景中，每个人都扮演不同的角色，承担不同的任务，对同一件事有不同的看法。产品经理觉得功能要全，工程师觉得架构要稳，设计师觉得体验要好，运营觉得上线要快。
当这些不同视角没有经过碰撞和对齐就直接进入执行，结果一定是混乱的。AI Agent面临的问题完全一样——一个Agent身兼所有角色，没有经过"内部讨论"就直接输出，相当于跳过了方案共识直接写代码。
所以我认为，无论什么样的任务，都由三个层次构成：
策略层：这个任务到底要解决什么问题？目标是什么？约束是什么？
方案共识层：从多个专业视角审视策略，通过讨论和辩驳达成一致，形成可执行的方案。
方案执行层：按照共识方案，调用具体工具和技能完成交付。
目前业界的主流实践——写AGENTS.md、配linter、搭CI——本质上都在优化执行层。但我认为，真正被忽视的是共识层。
Skill应该是底层能力，不是任务模板
现在的一个普遍问题是：几乎每个常规任务都需要一个专门的Skill来实现。Skill本质上就是prompt的变体——一套针对特定任务的指令模板。这意味着我们没有实现任务的通用化。
我的思考是：Skill更应该是底层能力框架。比如PDF处理、Word文档生成、PPT制作、图片生成、视频生成、代码执行——这些是模型的基础技能边界，是不随任务变化的。而任务本身的策略和方案，应该通过一个通用的工作流来生成，而不是为每种任务写一套专门的Skill。
一个通用的Harness工作流
基于以上思考，我设计并实践了这样一个流程：
第一步：任务识别。 模型识别任务的类型，理解用户到底需要什么——是要方案还是要成品？是内容创作还是数据分析？是一次性交付还是持续运营？
第二步：角色创建。 根据任务动态创建与之相关的角色。不是固定的"产品/运营/技术"三人组，而是根据任务的核心张力来决定需要哪些视角。做愚人节海报，需要创意编导、品牌运营、视觉设计；做技术架构评审，需要架构师、SRE、产品经理。角色由任务决定，不是反过来。
第三步：角色讨论。 每个角色作为独立的子Agent，从各自立场给出建议。关键是角色之间要有真实的张力——如果所有角色的意见都一样，讨论就没有价值。
第四步：辩驳与共识。 各角色Agent相互评价、挑战彼此的观点，最终收敛到一个各方都能接受的方案。这就是方案共识层的核心——不是一个Agent的独白，而是多个视角碰撞后的结果。
第五步：撰写共识方案。 将讨论结果结构化为可执行的方案文档，明确每一步要做什么、用什么工具、验收标准是什么。
第六步：查看工具清单，撰写执行计划。 根据方案查看可用的工具和Skill（TOOLS.md），把方案转化为具体的执行步骤。
第七步：执行。 按照执行计划调用底层Skill完成交付。
这个流程是半自动的——方案讨论过程中有环节需要人为确认。人类在共识层做决策，AI在执行层做交付。
全自动的关键：记忆系统
如果要实现全自动流程——从一句话需求到最终交付完全不需要人工干预——需要解决一个核心问题：记忆系统。
半自动流程中，人类确认方案的那个环节，本质上是在做"方向校准"。人类知道项目的长期目标、品牌调性、过往踩过的坑、团队偏好。这些信息如果不在Agent的记忆里，全自动流程就会跑偏。
目前的记忆方案有两条路线：Claude通过自身的对话记忆系统来积累用户偏好；ChatGPT通过向量存储和搜索来检索历史信息。OpenClaw用的是文件系统——MEMORY.md存储长期记忆，每日笔记记录当天的交互摘要。
但这些方案都有一个共同的短板：记忆的构建和维护成本高。你要么手动维护（写MEMORY.md），要么依赖模型自动提炼（但模型不知道什么重要什么不重要），要么用向量搜索（但召回精度有限）。
我在想的一个方向是：有没有一种模型能在对话过程中实时学习和构建记忆系统？ 不是事后总结，不是被动存储，而是在交互的过程中持续识别"这条信息在未来的任务中可能有价值"，并主动将其结构化存储。这需要模型具备一种"元认知"能力——不仅知道当前任务需要什么，还能预判未来任务可能需要什么。
本质上，这描述的是一种具备工作记忆的持续学习架构。学术界已经有人在探索这个方向——比如MemoryLLM尝试让模型在推理过程中直接更新自身参数来存储信息，Larimar则探索了基于外部记忆模块的实时写入和检索机制。但坦率地说，这些研究离工程可用还很远。
这里需要意识到一个关键区分：这是一个模型架构层面的问题，不是Harness工程层面能解决的。 Harness Engineering能做的是优化模型外面的系统——约束、反馈、工具链。但"让模型在交互中自主学习什么该记住"，需要的是Transformer无状态推理架构本身的突破。当前所有的记忆方案——Claude的事后提炼、ChatGPT的向量检索、OpenClaw的手动MEMORY.md——都是在架构限制下的工程折中，不是真正的解决方案。
这也引出了一个更大的问题：Harness的哪些层最终会被模型能力吸收，哪些永远不会？ Anthropic已经证明了sprint结构会被更强的模型淘汰。记忆层很可能也会走同样的路——一旦模型原生具备持久化工作记忆，我们现在设计的MEMORY.md机制就会变成下一个被砍掉的"sprint结构"。但共识层可能永远不会被吸收，因为多视角碰撞是一种结构性需求，不是模型能力不足的补偿。
这本质上还是一个系统工程问题。Harness Engineering解决了"怎么让Agent在单次任务中做得好"，但"怎么让Agent跨任务持续变好"，还需要记忆系统这一层来支撑——只是这一层的终极答案，可能不在Harness里，而在下一代模型架构里。
写在最后
Harness Engineering在2026年爆发，不是因为它是一个新概念，而是因为模型终于强到了一个临界点：模型的能力不再是瓶颈，模型外面的系统设计变成了瓶颈。
OpenAI的Codex团队不写代码了，写的是架构规则、linter配置和AGENTS.md。Stripe的工程师不写代码了，写的是Blueprint编排和CI限速策略。Anthropic的工程师不写代码了，写的是evaluator的打分标准和校准逻辑。
写代码正在变成一件成本很低的事。设计那套让Agent持续、稳定、高质量工作的系统，才是真正贵的部分。
而且这套系统不是一劳永逸的。每一代模型出来，都得重新审视哪些约束还管用、哪些该拆掉、哪些新的空间被打开了。Manus重写了5次，LangChain重构了4次，Cursor迭代了5个版本。
但最终，所有这些实践都在回答同一个问题：怎么从一个想法出发，经过充分的讨论和验证，最终交付一个可靠的结果。 这个问题在有AI之前就存在，有了AI之后也不会消失。变的只是谁来执行——以前是人写代码，现在是Agent写代码。不变的是：共识决定质量，系统决定效率，记忆决定持续性。
真正稀缺的能力，不在模型里面，在模型外面。而且它每隔几个月就得重写一次。
本文基于对Anthropic、OpenAI、Stripe、Cursor、LangChain等团队公开工程博客的分析，以及作者在AI内容生产Pipeline中的Harness Engineering实践。
参考来源：
- Anthropic Engineering Blog: Harness design for long-running apps (2026.03)
- OpenAI: Harness engineering: leveraging Codex in an agent-first world (2026.02)
- Stripe Dev Blog: Minions Part 1 & 2 (2026.02)
- Cursor Blog: Towards self-driving codebases (2026.02)
- Martin Fowler: Harness Engineering (2026.02)
- Mitchell Hashimoto: AI Coding (2026.02)
- Philipp Schmid: The importance of Agent Harness in 2026 (2026.01)
AI 速览
