背景：工具中心化部署为何失效
Pythian 是一家为企业管数据库与云基础设施的数据服务商——这个身份决定了它做 AI 试验有天然的可信度：它知道生产系统坏起来是什么样。2026 年，这家 500 人、分布在 27 个国家的公司把 Google Cloud 的 Gemini Enterprise 部署给全体员工，并把过程写成了 Google Cloud 官方客户故事。
他们在开头就否定了一种普遍模式：采购 license、把前沿模型铺给所有人、然后等待结构性价值自然出现。这条路的实际结局是工程团队去追零散的微效率——「每人每天省几分钟」的零钱级收益——而完全错过高回报的流程重构机会。Pythian 的自测结果：以结构化运营模型替代散点部署后，活跃用户参与度提升了 3 倍。
散点工具部署的回报上限是「零钱」，结构性回报来自把 AI 当作运营体系来建：策略、执行、运维三条腿缺一不可——这正是 AI Operating Model 的立论。
AI Operating Model：双 COE + XOps
框架由四个环节组成一个连续循环：
| 环节 | 职责 | 关键设计 |
|---|---|---|
| Field CTO 策略层 | 决定 AI 用在哪、不用在哪 | 从业务价值倒推场景，不从技术能力正推 |
| 工具部署层 | 把 Gemini Enterprise 等平台铺到位 | 统一入口，避免工具碎片化 |
| 双 COE 执行层 | 人的生产力 COE：面向非技术团队的采用与变革管理，做无代码智能体 流程的生产力 COE：面向核心数据平台的深度定制智能体与工作流 |
两个 COE 分工而非合并——采用推广与深度工程需要不同技能 |
| XOps 运维层 | 持续监控、提示词调优、模型漂移管理与可观测性 | 官方判断：部署智能体只占旅程的 20%，让它在生产里持续保持准确占剩下 80% |
这套结构与 2026 年多家企业的复盘相互印证：多数企业的 AI 项目不死于选型，而死于部署之后的漂移失管。XOps 把「模型会漂移、提示词会过时、数据会变形」当作常态化运维对象，是这份案例里最值得抄的部分。
场景一：数据库工单智能体（MTTR -80%）
这是四个场景中账本最硬的一个。
- 业务底数：Pythian 管理 30,000 个企业数据库，工单量大，人工分流、日志分析、runbook 编写拖慢故障解决，导致 SLA 风险与工程师倦怠。
- 实现方式：流程生产力 COE 用 ADK 2.0 在 Cloud Run 上部署智能体工作流——数据库工单创建时，Eventarc 触发器调用 ADK 智能体；智能体读取工单，经 Vertex AI Grounding 检索内部知识库，用 Gemini 2.5 Flash 在工程师打开工单之前自动生成一份 mini runbook，内含精确的诊断查询与修复步骤。
- 量化结果：应用于每月 15,000 条数据库工单，平均解决时间（MTTR）下降 80%。
注意这个设计的选择：智能体不直接修数据库，而是在人介入前把诊断材料准备好。这是典型的「先扩员能力、后放自主权」的路径——对生产数据库这类高风险标的，是比全自动修复稳妥得多的切入点。
场景二至四：供应链、零售、IT 支持
| 场景 | 原状 | 实现要点 | 自报结果 |
|---|---|---|---|
| 供应链预测匹配 | 数十个全球制造基地的预测匹配靠人工对账 ERP，周期以周计 | ADK Graph Workflows 确定性查询 BigQuery / Cloud SQL 库存，Gemini 2.5 Pro 负责差异调和与优化建模 | 70 个制造基地的预测匹配周期从数周压缩到 2-3 天 |
| 零售商品上架 | 人工录入、打标、归类，单件约 20 分钟 | ADK 智能体接商品图与供应商清单，Gemini 3.5 Flash 多模态提取元数据、生成 SEO 描述，输出严格 JSON schema 直接入库 | 20 分钟人工任务变成数秒级自动流 |
| IT 支持 | 大型咨询业务中成千上万条 IT / HR 工单年耗百万级运营小时 | ADK A2A 协议：主路由智能体把改密码、软件开通等任务分派给专用子智能体 | 10,000 名顾问、年 20,000 条 IT 工单中 10% 实现 no-touch 解决，节省超 100 万运营小时 |
三个场景代表三种编排形态：数据库工单是「事件触发 + 预加工」；供应链是「确定性查询 + 模型推理」的双层结构——把能写死 SQL 的部分写死，把需要判断的部分交给模型；IT 支持是 A2A 多智能体路由。选择哪种形态，取决于任务的确定性分布，而不是技术偏好。
参考架构：Cloud Run + Eventarc + VPC SC
案例给出的高吞吐智能体工作流参考架构有五个组件：
- Cloud Run：承载 ADK 2.0 Python 智能体的无服务器运行时，支持 GPU 加速、最大并发请求调优与 Direct VPC egress。
- Eventarc + Pub/Sub：工单事件路由，把智能体从批处理定时任务解耦为事件驱动。
- Vertex AI：Gemini 2.5 Flash 推理 + 企业知识库 grounding。
- BigQuery：结构化上下文查询。
- VPC Service Controls：零信任边界防数据外泄，隔离配额，保证确定性执行。
ADK 2.0 本身开源，支持 Python、TypeScript、Go、Java、Kotlin 五种语言，其 Graph Workflows 允许把确定性代码与自适应 AI 推理编排在同一张有向图里——这是「复杂任务走结构化图、不再用脆弱的纯提示词链」这一 2026 年共识的官方实现。
可复现六步与避坑
把 Pythian 的经验整理成可复现步骤：
- 先立 COE，再发工具：采用推广与深度工程分两个小组，避免「全员开通后无人负责转化」。
- 以自身为试验田：在自家业务上跑通再卖给客户——供应商自己不用，客户永远学不到真实经验。
- 选「单件耗时 20 分钟级」的流程任务起步：商品上架、工单预加工这类高频、规则边界清晰的任务是结构性回报密度最高的切入点。
- 确定性部分写死，判断性部分交给模型：查询、格式校验、入库用代码与 schema 约束；调和、归类、生成用模型。
- 上 XOps，别把部署当终点：漂移监控、提示词迭代、可观测性是持续预算，不是一次性交付。
- 高风险标的先做「预加工」：让智能体准备诊断与材料，人做决定——验证准确率后再逐步放权。
避坑清单：不要把工具铺开当作里程碑（那是起点）；不要合并「推广」与「工程」两个 COE（技能互斥）；不要让智能体直写生产系统（先 readonly + 预加工）。
口径批判与局限
必须说明这份账本的成色：
- 全部数字为厂商自报：MTTR -80%、3 倍活跃度、100 万小时等均来自 Google Cloud 官方客户故事与 Pythian 自述，无第三方审计；且 Pythian 是 Google Cloud 合作伙伴，存在天然的利益关联。
- 基线未披露：MTTR -80% 没有给出原始 MTTR 数值与统计周期；「100 万运营小时」是 20,000 工单 × 10% no-touch 的推算口径，其换算假设未公开。
- 工具栈单一：整套架构深度绑定 Google Cloud（Vertex AI、Cloud Run、Eventarc、BigQuery），可迁移性未讨论；ADK 2.0 虽开源，运维层 XOps 的具体工具链披露有限。
- 失败成本缺位：案例未披露试点失败率、智能体误判率与人工复核成本——这些恰是同类企业最关心的参数。
即便打上这些折扣，「双 COE + XOps + 以自身为试验田」的结构性打法仍有普适参考价值——它回答的是组织问题而非技术问题，而组织问题正是 2026 年企业 Agent 落地的首要瓶颈。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。