部署DeepSeek模型,进群交流最in玩法!
立即加群
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >从小白视角理解什么是MCP

从小白视角理解什么是MCP

原创
作者头像
GeekLiHua
发布于 2025-06-06 08:12:54
发布于 2025-06-06 08:12:54
20900
代码可运行
举报
文章被收录于专栏:大模型大模型
运行总次数:0
代码可运行

从小白视角理解什么是MCP

一、初始阶段:Prompt工程的局限性(2020-2023)

1. System Prompt与User Prompt的分工机制

核心设计

代码语言:plaintext
AI代码解释
复制
┌───────────────────────┐       ┌───────────────────────┐  
│   System Prompt        │       │   User Prompt          │  
│ (开发者预设)         │       │ (用户实时输入)       │  
├───────────────────────┤       ├───────────────────────┤  
│ • 定义AI角色           │──────▶│ • 具体任务指令         │  
│   (e.g., 翻译助手)      │       │   (e.g., 翻译"Hello World")│  
│ • 设定输出格式边界      │       │ • 补充上下文信息       │  
│ • 注入安全约束         │       └───────────────────────┘  
└───────────────────────┘  
  • System Prompt:作为模型的“底层操作系统”,在会话全程生效。例如设定“你是一个严谨的医疗顾问,回答需附文献来源”。
  • User Prompt:仅作用于当前交互,如用户追问“上述疾病的治疗方案是什么?”。

⚠️ 分工缺陷:双Prompt架构虽区分了“身份”与“任务”,但本质仍是封闭文本交互,如同给囚徒递纸条——信息无法突破牢笼。

2. 核心问题:静态知识库的致命瓶颈

问题可视化

代码语言:plaintext
AI代码解释
复制
用户问题 → 模型知识库 → 输出结果  
          │  
          └──▶ 知识边界:训练数据截止点  
               (e.g., GPT-3数据止于2021年)  

典型场景对比

用户需求

理想响应

实际响应(受限于静态数据)

“纽约今天气温多少?”

调用API返回实时数据

基于历史数据猜测:“约25℃”

“特斯拉最新股价?”

连接金融接口获取报价

输出训练时记忆的过时价格

“帮我订明早8点北京飞上海的机票”

执行多步工具调用(查航班→比价→下单)

回复“我无法操作外部系统”

根本矛盾:模型如同与世隔绝的学者,只能复述书本知识,无法感知现实世界动态。

3. Prompt工程的系统性缺陷

除静态数据问题外,更深层瓶颈包括:

  1. 设计复杂度陷阱
    • 优质Prompt需精确组合角色+任务+格式(如“以表格形式输出近5年诺贝尔经济学奖得主及贡献”)
    • 普通用户难以掌握设计技巧,错误示例如下: ❌ 模糊指令: “说说经济学奖” → 可能返回冗长无关内容 ✅ 结构化指令: “你是一名经济学史教授,用Markdown表格列出2019-2023年诺奖得主,包含获奖理由”
  2. 输入格式敏感性
    • 细微差异导致输出崩溃: System Prompt: “你是一个JSON生成器” User Prompt: “生成用户数据:姓名 年龄 职业” → 错误:未指定键名和分隔符,输出混乱 修正: “生成{name: string, age: int, job: string}格式的JSON”
    • 复杂任务需严格分隔符(如---划分指令与数据),否则模型解析失败。
  3. 上下文记忆短板
    • 对话超过token限制(早期模型仅4K)时,关键信息丢失: 用户: “我住在北京(之前对话已说明),推荐周末活动” 模型: “请先告诉我您所在城市?”
    • 临时解决方案:人工分段输入,打断交互流畅性。
  4. AI幻觉与不可控性
    • 即使明确要求“仅基于已知数据回答”,模型仍编造看似合理的错误答案:
代码语言:plaintext
AI代码解释
复制
     > 用户问虚构概念:“量子引力理论的最新突破”  
     > 模型虚构:“2023年哈佛团队发现量子引力子,获《Nature》封面报道”  
     这类幻觉在专业领域危害极大(如医疗、法律)。  
4. 技术债:Prompt工程的长期成本
代码语言:plaintext
AI代码解释
复制
短期收益 vs 长期技术债  
├─ ✅ 快速上线:无需重训模型,调整文本即可优化输出  
├─ ✅ 低成本试错:修改Prompt比调整模型参数更简单  
└─ ❌ 债务累积:  
   ├─ 脆弱性:模型微调导致Prompt失效(如GPT-3.5→GPT-4)  
   ├─ 维护成本:业务规则变化需重构整套Prompt(如电商促销规则更新)  
   └─ 能力天花板:无法突破文本交互范式,阻碍真正行动智能  

案例:某客服系统依赖200+精细Prompt,模型升级后30%指令失效,修复耗时相当于重开发。


