--- title: 'Harness为王的能动工程大师课' video_id: zbmuiaPuiNM url: https://youtu.be/zbmuiaPuiNM title_en: "Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good)" channel: Cole Medin published: 2026-06-25 duration: "21:55" topics: [Agent 工程] noted: 2026-07-05 value: A views: '11.3万' --- [![封面](https://i.ytimg.com/vi/zbmuiaPuiNM/maxresdefault.jpg)](https://youtu.be/zbmuiaPuiNM) > Cole Medin · 21:55 · 发布 2026-06-25 · 11.3万次观看(截至抓取) · [观看原视频](https://youtu.be/zbmuiaPuiNM) · 全文中译 > 🔥 观众最高回放 [10:58](https://youtu.be/zbmuiaPuiNM?t=658) — 演示语义缓存工具 BetterDB 命中缓存与 MCP 联动 ## 主旨 Cole 把 Google 官方发布的 51 页 Agentic Engineering 长文提炼成一套心智模型:AI 驱动的 SDLC 里真正被加速的只有"写代码"这一段,前后两头的规格质量和验证仍是瓶颈;而决定这一段能加速多少的,不是模型本身(只占 10%),而是你围绕模型搭建的 harness(规则、技能、guardrails、编排,占 90%)。 ## 核心论点 1. **AI 编码助手"10x 工程师产出"却没能"10x 公司产出"**,因为软件工程远不止写代码,前期需求收集、后期验证审阅依然要人力驱动,implementation 只是被大幅压缩的中间一段。 2. **模型只是系统的一小部分**,真正拉开差距的是你搭的 harness——上下文管理、workflow、guardrails 这些你能设计和控制的东西,模型是你无法控制的黑盒。 3. **Agentic engineering 不是道德优越感,而是场景选择题**,proof of concept 或一次性验证时 vibe coding 反而更划算,不是所有任务都值得上全套 spec+eval+CI 门禁。 4. **系统本身应该被当成可版本化的工程资产来迭代**,每次 AI 编码助手出问题时,与其只改代码,不如反过来问"我的规则/workflow 该怎么改",让 harness 越用越可靠。 ## 知识点详解 ### 规格质量成为新瓶颈,implementation 不再是 [02:27](https://youtu.be/zbmuiaPuiNM?t=147) 译 传统 SDLC 里,需求收集、设计各占几天,implementation 常常是工程师花几周写代码的大头,最后再花一周测试部署。 AI 驱动的 SDLC 里,implementation 从"1 到 3 周"压缩到"几分钟到几小时",但前端的需求收集和后端的人工验证并没有变快多少——因为这两段仍然离不开人。 所以"specification quality is the new bottleneck"(规格质量是新瓶颈)。 这也解释了一个反直觉现象:为什么 AI 编码助手让单个工程师产出翻十倍,公司整体产出却没跟着翻十倍——软件工程远不止写代码这一段。 ### AI 编码是一个光谱,不是二元开关 [03:58](https://youtu.be/zbmuiaPuiNM?t=238) 译 Google 把 AI 编码分成三档:vibe coding(随手一个 prompt,验证方式是"看起来能跑就行")、structured AI-assisted(更详细的 prompt + 人工抽查)、Agentic Engineering(完整的 spec、自动化 eval、CI 门禁,agent 能在你介入前自己发现并修正问题)。 三档在"intent specification 详细程度""verification 深度""risk profile"三个维度上依次升级。 关键是:这不是让你从低档"进化"到高档就一劳永逸,而是按任务选档——proof of concept 或 MVP 用 vibe coding 完全够用,agentic engineering 只是"大多数时候"更值得投入的那一档。 ### Harness 占 90%,模型只占 10% [07:13](https://youtu.be/zbmuiaPuiNM?t=433) 译 如果 agentic engineering 是大多数场景该走的路,那真正决定效果的是 [[Harness]]——你为 AI 编码助手搭的上下文、规则、工具和 workflow 的集合,也就是"你能控制的那一层"。 Google 的图里把大语言模型放在中间,标注只占系统的 10%;外圈的 instructions、MCP servers、guardrails、hooks 是第一层,再外一层是测试基础设施(eval 让 agent 自我迭代),最外层是给生产环境用的可观测性和扩展能力。 这个 10%/90% 的说法与 Anthropic 自己那篇 Claude Code 最佳实践文章("harness matters as much as the model")一脉相承,Google 更进一步说 harness 比模型更重要。 Terminal Bench 2.0 等基准测试也印证了这点:LangChain 只靠给同一个模型加一层规则和 workflow,就能把排名从 30 名开外冲进前五,提升 13.7 个百分点——相当于把 Sonnet 调教到 Opus 的水平。 ### 系统进化心智:把每次纠错都写回 harness [13:47](https://youtu.be/zbmuiaPuiNM?t=827) 译 Agentic engineering 的具体流程是:先定好 spec、context、requirement,交给一个 planning agent 出计划,再把这份计划当作 artifact 传给独立的 coding agent 去实现、测试、验证——之所以要拆成两个独立 session,是因为 planning agent 会在过程中积累大量上下文和偏见,混在一个 session 里容易造成 [[Context Rot|上下文腐化]]。 人依然要在最后审阅这个 pull request,不审阅就等于退化成了 vibe coding。 更关键的是 Cole 提炼的"系统进化心智":每当 AI 编码助手需要你额外介入纠错,不要只是把这个 bug 修完就完事,而要回头问 agent"我们的 workflow、规则该怎么改才能让这类问题以后更少出现",把这次纠错沉淀成 harness 本身的迭代,让整个流程像代码一样版本化演进。 ### 静态上下文与动态上下文,一个通才 agent 就够了 [17:14](https://youtu.be/zbmuiaPuiNM?t=1034) 译 Context 是使用 AI 编码助手最贵的资源,填多了会让模型和人一样"信息过载"(上下文腐化)。 [[静态上下文与动态上下文|Static context]](规则、system prompt)每次会话都保证加载,可靠但一开始就占用上下文窗口;[[静态上下文与动态上下文|dynamic context]](skills、特定代码区域的约定)只在需要时按需加载,省资源但风险是 agent 可能不会在该调用的时候主动去取。 Google 原文的表述是:skills 让 agent 保持一个"轻量级通才",通过 progressive disclosure(渐进式披露)按需切换成专家角色。 这也是行业正在从"堆一堆专精 sub-agent"转向"一个通才 agent + 按需加载的 skills"的底层原因——你真的只需要一个 agent 来驱动大部分 agentic engineering 工作。 ### 指挥者与编排者两种角色,以及 token 经济学 [21:18](https://youtu.be/zbmuiaPuiNM?t=1278) 译 Google 还提出工程师在两种模式间切换:conductor(逐文件精细操控,像早期 tab-complete 时代)和 orchestrator(review 整段代码库级别的产出,多个 agent 并行跑)。 Cole 对此有保留意见——他认为一旦 harness 足够可靠,你会"毕业"到只做 orchestrator,而不是持续在两者间摇摆;但他也承认深度调试、初期探索这类场景确实需要你重新变回 conductor。 最后落到 token 经济学:vibe coding 前期投入(CapEx)低,因为不用花时间搭 harness,但后期运营开销(OpEx)高,会在反复试错里烧掉大量 token;agentic engineering 前期投入高(要先搭好 spec 和 guardrails),但一旦搭好,后续复用成本极低——最终 agentic engineering 比 vibe coding 可靠且便宜 3 到 10 倍。 ## 可执行步骤 - [ ] 盘点当前项目的 harness 清单:列出现有的 rules、hooks、skills、MCP、subagents,标出哪些是每次都加载的 static context、哪些是按需触发的 dynamic context,检查有没有本可以瘦身进 dynamic 的冗余 static 内容。 - [ ] 下次 AI 编码助手需要你介入纠错时,不要只改代码就结束——追问一句"这次哪里出了问题,我们的规则或 workflow 该怎么改",把这次纠错写回 harness。 - [ ] 把"规划"和"实现"拆成两个独立会话:先用一个 agent 产出计划(当作 artifact),再另开一个干净会话喂给执行 agent,避免规划阶段积累的上下文和偏见污染实现阶段。 - [ ] 接手新任务前先做一次"光谱定级":判断这次是一次性验证可以走 vibe coding,还是需要走查的 structured AI-assisted,还是值得上完整 spec + eval + CI 门禁的 agentic engineering,再决定投入多少 harness。 ## 关联 - 印证:[[2026-06-09-Skill 按需加载 vs agents.md 每轮注入|Skill 按需加载 vs agents.md 每轮注入]] 用 944→53 token 实测把「静态上下文与动态上下文」权衡具象成 skill vs agents.md 的分工。 - 印证:[[2026-07-01-AI Agent是新一代SaaS：从一份工作到产品化的完整剧本|AI Agent是新一代SaaS]] 把「完整 spec + 自动化 eval」的上线门槛翻译成商业侧的「7 问 spec + 50 条 eval 集」。 - 印证:Claude Code 完全解读 从新手交付视角复现了本笔记的两个判断——"规格质量决定产出"(它用 ask user question 工具把 PRD 从粗逼细)、[[Context Rot]] 上下文腐化(它给出 Opus 20 万 token、过半即劣化的具体阈值)。 - 印证:Claude Code 六个层级 把本笔记的 [[Harness]]、[[Context Rot]]、[[静态上下文与动态上下文]] 从团队级工程流程收窄成面向个人的"六级技能树",并补 ETH Zurich 研究量化 CLAUDE.md 滥用的成本(收益微弱、推理成本 +20%)。 - 进阶(长课):Claude Code 高阶课(3h) 是同一 [[Harness]]/Agentic Engineering 世界观的 29 章实操展开,深挖 auto-research、多 agent 共识、网络自动化、模型分散与安全,本笔记的原则在其中逐条落地。 - 落地(长课):Agentic 工作流课(5.7h) 把本笔记的 [[Harness]] 思想具体化为 DOE(Directive/Orchestration/Execution)三层框架,并把 [[Context Rot]] 上下文腐化落到"不能什么都用 MCP、要压信息密度"的实操判断;是同源世界观在业务自动化交付方向的展开。 - 印证(agent 友好的基础设施与组件库):[[2026-06-19-2026年最佳AI自动化技术栈学习指南]] 给出 Agentic Engineering 原则的产品落地形态——Railway MCP server 让 coding agent 直接管部署(查日志、扩容、回滚),shadcn/ui 组件源码进项目让 agent 直接改组件(加字段、调圆角、换主题)。印证本片"agent 不只改代码、还能改部署"在产品选型层不是抽象口号,而是 2026 年工具链的具体设计取向(选 agent 改得动的工具,比选功能最全的工具更重要)。 - 印证:Greg·Skill 工作原理 用白板机制图解独立复现本笔记三个概念:上下文六部分组装(工具调用靠 [[Harness]])、agent.md(static)vs skill(dynamic)即 [[静态上下文与动态上下文]] 取舍、以及"越接近塞满越变笨"的 [[Context Rot]](其阈值约 70%,比六个层级的 50-60% 更宽松)。 ## 术语 - SDLC(Software Development Life Cycle,软件开发生命周期,从需求到部署维护的全流程) - CapEx/OpEx(资本支出/运营支出,这里指前期搭建 harness 的投入 vs 后期跑 agent 反复迭代烧的 token) - MVP(最小可行产品) - Progressive disclosure(渐进式披露,agent 按需加载 skill 而非把所有专精知识塞进 system prompt) - LLM judge(用另一个模型对 agent 产出做自动化评审) ## 金句 > "The model is what we don't control. The harness is what we get to create for our specific code bases, architectures, and tech stacks." → 模型是黑盒,harness 才是你真正能设计、能优化、能沉淀的资产,这也是本视频反复强调的投入方向。 ## 立场与利益 视频里 04:29 附近插入了一段独立赞助广告(Better DB,一个缓存/可观测性平台),与 Google 原文内容无关,是纯粹的贴片推广,可整体跳过。 核心框架部分来自 Google 官方文章,作为大厂发布的"最佳实践",本身带有为 Google 自家 agentic 工具栈背书的动机,但 Cole 引用的关键主张(harness 占 90%、static/dynamic context 权衡、Terminal Bench 2.0 数据)都能在独立信源(Anthropic 的 Claude Code 最佳实践文章、LangChain 的基准测试)里找到印证,不依赖某个特定厂商工具才能成立,可视为行业共识而非厂商话术。 Cole 本人在"conductor vs orchestrator"这一点上明确表达了与 Google 不同的看法,说明他并非无条件转述原文。 ## 价值定位 适合想建立 agentic engineering 整体心智模型的人——这是本主题簇的**纲领性母文档**,不是某个功能的操作教程。解决的是"AI 编码到底该投入到哪一层"这个方向性问题:瓶颈在规格与验证两头、真正可控的是 harness(占 90%)、按任务选档而非盲目上全套。 以认知框架为主,但落地抓手清晰:盘点现有 harness 清单并区分 static/dynamic context、每次纠错追问"规则该怎么改"写回 harness、planning 与 coding 拆独立会话、接手任务前先做"光谱定级"——四条都能直接套到自己的项目上。 这是 [[2026-03-08-Claude Code 六个层级|六个层级]](把框架收窄成个人技能树)、[[2026-06-15-Omnigent编排多个AI编码助手的元Harness|Omnigent]](把 harness 再包一层编排)、[[2026-01-19-Claude Code 完全解读|完全解读]](新手交付视角)多篇的共同上游。本片独有的是最完整的 [[Harness]] 框架论述、Google 51 页原文提炼,以及 token 经济学结论(agentic engineering 比 vibe coding 可靠且便宜 3–10 倍)。想先建立全局观,应从这篇入手。 ## 自检问题 1. 为什么 AI 编码助手让单个工程师产出翻十倍,公司整体产出却没跟着翻十倍? **答案**:因为 implementation 只是 SDLC 里被大幅压缩的中间一段,前期需求收集和后期人工验证仍是瓶颈,见"核心论点"第1条和"知识点详解"第1节。 2. Google 说模型只占系统的 10%,另外 90% 具体指什么? **答案**:指 harness——你能控制的那一层,包括 instructions、MCP servers、guardrails、hooks、测试基础设施和可观测性,见"知识点详解"第3节。 3. 为什么要把 planning agent 和 coding agent 拆成两个独立会话,而不是一个 agent 从头做到尾? **答案**:planning agent 会积累大量上下文和偏见,混在一个 session 里容易造成上下文腐化;把计划当作 artifact 传给独立的 coding agent 能避免这种污染,见"知识点详解"第4节。 4. static context 和 dynamic context 各自的权衡是什么? **答案**:static context(规则/system prompt)每次都保证加载,可靠但占用上下文窗口;dynamic context(skills/约定)按需加载,省资源但 agent 可能不会在该调用时主动去取,见"知识点详解"第5节。 5. 为什么长期来看 agentic engineering 比 vibe coding 更便宜,尽管前期投入更高? **答案**:vibe coding 前期投入低但靠反复试错烧掉大量 token,运营开销高;agentic engineering 前期要搭 harness 投入高,但搭好之后复用成本极低,长期减少 3 到 10 倍 token 消耗,见"知识点详解"第6节。 > [!quote] 💬 热门评论 top-12 主 + 8 回(抓取 2026-07-07) > > [3] **@jjvp1249**:为了构建更好的 orchestrator 栈，你必须扮演 conductor，去发现实际的 orchestration 栈在哪些方面失败了。 👍 3 > [4] **@umarzaii9258**:Conductor 角色极其重要，因为 agent 编写的代码可能会产生额外的内存开销，这些开销会随时间累积并导致额外费用。在安全性和扩展性方面，你无法忽视这个角色，因为你想要的可能是不同场景下 20 个最佳实践中的特定一个。在权衡取舍时，除非你明确说明在哪些层采用了哪种权衡，以及为每一层设置了护栏，这样它们才能精确地编码。 👍 1 > [5] **@BrokenRecord-l4n**:我一直这么说。我们最好构建带有合适 harness 的专用 agent，而不是纠结于使用哪个模型。 👍 1 > [8] **@johnsmith12421**:我刚刚开始以这种方式工作，边进行边整合技能并更新。我长期以来一直抵制使用技能，但它们确实是游戏规则改变者。廉价且易于调用的“高价值”上下文块。 👍 2 > [11] **@richardsantomauro6947**:这是一个危险的过度简化。即使是主要考虑因素也被忽略和遗漏了——那些困难的部分。1. 需求不是架构 2. CICD 流水线在时间上很昂贵，每个消耗 token 的阶段也是如此 3. 任何在紧密循环中未被捕获的问题如果逃逸，代价可能会高出几个数量级。解决方案架构本身必须考虑 AI——就像我们不得不为离岸团队所做的那样：工人价格是 1/5，但治理和外循环——一如既往——代价高出几个数量级。我不是说它行不通——但它不像这里或论文中描述的那样工作——前提是 agent 抵抗的架构，而 harness 无法掩盖这一点。例如，你不需要一个流水线——你需要每个组件原型的一个流水线切片，在指定的抽象层内。如果你不预先做契约，或者没有可切分的架构，无论你如何 harness，你都会得到垃圾。 👍 4 >   ↪ **@ColeMedin(UP)**:嗯，是的，我感谢你的反馈，这有道理 👍 1 > ——其他 6 条:感谢/夸赞([2]@DavidFregoli、[6]@andreasnordmandandersen8211、[7]@rujmah、[9]@dj1480、[10]@ea4all-genai-exploration、[12]@nascimendel);1 条 spam 已略 >
英文原文[1] @ColeMedin(UP):The Dynamous Agentic Coding Course is FULLY released - learn how to build reliable and repeatable systems for AI coding: https://dynamous.ai/agentic-coding-course 👍 12
  ↪ @dropbear9785:I believe the advice to bounce between orchestrator and conductor modes may not be relevant for your cases, however, agents and harnesses are not universally great or even compliant. For those cases, conducting takes a surprising amount of effort to steer the agents back ont rack...and making them stay there. Otherwords, I find the advice to be more valuable than you did, but ultimately YMMV. Thanks for the video...I like the doc. 👍 2
