先说几个核心判断。
2023年，你让AutoGPT写一个登录页面。它兴致勃勃地开始写代码，然后觉得应该先研究一下最佳实践，于是自己调用了浏览器搜索。搜到一半，又觉得应该先把路由配置好。配置路由时，它“灵光一现”，想重构整个项目结构。30轮循环之后——登录页面没写完，它还把已有的代码搞崩了。你盯着终端，心情复杂。
到了2024年，你用LangChain加Claude写同样的功能。这回好多了：框架帮你串好了prompts、tools和memory。Agent能跑了。但每次它用错API，写出时灵时不灵的代码，你还是得手工介入。感觉就像给一个聪明但毛手毛脚的“实习生”擦屁股。
2026年，你在Claude Code里说“加个登录页面”。系统自动拉取项目规范，并行调度子Agent——一个写前端组件，一个写后端接口，一个写测试。沙盒里跑测试，通过了才提交。不通过？自动回退修改，提取错误规则写入Harness，重新来。你喝着咖啡看着。
这不是科幻。这篇文章讲的就是这条路上发生了什么。
一、2023：蛮荒时代——第一次让AI“自己干活”
2023年3月，GitHub上一个叫Toran Bruce Richards的开发者发布了一个项目。它的默认prompt是让GPT-4自己设定子目标、执行、调用工具、存储记忆。这就是AutoGPT。同月，Yohei Nakajima发布了BabyAGI，用LangChain加Pinecone向量数据库做长期记忆——让Agent能记住之前执行过的任务。
当时的社区反应是爆发式的。AgentGPT很快出现，让不会写代码的人也能在浏览器里部署Agent。Andrej Karpathy也在讨论自主Agent的潜力——把多个LLM调用串成链条，让模型能“思考”多步。
但跑起来和跑得通之间，隔着一片雷区。
综合那年社区大量实践报告和学术文献，失败模式可以归纳为七类——你大概率撞上过其中几种：
| 失败模式 | 编程场景实例 | 后果 |
|---|---|---|
| 任务漂移 | Agent在“改登录按钮颜色”和“重构整个路由系统”之间反复横跳 | 什么都没做完 |
| 错误累积 | Step 1写错一个变量名，Step 2-10基于这个错误继续写 | 代码全废 |
| 幻觉级联 | Agent引用了一个不存在的API，然后写了一大段调用它的代码 | 全是死代码 |
| 窗口耗尽 | 20轮对话后上下文爆了，Agent“忘记”了最初的任务 | 从头再来 |
| 成本爆炸 | 一次任务烧掉几十刀API费用 | 成功率<10% |
| 无限递归 | Agent修bug引入新bug，循环修复永无止境 | 进程卡死 |
| 安全失控 | Agent未经确认删了文件、改了全局配置 | 系统损伤 |
Ars Technica在2023年4月的报道中泼了一盆精准的冷水：AutoGPT的“有限实用性可能是大语言模型当前局限性的最有力证据”。翻译一下就是：想法对了，时机错了。
但回头看，这七个失败模式像是一张需求清单。每一个后来都对应了一个Harness组件：任务漂移→编排约束，错误累积→验证门禁，幻觉级联→工具输出校验，窗口耗尽→上下文压缩，成本爆炸→预算控制，无限递归→循环检测，安全失控→权限系统。
回到那个写登录页面的场景。2023年的AutoGPT可能在第3步就开始修改node_modules，而你完全不知道。不是它不够聪明——是它没有边界。
二、2024：重建之年——框架成熟与“包装器”价值
2024年发生了两件事，改变了Agent的轨迹。
第一件：模型终于能可靠执行多步指令了。AI实验室大量算力从pre-training转向post-training——RLHF、Constitutional AI等方法让模型在“理解并完成一个多步骤任务”这件事上有了质的提升。Eric Simons（StackBlitz CEO）在回顾Bolt.new的发展时也印证了这一点——2024年初模型能力还不足以支撑产品，年中新一代模型发布后才有了质变。
第二件：Agent框架集中井喷。LangGraph、CrewAI、AutoGen、DSPy……底层逻辑惊人一致：ReAct循环变体加工具调用加状态管理。Claude Code、Cursor、Devin这些编程Agent也在这一年崛起——Agent第一次脱离玩具场景，进入真实开发流程。
但最具启发性的不是框架本身，而是Can Boluk的hashline编辑格式实验（2024年，oh-my-pi项目）。同一个模型，同一个任务集，只改变一个变量——文件编辑界面的调用格式。准确率从6.7%跳到了68.3%。不是模型变强了，是“包装器”变聪明了。这是Harness价值的第一次量化证明——虽然Harness Engineering这个名字还要再等两年才会出现。
从这一年的实践中，几条设计原则开始浮现：
| 原则 | 含义 | 反例 |
|---|---|---|
| 工具需要统一接口 | 每接入一个新工具不该写一套胶水代码 | 2023年每个工具单独封装 |
| 执行需要边界 | 沙盒不是可选项，是必选项 | AutoGPT裸奔操作文件系统 |
| 人需要介入点 | “完全自主”失败，证明要的不是无人，是人在正确时机介入 | 2023年全自动或全手动二选一 |
评估基础设施也在同步爆发。LangSmith、Braintrust、Ragas在2024-2025年集中间出现。“怎么知道Agent做对了”不再是一句模糊的追问——它成了一个独立的工程问题。
回到那个登录页面。2024年它能跑通了。但每次出问题，你得手工定位、手工修复。没有自动验证，没有自动回退。Agent像一个没有刹车的赛车——快起来很爽，出事了停不住。
三、2025：标准化之年——基础设施就位
如果说2023是发现“能跑”，2024是让它“跑稳”，那2025就是让Harness的各个零件有了标准接口。
MCP（Model Context Protocol）协议是这一年最重要的标准化事件。2024年11月Anthropic发布，2025年成熟。它的灵感来自LSP——那个让任何编辑器都能接入任何编程语言智能提示的协议。MCP做了同样的事，但对象是工具：M个应用乘以N个工具的连接复杂度，从M×N变成了M+N。工具接入第一次有了标准。
2025年3月，MCP升级引入OAuth 2.1认证和Streamable HTTP传输。Agent调用第三方工具，不再需要手工配token、写中间层。
Anthropic Agent SDK也在这一年发布，被明确定义为“a general-purpose agent harness”——Harness这个词第一次作为产品概念出现。
Claude Code的关键Harness设计，到2025年已经形成了清晰的架构：
| 组件 | 设计 | 解决什么问题 |
|---|---|---|
| 权限分级 | Tier 1安全工具自动批准 / Tier 2项目内文件编辑快速通道 / Tier 3独立分类器评估危险操作 | 推理和权限是两套独立系统——模型不能“说服”安全检查 |
| 自动压缩 | 上下文利用率98%时触发 | 保护Agent不“失忆” |
| 子Agent隔离 | worktree isolation，每个子任务独立上下文 | 避免相互污染 |
| CLAUDE.md | 根目录始终在上下文，子目录按需载入；每轮重新读取，不受压缩影响 | 项目规范持续生效 |
| MCP工具发现 | 按需加载schema，不预先加载所有工具 | 避免上下文膨胀 |
这里有三个设计哲学回头会反复出现：
推理与权限分离：模型决定做什么，独立系统决定允不允许。Tier 3分类器是独立的Sonnet 4.6模型，它看不到主模型的推理文本——防止prompt injection绕过检查。
上下文需要显式管理：该压缩的压缩，该隔离的隔离。没有“让模型自己看着办”这一说。推荐活跃MCP服务器约5-6个：不是越多越好。精准的工具集比全面的工具集更可靠。
Prompt Caching（Anthropic 2024年8月推出，2025年广泛使用）也在这一年改变了游戏规则。上下文从“一次性消耗品”变成了“可复用资产”。同一个系统提示、同一份项目规范，不必每轮都重新传一遍。
“Agent = Model + Harness”这个公式开始在社区浮现——虽然当时还没有人系统论证过后一项到底有多重要。
回到登录页面。2025年，框架帮你管理了上下文、标准化了工具接入。但Agent还是会犯错。区别是——现在错得更隐蔽了：代码能跑但不合项目规范，测试覆盖了happy path但边缘情况全漏了。你开始意识到：让Agent写代码不难，难的是让它写对的代码。
四、2026：正名之年——从个体经验到工程学科
4.1 命名与验证（1-3月）
2026年2月5日。Mitchell Hashimoto——HashiCorp创始人，Terraform、Vagrant、Ghostty的作者——在个人博客上写了一篇文章。他给这套实践起了一个名字：Harness Engineering。
他的操作型定义只有一句话：不是提醒它下次注意，不是写个更长的prompt，是改变系统本身。
他的个人实践清单像一份Harness工程的手工指南：始终有一个Agent在后台排队处理慢任务、分离规划与执行、每次犯错改进Harness而不是只修bug、关掉Agent通知（“我选择什么时候打断Agent，它不能打断我”）、扩大测试覆盖（因为AI是“目标导向的”，会破坏当前任务范围之外的东西）。
一周后，OpenAI甩出了一份震撼弹。
2月11日，OpenAI发表了《Harness Engineering: Leveraging Codex in an Agent-First World》。Ryan Lopopolo（OpenAI Member of Technical Staff）详细记录了他们的内部实验：
| 指标 | 数据 |
|---|---|
| 团队 | 3人起步→7人 |
| 时间跨度 | 5个月 |
| 生成代码量 | ~100万行 |
| PR数量 | ~1500个 |
| 人均日处理PR | 3.5个 |
| 开发效率 | 约10倍于手动开发 |
| 硬规则 | 完全禁止手写代码 |
这组数字背后的核心不是Codex有多强，是团队把Harness工程化了。三个核心设计：
知识即系统记录。AGENTS.md只有约100行，作用是目录。真实知识在结构化的docs/目录中，Agent按需检索。不是把整个wiki塞进上下文。
架构约束可执行。分层架构不是写在文档里的建议——由自定义linter和结构测试强制。违反即阻止提交。
持续“垃圾回收”。后台Agent定期扫描文档漂移和代码腐化，自动修复。项目不会随着Agent数量增加而熵增。
Birgitta Bockeler在Martin Fowler的博客上发表专题分析时，提了两个开放问题：完全Agent生成的系统能否多年保持架构一致性？人类判断力在哪里杠杆最高？这两个问题到现在没有答案。
又过了一周。LangChain发表了基于Terminal Bench 2.0的实验结果。这是Harness价值的第一个严格因果证据。
89个跨领域编码任务——ML、调试、生物信息学、密码分析、系统编程——Docker化二值通过/失败评分。每任务5次独立试验。同一模型（gpt-5.2-codex）、同一任务集、只替换Agent框架层：
| 指标 | 原始 | Harness优化后 |
|---|---|---|
| 通过率 | 52.8% | 66.5%（+13.7 pp） |
| 排名 | 第30 | 第5 |
三个改动方向：系统提示（强调自验证循环）、工具增强（更好帮助Agent理解环境）、中间件（检测“doom loop”——Agent无限循环重复错误操作——等有害模式）。简单，但有效。
这不只是“更好的prompt工程”。这是Harness的价值被严格量化——同一模型，不同Harness，差距13.7个百分点。
4.2 架构化与工业化（3月至今）
2026年3月24日，Anthropic发表了《Harness Design for Long-Running Application Development》，提出了一个关键架构：Planner → Generator → Evaluator。
灵感来自GAN（生成对抗网络）。核心思想：把规划、执行、评估拆成三个独立Agent。
为什么必须拆？因为让写代码的Agent评估自己的代码，等于让学生批自己的卷子。
关键设计：
| 设计元素 | 具体做法 | 为什么 |
|---|---|---|
| Evaluator无写权限 | 独立Agent，无Write/Edit | 评估和修改不能是同一个人 |
| 新鲜上下文 | Evaluator从干净上下文窗口启动 | 不被Generator的推理过程影响 |
| Sprint合同 | Generator和Evaluator写代码前协商“done”标准 | 对齐预期 |
| Default-FAIL | 每条标准初始为false，Agent必须打开证据才能声称成功 | 防止自欺 |
| 评分rubric | Design Quality / Originality / Craft / Functionality | 把主观判断变成可打分维度 |
| Agent自维护交接 | 自己写进度笔记并git commit | 上下文重置不丢进度 |
结果对比：
| 配置 | 耗时 | 成本 | 产出 |
|---|---|---|---|
| 裸Agent（无Harness） | 20分钟 | $9 | 坏掉的游戏逻辑 |
| Planner→Generator→Evaluator | 6小时 | $200 | 完整可玩游戏，16个feature，含AI功能 |
$200 vs $9，看起来是22倍成本。但产出是“可玩的产品”vs“不能用的代码”。账不是这么算的。
关键洞察：Harness组件都是可被模型升级淘汰的假设。根据Anthropic工程团队的观察，Opus 4.5大幅缓解了Sonnet 4.5的“上下文焦虑”问题——之前为Sonnet设计的上下文重置机制就没必要了。Harness需要持续进化，不是在某个版本冻结。
学术界从2026年开始系统化Harness：
ETCLOVG七层模型出现了——这个名字是七个层次的首字母缩写——把Harness的各个维度结构化为一个完整框架：
| 层级 | 负责 |
|---|---|
| Execution | 执行环境与沙箱 |
| Tools | 工具接口与协议 |
| Context | 上下文管理 |
| Lifecycle | 生命周期编排 |
| Observability | 可观测性 |
| Verification | 验证 |
| Governance | 治理（权限、身份、策略、安全、审计、人工监督） |
Meta-Harness（Stanford/MIT，2026年3月）更进一步——自动优化Harness本身。用Haiku 4.5做Agent→37.6%（所有Haiku Agent中#1）。用Opus 4.6→76.4%（#2 overall）。
AHE（Agentic Harness Engineering，2026年4月）把这个方向推到极致：自动化闭环Harness进化达到77.0% pass@1，超越了人类设计的Harness。
行业落地也在加速：
| 案例 | 规模/状态 |
|---|---|
| Stripe Minions | 周产1000+合并PR，任务创建到审查全自动 |
| DeepSeek | 2026年5月组建Harness团队，对标Claude Code |
| 小米 | 2026年6月MiMo Code发布，内置专属Harness |
| 创业公司明日新程 | 获李开复、陆奇等投资 |
| Stanford/Tsinghua研究 | 同一模型不同Harness，性能差异可达6倍 |
开源vs闭源两条路线也在分野：开源生态（LangChain、CrewAI）注重灵活组合，像乐高；闭源产品（Claude Code、Cursor）注重集成体验，像整机。两条路线对Harness的理解有结构性差异——开源更强调可替换性，闭源更强调端到端优化。哪个更好？取决于你的团队有没有能力做集成。
回到登录页面——这次是真的回来了。2026年写它：Agent自动拉项目规范→子Agent并行开发前后端→沙盒测试→独立评估Agent审核→通过了才提交。出错了自动回退，从错误中提取规则加入Harness。
你不再盯着代码。你盯着系统。
五、结语：三部曲的终点
四年，一条线。
2023年，Agent搞砸的七种方式——任务漂移、错误累积、幻觉级联、窗口耗尽、成本爆炸、无限递归、安全失控——每一个都变成了Harness的一个组件：编排约束、验证门禁、工具校验、上下文压缩、预算控制、循环检测、权限系统。Harness不是凭空设计出来的，它是从“搞砸”中长出来的工程实践。
这是“AI工程三部曲”的第三篇。
| 篇章 | 回答的核心问题 | 工程层面 |
|---|---|---|
| 提示词工程 | 怎么说 | 优化单次交互质量 |
| 上下文工程 | 让AI看什么 | 管理信息输入 |
| Harness工程 | 怎么防止做错 | 构建执行、验证、约束、恢复的外层系统 |
三者合在一起，才是完整的AI交互工程。不是你prompt写得多好、上下文管得多精——如果执行层没有约束和验证，前面的努力随时可能被一次幻觉级联清零。
核心insight：模型正在变成commodity（通用商品）。同一模型，不同Harness，性能差6倍。拼的不是谁的模型更强——拼的是谁的环境更扎实、规范更清晰、验证链路更完整。
你可能会想：“模型再强一点，Harness不就不需要了吗？”
GPT-5的实践证明恰恰相反。更强的模型不是不犯错，是犯更隐蔽的错误。代码能跑，但逻辑有洞。测试通过，但边缘情况全漏。Harness的必要性不降反升。不是模型不够好才需要Harness，是模型越强，越需要Harness来管住它。
Mitchell Hashimoto那句话应该刻在每个搞AI工程的团队的墙上：不是提醒它下次注意。不是写个更长的prompt。是改变系统本身。
这不只是Harness工程的定义。这是人和AI合作这件事，正在发生的根本转变——从依赖模型能力，到依赖系统工程能力。从“这个模型真聪明”到“这个系统真可靠”。
四年。从AutoGPT搞砸一个登录页面，到Harness工程从每一次搞砸中长成一套完整的工程学科。
这条路还在走。
本文基于公开论文、工程博客和开发者社区记录整理。关键数据来源：
Mitchell Hashimoto 个人博客《My AI Adoption Journey》（2026.2.5）
OpenAI《Harness Engineering: Leveraging Codex in an Agent-First World》（2026.2.11, openai.com/index/harness-engineering/）
LangChain《Improving Deep Agents with Harness Engineering》（2026.2, langchain.com/blog/improving-deep-agents-with-harness-engineering）
Anthropic《Harness Design for Long-Running Application Development》（2026.3.24, anthropic.com/engineering/harness-design-long-running-apps）
Anthropic MCP 规范文档（2024.11）
Ars Technica 对 AutoGPT 的报道（2023.4.18）
Birgitta Bockeler, Martin Fowler 博客《Harness Engineering - first thoughts》（2026.2.17, martinfowler.com）
Meta-Harness: End-to-End Optimization of Model-Agnostic Harnesses（arXiv, 2026.3）
AHE: Agentic Harness Engineering（arXiv, 2026.4）
ETCLOVG 综述论文（CMU/耶鲁/JHU/亚马逊联合发布）
Stanford/Tsinghua SWE-bench Mobile 研究（Tian et al., 2026）
Can Boluk, hashline 编辑格式实验, oh-my-pi 项目（2024）