企业官网建设流程全解析

1. 接入前的架构思考：MCP 能解决旧系统的什么问题

先说一个我经常遇到的场景：业务方提了一堆 AI 需求，比如"能不能让大模型帮客户查订单状态""能不能让 AI 直接改一下配置中心的某个开关"或者"能不能让 AI 助手替运营查一下昨天的数据报表"。需求听起来不复杂，但一翻代码发现全是十年前的架构：数据库表几十张、核心服务还是一个老单体、接口文档早就过时了，更别提什么微服务治理。

这时候摆在面前的选项无非三个：重写核心让系统原生支持 AI、在旧系统旁边做一个"胶水层"对接 AI、或者让 AI 直接调旧系统的接口。第一个方案基本等于推倒重来，周期和风险都大到没法立项。第二个方案听着常规，但做起来很容易演化成"每个 AI 需求写一个专用接口"，最后变成一个谁也维护不了的接口泥潭。第三种方案最直接，但往往意味着 AI 要拿到数据库连接串或者一堆内部接口的调用权限，安全隐患先不谈，光是让大模型自己拼 SQL、找接口文档这件事就极其不靠谱。

这时就轮到 MCP（Model Context Protocol，模型上下文协议）出场了。它是一个把"AI 能力"和"工具能力"解耦的开放协议，通俗地说，MCP 定义了一套标准的"对话规则"，让各种 AI 应用（比如 Cursor、Claude Desktop，甚至你自己写的 Agent）能够通过统一的方式去调用外部工具和获取上下文数据。你可以理解为：过去每家 AI 应用都自己发明一套"插U盘"的方式，现在大家统一了口径，插进去就能用。对于旧系统来说，MCP 的价值不在于它是一个什么高深的协议，而在于它提供了一种"低成本、非侵入"的方式——你不需要改动旧系统的核心逻辑，只需要在旁边包装一层符合 MCP 协议的适配器，把旧系统已有的能力"翻译"成 AI 能理解和调用的工具，就算接上了。

这篇文章就是围绕这个思路展开的。我会从架构选型、核心协议概念、两个方向的接入实操（旧系统能力反向暴露给 AI、旧系统主动调用外部 MCP 能力）、常见问题排查这几个维度来讲，目标是让你看完之后能直接在自己的老系统上做一次完整的 MCP 接入验证。

1.1 两个接入方向，先搞清楚你要的是哪个

很多人一听到"MCP 接入"就直接开始想怎么把系统做成 MCP Server，其实 MCP 的接入有两条完全相反的路径，方向搞错了后面全是白做。

方向一：旧系统作为 MCP Server，把已有能力暴露给 AI。这种场景下，AI 是"甲方"，你的旧系统是"乙方"。AI Agent 通过 MCP 协议调用你系统里已有的能力，比如查订单、查库存、触发某个流程、读取某个报表。热词里提到的"ruoyi-vue-pro 合并 MCP 功能""同花顺 MCP""hermes 接入 MCP"基本都属于这个方向——它们做的是把已有业务能力包装成 MCP 工具，让 AI 可以直接调用。这个方向适合"业务方希望 AI 能自己干活"的场景，典型产品形态是智能助手、业务机器人、AI 运营工具。

方向二：旧系统作为 MCP Client，主动去消费外部的 MCP Server 能力。这种场景下，你的旧系统是"甲方"，外部 AI 能力是"乙方"。旧系统通过 MCP 协议去调用一个远程的 MCP Server，这个 Server 背后可能是某个大模型的能力封装，也可能是某个第三方工具的 MCP 实现（比如 Playwright MCP、Chrome DevTools MCP）。这个方向适合"旧系统需要嵌入 AI 能力，但又不想直接对接各家大模型厂商的私有 API"的场景。典型例子就是：你的老系统里有个"智能测试"模块，后端要调用浏览器自动化能力去做回归测试，你不需要自己实现浏览器控制，直接通过 MCP Server 调 Playwright 就行。

从我的经验看，绝大多数旧系统接入 MCP 的需求是方向一，因为业务方想要的是"让 AI 用上我们的数据"，而不是"让我们的系统用上 AI"。但方向二在测试平台、运维平台、自动化工具这类内部系统中也很常见。写代码之前一定要把需求方到底要哪个搞清楚，否则架构设计出来就偏了。

1.2 为什么"不重写核心"这条路值得优先考虑

