Harness Engineering：AI Agent 稳定运行的秘密

前言

#

最近 Harness Engineering 这个概念在 AI 圈火得不行，各路技术博客和播客都在讨论。我花了不少时间研究相关资料，包括 Anthropic 和 OpenAI 的公开实践，越看越觉得这东西确实是 Agent 落地过程中绕不过去的一环。很多人在做 Agent 的时候都有过类似的困惑：模型不差、提示词也改了好几版，但跑起来就是不稳定。问题的根源往往不在模型本身，而在模型外面那套运行系统。这套东西，现在有了一个统一的名字：Harness。这篇文章把我研究的心得整理出来，聊聊 Harness Engineering 到底是什么，包含哪些核心部分。

三次重心转移

#

过去两年，AI 工程经历了三次明显的重心转移：从 Prompt Engineering 到 Context Engineering，再到最近的 Harness Engineering。表面上看是换了几个新名词，但它们分别对应了 AI 系统发展中的三个核心问题：

1. 模型有没有听懂你在说什么？
2. 模型有没有拿到足够且正确的信息？
3. 模型在真实执行中能不能持续做对？

这些问题是一层一层往外扩张的。

Prompt Engineering：把话说清楚

#

大模型刚火起来的时候，大家最直观的感受是：同一个模型，换一种说法，结果可能差很多。说「帮我总结一下这篇文章」得到一个平庸的摘要，换一种更结构化的表述，效果马上就不一样。

于是大家开始疯狂研究提示词：角色设定、风格约束、Few-shot 示例、分步引导、输出格式等等。为什么这些东西有效？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给它什么身份，它就沿着那个身份回答；你给它什么样的示例，它就沿着那个范式补全；你强调什么约束，它就把那部分当成重点¹。

所以 Prompt Engineering 的本质不是命令模型，而是塑造一个局部的概率空间。这个阶段最重要的能力是语言的设计。

但 Prompt Engineering 很快就遇到了天花板。很多任务不是你说清楚就行，而是真的需要信息支撑。比如让模型分析一份公司的内部文档、回答产品的最新配置、按规范写代码、在多个工具之间完成复杂任务。提示词写得再漂亮，也替代不了事实本身。

Prompt 擅长的：约束输出、激发模型已有能力、短链路任务。不擅长的：弥补缺失的知识、管理大量动态信息、处理长链路任务里的状态。

Context Engineering：把信息给对

#

当 Agent 开始兴起，模型不再只是回答问题，而是要进入真实环境做事情。它需要多轮对话、调浏览器、读写代码、操作数据库，还要在多个步骤之间传递中间结果，根据反馈不断修正计划。

这时候系统面对的已经不是「一次回答对不对」，而是「整条链路的任务能不能跑通」。以一个真实任务为例：「分析这份需求文档，找出潜在风险，结合历史评审意见给出改进建议，再生成一版发给产品经理的反馈稿」。这已经完全不是一句提示词能解决的了。它至少需要拿到当前需求文档、历史评审记录、相关规范、当前目标、已分析的中间结论、输出的对象、语气要求等等。

Context Engineering 的核心就变成了一句话：模型未必知道，系统必须在合适的时机把正确的信息送进去。

这里的 Context 不只是几段背景资料。在工程意义上，它代表了所有影响模型当前决策的信息总和：用户输入、历史对话、检索结果、工具返回、任务状态、中间产物、系统规则、安全约束，以及其他 Agent 传过来的结构化结果。Prompt 其实只是 Context 的一部分²。

RAG 算是一个典型的 Context Engineering 实践。但真正成熟的上下文工程关注的远不只是检索：文档怎么切块、结果怎么排序、长文怎么压缩、历史对话什么时候保留什么时候摘要、工具返回要不要全部塞给模型、多个 Agent 之间传原文还是摘要还是结构化字段。这些都需要精心设计。

Agent Skill 的渐进式披露也是上下文工程的高级实践。它解决了一个现实问题：如果把十几个工具的说明、参数定义全部塞给模型，理论上它知道得更多，但实践效果往往更差。因为上下文窗口是稀缺资源，信息一多注意力就涣散。Skill 采用的策略是只给模型看最少量的元信息，等它真正需要触发某些能力时，再动态加载详细的参考信息和脚本。

这个思路很关键：上下文的优化不是给得更多，而是按需给、分层给、在正确的时机给。

Harness Engineering：让模型持续做对

