这是第七堂课，讲的内容是 function call 和 mcp，内容是语音识别的，存在错别字，请帮我总结课程内容

第七课课程总结（Function Call + MCP，基于你给的录音转写+你的笔记）

本节课核心主题：大模型工具调用体系：Function Call 和 MCP（Model Context Protocol），配套使用 Qwen-Agent（千问Agent） 框架上手实操，核心案例是 ChatBI 门票数据查询助手，同时演示现成MCP服务、自研MCP服务开发。

一句话区分：Function Call 是模型侧本地工具调用能力；MCP是一套跨模型、标准化开放协议，用来对外暴露工具服务，二者不是替代关系，各有适用场景。

一、前置铺垫

1. Agent 框架选型：LangGraph、LlamaIndex、Qwen-Agent等，框架只是“外壳”，底层逻辑差别不大；老师优先推荐 Qwen-Agent，代码精简、自带WebUI，适合原型开发、学习调试，也支持本地私有化大模型接入。
2. Agent 的本质：大模型本身只有参数，只能做文本推理，工具就是给大模型增加“手脚”，对接外部系统、数据库、文件、API；由大模型自主判断要不要调用工具、调用哪个工具、传什么参数。
3. RAG 和 ChatBI 的区别
   • RAG：文本相似度检索，找知识片段，非结构化文本；
   • ChatBI：结构化数据查询，生成SQL，从数据库拿精确数值（本课重点案例）。

二、Function Call（函数调用）核心内容

1. 原理

提前定义好可调用函数，用装饰器注册工具（@register_tool），在系统提示词里告诉大模型：工具能力、数据表结构（建表语句）、业务黑话/术语映射、Few-shot样例（易错bad case错题本）。 大模型理解用户自然语言问题 → 自行生成SQL语句 → 传给注册好的SQL执行工具 → 工具连接数据库执行SQL、返回结果。

✅ 本课技巧：不需要单独写一个“生成SQL”工具，直接让大模型自己生成SQL字符串，传给唯一的execute_sql执行工具，简化链路。

2. ChatBI 门票助手案例（Function Call实战）

目标：乐园门票业务查询（按月/按省份统计门票销量、订单金额等）

1. System Prompt 必须包含三块信息：
   • 角色定义：你是门票数据查询助手；
   • 数据表建表语句：告诉大模型表名、字段、字段含义；
   • 业务术语映射 + Few-shot（Bad Case）：把容易理解错的业务黑话、之前答错的例子放进提示词，修复模型缺陷。
2. 工具注册：只注册 execute_sql 工具，描述清楚工具作用、入参（SQL语句）；工具内部持有数据库连接权限，执行SQL并返回数据（做截断，防止返回数据过长爆上下文）。
3. 拓展：图表可视化方案
   • 方案A：新增独立画图工具，两个工具通过大模型中转传递数据 → 缺点：耗Token、数据在大模型中转容易失真、超长上下文风险；
   • 方案B（推荐）：把绘图逻辑内置在SQL工具内部，拿到查询结果之后直接本地生成图表，不再经过大模型转发数据。
4. Qwen-Agent使用：配置模型、system prompt、注册工具，自带Web界面（默认端口7860），开箱即可对话调试；支持多智能体路由。

3. Function Call 的优缺点 & 适用场景

• 优点：无额外服务层、无通信开销、延迟低；简单工具（计算、发邮件、单SQL查询）直接本地注册使用，不用额外部署服务。
• 缺点：绑定模型，不同厂商模型Function Call参数格式不一样，需要单独适配；工具代码内置在Agent项目里，没法直接开放给别的模型/别的项目调用。

三、MCP（Model Context Protocol）核心内容

MCP：模型上下文协议，类比HTTP，是一套标准化开放协议，用来把工具封装成独立服务，跨模型通用。

1. MCP 三角色（对应你的笔记 Host / Client / Server）

• Host：宿主，运行AI Agent的环境（Cursor、TIE、Qwen-Agent等）
• Client：MCP客户端，在Host里面，向MCP服务发起调用请求
• Server：MCP服务端（MCP Server）：真正实现工具逻辑，向外暴露工具列表、能力描述，接收参数、执行函数、返回结果

2. 两种使用方式

1. 直接使用现成MCP服务 示例：高德地图MCP、Tavily搜索MCP；在Cursor/TIE里配置MCP地址+密钥，一键启用，Agent自动发现工具并调用。 演示案例：高德MCP给大模型提供地点、路线、距离查询能力，自动生成上海一日游攻略。 市场：ModelScope上有现成MCP市场，可以直接取用第三方MCP服务，部分免费、部分付费。
2. 自研开发MCP Server（fastmcp）
   • fastmcp：轻量Python库，用来快速开发MCP服务，提供装饰器注册工具；
   • 开发步骤：先写好纯Python函数，本地跑通功能；再加@fastmcp.tool装饰器注册；启动MCP服务；
   • 本课示例：桌面TXT文件统计MCP，提供3个工具：统计txt数量、列出txt文件名、读取txt内容；
   • 调试工具：mcp inspector，专门用来调试MCP服务，查看暴露的工具、测试调用。
   • 通信模式两种：
     • STDIO：标准输入输出，命令行通信，本地常用；
     • HTTP+SSE：网页长链接方式，适合网页端、局域网/外网调用。

3. MCP 的优缺点 & 适用场景