我见过不少团队接到 AI 需求后，第一反应是"我们给系统加一个 AI 模块吧"，加着加着就变成了"我们要不要上个智能体框架""要不要把老模块重构成服务化"。不是说这些想法不对，而是在旧系统这种约束条件下，MCP 提供的"轻触式接入"有它不可替代的优势。

第一个优势是核心代码零改动。MCP Server 或 MCP Client 都是独立进程（或独立模块），通过 JSON-RPC 和旧系统交互。你甚至可以把 MCP Server 部署在一台单独的机器上，通过旧系统已有的 HTTP 接口、数据库视图、消息队列去拿数据、做操作。核心服务不需要重新编译，不需要修改数据库表结构，不需要改依赖，这直接砍掉了"重写核心"的大部分风险。

第二个优势是接入是渐进式的。不需要规划一个大版本去把所有功能都暴露给 AI，完全可以先挑两个高频场景做试点，比如"查订单状态"和"查库存"，跑通了再扩大范围。这种模式对于预算有限、业务又不能停的团队来说，几乎是唯一可行的路径。

第三个优势是治理逻辑集中在适配层。谁有权限让 AI 调用什么工具、调用频次怎么限制、敏感字段要不要脱敏，这些都可以在 MCP Server 这一层统一处理，不需要散落到业务代码里。后续 AI 合规要求越来越严的时候，你会发现这个"集中治理点"的价值比想象中大得多。

2. 核心概念拆解：MCP 的 Host、Client、Server 和三种原语

动手之前，我强烈建议先把 MCP 协议的几个核心概念吃透。这东西说复杂也复杂，说简单也简单，如果你写过 WebSocket 或者 JSON-RPC，上手会非常快。

2.1 Host、Client、Server 各自扮演什么角色

MCP 的架构是经典的三层结构：

• MCP Host：用户直接交互的 AI 应用，比如 Claude Desktop、Cursor、自研的 Web 聊天界面。Host 负责理解用户的意图，然后决定调用哪个工具。
• MCP Client：Host 内部与 Server 建立连接的组件，负责协议层面的握手、会话管理、请求转发。在 MCP 的 SDK 里，Client 通常是一段代码，不是独立进程。
• MCP Server：暴露具体工具、资源、提示词的服务端程序。它可以是本地进程（通过 stdio 通信），也可以是远程服务（通过 HTTP 通信）。你的旧系统如果作为服务方，承担的就是这个角色。

我画个不太严谨但很好理解的类比：Host 是大脑，Client 是手，Server 是工具箱。大脑决定要拧螺丝，手去工具箱拿螺丝刀（工具），工具箱把螺丝刀递出来。MCP 协议管的是"手怎么去工具箱拿东西"这个过程。

对旧系统接入来说，最关键的认知是：MCP Server 不一定是"你写的一个新服务"，它可以是"包在旧系统外面的一层翻译官"。旧系统内部的代码完全不用知道 MCP 的存在，翻译官负责把 MCP 请求翻译成旧系统内部的调用（HTTP、RPC、SQL、Shell 都行），再把结果翻译回 MCP 协议格式。

2.2 Tools、Resources、Prompts 三种原语各有什么用

MCP 协议定义了三种核心原语，理解它们的分工是做好适配层设计的前提：

这三个里面最关键的是 Tools。AI Agent 能不能真正"干活"，取决于你暴露了多少个设计良好的 Tools。Resources 的作用也很容易被低估——很多旧系统的业务口径、术语、规则只有老员工知道，把这些东西做成 Resources 喂给 AI，能显著降低 AI 的"胡言乱语"概率。

2.3 传输层：stdio 和 Streamable HTTP 怎么选

MCP 目前主流的传输方式有两种：stdio（标准输入输出）和Streamable HTTP（流式 HTTP）。

stdio 是 MCP Server 作为本地子进程运行时的方式，Host 启动 Server 进程，通过标准输入输出流交换 JSON-RPC 消息。这种方式适合开发调试，也适合本地工具类集成（比如热词里提到的 Cursor 配置本地 MCP Server 就是典型）。缺点是不能跨机器——Server 和 Host 必须在一台机器上。

Streamable HTTP 则把 MCP 消息封装在 HTTP 请求里，Server 可以部署在远程，Host 通过网络访问。它还支持 Server-Sent Events（SSE）做服务端推送，适合长耗时的工具调用。旧系统接入时如果服务端不在本机、或者要供多人使用，基本都会选 Streamable HTTP。

