当 AI 编程进入下半场，拼的不是模型，而是 Harness

Humans steer. Agents execute.

最近几个月，我把 OpenAI、Anthropic、LangChain、Thoughtworks、HumanLayer 这些团队关于 Agent 的文章基本顺着看了一遍，也顺手看了不少一线实践、开源项目和企业侧复盘。看得越多，我越觉得现在很多人对 AI 编程的理解，其实还停在一个挺早期的阶段。

大家最爱聊的还是模型、prompt、MCP、上下文窗口，仿佛只要这些关键词掌握得够熟，AI 编程就算学明白了。但真把那些一线团队的实践拆开看，你会发现他们真正花时间、花精力、花工程能力去补的，常常不是模型本身，而是模型外面的东西。

同样是 Claude Code、Codex、Cursor，有人让 AI 改两个文件就开始发散，修一个 bug 顺手再造三个 bug；也有人能让 Agent 自己读仓库、跑测试、看日志、开 PR、吃 review、修回归，连续干几个小时还不崩。很多人第一反应是模型差距，但你真把这些案例拆开看，会发现真正拉开差距的，往往不是模型本身，而是模型外面那套工作环境。

这套东西，现在慢慢有了一个更稳定的名字，叫 Harness。

我一开始其实挺烦这种新词，感觉像又在给老东西换包装。后来资料看多了，才发现不是。因为它讨论的已经不是“prompt 怎么写更巧”“MCP 要不要接”“要不要多开几个 Agent”这种局部技巧，而是在追问一个更硬的问题：

你到底有没有给 AI 一个能持续工作、能不断纠错、能长期积累的环境？

如果没有，再强的模型也只能偶尔灵光一现；如果有，它才可能从一个聊天框，慢慢变成一个真的能协作的执行者。说得再难听一点，很多人现在不是不会用 AI，而是根本没把 AI 放进一个能好好干活的场子里。

Harness 到底是什么

LangChain 那篇《The Anatomy of an Agent Harness》里给了一个很简洁的说法，叫 Agent = Model + Harness。这句话好就好在，它一下子把很多空话都裁掉了。模型负责的是能力上限，Harness 负责的是稳定下限；模型决定它会不会，Harness 决定它稳不稳；模型给你生成的可能性，Harness 决定这些可能性能不能真的落地。

所以 Harness 说白了，不是什么玄乎的新发明，它就是 AI 的工作台。你得给它文件系统，给它清晰的仓库结构，给它能读懂的文档，给它能实际调用的工具，给它看运行结果的入口，给它知道哪里算错、哪里算对的反馈机制。再往后一点，你还得管它每次会话之间怎么接力，怎么恢复，怎么避免把上下文越用越脏，怎么让坏模式不要在仓库里越长越多。

没有这些，模型再强也只是个会说话的概率机器；有了这些，它才可能开始干真正复杂、真正长期的活。

顺着阿里那篇文章里的比喻往下说，我觉得 Harness 这个词确实挺形象。模型像一匹很强、很有爆发力、但也带着黑盒属性的马；Harness 是缰绳、马鞍、护具这些成套装备；人类工程师更像骑手，负责明确方向、设计环境、布置约束、接住反馈。单独有马不够，单独有骑手也不够，真正决定这套系统能不能跑远的，是这三者之间有没有被工程化地接好。

腾讯那篇文章里还提到 Mitchell Hashimoto 给 Harness 下过一个特别朴素、但非常有杀伤力的定义：每次你发现 Agent 犯了一个错误，就花时间设计一个工程化方案，让它以后别再犯同样的错。这个定义比很多大词都更像人话。因为它直接把 Harness 从“听起来很高级的方法论”拉回到了一个非常日常的动作上：别反复纠正，要把纠正固化成系统。你写进 AGENTS.md 的规则也好，补的脚本也好，专门加的截图工具也好，甚至一条 linter 规则也好，本质都是同一类东西。Harness 不是一开始就有的，它很多时候就是被错误一条条逼出来的。

从 Prompt Engineering 到 Context Engineering，再到 Harness Engineering

我现在越来越觉得，AI 工程这几年其实已经走过了一个很清楚的迁移路径。

最早大家聊的是 Prompt Engineering。核心问题是“怎么跟模型说话”。那时候很多技巧确实有用，few-shot、chain-of-thought、角色扮演、格式约束，大家都在一个固定对话窗口里雕 prompt，试图从黑盒里诱导出更好的答案。

后来大家开始意识到，单靠 prompt 不够，于是讨论慢慢转向 Context Engineering。问题变成了“模型到底该看到什么”。知识库、工具、记忆、检索、文件选择、上下文压缩，这一层其实已经不再是纯聊天技巧了，而是在给模型设计输入面。Karpathy 说 context engineering 比 prompt engineering 更重要，我觉得这话是对的，因为很多时候模型表现差，不是它不会想，而是它根本没看到该看的东西。