• 优点：协议标准化，和模型无关，任意Agent/大模型都能接入调用；工具逻辑独立部署，代码和Agent解耦，可以给多个项目共享；
• 缺点：需要单独部署MCP Server，多一层网络通信，有额外延迟；简单小工具没必要上MCP。

四、Function Call vs MCP（面试重点对比）

结论：二者不是二选一，经常搭配使用。简单内部工具用Function Call；需要对外共享、跨模型复用的工具，封装成MCP服务。

五、你的笔记问题解答

1. ChatBI是什么？ ChatBI是面向业务人员的自然语言BI：用户用自然语言提问数据问题，自动翻译成SQL查询数据库，返回数据、报表、图表，不用业务人员手写SQL。本课就是用Function Call实现ChatBI。
2. few shot（bad case） Few-shot就是给提示词里放样例；bad case是专门收集之前模型容易答错的案例，做成错题本放进prompt，用来纠正模型的固定错误，提升准确率。
3. @register_tool 装饰器 Qwen-Agent里面用来把普通Python函数注册成大模型可识别工具的装饰器，标记之后框架会自动把工具描述、参数信息传给大模型。
4. MCP Host、Client、Server
   • Host：AI运行环境（Cursor / TIE / Qwen-Agent）
   • Client：Host内部组件，负责和MCP Server通信
   • Server：独立服务，存放工具代码，接收请求执行工具
5. mcp inspector MCP官方调试工具，启动MCP服务之后，用inspector连接，可以查看服务暴露了哪些工具、手动测试调用，排查MCP连通、参数报错。
6. fastmcp是什么 Python轻量开发库，快速开发MCP Server，提供装饰器注册工具，支持STDIO / HTTP+SSE两种通信方式，简化MCP服务开发。

六、课后练习任务

1. 练习一：Qwen-Agent + Function Call 搭建ChatBI，连接MySQL，实现自然语言查数据，进阶在工具内增加绘图生成图表；
2. 练习二：用fastmcp开发自定义MCP服务（本课示例是桌面txt工具），在Qwen-Agent或者TIE/Cursor里接入这个自研MCP，完成调用。

如果你想要，我可以把这份总结压缩成一页面试背诵版，或者整理成一份可直接复制的思维导图。

本回答由AI生成，仅供参考，请仔细甄别，谨慎投资。

tools + mcp server 提供了工具，工具背后可能就是调用 api。那这和 skills 有啥区别，skills 他也可以执行脚本呢

一句话核心：MCP 是「连接通道/手脚」，负责标准化对外调用；Skill 是「流程手册/剧本」，负责告诉AI该怎么做事。Skill 确实可以带脚本、也能调用API，但它和MCP不在同一个层级，不是替代关系，是搭配关系。

1. MCP Server（Model Context Protocol）

本质：一套通信协议 + 独立常驻进程（JSON-RPC，stdio/http）

• 职责：对外暴露原子工具，统一发现、调用、鉴权、权限隔离。底层可以是API、数据库、本地文件、浏览器等。
• 特点：
  • 独立服务，长期运行；多个Agent/客户端可以共用同一个MCP Server
  • 工具是强Schema、机器可识别，tools/list自动发现能力
  • 关注点：能不能连上外部系统、安全调用资源
• 例子：一个MCP server包装语音识别API，只暴露 speech_recognition(file) 这个工具，只负责把文件传给接口、拿回结果，它不关心识别之后该做什么。

2. Skill（Agent Skill）

本质：一个文件夹包（SKILL.md + 可选scripts脚本、参考文档），是流程/领域知识包

• 职责：定义一套完整SOP、判断逻辑、输出规范、多工具编排顺序。
• 特点：
  • 默认是静态文件，按需加载（渐进式披露）：只先加载简短元描述，匹配任务时才把完整规则读进上下文，省token
  • 里面可以内嵌脚本（python/js），脚本内部可以直接调API，也可以去调用MCP工具
  • 关注点：拿到工具之后，按什么步骤、按团队规范处理任务
• 例子：语音识别Skill：
  1. 拿到音频 → 调用识别工具（可以是MCP，也可以是自带脚本）
  2. 识别完自动纠错、过滤脏话、按指定格式输出字幕
  3. 长音频自动分段、生成时间轴 👉 这一套“先识别、后清洗、再排版”的业务流程，才是Skill管的

3. 关键对比（回答你的疑问：都能调API、跑脚本，差别在哪）

误区：Skill里写脚本直接调用API，看起来和MCP效果一样，但这是“自己手写连接逻辑”。如果以后这个语音识别API地址、密钥、鉴权方式变了，所有用到这个Skill的地方都要改；而MCP只改Server一处，所有Agent自动生效。

4. 经典搭配（你课堂讲的function call + MCP + Skill）

• Function Call：底层基础能力，模型输出结构化调用JSON
• MCP：把一堆API/能力标准化包装成function call可调用的工具，解决“对接外部系统”
• Skill：编排多个MCP工具，定义业务流程、判断分支、输出规范

举语音识别场景：

1. MCP server：封装ASR语音识别API，只提供识别这个原子能力
2. Skill：一份语音转字幕SOP，告诉Agent：音频来了，调用这个MCP识别 → 校对文本 → 打时间轴 → 导出srt字幕
3. Agent收到用户指令，匹配到这个Skill，自动走完整套流程

5. 什么时候选哪个

• 要接入外部系统、数据库、第三方API，希望多个地方共用、统一权限：MCP
• 要固化一套反复用的业务流程、规范、多步骤编排：Skill
• 简单一次性脚本、不想起一个独立服务：直接写在Skill脚本里就行，不用上MCP