驾驭工程¶

约 6803 个字预计阅读时间 21 分钟

Harness Engineering: AI Agent稳定落地的核心引擎，重塑AI Agent时代的软件工程。

1.定义¶

Harness Engineering是指在AI系统中，除模型本身外所有决定系统稳定交付能力的组件总和。其核心目标是解决AI Agent在真实场景中的执行稳定性问题，确保模型从“能思考”到“能稳定做事”的关键跨越。

2.AI工程的三阶段演进¶

阶段	核心问题	解决思路	技术重点	局限性
Prompt Engineering (提示词工程)	模型是否可理解指令	优化语言表达	角色设定、风格约束、示例引导	无法弥补知识缺失，不能管理动态信息
Context Engineering (上下文工程)	模型是否获得正确信息	优化信息供给	检索增强(RAG)、渐进式微调、信息分层	无法解决执行过程中的监督与纠偏问题
Harness Engineering (驾驭工程)	模型能否稳定交付任务	优化运行系统	执行编排、状态管理、错误恢复

3.成熟Harness的六层架构¶

3.1 上下文边界层¶

核心功能: 确保模型在正确边界内思考。

关键组件:

角色与目标定义: 明确模型身份、任务范围及成功标准。
信息获取与选择: 确保上下文相关性(非越多越好)。
结构化组织: 分层管理规则、任务状态、外部证据。

3.2 工具系统层¶

核心功能: 连接模型与现实世界的桥梁。

关键挑战:

工具选择: 平衡能力覆盖与使用复杂度。
调用时机: 避免不必要的调用(不必要)和错误判断(不管)。

3.3 执行编排层¶

核心功能: 将任务分解为可执行步骤。

典型流程: 目标理解→信息整合→分析处理→输出生成→结果检查→修正迭代。

价值: 解决Agent“想到哪做到哪”的无序执行问题，确保任务闭环。

3.4 记忆与状态层¶

核心功能: 解决Agent“失忆”问题。

状态分类:

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

管理原则: 分类存储，避免信息混乱导致的执行偏差。

3.5 评估与观测层¶

核心功能: 建立质量反馈机制。

关键组件:

输出验证与验收。
自动化测试系统。
日志与指标监控。
错误回溯分析。

价值: 避免Agent“自我感觉良好”的认知偏差。

3.6 约束校验与恢复层¶

核心功能: 保障系统鲁棒性。

关键机制:

约束机制: 明确能力边界(能做什么/不能做什么)。
校验机制: 输出前后的检查流程。
恢复机制: 失败后的重试、回滚策略。

4.一线公司实践案例¶

4.1 Anthropic的自主编码系统¶

核心问题: 长任务上下文过载。

解决方案: Context Reset(上下文重置)。
类比: 内存泄漏后重启进程而非清理缓存。

核心问题: 自评失真。

解决方案: 角色分离架构：Planner(规划者): 需求转换器；Generator(生成器): 逐步实现；Evaluator(评估者): 环境化测试(真实操作验证)。

4.2 OpenAI的Agent开发实践¶

工程师角色转变: 从写代码→设计环境。

关键策略:

渐进式部署: 将巨型文档拆分为目录+子文档，按需加载。
环境化验证: Agent接测逻辑(截图/操作)+日志系统+隔离环境。
自动治理系统: 将资源工程师经验编码为可执行规则(含修复方案)。

4.3 关键策略¶

约束机制: 明确能力边界(能做什么/不能做什么)。
校验机制: 输出前后的检查流程。
恢复机制: 失败后的重试、回滚策略。

5.关键洞察¶

能力边界: Prompt解决“说清楚”，Context解决“信息对”，Harness解决“持续做对”。
包含关系: Harness包含前两者，是更大系统边界的工程化。
落地关键: 模型决定上限，Harness决定能否稳定落地。
发展趋势: AI落地挑战正从“让模型聪明”转向“让模型稳定工作”。

6.Reference¶

最近爆火的 Harness Engineering 到底是啥？一期讲透！

《最近爆火的 Harness Engineering 到底是啥？一期讲透！》字幕

过去两年呢，AI工程其实经历了三次很明显的中心迁移：从prompt engineering、上下文工程，再到最近的harness engineering。表面上看好像只是换了几个新的名词，但如果你只是把它理解成术语流行式，那就完全低估它们了。

那这三个词呢，分别对应了现在AI系统发展的三个阶段性问题：模型有没有听懂你在说什么，模型有没有拿到足够而且正确的信息，模型在真实的执行力能不能持续的做对。你会发现这些问题呢，是一层一层往外扩张的。

