Uber如何为AI代理构建访问工具的网关
内容提要
Uber构建MCP网关，让AI代理安全调用内部工具。平台分为注册中心（管理工具目录与配置）和代理网关（处理实际请求）。AutoCrawler自动发现API和原生MCP服务器并生成工具定义，新工具默认禁用，需所属团队审核启用。网关统一处理权限、PII脱敏和第三方认证，并通过Omni MCP的渐进发现、响应投影和代码模式控制上下文膨胀。
延伸解读
控制面与数据面分离的设计价值
Uber将MCP平台拆为注册中心与代理网关：前者管理工具目录、配置与启停，后者处理实际请求。这种分离让工具定义和权限变更不必与请求路径耦合，网关按固定周期刷新内存状态，新配置无需重启或重新部署即可生效。对多团队环境而言，控制面集中治理、数据面独立扩展，比各团队各自维护MCP集成更易保持一致性和可运维性。
自动发现不等于自动放行
AutoCrawler能从现有API定义和原生MCP服务器两条路径自动生成或获取工具定义，减少手工接入成本。但Uber刻意让新发现的工具默认处于禁用状态，需由所属服务团队审核描述并启用，每次修改都形成待审批的diff且可回滚。这一设计把“能力可见”和“授权可用”分开，避免自动扫描把未经确认的工具直接暴露给代理，适合企业内工具数量庞大的场景。
网关统一收口权限与敏感数据
网关按调用方身份执行访问策略，粒度可到单个工具，例如同一事件管理服务器下，读取事件与修改状态可授予不同权限。它还能对工具响应中的PII等敏感数据做脱敏。对Jira、Google等第三方服务，网关将内部用户令牌交给第三方服务换取外部认证令牌，再由其调用外部MCP服务器。这种分工把通用访问控制留在网关，把外部认证细节交给专门服务处理。
上下文膨胀是工具规模化的隐性成本
当网关暴露数千个工具时，工具描述和schema会占用大量模型上下文，工具返回的冗长对象也会推高输入量。Uber为此加入三项机制：Omni MCP通过discover_server、discover_tools、get_tool_schema等工具实现渐进发现；Response Projection允许请求方指定返回字段，由网关裁剪其余字段；Code Mode让编码代理用shell命令和文件处理结果。这些做法针对的是工具目录变大后的实际开销，而非模型能力本身。
Q&A
Uber 为什么需要构建 MCP 网关？
Uber 的工程团队最初各自构建 MCP 集成，导致工具分散、重复解决类似问题（如暴露工具、管理连接、处理权限），且难以发现可用工具。此外，Uber 的服务使用 HTTP、gRPC、TChannel 等不同协议，无法直接转发 MCP 请求。因此需要一个公共层来统一连接 MCP 客户端与工具，并处理发现、安全和运维支持。
Uber 的 MCP 网关由哪些主要组件构成？
MCP 网关平台分为两个主要组件：MCP 注册中心（控制平面）和代理网关（数据平面）。注册中心保存 MCP 服务器和工具的目录，管理配置（如启用/禁用工具），是共享的事实来源；代理网关处理实际的 MCP 请求，识别请求的工具，应用控制措施，并将请求路由到正确的服务，返回 MCP 兼容的结果。
AutoCrawler 如何自动发现工具？
AutoCrawler 是一个基于 Cadence 的分布式工作流系统，通过两条路径发现工具：1）从现有 API 定义（IDL）中读取服务接口，提取方法名、请求/响应结构，转换为工具 schema，并利用 LLM 生成更好的工具描述；2）对于原生 MCP 服务器，通过心跳指标发现后调用其 listTools 操作，获取工具定义并在注册中心创建代理表示。所有发现的工具默认处于禁用状态，需所属团队审核启用。
MCP 网关如何处理权限和敏感数据？
网关使用内部访问控制系统，基于调用者（人类、服务或 AI 代理）应用策略，支持服务器级和工具级授权。网关还能对工具响应中的个人身份信息（PII）或其他敏感数据进行脱敏。对于第三方服务（如 Jira、Google），网关将调用者的内部用户令牌发送给第三方服务，由其换取外部认证令牌，再携带该令牌请求外部 MCP 服务器。
Uber 如何解决工具目录庞大导致的上下文膨胀问题？
Uber 在网关中增加了三个功能：1）Omni MCP：一个单一代理服务器，支持渐进式发现，提供 discover_server、discover_tools、get_tool_schema 等工具，让代理逐步发现能力；2）响应投影：类似 GraphQL 的模式，允许在工具请求中指定返回字段，网关过滤掉其他字段；3）代码模式：让编码代理使用 shell 命令和文件处理结果。
一个 MCP 请求如何通过网关到达后端服务？
请求到达网关后，网关找到对应的虚拟服务器和请求的工具，服务器处理器使用内存映射确定下游目的地和操作，将工具的 JSON 参数转换为服务期望的格式（如 gRPC 的 Protobuf 字节），服务执行操作并返回响应，最后网关将响应转换为 MCP 兼容结果返回给调用者。相同方法适用于 HTTP、TChannel 等后端。
