Uber 如何用 AI 做开发：内部实况揭秘

Uber 如何用 AI 做开发：内部实况揭秘 Uber 如何用 AI 做开发：内部实况揭秘 Modified March 13 新的内部开发工具 随着 AI 智能体使用量的增长，开发者的工作性质也发生了变化： • 开发者花在规划上的时间更多了 • 代码审查的工作量增加了——因为 AI 智能体生成了更多代码，尽管开发者普遍并不特别喜欢审查代码 • 开发者的上下文切换明显变多了——因为要同时管理多个智能体，还要审查更多 PR 开发者们开始被来自智能体的代码审查请求淹没。Uber 的开发者体验团队为此打造了一个叫 Code Inbox 的工具： Uber's Code Inbox Uber 的 Code Inbox Code Inbox 会筛选出需要开发者关注才能推进的 PR，隐藏那些正在等待其他人处理的。 智能分配 是团队投入大量精力打造的一项功能，它会自动识别最适合审查代码的人选： Smart assignment settings for Code Inbox Code Inbox 的智能分配设置 使用的信号包括： • 所有权： “这段代码归哪个团队？” • 合规要求： “代码库的哪些部分需要特定人员或团队的签字？” • 变更历史： “最近谁改动过代码库的这个部分？” • 时区： “哪些开发者所在的时区能在接下来几小时内响应？” • 日历空闲： “哪些开发者有空闲时间可以合理安排审查？”这个功能还会考虑开发者日历中的专注时间设置，避免把审查请求分配给正在进行深度工作的工程师。 然后工具通过服务级别目标（SLO，对服务响应时间等指标设定的承诺标准）来保持流程推进：如果被分配的开发者在规定时间内没有响应，就自动重新分配给下一个人。必要时还可以逐级上报。 在 Code Inbox 中，每个 PR 都有一个影响评估。工具会尝试标记高风险的变更： Risk profile highlighting in Code Inbox Code Inbox 会评估代码变更的风险等级并重点标注 高影响变更可能包括：部署到关键服务的（Uber 根据影响范围将服务从 Tier 0 到 Tier 3 分级，Tier 0 最关键）、涉及分级发布的、跨多个服务的变更等。 提醒开发者注意高影响变更，能促使他们更加认真地对待，考虑找更多人审查，或者制定更周密的发布计划——对于风险特别高的变更，还可以设置实验来验证。 Uber 试用过 CodeRabbit、Graphite 等 AI 代码审查工具，但发现它们无法捕捉到大量的内部上下文。于是，Uber 自建了内部 AI 代码审查工具 uReview： How uReview works uReview 的工作原理 它的工作方式是这样的： • 多个智能体生成评论： 各种专用 AI 智能体——比如“通用缺陷检测机器人”、“最佳实践机器人”，或者运行 MCP 服务器的机器人——会生成评论。外部代码审查工具也可以接入这个系统。 • 评论评分： 过滤掉低置信度的评论。 • 评论合并： 减少噪音。 • 评论分类： 移除不重要的类别。 开发者平台团队追求只输出高质量评论，这个方向对了。市面上很多工具生成了大量评论，大部分是噪音。输出低质量评论是最糟糕的做法：开发者会直接忽略所有评论，连真正重要的也一并错过。 开发者可以对 AI 生成的评论进行有用性评分，这既帮助衡量工具质量，也推动改进： All AI comments can be rated by usefulness 所有 AI 评论都可以被评价有用性 自去年年中上线 uReview 以来，PR 收到的评论略有增加——但机器人评论仍然只占人工评论的一小部分。而且由于团队更注重评论质量而非数量，机器人评论数量还在逐步下降： Comments per pull request over time PR 评论数量随时间的变化。目前机器人评论与人工评论的比例约为 1:4 代码审查之外，测试同样是 AI 能发挥作用的领域。在 Uber 这样的公司，验证系统正常运行一直至关重要——Uber 向来有着完善的自动化测试体系。 为了改进验证方式，团队打造了一个新工具 Autocover [5] ，专门生成单元测试。这个工具基于 Uber 内部的 LangFX SDK 构建，Uber 发现用它生成的单元测试质量优于 Claude Code 等现成产品。 如今，Uber 每月通过 Autocover 生成超过 5000 个单元测试（!!）。根据团队自己的衡量标准，这些测试的质量大约是外部工具生成的测试的 3 倍。 团队担心生成低质量的测试，于是专门打造了一个“评审引擎”来检查生成的单元测试。这个工具后来发展成了一个独立的测试验证服务——现在开发者无论是手写的还是 AI 生成的单元测试，都可以获得自动化的质量评审。 在所有重复劳动中，大规模代码迁移是最复杂的一类。没人喜欢做迁移，在开发者看来这纯粹是浪费时间，而且往往旷日持久——动辄数月，甚至数年。 Uber 打造了一个名为 AutoMigrate 的工具来辅助大规模迁移，大量依赖 AI 工具。这个系统有几个层次： 1. 问题识别器： 评估迁移的风险，审查迁移策略。 2. 代码转换器： Uber 有多种迁移工具，如 Piranha [6] 、OpenRewrite [7] ，或者直接使用智能体。 3. 验证层： 一组工具用于验证变更的正确性。 4. 迁移管理器（Shepherd）： 这个工具生成 PR、高效地将 PR 路由给审查者、在 Code Inbox 中放到合适的位置，并帮助追踪工作进度。 新的内部开发工具 随着 AI 智能体使用量的增长，开发者的工作性质也发生了变化： • 开发者花在规划上的时间更多了 • 代码审查的工作量增加了——因为 AI 智能体生成了更多代码，尽管开发者普遍并不特别喜欢审查代码 • 开发者的上下文切换明显变多了——因为要同时管理多个智能体，还要审查更多 PR 开发者们开始被来自智能体的代码审查请求淹没。Uber 的开发者体验团队为此打造了一个叫 Code Inbox 的工具： Uber's Code Inbox Uber 的 Code Inbox Code Inbox 会筛选出需要开发者关注才能推进的 PR，隐藏那些正在等待其他人处理的。 智能分配 是团队投入大量精力打造的一项功能，它会自动识别最适合审查代码的人选： Smart assignment settings for Code Inbox Code Inbox 的智能分配设置 使用的信号包括： • 所有权： “这段代码归哪个团队？” • 合规要求： “代码库的哪些部分需要特定人员或团队的签字？” • 变更历史： “最近谁改动过代码库的这个部分？” • 时区： “哪些开发者所在的时区能在接下来几小时内响应？” • 日历空闲： “哪些开发者有空闲时间可以合理安排审查？”这个功能还会考虑开发者日历中的专注时间设置，避免把审查请求分配给正在进行深度工作的工程师。 然后工具通过服务级别目标（SLO，对服务响应时间等指标设定的承诺标准）来保持流程推进：如果被分配的开发者在规定时间内没有响应，就自动重新分配给下一个人。必要时还可以逐级上报。 在 Code Inbox 中，每个 PR 都有一个影响评估。工具会尝试标记高风险的变更： Risk profile highlighting in Code Inbox Code Inbox 会评估代码变更的风险等级并重点标注 高影响变更可能包括：部署到关键服务的（Uber 根据影响范围将服务从 Tier 0 到 Tier 3 分级，Tier 0 最关键）、涉及分级发布的、跨多个服务的变更等。 提醒开发者注意高影响变更，能促使他们更加认真地对待，考虑找更多人审查，或者制定更周密的发布计划——对于风险特别高的变更，还可以设置实验来验证。 Uber 试用过 CodeRabbit、Graphite 等 AI 代码审查工具，但发现它们无法捕捉到大量的内部上下文。于是，Uber 自建了内部 AI 代码审查工具 uReview： How uReview works uReview 的工作原理 它的工作方式是这样的： • 多个智能体生成评论： 各种专用 AI 智能体——比如“通用缺陷检测机器人”、“最佳实践机器人”，或者运行 MCP 服务器的机器人——会生成评论。外部代码审查工具也可以接入这个系统。 • 评论评分： 过滤掉低置信度的评论。 • 评论合并： 减少噪音。 • 评论分类： 移除不重要的类别。 开发者平台团队追求只输出高质量评论，这个方向对了。市面上很多工具生成了大量评论，大部分是噪音。输出低质量评论是最糟糕的做法：开发者会直接忽略所有评论，连真正重要的也一并错过。 开发者可以对 AI 生成的评论进行有用性评分，这既帮助衡量工具质量，也推动改进： All AI comments can be rated by usefulness 所有 AI 评论都可以被评价有用性 自去年年中上线 uReview 以来，PR 收到的评论略有增加——但机器人评论仍然只占人工评论的一小部分。而且由于团队更注重评论质量而非数量，机器人评论数量还在逐步下降： Comments per pull request over time PR 评论数量随时间的变化。目前机器人评论与人工评论的比例约为 1:4 代码审查之外，测试同样是 AI 能发挥作用的领域。在 Uber 这样的公司，验证系统正常运行一直至关重要——Uber 向来有着完善的自动化测试体系。 为了改进验证方式，团队打造了一个新工具 Autocover [5] ，专门生成单元测试。这个工具基于 Uber 内部的 LangFX SDK 构建，Uber 发现用它生成的单元测试质量优于 Claude Code 等现成产品。 如今，Uber 每月通过 Autocover 生成超过 5000 个单元测试（!!）。根据团队自己的衡量标准，这些测试的质量大约是外部工具生成的测试的 3 倍。 团队担心生成低质量的测试，于是专门打造了一个“评审引擎”来检查生成的单元测试。这个工具后来发展成了一个独立的测试验证服务——现在开发者无论是手写的还是 AI 生成的单元测试，都可以获得自动化的质量评审。 在所有重复劳动中，大规模代码迁移是最复杂的一类。没人喜欢做迁移，在开发者看来这纯粹是浪费时间，而且往往旷日持久——动辄数月，甚至数年。 Uber 打造了一个名为 AutoMigrate 的工具来辅助大规模迁移，大量依赖 AI 工具。这个系统有几个层次： 1. 问题识别器： 评估迁移的风险，审查迁移策略。 2. 代码转换器： Uber 有多种迁移工具，如 Piranha [6] 、OpenRewrite [7] ，或者直接使用智能体。 3. 验证层： 一组工具用于验证变更的正确性。 4. 迁移管理器（Shepherd）： 这个工具生成 PR、高效地将 PR 路由给审查者、在 Code Inbox 中放到合适的位置，并帮助追踪工作进度。 The web interface of Shepherd Shepherd 的 Web 界面 下面是 Shepherd 利用智能体平台 Minion 生成 PR 的一个实例。这次 Shepherd 的任务是识别和修复性能问题。以下是它生成的一个 PR 示例： Shepherd pull request diff part 1 Shepherd 使用 Minion AI 智能体生成 PR。生成的 diff（PR）第一部分 Shepherd pull request diff part 2 Shepherd 使用 Minion AI 智能体生成 PR。生成的 diff（PR）第二部分，包含代码变更 落地挑战 Uber 的开发者平台团队还面临着一系列非技术性的挑战，这些挑战并非 Uber 独有： 领先供应商变化很快。 在不同任务上“最好的”模型换得相当频繁，各家供应商的能力也在不断变化。自建还是采购的决策因此也在不断变化，需要定期重新评估。 构建内部 AI 基础设施是一项长期项目和投入。 Uber 投入了数十名工程师来搭建本文介绍的这些系统。不可能突然换方向，所以选择必须明智！Uber 的开发团队在两方面力求精明： 1. 搭建正确的抽象层。这样将来如果新的供应商表现更好，就能方便地整合进来。Minion 就是这种思路的好例子——新模型如果性能更优，可以轻松接入。 2. 不要被自建系统绑死。要假设公司外部可能出现更好的方案，到了一定时候，淘汰内部系统、换用更强的第三方产品是完全合理的。 将 AI 接入“老旧”系统很棘手。 让 MCP 与一些真正的遗留系统集成花了大量功夫，而且这个工作量很容易被低估。 AI 的落地速度比很多人预期的要慢。 Uber 算是很有前瞻性的公司了，但他们仍然觉得 AI 落地进程比预想的慢。Anshu 这样说： "（落地慢的）部分原因是我们在要求开发者做他们并不习惯的事。他们习惯了看代码、从零开始写代码、习惯了在 IDE 里操作。而现在我们在告诉他们，去冒险尝试一种完全不同的工作方式。 我们试过不同的策略来推动： 我们试过自上而下的方式——由领导层发指令说'你们必须做 X、Y、Z，必须采用。'效果嘛…… 有一些 。 真正有效的做法其实是分享成功案例。 当我们把不同工程师尝试的酷做法和取得的成果分享出来时，技术的采纳率一下子就爆发了。所以现在我们主推的策略就是'分享成功案例'。 工程师信任工程师——而不是像我这样的总监！" 数据说话 Uber 收集了数据来追踪 AI 的使用效果。以下是他们看到的情况： • 92% 的开发者每月至少使用一次智能体。 绝大多数开发者每月都会用到某种智能体。 • 84% 的 Uber 开发者是智能体化编程用户： 使用命令行智能体，或在 IDE 中发起的智能体请求多于 Tab 补全。 • 65 72% 的代码由 AI 生成 ，这是 IDE 工具中的数据。虽然不能完全直接对比，但 Anthropic 公布的数据是约 80% 的代码由 AI 生成，OpenAI 约为 70%。 • Claude Code 的使用率三个月内几乎翻倍 ，从 2025 年 12 月的 32% 涨到 2026 年 2 月的 63%，而 IDE 工具（Cursor、IntelliJ）的使用率已趋于平稳。 • 11% 的 PR 由 AI 机器人生成。 也就是说 89% 的 PR 仍由开发者提交。 • 净推荐值（NPS，衡量用户满意度的指标，正值表示推荐者多于批评者）创历史新高。 Uber 定期调查开发者对开发环境的满意度。这一数值达到了历史最高的 10.9，比一年前（当时是 3）提升了 13 个点。这意味着“推荐者”多于“批评者”。对于开发者平台来说，这已经相当高了——虽然放在消费类产品中不算特别突出。 • 平均每周节省约 4 小时。 这是工程师自报的 AI 工具节省时间数据。这个数字与开发者体验专家 Laura Tacho 分享的 [8] 行业平均值非常接近。 • 部分功能的发布速度大大加快。 从案例来看，Uber 有好几次发布创造了速度纪录，达到了没有这些工具很难实现的速度。 Uber 将每月使用 AI 工具至少 20 天的开发者定义为“重度用户”。重度用户的比例在去年 11 月前后飙升——当时更强大的模型发布了，Uber 也推出了 Minion： AI power users growth at Uber 目前，公司内 32% 的开发者属于“重度用户”。Uber 发现了重度用户和非重度用户之间的有趣差异。AI 重度用户： • 比非重度用户多提交 30% 的 PR • 比完全不用 AI 的用户多提交 52% 的 PR 当然，PR 数量 不是 目标——这只是一个关于提交频率和 AI 使用情况的有趣观察。实际上，要准确衡量 AI 的真实业务影响并不容易。Anshu 的反思是： "问题在于，这些数据都是 活动指标 。它们不一定代表业务成果。 当我们开始谈论这项技术的成本时，我们的 CFO 问我：效果到底怎么样？ 我不能拿 diff 的数量去跟他说，我需要展示的是对营收的影响。 我相信（所有担任工程管理职位的人）都面临着同样的问题。这对我们来说也不是一个已经解决的问题。 我们今年的一个策略是在整个功能基础设施中打点计时——从设计创建的那一刻，到实验在生产环境上线，然后看看我们能多大程度上加速这条流水线。" AI 相关成本自 2024 年以来增长了 6 倍，Token 成本正在成为一个令人担忧的问题。 Uber 内部有共识认为这项技术在发挥积极作用，但在工程团队能够证明 业务 影响之前，增加 AI 工具开支需要 CFO 的批准。 Uber 现在开始关注平衡 Token 成本，对那些用不着昂贵模型的任务使用更便宜的模型。Anshu 说： "我们不得不更谨慎地使用 Token，思考什么模型适合什么任务，然后帮助开发者选择合适的模型。还是以 Minion 为例——我们帮助开发者选用合适的模型来制定项目计划，然后用成本更低但仍然很有效的模型来执行具体工作。 我们不想让开发者操心这些，而是希望基础设施能替他们决定——这样既减少了他们的摩擦，也优化了我们的成本。" 几点感受 看完 Uber 内部的 AI 智能体系统，几点感受。 大公司要真正落地 AI，背后需要大量“看不见”的平台工作。 Uber 围绕 AI 智能体搭建的新系统数量超出预期：MCP Gateway、Uber Agent Builder、AIFX CLI、Minion、uReview、AutoMigrate 等等。 其中一些是为了让 AI 供应商的使用更加标准化（如 Minion、MCP Gateway），一些是让非开发人员也能使用 AI 智能体（Agent Builder），还有一些是帮助工程师更简单地搭建智能体环境（AIFX CLI）。 Anshu 认为要说服团队投入精力做这些内部工具，并不总是容易的事。 如果你所在的公司还没做这方面的投入，Uber 的做法或许能提供一些启发。 AI 模型和供应商的更替非常频繁，没有完美的应对之策。 AI 模型不断变强，供应商的排名在“落后”与“领先”之间反复横跳。这对竞争是好事，但对大公司来说是个持续的挑战。想让开发者随时用上最新最强工具的团队，就得不断重新评估模型和工具，有时候甚至需要淘汰自研平台，换用外部供应商的工具。 Ty 和 Anshu 都表示，如果外部供应商比自研方案更强，他们愿意退役内部平台。这种务实态度在大公司里并不常见。 软件工程师的角色正在改变：至少每个人都要像 Tech Lead 一样工作了。 在 Uber 内部，工程师管理多个 AI 智能体已经变得越来越常见，他们开始承担以前只有技术负责人（Tech Lead）才有的职责。有意思的是，Uber 工程团队的这一观察，和我自己在今年 1 月对软件工程师角色变化的预测不谋而合。在那篇深度分析《当 AI 写了几乎所有代码，软件工程会怎样？》 [9] 中，我写道： "Tech Lead 特质几乎必然会更加抢手。当 AI 能实现任何定义清晰的任务时，谁来写那个让 AI 正确生成代码的任务描述？ 非技术人员可以为面向用户的工作写出详细的任务描述，但他们几乎不可能准确表达非功能性需求——而这恰恰是软件工程知识越来越关键的地方。同时，那些既能与用户共情、又能把工作拆解成定义清晰的任务的实战型工程师，在这个新世界里会更加抢手。而这种能力恰好是优秀 Tech Lead 已经具备的。唯一的变化是，即使是入门级工程师，如果想在编程方面更快成长，也需要掌握这项能力。" 成本是一个日益严峻的问题，对 AI 成本的担忧可能只是一个趋势的开端。 AI 的支出正在急剧攀升。就在今天，Anthropic 发布了一个新工具 Claude Code Code Review，声称对自家工程团队很有帮助。但运行成本 [10] 高达每次 PR 审查 15 25 美元，差不多是其他 AI 代码审查工具 每月 的收费水平。这样的定价可能再次迫使工程管理者为更高的 AI 账单做出合理化解释，却拿不出使用这个更贵的 AI 工具能创造更多营收的证据。 引用链接 [1] Ty Smith: https://www.linkedin.com/in/tyvsmith/ [2] Anshu Chada: https://www.linkedin.com/in/anshuman chadha 8ab58717/ [3] 揭秘了: https://youtu.be/i1tZN41VKcE [4] Michelangelo: https://www.uber.com/en NL/blog/michelangelo machine learning platform/ [5] Autocover: https://x.com/LangChain/status/1932493346498543898?s=20 [6] Piranha: https://github.com/uber/piranha [7] OpenRewrite: https://docs.openrewrite.org/ [8] 分享的: https://newsletter.pragmaticengineer.com/i/189035949/1 data vs hype how orgs actually win with ai [9] 《当 AI 写了几乎所有代码，软件工程会怎样？》: https://newsletter.pragmaticengineer.com/p/when ai writes almost all code what [10] 运行成本: https://x.com/claudeai/status/2031088175456903667?s=20 🔗 原文链接： https://mp.weixin.qq.com/s/vrb idU0... https://mp.weixin.qq.com/s/vrb idU0... 原创 Gergely Orosz Gergely Orosz 宝玉AI2026年3月13日 13:55 美国 3 月 11 日更新：Uber 团队分享了截至 2026 年 3 月的最新数据： • 84% 的 Uber 开发者已在使用智能体化编程 （使用命令行智能体，或在 IDE 中发起的智能体请求多于 Tab 补全） • 65 72% 的代码由 AI 生成 ，这是 IDE 工具中的数据。 对于 Claude Code 这类 AI 命令行工具，这个数字自然是 100%。 • Claude Code 的使用率三个月内几乎翻倍 ，从去年 12 月的 32% 涨到今年 2 月的 63%，而 IDE 工具（Cursor、IntelliJ）的使用率已趋于平稳。 本文已更新为最新数据。 Uber 飞速经历了从小型创业公司到超高速增长，再到在疫情中面临存亡危机（网约车业务一度几近崩溃）的整个历程。如今，它已成为一家成熟的上市盈利公司，技术团队接近 3000 人。 在旧金山举办的 Pragmatic Summit 上，最引人入胜的幕后分享来自 Uber 首席工程师 Ty Smith [1] 和工程总监 Anshu Chada [2] 。他们揭秘了 [3] Uber 在 AI 工具方面的内部实践——坦诚地讲述了搭建内部“AI 技术栈”花了多少功夫、为什么这些投入必不可少，也没有回避这项快速扩散的技术带来的弊端。 你可以在这里观看他们在 Pragmatic Summit 的演讲。 AI 对 Uber 来说并不新鲜，但在全公司范围内推广却是一件新事。Uber 很早就在许多系统中使用了机器学习和 AI 技术，包括负责司机与乘客匹配、需求预测等功能的 Marketplace 平台。但对几乎所有科技公司来说，将 AI 融入整个工程团队乃至更广泛的业务部门，都还是一个相对全新的过程。 Anshu Chada at Pragmatic Summit Anshu Chada 在 Pragmatic Summit 上 这家网约车巨头的官方策略是成为一家“GenAI 驱动”的公司： Uber's company strategy now explicitly includes AI Uber 的公司战略现已明确包含 AI Uber 愿意公开分享这一策略，这点难得。大多数公司都说自己要做“AI 驱动”，但不是所有公司都拿得出这样的透明度。 工程师应该认真理解管理层怎么看 AI 这件事。 高管们普遍把 AI 视为一种能在方方面面提升效率的工具。AI 在某种程度上和当年的云计算类似。云计算被认为是降低成本、提升硬件资源灵活性和弹性的手段。今天，AI 被视为提升效率和降低成本的工具，客服、研发、财务都适用。 Uber 并不想用 AI 自动化工程中的一切，而是聚焦于两件事： 1. 消除重复劳动（toil）：让 AI 来做升级、迁移、简单 bug 修复等“无聊”工作。 2. 释放工程师的精力，让他们专注于更有创造力的工作。 Uber 开发者平台工程总监 Anshu Chada 这样说： “我们发现，当把那些无聊的活儿——升级、迁移、修 bug——交给 AI 之后，工程师们的满意度大幅提升。不仅如此，他们还能以我们此前想都不敢想的方式去推进产品、为终端用户创造新功能。” Ty Smith at The Pragmatic Summit Ty Smith 在 Pragmatic Summit 上 Uber 的软件工程”智能体系统”实际上由多个系统组成： Uber's agentic systems, split across four layers Uber 的智能体系统，分为四层架构 各系统类别： • 内部 AI 平台。 构建在 Michelangelo [4] （Uber 的 ML/AI 平台）之上。这一层提供模型网关等基础能力，可以代理访问前沿模型（frontier models）或内部托管的模型。 • Uber 内部上下文： 让智能体可以访问 Uber 的源代码、工程文档、Slack 信息、JIRA 工单等。这些都充当智能体的“记忆”。 • 行业智能体： Uber 的策略是为工程师提供“最新最强”的 AI 智能体，因此支持 Claude Code、GitHub Copilot、Codex 等多种工具。 • 专用智能体： Uber 的背景智能体平台、测试生成平台、代码审查智能体等。 • 工程赋能： 衡量智能体的效率、控制成本，并教育工程师选择合适的工具。 内部工具：MCP Gateway、Agent Builder 与 AIFX CLI MCP（模型上下文协议，Model Context Protocol）已经迅速成为连接智能体和数据源的标准方式。一个常见的类比是：MCP 就像“AI 智能体的 USB C 接口”。 我们此前发布过 MCP 协议深度解析和真实场景中的 MCP 服务器用例。 Uber 组建了一支“虎队”（tiger team，临时组建的快速攻坚小组）来制定 MCP 策略并搭建中心化的 MCP 网关，架构如下： Uber's MCP gateway Uber 的 MCP 网关 这个 MCP 网关实现了： • 将内部接口代理为 MCP： 任何内部的 Thrift、Protobuffer 或 HTTP 接口都可以通过简单的配置变更暴露为 MCP 服务器。 Uber 在后端服务通信中广泛使用 Apache Thrift 和 Protobuffer 这两种通信协议。 • 第一方 MCP： 以统一、一致的接口暴露。 • 第三方 MCP： 外部 MCP 服务器也通过网关接入，由网关统一处理认证和授权。 • 平台能力： 网关在一个中心点统一处理授权、遥测和日志记录，并提供一个统一的交互接口来访问任意 MCP。 MCP 网关还提供了： • 注册中心： 用于查找 MCP 服务器，开发者也可以注册自己的。 • 沙盒环境： 让开发者无需繁琐配置就能快速试用 MCP 服务器。 Uber 的 Agent Builder 是一个无代码工具，可以用来构建能访问 Uber 内部数据源（包括 MCP 服务器和 Uber 数据集）的智能体，还能把任务交接给其他智能体： Uber's Agent Builder Uber 的 Agent Builder：无代码构建智能体 该平台还包含一个叫做 Agent Studio 的工具，可以对多智能体工作流进行可视化、调试、追踪、版本管理和评估。界面长这样： Uber's Agent Studio Uber 的 Agent Studio：用于创建 AI 智能体工作流的无代码界面 在 Agent Builder 中创建的智能体可以通过注册中心被发现和复用： U