Uber 的 MCP 网关：800 个服务器、5000 个工具，收敛到一个控制面

在 2026 年 10 月的一篇工程博客中，Uber 讲述了它为在生产规模上运行 Model Context Protocol 而自建的 MCP 网关。数字本身就是故事：800 多个 MCP 服务器、5000 多个独立工具，收敛到单一控制面，每周为数千名工程师承接约 6 万次 Agent 任务。这是首个公开披露的、达到这一规模的世界五百强 MCP 部署，也回答了大多数团队在采用 MCP 数周后就会撞上的问题：工具一多，谁来治理？

Uber 把 800 个 MCP 服务器与 5000 个工具收敛到一个控制面

五千个工具带来的问题

MCP 的采用很少在第一个服务器处失败，而是在第一百个处失败。每接一个新服务器，就带来自己的鉴权、自己的错误处理、自己对「什么是一次工具调用」的理解。团队重复造同一套管道，没人真正对工具治理负责，目录也在悄无声息中与背后的服务脱节。Uber 的网关正是针对这种脱节：与其让每个团队各自即兴发挥，不如把 MCP 逻辑集中起来，让 Agent 与服务通过一条一致、可审计的路径对话。

# The registry is the source of truth: every backend service and
# native MCP server is declared once, then exposed as governed tools.

MCP_GATEWAY = {
    'servers': 800,          # upstream MCP servers
    'tools': 5000,           # individual callable tools
    'agent_tasks_per_week': 60000,
    'consumers': 'thousands of engineers',
}

# Teams do not hand-roll MCP plumbing. They register an API and
# the gateway does the rest.

网关到底做什么

它的核心是编排与路由层：Agent 调用工具，网关把每次调用解析到正确的服务器、施加策略、返回结果。关键的取舍是「集中」——把 MCP 逻辑收进一个微服务后，Uber 让 Agent 与服务的交互拥有统一执行模型，也免去了每个团队重复发明核心基础设施的负担。既有 API 无需定制集成即可暴露为 MCP 工具，这正是让 5000 个工具规模变得可控的前提。

# The gateway is an orchestration + routing layer between agents
# and backend services. One execution model, everywhere.

class McpGateway:
    def route(self, agent, tool_call):
        server = self.registry.resolve(tool_call.name)
        policy = self.charter.policy_for(agent, tool_call.name)
        if not policy.allowed:
            raise ToolDenied(tool_call.name, policy.reason)
        payload = redact_pii(tool_call.args)   # automatic
        return server.invoke(payload)

# Centralizing this logic is what lets 5,000 tools share one
# consistent, auditable execution path.

网关是 Agent 与后端服务之间的编排层

把治理收在一处

第二个职责是治理，也是网关真正体现价值的地方。charter 策略在工具级强制执行，于是「这个 Agent 能不能调用这个工具」只有一个答案，而不是五十个。PII 脱敏在网关内自动完成——在任何载荷离开信任边界之前——因此 Agent 永远看不到原始客户标识。访问还在一方与三方 MCP 服务器之间分级：那是「你自己工程师造的工具」与「别人家 Agent 够得着的工具」之间的差别。

# Tool-level charter policies: who may call what, and how.
# Policy lives next to the tool, not scattered across services.

CHARTER = [
    {'agent': 'internal-bot',  'tool': 'orders/*',   'access': 'read' },
    {'agent': 'internal-bot',  'tool': 'orders/refund','access': 'write'},
    {'agent': 'third-party',   'tool': 'catalog/*',  'access': 'read' },
    {'agent': 'third-party',   'tool': '*',           'access': 'deny' },
]

def allowed(agent, tool):
    for rule in CHARTER:
        if fnmatch(tool, rule['tool']) and rule['agent'] == agent.kind:
            return rule['access']
    return 'deny'

AutoCrawler 让目录保持诚实

5000 个工具的目录，只有保持最新才有用。Uber 的答案是 AutoCrawler：一个基于 Cadence 的分布式工作流，持续扫描公司的 IDL 注册表，发现新服务、新 API 与 schema 变更。有新服务出现时即可接入；API 形状变化时，对应工具 schema 随之刷新。过期的工具定义是一种「静默宕机」——Agent 调用一个早已不匹配其背后服务的工具，拿到一个看似合理、却离真正病因很远的错误。

# PII redaction runs inside the gateway, before anything leaves
# the trust boundary. Agents never see raw customer identifiers.

PII_PATTERNS = [r'\b\d{3}-\d{2}-\d{4}\b', r'[\w.]+@[\w.]+',
               r'\b4\d{3}[ -]?\d{4}[ -]?\d{4}[ -]?\d{4}\b']

def redact_pii(args):
    for k, v in args.items():
        if isinstance(v, str):
            for pat in PII_PATTERNS:
                v = re.sub(pat, '[REDACTED]', v)
            args[k] = v
    return args

# One redaction layer beats 5,000 teams each rolling their own.

AutoCrawler 通过扫描 IDL 注册表保持工具目录常新

这套模式为何不止于 Uber

网关是一种架构模式，而非一次性的作品。它把 MCP 从一堆连接器，变成既是控制面、又是安全边界的组件。正因如此，企业正在向它收敛：厂商在提供原生 MCP 支持，大型雇主把 MCP 推向日常工作流。当 MCP 从实验走向关键业务逻辑，缺少网关就不只是工程上的不便，而是治理上的缺口。

# AutoCrawler: a Cadence-style distributed workflow that keeps the
# catalog honest by scanning the IDL registry for changes.

def autocrawler_tick(registry, idl_index):
    changed = idl_index.diff_since(registry.last_scan)
    for svc in changed.new_services:
        registry.register_mcp_server(svc)   # onboard automatically
    for api in changed.modified_apis:
        registry.refresh_tools(api)         # keep schemas current
    registry.last_scan = now()

# Stale tool schemas are a silent outage. Discovery is not optional.

自建网关的实用清单

如果你正在扩大 MCP 规模，先从三件事入手。一：在 Agent 与服务器之间放一层统一路由，让观察和变更都有唯一入口。二：把策略挂在工具上，而不是调用者上，让访问规则在团队重组后依然成立。三：针对你的服务注册表做自动发现，因为手工维护的工具列表撑不过一个季度。再在边界处加上 PII 脱敏，并对三方服务器单独分级。这些都不新鲜——不过是你早已用于 API 网关的那套纪律，如今指向了 Agent。