本文介绍了AI工具调用的三代技术演进Function Calling、MCP和Agent Skills。Function Calling让LLM学会下达结构化指令MCP提供标准化接口连接任何工具Agent Skills则赋予AI领域知识和工作流。从硬连接到标准接口再到操作手册AI正逐步从“只会说”进化到“能动手”。文章详细解析了各阶段的技术特点、工作流程及适用场景并提供了混合使用的建议帮助读者全面理解AI工具调用的演进路径。一、填坑来了为什么工具调用值得单独写一篇上期《从 Prompt 到 Harness》里讲 Context Engineering 时提到过“后面会单独出一个系列介绍工具调用这里先挖个坑。”没学习的小伙伴可以去学习下保证你有收获说实话本来想挖着坑慢慢填。但后来发现——这个坑越不填越大。因为最近一年工具调用领域发生了太多事Anthropic 发布了 MCP 协议整个行业跟进OpenAI、Google、微软都宣布支持 MCPClaude Code 引入了 Skills 机制改变了工具 vs 知识的边界社区开始争论MCP 是不是过度工程Function Calling 是不是就够了想了想与其分几期零散讲不如一篇文章把三代技术全部捋清楚。你只需要记住一条主线Function Calling → MCP → Agent Skills 硬连接 标准接口 操作手册好开始。二、Function CallingAI 从只会说到能动手2.1 它解决了什么问题在 Function Calling 出现之前LLM 就是一个缸中之脑——它能推理、能聊天但不知道现在几点不知道今天天气不能发邮件不能查数据库不能操作任何真实系统说白了它有脑子没有手。 一句话定义Function Calling 让 LLM 学会了下达结构化指令——它不直接执行任务而是告诉你的程序我想调用哪个函数、传什么参数。给你打个比方想象一个坐在轮椅上的天才指挥官。他不能自己冲锋陷阵但他可以精确地下达命令“3 号士兵用步枪朝东南方向 200 米的目标射击。”Function Calling 就是这个精确下达命令的能力。模型是指挥官你的代码是士兵。2.2 它是怎么工作的——三步走早期的工具调用依赖 Prompt Engineering——开发者苦口婆心地写“请务必返回 JSON 格式不要多说废话。”结果呢模型经常抽风一会儿返回 JSON一会儿返回散文程序解析直接崩。OpenAI 引入 Function Calling 后把这个过程变成了严格的三步规范。用一个场景带你走一遍你问 Agent“查一下杭州明天天气”第一步契约定义Schema——给模型一份说明书开发者预先定义好工具的名片——用 JSON Schema 说清楚{ name:get_weather, description:查询指定城市的天气预报, parameters:{ type:object, properties:{ city:{ type:string, description:城市名称如 Hangzhou } }, required:[city] } }这张名片告诉模型我这里有个工具叫get_weather你想用它就必须给我一个city参数。第二步大脑决策——模型下达订单你问杭州明天天气怎样模型一看我自己没有实时天气数据但我有一个get_weather工具可以用用户提到了杭州于是它不再瞎编而是输出一份精确的调用请求{ name: get_weather, arguments: {/city/: /Hangzhou/} }注意此时模型没有联网没有调 API。它只是精准地提炼了你的意图翻译成了结构化指令。第三步闭环执行——Agent 跑腿 模型回复你的 Agent 程序收到这个 JSON去调真正的天气 API→ 调用 weather_api(Hangzhou) ← 返回12°C小雨然后把结果塞回给模型。模型拿到真实数据后组织一段自然语言“杭州明天 12°C有小雨记得带伞哦”整个过程用一张图总结你杭州明天天气 ↓ 模型决策我要调用 get_weather(cityHangzhou) ↓ Agent 执行调用真实 API → 得到 12°C/小雨 ↓ 模型回复杭州明天12°C有小雨带伞2.3 Function Calling 的局限Function Calling 很好但当你的工具从 3 个变成 30 个、甚至 300 个时——问题来了。自己经历过问题 1重复造轮子你给 Claude 写了一套工具定义给 GPT-4 又要重写一遍给 Gemini 再来一遍。格式不同、字段名不同、行为不同。三个模型三套代码维护成本爆炸。问题 2紧耦合工具定义硬编码在代码里。换个模型全部重写。换个应用场景全部重写。想让别人复用你的工具把代码 copy 给他。问题 3工具描述占上下文每个工具的 JSON Schema 都要塞进上下文窗口。工具一多光工具描述就占了几千个 Token——留给真正对话的空间就少了。“Function Calling 就像有线耳机——好用但每台设备都要买一根专用线。”这时候你就会想能不能有个标准接口写一次工具到处都能用这就是 MCP 要解决的问题。三、MCPAI 世界的USB-C 接口3.1 它是什么 一句话定义MCPModel Context Protocol模型上下文协议是 Anthropic 推出的一套开放协议让 AI 应用可以通过标准化接口连接任何外部工具和数据源——写一次到处用。2024 年 11 月Anthropic 正式发布了 MCP 协议。他们给出的类比是MCP 之于 AI 工具就像 USB-C 之于硬件设备。以前每个手机充电器都不一样Micro-USB、Lightning、各种私有接口USB-C 一出来——一根线搞定所有设备。MCP 做的是同样的事以前每个 AI 应用Claude、GPT、Cursor接工具都要单独写代码有了 MCP——写一个 MCP Server所有支持 MCP 的应用都能直接接入。3.2 MCP 的三层架构Host / Client / ServerMCP 不是一个工具它是一套通信协议。要理解它怎么工作你得先知道三个角色用一个类比帮你记住Host宿主 你家的电脑。它运行 AI 应用管理所有连接。Client客户端 电脑上的 USB 接口。每个接口对接一个外设。Server服务端 外接设备。键盘、鼠标、硬盘——各管各的功能。一个 Host 可以连多个 Server。每个 Server 独立提供能力。互不干扰。3.3 MCP 是怎么通信的两种传输方式方式使用场景大白话stdio(标准输入输出)本地server,跑在你自己的电脑上像两个人面对面说话不用网络sse/http远程server,跑在云端像打电话通过网络连接通信协议是 JSON-RPC 2.0——说白了就是用 JSON 格式发消息按规范办事。3.4 MCP 的完整工作流用杭州天气这个例子走一遍 MCP 的全流程第一步建立连接InitializeClaude DesktopHost启动时看到配置里有一个天气 MCP Server。于是Host → Server你好我是 Claude Desktop你能干啥 Server → Host我能查天气get_weather也能查空气质量get_air_quality双方握手完成Host 知道了 Server 有哪些能力。第二步发现工具List ToolsHost 把 Server 提供的工具列表注入到 LLM 的系统提示词中。现在模型看到了你有以下工具可用 - get_weather(city: string)查询城市天气 - get_air_quality(city: string)查询空气质量第三步调用工具Call Tool你问杭州天气模型决定调用get_weather模型 → Host我想调 get_weather参数 cityHangzhou Host → Client → Server转发调用请求 Server调真实 API拿到结果 Server → Client → Host → 模型返回12°C小雨和 Function Calling 有什么不同 核心区别在于维度Function CallingMCP工具定义在哪硬编码在你代码里独立的server 进程换个AI应用重写一遍直接接入不用改别人写的工具复制代码到你项目加个server配置就行工具更新了该你的代码server自己更新你不用动3.5 MCP 的三大能力MCP Server 不只能提供工具它实际上有三种能力能力谁来决定使用大白话类比Tool(工具)模型自主决定调用“我能帮你干活”–查天气、发邮件、写文件你桌子上的计算器–你觉得你需要就拿起来用Resourses(资源)应用程序决定注入“我有数据给你看”–数据库内容、文件列表领导放你桌子上的参考资料–不是你选的但是你得看Prompts(提示模版)用户主动选择“我有现成的流程”–一键启动特定的工作流用户点击一个“快捷操作”按钮觉得这个设计挺聪明的不是所有东西都让模型自己决定用不用。有些信息是应用自动塞进去的Resources有些是用户手动触发的Prompts。分层控制避免模型瞎调用。3.6 MCP 的生态有多火自 2024 年底发布以来MCP 的生态增长速度超乎想象主流大厂全面跟进GoogleGemini、OpenAI、微软VS Code、Copilot、AWS、Cloudflare 先后宣布支持第三方 Server 爆发GitHub、Stripe、Linear、Slack、Notion、Postgres、Docker 等都发布了官方 MCP Server开发工具原生支持Cursor、Windsurf、Claude Code、Zed 等 AI 编辑器已原生集成 MCPMCP Registry社区搭建了中央发现仓库开发者可以搜索、安装、发布 MCP Server远程 MCPCloudflare Workers 等平台支持将 MCP Server 部署为 Serverless 函数无需本地运行自己体验下来——MCP 最香的地方是别人写好的 Server你加一行配置就能用。比如要让你的 Agent 操作 GitHub以前要自己写 GitHub API 封装代码现在{ mcpServers:{ github:{ command:npx, args:[-y,modelcontextprotocol/server-github], env:{GITHUB_TOKEN:your-token} } } }加这么一段配置Agent 就能创建 PR、查看 Issue、管理仓库了。零开发成本。这就是标准化带来的生态红利——一个人写所有人用。四、MCP 出来后Function Calling 是不是就过时了这个问题最近社区争论很热闹。先说结论没过时。两者是不同层面的解决方案各有适用场景。4.1 一个反常的案例龙虾 AgentOpenClaw2025 年有一个现象级的开源项目叫 OpenClaw中文名龙虾做的是本地个人 Agent。有意思的是——它明确选择了回归 Function Calling没有用 MCP。这是在开历史倒车吗研究了他们的设计文档总结出两个核心原因原因 1开发成本MCP 需要单独启动 Server 进程涉及生命周期管理连接、握手、心跳、断线重连。对于一个本地 Agent 就用 5-10 个工具的场景——这太重了。MCP 方式 启动 Server A 进程 → 启动 Server B 进程 → 握手 → 注册工具 → 调用 → 管理心跳... Function Calling 方式 定义 JSON Schema → 写业务逻辑函数 → 搞定说白了能跑就行远比符合国际协议重要。 对很多独立开发者来说这是大实话。原因 2性能延迟MCP 在动态拉取工具列表list_tools时会消耗额外的 Token 和往返时间。在生产环境中如果工具列表是固定的——直接把 Function 定义写死在 Prompt 里速度更快、更省钱。实测过MCP 的 stdio 模式每次调用多了大约 50-100ms 延迟。单次不明显但如果一个任务需要连续调 20 次工具——这就是 1-2 秒的额外等待。4.2 那什么时候该用 MCP场景function callingMCP工具数量少10个且固定不变✅过度工程你只是一个模型/应用✅不需要标准化追求极致的延迟✅有额外开销工具被多个应用共享不够用✅工具由第三方提供自己重写累不稳定✅ 直接接入工具列表动态变化硬编码不稳定✅动态发现需要安全隔离(server独立进程)自己做隔离✅天然隔离一句话总结“MCP 是工具的分发方案Function Calling 是工具的集成方案。分发给全世界用 MCP自己内部用 Function Calling 就够了。”五、Agent Skills比能连接更重要的是会使用5.1 MCP 的两个痛点MCP 解决了标准化连接的问题。但在实际使用中发现了两个新问题痛点 1上下文爆炸一个 MCP Server 可能暴露几十甚至上百个工具。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中。社区开发者实测数据仅加载一个 Playwright MCP Server 就占用了 200K 上下文窗口的 8%。你接 3-5 个 Server20-40% 的上下文就被工具描述占了。留给真正对话的空间严重压缩。在多轮对话中这个问题更严重——Token 成本飙升推理能力下降。痛点 2能力鸿沟——“能连上≠会用”MCP 解决了能够连接的问题但没有解决知道如何使用的问题。举个例子你给 Agent 接了一个数据库 MCP Server。Agent 现在可以执行 SQL 了。但它知道你的数据库有哪些表表结构是什么查员工信息应该 JOIN 哪几张表有哪些查询是绝对不能执行的比如 DROP TABLE返回结果太多时应该怎么分页答案是它不知道。MCP 只给了它手没给操作手册。打个比方这就像给一个新入职的员工开通了所有系统的访问权限但没给他任何培训资料和操作规范。他有权限登录 CRM、ERP、数据库——但他完全不知道该怎么用。5.2 Agent Skills 是什么 一句话定义Agent Skills 是一种标准化的程序性知识封装格式——如果 MCP 给了 AI “手”Skills 就给了 AI “操作手册”。Skills 不是工具不提供 API不是 Prompt不只是文字指令。它是一个知识包包含什么时候可能还有脚本和参考文件一句话区分三者属性Function CallingMCPAgentSkills本质一次函数调用一个标准化接口一本操作手册提供的是“手”“标准化的手”“大脑里面的SOP”类比一个按钮USE-C接口应用软件小编再展开类比MCP 像 USB 接口或驱动程序——定义设备如何连接Skills 像应用软件——定义如何使用这些设备完成任务你可以有一个完善的打印机驱动MCP但如果没人告诉你怎么在 Word 里设置双面打印Skill你还是搞不定。5.3 Skills 最核心的创新渐进式披露前面说了MCP 的一大问题是上下文爆炸——所有工具描述一次性全塞进去。Skills 的解决方案非常聪明分三层加载按需逐步披露。小编用一个比方帮你理解想象你新入职一家公司。公司不会在第一天就把所有部门的操作手册、全部流程文档、几百个系统的使用指南全塞给你。那样你会当场崩溃。合理的做法是第一天入职手册告诉你公司有哪些部门、各干什么——你大概知道有什么就行接到任务时岗位培训你被分到市场部OK现在才给你市场部的详细流程遇到具体问题时查手册你需要用某个系统这时候才打开那个系统的操作指南Skills 的三层加载机制一模一样第一层元数据Metadata—— “公司有哪些部门”Agent 启动时只扫描每个 Skill 的名片——名称、一句话描述、触发词。--- name: wechat-article-writer description: 撰写微信公众号技术文章时使用此 skill triggers: - 写公众号文章 - 微信文章 - 改写成公众号 ---每个 Skill 的元数据只占约 100 个 Token。就算你装了 50 个 Skill初始消耗也只有 ~5000 Token。对比 MCP连一个 Playwright Server 就占 16000 Token。差距是数量级的。第二层技能主体Instructions—— “岗位培训手册”当用户的请求匹配到某个 Skill 的触发条件时Agent 才加载这个 Skill 的完整内容。比如用户说帮我写一篇公众号文章Agent 匹配到wechat-article-writer这时才把完整的写作规范、文章结构、风格要求全部加载进上下文。这部分通常 1000-5000 Token取决于指令复杂度。第三层附加资源Scripts References—— “具体问题查手册”对于复杂的 Skill还可以附带脚本、模板、参考文档。Agent 只在具体执行到那一步时才加载。skills/pdf-processing/ ├── SKILL.md # 主技能文件 ├── parse_pdf.py # PDF 解析脚本需要时才执行 ├── forms.md # 表单指南遇到表单任务才加载 └── templates/ # 模板文件需要时才访问结果你可以给 Agent 装几十个 Skill它的初始上下文消耗非常小。只有当任务真正需要某个 Skill 时才展开那个 Skill 的详细内容。这就是渐进式披露的威力——不是一次性全塞进去而是用多少加载多少。5.4 Skills MCP不是竞争是互补理解了三代技术的差异后你会发现——它们不是互相替代而是各管一层。最佳实践是把三者组合成分层架构小编用一个实际场景带你走一遍这个分层场景用户问 “分析一下公司里谁的话语权最高”Skills 层介入Agent 识别到这是一个数据分析类任务加载mysql-employees-analysis技能。Skill 里定义了分析话语权需要看哪些维度管理关系、薪资水平、任职时长、汇报线应该查哪些表、怎么 JOIN返回结果应该怎么解读MCP 层执行Skill 指导 Agent 调用数据库 MCP Server执行具体的 SQL 查询SELECT * FROM managers JOIN employees ON ...SELECT salary, title FROM ...Function Calling 层MCP Server 底层调用实际的数据库驱动执行 SQL。最终结果Agent 基于 Skill 里的领域知识把原始数据解读为有意义的结论返回给用户。这种架构的好处优势说明关注点分类MCP管“能力连接”Skills管“领域智慧”成本优化渐进式加载token消耗最小化可维护性业务逻辑(skills)和基础设施MCP解耦复用性同一个MCP Server 可被多个skills复用5.5 如何写好一个 Skill小编总结了几条实战原则基于自己写代码审查 Skill 的经验原则 1描述要回答什么时候加载我不是我是什么# ❌ 坏的描述 description: 这是一个代码审查技能 # ✅ 好的描述 description: 当用户提交代码要求 Review、检查代码质量、或合并 PR 前审查时使用Agent 扫描描述是为了判断要不要加载你——所以描述要像触发条件不像自我介绍。原则 2触发词覆盖多种说法用户可能说帮我 review 代码也可能说看看这段代码有没有问题。你的触发词要尽量覆盖各种说法triggers: -review 代码 -代码审查 -检查代码质量 -帮我看看这段代码 -PR review - code review原则 3指令要像 SOP不像散文# ❌ 坏的指令散文式 审查代码时要注意安全性、性能和可读性 同时关注命名规范和错误处理... # ✅ 好的指令SOP式 ## Step 1 — 理解上下文 1. **确认变更的目的修 Bug / 新功能 / 重构** 2. **查看关联的 Issue 或需求描述** 3. **了解影响范围涉及哪些模块** ## Step 2 — 逐层审查 1. **安全性是否有 SQL 注入、XSS、硬编码密钥** 2. **正确性边界条件、空值处理、并发安全** 3. **性能是否有 N1 查询、内存泄漏、死循环风险** 4. **可维护性命名清晰度、函数长度、重复代码** ...越结构化、越具体Agent 执行得越好。原则 4声明退出条件——什么算做完了## 完成标准 - [ ] 所有文件都已逐一审查 - [ ] 安全类问题标记为「必须修复」 - [ ] 每条审查意见标注了严重等级P0/P1/P2 - [ ] 给出总体评价通过 / 需修改 / 打回重写没有退出条件的 SkillAgent 可能无限循环或提前结束。原则 5Skill 内部可以调用 MCP 工具好的 Skill 不是替代MCP而是编排MCP。在指令里明确说用什么工具做什么事## Step 3 — 提交审查结果 1. **使用 GitHub MCP Server 在 PR 上逐行添加 Review Comment** 2. **对于安全类问题调用 Jira MCP Server 自动创建 Bug 工单** 3. **使用消息 MCP Server 通知提交者审查已完成**这样 Skill 负责决策和编排MCP 负责执行具体操作——职责清晰。5.6 一个完整的 Skill 工作场景小编用一个大家都遇到过的场景带你走一遍有 Skill 的 Agent是怎么工作的场景你对 Agent 说帮我看看这周的 Bug 列表写封周报邮件发给领导这件事你自己做大概要打开 Jira 查 Bug → 筛选本周的 → 分类汇总 → 写成邮件 → 发送。30 分钟起步。现在看 Agent 怎么做——第一步元数据匹配Agent 扫描所有已安装 Skill 的元数据发现weekly-report-writer匹配了用户说的写封周报邮件 Skill 触发词[周报, weekly report, 写周报, 汇报邮件] → 匹配加载这个 Skill此时消耗~100 Token。其余几十个 Skill 完全不占上下文。第二步加载完整指令Agent 读取这个 Skill 的完整内容。现在它知道了周报的标准格式本周完成 / 进行中 / 下周计划 / 风险项Bug 应该按严重程度分组不是按时间领导喜欢先看结论再看细节金字塔结构邮件标题格式[周报] XX团队 第N周工作汇报语气要求专业但不啰嗦重点加粗没有这个 SkillAgent 可能写成流水账或格式乱七八糟。有了 Skill它写出来的周报就像你组里最靠谱的那个同事写的。第三步按 SOP 执行Skill 编排 MCP 执行Skill 定义了清晰的步骤Agent 依次执行Step 1调用 Jira MCP Server → 查询本周所有 Bug状态、优先级、负责人 Step 2按 Skill 指令分类 → P0/P1/P2 分组 已解决/进行中/待处理 Step 3调用日历 MCP Server → 看看本周有没有重要会议/里程碑 Step 4根据 Skill 模板组织邮件正文 → 金字塔结构结论先行 Step 5调用邮件 MCP Server → 发送给领导抄送组内成员注意这里的分工Skill 负责怎么做分组逻辑、格式模板、语气要求MCP 负责去执行查 Jira、读日历、发邮件第四步退出检查Agent 对照 Skill 里定义的完成标准自检Bug 数据来源是本周不是上周的旧数据邮件标题符合格式有风险项板块领导最关心的收件人正确发给领导抄送组员邮件已成功发送全部通过 → 任务完成。你收到 Agent 的回复“周报已发送本周共处理 12 个 Bug其中 P0 级 2 个已修复。”从你说话到邮件发出可能就 30 秒。小编想强调的点是——如果没有 SkillAgent 也能写周报。但它写出来的很可能是格式不对领导看了想打人分类混乱P0 和 P2 混在一起重点不突出埋在一堆细节里语气不合适要么太随意要么太正式Skill 的价值不是让 Agent “能做”而是让它做得对、做得好。Skill 让 Agent 从什么都能干但什么都干不精变成了接到任务就像老员工一样驾轻就熟。六、全景总结三代技术一张表维度Function CallingMCPAgentSkills诞生时间20232024年底2025年底创造者OpenAIAnthropicanthrppic定义让模型输出结构化工具调用让模型通过标准协议被任何应用接入让Agent拥有领域的知识和工作流解决的问题AI不能动手工具不能被复用AI会玲姐但是不会精准的使用工具类比有线耳机USB-C接口应用软件上下文消耗中等工具定义常驻高每次都需要加在所有schema低渐进式加在适用场景内部简单工具绑定跨应用工具共享复杂领域任务编排关系基础层中间层上层演进关系 Function Calling → MCP → Agent Skills 能动手 手能通用 知道怎么用好手“从 Function Calling 到 Skills本质上是从’连接’到’智慧’的跃迁。”好了三代工具调用技术全部讲完。回到最开始的问题——该选哪个小编的建议很实际刚入门、做 Demo直接用 Function Calling简单够用要做跨应用共享、接第三方工具上 MCP做复杂的领域任务、需要 Agent “真的懂业务”写 Skills生产级系统三层都用各管各的层说实话小编自己目前的项目就是三层混合的——MCP 接数据库和文件系统Skills 定义写作流程和质量标准Function Calling 处理一些简单的内部逻辑。分工明确各司其职。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 从“只会说”到“能动手”：AI工具调用三代技术演进，建议收藏
本文介绍了AI工具调用的三代技术演进Function Calling、MCP和Agent Skills。Function Calling让LLM学会下达结构化指令MCP提供标准化接口连接任何工具Agent Skills则赋予AI领域知识和工作流。从硬连接到标准接口再到操作手册AI正逐步从“只会说”进化到“能动手”。文章详细解析了各阶段的技术特点、工作流程及适用场景并提供了混合使用的建议帮助读者全面理解AI工具调用的演进路径。一、填坑来了为什么工具调用值得单独写一篇上期《从 Prompt 到 Harness》里讲 Context Engineering 时提到过“后面会单独出一个系列介绍工具调用这里先挖个坑。”没学习的小伙伴可以去学习下保证你有收获说实话本来想挖着坑慢慢填。但后来发现——这个坑越不填越大。因为最近一年工具调用领域发生了太多事Anthropic 发布了 MCP 协议整个行业跟进OpenAI、Google、微软都宣布支持 MCPClaude Code 引入了 Skills 机制改变了工具 vs 知识的边界社区开始争论MCP 是不是过度工程Function Calling 是不是就够了想了想与其分几期零散讲不如一篇文章把三代技术全部捋清楚。你只需要记住一条主线Function Calling → MCP → Agent Skills 硬连接 标准接口 操作手册好开始。二、Function CallingAI 从只会说到能动手2.1 它解决了什么问题在 Function Calling 出现之前LLM 就是一个缸中之脑——它能推理、能聊天但不知道现在几点不知道今天天气不能发邮件不能查数据库不能操作任何真实系统说白了它有脑子没有手。 一句话定义Function Calling 让 LLM 学会了下达结构化指令——它不直接执行任务而是告诉你的程序我想调用哪个函数、传什么参数。给你打个比方想象一个坐在轮椅上的天才指挥官。他不能自己冲锋陷阵但他可以精确地下达命令“3 号士兵用步枪朝东南方向 200 米的目标射击。”Function Calling 就是这个精确下达命令的能力。模型是指挥官你的代码是士兵。2.2 它是怎么工作的——三步走早期的工具调用依赖 Prompt Engineering——开发者苦口婆心地写“请务必返回 JSON 格式不要多说废话。”结果呢模型经常抽风一会儿返回 JSON一会儿返回散文程序解析直接崩。OpenAI 引入 Function Calling 后把这个过程变成了严格的三步规范。用一个场景带你走一遍你问 Agent“查一下杭州明天天气”第一步契约定义Schema——给模型一份说明书开发者预先定义好工具的名片——用 JSON Schema 说清楚{ name:get_weather, description:查询指定城市的天气预报, parameters:{ type:object, properties:{ city:{ type:string, description:城市名称如 Hangzhou } }, required:[city] } }这张名片告诉模型我这里有个工具叫get_weather你想用它就必须给我一个city参数。第二步大脑决策——模型下达订单你问杭州明天天气怎样模型一看我自己没有实时天气数据但我有一个get_weather工具可以用用户提到了杭州于是它不再瞎编而是输出一份精确的调用请求{ name: get_weather, arguments: {/city/: /Hangzhou/} }注意此时模型没有联网没有调 API。它只是精准地提炼了你的意图翻译成了结构化指令。第三步闭环执行——Agent 跑腿 模型回复你的 Agent 程序收到这个 JSON去调真正的天气 API→ 调用 weather_api(Hangzhou) ← 返回12°C小雨然后把结果塞回给模型。模型拿到真实数据后组织一段自然语言“杭州明天 12°C有小雨记得带伞哦”整个过程用一张图总结你杭州明天天气 ↓ 模型决策我要调用 get_weather(cityHangzhou) ↓ Agent 执行调用真实 API → 得到 12°C/小雨 ↓ 模型回复杭州明天12°C有小雨带伞2.3 Function Calling 的局限Function Calling 很好但当你的工具从 3 个变成 30 个、甚至 300 个时——问题来了。自己经历过问题 1重复造轮子你给 Claude 写了一套工具定义给 GPT-4 又要重写一遍给 Gemini 再来一遍。格式不同、字段名不同、行为不同。三个模型三套代码维护成本爆炸。问题 2紧耦合工具定义硬编码在代码里。换个模型全部重写。换个应用场景全部重写。想让别人复用你的工具把代码 copy 给他。问题 3工具描述占上下文每个工具的 JSON Schema 都要塞进上下文窗口。工具一多光工具描述就占了几千个 Token——留给真正对话的空间就少了。“Function Calling 就像有线耳机——好用但每台设备都要买一根专用线。”这时候你就会想能不能有个标准接口写一次工具到处都能用这就是 MCP 要解决的问题。三、MCPAI 世界的USB-C 接口3.1 它是什么 一句话定义MCPModel Context Protocol模型上下文协议是 Anthropic 推出的一套开放协议让 AI 应用可以通过标准化接口连接任何外部工具和数据源——写一次到处用。2024 年 11 月Anthropic 正式发布了 MCP 协议。他们给出的类比是MCP 之于 AI 工具就像 USB-C 之于硬件设备。以前每个手机充电器都不一样Micro-USB、Lightning、各种私有接口USB-C 一出来——一根线搞定所有设备。MCP 做的是同样的事以前每个 AI 应用Claude、GPT、Cursor接工具都要单独写代码有了 MCP——写一个 MCP Server所有支持 MCP 的应用都能直接接入。3.2 MCP 的三层架构Host / Client / ServerMCP 不是一个工具它是一套通信协议。要理解它怎么工作你得先知道三个角色用一个类比帮你记住Host宿主 你家的电脑。它运行 AI 应用管理所有连接。Client客户端 电脑上的 USB 接口。每个接口对接一个外设。Server服务端 外接设备。键盘、鼠标、硬盘——各管各的功能。一个 Host 可以连多个 Server。每个 Server 独立提供能力。互不干扰。3.3 MCP 是怎么通信的两种传输方式方式使用场景大白话stdio(标准输入输出)本地server,跑在你自己的电脑上像两个人面对面说话不用网络sse/http远程server,跑在云端像打电话通过网络连接通信协议是 JSON-RPC 2.0——说白了就是用 JSON 格式发消息按规范办事。3.4 MCP 的完整工作流用杭州天气这个例子走一遍 MCP 的全流程第一步建立连接InitializeClaude DesktopHost启动时看到配置里有一个天气 MCP Server。于是Host → Server你好我是 Claude Desktop你能干啥 Server → Host我能查天气get_weather也能查空气质量get_air_quality双方握手完成Host 知道了 Server 有哪些能力。第二步发现工具List ToolsHost 把 Server 提供的工具列表注入到 LLM 的系统提示词中。现在模型看到了你有以下工具可用 - get_weather(city: string)查询城市天气 - get_air_quality(city: string)查询空气质量第三步调用工具Call Tool你问杭州天气模型决定调用get_weather模型 → Host我想调 get_weather参数 cityHangzhou Host → Client → Server转发调用请求 Server调真实 API拿到结果 Server → Client → Host → 模型返回12°C小雨和 Function Calling 有什么不同 核心区别在于维度Function CallingMCP工具定义在哪硬编码在你代码里独立的server 进程换个AI应用重写一遍直接接入不用改别人写的工具复制代码到你项目加个server配置就行工具更新了该你的代码server自己更新你不用动3.5 MCP 的三大能力MCP Server 不只能提供工具它实际上有三种能力能力谁来决定使用大白话类比Tool(工具)模型自主决定调用“我能帮你干活”–查天气、发邮件、写文件你桌子上的计算器–你觉得你需要就拿起来用Resourses(资源)应用程序决定注入“我有数据给你看”–数据库内容、文件列表领导放你桌子上的参考资料–不是你选的但是你得看Prompts(提示模版)用户主动选择“我有现成的流程”–一键启动特定的工作流用户点击一个“快捷操作”按钮觉得这个设计挺聪明的不是所有东西都让模型自己决定用不用。有些信息是应用自动塞进去的Resources有些是用户手动触发的Prompts。分层控制避免模型瞎调用。3.6 MCP 的生态有多火自 2024 年底发布以来MCP 的生态增长速度超乎想象主流大厂全面跟进GoogleGemini、OpenAI、微软VS Code、Copilot、AWS、Cloudflare 先后宣布支持第三方 Server 爆发GitHub、Stripe、Linear、Slack、Notion、Postgres、Docker 等都发布了官方 MCP Server开发工具原生支持Cursor、Windsurf、Claude Code、Zed 等 AI 编辑器已原生集成 MCPMCP Registry社区搭建了中央发现仓库开发者可以搜索、安装、发布 MCP Server远程 MCPCloudflare Workers 等平台支持将 MCP Server 部署为 Serverless 函数无需本地运行自己体验下来——MCP 最香的地方是别人写好的 Server你加一行配置就能用。比如要让你的 Agent 操作 GitHub以前要自己写 GitHub API 封装代码现在{ mcpServers:{ github:{ command:npx, args:[-y,modelcontextprotocol/server-github], env:{GITHUB_TOKEN:your-token} } } }加这么一段配置Agent 就能创建 PR、查看 Issue、管理仓库了。零开发成本。这就是标准化带来的生态红利——一个人写所有人用。四、MCP 出来后Function Calling 是不是就过时了这个问题最近社区争论很热闹。先说结论没过时。两者是不同层面的解决方案各有适用场景。4.1 一个反常的案例龙虾 AgentOpenClaw2025 年有一个现象级的开源项目叫 OpenClaw中文名龙虾做的是本地个人 Agent。有意思的是——它明确选择了回归 Function Calling没有用 MCP。这是在开历史倒车吗研究了他们的设计文档总结出两个核心原因原因 1开发成本MCP 需要单独启动 Server 进程涉及生命周期管理连接、握手、心跳、断线重连。对于一个本地 Agent 就用 5-10 个工具的场景——这太重了。MCP 方式 启动 Server A 进程 → 启动 Server B 进程 → 握手 → 注册工具 → 调用 → 管理心跳... Function Calling 方式 定义 JSON Schema → 写业务逻辑函数 → 搞定说白了能跑就行远比符合国际协议重要。 对很多独立开发者来说这是大实话。原因 2性能延迟MCP 在动态拉取工具列表list_tools时会消耗额外的 Token 和往返时间。在生产环境中如果工具列表是固定的——直接把 Function 定义写死在 Prompt 里速度更快、更省钱。实测过MCP 的 stdio 模式每次调用多了大约 50-100ms 延迟。单次不明显但如果一个任务需要连续调 20 次工具——这就是 1-2 秒的额外等待。4.2 那什么时候该用 MCP场景function callingMCP工具数量少10个且固定不变✅过度工程你只是一个模型/应用✅不需要标准化追求极致的延迟✅有额外开销工具被多个应用共享不够用✅工具由第三方提供自己重写累不稳定✅ 直接接入工具列表动态变化硬编码不稳定✅动态发现需要安全隔离(server独立进程)自己做隔离✅天然隔离一句话总结“MCP 是工具的分发方案Function Calling 是工具的集成方案。分发给全世界用 MCP自己内部用 Function Calling 就够了。”五、Agent Skills比能连接更重要的是会使用5.1 MCP 的两个痛点MCP 解决了标准化连接的问题。但在实际使用中发现了两个新问题痛点 1上下文爆炸一个 MCP Server 可能暴露几十甚至上百个工具。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中。社区开发者实测数据仅加载一个 Playwright MCP Server 就占用了 200K 上下文窗口的 8%。你接 3-5 个 Server20-40% 的上下文就被工具描述占了。留给真正对话的空间严重压缩。在多轮对话中这个问题更严重——Token 成本飙升推理能力下降。痛点 2能力鸿沟——“能连上≠会用”MCP 解决了能够连接的问题但没有解决知道如何使用的问题。举个例子你给 Agent 接了一个数据库 MCP Server。Agent 现在可以执行 SQL 了。但它知道你的数据库有哪些表表结构是什么查员工信息应该 JOIN 哪几张表有哪些查询是绝对不能执行的比如 DROP TABLE返回结果太多时应该怎么分页答案是它不知道。MCP 只给了它手没给操作手册。打个比方这就像给一个新入职的员工开通了所有系统的访问权限但没给他任何培训资料和操作规范。他有权限登录 CRM、ERP、数据库——但他完全不知道该怎么用。5.2 Agent Skills 是什么 一句话定义Agent Skills 是一种标准化的程序性知识封装格式——如果 MCP 给了 AI “手”Skills 就给了 AI “操作手册”。Skills 不是工具不提供 API不是 Prompt不只是文字指令。它是一个知识包包含什么时候可能还有脚本和参考文件一句话区分三者属性Function CallingMCPAgentSkills本质一次函数调用一个标准化接口一本操作手册提供的是“手”“标准化的手”“大脑里面的SOP”类比一个按钮USE-C接口应用软件小编再展开类比MCP 像 USB 接口或驱动程序——定义设备如何连接Skills 像应用软件——定义如何使用这些设备完成任务你可以有一个完善的打印机驱动MCP但如果没人告诉你怎么在 Word 里设置双面打印Skill你还是搞不定。5.3 Skills 最核心的创新渐进式披露前面说了MCP 的一大问题是上下文爆炸——所有工具描述一次性全塞进去。Skills 的解决方案非常聪明分三层加载按需逐步披露。小编用一个比方帮你理解想象你新入职一家公司。公司不会在第一天就把所有部门的操作手册、全部流程文档、几百个系统的使用指南全塞给你。那样你会当场崩溃。合理的做法是第一天入职手册告诉你公司有哪些部门、各干什么——你大概知道有什么就行接到任务时岗位培训你被分到市场部OK现在才给你市场部的详细流程遇到具体问题时查手册你需要用某个系统这时候才打开那个系统的操作指南Skills 的三层加载机制一模一样第一层元数据Metadata—— “公司有哪些部门”Agent 启动时只扫描每个 Skill 的名片——名称、一句话描述、触发词。--- name: wechat-article-writer description: 撰写微信公众号技术文章时使用此 skill triggers: - 写公众号文章 - 微信文章 - 改写成公众号 ---每个 Skill 的元数据只占约 100 个 Token。就算你装了 50 个 Skill初始消耗也只有 ~5000 Token。对比 MCP连一个 Playwright Server 就占 16000 Token。差距是数量级的。第二层技能主体Instructions—— “岗位培训手册”当用户的请求匹配到某个 Skill 的触发条件时Agent 才加载这个 Skill 的完整内容。比如用户说帮我写一篇公众号文章Agent 匹配到wechat-article-writer这时才把完整的写作规范、文章结构、风格要求全部加载进上下文。这部分通常 1000-5000 Token取决于指令复杂度。第三层附加资源Scripts References—— “具体问题查手册”对于复杂的 Skill还可以附带脚本、模板、参考文档。Agent 只在具体执行到那一步时才加载。skills/pdf-processing/ ├── SKILL.md # 主技能文件 ├── parse_pdf.py # PDF 解析脚本需要时才执行 ├── forms.md # 表单指南遇到表单任务才加载 └── templates/ # 模板文件需要时才访问结果你可以给 Agent 装几十个 Skill它的初始上下文消耗非常小。只有当任务真正需要某个 Skill 时才展开那个 Skill 的详细内容。这就是渐进式披露的威力——不是一次性全塞进去而是用多少加载多少。5.4 Skills MCP不是竞争是互补理解了三代技术的差异后你会发现——它们不是互相替代而是各管一层。最佳实践是把三者组合成分层架构小编用一个实际场景带你走一遍这个分层场景用户问 “分析一下公司里谁的话语权最高”Skills 层介入Agent 识别到这是一个数据分析类任务加载mysql-employees-analysis技能。Skill 里定义了分析话语权需要看哪些维度管理关系、薪资水平、任职时长、汇报线应该查哪些表、怎么 JOIN返回结果应该怎么解读MCP 层执行Skill 指导 Agent 调用数据库 MCP Server执行具体的 SQL 查询SELECT * FROM managers JOIN employees ON ...SELECT salary, title FROM ...Function Calling 层MCP Server 底层调用实际的数据库驱动执行 SQL。最终结果Agent 基于 Skill 里的领域知识把原始数据解读为有意义的结论返回给用户。这种架构的好处优势说明关注点分类MCP管“能力连接”Skills管“领域智慧”成本优化渐进式加载token消耗最小化可维护性业务逻辑(skills)和基础设施MCP解耦复用性同一个MCP Server 可被多个skills复用5.5 如何写好一个 Skill小编总结了几条实战原则基于自己写代码审查 Skill 的经验原则 1描述要回答什么时候加载我不是我是什么# ❌ 坏的描述 description: 这是一个代码审查技能 # ✅ 好的描述 description: 当用户提交代码要求 Review、检查代码质量、或合并 PR 前审查时使用Agent 扫描描述是为了判断要不要加载你——所以描述要像触发条件不像自我介绍。原则 2触发词覆盖多种说法用户可能说帮我 review 代码也可能说看看这段代码有没有问题。你的触发词要尽量覆盖各种说法triggers: -review 代码 -代码审查 -检查代码质量 -帮我看看这段代码 -PR review - code review原则 3指令要像 SOP不像散文# ❌ 坏的指令散文式 审查代码时要注意安全性、性能和可读性 同时关注命名规范和错误处理... # ✅ 好的指令SOP式 ## Step 1 — 理解上下文 1. **确认变更的目的修 Bug / 新功能 / 重构** 2. **查看关联的 Issue 或需求描述** 3. **了解影响范围涉及哪些模块** ## Step 2 — 逐层审查 1. **安全性是否有 SQL 注入、XSS、硬编码密钥** 2. **正确性边界条件、空值处理、并发安全** 3. **性能是否有 N1 查询、内存泄漏、死循环风险** 4. **可维护性命名清晰度、函数长度、重复代码** ...越结构化、越具体Agent 执行得越好。原则 4声明退出条件——什么算做完了## 完成标准 - [ ] 所有文件都已逐一审查 - [ ] 安全类问题标记为「必须修复」 - [ ] 每条审查意见标注了严重等级P0/P1/P2 - [ ] 给出总体评价通过 / 需修改 / 打回重写没有退出条件的 SkillAgent 可能无限循环或提前结束。原则 5Skill 内部可以调用 MCP 工具好的 Skill 不是替代MCP而是编排MCP。在指令里明确说用什么工具做什么事## Step 3 — 提交审查结果 1. **使用 GitHub MCP Server 在 PR 上逐行添加 Review Comment** 2. **对于安全类问题调用 Jira MCP Server 自动创建 Bug 工单** 3. **使用消息 MCP Server 通知提交者审查已完成**这样 Skill 负责决策和编排MCP 负责执行具体操作——职责清晰。5.6 一个完整的 Skill 工作场景小编用一个大家都遇到过的场景带你走一遍有 Skill 的 Agent是怎么工作的场景你对 Agent 说帮我看看这周的 Bug 列表写封周报邮件发给领导这件事你自己做大概要打开 Jira 查 Bug → 筛选本周的 → 分类汇总 → 写成邮件 → 发送。30 分钟起步。现在看 Agent 怎么做——第一步元数据匹配Agent 扫描所有已安装 Skill 的元数据发现weekly-report-writer匹配了用户说的写封周报邮件 Skill 触发词[周报, weekly report, 写周报, 汇报邮件] → 匹配加载这个 Skill此时消耗~100 Token。其余几十个 Skill 完全不占上下文。第二步加载完整指令Agent 读取这个 Skill 的完整内容。现在它知道了周报的标准格式本周完成 / 进行中 / 下周计划 / 风险项Bug 应该按严重程度分组不是按时间领导喜欢先看结论再看细节金字塔结构邮件标题格式[周报] XX团队 第N周工作汇报语气要求专业但不啰嗦重点加粗没有这个 SkillAgent 可能写成流水账或格式乱七八糟。有了 Skill它写出来的周报就像你组里最靠谱的那个同事写的。第三步按 SOP 执行Skill 编排 MCP 执行Skill 定义了清晰的步骤Agent 依次执行Step 1调用 Jira MCP Server → 查询本周所有 Bug状态、优先级、负责人 Step 2按 Skill 指令分类 → P0/P1/P2 分组 已解决/进行中/待处理 Step 3调用日历 MCP Server → 看看本周有没有重要会议/里程碑 Step 4根据 Skill 模板组织邮件正文 → 金字塔结构结论先行 Step 5调用邮件 MCP Server → 发送给领导抄送组内成员注意这里的分工Skill 负责怎么做分组逻辑、格式模板、语气要求MCP 负责去执行查 Jira、读日历、发邮件第四步退出检查Agent 对照 Skill 里定义的完成标准自检Bug 数据来源是本周不是上周的旧数据邮件标题符合格式有风险项板块领导最关心的收件人正确发给领导抄送组员邮件已成功发送全部通过 → 任务完成。你收到 Agent 的回复“周报已发送本周共处理 12 个 Bug其中 P0 级 2 个已修复。”从你说话到邮件发出可能就 30 秒。小编想强调的点是——如果没有 SkillAgent 也能写周报。但它写出来的很可能是格式不对领导看了想打人分类混乱P0 和 P2 混在一起重点不突出埋在一堆细节里语气不合适要么太随意要么太正式Skill 的价值不是让 Agent “能做”而是让它做得对、做得好。Skill 让 Agent 从什么都能干但什么都干不精变成了接到任务就像老员工一样驾轻就熟。六、全景总结三代技术一张表维度Function CallingMCPAgentSkills诞生时间20232024年底2025年底创造者OpenAIAnthropicanthrppic定义让模型输出结构化工具调用让模型通过标准协议被任何应用接入让Agent拥有领域的知识和工作流解决的问题AI不能动手工具不能被复用AI会玲姐但是不会精准的使用工具类比有线耳机USB-C接口应用软件上下文消耗中等工具定义常驻高每次都需要加在所有schema低渐进式加在适用场景内部简单工具绑定跨应用工具共享复杂领域任务编排关系基础层中间层上层演进关系 Function Calling → MCP → Agent Skills 能动手 手能通用 知道怎么用好手“从 Function Calling 到 Skills本质上是从’连接’到’智慧’的跃迁。”好了三代工具调用技术全部讲完。回到最开始的问题——该选哪个小编的建议很实际刚入门、做 Demo直接用 Function Calling简单够用要做跨应用共享、接第三方工具上 MCP做复杂的领域任务、需要 Agent “真的懂业务”写 Skills生产级系统三层都用各管各的层说实话小编自己目前的项目就是三层混合的——MCP 接数据库和文件系统Skills 定义写作流程和质量标准Function Calling 处理一些简单的内部逻辑。分工明确各司其职。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。大模型入门到实战全套学习大礼包1、大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通2、大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。3、AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。4、大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。5、大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。适用人群第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】