太长不看版
- 如果把《跟Cloudflare大佬学用 Claude Code》《Skills 详解》《深度拆解 Clawdbot（OpenClaw）架构与实现》放在一起看，会发现它们其实都在补模型外面的系统层
- Harness 可以粗略理解成"把模型接进真实工作流的控制系统"，里面不只有工具，还有状态、约束、反馈和验收
- 它现在变重要，原因很直接：模型一旦开始真正动手，系统层问题暴露得比能力问题更快
- 具体做法会随着模型迭代不断变化，但知识沉淀、硬约束、反馈回路、完成标准这些问题不会自己消失
- 如果现在准备补 Harness，我会更建议先补统一知识入口、硬约束和验证闭环，再谈多 Agent 和复杂编排
先别把 Harness 当成一层"壳"
很多人第一次听到 Harness，会本能地把它理解成"模型外面那层包装"。这个理解不算错，但也不够。
如果只是为了做一个短对话应用，你确实可以把它理解成包装层。一个聊天窗口，加一个消息循环，再加几个工具，差不多也能跑起来。但一旦任务开始变长，事情就不是"包一层"这么简单了。
模型自己不会保存状态，不会主动维护工作目录，不会判断某次输出是不是已经满足了系统约束，也不会天然知道什么时候该停、什么时候该继续、什么时候该回滚。它当然也不会自己给自己搭测试环境，更不会在写完之后自觉打开浏览器、点一遍页面、看一眼日志，再决定这次提交到底能不能合并。
所以我现在更愿意把 Harness 理解成另一种东西：它不是给模型套上的外壳，而是把模型接进工程世界的那层控制系统。
这里面通常包括几类东西：
- 状态怎么保存
- 工具怎么暴露
- 权限怎么约束
- 输出怎么验证
- 上下文怎么管理
- 任务怎么续跑
- 什么叫"真的完成了"
把这几样拆开看，你会发现它们并不花哨，甚至很多都不新鲜。文件系统、测试、日志、浏览器、Lint、计划文件、审批机制，这些原本就是软件工程里再普通不过的东西。
但一旦主角从人类工程师换成模型，它们突然重新变成了核心。
因为模型最擅长的是生成，最不擅长的是在约束里稳定收敛。
为什么它偏偏现在火了
如果把时间往前拨两年，你会发现那时候大家最关心的是 Prompt Engineering。核心问题是：怎么把一句话说清楚，让模型按你的意思回答。
后来上下文变长了，任务变复杂了，大家开始聊 Context Engineering。问题也跟着变了，不再是"这一句怎么写"，而是"什么信息应该放进来，什么不该放进来"。
再往后走，就到了今天这个阶段。
Prompt Engineering 和 Context Engineering 当然没有过时。更准确地说，它们被包进了一个更大的问题里。
现在更让人头疼的问题变了：模型能理解需求，但在一个复杂系统里，它能不能把事情从头到尾做稳？
这也是为什么最近围绕 Harness 的材料，明显都带着一种很强的"实战味"。
- Mitchell Hashimoto 提出 Engineer the Harness，出发点很具体：每当 Agent 犯了一个错误，就别只盯着这次对话修修补补，把修复方式沉淀进系统，让它下次别再犯
- OpenAI 的 Codex 团队讲得更直接。他们从零开始跑出一个大规模代码库之后，最后得出的重点，落在三件事上：仓库怎么成为统一知识入口，架构边界怎么机械执行，PR 怎么通过 Lint 和测试去卡住错误方向
- Anthropic 的材料也很典型。里面有一个很朴素的发现，我一直记得：模型并不擅长评价自己的工作
这句话看起来平淡，其实分量很重。因为它把很多人真实碰到的问题说穿了。页面看起来像是做完了，交互其实没通。功能大体对了，边界条件一跑就露馅。代码能过一部分测试，但系统层面已经悄悄偏离了原本的设计。
这些失败的根源都一样：系统没有逼着它验证。
这也解释了最近讨论 Harness 时的一个微妙转向：大家关心的，越来越是"怎么让 Agent 别自信地干错事"。
AI 工程开始从能力问题，转向可靠性问题。
Harness 真正值钱的地方，不是功能多，而是能收敛
如果把这件事说得再具体一点，我觉得现在很多团队补 Harness，本质上是在补三种能力：
- 把隐性约束写出来
- 把失败信号接回来
- 把完成标准钉死
这三样一旦缺了，模型越强，系统有时候反而越难管。
过去看很多 Agent 产品介绍，很容易被带到"功能视角"里。有多少工具，能不能并发，支不支持子 Agent，能不能接浏览器，能不能连 MCP。这些当然重要。但如果只按这个角度理解 Harness，很容易越做越重，最后把它做成一个功能清单。
我更认同的一种看法是：Harness 最值钱的地方，在于它让模型更容易收敛到正确的事。
这背后至少有三层含义：
第一层：把隐性知识显性化
人类工程师在团队里工作，很多判断其实不写在代码里。哪些模块不能碰，哪些目录是只读的，哪些约定必须复用，哪些测试不过就别谈合并，这些东西往往散落在经验里。
模型没有这些经验。所以你越希望它长期工作，就越要把这些知识推到文件系统里，推到规则里，推到工具可见性里，推到报错提示里。
第二层：缩小解空间
这件事听起来有点反直觉。大家本能上会觉得，给模型更多工具、更多自由、更多上下文，它应该更强。
但很多实战案例恰恰指向相反的方向：
- 工具太多，它开始犹豫
- 上下文太满，它开始退化
- 边界太松，它会在错误方向上越跑越远
更有效的 Harness，往往是把路修得越来越清楚，而不是越来越宽。
第三层：把"生成"改造成"闭环"
很多人对 AI 的默认想象，还是输入一个需求，等它吐出一个答案。但真实工作并不是这样。
真实工作更像一个循环：读上下文，做判断，执行动作，观察结果，修正方向，再继续。
如果没有日志、测试、浏览器、Lint、评审规则这些反馈点，模型的生成能力再强，也很容易停在"看起来差不多"。
所以从工程角度看，Harness 不只是让模型有手有脚，它更像是在给模型装感官和护栏。
-wrap { display: flex; flex-direction: column; align-items: center; justify-content: center; }
.form { display: flex; flex-direction: column; align-items: center; gap: 20px; width: 100%; max-width: 400px; }
.form-group { display: flex; flex-direction: column; gap: 8px; width: 100%; }
.form-group label { font-weight: 500; color: #333; }
.form-group input { padding: 12px; border: 1px solid #ddd; border-radius: 6px; font-size: 16px; }
.form-group input:focus { outline: none; border-color: #007bff; }
.btn { padding: 12px 24px; background: #007bff; color: white; border: none; border-radius: 6px; font-size: 16px; cursor: pointer; transition: background 0.2s; }
.btn:hover { background: #0056b3; }
.error { color: #dc3545; font-size: 14px; }
.success { color: #28a745; font-size: 14px; }
会过时的是具体补丁，不是整个问题
讲到这里，很容易把 Harness 说得像一切答案。我不太想这么写。
Noam Brown 那一派的提醒，我觉得是有价值的。很多今天看起来很聪明的脚手架设计，半年后确实可能就没那么必要了。模型一旦变强，一些原本靠工程补上的能力，可能就会被模型自己吸收掉。
Anthropic 的例子就很典型。旧模型阶段，一些为了对抗长任务退化而设计出来的流程，到了新模型阶段，可能就可以拆掉。你昨天还觉得离不开的那层补丁，明天也许就成了多余复杂性。
所以我并不觉得 Harness 会无限膨胀。但我也不觉得它会消失。
更可能的情况是：具体做法不断被替换，但底层问题一直都在。
比如：
- 上下文总得管理
- 环境总得约束
- 结果总得验证
- 失败总得反馈
- 知识总得沉淀
这些问题不会随着某一代模型升级就消失。只要你让一个生成模型进入真实系统，它们迟早都会冒出来。
模型变强，变化的更像是"问题出现的位置"。以前你要花很多力气教它怎么保持上下文一致性。以后也许这件事轻了，但你会开始让它跑更长的任务、接更复杂的系统、承担更高的自主权。那时新的边界和新的反馈机制又会冒出来。
所以如果一定要给这件事下一个更温和的判断，我会这么说：Harness 不是一套固定答案，它更像一类持续移动的问题。
如果你真准备动手，先补这五样
写到这里，最实际的问题其实是：那到底该先做什么。
如果你是个人开发者，或者是刚开始让 Agent 真正进入工作流的团队，我会更建议从下面五样开始，而不是一上来就追求复杂编排。
1. 先有一个统一知识入口
仓库里该有的东西尽量放进仓库。架构约定、目录说明、关键约束、计划文件，都尽量文件化。不要把关键知识散在口头习惯、飞书聊天和个人脑子里。
2. 指令文件短一点，像目录，不像百科
AGENTS.md、CLAUDE.md 这类文件有用，但别写成一部长篇制度手册。它更适合告诉模型"去哪看什么"，而不是试图一次性把所有知识塞进去。
3. 能靠硬约束解决的，就别只靠 Prompt
架构边界、目录限制、测试要求、Lint 规则，这些如果能自动检查，就不要只写一句"请遵守"。模型会忘，规则不会。
这背后的思路很值得学：不要只问"模型会不会犯错"，而要先问"错误有没有被系统提前挡住"。
4. 给它反馈，不要只给它任务
写完代码之后，它应该能看到测试结果、浏览器表现、日志、错误提示。没有反馈的 Agent，很容易把"生成了一份看起来像样的输出"误判成"任务已经完成"。
Anthropic 那套 generator / evaluator 分工，本质上也是在补这一点。系统里有一个角色专门负责"验收"，生成和验收分开。
5. 别急着上多 Agent
很多问题，单 Agent 加清晰约束就能解决。多 Agent 当然有价值，但它会把状态同步、职责边界、上下文漂移这些问题一起放大。单线程都没跑稳时，盲目并行通常只会更乱。
先把架子搭稳，再谈拆分和并发。
这五样做完，系统未必立刻变得很高级。但它会先变得靠谱一点。而在今天这个阶段，我觉得"靠谱一点"比"花哨很多"更重要。
写在最后
这一轮看下来，我对 Harness 最后的感受，其实挺朴素。
它更像是大家终于开始认真承认一件事：要把模型放进真实工作流，难点从来不只在模型本身。
模型把可能性打开，系统再决定这些可能性能不能落成稳定结果。边界怎么设，反馈怎么回，什么算完成，出了问题从哪里继续，这些事最后都要靠系统来接住。
过去两年，大家在拼谁的模型更强。接下来一段时间，我更倾向于把差距看成另一件事：
谁更早把模型外面那层系统，当成一门正经工程来做。
这未必是最热闹的话题，但很可能是更难绕开的那个话题。
参考来源：
- Mitchell Hashimoto,《My AI Adoption Journey》, mitchellh.com, 2026 年 2 月
- OpenAI Codex 团队,《Harness Engineering》, openai.com, 2026 年 2 月
- Anthropic,《Long-running coding agents》, anthropic.com, 2026 年 3 月
- Birgitta Böckeler,《Harness Engineering》, martinfowler.com, 2026 年 2 月
- 论文: Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned (arXiv: 2603.05344)
- 原文: 模型越来越强，为什么大家却开始重写 Harness - 架构师（若飞）
Published by Tars | 2026-03-29