AI 智能体要接入几千个内部工具，怎么管才不乱？小编先给结论：Uber 的做法是搭一个统一的 MCP Gateway，集中管理工具发现、访问权限和对内部 API 的请求。据 Uber 的工程博客，这个平台已支持 800 多个 MCP 服务器和 5000 个工具，开发者可以通过统一接口调用现有 API。
起因是各团队开始各自搭建独立的 MCP 集成，导致基础设施重复、工具分散、难以发现已有工具，安全控制也不一致。网关把这些事集中起来，并把 MCP 请求翻译成 Uber 现有服务使用的通信协议。
把智能体接到现有 API 上
Uber 的 MCP Gateway 由两个主要组件构成：MCP 注册中心（Registry）和代理网关（Proxy Gateway），分别负责工具管理和请求执行。
| 组件 | 作用 |
|---|---|
| MCP 注册中心 | 作为控制平面，维护可用 MCP 服务器和工具的目录，记录工具定义、归属，以及各工具是否已获批准使用 |
| 代理网关 | 处理智能体的请求并转发给对应后端服务，把 MCP 请求翻译成 HTTP、gRPC 或 TChannel 调用，再把响应转回 MCP 兼容的结果 |
| AutoCrawler | 借助 Cadence 工作流引擎自动发现 API，并生成 MCP 兼容的工具定义 |
| MCPFx | Uber 的框架，用来开发直接实现 MCP 的原生服务器 |
Uber 运行着数千个内部微服务，通过上述协议暴露 API。网关让开发者无需修改底层服务，也无需为每个集成单独搭 MCP 服务器，就能把这些 API 变成 MCP 工具。
对于由 API 支撑的工具，传入请求会被转换成合适的格式，用 Protocol Buffers 或 Thrift 序列化，再通过 Uber 现有的服务网格边车 Muttley 路由，由它负责与下游服务通信。网关还会定期刷新服务器和工具配置的内存副本，所以改动无需重启或重新部署就能生效。
AutoCrawler 通过定时任务触发工作流，扫描 Uber 的接口定义语言（IDL）注册表，查找新服务、新 API 和模式变更。它从 Protocol Buffers 和 Thrift 定义里提取方法名、请求与响应模式和文档，转换成 MCP 兼容的模式，再用大语言模型生成工具描述。对于原生 MCP 服务器，AutoCrawler 通过 MCPFx 框架发出的心跳信号发现它们，获取其工具与模式后注册到注册中心。
控制工具访问与安全
尽管 AutoCrawler 能自动发现 API 并生成工具定义，新注册的服务器和工具默认是禁用的，必须由服务负责人审核批准，才会开放给 AI 智能体。Uber 的工程师在博客里说：“发现不等于开放。”每个 MCP 服务器的所有权和控制权，仍归底层服务的负责团队。
工具描述的变更同样要经负责团队批准。注册中心会记录配置差异并支持回滚，服务负责人必要时可以恢复到早期版本。
这些审批控制，对应的正是开放全球应用安全项目（OWASP）指出的安全风险。其 MCP 安全速查表描述了“工具投毒”：嵌入在工具描述、参数模式或响应里的恶意指令，可能影响智能体的行为。OWASP 还指出了“拉地毯”（rug pull）攻击，即 MCP 服务器在初次批准后改动工具定义，并建议审查完整的工具定义（包括模式和注解），用加密哈希检测变化。
Uber 已公开的控制措施，是要求服务负责人批准工具描述的变更并支持恢复旧配置；但其工程博客没有说明网关是否对完整工具定义使用加密校验来检测变化。
网关与 Uber 现有的访问控制系统集成，按调用者身份执行授权策略，区分人类用户、内部服务和 AI 智能体，权限可在 MCP 服务器层面配置，还能对单个工具施加额外限制。OWASP 建议对 MCP 部署实行最小权限，限制工具权限并使用范围狭窄的凭据，并把权限过大和令牌范围过宽列为智能体与所连服务交互时的风险。网关还会自动对工具响应里的个人身份信息和其他敏感数据做脱敏。
对于 Jira、Google 服务等第三方集成，网关会把调用者的内部用户令牌转发给 Uber 的第三方 MCP 服务，由它换成对应的外部认证令牌，再把请求发给第三方 MCP 服务器；网关同样对第三方请求施行授权、限流和敏感数据脱敏，把这些控制延伸到外部 MCP 连接。
Uber 把集中式可观测性列为网关的另一项能力，但没有披露详细的监控指标，也没有公布系统处理的智能体请求量。OWASP 在 2026 年 9 月发布的智能体控制标准（Agent Control Standard），也针对企业 AI 智能体提出了类似的运营要求：要能看到智能体的活动、访问权限和与所连系统的交互，并能在运行期间执行安全策略。
在规模化场景下管理工具发现
除了安全和访问管理，Uber 还遇到另一个难题：智能体如何在数百个 MCP 服务器里发现工具。公司认为，协议缺少原生的跨服务器搜索是个局限，因为智能体得先知道该联系哪些服务器，才能获取它们的可用功能。再加上要让智能体访问众多服务器，就得管理服务器地址、凭据和工具定义；把几千个定义塞进智能体的上下文，会消耗 token，其中还夹杂与当前任务无关的信息。
为此 Uber 开发了 Omni MCP，一个代理服务器，让智能体逐步发现工具，而不是一次把整个目录加载进上下文。它提供查找服务器、搜索可用工具、获取单个工具模式和执行请求的功能，智能体可以根据查询找到所需工具，只在需要时再取更多信息。据 Uber 说，Omni MCP 在工具发现和执行期间，保留了网关现有的访问控制。
网关还有“响应投影”（Response Projection）功能：智能体可以指定自己需要工具响应里的哪些数据。系统在请求模式里加一个字段，让智能体用嵌套路径标明所需信息，网关再用这些路径在运行时过滤响应，只把选中的字段返回给智能体，而不是完整结果。
Uber 还为在 shell 环境中运行的编码智能体推出了“代码模式”（Code Mode），它使用名为 aifx 的命令行界面，让智能体无需安装单独的 MCP 服务器，就能通过网关发现和调用 MCP 工具，共有三条命令：
aifx mcp list：查看可用的服务器。aifx mcp search：查找工具。aifx mcp call：执行请求。
智能体可以把这些命令串联起来，并把工具响应直接写入文件，只取需要的信息，而不必把完整输出加载进模型上下文。据 Uber 称，代码模式现在是其编码智能体使用 MCP 工具的默认方式。
想了解智能体工作量在 GitHub 上有多大，可以读小编的另一篇：GitHub 报告：AI 智能体已发起超过 40% 的拉取请求。
（题图来自 Unsplash 摄影师 Priscilla Du Preez）
常见问题（FAQ）
Uber 的 MCP Gateway 解决了什么问题？
各团队各搭 MCP 集成，造成基础设施重复、工具难以发现、安全控制不一致。网关把工具发现、权限和请求转发集中管理。
自动发现的工具会立刻被智能体使用吗？
不会。新注册的服务器和工具默认禁用，需要服务负责人审核批准后才开放。
Omni MCP 为什么能省 token？
它让智能体按查询逐步发现工具、按需取单个工具的模式，避免把整个目录的定义一次性放进上下文。
Uber 是否用加密哈希来检测工具定义被篡改？
其工程博客没有明确说明。已公开的是变更需审批、注册中心记录差异并支持回滚。