33 篇博文 含有标签「mcp」

你在一个工具 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）与外部系统之间真实的集成摩擦。但在“完成演示原型”与“在真实用户负载下可靠运行”之间，存在着比大多数团队预想的更大的鸿沟。以下是这个鸿沟的真实样貌。

每个发布过 AI 产品的工程师都了解集成成本。你希望你的代理从数据库中读取数据、触发 GitHub PR 并发布 Slack 消息。于是你编写了一个数据库连接器、一个 GitHub 连接器和一个 Slack 连接器——每个都是嵌入你提示管道中的自定义代码块。将其扩展到三个产品和五个数据源，你将有十五条不同的集成路径需要维护。Anthropic 称之为“M×N 问题”，他们说得没错。

模型上下文协议（MCP），于 2024 年 11 月推出，现由 Linux 基金会管理，是业界的解决方案。你可以将其比作语言服务器协议（LSP）改变代码编辑器的方式：在 LSP 之前，每个编辑器都必须实现自己的 TypeScript 语言服务器。LSP 之后，VS Code、Neovim 和 Emacs 都共享同一个服务器。MCP 将同样的逻辑应用于 AI：只需编写一个服务器，即可将其连接到任何兼容 MCP 的客户端——Claude、ChatGPT、Cursor、GitHub Copilot，所有这些。

“AI 界的 USB-C” 这个比喻很吸引人。但在涉及负责生产环境运行的这一关键层面时，这个比喻又是错误的。Model Context Protocol (MCP) 确实解决了一个真实存在的问题——即 AI 模型与外部系统之间爆发式增长的 N×M 次自定义集成——但“演示效果良好”与“在周一早高峰流量下既不泄露数据也不耗尽延迟预算”之间的差距，比大多数团队预期的要大得多。

MCP 在 2024 年 11 月发布后的五个月内，服务器下载量增长了 8,000%，到 2025 年 4 月，每月 SDK 下载量已达到 9,700 万次。这种采用速度既是其真正实用性的标志，也是一个警告：大多数服务器在投入生产时，团队并未完全理解他们所构建的基础。

大多数 AI 智能体之所以昂贵，是因为一个细微的架构错误：它们将每一个中间结果都视为要反馈给模型的消息。每一次工具调用都变成了 LLM 上下文窗口的一次往返，而当一个中等复杂度的任务完成时，你已经为处理相同的数据支付了五次、十次、甚至二十次的费用。一个在三个分析工具之间传递的 2 小时销售录音，可能在路由上就花费你 50,000 个 token —— 而这还不是为了分析，仅仅是为了路由。

有一种更好的方法。当智能体编写并执行代码而不是逐个调用工具时，中间结果会保留在执行环境中，而不是上下文窗口中。模型看到的是摘要和过滤后的输出，而不是原始数据。这种差异不是渐进式的 —— 在实际工作负载中，token 消耗量减少了 98–99%。