10. MCP 和 Agent Skill 的区别是什么MCP 和 Agent Skill 不是同类概念不是竞争关系而是互补的。MCP 解决的是「Agent 怎么获得外部能力」它把数据库、API、文件系统这些外部工具标准化封装成服务Agent 通过 MCP 就能查数据、调接口、读写文件。Skill 解决的是「Agent 拿到这些能力之后该按什么步骤、什么标准来完成任务」它把完成某类工作的知识和流程打包成可复用的模块。简单记MCP 是给 Agent 配的电脑和软件Skill 是给 Agent 发的操作手册和 SOP。在实际系统里两者经常同时工作Skill 定义流程流程中调用 MCP 提供的工具。从定位说起两者解决的不是同一个问题很多人第一次接触这两个概念会觉得它们都跟「Agent 能做什么」有关但仔细一想会发现两者的目的和工作层次完全不同。MCP 解决的是「Agent 怎么获得外部能力」。没有 MCP 之前Agent 就是一个只会说话的语言模型你让它查数据库它查不了让它读文件它读不了让它调 API 它也调不了。MCP 把这些外部工具标准化封装成独立的服务Agent 连上 MCP Server 就能用这些工具了。所以 MCP 解决的是「从无到有」的问题让 Agent 有能力去操作外部世界。Skill 解决的是另一类问题「Agent 有了这些能力之后该怎么用」。你想Agent 现在能查数据库了、能读文件了、能调 API 了但面对一个「帮我做代码审查」的任务它该先做什么后做什么检查哪些维度用什么格式输出这些「知识和流程」就是 Skill 要提供的。用一个类比就很好理解。MCP 就像给新员工配电脑、装软件、开各种系统权限这些是他「能做事」的前提。但光有电脑和权限是不够的你还得给他一份操作手册告诉他做代码审查的时候先检查什么、后检查什么、用什么标准判断、最后用什么模板写报告。这份操作手册就是 Skill。MCP让 Agent 有「手」理解了两者的定位差异先来展开看看 MCP。为什么说它是 Agent 的「手」因为如果没有 MCPAgent 就只会「说话」不会「做事」。MCP Server 暴露的 Tools、Resources、Prompts 就是 Agent 操作外部世界的手段。模型通过 Function Calling 触发这些工具工具执行完把结果喂回对话。MCP 的粒度是「原子操作」read_file(path)是一个 Toolquery_database(sql)是一个 Tool每次调用做一件明确完整的事执行结果立刻返回。模型能看到每个 Tool 的完整 schema包括它叫什么名字、接受什么参数、返回什么格式。这种精确的可见性正是模型能准确判断「这个问题该调哪个工具」的基础。简单说MCP 让 Agent 从「只会聊天」进化成了「能真正干活」这是一切上层能力的前提。Skill给 Agent 一份「操作手册」有了 MCP 之后Agent 确实能查数据、调 API 了但面对一个复杂任务它怎么知道该按什么顺序用这些工具该关注哪些维度该用什么标准判断质量这就是 Skill 要解决的问题。Agent Skill 是 Anthropic 在 2025 年 10 月推出的概念同年 12 月把规范作为开放标准发布目标是让这套能力模块格式能在不同 Agent 平台之间通用。每个 Skill 是一个文件夹核心是一份 SKILL.md 文件用 YAML frontmatter 声明名字和描述正文写具体的执行指令和步骤。除了指令文件Skill 还可以带上脚本比如一个安全检查的 Python 脚本、参考文档比如团队的审查标准、模板比如报告的输出格式。这些东西打包在一起就构成了一个完整的「操作手册」。Skill 和普通 prompt 最大的区别在于两点。第一Skill 能被 Agent 自动发现。Agent 启动的时候会扫描可用的 Skill 列表当用户提了一个任务Agent 自己判断哪个 Skill 和这个任务相关主动去加载不需要你手动告诉它「用 code-review 这个 Skill」。第二Skill 用了一套「渐进式加载」的机制来节省 context window。启动时只加载每个 Skill 的名字和一句话描述大概每个 Skill 只占 30 到 50 个 token只有当 Agent 判断某个 Skill 和当前任务相关时才会加载完整的指令正文执行过程中需要用到模板或参考文档时才会进一步加载这些资源文件。这样就避免了把所有 Skill 的内容一股脑塞进上下文浪费宝贵的 context window 空间。所以 Skill 的粒度比 MCP 工具粗得多。MCP 的粒度是单个函数调用比如read_file、query_databaseSkill 的粒度是一个完整的工作流程比如「代码审查」「数据分析报告」内部可能涉及好几个步骤、调用好几个工具。两者怎么配合工作看到这里你可能会想既然 MCP 提供工具、Skill 提供流程那它们在实际系统里是怎么配合的咱们用一个代码审查的场景走一遍就清楚了。用户对 Agent 说「帮我审查一下这次提交的代码」。Agent 收到任务后先扫描自己可用的 Skill 列表发现有一个叫 code-review 的 Skill 和这个任务匹配度很高。于是 Agent 加载它的 SKILL.md 正文读取里面的执行流程。这份 SKILL.md 长这个样子--- name: code-review description: 对代码进行全面审查识别 bug、安全漏洞和性能问题 --- # 代码审查 ## 第一步读取待审查的代码文件 读取用户指定的代码文件理解功能和修改范围。 ## 第二步执行安全检查 运行 scripts/check_security.py 对代码做自动化安全扫描。 ## 第三步输出审查报告 使用 assets/report_template.md 的模板格式输出结构化审查报告。你看SKILL.md 的作用就是告诉 Agent「做什么、按什么顺序做」它就是一份操作手册。但 Skill 只定义了流程真正「动手」的时候还是得靠 MCP。Agent 执行第一步「读取代码文件」需要调用文件系统 MCP Server 提供的工具# Skill 第一步说读取待审查的代码文件 # Agent 发现 MCP 有 read_file 工具于是调用它 code mcp_client.call_tool(read_file, { path: src/auth.py # 要审查的文件路径 })执行第二步「安全检查」时Agent 加载 Skill 自带的脚本scripts/check_security.py并执行。这就是 Skill 比普通 prompt 强的地方它不只有文字指令还能带可执行的脚本。执行第三步「输出报告」时Agent 加载 Skill 的assets/report_template.md模板按照里面定义的格式把审查结果整理成结构化报告返回给用户。整个流程的分工非常清晰Skill 扮演「编排者」定义了做什么、按什么顺序做、用什么标准做MCP 扮演「执行者」提供了每一步需要调用的具体工具。两者配合起来Agent 才能既知道「该怎么做」又有能力「真正去做」。再看一个稍复杂的场景你就能感觉到这种分工的威力。假设 Skill 定义的流程里有一步「如果改动涉及数据库表结构额外执行权限合规检查」这就是条件分支。Agent 读到这条指令时会先调用一个 MCP Tool 去扫描这次提交有没有改数据库 schema拿到结果布尔值之后再决定要不要走那条分支如果要走就再调另一个 MCP Tool比如query_permission_policy去查合规规则最后根据结果决定审查报告里是否要加一条严重级警告。整个过程里Skill 就像项目经理拿着流程图和判断标准指挥执行MCP 提供的每个 Tool 就像专业工人各自只管做好一件小事。缺了 SkillAgent 拿着一堆工具不知道该什么时候用缺了 MCPSkill 再详细的流程也只是纸上谈兵。面试回答这道题第一个必须说清楚的是两者的定位差异MCP 提供工具和数据的访问能力解决的是「Agent 怎么做事」Skill 提供完成任务的知识和流程解决的是「Agent 该怎么做事」。一个是能力一个是知识。第二个关键点是粒度差异。MCP 的粒度是原子操作每次调用做一件明确的事schema 对模型完全可见Skill 的粒度是工作流程定义的是完成某类任务的完整步骤和标准还可以附带脚本、模板等资源通过渐进式加载按需使用。第三个加分点是讲清楚两者的配合方式。Skill 编排流程MCP 提供工具Skill 指令里经常会调用 MCP 的工具来完成具体操作。如果能用代码审查这样的完整场景把两者的配合串起来面试官能看出你不只是背了概念而是真正理解了它们在系统里怎么协作的。11. Function Calling、Skill、MCP 这三个有什么区别Function Calling 是最底层的调用协议解决的是「模型怎么调函数」模型输出结构化 JSON 告诉程序该调哪个函数、传什么参数。MCP 在 Function Calling 之上做工具标准化解决的是「工具怎么暴露给模型」把数据库、API 这些外部能力封装成标准化服务一次实现到处复用。Agent Skill 在最上层做知识和流程的封装解决的是「拿到工具之后按什么流程完成任务」把执行步骤、标准、脚本、模板打包成可复用模块。简单记就是Function Calling 是语言MCP 是工具箱Skill 是操作手册。为什么会有三个概念这三个概念放在一起确实很容易让人迷惑但其实它们各自解决的是完全不同层次的问题是三层架构不是三个竞争方案。怎么理解呢咱们先建立一个直觉感受Function Calling 是「模型说我要调这个函数」MCP 是「工具服务说我能提供这些函数」Skill 是「操作手册说用这些工具按这个流程做」。你看三句话的主语不一样说话对象不一样粒度也不一样这就是三者的本质差异。再从时间线来看就更清楚了。Function Calling 是最先出现的当时的核心问题是「模型只会生成文本怎么让它能触发外部调用」所以 Function Calling 解决的是最基础的调用协议问题。后来 Function Calling 普及了大家发现一个新的痛点每个应用都要自己写代码对接各种工具数据库一套、文件系统一套、API 又一套重复劳动太多了。MCP 就是在这个背景下出现的它把工具的接入标准化了一次实现到处复用。再后来工具有了、接入也标准化了又冒出了新问题Agent 有了一堆工具但面对一个复杂任务它不知道该按什么流程、什么标准来用这些工具。Skill 就是为了解决这个「知识和流程复用」的问题才诞生的。三者的出现背景不同自然解决的是不同层次的东西。从「谁和谁通信」来看三者位置理解三者最清晰的切入点是每个机制发生在哪两个角色之间。Function Calling发生在模型和函数之间是单次调用的格式规范。模型生成tool_callsJSON 告诉宿主程序「调这个函数、参数是这个」宿主程序执行完把结果以 tool 消息形式喂回去。这一切发生在单个 Agent 内部是最底层的「调用语言」整个系统靠这个让模型触发实际动作。理解了 Function Calling 是最底层的通信语言往上一层就是MCP。它发生在 AI 客户端MCP Client和工具服务MCP Server之间是工具的标准化封装协议。Client 连上 Server 后自动发现工具列表把工具定义转换成 Function Calling 格式喂给模型。所以 MCP 本质上是对 Function Calling 的封装和管理它让工具从「应用内的代码片段」变成「独立的标准化服务」一次实现到处复用。再往上一层就到了Skill它发生在 Agent 和知识模块之间。Agent 启动的时候会扫描可用的 Skill 列表当用户提了一个任务Agent 自己判断哪个 Skill 和这个任务相关主动去加载 SKILL.md 里的执行指令、脚本和模板。Skill 的粒度比 MCP 工具粗得多「代码审查」是一个 Skill「数据分析报告」是一个 Skill每个 Skill 内部可能涉及好几个步骤、调用好几个 MCP 工具。三者的层级依赖关系搞清楚了三者各自的位置接下来一个很自然的问题是它们之间有没有上下级关系答案是有的而且层级非常明确。为什么 Function Calling 在最底层因为它是模型触发工具调用的「语言」没有这套语言模型就没办法告诉外部「我要调哪个函数、传什么参数」一切上层能力都无从谈起。MCP 为什么在它之上因为 MCP 做的是工具管理和标准化封装但归根到底MCP Server 暴露的工具最终还是要通过 Function Calling 的格式传给模型、让模型来触发所以 MCP 天然依赖 Function Calling。那 Skill 为什么在最上面因为 Skill 定义的是使用工具完成任务的流程和标准Agent 按照 Skill 里的指令去执行每一步需要调工具的时候还是得靠 MCP 发现工具、靠 Function Calling 触发调用。所以完整的链条是Skill定义流程- MCP提供工具- Function Calling模型触发调用从上到下三层每一层都建立在下一层的基础之上各司其职。用一个完整故事串联三者把三者放在同一个场景里感受一下各层分工。用户对 Agent 说「帮我分析最近三个月的销售数据找出下滑的产品线给改进建议」。首先是Skill 层在起作用。Agent 收到任务后扫描自己可用的 Skill 列表发现有一个叫「数据分析报告」的 Skill 和这个任务高度匹配。于是 Agent 加载这个 Skill 的 SKILL.md 正文读取里面定义的分析流程第一步从数据库取数据第二步用 Python 做趋势分析第三步按模板写分析报告。Skill 就像一份菜谱把整个任务的步骤和标准安排得明明白白。然后是MCP 层在起作用。执行第一步「从数据库取数据」的时候Agent 的 MCP Client 已经连着数据库 MCP Server 和 Python 执行器 MCP Server自动知道有query_database和run_python这些工具可用。MCP 就像厨房里面的厨具和食材随时可以取用不需要任何手动配置。最底层是Function Calling在起作用。模型判断需要查数据库输出tool_calls: query_database(sqlSELECT product, revenue FROM sales WHERE date 2026-01-01)MCP Client 把这个请求路由到数据库 Server 执行拿到结果后模型继续处理。接着模型输出调用 Python 执行器的 Function Calling对数据做趋势分析。最后 Agent 按 Skill 里定义的报告模板把结果整理成结构化的分析报告返回给用户。整个流程里 Skill 做流程编排、MCP 做工具管理、Function Calling 做模型和工具的通信三层分工明确缺哪层都不完整。12. 什么是 A2A 协议它和 MCP 协议的区别是什么A2A 是 Google 发布的开放协议专门解决多个 AI Agent 之间怎么互相通信协作的问题。我理解它和 MCP 的区别是这样的MCP 解决的是「单个 Agent 怎么连工具和数据」A2A 解决的是「多个 Agent 之间怎么分工协作」。一个 Agent 通过 A2A 可以把子任务委托给另一个专业 Agent接收方按自己的 Skill 声明承接支持异步长任务和流式推送结果。两者是互补的不冲突MCP 向下连工具A2A 向上连 Agent在复杂的多 Agent 系统里这两个通常都要用到。为什么单个 Agent 不够用上下文和专业边界要理解 A2A 是干什么的得先把「单 Agent 的天花板」搞清楚。一个 Agent 的本质是一个 LLM 一组工具 一段上下文窗口。这三个维度都有自己的天花板。首先是工具数量的限制你不可能给一个 Agent 装 100 个工具模型处理起来效率极低容易混乱。其次是上下文窗口的限制128K tokens 听起来很多但复杂任务积累的中间产物搜索结果、草稿、反思记录会很快把窗口塞满后面的生成根本顾不上前面写了什么。最后是专业能力的限制同一个 Agent 既做代码审查又做市场分析不如专门为各自任务配置或微调的 Agent 效果好。举一个具体任务「帮我做一份 AI 编程工具的竞品分析报告要有行业趋势、技术对比、商业模式分析和 SWOT」。让单个 Agent 做这件事问题是搜索结果和草稿会把上下文撑满等到写 SWOT 时前面的行业趋势分析早就被挤出了有效注意力范围而且市场调研和技术分析需要不同的知识侧重一个 Agent 很难全面兼顾。你可能会问拆成多个 Agent 协作上下文压力就真的变小了吗关键就在这里调度 Agent 把「做行业趋势分析」委托给市场 Agent市场 Agent 自己去搜几十个网页、写草稿、反复迭代这些中间过程都在它自己的上下文里。任务做完它只把最终结论比如一份几百字的摘要通过 A2A 返回给调度 Agent。调度 Agent 的上下文里只多了一份摘要而不是几十个网页的原文。这就把「调研过程」的上下文压力隔离在了市场 Agent 内部调度 Agent 保持轻量这是多 Agent 协作在上下文层面的核心收益。解决方案很自然把任务拆开交给不同的专业 Agent 并行处理最后汇总。一个「调度 Agent」负责任务拆分「市场分析 Agent」专门做趋势调研「技术研究 Agent」专门做工具对比每个只需聚焦自己擅长的部分整体效果远好于一个 Agent 包揽所有。多 Agent 的基础问题Agent 之间怎么互相认识多 Agent 系统有一个绕不开的基础问题Agent A 要把任务委托给 Agent B它得先知道 B 能做什么。但怎么知道呢最笨的方案是写死配置A 的代码里硬编码「B 可以做竞品分析」。这样太脆了B 的能力一变A 的代码就得改根本没法维护。更好的方案是让 B 主动「发名片」声明自己能做什么A 来查。这就是 A2A 里Agent Card的设计思路。每个 A2A Agent 都在一个约定位置发布一张 JSON 格式的名片A2A 规范推荐的路径是/.well-known/agent-card.json早期版本叫agent.json两种路径在社区里都能看到里面写清楚自己叫什么、能做哪类任务Skill 列表、支不支持流式返回、支不支持异步回调push notification任务完成后主动通知调用方。任何想和它协作的 Agent先去拿这张名片再决定要不要把任务委托给它。Agent Card 里最关键的是Skill 列表每个 Skill 描述一类能力比如「竞品分析」「行业趋势分析」并带有示例输入。调度 Agent 用这些 Skill 描述来做任务路由决策「这个任务和哪个 Agent 的哪个 Skill 最匹配」。这套机制让整个多 Agent 系统变得可插拔新加一个 Agent发布它的 Agent Card调度 Agent 就能自动发现和利用它完全不需要改调度 Agent 的代码。TaskA2A 里的一等公民A2A 里任务协作的基本单位是Task。调度 Agent 把一段任务委托给另一个 Agent就是创建一个 Task接收方执行这个 Task完成后把结果作为 Task 的产出artifacts可以是文本、文件等返回。Task 有完整的生命周期状态管理。一个 Task 刚被创建时是 submitted 状态表示已提交、等待处理。接收方开始执行后变为 working 状态最终根据执行结果进入 completed成功或 failed失败状态。为什么需要这么完整的状态机因为 A2A 专门为长时间任务设计。一个「竞品分析」任务可能要跑几分钟先搜索、再整理、再写报告不可能让调度 Agent 同步等着。所以调度 Agent 提交任务后可以去处理其他事情通过轮询状态或者 push notification任务完成时接收方主动回调通知来得知任务完成了。这套状态管理机制正是为了支持这种异步长任务协作的。调度 Agent 的视角很干净给 Agent B 提交一个 Task定期查一下状态等到completed了去取 artifacts。整个过程不需要知道 B 内部用了什么工具、调了几次 LLM完全黑盒。每个专业 Agent 自己的实现对外不可见这正是解耦的意义所在。A2A 的架构本质Agent 的微服务化如果你有后端开发经验A2A 其实不陌生它就是 Agent 世界里的微服务架构。在微服务架构里每个服务是独立部署的 HTTP 服务有自己的 API 文档服务之间通过 HTTP 互相调用支持异步消息队列处理耗时任务。A2A 的设计几乎照搬了这套思路只不过把「服务」换成了「Agent」。怎么理解这个对应关系呢Agent Card 就像 API 文档告诉别人「我能做什么、怎么调用我」。Task 状态机就像异步消息队列支持提交任务后去做别的事、完成了再来取结果。而.well-known下的 Agent Card 就像微服务注册中心里的一条记录让其他 Agent 能自动发现你。所以每个 A2A Agent 对外其实就是一个 HTTP 服务任何支持 A2A 的系统都可以发现它、向它发任务、接收结果不绑定特定的 AI 框架也不依赖特定的编程语言。这个设计理念和 MCP 是一脉相承的MCP 让工具成为独立标准化服务A2A 让 Agent 成为独立标准化服务。A2A 和 MCP 的关系一纵一横各管一层理清两者关系最简单的方式是看方向MCP 是 Agent 向下连工具A2A 是 Agent 向外连其他 Agent。具体来说一个专业 Agent 内部用 MCP 连各种工具比如数据库、浏览器、代码执行器用 Function Calling 让 LLM 触发这些工具调用这是「纵向」的连接。而多个 Agent 之间需要分工协作的时候就用 A2A 来互相通信、委派任务、接收结果这是「横向」的连接。两个协议解决的是完全不同维度的问题不存在谁替代谁。打个比方MCP 就像公司里每个员工的「工具箱」决定了这个人能用什么工具干活。A2A 就像公司里的「协作流程」决定了不同岗位的人怎么分工、怎么交接任务。工具箱和协作流程是两回事缺了哪个都不行。在一个复杂的多 Agent 系统里这两者通常同时在用MCP 负责每个 Agent 和工具之间的纵向连接A2A 负责 Agent 之间的横向协作通信。两层协议各管一个维度合在一起才能支撑起真正复杂的 Agent 系统。