我在实际项目里的选型标准很简单：本地个人工具用 stdio，团队共享或线上服务用 Streamable HTTP。另外注意一点，MCP 的 HTTP 传输不是 RESTful API，它的端点更像一个"消息入口"，请求体是 JSON-RPC 格式。如果有团队成员习惯性地用 REST 思维去调 MCP HTTP 端点，多半会一头雾水。

2.4 协议版本和"软件协议、硬件协议"的认知误区

热词里有一条"mcp 是软件协议 硬件协议那个概念叫什么来着"，这里顺便说清楚一下：MCP 是软件协议，和它经常并列出现的是 ICP/IP 这类网络协议，以及 USB、HDMI 这类硬件接口协议。MCP 不关心你的系统跑在什么网络上、用什么语言写的、数据库是哪一家，它只关心"AI 应用和工具服务之间怎么交换消息"。这种分层设计正是它能作为"旧系统适配层"的原因——协议层和实现层完全解耦。

协议版本方面，现在主流 SDK 支持的是 2024-11-05 版本，2025-03-26 版本也开始普及了。如果你用的是官方 SDK，版本通常会自己协商好；如果手写协议实现，务必在 initialize 请求里声明协议版本，并且做版本兼容判断。很多手写实现连不上 MCP Server，八成是这一步没做好。

3. 实操方向一：把旧系统能力封装成 MCP Server

这个方向是重头戏。我拿一个虚拟案例来讲：假设你有一个老旧的订单管理系统，核心是单体 Java 应用，对外提供了一些 HTTP 接口（但文档不全、参数语义模糊），数据库是 MySQL，里面有几个核心表。现在要让 AI 能查订单、能改订单备注、能拉取每日订单统计。下面是我推荐的分步骤实操路径。

3.1 第一步：盘清楚旧系统有哪些能力值得暴露

别急着写代码，先做一次"能力盘点"。和普通接口设计不同的是，给 AI 暴露能力要站在"AI 能理解、能正确调用"的角度去筛选。我的原则是：按任务暴露，不按接口暴露。

举例来说，旧系统里可能有一个GET /api/order?orderNo=xxx&userId=yyy&status=zzz的接口，参数有七八个，里面还有一堆历史遗留的兼容逻辑。这个接口直接暴露给 AI 很容易出问题——AI 不知道该传哪些参数、不知道返回结果里哪些字段有用。正确做法是把"查订单详情"设计成一个 MCP Tool，参数只需要orderNo一个，返回结果挑出 AI 真正关心的字段（订单状态、金额、收件人、物流单号），按统一的结构返回。

这个步骤的核心产出是一张表：业务任务、对应旧系统能力、参数设计、返回结构设计、权限级别。有了这张表，后续的 MCP Server 开发就是机械劳动了。下面是一个我常用模板：

3.2 第二步：用官方 SDK 快速搭起一个 MCP Server

MCP 官方提供了 Python、TypeScript、Java、Kotlin 等多个语言的 SDK。我推荐用 Python 或 TypeScript 来做适配层，因为这两个的 SDK 最成熟、社区资料最多。下面以 Python 为例演示一个最小可用的 MCP Server。

首先安装 SDK：

pip install mcp

然后写一个最简单的 Server，暴露一个 "query_order" 工具：

from mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import Tool, TextContent import json, requests app = Server("legacy-order-mcp") # 旧系统接口的 Base URL，从配置文件读取 LEGACY_API_BASE = "http://legacy-order-service:8080/api" @app.list_tools() async def list_tools(): return [ Tool( name="query_order", description="根据订单号查询订单详情，返回订单状态、金额、物流等核心信息", inputSchema={ "type": "object", "properties": { "order_no": {"type": "string", "description": "订单号，必填"}, }, "required": ["order_no"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "query_order": order_no = arguments.get("order_no") # 调用旧系统接口，这里只做最基础的错误处理 resp = requests.get(f"{LEGACY_API_BASE}/order", params={"orderNo": order_no}, timeout=10) resp.raise_for_status() data = resp.json() # 只挑出 AI 关心的字段，避免把整个响应对象扔给 LLM result = { "order_no": data["order_no"], "status": data["status"], "amount": data["amount"], "logistics_no": data.get("logistics_no", ""), "receiver": data.get("receiver_name", "") } return [TextContent(type="text", text=json.dumps(result, ensure_ascii=False))] raise ValueError(f"Unknown tool: {name}") async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream) if __name__ == "__main__": import asyncio asyncio.run(main())