#

但 Context Engineering 也不是终点。就算信息给对了，模型也不一定能稳定执行。它可能计划做得很好但执行跑偏了，调了工具但理解错了返回结果，在一个很长的链路里慢慢偏航而系统却没发现。

Prompt 优化意图表达，Context 优化信息供给，但复杂任务里还有一个更难的问题：当模型开始连续行动时，谁来监督它、约束它、纠偏它？

这就是 Harness Engineering 要解决的。

Harness 是什么

#

Harness 这个词原本是挽具、绳索、约束装置的意思。放在 AI 系统里，它提醒我们一件朴素的事情：当模型从回答问题走向执行任务，系统不仅要喂信息，还要驾驭整个过程。

有人给过一个很简洁的公式：Agent = Model + Harness。也就是说，在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都属于 Harness 的范畴。

打个比方。假设你要派一个新人去完成一次重要的客户拜访。

• Prompt 做的事，相当于把任务讲清楚：见面先寒暄、再介绍方案、再问需求、最后确认下一步。重点是把话说对
• Context 做的事，相当于把资料准备齐全：客户背景、过往沟通记录、产品报价、竞品情况、这次会议的目标。重点是把信息给对
• Harness 做的事，相当于建立完整的运行保障：让他带着 Checklist 去，关键节点实时汇报，会后核实纪要和录音，发现偏差马上纠正，按明确标准验收结果。重点是有没有一套持续观测、纠偏和验收的机制

三者不是替代关系，而是包含关系：Prompt 是对指令的工程化，Context 是对输入环境的工程化，Harness 是对整个运行系统的工程化。边界一层比一层大。前两代工程关注的是「怎么让模型更会想」，Harness 关注的则是「怎么让模型别跑偏、跑得稳、出了错还能拉回来」。

Harness 的六层结构

#

把一个成熟的 Harness 拆开来看，我认为可以分成六层。

第一层：上下文管理

#

模型能不能稳定发挥，很多时候不取决于它聪不聪明，而取决于它看到了什么。Harness 的第一层职责是让模型在正确的信息边界内思考，通常包括三件事：

• 角色和目标定义：模型要知道自己是谁、任务是什么、成功的标准是什么
• 信息裁剪和选择：上下文不是越多越好，而是越相关越好
• 结构化组织：固定规则、当前任务、运行状态、外部证据分层放好。信息一乱，模型就容易漏重点、忘约束，甚至自我污染

说到信息裁剪，OpenAI 踩过一个很典型的坑：他们早期写了一个巨大的 Agent 指令文档，把所有规范、框架、约定全部塞进去，结果 Agent 反而更糊涂了。上下文窗口是稀缺资源，塞得太满等于什么都没说。后来他们把文档改成了目录页，只保留核心索引，详细内容拆到架构文档、设计文档、执行计划、质量评分、安全规则等子文档里。Agent 先看目录，需要时再钻进去。这和 Agent Skill 的渐进式披露是同一个思路：不是一次性全给，而是按需暴露。

Anthropic 在长时间自主任务中也遇到了类似问题。上下文越来越满，模型开始丢细节、丢重点，甚至出现一种有意思的现象：模型好像知道自己快装不下了，于是着急收尾。常见的做法是上下文压缩，但 Anthropic 发现对某些场景来说光压缩还不够，压缩只是变短了，不代表负担感真的消失。所以他们做了一件更激进的事：Context Reset。不是在原上下文里继续压，而是换一个干净的新 Agent 接手工作。这个思路很像工程里遇到内存泄漏，不是清缓存，而是直接重启进程再恢复状态³。

第二层：工具系统

#

没有工具，大模型本质上还是一个文本预测器。连上工具后，模型才可以真正做事：搜网页、读文档、写代码、调 API。

但 Harness 在这里做的不是简单地把工具挂上去，而是要解决三个问题：

• 给什么工具：太少能力不够，太多模型会乱用
• 什么时候调用：不需要查的时候别乱查，该查的时候别硬答
• 工具结果怎么回喂：搜索返回的几十条结果不应该原封不动塞回去，要提炼筛选，保持和任务的相关性

OpenAI 在这方面的实践比较极端：他们不只给 Agent 接代码编辑器，还接上浏览器让 Agent 能截图、模拟用户操作，接上日志和指标系统让 Agent 能查 Log、查监控，每个任务都在独立隔离的环境里跑。Agent 不再是写完代码就说「写完了」，而是能真正跑起来、看结果、发现 Bug、修 Bug、再验证。工具系统的设计直接决定了 Agent 能做到多「真实」。

