{
  "slug": "google-agent-whitepaper",
  "url": "https://kelewrites.com/posts/google-agent-whitepaper/",
  "title": "Agent 的「正确答案」：Google 白皮书把 Agent 拉回工程系统",
  "subtitle": "Agent 不是更会聊天的 LLM，而是一套可构建、可运行、可治理的工程系统",
  "summary": "Google 在 2025 年 11 月一次性放出五篇 Agent 白皮书，等于给从业者发了一张统一的架构地图。本文拆解第一本 Introduction to Agents：把 Agent 重新定义成「Model + Tools + Orchestration + Runtime」的四件套，按 Level 0–4 标定系统承诺，并用上下文工程、AgentOps、安全治理三把尺子衡量它能不能上生产。",
  "date": "2025-12-24",
  "updated": "",
  "tags": [
    "AI",
    "Agent",
    "工程方法"
  ],
  "series": "",
  "source": {
    "title": "Agent 的正确答案来了，Google AI Agent 白皮书拆解①",
    "url": "https://www.bilibili.com/video/BV1JSBTB2EMT/"
  },
  "ai": {
    "summary": "Google 在 2025 年 11 月一次性放出五篇 Agent 白皮书，等于给从业者发了一张统一的架构地图。本文拆解第一本 Introduction to Agents：把 Agent 重新定义成「Model + Tools + Orchestration + Runtime」的四件套，按 Level 0–4 标定系统承诺，并用上下文工程、AgentOps、安全治理三把尺子衡量它能不能上生产。",
    "takeaways": [
      "Google 在 2025 年 11 月一次性放出五篇 Agent 白皮书，等于给从业者发了一张统一的架构地图。本文拆解第一本 Introduction to Agents：把 Agent 重新定义成「Model + Tools + Orchestration + Runtime」的四件套，按 Level 0–4 标定系统承诺，并用上下文工程、AgentOps、安全治理三把尺子衡量它能不能上生产。",
      "开场：为什么要重新定义 Agent",
      "一、定义：Agent 是四件套，不是「会聊天的 LLM」",
      "二、分级：Level 0–4 不是炫技，是系统承诺"
    ],
    "audience": [
      "正在做 AI Agent / 工程实践的工程师",
      "关心工程落地与系统设计的人"
    ],
    "quote": "一句话总结：Google 给 Agent 的「正确答案」是把它当工程系统对待——四件套定义边界，Level 0-4 标系统承诺，AgentOps 与防御纵深决定它能不能真上生产。",
    "questions": [
      "这篇文章的核心结论是什么？",
      "开场：为什么要重新定义 Agent？",
      "定义：Agent 是四件套，不是「会聊天的 LLM」是什么？",
      "分级：Level 0–4 不是炫技，是系统承诺是什么意思？"
    ],
    "citation": {
      "title": "Agent 的「正确答案」：Google 白皮书把 Agent 拉回工程系统",
      "conclusion": "Google 在 2025 年 11 月一次性放出五篇 Agent 白皮书，等于给从业者发了一张统一的架构地图。本文拆解第一本 Introduction to Agents：把 Agent 重新定义成「Model + Tools + Orchestration + Runtime」的四件套，按 Level 0–4 标定系统承诺，并用上下文工程、AgentOps、安全治理三把尺子衡量它能不能上生产。",
      "points": [
        "开场：为什么要重新定义 Agent",
        "一、定义：Agent 是四件套，不是「会聊天的 LLM」",
        "二、分级：Level 0–4 不是炫技，是系统承诺"
      ],
      "quote": "一句话总结：Google 给 Agent 的「正确答案」是把它当工程系统对待——四件套定义边界，Level 0-4 标系统承诺，AgentOps 与防御纵深决定它能不能真上生产。",
      "url": "https://kelewrites.com/posts/google-agent-whitepaper/",
      "attribution": "kele · Article Share"
    }
  },
  "headings": [
    {
      "depth": 2,
      "text": "开场：为什么要重新定义 Agent"
    },
    {
      "depth": 2,
      "text": "金字塔总览"
    },
    {
      "depth": 2,
      "text": "一、定义：Agent 是四件套，不是「会聊天的 LLM」"
    },
    {
      "depth": 3,
      "text": "1.1 Agent 等于四件套，外加一个核心动作"
    },
    {
      "depth": 3,
      "text": "1.2 Think–Act–Observe：可重复的五步循环"
    },
    {
      "depth": 3,
      "text": "1.3 一个客服场景把舞步跑一遍"
    },
    {
      "depth": 2,
      "text": "二、分级：Level 0–4 不是炫技，是系统承诺"
    },
    {
      "depth": 2,
      "text": "三、循环：Agent 本质是 Context Window 的策展系统"
    },
    {
      "depth": 3,
      "text": "3.1 上下文有六块，缺一不可"
    },
    {
      "depth": 3,
      "text": "3.2 短期记忆 = RAM，长期记忆 = 带检索的硬盘"
    },
    {
      "depth": 3,
      "text": "3.3 编排层是状态机加调度器"
    },
    {
      "depth": 2,
      "text": "四、上线：AgentOps 与防御纵深是生产线的两根支柱"
    },
    {
      "depth": 3,
      "text": "4.1 AgentOps：用三段流水线把不确定性变成可控工程"
    },
    {
      "depth": 3,
      "text": "4.2 防御纵深：硬规则 + Guard Models 两道门"
    },
    {
      "depth": 3,
      "text": "4.3 模型不是选最强，是选最合适"
    },
    {
      "depth": 2,
      "text": "一页速览"
    },
    {
      "depth": 2,
      "text": "一句话收束"
    }
  ],
  "text": "> **一句话总结**：Google 给 Agent 的「正确答案」是把它当工程系统对待——四件套定义边界，Level 0-4 标系统承诺，AgentOps 与防御纵深决定它能不能真上生产。\n\n---\n\n## 开场：为什么要重新定义 Agent\n\n大家都在做 Agent，但谁都说不清「到底什么才算 Agent」。一边是 demo 满天飞，一边是上线就翻车，团队互相指责模型不够强、工具不够多、prompt 不够精。\n\nGoogle 在 2025 年 11 月 10 到 14 日，连续五天密集课程，同时把五篇白皮书完整开源到 Kaggle Learn 并且免费。这不是一次发布会，是一份对从业者发出的统一参考系：把 Agent 从「prompt 加几个工具的拼装」拉回到软件工程的全生命周期——能构建、能评估、能运维、能部署。\n\n第一本 Introduction to Agents 就只干一件事：把 Agent 的底层框架钉死。Agent 不是更会聊天的 LLM，而是一套可构建、可运行、可治理的工程系统。\n\n答案是一句话：**Agent 等于 Model + Tools + Orchestration + Runtime 四件套；用 Level 0–4 标定系统承诺；以 AgentOps 与防御纵深为底线，才算进入生产成熟度。** 下面分四层展开。\n\n---\n\n## 金字塔总览\n\n---\n\n## 一、定义：Agent 是四件套，不是「会聊天的 LLM」\n\n### 1.1 Agent 等于四件套，外加一个核心动作\n\nGoogle 给出可落地的最简定义：\n\n| 组件 | 类比 | 职责 |\n\n| Model | 大脑 | 理解目标、做推理、出计划 |\n| Tools | 手 | 接触现实：查数据、搜信息、调 API、执行代码 |\n| Orchestration Layer | 神经系统 | 把 Think–Act–Observe 循环跑起来、管状态、管上下文 |\n| Runtime / Deployment | 身体与腿 | 长期在线、可监控、可观测、可扩缩容、可治理 |\n\n关键不是「能生成」，而是**用 LLM 在循环里做事**——每一轮把目标和上下文塞进去，模型决策、必要时调用工具、再把结果回写上下文，进入下一轮。\n\n只要还停留在「一问一答，哪怕加了几个 function calling」，本质都还是应用层的对话接口。**只有循环跑稳、运行时撑得住，才开始像一个真正的 Agentic System。**\n\n### 1.2 Think–Act–Observe：可重复的五步循环\n\n把循环翻译成工程语言，就是这五步：\n**Get Mission**——拿到目标，来自用户或系统触发。\n**Scan the Scene**——扫现场：用户说了什么、历史有什么、能调哪些工具。\n**Think it Through**——基于目标和现场产出一个可执行计划。\n**Take Action**——编排层选工具，发起一次具体的 Tool Call。\n**Observe & Iterate**——把工具返回结构化、可筛选、可追踪地写回上下文，进入下一轮。\n\n五步里最值钱的不是 Think，而是 **Think 之后真的能 Act，并且 Act 的结果能被系统消费**。这才叫办事。\n\n> **金句**：Agent 的核心不是输出更漂亮的文本，而是用一个可重复的循环把任务一步步办完。\n\n### 1.3 一个客服场景把舞步跑一遍\n\n用户问「我的订单 12345 现在到哪了」：\n**Mission**：给出订单状态。\n**Scene**：内部订单库查询、物流承运商查询两类工具可用。\n**Think**：三段式计划——Identify（查内部库拿运单号）→ Track（查承运商实时状态）→ Report（汇总成一句话）。\n**Act + Observe**：先调 `find_order(12345)` 拿运单号 `ZYX987`；再调 `get_shipping_status(ZYX987)` 拿到 `out_for_delivery`。\n**生成最终回复**。\n\n这就是 Agent 和聊天机器人的分水岭：**聊天机器人会直接编一个看起来很像的答案，Agent 会先把世界查一遍再开口。**\n\n---\n\n## 二、分级：Level 0–4 不是炫技，是系统承诺\n\n做 Agent 最容易翻车的不是模型选错，而是一开始就把系统范围开太大，最后治理跟不上。**每上一个 Level，你增加的不是能力点，而是一整套工程负担：权限面、隐私合规、可观测、责任边界都会指数级复杂。**\n\n| Level | 名称 | 分水岭 | 工程意义 |\n\n| **L0** | 纯推理 | 没手 | 只能在训练知识里解释、规划、给建议；对现实是盲的 |\n| **L1** | Connected Problem Solver | 接上工具（搜索/RAG/数据库） | 不靠死记事实，靠工具把事实取回来——**贴近事实、减少幻觉的最划算起点** |\n| **L2** | Context Engineering | 主动管理上下文 | 战略规划 + 每步动态生成「最小上下文」，是「真做 Agent」和「工具型聊天」的分界 |\n| **L3** | 协作多智能体 | 一个协调者 + 多个专家 Agent | 解决的是组织问题：分工、并行、复用 |\n| **L4** | 自我扩展 | 能发现自己缺能力，动态造新工具/新 Agent 补缺口 | 最激进，治理体系不到位就是「不可控的 Agent SPA」 |\n\nL1 最常被低估的不是 function calling 本身，而是「把工具变成稳定契约——能调用、能处理失败、能回写上下文」；L2 真正的瓶颈往往不是模型不会想，而是**上下文塞得太满，注意力被垃圾信息稀释了**，导致计划漂移、工具乱调用。\n\n> **金句**：Level 不是炫技，Level 是你的系统承诺。先把 L1 事实闭环跑稳，再把 L2 上下文工程做扎实，最后再谈 L3 团队化和 L4 自我扩展。\n\n---\n\n## 三、循环：Agent 本质是 Context Window 的策展系统\n\n### 3.1 上下文有六块，缺一不可\n\n一轮 Agent 调用 LLM，喂进去的 Context 至少包含六块：\n\n| 块 | 内容 | 工程要点 |\n\n| System Instruction | 系统指令、行为约束、何时必须用工具 | 硬约束放这里 |\n| User Input | 任务触发点 | 只靠它通常不够 |\n| Session History | 多轮对话连续性 | 需求澄清和约束变化的载体 |\n| Long-term Memory | 偏好、事实、决策记录 | **按需召回，不是全塞进来** |\n| Grounding | RAG / 搜索 / 知识图谱 | 先对齐事实再开口 |\n| Tools + Tool Results | 可用工具清单 + 刚刚做了什么、拿回了什么 | observe 必须结构化、可追踪 |\n\n很多 Agent 不稳定，根因不是模型不行，是**上下文被喂成了一锅粥**。Context Engineering 做的就是把这一锅粥拆成一道道可复用的配菜。\n\n### 3.2 短期记忆 = RAM，长期记忆 = 带检索的硬盘\n\n| 维度 | 短期记忆 | 长期记忆 |\n\n| 边界 | 任务进行时 | 跨会话持久 |\n| 形态 | Action–Observation 序列 | 可召回的偏好/事实/决策 |\n| 实现 | 挂在 State 里 | 做成一个工具，通过 RAG 召回最相关几条 |\n| 保证 | 任务不丢线 | 体验能积累 |\n\n把长期记忆做成「工具」而不是「把全文塞进 prompt」，带来两个直接收益：个性化可以持续；上下文不会爆炸。\n\n> **金句**：Agent 的不稳定，往往不是模型不行，是上下文被喂成了一锅粥。\n\n### 3.3 编排层是状态机加调度器\n\n编排层不是一段胶水代码，更不是简单的流程管道，它是**系统的行为中枢**：\n**调度**：把 Think–Act–Observe 跑起来。\n**状态**：管「当前任务在哪一步、已经调过哪些工具、拿到哪些字段、还缺什么」。\n**节奏**：决定何时思考、何时用工具、何时降级、何时必须 Human-in-the-Loop。\n\n工程上最常见的成功解法是**混合式**——关键步骤用硬规则卡口，开放区域让模型发挥。高风险动作必须 HITL 或者必须通过 Policy 校验。\n\n---\n\n## 四、上线：AgentOps 与防御纵深是生产线的两根支柱\n\n### 4.1 AgentOps：用三段流水线把不确定性变成可控工程\n\n传统单测「输入固定 → 输出等于预期」在 Agent 上天然不成立——Agent 的输出是**概率分布**，同一个输入措辞会变、步骤会变、甚至工具调用顺序都会变。要测的不是最后一句话对不对，而是**整条轨迹质量是不是下降了**。\n\n| 段 | 做什么 | 关键产物 |\n\n| **KPI 先行** | 先定义「什么叫更好」并能映射到业务转化 | 目标达成率、端到端时延、单次成本 |\n| **LLM-as-Judge** | 用强模型按 rubric 给离线 Golden Set 打分 | 指令遵循、Grounded、工具合理、格式合规 |\n| **Metrics-Driven Development** | 每次改 prompt/换模型/加工具都跑评测集；上线走灰度或 AB | 离线分数与线上指标对齐 |\n\n加上两样武器：**OpenTelemetry Traces** 用来回答「为什么他选了这个工具、为什么参数这样填、为什么第三步开始偏航」；**人类反馈闭环**——线上一个 thumbs-down 不是噪声，是评测集缺失的证据，复现后沉淀进 Golden Set，就是给系统打了一针疫苗。\n\n### 4.2 防御纵深：硬规则 + Guard Models 两道门\n\n授权越大越有用，但风险也同步放大。主要就三类：\n**Rogue Actions**：自作主张做了不该做的动作，而且很多不可逆。\n**敏感数据泄露**：上下文混合了用户输入、检索结果、工具返回、历史记忆，任何一段被误输出就是系统级事故。\n**Prompt Injection**：本质是**指令被劫持**——攻击者把恶意指令藏在网页、文档、邮件里，Agent 一检索一读取，就可能把攻击当成更高优先级任务执行。\n\n两道门同时上：\n\n| 门 | 形态 | 作用 |\n\n| **Guardrails** | 模型外的硬规则 | 金额上限、敏感操作二次确认、白名单参数校验——**可预期、可审计** |\n| **Guard Models** | 小模型/专用模型实时判别 | 拦截上下文相关的灰区风险（诱导越权、工具调用意图变形） |\n\n从一个 Agent 走向一堆 Agent，安全就必须**平台化**——Agent Identity 让每个 Agent 成为可验证身份；Policy 同时管 Agent、Tools、其它 Agents、Context；Control Plane + Registry 做统一入口，所有交互都走这里，审计、授权、可观测一并接管。\n\n> **金句**：单体安全靠加栏杆，规模化安全靠修交通系统。\n\n### 4.3 模型不是选最强，是选最合适\n\nAgent 场景的模型选型有一条硬路径：**业务目标在前，模型在后**——别看哪个榜单分高就塞进系统。Agent 是 LLM-in-a-Loop，任何一轮工具调用不稳定都会把后面的轨迹带崩。所以要测的不只是「答案对不对」，而是「推理链是否稳、工具调用是否准、失败时能否恢复」。\n\n落地三件事合起来才算 Production-Grade：**权衡（质量/速度/价格）**→ **多模型路由（Team of Specialists：重推理给旗舰，意图识别/摘要/抽取给便宜快的）**→ **AgentOps 持续评测支撑快速升级**。没有稳定评测集，每次换模型都像在赌博。\n\n---\n\n## 一页速览\n\n| 层级 | 内容 | 一句话核心 |\n\n| **核心结论** | Agent = 工程系统 | 四件套 + Level 分级 + AgentOps + 防御纵深，才是「正确答案」 |\n| **主论点一** | 定义 | Model / Tools / Orchestration / Runtime 四件套，关键是「LLM in a loop」 |\n| 1.1 | 四件套 | 大脑 / 手 / 神经系统 / 身体腿 |\n| 1.2 | 五步循环 | Mission → Scene → Think → Act → Observe |\n| 1.3 | 分水岭 | 聊天机器人编答案，Agent 先查世界再开口 |\n| **主论点二** | 分级 | Level 0–4 是系统承诺，不是炫技 |\n| L0–L1 | 有没有手 | L1 是减少幻觉最划算的起点 |\n| L2 | 上下文工程 | 真做 Agent 与工具型聊天的分界 |\n| L3–L4 | 团队化与自我扩展 | 治理不到位就是 Agent SPA |\n| **主论点三** | 循环 | Agent 本质是 Context Window 的策展系统 |\n| 3.1 | 上下文六块 | System / User / Session / Long-term / Grounding / Tools |\n| 3.2 | 记忆二分 | 短期 = RAM，长期 = 带检索的硬盘 |\n| 3.3 | 编排层 | 状态机 + 调度器，混合式最稳 |\n| **主论点四** | 上线 | AgentOps + 防御纵深决定能不能上生产 |\n| 4.1 | AgentOps | KPI → LLM-as-Judge → Metrics-Driven，Trace + 反馈闭环 |\n| 4.2 | 防御纵深 | Guardrails 定底线 + Guard Models 覆盖灰区，规模化要平台化 |\n| 4.3 | 模型选型 | 业务在前模型在后，团队化路由 + 持续评测 |\n\n---\n\n## 一句话收束\n\n> **Agent 的「正确答案」，不是更聪明的模型，而是更克制的系统——把不确定性关进可观测、可治理、可演化的边界里。**\n\n---\n\n*本文是对 Google AI Agent 白皮书第一本 Introduction to Agents 的拆解。原视频出自 B 站 UP 主「碳硅同传」，五本白皮书构成的完整路线图——Day1 定义、Day2 工具与互操作、Day3 会话与记忆、Day4 质量评测、Day5 原型到生产——本文只覆盖 Day1。*"
}