在大模型刚火起来的时候呢，大家最直观的感受就是：同一个模型，你换一种说法，结果可能差很多。比如你说一句「帮我总结一下这篇文章」，他可能只会给你一个很平的总结；但如果你换一种说法，效果马上就会不一样。所以那个阶段呢，大家都相信一件事情：模型不是不会，而是你没有把问题说明白。于是大家开始疯狂的研究提示词：什么角色设定、风格约束、few-shot的示例分布、引导输出格式，等等等等。

那为什么这些东西有效呢？因为大模型本质上是一个对上下文非常敏感的概率生成系统：你给他什么身份，他很容易沿着那个身份去回答；你给他什么样的样例，他很容易沿着那个范式去补全；你强调什么样的约束，它就很容易把那部分当成重点。所以提示词工程的本质不是命令模型，而是塑造一个局部的概率空间。那这个阶段的最重要的能力不是系统的设计，而是语言的设计。

但提示词工程很快就遇到了天花板。因为很多任务不是你说清楚就行，而是你真的得知道——比如你让模型分析一份公司的内部文档，回答一个产品的最新配置，按照一套非常长的规范去写代码，在多个工具之间完成复杂的任务。这个时候你会发现，提示词写得再漂亮，也替代不了事实本身。所以呢，提示词擅长的是长期任务约束输出、激发模型的已有能力，但是他不擅长凭空弥补缺失的知识、管理大量动态的信息、处理长链路任务里的状态。说白了，提示词解决的是表达的问题，不是信息的问题。于是第二阶段开始了。当大家还只是做聊天机器人的时候呢，提示词的作用很大，因为任务短、链路短、状态少，很多问题确实靠把话说明白就可以解决了。但后来agent开始火了，模型不只是要回答问题，而是要进到真实的环境里面做事情：他要多轮对话，调浏览器，写代码，数据库这些工具，还要在多个步骤之间传递中间结果，还要根据外部的反馈不断修订计划。

那这个时候问题就变了：系统面对的已经不是一次回答对不对，而是整条链路的任务能不能跑通。比如如果你不是简单的问一句「帮我总结一下这篇文章」，而是让他做一个更真实的任务啊——比如说，帮我分析这份需求文档，找出潜在风险，结合历史的评审意见给出改进建议，再生成一版发给产品经理的反馈稿——你会发现，这已经完全不是一句提示词就能解决的问题了。他至少要拿到当前的需求文档、历史的评审记录、相关规范、当前目标、已经分析出来中间结论、输出的对象是谁、语气应该怎么调，等等等等。

所以context engineering的核心就变成一句话：模型未必是知道的，系统必须在合适的时机把正确的信息送进去。那这里的context呢，也不只是几段背景的资料；在工程的意义上，它代表了所有影响模型当前决策的信息的总和，包括用户的输入、历史对话、检索结果、工具返回、当当前任务的状态、中间产物、系统规则、安全约束，或者其他agent的传过来的结构化的结果。所以你会看到，prompt其实只是context的一部分；也正因为如此呢，推到上下文的供给机制是非常重要的。

那说到context engineering呢，我觉得RAG也算是一个比较典型的实践。RAG的价值是很直接的：模型参数里面没有知识，怎么在运行时补进去呢？那做法大家都知道：先检索，再把相关的内容塞到上下文。

但是真正成熟的context engineering呢，关注的肯定不只是检索啊，他关注的是整条完整的链路：比如文档怎么切块，结果怎么排序，长文怎么压缩，历史对话什么时候要保留、什么时候要摘要，工具返回要不要全部暴露给模型，多个A证的之间到底传原文摘要还是结构化的字段呢，包括最近很火的agent skills——我觉得本质上也是上下文工程的高级实践。因为它解决了一个特别现实的问题：如果你把十几个不同的工具、工具的说明、所有的参数定义全部一上来就塞个模型，理论上模型会知道的更多，但是实践往往会更糟糕。

为什么呢？因为上下文的窗口是非常稀缺的资源，信息一多，注意力就会涣散。所以skill采用的是一个非常典型的思路，叫渐进式披露：不是一开始就把能力全部给模型看，而是只给他看最少量的原信息；等他真正的要触发某些能力的时候，再把那部分的SOP、详细的参考信息、脚本动态的加载进来。

那这个思路呢，其实非常重要，因为它告诉我们：上下文的优化不只是给的更多，而是按需给、分层给、在正确的实际给。

但是上下文工程其实也不只是终点，因为后来大家又发现了一个更麻烦的问题：就算信息给对了，模型也不一定能稳定的执行的正确。它可能计划做的很好，但是执行跑偏了、掉了工具、但理解错了，返回结果在一个很长的链路里已经慢慢偏航了，但是系统却没有发现。哎，这个时候我们发现啊，提示词和上下文其实主要的解决都在输入词的问题——提示词优化意图的表达，上下文优化的是信息的供给。但是复杂的任务里还有一个更难的问题：当模型开始连续行动的时候，谁来监督它、约束它和纠偏它呢？这个时候第三阶段来了。harness这个词呢，原本的意思是缰绳、马具、约束装置的意思；放到AI系统里面，其实就是在提醒我们一件非常朴素的事情：当模型做从回答问题走向执行任务，系统不只要能够负责信息，还要能够驾驭整个过程。这个就是harness engineering的出发点。

