背景
最近翻完 Google Cloud 出的 46 页手册《The AI Agent Handbook: 10 Practical Hacks to Use AI Agents for Business》。封面那句 Work smarter, not harder 基本定了调——这是一份企业落地指南，不是技术原理文档。
里面没有 ReAct、tool use、function calling 这些底层机制的讨论，但如果你做企业 Agent 做了一段时间，会看出它比纯技术论文信息密度更高：它把 Google 整个企业 Agent 产品矩阵按场景拆给你看了。
下面是我整理出来的几条结构化观察，供同样在做 Agent 的同学参考。
一、10 个场景重新分层，才看得出 Google 的产品布局
原文是 10 个并列 case，硬看就是 10 个软文。但按"离数据远近 + 用户卷入度"重新分层，就能看出整套产品矩阵：
| 层级 | 场景 | 对应产品 | 用户角色 |
|---|---|---|---|
| 数据访问层 | 01 企业搜索 | Gemini Enterprise（含 Agentspace） | 全员 |
| 数据访问层 | 04 深度研究 | Deep Research agent | 全员 |
| 知识加工层 | 02 文档转播客 | NotebookLM | 分析师 |
| 知识加工层 | 06 营销内容 | Gemini Enterprise + 营销连接器 | 营销 |
| 决策协作层 | 03 创意生成 | Idea Generation agent | 产品/战略 |
| 决策协作层 | 05 客户体验 | Customer Engagement Suite | 客服/运营 |
| 业务流程层 | 07 销售加速 | Gemini Enterprise + CRM 连接器 | 销售 |
| 业务流程层 | 09 HR 入职 | Gemini Enterprise + HR 系统 | HR |
| 开发协作层 | 08 代码 bug | Gemini Code Assist | 研发 |
| 平台能力层 | 10 自建 Agent | Agent Gallery / Agent Designer / Vertex AI Agent Builder | 全员 + 开发者 |
关键观察：从底层往上层走，用户卷入度递增，对模型能力的要求也递增。最底层是企业搜索（不需要 Agent 推理，只要 RAG + 多模态），最上层是自建 Agent（需要 no-code 编排 + 工具调用 + 跨 Agent 通信）。
如果你做的是企业 Agent 创业，可以拿这个表当坐标：你的产品落在哪一层？同层竞品是谁？上下游卡点在哪？
二、企业搜索被定为"地基"，不是 Agent 本身
手册第一个场景不是写代码、不是营销，是企业搜索。原文明确做了切割：
"While not technically an AI agent itself, enterprise search then becomes the foundational layer for agentic AI."
这句话在工程上很关键。Agent 的能力链是 找信息 → 推理 → 决策 → 执行，第一步跑不通后面全是空中楼阁。而企业数据天然散在 Drive / 邮箱 / CRM / IT 工单 / HRIS 里，没有一个统一访问层，Agent 就只能在你接好的那一两个系统里转圈。
Google 的解法是把 Gemini Enterprise 做成统一入口 + 预置连接器 + Chrome 搜索栏这个天然入口。潜台词是：谁掌握企业数据访问层，谁就掌握企业 Agent 的分发权。
国内做企业 Agent 的同学，先别卷模型能力，先问自己三个问题：
- 你的数据底座接得全不全？
- 跨系统权限模型怎么做？
- 实时增量更新还是定时同步？
三、Multi-agent 已经是产品形态，不是论文里的实验
两个值得注意的细节：
Customer Engagement Suite（场景 05）明确写了是 multi-agent application，三个 Agent 分工：
Conversational Agents：对客户，多语言自动响应 + 复杂 case 路由Agent Assist：对客服，实时辅导 + 推荐回复Conversational Insights：对管理者，全量交互分析 + 仪表盘
Idea Generation agent（场景 03）更极端：
"uses hundreds of AI agents to generate and refine innovative ideas; and then self-scores through multi-angle evaluation"
这是 Agent-as-Judge 的规模化应用——一群 Agent 生成、另一群 Agent 互评打分、最后排序输出。这种"生成群 + 评审群"的范式，在自己做 Agent 设计时可以直接复用，比单 Agent 自评稳定得多。
四、Agent2Agent 协议被点名，是个强信号
场景 10 末尾这句话很容易被忽略：
"Gemini Enterprise supports the open Agent2Agent protocol, ensuring interoperability with not only data sources connected via Gemini Enterprise, but also agents built on other platforms."
翻译过来：Google 的 Agent 不只跟自家数据互通，还能跟别家平台造的 Agent 互通。
在 Agent 生态早期，"互操作性"看起来是负担，但中后期就是护城河。参考 K8s 之于容器编排、ONNX 之于模型交换，谁先把协议推成事实标准，谁就拿到生态定义权。A2A 协议值得长期跟踪，国内做 Agent 平台的同学建议直接参与或 mirror 一份。
五、"让做事的人造自己的 Agent"——无代码是企业级分发关键路径
场景 10 这句话我觉得是整本手册的精神内核：
"No one knows the nuances of a job as well as the people who do that job."
Google 给的三档方案：
- Agent Gallery：现成 Agent 商店，零门槛
- Agent Designer：no-code 聊天式界面，员工自己拼
- Vertex AI Agent Builder：开发者专业开发
这套打法和低代码平台下沉到业务人员一脉相承，只是粒度从"应用"细化到了"Agent"。做 Agent 平台的同学，无代码体验不是加分项，是必选项——能不能让一个 HR 自己 10 分钟拼一个"自动处理入职合同 + IT 工单"的 Agent，决定了你的产品能不能在企业里铺开。
六、几个客户案例的真数据
| 客户 | 场景 | 数据 |
|---|---|---|
| Seattle Children's Hospital | 临床路径助手 | 关键信息获取从 15 分钟降到几秒 |
| Deloitte | NotebookLM 处理市场调研 | 原本 2 周 → 几分钟出初步洞察 |
| Verizon | Customer Engagement Suite | 显著缩短通话时长 |
| Rubrik | 销售知识 Agent | 自动准备客户互动所需洞察 |
| TCS | Persona-based dev Agent | 加速软件开发 |
| UKG | HR 政策问答 Agent | HR/经理自助查询 |
共同特征：没一个吹"取代人类"，都在讲"把人从低价值环节里解放出来"。这是企业 Agent 落地的安全叙事姿势——讲放大，不讲替代。
给做 Agent 的人的 5 条结论
- 数据底座优先于模型能力：Agent 接不进企业系统、拿不到全量数据，能力再强也是花架子。
- 场景必须落到具体工作流：手册每个场景都有一个具体的"今天发生的事"——写完代码崩了、新员工入职要办 6 件事、Q1 营销 ROI 要复盘。别做"通用助手"。
- 多 Agent 协作 + Agent-as-Judge 已经是产品形态：Google 已经把它封装成 Idea Generation 卖了，不是论文里的小研究。
- 无代码是企业级分发的关键路径：让做事的人造自己的 Agent，谁先跑通谁规模化。
- 盯紧 A2A 协议：早期是负担，中后期是护城河。
没回答的问题
手册有意回避了几个工程级痛点：Agent 可解释性、跨系统权限治理、多 Agent 故障定位、长时任务的成本控制。这些是真正落地时绕不开的坑，留待后续讨论。
