Agent 的「正确答案」：Google 白皮书把 Agent 拉回工程系统

一句话总结：Google 给 Agent 的「正确答案」是把它当工程系统对待——四件套定义边界，Level 0-4 标系统承诺，AgentOps 与防御纵深决定它能不能真上生产。

开场：为什么要重新定义 Agent

大家都在做 Agent，但谁都说不清「到底什么才算 Agent」。一边是 demo 满天飞，一边是上线就翻车，团队互相指责模型不够强、工具不够多、prompt 不够精。

Google 在 2025 年 11 月 10 到 14 日，连续五天密集课程，同时把五篇白皮书完整开源到 Kaggle Learn 并且免费。这不是一次发布会，是一份对从业者发出的统一参考系：把 Agent 从「prompt 加几个工具的拼装」拉回到软件工程的全生命周期——能构建、能评估、能运维、能部署。

第一本 Introduction to Agents 就只干一件事：把 Agent 的底层框架钉死。Agent 不是更会聊天的 LLM，而是一套可构建、可运行、可治理的工程系统。

答案是一句话：Agent 等于 Model + Tools + Orchestration + Runtime 四件套；用 Level 0–4 标定系统承诺；以 AgentOps 与防御纵深为底线，才算进入生产成熟度。 下面分四层展开。

金字塔总览

mindmap
  root((Google Agent 白皮书①<br/>正确答案 = 工程系统))
    一·定义·四件套
      Model 大脑
      Tools 手
      Orchestration 神经系统
      Runtime 身体与腿
    二·分级·Level 0-4
      L0 纯推理
      L1 接工具
      L2 上下文工程
      L3 多智能体
      L4 自我扩展
    三·循环·策展上下文
      Think Act Observe
      短期 = 内存
      长期 = 带检索的硬盘
    四·上线·AgentOps + 防御纵深
      KPI 评测 灰度
      Guardrails + Guard Models
      平台化治理

一、定义：Agent 是四件套，不是「会聊天的 LLM」

1.1 Agent 等于四件套，外加一个核心动作

Google 给出可落地的最简定义：

关键不是「能生成」，而是用 LLM 在循环里做事——每一轮把目标和上下文塞进去，模型决策、必要时调用工具、再把结果回写上下文，进入下一轮。

只要还停留在「一问一答，哪怕加了几个 function calling」，本质都还是应用层的对话接口。只有循环跑稳、运行时撑得住，才开始像一个真正的 Agentic System。

1.2 Think–Act–Observe：可重复的五步循环

把循环翻译成工程语言，就是这五步：

1. Get Mission——拿到目标，来自用户或系统触发。
2. Scan the Scene——扫现场：用户说了什么、历史有什么、能调哪些工具。
3. Think it Through——基于目标和现场产出一个可执行计划。
4. Take Action——编排层选工具，发起一次具体的 Tool Call。
5. Observe & Iterate——把工具返回结构化、可筛选、可追踪地写回上下文，进入下一轮。

五步里最值钱的不是 Think，而是 Think 之后真的能 Act，并且 Act 的结果能被系统消费。这才叫办事。

金句：Agent 的核心不是输出更漂亮的文本，而是用一个可重复的循环把任务一步步办完。

1.3 一个客服场景把舞步跑一遍

用户问「我的订单 12345 现在到哪了」：

• Mission：给出订单状态。
• Scene：内部订单库查询、物流承运商查询两类工具可用。
• Think：三段式计划——Identify（查内部库拿运单号）→ Track（查承运商实时状态）→ Report（汇总成一句话）。
• Act + Observe：先调 find_order(12345) 拿运单号 ZYX987；再调 get_shipping_status(ZYX987) 拿到 out_for_delivery。
• 生成最终回复。

这就是 Agent 和聊天机器人的分水岭：聊天机器人会直接编一个看起来很像的答案，Agent 会先把世界查一遍再开口。

二、分级：Level 0–4 不是炫技，是系统承诺

做 Agent 最容易翻车的不是模型选错，而是一开始就把系统范围开太大，最后治理跟不上。每上一个 Level，你增加的不是能力点，而是一整套工程负担：权限面、隐私合规、可观测、责任边界都会指数级复杂。

L1 最常被低估的不是 function calling 本身，而是「把工具变成稳定契约——能调用、能处理失败、能回写上下文」；L2 真正的瓶颈往往不是模型不会想，而是上下文塞得太满，注意力被垃圾信息稀释了，导致计划漂移、工具乱调用。

