写在前面
你有没有想过这个问题:AI大模型说得头头是道,为什么不能直接帮我当前天气怎么样、我的数据库里有多少订单?
原因很简单:大模型本身是一个语言理解和生成工具,它的知识封闭在训练时刻,无法实时访问任何外部系统。而 Function Calling 和 MCP 就是给它居个拓展坑的模块——让它能够调用真实的工具、操作外部系统、获取实时数据。
这节课学完,我终于搞明白了:AI Agent 的“行动能力”到底是怎么来的。
知识点1:Function Calling——模型与现实世界的“桥”
Function Calling 是指大模型在对话过程中,能够识别用户意图并自动调用开发者预先注册的函数,将自然语言转化为结构化参数,传递给外部工具执行。
它能解决哪些问题?
●实时数据获取:天气、股价、新闻(模型自己不懂,但它知道谁懂)
●复杂计算:数学公式、代码执行(调用求算工具而不是自己训算)
●操作外部系统:发送邮件、查询数据库、控制智能设备
一个直观的例子 用户说「明天北京天气怎么样?」→ 模型识别意图 → 自动生成调用:get_weather(location=”北京”, date=”明天”) → 工具执行,返回结果 → 模型生成回答。整个流程对用户透明。 |
知识点2:MCP——AI展界的“USB-C接口”
MCP(Model Context Protocol)是由 Anthropic 于 2024 年 11 月推出的开放协议标准。它的目标是标准化 LLM 与外部数据源、工具、服务之间的交互方式——就像 USB-C 接口标准化了各类设备连接方式一样。
MCP 的核心架构
●MCP Host:运行 AI 模型的环境,如 Claude Desktop、Cursor IDE、Cherry Studio
●MCP Client:嵌入在 Host 中的组件,负责发起请求并与 MCP Server 通信
●MCP Server:轻量级服务,提供具体功能,如数据查询、API 调用等
MCP 提供三大能力
1. Resources(知识扩展):提供结构化数据,增强 AI 的上下文理解
2. Tools(工具调用):允许 AI 执行外部操作,如发送邮件、查询 GitHub
3. Prompts(提示模板):预定义的指令模板,优化 AI 的任务执行
知识点3:Function Calling vs MCP——选哪个?
这是课堂上最常被问到的问题。老师的回答让我印象深刻:两者不是替代关系,而是适用不同场景。
维度 | Function Calling | MCP |
性质 | 模型内置功能 | 开放协议标准 |
适用场景 | 简单、原子化任务 | 复杂场景、跨平台 |
开发复杂度 | 每个任务单独开发 | 一次开发,多模型兼容 |
复用性 | 低(特定任务设计) | 高(一次开发,多场景使用) |
安全性 | 依赖云端 API 密鑰 | 支持本地化数据控制 |
典型场景 | 天气查询、单次计算 | 高德地图、Tavily 搜索、全局工具集 |
实务建议 简单、单次调用的任务(天气查询、单一计算)直接用 Function Calling 就够,无需多余的协议开销。确需跨平台、多功能、常驻外部工具的场景,上 MCP 。 |
知识点4:CASE 实战方向——学习路径指引
课程共涉及四个 CASE,涵盖了 Function Calling 到 MCP SDK 的完整学习路径。这里只提炼核心思路,具体操作建议项着课程原带的 CASE 练习。
CASE 1:门票助手(Function Calling 实战)
核心思路:通过 Qwen-Agent 的 Assistant 类注册一个 exc_sql 工具,将用户的自然语言问题自动转化为 SQL 查询并返回结果。进阶版进一步将查询结果可视化,实现表格+图表异步输出。
核心提问:如何设计 system_prompt 让模型准确理解业务词表?多维查询如何通过 pivot_table 展示?
CASE 2:旅游攻略 MCP(高德地图服务)
核心思路:在 Cursor / Cherry Studio / GitHub Copilot 中配置高德地图 MCP Server,通过自然语言输入就能获取真实的地点、路线、现场数据。
核心提问:不同 AI 客户端配置 MCP 的方式有什么差异?本地 UV/Bun 工具的安装和排查思路是什么?
CASE 3:Tavily 搜索 MCP(联网搜索能力)
核心思路:集成 Tavily MCP 后,模型可通过 tavily-search 进行实时搜索、通过 tavily-extract 提取网页内容。在 Qwen-Agent 中集成 Tavily 后能开启模型的真实联网检索能力。
CASE 4:桌面 TXT 统计器(MCP SDK 自建)
核心思路:用 Python MCP SDK 的 FastMCP 框架,通过 @mcp.tool() 装饰器将 Python 函数暴露为 MCP 工具。仅少量代码就可自建一个可被 AI 调用的服务,并通过 MCP Inspector 调试。
对 PM 的启发:这不只是技术课
学这节课前,我以为 Function Calling 和 MCP 是单纯的开发技术,和 PM 的日常工作关系不大。学完之后我改变了看法。
1. 需求清晰度直接影响工具是否好用
Function Calling 的效果好不好,很大程度取决于 system_prompt 和工具定义的质量。这意味着 PM 写的需求文档和数据表结构说明越清晰,最终轮序出来的结果就越精准。
2. MCP 正在重塑工具集的产品道路
过去我们说“集成第三方工具”是一件工程量很大的事。MCP 将这个门槛降低了一个数量级。未来一两年内,具备 ‘支持 MCP’ 的工具生态会成为 B端 AI 产品的标配要素。PM 需要在选型和产品设计中将这个趋势纳入考虑。
3. 向开发提问的姿势升级了
当你需要一个工具集成功能时,不再只能说“我想对接XXX”,而是可以问:「这个工具是否已有 MCP Server?我们可以直接用吗?还是需要自建?”——这就是 PM 理解技术后的价値。
下次写需求时,你可以这样向开发提问: 「这个查询功能,我们是通过 Function Calling 让模型自动调用 SQL 工具实现,还是直接做硬编码接口?」 「这个功能需要的外部工具,是否有现成的 MCP Server 可用?」 |
風险提示 MCP Server 目前以第三方提供为主,调用前请确认提供方的可信度和隐私条款。关涉业务数据的工具调用需审核权限设计,避免敏感信息外泄。Function Calling 中的 SQL 工具要谨防 SQL 注入风险。 |
互动与关注
你目前工作中有哪些场景可以用上 Function Calling 或 MCP?欢迎在评论区分享你的业务场景!
✅ 关注我,私信回复「AI学习」,领取该章节课程
以上内容纯属个人学习分享,非广告。相关工具和平台均来自公开信息,仅供参考。
《婉之画中话》 | 记录 AI PM 学习笔记,分享实用工具
夜雨聆风