Uber 面向 AI 智能体的开发基础设施

在这期 2026 年 10 月的 Pragmatic Engineer 节目中，主持人 Gergely Orosz 采访 Uber 杰出工程师 Uday Kiran Medisetty，讨论公司的开发基础设施和 AI 智能体。Orosz 曾在 Uber 工作；节目有赞助商。文中的工具和数据来自嘉宾对当时 Uber 实践的介绍。

Medisetty 于 2015 年加入 Uber，当时公司正从少量服务转向微服务架构。两人介绍快速增长如何推动部署、可观测性和内部负责人查询工具的投资。

他解释说，独立的服务代码仓库使升级和构建变得困难。Uber 转向按语言划分的单体仓库，并开发云端 DevPods，让工程师在准备好的环境中工作，而不必在笔记本上配置大型构建。

在 AI 方面，团队选择设计可跨模型和智能体运行框架使用的基础模块。模型网关提供兼容的 API，并集中处理政策控制和可观测性等方面；这些控制仍需要适当的实现与审阅。

Medisetty 说，MCP 网关向智能体提供内部工具，并利用已有的服务接口定义帮助生成工具规范。共享 skills 仓库在不同运行框架之间提供可复用工作流和质量检查。

内部上下文图谱连接原本分散在代码仓库、负责人记录、事件和其他系统中的工程信息。目标是帮助智能体与工程师用更少步骤找到相关上下文；图谱的效果取决于底层数据与权限。

两人讨论产品和工程需求，以及智能体与人围绕共享计划协作的可能性。Medisetty 说，该工作流的不同部分成熟程度不同。

Uber 的后台编码智能体 Minion 可以根据规范工作、使用云开发环境，并跨仓库创建 pull request。Medisetty 称当时约 15% 的生产 pull request 经过该工具；这个数字不能证明更改是完全自主的或经过独立验证。

讨论从生成代码延伸到测试和审阅：一致的构建命令有助于智能体，团队也在处理 CI 修复和审阅瓶颈。开发与测试环境仍是工作流的重要组成部分。

Medisetty 介绍 Edge Gateway 和流量捕获回放工具如何帮助理解请求、依赖关系和可靠性。这些上下文可以帮助工程师和智能体调查问题。

展望未来，他将工程工作描述为在功能的整个生命周期中寻找下一个瓶颈。他认为这种转变仍在进行，周边工具与编排必须随模型一起发展。