Prompt工程的局限框架

代码语言:plaintext
AI代码解释
复制
          ┌──────────────┐  
          │ 用户现实需求 │  
          └──────┬──────┘  
                 ↓  
  ┌───────────────────────────┐  
  │ Prompt工程系统            │  
  │ ┌────────┐  ┌──────────┐ │  
  │ │静态知识│◀─┤无法调用工具│ │  
  │ │ 库     │  │(API/设备) │ │  
  │ └───┬────┘  └──────────┘ │  
  │     │                    │  
  │  ┌─▼───────┐  ┌────────┐ │  
  │  │复杂任务  │  │设计维护│ │  
  │  │分步中断◀┼──┤成本飙升│ │  
  │  └────────┘  └────────┘ │  
  └───────────────────────────┘  
                 ▼  
          ┌──────────────┐  
          │ 局限爆发点   │  
          │ • 动态数据需求│  
          │ • 多步工具操作│  
          └──────────────┘  

此阶段局限本质上源于纯文本交互范式的先天不足,直接催生了Agent与工具调用技术的诞生。


二、破局尝试:AI Agent与Agent Tools(2023-2024)

1. AI Agent的诞生:从“思考”到“行动”的质变

核心突破:通过规划(Planning)、记忆(Memory)、工具使用(Tool Use) 三组件,赋予大模型动态执行复杂任务的能力,实现“认知-决策-执行”闭环。

技术架构与典型场景

代码语言:plaintext
AI代码解释
复制
┌───────────────────┐         ┌───────────────────┐         ┌───────────────────┐  
│   用户指令         │         │   AI Agent决策层   │         │   工具执行层       │  
│  (高层目标)        │───────▶│  ┌──────────────┐  │────────▶│  ┌─日历工具       │  
│  "写周报"          │         │  │ 任务规划引擎  │  │         │  │ 查日程          │  
└───────────────────┘         │  │ (拆解子任务)  │  │         │  └───────────────┘  
                               │  └──────────────┘  │         │  ┌─文档分析工具    │  
                               │  ┌──────────────┐  │         │  │ 提取会议记录    │  
                               │  │ 记忆管理系统  │◀─┼───┐     │  └───────────────┘  
                               │  │ (情境记忆库)  │  │   │     │  ┌─邮件客户端      │  
                               │  └──────────────┘  │   └─────▶│  │ 发送周报        │  
                               └───────────────────┘         └───────────────────┘  
  • 规划引擎
    • AutoGPT:将“写周报”拆解为「查日程→提取会议记录→总结成果→邮件发送」
    • 荣耀AI Agent:用户说“取消订阅”时,自动跳转支付页面操作
  • 记忆系统
    • 短期记忆:缓存当前任务上下文(如用户偏好“周报需包含KPI数据”)
    • 长期记忆:通过向量数据库存储历史行为模式(如“用户常周一提交周报”)
  • 工具使用
    • 浏览器操控(Browser Use):Manus通过网页自动化工具操作电商页面
    • API调用:Kimi模型自动判断调用计算器或天气API

技术意义:AI Agent使大模型从“被动应答者”升级为“主动执行者”,首次实现端到端任务闭环。


2. Agent Tools的碎片化困境:繁荣背后的技术债

尽管单点工具能力强大,但生态缺乏统一标准,引发 “M×N集成问题”

代码语言:plaintext
AI代码解释
复制
       M种模型                          N种工具  
    ┌─────────────┐                  ┌─────────────┐  
    │ GPT-4        ├─┐                │ 日历API     │  
    ├─────────────┤ │                ├─────────────┤  
    │ Claude 3     ├─┼─────需要开发─────┤ 邮件系统    │  
    ├─────────────┤ │   M×N个定制连接器  ├─────────────┤  
    │ DeepSeek R1 ├─┘                │ 支付接口     │  
    └─────────────┘                  └─────────────┘  

典型问题

  1. 开发成本爆炸
    • 5种模型 × 10种工具 → 需开发50个定制化连接器
    • 每个连接器需独立适配数据格式(如Slack消息结构 vs. 数据库Schema)
  2. 维护噩梦
    • 工具接口变更(如Twitter APIv1→v2)导致所有相关连接器失效
    • 模型更新(如GPT-4→GPT-4o)需重写工具调用逻辑
  3. 能力割裂
    • 工具间无法互操作(如“查航班→订酒店”需人工传递数据)
    • 跨厂商Agent协作困难(如OpenAI Agent无法直接调用Anthropic的MCP工具)

💥 行业痛点案例:某企业部署客服Agent时,为集成CRM、支付、物流系统开发12个定制连接器,耗时3个月,每次系统升级平均触发2个连接器故障。


3. 技术卡点:缺乏统一协议的连锁反应

碎片化问题暴露三大本质矛盾:

矛盾维度

表现案例

技术根源