金句：Level 不是炫技，Level 是你的系统承诺。先把 L1 事实闭环跑稳，再把 L2 上下文工程做扎实，最后再谈 L3 团队化和 L4 自我扩展。

三、循环：Agent 本质是 Context Window 的策展系统

3.1 上下文有六块，缺一不可

一轮 Agent 调用 LLM，喂进去的 Context 至少包含六块：

很多 Agent 不稳定，根因不是模型不行，是上下文被喂成了一锅粥。Context Engineering 做的就是把这一锅粥拆成一道道可复用的配菜。

3.2 短期记忆 = RAM，长期记忆 = 带检索的硬盘

把长期记忆做成「工具」而不是「把全文塞进 prompt」，带来两个直接收益：个性化可以持续；上下文不会爆炸。

金句：Agent 的不稳定，往往不是模型不行，是上下文被喂成了一锅粥。

3.3 编排层是状态机加调度器

编排层不是一段胶水代码，更不是简单的流程管道，它是系统的行为中枢：

• 调度：把 Think–Act–Observe 跑起来。
• 状态：管「当前任务在哪一步、已经调过哪些工具、拿到哪些字段、还缺什么」。
• 节奏：决定何时思考、何时用工具、何时降级、何时必须 Human-in-the-Loop。

工程上最常见的成功解法是混合式——关键步骤用硬规则卡口，开放区域让模型发挥。高风险动作必须 HITL 或者必须通过 Policy 校验。

四、上线：AgentOps 与防御纵深是生产线的两根支柱

4.1 AgentOps：用三段流水线把不确定性变成可控工程

传统单测「输入固定 → 输出等于预期」在 Agent 上天然不成立——Agent 的输出是概率分布，同一个输入措辞会变、步骤会变、甚至工具调用顺序都会变。要测的不是最后一句话对不对，而是整条轨迹质量是不是下降了。

加上两样武器：OpenTelemetry Traces 用来回答「为什么他选了这个工具、为什么参数这样填、为什么第三步开始偏航」；人类反馈闭环——线上一个 thumbs-down 不是噪声，是评测集缺失的证据，复现后沉淀进 Golden Set，就是给系统打了一针疫苗。

4.2 防御纵深：硬规则 + Guard Models 两道门

授权越大越有用，但风险也同步放大。主要就三类：

• Rogue Actions：自作主张做了不该做的动作，而且很多不可逆。
• 敏感数据泄露：上下文混合了用户输入、检索结果、工具返回、历史记忆，任何一段被误输出就是系统级事故。
• Prompt Injection：本质是指令被劫持——攻击者把恶意指令藏在网页、文档、邮件里，Agent 一检索一读取，就可能把攻击当成更高优先级任务执行。

两道门同时上：

从一个 Agent 走向一堆 Agent，安全就必须平台化——Agent Identity 让每个 Agent 成为可验证身份；Policy 同时管 Agent、Tools、其它 Agents、Context；Control Plane + Registry 做统一入口，所有交互都走这里，审计、授权、可观测一并接管。

金句：单体安全靠加栏杆，规模化安全靠修交通系统。

4.3 模型不是选最强，是选最合适

Agent 场景的模型选型有一条硬路径：业务目标在前，模型在后——别看哪个榜单分高就塞进系统。Agent 是 LLM-in-a-Loop，任何一轮工具调用不稳定都会把后面的轨迹带崩。所以要测的不只是「答案对不对」，而是「推理链是否稳、工具调用是否准、失败时能否恢复」。

落地三件事合起来才算 Production-Grade：权衡（质量/速度/价格）→ 多模型路由（Team of Specialists：重推理给旗舰，意图识别/摘要/抽取给便宜快的）→ AgentOps 持续评测支撑快速升级。没有稳定评测集，每次换模型都像在赌博。

一页速览

一句话收束

Agent 的「正确答案」，不是更聪明的模型，而是更克制的系统——把不确定性关进可观测、可治理、可演化的边界里。

本文是对 Google AI Agent 白皮书第一本 Introduction to Agents 的拆解。原视频出自 B 站 UP 主「碳硅同传」，五本白皮书构成的完整路线图——Day1 定义、Day2 工具与互操作、Day3 会话与记忆、Day4 质量评测、Day5 原型到生产——本文只覆盖 Day1。