第三层：执行编排

#

这一层解决的核心问题是：模型下一步该做什么。

很多 Agent 的问题不是某一步不会，而是不会把所有步骤串起来。它会搜索、会总结、会写代码，但整个过程想到哪做到哪，最后交付一堆半成品。一个完整的任务通常需要这样的轨道：理解目标 → 判断信息够不够（不够就补）→ 基于结果分析 → 生成输出 → 检查输出 → 不满足要求就修正或重试。

OpenAI 在这方面提出过一个很有启发性的观点：工程师在 Agent 时代的工作不再是写代码，而是设计环境。具体来说就是三件事：把产品目标拆解成 Agent 能力范围内的小任务；Agent 失败时不是让它更努力，而是问环境里缺了什么能力；建立反馈链路让 Agent 能看到自己的工作结果。「Agent 出了问题，修复方案几乎从来不是让它更努力，而是确定它缺了什么能力」。这本身就是典型的 Harness 思维。

第四层：记忆和状态

#

没有状态的 Agent 每一轮都像失忆一样。它不知道自己刚做了什么，哪些结论已经确认，哪些问题还没解决。Harness 必须管理状态，至少要分清三类东西：

• 当前任务的状态
• 会话中的中间结果
• 长期记忆和用户偏好

三类信息如果混在一起，系统会越来越乱。分清楚之后，Agent 才像一个稳定的协作者。

第五层：评估和观测

#

这是很多团队最容易忽视的一层。很多系统不是生成不出来，而是生成完了之后根本不知道自己做得好不好。没有独立的评估能力，Agent 就会长期停留在「自我感觉良好」的状态。

这一层通常包括：输出验收、环境验证、自动测试、日志和指标、错误归因。系统不仅要会做，还要知道自己有没有真的做对。

这里有一个关键的工程原则：生产和验收必须分离。模型自己干活再自己打分，往往偏乐观，尤其在设计体验、产品完整度这类没有标准答案的问题上偏差更明显。Anthropic 的做法是把角色拆开：Planner 负责把模糊需求展开成完整规格，Generator 负责逐步实现，Evaluator 像 QA 一样真实测试。关键是 Evaluator 不只是看代码，而是真实操作页面、检查具体交互和实际结果。只要评估者足够独立，系统就能形成「生成 → 检查 → 修复 → 再检查」的有效循环。

第六层：约束、校验与失败恢复

#

最后一层才是真正决定系统能不能上线的关键。因为在真实环境里，失败不是例外而是常态。搜索不准、API 超时、文档格式混乱、模型误解任务，这些都是家常便饭。

如果没有恢复机制，Agent 每次出错就只能从头再来。一个成熟的 Harness 必须包括：

• 约束：哪些能做，哪些不能做
• 校验：输出前、输出后怎么检查
• 恢复：失败后怎么重试、切路径、回滚到稳定状态

OpenAI 在这一层做了一个很值得借鉴的事：把资深工程师的经验直接编码为系统规则。模块怎么分层、哪一层不能依赖哪一层、什么情况下必须拦截、发现问题后怎么修。这些规则不只是报错，而是把修复方案一起反馈给 Agent，进入下一轮上下文。这已经不是传统意义上的代码规范，而是一套可持续运行的自动治理系统⁴。Agent 提交代码的速度远超人类 Code Review 的处理能力，所以必须靠系统规则来兜底，而不是依赖人工审查。

总结

#

把整条线索串起来：

• Prompt Engineering 解决怎么把任务讲清楚
• Context Engineering 解决怎么把信息给对
• Harness Engineering 解决怎么让模型在真实执行中持续做对

Harness 不是在取代前两者，而是在更大的系统边界上把它们包含进来。当任务是简单的单轮生成时，Prompt 很重要；当任务依赖外部知识和动态信息时，Context 就很关键；当模型进入长链路、可执行、低容错的真实场景时，Harness 几乎不可避免。

这也是为什么同样的模型在不同产品里表现差距会这么大。真正决定能不能上线的是模型，但真正决定能不能落地、能不能稳定交付的，是 Harness。AI 落地的核心挑战，正在从「让模型看起来更聪明」转向「让模型在真实世界里稳定工作」。