简介：在AI Agent大规模落地企业场景的进程中，模型能力本身往往不是瓶颈，真正决定智能化上限的，是模型能否稳定、安全地调用内部工具与服务。MCP（Model Context Protocol）正是为解决这一痛点而生的标准化协议，它基于轻量的JSON-RPC消息机制，将数据库、文件系统、API服务及RPA脚本抽象为可被AI动态调度的工具资源。通过Host、Client与Server的三层架构，MCP实现了工具接入的统一路径，让每一个遗留系统都能快速被“AI看见”。与此同时，Serverless架构凭借事件驱动与毫秒级弹性伸缩的特性，正在与MCP形成天然互补：AI任务的高频、动态、不可预测的负载特征，恰好由Serverless承接。当MCP中台结合工具向量化召回与可信沙盒边界控制，企业便能在安全可控的前提下，将传统软件重塑为可被AI按需调度的能力服务。软件进化的下一轮筛选条件，正从“功能完整”转向“能被AI稳定、安全地调用”。
1. 当 AI 开始调度软件，企业 IT 架构的边界被重新划定了
Altman 公开表态 OpenAI 将跟进支持 MCP 协议之后，MCP 中台这个话题在企业 IT 架构讨论中的分量明显加重了。过去一年里我拆过不少 AI 落地项目，发现一个共性：大多数企业并不缺模型能力，缺的是让模型稳定、安全、可审计地调用内部工具的那一层基础设施。MCP（Model Context Protocol）做的事情非常聚焦——用一套基于 JSON-RPC 的标准化协议，把数据库、文件系统、API 服务、RPA 脚本统一成 AI 可调度的工具资源。本文从协议机制、Serverless 融合、中台落地与可信沙盒四个维度展开，最后落在一个所有做企业软件的人都绕不开的问题上：软件进化的下一轮筛选条件是什么。
2. MCP 协议的工作机制：JSON-RPC 与工具接入的标准化路径
MCP 之所以有成为通用协议的潜质，不是因为它定义了某个具体功能，而是它把“AI 模型接入外部工具”这件事抽象成了一组标准动作。任何工具，只要实现这组动作，就能被任何支持 MCP 的模型调用。这个思路和 LSP（Language Server Protocol）当年的路径一致：先统一协议，再繁荣生态。
2.1 为什么是 JSON-RPC：MCP 的消息骨架
MCP 选择 JSON-RPC 2.0 作为消息层，这一点值得展开说。JSON-RPC 是一个无状态、轻量的远程调用协议，请求和响应都是 JSON 结构，天然适合大模型场景下的工具调用。MCP 在此基础上定义了三个核心方法：initialize用于能力协商，tools/list让客户端获取当前可用的工具清单，tools/call执行具体的工具调用。
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "video_compress", "arguments": { "source": "/data/demo.mp4", "ratio": 0.5 } } }这三次交互解决了一个关键问题：模型不需要预先知道工具的实现细节，只需通过tools/list拿到工具名和参数 schema，再按 schema 组织tools/call的请求体。响应里可以带isError字段标记调用失败，模型据此决定是重试、换工具还是直接告诉用户。
从工程角度看，JSON-RPC 的价值在于它足够薄。像 gRPC 或 GraphQL 那样厚重的协议层会抬高工具接入门槛，而 JSON-RPC 几乎任何语言都能在几小时内实现。对于企业内大量遗留系统——比如只能暴露 HTTP 接口的老旧 ERP——包一层 MCP Server 的成本远低于重构接口。
围绕 JSON-RPC，工具开发时需要注意三条规则：第一，tools/list返回的 inputSchema 必须严格遵循 JSON Schema 规范，否则模型生成参数时容易出错；第二，所有错误都要返回结构化信息，不要只丢一个 "error" 字符串，模型需要知道是参数不合法还是服务不可用；第三，超时时间要单独配置，大文件处理类工具往往超过默认的 30 秒上限。
2.2 MCP 架构三要素：Host、Client 与 Server
MCP 架构里三个角色很容易混淆，实际落地时先把这个模型理清楚，后面设计才不会走偏。MCP Host 是 AI 应用本体，比如 Claude Desktop、Cursor 或企业自己开发的 Agent 平台；MCP Client 是 Host 内部负责与 Server 建立连接的组件，一个 Host 可以同时持有多个 Client；MCP Server 则是轻量级进程或服务，暴露一个或多个工具。
这个分层设计对企业 IT 架构有一个直接好处：工具可以独立演进。业务部门需要视频压缩功能时，不需要改 Agent 平台的代码，只需要新部署一个 MCP Server 并在配置里注册。平台侧通过tools/list动态发现能力，这也让“工具市场”在架构层面成为可能。
在部署形态上，MCP Server 可以是本地 stdio 子进程，也可以是远程 HTTP 服务。本地模式适合文件系统操作、桌面自动化这类需要访问本机资源的场景；远程模式适合数据库查询、SaaS API 调用这类集中化能力。一个常见误区是强行把所有工具都做成远程服务，结果网络延迟和鉴权复杂度反而拖垮了整体体验。
为了更直观地理解三种模式的场景差异，下面这张表是常用的选型依据：
| 部署形态 | 通信方式 | 典型场景 | 注意点 |
|---|---|---|---|
| 本地进程 | stdio | 文件操作、本机浏览器控制 | 生命周期由 Host 管理 |
| 远程服务 | Streamable HTTP | 数据库、知识库、SaaS API | 需要鉴权和限流 |
| 混合模式 | 两者兼有 | 既有本地又要共享的工具 | 注意工具状态同步 |
2.3 一个最小可用的 MCP 工具服务器
理解了架构再动手写代码，会顺很多。我一般会从官方 SDK 的 FastMCP 封装开始，而不是手写 JSON-RPC 处理逻辑。因为协议层的会话管理、消息帧解析、错误码映射这些样板代码，SDK 已经处理得足够稳定，手写反而容易在边界情况上出问题。
from mcp.server.fastmcp import FastMCP mcp = FastMCP("video-tools") @mcp.tool() def compress_video(src_path: str, target_ratio: float = 0.5) -> str: """压缩视频文件到指定比例，返回输出路径""" out_path = f"{src_path}.compressed.mp4" # 实际场景在这里调用 ffmpeg 命令完成转码 return out_path @mcp.tool() def add_watermark(video_path: str, watermark_text: str) -> str: """在视频左上角叠加文字水印""" output_path = f"{video_path}.watermarked.mp4" return output_path if __name__ == "__main__": mcp.run(transport="stdio")这个例子里，@mcp.tool()装饰器做了两件事：把函数名和 docstring 转换成tools/list需要的 JSON Schema；把函数的参数签名映射成模型可以理解的入参结构。mcp.run(transport="stdio")启动本地模式，Host 通过标准输入输出与 Server 通信。
这里有个细节值得注意：target_ratio给了默认值 0.5，这在 schema 里会被标记为 optional。给工具参数设置合理默认值能显著降低模型误调用的概率，因为模型在拿不准参数时通常会优先尝试带默认值的调用。此外，docstring 一定要写清楚工具的适用边界，比如“仅支持 MP4 格式”，否则模型可能会拿不兼容的文件格式去试错。
3. MCP 与 Serverless：两种架构的融合路径与边界
原文中有一个判断我觉得非常关键：过去 Serverless 在企业私有化环境里很难铺开，因为它的调用主体都是软件工程师预先封装好的应用；但 AI 智能体的出现改变了调用主体——AI 会动态地、高频地、不可预测地创建新的执行任务，这恰好是 Serverless 擅长应对的负载特征。
3.1 Serverless 的本质：资源弹性与事件驱动
Serverless 的核心抽象是 FaaS（Function as a Service）。开发者只写函数逻辑，平台负责实例的启动、扩容、回收和计费。AWS Lambda 是这类架构的典型代表：函数实例在请求到来时创建，执行完即销毁，计费粒度精确到毫秒级。
企业 IT 架构语境下，Serverless 长期以来被贴上“不适合私有化”的标签，原因有三：私有云环境通常没有成熟的 FaaS 平台；企业应用的调用模式相对固定，弹性需求不明显；运维团队对“看不见服务器”这件事缺乏信任。但当一个企业需要运行上万个 AI 智能体时，情况就变了。智能体的任务负载服从长尾分布——高峰期可能是空闲时的几十倍，用常驻虚拟机支撑这种负载，资源浪费非常严重。
3.2 MCP 与 Serverless 的差异对照
两种架构解决的是不同层面的问题，对照一下就能看出它们为何互补：
| 维度 | MCP | Serverless |
|---|---|---|
| 核心目标 | 工具标准化接入 | 资源弹性调度 |
| 抽象单位 | 工具能力 | 函数逻辑 |
| 调用方 | AI 模型/Agent | 应用/事件触发器 |
| 计费模式 | 按工具调用次数 | 按函数执行时间和资源 |
| 主要场景 | 动态工具集成 | 突发流量、事件驱动任务 |
企业在设计 MCP 中台时，不需要把每个工具都做成 Serverless 函数，但可以把两类工具优先 Serverless 化。一类是调用频率低但偶发性强的工具，比如月度报表生成、临时视频转码；另一类是无状态的计算型工具，比如格式转换、文本处理、图像缩放，这些任务天然适合函数计算。
3.3 MCP Server 在 Serverless 环境下的部署形态
把 MCP Server 跑在 Serverless 平台上的常见做法是使用 Streamable HTTP 传输模式。以 AWS Lambda 为例，需要将 MCP Server 封装成一个 HTTP 端点，让 API Gateway 将外部请求转发给 Lambda 函数执行。
service: mcp-toolbox provider: name: aws runtime: python3.12 memorySize: 1024 timeout: 60 functions: mcp-server: handler: handler.mcp_endpoint events: - httpApi: path: /mcp method: post environment: TOOL_REGISTRY_ENDPOINT: "http://internal-tools-registry:8080"这个配置里的关键参数有三个：memorySize决定函数可用的内存上限，也影响 CPU 配额，处理视频、PDF 这类重型工具建议至少配到 1024 MB；timeout设成 60 秒是因为 MCP 工具调用可能包含外部 API 请求，30 秒默认值在真实业务里经常不够；TOOL_REGISTRY_ENDPOINT指向企业的内部工具注册中心，这样 MCP Server 实例在启动时能动态拉取工具清单。
一个容易踩的坑：Serverless 函数默认是无状态的，而 MCP 会话需要维持上下文状态。解决方案有两种：把状态存到外部存储（Redis 或 DynamoDB），或者确保工具本身是幂等设计——同一请求重复执行不会产生副作用。做视频压缩这类写文件操作时，输出路径要带上请求 ID，避免并发执行时互相覆盖。
4. MCP 中台落地：资源池构成、工具向量化与可信沙盒
MCP 中台的概念有点像企业级应用商店，但服务对象不是人，而是 AI。这个定位决定了中台的架构设计与传统软件分发平台有本质区别：它不仅要管软件的安装和部署，还要解决 AI 如何“找到”对的工具、“信任”工具执行结果的问题。
4.1 MCP 中台的资源池构成
从落地形态看，企业 MCP 中台的资源池通常包含四类资产。第一类是开源软件镜像，比如 ImageMagick、FFmpeg、LibreOffice，这些工具适合以容器镜像形式集中部署，通过 MCP Server 暴露能力；第二类是商业软件镜像，需要考虑许可证管控和授权配置；第三类是 RPA 工具箱，用于打通那些没有 API 的遗留系统；第四类是云服务和 SaaS API，比如对象存储、短信服务、OCR 服务，直接用现成的 SDK 封装成 MCP 工具。
资源池设计上有一个原则：工具描述要面向任务，而不是面向功能。比如“video_tool”这个名字对 AI 来说太模糊，应该描述为“压缩视频、添加水印、格式转换”，这样模型在规划复杂任务时才能准确匹配工具。
4.2 工具描述向量化：让 AI 找到对的工具
中台里工具数量超过几十个之后，工具选择的准确性会快速下降。大模型依赖tools/list返回的全部工具清单来选择，但每次把上百个工具的完整 schema 都塞进上下文，既浪费 token 又容易让模型“看花眼”。常见做法是用向量检索做工具召回。
import numpy as np from openai import OpenAI client = OpenAI() def vectorize_tool(name: str, description: str) -> list[float]: """把工具名和描述转成 embedding 向量""" resp = client.embeddings.create( model="text-embedding-3-small", input=f"{name}: {description}" ) return resp.data[0].embedding def select_tools(user_request: str, tool_index: dict, top_k: int = 5) -> list[str]: """根据用户请求语义召回最相关的工具 ID 列表""" query_vec = vectorize_tool("user_request", user_request) scored = [] for tool_id, meta in tool_index.items(): score = np.dot(query_vec, meta["vector"]) scored.append((score, tool_id)) scored.sort(reverse=True) return [tool_id for _, tool_id in scored[:top_k]]这段代码的逻辑分三层：vectorize_tool把工具名称和描述编码成向量，select_tools计算用户请求向量与每个工具向量的余弦相似度，最后取 top_k 个候选工具交给大模型做最终决策。top_k的取值需要根据工具总数调整——50 个工具时设为 5 比较合适，200 个工具时可以调到 10，但不要超过 15，否则就失去了召回筛选的意义。
这个方案能落地的前提是工具描述写得好。描述文本尽量包含：工具能处理的输入类型、典型使用场景、输出格式、限制条件。比如“图片压缩：将 PNG/JPEG 图片压缩到指定大小，适合网页素材和邮件附件场景，输出格式与原图一致”就比“图片处理工具”有用得多。
4.3 可信沙盒：AI 执行环境的边界设计
让 AI 直接操作用户桌面环境存在安全风险。模型规划失误、恶意提交通道被注入、RPA 脚本操作了错误窗口，这些场景都可能造成无法撤回的损失。可信沙盒要解决的是：AI 可以放开手脚执行，但所有副作用都被限制在一个可回滚的隔离环境里。
相比传统虚拟机，AI 沙盒的启动速度要快，通常要在秒级甚至毫秒级完成创建。因此轻量虚拟化是比 KVM 更合适的技术底座，gVisor 和 Kata Containers 是这一场景下的常见选项。沙盒镜像里预装好 Python 运行时、浏览器、常用 CLI 工具，AI 的所有文件操作、网络请求、进程创建都发生在沙盒内部。
docker run -d \ --name ai-sandbox-01 \ --cpus="2.0" \ --memory="4g" \ --read-only \ --tmpfs /tmp:rw,noexec,size=1g \ --cap-drop ALL \ --security-opt no-new-privileges \ --network bridge \ mcp-sandbox:latest这条命令的参数含义值得逐一说清楚。--cpus="2.0"限制容器最多使用两个 CPU 核心，防止 AI 执行失控时占满宿主机资源；--memory="4g"限制内存上限，超限直接 OOM；--read-only把根文件系统设为只读，AI 只能往/tmp写临时文件，这样即使写了恶意文件也不会污染镜像层；--cap-drop ALL丢弃全部 Linux 内核能力，配合--security-opt no-new-privileges防止提权；--network bridge让容器走 NAT 网络，宿主机可以随时断网隔离。
沙盒的审计机制同样关键。每次工具调用的入参、出参、执行时间、退出码都要写入只读审计日志，日志文件的哈希链定期上链或同步到独立的存储服务。这样即使 AI 在沙盒里执行了可疑操作，事后也能定位到具体是哪次调用引起的，为金融、政务这类强监管场景提供完整的证据链。
5. 软件进化的方向：从买断到可被 AI 调度的能力
原文提出了一个值得深思的判断：传统软件许可模式在 AI 调度面前会面临巨大挑战。一套视频编辑软件卖一百美金，但一个员工手动处理视频的人力成本可能是这个数字的几倍。当 AI 可以按需调用压缩、转码、加水印这些能力时，企业为什么要为每个员工都买一套完整的商业软件？
5.1 软件授权的重构方向
软件从工具私有化转向能力服务化，授权模式也需要同步重构。按年收费的 per-seat 模式将逐渐被按次调用、按用量计费的模式替代。API 网关记录每一次 MCP 工具调用，按照调用次数、处理的数据量、消耗的计算资源计费。这种模式下，软件厂商的商业模式从“卖许可证”变成“卖能力”，续费逻辑从“到期提醒”变成“用量耗尽”，后者的用户粘性反而更强。
5.2 让商业软件被 AI“看见”的工程动作
对应到工程层面，商业软件要融入 MCP 生态，需要完成几项具体改造。接口设计上，所有功能都要暴露为无状态的 API，输入输出用 JSON 描述，避免依赖 GUI 交互；自动化测试要补充针对 AI 调用的测试用例，重点验证参数边界和错误返回的规范性；文档编写要从“给用户看”转向“给模型看”，把每个接口的能力、限制、示例请求都写成结构化描述；收费模式要预留按量计费的埋点。
一个直观的判断标准是：如果一套软件可以用一句自然语言描述清楚它的输入输出，并且可以在沙盒中无人工干预地完成一次完整调用，它就进入了被 AI 调度的候选名单——这也是软件进化的下一轮筛选条件。
本文还有配套的精品资源，点击获取
