39 篇博文 含有标签「mcp」

你的 Agent 代码库中最危险的文件是你一直当作 API 文档来编写的那个。工具注册表（Tool Registry）——即告诉模型存在哪些函数以及它们接受哪些参数的 JSON 或 Pydantic schema —— 不再仅仅是一个 docstring。它是你的授权层（authorization layer）。如果你像大多数团队那样设计它，你就是把万能钥匙交给了大模型（LLM），并称之为优秀的工程设计。

考虑一个典型的工具初步尝试：query_database(sql: string)。初衷是合理的 —— 让模型根据用户的问题制定正确的 SQL。现实情况是，模型现在成了一个不受信任的客户端，拥有连接字符串所指向的任何数据库的无限 DDL 和 DML 权限。系统提示词说“仅在 orders 表上运行 SELECT” 只是一个建议，而不是控制手段。当一个受到提示注入（prompt-injected）的工具结果 —— 比如邮件正文、网页或 PDF —— 告诉模型运行 DROP TABLE users 时，你的授权模型就变成了对模型指令遵循能力的纪律要求。那不是授权。那是祈祷。

在你的技术栈中，每一个设计良好的 HTTP API 都会返回分页结果。没有人会把一百万行数据加载进内存并祈祷一切顺利。然而，你的智能体（agent）所调用的工具却会返回整个列表，而智能体也会尽职尽责地阅读它，因为函数签名写的是 list_orders() -> Order[]，且智能体不像人类用户那样拥有“滚动并加载更多”的协议。

智能体在原本可以跳过的行上浪费了 Token。拥有 50K 记录的长尾客户遇到了中等规模客户从未见过的上下文窗口失败。工具作者无法从追踪（trace）中判断智能体是需要所有这些行，还是仅仅因为无法请求更少的数据。而且，在你评估套件的某个地方，原本会标记这种退化的回归测试从未运行，因为每个测试固件（test fixture）的记录都少于 100 条。

分页不是一种 UI 交互功能。它是一种负载卸载（load-shedding）原语 —— 而在没有分页的情况下使用工具的智能体，正在重新犯下你们公司的 API 设计师们花了十年时间才学会避免的每一个 SELECT * FROM orders 错误。

你的安全团队拥有公司信用卡上每一项 SaaS 订阅的完整清单、每一个获得管理员授权的 OAuth 应用，以及连接到公司 Wi-Fi 的每一台设备。然而，对于你的高级工程师笔记本电脑上当前绑定到 127.0.0.1 的七个进程，他们却完全视而不见——一个带有长期 Staging API 令牌的“部署助手”，一个订阅了包含客户数据的 Slack 频道的“工单分类器”，以及一个拥有生产分析数据仓库读取权限的“发布说明生成器”。这些都不在供应商名单上。它们不会出现在 SSO 日志中。所有这些都在利用工程师现有的凭据运行，执行着从未经过审批的操作。

这就是影子 MCP（Shadow MCP），它是企业中增长最快的未管理授权面。模型上下文协议（Model Context Protocol）使得将任何工具接入任何 LLM 的成本变得极低，而工程师们——天性使然——首先接入了那些最显而易见的工具。Saviynt 的 CISO AI 风险报告指出，75% 的 CISO 已经发现其生产环境中运行着未经授权的 AI 工具。GitHub MCP 服务器在 2026 年初的周安装量突破了 200 万次。Postgres MCP 服务器允许 LLM 对开发者能接触到的任何数据库执行 SQL 提示词，其周安装量已超过 80 万次。这些数字中没有一个代表企业的 IT 决策。

调取任何生产环境智能体（agent）的一周工具调用追踪（tool-call traces），你会发现其规律如出一辙：三四个工具处理了 90% 的调用，其余数十个工具则瓜分了剩下的 10%。工具目录呈现幂律分布（power law），但框架却将其视为均匀列表。每个工具描述都会出现在每个系统提示词（system prompt）中，每个选择准则都对工具一视同仁，每个评估（eval）在对目录进行采样时，都仿佛 search-files 调用和 refund-issue 调用来自同一分布。事实并非如此。