[2] @DavidFregoli:I'll tell my agent to read it 👍 21
  ↪ @André-h1j3l:same 👍 1
  ↪ @ColeMedin(UP):Fair enough! Related to the video I have coming out next ;) 👍 1
[3] @jjvp1249:In order to build a greater orchestrator stack, you must play the conductor, to discover what the actual orchestration stack failed at. 👍 3
[4] @umarzaii9258:Conductor role is extremely important because agents can write codes that cause those extra memory overhead that piles up over time and cause extra expenses. When it comes to security and scaling, you won't be able to ignore this role because what you want might be specific out of 20 best practices of different scenarios. When it comes to trade-offs, unless you specifically mentioned which trade-off ur taking for which layers, along with guardrails for each layers so they can code with pinpoint precision. 👍 1
[5] @BrokenRecord-l4n:Been saying this. We're better off building specialized agents with proper harnesses than obsessing over which model you use. 👍 1
[6] @andreasnordmandandersen8211:Great content, Cole. Thanks for taking the time to make videos like this! 👍 3
  ↪ @ColeMedin(UP):You bet, I appreciate it!
[7] @rujmah:Awesome! Thanks for the really useful overview of the document and your commentary on it. Would love to hear more about developing a harness. The nuances for each industry, business, etc. Thanks again! 👍 1
[8] @johnsmith12421:I have just started working in exactly this way, incorporating skills and updating as I go. I resisted using skills for a long time but they are indeed a game changer. Cheap easily invokable "high value" context blobs 👍 2
[9] @dj1480:That's a fantastic distillation of a ton of ideas. You are a pro, sir! 👍 4
  ↪ @ColeMedin(UP):Thank you! :D