如果前两代工程关注的是怎么让模型更会想，那harness更关注的就是怎么让模型别跑偏、跑得稳、出了错还能拉回来。

这里呢啊，我用一个比较通俗的例子啊，来解释这三个概念。假设你要派一个新人去完成一次很重要的客户拜访的工作：prompt engineering呢，就是你要告诉他先把任务讲清楚——比如见面先寒暄，再介绍方案，讲完需求，最后确认下一步啊——这个就是prompt，重点是把话说明白。那context engineering是啥呢？你要告诉他把资料要准备齐全啊，比如说这个客户的背景、过往的沟通记录、产品的报价、竞品的情况啊、这次会议的目标，这些都是context，重点是把信息要给对。那如果这个会真的很重要啊，你还会继续做很多事情啊，比如说让他带着checklist去，让他在关键的节点实时汇报，汇后核实纪要和录音啊，如果发现偏差马上纠正，最后按照明确的标准去验收结果。这些啊，就是harness，重点已经不是说清楚和资料齐不齐了，而是有没有一套持续观测、持续纠偏、最终验收结果的机制。

所以呢，这三者啊也不是替代的关系，而是包含的关系：prompt是对指令的工程化，context是对输入环境的工程化，harness呢就是对整个运行系统的工程化。它们的边界是一层比一层大的。

LangChain的工程师呢，给harness下了一个很典型的定义：agent等于model加harness；那harness呢，就等于agent减model。翻译成人话呢，就是在一个Agent的系统里面，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西，都可以算进harness。

那如果拆开来看呢，我自己会把一个成熟的harness engineering分成六层。

第一层啊，就是我们重新站在harness的视角去看context。模型能不能稳定发挥，很多时候不仅取决于他聪不聪明，而取决于他看到了什么。所以harness的第一职责，就是让模型能够在正确的信息边界内思考。第一层通常包括三件事情：首先啊，角色的目标和定义——模型要知道自己是谁、任务是什么、成功的标准是什么；第二，信息的裁剪和选择——上下文不是越多越好，而是越相关越好；第三啊，结构化的组织——固定的规则放在哪，当前的任务放在哪儿，任务运行的状态放在哪儿，外部的证据又放在哪儿，最好分层清除。因为信息一旦乱掉呢，模型就很容易漏重点、忘约束，甚至自我污染。

第二层，工具系统。没有工具，大模型本质上还是一个文本预测器：会解释，会总结，但他接触不到真实的世界。一旦连上工具呢，模型才可以真正的做事，比如搜网页、读文档、写代码、调API，等等等等。但是harness在这里做的，不是简单的把工具挂上去，而是啊也要解决三个问题：第一，给他什么工具——工具太少能力不够，工具太多模型又会乱用；第二，什么时候该调用工具——本来不需要查的时候别乱查，该查账的时候也别硬答；第三，工具结果怎么重新喂回模型——搜索过来的几十条结果，不应该原封不动的塞回去，而是要提炼、筛选，保持和任务的相关性。

第三层，执行编排。那这一层解决的核心问题呢，就是模型下一步该做什么。很多agent的问题呢，不是某一步不会，而是不会把所有的步骤给串起来：它会搜索，也会总结，也会写代码，但整个过程想到哪做到哪儿，最后交付出来一堆半成品。所以一个完整的任务呢，通常需要有这样的轨道：首先理解目标，然后判断信息够不够——不够继续补，基于结果继续分析，然后生成输出，检查输出——不满足要求就重新修正，或者从事。这个时候你会发现，这已经非常接近人在工作了；区别在于人靠经验，代理人靠harness这套环境。

第四层，记忆和状态。那没有状态的agent呢，每一轮都会像失忆一样：他不知道自己刚做了啥，也不知道哪些结论已经确认了、哪些问题还没解决。所以harness还必须要管理状态。这里呢，我们要至少让它分清三类东西：首先，当前任务的状态；会话中的中间结果；长期的记忆和用户偏好。这三类呢，如果混在一起，系统会越来越乱；看清楚之后呢，agent的才会像一个稳定的写作者。

第五层，评估和观测啊。这个呀，就是很多团队啊最容易忽视的一层：很多系统其实不是生成不出来，而是生成完了之后根本不知道自己做的好不好。那如果没有独立的评估和观测的能力，agent就会长期停留在自我感觉良好的状态。这一层呢，通常包括输出和验收、环境的验证、自动的测试、日志和指标、错误的归因，等等等等。也就是说呢，系统不仅是要会做，还要知道自己有没有真的能够做对。

