Appearance
Harness Engineering：让 Agent 在真实世界里稳定工作
一个普遍的困境
许多做 Agent 的团队都遇到过同样的困惑：为什么同样的模型，别人做出来的 Agent 可以连续跑很久、成功率很高，到了自己手里却总是差强人意？
常见的猜测无非那么几个 —— 模型不够强、提示词没调好、RAG 没调明白。这些当然都有影响，但越来越多的团队最终发现：真正决定系统能不能稳定跑起来的，往往不是模型本身，而是模型外面那套运行的系统。
一些团队的经历很有代表性：换上最好的旗舰模型，提示词改了上百版，各种参数也调了不少，但一进真实场景，效果还是不稳定 —— 有时候很聪明，有时候莫名其妙跑偏，任务成功率不到 70%。而当他们重新审视问题，把注意力放在任务怎么拆分、状态怎么管理、关键步骤怎么校验、失败后怎么恢复之后，还是同样的模型、同样的提示词，成功率拉到了 95% 以上。
这些改动有一个统一的名字 —— Harness Engineering。
过去两年，AI 工程经历了三次明显的中心迁移：Prompt Engineering → Context Engineering → Harness Engineering。表面看是换了几个新名词，实际上它们分别对应了 AI 系统发展中的三个阶段性问题。要真正理解 Harness Engineering，我们需要先看清这条演进路径。
三次中心迁移：AI 工程的演进
三次中心迁移不是术语更替，而是对应三个阶段性问题：
- 模型有没有听懂你在说什么？ — Prompt Engineering
- 模型有没有拿到足够且正确的信息？ — Context Engineering
- 模型在真实的执行中能不能持续做对？ — Harness Engineering
这些问题是一层一层往外扩张的。
Prompt Engineering：塑造概率空间
在大模型刚火起来的时候，大家最直观的感受就是：同一个模型，换一种说法，结果可能差很多。你说 “帮我总结一下这篇文章”，可能只得到一个很平的总结；但换一种说法，效果马上就不一样。
于是大家开始研究提示词 —— 角色设定、风格约束、Few-shot 示例分布、引导输出格式，等等。为什么这些技巧有效？因为大模型本质上是一个对上下文非常敏感的概率生成系统。你给它什么身份，它就容易沿着那个身份回答；你给它什么样例，它就容易沿着那个范式补全；你强调什么约束，它就容易把那部分当成重点。
核心判断
提示词工程的本质不是命令模型，而是塑造一个局部的概率空间。
但 Prompt Engineering 很快遇到了天花板。很多任务不是你说清楚就行，而是真的需要知道事实。比如让模型分析内部文档、回答产品最新配置、按长规范写代码、在多个工具间完成复杂任务 —— 提示词写得再漂亮，也替代不了事实本身。
- 擅长：约束输出、激发已有能力
- 不擅长：弥补缺失知识、管理动态信息、维护长链路状态
提示词解决的是表达的问题，不是信息的问题。
Context Engineering：在正确的时机送入正确的信息
当 Agent 开始流行，模型不再只是回答问题，而是要进入真实环境做事情 —— 多轮对话、调浏览器、写代码、查数据库，还要在多个步骤间传递中间结果、根据外部反馈修订计划。此时系统面对的已经不是 “一次回答对不对”，而是 “整条链路的任务能不能跑通”。
一个真实的任务可能是这样的：分析一份需求文档，找出潜在风险，结合历史评审意见给出改进建议，再生成一版发给产品经理的反馈稿。这已经不是一句提示词能解决的了 —— 它至少需要拿到当前需求文档、历史评审记录、相关规范、当前已分析的中间结论、输出对象和语气要求等。
什么是 Context？
Context 不仅仅是几段背景资料。在工程意义上，它代表了所有影响模型当前决策的信息总和：用户输入、历史对话、检索结果、工具返回、当前任务状态、中间产物、系统规则、安全约束，以及其他 Agent 传过来的结构化结果。Prompt 其实只是 Context 的一部分。
Context Engineering 的核心就一句话：模型未必知道，系统必须在合适的时机把正确的信息送进去。
RAG 是 Context Engineering 的典型实践 —— 模型参数里没有知识，就在运行时补进去。但成熟的 Context Engineering 关注的不只是检索，而是整条完整链路：
- 文档怎么切块
- 结果怎么排序
- 长文怎么压缩
- 历史对话什么时候保留、什么时候摘要
- 工具返回要不要全部暴露给模型
- 多个 Agent 之间传原文、摘要还是结构化字段
最近很火的 Agent Skills，本质上也是 Context Engineering 的高级实践。如果把十几个工具的说明和参数定义全部一次性塞给模型，理论上模型知道的更多，但实践往往更糟糕 —— 上下文窗口是稀缺资源，信息一多，注意力就涣散。Skill 采用的是渐进式披露：一开始只给最少量的元信息，等真正需要触发某些能力时，再把那部分的 SOP、详细参考信息、脚本动态加载进来。
上下文的优化不只是给的更多，而是按需给、分层给、在正确的时机给。
Harness Engineering：当模型开始连续行动
即使信息给对了，模型也未必能稳定执行。它可能计划做得很好，但执行跑偏了；调了工具但理解错了返回结果；在长链路里慢慢偏航，系统却没有发现。
Prompt 和 Context 主要解决的还是输入侧的问题：Prompt 优化意图表达，Context 优化信息供给。但在复杂任务里，还有一个更难的问题 —— 当模型开始连续行动，谁来监督它、约束它、纠偏它？
Harness 这个词原本的意思是缰绳、马具、约束装置。放到 AI 系统里，就是在提醒一件朴素的事情：当模型从回答问题走向执行任务，系统不仅要负责喂信息，还要能够驾驭整个过程。
用一个通俗的比喻来区分三者：
- Prompt Engineering：告诉新人 “见面先寒暄，再介绍方案，再挖需求，最后确认下一步” —— 把话说明白；
- Context Engineering：准备好客户背景、过往沟通记录、产品报价、竞品情况、会议目标 —— 把信息给对；
- Harness Engineering：让他带着 checklist 去，关键节点实时汇报，会后核实纪要和录音，发现偏差马上纠正，按明确标准验收结果 —— 有一套持续观测、纠偏、验收的机制。
三者不是替代关系，而是包含关系。Prompt 是对指令的工程化，Context 是对输入环境的工程化，Harness 是对整个运行系统的工程化。边界一层比一层大。
Harness 的六层架构
LangChain 的工程师给 Harness 下了一个很典型的定义：
Agent = Model + Harness
Harness = Agent − Model
也就是说，在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都可以算进 Harness。拆开来看，一个成熟的 Harness 可以分为六层。
Layer 1：上下文环境
模型能不能稳定发挥，很多时候不仅取决于它聪不聪明，而取决于它看到了什么。Harness 的第一职责，就是让模型在正确的边界内思考。
这一层通常包括三件事：
- 角色和目标定义：模型需要知道自己是谁、任务是什么、成功标准是什么
- 信息裁剪和选择：上下文不是越多越好，而是越相关越好
- 结构化组织：固定的规则放在哪、当前任务放在哪、运行状态放在哪、外部证据又放在哪 —— 分层清楚。因为信息一旦乱掉，模型很容易漏重点、忘约束，甚至自我污染。
Layer 2：工具系统
没有工具，大模型本质上还是一个文本预测器 —— 会解释、会总结，但接触不到真实世界。连上工具之后，模型才可以真正做事：搜网页、读文档、写代码、调 API。
但 Harness 在这里做的不是简单地把工具挂上去，而是要解决三个问题：
- 给什么工具：太少能力不够，太多模型又会乱用；
- 什么时候调用：不该查的时候别乱查，该查的时候别硬答；
- 工具结果如何回喂模型：搜索回来的几十条结果，不应原封不动地塞回去，而是要提炼筛选，保持和任务的相关性。
Layer 3：执行编排
这一层解决的核心问题是：模型下一步该做什么？
很多 Agent 的问题不是某一步不会，而是不会把步骤串起来。它会搜索、会总结、也会写代码，但整个过程想到哪做到哪，最后交付一堆半成品。
一个完整的任务通常需要这样的轨道：
理解目标 → 判断信息是否充分 → 补充信息 → 分析 → 生成输出 → 检查输出 → 不满足则修正或重试这已经非常接近人在工作的方式了。区别在于：人靠经验，Agent 靠 Harness 这套环境。
Layer 4：记忆与状态
没有状态的 Agent，每一轮都像失忆 —— 不知道自己刚做了什么，也不知道哪些结论已经确认、哪些问题还没解决。
Harness 必须管理状态，而且至少要分清三类：
- 当前任务状态：走到哪一步了，哪些已完成，哪些待处理；
- 会话中的中间结果：已经分析出来的结论、已经确认的数据；
- 长期记忆和用户偏好：跨会话的知识积累。
这三类如果混在一起，系统会越来越乱。分清之后，Agent 才会像一个稳定的工作者。
Layer 5：评估与观测
这是很多团队最容易忽视的一层。
很多系统不是生成不出来，而是生成完了之后根本不知道自己做得好不好。如果没有独立的评估和观测能力，Agent 就会长期停留在自我感觉良好的状态。
这一层通常包括：
- 输出验收：结果是否满足需求，环境是否正常运行；
- 自动测试 / 日志 / 指标：量化系统的表现；
- 错误归因：问题出在哪一步，是信息不足、工具错误还是模型判断失误。
提示
系统不仅要有能力做，还要知道自己有没有真正做对。
Layer 6：约束、校验与故障恢复
最后一层，往往是真正决定系统能不能上线的最关键环节。
在真实环境里，失败不是例外，而是常态。搜索可能不准，API 可能超时，文档格式可能混乱，模型可能误解了任务。如果没有恢复机制，Agent 每次出错就只能从头再来。
一个成熟的 Harness 一定要包括三个要素：
- 约束：哪些能做，哪些不能做 —— 划定安全边界；
- 校验：输出之前、输出之后要怎么检查 —— 在关键节点设卡；
- 恢复：失败之后怎么从断点切入，回滚到稳定状态 —— 让系统有韧性。
一线公司的真实实践
Harness 这个概念之所以最近突然火起来，不是因为空谈方法论，而是很多公司已经把它做进了产品和工程体系里。LangChain 在底层模型完全不变的情况下，只通过改造和迭代 Harness，就把自家智能体的榜单排名从 30 开外拉到了前五。OpenAI 依靠一个只有几名人类工程师的团队，用 Agent 从零构建了一个超百万行代码的生产级应用，100% 的代码由 Agent 编写，耗时只有纯人工开发的十分之一。Anthropic 也构建了一个完全自主编码的系统 —— 只凭一句自然语言需求，就能在无需人类干预的情况下连续运行数小时，最终做出完整的游戏和数字音频工作站。
Anthropic 的实践
Context Reset：换一个干净的 Agent 接力
在长时间自主任务上，Anthropic 发现了两个典型问题。第一个是上下文淤积：时间一长，上下文越来越满，模型开始丢细节、丢重点，甚至出现一种有意思的现象 —— 它好像知道自己快装不下了，于是开始着急收尾。
很多系统面对这种问题会做 Context Compression，把前面的历史上下文压缩一下再继续跑。但 Anthropic 发现这对某些模型来说还不够 —— 压缩只是变短了，不代表那种负担感真的消失了。
所以他们做了一件更激进的事：Context Reset。不是在原上下文里继续压，而是换一个非常干净的新 Agent，把工作交接给它。
这个思路很像工程里遇到内存泄漏之后的做法 —— 不是继续清缓存，而是直接重启进程再恢复状态。这是一种典型的 Harness 设计。
自评失真：干活和验收必须分离
Anthropic 解决的第二个问题是自评失真。让模型自己干活、再自己给自己打分，往往会偏乐观。尤其是在设计体验、产品完整度这类没有标准答案的问题上，偏差更明显。
所以他们采用了一个关键思路：把干活的人和验收的人分开。角色这样拆分：
- Planner：把模糊的需求扩展成完整的规格；
- Generator：逐步实现；
- Evaluator：像 QA 一样去真实测试。
更关键的是，Evaluator 不只是看代码，而是会真实操作页面，看具体的交互，检查实际的结果。这不是一个抽象的审查，而是一个带具体环境的验证。
工程原则
生产验收必须分离。只要评估者足够独立，系统就能形成一个真正有效的循环：生成 → 检查 → 修复 → 再检查。
OpenAI 的实践
重新定义工程师角色：不写代码，只设计环境
OpenAI 给人的感觉是，他们重新定义了 Agent 时代工程师的工作。人类不需要写一行代码，只需要负责设计环境。具体来说，工程师的工作变成了三件事：
- 把产品目标拆解成 Agent 能理解的小任务。
- Agent 失败时，不是让它更努力一点，而是问环境里缺了什么能力。
- 建立反馈链路，让 Agent 真正能看到自己的工作结果。
典型的 Harness 思维
当 Agent 出了问题，修复方案几乎从来不是 “要更努力一点”，而是确定它缺了什么样的结构性能力。
渐进式披露：从巨型文档到目录页
OpenAI 早期犯过一个很多团队都会犯的错误：写了一个巨大的 agent.md，把所有规范、框架、约定全部塞进去。结果 Agent 更糊涂了 —— 上下文窗口是稀缺资源，塞得太满等于什么都没说。
后来他们把 agent.md 变成一个目录页，只保留核心索引，更详细的内容拆到架构文档、设计文档、执行计划、质量评分、安全规则等子文档里。Agent 先看目录，需要时再钻进去。这和前面说的 Skills 本质上是同一个思路 —— 不是一次性全给，而是按需暴露。
让 Agent 看见自己的工作
OpenAI 不只是让 Agent 写代码，还会让 Agent 看见整个应用。因为产出速度一旦上来，瓶颈就不再是写而是验了，人类根本验不过来。
所以他们让 Agent 自己去验：
- 接浏览器：能截图、点页面，模拟用户的真实操作；
- 接日志和指标系统：让 Agent 查 log、查监控；
- 每个任务独立隔离环境：互不影响。
结果就是 Agent 不再是写完代码就说写完了，而是真正跑起来看结果，发现 Bug、修 Bug、再验证。这就是 Harness 里非常完整的一套：执行编排、评估观测、约束恢复。
自动治理系统
OpenAI 不只靠人类在最后的 Code Review 环节兜底质量，因为 Agent 的提交速度太快了，人类盯不过来。所以他们把很多资深工程师的经验直接写成了系统规则 —— 模块怎么分层、哪一层不能依赖哪一层、什么情况下必须拦截、发现问题后应该怎么修。
重点是：这些规则不只是报错，而是把怎么修也一起反馈给 Agent，进入下一轮上下文。这已经不是传统意义上的代码规范了，而是一套可持续运行的自动治理系统 —— 也是 Harness 的典型形态。
写在最后
三者之间的关系很清晰：
- Prompt Engineering 解决的是怎么把任务讲清楚；
- Context Engineering 解决的是怎么把信息给对；
- Harness Engineering 解决的是怎么让模型在真实的执行中持续做对。
Harness 不是在取代 Prompt，也不是在取代 Context。它是在更大的系统边界上，把前两者都包含进来。当任务还是简单的单轮生成，Prompt 很重要；当任务开始依赖外部知识和动态信息，Context 就很关键；当模型真的进入了长链路、可执行、低容错的真实场景，Harness 几乎不可避免。
这也是为什么同样的模型，在不同的产品里表现差距会这么大。真正决定上限的可能是模型，但真正决定能不能落地、能不能稳定交付的是 Harness。
AI 落地的核心挑战，正在从 “让模型看起来更聪明” 转向 “让模型在真实世界里稳定工作”。如果你正在做 Agent，这件事情值得趁早想明白。