1. 项目概述一次面试引发的深度技术辨析前几天和一位在阿里做AI应用架构的朋友聊天他提到最近面试候选人时发现很多人对“Agent Skills”、“MCP”和“Function Call”这几个概念的理解是模糊的、甚至是混淆的。这其实挺有意思的因为这三个词恰好代表了当前AI应用开发特别是智能体Agent构建领域三种不同层级、不同思路的能力扩展方案。它们不是简单的并列关系而是从微观到宏观从封闭到开放的一套技术演进图谱。简单来说你可以把它们想象成给一个聪明的“大脑”大语言模型配备不同工具和技能的方式。Function Call是最基础、最直接的“手把手”教学告诉模型现在可以调用某个具体函数了。Agent Skills则更像是一个“技能工具箱”的管理理念它关注如何组织、描述和让模型理解一整套能力。而MCP则是一个雄心勃勃的“行业标准协议”它试图定义一套统一的语言和流程让任何工具都能以标准化的方式接入任何模型或智能体实现真正的“即插即用”。这次讨论我们就来彻底厘清这三者的区别、联系以及各自的适用场景。无论你是正在准备面试的开发者还是希望构建更强大AI应用的工程师理解这些概念背后的设计哲学和实现差异都能帮你更好地进行技术选型和架构设计。2. 核心概念拆解从Function Call到MCP协议要理解区别我们必须先回到原点看看每个概念究竟解决了什么问题。它们诞生的背景和要应对的挑战是不同的这直接决定了它们的设计形态和应用范围。2.1 Function Call模型与外部世界的“基础连接器”Function Call通常被称为“函数调用”是伴随GPT-3.5/4等模型API一同成熟起来的基础能力。它的核心逻辑非常简单直接开发者定义好一个函数包括名称、描述、参数结构然后将这个定义“告知”大语言模型。模型在对话过程中如果判断需要调用这个函数来获取信息或执行操作就会在回复中结构化地输出一个包含函数名和参数的JSON对象。随后开发者的应用程序解析这个JSON真正执行本地或远程的函数并将执行结果返回给模型模型再基于结果生成最终的自然语言回复给用户。它的工作流程是一个清晰的闭环用户提问 - 模型思考是否需要调用函数 - 是则输出结构化调用请求 - 应用端执行函数 - 返回结果给模型 - 模型整合结果生成回答。例如你问“北京今天天气怎么样”模型可能会输出一个调用get_weather(location北京)的请求你的代码执行这个函数调用气象API把“晴25℃”的结果塞回给模型模型再组织成“北京今天天气晴朗气温25摄氏度……”这样的句子回复你。Function Call的本质是给模型开了一个非常具体、预设好的“后门”。这个后门是什么样、能通向哪里完全由开发者定义。它的优势在于极度简单和可控几乎无额外开销与模型API集成紧密。但它的缺点也同样明显它是静态和封闭的。函数列表需要在对话开始前就定义好并注入模型的上下文中途难以动态增删。每个函数都需要手动编写描述和参数格式当工具数量庞大时管理和维护成本很高。更重要的是它缺乏统一的发现和描述标准每个项目、每个模型平台可能都有自己的实现方式。2.2 Agent Skills面向任务规划的“能力抽象层”当我们需要构建一个能处理复杂任务的智能体Agent时仅仅有一堆零散的Function Call就不够用了。这就是Agent Skills概念登场的时候。Skill不是一个具体的技术协议而是一个更高层次的设计范式或架构理念。它关注的是如何对“能力”进行抽象、封装和组织以便智能体能够更好地理解、选择和组合这些能力来完成复杂目标。一个Skill通常包含以下几个要素能力描述用自然语言清晰说明这个技能能做什么、适用于什么场景。输入/输出规范定义执行该技能需要哪些参数以及会返回什么格式的结果。执行逻辑背后具体的代码实现可能对应一个或多个Function Call也可能是一段复杂的业务流程。元信息如技能类别、权限要求、依赖条件、成功概率估计等用于帮助智能体进行决策。例如一个“订机票Skill”可能内部封装了查询航班、比价、填写乘机人信息、支付等多个底层函数调用。但对智能体来说它只需要知道“我有一个订机票的技能需要提供目的地、时间和乘客信息”而不必关心里面具体调用了哪个航空公司的API、支付流程如何衔接。Agent Skills的核心价值在于“管理”和“规划”。它让智能体以更接近人类“技能”的维度去思考而不是面对一堆冰冷的函数签名。在基于LLM的智能体框架如LangChain、AutoGPT、Dify等中Skills的管理系统负责技能的注册、发现、描述和调用。智能体的“大脑”通常是规划模块根据用户目标和当前状态从技能库中选择最合适的一个或一系列技能来执行。与Function Call相比Skill是更上层的抽象。一个Skill内部可能会调用多个Function Call而一个Function Call也可能被多个不同的Skill复用。你可以把Function Call看作是“汇编指令”而Skill则是“高级函数”或“模块”。Skill的设计更注重与智能体规划、推理流程的配合。2.3 MCP打破生态壁垒的“通用工具协议”如果说Function Call是“私有后门”Agent Skills是“内部管理规范”那么MCP的目标就是建立一条“公共高速公路”。MCP全称Model Context Protocol是由Anthropic公司牵头提出并开源的一套协议标准。它要解决的核心痛点是AI模型/智能体与外部工具、数据源之间连接的高度碎片化和定制化问题。在MCP出现之前如果你想让你Claude、ChatGPT或自己部署的模型能使用某个特定工具比如查询公司内部数据库、操作Figma设计稿、控制智能家居你需要为每个“模型-工具”组合编写特定的适配器代码。这产生了大量的重复劳动并且工具生态难以共享。MCP协议定义了一套标准化的通信方式主要包括标准化接口规定了工具称为MCP Server如何向模型MCP Client宣告自己提供了哪些“资源”和“工具”。统一描述格式工具的能力通过统一的模式Schema进行描述包括名称、描述、参数等类似于OpenAPI规范但更简洁为AI交互优化。安全的执行通道模型可以通过标准请求调用工具工具执行后通过标准响应返回结果。这个过程通常是远程过程调用。动态发现与连接MCP Client可以在运行时动态发现并连接到MCP Server无需在应用启动前就将所有工具定义硬编码进去。MCP的核心思想是“关注点分离”和“标准化”。工具开发者只需关注实现一个符合MCP协议的Server就可以让所有支持MCP协议的AI模型或智能体框架如Claude Desktop、Cursor、Continue.dev等直接使用。而AI应用开发者则无需关心每个工具的具体集成细节只需让他的智能体客户端支持MCP协议就能接入整个MCP工具生态。举个例子社区有人开发了一个figma-mcp-server这个服务器程序运行后任何支持MCP的AI助手如配置好的Claude就能直接获取Figma文件列表、读取设计稿内容甚至进行简单编辑而不需要Figma官方为每个AI助手单独开发插件。3. 三维对比设计哲学、应用场景与实操差异理解了各自是什么我们可以从多个维度进行一场深入的“同台竞技”这能帮你更清晰地把握何时该用什么。3.1 设计哲学与定位对比Function Call模型原生扩展机制定位是大语言模型API的一部分是模型能力的直接延伸。它的设计首要目标是简单、高效、低延迟地让模型获得执行简单、离散操作的能力。哲学“告诉模型它能做什么具体事”。它是一种指令式的扩展强调控制和精确性。Agent Skills智能体架构中的能力单元定位是构建复杂智能体Agent应用时的架构设计概念。它不属于某个特定模型而是属于智能体系统本身。哲学“为智能体规划提供模块化能力”。它是一种任务导向的抽象强调能力的封装、描述和可规划性。MCP跨平台工具集成开放标准定位是一个中立的、开放的网络协议。它独立于任何特定的模型或智能体框架旨在成为连接AI模型与外部工具世界的“通用总线”。哲学“让任何工具都能被任何AI使用”。它是一种协议化、标准化的解决方案强调互操作性和生态建设。3.2 技术实现与依赖关系Function Call实现深度依赖特定模型提供商如OpenAI、Anthropic的API规范。你需要按照它们的格式定义JSON Schema。依赖强绑定于你所使用的模型API。不同厂商的格式可能有细微差别。通信通常作为模型API请求/响应的一部分在同一次HTTP请求/响应周期内完成是同步的。Agent Skills实现没有统一标准由各个智能体框架LangChain, AutoGen, Dify等自行定义其Skill的接口和注册方式。通常需要在框架的代码中定义。依赖绑定于你选择的智能体框架。从一个框架迁移到另一个可能需要重写Skill定义。通信在智能体框架内部进行可能是内存函数调用也可能是内部消息传递。MCP实现基于标准的、与模型无关的协议通常使用JSON-RPC over stdio/HTTP/SSE。工具端实现MCP ServerAI端实现MCP Client。依赖不依赖任何特定模型或框架只依赖MCP协议本身。只要双方都遵循协议即可通信。通信通常是进程间或网络间的通信。Server可以独立部署和运行Client动态连接。支持异步和流式响应。3.3 动态性与生态对比这是三者区别最显著的地方之一。Function Call静态。函数列表必须在会话开始前确定并注入系统提示词或通过API参数传入。对话中途无法动态添加新的函数。生态上每个应用都是孤岛。Agent Skills半静态。取决于框架实现有些框架支持运行时注册Skill但通常仍需要在代码层面预定义或通过配置文件加载。生态局限于该框架的内部社区。MCP高度动态。MCP Client可以在任何时候发现并连接到新的MCP Server立即获取其提供的工具列表并开始使用。这带来了真正的“即插即用”体验。它正在形成一个共享的生态开发者可以将自己写的MCP Server开源供所有MCP用户使用比如搜索、数据库、浏览器自动化等通用工具正在涌现。3.4 复杂度与适用场景Function Call复杂度低。适合快速原型验证、功能简单的聊天机器人、需要紧密耦合模型响应的场景。场景天气查询、简单计算、知识库问答调用检索函数等。当你的工具数量很少10个且变动不频繁时它是最高效的选择。口诀“简单、直接、快但别想太多。”Agent Skills复杂度中到高。引入了架构设计需要你思考能力的抽象和智能体的规划逻辑。场景构建需要自主规划、分解和执行多步骤任务的智能体。例如一个“旅行规划Agent”可能需要组合“查询航班”、“预订酒店”、“生成日程”等多个Skills。或者企业内部的自动化流程助手需要调用多个内部系统API。口诀“我要造一个能自己思考、组合技能完成复杂任务的‘大脑’。”MCP复杂度中使用/ 高开发Server。使用现成的MCP Server很简单如下载一个二进制文件运行。开发一个新的MCP Server需要理解协议细节。场景希望AI助手拥有广泛、可扩展的工具能力比如让Claude Desktop能直接操作我的本地文件、查询数据库、控制智能家居。开发通用工具希望被多种AI使用你写了一个优秀的代码仓库分析工具通过封装成MCP Server可以让Claude、Cursor、以及任何支持MCP的智能体都使用它。在安全隔离环境中运行工具工具运行在独立的Server进程中与AI主进程隔离更安全。口诀“我想要一个开放的工具生态让我的AI能像安装插件一样使用各种能力。”4. 实战推演从零构建一个智能体看三者如何协作光讲理论有点干我们通过一个虚构但具体的例子来看看这三者在实际项目中可能扮演的角色。假设我们要构建一个“智能研发助手Agent”它能帮程序员分析需求、检索相关代码、生成新代码并提交到Git。4.1 技术选型与架构设计我们选择使用一个开源的智能体框架比如LangGraph作为我们Agent的“大脑”和协调中枢。这个框架本身提供了Agent Skills的管理能力。我们的大模型选用支持Function Call的API例如GPT-4。同时我们希望代码检索、Git操作等工具能力是标准化、可复用的因此考虑采用MCP协议。于是架构雏形如下核心智能体框架管理Skills和规划流程。思维引擎大模型API通过Function Call接收框架的指令。工具生态多个MCP Server提供代码检索、Git操作、文件浏览等标准化工具。粘合剂框架内会有一个“MCP Client Skill”专门负责与各类MCP Server通信。4.2 具体实现步骤与代码示意第一步搭建MCP工具层标准化基础设施我们不会为这个项目单独写Git操作函数而是启动一个现成的git-mcp-server。同样启动一个code-search-mcp-server来连接我们的代码仓库索引。# 假设通过npm或cargo安装后运行MCP Server git-mcp-server --repo-path /path/to/our/code code-search-mcp-server --index-path /path/to/index 这些Server启动后会在本地某个端口或通过stdio提供MCP服务宣告它们拥有的“工具”比如git_commit,git_diff,search_code等。第二步在智能体框架中创建“MCP Client Skill”适配层我们在LangGraph中定义一个Skill它的核心是一个MCP客户端。这个Skill的职责是动态发现并连接上述MCP Server。将Server提供的工具转换并注册为框架内部可理解的Skill。当Agent决定执行某个工具时例如“执行Git提交”这个Skill负责将请求转换为MCP协议格式发送给对应的Server并将结果返回。# 伪代码示意 MCP Client Skill 的核心 class MCPClientSkill(Skill): def __init__(self): self.client MCPClient() # 一个MCP协议客户端库 self.client.connect_to_server(http://localhost:8080) # 连接git-mcp-server self.client.connect_to_server(http://localhost:8081) # 连接code-search-server def get_skills(self): skills [] for tool in self.client.list_all_tools(): # 从所有Server获取工具列表 # 将MCP工具描述封装成框架所需的Skill格式 skill Skill( nametool.name, descriptiontool.description, executeself._make_executor(tool) # 执行器会调用MCP协议 ) skills.append(skill) return skills def _make_executor(self, tool): def executor(**kwargs): # 调用MCP Server result self.client.call_tool(tool.name, argumentskwargs) return result.content return executor第三步定义核心Agent Skills业务流程抽象除了工具类Skill我们还需要定义一些更高阶的、负责业务流程的Skill这些Skill内部会调用底层的工具Skill。AnalyzeRequirementSkill: 分析用户需求拆分子任务。它主要与大模型交互通过Function Call可能不需要调用外部工具。ImplementCodeSkill: 实施编码。它内部可能先调用code-search-skill背后是MCP查找类似代码然后调用大模型Function Call生成新代码最后调用file-write-skill可能是另一个MCP工具保存文件。ReviewAndCommitSkill: 审查并提交。调用代码检查工具最后调用git-commit-skill背后是MCP提交更改。第四步配置大模型与Function Call思维驱动在智能体框架中当我们的大模型需要执行某个Skill时比如AnalyzeRequirementSkill框架会将这个Skill的描述、参数格式等信息动态地转换为一次大模型API调用中的Function Call定义。模型在思考后如果决定调用就会输出结构化的调用请求。框架捕获这个请求找到对应的Skill可能是MCP Client Skill封装的也可能是纯业务的并执行。# 伪代码示意框架如何将Skill转化为对LLM的Function Call def step_think(state): # 获取当前所有可用Skills的描述 available_functions [] for skill in all_skills: available_functions.append({ name: skill.name, description: skill.description, parameters: skill.parameters_schema # 转换为OpenAI Function Call格式 }) # 调用LLM传入这些function定义 llm_response openai.chat.completions.create( modelgpt-4, messagesstate.messages, functionsavailable_functions, # 动态注入当前可用的技能作为Function Call function_callauto, ) # ... 解析llm_response执行对应的skill4.3 流程梳理与价值体现在这个架构中MCP提供了标准化、可插拔的工具底座。Git操作、代码搜索等能力被封装成独立的服务不仅本项目能用其他任何支持MCP的AI应用都能用。未来要新增一个Jira操作能力只需要找一个或写一个jira-mcp-server启动即可我们的Agent几乎无需修改代码就能获得新能力。Agent Skills提供了业务逻辑的抽象和编排能力。它将“提交代码”这个业务概念与底层的git commit命令解耦。Skills层负责管理哪些工具在什么情况下可用以及如何将复杂任务如“实现一个登录功能”分解为调用搜索、生成、写入、提交等多个步骤。Function Call是驱动整个智能体思考和执行的具体机制。它是大模型与Skills之间的“翻译官”和“触发器”。模型通过Function Call来表达“我现在要使用那个叫‘搜索代码’的技能参数是‘用户登录’”。这个例子清晰地展示了一个趋势Function Call作为基础的执行机制Agent Skills作为能力的组织和管理范式而MCP则致力于成为连接能力和模型的开放生态标准。在现代AI应用开发中它们常常是协同工作的而不是非此即彼的选择。5. 常见困惑、陷阱与选型指南在实际学习和应用中大家会对这几个概念产生不少困惑也容易踩坑。5.1 典型误区澄清误区一MCP是来取代Function Call的。不对。MCP和Function Call解决的是不同层面的问题。Function Call是模型如何调用一个已定义功能的具体机制。MCP是工具功能如何被描述和发现的协议。一个MCP Server提供的工具最终被AI模型使用时很可能在模型那一侧还是通过一次Function Call请求来触发的。MCP让Function Call里的“函数定义”可以动态地从Server获取而不是写死在代码里。误区二有了MCP就不需要设计Agent Skills了。不完全对。对于简单场景直接让模型使用MCP工具也许足够。但对于复杂AgentSkills这层抽象依然重要。Skills负责的是战略层面的“为什么要用这个工具”、“用了之后下一步做什么”而MCP解决的是战术层面的“这个工具怎么连接和调用”。Skills是智能体的“大脑皮层”负责规划和决策MCP工具是“脊髓和末梢神经”负责执行标准动作。误区三Function Call的性能一定比MCP好。在简单、封闭的场景下是的。因为Function Call是内存内或同进程的调用而MCP通常涉及进程间通信IPC或网络调用HTTP有额外的序列化/反序列化和传输开销。但是MCP带来的动态性、安全隔离和生态价值往往远大于这点性能损耗。对于大多数AI交互场景响应时间在秒级这点开销是可接受的。在需要极致性能且工具固定的场景Function Call仍是优选。5.2 实操中的关键陷阱陷阱一MCP工具描述的模糊性。MCP Server提供的工具描述name, description, parameters的质量直接决定了模型能否正确使用它。描述过于简略模型可能无法理解或错误调用。例如一个“搜索”工具如果描述只是“搜索信息”模型可能用它来搜网页而实际上它是搜本地文件的。最佳实践是像写API文档一样清晰、具体、举例说明工具用途和每个参数的意义。陷阱二忽视Function Call结果的上下文管理。这是一个经典且容易导致对话“死机”的问题。当模型通过Function Call调用工具后工具返回的结果必须被完整、准确地追加到对话上下文中供模型在生成下一步回复时参考。如果遗漏或截断模型就会基于不完整的记忆做出错误判断。在一些流式响应或复杂编排中这个环节容易出错。务必在代码中确认每次工具调用的输出都成为了后续模型输入的一部分。陷阱三Skill爆炸与规划迷失。当你的Agent Skills或MCP工具数量非常多比如几十上百个时一股脑儿全部提供给模型反而会降低模型的规划和调用准确性。模型可能会陷入“选择困难”或者产生幻觉调用不相关的工具。解决方案是分层或动态过滤设计一个“路由器”Skill先根据用户意图判断大类再动态加载该类下的具体工具或者利用Embedding计算工具描述与用户查询的相似度只返回最相关的几个工具。5.3 技术选型决策树面对一个新项目你可以通过回答下面几个问题来做选择你的工具/能力是否需要被多种不同的AI模型或应用使用是- 强烈考虑MCP。标准化一次处处可用。否- 进入下一题。你的应用核心是处理需要多步骤规划、复杂决策的链式或图式任务吗是- 你需要一个Agent框架并采用Agent Skills的思想来设计你的能力模块。然后考虑这些Skill底层用什么实现。否- 你的应用可能更接近一个“增强型聊天机器人”进入下一题。你需要的能力是否简单、固定且数量少10个是- 直接使用模型原生的Function Call是最快、最直接的方案。否- 即使不用MCP你也应该考虑在代码层面对“能力”进行良好的封装和管理这其实就是简单的Skill思想底层调用可以混合使用Function Call和其他API。你是否非常关注工具运行的安全隔离例如工具代码不可信是-MCP的Server-Client隔离架构是天然优势。否- 安全性不是首要决定因素。一个简单的总结公式快速原型/简单功能直接用Function Call。构建复杂自主智能体用Agent框架 Skills抽象。希望能力标准化、可复用、即插即用用MCP。现代复杂生产级Agent应用很可能是三者结合用MCP构建开放工具生态用Skills管理业务能力抽象用Function Call作为模型与Skills间的执行桥梁。6. 未来展望与个人洞见聊了这么多区别其实我们能看到一个清晰的演进脉络从封闭的、点对点的集成Function Call到系统化的内部管理Agent Skills再到开放的、标准化的生态共建MCP。这背后是AI应用从“玩具”到“工具”再到“平台”的必然路径。MCP协议虽然由Anthropic推动但其开源和协议中立的特性让它有潜力成为AI时代的“USB标准”或“驱动模型”。目前Claude Desktop、Cursor、Continue.dev等客户端已原生支持社区也涌现了大量实用的MCP Server。它的挑战在于协议本身的完善度如更复杂的权限控制、流式工具响应等以及生态的进一步繁荣。对于开发者而言我的建议是掌握Function Call这是基本功理解它如何工作是理解一切上层建筑的基础。理解Skill设计模式无论你用不用某个具体的Agent框架学会将能力模块化、描述化、可规划化是构建健壮AI应用的关键思维。密切关注MCP生态即使你现在不直接使用也值得了解。尝试为你的内部工具写一个MCP Server适配器或者在你的项目中试验性地接入一个MCP工具比如文件浏览器感受一下“即插即用”的威力。这很可能代表了未来工具集成的主流方向。最后回到那个面试题。如果被问到一个清晰的回答层次应该是先说明Function Call是模型调用的基础机制再阐述Agent Skills是智能体内部管理能力的架构思想最后点明MCP是连接AI与工具、旨在建立开放生态的通信协议。它们分别作用于执行层、组织层和生态层在复杂的AI应用中可以协同工作共同构成智能体能力扩展的完整图景。