一、什么是MCP？

MCP（Model Context Protocol，模型上下文协议） 是由Anthropic推出的一种开放协议，旨在标准化大语言模型与外部数据源、工具之间的交互方式。可以把它理解为AI应用的“USB-C接口”——通过统一协议，让任何MCP客户端（如Claude Desktop、各类AI IDE插件）都能动态发现并调用MCP服务器提供的工具和资源。

简单来说，MCP定义了：

• 工具（Tools）：可执行的函数，AI模型可以调用它们完成具体操作（如查询数据库、发送邮件）
• 资源（Resources）：可被读取的数据源（如文件、API返回结果、数据库记录）
• 提示模板（Prompts）：预定义好的交互模板

MCP Server作为中间层，将现有系统的能力封装成标准化的工具暴露给AI，而无需AI直接对接每个系统的私有API。

二、为什么老项目要关注MCP？

很多团队面临这样一个现实：拥有运行多年的老系统（单体应用、陈旧API、各种历史遗留代码），它们承载着核心业务逻辑。当下AI浪潮来袭，团队希望让AI能“理解”并“操作”这些老系统，常见的思路是：

“干脆用AI重写整个老系统吧，新系统直接原生支持AI。”

这个想法极具诱惑力，但风险极高。而MCP提供了另一条路——不改老系统，让它“长出”AI能力。

三、老项目接入MCP vs 重写全部功能：逐项对比

维度	重写全部功能	老项目接入MCP
成本	极高，通常数十人月起步	低，1-2人周即可完成核心工具封装
风险	高，业务逻辑回归、数据迁移、上线故障	低，老系统零改动，可随时回退
时间	数月到一年	几天到两周
对业务连续性影响	需停机或双写，影响大	零影响，MCP Server独立部署
团队接受度	业务方抗拒，开发压力大	业务无感知，开发开心
能否利用老系统已验证的稳定性	不能，新系统需要重新踩坑	能，完全保留老系统的稳定逻辑
AI能力集成速度	慢，要等新系统上线	快，本周封装下周AI可用
长期维护成本	两套系统并存或完全替换，成本高	MCP Server轻量维护，老系统不变

四、MCP带给老项目的核心好处（重点）

1. 零侵入式集成

MCP Server作为一个独立进程运行，通过标准输入输出（stdio）或SSE与客户端通信。它调用老系统现有的API、命令行、数据库或直接调用业务函数，老系统一行代码都不用改。这意味着：

• 不需要重新部署老系统
• 不需要申请停服窗口
• 不需要回归测试

2. 渐进式暴露能力

你可以按优先级，一步一步把老系统的功能封装成MCP工具：

• 第一周：封装“查询订单”和“查询库存”两个只读工具 → AI能回答客服常见问题
• 第二周：封装“创建工单”工具 → AI能自动处理客户投诉
• 第三周：封装“修改价格”工具（加权限控制） → AI辅助运营人员调价

每次只增加一个工具，随时上线，随时回滚。

3. 天然适合“人机协同”而非“完全自动化”

老项目的很多操作是不可逆的（如财务结算、发货确认）。MCP工具可以设计为“建议模式”——AI给出操作建议和参数，由人类点击确认后再调用MCP工具执行。这样既享受了AI的理解能力，又保留了人工审批的安全阀。

4. 复用现有的鉴权、审计、限流机制

MCP Server调用老系统时，可以携带固定的服务账号Token，老系统原有的操作日志、权限控制、限流策略完全生效。不需要在新AI层重新实现一套安全体系。

5. 一次封装，多端使用

同一个MCP Server可以被多个AI客户端使用：

• Claude Desktop
• Continue、Cline等IDE插件
• 自建的AI Agent框架
• 甚至通过MCP网关暴露给多个团队

这比每个AI应用单独对接老系统API要高效得多。

五、一个真实案例（简化版）

某物流公司的核心调度系统是10年前用Java写的，没有REST API，只有命令行接口和共享数据库。团队想用AI帮助客服查询运单状态、修改配送地址。

重写方案评估：预计6个月，200万预算，业务部门拒绝。

MCP方案：

1. 用Python写一个MCP Server（2天）
2. 封装三个工具：query_shipment（调用现有命令行）、update_address（直接写数据库）、get_customer_contact
3. 在Claude Desktop配置MCP Server
4. 客服人员直接自然语言问：“单号SHP12345的收货地址从A改成B，通知司机了吗？”

结果：一周上线，老系统无任何改动，客服处理时间从平均8分钟降到2分钟。

六、什么时候才应该考虑重写？

MCP不是银弹。当以下情况出现时，重写才是正确选择：

• 老系统的技术栈已经无法维护（如不再支持的操作系统、已淘汰的语言版本）
• 业务逻辑已经严重腐化，没人能说清楚系统到底怎么跑的
• 性能瓶颈无法通过加机器解决，需要架构级重构
• 安全和合规要求已经无法满足（如缺少完整审计日志）

但请注意：即使你决定未来重写，现在用MCP封装老系统让AI先用起来，也是一种“以战养战”的策略——用AI辅助理解老系统行为，为未来的重写积累需求文档和测试用例。

七、总结

你的目标	推荐方案
让AI尽快用上老系统的能力	✅ 接入MCP
低风险、低成本地探索AI场景	✅ 接入MCP
保持业务连续，不折腾老团队	✅ 接入MCP
老系统实在烂透了，必须换掉	❌ 考虑重写
技术栈已被时代抛弃	❌ 考虑重写

MCP的真正价值不是“新技术的炫酷”，而是让老项目体面地活进AI时代，同时把重写的决策权交还给业务本身，而非技术焦虑。

与其花一年重写一个被AI取代的业务，不如花一周让AI用上你已验证了十年的业务逻辑。

---

如果你正在评估老系统AI化改造，欢迎在评论区交流具体场景。