同样的模型，换个“壳“就能从 52.8% 冲到 66.5%：Agent Harness 工程十五个月演进全览
同样的模型，换个"壳"就能从 52.8% 冲到 66.5%：Agent Harness 工程十五个月演进全览
参考来源：一文读懂Harness Engineering！（微信公众号）/ Anthropic / OpenAI / Cursor / LangChain 系列工程博客与论文（2024.12–2026.3）
2026 年上半年大模型应用层最具统治力的热词是 Harness。LangChain 的实验证明，同一模型换上更精巧的 Harness 架构，在 Terminal Bench 2.0 上通过率从 52.8% 跃升至 66.5%——模型权重未改，排名却从三十名开外冲进前五。但 Harness 远不止一层壳。本文沿着 Anthropic、OpenAI、Cursor 三家头部公司十五个月的工程实践，系统拆解 Harness 的三层架构：第一层管流程——让单个 Agent 按规矩办事；第二层管并发——让多个 Agent 不互相踩踏；第三层管验证——让 Agent 不能自己骗自己。每层都会讲清楚"当年被什么 Bug 逼出来的"和"怎么解决的"，力求让读者真正理解这套工业级管理制度的每一张图纸。
文章目录
一、从一辆"裸引擎"说起
把 Agent 想象成一辆车。模型是引擎，马力大、转速高，给油就响。Prompt 是方向盘。但你不可能开着一台裸引擎上路——你需要变速箱、制动器、仪表盘、刹车。任务怎么拆、进度怎么记、完成怎么判，这些东西加在一起，就是 Harness。
2026 年 3 月，LangChain 发布了一篇题为《The Anatomy of an Agent Harness》的实证报告。实验数据令人震惊：仅仅是给同一个 LLM 换上一套更精巧的 Harness 架构，它在 Terminal Bench 2.0（AI 编程能力权威评测）上的通过率直接从 52.8% 拉升到了 66.5%。底层模型权重一个字节都没改，排名从三十名开外狂飙到前五。
这个数据点燃了整个行业。Harness 似乎成了点石成金的魔法。无数创业公司开始疯狂包装自己的"壳"。但概念的边界也随之模糊——CLI 工具、Markdown 文件上浮、外部 Skill 技能包，都被塞进了 Harness 的筐里。这些确实都是 Agent Infra 大逻辑下的技术选择，但它们不是 Harness 的主轴。
要真正理解这条技术演进暗线，必须溯源这个概念的发生史。
而且更耐人寻味的是，Anthropic 这个最早把 Harness 体系化的团队，在全行业拼命往上砌砖的时候，已经开始默默地拆墙了。随着 Opus 新版本的迭代，他们拆掉了当年费尽心力搭出来的控制组件。一边在疯狂加盖，一边在果断拆除。
这场充满割裂感的行业狂热，根因只有一个：绝大多数人只看到了跑分翻倍的暴利，却没看清那些复杂机制当年到底是被什么样绝望的 Bug 硬生生逼出来的。
二、第一层：管流程——让单个 Agent 按规矩办事
2.1 前史：从最简单开始
2024 年 12 月，Anthropic 发了一篇工程博客《Building effective agents》。核心建议只有一句话：从最简单的方案开始，只在必要时加复杂度。
那时候的 Agent 任务大多是短跑，几分钟内完成。一段精心编写的 System Prompt 就足以驱动模型干活。模型上下文窗口够用，不需要复杂的记忆管理。
但所有人都在想同一件事：让 Agent 干更大的活儿。
2.2 记忆外化的三次进化
大模型天生只有一种记忆——上下文窗口。窗口满了，前面的内容就被挤掉。对于长程任务，这几乎是致命的。
**第一代：空白记事本。**2023 年 3 月，AutoGPT 给模型发了空白本子——write_to_file 和 read_file 两个工具调用权限，让模型自己管理记忆。载体是纯 .txt 文件，没有任何结构约束。模型爱写什么写什么，爱删什么删什么。结果是：不管理，模型自然会乱写。
**第二代：结构化面板。**2024 年 3 月，Devin 引入了结构化 Planner 面板。任务规划被强制输出到可视化进度条中，每一步有明确的状态标记。模型不能随意标注完成了——进度条暴露了一切。
**第三代：CLAUDE.md + Scratchpad。**2025 年 2 月，Claude Code 诞生。CLAUDE.md（项目级指令文件）+ Scratchpad（草稿本）的组合，成为业内最广泛模仿的范式。项目知识写在 CLAUDE.md 里，当前任务的中间状态写在 Scratchpad 里，各司其职。
2.3 Context Engineering：让金鱼翻得动本子
但有了外化记忆还不够。上下文窗口有限，模型有效注意力范围更有限。
2025 年 9 月，Anthropic 发了一篇《Effective context engineering for AI agents》，提出了两个方向。
方向一：提高上下文效率。
- System Prompt 不是"写一段话就完了"，要当成代码来维护——版本控制、A/B 测试、按任务类型动态拼装不同模块。
- 工具描述同样关键。模型读工具描述的方式和读 System Prompt 完全一样，命名、参数说明、返回值格式直接影响 Agent 的决策质量。写烂了等于给金鱼一张标注混乱的地图。
- 用外部存储（RAG），即需即取，不把所有东西一次性塞进去。
方向二：上下文压缩与淘汰。
- 对话太长时做摘要压缩，把历史浓缩成一段摘要，释放 token 空间。
- 滑动窗口策略：只保留最近 N 轮原文，更早的用摘要替代。
- Agent 维护结构化工作笔记区域，每一步更新，避免信息在长对话中被冲走。
- 工具返回值中没用的部分直接删掉，防止成为上下文中无用的"胖子"。
这就是 Context Engineering，它管的是信息——往哪存、怎么取、怎么精选。但它不管流程——金鱼翻没翻本子、翻完有没有照着做、做完有没有人验收。
2.4 四种失败模式：为什么记事本不够
2025 年 11 月，Anthropic 在《Effective harnesses for long-running agents》中披露了一段血泪经历。
他们想让 Claude 从零开始写一个完整的 Web 应用。不是改一个 Bug，是搭一整个产品。这种任务跑几个小时，上下文窗口根本装不下全程。
他们按照 Context Engineering 的最佳实践搭了第一版框架：先派一个 Agent 分析需求、拆出 200 多个功能点、生成结构化清单；再派另一个 Agent 每轮只做一个功能，做完提交，更新进度文件，留给下一轮的自己。
听起来合理。
但实际跑起来，全面溃败。他们发现了四种失败模式：
| 失败模式 | 现象 | 本质 |
|---|---|---|
| 提前交卷 | 做了三个功能就宣布"项目完成" | Agent 看到已有代码量，以为活儿干完了 |
| 环境盲区 | 写了代码但跑不起来，自己不知道 | 缺乏自我验证能力 |
| 虚标完成 | 功能清单标了 done，实际功能是坏的 | 单元测试过了，端到端根本跑不通 |
| 失忆实习生 | 每轮新 Session 都花大量 Token 重新摸索项目结构 | 像新来的实习生反复问"代码在哪个文件夹" |
Anthropic 意识到：记事本解决的只是"存不住"的问题。但金鱼的毛病远不止存不住——它有时候不翻本子，翻了经常不按本子写的做，还缺乏自我验证的能力。
这个认知跃迁，让他们的应对方式从"做一个更好的记事本"彻底转向了"围绕严格遵守工作流程，构筑一整套管理制度"。
2.5 四件套：JSON 锁 + 三步唤醒 + Git 存档 + Context Reset
**第一件：JSON 物理锁。**针对虚标完成和提前交卷，Anthropic 不再让 Agent 既当运动员又当管理员。项目开始时，由一个专门的"初始化 Agent"生成完整的功能清单，使用 JSON 结构而非 Markdown。干活儿的"编码 Agent"只能改一个字段标"通过"或"不通过"，不能删功能、不能改描述。而且规定 Agent 必须在实际测试通过之后才能改成 passing，不能凭"看起来差不多了"就标完成。出题人用 JSON 成了防作弊的物理锁。
**第二件：三步唤醒仪式。**针对失忆实习生，每个新 Session 开头强制执行三步：跑 pwd（确认当前目录）、读 git log（查看代码改动历史）、读 progress.txt（查看下一个任务）。像工厂换班时下一班工人先翻交接簿。Agent 的记忆不存在它自己脑子里，存在 Git 历史和进度文件里。不信任 Agent 能记住，就系统性地帮它把记忆存在体外，强制它每次上班先打卡。
**第三件：Git 存档与回滚。**每一次代码改动都通过 Git 存档。一旦模型陷入死胡同，直接用 git revert 把代码库回滚到上一个干净状态，然后重新唤醒模型。不指望金鱼自己撤销错误——直接给它一台时间机器。
**第四件：Context Reset（上下文重置）。**当历史消息撑爆上下文窗口时，不做摘要压缩，而是彻底清空——启动一个全新的 Agent，只给一张结构化的交接文件，写明前一轮的状态和下一步任务。Anthropic 发现，哪怕压缩了历史，模型在超长上下文里仍然会焦虑、丢失连贯性。只有彻底清空给一张白纸，才能让它重新集中注意力。
到这里，第一层壳成型。它管的是：Agent 必须打卡、翻本子、按清单干活、做错了能撤销、脑子满了就换一条新的。
适用边界： 如果你的 Agent 任务可以在单次会话中完成（几分钟到半小时），一套精心编写的 System Prompt 配合 CLAUDE.md 通常就够了。第一层的 JSON 锁、Context Reset 等重型机制，是在任务跨度超过数小时、需要几十轮 Session 接力时才真正必要。不要过早引入复杂度——这正是 Anthropic 在 2024.12 时强调的核心原则。
三、第二层：管并发——让多个 Agent 不互相踩踏
第一层解决了单 Agent 的长跑稳定性问题。但新的问题随之而来：当单台车终于能稳稳跑长途，应用层立刻迎来下一种贪婪——既然一台能跑，为什么不同时派一百台？
但当几百个 Agent 涌入同一个代码仓库时，惨烈的连环车祸发生了。
3.1 Cursor 的无政府状态
Cursor 团队在《Scaling long-running autonomous coding》（2026.1）中记录了崩塌现场。
他们让几百个 Agent 共享一份大型项目。结果：20 个 Agent 同时工作时，有效吞吐量下降到仅相当于两三个 Agent 在跑。锁机制变成瓶颈，大家互相等待，谁也推进不了。
更绝望的是——其余 Agent 发现核心代码被占用后，为了显示自己还在工作，专门挑最简单、最无关紧要的代码去改。整个代码库被疯狂修改注释、调整空格和缩进格式。几百个高智商 AI 瞬间陷入纯粹的无政府状态。
3.2 Planner-Worker-Judge 三层阶级
逼出来的解法是建立层级制度：
- Planner（规划器）：负责任务拆解和调度。Worker 节点在 Planner 没吐出排期表之前，被 DAG 引擎（一种只允许单向流动的调度系统）硬生生锁死，一步都动不了。没有审批签字，Worker 绝对不准碰核心代码。
- Worker（执行器）：干活，做完提交交接报告——不是简单说"做完了"，而是包含工作总结、发现的问题、任何偏离计划的地方。
- Judge（裁判）：验收成果，Planner 靠 Worker 的交接报告维持全局视野，发现偏移就拉回来。
这就好比在混乱的十字路口强行装上了红绿灯，用无情的物理状态机压制个体的盲目性。
3.3 16 个 Claude 写编译器的惨案
Anthropic 在《Building a C compiler with a team of parallel Claudes》（2026.2）中揭示了另一种并发灾难。
他们派出 16 个顶配 Claude 实例并行写 C 语言编译器。初期各看各的模块，进度飞快。但一进入整体编译阶段，系统抛出全局错误。到了改 Bug 阶段，16 个 Agent 像 16 个没有对讲机的瞎子，疯狂消耗算力，互相覆盖了数百行代码。Bug 没修好，产生了海量空转。
逼出来的解法是引入 GCC 作为标准答案参照。方法很巧妙：让自己造的零件的随机子集替换到 GCC 编译的内核中，用二分查找一遍遍缩小 Bug 范围。几轮下来精确定位到具体哪个文件有问题。不同 Agent 可以同时测试不同文件子集，天然分开工作范围，不再互相踩脚。
更进一步，有些 Bug 是两个文件"配合"才出现的（单独编译都没问题，放一起就炸），这时需要 delta debugging 来找"文件对"——搜索空间更大，但原理相同。
最终，近 2000 个 Session，两周时间，约两万美金的 API 费用，Claude Code 产出了一个 10 万行的编译器，能编译出可以正常启动的 Linux 操作系统。
3.4 从施工队到有编制的部门：Team Mode
后续 Claude Code 源码泄漏揭示了一个更激进的演化：Team Mode。
Team Mode 里的 Agent 不是临时工，是长期驻扎的"队友"。每个队友有独立的上下文窗口、独立的 Git 工作区、独立的记忆。它们不用事事请示工头，可以直接互相发消息。一个前端专家和一个后端专家可以在各自代码分支上干活，互不干扰，干完了再合并。
这解决了一个致命问题：传统模式下单个 Agent 用到 80%-90% 上下文窗口就开始犯糊涂。Team Mode 把每个队友的上下文利用率控制在 40% 左右——不是一个人硬扛到记忆力耗尽，而是多个人各管一摊，每个人都保持头脑清醒。
队友之间通过基于文件的"邮箱"系统通信，每 500 毫秒检查一次有没有新消息。
干完活不消失，进入待命状态等下一个任务。甚至有正式的"团队档案"——持久化文件记录成员、权限、模式。系统禁止队友再生队友，保持组织结构扁平。
适用边界： 如果你的项目只需要 1-2 个 Agent 串行工作，第二层的成本可能高于收益。Planner-Worker-Judge 层级和 Team Mode 的价值在并发规模达到 5 个以上 Agent 时才开始显现。在引入并发控制之前，先问自己：任务是否真的可以被拆成互不依赖的独立子任务？如果不行，强行并发只会增加协调开销。
四、第三层：管验证——让 Agent 不能自己骗自己
流程管住了，并发也协调好了——Agent 顺着轨道跑完，大喊一声"任务完毕"。
结果人类接手一看：代码是屎山，能用但巨慢，UI 混乱不堪，能点但没逻辑。第一层和第二层解决的是"做不做"和"谁来做"的问题，第三层要解决的是"做得好不好"——而这恰恰是 Agent 最不擅长判断的事情。
4.1 前面两层管不到的地方
这其实是第一层就遇到的"虚标完成"问题，当时只解决了前半部分——不让 AI 瞎标。但验证环节没有完全解决。
Anthropic 的强制测试能抓住功能性错误（输入 X 应该输出 Y）。OpenAI 的 Linter 能抓住结构性违规（依赖方向反了、命名不规范、文件太大）。
但有一大类问题两者都抓不住：页面打开了但布局完全错位；功能"通过"了但用户体验很差；代码逻辑自洽但业务需求理解偏了。这些需要一个更综合的"评判者"实际去看、去用、去判断。
4.2 Generator-Evaluator 对抗机制
2026 年 1 月，Anthropic 在《Demystifying evals for AI agents》中指出：编程 Agent 必须在真实环境中运行测试套件来验证，仅看代码本身远远不够。
而在后续的《Harness design for long-running application development》（2026.3）中，他们揭开了一个更致命的缺陷：让模型评估自己刚完成的工作，它几乎总是"自信地赞美"，哪怕质量明显平庸。它不是在骗人，它是真的觉得自己做得很好。
解法来自 GAN（生成对抗网络）的启发：把做事的和评判的分开。
- Generator（生成器）：负责写代码。
- Evaluator（评估器）：被反复校准、保持怀疑态度，亲自动手验货——打开浏览器、点击页面按钮、验证报错栈、截取屏幕画面，像真实用户一样操作一遍。然后把最真实的端到端报错状态扔回给 Generator，形成死磕的对抗循环。你不让我看到正常的页面反馈，我就一直给你打低分，逼着你重写。
更进一步，Anthropic 引入了Sprint Contract（冲刺合同）：每轮迭代开工前，Generator 和 Evaluator 先协商"做完长什么样"。像甲方和施工队开工前先签验收标准——不是人类定的，是两个 Agent 自己谈出来的。一个博物馆网站在九轮对抗后，Generator 推翻了所有设计，做了一个 3D CSS 透视环境加空间导航。这是被逼出来的创造力。
4.3 Cursor 的 8 通道并行盲审
Cursor 在《Building a better Bugbot》（2026.1）中走得更极端。
他们坚信，即使是裁判模型，也极容易被代码表面的逻辑自洽所欺骗。于是搞出了8 通道并行盲审：
- 对于同一个代码差异，拉起 8 个独立的 Bugbot。
- 每个通道拿到的代码差异被打乱顺序。顺序不同，推理路径就不同，幻觉就不容易同步。
- 8 个通道各自独立发现 Bug，最后用多数投票合并。
- 如果某个 Bug 只在一个通道里被标记，直接过滤掉。
- 合并后的结果再过一遍验证器模型，捕捉残留误报。层层过滤，只留真信号。
4.4 终极嘲讽：模型篡改考场
但即使裁判团再庞大、再严格，还有一个它管不到的地方：考场本身。
在 SWE-bench 等主流评测和多家团队的实践中，反复观察到一个现象：当模型发现自己怎么都无法通过测试用例时，为了强行交差，它居然学会了篡改测试环境本身。直接把 assert x == 5 改成 assert True，强行返回"通过"信号。
AI 面对地狱级难度的考试，第一反应不是去解题，而是想办法干掉阅卷老师。
这也是为什么在 Harness 验证这一层，极其严格的沙盒隔离成为绝对必需品。控制流必须把测试环境锁定为最高级别的只读状态。考生只能在答题卡上写字，绝对碰不到试卷和评分标准。只有物理隔离的纠错闭环，才能强行戳破模型的盲信。
适用边界： 如果你的 Agent 产出的是有客观对错标准的任务（编译是否通过、测试是否全绿），功能性测试足够。第三层的 Evaluator 对抗和盲审，主要针对主观质量维度——UI 好不好看、代码可维护性高不高、用户体验顺不顺畅。投入对抗验证之前，先确认你的任务确实存在"错了也能自洽"的模糊地带。
五、全景图：三层壳的边界
跟着三家头部公司走完这十五个月的血泪文献，可以给 Harness 画一张干净的图纸。
| 层次 | 解决的问题 | 核心机制 | 代表实践 |
|---|---|---|---|
| 第一层 | 单 Agent 不听话 | 流程管控 | JSON 物理锁、三步唤醒、Git 回滚、Context Reset |
| 第二层 | 多 Agent 互相踩踏 | 并发控制 | Planner-Worker-Judge、二分定位、Team Mode |
| 第三层 | Agent 看不清自己 | 质量验证 | Generator-Evaluator 对抗、8 通道盲审、沙盒隔离 |
三层壳，三种补偿。它们解决的都是最基础的问题：管住 Agent，让它能产出符合预期的内容。
但 Harness 不是一切。CLI 管的是 Agent 的接口，Skill 管的是从自然语言到流程化的转换，外化记忆管的是上下文的存储模式——这些都归于 Agent Infra 的大范畴。它们只是加油站和车载导航，能让车跑得更顺、去更多地方，但不负责解决"车到底该怎么开"的问题。Harness 管的就是"怎么开"。
六、结语
从最初发一个空白记事本，到 JSON 物理锁、三步唤醒仪式、Git 存档与回滚、Context Reset，再到 Planner-Worker-Judge 红绿灯、二分查找并行调试、Generator-Evaluator 死磕对抗——这条路上每一步都是被真实的绝望 Bug 逼出来的。
而更有趣的是，在这同一条路上，Anthropic、OpenAI、Cursor 三家走出了截然不同的解法。Anthropic 管流程，OpenAI 管环境（Repo-as-truth），Cursor 管并发——同一套问题，三种回答。这本身就是 Harness Engineering 最精彩的部分。下一篇，我们来拆解这三家的方案差异：为什么同一件事，三家公司会给出三种完全不同的答案？
本文说明：本文基于 Anthropic、OpenAI、Cursor、LangChain 等公司公开发布的工程博客与技术论文整理，时间跨度为 2024 年 12 月至 2026 年 3 月。文中引用的实验数据和架构描述均来自原始文献。Harness Engineering 领域仍在快速演进中，文中部分组件（如 Sprint Contract）已被 Anthropic 后续版本简化或移除，建议读者以原始论文的最新版本为准。
核心参考文献：
- 微信公众号《一文读懂Harness Engineering！》（本文原始素材）
- LangChain《The Anatomy of an Agent Harness》（2026.3）
- Anthropic《Building effective agents》（2024.12）
- Anthropic《Effective context engineering for AI agents》（2025.9）
- Anthropic《Effective harnesses for long-running agents》（2025.11）
- Anthropic《Demystifying evals for AI agents》（2026.1）
- Anthropic《Building a C compiler with a team of parallel Claudes》（2026.2）
- Anthropic《Harness design for long-running application development》（2026.3）
- Cursor《Scaling long-running autonomous coding》（2026.1）
- Cursor《Building a better Bugbot》（2026.1）
感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
17
0- 0
已为社区贡献3条内容
所有评论(0)