第六层，约束、校验、失败和恢复。那最后一层呢，往往才是真正决定这个系统能不能上线的关键环节。因为在真实的环境里面，失败不是例外，而是常态：可能搜索不准，可能是API超时，也可能文档格式混乱，或者模型误解了任务。那如果没有恢复的机制呢，agent每次出错就只能从头再来。所以一个成熟的harness，一定要包括三件事情：约束啊——哪些能做、哪些不能做；校验啊——比如输出之前、输出之后要怎么检查；恢复——失败之后怎么从事、切入镜、回滚到稳定的状态。

转过来呢，我们来看最有参考价值的部分啊：一线公司的真实实践。因为harness这个词最近之所以突然火起来呢，不是大家在空谈这个方法论，而是很多公司都已经把它做进了产品和工程体系里面了啊。比如LangChain在底层模型完全不变的情况下，只通过改造和迭代安全带，就把他自家的智能体验从一个榜单上的排名直接从30开外杀到了前五。OpenAI呢，依靠一个只有几名人类工程师的团队，用agent从零构建了一个超百万行代码的生产及应用，百分之百的代码都是由agent编写的，耗时呢只有纯人工开发的1/10。那Anthropic呢，也构建了一个可以完全自主编码的系统：只凭一句自然语言的需求，就能在无需人类干预的情况下连续运行几个小时，最后做出完整的游戏、完整的数字音频工作站。

那我们先看看Anthropic的实践啊。首先啊，他们在长城自主的任务上总结了两个特别典型的问题。那第一个问题啊，我自己把它翻译成上下文交易，时间一长，上下文越来越满，模型就是模型就开始丢细节、丢重点；甚至呢还会出现一种很有意思的现象——他好像知道自己快装不下了，于是开始着急的去收尾。很多系统面对这种问题呢，都会做context complication，也就是啊把前面的历史上下文压缩一下再继续跑。但Anthropic发现呢，对于一些模型来说，这还是不够的，因为压缩只是变短了，不代表那种负担感真的消失了。所以他们做了一件更激进的事情，叫context reset：不是在原上下文里面继续压，而是换了一个非常干净的新的agent，把工作交接给他。那这个思路很像什么呢？特别像工程里面遇到内存泄漏之后，不是继续清缓存，而是直接重启整个进程再恢复状态。这个其实就是一种非常典型的harness设计。

那Anthropic解决的第二个问题呢，就是自评失真的问题。首先模型自己干活啊，再让他自己给自己打分，往往会是会偏乐观的；那尤其是在设计体验、产品完整度这一类没有标准答案的问题上，偏差是更明显的。所以他们采用了一个非常关键的思路啊：把干活的人和验收的人分开。他们是这样拆分的啊：planner负责把模糊的需求扩展成完整的规格，generator负责逐步的去实现，那evaluator呢负责像QA一样去真实的测试。更关键的是，这个evaluator他不只是会看代码，而是会真实的操作页面、看具体的交互、检查实际的结果。也就是说啊，这不是一个抽象的审查，它是一个带具体环境的验证。那这个事情非常重要啊，因为它背后是一个很明确的工程原则：生产验收必须分离。只要评估者足够独立，系统就能形成一个真正的有效循环——生成、检查、修复、再检查的这样的一个循环。

那OpenAI呢，在这方面给我的感觉是，他们重新定义了工程师在agent的时代的工作。他们做了一个非常有意思的思路啊：人类在这个环境里面不需要写一行的代码，人类只需要去负责设计环境。具体来说呢，工程师的工作变成了三件事情：首先，把产品目标拆解成agent能理解的小任务；那agent失败的时候呢，不是让他更努力一点，而是问环境里面缺了什么能力；最后，建立反馈的链路，让agent真正的能够看到自己的工作结果。那这句话我是非常认同的：当agent的出了问题的时候，修复方案几乎从来不是要更努力一点，而是确定他缺了什么样的结构性的能力。这个其实也是典型的harness思维。

OpenAI还有一个特别典型的事件啊，也是渐进式披露。他们早期呢犯过一个很多团队都会犯的错误：写了一个巨大的agent.md，把所有的规范、框架、约定全部塞进去了。结果呢，agent的更糊涂了，因为上下文窗口是一个稀缺的资源，塞的太满，其实等于什么都没说。那后来他们怎么改的呢？把agent.md变成一个目录页啊：页面只保留核心的索引，更详细的内容呢查到架构文档、设计文档、执行计划、质量评分、安全规则这些具体到子文档里面去了。那agent的先看目录，需要的时候再钻进去。那这个时候我们会发现啊，这个和我们前面说的skills本质上是一个思路：不是一次性全给，而是按需暴露。还有个实践啊，就是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，我觉得这件事情非常值得你趁早想明白。