从“提示词”到“缰绳”：Harness Engineering的起源、内核与范式革命
——深度剖析Harness Engineering的诞生背景、核心定义与从“调教模型”到“搭建系统”的工程范式跃迁
一句话概括：Harness Engineering不是提示词工程的升级版，而是一套以“Agent犯错→工程化防错”为方法论闭环、以“Agent = Model + Harness”为架构公式、以“上下文管理+工具接口+执行环境+编排+可观测+验证+治理”七层体系为技术骨架的全新AI工程化范式——让AI从“单次对话的智能”变成“长期可靠的生产力”，并在2026年取代提示词工程成为硅谷最主流的AI工程实践。
一、起源：一篇博客引发的范式革命
1.1 命名时刻：Mitchell Hashimoto的六步经验
2026年2月5日，HashiCorp联合创始人、Terraform和Ghostty的创造者Mitchell Hashimoto发表了一篇博客，标题是《My AI Adoption Journey》。在这篇文章的第五步，他写下一个新术语：Harness Engineering（驾驭工程）。
Hashimoto总结了自己使用AI工具的六点经验，核心洞察朴素而犀利：Agent在实际任务中总会反复犯同一类错误。他的建议是：
“Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”
——每当你发现Agent犯了一个错误，你就花时间设计一个方案，让它永远不会再犯同样的错误。
这个定义的关键在于：它不是“调一下prompt试试”，而是“搭一个系统让它再也犯不了”。这是从“单次交互优化”到“系统级可靠性工程”的范式切换。
Hashimoto本人将Harness Engineering描述为“人类掌舵，智能体执行”——人类负责设计约束和反馈回路，智能体在轨道内自主运行。
1.2 从概念到共识：不到一个月的“闪电收敛”
从Hashimoto的博客到全行业的共识，只用了不到一个月：
| 时间 | 事件 | 意义 |
|---|---|---|
| 2月5日 | Mitchell Hashimoto发表博客 | Harness Engineering正式命名 |
| 2月11日 | OpenAI发表《Harness engineering: leveraging Codex in an agent-first world》 | 提出Agent = Model + Harness公式 |
| 2-3月 | Martin Fowler在其博客上发文 | 理论体系彻底打通 |
| 3月 | LangChain发表《The Anatomy of an Agent Harness》 | 实证数据引爆行业 |
“这可能是AI领域‘从概念到共识’最快的一次收敛。”
1.3 引爆点：7个人、5个月、100万行代码
真正让Harness Engineering从小众术语变成行业共识的，是OpenAI内部一个真实案例：
一个最初只有3人、后来扩展到7人的小团队，从空Git仓库起步，完全禁止人工手写一行代码，用Codex Agent在大约5个月内构建出一个供数百内部用户使用的Beta产品——生成近100万行代码、约1500个PR，人均日处理3.5个PR，整体效率提升约10倍。
这件事像一记重锤，彻底点燃了行业讨论：AI工程正在从“调模型”走向“搭系统”。
二、核心定义：Harness Engineering到底是什么？
2.1 最简洁的公式：Agent = Model + Harness
OpenAI在2月11日的博客中给出了一个经典公式：
Agent = Model + Harness
LangChain把这个公式进一步展开：
Harness就是模型之外的一切：系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、钩子中间件、反馈回路、约束机制。
一个更形象的类比：如果LLM是CPU，上下文窗口是RAM，那么Harness就是操作系统。CPU再强，没有操作系统也跑不了任何应用。
2.2 另一个精妙的比喻
在AI社区中，另一个广为流传的比喻是：
“如果模型是一匹马力很强的马，Harness就是那套缰绳和车厢——负责把马（模型）和读文件、执行命令、调用工具这些‘让马真正拉车干活’的组件绑在一起。”
模型负责“想”，Harness负责“干”：
“模型提供智能，Harness提供让这种智能真正能干活的一切基础设施。”
2.3 与其他“Engineering”的区别
Harness Engineering经常被拿来与Prompt Engineering和Context Engineering对比：
| 维度 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 核心问题 | “这句话怎么说？” | “给它看什么？” | “怎么让它永远不犯这个错？” |
| 作用范围 | 单次交互 | 单次交互的上下文 | 整个系统生命周期 |
| 实现方式 | 调措辞、加示例 | RAG、动态上下文构建 | 搭约束、建反馈、自动化 |
| 失败模式 | 单次输出质量差 | 检索不准、上下文缺失 | 长期质量退化 |
| 可维护性 | 手动、per-task | 半自动 | 自动、持续 |
“Prompt解决‘说什么’，Context解决‘看什么’，Harness解决‘怎么干’。”
2026年，一篇由卡内基梅隆大学、耶鲁大学、亚马逊等机构联合发表的Harness工程综述，将2022到2026年的工程重心变化概括为三个阶段：
- 2022-2024年：提示工程——重点是优化单次模型调用的输入
- 2025年：上下文工程——重点转向每一步该向模型提供什么上下文
- 2026年：Harness工程——随着Agent处理长链条、多步任务，可靠性越来越取决于状态管理、工具协调、反馈注入、约束施加和进展验证
三、Harness的技术骨架：七层体系
卡内基梅隆大学、耶鲁大学、亚马逊等机构联合发表的Harness工程综述，提出了ETCLOVG七层分类体系：
┌─────────────────────────────────────────────────────┐ │ 治理层（Governance） │ │ 权限 · 身份 · 策略 · 审计 · 人工监督 │ ├─────────────────────────────────────────────────────┤ │ 验证层（Verification） │ │ 评估 · 失败归因 · 回归反馈 │ ├─────────────────────────────────────────────────────┤ │ 可观测性层（Observability） │ │ 轨迹 · 成本 · 失败 · 可靠性信号 │ ├─────────────────────────────────────────────────────┤ │ 生命周期与编排层（Lifecycle & Orchestration） │ │ 单Agent循环 · 多Agent协作 · 工作流控制 │ ├─────────────────────────────────────────────────────┤ │ 上下文管理层（Context Management） │ │ 短期 · 会话级 · 持久化 · 压缩 · 检索 │ ├─────────────────────────────────────────────────────┤ │ 工具接口与协议层（Tool Interface & Protocol） │ │ 能力描述 · 发现机制 · 调用协议 │ ├─────────────────────────────────────────────────────┤ │ 执行环境与沙箱层（Execution & Sandbox） │ │ 代码运行 · 约束 · 隔离 │ └─────────────────────────────────────────────────────┘前四层构成Harness的结构核心，后三层是围绕核心的控制平面。
3.1 OpenAI的三层实践视角
OpenAI将Harness拆解为三个核心类别：
第一层：上下文工程（Context Engineering）——不是给Agent一份文档，而是持续增强的知识库，加上动态上下文（可观测性数据、浏览器导航状态）。OpenAI团队发现，传统的“一个巨大的AGENTS.md文件”方法注定失败：上下文是稀缺资源，过多的指导反而无效。
第二层：架构约束（Architectural Constraints）——通过自定义格式和结构测试来强制执行规则，而不是让Agent随意发挥。OpenAI要求Codex“在边界处解析数据形状”，但不规定具体实现方式。“增加信任和可靠性需要约束解决方案空间”——这意味着放弃一些“生成任何东西”的灵活性。
第三层：垃圾回收（Garbage Collection）——定期运行的Agent，扫描不再反映真实代码行为的过时文档，发起修复PR。这对应了软件开发中的“技术债务”概念——与其让债务累积，不如持续小额偿还。
四、实证数据：Harness的力量
4.1 LangChain的“模型不变、Harness变”实验
LangChain做了一个极具说服力的实验：
同一个编码模型，模型本身一个参数都没改，只优化了Agent运行的外部环境（文档结构、验证回路、追踪系统），在Terminal Bench 2.0基准测试上，排名从全球第30位跃升至第5位，得分从52.8%飙升至66.5%。
LangChain的结论是：“Same model, very different agent.”——同一个模型，完全不同的Agent。
4.2 OpenAI的百万行代码案例
7人团队、5个月、100万行代码——这个案例证明了Harness Engineering的规模化交付能力。关键在于他们构建的不是一个“更聪明的模型”，而是一个能让模型持续可靠工作的系统。
4.3 Anthropic的“长时Agent”方案
Anthropic工程团队面临的挑战是：Agent必须在多个上下文窗口之间持续工作，而每个新session开始时对之前发生的事毫无记忆。
他们的解决方案是双Agent架构：
- 初始化Agent（Initializer）：第一次运行时设置环境，为所有功能奠定基础
- 编码Agent（Coding Agent）：每个session做增量进展，并在session结束时留下清晰的状态——代码整洁、文档完善、无重大bug，就像“适合合并到主分支的状态”
这种设计模仿了人类优秀工程师的日常习惯：“每轮开工前先做一套固定的‘上岗动作’”。
五、框架落地：Harness工程化的三足鼎立
2026年8月，三个重量级Harness实现几乎同时开源，标志着Harness Engineering从理论走向了产业基础设施。
5.1 AgentScope Java Harness
AgentScope Java 2.0将Harness内置为内核能力，以“叠加，而非改写”为设计哲学——不修改ReActAgent的推理循环，而是通过Hook和Toolkit两个扩展通道注入工程化能力。
其核心能力包括：Workspace驱动的持久化人格、三层记忆管理（上下文+长期记忆+审计流水账）、对话自动压缩、安全沙箱执行和多租户隔离。
5.2 DeepSeek Harness
DeepSeek Harness采用**“一切皆插件”** 的极致可组装性设计，基于Cordis元框架构建。模型适配器、工具注册表、会话管理、沙箱、存储、甚至Agent主循环本身都是可替换的插件。
其口号“Model + Harness = Agent”与OpenAI的公式完全一致，两者成为Harness Engineering在开源社区的两大旗帜。
5.3 Codex Harness（OpenAI）
OpenAI选择“向右”——将基于Rust构建的Codex Harness核心仓库以Apache-2.0协议彻底开源。Codex Harness采用Rust核心（codex-rs）+ TypeScript SDK双栈架构，提供三层集成接口：codex exec（非交互式任务执行）、@openai/codex-sdk（程序化Agent编排）、codex app-server（持久会话驱动）。
六、对开发者的启示
6.1 思维范式的转变
Harness Engineering要求开发者完成三个思维转变：
| 旧思维 | 新思维 |
|---|---|
| “这个prompt怎么写模型才懂？” | “这个系统怎么搭模型才不出错？” |
| “换一个更强的模型” | “优化模型周围的Harness” |
| 每次遇到问题调一次prompt | “Agent的每一次失败，都是环境设计不完善的信号” |
6.2 实践建议
① 从“调prompt”转向“搭系统”
当Agent犯错时，不要只改prompt，而是问：“我能不能搭一个机制，让它永远不再犯这个错？”
② 把可复用的成功模式沉淀为Skill
团队在实践中发现的有效模式，应该沉淀为可复用的技能文件，跨会话、跨项目共享。
③ 建立反馈闭环
Harness不是一次性搭建的。它需要持续优化——每次Agent失败都是改进Harness的信号。
④ 关注可观测性
没有可观测性的Harness是盲目的。追踪Agent的每一步推理、每一次工具调用、每一个决策。
七、总结
7.1 核心设计哲学提炼
Harness Engineering的演进可以用三句话概括：
“从‘怎么说’到‘怎么让它永远不出错’”——Harness Engineering不是Prompt Engineering的升级版，而是一次工程范式的跃迁
“Agent = Model + Harness”——模型提供智能，Harness提供让智能真正能干活的一切基础设施
“模型决定上限，Harness决定下限”——同一个模型，换一套Harness，效果可以差3倍
7.2 核心亮点速览
| 亮点 | 说明 |
|---|---|
| 命名起源 | Mitchell Hashimoto于2026年2月5日首次提出 |
| 核心公式 | Agent = Model + Harness |
| 核心定义 | “Agent犯错→工程化防错” |
| 七层体系 | ETCLOVG：执行环境、工具接口、上下文、编排、可观测、验证、治理 |
| 实证数据 | 同模型，Harness优化后排名从30到前5 |
| 标志案例 | 7人5个月100万行代码，人工编写比例0% |
7.3 对开发者的启示
Harness Engineering的故事告诉我们：AI工程的下半场，竞争不在“谁的模型更强”，而在“谁的Harness更完整”。
2026年之前，行业关注的是“模型能做什么”。2026年之后，行业关注的是“怎么让模型在真实世界中可靠地工作”。Harness Engineering正是对这一问题的系统化回答。
对于开发者，这意味着：
- 不要只盯着模型——Harness工程化带来的收益，常常大于换一个更强模型
- 把每一次Agent失败当作改进Harness的机会——而不是“换一个prompt试试”
- 关注Harness的七层能力——执行环境、工具接口、上下文管理、编排、可观测性、验证、治理——每一层都是生产环境中不可或缺的
- 拥抱开源Harness生态——AgentScope、DeepSeek Harness、Codex Harness三大实现正在降低Harness工程化的门槛
最后，正如一位开发者所说：“当AI开始真正‘干活’，我们需要的不再是更好的‘鞭子’，而是一套可靠的‘缰绳’。”Harness Engineering，正是那套缰绳。
本文数据来源：Mitchell Hashimoto个人博客、OpenAI官方博客、Anthropic工程博客、LangChain官方文档、卡内基梅隆大学/耶鲁大学/亚马逊联合Harness工程综述、百度百科“驾驭工程”词条及各技术社区。所有日期、版本号及性能数据均基于公开可验证的官方资料。
如您所在的企业正面临AI Agent生产化部署、智能体平台建设或AI工程化转型的相关需求，欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。
