Uber 的 AI 基础设施，从内部看

这场 Pragmatic Engineer 访谈的主线，不是 Uber 突然做出一个编码运行框架。Udai 描述，在智能体工具出现之前，团队已经多年投入服务基础设施、语言标准化、归属记录、测试、部署与可观测性。

这些建设最初是为了支持跨产品、跨地区的业务，后来也给智能体提供了有结构的工作对象。这个案例说明基础的价值，而不是证明每家公司都该重建 Uber 的内部技术栈，或者换一个聊天入口就能得到相同结果。

Udai 把按语言组织的单体仓库、统一构建系统，与 Dev Pods 联系起来：仓库、工具和缓存已经准备好的云端环境。更大的智能体环境还能跨仓库工作，不必反复摸索配置步骤。

重要杠杆是可重复性。人和智能体能使用已知的构建、测试命令，顶层说明解释共同约定。快速创建环境，依赖提前准备的镜像和预热基础设施，而不是智能体神奇地跳过了依赖与构建工作。

访谈描述了一个模型网关：以项目身份和调用方凭据为基础，对外提供兼容接口，不同模型供应方放在接口之后，同时接入策略检查、可观测性和计费归因。

AI Guard 被介绍为共同的请求与响应控制层，支出归因和审计追踪则帮助团队理解使用情况。这些是对保障机制的描述，不是证明所有敏感内容或每一种攻击都能被完美拦截。设计价值在于，模型变化时仍有一致位置应用并改进控制。

围绕不同编码运行框架的包装层，把共同插件、技能与用户配置带到本地和云端环境。目标是让工具切换不必依赖每位工程师重新搭建个人配置。

成本仍然可见。Udai 描述了支出层级、工具内反馈，以及需要更多额度时与管理者进行的轻量讨论。这把访问能力与投入产出判断结合起来，而不是把无限消耗 token 当作进步指标。交互工具和托管后台智能体，也可以有各自预算。

Uber 的 MCP 网关建立在已有服务契约注册表之上。访谈描述，从 Thrift 或 Protocol Buffers 定义生成工具结构，改善说明，再把自定义工具或供应方工具放到同一入口之后。

CLI 投影让运行框架可以选择另一种交互形式，而不必由每个团队重做底层集成。自动生成不等于自动授权：开放工具之前，配置和安全策略仍然重要。这个案例的一部分优势，正来自提前拥有结构化契约和网关经验。

共享技能仓库把中央平台能力与团队流程放在一起，使用共同安装方式和质量关口。工具访问可移植，能帮助同一个工作流跨运行框架延续。

Udai 区分了做出第一版与让技能在多场景下可靠。基于追踪的改善和评测仍在持续建设，使用量并不能保证质量。把合适的交互改为 CLI，被介绍为减少无谓上下文负担的方法，而不是某种协议永远更优的普遍结论。

图谱连接人员、资产、文档、变更和运营记录。助手可以先通过关系定位相关领域或负责人，再继续读取回答问题所需的实际文档、查询或服务信息。

画面中较多的节点类型和边类型，描述的是类别，不是记录总数。Udai 报告了质量、成本和延迟方面的收益，但访谈并不是独立基准测试。他也明确说，现有用户权限会延续：连接图谱不等于无边界访问所有人的数据。

设计文档与批准记录，为人和智能体提供关于预期功能的可信来源。Minion 被描述为后台编码智能体，可以根据范围明确的规格跨仓库产出改动，也能通过聊天获得进一步指导。

生成之后，构建规则、lint 和视觉验证等检查会前移到内部循环。Code Inbox 则把证据归拢给审查者。演示包含模拟界面和仍在建设的内容；尤其重要的是，Udai 说录制时每个生产 PR 仍需要工程师审查。可能的低风险绿色通道是未来工作，不是当前规则。

Slate 让工程师把分支部署到测试环境，再把选定测试账号路由到被测服务，其他调用则使用周围的 staging 系统。追踪附带信息与服务网格路由，帮助这个决定跨服务边界传播。

智能体于是能使用相同配置，对比主分支与工作分支，并附上截图、视频或 API 证据。这是具体反馈循环，不是证明所有可能的回归都不存在。系统经历了多年埋点与兼容工作，智能体演示中看似轻松的操作，依赖这些先前投入。

63:00查看原图

捕获与重放系统记录请求、响应及下游交互，再标注相关维度，让团队对比变更前后的行为。某个具体问题可以在分支上重放，更广的已观察组合也有助于暴露意外差异。

已观察到的组合，并不等于所有逻辑上可能的状态。公开架构演示也不能确立每份载荷具体怎样脱敏、保留和授权。值得学习的原则是可复现与受控比较，而不是拿生产私人用户数据临时充当测试样本。

Shepherd 把大规模改动组织为活动：适合机械转换的部分用规则处理，需要更多判断的部分交给智能体。Fox 则把类似思路延伸到已登记服务的周期性维护提案，相关技能在描述时仍处于主动加入阶段。

Wisdom 提供另一条路径：员工报告的问题附带遥测和复现背景，助手提出根因，人检查后再把诊断交给编码智能体。这些循环产出可审查的工作和证据，并不意味着每个清理提案或诊断都正确、已经合入，或无需验证就安全。

Udai 描述，生产力讨论正在从变更数量扩展到功能周期、工作类别、开发者体验和质量信号。连接计划、任务与改动，是为了弄清真正的延迟在哪里。

访谈没有给出生产力提升的受控因果估计。结尾的转变更具体：工程师越来越多地设计背景、约束、工具和验证路径，让智能体能够可靠工作。目标仍是有用的业务结果，以及人工检查和持续测量，而不是为了生成物本身增加产量。