背景：一家电信公司的两条 Agent 战线
AT&T 的 Agent 实践始于 2023 年上线的内网平台 Ask AT&T——起初面向软件开发者，之后扩展到客服、财务分析、供应链、门店客流分析等场景。按 Forbes 与 Moor Insights 的早期报道，其员工使用率已接近 15 万员工的三分之二；Larridin AI 影响力追踪器 2026 年 9 月的汇编显示，Ask AT&T 平台支撑 10 万以上员工、日处理约 90 亿 token（口径分歧见后文），并有 600 余个 AI/ML 模型在生产环境中运行。对客侧，AT&T 与 Google Cloud 合作，将传统「按键式」电话菜单升级为由 BigQuery 意图路由 + GECX 驱动的高上下文虚拟 Agent。
双栈是这个案例的第一个结构特征，且两个栈的供应商并不相同：内网 Ask AT&T 构建在 Microsoft Azure 上（配套 NVIDIA NeMo/NIM 微服务），对客 CX 线构建在 Google Cloud 上。一家公司同时深度使用两大云的 AI 栈，通常被解读为供应商锁定风险的对冲——但对 AT&T 而言，更务实的解释是按场景选栈：内网知识工作场景 Azure 的企业集成成熟；对客对话场景 Google 的语音与数据基础设施占优。这个「不追求统一栈」的决策本身，就值得正在做架构选型的企业参考。
两条战线、两套栈：内网线（Azure + NVIDIA 微服务）解决「员工效率」，对客线（BigQuery + GECX）解决「客户体验」。共享的不是技术栈，而是测量纪律——两边的成功都按业务结果（节省金额、自愈率、NPS）核算，而非按调用量核算。
对客线核心：路由先行——Agent 项目从分流开始
AT&T 数据科学与 AI 副总裁 Mark Austin 在 Google Cloud 官方案例中的表述，是全案最值得抄录的一句话：「当我们思考 Agent 的应用时，一切都从路由开始（it all starts with the routing first）。借助 Google Cloud，我们早已越过『按 1 转账单、按 2 转客服』的阶段。」
这句话背后是一个容易被低估的架构决策。客服 Agent 的常规叙事聚焦「对话能力」——模型多聪明、多轮理解多流畅。但 AT&T 把投资的大头放在了对话之前：BigQuery 分析客户历史数据（历史账单、使用行为、在办业务），在接入瞬间完成意图识别与分流，再交给 GECX 驱动对话。效果直接体现在官方口径的核心指标上：前端呼叫自愈率（front-end containment，即呼叫在前端被 AI 完整解决、无需转人工的比例）提升约 20%。
为什么路由先行有效？三个原因。其一，自愈率的杠杆在入口：一个客户带着「账单争议」的真实意图被错路由到「套餐咨询」分支，后面再聪明的对话模型也会失败——意图识别错了，对话能力无从发挥。其二，路由是数据问题而非模型问题：BigQuery 里的客户历史决定了路由质量，这类结构化数据资产是企业已有的，边际成本低。其三，路由错误可测量、可迭代：分流准确率是清晰可优化的指标，比「对话满意度」更容易建立反馈闭环。
60 天跨渠道记忆：被低估的体验变量
对客线的第二个关键设计是跨渠道记忆：虚拟 Agent 保留客户长达 60 天的交互历史，客户从网页转到门店再转到电话，对话上下文与业务意图可以延续。Austin 的原话是：「客户很少会立刻下单购买，但 GECX 允许我们保留 60 天的记忆，这让交互更有个人感，客户不必反复重复自己。」
这个设计回应的是客服自动化的一个经典失败模式：客户在第 3 次联系时被迫复述前两次说过的全部信息——这类体验损耗对 NPS 的杀伤力，往往大于模型答错一个具体问题。60 天窗口的价值在于把「单次会话的智能」升级为「客户关系的记忆」：客户上月的购物意图、军事折扣资格这类 eligibility 信息，都能在本次对话中被直接引用。对正在设计客服 Agent 的团队，这是一个可以直接移植的参数化决策：记忆窗口的长度应该匹配业务的决策周期，而不是模型的上下文上限——电信业务的复购与变更周期以周和月计，60 天是对业务节奏的回应而非技术炫技。
结果账本：1.5 亿美元与 ROI 5 倍的口径核对
公开渠道可核对的量化结果与口径如下：
| 指标 | 数值 | 口径与出处 |
|---|---|---|
| 前端呼叫自愈率提升 | 约 +20% | Google Cloud 官方案例视频（BigQuery 路由 + GECX） |
| 年节省金额 | 约 1.5 亿美元 | Google Cloud 官方案例视频，公司自报 |
| 整体 AI ROI | 提升至 5 倍（2025） | Google Cloud 官方案例视频；另有 Fierce Network 报道的「超过 2 倍」为更早期口径 |
| NPS | 改善（未公布具体数值） | Google Cloud 官方案例视频 |
| 内网生成式 AI 方案数 | 150+（Google 案例口径）/ 100+（NVIDIA 博客口径） | 统计时点与范围差异，本文如实并列 |
| 日 token 处理量 | 约 90 亿（Larridin 汇编，引 AT&T 官方）/ 400 亿（第三方报道口径） | 存在 4 倍以上口径差，引用需谨慎 |
| 员工覆盖 | 10 万以上（Larridin）/ 近 10 万（Forbes 报道约 15 万员工的三分之二） | 两口径基本一致 |
三点核对结论。一，1.5 亿美元年节省与 20% 自愈率提升出自 Google Cloud 官方制作案例，属公司自报数据，无独立审计——但测量方向（自愈率、节省金额、NPS）本身是正确的。二，ROI 从「超过 2 倍」到「5 倍」是时间序列而非矛盾：前者是 2024–2025 年初的报道口径，后者是 2025 年底官方案例口径，呈现的是平台规模化后的回报爬升。三，token 量口径分歧提醒我们二手汇编的危险：90 亿与 400 亿的差距大概率来自统计范围（全公司 vs Ask AT&T 平台）或时点不同，任何引用单一数字做「AI 使用量」论证的文章都应回到原始出处。
可复现打法：四步与一条测量纪律
剥开电信行业的特殊性，AT&T 案例里可迁移的方法论可以压缩为四步：
第一步：先建内网，再上对客。AT&T 的顺序是 2023 年内网 Ask AT&T，验证平台、治理与员工习惯，之后才把成熟的能力推向对客场景。对客 Agent 的错误成本（品牌伤害、合规风险）远高于内网，内网是低成本的风险练兵场。
第二步：路由先行，对话殿后。把首批工程资源投向意图识别与分流（数据侧），而非对话生成（模型侧）。自愈率的杠杆在入口，路由质量决定后续一切对话的上限。
第三步：记忆窗口匹配业务周期。跨渠道持久记忆（60 天）解决「客户重复自己」的体验痛点，窗口长度按业务复购/变更周期设定，而非技术参数拍脑袋。
第四步：按场景选栈，不追求统一。内网与对客用了两家云的栈，共享的是测量与治理标准而非供应商。选栈的单元是「场景」，不是「公司」。
测量纪律只有一条，也是全案最具普遍性的启示：用业务结果做因变量，不用 AI 用量做因变量。AT&T 公布的是自愈率、节省金额、NPS，而不是「我们处理了多少 token」——后者在第三方报道中反而出现了 4 倍口径混乱，恰好反证了用调用量当成绩的不可靠。第三方分析者在复盘这一案例时给出的概括同样适用于所有企业：问客户是否觉得聊天机器人「有创新感」没有意义，问他们有没有留下来才有意义。
把「AI 用量」（token、调用次数、对话轮数）当作过程指标监控，把「业务结果」（自愈率、解决时长、节省金额、NPS、留存）当作成果指标汇报。两套指标混用的团队，最终汇报的一定是好看但无意义的那套。
避坑与局限
- 自报数据的信任边界：1.5 亿美元、5 倍 ROI、150+ 方案均为厂商或公司自报，无独立审计；案例由 Google Cloud 制作并发布，供应商叙事的筛选偏差客观存在。复用数字时请标注口径。
- 规模即壁垒，不是起点：AT&T 的路由质量建立在多年沉淀的客户数据资产（BigQuery 中的历史账单与行为数据）之上。没有数据资产积累的团队，第一步应先补数据地基，而非直接复制「路由先行」——没有数据的路由是无米之炊。
- 双栈的隐性成本：按场景选栈的代价是两套运维、两套安全合规与两套人才结构。对多数中型企业，单栈起步、按需扩栈比一开始就双栈更务实。
- 行业特异性的边界：电信客服的高频次、强结构化特征是本案例的重要背景；低频高价值的场景（如大客户销售）中，路由先行的适用性需要重新验证。
- token 口径教训：90 亿与 400 亿的日 token 口径差提醒我们，二手汇编数据在传播中会持续放大失真，引用前必须回到原始出处核对统计范围与时点。