这种“扁平化”处理的代价在爆发前往往是隐形的。团队增加第 18 个工具，规划器（planner）对最初三个工具的准确率下降了两个百分点，却没人能将这种退化归因于特定变更，因为所有指标都同时发生了偏移。而评估套件本身在目录中也是均匀分布的，它将这些下滑平均成一个看起来依然正常的数字。与此同时，本轮对话中模型不会调用的工具描述所消耗的 token，已经超过了用户实际提示词的 token。

当一个智能体因为循环处理一个格式错误的告警信号，在一小时内给你的值班人员发了四次传呼时，领导层终于意识到安全团队早已知晓的一件事：“工具访问权限”与“创造人工任务的能力”其实是同一种权限，而你在没有进行安全审查或产品归属权审查的情况下就授予了它。没有人关注“谁被允许在凌晨 3 点打扰人类”这个问题，因为根本没人把它当作一个问题。它被描述为一个 Slack 集成。

2026 年的智能体技术栈让这种故障模式的发生门槛变得极低。Anthropic 的 MCP 服务器、OpenAI 的 Agents SDK，以及各种厂商提供的操作工具，极大地缩短了“模型决定做某事”与“人类被吵醒”之间的距离。大多数团队部署这些集成的方式与部署数据库客户端如出一辙：定义一个 Token 作用域，引入 SDK，写一段系统提示词，然后发布。数据库客户端的爆炸半径是受影响的行数。PagerDuty 客户端的爆炸半径则是一个人的睡眠。

你的 Agent 每五分钟调用一次的 MCP 服务，其最后一次 commit 还是在八个月前。它所封装的上游 API 在二月份推出了新的身份验证模型。目前有 47 个未解决的 issue，其中 12 个被标记为安全风险。维护者的 GitHub 账号自十月以来就没有过任何活动。你的 Agent 仍然能够连接，仍然能够接收工具描述，仍然能够执行调用 —— 而在无声无息中，每一次调用都流经一段无人看管的基础设施。

这就是 MCP 被遗弃的现状。不是恶意的卷款跑路（rug pull），也不是被攻破的软件包，仅仅是由于疏忽。有人在 2025 年发布了一个有用的服务，被大家采用后，便转向了其他项目。该服务之所以能继续运行，是因为没有任何因素强行让它崩溃。直到它彻底崩溃 —— 而到那时，你的 Agent 每五分钟跨越一次的信任边界其实早已失效。

大多数团队采用社区 MCP 服务的方式与采用 npm 包的方式如出一辙：运行 install 并阅读 README。这种思维模型在面对 MCP 时失效了。在 MCP 中，依赖是一个动态的信任边界，LLM 在循环中携带凭据，并在生产数据上对其进行调用。

你在一个工具 schema 中将 query 重命名为 search_query。变更日志写着：“非破坏性更名：更清晰的命名”。PR 通过了评审。三天后，你的支持队列里塞满了关于助手“搜索结果为空”的报告。发生的事情并不是讨论帖里任何人会告诉你的。智能体（Agent）并没有失败。它们提交了旧的字段名称，你的工具服务器忽略了未知的 key，将 search_query 默认设置为空字符串，并返回了零条结果。模型看到一个看起来很正常的空响应，便自信地向用户解释为什么他们的查询没有返回任何相关内容。

这是智能体工程（Agent Engineering）中不符合从 REST API 版本管理借鉴来的心理模型的部分。发送已重命名字段的 REST 客户端会收到 400 错误和清晰的报错——该字段要么存在于验证器中，要么不存在。而发送已重命名字段的智能体得到的则是静默接受、一个毫无意义的结果以及一段幻觉式的合理解释。失败不在于线路传输（the wire）；而在于运行时 schema 与模型关于工具外观的上下文心理模型（in-context mental model）之间的脱节。