但到今天，再往前走一步，你会发现光解决“看什么”还不够，还得解决“整个环境怎么运作”。也就是说，问题继续升级成了：

这个 Agent 在什么边界里工作？怎么拿工具？怎么验收？怎么恢复？怎么避免失忆？怎么避免仓库熵增？

到了这一步，讨论的就已经不是 prompt，也不只是 context，而是 Harness Engineering。

这也是为什么我现在越来越觉得，prompt engineering 这件事并没有死，但它的地位确实降了。以前大家总觉得谁更会写 prompt，谁就更会用 AI。现在看，prompt 当然还重要，但它已经更像一台机器里的一个零件，而不是那台机器本身。你只研究 prompt，不研究环境、约束、反馈和恢复，最后就很容易陷入一种很熟悉的局面：AI 偶尔特别惊艳，但一拉长流程就散，一碰真实系统就乱，一遇到复杂项目就开始到处漏风。

OpenAI 真正讲明白的，不是“AI 写了一百万行代码”，而是“工程师开始不直接写代码了”

OpenAI 那篇《Harness engineering: leveraging Codex in an agent-first world》之所以能一下子把 Harness 这个词带火，不是因为它用了什么特别花哨的概念，而是因为它给了一个所有人都没法忽略的案例。三名工程师，五个月，零手写代码，做出一个约一百万行代码的真实产品，已经有内部用户，也有外部 alpha 测试用户。文章里提到，五个月里大概开了 1500 个 PR，平均每个工程师每天 3.5 个 PR，而且随着团队从 3 人长到 7 人，吞吐量还在往上走。

但老实说，真正值得看的根本不是这个数字，而是他们从头到尾都在强调一件事：团队最早的瓶颈，不是模型不够强，而是环境不够完整。项目早期推进慢，不是 Codex 不能写，而是仓库里缺少足够清晰的工具、抽象、结构和内部约束，Agent 没法稳定朝高层目标推进。于是工程师的主要工作，慢慢从“自己写实现”变成了“给 Agent 补能力”。

这句话非常关键，因为它把很多人今天的误区一下子点穿了。很多人一遇到 AI 产出差，第一反应就是模型还不够强，提示词还不够细，训练数据没见过我的项目。OpenAI 这篇文章给出的回答完全是另一套逻辑：当 Agent 卡住时，不要先问它为什么不聪明，要先问系统里缺了什么。很多时候不是模型拉胯，是你的场子太烂。

这个视角一变，后面所有动作都会跟着变。

比如他们自己就踩过一个很典型的坑：一开始把系统说明、架构规范、代码风格、注意事项全塞进一个巨大的 AGENTS.md，以为信息给得越全越好。结果恰恰相反，AI 被淹没了。后来他们把 AGENTS.md 压得很短，只保留入口和导航的作用，真正的设计文档、架构文档、计划文档、质量文档都分开放回 repo，让 Agent 在需要的时候自己去找。

这个改动表面看只是文档整理，实际上背后是个很硬的判断：AI 不需要一开始就知道一切，它需要的是在正确的时机拿到正确的信息。给一张地图，比塞一本到处翻不到重点的说明书有用得多。

再往后，他们做的事就更有意思了。OpenAI 不是只让 Codex 看源码，而是让它能跑 bash、执行代码、打开应用、驱动浏览器、看 DOM snapshot、截图、查日志、查指标、看 trace。你仔细想想，这些东西凑在一起，才构成了一个真正像样的工作台。因为很多 bug 根本不在代码字面上，而是在运行之后才出现。你不给 Agent 这些反馈，它就只能闭眼猜。你给了，它才有机会真的像工程师一样，写完，运行，观察，修正，再验证。

他们还做了一件特别工程的事，就是把规则尽量从“文档建议”变成“机械约束”。比如他们把业务域内部固定成 Types -> Config -> Repo -> Service -> Runtime -> UI 这种依赖方向，然后用自定义 lint 和结构测试去硬卡。这个点我觉得特别重要，因为它说明了一个事实：对 Agent 来说，稳定边界的价值远高于自由发挥。很多人总怕“约束太多会不会限制创造力”，但对 Agent 而言，边界清楚往往恰恰会让它更稳定。

还有一个我特别喜欢的细节。OpenAI 说他们后来连 linter 的错误提示都专门改过，因为这些提示不只是给人看，也要给 Agent 看。以前我们默认所有工具链的第一读者都是人，现在不是了。未来很多工程系统，第一读者很可能是 Agent。这个变化其实非常深，它意味着软件工程里很多原本“默会的、靠经验理解的东西”，都要被重新翻译成机器也能稳定读懂的形式。

再往后一个层次，就是他们发现坏模式会扩散。Agent 会模仿仓库里已经存在的风格，哪怕这些风格本身就不太好。时间一长，坏抽象、坏习惯、坏代码味道会像霉菌一样蔓延。OpenAI 最开始是靠人类每周花很多时间清理这些东西，后来发现根本不可持续，于是开始把清理逻辑系统化，把“黄金原则”写进 repo，定期让系统去巡检仓库里的文档和代码模式，发现过期说明、坏味道和跑偏的地方，就自己提修复 PR。

