https://www.youtube.com/watch?v=3DlXq9nsQOE

一、视频评价

这是一期内容质量不错的 AI 工程科普视频，有以下几个突出优点：

优点：

• 框架清晰，用"三次重心迁移"串联起整个叙事，逻辑自洽
• 以真实案例开篇（朋友的 agent 项目，成功率从 70% 提升到 95%），落地感强，不空谈
• 对 Anthropic 和 OpenAI 的实践案例（context reset、生产/验收分离、渐进式披露）有实质内容，不是泛泛而谈
• 用"新人客户拜访"的类比解释三层工程的关系，浅显易懂

不足之处：

• 部分内容对 Harness 六层结构的阐述略显仓促，每层只点到即止，深度有限
• 口播内容密集，缺少图示辅助，对非技术背景的观众理解门槛稍高
• "Harness Engineering"这个词本身目前并非行业标准术语，视频对它的溯源和引用来源交代得不够清晰

总体评分：值得观看，适合已经在做 agent 或对 AI 工程感兴趣的从业者，对纯小白略有难度。

---

二、内容总结

视频核心论点是：决定 AI agent 能否稳定落地的，往往不是模型本身，而是围绕模型搭建的那套运行系统——即 Harness（驾驭系统）。

AI 工程经历了三个阶段：

1. Prompt Engineering（怎么把任务说清楚）：解决的是表达问题，塑造模型的概率空间，但遇到信息缺失和长链路任务时失效。

2. Context Engineering（怎么把信息给对）：解决信息供给问题，涵盖检索、压缩、结构化组织、渐进披露（如 Agentskills）。但信息给对了，模型仍可能执行跑偏。

3. Harness Engineering（怎么让模型在真实执行中持续做对）：覆盖整套运行系统的工程化，是三者中边界最大的。

Harness 包含六层：上下文边界、工具系统、执行编排、记忆与状态、评估与观测、约束校验与失败恢复。

---

三、完整笔记

以下是整理后的结构化笔记：—

📌 核心概念

Agent = Model + Harness
Harness = Agent 减去 Model，即模型之外所有决定系统能否稳定交付的机制。

---

🔁 三次工程重心迁移

阶段	名称	核心问题	解决什么	局限
第一阶段	Prompt Engineering	模型有没有听懂你	表达方式、角色设定、格式控制	替代不了事实本身，信息缺失时失效
第二阶段	Context Engineering	信息有没有给对	检索、压缩、结构化供给	信息给对了，模型仍可能执行跑偏
第三阶段	Harness Engineering	模型有没有持续做对	整套运行系统的工程化	—

三者是包含关系，不是替代关系：Prompt ⊂ Context ⊂ Harness

---

🏗️ Harness 的六层结构

第一层：上下文边界管理

• 角色、目标、成功标准的清晰定义
• 信息裁剪与选择（相关 > 丰富）
• 结构化组织：固定规则 / 当前任务 / 运行状态 / 外部证据分层清晰

第二层：工具系统

• 给什么工具（太少能力不足，太多模型乱用）
• 何时调用（别乱查，该查时别跳过）
• 返回结果如何回流（提炼筛选，保持与任务相关性）

第三层：执行编排

• 任务有完整"轨道"：理解目标 → 补充信息 → 分析结果 → 生成输出 → 检查 → 修正
• 解决"会每一步但串不起来"的问题

第四层：记忆与状态管理

• 分清三类：当前任务状态 / 中间结论 / 长期记忆与用户偏好
• 三者混在一起，系统越来越乱

第五层：评估与观测

• 系统要知道自己做得好不好
• 包括：输出验收、环境验证、自动测试、日志指标、错误归因

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

• 失败在真实环境是常态（API 超时、格式混乱、模型误解任务）
• 必须包括：约束（哪些能做/不能做）、校验（输出前后检查）、恢复（重试/切路径/回滚）

---

🏢 真实公司实践案例

Anthropic 的实践：

1. Context Reset（上下文重置）

   • 问题：长任务中上下文越来越满，模型开始丢细节、着急收尾
   • 解法：不是压缩（不够），而是开一个全新的 agent 接手任务，传递当前状态
   • 类比：内存泄漏时不清缓存，直接重启进程恢复状态

2. 生产/验收分离

   • 问题：模型自评偏乐观（自己干活再自己打分）
   • 解法：Planner（需求 → 规格）/ Developer（逐步实现）/ Evaluator（像 QA 一样真实操作页面测试）
   • 工程原则：生产和验收必须分离，形成 生成→检查→修复→再检查 的闭环

OpenAI 的实践：

1. 人类工作的重新定义

   • 工程师不写代码，而是：① 把目标拆成 agent 能执行的小任务 ② 失败时问"环境缺了什么能力" ③ 建立反馈回路让 agent 看见自己的工作结果

2. 渐进式披露（AGENTS.MD 改造）

   • 错误做法：把所有规范全塞进一个大文件 → agent 更糊涂
   • 正确做法：主文件只保留核心索引，详细内容（设计文档、执行计划、安全规则）按需钻进子文档
   • 本质与 Agentskills 相同：不是一次性全给，而是按需暴露

3. 让 Agent 看见整个应用

   • Agent 可接浏览器截图、点击页面、查日志和监控指标
   • 每个任务在独立沙箱环境中运行
   • 结果：agent 不只是写完代码就算，而是跑起来看结果 → 发现 bug → 修 bug → 再验证

4. 规则即反馈

   • 资深工程师经验写成系统规则（模块怎么分层、什么情况拦截）
   • 规则不只报错，还把"怎么修"一起反馈给 agent 的下一轮上下文
   • 本质：一套可持续运行的自动质检系统

---

💡 核心结论

“真正决定能不能上线的可能是模型，但真正决定能不能稳定落地的，是 Harness。”

当模型任务从 简单问答 → 依赖外部信息 → 长链路自主执行，工程重心随之从 Prompt → Context → Harness 迁移。

AI 落地的核心挑战已经从"让模型看起来更聪明"转向"让模型在真实世界中稳定工作"。