年初的时候一个朋友跟我吐槽他们团队花了几个月调 Agent换上了最好的旗舰模型提示词改了上百版。结果到了真实场景还是不稳定 — 时灵时不灵效果差强人意。后来他们请我来帮忙做调优我没动模型也没改提示词。而是重新设计了任务拆解、状态管理、校验机制和失败恢复的流程。新版上线后同样的模型、同样的提示词任务成功率从不到 70% 涨到了 95% 以上。朋友问我“你改的到底是啥”说实话我当时也没有一个现成的词来概括。直到最近Harness Engineering 这个概念突然火了起来我才意识到 — 我改的那些东西就是 Harness。今天这篇教程我会从三个角度把 Harness 这个新概念跟大家讲清楚Harness 的演进从 Prompt Engineering 到 Context Engineering 再到 Harness EngineeringAI 工程的重心经历的三次迁移。Harness 的构成拆开来看一个成熟的 Harness 到底包含哪些部分每一层分别在解决什么问题。Harness 的实践OpenAI、Anthropic 等头部公司是怎么在真实产品中落地 Harness 的以及它们的做法为什么有效。一、Harness 的演进过去两年AI 工程领域经历了三次重心迁移。表面上看只是术语在更新 —Prompt Engineering、Context Engineering、Harness Engineering。但把时间线拉长你会发现它们对应着三个越来越本质的问题模型是否听得懂你在说什么模型是否拿到了足够且正确的信息模型是否能在真实执行中持续做对理解这三次迁移不只是理解几个新名词而是在理解 AI 系统是如何一步步从 “会聊天” 走向 “可交付” 的。1.1 Prompt Engineering大模型刚爆发的时候很多人第一次感受到一种近乎魔法的体验同一个模型换一种说法结果可能天差地别。你对它说“帮我总结一下这篇文章。”它可能给你一段平平无奇的概述。但如果你换成“请以资深技术编辑的身份用三段结构总结这篇文章先讲核心观点再讲论证方式最后讲局限性每段不超过 150 字。”结果通常会明显好很多。这就是 Prompt Engineering 最早的魅力所在。它的核心思想很朴素模型不是不会而是你没有把问题讲清楚。既然模型对输入形式敏感那工程优化的第一步自然就是优化指令本身。于是一整套方法迅速流行起来角色设定先告诉模型 “你是谁”。目的不是 cosplay而是先限定它该站在哪个专业视角上说话。风格约束告诉模型 “怎么说”。解决的不是对不对而是像不像你要的表达。Few-shot示例少讲原则多给样例。很多时候模型不是听不懂规则而是更擅长模仿范式。分步引导别让它直接跳答案先拆再想再答。作用是减少拍脑袋式结论。格式约束提前规定输出长什么样。它提升的不是智商而是可用性。拒答边界先划红线再让它回答。核心是降低 “明明不知道还特别自信” 的风险。那时候Prompt 像一把万能钥匙。很多团队都曾真诚地相信只要提示词打磨得足够精细模型就能越来越稳定、越来越好用。这种判断并不荒谬。因为在那个阶段Prompt Engineering 确实解决了一个最直接的问题如何把人类意图更准确地映射成模型行为。1.1.1 Prompt Engineering 为什么会有效因为大模型本质上是一个对上下文极度敏感的概率生成系统。它不是“命令行”更像是一个临时搭建出来的认知场你给它什么身份它会沿着那个身份分布去采样你给它什么例子它会沿着那个模式继续补全你强调什么约束它就更可能把那部分当成高权重信号。所以Prompt Engineering 的本质不是“下命令”而是“塑造局部概率空间”。这个阶段最重要的工程能力也不是系统设计而是语言设计。谁更懂模型的脾气谁就更容易做出看起来更聪明的效果。1.1.2 Prompt Engineering 的天花板Prompt 问题出在很多任务不是“你说清楚就行”而是“你得真的知道”比如你让模型分析一份公司内部文档回答某个产品最新配置对照一套长规范生成代码在多个工具之间完成复杂任务这时你会发现提示词再漂亮也不能替代事实本身。Prompt 擅长的是澄清任务、约束输出、激发已有能力。但它不擅长凭空补齐缺失知识、管理大量动态信息、处理长链条任务中的状态变化。说得更直接一点Prompt 解决的是“表达问题”不是“信息问题”。当任务从开放问答进入真实业务工程重点自然开始转移。大家逐渐意识到模型答得不好未必是因为你不会问也可能是因为你根本没把它需要的材料给全。问题的焦点从 “怎么说” 变成了 “给什么”。于是第二次迁移来了。1.2 Context Engineering如果说 Prompt Engineering 的默认假设是 模型本来就知道只是你得问对。那么 Context Engineering 的默认假设变成了 模型未必知道所以系统必须在调用时把正确的信息送进去。在 Prompt 时代大家主要研究的是 “怎么把一句话说好”。到了 Context 时代问题变成了模型现在看到了什么没看到什么哪些信息该提前给哪些该延后给哪些信息该完整保留哪些该摘要压缩哪些信息应该对当前模块可见哪些应该被隔离1.2.1 为什么 Context Engineering 会兴起最重要的原因是模型的使用场景变了。在大模型刚流行的时候主流交互形态还是聊天用户提一个问题模型给一段回答。这种模式下Prompt 的权重很高因为任务短、链路短、状态少很多问题确实可以靠 “把话说清楚” 解决。但后来 Agent 开始爆火情况一下子变了。模型不再只是回答问题而开始被放进真实的执行环境中要持续多轮对话、要调用搜索、浏览器、代码、数据库等工具要在多个步骤之间传递中间结果、要根据外部反馈不断修正计划、甚至要和其他 Agent 分工协作这时候系统面对的已经不是 “一次回答对不对”而是 “一整个任务链路能不能跑通”。举个很简单的例子如果你只是问模型一句“帮我总结这篇文章。”那它只需要看文章内容再按要求输出即可。但如果你让它完成一个更真实的任务比如“帮我分析这份需求文档找出潜在风险结合历史评审意见给出修改建议并生成一版给产品经理看的反馈稿。“这已经不是一句 prompt 能解决的事了。它至少需要拿到当前需求文档、历史评审记录相关规范或最佳实践、当前任务目标之前已经分析过的中间结论、输出对象是谁、语气应该如何调整这时就有新的问题暴露出来了模型的上下文窗口是有限的这时候你就必须要考虑你有没有把对的信息以对的形式在对的时刻交给模型。这就是 Context Engineering 兴起的真正背景。1.2.2 Context 到底是什么很多人一提到 Context就会想到 “给模型补几段背景资料”。这当然没错但太窄了。在工程意义上Context 不是一堆附加文本而是所有会影响模型当前决策的信息总和。它通常包括当前用户输入、整个任务的历史对话外部知识检索结果、工具调用返回当前任务状态、工作记忆与中间产物系统规则与安全约束、其他 Agent 传过来的结构化结果所以Prompt 只是 Context 的一部分而不是全部。这也是为什么很多人会有一种很强的体感同一个模型、同一个 Prompt放在不同系统里效果完全不一样。原因往往不在模型也不在 Prompt而在于它们背后的上下文供给机制根本不是一回事。1.2.3 Context Engineering 的典型实践Context Engineering 早期最典型的代表就是 RAG。RAG 的价值其实不复杂它回答了一个非常现实的问题模型参数里没有的知识怎么在运行时补进去它的基本做法是先从外部知识库中检索相关内容再把这些内容注入到当前上下文里让模型基于这些信息继续生成。所以 RAG 之所以重要就是因为它第一次把 “模型不知道怎么办” 这个问题变成了一个工程上可落地的机制。但是真正成熟的 Context Engineering关心的肯定不只是 “检索一下”而是整条链路文档如何切块才能既保留语义又方便召回检索结果如何排序才能让真正关键的内容优先进入上下文长文档如何压缩才能不把窗口挤爆历史对话什么时候保留原文什么时候该摘要工具返回的原始结果是否要全部暴露给模型多个 Agent 之间到底该传原文、摘要还是结构化字段所以RAG 可以说是 Context Engineering 的起点围绕上下文的优化还有很长的路要走。而最近爆火的 Agent Skills我认为是对 Context Engineering 的又一大典型实践。当系统开始调用工具时模型面临的问题不再只是“知道什么”还包括“当前能做什么”。比如你给模型接了十几个工具然后把工具说明、参数定义、注意事项一次性全塞进上下文模型当然 “理论上更知道自己能做什么”。但实践里常常更糟Token 消耗巨大、注意力被分散、简单任务也要背一堆无关能力 …Skills 的核心机制渐进式披露巧妙地缓解了这些问题不要让模型从一开始就看到全部能力和全部信息而是只在需要的时候暴露与当前任务最相关的那一部分。它将技能信息分为三层实现 “按需加载、精准投放”元数据层~50 Token仅包含技能名称、触发条件、功能概述启动时全局加载指令层~500 Token标准作业流程SOP、输入输出规范仅在任务触发时加载资源层按需加载脚本、模板、API 文档等仅在执行具体步骤时动态调用这种机制将模型在复杂 Agent 场景下的上下文利用率提升了数倍。1.2.4 Context Engineering 的局限性到这里很多系统已经比纯 Prompt 时代强很多了。模型拿到了更好的信息也能处理更复杂的任务。可新的问题又出现了即便信息是对的模型也未必会稳定执行对。它可能计划做得很好但执行偏了调了工具但误解了结果中间某一步出错后继续一路错下去表面看起来很自信实际上任务状态早已失真在长流程里逐渐偏航却没人发现你会发现Prompt 和 Context 都主要作用在“输入侧”Prompt 在优化意图表达Context 在优化信息供给但真实世界的复杂任务还有一个更难的问题当模型开始连续行动时谁来持续监督它、约束它、纠正它这时第三次迁移开始发生。1.3 Harness EngineeringHarness 这个词原本就有 “缰绳、马具、约束装置” 的意思。放在 AI 系统里它不是一个华丽的新包装而是一个非常直白的提醒当模型从“回答问题”走向“执行任务”系统不能只负责喂信息还必须负责驾驭过程。这就是 Harness Engineering 的出发点。如果说前两代工程思路关注的是如何让模型 “更会想”那么 Harness Engineering 更关心的是如何让模型“别跑偏、跑得稳、出了错能拉回来”。1.3.1 三者的对比我们来看一个通俗的例子假设你要让一个新人完成一次重要客户拜访。Prompt Engineering你会先把任务讲清楚“见面先寒暄再介绍方案再问需求最后确认下一步。”这是提示词层面的工作。重点是把话说明白。Context Engineering接着你会把资料准备齐客户背景、过往沟通记录产品报价、竞品情况、这次会议目标这是上下文层面的工作。重点是把信息给对。Harness Engineering但如果会议很重要你不会只做到这里。你还会让他带着 checklist 去、要求关键节点实时回报会后核对纪要与录音、出现偏差时马上纠正对最终结果按明确标准验收这就是 Harness。重点已经不只是“说清楚”和“给资料”而是建立一个持续观测、纠偏、验收的机制。1.3.2 三者的关系很多人看到新词出现就容易误以为旧词过时了恰恰相反他们是层层递进的关系。Prompt Engineering关注的是 “我该怎么对模型说”本质上是在优化单次调用里的指令表达Context Engineering往外扩了一层关注的不再是 prompt 本身而是模型在当前时刻 “能看到什么信息”因此 prompt 只是 context 的一个组成部分历史对话、检索结果、工具返回、任务状态、工作记忆都被纳入进来Harness Engineering则又再往外扩了一层它关心的已经不是 “输入给得对不对”而是模型在真实执行过程中是否被一个完整系统持续约束、观测、纠偏和收敛因此 context 也只是 harness 中的一部分。换句话说Prompt是对 “提示词” 的工程化Context是对 “输入环境” 的工程化Harness是对 “整个运行控制系统” 的工程化边界一层比一层大所以后者天然包含前者。很多技术趋势看上去像观点之争实际上是任务复杂度逼出来的。当任务简单时Prompt 就够了。当任务复杂到上下文不够用时Context 成为核心。当任务变成需要持续执行、长链路、低容错时Harness 几乎不可避免。二、Harness 的构成2.1 Harness 到底是什么LangChain 工程师给 Harness 下一个非常典型的定义Agent Model HarnessHarness Agent - Model简单理解Harness 是在一个 Agent 环境中除了模型外的所有东西它决定了模型看到什么、能做什么、按什么规则做、做错了怎么纠偏以及最后如何把能力稳定地交付出来。理解这一点你对 Agent 的认识会一下子清晰很多为什么同一个模型在不同产品里表现差距巨大为什么有些 Agent 看起来“像个实习生”有些却像“成熟员工”模型的能力上限是由 OpenAI、Anthropic 这些公司决定而 Harness 由我们这些工程师来决定。如果拆开来看一个成熟的 Harness通常至少包含下面六个核心部分仅代表我个人的拆解2.2 Harness 的第一层上下文管理上面在 Context Engineering 的章节我们已经介绍过上下文管理了这里我们再从 Harness 的视角来看一看。在大量任务里大模型能力的差异并不在于它本身的 “智商” 而是来自它看到了什么信息。一个模型再强如果上下文是乱的、缺的、过载的它也很难稳定发挥。所以 Harness 的第一职责是让模型在正确的信息边界内思考。这包括几件事2.2.1 角色与目标定义模型需要先知道自己是谁、任务是什么、成功标准是什么。比如同样是“写一篇文章”你给它的上下文不同结果会完全不同是技术科普还是产品宣传面向小白还是面向工程师是追求传播性还是追求严谨性允许类比吗允许口语化吗这些都不是“文风细节”而是任务边界。Harness 要把这些边界明确地灌给模型。2.2.2 信息选择与裁剪上下文不是越多越好。大模型常见问题不是“知道太少”而是“信息太杂”。一个好的 Harness 会做两件事把相关信息挑出来把不相关的信息挡在外面这其实很像一个成熟工程师接需求不是把所有文档都丢给同事而是先整理好关键背景再让他进入问题。2.2.3 上下文的结构化组织同样的信息堆成一团和按层次组织效果天差地别。成熟 Harness 往往会把上下文分层比如这会显著降低模型“看漏重点”或“忘记约束”的概率。2.3 Harness 的第二层工具系统如果没有工具大模型本质上只能做“文本预测”。它可以解释、总结、推理、改写但不能真正接触世界。一旦接上工具事情就变了。模型可以搜网页获取最新信息、读文档理解长文本写代码并执行、调用数据库和业务 API操作浏览器点击页面、生成图片、编辑文件、发送消息这时模型不再只是“回答问题的人”而开始变成“做事情的人”。而 Harness 在这里的作用不是简单把工具挂上去而是解决三个更深的问题。2.3.1 给模型什么工具工具太少能力不够 工具太多模型容易乱用。所以工具设计不是“越全越好”而是要围绕任务场景来配置。写作 Agent 和安全分析 Agent应该拥有完全不同的工具集。2.3.2 什么时候调用工具这比“有什么工具”更重要。一个糟糕的 Agent 会出现两种极端本来不需要查非要查明明该查证却凭印象乱答好的 Harness 会引导模型判断这个问题是否需要外部信息当前上下文是否足够这一步更适合搜索、读取、计算还是直接作答2.3.3 如何把工具结果重新喂回模型工具不是一调用就结束真正关键的是返回结果如何被理解、筛选、吸收再进入下一步决策。例如搜索到了十条结果不应该原封不动塞回去。Harness 需要帮助模型提炼有效证据保持结果与任务的关联性。2.4 Harness 的第三层执行编排有了上下文和工具Agent 还不够成熟。因为它还需要一个能力知道下一步该干什么。这就是执行编排。很多失败的 Agent不是因为不会某一步而是因为不会“串起来”。它可能会搜索也会总结也会写代码但整个过程像想到哪做到哪最后输出一堆半成品。执行编排解决的就是这个问题。一个完整任务通常会被拆成这样的流程理解目标判断信息是否足够必要时获取外部信息基于结果继续分析生成输出检查输出是否满足要求不满足则修正或重试你会发现这已经很像人在工作时的思维链条了。区别在于人是靠经验和习惯完成这套流程Agent 则需要 Harness 明确地搭好轨道。所以一个成熟 Harness 往往不仅是 “能调工具”而是具有明确的步骤划分决策节点中间产物终止条件异常处理逻辑2.5 Harness 的第四层状态与记忆很多人对 Agent 的期待是“像人在持续工作”。而要做到这一点系统必须有状态。没有状态的系统每一轮都像失忆。它不知道自己刚做了什么也不知道哪些结论已经得到哪些问题还没解决。因此Harness 里很关键的一部分就是状态管理。它至少要回答三个问题问题 1当前任务进行到哪一步了比如已完成资料收集、正在撰写提纲已生成初稿待校验、某个工具调用失败待重试这会让系统避免反复横跳。问题 2哪些中间结果应该保留并不是所有信息都该塞进长期记忆。但对于一个复杂任务中间状态必须被保留否则系统很难连续推进。比如已确认的需求约束、重要结论已筛选过的资料、已完成的子任务问题 3哪些内容应该形成长期记忆这通常是用户偏好、稳定规则、长期项目背景等。例如你喜欢什么写作风格、某个项目的固定术语、常用输出模板等。所以记忆不是“存得越多越好”而是要区分临时状态会话记忆长期偏好这三者混在一起系统就会越来越乱。 分得清Agent 才会越来越像一个靠谱的协作者。2.6 Harness 的第五层评估与观测很多系统的问题不是 “生成不出来”而是 “生成完了却不知道好不好”。如果没有独立的评估与观测能力Agent 就容易停留在 “自我感觉良好” 的阶段。这一层通常包括输出验收是否满足任务要求环境验证是否真的可运行、可点击、可交互自动测试代码、接口、页面、文档格式等过程观测日志、指标、调用链、重试记录质量归因问题到底出在模型、上下文、工具还是流程设计2.7 Harness 的第六层约束、校验与失败恢复真正让系统从“能跑”走向“能上线”的往往不是主流程而是异常流程。因为真实环境里失败才是常态搜索结果不准、API 超时文档格式混乱、模型误解指令输出不符合约束、工具权限不足如果没有恢复机制Agent 每次出错都只能 “重新来一遍”。所以 Harness 的最后一层是控制系统稳定性的部分约束限制模型可做和不可做的事比如哪些工具能用、哪些场景必须查证、哪些内容涉及安全边界校验在输出前做检查比如是否回答了用户问题、是否遗漏关键要求、是否满足格式规范恢复当一步失败时分析错误原因、重试同一步、切换备用路径、回退到上一个稳定状态这部分最像传统软件工程里的“鲁棒性设计”。当然以上更多还是我基于原理层面对 Harness 做的一次拆解。真正把这个概念做深、做实、做成工程方法论的还是 OpenAI 和 Anthropic 这类一线公司。它们并不是停留在 “模型怎么调得更聪明” 这件事上而是在认真回答另一个更关键的问题如何把模型稳定的放进一个可持续运行、可反复交付、可长期演进的系统里。下面我们来看看目前业界对 Harness 这个概念最前沿的实践。三、Harness 的实践最近各大头部公司纷纷发布了 Harness 在各自产品上的工程实践我们来看几个最典型的案例OpenAIHarness engineering: leveraging Codex in an agent-first worldOpenAI 依靠一个仅有几名人类工程师的团队利用 Codex 智能体从零开始构建了一个超百万行代码的生产级应用。从业务逻辑、CI/CD 配置、可观测性堆栈到内部文档100% 由智能体编写耗时仅为人工开发的 1/10。AnthropicHarness design for long-running application developmentAnthropic 构建了一个长程自主编码系统。仅凭一句自然语言需求Claude 就能在无需人类干预的情况下连续运行数小时端到端地交付包含关卡编辑器、物理引擎的 2D 游戏制作工具、能在浏览器里跑起来的数字音频工作站。LangchainImproving Deep Agents with harness engineeringLangChain 在底层模型完全不变的情况下仅仅通过改造和迭代 Harness就把自家代码智能体在 Terminal Bench 2.0 榜单上的得分从 52.8 拔高到了 66.5直接从 Top 30 开外杀入 Top 5。同样是调用大模型 API为什么加上了精心设计的 Harness智能体就能产生如此夸张的质变下面我们深入看看他们的具体实践到底是什么。3.1 Anthropic 的实践3.1.1 两个典型问题Anthropic 在大量实践中总结了两个典型的失败模式第一个是上下文焦虑任务一长上下文窗口越来越满模型开始丢细节、丢重点甚至出现一种很有意思的现象当模型接近上下文窗口极限时它会 “焦虑” 地想赶紧收尾仿佛知道自己快装不下了。第二个是自评失真也就是模型自己做完之后再让它自己评判它往往会偏乐观尤其在设计、体验、产品完整度这类没有绝对二元答案的问题上这种偏差更明显。3.1.2 实践一上下文重置针对第一类问题很多系统在上下文长了之后会做 Context Compaction也就是把前面的历史总结一下压缩后继续跑。而 Anthropic 的思路是做 Context Reset 这两种模式的区别很明显Compaction同一个 Agent历史变短了但知道自己要干啥、 “心理状态” 还延续着Reset直接换一个干净上下文的新 Agent但是在两个模型交班时要把工作交接清楚。Anthropic 发现对于某些模型如 Claude Sonnet 4.5仅靠压缩并不能解决 “上下文焦虑” 的问题而真正的 Reset 才能给模型 “清空包袱、重新出发” 的效果。这个认识很像工程里的进程重启与状态恢复不是所有内存泄漏都能靠 “清理缓存” 解决有时候就得重启进程。3.1.3 实践二引入评估者Anthropic 说得很直白让模型评估自己产出的质量时它往往会 “自信地夸自己”即便结果在真人看来很一般。所以他们采用了一个很典型、也很有效的 Harness 手法把 “干活的人” 和 “打分的人” 拆开了。这就是它的核心思路generator evaluator后来又扩展成 planner generator evaluator。这个设计非常关键因为它背后其实是一个朴素但非常硬核的工程原则生产与验收必须分离。在 Anthropic 的实现里Planner把一句很短的需求扩展成完整产品规格Generator逐步实现Evaluator像 QA 一样用浏览器和工具真实操作应用检查功能、设计、代码质量等。尤其值得注意的是Evaluator 不是 “读代码打分”而是会实际操作页面、跑交互、看结果。这意味着它不是抽象审查而是 “带环境的验证”。一旦 Evaluator 能独立测试、独立质检并且能够保证公平性系统能实现 “生成 — 检查 — 修复” 的工程循环。3.2 OpenAI 的实践3.2.1 重新定义工程师这个团队从第一天就定了一条铁律人类不写代码只设计环境。 工程师的核心工作变成了三件事拆解意图把产品目标拆成 Agent 能理解的小块任务补全能力Agent 失败时不是再试一次而是问环境里缺了什么让它失败了然后把缺的东西补上建立反馈回路让 Agent 能看到自己工作的结果而不是盲人摸象用他们自己的话说当出了问题修复方案几乎从来不是更努力而是缺了什么结构性的能力。3.2.2 渐进式披露早期他们犯了一个经典错误写了一个巨大的 AGENTS.md 文件把所有规范、架构、约定一股脑塞进去。结果 Agent 反而更迷糊了 — 因为上下文窗口是稀缺资源塞太满等于什么都没说。他们最终的方案优雅得多AGENTS.md 只有 ~100 行充当目录页指向仓库里的详细文档。AGENTS.md ← 入口只有指针ARCHITECTURE.md ← 架构总览docs/├── design-docs/ ← 设计文档带验证状态├── exec-plans/ ← 执行计划活跃/已完成/技术债务├── product-specs/ ← 产品规格├── references/ ← 第三方参考├── QUALITY_SCORE.md ← 各模块质量评分└── SECURITY.md这种思路看着是不是很熟悉就是 Skill 的核心机制渐进式披露Agent 先看到目录需要深入时再去查对应文档。更关键的是他们用 CI 自动校验文档的新鲜度和交叉引用。还有一个专门的 “文档园丁” Agent定期扫描过时文档并提 PR 修复。知识管理本身也自动化了。3.2.3 让 Agent “看见” 整个应用产代码的速度上去之后瓶颈从 “写” 变成了 “验” — 人类根本验不过来。OpenAI 的解法是让 Agent 自己验。结果是什么单次 Codex 运行经常连续工作 6 小时以上通常是在人类睡觉的时候。Agent 自己跑应用、发现 bug、修复、验证、提 PR一条龙。3.2.4 把架构约束写进系统里人类 Code Review 的带宽跟不上 Agent 的产出速度每人每天 3.5 个 PR怎么保证代码质量他们的答案是把资深程序员的经验判断写成机器可以自动执行的检查规则。OpenAI 的做法很典型他们不是指望工程师反复提醒 “这一层不该依赖那一层”“这个模块不该这么写”而是把这些经验直接写进工程系统里。例如他们会把业务代码按固定分层组织比如TypesConfigRepoServiceRuntimeUI更重要的是这些规则不只是负责报错还会告诉 Agent 该怎么改。也就是说检查结果本身就带着修复提示可以直接回到上下文里推动下一轮修改。这样一来代码质量就不再主要靠人盯而是靠一套能反复执行的规则来守住。对人来说这些规则有时可能显得太细但对 Agent 来说它们非常重要。因为 Agent 一旦高频提交小问题如果不及时拦住很快就会扩散。除了拦截提交时的问题他们还会定期运行后台 Agent持续扫描代码库看看哪些地方开始偏离原则检查哪些模块正在变乱给不同区域打质量分找出值得重构的部分直接提交修复或重构 PR这样架构治理就不再只是人工审查而变成了一套持续运行的系统。它的价值不只是发现问题更是趁问题还小的时候就把它修掉。3.3 回过头看大家做的其实是同一件事如果把前面的案例重新放回 Harness 的框架里你会发现一件很有意思的事OpenAI、Anthropic 看起来路径不同做法也不一样但它们本质上都在补同一套东西模型到底应该看到什么模型到底能做什么模型下一步该做什么系统如何保持连续工作系统怎么知道自己做得对不对系统出错后怎么拉回来Anthropic 在解决的是长程任务里的两个核心问题上下文一长模型会乱只靠模型自评质量会失真。所以他们一边做 Context Reset一边引入独立 Evaluator本质上是在补强上下文管理、执行编排和评估与观测。OpenAI 更进一步他们关心的已经不是 “Agent 能不能写代码”而是怎样让 Agent 稳定地在真实工程环境里持续工作。所以他们做渐进式披露让 Agent 不被信息淹没给它浏览器、日志、指标和隔离环境让它能自己验证结果再把架构规则写进系统让质量控制从 “靠人盯” 变成 “靠规则守”。这对应的其实就是上下文管理、工具系统、评估与观测、约束与恢复。看到这里Harness 的意义其实就很清楚了把模型从一个会回答问题的概率机器变成一个能稳定完成任务的工程系统。这也是为什么同一个模型放进不同产品里最后表现会差这么多。决定差距的往往不只是模型参数本身而是工程团队有没有把这套 Harness 搭出来。最后回头看这三次演进会发现它们并不是谁取代了谁而是 AI 工程在不断面对更复杂任务时重心一层层向外扩展。当任务还停留在单轮生成时Prompt Engineering 很重要因为问题首先是 “有没有把任务讲清楚”当任务开始依赖外部知识、历史状态和运行时信息时Context Engineering 成为关键而当模型真正进入长链路、可执行、低容错的真实环境后Harness Engineering 几乎不可避免因为系统必须回答最后那个最难的问题模型不仅要会想还要能被稳定地组织、约束、验证和纠偏。所以Prompt 没有过时Context 也不是终点。它们都还在而且都很重要。只是越往后我们越会意识到真正决定 AI 产品上限的也许是模型但真正决定 AI 产品能否落地、能否稳定交付的往往是 Harness。换句话说未来 AI 工程的竞争未必只是 “谁接入了更强的模型”而更可能是谁更早建立起一套成熟的运行系统它知道该给模型看什么允许模型做什么要求模型如何验收结果又在失败时如何把它拉回正轨。从这个意义上说Harness Engineering 不是一个新瓶装旧酒的概念。它更像是一个信号AI 落地的核心挑战正在从 “让模型显得聪明”转向 “让模型在真实世界里稳定工作”。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】