|
过去一年，AI Agent 开发的重点还是“如何让模型调用工具”，但进入 2026 年下半年后，这个问题正在迅速发生变化。 随着 MCP（Model Context Protocol）接入的工具越来越多，企业真正面对的问题已经变成：几千个工具如何发现、如何路由、谁有权限调用、调用失败怎么办，以及第三方 MCP Server 到底能不能信任。
最新一批工程实践显示，MCP 正逐渐从 Agent 的“插件协议”，演变成类似 API Gateway、服务注册中心和权限平台结合起来的基础设施层。
Uber 已管理超过 800 个 MCP Server、5000 个工具Uber 最近公开了内部 MCP Gateway 的架构。
Uber 表示，早期不同团队分别为 Agent 接入内部系统，很快出现了工具重复建设、协议不统一、难以发现和缺乏统一安全策略的问题。
为此 Uber 建立了一层统一 MCP Gateway，目前已经承载 800 多个 MCP Server 和超过 5000 个 Tool。
它的整体结构与传统微服务体系非常相似：
Agent
↓
MCP Gateway
↓
Tool Registry / Discovery
↓
HTTP、gRPC、TChannel、Native MCP
↓
内部业务服务
其中 Registry 负责 Tool 的注册、所有权和发现，相当于 MCP 的“控制面”；Proxy Gateway 则负责真正执行请求，是运行时“数据面”。Uber 甚至构建了 AutoCrawler，自动扫描内部 API 和 Schema 变化，并把符合条件的接口转换、注册成 MCP Tool。
这意味着企业未来可能根本不会要求每个团队单独维护 MCP Server，而是直接把已有 API 通过统一 Gateway 暴露给 Agent。
LangChain / LangGraph 也在向新版 MCP 架构迁移Agent Framework 这一侧也出现了类似变化。
LangChain 已经把 MCP 支持从独立的 langchain-mcp-adapters 逐渐迁入主包 langchain.mcp，底层采用 FastMCP，并开始支持新版 MCP 的无状态协议、Tool List Cache、Elicitation 等能力。
10 月 8 日最新的 LangGraph 实际运行案例也显示，目前新的 Agent 项目已经可以直接通过 MCPAdapter 接入本地或远程 MCP Server，同时实现多 Server、工具调用审批、异常处理以及 Human-in-the-loop。
一个比较明显的趋势因此出现：
过去：
Agent → 一堆 Tool
正在变成：
Agent → Tool Discovery → Permission → MCP Gateway → Tool
Tool 本身不再直接暴露给模型，而是开始被放进一套受治理的运行环境里。
但 MCP 的另一个问题也开始暴露：供应链安全MCP 生态高速扩张的同时，安全治理明显没有同步跟上。
OX Security 最近对 5 个 MCP Registry 中的 15,465 个公开 MCP Server进行了分析，对应 5,095 个独立主机。研究发现，其中一些 Server 托管在个人设备或临时隧道上，还有部分域名已经失效甚至过期。
更危险的一点是：
GitHub 上看到的 MCP Server 源代码，并不一定等于远程 MCP Server 实际运行的代码。
也就是说，即使开发者审计了开源仓库，远程服务器仍然可能执行完全不同的逻辑。研究因此认为，当前 MCP Marketplace 普遍缺少类似应用商店的自动扫描、代码签名和来源验证机制。
这使得 MCP 很像早期的浏览器插件和手机 App 生态：
能力扩张非常快，但权限、审核和供应链治理往往要晚几年才补上。
Agent 开发真正开始变成“后端工程”这些变化背后其实透露出了一个更大的趋势。
AI Agent 技术栈正在逐渐长成：
Model Router
→ Agent Harness
→ Context / Memory
→ Skill & Tool Discovery
→ Identity & Permission
→ MCP Gateway
→ API / Service
→ Trace
→ Eval
换句话说，模型已经不是 Agent 系统的全部。
真正决定一个 Agent 能不能进入生产环境的，开始变成传统软件工程非常熟悉的问题：
权限、路由、状态、事务、重试、监控、审计和测试。
这也是近期 Agent 领域一个非常值得关注的变化——行业的竞争重点正在从“谁能做出一个会调用工具的 Demo”，逐渐转向：
谁能构建一个可靠、可治理、可扩展的 Agent Runtime。
对于正在开发 Agent 应用的团队来说，下一阶段可能已经不应该继续无限增加 Tool。
更值得优先建设的是：
Tool Registry + Gateway + Permission + Trace + Eval。
Agent 的“聪明程度”仍然重要，但当它真正开始操作业务系统以后，如何约束它、观察它、验证它，可能比再增加几个百分点的模型能力更加重要。
| 
发表于 2026-10-9 15:03:53