先接数据，再谈智能：企业 Agent 的"地基"其实是一条知识管道

很多团队做 Agent 的第一反应是换模型。但翻完 Google Cloud 那份 46 页的《The AI Agent Handbook: 10 Practical Hacks to Use AI Agents for Business》，再看国内这两天的技术讨论，会发现真正卡住落地的东西，往往在模型之外——在数据怎么进来这一层。 一、把 10 个场景重新分层，才看得出产品布局 手册原文列的是 10 个并列案例，硬读像 10 篇软文。但如果按"离数据远近 + 用户卷入度"重新排一次，整套产品矩阵就浮出来了： · 数据访问层：企业搜索（Gemini Enterprise）、深度研究（Deep Research agent） · 知识加工层：文档转播客（NotebookLM）、营销内容生成 · 决策协作层：创意生成（Idea Generation agent）、客户体验（Customer Engagement Suite） · 业务流程层：销售加速、HR 入职 · 开发协作层：代码 bug 修复（Gemini Code Assist） · 平台能力层：自建 Agent（Agent Gallery / Agent Designer / Vertex AI Agent Builder） 从下往上走，用户卷入度递增，对模型能力的要求也递增。最底层是企业搜索，它几乎不需要 Agent 推理，只要 RAG 加多模态；最上层是自建 Agent，需要无代码编排、工具调用和跨 Agent 通信。 如果你的产品落在某一层，这张表就是个坐标系：同层竞品是谁，上下游卡点在哪，一目了然。 二、企业搜索被明确切成"地基"，而不是 Agent 本身 手册第一个场景不是写代码、不是做营销，而是企业搜索。原文做了很清楚的切割： > "While not technically an AI agent itself, enterprise search then becomes the foundational layer for agentic AI." 这句话在工程上很关键。Agent 的能力链是"找信息 → 推理 → 决策 → 执行"，第一步跑不通，后面全是空中楼阁。而企业数据天然散在网盘、邮箱、CRM、IT 工单、HR 系统里，没有统一访问层，Agent 就只能在你已经接好的那一两个系统里打转。 国内团队在讨论 Agent 能力时，第一个该问的其实不是"用哪个模型"，而是这三个问题： 1、你的数据底座接得全不全？ 2、跨系统的权限模型怎么做？ 3、数据是实时增量更新，还是定时同步？ 三、知识管道的第一步，是承认"提取一定有损" 掘金上那篇《走进 AI Agent 第四篇：知识获取管道——RAG 基础》把这个环节讲得很实在。它讨论多模态信息提取时给了一个很务实的分法：提取为文本是一条低成本路径——先用 OCR 服务、音频转录服务把非文本内容转成纯文本，再输入语言模型。 作者对这种做法的评价是"模块化和成本效益的设计哲学"：可以把任何多模态任务转化为纯文本任务，兼容所有语言模型，提取出的文本还能缓存和复用。代价也写得很坦率——上下文信息的损失，所有版式、图表、图像信息都在提取过程中被丢弃。 这一点值得反复提醒自己：知识管道不存在"最好的那一条"，只存在"按查询类型分派的那一条"。合同、表格、设计稿这类强版式内容，如果一律降级成纯文本，丢掉的恰恰是回答问题所需的信息；而会议录音、公告、说明文档这类本来就以文字为主的内容，硬上多模态只会把成本推高好几倍。 换句话说，把什么都往向量库里塞，不是管道设计，是管道偷懒。 四、无代码不是加分项，是企业级分发的必选项 手册里有一句话，我觉得是整份文档的精神内核： > "No one knows the nuances of a job as well as the people who do that job." 配套给了三档方案：Agent Gallery（现成 Agent 商店，零门槛）、Agent Designer（无代码聊天式界面，员工自己拼）、Vertex AI Agent Builder（开发者专业开发）。 它给的客户案例也都在讲同一件事——把人从低价值环节里解放出来。Seattle Children's Hospital 的临床路径助手把关键信息获取从 15 分钟压到几秒；Deloitte 用 NotebookLM 处理市场调研，原本两周的工作变成几分钟出初步洞察。没有一个是"取代人类"的叙事。 五、Multi-agent 已经是产品形态，A2A 值得长期跟踪 两个细节值得单独拎出来。 一是 Customer Engagement Suite 被明确定义为 multi-agent application，三个 Agent 分工：Conversational Agents 面向客户做多语言响应与复杂 case 路由，Agent Assist 面向客服做实时辅导与回复推荐，Conversational Insights 面向管理者做全量交互分析。 二是创意生成场景里那句原文： > "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 设计的团队可以直接借用。 还有一句很容易被忽略的话： > "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." 意思很直白：不只跟自家数据互通，还能跟别家平台造的 Agent 互通。在生态早期，"互操作性"看起来是负担，中期往后就是护城河。参考 Kubernetes 之于容器编排、ONNX 之于模型交换——谁先把协议推成事实标准，谁就拿到生态定义权。 六、可以带走的东西，和手册没回答的问题 把上面这些收一下，大致是五条： 1、数据底座优先于模型能力。Agent 接不进企业系统、拿不到全量数据，能力再强也是花架子。 2、场景必须落到具体工作流。每个场景背后都有一件"今天正在发生的事"，别做"通用助手"。 3、多 Agent 协作 + Agent-as-Judge 已经是可买到的产品形态，不是论文里的实验。 4、无代码体验决定了能不能规模化铺开。 5、盯紧 A2A 协议。 手册也有意回避了几个真问题：Agent 可解释性、跨系统权限治理、多 Agent 故障定位、长时任务的成本控制。这四条才是真正落地时绕不开的坑，也是所有做企业 Agent 的团队早晚要自己填的空白。 参考链接 · 拆解 Google《AI Agent Handbook》：企业级 Agent 的六层架构与产品矩阵：https://juejin.cn/post/7687151813254021154 · 走进 AI Agent 第四篇：知识获取管道——RAG 基础：https://juejin.cn/post/7687422041256689691