你会发现，到了这一步，所谓 Harness 已经不是“给 AI 几个工具”那么浅的东西了，它开始变成一整套维持秩序、抑制熵增、让系统长期不烂掉的工程机制。

所以 OpenAI 这篇文章最震撼我的，不是“AI 写了一百万行代码”，而是它把工程师的角色讲变了。人类开始越来越少地直接下场写实现，越来越多地去设计结构、定义规则、布置反馈、维护秩序。这不是“AI 帮我写代码”这么简单了，而是软件工程本身在为了 AI 协作重新长一遍。

Anthropic 讲得更现实：长任务真正的敌人，不是笨，而是失忆和自我感觉良好

如果说 OpenAI 把 Harness 的大方向说得很震撼，那 Anthropic 的文章更像在给你拆工程现场。它们没有那么强的“传奇叙事”，但特别贴地。尤其是《Effective harnesses for long-running agents》和《Harness design for long-running application development》这两篇，几乎把长任务为什么容易废掉讲透了。

Anthropic 观察到的第一个问题特别真实：长任务一旦跨多个上下文窗口，Agent 很容易开始失忆。前一个会话里想明白的事，后一个会话未必还知道；前一个会话里埋下的坑，后一个会话经常会踩第二遍。于是项目就会进入一种很熟悉的状态：半截功能，半截修复，半截理解，最后谁也说不清现在到底卡在哪一步。

第二个问题更常见：Agent 特别容易过早宣布“差不多做完了”。项目做到一半，它看了一眼页面，觉得“好像也能用”，就开始收尾。这个现象你一旦见过一次，后面就很难忘，因为它太像一个自我感觉良好的实习生了。Anthropic 对这个问题的判断很准：这不是单纯的推理能力不够，而是状态管理和验证闭环太差。说白了，不是笨，是散。

所以他们的做法很工程化。第一轮不是直接开写，而是先跑一个 initializer，把环境搭起来，生成进度文件、拆任务、留下 handoff artifact。后面的 coding agent 不再从零开始猜世界，而是每次只推进一个明确子任务，做完之后留下可交接的工件，让下一个会话接班。你会发现，这整套做法的核心根本不是“让模型更聪明”，而是 别失忆。

Anthropic 另一点讲得特别明白，就是端到端验证的重要性。模型特别容易把“代码改了”误判成“功能好了”。它可能跑一下单测，或者 curl 一下接口，就觉得这件事 done 了。但用户路径一走，发现页面不通、按钮失效、交互断裂。所以他们后来非常强调浏览器自动化和真实用户视角的验证。能看到按钮点没点通、页面有没有挂、交互是不是顺手，这比只看 diff 有价值得多。

更进一步，Anthropic 在另一篇文章里把 generator / evaluator 这套双环路也讲得很清楚。说白了就是：负责生成的 Agent 不负责给自己打分，另一个 Agent 拿着工具去真实操作页面、检查功能、截图、对照标准打分，再把问题反馈回来。这个设计最打动我的地方，不是“多 Agent 听起来很高级”，而是它把一个大家平时不好意思承认的事实说透了：

模型自评真的非常不靠谱。

特别是在设计任务、前端任务这种主观度高的场景里，一个页面到底是“能看”还是“真的好”，一个交互到底是“勉强通”还是“顺手”，模型自己往往没那么清醒。它太容易对半成品说“已经不错了”。这点真的很像实习生，只不过这个实习生嘴特别硬。

Anthropic 后面那几篇 context engineering、sandboxing、tool design 的文章，其实也都在补同一件事。上下文不是垃圾桶，而是注意力预算；沙箱不是束缚，而是自治的前提；工具不是越多越好，而是越清晰越好。你把这些东西全放一起看，就会发现 Anthropic 真正在做的，不是给 Agent 增加一点花里胡哨的新能力，而是在不断把它从“会胡乱发挥的聪明人”往“在边界内稳定做事的工程角色”上拉。

腾讯那篇文章里有一句我也很认同：纪律没有消失，只是从“如何把代码写好”转移到了“如何把让 Agent 工作的支撑结构搭好”。这句话其实非常重要。以前工程纪律体现在线下怎么写代码、怎么 review、怎么守编码规范；现在纪律越来越多地体现在文档怎么组织、约束怎么机械执行、反馈回路怎么布置、验收标准怎么前置、运行结果怎么暴露给 Agent。你要是还把工程纪律只理解成“把每一行代码写漂亮”，那你其实还活在上一个时代。

四个具体案例，比概念更能说明 Harness 到底在补什么

如果只停留在概念层面，Harness 很容易被讲成一句大话。但把具体案例摆出来，问题就清楚多了。

1. 编辑工具本身就是 Harness，不只是小配件

