让Agent跑得稳：AI工程第三次进化
Harness Engineering：决定 AI Agent 能否真正落地的隐藏系统
本报告由 AI 深度分析生成，基于视频完整字幕。
导读
「科特秘密花园」是国内少数能把 AI 工程概念讲得既有深度又接地气的中文频道。这期视频选在「Harness Engineering」这个词刚开始在 AI 圈流行的时间节点，系统性地梳理了 AI 工程范式的三次演进，并给出了成熟 Harness 的六层结构拆解，最后以 Anthropic 和 OpenAI 的真实工程实践作为落地印证。
花园老师开篇就用了一个亲历案例：朋友的 Agent 换过最好的模型、改了上百版提示词，任务成功率依然卡在 70% 以下。他介入后做的改动既不是换模型也不是改提示词——而是重新设计任务拆解方式、状态管理逻辑、关键步骤校验和失败恢复机制。结果：同样的模型、同样的提示词，成功率拉到 95% 以上。
这就是 Harness Engineering 要解决的核心问题：不是让模型更聪明，而是给模型建一套可以稳定交付的运行系统。
一句话核心论点：真正决定 AI Agent 能否落地的，从来不是模型本身，而是模型外面那套你看不见的基础设施。
核心观点速览
- AI 工程经历了三次范式迁移：Prompt Engineering → Context Engineering → Harness Engineering，每一次都是解决问题的边界向外扩一圈。
- Harness = Agent - Model：除了模型本身，几乎所有决定 Agent 能否稳定交付的东西都属于 Harness。
- 成熟 Harness 有六层：上下文管理、工具系统、执行编排、记忆与状态、评估与观测、约束校验与失败恢复。
- Anthropic 的关键突破：Context Reset（重启一个干净的新 Agent 交接工作）+ 生产验收必须分离（Planner/Generator/Evaluator 三角）。
- OpenAI 的关键突破：渐进式披露（agents.md 变目录页）+ 让 Agent 自己看到并测试整个应用 + 将资深工程师经验写成含修复指引的系统规则。
深度解析
一、三代 AI 工程的演进逻辑
花园老师用一个非常清晰的框架来解释这三个名词为什么不是炒概念的新词，而是真正对应了 AI 系统发展的三个阶段性问题：
| 阶段 | 核心问题 | 解决方案 |
|---|---|---|
| Prompt Engineering | 模型有没有听懂你在说什么？ | 语言的设计：角色设定、风格约束、少样本示例、输出格式 |
| Context Engineering | 模型有没有拿到足够且正确的信息？ | 信息的供给：RAG 检索、上下文裁剪、状态传递、工具结果整合 |
| Harness Engineering | 模型在真实执行中能不能持续做对？ | 系统的驾驭：编排、监控、校验、纠偏、失败恢复 |
为什么是这个顺序？
提示词工程解决的是「表达问题」。大模型本质上是一个对上下文极度敏感的概率生成系统——你给它什么身份，它就沿着那个身份回答；你给什么样例，它就沿着那个范式补全。所以早期靠「把话说明白」确实有效。
但提示词很快遇到天花板：当你让模型分析一份内部文档、按照复杂规范写代码、在多个工具之间完成长链路任务，提示词写得再漂亮也替代不了事实本身。于是进入了第二阶段——上下文工程，核心变成「把正确的信息在正确的时机送进去」。
然后上下文工程也不够了。就算信息给对了，模型也不一定能稳定执行：计划做得很好，但执行跑偏；调了工具但理解错了反馈；在长链路里慢慢偏行，系统却没发现。这时候需要的是第三件事：不只管输入侧，还要管运行时的全程。
这三者是包含关系，不是替代关系。Prompt 是对指令的工程化，Context 是对输入环境的工程化，Harness 是对整个运行系统的工程化。边界一层比一层大。
二、Harness 的六层结构——一个成熟 Agent 系统的完整拆解
花园老师给出了一个公式：Agent = Model + Harness，反过来 Harness = Agent - Model。也就是说，在一个 Agent 系统里，除了模型本身以外，几乎所有能决定它能不能稳定交付的东西都属于 Harness。
具体拆开来，他将其分为六层：
第一层：上下文管理
这一层重新站在 Harness 的视角看「信息」：模型能不能稳定发挥，很多时候不只取决于它聪不聪明，而取决于它看到了什么。
三件核心事：
- 角色、目标与定义：模型要知道自己是谁、任务是什么、成功的标准是什么
- 信息裁剪与选择：上下文不是越多越好，而是越相关越好
- 结构化组织：固定规则放哪、当前任务放哪、运行状态放哪、外部证据放哪——分层清楚，模型才不会漏重点、忘约束、甚至「自我污染」
关键洞察：上下文窗口是一种稀缺资源。信息一旦乱掉，注意力就会涣散，效果往往比信息少时更差。
第二层：工具系统
没有工具，大模型本质上只是一个文本预测器——会解释会总结，但接触不到真实世界。连上工具之后，Harness 要解决三个问题：
- 给它什么工具：工具太少能力不够，工具太多模型乱用
- 什么时候调用：不需要查的时候别乱查，该查证的时候别硬答
- 工具结果怎么回注模型：搜索返回的几十条结果不应该原封不动塞回去，而是要提炼筛选，保持与任务的相关性
第三层：执行编排
这一层解决的核心问题是「模型下一步该做什么」。
很多 Agent 的问题不是某一步不会，而是不会把所有步骤串起来：会搜索、会总结、会写代码，但整个过程想到哪做到哪，最后交付一堆半成品。
一个完整任务的执行轨道应该是：
理解目标
→ 判断信息够不够？不够 → 补充信息
→ 生成输出
→ 检查输出
→ 不满足要求 → 修正或重试
→ 满足要求 → 交付
这个闭环思路和人类工作方式已经非常接近。区别在于：人靠经验，Agent 靠 Harness 这套机制。
第四层：记忆与状态
没有状态的 Agent，每一轮都像失忆了一样——不知道自己刚做了什么，不知道哪些结论已经确认，哪些问题还没解决。
Harness 必须至少管理清楚三类东西，而且不能混在一起：
| 类别 | 内容 |
|---|---|
| 当前任务状态 | 进行到第几步、当前目标、待解决问题 |
| 会话中间结果 | 本次对话产生的中间产物和已确认结论 |
| 长期记忆与用户偏好 | 跨对话的知识、用户习惯、历史决策 |
只有这三层分清楚，Agent 才会像一个稳定的协作者，而不是一个每次都要重新认识自己的失忆患者。
第五层：评估与观测
这是最容易被团队忽视的一层。很多系统不是生成不出来，而是生成完了之后根本不知道自己做得好不好。
没有独立的评估与观测能力，Agent 会长期停留在「自我感觉良好」的状态。这一层通常包括：
- 输出验收与环境验证
- 自动化测试
- 日志与指标监控
- 错误归因分析
系统不只要会做，还要知道自己有没有真的做对。
第六层：约束、校验、失败与恢复
这一层往往才是真正决定系统能不能上线的关键。
在真实环境里，失败不是例外，而是常态——搜索不准、API 超时、文档格式混乱、模型误解了任务。如果没有恢复机制，Agent 每次出错就只能从头再来。
一个成熟的 Harness 必须包括三件事：
- 约束：哪些事能做，哪些不能做
- 校验：输出之前和之后分别怎么检查
- 恢复：失败后怎么从断点切入，或者回滚到稳定状态
三、一线公司的真实实践——Harness 不是方法论，是已在生产跑的工程体系
这部分是视频最有价值的地方。花园老师引用的三个数据点先把认知锚定好：
- Lunchen：底层模型完全不变，只迭代 Harness，Agent 基准测试排名从第 30 开外直接杀进前 5
- OpenAI：几名人类工程师 + Agent，从零构建超百万行代码的生产级应用，100% 代码由 Agent 编写，耗时仅纯人工的十分之一
- Anthropic：一句自然语言需求，Agent 可以无需人类干预连续工作数小时，交付完整游戏、完整数字音频工作站
这些数字不是演示性的 demo，而是已在生产环境运行的结果。关键是背后的工程设计。
Anthropic 的两个核心突破
突破一：Context Reset——不是压缩，而是重启
长程任务里有一个花园老师把它叫做「上下文焦虑」的问题：时间一长，上下文越来越满，模型开始丢细节、丢重点，甚至出现一种有意思的现象——它好像知道自己快装不下了，于是开始着急收尾。
常规解法是 Context Compression（把历史上下文压缩一下再继续跑）。Anthropic 发现这对某些模型来说仍然不够，因为压缩只是变短了，那种负担感并没有真正消失。
他们做了一件更激进的事：Context Reset——不在原上下文里继续压，而是换一个干净的新 Agent，把工作交接给它继续。
花园老师用了一个绝妙的类比：就像工程里遇到内存泄漏，不是继续清缓存，而是直接重启整个进程再恢复状态。这是一种非常典型的 Harness 设计思路——从系统层面解决模型层面无法根治的问题。
突破二：生产验收必须分离
Anthropic 发现，让模型自己干活再让自己打分，结果往往偏乐观——尤其是在设计体验、产品完整度这类没有标准答案的问题上。
解法是把干活的人和验收的人彻底分开，形成三角结构：
| 角色 | 职责 |
|---|---|
| Planner | 把模糊需求展开成完整规格 |
| Generator | 逐步实现 |
| Evaluator | 像 QA 一样真实测试——不只看代码，而是真实操作页面、检查交互、验证实际结果 |
关键点在于 Evaluator：它不是抽象的审查，而是在具体环境里的实际验证。这背后是一个非常清晰的工程原则：生产验收必须分离，只要评估者足够独立，系统就能形成真正有效的「生成→检查→修复→再检查」循环。
OpenAI 的三个关键实践
实践一：工程师角色的重新定义
OpenAI 最有洞见的思路是：在 Agent 时代，人类工程师不需要写一行代码，而是负责设计环境。具体变成三件事：
- 把产品目标拆解成 Agent 能理解的小任务
- Agent 失败时，不是让它更努力，而是问环境里缺了什么能力
- 建立反馈链路，让 Agent 能真正看到自己的工作结果
花园老师对这段话做了很重要的延伸：当 Agent 出了问题，修复方案几乎从来不是「要更努力一点」，而是确认它缺了什么结构性能力。这是典型的 Harness 思维——把问题从模型层转移到系统层。
实践二：渐进式披露——agents.md 变目录页
OpenAI 早期犯过一个很多团队都会犯的错误：写了一个巨大的 agents.md，把所有规范、框架、约定全部塞进去。结果 Agent 更糊涂了——因为上下文窗口是稀缺资源，塞得太满等于什么都没说。
后来的解法：把 agents.md 变成目录页，只保留核心索引，详细内容拆到架构文档、设计文档、执行计划、质量评分、安全规则等子文档里。Agent 先看目录，需要的时候再钻进去。
这和前面提到的 Skill 渐进式披露是同一个思路：不是一次性全给，而是按需暴露。
实践三：让 Agent 看见并测试整个应用
随着 Agent 代码产出速度越来越快，验收速度成了瓶颈——人类根本验不过来。OpenAI 的解法是让 Agent 自己验：
- 接浏览器：能截图、能点页面、能模拟用户真实操作
- 接日志系统和指标系统：能查 log、查监控
- 每个任务在独立隔离的环境里跑
结果：Agent 不再是「写完代码就说完了」，而是真正跑起来看结果、发现 bug、修 bug、再验证。
OpenAI 还做了一件值得单独记录的事：把资深工程师的经验直接写成系统规则——规则不只是负责报错，而是把「怎么修」也一起返回给 Agent，进入下一轮上下文。这已经不是传统的代码规范，而是一套可持续运行的自动治理系统。
四、最关键的工程洞见——问题在模型外面，不在模型里面
视频最后花园老师做了一个总结，值得单独摘出来：
真正决定上限的可能是模型，但真正决定能不能落地、能不能稳定交付的，是 Harness。
这句话背后有一个深刻的现实认知：AI 落地的核心挑战，正在从「让模型看起来更聪明」转向「让模型在真实世界里稳定工作」。
这解释了为什么同样的模型在不同产品里表现差距可以如此巨大——因为大家比的早就不是模型了，而是 Harness 的设计水平。
对于正在做 Agent 的团队，这意味着一个优先级的重新排序：在把大量时间投入调提示词和换模型之前，先问自己：我的任务拆解对不对？我的状态管理清楚吗？我有没有独立的评估机制？我的失败恢复设计到位了吗？
行动启示
如果你正在做 Agent 开发，可以用这六层来做一次现有系统的快速诊断：
| 层 | 自查问题 |
|---|---|
| 上下文管理 | 模型知道自己是谁、任务是什么、成功标准是什么吗？信息是按相关性过滤的，还是全量塞进去的？ |
| 工具系统 | 工具数量是否合理？工具返回结果有没有经过整理再回注？ |
| 执行编排 | 有没有一个明确的任务执行循环（生成→检查→修正→重试）？ |
| 记忆与状态 | 任务状态、中间结果、长期记忆三类有没有分清楚？ |
| 评估与观测 | 有没有独立于生成流程的评估机制？有没有可查询的日志和指标？ |
| 约束与恢复 | 失败后系统能不能从断点恢复，而不是从头再来？ |
金句收录
"那个时候改动最大的地方，反而不是模型，也不是提示词。我的改进点在于任务是怎么拆的、状态是怎么管的、关键步骤要怎么校验、失败之后要怎么恢复。"——花园老师
"Prompt 是对指令的工程化，Context 是对输入环境的工程化，Harness 是对整个运行系统的工程化。它们的边界是一层比一层大的。"
"当 Agent 出了问题，修复方案几乎从来不是要更努力一点，而是确认它缺了什么结构性的能力。"
"上下文窗口是一种稀缺资源。塞的太满，其实等于什么都没说。"
"生产验收必须分离。只要评估者足够独立，系统就能形成一个真正有效的循环。"
"AI 落地的核心挑战，正在从让模型看起来更聪明，转向让模型在真实世界里稳定工作。"
时间线索引
| 时间 | 内容 |
|---|---|
| [00:00] | 开场：Harness Engineering 是什么，为什么重要 |
| [00:53] | 亲历案例：改 Harness 把 Agent 成功率从 70% 拉到 95% |
| [01:57] | AI 工程三代演进框架概述 |
| [02:15] | 第一代：Prompt Engineering 的原理与边界 |
| [03:28] | 提示词工程的局限性 |
| [03:47] | 第二代：Context Engineering 的出现背景 |
| [05:11] | Context 的完整定义（不只是背景资料） |
| [05:37] | RAG 和 Agent Skills 作为上下文工程的典型实践 |
| [06:29] | 第三代：Harness Engineering 的出发点 |
| [07:22] | Harness 的字面含义与本质定义 |
| [08:07] | 三代工程的经典类比（派新人去客户拜访） |
| [08:37] | Agent = Model + Harness 公式 |
| [09:02] | Harness 六层结构：第一层上下文管理 |
| [09:57] | 第二层：工具系统 |
| [10:22] | 第三层：执行编排 |
| [10:52] | 第四层：记忆与状态 |
| [11:15] | 第五层：评估与观测 |
| [11:38] | 第六层：约束、校验、失败与恢复 |
| [12:15] | 一线公司真实实践 |
| [13:00] | Anthropic：Context Reset + Planner/Generator/Evaluator 三角 |
| [14:38] | OpenAI：工程师角色重定义 + 渐进式披露 |
| [16:11] | OpenAI：让 Agent 看见并测试整个应用 |
| [16:52] | OpenAI：含修复指引的系统规则 |
| [17:19] | 总结：三代工程的边界与未来 |
评论
还没有评论，来第一个留言吧 ✨