我与他人合著了一份 Google 白皮书，讲 AI 如何改变软件生命周期。我不打算概括整份报告。下面是我认为真正重要的几个观点，外加六张插图，欢迎随意复用。

Google 本周发布了《Vibe Coding 时代的新 SDLC》。我与 Shubham Saboo 和 Sokratis Kartakis 合著了这份报告。它是一个短系列的第一篇。

这是 Day 1 报告，所以前几页覆盖了基础概念：什么是 Agent、什么是"vibe coding"、为什么工作的重心从写代码转向评判代码。如果你在读这个博客，这些你应该已经知道了。我跳过这些，只写我认为值得你花时间读的部分，外加六张抽出来的图。图你们随便用。

Agent = 模型 + 套件（Harness）

报告中有一个框架我反复回想：Agent 等于一个模型加上一个套件（Harness）。

模型只是一个输入。其他一切都是套件：指令和规则文件、工具和 MCP 服务器、它运行的沙箱、生成子 Agent 和在模型之间路由的编排逻辑、在指定节点运行确定性代码的钩子、以及告诉你它何时偏离轨道的可观测性。报告粗略划分为：10% 模型，90% 套件。这个比例听起来很高，直到你花了一周时间调试一个套件。

模型是引擎。套件是车、路和交通规则。

几个公开数据让关系变得具体。在 Terminal Bench 2.0 上，一个团队只改了套件——底层模型没变——就把一个编程 Agent 从 30 名开外提到了前 5 名。LangChain 的另一个实验在同一个基准上只改了系统提示词、工具和中间件，就加了 13.7 分。两者都没有碰模型。

所以当 Agent 做出蠢事时，我学会了先调试套件。通常原因是：缺少某个工具、规则写得太松、忘了加护栏、或上下文窗口里塞满了垃圾。大多数 Agent 失败本质上是配置失败。我发现这反而令人鼓舞——因为配置是我今天就能修的东西，不需要等一个更好的模型出来。反正模型迟早会被套件下面的东西换掉。我在《套件工程》和《工厂模型》中更详细地展开过。

上下文工程是决定你账单的部分

如果套件是系统，上下文工程就是系统中最重要的旋钮。报告将 Agent 上下文分为六类：指令、知识、记忆、示例、工具和护栏。真正有趣的决策——也是会体现在你账单上的决策——是什么放进静态上下文，什么放进动态上下文。

静态上下文每次对话回合都会加载，所以它可靠且昂贵。动态上下文按需加载，所以你只为当前任务需要的部分付费。

静态上下文每次对话回合都会加载：系统指令、规则文件（AGENTS.md、CLAUDE.md、GEMINI.md）、全局记忆、核心护栏。它可靠，也很贵——因为你在每一次调用中都在为它付费。动态上下文按需加载：任务匹配时触发的技能、工具结果、从 RAG 中拉取的文档。你只为某个任务触及到的部分付费。

把这个平衡搞错一个方向，你会烧掉 token 并淹没信号；搞错另一个方向，Agent 会忘记保证它安全运行的规则。报告的建议，我同意的是把边界当作一个真正的架构决策来处理：在 PR 中审查，像代码一样做版本管理。

让动态上下文可扩展的秘诀是渐进式披露的 Agent Skills。Agent 在启动时看到少量元数据，任务匹配时才加载完整的指令，只在确实需要时才拉入沉重的参考材料。这就是一个 Agent 可以携带十几个 skills，但只需为正在用的那一个付费的原因。

验证是 vibe coding 和工程之间的分界线

同一个 Agent 可以落在从 vibe coding 到 Agent 工程之间光谱的任何位置。决定你落在哪里的东西是验证。

在光谱上的正确位置取决于风险。技能在于知道每个任务该把线画在哪里。

有两种机制。测试覆盖确定性的部分：这个输入，那个输出。评估（Eval）覆盖非确定性的部分——报告对它们的分类我觉得很有用。输出评估问的是最终结果是否正确。轨迹评估问的是它到达那里的路径——工具调用和推理过程——是否合理。两者都需要。一个看起来正确但跳过了检查的答案，比一个明显坏掉的答案更危险。

如果要我给领导者一句话，那就是：把标准定在评估上，而不是演示上。 演示展示 Agent 能工作一次。一个带真实评分标准的评估套件展示它能可靠地工作。我一直在做这个论证。

每个阶段实际如何变化

AI 压缩了生命周期，但压缩得不均匀，而这种不均匀才是关键。实现从几周降到几小时。需求、架构和验证仍然很慢，因为它们是判断性工作。所以规范质量成为瓶颈，而验证被移到了中间。

相同阶段，不同瓶颈，不同比例。

逐个阶段看：

需求不再是团队间传递的文档。它们变成了一场同时产出规范和第一个原型的对话。Agent 从简短描述中起草用户故事、暴露边界情况，让一段描述在几分钟内变成能跑的东西。

架构是最顽固地保留给人类的阶段。一致性 vs 可用性这样的权衡依赖模型无法完全理解的业务上下文。开发者的工作变成做出并记录结构性的决策，然后由 Agent 来实现。