阿里那篇文章里提到一个很有意思的案例。独立开发者 Can Duruk 发现，很多 coding agent 失败，不是因为模型不会改，而是因为 编辑接口太脆弱。你让模型输出 patch、精确复写旧文本、或者依赖某种特殊 diff 语法，本质上都是在要求模型用很别扭的方式表达意图。

他后来做了 Hashline 这种方案，给文件每一行加短哈希标签，让模型按标签编辑，而不是按全文复现。结果同一批模型，成功率直接明显上升。这个案例我特别喜欢，因为它说明了一件很容易被忽略的事：

Harness 不只是宏大架构，连编辑接口这种底层交互面，本身也是 Harness。

你以为你在测模型，其实你常常在测的是模型和环境之间那层接口设计。

2. 技术债在 Agent 时代不是线性累积，而是指数扩散

第二个案例也很扎心。有开发者复盘说，人类工程师看到仓库里一段脏代码，很多时候知道“这是历史包袱，不要学它”；但 Agent 不会，它看到什么，就会模仿什么。于是一个临时妥协、一个硬编码、一个绕层调用，很可能会被它当成仓库合法模式，然后系统性复制到后续实现里。

这点和 OpenAI 的经验其实完全对上。人类时代的技术债，很多时候是慢慢堆；Agent 时代的技术债，更像会自我复制的病毒。你仓库里什么味道占上风，Agent 就会把这种味道放大。

所以现在越来越多团队开始重视“代码库卫生”这件事。不是靠人每周手工大扫除，而是把品味固化成 lint、结构测试、模板、脚本、巡检任务、后台 refactor PR，让系统自己去抑制坏模式扩散。说白了，Harness 到最后会碰到一个很老派、但躲不开的问题：

你有没有能力把“品味”从口头经验变成机器能执行的规则。

3. 子 Agent 真正值钱的地方，是做上下文防火墙

HumanLayer 有个说法我特别认同，他们把 sub-agent 直接看成一种 context firewall。

这个比喻很准。一个复杂任务如果所有搜索、探索、grep、read、试错、日志输出都塞进主上下文，主线程很快就会被临时垃圾拖死。让子 agent 在自己的上下文里把局部问题做完，再把压缩后的结论和引用交回来，主上下文才能保持干净。

所以多 Agent 真正有价值的地方，很多时候不是“人多力量大”，而是：

隔离噪音
压缩信息
保住主线程的方向感

这也是为什么我现在越来越不迷信“多开几个 Agent 就更高级”。多 Agent 不是目的，能稳定交接、稳定压缩、稳定恢复，才是。

4. 成功应该是沉默的，只有失败才应该发声

阿里那篇文章里还提到 HumanLayer 和 LangChain 的另一类实践，我觉得特别值得普通团队直接拿来用。HumanLayer 早期踩过一个坑：每次 Agent 改完代码，就把一整套测试输出塞回上下文。结果不是更安全，而是把模型注意力拖垮了。

后来他们总结出一句很重要的话：

成功应该是沉默的，只有失败才应该发声。

这句话听起来像个小技巧，但背后其实是非常硬的 harness 思维。你要让 Agent 获得反馈，但不是让它淹死在反馈里。构建、测试、lint、截图、日志这些东西，成功时给简短信号就够了；失败时再返回最小可操作单元的错误。这种“静默成功、精准失败”的设计，本质上是在保护上下文预算。

LangChain 那边更进一步，还做了 pre-completion checklist 和 loop detection。一个负责拦截“你真的做完了吗”，一个负责识别“你是不是在同一个地方兜圈子”。这些设计听起来不像模型能力，但它们恰恰是让模型少犯低级错误的关键。

HumanLayer 这批文章最值钱的地方，是把很多细活讲透了

如果说 OpenAI 和 Anthropic 是把大方向讲清楚，那 HumanLayer 那几篇文章的价值，就在于它们特别像一线使用者写的复盘。没有那么多宏大叙事，但很多点一看就知道是被真实问题逼出来的。

我最认同的是他们对 CLAUDE.md 这类文件的态度。HumanLayer 在《Writing a good CLAUDE.md》里讲得很克制：这种文件是高杠杆点，因为它会稳定进入每次会话；但它也是高风险点，因为你很容易把它写成垃圾场。太多人写这类文件时，思路其实是“把我脑子里的所有想法都塞进去”。结果不是帮助，而是污染。短、小、稳定、只写模型自己推不出来但又会反复用到的规则，这种做法反而更有效。

这点和 OpenAI 后来把大 AGENTS.md 拆散，逻辑是一模一样的。

HumanLayer 另一个特别强的观点，是他们把 coding agent 的很多问题直接归因到 configuration surface 上。skills、MCP、memory、sub-agents、hooks，这些都不是边角配件，而是 coding agent 的真正配置平面。这个说法很扎心，但也确实把问题说透了。很多人不是不会用模型，而是根本没给模型一个像样的工作配置。嘴上说是在用 Agent，实际干法还是把它当一次性聊天框。

