LLM向左，Agent Harness向右 =
原创 鲁工 AI编程实验室 2026-03-26 17:00 浙江
大家好，我是鲁工。
最近一周都在收集和学习Agent Harness和Harness Engineering相关的资料。作为年后最火的Agent工程概念，我觉得有必要写一篇文章来普及Harness。
经过近一年的Vibe Coding实践，我越来越强烈地感觉到一件事：模型能力和实际产出之间，隔着一道很深的沟。这道沟跟模型本身关系不大，跟模型外面那层运行环境关系很大。
这篇聊聊我对这件事的理解：LLM向左，Harness向右。
Harness Engineering的由来
那么，什么是Harness呢？
简单来说，就是包裹在模型外面的那层控制系统。它管的事情很杂，上下文怎么组织、工具怎么调、权限怎么划、测试怎么跑、失败了怎么恢复、跨会话的状态怎么续。
Agent Harness概念全景图：
更形象一点的说法是，LLM是发动机，Harness是底盘加方向盘加刹车。发动机再猛，没有这些东西，车还是上不了路。
先来回溯一下。Harness Engineering不是一下子变出来的，如果你对这个词陌生，那么我提Prompt Engineering和Context Engineering你就熟悉了。
2024年之前，Prompt Engineering（提示工程）围绕LLM的关键概念。彼时的核心诉求是，如何让模型听懂指令并输出符合预期的结果。比如通过Few-shot、Chain-of-Thought等提示词技巧，来激发模型的特定能力。本质上是一锤子买卖。
2025年开始，随着Manus爆火，Claude公开Agent相关实践，Context Engineering（上下文工程）这个词随之兴起。这一范式不再纠结于具体的提示用词，而是致力于构建动态的信息管道。在模型每一次需要输入时，能够选择性的看到哪些信息、调用哪些工具。2025年爆火的Vibe Coding概念，其实践本质上就是一连串的上下文工程游戏。
Harness Engineering（这个词还没有通用的中文翻译，姑且叫它运行控制工程）的概念是在今年2月份才开始流行的。
Mitchell Hashimoto（就是做Terraform那位）在博客里把自己的AI编程进化路径分成了六个阶段，第五阶段直接叫Engineer the Harness。几天之后 OpenAI 发了篇博文，正式用Harness Engineering来命名这套工程实践。Martin Fowler站点的Birgitta Böckeler紧跟着出了一篇分析。几周之内这个词就火了。
三者之间的对比图：
概念追溯完了，我们看一下关于Harness Engineering的实践数据。Harness到底能带来多大差异？
Agent Harness实践
Nate B Jones（一位AI圈内的内容创作者和评论者）做过一项测试：同一个模型，什么都不改，只换外面的Harness，编程基准的成功率从42%跳到了78%。翻了将近一倍。
LangChain在2026年2月也验证了类似的事情。他们用GPT-5.2-Codex跑 Terminal Bench 2.0，模型不动，只调Harness，分数从52.8拉到了66.5，排名从三十名开外冲进前五。他们做的调整主要是三件事：加了自验证循环，注入了环境信息，以及在关键节点强制模型停下来重审计划。
划重点：模型一行代码没改，只改了壳，性能提升相当于换了一代模型。
还有一组数据也很能说明问题。假设Agent每个步骤的成功率是95%，非常高了。但一个20步的流水线跑下来，端到端的完成率只有36%。这就是复合失败效应，每一步的小误差会指数级放大。而根据harness-engineering.ai的测试，仅仅加一层验证环节，任务完成率就能从83%提到96%，模型完全没动。
我自己在用 Claude Code 的时候也有过类似的体感。同一个 Claude Opus，在一个没有 CLAUDE.md、没有测试、没有结构化文档的老项目里，经常写出让我想摔键盘的代码。但在另一个我花了时间搭好约束体系的项目里，它的表现稳定很多。模型没换，换的是环境。
数据说完了，再聊聊几个大厂的具体做法。
OpenAI Codex团队做了一个很有冲击力的实验。他们从一个空仓库开始，5 个月时间，3个工程师（后来扩到7个），用GPT-5驱动的Codex CLI，从零构建了一个完整的生产级应用。
最后的数据是：大约100万行代码，合并了约1500个PR，人类一行代码都没手写。平均每位工程师每天合并3.5个PR。按传统方式估算，工期大约是现在的 10倍。
但这件事最让我在意的，其实是OpenAI自己给出的结论。他们没说模型替代了工程师，他们说的是：工程师的主要工作变了，从写代码转向了设计环境、建立反馈回路和控制系统。
核心工程师Ryan Lopopolo有一句话说得很直白：Agent不难，Harness才难。
我仔细读了OpenAI的那篇文章，会发现他们在Harness上的实践深度远比外界想象的要深（这么好的文章我竟然过了一个多月才看到）。
先说上下文管理。他们的核心原则是"给Codex一张roadmap，别给一本千页说明书"。AGENTS.md只有大约 100 行，更像一个目录，指向仓库里结构化存放的设计文档、架构规范和质量标准。
他们试过把所有规则塞进一个大文件，结果发现四个问题：挤占了任务本身的上下文，什么都标"重要"等于什么都不重要，内容过时速度极快，而且没法机械化验证。
AGENTS.md
所有的隐性知识都必须显性化。他们原文里有一句话我觉得很到位：Slack上对齐的架构决策，如果没推进仓库，对Agent来说就跟不存在一样，就像一个三个月后入职的新人也不会知道。
再说执行环境。他们给Agent接了Chrome DevTools Protocol，让Codex能自己截图、操作DOM、验证UI渲染。每个git worktree还配了一套本地可观测性栈，Agent能用LogQL查日志、用PromQL查指标，跑完任务整套环境自动销毁。所以像"确保服务启动不超过800ms"或者"关键用户路径里没有超过2秒的span"这种prompt，Agent自己就能验证。
然后是架构约束。他们设计了严格的分层规则：Types → Config → Repo → Service → Runtime → UI，每一层只能依赖下面的层。这些规则靠自定义 linter 和结构化测试来强制执行，CI直接挡住违规。而且linter的报错信息里嵌入了修复指引，相当于把老师傅的经验写进了编译器。
还有一个细节挺有意思：他们最初每周五花20%的时间手动清理AI生成代码里的slop（风格漂移、重复代码、过时模式），后来发现不可持续，就改成了自动化的"垃圾回收"机制。定期启动专门的Codex任务扫描偏差、更新质量评分、提交修复PR，大部分 PR一分钟内就能审查合并。
到后期，他们的Agent已经能端到端跑完一个完整的功能开发循环了：验证代码库状态、复现bug、录一段视频证明问题存在、实现修复、再验证、再录一段视频证明修复有效、开PR、回复审查意见、检测构建失败并修复、只在需要人类判断的时候才上报。单次Codex任务经常连续跑6个小时以上，通常是工程师们睡觉的时候在跑。
而且他们把几乎所有的代码审查都推给了Agent之间互审。人工也可以审，但不是必须的。
这个其实跟我自己折腾CLAUDE.md的经验很像。我发现CLAUDE.md写得太长反而不好使，ETH Zurich的一项研究也发现这类文件超过60行效果就开始下降。
关键是分层，把规则写成索引，别写成百科全书。OpenAI的做法验证了这一点：渐进式披露（又有点像Skills了），Agent先看到一个小而稳定的入口，然后被引导去该看的地方，而不是一上来就被信息淹没。
OpenAI聊完了，再来看Anthropic。
Anthropic在2025年11月发过一篇关于长时程Agent的文章，核心观点是：难点不在单次上下文窗口里面，而在多次离散会话之间怎么保持连续推进。
他们的解法是设计了一个双阶段结构。initializer agent负责第一次进场时搭环境，创建init.sh脚本、生成包含200多个feature的进度清单（JSON格式，初始全标为false）、做初始git commit。之后每次进场的coding agent读进度文档和git历史，每次只推进一个feature，完成后更新进度文件。
说白了就是给Agent建了一套交班制度，确保下一次进场的Agent不用从头摸情况。
Cursor在多智能体编排上也踩过不少坑，他们的Self-Driving Codebases文章写得很坦诚。
单Agent在复杂项目上天然会慢，多Agent并发看起来是直觉解法。但他们试了好几版，平权协作会带来共享状态冲突和锁竞争，Agent之间互相打架。最后他们转向了递归的Planner-Worker 结构：Root Planner拥有全局视野做切分，Worker在各自的仓库副本上独立干活。
他们还发现了一个有点黑色幽默的事：一条模糊的初始指令，一个Agent犯的错，乘以几百个并发Agent，结果必然是崩了。
这件事其实验证了一个很朴素的道理：Agent一多，问题就从智能变成了组织。一旦组织成了核心问题，Harness就从辅助工具变成了主战场。
Harness也不是魔法
话说回来，我也不觉得凡事都能归因于Harness。
METR在2026年3月做了一项很有参考价值的研究。他们找了scikit-learn、Sphinx、pytest三个项目的4位活跃维护者，去审查296个通过了SWE-bench 自动评分的AI PR。结论是：大约一半自动评分通过的PR，维护者实际上不愿意merge。
以Claude Sonnet 4.5为例，自动评分器认为它能处理大约50分钟范围的任务，但维护者实际愿意合并的PR对应的任务范围只有8分钟左右。相差了大约7倍。
这个数据提醒我们，基准分和真实生产价值之间差距还很大。Harness能让 Agent的行为分布更可控、更连续，但它没法自动抹平真实工程里对代码质量、风格一致性和长期可维护性的要求。
OpenAI的Noam Brown在Latent Space的一次访谈里也直接说了：Harness就像一根拐杖，我们终将能够超越它。他的理由是，推理模型出来之后，之前在GPT-4o上搭建的大量Agentic系统一夜之间就不需要了。他的预判是 OpenAI最终会走向一个统一模型的方向。
这个观点我觉得有道理，但可能还不够。
我自己的判断是这样的：LLM向左，Harness向右，说的其实是分工重排。
模型向左，意思是基础模型的能力会继续沿着规模、推理深度、上下文长度这条路往前卷，而且会越来越平台化，越来越像公用电力。
Harness向右，意思是每个团队会围绕自己的业务、代码栈、合规边界和工程文化，长出越来越具体的控制系统。这种差异化短期内不会被统一模型吃掉，因为它本质上是业务工程问题，不是通用智能问题。
harness-engineering.ai上有一句话说得很直白：模型是大宗商品，Harness 才是护城河。这话虽然有点绝对，但方向没错的。
打个比方，数据库再成熟，你的数据建模工作不会消失。云服务再成熟，你的系统架构工作也不会消失。模型越强，反而越需要有人把强能力收束成可交付的生产力。
很多团队现在最大的问题，其实不是模型不够强。是没有给模型搭一个正确的系统：没有稳定的工作区，没有最小权限边界，没有结构化的知识入口，没有可回放的trace，没有严格的测试信号。这种情况下，模型每强一分，输出波动可能反而放大一分。你会觉得它偶尔惊艳、偶尔离谱、偶尔拉个大胯，整体不可控。
把这些控制面补上，模型的价值就会从灵光一现变成可重复产能。这个转变，才是Harness Engineering真正要解决的事。
Noam Brown（OpenAI研究员）说得对，很多脚手架确实会随着模型进化被淘汰。但架构约束、反馈循环、熵管理这些东西，本质上不会消失，只会换形态。就像从马车到汽车，马鞭消失了，但方向盘和刹车不会消失。
所以Harness阵营真正该担心的，其实是自己搭的壳会不会六个月就过时。Noam Brown那句"别花六个月搭一个可能六个月后就被淘汰的东西"，反过来恰恰是最好的Harness Engineering建议是：
Harness要轻，要模块化，要随时准备被拆掉重来。
模型回答的是它会不会。Harness决定的是它能不能持续地做、批量地做、低成本地做、在真实约束下做。前者是能力问题，后者是交付问题。真实世界里，交付从来比能力更稀缺。
参考资料：
[1] https://openai.com/zh-Hans-CN/index/harness-engineering/
[2] https://harness-engineering.ai/blog/agent-harness-complete-guide/
[3] https://mitchellh.com/writing/my-ai-adoption-journey
[4] https://cursor.com/blog/self-driving-codebases
如果觉得有用，点个赞或者在看，也方便更多朋友看到。
我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道。感兴趣的朋友也可以加我微信（louwill26_）交个朋友。