本文信息来源：cowboy

自 Anthropic 宣布模型上下文协议(MCP)以来，我们一直怀着兴奋的心情关注着。但承诺与广泛部署之间仍存在巨大差距。原因何在？

‍

MCP 令人振奋 ，因为它能让 LLMs 扮演代理角色

‍ 然而…MCP 放大了现有 LLM 的脆弱性 。如果涉及敏感数据或操作，这将限制其生产环境应用。

‍

对构建者而言，当前的局限恰恰意味着重大机遇。

‍

什么是 MCP 及其令人兴奋之处

MCP 是一种标准化 LLMs 与外部工具及系统通信的协议。开发者无需为每个 AI 模型单独构建集成，只需创建一个通用的”MCP 服务器”，即可兼容任何支持 MCP 的 LLM（任何具备”函数调用”或”工具使用”功能的 LLM）。

‍

MCP 工作原理：

  1.  发现机制： 当你打开一个”MCP 宿主”应用程序（如 Cursor 或 Claude 桌面端）时——该应用既包含 LLM 访问权限又内置”MCP 客户端”——MCP 客户端会连接已配置的”MCP 服务器”，并获取其可用工具（例如 filesystem/read_file 文件系统/读取文件、github/create_pull_requestGitHub/创建拉取请求、postgres/queryPostgreSQL/查询、notes/create_note 笔记/创建笔记）。
  2. 请求阶段： 当你通过 MCP 宿主应用向 LLM 发送消息时，LLM 会识别需要使用的工具并生成对应的函数调用指令。
  3. 执行阶段： 宿主应用中的 MCP 客户端将函数调用路由至相应的 MCP 服务器，由服务器执行具体操作。
  4. 响应阶段： 处理结果通过 MCP 客户端返回至 LLM，LLM 将其整合后呈现在宿主应用中（例如 GitHub Copilot 的响应界面）。

‍

MCP 的核心价值在于让 LLM 能轻松对接多种工具和数据源。例如：当你向 Claude 桌面版提交一张收据照片时，Claude 的”MCP 客户端”会向费用管理系统（如 Ramp 的”MCP 服务器”）发起请求，服务器将处理图像、提取关键信息创建费用条目、根据公司政策进行校验、添加到报表并提交审批——这消除了当前流程中大量的人工操作环节。

‍

MCP 推动三大变革：

  1. 系统互联无需定制集成 。 支持 MCP 的 LLMs 能够读取并解析跨多软件系统（如 Drata、Jira、Confluence、Github、Outlook、Salesforce）的信息 
  2. 数字助理成为可能 。 支持 MCP 的 LLMs 可以创建并执行当前由人工驱动的操作。聊天机器人能回复邮件、提交代码、更新工单或编写文件。
  3. AI 驱动的工作流取代人工定义流程 。 理想状态下，AI 能通过决定工具使用时机来规划与协调整个工作流。当前的问题是”AI 会取代程序员吗？”但真正的变革可能是 AI 取代程序。工程师仍将构建工具，但 AI 将消除编写系统连接与数据流协调代码（工程师称为”控制平面”）的需求。

从传统人工或 “工程师定义” 的工作流程转向 “AI 定义” 的工作流程（或称”智能代理工作流程”），将帮助人们快速穿透复杂的层级结构，使数据立即可用。

假设您希望通过 Slack 频道追踪每周销售渠道健康状况。以下是每周 GTM 报告工作流程以不同方式构建的示例：

‍

人工定义的工作流程：

  • 设置 Zapier 工作流程并配置触发-动作链
  • 为每个数据源（CRM、工单系统）创建独立的自动化流程
  • 使用 Google 表格作为临时数据库手动关联数据
  • 构建字段变更时就会失效的格式化模板
  • 添加定时向 Slack 推送的 Webhook
  • 每个新指标 = 重建整个自动化流程

‍

工程师定义的工作流程：

  • 在脚本中编写复杂且脆弱的数据查询
  • 交叉引用 CRM 系统、工单、文档，理解数据模式，关联数据表
  • 将以上内容整理成文档及 Slack 摘要
  • 将所有内容串联起来，编写调用 Slack 的 API 代码
  • 每个新需求 -> 编写更多代码

‍

AI 定义（通过 MCP）的工作流程：

告诉 Claude 桌面版：”周一上午 9 点前准备好我们的 GTM 资料包，选用最能体现本周业务健康状况的指标，并将分析见解分享到#exec-weekly 频道。”

AI 动态协调 MCP 服务器以实现：

  • 发掘可用数据源（Salesforce、HubSpot、Zendesk、文档系统）
  • 根据当前业务场景确定核心指标优先级
  • 根据数据质量与业务现状调整分析方案
  • 执行跨系统数据提取、关联与分析
  • 以最优格式发布成果（幻灯片、CSV 文件、Slack 摘要）