而且 HumanLayer 那种写法有个好处，它不会假装一切都很优雅。很多文章会把 Agent 写得像一个天然懂事的协作者，HumanLayer 没这么浪漫。它们的出发点更像是：模型会忘、会乱、会自信地犯错，会被噪音拖死，会在错误接口上用力过猛，所以你必须把这些坑一个个封起来。这个思路其实很符合我现在对 Harness 的理解。Harness 不是锦上添花，它很多时候是在不断堵漏。

Thoughtworks、Inngest 这些文章把另外半边补上了：别迷信框架，要重视系统纪律

再往下看，会发现很多文章最后都绕不开同一个话题：约束和系统纪律。

Thoughtworks 那篇《Harness Engineering》我觉得特别好的一点，是它没有被“新词”带跑，而是把这件事拉回了工程本身。他们把重点落在三件事上：context engineering、architectural constraints、entropy control，也就是持续清理漂移和坏模式。这其实和 OpenAI 的经验高度重合。说明一线团队最后都在同一类问题上收敛。

Inngest 那篇《Your Agent Needs a Harness, Not a Framework》则从另一个方向把问题说透了。它的核心观点是：Agent 最终碰到的很多问题，本质上不是 AI 问题，而是基础设施问题。比如任务做到第五步挂了怎么办，两条消息同时打进来怎么防止状态冲撞，一个长循环怎么拆成可重试的 step，中间结果怎么持久化，出错之后谁来接管、怎么通知。

这些问题如果放回传统软件工程里，大家都觉得理所当然；可一到 Agent 这里，很多人又突然回到“给个 prompt 试试”的原始社会。

所以我现在越来越认同 Inngest 这个判断：很多团队不是缺 framework，而是缺 harness。真正难的地方，通常不在“怎么让模型更会想”，而在“怎么让系统别失控”。

很多人现在最缺的，不是更多 Agent，而是更像样的规格、评估和可观测性

还有一层很容易被忽略，但其实非常要命，那就是 spec、eval 和 observability。

规格不清，Agent 往往不是做不动，而是高效率跑偏。OpenAI 把设计文档、架构文档、计划文档、质量文档都收进 repo，Anthropic 把 feature list 结构化，GitHub 的 spec-kit 干脆直接把这种思路产品化了。本质都在回答同一个问题：Agent 到底在替你完成什么目标，按什么流程推进，做到什么程度才算结束。

一旦进入多会话、多步骤、多 Agent 的世界，模糊规格的代价会被无限放大。人类工程师还能靠 tacit knowledge 补一补，Agent 补不了。

评估这件事也是一样。OpenAI 后面关于 eval 的几篇东西，像 eval skills、agent evals、trace grading，本质上都在做一件事：把 Agent 的过程纳入评估，而不是只看最后一句答案像不像。因为 Agent 经常不是输在最后结果，而是中间某一步就已经歪了。你不看 trace、不看过程、不做任务级 eval，很多问题根本不会暴露出来。

LangChain 那篇《Improving Deep Agents with harness engineering》甚至直接给出了一个很有说服力的例子：他们的 coding agent 在 Terminal Bench 2.0 上从 Top 30 到 Top 5，改的不是模型，而是 harness，重点就是 self-verification 和 tracing。这句话其实已经够说明问题了，今天很多性能提升，来自系统外壳，而不是大脑本身。

可观测性就更不用说了。OpenAI 让 Codex 看 logs、metrics、traces，Anthropic 让 evaluator 用浏览器去真实操作页面。背后只有一个朴素事实：如果你不让 Agent 看见系统运行后的真实反馈，它就只能闭眼猜。而闭眼猜这件事，偶尔能蒙对，但很难持续交付。

Harness 越强，Spec 越重要，这不是二选一关系

很多人看到 Harness 这个词火起来之后，第一反应是：既然环境和工具这么重要，那是不是以后花精力写 Spec、写设计文档、写行为约束，就没那么重要了？反正 Harness 会越来越强，Agent 会越来越聪明，直接让它在仓库里自己找不就行了？

这个想法乍看很顺，但其实是反的。

OpenAI 那篇文章已经给过一个非常硬的事实：从 Agent 的视角看，它在运行时访问不到的东西，等于不存在。存放在 Google Docs、Slack、会议纪要或者人脑子里的知识，对它来说都像空气。真正能被 Agent 当成推理依据的，只有那些被写进仓库、被版本化、被它明确读到的东西。

也就是说，Harness 再强，也只能放大它真正看得见的内容。你把仓库里的规范、契约、设计决策写得越清楚，Harness 就越能把这些东西放大成稳定输出；如果仓库里根本没有这些东西，或者写得很虚，Harness 放大的就不是工程纪律，而是模型的猜测。

这也是为什么我现在越来越认同腾讯那篇文章的判断：Harness 和 SDD 不是竞争关系，而是同一件事的两个层面。