这段代码看着简单，但里面的几个设计细节其实是反复踩坑后才定下来的：

只返回核心字段这个点非常重要。MCP Server 返回给 AI 的内容会直接进入 LLM 的上下文窗口，如果你把旧系统整个 Response 对象丢过去，几十个字段里可能有一堆是 AI 不需要的，甚至包含敏感信息。截断、精简、脱敏，这一步应该在 MCP Server 层完成，而不是期望 AI 自己会过滤。

描述信息要写得像给实习生看。inputSchema里的 description 字段是 LLM 决定"怎么调用这个工具"的关键依据。你描述得越清楚，AI 的调用成功率越高。我见过很多人随便写一句"查询订单"，结果 AI 经常猜错参数含义。正确的做法是像上面的代码一样，把参数说明、返回内容要点都写清楚，甚至可以补充参数格式示例。

3.3 第三步：连接 AI Client 实测

Server 写好后，先用官方提供的 MCP Inspector 做协议级调试。运行：

npx @modelcontextprotocol/inspector python server.py

Inspector 会打开一个图形界面，可以手动调用 Tools、看协议消息、检查返回格式。这一步能排除掉 90% 的协议层问题（比如参数格式错误、返回类型不对、Tool 没有注册成功）。

协议调试通过后，再到真实的 AI 客户端里去测。现在主流的客户端基本都支持"添加 MCP Server"，比如 Cursor、Claude Desktop、Cherry Studio 等。打开配置界面，填上启动命令（stdio 模式）或者 Server URL（HTTP 模式），加完就能在对话里体验"AI 帮你查订单"了。

如果你用的是 TypeScript 技术栈，也可以直接用@modelcontextprotocol/sdk的McpServer类写，核心的registerTool和registerResource方法设计得比 Python 版更顺，社区示例也更多，我个人在做正式项目时反而更喜欢 TypeScript 版本。

3.4 第四步：加上权限控制、限流和审计

这一步千万别省。MCP Server 一旦部署上线，AI 就成了一个"超级用户"，它能调用你暴露的所有工具，比你团队的任何一个普通成员权限都大。常见的风险点是：AI 在对话中可能被诱导执行高风险操作（比如删数据、批量修改）、也可能因为工具设计不当被反复调用导致后端压力飙升。

我建议至少做三层防护：

• 工具级白名单：不在清单里的工具一律拒绝调用，输出清晰错误信息。
• 参数校验：在 MCP Server 层做参数合法性校验，不要指望 AI 次次都传对。比如订单号必须符合格式，日期区间必须合法，金额不能为负。校验不通过要返回可读的错误提示，让 AI 能根据错误信息自我纠正。
• 调用限流和审计：记录每个会话的调用日志，包括谁调的、调了什么工具、传了什么参数、返回了什么。这个日志后续既是排查问题的依据，也是 AI 合规审计的凭证。

我遇过一个真实事故：一个 AI 助手工具暴露了"导出报表"能力，结果有用户在对话里反复让 AI 导出几十次，每次都触发后台生成大文件，差点把文件存储打满。后来加了一分钟限流 5 次、单日导出上限 20 次，才把这类问题压住。不要觉得只有高权限接口才需要限流，耗资源的接口同样需要。

4. 实操方向二：让旧系统主动调用外部 MCP Server

如果你的需求是"旧系统要用上 AI"，而不是"AI 要用上旧系统"，那方向二更合适。这个方向的核心是：在旧系统代码里嵌入一个 MCP Client，通过它去调用某个远程 MCP Server 的能力。

4.1 典型场景：AI 能力嵌入老平台

举两个常见场景。第一个是内部工单系统要加一个"AI 智能回复"功能：用户提交工单后，系统自动调用一个部署在外部的 AI 服务，让它基于历史工单记录生成回复草稿。你不需要在工单系统里接入大模型厂商的私有 SDK，只需要统一通过 MCP Client 去调一个封装好的 MCP Server 就行。