协议缺失

Manus网页操作工具无法被Claude调用

无标准接口描述规范

安全割裂

每个工具需独立实现OAuth认证

无统一身份管理机制

状态隔离

用户偏好需在每个工具重复配置

无跨会话上下文传递协议

🔧 破局方向:行业亟需解决 “工具互操作性” 问题,直接催生Function Calling过渡方案与MCP协议的诞生。


技术演进启示

  • 短期价值:AI Agent证明了工具调用可实现任务自动化(如节省40%客服人力)
  • 长期瓶颈:碎片化生态制约规模化应用,标准化协议成为刚需
  • 行业共识“没有统一的工具协议,Agent生态就像1980年代的计算机网络——局部智能,全局混乱。”

此阶段的技术探索既揭示了行动智能的可行性,也以残酷的工程代价证明了协议标准化的必然性,为MCP的横空出世埋下伏笔。


三、过渡方案:Function Calling的探索(2023-2024)

1. 技术诞生:从Prompt到函数调用的质变

OpenAI于2023年6月推出函数调用功能,首次实现自然语言→结构化指令的自动转换,标志着大模型从“纯文本交互”迈向“工具协作”的关键一步。其核心设计包含三层:

代码语言:plaintext
AI代码解释
复制
┌───────────────────────┐     ┌───────────────────────┐     ┌───────────────────────┐  
│     用户自然语言输入    │───▶│  大模型意图解析与函数选择  │───▶│  结构化函数调用指令生成   │  
│  (e.g., "纽约今天气温") │     │ • 匹配预定义工具库       │     │ {"name":"get_weather",  │  
└───────────────────────┘     │ • 提取参数规则           │     │  "arguments":{...}}    │  
                              └───────────────────────┘     └───────────────────────┘  
  • 动态接口生成:模型将口语指令(如“查股票”)转化为机器可执行的JSON指令
  • 开发者控制权:需预先定义工具库(如函数名、参数类型、描述),通过System Prompt注入模型 ✅ 突破性价值:首次实现实时数据接入(如股价/天气),解决大模型“知识冻结”问题。

2. 核心机制:标准化交互的首次尝试

以天气查询为例,典型开发流程如下:

代码语言:python
代码运行次数:0
运行
AI代码解释
复制
# 1. 工具注册:定义函数签名(开发者的“说明书”)  
tools = [{  
    "name": "get_weather",  
    "description": "查询指定城市的实时天气",  
    "parameters": {  
        "location": {"type": "string", "description": "城市名称,如'北京'"},  
        "date": {"type": "string", "description": "日期,默认当天"}  
    }  
}]  

# 2. 模型解析:用户问“纽约今天多少度?” → 返回调用指令  
response = openai.ChatCompletion.create(  
    messages=[{"role": "user", "content": "纽约今天多少度?"}],  
    tools=tools  
)  
# 返回结果:{"name": "get_weather", "arguments": {"location": "New York"}}  

# 3. 手动执行:开发者调用真实天气API  
weather_data = call_weather_api(location="New York")  

# 4. 结果反馈:将API返回数据重新输入模型生成自然语言回复  

⚙️ 技术本质:大模型仅生成调用指令,实际执行与结果整合仍需人工编码实现。


3. 关键缺陷

尽管推动了大模型落地,Function Calling在规模化应用中暴露三大硬伤:

缺陷维度

典型表现

案例佐证

平台绑定

• 仅原生支持OpenAI模型 • 阿里云Qwen/DeepSeek需定制适配接口

国内模型调用准确率低至20%

单任务局限

• 同步串行调用(1请求=1函数) • 复杂流程需多次人工交互

订酒店+租车需拆解为2次独立调用

无状态管理

• 每次调用独立 • 无法记忆用户偏好(如“每次用美元计价”)

跨会话需重复输入参数,体验割裂

扩展成本

• 新增工具需重定义Schema+更新Prompt • M×N适配问题未解决

10工具×3模型=30套定制代码

💥 行业痛点案例:某电商客服系统接入支付/物流工具时,因OpenAI模型升级导致函数调用格式变更,需重构全部接口适配逻辑,维护成本飙升300%。


4. 价值与局限:技术演进的必然性

短期价值

  • ⏱️ 开发敏捷性:5分钟完成简单工具注册(如汇率计算)
  • 执行效率:原子操作平均延迟<500ms,轻量级场景优势显著
  • 🚀 推动标准化:促使阿里云/Google等厂商向OpenAI接口规范靠拢

长期瓶颈

代码语言:plaintext
AI代码解释
复制
Function Calling 技术债累积曲线  
├─ 初期:快速接入API工具 → 成本下降80%  
├─ 中期:多工具组合需求 → 代码复杂度指数增长  
└─ 后期:跨模型/跨会话场景 → 架构重构不可避免  