Harness 解决的是“Agent 在一个什么样的环境里工作”；Spec 解决的是“这个环境里到底写了什么，让它可以推理、可以执行、可以验证”。Harness 像放大器，Spec 像被放大的信号。放大器越强，输入质量越重要。引擎越猛，导航越不能瞎。高速路的护栏不是因为车慢才不重要，恰恰是因为车快了，护栏才更重要。

腾讯那篇文章里有个说法我觉得很准：Spec 在 Harness 里至少扮演三种角色。第一，它是 Agent 推理的地图。没有地图，Agent 看到的只有“代码现在长什么样”，看不到“为什么这么设计”“哪里不能动”“这个字段跨服务到底是什么意思”。第二，它是很多语义约束的载体。Lint 能卡格式，结构测试能卡依赖方向，但很多业务语义、错误码契约、状态流转规则，机械检查根本管不到，这些东西不写下来，Agent 就只能猜。第三，它其实还是反馈回路里“正确性”的判据。你得先有一个“应该是什么样”的定义，后面的验证、回归、评分、trace grading 才有落点。

这三层我觉得特别重要，甚至可以说是很多团队现在最薄弱的地方。地图这一层，很多人其实是缺的。仓库里代码很多，但没有高层视图，没有边界说明，没有清晰导航，Agent 一进去就像掉进迷宫。语义约束这一层，更容易被忽视。大家总以为有 lint、有类型系统、有测试就够了，但很多真正会出事故的东西，恰恰不在这些机械规则里，而在那些“默认大家都懂”的跨服务契约、业务含义、错误码语义、状态流转条件里。人类同事之间还能靠语境和背景知识补一下，Agent 不行。它不知道的时候不会举手说“这里我有点不确定”，它大概率会沉默地猜一个看起来合理的答案，然后把这个猜测写成代码。

腾讯那篇文章举了一个我觉得特别有代表性的例子：服务 A 定义了某个错误码的含义，但服务 B 的 Agent 在实现时完全不知道这个跨服务语义，于是直接猜了一个处理方式。这个 bug 不是因为模型不够强，而是因为真正关键的语义根本没写进 Spec。这个案例我觉得特别能说明问题。很多人现在在 AI coding 里遇到的坑，本质都不是“能力缺失”，而是“定义缺失”。

所以我现在越来越觉得，Harness Engineering 真正把一件事放大了：仓库里写进去的东西，比以前重要得多。 以前很多团队文档写得一般，也能勉强靠几个熟手扛住。现在主力执行者慢慢变成 Agent，那些原来藏在人脑、口头、群聊和默契里的知识，必须被显式写出来，不然系统就会在最脆弱的地方开始靠猜测运转。

换句话说，Harness 越成熟，Spec 不但不会过时，反而会更值钱。不是因为 Harness 不够强，而是因为 Harness 太强了，强到它会把你仓库里的好东西和坏东西一起放大。你写清楚了，它就高速放大你的清晰；你写含糊了，它就高速放大你的含糊。

而且腾讯那篇文章还把另外一个容易被忽略的问题讲得很透：大型 AGENTS.md 本身就是个陷阱。OpenAI 已经踩过这个坑，腾讯那边顺着这个坑继续往下分析，指出执行约束和语义约束其实是两类完全不同的东西。前者更像“不要用这个 API”“文件不要超过多少行”“这个命令不要跑”，后者更像“这个字段到底是什么意思”“这个状态在跨服务场景下怎么流转”“这个错误码在什么上下文里代表什么”。这两类东西混在一起，最后就会一起失效。文件越来越长，Agent 既抓不到行动入口，也抓不到真正关键的语义重点。

这个分析我觉得特别值钱，因为它帮我们把一个很模糊的感觉说清楚了。不是所有东西都该写进一个 agent file。AGENTS.md 更像目录和行动入口，Spec 更像系统语义和行为定义，两者职责不同。你硬把它们揉成一团，最后只会变成一个没人愿意读、Agent 也读不好的巨大说明书。

腾讯那篇文章还有一点我很喜欢，它把“Spec 漂移”这个问题单独拎出来说了。代码漂移通常还能在运行时感知，测试会挂、类型会报错、行为会出问题；Spec 漂移更阴，因为它往往是沉默的。仓库里那份 Spec 还挂着“Active”，但实际上早就没跟上系统演化了。下一个 Agent 进来，基于一份过时定义继续生成代码，整个系统就开始在错误地图上高速前进。这个问题我觉得特别真实，而且很多团队现在还没认真对待。大家会觉得“文档过时一点很正常”，但在 Agent 时代，过时文档不是中性噪音，而是主动误导。

所以腾讯那篇文章最后那几个启示，我觉得都很值得吸收进 Harness 的讨论里。第一，人类最稀缺的资源不是代码时间，而是注意力，所以 review 的重点迟早要前移到 Spec；第二，大型 AGENTS.md 是个陷阱，行动入口和语义定义要分开管；第三，Spec 漂移是必然的，只靠人工维护不够，迟早要有主动检测机制；第四，系统一出问题，首要追问不该是“人类要不要更努力一点”，而应该是“AI 还缺什么能力，才能把这件事自己做对”。我觉得这四个判断，基本已经把 SDD 为什么不会过时、反而会在 Harness 时代更重要，说得很明白了。

