Google AI 工程 Playbook 深度解读：模型只占 10%，真正决定生产力的是 Harness
Google AI 工程 Playbook 深度解读：模型只占 10%，真正决定生产力的是 Harness
2026 年 5 月，Google 悄悄放了一颗原子弹。
不是什么新模型，不是什么新架构。 是一份白皮书。一份只有 49 页，但是可能会重新定义未来十年软件工程的白皮书。
名字叫：《The New SDLC with Vibe Coding》。
作者是 Addy Osmani——Google Chrome 团队的工程总监，整个前端社区无人不知的大神。
这份白皮书出来之后，国外的工程圈已经炸了。但是国内好像还没什么人讨论。
这篇文章，我就来给你深度解读一下。这不是又一篇 "AI 会取代程序员" 的焦虑文。这是一份真正的、来自一线大厂的、可落地的、AI 时代的工程方法论。
看完这篇文章，你会知道：
- 为什么说 "模型只占 10%"？
- 什么是 Harness？为什么它比模型本身重要 10 倍？
- 什么是 Vibe Coding？什么是 Agentic Engineering？区别在哪里？
- 什么是 Factory Model？为什么说未来的程序员不再写代码，而是设计"写代码的系统"？
- 什么是 Conductor？什么是 Orchestrator？你应该成为哪一种？
- 以及最重要的：普通人、团队、公司，分别应该从哪里开始？
先搞清楚一个最基本的事实
在深入所有细节之前，先看这组数据：
截至 2026 年初：
- 85% 的专业开发者在日常使用 AI 编码助手
- 51% 每天都用
- 41% 的新代码是 AI 生成的
这件事已经不是"会不会发生"的问题了。 它已经发生了。而且正在以比所有人预想都快得多的速度渗透到整个行业。
但是，到这里为止，所有人都只在讨论一件事：模型。
- 这个模型更强
- 那个模型更快
- 这个模型更便宜
- 那个模型上下文更长
Google 这份白皮书，一上来就打脸了所有人：
那直觉是错的，而且会导致错误的投资。模型只是运行中 Agent 的一个输入而已。其他所有东西——提示词、工具、上下文策略、钩子、沙箱、子 Agent、可观测性——才是 Harness。
Harness 这个词，国内暂时还没有统一的翻译。你可以把它理解成： 包裹在模型外面的那层脚手架。那层把一个只会吐字的模型，变成一个能真正把事情做完的 Agent 的所有东西。
用一个公式表达：
Agent = 模型 + Harness你每天用的 Cursor、Claude Code、Aider、Cline，你感受到的体验，90% 是由 Harness 决定的，而不是底下的模型。
这是整篇白皮书最核心的洞见。也是所有团队都应该立刻意识到的事情。
光谱：从 Vibe Coding 到 Agentic Engineering
Google 把 AI 时代的开发方式，画成了一个完整的光谱。
从左到右，从随意到严谨：
<--- Vibe Coding --------------------------- Agentic Engineering --->
即兴发挥 有一些规则 完整的脚手架 工厂模式
低 CapEx 中等投入 高前期投入 最高 CapEx
高 OpEx 中等成本 低边际成本 最低 OpEx
适合原型 适合小项目 适合生产 适合大规模什么是 Vibe Coding？
Vibe Coding 就是大多数人现在正在做的事情：
- 打开 AI 助手
- 大概描述一下你想要什么
- AI 输出代码
- 看起来差不多就用了
- 出问题了再回去让它改
它的优点非常明显：快，零门槛，爽。 它的缺点也非常明显：不可靠，不可重复，不可维护，不可扩展。
白皮书里有一句话说得非常扎心：
你告诉 CTO 说你们团队在用 Vibe Coding 写支付系统，那是应该拉响警报的。
Vibe Coding 非常适合做原型、做探索、做一次性的脚本。 但是绝对不适合生产环境。
什么是 Agentic Engineering？
光谱的另一端，就是 Agentic Engineering。
它的核心思想是：
AI 不是你的搭档，是你工厂里的工人。你是工厂的设计师和管理者。你不直接指挥工人干活，你设计整个流水线、质量检测、反馈回路、安全护栏。然后工人在这个系统里自动干活。
Agentic Engineering 不是用不用 AI 的区别。 是你对 AI 输出的质量负不负责的区别。
Vibe Coding 说："AI 你随便写，我看着没问题就行。" Agentic Engineering 说："AI 你在我设计好的规则、测试、护栏里面写。写出来的东西必须通过所有质量门，通不过你自己改，直到通过为止。"
一个非常震撼的事实
白皮书里引用了两组数据：
在 Terminal Bench 2.0 上，有一个团队，只改了 Harness，模型完全没变，就把一个排名 30 名开外的编码 Agent，干到了前五名。
LangChain 的另一项研究：只改系统提示词、工具、中间件，完全不动模型，就让 Agent 的分数提高了 13.7 分。
还有一个所有人都观察到但是没人说出来的现象：
当 Agent 做错了什么事，所有人的第一反应都是骂模型傻。但是 90% 的情况下，问题根本不在模型。而是缺了一个工具，或者规则写得太模糊，或者没有护栏，或者上下文窗口里塞满了垃圾。
大多数 Agent 失败，诚实点说，都是配置失败。
Harness 里面到底有什么？
既然 Harness 这么重要，那它里面到底有什么东西？
Google 给出了非常明确的清单：
| 组件 | 说明 |
|---|---|
| 指令和规则文件 | AGENTS.md、CLAUDE.md、技能文件、子 Agent 提示词。定义这个 Agent 是谁，它关心什么，它绝对不能做什么。 |
| 工具 | 函数、MCP 服务器、API，以及告诉模型什么时候用、怎么用的说明文字 |
| 沙箱和执行环境 | Agent 的代码实际在哪里跑，它能访问什么，不能访问什么 |
| 编排逻辑 | 子 Agent 生成、模型路由、专家之间的交接、以及什么时候触发谁的规则 |
| 护栏和钩子 | 在生命周期特定节点运行的确定性代码：工具调用之前、文件编辑之后、提交之前。钩子是放那些 Agent 永远会忘但是绝对不能忘的事情的地方。 |
| 可观测性 | 日志、追踪、评估、成本和延迟计量。没有可观测性，你根本不知道 Agent 是在好好干活，还是在悄悄漂移。 |
看清楚了吗？ 这里面没有一样东西是关于模型的。 所有这些东西，都不是 OpenAI、Anthropic、Google 会给你的。 所有这些东西，都是你的团队自己的责任。
这就是为什么 "模型只占 10%"。 剩下 90% 的东西，都在这个清单里。而大多数团队，现在连 1% 都还没开始做。
Harness 如何贯穿整个新 SDLC
Harness 不是只在写代码的时候用。 它贯穿了整个软件开发生命周期的每一个阶段。
让我们一个阶段一个阶段看：
阶段 1：需求、规划、架构 —— 配置 Harness
在 AI 写任何生产代码之前，开发者必须先配置好 Agent 的环境。
- 写好 AGENTS.md，定义架构约束
- 配置 Agent 可以访问哪些工具
- 设置 Agent 绝对不能打破的基本规则
这是整个流程的基础。地基打歪了，后面所有东西都是歪的。
阶段 2：实现 —— 运行 Harness
在实际编码的时候，Harness 是边界，是让 AI 保持专注、安全、高效的护栏。
- AI 写的代码在隔离的沙箱里运行
- AI 只能使用 Harness 提供给它的工具
- 所有文件访问都经过权限检查
阶段 3：测试和 QA —— 反馈回路
这是 Harness 最强大的地方。 当 Agent 写了一个函数，Harness 会：
- 在沙箱终端里自动跑测试
- 如果测试失败，捕获错误输出
- 把错误塞回给模型，让它再试一次
- 循环，直到通过
这就是自动化的 "思考 → 行动 → 观察" 循环。 这才是 Agent 真正的力量。不是一次写对。是错了之后能自己改对。
阶段 4：代码审查、部署、维护 —— 观察 Harness
代码写完之后，Harness 依然在工作。
- 钩子会在提交之前自动检查，发现硬编码的密码直接拦截
- 可观测层追踪 token 成本、延迟、Agent 漂移
- 人类工程师可以审计 Agent 为什么做出了某个特定的部署决策
Factory Model：全新的心智模型
整篇白皮书，最颠覆我认知的，是这个叫做 Factory Model（工厂模型） 的心智模型。
旧的心智模型
开发者 → 写代码开发者的产出是代码。
新的心智模型
开发者 → 设计生产代码的系统 → Agent 在这个系统里生产代码开发者的产出不再是代码。 开发者的产出是生产代码的那个系统。
这个系统包括：
- 定义需要构建什么的规范和上下文
- 把规范翻译成实现的 Agent
- 验证正确性的测试和质量门
- 把失败路由回 Agent 修正的反馈回路
- 约束 Agent 安全可预测行为的护栏
工厂经理不会亲手组装每一个零件。 他们设计流水线，确保质量控制。
现代开发者设计开发系统，确保它的输出达到要求的标准。
成功来自于给 Agent 成功标准，而不是一步步的指令。然后让它们自己迭代。
这不是未来。这就是今天 Google 内部正在发生的事情。
开发者角色的转变：Conductor vs Orchestrator
AI 时代，开发者的角色正在发生深刻的转变。Google 把它分成了两种模式：
Conductor（指挥家模式）
开发者和 AI 结对编程，实时互动。 你在 IDE 里，看着代码一行一行出现，用提示词和纠正引导 AI，对写出来的每一行都保持细粒度的控制。
适合：复杂逻辑、调试疑难问题、在不熟悉的代码库里工作。 工具：GitHub Copilot、Cursor、Windsurf、Gemini Code Assist。
优点：保留理解和控制的感觉。 缺点：如果你在亲自指挥每一次按键，AI 带来的吞吐量提升是有限的。你依然是瓶颈。
Orchestrator（指挥家模式？不，是乐团经理模式）
开发者在更高的抽象层工作。 你定义目标，把任务分配给 Agent，然后审核结果——但是你不会一行一行看着代码出现。 Agent 可能在后台、并行地、在代码库的不同部分工作。你定期检查，审核输出，提供方向修正。
适合：定义清晰的任务——Bug 修复、按照既定模式实现功能、代码库迁移、生成测试。 工具：Google Jules、GitHub Copilot Agent Mode、Cursor Background Agents、Claude Code。
Orchestrator 模式需要一套完全不同的技能：
- Specification 能力：把任务定义得足够精确，让 Agent 可以无歧义地执行
- Decomposition 能力：把大任务拆成适合 Agent 执行的合适大小的单元
- Evaluation 能力：快速评估 Agent 的输出是否达到质量标准
- System Design 能力：设计约束、测试、反馈回路，让 Agent 保持高效
这就是未来 5 年，程序员技能树的变化方向。 语法写得溜不溜，越来越不重要了。 上面这四个能力，越来越重要。
80% 问题：所有人都在踩的坑
所有用 AI 写过代码的人，都遇到过这个问题：
AI 可以非常快地写出 80% 的代码。但是剩下那 20%——边界条件、错误处理、集成点、微妙的正确性要求——需要深度的上下文知识，而这正是当前模型常常缺乏的。
而且 AI 错误的性质也变了。 以前是明显的语法错误，一眼就能看出来。 现在是更隐蔽的概念错误：
- 对业务逻辑的错误假设
- 没有对模糊的需求寻求澄清
- 漏掉了边缘情况
- 做出了会带来微妙长期维护负担的架构决策
这些错误更难被发现，恰恰是因为代码"看起来是对的"，甚至可能通过了基本测试。
最有效地应对这个挑战的开发者，都采取了一个特定的姿态：
他们用 AI 做 AI 擅长的事——快速实现定义清晰的任务。 他们把自己的注意力留给 AI 不擅长的事——模糊的需求、架构权衡、正确性验证。 他们不是通过接受 AI 生产的所有东西来变得更快。 他们是通过把专业知识集中在最重要的地方来变得更快。
AI 开发的经济学：Vibe Coding vs Agentic Engineering
这一部分是写给管理者和 CTO 看的。非常重要。
大多数人对 AI 成本的理解，还停留在"每个月 20 美元订阅费"。 这是非常非常危险的错觉。
AI 开发的总成本，应该分成两类：
- CapEx（资本支出）：前期投入
- OpEx（运营支出）：持续运行的成本
| 模式 | CapEx | OpEx |
|---|---|---|
| Vibe Coding | 极低（零门槛，订阅就行） | 极高 |
| Agentic Engineering | 高（前期投入设计系统） | 极低 |
Vibe Coding 的隐藏债务
Vibe Coding 看起来非常划算。门槛几乎为零。 但是它隐藏了巨大的、复利增长的 OpEx 负担：
Token 燃烧率：每次和 LLM 交互都要钱。Vibe Coding 里，开发者经常把巨大的、无结构的文件塞进上下文窗口，反复让模型修复它自己未经核实的错误。这创造了一个昂贵的"提示循环"，第一次成功率很低，token 哗哗地烧。
维护税：通过即兴提示写出来的代码，往往缺乏结构一致性。六个月后出现一个 Bug，人类工程师必须花好几天反向工程这些无结构的、AI 生成的"意大利面条代码"。
安全修复成本：没有自动化的评估 Harness，快速生成代码就等于快速生成漏洞。在生产环境修复一个安全漏洞的成本，比在设计阶段抓住它高出几个数量级。
Agentic Engineering 的投资回报
Agentic Engineering 翻转了这个经济模型。 它要求在生成第一行生产代码之前，进行刻意的、前期的工程时间和资源投入。
- 设计 API Schema
- 构建确定性的测试套件
- 最重要的，结构化 Agent 的上下文
前期成本更高，但是交付和维护一个功能的边际成本会急剧下降。 AI 在一个严格治理的"工厂"里运行，意味着它的输出在结构上是健全的、经过预先测试的、符合公司标准的。
Context Engineering 不是技术技能，是财务策略。
你给模型的上下文越精准、越密集、越有信号，Agent 的第一次成功率就越高，就能避免 Vibe Coding 里那些昂贵的试错循环。
智能模型路由：再省一大笔
Agentic Engineering 还有一个巨大的成本优势：智能模型路由。
在 Vibe Coding 工作流里，开发者通常依赖一个单一的、巨大的前沿模型来处理每一次交互——花着最高级的 token 价格，只是为了让 AI 改个 typo 或者生成一个基础的单元测试。
一个设计良好的工厂模型避免了这种浪费：
- 用大的、先进的模型处理高度复杂的任务（需求、架构、初始实现）
- 自动把确定性的、低复杂度的任务（测试生成、代码审查、CI/CD 监控）路由给更小、更快、便宜得多的模型
通过编排一个多模型生态系统，工程团队可以保持最高的输出质量，同时系统性地把运营 token 成本降下来。
从哪里开始？行动指南
白皮书的最后，给出了非常具体的行动指南。 分个人开发者、工程管理者、公司组织三个层面。我提炼了最核心的部分。
给个人开发者
先给你的项目写一个 AGENTS.md。就从十行开始：技术栈、约定、硬性规则、工作流。每次 Agent 做了它不应该再做的事情，就加一条规则。这是你能做的投入产出比最高的一件事。
先写测试和评估，再生成代码。它们加在一起就是和 AI 的合同。一套写得好的测试和评估套件，比任何自然语言提示词都能更精确地传达意图。它把 AI 辅助开发从 Vibe Coding 变成了 Agentic Engineering。
审查 Agent 生产的每一行要上线的代码。对任何看起来"聪明"的东西保持怀疑。检查 import 的包是不是真的存在。验证错误处理是不是覆盖了真实的失败模式。团队不理解的代码，最终会变成团队付不起的调试成本。
保持你的开发者技能。AI 处理常规工作，是为了让开发者可以专注于挑战性的工作。这个安排成立的前提是你的基础技能——调试、系统设计、对性能和正确性的直觉——保持敏锐。把 AI 当作更大规模应用专业知识的手段，而不是它的替代品。
给工程管理者
把 Context Engineering 变成团队的一等工程实践。把 AGENTS.md、系统提示词、评估套件、技能库当作代码来对待：在 PR 中审查、和项目一起版本控制、由指定工程师负责。没有这个纪律，Harness 就会漂移，Agent 的行为就会变得不可复现。
把标准定在评估，而不是演示上。一个能跑的演示证明一个 Agent 可以成功一次。一套通过的评估证明它可以可靠地成功。但是没有明确评分标准的评估，什么也衡量不了。定义你要打分的维度：任务成功率、工具使用质量、轨迹合规性、幻觉、响应质量。把评估覆盖率和明确的评分标准作为任何 Agent 进入共享工作流的前置条件，就像测试覆盖率 gates 服务部署一样。
为 AI 生成的代码重塑代码审查流程。AI 生成的代码需要和人类写的代码同等甚至更高的审查力度，尤其要注意幻觉的依赖、不充分的错误处理、以及一眼看上去很对但实际上有微妙正确性漏洞的地方。培训审查员了解生成代码的失败模式，并相应调整审查清单。
在团队规范中明确区分原型工作和生产工作。Vibe Coding 是探索的正确速度。Agentic Engineering 是生产的正确纪律。把边界划清楚：哪些项目、哪些分支、哪些环境需要哪种工作模式。保持这个边界模糊的团队，最终会生产出不小心上线的原型。
给组织
把 AI 辅助开发当作工程投资，而不是生产力功能。看到最大收益的团队，是把 AI 工具和评估覆盖率、可观测性、清晰的架构标准配对使用的团队。在没有这些脚手架的情况下推广编码 Agent，只会带来没有质量的速度，这会比任何团队能还清的速度都更快地累积技术债务。
在规模化之前投资生产基础设施。笔记本上的 Vibe Coding 原型不是生产系统。把前者变成后者的，是围绕它的运营纪律：在 CI 中运行轨迹和最终响应评估、每次 Agent 运行的追踪、每个 Agent 的权限范围、针对生成代码失败模式调整的安全审查。在第一个生产 Agent 上线之前就建好这些基础设施，而不是之后。
采用工具和 Agent 间通信的开放标准。Model Context Protocol（MCP）用于工具访问，Agent2Agent（A2A）用于跨 Agent 委托，正在汇聚成多 Agent 系统的结缔组织。现在就选择它们，保持混合供应商和框架的选项开放，避免以后重新平台化。
写在最后
这份白皮书的标题里有 "Vibe Coding" 这个词，听起来很随意，很时髦。 但是你越读下去，就越会发现它的内核一点都不随意。 它非常严肃，非常务实，非常工程化。
它本质上是在说一件事：
AI 这个东西，我们已经玩了好几年了。现在是时候从"玩"，转到"认真生产"了。玩的时候，你可以 Vibe Coding，怎么爽怎么来。但是要生产，你必须有纪律，有流程，有体系。
这个转型，现在正在发生。
两三年后，所有正经的软件工程团队，都会有完整的 Harness 体系。 Agent 会成为日常工作流中看不见但是无处不在的一部分。 今天的很多最佳实践，到时候会变成常识。
而现在，就是你建立先发优势的时候。 不是去卷谁的模型更大，不是去卷谁的提示词写得更好。 是去卷 Harness，去卷整个体系，去卷那些真正能带来长期竞争优势的东西。
未来已来，只是分布不均。 希望你是那个分布在有利位置的人。
参考资源
- The New SDLC with Vibe Coding 白皮书原文 — https://readwise-assets.s3.amazonaws.com/media/wisereads/articles/the-new-sdlc-with-vibe-coding/1317.pdf
- B 站解读视频 — https://b23.tv/8pviEHy
- Google Agents CLI — 本文提到的 Google 官方 Agent 开发命令行工具
- Model Context Protocol (MCP) — Agent 工具访问的开放标准
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