第二个是自动化测试平台：老测试平台要支持"自然语言生成测试用例"或者"自动执行浏览器操作"，典型的热词组合就是 Playwright MCP 和 Chrome DevTools MCP。测试平台后端通过 MCP Client 去调 Playwright MCP Server，让 AI Agent 能直接操作浏览器页面、抓取元素、断言结果。这种做法的好处是浏览器控制和 AI 决策都外包给了 MCP 生态，你自己的系统只负责"发起任务、接收结果"。

4.2 用 Python SDK 写一段最小可用的 MCP Client

import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): # 这里假设本机已安装了 playwright-mcp-server 的可执行文件 server_params = StdioServerParameters( command="npx", args=["-y", "@playwright/mcp@latest"], env=None ) async with stdio_client(server_params) as (read_stream, write_stream): async with ClientSession(read_stream, write_stream) as session: await session.initialize() tools = await session.list_tools() print("可用工具列表：", [(t.name, t.description) for t in tools.tools]) # 调用一个浏览器导航工具 result = await session.call_tool( name="browser_navigate", arguments={"url": "https://example.com"} ) print("调用结果：", result) asyncio.run(main())

这段代码做的事情是：启动本地的 Playwright MCP Server 子进程，建立 MCP 会话，列出它支持的所有工具，然后调用其中一个工具让浏览器打开一个页面。整个过程你的主系统没有直接依赖任何 Playwright 的库，全部通过 MCP 协议达成了目的。

如果你是走远程 HTTP 模式，用mcp.client.streamable_http里的streamablehttp_client替换stdio_client即可，参数从 command 换成一个 URL，然后处理对应的鉴权 Header。

4.3 接入时的三个设计要点

要点一：把 MCP 调用包装成你系统的领域服务。不要让业务代码直接和 MCP Client 交互，而是封装一层，比如定义一个AiAssistantService，业务代码只调generateReply(ticket) -> str，内部再去走 MCP 会话。这样后续如果 MCP Server 地址变了、或者换了一家大模型服务商，你只需要改这一层，业务代码零改动。

要点二：管理好连接生命周期。MCP Client 和 Server 的连接是可以复用的，不要每次调用都重新握手初始化，这样性能和稳定性都很差。建议把 Client 做成单例，用连接池管理，超时时间根据你调用的工具类型灵活配置。有些长耗时工具（比如浏览器自动化、大数据分析）可能需要几十秒甚至几分钟，这时候就要在协议层面支持 SSE 流式返回或任务异步化。

要点三：错误处理要面向 AI 调用设计。旧系统内部的错误码千奇百怪，MCP Server 返回的错误信息如果还是"ERR-2043：系统内部错误"，AI 拿到这种信息也没法自我修复。接回来的错误信息要做一次翻译，变成 AI 能理解的话，比如"订单号不存在，请确认后重试"。这属于很小但很影响体验的细节。

5. 常见问题与排查技巧实录

MCP 接入过程中一定会踩到一些坑，这里把我在多个项目里遇到的高频问题整理成一份速查表，都是实操中真正需要留意的点。

5.1 连不上 Server，日志也没有任何输出

排查这个问题，先分清是进程没启动、握手失败了还是工具注册失败了。最有效的办法是打开 MCP Inspector，它会把每个阶段的协议日志都显示出来。如果 Inspector 能连上而你的 AI 客户端连不上，多半是客户端的 Server 配置命令写错了。这里有个小技巧：把 Server 启动命令先手动在终端里跑一遍，看能不能正常输出 MCP 协议标志（stdio 模式下，Server 启动后会在 stdout 打印一行{"jsonrpc":"2.0","method":"initialize"...}类似的内容），只有这一步通过了，才能证明 Server 本身没毛病。

注意：stdio 模式下，Server 的日志不能直接打到 stdout，否则会污染 MCP 协议消息。调试时用 stderr 打日志，或者把日志写到独立的文件里。很多"连不上"的诡异问题其实都是往 stdout 里打了普通日志导致的。

5.2 工具调用超时

MCP 默认的请求响应模式适合快速操作，但旧系统的一些接口本身就慢，比如查一个跨月的报表可能要几十秒。这时候如果在 MCP Server 里同步等待结果，请求大概率会超时。我的做法是：把慢操作改成"任务提交 + 轮询结果"模式。Tool 提交任务后立刻返回一个task_id，同时 Server 端异步执行，AI 再通过另一个 Tool（比如get_task_result）轮询结果。这个模式虽然多了一个步骤，但对慢接口来说是唯一稳妥的方案。

