> 来源：UsefulAI（实用 AI / Useful AI）— https://usefulai.cloud/insights/what-is-agent-harness/ > 作者：CarryChang · 最近更新：2026-11-01 · 语言：zh-CN [实用 AI 指南](https://usefulai.cloud/) › [深度阅读](https://usefulai.cloud/insights/) Agent Harness 概念拆解 Harness Engineering # Harness 到底是什么？——Agent 拆掉模型之后，剩下的全部 2026 年下半年，几乎每一篇讲 AI Agent 的文章都绕不开「Harness」这个词，连面向大众的媒体开始专门解释「Harness 到底是什么」。它是圈内黑话突然破圈了吗？不完全是——更准确的说法是：**模型竞争的边际收益开始递减，整个行业的战场移到了模型之外那一层**。这篇是本站 Harness 专题的第一篇，先把概念和地图讲透；后面两篇分别看行业格局（[当所有人开始卷 Harness](https://usefulai.cloud/insights/harness-engineering-moat/)）和评测方法（[Google 开始教大家测 Harness](https://usefulai.cloud/insights/harness-evals-trajectory/)），第四篇是给「Harness 自我改进」泼的冷水（[在这里](https://usefulai.cloud/insights/harness-self-improvement-skepticism/)）。 **我的立场：**Harness 不是新发明，它是一次迟到的命名。执行循环、工具接口、权限边界、检查点恢复、可观测性——这些全是操作系统和分布式计算研究了几十年的老问题，换了 Agent 的语境重新出现。真正新增的只有一件事：这套骨架的「程序员」从人变成了一个不稳定的自然语言智能体。所以我的判断是——**Harness 的价值不在「新」，在于它终于逼着 AI 行业把软件工程里最枯燥的那套纪律捡回来**。 ### 先把定义钉死：Agent = Model + Harness 最干脆的定义：**Harness 是 Agent 减去模型之后剩下的全部**——状态、工具、执行环境、约束与反馈。Harness 本义是「马具」，套在马身上、把马的力量传导到车上的那套装置。放在 AI 语境里，模型是那匹马：能力强，但放任它自由发挥，就会发散、会编造、会在长任务里迷路。一个更工程化的比方：模型是一个聪明但失忆的外包工程师——每次开工都不记得上次干了什么，能同时接十个活但每个都可能跑偏。Harness 就是给他配的工位、流程、检查清单和门禁卡。 在这个公式里，**模型只是可替换的零件**。同一匹马路跑不跑得过别的马车，要看车；同一个模型在不同产品里用起来像换了个模型，差的就是这层骨架。 ### 工程范式的第三跳：从「怎么问」到「让它看见什么」到「整套系统怎么可靠干活」 把这三年串起来看，是一条清晰的问题升级链： - **Prompt Engineering（2023）**：解决「这一次怎么问」。角色、背景、任务、格式——本站在 [入门篇](https://usefulai.cloud/primer/) 里讲过，它有效，但它作用的是单次交互。 - **Context Engineering（2025）**：解决「这一次该让它看见什么」。检索什么、塞什么、压缩什么、什么时候清空。 - **Harness Engineering（2026）**：解决「**整套系统怎样持续、可靠、无人值守地干活**」。提示词和上下文降级成它十几个模块中的两个。 这个术语在 2026 年初被正式确立：OpenAI 工程师 Ryan Lopopolo 在《Harness engineering: leveraging Codex in an agent-first world》里披露了一个让全行业坐不住的实验——不到 10 人的团队，5 个月让 Codex 写出了超过 100 万行代码，全程没有手敲一行。他们改的最多的不是模型，也不是提示词，而是模型外围那套让它可以连续工作的系统。那个著名的「AGENTS.md 实验」也出自这里：在仓库根目录加一个不到 100 行的文件，只写三块内容——项目说明、禁止操作、完成定义——Codex 就从「能写代码」变成「稳定交付」。 > 如果你不是模型本身，那你就是 Harness。 — — 2026 年行业讨论中对 Agent = Model + Harness 最流行的通俗表述 ### Harness 具体管哪六件事——每一件都影响你的实际体验 - **执行循环**：干一步、看结果、再决定下一步。这是 Agent 能「连着干」而不是「答一句」的根源，循环里出错还是出错在模型里，是排障时第一个要拆开的问题。 - **工具层**：文件读写、命令行、网络请求、数据库、浏览器。模型碰不到你的电脑，它只能输出一段结构化文字说「我想执行这个」，**真正动手的是 Harness**——所以工具安不安全、超时多久、报错怎么回灌，都是骨架的事，不是模型的事。 - **上下文工程**：提示词怎么写、多轮对话怎么管、历史什么时候压缩、知识怎么按需放进去。本站在 [Claude Code 进团队工作流](https://usefulai.cloud/insights/claude-code-beyond-basics/) 里算过这笔 token 账。 - **权限与沙箱**：能读哪些目录、能连哪些地址、花多少钱算超支。一句话：**提示词是「劝」，沙箱是「拦」——劝不住的时候，只有拦得住才算安全**。GitSpawn 那次打穿 7 款编程 Agent 的事故（见[前沿动态](https://usefulai.cloud/frontier/)）说明「拦」这一层恰恰是最薄弱的。 - **状态与记忆**：短期窗口、长期存储、任务进度检查点。任务中途断了还能接上，靠的是这层，不是模型。 - **错误恢复与可观测**：输出格式校验、重试、超时、成本控制、运行记录。没有 Harness，模型只能做单轮问答；有了 Harness，模型才能在包含工具调用、状态记忆、失败恢复的闭环里，自主完成小时级的复杂任务。 ### 为什么是现在火：三组数据说明战场确实移了 「Harness 比模型重要」在 2025 年还是观点，到 2026 年有了实测数字： - YC 的研究团队在 ARC-AGI-3 上测试：**同一个模型，只更换 Harness，得分差距可达 35.9%，成本反而下降 34%**——骨架层的两次迭代（Harness 1 → Harness 2）带来的提升，比换一档模型大。 - LangChain 的实验：只重构 Harness、不换模型，任务成功率提升 13 个百分点。 - 最直观的注脚是 Claude Code：2026 年 4 月源码泄露后，社区数了数——约 51 万行 TypeScript、1900 个文件、40 多个内置工具、46000 行的查询引擎、三层自愈记忆架构。**「Anthropic 的编程 Agent」原来有 99% 的代码不在模型里**，这批源码直接成了全行业学习 Harness 设计的公开教科书。 评论员视角 两个警告，都是我这半年看团队落地时反复见到的错法。第一，**不要把「优化 Harness」做成了「频繁更换 Harness」**——市面上开源骨架越来越多，今天换 Deep Agents 明天换别家，这个毛病和 RAG 项目里「效果不好就换框架」是同一种病：**骨架的价值恰恰在于它是长期沉淀的资产**（你的验收集、错误写回的规则、权限边界都长在里面），换骨架等于把这些清零。本站在 [落地手册](https://usefulai.cloud/playbook/) 里把这条写成了第六条反直觉经验：Agent 效果不好，先查 Harness，不要先换模型——注意是「查」，不是「换」。 第二，**「模型会吃掉一切脚手架」的说法只对一半**。模板化的规则、写死的流程，确实会被更强的模型逐步吸收；但权限、沙箱、审计、回滚这一层永远吃不掉——因为它们约束的不是智能，是责任，这是组织和合规问题，不是模型能力问题。这和我在入门篇讲的「可验证性定律」是同一个结构：模型负责变聪明，Harness 负责让它的错误能被低成本发现。 #### 一句话定义 - Harness = Agent 减去模型之后剩下的全部 - Agent = Model + Harness，模型是可替换零件 - 范式三级跳：Prompt（2023）→ Context（2025）→ Harness（2026） - 六件事：循环 / 工具 / 上下文 / 权限沙箱 / 记忆 / 恢复与观测 #### 关键数据 - YC 实测：同模型换 Harness，ARC-AGI-3 分差 35.9%，成本降 34% - LangChain：只改 Harness 不换模型，成功率 +13pp - OpenAI：不到 10 人 5 个月，Codex 写完超 100 万行代码 - AGENTS.md 不到 100 行：项目说明 + 禁止操作 + 完成定义 - Claude Code 源码：约 51 万行、40+ 工具、46000 行查询引擎 #### 你现在能做的两件事 - 不必自己写 Harness——选一个成熟骨架用满它的默认能力 - 在你的项目根目录维护一份 AGENTS.md / CLAUDE.md：项目说明、禁止操作、完成定义 - Agent 效果不好时，先审查工具描述和上下文取舍，再考虑换模型 - 配套阅读：[行业地图篇](https://usefulai.cloud/insights/harness-engineering-moat/) 与 [评测方法篇](https://usefulai.cloud/insights/harness-evals-trajectory/) ## 常见问题 ### Harness 和提示词、上下文工程是什么关系？ 这是工程范式的三代演进：Prompt Engineering（2023）解决「这一次怎么问」，Context Engineering（2025）解决「这次该让它看见什么」，Harness Engineering（2026）解决「整套系统怎样持续可靠地干活」。前两者是后者的子集——提示词和上下文只是 Harness 十几个模块中的两个，执行循环、工具调度、沙箱权限、记忆、错误恢复这些不在提示词里、却决定 Agent 能不能跑长任务的部分，才是 Harness 的主体。 ### 同一个模型，换一套 Harness 效果能差多少？ 已有公开实测给出量级：YC 的研究团队在 ARC-AGI-3 上测试，同一个模型、只更换 Harness，得分差距可达 35.9%，成本反而下降 34%；LangChain 的实验里，仅重构 Harness 不换模型，任务成功率提升 13 个百分点。换句话说，把「效果不好」归因于「模型不够强」之前，应该先审查系统提示词、工具描述、上下文取舍和验证回路这些骨架层面的缺陷。 ### 普通人需要自己写 Harness 吗？ 不需要，也不建议。Claude Code、Codex、DeepSeek Harness 这类成熟产品已经把骨架层做到生产级，自己重写一遍是成本极高的重复劳动。个人真正值得做的两件事：一是选一个成熟 Harness 并用满它的默认能力，二是像给新员工写入职手册一样，在项目根目录维护一份 AGENTS.md / CLAUDE.md——写清项目说明、禁止操作、完成定义三块，不到一百行就能显著改变 Agent 的交付稳定性。 ## 继续阅读 [当所有人开始卷 Harness：模型决定下限，骨架决定上限 → OpenAI 给学科命名、DeepSeek 组队并全栈开源、Claude Code 源码成了社区教科书——2026 年 Agent 战场的重心从模型移到了 Harness。但这份热闹里有一个反向趋势值得警惕。](https://usefulai.cloud/insights/harness-engineering-moat/) [Google 开始教大家测 Harness：只看最终成功率，已经不够了 → 只改一版系统提示词，成功率从 86% 掉到 79%，但没人说得清是哪个组件坏了。把 Harness 的 12 个组件拆开、按执行轨迹归因，是 Agent 进生产的最后一道关卡。](https://usefulai.cloud/insights/harness-evals-trajectory/) [深度阅读 → 18 篇 AI 长文的完整中文解读：Claude Code、Skill、Agent、大模型原理、LLM 资源地图。](https://usefulai.cloud/insights/)