行业共识:需支持多工具并行(如同时查航班+天气)、跨会话状态持久化(用户偏好记忆)、开放协议(解耦模型与工具)的下一代方案。


技术演进启示

  • 历史定位:Function Calling是工具调用标准化的启蒙者,但非终局方案
  • 核心矛盾:解决了“单点工具连接”,未解决“生态互通”问题
  • 直接遗产:其JSON Schema定义格式被MCP的Protocol Buffers 3.0继承优化

正如 Anthropic 技术报告指出:“Function Calling证明了工具调用的可行性,而MCP要解决的是如何让工具调用像HTTP协议一样开放普适。”

此阶段的探索既验证了“语言模型+工具”路线的商业价值,也以工程实践代价催生了MCP等开放协议的诞生,成为AI行动智能演进的关键转折点。

以下是对 MCP协议(Model Context Protocol) 的通俗版讲解,用生活场景比喻技术概念,帮你轻松理解为什么它是AI世界的“万能插座”:


四、MCP是什么?一句话解释:

MCP是AI模型和现实世界的“翻译官 + 万能遥控器”undefined它让大模型(比如ChatGPT)能直接“打电话”给数据库、日历、支付系统等工具,像人一样操作现实事物,而不用背下所有说明书。


为什么需要MCP?—— 解决三大痛点

1. 以前:AI是“书呆子”,只会背课本
  • 问题:大模型像闭门读书的学生,不知道实时天气、查不了最新股价、操作不了订票系统。
  • 例子: ❌ 你问:“帮我订明天北京飞上海的机票”

AI答:“我无法操作系统”undefined(实际因为它没“手”去操作网页和支付)

2. 后来:AI有了“手”,但每只手都要定制
  • 问题:每个工具(如天气API、日历)都要单独给每个模型(如GPT-4、Claude)开发接口,工作量爆炸。
  • 例子: 🤯 5个模型 × 10种工具 = 50套定制代码!

工具一升级(如微信API更新),所有模型接口全要重写!

3. 现在:MCP让AI学会“即插即用”
  • 解法
    • 统一插座:所有工具按MCP标准做成“插头”(MCP Server)
    • 万能遥控:所有模型配“接收器”(MCP Client),即插即用
  • 效果: ✅ 新工具上线 → 所有模型自动识别

✅ 模型升级 → 工具无需改动undefined(就像USB-C接口:手机、电脑、充电宝全都能互充)


MCP怎么工作?—— 3步秒懂

1. AI接到任务 → 找“工具黄页”

你问:“帮我查今天纽约气温,再订机票” AI打开 MCP Server 黄页,搜索“天气查询”和“机票预订”工具

2. AI调用工具 → 自动“打电话”

MCP协议 给天气Server打电话:“查纽约气温”☀️ 同时给机票Server打电话:“订明天北京-上海票”✈️undefined(并行操作:不用等天气结果再订票)

3. 结果拼装 → 回复你

天气Server回:“纽约25℃” 机票Server回:“已订好航班CA1234” AI汇总生成回答:undefined“纽约今天25℃🌞,已帮您订好明早8点航班CA1234!”


MCP的厉害之处

功能

生活比喻

解决了什么问题?

动态发现工具

自动更新“工具黄页”

新增工具无需通知每个AI

跨会话记偏好

记住“用户爱用美元付款”

不用每次重复说需求

并行调用工具

同时查天气+订机票

复杂任务速度提升60%

安全沙盒

工具操作限制(如禁删数据库)

防止AI乱操作重要系统


真实案例对比

  • 传统方案:某公司接CRM系统undefined⏳ 耗时2周,为每个模型定制接口undefined💸 每次系统升级可能崩2个接口
  • MCP方案:undefined⏱️ 10分钟部署通用CRM的MCP Serverundefined🤖 GPT-4、Claude等模型直接调用 ✅ 开发效率提升98%

MCP = AI的行动神经系统

对开发者:告别“重复造轮子”,专注创新 对企业:节省百万级定制成本,统一AI能力中台 对普通人:未来AI能直接帮你订餐、打车、写周报——真正成为“全能助手”!

TCP/IP连接了计算机,MCP连接了智能。”

—— 一个协议,让AI从“聊天机器人”进化为“行动智能体”。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 从小白视角理解什么是MCP
    • 一、初始阶段:Prompt工程的局限性(2020-2023)
    • Prompt工程的局限框架
    • 二、破局尝试:AI Agent与Agent Tools(2023-2024)
    • 技术演进启示
    • 三、过渡方案:Function Calling的探索(2023-2024)
    • 技术演进启示
    • 四、MCP是什么?一句话解释:
    • 为什么需要MCP?—— 解决三大痛点
    • MCP怎么工作?—— 3步秒懂
    • MCP的厉害之处
    • 真实案例对比
    • MCP = AI的行动神经系统
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档