5.3 工具参数校验不过，AI 反复做无用尝试

大模型调用工具时偶尔会搞错参数类型，比如把整数当字符串传、日期格式不对、漏传必填字段。如果 Server 端校验失败就只返回一个简单的 "invalid params"，AI 会自己乱猜然后再次尝试，浪费时间和 token。更好的做法是返回带指导性的错误信息，比如 "参数 order_no 格式不正确，应为 YYYYMMDD + 6 位数字，例如 20250101000123"。实测这样处理后 AI 的下一次尝试成功率大幅提升，这是 Agent 场景下的一个经典调优点。

5.4 日志管理怎么做才够用

MCP Server 的日志管理之所以常被忽略，是因为它不像 Web 服务那样有个标准的 access log。我建议至少做三层：协议层日志（记录所有进来的 JSON-RPC 请求和返回）、工具层日志（记录每个 Tool 调用的参数、耗时、结果摘要）、审计日志（记录用户身份、会话 ID、操作时间）。前两层用标准 logger 输出到文件或收集系统即可，审计日志建议单独存，可以落到独立表或独立文件，方便将来追溯。不要试图把所有日志都打到一个流里，不然出问题的时候根本没法查。

5.5 回写数据怎么打通

热词里有一条"mcp 回写打通"，指的是 AI 操作完数据后把结果写回业务系统的能力。回写比读数据复杂得多，因为涉及事务、幂等、权限。我的经验是：回写接口必须做幂等设计，在 MCP Server 层拿一个外部幂等键（比如订单号 + 操作类型 + 时间戳哈希），同一个请求重复提交多次也只生效一次。AI 的特性决定了它可能因为上下文混乱而重复调用同一个工具，幂等是防备这个问题的唯一可靠手段。

5.6 手写 JSON-RPC 实现 MCP，最常见的问题在哪

如果不用官方 SDK 而是手写协议实现，最常见的坑有三个。一是 initialize 握手阶段的protocolVersion没处理兼容，新版 Server 和旧版 Client 互相不认。二是工具调用响应格式不对，content数组里每一项必须是{type: "text", text: "..."}这种规范结构，很多人习惯性返回纯字符串。三是缺少notifications/initialized通知——握手后必须发这个通知，有些实现省略了这一步，结果后续工具调用就静默失败。手写协议对理解 MCP 非常有帮助，但生产环境还是建议大家直接用官方 SDK，没必要重复造轮子。

6. 接入后的效果评估与范围扩展

MCP Server 上线后，怎么判断接入质量好不好？我的衡量标准是：看 AI 在真实业务场景中的任务完成率。简单说就是，用户给 AI 提一个请求，AI 能否通过调用你暴露的工具正确完成操作。可以在测试阶段设计一组标准任务，比如"帮我查订单 20250101000123 的物流状态"，然后看 AI 第一次调用工具就成功的比例。如果这个比例低于 80%，大概率不是 AI 能力问题，而是工具设计问题——参数说明不清、返回字段混乱、错误信息没有指导性，逐一排查。

范围扩展上，MCP 接入从来不是一步到位的事情。我习惯的做法是按"只读 → 低风险写 → 高风险写"的节奏推进。第一批只暴露查询类工具，验证 AI 的数据理解能力；第二批暴露备注修改、状态流转这类低风险操作；第三批才考虑让 AI 做批量操作或者跨系统联动。这个节奏能让业务方逐步建立对 AI 的信任，也能给运维留出观察窗口。

另外一个值得留意的方向是多 AI 协作。MCP 协议本身支持一个 Host 连接多个 Server，这意味着你可以让一个"主 Agent"同时调用旧系统工具、内部知识库资源、甚至外部第三方工具，形成一个复合智能体。热词里提到的"多 AI 协作"很多就是这么落地的——不是让几个大模型互相聊天，而是让几个通过 MCP 暴露出来的能力服务在一个任务链路里协同工作。

我个人在实际操作中的体会是：MCP 接入旧系统这件事，方法论的价值远大于代码量。一套设计良好的 MCP 适配层，本质上是在梳理你旧系统的能力边界——你有哪些能安全暴露给 AI 的能力、哪些必须藏起来、哪些需要脱敏、哪些需要限流。这些思考本身就是对系统的一次"AI 化体检"。即使将来 MCP 协议被更新的标准替代，这套适配层的设计思想仍然会延续下去。