‍

这就是转变：从预先定义每条路径，到为 AI 提供工具并让它自行寻找路径。

‍

然而，我们尚未完全准备好转向由智能体或 AI 定义的工作流，或将 MCP 部署到生产环境。 这意味着构建者面临机遇：

‍

机遇一：当前 LLMs 的训练目标是生成文本而非协调工作流

当由 AI 而非代码决定调用哪些工具时，我们将丧失审计和调试工作流的能力。软件的可复现性、可追溯性和确定性等保障随之消失。这些挑战因当今 LLMs 的根本缺陷而加剧——它们专为文本生成设计，而非执行动作或协调工作流。虽然 LLMs 能表现出智能体行为，但它们缺乏传统软件赖以实现可预测多步骤执行的可靠状态管理和错误处理机制。

LLMs 的非确定性特质意味着相同的提示可能产生不同结果，使得输出难以预测（尽管温度设置可以部分缓解此问题）。或许最关键的是，当前 LLMs 在面对模糊性和庞大上下文时表现欠佳。无论是编排复杂工作流还是配置多台 MCP 服务器，随着上下文长度增加，其性能都会下降，从而影响规划和任务执行质量。

潜在解决方案：具备代理能力的 LLMs 与模型、混合工作流及工具

当前的局限性或许并非永久性，人们乐观预期随着工具和技术的进步，LLMs 最终将能编排复杂工作流：

  • 新型及/或经过再训练的代理行为 LLMs 与模型： 构建具备规划能力、消除用户指令歧义、工具选择及状态追踪功能的人工智能
  • 具备传统软件保障的 MCP 托管应用 ：通过人工检查点为专注 AI 定义的工作流带来可复现性、可追溯性与确定性
  • 复杂上下文管理解决方案 ：防止 LLMs 同时处理多个 MCP 服务器和大规模上下文时出现性能下降
  • AI 的测试、监控与审计 ：模拟运行、支持回滚，并在 AI 决策时添加细粒度覆盖机制

‍

机遇二：MCP 与 LLM 编排系统的安全漏洞

当你通过 MCP 服务器向 LLM 暴露敏感数据时，就创造了多重攻击面。MCP 服务器将 LLM 直接连接到你的后端和数据库。成功的提示词注入不仅会导致信息泄露，还可能在你的系统上执行操作。

为 MCP 实施恰当的 IAM（身份访问管理）同样复杂。现有为人用户设计的系统采用粗粒度权限机制，其隐含边界对 AI 无效。MCP 服务器还可能为现有漏洞（如 ‘0.0.0.0 日漏洞’ ）引入新的攻击向量

LLMs 固有的漏洞（如提示注入和数据提取）与 MCP 广泛的系统访问权限相结合，形成了一场完美风暴：攻击者可以操纵 AI 成为内部威胁，合法访问您的基础设施。

潜在解决方案：假设漏洞存在，以安全为设计准则

这些安全挑战为防御性架构和工具创造了机遇：

  • 纵深防御应用架构 ：MCP 服务器与潜在恶意用户输入隔离（甚至通过人工审核外部文本输入）
  • MCP 安全解决方案 ：特别是涉及敏感数据的服务器
  • 产品化 LLM 安全研究： 为开放权重模型提供结构化提示、权限分离和对抗性训练打包的解决方案或模型
  • AI 原生身份与访问管理： 控制哪些 AI 代理可以代表用户执行特定操作，为人类和 AI 发起的操作提供细粒度权限及审计追踪

‍

机遇三：MCP 配置与部署的摩擦

在 Claude 中设置 MCP 服务器需要用户配置 JSON 文件，这阻碍了主流采用。就像用户不需要知道他们最喜欢的应用背后是什么数据库一样，他们也不应该需要为 AI 原生应用背后的 MCP 服务器进行设置。此外，MCP 的开放性意味着任何人都可以发布服务器。这对非技术用户来说是个问题，他们难以评估如何安全选择和托管 MCP 服务器。对开发者而言，尽管 MCP 是模型无关的，但不同模型可能以不同方式调用 MCP 服务器，这意味着提示词、工具和资源可能需要针对不同模型进行调整。

潜在解决方案：将 MCP 转化为无形基础设施

解决方案不仅在于简化 MCP 服务器的部署流程，更要让其在应用程序中彻底隐形：

  • MCP 宿主应用 ：安全嵌入 MCP 技术，打造愉悦、高品质且专注的用户体验
  • MCP 工具链： 实现 MCP 服务器跨模型与主机的可移植性，并提供测试与调试框架
  • MCP 服务器即服务 ：正如 Twilio 和 Plaid 将高价值服务产品化一样，我们看到为 AI 编排工作流构建的服务器存在巨大机遇