实现是增益和警示同时存在的地方。调查显示生产力提升在 25% 到 39% 之间。但 METR 的一项研究发现，有经验的开发者在某些任务上——把检查和修复的时间算进去之后——反而慢了 19%。两种说法都对。诚实的总结是：AI 把实现从书写变成了审阅。

测试和质量保障被翻转了过来。你的测试和评估成为你告诉 Agent"正确"是什么意思的主要方式，嵌入一个循环中：在基准上运行 → 对失败聚类 → 修复导致它们的提示词或工具 → 用回归套件检查 → 观察生产环境中的新问题。

维护——这是我认为最被低估的一个。那些"太冒险不敢动"的代码——因为只有它的作者才理解它——现在可以被 Agent 阅读、重构和现代化。那些因为太繁琐、太冒险而从未发生的迁移和废弃清理，开始发生了。

这一切的天花板仍然是 80% 问题：Agent 能快速完成一个功能的前 80%，但最后的 20%——边界情况和各系统之间的接缝——仍然需要模型通常不具备的上下文。

经济学：上下文和模型路由是财务杠杆

对领导者来说，重要的数字不是速度，而是总拥有成本（TCO）。AI 时代以一种颠覆直觉的方式拆解它。

越过交叉点后，vibe coding 每个功能的花费高出 3 到 10 倍。代码需要存活多久，决定了你是否会到达那个交叉点。

Vibe coding 前期便宜，运行起来贵。 启动时几乎不花什么钱：一个订阅和一些提示词。然后你之后付出代价。Token 烧钱——把非结构化的文件扔进模型让它修自己的错误。维护税——几个月后有人不得不逆向工程那些临时拼凑的代码。安全清理——因为快速生成的漏洞和功能一样快。

Agent 工程与之相反： 前期投入更多（模式、测试、结构化上下文），之后每个功能的成本更低。

"Vibe coding 每个功能贵 3 到 10 倍"这个交叉点是示意性的，不是一个精确常数。我希望开发者带走的是：上下文工程和模型路由是财务杠杆，不只是技术杠杆。 你不能把一个 10 万 token 的代码库塞进每个提示词里还指望它能扩展。把困难的推理路由到大模型，把常规工作——测试生成、代码审查、CI 检查——路由到小型廉价模型。质量保持不变，账单降下来。这就是我称为"编排税"的财务面。

原型正在变成生产 Agent

这是报告中我最关注的部分。同一个生成一次性脚本的终端工作流，现在可以产生一个生产级 Agent——在同一个地方，通常通过与你已经在用的编程 Agent 对话就能完成。

构建、评估和部署一个真正的 Agent——带持久记忆、限定权限、评估覆盖和可观测性——过去是一个独立的栈、一份独立的工作。现在它融入了你已经在跑的循环。Google 的 Agents CLI 就是围绕这个理念构建的。一次性安装后，你的编程 Agent 学会整个生命周期的技能，你用自然语言驱动它：

# one-time setupuvx google-agents-cli setup# then, in your coding agent:> Build a support agent that answers questions from our docs.> Evaluate it on the FAQ dataset.> Deploy it to Agent Engine.

在这条指令背后，它搭建项目、编写代码、生成评估集、运行评估、部署到托管运行时，然后回报结果。昨天你笔记本上的原型变成了今天服务用户的生产 Agent，无需重写。Agent 之间的协调基于开放标准：MCP 用于工具，A2A 用于将工作交给其他 Agent。

报告中有一个实验我一直在跟人提起。Anthropic 的一个团队让一群 Agent 在两周内用 Rust 构建了一个能用的 C 编译器——人类设定方向和审查，而不是写代码。这大致就是未来的方向。

日常中你在两种模式之间切换，报告称之为指挥（Conductor）和编排器（Orchestrator）。指挥是实时的、在 IDE 内、逐键交互，适合探索和不熟悉的代码。编排器是异步的：你把一个目标交给一个或多个 Agent，然后审查返回的结果，适合规范化、明确的工作——如迁移或测试生成。现在的工具两者都支持，有时在同一小时内。我认为从指挥到编排器的转变，首先是技能的转变，然后才是工具的转变。

给其他人的那张图

还有一张图，这张不是给你的。是给你想带动的人看的——那些仍然认为这不过是高级自动补齐的高管、那些还没跟上来的同事。

每一代都保留了前一代的能力，并提高了单个工程师能做到的天花板。

上面有那些通常会终结"这东西到底是不是真的"争论的采用数据。截至 2026 年初，85% 的专业开发者经常使用 AI 编程 Agent，51% 每天使用，约 41% 的新代码是 AI 生成的。

从哪里开始

报告最后有一组更长的建议，面向个人、领导者和组织。我不在这里全部复述。

如果要挑一句话带走，那就是：AI 放大了它所落脚的工程文化——好的部分和坏的部分都是。 生成现在很大程度上已经解决了。剩下的工作是规范制定和验证，以及将这两者维系在一起的那些系统。这是我会去精进的部分。

原文：The New Software Lifecycle — Addy Osmani^[1]

对话私信：The New SDLC，可获取51页原文pdf。