工具 schema 存在于两个地方。第一个是运行时规范（runtime spec）——即你发布到 MCP 服务器或函数调用注册表的 JSON schema。第二个是该规范在模型中的上下文表示，它通过系统提示词（system prompt）中的 few-shot 示例、智能体在多轮任务中看到的序列化工具历史记录，以及模型在预训练期间已经吸收的关于你 API 的知识来在每一轮对话中不断强化。你可以原子化地更新前者，但你无法原子化地更新后者。这种不对称性就是问题的核心，这也是为什么“仅限添加，永久保留”——protobuf 和 GraphQL 运营商在十年前就已经内化的原则——现在需要迁移到工具 schema 层了。

大多数团队在选择智能体协议时，实际上同时做了三个不同的决策——把它们混为一谈，正是为什么许多集成一旦引入第二个框架就会崩溃的原因。

这三个决策分别是：智能体如何与工具和数据交互（纵向集成）、智能体如何与其他智能体协作（横向协调），以及智能体如何向人机界面暴露状态（交互层）。Google 的 A2A、Anthropic 的 MCP 和基于 OpenAPI 的 REST 解决的是这个栈的不同层次。当工程师混淆它们时，要么用多智能体机制过度设计单智能体场景，要么用单智能体工具欠设计多智能体工作流。两种失败在生产环境中重构代价都极高。

如果你经历过 2015–2018 年的微服务爆发期，那么 MCP 的现状应该会让你感到不安的熟悉。一个真正有用的协议出现了。它很容易搭建。每个团队都搭建了一个。没有人追踪什么在运行、谁负责维护、如何保障安全。不到十八个月，你就会盯着一张工程师私下称为"死星"的依赖关系图。

Model Context Protocol 正在沿着同样的轨迹发展，速度大约是三倍。非官方注册中心已经索引了超过 16,000 个 MCP 服务器。GitHub 上有超过 20,000 个公开仓库在实现它们。Gartner 预测到 2027 年 40% 的 agentic AI 项目将失败——不是因为技术不行，而是因为组织在自动化有缺陷的流程。MCP 泛滥正是这个问题的症状。

MCP 生态已拥有 10,000+ 服务器和 9700 万次 SDK 下载量。但同时也在六十天内出现了 30 个 CVE、502 个未锁定版本的服务器配置，以及一个在十五个版本中悄悄将每封外发邮件密送给攻击者的供应链攻击。可组合性的承诺——「只需再接入一个 MCP 服务器」——是真实的。但它带来的依赖蔓延也是真实的，大多数团队在深陷集成债务之后才发现其代价。

如果你在 npm 上构建过生产系统，你一定看过这部电影。MCP 生态正在加速重演同一剧情，只不过这次的「包」拥有对你机器的 shell 访问权限和生产系统的凭证。

2025 年 9 月，一个每周下载量达 1,500 次的非官方 Postmark MCP 服务端被悄悄篡改了。更新在其 send_email 函数中添加了一个单一的 BCC 字段，静默地将每封邮件抄送给攻击者的地址。启用了自动更新的用户开始在没有任何可见行为变化的情况下泄露邮件内容。没有错误。没有警报。该工具的工作表现完全符合预期 —— 只是它也在为别人工作。

这是供应链攻击的新形态。不是受损的二进制文件或被植入木马的库，而是 AI 智能体盲目信任的被投毒的工具定义。随着注册中心索引了超过 12,000 个公共 MCP 服务端，且该协议正成为 AI 智能体的默认集成层，MCP 生态系统正在重现 npm 生态系统犯过的每一个错误 —— 只是现在的波及范围包括了你的智能体代表你阅读文件、发送消息和执行代码的能力。

Model Context Protocol (MCP) 将自己定位为 AI 的 USB-C 接口 —— 将任何工具接入任何模型，然后看着它们自如交流。在实践中，第一天确实感觉如此。第二天你会遇到扩展性漏洞。到了第三天，你就在阅读关于那些你甚至都不知道存在的工具投毒攻击（tool poisoning attacks）的 CVE 了。

MCP 是一个非常有用的标准。它于 2024 年底推出，并迅速被整个行业采用，它解决了大语言模型（LLM）与外部系统之间真实的集成摩擦。但在“完成演示原型”与“在真实用户负载下可靠运行”之间，存在着比大多数团队预想的更大的鸿沟。以下是这个鸿沟的真实样貌。