[10] @ea4all-genai-exploration:Hi Cole, what a masterclass. I joined the Google 5days that was great but your summary is an even better complement. Thanks. 👍 6
  ↪ @ColeMedin(UP):That's great to hear, glad you found the summary helpful!
[11] @richardsantomauro6947:Tgis is a dangerous oversimplification. Even the primary considerations have been glossed over and left out - the hard parts. 1. Requirements are not architecture 2. CICD pipelines are EXPENSIVE in time as is every token consuming stage 3. Anything not caught in the tight loop can cost orders of magnitude more if it escapes. The solution architecture itself must take AI into account - just like we had to do for offshore teams: The workers are 1/5 price but the governance and outer loop - as always - is orders of magnitude more. I’m not saying it can’t work - but it doesn’t work as described here or in the paper - the PREREQUISITE is an agent resistant architecture and the harness cannot paint over that. For example, You dont need one pipeline - you need one pipeline slice per component archetype - within a specified abstraction. And if you dont do the contracts up front or have a sliceable architecture no matter how much you harness it you get slop. 👍 4
  ↪ @ColeMedin(UP):Hmmm yeah I appreciate your feedback, this makes sense 👍 1
[12] @nascimendel:Thanks for the vídeo! What’s the output of my Planning agent? A prompt for me to use on my build agent? 👍 1
  ↪ @ColeMedin(UP):You are welcome and yes exactly!