MCP让Agent连上工具，为何还是不够用？

MCP解决了什么，又漏掉了什么

给Agent接上MCP，调用工具似乎就顺理成章了。但越南技术频道的一段分析提出了一个反直觉的判断：连上工具只是问题的一半。

MCP（Model Context Protocol）的价值在于统一了Agent查找和调用工具的方式。Agent通过MCP Client与MCP Server对话，Server把工具暴露出来，真正触达GitHub、Jira、代码搜索、文档和production系统。协议层面主要就两个动作：Tools List（服务器上有哪些工具、名称、描述、入参是什么）和Tools Call（执行某个工具，比如查一个issue）。

Tools List, server có tool nào.

问题在于，连接本身并不回答治理问题。每接一个系统，就带进来一整套权限、credential和监控的负担。MCP协议不负责回答：哪个Agent用了哪个工具？以谁的身份在跑？谁来追踪访问？这些恰恰是每家公司自己的规则。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出并开源的开放协议，目标是标准化大模型应用与外部数据源、工具之间的连接方式。它采用 Client–Server 架构：Agent 侧作为 MCP Client，外部系统封装为 MCP Server，双方通过 JSON-RPC 风格的请求交换能力描述与执行结果。协议定义了工具（Tools）、资源（Resources）、提示模板（Prompts）等原语，其中 Tools List 用于声明可用工具及其输入 schema，Tools Call 用于实际执行。MCP 的定位类似于"AI 应用的 USB-C 接口"，解决的是接口碎片化问题，但有意将认证、授权、审计等策略层留给实现方，这也是本文所述治理缺口的技术根源。

每个团队各写一套，才是真正的成本黑洞

如果放任各团队自行其是，局面会迅速失控：这个团队自己写OAuth，那个团队自己管secret，另一个团队自己记日志。重复建设不说，标准还完全不统一。

DoorDash的做法是把问题拆成三条主线，并统一收敛到一个Agent Gateway上：

Access（访问控制）：谁在调用、被允许做什么、需要哪种credential
Selection（工具筛选）：一个Server可能挂着上百个工具，而某个workflow只需要其中几个，因此只暴露相关且已审批的工具
Operations（运行保障）：跟踪流量、错误、响应时间、用量与成本

据该频道分析，这三条线合在一起，才构成Agent Gateway的完整职责——访问控制管"谁能做什么"，筛选管"只放出对的工具"，运维管"跑得稳不稳"。

Ai đang gọi.

身份问题是其中最容易被低估的一环。Agent以谁的账号执行操作，直接决定了审计链路是否成立。

Chạy bằng tài khoản của ai.

Agent Gateway 可理解为位于 Agent 与后端系统之间的一层策略执行点（Policy Enforcement Point），其角色类似传统 API Gateway，但针对非确定性、多工具编排的 Agent 场景做了适配。典型能力包括：基于 OAuth/OIDC 的身份代理与令牌交换（让 Agent 以明确的用户或服务身份调用下游）、工具白名单与按 workflow 的动态裁剪、请求级审计日志、速率限制与成本计量，以及在请求到达生产系统前的拦截与脱敏。与 API Gateway 的关键差异在于，Agent 的调用路径由模型动态决定而非预先编码，因此 Gateway 必须在运行时完成工具可见性控制与最小权限授予，否则权限模型会退化为粗粒度的"全通"授权。

审计链路与身份传播是 Agent 治理中常被忽视的技术细节。在传统系统中，请求身份由调用方直接持有；而 Agent 场景下存在"委托"关系：用户授权 Agent，Agent 再调用 MCP Server，Server 再访问后端。若中间各跳不传递原始用户身份，日志中只会留下一个共享的服务账号，导致无法回答"是谁发起的这次操作"。业界常用做法是采用 OAuth 2.0 Token Exchange（RFC 8693）或嵌套令牌，在每一跳保留发起者与执行者的双重身份声明，并在 Gateway 侧统一记录。缺少这一机制时，即便工具调用成功，事后追溯和合规审计也无法成立。