为什么现在 benchmark 也越来越像在测 Harness，而不是单测模型

现在很多 benchmark，像 SWE-bench Verified、OSWorld、GAIA、AppWorld、WebArena、WorkArena、Terminal-Bench、HAL。把这些 benchmark 放在一起看，你会发现一个很明显的趋势：今天有区分度的测试，越来越少是“单轮答题”，越来越多是“长链路闭环”。

终端里能不能稳定操作，浏览器里能不能真实完成任务，多步工作流里会不会把环境搞乱，跨工具、跨状态、跨时间窗口之后，还能不能维持方向感。比如 SWE-bench Verified 强调真实 issue、真实测试，天然就能暴露 retrieval、patching、validation 这些 harness 质量；OSWorld、WebArena、WorkArena 这种更偏 computer-use 的 benchmark，测的已经不是“会不会答”，而是“能不能在环境里稳定操作”；Terminal-Bench 更像是对 shell-native harness 的全面拷打；HAL 这类 leaderboard 甚至开始把可靠性和成本也纳入比较。

这说明了一件很重要的事：行业已经默认，Agent 的竞争不再只是大脑竞赛，而是整套系统竞赛。以后你再看到某个榜单，很可能不能只问“这是什么模型跑出来的”，还得问一句：它跑在什么 harness 里？不然你很可能拿着一个系统分，当成了模型分。

开源实现也越来越多了，但越看越会发现：真正稀缺的不是框架，而是系统能力

还有一些实现和参考系统：Claude Agent SDK、Anthropic 的 multi-agent research system、SWE-agent、SWE-ReX、deepagents、Harbor、AgentKit、terminal-bench 等等。把这些项目放一起看，你会发现一个很有意思的现象：大家表面上长得不同，底层都在补同一类东西。会话和状态管理、受控执行环境、任务分解和分工、恢复能力、验证闭环、trace 和可观测性，这些东西才是真正反复出现的硬需求。

阿里那篇文章里提到的 CLI-Anything 和 HiClaw，其实也是这个脉络里的东西。一个更偏“把 GUI 世界翻译成 Agent 能稳定调用的 CLI 能力”，一个更偏“多 Agent 组织、共享文件系统、模型路由、权限治理、FinOps 和网关控制”。你看名字会以为大家在做不同的产品，往底层一拆，其实都在做同一件事：给 Agent 搭更完整的执行环境。

Anthropic 那篇多 agent 研究系统的文章就特别典型。它讲得很清楚：multi-agent 真正有价值的地方，不是“人数多”，而是把大问题切成并行、可压缩的小问题，再由 lead agent 汇总。子 agent 的价值本质上是扩展 token 容量、隔离上下文、做信息压缩。但他们同时也强调，多 Agent 很费 token，也很容易出现协调复杂度暴涨。研究任务适合，因为可并行性高；大多数 coding task 不一定适合，因为强依赖和实时协调很多。

这话就特别有含金量。因为它把很多人的误区直接打掉了：多 Agent 不是目的，能稳定交接、稳定压缩、稳定恢复，才是。

所以我现在越来越不迷信“某个框架”。这些开源项目看久了，你会发现真正稀缺的不是框架 API，而是你有没有把环境、状态、规则、验证、恢复这些能力接好。

腾讯那篇文章其实也在另一条线上提醒了这一点。很多人看见 Harness 这个词火起来，会下意识地把它理解成“又多了几个工具、几个框架、几个平台”。但真把 OpenAI、Mitchell、Anthropic、HumanLayer、Inngest 这些文章放一起看，你会发现大家说的根本不是“去选一个最好的壳”，而是“你有没有把你的工程能力迁移到环境设计上”。这个迁移才是最难的。因为它要求你不再只盯着功能实现，而要开始思考：这个系统怎样组织，Agent 才能读懂；这个规则怎样表达，Agent 才能执行；这个错误怎样反馈，Agent 才能修正；这个知识怎样沉淀，下一次会话才不会重新踩坑。

对企业来说，Harness 还不只是提效工具，而是群体智能的治理层

阿里那篇文章里还有一层我觉得值得补进来，就是它不是只把 Harness 当成 coding agent 的工作台，而是把它往企业侧再推了一层。

单个 Agent 的效率提升当然重要，但真正让企业愿意长期投资源的，通常不只是“写得更快”，而是 能不能把多个角色、多个工具、多个模型、多个知识源组织成一个可治理、可编排、可持续演化的系统。

这个角度一进来，Harness 讨论的东西就会明显变化。你不只是关心 prompt 和代码生成了，你还得关心：

多个 Agent 之间怎么隔离记忆污染
文件和中间结果怎么共享
不同任务怎么路由到不同模型
凭证、权限、审计、限流怎么做
成本怎么控制，失败怎么降级

