阿里面试：MCP与FC的10大差别？Harness 怎么 用MCP与FC？

一、定位差异：原生能力vs 通用协议

(1) 本质差异：FC是单一模型的原生工具调用能力（OpenAI 2023.6推出），MCP是多模型通用开源协议（Anthropic 2024.11推出）；

(2) 核心逻辑：MCP符合分层架构“解耦”思维，FC与 模型深度绑定、无解耦；

(3) 核心价值：FC解决“模型不会做事”，MCP解决“不同模型与工具适配碎片化”。

先聊FC (Function Calling）。

FC 是OpenAI于2023年6月率先推出的特定模型原生工具调用能力，核心目标很纯粹——“让单一模型具备工具调用能力”，解决的是**“模型不会做事”**的核心痛点。

说白了，FC就是模型自带的“手脚”，不用额外搭架子，模型自己就能调用工具。

FC 作为模型内置的原生功能，它的核心价值是将用户的自然语言指令，直接转换为具体的API调用指令，从而让大模型突破自身知识更新停滞的局限，实现实时数据查询（如天气、股市）、本地文件操作、数据库交互等实际功能。

目前，包括面壁智能MiniCPM 3.0在内的多数主流模型，都强化了FC能力，适配更多端侧场景。

但尼恩必须吐槽一句：FC的问题，也出在“原生”上。

它和模型绑定得太深了，相当于把**“工具调用”和“模型本身”揉在了一起**，违背了分层架构的解耦思维。

就像把螺丝刀和家电焊死在一起，换个家电，螺丝刀就废了。

再看MCP。

MCP是Anthropic于2024年11月推出的开源标准化协议，被业内比喻为AI领域的“通用USB接口”，核心目标是**“统一模型与工具的连接标准”**，解决的是“不同模型与工具适配碎片化”的行业痛点。

据尼恩了解，现在70%的企业，都因为工具协同问题延缓了AI项目落地 。而MCP的诞生，就是为了破解这个困境。

它不局限于某一款模型，而是制定了统一的交互规范，相当于在“模型”和“工具”之间，加了一层统一的适配层，完美契合分层架构的解耦理念。

这样一来，各类AI模型、外部工具、数据源，都能通过这一层接口实现互联互通，开发者不用为不同模型重复开发工具适配代码，大幅降低开发成本。

现在，谷歌Gemini、百度文心一言、通义千问3等主流模型，都已正式接入MCP协议，AI工具调用终于要进入标准化时代了。

案例介绍

下面是 一家中型企业做AI工具集成，客户需求很简单：

让GPT-4和通义千问3，同时调用企业内网的数据查询工具。

一开始，技术团队想用 FC做，给GPT-4写了一套函数适配，又给通义千问3写了一套，结果两套代码不兼容，改来改去，一周都没搞定，还出了bug。

后来 ，直接用MCP协议封装了工具接口，注册到MCP Server上，两款模型不用单独适配，直接通过MCP Client调用，当天就调试通过了。

这就是分层解耦的威力——把“工具适配”这一层独立出来，不管上层是什么模型，都能直接对接。

1. Function Calling (FC) 实现示例

尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取

二、架构复杂度差异：复杂协同 vs 轻量调用

(1) 架构差异：MCP是“客户端-服务器”双层架构（需搭建MCP Server中间层），FC是“点对点”轻量架构（无中间层）；

(2) MCP优势：支持双向实时通信、自动维护上下文、多模型/多工具并行，适配企业级复杂场景；3. FC优势：部署简单、调用延迟低，适配轻量场景；

(4) 核心总结：复杂场景用MCP，轻量场景用FC。

还是用分层架构的思维来看：

• MCP是“客户端-服务器”双层架构，多了一层中间协调层；
• FC是“点对点”的 轻量级 架构，没有中间层。

没有好坏之分，只看场景适配。

先看MCP。

MCP采用“客户端-服务器（Client-Server）”双层架构，必须搭建MCP Server作为中间协调层，形成**“AI模型→MCP客户端→MCP服务器→外部工具”**的完整交互链路。

这一层中间层，就是分层架构里的“接口层”，负责协调模型和工具的通信，解耦二者的依赖。

这种架构的优势很明显：支持双向实时通信（如SSE流），能主动维护多轮对话的上下文状态，轻松实现跨工具连贯任务的自动化执行。

比如“查询企业销售数据→生成可视化图表→发送至指定邮箱”， 用MCP搭建好架构后，全程不用人工干预，系统自动完成所有步骤。

而且MCP基于TCP/IP协议传输数据，支持多模型、多工具并行协同，扩展性极强，完全能扛住企业级的复杂场景。

当然，缺点也有——搭建MCP Server需要一定的技术门槛，不是小白能快速上手的。

再看Function Calling。

FC就简单多了，没有复杂的架构设计，采用“请求-响应”模式，无需搭建中间层，直接实现“用户→模型→工具”的点对点交互。

它的调用流程是独立的，单次调用只完成一个工具的操作，相当于“一锤子买卖”。

要是想实现多步骤任务，比如刚才说的“查数据→生成图表→发邮件”，就需要开发者手动串联多次函数调用，自己维护上下文状态——这就很麻烦了。

假如用FC做 一个简单的天气查询工具，单独调用没问题，但要串联“查天气→生成日报→发邮件”，**光写串联逻辑就写了几十行代码，**还容易出bug。

但不可否认，FC的优势也很突出：部署简单、低延迟，不用复杂的环境配置，适合快速开发、高性能 、和简单功能扩展。

总结一句：复杂场景用MCP，轻量场景用FC，别搞反了！

三、安全与合规差异：本地化防护vs 云端依赖

(1) MCP安全优势：MCP解决方案（本地化部署、权限管控、通过合规审核）。 敏感数据本地化部署（留存企业内部），支持OAuth2.0+RBAC权限精细化管控，符合企业合规要求；

(2) FC安全痛点：FC弊端（密钥上传云端、有泄露风险、不合规）；高度依赖云端，API密钥等信息需上传云端，数据流向不可自主掌控，合规性不足；

(3) 核心对比：MCP=数据锁在自家，FC=数据放在第三方仓库。

对于企业级应用，安全和合规，比什么都重要！

尤其是金融、政务这类行业，敏感数据泄露，轻则罚款，重则停业。

而MCP和FC在安全上的差异，简直是天差地别。

先看MCP。

MCP最核心的安全优势，就是强调敏感数据的本地化处理. 所有敏感信息，比如企业内网API密钥、用户隐私数据、核心业务数据，都能保留在企业自身部署的MCP Server中，不用上传到第三方云端。

这就相当于把数据锁在自己家里，而不是放在别人的仓库里，从源头降低了数据泄露的风险。

而且MCP支持OAuth2.0+RBAC权限模型，能对不同角色、不同工具的访问权限进行精细化管控，谁能调用什么工具、能看什么数据，都能设置，操作可审计、权限可追溯，完全符合企业级数据安全合规要求。

尼恩有vip 去年给一家银行做AI架构设计，客户明确要求“敏感数据不上云”，最后就是用MCP做的本地化部署，顺利通过了合规审核。

再看Function Calling。

FC的数据流，高度依赖云端服务： 开发者必须把工具API密钥、调用逻辑等信息，配置在模型厂商的云端平台。

不是说云端不安全，而是企业无法自主掌控数据流向——数据传输过程中，有可能被拦截、泄露；而且一旦厂商的云端出问题，你的工具调用也会跟着崩。

虽然主流厂商都提供API密钥加密管理，但整体安全防护，还是依赖厂商的云端安全体系。

对于金融、政务这类对数据安全要求极高的行业，FC的合规性，很难完全满足。

尼恩见过一个案例，某金融公司用FC调用客户信息查询工具，不小心把API密钥泄露了，最后被监管部门罚款，还丢了客户， 血的教训啊！

四、适用场景差异：企业级复杂场景vs轻量快速开发场景

(1) MCP适配场景：跨系统数据整合、复杂Agent任务、安全敏感操作（金融/政务），适合企业级复杂场景；

(2) FC适配场景：简单功能扩展（天气/快递/汇率）、单模型插件开发、快速原型验证，适合轻量快速开发；

(3) 核心判断标准：需求是“复杂、安全、多模型”用MCP，“简单、快速、单模型”用FC。

MCP和FC，不是替代关系，而是互补关系，各自有自己的适配场景。

尼恩总结了一个简单的判断标准：看你的需求是“复杂、安全、多模型”，还是“简单、快速、单模型”。

先看MCP的适配场景。 MCP更适合企业级复杂场景，尤其是对数据安全、多工具协同、跨模型适配有较高要求的场景。

具体来说，主要有三类：

• 1. 跨系统数据整合：比如ERP、CRM、企业文件库的互联互通，比如 制造业的项目，用MCP把生产、销售、库存三个系统的工具整合起来，实现了数据实时同步，效率提升了60%。
• 2. 复杂Agent任务：比如企业工单自动化处理、智能客服多工具协同响应，不用人工干预，系统自动完成“接收工单→查询数据→生成回复→反馈结果”的全流程。
• 3. 安全敏感操作：比如内网数据查询、本地文件读写、核心业务系统调用，尤其是金融、政务行业，必须用MCP做本地化部署，确保数据安全。

还有一个点，MCP在接入企业本地资料方面，表现特别突出，是企业实现AI本地化部署的优选方案。

**再看Function Calling的适配场景。**FC更适合轻量、快速开发场景，尤其是对开发成本、部署效率有较高要求的场景。

具体来说，也有三类：

• 1. 简单功能扩展：比如天气查询、快递跟踪、汇率转换，这些功能单一，不用复杂协同，用FC开发，几分钟就能搞定。
• 2. 单模型插件开发：比如基于GPT的文档翻译插件、表格处理插件，只适配一个模型，不用考虑跨模型复用，开发成本低。
• 3. 快速原型验证：比如验证工具调用逻辑的可行性，不用搭建复杂架构，用FC快速写个demo，验证没问题再升级架构。

FC的优势就是开箱即用，不用掌握复杂的协议规范，适合有一定开发基础的开发者，快速实现功能落地。

五、使用差异：开发门槛vs便捷性

(1) FC使用门槛：较高，需手动定义函数签名、处理调用逻辑、串联多步骤任务，适合有编程经验者；

(2) MCP使用便捷性：低，无需手动定义函数，搭建配置MCP Server后，模型直接发送请求即可调用工具，小白可快速上手；

(3) 总结：MCP上手稍难但后续省心，FC上手简单但后续麻烦。

聊完场景，再聊使用体验——这也是很多开发者关心的点：到底哪个好上手？

尼恩一句话总结：MCP上手稍难，但后续省心；FC上手简单，但后续麻烦。

先看Function Calling。

FC的使用门槛相对较高，需要开发者具备一定的编程基础——不是说小白完全不能用，而是小白用起来会很吃力。

• 首先，你得手动定义函数签名，包括函数名称、参数、返回值、描述等，明确模型与工具的交互规则；
• 其次，你得自行处理函数调用逻辑，比如参数校验、异常处理、上下文传递；
• 要是涉及多步骤任务，还得手动串联多个函数调用。

尼恩见过很多小白，第一次用FC，光是定义函数签名，就改了好几次——要么参数不对，要么描述不清晰，模型识别不了。

简单来说，FC的使用，更像是“手动编写工具调用脚本”，灵活性强，但便捷性不足，适合有编程经验的开发者。

再看MCP。

MCP的使用，就便捷多了，大幅降低了工具调用的门槛——哪怕你是非专业开发者，稍微了解一下，也能快速上手。

• 开发者只需搭建并配置MCP Server地址，将外部工具接口注册至服务器，
• 后续AI模型无需关心工具的具体实现细节，只需通过MCP客户端发送请求，就能实现工具调用。

整个过程，**不用手动定义函数，不用处理复杂调用逻辑，**模型会自动匹配合适的工具与参数，甚至不用精准指令，就能唤起服务——这才是真正的“傻瓜式操作”。

六、复用性差异：跨模型共用vs’模型专属

(1) FC复用性痛点：模型专属，不同模型FC规范不同，工具需单独适配，重复开发成本高；

(2) MCP复用性优势：一次封装工具、注册至Server，所有兼容MCP的模型均可调用，实现“一次开发，多模型共用”；

(3) 核心差距：FC重复造轮子，MCP高效复用、降低成本。

这一点，是MCP最核心的优势，也是FC最大的痛点 。

尼恩做架构设计，最看重的就是复用性——能一次开发，多次使用，才是高效的架构，不然就是重复造轮子，浪费时间和成本。

**先看Function Calling。**FC的工具复用性，差到离谱——它属于“模型专属”模式，不同厂商的FC实现方式、函数签名规范，各不相同。

比如，你为GPT-4开发的工具，无法直接适配Gemini、通义千问3，更换模型时，必须重新定义函数、适配调用逻辑——相当于你写了一个螺丝刀，只能拧一个牌子的螺丝，换个牌子，就得重新做一个。

而且，工具数量越多，模型数量越多，重复开发的成本就越高，这也是很多企业用FC做多模型项目，最后成本超支的原因。

**再看MCP。**MCP完美解决了复用性的痛点——它的核心优势之一，就是跨模型复用能力。

开发者只需按照MCP协议，将工具接口封装一次，注册至MCP Server，所有兼容MCP协议的模型，比如GPT-4、Gemini、通义千问3，都能通过MCP客户端访问该工具，无需重复开发适配代码。

这种“一次开发，多模型共用”的模式，大幅提升了开发效率，尤其适合多模型协同的企业场景——这也是MCP被尼恩称为“AI互联互通关键方案”的核心原因。

七、流程差异：注册式协同vs点对点调用

(1) FC流程：无注册式，点对点调用，流程为“用户需求→LLM解析→生成函数指令→工具执行→反馈”，需手动传递上下文；

(2) MCP流程：预先注册式，有中间层协调，流程为“工具注册→用户需求→LLM请求→Server协调→工具执行→反馈”，自动维护上下文；

(3) 核心差异：FC需手动串联上下文，MCP自动协调多工具、维护上下文。

聊完复用性，再聊调用流程——流程的差异，决定了二者的协同效率。

还是用分层架构的思维来看：MCP的流程，是“注册式协同”，中间层负责协调；FC的流程，是“点对点调用”，没有中间层，直接交互。

先看Function Calling。

FC采用“无注册式”调用流程，无需预先注册工具，核心流程很简单：

• 用户提出自然语言需求→LLM解析用户意图→生成格式化的函数调用指令→工具执行→返回结果→LLM整理反馈。
• 整个流程，单次调用独立，上下文信息需要开发者手动传递——也就是说，你调用完一个工具，要自己把结果保存下来，再传给下一个工具，不然上下文就丢了。

尼恩之前用FC做“查数据→生成图表”，就是因为忘了传递上下文，导致生成的图表没有数据，调试了半天，才发现是上下文丢失的问题——太坑了！

再看MCP。

MCP采用“预先注册式”协同流程，核心流程是：

• 开发者预先注册工具→用户提需求→LLM生成请求→MCP客户端传递请求→MCP Server协调工具执行→返回结果→LLM整理反馈。
• 这种流程，引入了中间协调层（MCP Server），职责划分更清晰，而且能自动维护上下文状态，实现跨工具、多步骤的连贯执行，无需人工干预。

还是“查数据→生成图表”，用MCP，你只需发送一个请求，MCP Server会自动协调“数据查询工具”和“图表生成工具”，自动传递上下文，全程不用你管，省心太多。

八、组件差异：三层解耦 vs无独立组件

(1) MCP组件：三大核心组件（Server-大脑、Client-信使、AI模型-决策者），实现三层解耦，可单独升级组件、维护性强；

(2) FC组件：无独立组件，依赖模型意图解析能力和开发者定义的函数签名，耦合度高，无法单独优化调用流程；

(3) 核心差异：MCP解耦、可维护性强，FC耦合、灵活性差。

这一点，其实是架构差异的延伸——组件设计的不同，决定了二者的灵活性、可维护性。

尼恩还是用分层架构的解耦思维来聊——MCP的组件设计，完美实现了三层解耦；FC则没有独立组件，耦合度很高。

先看MCP。

MCP包含三大核心组件，实现了“AI模型、MCP客户端、MCP服务器”的三层解耦设计：

1. MCP Server（服务器）：核心组件，负责工具注册、请求协调、权限管理、结果反馈，相当于“大脑”；

2. MCP Client（客户端）：负责AI模型与MCP Server之间的消息传递，相当于“信使”；

3. AI模型：负责解析用户意图，生成符合MCP协议的请求指令，相当于“决策者”。

这种解耦设计，最大的优势就是可维护性极强——你可以单独升级某一个组件，比如优化MCP Server的权限管理功能，不用影响其他组件的正常运行。

尼恩某vip做过一个 mess 智能体 项目，需要优化工具调用的响应速度，只升级了MCP Server的协调逻辑，其他组件不用动，半天就完成了升级，不影响业务正常运行——这就是解耦的威力。

再看Function Calling。

FC没有独立的组件设计，它的调用能力，完全依赖两大核心要素：

1. 模型自身的意图解析能力：LLM能否准确将自然语言转换为函数调用指令；

2. 开发者定义的函数签名：明确工具的调用规则。

整个调用过程，没有中间协调组件，结构更简单，但灵活性与可维护性不足——如果你想优化调用逻辑，只能修改函数签名，或者依赖模型升级，无法单独对调用流程进行调整。

九、集成方式差异：统一协议接入vs单独适配

(1) FC集成方式：单独适配，每接入一款工具需单独定义函数、编写适配代码，成本随工具数量线性上升；

(2) MCP集成方式：统一协议接入，所有工具统一封装、一次注册至Server，无需单独适配，成本低、效率高；

(3) 核心对比：FC“逐个适配”，MCP“一次搞定”。

这一点，其实是架构差异的延伸——组件设计的不同，决定了二者的灵活性、可维护性。

尼恩还是用分层架构的解耦思维来聊——MCP的组件设计，完美实现了三层解耦；FC则没有独立组件，耦合度很高。

先看MCP。

MCP包含三大核心组件**，实现了“AI模型、MCP客户端、MCP服务器”的三层解耦设计：**

1. MCP Server（服务器）：核心组件，负责工具注册、请求协调、权限管理、结果反馈，相当于“大脑”；

2. MCP Client（客户端）：负责AI模型与MCP Server之间的消息传递，相当于“信使”；

3. AI模型：负责解析用户意图，生成符合MCP协议的请求指令，相当于“决策者”。

这种解耦设计，最大的优势就是可维护性极强——你可以单独升级某一个组件，比如优化MCP Server的权限管理功能，不用影响其他组件的正常运行。

尼恩之前做过一个项目，需要优化工具调用的响应速度，只升级了MCP Server的协调逻辑，其他组件不用动，半天就完成了升级，不影响业务正常运行——这就是解耦的威力。

再看Function Calling。

FC没有独立的组件设计，它的调用能力，完全依赖两大核心要素：

1. 模型自身的意图解析能力：LLM能否准确将自然语言转换为函数调用指令；

2. 开发者定义的函数签名：明确工具的调用规则。

整个调用过程，没有中间协调组件，结构更简单，但灵活性与可维护性不足——如果你想优化调用逻辑，只能修改函数签名，或者依赖模型升级，无法单独对调用流程进行调整。

十、生态差异：封闭专属vs开放通用

(1) FC生态：封闭专属，不同模型厂商各自制定规范，工具无法跨模型复用，开发者重复开发，协同性差；

(2) MCP生态：开放通用，开源标准化协议，不依附任何厂商，主流AI厂商均接入，工具可跨模型/跨平台复用，全球开发者共建；

(3) 未来趋势：MCP为主流，FC为轻量补充，二者融合发展。

这决定了二者的长期发展潜力，也关系到开发者的长期投入成本。

尼恩的判断：未来，AI工具调用的趋势，一定是“开放化、标准化”，MCP会成为主流，FC会作为轻量补充，二者融合发展。

先看Function Calling的生态。

FC的生态，属于“封闭专属”模式——不同模型厂商，各自制定自身的函数调用规范，形成独立的生态体系。

比如，GPT的FC规范，和DeepSeek、MiniCPM 3.0的规范不兼容；你为GPT开发的工具，无法直接用于其他模型，开发者只能在不同厂商的生态中，重复开发——相当于“各自为战”，生态协同性极差。

尼恩把这种模式，比作“什么样的锅配什么盖”。

你买了某品牌的锅，就只能用该品牌的盖，换个锅，盖就废了。

这种封闭生态，最大的问题，就是开发者的投入成本太高。 重复开发，重复维护，不利于生态的长期发展。

再看MCP的生态。

MCP的生态，属于“开放通用”模式——它是开源标准化协议，不依附于任何一款模型或厂商，由全球开发者共同共建生态。

目前，国内外主流AI厂商，比如OpenAI、谷歌、百度、阿里、字节，都已接入MCP协议，形成了“多模型、多工具、多平台”的互联互通生态。

开发者开发的MCP Server，可开放给所有兼容模型使用；工具可跨模型、跨平台复用，大幅减少重复开发成本——这才是生态该有的样子。

当然，MCP生态目前也有短板——比如互联网工具池还比较小，部分平台只开放边缘功能，核心数据与权限仍保持戒备。

不过尼恩了解到，Anthropic正在计划完善MCP的托管机制与可发现性，相信用不了多久，MCP生态会越来越成熟。

十一、性能差异： MCP 与 FC 性能核心差异

前面把MCP和FC的定位、架构、安全、场景这些“表面功夫”全拆透了，却漏了一个线上落地必踩坑、很多架构师容易忽略的核心点：性能差异。

单从性能角度来讲，FC完胜！无论是时延、开销、并发响应速度， FC都比MCP更有优势；

(1) 单次低延迟场景：Function Calling 完胜！没有中间层转发，链路更短、时延更低、开销更小，简单调用秒响应，MCP多一层中转，单次时延必高于FC。

(2) 网络传输开销：FC 完胜！轻量化小包直传，开销极小，无任何多余协议封装和中转损耗；MCP多一层协议封装+Server转发，单请求带宽开销、传输时延均高于FC，这是架构设计带来的性能损耗，无法避免。

先看Function Calling 链路

链路特别简单：用户 → LLM → 工具API

没有中间转发、没有协议封装冗余，就是“点对点”的直接调用——这也是FC最核心的优势。

优势很明显：单次调用RT极低，比如查个天气、查个快递（就像之前聊的快递100API调用）、查个汇率，这类单次短请求，用FC秒响应，完全不用多余操作。

再看MCP 链路

链路比FC多一层：用户 → LLM → MCP Client → MCP Server → 工具API

多了一层Client-Server中转，还有协议标准化封装 , 这就是 MCP“时延高”的原因 。

还是刚才“查数据→生成图表→发邮件”的需求，用MCP确实省心、不易出错，但单论每一步的响应时延、整体性能表现，依然是FC更优。

MCP赢在便捷性，而非性能。

第 十二 章　DeerFlow 如何使用 FC、MCP扩展工具

DeerFlow FC & MCP互补共生，适配不同场景的技术选择

DeerFlow 的工具体系，采用三层分层设计，边界清晰、职责明确，不用搞复杂的嵌套逻辑——分别是：

• 内置工具（builtins） 这个是fc
• 社区工具（community） 这个是fc
• MCP 扩展工具。

其中前两层由框架自身统一管理，不用开发者额外维护。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】