Harness Engineering：让 AI Agent 真正跑稳的那套系统
导读： 为什么同样的模型，别人的 Agent 成功率 90%，你的只有 70%？答案往往不在模型本身，而在模型外面那套"驾驭系统"。这个系统有了统一的名字：Harness Engineering。它在 2026 年初突然火遍整个 AI 工程圈，不是因为有人在空谈理论，而是多家顶级公司同时用事实证明了它的价值。
这个词是怎么来的
2026 年 2 月，Mitchell Hashimoto（HashiCorp 联合创始人、Terraform 作者）发布了一篇博客，描述了他在使用 AI Agent 过程中养成的一个习惯：每次 Agent 犯错，他都会把解决方案永久性地固化进 Agent 的运行环境里，让它永远不会再犯同样的错误。他把这个做法称为"engineering the harness"（工程化地设计约束装置）。
这篇文章在工程师圈子里引发了强烈共鸣，因为它精准命名了每个在做 Agent 的人都碰到过、却没有词来描述的问题。几周内，OpenAI 和 Anthropic 相继发表工程文章展开这个概念。Harness Engineering 作为一个正式术语，就此诞生。
LangChain 随后给出了一个简洁的定义：
Agent = Model + Harness
Harness = Agent − Model
翻译成大白话：在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都叫 Harness。
AI 工程的三次演进
过去两三年，AI 工程的重心经历了三次明显的迁移：
| 阶段 | 核心问题 | 解决方向 | 时间节点 |
|---|---|---|---|
| Prompt Engineering | 模型听懂了吗？ | 指令的工程化 | 2022—2023 |
| Context Engineering | 模型拿到正确信息了吗？ | 输入环境的工程化 | 2023—2024 |
| Harness Engineering | 模型在真实执行中能持续做对吗？ | 整个运行系统的工程化 | 2024—至今 |
这三者不是替代关系，而是包含关系——每一层都把前一层装在里面，边界一圈比一圈大。
第一代：Prompt Engineering（把任务说清楚）
大模型刚火起来时，工程师发现同一个模型、换一种说法，效果天差地别。
比如让模型写一段 Python 函数的错误处理：
"加一下错误处理"
vs.
"你是一位资深 Python 工程师，请为以下函数添加完整的异常捕获：
区分 ValueError、NetworkError 和未知异常三种情况，
每种情况分别记录日志并返回对应的错误码。"
后者的输出质量远好于前者。于是人们开始系统地研究提示词：角色设定、思维链（CoT）、少样本示例、输出格式约束……
提示词工程的本质，是在模型的概率空间里"塑造地形"——你给它什么样的开头，它就更容易沿着那个方向走。
但它遇到了天花板。 提示词解决的是"表达"问题，不是"信息"和"稳定执行"问题。你让模型按公司内部的代码规范写代码——哪怕提示词写得再精确，如果规范文档有 200 页，模型根本看不到，说清楚也没用。
第二代：Context Engineering（把信息给对）
当 Agent 开始流行，模型不再只是回答问题，而是要进入真实环境做事：调工具、读文件、写代码、跨多个步骤传递中间状态。
这时候问题变了。不是简单地"帮我总结这篇文章"，而是：
读取我们的 GitHub 仓库最近 30 个 PR，识别其中涉及数据库 schema 变更的，对照 migration 文件检查是否有遗漏的回滚逻辑，生成一份风险报告。
这个任务需要：PR 列表、diff 内容、migration 文件、团队的 schema 规范、历史事故记录……任何一个信息缺失，结果就会跑偏。
Context Engineering 的内核是：系统必须在合适的时机，把正确的信息送到模型面前。
这里的 Context 不只是几段背景资料，而是影响模型当前决策的一切信息的总和：用户输入、历史对话、检索结果、工具返回值、任务中间状态、系统规则、安全约束……Prompt 只是 Context 的一个很小的部分。
渐进式披露（Progressive Disclosure） 是这一阶段最重要的工程思路：不是把所有信息一次性全塞给模型，而是按需投喂、分层加载。上下文窗口是稀缺资源，信息多不等于好——注意力会涣散，关键约束会被淹没。
第三代：Harness Engineering（让模型跑得稳）
但信息给对了，模型依然可能稳定地做错事。
最典型的场景：一个编码 Agent，每一步看起来都在推进，工具调用也成功了，但三十步之后你发现它已经偏离了最初的目标——而系统没有任何机制发现这一点。
这时候大家意识到：提示词和上下文，主要解决的都是输入侧的问题。真正难的是——当模型开始连续行动，谁来监督它、约束它、在它跑偏时把它拉回来？
市场数据很直接：当前 88% 的企业 AI Agent 项目无法达到生产级别。深入分析这些失败案例，65% 的根因不是模型能力不足，而是 Harness 层面的缺陷——上下文漂移（Context Drift）、状态退化（State Degradation）、工具调用混乱。
这就是 Harness Engineering 要解决的问题。
用一个比喻彻底理解三者的区别
想象你在培训一个新入职的数据分析师，让他独立完成一份季度财务分析报告：
Prompt Engineering = 给他讲清楚任务要求
“分析 Q3 的收入数据，找出环比下降超过 10% 的品类，按影响程度排序，结论写在最前面。”
Context Engineering = 给他准备齐全所有资料
给他数据库权限、上季度报告模板、往年同期数据、各品类的负责人联系方式、公司的指标定义文档……
Harness Engineering = 建立一套完整的工作保障机制
设定明确的阶段检查点（数据提取完成后必须先做验证再分析）；关键数字要和财务系统自动核对；分析结论写完后由独立的审核流程校验逻辑；如果中途数据源出错，自动切换备用数据源并通知你；最终报告提交前跑一遍格式检查脚本……
区别不在于他聪不聪明，在于有没有一套系统能让他即便面对异常情况也能稳定交付。
Harness 的六层架构
把 Harness 拆开来，可以分成六个层次，从内到外依次是：
第一层：上下文管理（信息边界）
这一层决定模型"能看到什么"。信息边界设得好，模型才能在正确的约束下思考，不会因为信息过载而漏掉关键约束，也不会因为信息缺失而乱猜。
三个关键动作：
- 角色与目标定义：模型要清楚自己是谁、这次任务的边界在哪、成功的标准是什么
- 信息裁减：上下文不是越多越好，越相关越好——无关信息会稀释注意力
- 结构化组织：把"永久规则"、“当前任务”、“运行状态”、"外部证据"分层放置，让模型能快速定位
一个工程级数据点： 通过 KV 缓存局部性（KV-cache Locality）和语义路由优化，在不换模型的情况下，Token 成本可以从 $3.00/MTok 降低到 $0.30/MTok，同时延迟降低 75%。关键操作之一，是把系统提示里的动态元素（比如精确到秒的时间戳）替换成稳定内容——这个小改动能让前缀缓存命中率大幅提升。
第二层：工具系统（能力边界）
没有工具，大模型是个强大的文本预测器，但碰不到真实世界。工具让 Agent 能真正做事——查数据库、调 API、运行代码、操作浏览器。
Harness 在这里要解决三个问题：
- 工具的数量：工具太少，能力不够；工具太多，模型容易乱用或者在选择上浪费大量推理
- 工具的调用时机：让模型知道"什么情况下该用工具，什么情况下直接回答"
- 工具结果的处理：工具返回的原始结果往往包含大量噪音，需要在回喂给模型之前进行提炼和筛选
一个常见陷阱： 把 250 个 SaaS API 的完整文档全部塞进系统提示——理论上模型"知道"更多，实践中往往更差。正确的做法是只在相关任务的上下文中动态加载对应工具的说明。
第三层：执行编排（流程骨架）
这一层决定"模型下一步该做什么"，以及整个任务如何被有序推进。
很多 Agent 的问题不是某一步不会，而是缺乏全局视角——它会搜索、会分析、会写代码，但整个过程想到哪做到哪，最后交出一堆半成品。
一个有 Harness 的任务流程是这样的：
明确目标和成功标准
→ 判断当前信息是否足够
→ 信息不足则先获取，不猜测
→ 分阶段执行，每阶段有明确输出
→ 完成后自我校验（对照成功标准）
→ 发现偏差则修正或重试，不硬着头皮继续
→ 最终验收交付
执行编排还包括：时间和步骤的预算限制（防止 Agent 陷入无限循环），以及任务分解粒度的控制（粒度太粗容易失控，粒度太细又会拖慢速度）。
第四层：记忆与状态（持续性）
没有状态的 Agent，每一轮都像失忆——不知道自己刚做了什么，不知道哪个结论已经确认，哪个问题还没解决。
Harness 需要管理三类完全不同的状态：
| 类型 | 内容 | 生命周期 | 存储位置 |
|---|---|---|---|
| 任务状态 | 当前步骤、中间结果、待处理项 | 一次任务执行期间 | 内存 / 临时文件 |
| 会话记忆 | 用户偏好、本次对话关键结论 | 整个会话 | 会话存储 |
| 长期记忆 | 历史决策、跨会话的知识积累 | 永久 | 向量数据库 / 持久化存储 |
这三类一旦混存，Agent 的行为会越来越不可预测。清晰的状态分层，是 Agent 从"原型"走向"生产"的必要条件。
第五层：评估与观测（可见性）
这是最容易被忽视、也最致命的一层。
如果没有独立的评估机制，Agent 做完任务之后你根本不知道它做得好不好——更危险的是，Agent 自己往往觉得做得不错。研究表明，让模型自评，结果系统性地偏乐观，在体验设计、代码质量这类主观判断上尤为明显。
这一层要解决的核心问题：系统不只是要"会做"，还要知道自己"有没有真的做对"。
具体包括：
- 执行日志：每一步做了什么、调了哪些工具、返回了什么——不是给人看的，是给系统自己做归因用的
- 结果校验：有明确标准的任务，自动对照标准检查输出
- 指标监控：响应时间、工具调用次数、token 消耗、任务成功率……长期追踪才能发现退化
- 错误归因：出了问题能定位到是哪一步、什么原因，而不是"不知道为什么就错了"
第六层：约束、校验、失败与恢复（安全网）
这一层往往才是决定系统能不能上生产的真正门槛。
在真实环境里，失败是常态，不是例外：API 超时、第三方数据格式变了、模型对模糊需求做了错误假设、一个工具的返回值触发了意外的分支……
没有恢复机制的 Agent，每次失败都只能从头来过。成熟的 Harness 必须包括：
- 硬约束：某些操作不需要判断，直接禁止（比如生产数据库的写操作必须经过人工确认）
- 熔断机制：当错误超过阈值，自动暂停并等待人工介入，而不是无限重试
- 降级路径：主路径失败后，有备选方案而不是直接报错
- 幂等性设计：操作可以安全地重试，不会因为重复执行产生副作用
- 人在环路（Human-on-the-loop）：高风险操作触发前，Harness 自动插入人工审批节点
一个关键的认知转变： 告诉 Agent “遵守我们的安全规范” 是 Prompt 层面的约束，依赖概率性服从。而在 CI 流水线里加一个会自动拦截不合规代码的 Linter，是 Harness 层面的约束，强制确定性执行。前者靠模型"想起来"，后者根本不给它犯错的机会。
一线公司的真实实践
OpenAI：3 人团队、5 个月、100 万行代码
2025 年 8 月底，OpenAI 一个三人团队从空仓库开始，用 Codex（OpenAI 的 AI 编码 Agent）构建了一个生产级应用。规则只有一条：团队里没有人手写一行代码，所有代码全部由 Agent 生成。
五个月后，仓库里有超过 100 万行代码和 1500 个合并的 PR。
这个案例最有价值的不是结果，而是他们一路踩的坑和对应的 Harness 解法：
坑 1：Agent 没有共享的代码库理解
第一反应是写一个大型 AGENTS.md，把所有规范、约定、历史决策全部塞进去。失败了，原因有四：上下文窗口装不下；所有东西都标重要，等于没有重要的；时间一长文档会腐烂；平铺的文档无法被机器校验。
解法： 把 AGENTS.md 压缩到 100 行以内，变成一个"地图"而不是"手册"，指向 docs/ 目录下按主题组织的子文档——设计决策、执行计划、产品规格、参考文档分开存放。CI 自动验证交叉引用的完整性。
坑 2：人类 QA 跟不上 Agent 的生成速度
解法是把 Chrome DevTools Protocol 接进 Codex——Agent 可以截图、观察 UI 事件、用 LogQL 查日志、用 PromQL 查指标。设定明确的验收阈值：服务启动必须在 800 毫秒以内才算完成。Codex 任务最长连续跑超过 6 个小时，通常是工程师睡觉的时候。
坑 3：没有架构约束导致代码腐化
Agent 默认会复制它在仓库里见过的模式，包括糟糕的模式。解法是强制单向依赖关系：Types → Config → Repo → Service → Runtime → UI。用自定义 Linter 机械执行，错误信息里直接带修复指令。
坑 4：技术债务悄悄积累
解法是把核心工程原则写进仓库，然后用定时的后台 Codex 任务扫描偏离、自动提交重构 PR，大部分在一分钟内自动合并——小额持续偿还，而不是周期性大规模清理。
Spotify：Honk 系统，1500+ AI 生成的 PR
Spotify 的 Honk 系统从 2024 年中开始，已经在数百个代码仓库里合并了超过 1500 个 AI 生成的 PR。
他们遇到了和 OpenAI 类似的问题：AI 生成代码的速度远超人工审查能力，而 AI 引入安全漏洞的速度也在同步加速。一项 2025 年 9 月的分析显示，AI 生成的代码每月引入超过 1 万个新安全发现，是 2024 年 12 月的 10 倍。
Honk 的核心 Harness 设计是验证循环（Verification Loop）：Agent 生成代码后，必须经过自动化测试、安全扫描、代码规范检查三道关卡，任何一道不过都会打回重新生成，而不是让错误的代码进入人工审查队列。
这个设计的本质是把"概率性的规范遵守"变成"确定性的规范强制"。
企业采用的现实：有监督的确定性工作流
2025—2026 年，生产环境里一个明显的趋势："无约束多 Agent 网状协作"正在被淘汰，有监督的确定性工作流正在主导。
实践者的反馈很一致：高度自主的 Agent 集群脆弱、昂贵、几乎不可调试。主流模式正在向单一、职责明确的 Agent + 确定性工具访问收敛，并在高风险操作前强制插入人工审批节点（Human-on-the-loop）。
这并不是说 Agent 能力不够，而是 Harness 的成熟度还跟不上——在 Harness 没有建好之前，给 Agent 更多自主权往往意味着更多失控。
Harness Engineering 的核心思想转变
从这些实践里，可以提炼出 Harness Engineering 最重要的几个思维转变：
从"让 Agent 更努力"到"让环境更合理"
当 Agent 犯错，第一个问题不应该是"提示词怎么改"，而应该是"Harness 里缺了什么结构性的约束"。
从"概率性合规"到"确定性强制"
告诉 Agent 要遵守规范是 Prompt，写一个会自动拦截违规的 CI 检查是 Harness。前者靠运气，后者靠机制。
从"单次对话"到"全生命周期管理"
Prompt 优化的是一次对话，Harness 管理的是任务从开始到结束的整个过程，包括失败之后的恢复。
从"工程师写代码"到"工程师设计环境"
OpenAI 的实践给出了一个极端案例：工程师不再写任何应用代码，他们的工作是设计 Agent 的工作环境——规则、约束、验证逻辑、反馈机制。
如果你现在在做 Agent
用以下六个问题自查你的系统，每一个"没有"都可能是成功率的瓶颈：
| 层次 | 自查问题 |
|---|---|
| 上下文 | 你的系统提示里有没有"什么都重要就是没有重点"的问题？信息是否分层组织，而不是一股脑堆叠？ |
| 工具 | Agent 调用了大量工具但效果依然差？工具数量是否过多？工具返回结果是否经过筛选再回喂？ |
| 编排 | 长任务执行到一半"跑偏"了怎么办？有没有明确的阶段检查点和修正机制？ |
| 状态 | 任务中间状态、会话记忆、长期知识是否混存在一起？有没有清晰的分层管理？ |
| 评估 | Agent 完成任务后，你怎么知道它做对了？有没有独立于 Agent 自身的验收机制？ |
| 约束恢复 | API 超时、数据格式变化、模型误解任务——这些情况发生时系统会怎么办？有没有熔断和降级路径？ |
一个数字值得记住：当前 88% 的企业 AI Agent 项目无法达到生产级别，65% 的根因是 Harness 缺陷。在 Prompt 和模型上继续投入之前，先把 Harness 建结实。
总结
Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering
说清楚 给对信息 跑得稳
Harness Engineering 不是在取代前两者，而是在更大的系统边界上把它们包含进来。
当任务还是简单的单次生成，Prompt 就够了。当任务开始依赖外部知识和动态信息，Context Engineering 就变得关键。当模型真正进入长链路、自主执行、低容错的真实场景，Harness 几乎是不可避免的。
模型决定 Agent 的能力上限，Harness 决定这个上限能不能被稳定兑现。
两者都重要，但现在绝大多数团队的问题不是模型不够强，而是 Harness 没建起来。
AI相关资源
整理了一些关于AI 学习资料，持续更新中，希望能帮到大家更好的学习AI：
点击查看 → AI 教程合集
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
6
0- 0
已为社区贡献4条内容
所有评论(0)