说白了，到了企业场景，Harness 已经不只是“让 AI 干活”，而是“让一群 AI 不要互相拖垮、不要失控、还能被治理”。这个思路和 HiClaw 那类项目想解决的问题，其实是一致的。

所以我觉得 Harness Engineering 这个词会越来越常见，不是因为它听起来新，而是因为 Agent 一旦从“单人副驾驶”往“组织级执行者”演进，你迟早都得补上这一层。

看完这一圈文章之后，我现在对 Harness 有三个更明确的判断

第一个判断是，prompt engineering 没死，但它确实降级了。Prompt 当然还重要，但它现在更像一台机器里的一个零件，而不是那台机器本身。真正决定效果的，是 prompt 能不能接上工具、接上状态、接上规范、接上验证、接上恢复、接上评估。脱离这些单谈 prompt，有点像在研究怎么把方向盘擦得更亮。

第二个判断是，未来最值钱的工程能力，不一定是“写”，而是“布置”。OpenAI 那句 Humans steer. Agents execute. 我觉得不是一句宣传语，它其实是在提前描述一种角色转移。以后越来越值钱的人，可能不是手写代码最快的人，而是最会做这些事的人：把问题拆成 Agent 吃得下的粒度，把经验沉淀成稳定工件，把主观口味变成可执行规则，把运行反馈暴露给 Agent 自己，给系统设计边界、恢复和回收机制。说白了，就是更会布置战场的人。以前拼的是谁手更快，后面拼的很可能是谁把场搭得更对。

第三个判断是，Harness Engineering 本质上是在把“AI 味”一点点挤出去。很多人现在一看 AI 生成的东西，就说有股“AI 味”。我现在越来越觉得，这个味道很多时候不是模型天生带的，而是 harness 太差导致的。规范不清，所以它讲空话；验收模糊，所以它自我感觉良好；上下文太脏，所以它重复、漂移、跑偏；没有反馈，所以它看起来很忙，实际没闭环。从这个意义上说，Harness Engineering 干的事非常朴素：它不是在给模型加戏，而是在不断挤掉系统里的模糊、噪音和侥幸。

普通人今天能怎么开始

说了这么多，最后还是得落回来。不然又变成一篇“看完觉得很有道理，然后什么都没改”的文章。

如果你今天就想把自己的 AI 工作流往前推一步，我觉得不用学大厂那套完整系统，先做几件事就够了。

先建一个短而稳的入口文件，别写百科全书，只写目录结构、构建命令、输出要求、禁止事项、去哪找详细资料。再把长期知识放回文件系统，规范、模板、参考资料、历史决策固定存放，不要每次都靠聊天记录和复制粘贴续命。

再往下，就是先写验收单，再让 Agent 开始干活。不要只说“做个页面”“写篇文章”“修个 bug”，要把“怎样算做完”说清楚。然后给它看结果，不要让它盲改，能跑测试就跑测试，能截图就截图，能看日志就看日志，能回放就回放。

最后，每次犯错都别只纠正一次，要想办法把它固化下来，变成 lint、清单、模板、脚本、文档、hook，让同样的错，不要下次还靠你亲自盯。对个人来说，这是把 AI 从“会聊天的助手”往“能协作的执行者”推一步；对团队来说，这其实就是你们第一版 harness 的起点。

这几件事做完，你的 harness 可能还很粗糙，但已经不是“纯聊天”了。你会明显感觉到，AI 不再只是时灵时不灵地给你吐答案，而是开始有一点“真在这个环境里干活”的味道了。

如果再往前多走一步，我觉得腾讯那篇文章给的启发也很值得普通团队直接照着想。别把“写 Spec”理解成官样文章。真正有用的 Spec 不是为了给人看着舒服，而是为了让 Agent 少猜一次、少返工一次、少把错误放大一次。你现在每次在 review 里发现 AI 又把某个字段理解错了、又把某个跨服务契约猜偏了、又把某个边界条件漏了，其实都可以反过来问一句：这件事是不是应该前移写进 Spec，而不是等下一次再人工纠正？

这就是 Harness 最实在的起点。不是一上来搭一个很大的平台，也不是先聊宏大方法论，而是把一次次真实犯错，慢慢固化成它以后不再犯的环境。

写在最后

我现在越来越不觉得 Harness Engineering 是个营销词了。

它更像是 AI 时代的软件工程，被现实逼出来的一次重新分工。

以前很多东西做得差一点，也许还能靠几个老工程师硬撑住。现在主力执行者慢慢变成 Agent，这些以前模糊过去的地方，全都会被成倍放大。文档烂、边界松、日志乱、规格虚、验收空，这些东西以前只是“不够专业”，现在会直接把 Agent 用废。

所以最后你会发现，Harness Engineering 讨论的根本不是“怎么更优雅地用 AI”，而是一个老问题的新版本：

什么样的系统，才配得上持续协作？

以前这是问人的。

现在，也得问 Agent 了。