Agent Mcpskill等等这些是什么在如今的2026年相信大家面对ai圈的各种概念和知识有些会模糊不清下面我就结合我在别人的博客上学习到的以及自己的一些理解吧 下面从小林coding的笔记中给大家带来讲解小林coding编程导航LLM 和 Agent有什么区别?Agent 和workflow有什么区别?function call是什么?mcp是协议什么?skills是什么?function call、mcp、skills有什么区别?什么是A2A协议?说一下这些年我对ai的感受我是23年高考的当年语文老师还说高考很有可能会考ai相关的让我们了解一下不过最后还是没考留到了第二年24届去考了。然后在大一上学期的时候ai其实还没有进入到我的生活当时用搜题目以及问东西都还是大学搜题酱和百度等等但是到了下学期我当时就发现了一款ai软件发现很好用当时还叫海螺ai现在好像已经改名字了到如今我才发现原来之前用的海螺就是minimax家的我还以为i已经退出市场了。然后到了24后半年ai开始爆发开始逐渐走进大众视野开始知道豆包、通义、kimi等等这些然后ai就开始逐渐改变大家生活了。说一下我身边最明显的变化就是以前老师布置的作业可能需要去搜一下或者抄同学的但是现在人手都用豆包水一下只要一涉及到什么作业或者问题第一想法就是用豆包可见现在ai的使用深入人心。接着ai就如同脱缰的野马一般进化飞快什么都能做了pptword等文档生成视频以及各种事情也都能做了这也就不得不提出今天要说的agent了 这也是agent和ai之间的区别之一。随之而来的也是面对ai冲击下的就业市场的恐慌毕竟ai这么强效率也高性价比远远大于人类。我也时常感到恐慌面对无所不能的ai未来该何去何从感觉学什么好像都不如问一下ai直接出答案来的快感觉好像做什么再也没有之前的成就感了因为什么都可以让ai来做了有一种面向自然语言编程的感觉了。但是这样让我意识到必须要顺应时代当今时代就是要学会使用ai和了解其原理我们每一个小个体都不可能改变时代发展真所谓顺时代者昌逆时代者亡所以必须要更上时代学会接受变化。就好比一百多年前慈禧还说外国的奔驰跑的不如他们的马车所以你看现在呢走在路上有人骑马 以前的马夫也许早改行做司机了所以你问我会骑马吗我会回答我不会因为我不需要骑马作为代步工具了而是需要会开车的司机。所以每一个时代的科技都革命人们的生活方式。所以在ai时代的冲击未来会怎么样其实我也无法精准预测但是我们要做到的就是能够紧跟时代保持持续学习的状态和接收变化就好比当年的马夫和人力车夫早已经改行去当司机去了出租车司机因为网约车改行去跑线上或者去跑货车了。下面切入正题让我们来看看agent相关的知识吧。下面的知识是我从小林coding和鱼皮那学习到的以及自己的一些个人鄙见。LLM 和 Agent有什么区别?什么是LLM其实这个llm就是large language model 的缩写 也就是大语言模式是所有ai的大脑就好比人的大脑一样可以做出思考和推断具有自我意识还会学习知识不过这里的学习需要去训练模型但是他也能具备感知外部环境的能力你可以把它想象成一个读了互联网上几乎所有文字的超级学霸。它通过学习海量的文本数据掌握了人类语言的各种规律和知识。我们平时用的ChatGPT、Claude、DeepSeek、文心一言底层都是大语言模型。这里引用xiaolin的图解就是LLM的工作原理说白了就是「预测下一个字」。你给它一段话它会根据学到的语言规律一个字一个字地往后接。听起来简单但因为它学的数据量实在太大了这种「接龙」的效果好到令人吃惊它能写文章、写代码、做翻译、回答各种专业问题。所以平时输入的prompt提示词本质就是在提高他预测词的精准度因为经常训练今天天气真好明天是晴天后天是雨天等等这些内容所以你问他今天怎么样他能通过训练的数据掌握这里面的回答规律从而预测下一个字的回答LLM有什么弊端虽然这个大脑LLM非常聪明但是你要想如果只聪明但是不能做不了事那不也就是只会说不会做了就像那种只说不做假大空一样。说不好听点只要LLM就像人彘一样只有思想和想法但是做不了事想要做事必须得要有手脚光有大脑是不够的第一个弊端是只会「说」不会「做」。你让LLM「帮我订一张机票」它会详细告诉你怎么订但它真没法替你去携程下单。你让它「帮我把这个Bug修了」它能给你改好的代码但它没法自己打开编辑器去改文件、跑测试。说白了LLM的能力被困在对话框里了它没法跟外部世界互动没法操作任何系统。第二个弊端是没有「记忆」。你跟ChatGPT聊了一下午聊了很多你的个人情况和项目背景。结果第二天开一个新对话它完全不记得你是谁了。因为LLM的记忆只限于当前这轮对话的上下文窗口对话一结束一切归零。第三个弊端是不会用「工具」。你问LLM今天上海天气怎么样它只能根据训练数据里的旧知识来猜而不是像你一样打开天气App查实时数据。LLM本身不能上网搜索、不能查数据库、不能调API所有回答都来自它「脑子里」已有的知识而这些知识不仅有截止日期还可能是错的也就是常说的「幻觉」问题。第四个弊端是不会「规划」。如果你给LLM一个复杂任务比如「帮我做一份竞品分析报告」它只能一次性生成一大段文字。它不会像人一样先想想应该先搜集哪些信息、分析哪些维度、用什么框架来组织然后一步一步去执行。LLM是「被动响应型」的你问一句它答一句没法自主拆解任务、制定计划、分步执行。什么是agent其实说白了agent就是给LLM装上手脚以及记忆等等一些工具简单来说Agent 就是 LLM 在循环中自主使用工具的系统这个里面的循环持续思考我感觉其实就是从2024年deepseek开始的当时我记得你问他问题他就会一直不断的去思考然后观察然后再思考这样去loop导致每一个一个问题他要思考很久而且当时访问还有限制因为访问人太多了图里有三个关键词「LLM」说明Agent的核心大脑还是大模型「工具」说明它能调用外部能力「循环」说明它不是一问一答就结束而是会不断地思考、行动、观察结果、再思考直到任务完成。打个比方如果LLM是一个只会给你建议的顾问你问他「怎么装修房子」他能讲一大堆方案但绝不会亲自动手。这里的流程就是LLM-TOOL-ACT-OBSERVE-LLM-TOOL…那Agent就是一个能动手干活的项目经理你说「帮我把房子装修好」他会自己去找装修队、买材料、盯进度、解决问题直到装修完成。所以从LLM到agent 它解决了什么问题呢其实就是针对只会说不会做Agent引I入了工具调用能力可以调用搜索引擎、数据库、API、代码执行器等各种外部工具来真正执行操作。针对“没有记忆”Agent配备了记忆系统包括记住当前任务上下文的短期记忆和存储在外部数据库中、可以跨对话保留的长期记忆。针对”不会用工具”业界推出了MCP等标准化协议来统一工具接入方式后面会详细讲。针对”不会规划”Agent具备了任务拆解和规划能力能把一个大目标分解成多个小步骤然后逐步执行。Agent的核心组成第一个是大脑也就是LLM负责理解意图、推理判断、决定下一步行动。第二个是规划模块负责把复杂任务拆解成可执行的步骤。第三个是记忆模块负责存储和检索信息让Agent能在长时间任务中保持连贯。第四个是工具模块是Agent的「手和脚」让它能跟外部世界互动。这样的话LLM就从只会说以及什么也没有的状态进化成了有各种能力的agent智能体。Agent和workflow有什么区别搞懂了 LLM 和 Agent 的区别之后你可能还会碰到另一个容易搞混的概念Workflow工作流很多人把 Agent 和 Workflow 混为一谈但它们的设计理念其实完全不同其实这个概念的区别可以用一个场景来区别就好比你去做饭你妈妈做饭可能做了十几年做一个菜的步骤可能都已经刻在DNA里面了比如辣椒炒肉1.先煸炒辣椒2.辣椒炒好先放出来然后再放肉3.最后混合在一起炒放入多少盐比较合适等等这个就是workflow工作流也就是每一步都按照设定好的流程去做到了你去做随机性可能就比较大了因为你不会做所以你可能回去dy上面去搜教程然后不同的人做法也不一样所以就看谁怎么做的你就按照他的来比如1.先把肉腌好辣椒都切好2.先炒肉在这个时候就加调味料之类的3.然后再加入辣椒4.然后加水焖一下…你下次可能又忘了上一次的怎么来的了所以做法又不一样了然后就带有自主性的加入了自己的想法以及看了另外一个博主教的视频步骤和上次又不一样了而agent就像你做饭一样思考行动然后感觉好像不对发现盐放多了那就多加水然后发现水放多了只能多煮一会了哈哈哈就是一直这样来回的loop声明本人不是很会做饭上诉步骤纯属瞎编Workflow 是指 LLM 和工具通过预定义的代码路径进行编排的系统而Agent 是指 LLM 动态主导自身流程与工具调用的系统由 LLM 自主决定如何完成任务。说人话就是一个是流水线标准都已经定好了流程也是定好的就是按照既定的方案去实现但是agent是你让它做一件事它自己去分析然后行动然后看效果然后再来思考反馈然再重复核心区别在哪就是看谁在掌控流程workflow就是你自己agent就是llm自己去决策回到做饭就是workflow就是经验agent就是新兵蛋子啥也不会只能摸着石头过河什么时候用 Workflow什么时候用 AgentAnthropic给了一个非常实用的建议从最简单的方案开始只在明确需要时才增加复杂度。如果任务步骤是固定的、可以提前规划好的或者对可靠性要求很高比如金融交易、医疗系统那就用Workflow。如果任务是开放式的、无法预知所有步骤或者需要灵活应对各种意外情况那就用Agent。不过在实际生产环境中最常见的其实是混合架构Workflow和Agent 的结合。正如LangChain说的“大多数生产中的Agent系统其实是Workflow和Agent的组合。”用做饭的例子说人话就是有些事情按照经验步骤来就可以了因为已经经过你这么多年吃妈妈饭的口味检验了有些可以自主规划一下比如最近上火了就少加点辣椒。晚上吃饭的客人不喜欢吃香菜和葱菜里面就不放适度调整。而不是完全一股脑用之前的死板做法也就是workflow。agent就是带有自己思考当然程序员使用workflow和agent的场景和做饭不一样他们的眼中的workflow是自己写代码把流程业务规划好而agent就是开放式的不可确定的需要灵活应对各种情况比如一个智能客服系统整体流程用Workflow控制接收工单→分类→处理一回复但在”处理”环节遇到复杂问题时会启动一个Agent来自主分析和解决。所以不要把两者对立起来它们更像是工具箱里的锤子和螺丝刀不是竞争关系而是配合关系。Agent有什么工作模式了解了Agent是什么之后下一个问题就是Agent到底是怎么「干活」的就像人干活有不同的方式有人喜欢边做边想有人喜欢先列计划再动手有人喜欢团队协作Agent干活也有不同的工作模式。1.ReAct模式(边想边做)ReAct 是目前最经典、最基础的 Agent 工作模式名字来源于 Reasoning Acting 的缩写也就是「推理 行动」。几乎所有主流的 Agent 框架底层都在用它。这个模式的本质就是循环交替思考think-行动act-观察observe它的核心思想非常简单Agent在思考和行动之间不断交替。具体来说就是一个三步循环先是思考Thought分析当前情况决定下一步做什么然后是行动Action调用一个工具来执行接着是观察Observation查看工具返回的结果。然后回到思考如此循环直到任务完成。打个生活化的比方。想象你要收拾行李准备出差你会先想「我要去上海三天先看看天气怎么样」然后打开手机查天气预报发现会下雨气温15-20°C接着想「得带伞和外套」于是去找出来放进行李箱再想「还得确认酒店」打开App检查预订信息.这就是ReAct的精髓每一步都先想后做做完看结果再决定下一步。ReAct的优点是透明可审计每一步思考过程都看得见、灵活适应遇到意外能随时调整、通用性强。但它的缺点也很明显token消耗大因为每一步都要完整推理一次有时会陷入循环反复执行相同动作走不出来。2.Plan-and-Execute先想好再做)如果说ReAct是「边想边做」Plan-and-Execute就是「先想好再做」。它把Agent的工作分成两个阶段第一阶段是规划Agent先把完整的执行计划想清楚第二阶段是执行按计划逐步完成不用每步都重新思考全局。用出差的例子来对比ReAct是「查天气→想想带什么→找衣服一想想还缺什么一查酒店一想想还要准备什么.」每一步都重新审视全局。而Plan-and-Execute是先列一个清单查天气、准备衣物、确认酒店、准备证件、叫车然后逐项打勾执行。这种模式最大的优势是省钱。规划只做一次执行阶段不用反复推理token消耗大约是ReAct的五分之一。但缺点是不够灵活如果执行到第3步发现情况变了原来的计划可能就不适用了。所以也有这么个做法是在执行过程中加入「重新规划检查点」每隔几步检查一下计划是否还靠谱。3.Reflection(做完再检查)反思模式的核心思想是 Agent 完成任务后不急着交付而是先自我检查一遍就像你写完文章不会直接发出去而是再通读一遍、改一改、润色一下。实现方式通常有两种。一种是自我反思同一个Agent完成任务后切换到「审查者」角色来审视自己的输出发现问题就修改然后再审查直到满意。另一种是双Agent对话一个Agent负责生成另一个负责评审两者来回迭代直到评审方满意就像代码的CodeReview过程。这种模式特别适合对质量要求高的场景比如代码生成、法律文书、学术论文等。4.Multi-Agent团队协作当任务太复杂、一个Agent 搞不定的时候怎么办答案是派一个团队上。Multi-Agent模式让多个专业化的Agent各司其职比如一个负责规划、一个负责搜集信息、一个负责写代码、一个负责测试通过协作来完成复杂任务。这个就像大家去参加项目一样有人负责制作ppt有的人负责写文字有的人负责答辩让不同的人在自己擅长的领域去做贡献目前主流的多Agent框架包括 LangGraph、CrewAI、OpenAl Agents SDK 和微软的 AutoGen等。不过Anthropic提醒过不要过早引l入多Agent架构。很多时候一个强大的单Agent就够用了。只有任务确实需要拆分成多个并行子任务时多Agent才值得引入。最后总结一下这几种模式不是互斥的实际中往往是组合使用的。一个多Agent系统中每个Agent内部可能用的是ReAct模式整体协作用的是Multi-Agent模式最后还有一个Reflection环节来检查质量。选择哪种模式关键看你的任务特点和对灵活性、成本、质量的优先级排序。function call是什么前面说了ai到agent的进化有工具调用有了工具调用ai就是查询天气获取各种信息甚至操作数据库那这些是怎么实现的呢其实就是function call[从「只会说话」到「能做事情」]以前的ai都是和聊天机器人似的一问一答基本就是你问他什么 他回答你也帮你干不了什么事情甚至很多数据都是它自己凭空捏造的但是FunctionCall的出现彻底改变了这个局面。它是OpenAl在2023年6月率先推出的一种能力简单来说就是让LLM不仅能生成文字还能告诉外部程序「我想调用某个函数参数是这些」。打个比方。在没有FunctionCall之前LLM就像一个只能写字的人你问他天气他只能根据记忆回答「上海通常三月份比较潮湿」。有了FunctionCall之后这个人学会了「打电话」你问他天气他会拿起电话拨给天气台调用天气API)听到对方报的实时数据后再告诉你「今天上海22°C多云」。fc工作原理Function Call 的工作流程分四步。图中的流程大致就是prompt-llm-if tool -response第一步定义函数。开发者预先告诉LLM「你手边有哪些工具可以用」用JSON格式描述每个函数的名字、功能说明和参数。比如你告诉它有一个get_weather函数接收一个城市名参数返回天气信息。{tools:[{type:function,function:{name:get_weather,description:获取指定城市的实时天气,parameters:{type:object,properties:{city:{type:string,description:城市名称比如上海}},required:[city]}}}]}第二步模型判断。用户提问后LLM分析用户的意图自己判断「要回答这个问题我需要调用哪个函数」。如果用户问「上海今天天气如何」LLM会决定调用get_weather并生成参数{“city”“上海”}{tool_calls:[{type:function,function:{name:get_weather,arguments:{\city\: \上海\}}}]}第三步执行函数。注意这一步非常关键LLM自己并不执行函数。它只是输出了「我想调用这个函数参数是这些」的结构化指令。真正执行函数的是你的应用程序。你的代码拿到LLM返回的调用指令后解析出去实际调用天气API拿到结果比如22度多云第四步生成回答。你的代码把拿到的真实温度数据再次发给LLM。LLM这次有了客观数据支撑就会用非常自然的人类语言回复你今天上海天气是多云气温大约22摄氏度。为什么fc这么重要你可能会觉得这不就是「让LLM调API」吗有什么了不起的关键在于FunctionCall解决了两个核心问题。第一个是**什么时候调用“的判断问题**LLM能根据用户的自然语言意图自动判断需不需要调用工具、调用哪个工具。你不需要写复杂的条件判断逻辑LLM自己会推理。第二个是**“传什么参数“的提取问题**LLM能从用户的自然语言中提取出结构化的参数。用户说“帮我查一下北京后天的天气”LLM能自动提取出city北京和date后天。这两个能力加在一起就把LLM从一个「只会聊天的文本生成器」变成了一个「能理解意图并驱动外部系统的决策引擎」。而这正是Agent 的基石。可以说FunctionCall就是Agent能力的最底层技术基础没有FunctionCallAgent就无法调用工具也就没法真正「做事」。目前几乎所有主流大模型都支持FunctionCall包括OpenAI的GPT系列、Anthropic的Claude系列、Google的Gemini系列以及各种开源模型如Llama等。虽然各家的API格式略有不同但核心原理是一样的。fc和agent的关系fc就是工具调用嘛但是llm只能决定一次的工具调用它没有反馈机制所以导致可能一次并不成功但它也没有异常处理。但是agent它会循环执行工具调用如果发现不对就会收到反馈信息来纠正MCP协议是什么前面讲了 Function Call 让 LLM 能调用工具。但随着 Agent 越来越强大需要连接的工具和服务越来越多一个新问题浮出水面了集成太麻烦了。Function Call 的集成困境很明显的问题就是各家agent的调用不同的tool的格式一样 导致很多格式不兼容比如你要agent能够访问github上的仓库还能打开web页面等等这样就需要写不同的工具的适配性有多个agent还需要n多个为了解决这个问题Anthropic在2024年11月开源了MCP(Model Context Protocol模型上下文协议。你可以把MCP理解为**「AI界的USB-C接口」**。这里引用鱼皮说的一个有标准的东西形成之后才会有生态 标准-生态所以就由此诞生了MCP这个就相当于定义了调用工具的格式协议就像以前小时候手机有很多我小时候用过酷派手机以及其他的不知名的手机如果他们充电用的都是不同的插口那怎么办比如oppo用不了vivo的小米的用不了oppo的这样的话就会存在很多问题所以为了统一标准慢慢的都演变成了typeC口了 包括苹果现在好像也有tc口。所以这就是标准的形成MCP整个流程就是用户在AI应用中提问→AI应用Host通过MCPClient发现有哪些可用工具→AI决定调用某个工具→MCPClient向对应的MCPServer发送请求→Server执行操作返回结果→AI基于结果生成回答。MCP解决了什么问题最核心的就是把N×M的集成问题变成了NM的问题。以前每个AI应用要跟每个服务单独对接现在每个AI应用只要支持MCP协议实现一次Client每个服务只要提供一个MCPServer实现一次Server双方就能自动对接。新增一个服务不需要改任何AI应用的代码新增一个AI应用也不需要改任何服务的代码。而且MCPServer暴露的工具是可发现的AI应用启动时能自动查询有哪些MCPServer可用、每个Server提供哪些工具、每个工具的参数是什么。这意味着Agent可以在运行时动态发现新的能力而不是只能用开发者写死的那些函数。Skills是什么Skills是一种自然语言指令文件通常是Markdown格式用来教Agent在什么场景下、按照什么方法、遵循什么规范来完成特定任务”。在Claude Code、Cursor等AI工具中Skills通常以sKILL.md文件的形式存在。Skills的结构很简单顶部有一段YAML格式的元数据声明这个Skill什么时候应该被激活比如”当用户要求代码审查时下面是具体的行为指令用自然语言写成。eg--- name: Code_Review_Expert description: 当用户要求进行代码审查时自动触发此技能。 triggers: - 帮我 review 一下这段代码 - 代码审查 --- # 身份设定 你是一个拥有 10 年开发经验的资深后端架构师你极其看重代码的可读性、性能和安全性。 # 审查工作流 当你进行代码审查时你必须严格按照以下步骤进行排查 1. 看结构检查代码是否符合单一职责原则有没有超过 100 行的超长方法。 2. 查漏洞重点检查是否存在 SQL 注入风险、越权访问风险或空指针异常风险。 3. 审性能是否有在 for 循环里查数据库的愚蠢操作是否有流对象没有及时 close 释放 4. 给方案你绝对不能只挑毛病必须针对每个问题给出具体的修改建议并且附带优化后的代码片段。 # 输出规范 语气要专业、极其直接不要说废话。直接输出一份 Markdown 格式的审查报告分点列出问题和修改方案。打个更直观的比方如果说McP给了Agent一个装满工具的厨房有刀、有锅、有烤箱、有各种调料。那Skills就是一本菜谱告诉Agent做红烧肉要先焯水再炒糖色加水炖40分钟火候要先大后小”。厨房MCP解决的是能做什么的问题菜谱Skills解决的是”该怎么做”的问题。一个完整的Agent两者都需要。这里有很多同学可能会混淆MCP和SKILLs 其实二者的区别就是mcp是让ai能够获取到外部信息 就是can do 的问题而skill就是让ai知道how todo 比如ai知道获取天气的tool 但是它不知道什么时候调用这个时候就需要skill来告知他什么情况下使用以及如何使用等等。就类似你会加盐但是你不知道什么时候和情况下加盐比较好但是skill里面也顶定义tool 就是获取行为的能力Skills 的工作方式Skills的工作方式跟FunctionCall和MCP有一个关键不同Skills的核心是“指令和知识但它在执行过程中完全可以调用工具。具体来说当Agent启动时它会扫描可用的Skills列表。当用户提出请求时Agent判断有没有匹配的Skill。如果有Agent就把这个Skill的内容加载到上下文中然后按照Skill中的指令来思考和行动。但这里有一个很重要的点——Skill不只是告诉Agent怎么想它还能指导Agent怎么做。一个Skill可以在SKILL.md〃文件中通过allowed-tools字段声明它需要使用哪些工具(比如Bash、Read、Edit也可以打包可执行的脚本文件甚至可以指导Agent去调用MCP工具或发起FunctionCall。举个例子一个部署到测试环境“的Skill它的SKILL.md²不仅包含部署的步骤说明还会声明allowed-toolsBash然后在指令中写明先执行npmtest再执行npm run build最后执行部署脚本。Agent加载这个Skill后会按照指令一步步调用Bash工具来真正执行这些操作。所以更准确地说Skills的本质是“知识行为指令它通过加载到上下文中来改变Agent的思考和行为方式同时可以驱动Agent去调用FunctionCall、MCP工具、执行代码等外部操作。这就像给Agent I临时注入了一段专业经验——不仅告诉它“该怎么想”还告诉它“该怎么做、用什么工具做”Skills 有什么价值Skills 的核心价值在于将专业知识和最佳实践编码成可复用的模块。skills就相当于给提供了一本葵花宝典你不会的就可以去查比如你是程序员这本宝典就是各种api以及规范等等比如你是厨师这本宝典可能就是菜谱比如你是被四六级折磨的大学生或者正在“监狱”的高中生这本可能就是单词书了这些经验以前都在人的脑子里现在可以写成 Skill 文件让 Agent 使用。而且 Skills 可以共享和复用你写了一个好的 Skill团队里所有人的 Agent 都能用上FunctionCall、MCP、Skills有什么区别前面分别讲了 Function Call、MCP 和 Skills你可能已经有点绕了它们不都是让 Agent 更强的手段吗到底有什么区别咱们用一个统一的比喻来把它们串起来你就彻底明白了一个比喻想象Agent是一个新入职的员工。FunctionCall就是“打电话的能力这个员工学会了怎么拿起电话、拨号、跟对方沟通。这是最基础的能力没有这个能力他就没法跟外部世界互动。MCP就是”公司的通讯录和电话系统”它统一管理所有外部联系方式供应商、合作伙伴、服务商员工不需要自己记住每个人的电话号码和通话方式直接查通讯录就行。新增一个联系人只要加到通讯录里所有员工都能用。Skills就是”岗位培训手册“它告诉员工“遇到客户投诉应该按什么流程处理””做报表应该用什么模板和方法”“跟供应商谈判要注意哪些要点”。它教的是做事的方法和规范而不是打电话的技术三者的本质区别从解决的问题来看FunctionCall解决的是“LLM怎么跟外部函数交互“这个最基础的问题。MCP解决的是“怎么用统一标准管理大量工具“的集成问题。Skills解决的是”Agent怎么获得领域专业知识”的知识问题。从运行位置来看FunctionCall的函数在你的应用程序中执行。MCP的工具在外部的MCPServer中执行。Skills完全在Agent的上下文窗口内生效不涉及任何外部调用。从技术本质来看FunctionCall是一种API协议LLM输出结构化的调用请求应用程序执行后返回结果。MCP是一种通信标准定义了Client和Server之间如何发现和调用工具。Skills是一种提示词扩展用自然语言编写的行为指令加载到Agent的上下文中。从标准化程度来看FunctionCall在各LLM厂商之间格式不统一OpenAl 和Anthropic的格式就不一样。MCP是统一的开放标准跨厂商通用。Skills目前还没有统一标准各个Agent平台有自己的Skill格式。三者是什么关系FunctionCall是底层基础。MCP建立在FunctionCall之上提供了标准化的包装。当你的Agent通过MCP调用一个工具时底层其实还是在做FunctionCall只不过格式和通信方式被MCP统一了。Skills则在一个完全不同的维度上工作它不参与工具调用的过程而是指导Agent什么时候该调用工具“用什么策略来完成任务”。用做饭来总结FunctionCall是会使用厨具的能力”会开火、会切菜MCP是一个设备齐全且标准化的厨房”所有厨具放在该放的地方用统一的方式使用Skills是“菜谱和厨艺经验”知道做什么菜、怎么做、火候多大。三者结合才能做出一桌好菜。什么是A2A前面我们讲了 MCP 协议它解决了 Agent 跟工具之间的连接问题。但还有一个问题 MCP 没有解决**如果有多个 Agent 需要互相协作它们之间怎么通信这个时候就引入了A2A 其实就是agent to agent 这个概念可以类比java后端里面的微服务 模块之间的通信可以用http也可以用一系列rpc框架去通信那agent之间怎么通信呢其实就是通过A2A协议但是这个目前还不是很成熟但是相信有大厂背书未来应该会越来越成熟为什么需要 A2A想象这样一个场景一个大型企业里有多个AlAgentHR部门有一个招聘AgentIT部门有一个运维Agent财务部门有一个报销Agent。这些Agent可能由不同的团队开发使用不同的框架有的用LangGraph有的用CrewAl有的用 OpenAl Agents SDK)。当一个新员工入职时需要HRAgent处理入职手续、ITAgent配置工作电脑和账号、财务Agent设置薪资账户。这三个Agent需要协作但它们互相不认识也不知道对方会什么、怎么沟通。MCP解决不了这个问题因为MCP是给Agent连接工具用的它处理的是Agent调用数据库Agent发送邮件这类Agent与工具之间的交互。但Agent与Agent之间的协作需要一个全新的协议。A2A 是什么开头其实就点明了 A2A就是一个agent之间通信的协议A2A是Google 在2025年4月的Google Cloud Next大会上发布的一个开放协议全称Agent-to-AgentProtocol顾名思义就是Agent 对Agent的通信协议。它联合了超过50家合作伙伴共同推出包括Atlassian、Salesforce、SAP、MongoDB、LangChain等业界大玩家。A2A定义了一套标准让不同的AlAgent能够互相发现、互相通信、互相委派任务不管这些Agent是用什么框架开发的、运行在什么平台上。A2A 和 MCP 是什么关系简单来说MCP 是「竖向」的处理 Agent 到工具的连接A2A 是「横向」的处理 Agent 到 Agent 的协作。总结通过我在小林coding里面学习到的知识来给大家展现了agent相关的知识里面有我个人的部分见解 还有一个很重要且很难的知识RAG没说下一期再讲ai圈子的知识迭代非常快需要大家持续关注和学习我也是一名在ai时代洪流下苦苦寻求出路的苦命大学牲如果能看到这我给每一位读者点个赞 如果有什么问题都可以评论或者私信我。希望你们能够点赞给予我一些支持我看到正向反馈也会让我分享更多自己知道的读到的知识。我只是想把知识分享给每一位在路上寻光的赶路人**声明**本文的图片均来自小林coding 非本人制作如有侵权请联系我我会删除
Agent？ Mcp？skill等等这些是什么
发布时间：2026/6/28 8:48:01
Agent Mcpskill等等这些是什么在如今的2026年相信大家面对ai圈的各种概念和知识有些会模糊不清下面我就结合我在别人的博客上学习到的以及自己的一些理解吧 下面从小林coding的笔记中给大家带来讲解小林coding编程导航LLM 和 Agent有什么区别?Agent 和workflow有什么区别?function call是什么?mcp是协议什么?skills是什么?function call、mcp、skills有什么区别?什么是A2A协议?说一下这些年我对ai的感受我是23年高考的当年语文老师还说高考很有可能会考ai相关的让我们了解一下不过最后还是没考留到了第二年24届去考了。然后在大一上学期的时候ai其实还没有进入到我的生活当时用搜题目以及问东西都还是大学搜题酱和百度等等但是到了下学期我当时就发现了一款ai软件发现很好用当时还叫海螺ai现在好像已经改名字了到如今我才发现原来之前用的海螺就是minimax家的我还以为i已经退出市场了。然后到了24后半年ai开始爆发开始逐渐走进大众视野开始知道豆包、通义、kimi等等这些然后ai就开始逐渐改变大家生活了。说一下我身边最明显的变化就是以前老师布置的作业可能需要去搜一下或者抄同学的但是现在人手都用豆包水一下只要一涉及到什么作业或者问题第一想法就是用豆包可见现在ai的使用深入人心。接着ai就如同脱缰的野马一般进化飞快什么都能做了pptword等文档生成视频以及各种事情也都能做了这也就不得不提出今天要说的agent了 这也是agent和ai之间的区别之一。随之而来的也是面对ai冲击下的就业市场的恐慌毕竟ai这么强效率也高性价比远远大于人类。我也时常感到恐慌面对无所不能的ai未来该何去何从感觉学什么好像都不如问一下ai直接出答案来的快感觉好像做什么再也没有之前的成就感了因为什么都可以让ai来做了有一种面向自然语言编程的感觉了。但是这样让我意识到必须要顺应时代当今时代就是要学会使用ai和了解其原理我们每一个小个体都不可能改变时代发展真所谓顺时代者昌逆时代者亡所以必须要更上时代学会接受变化。就好比一百多年前慈禧还说外国的奔驰跑的不如他们的马车所以你看现在呢走在路上有人骑马 以前的马夫也许早改行做司机了所以你问我会骑马吗我会回答我不会因为我不需要骑马作为代步工具了而是需要会开车的司机。所以每一个时代的科技都革命人们的生活方式。所以在ai时代的冲击未来会怎么样其实我也无法精准预测但是我们要做到的就是能够紧跟时代保持持续学习的状态和接收变化就好比当年的马夫和人力车夫早已经改行去当司机去了出租车司机因为网约车改行去跑线上或者去跑货车了。下面切入正题让我们来看看agent相关的知识吧。下面的知识是我从小林coding和鱼皮那学习到的以及自己的一些个人鄙见。LLM 和 Agent有什么区别?什么是LLM其实这个llm就是large language model 的缩写 也就是大语言模式是所有ai的大脑就好比人的大脑一样可以做出思考和推断具有自我意识还会学习知识不过这里的学习需要去训练模型但是他也能具备感知外部环境的能力你可以把它想象成一个读了互联网上几乎所有文字的超级学霸。它通过学习海量的文本数据掌握了人类语言的各种规律和知识。我们平时用的ChatGPT、Claude、DeepSeek、文心一言底层都是大语言模型。这里引用xiaolin的图解就是LLM的工作原理说白了就是「预测下一个字」。你给它一段话它会根据学到的语言规律一个字一个字地往后接。听起来简单但因为它学的数据量实在太大了这种「接龙」的效果好到令人吃惊它能写文章、写代码、做翻译、回答各种专业问题。所以平时输入的prompt提示词本质就是在提高他预测词的精准度因为经常训练今天天气真好明天是晴天后天是雨天等等这些内容所以你问他今天怎么样他能通过训练的数据掌握这里面的回答规律从而预测下一个字的回答LLM有什么弊端虽然这个大脑LLM非常聪明但是你要想如果只聪明但是不能做不了事那不也就是只会说不会做了就像那种只说不做假大空一样。说不好听点只要LLM就像人彘一样只有思想和想法但是做不了事想要做事必须得要有手脚光有大脑是不够的第一个弊端是只会「说」不会「做」。你让LLM「帮我订一张机票」它会详细告诉你怎么订但它真没法替你去携程下单。你让它「帮我把这个Bug修了」它能给你改好的代码但它没法自己打开编辑器去改文件、跑测试。说白了LLM的能力被困在对话框里了它没法跟外部世界互动没法操作任何系统。第二个弊端是没有「记忆」。你跟ChatGPT聊了一下午聊了很多你的个人情况和项目背景。结果第二天开一个新对话它完全不记得你是谁了。因为LLM的记忆只限于当前这轮对话的上下文窗口对话一结束一切归零。第三个弊端是不会用「工具」。你问LLM今天上海天气怎么样它只能根据训练数据里的旧知识来猜而不是像你一样打开天气App查实时数据。LLM本身不能上网搜索、不能查数据库、不能调API所有回答都来自它「脑子里」已有的知识而这些知识不仅有截止日期还可能是错的也就是常说的「幻觉」问题。第四个弊端是不会「规划」。如果你给LLM一个复杂任务比如「帮我做一份竞品分析报告」它只能一次性生成一大段文字。它不会像人一样先想想应该先搜集哪些信息、分析哪些维度、用什么框架来组织然后一步一步去执行。LLM是「被动响应型」的你问一句它答一句没法自主拆解任务、制定计划、分步执行。什么是agent其实说白了agent就是给LLM装上手脚以及记忆等等一些工具简单来说Agent 就是 LLM 在循环中自主使用工具的系统这个里面的循环持续思考我感觉其实就是从2024年deepseek开始的当时我记得你问他问题他就会一直不断的去思考然后观察然后再思考这样去loop导致每一个一个问题他要思考很久而且当时访问还有限制因为访问人太多了图里有三个关键词「LLM」说明Agent的核心大脑还是大模型「工具」说明它能调用外部能力「循环」说明它不是一问一答就结束而是会不断地思考、行动、观察结果、再思考直到任务完成。打个比方如果LLM是一个只会给你建议的顾问你问他「怎么装修房子」他能讲一大堆方案但绝不会亲自动手。这里的流程就是LLM-TOOL-ACT-OBSERVE-LLM-TOOL…那Agent就是一个能动手干活的项目经理你说「帮我把房子装修好」他会自己去找装修队、买材料、盯进度、解决问题直到装修完成。所以从LLM到agent 它解决了什么问题呢其实就是针对只会说不会做Agent引I入了工具调用能力可以调用搜索引擎、数据库、API、代码执行器等各种外部工具来真正执行操作。针对“没有记忆”Agent配备了记忆系统包括记住当前任务上下文的短期记忆和存储在外部数据库中、可以跨对话保留的长期记忆。针对”不会用工具”业界推出了MCP等标准化协议来统一工具接入方式后面会详细讲。针对”不会规划”Agent具备了任务拆解和规划能力能把一个大目标分解成多个小步骤然后逐步执行。Agent的核心组成第一个是大脑也就是LLM负责理解意图、推理判断、决定下一步行动。第二个是规划模块负责把复杂任务拆解成可执行的步骤。第三个是记忆模块负责存储和检索信息让Agent能在长时间任务中保持连贯。第四个是工具模块是Agent的「手和脚」让它能跟外部世界互动。这样的话LLM就从只会说以及什么也没有的状态进化成了有各种能力的agent智能体。Agent和workflow有什么区别搞懂了 LLM 和 Agent 的区别之后你可能还会碰到另一个容易搞混的概念Workflow工作流很多人把 Agent 和 Workflow 混为一谈但它们的设计理念其实完全不同其实这个概念的区别可以用一个场景来区别就好比你去做饭你妈妈做饭可能做了十几年做一个菜的步骤可能都已经刻在DNA里面了比如辣椒炒肉1.先煸炒辣椒2.辣椒炒好先放出来然后再放肉3.最后混合在一起炒放入多少盐比较合适等等这个就是workflow工作流也就是每一步都按照设定好的流程去做到了你去做随机性可能就比较大了因为你不会做所以你可能回去dy上面去搜教程然后不同的人做法也不一样所以就看谁怎么做的你就按照他的来比如1.先把肉腌好辣椒都切好2.先炒肉在这个时候就加调味料之类的3.然后再加入辣椒4.然后加水焖一下…你下次可能又忘了上一次的怎么来的了所以做法又不一样了然后就带有自主性的加入了自己的想法以及看了另外一个博主教的视频步骤和上次又不一样了而agent就像你做饭一样思考行动然后感觉好像不对发现盐放多了那就多加水然后发现水放多了只能多煮一会了哈哈哈就是一直这样来回的loop声明本人不是很会做饭上诉步骤纯属瞎编Workflow 是指 LLM 和工具通过预定义的代码路径进行编排的系统而Agent 是指 LLM 动态主导自身流程与工具调用的系统由 LLM 自主决定如何完成任务。说人话就是一个是流水线标准都已经定好了流程也是定好的就是按照既定的方案去实现但是agent是你让它做一件事它自己去分析然后行动然后看效果然后再来思考反馈然再重复核心区别在哪就是看谁在掌控流程workflow就是你自己agent就是llm自己去决策回到做饭就是workflow就是经验agent就是新兵蛋子啥也不会只能摸着石头过河什么时候用 Workflow什么时候用 AgentAnthropic给了一个非常实用的建议从最简单的方案开始只在明确需要时才增加复杂度。如果任务步骤是固定的、可以提前规划好的或者对可靠性要求很高比如金融交易、医疗系统那就用Workflow。如果任务是开放式的、无法预知所有步骤或者需要灵活应对各种意外情况那就用Agent。不过在实际生产环境中最常见的其实是混合架构Workflow和Agent 的结合。正如LangChain说的“大多数生产中的Agent系统其实是Workflow和Agent的组合。”用做饭的例子说人话就是有些事情按照经验步骤来就可以了因为已经经过你这么多年吃妈妈饭的口味检验了有些可以自主规划一下比如最近上火了就少加点辣椒。晚上吃饭的客人不喜欢吃香菜和葱菜里面就不放适度调整。而不是完全一股脑用之前的死板做法也就是workflow。agent就是带有自己思考当然程序员使用workflow和agent的场景和做饭不一样他们的眼中的workflow是自己写代码把流程业务规划好而agent就是开放式的不可确定的需要灵活应对各种情况比如一个智能客服系统整体流程用Workflow控制接收工单→分类→处理一回复但在”处理”环节遇到复杂问题时会启动一个Agent来自主分析和解决。所以不要把两者对立起来它们更像是工具箱里的锤子和螺丝刀不是竞争关系而是配合关系。Agent有什么工作模式了解了Agent是什么之后下一个问题就是Agent到底是怎么「干活」的就像人干活有不同的方式有人喜欢边做边想有人喜欢先列计划再动手有人喜欢团队协作Agent干活也有不同的工作模式。1.ReAct模式(边想边做)ReAct 是目前最经典、最基础的 Agent 工作模式名字来源于 Reasoning Acting 的缩写也就是「推理 行动」。几乎所有主流的 Agent 框架底层都在用它。这个模式的本质就是循环交替思考think-行动act-观察observe它的核心思想非常简单Agent在思考和行动之间不断交替。具体来说就是一个三步循环先是思考Thought分析当前情况决定下一步做什么然后是行动Action调用一个工具来执行接着是观察Observation查看工具返回的结果。然后回到思考如此循环直到任务完成。打个生活化的比方。想象你要收拾行李准备出差你会先想「我要去上海三天先看看天气怎么样」然后打开手机查天气预报发现会下雨气温15-20°C接着想「得带伞和外套」于是去找出来放进行李箱再想「还得确认酒店」打开App检查预订信息.这就是ReAct的精髓每一步都先想后做做完看结果再决定下一步。ReAct的优点是透明可审计每一步思考过程都看得见、灵活适应遇到意外能随时调整、通用性强。但它的缺点也很明显token消耗大因为每一步都要完整推理一次有时会陷入循环反复执行相同动作走不出来。2.Plan-and-Execute先想好再做)如果说ReAct是「边想边做」Plan-and-Execute就是「先想好再做」。它把Agent的工作分成两个阶段第一阶段是规划Agent先把完整的执行计划想清楚第二阶段是执行按计划逐步完成不用每步都重新思考全局。用出差的例子来对比ReAct是「查天气→想想带什么→找衣服一想想还缺什么一查酒店一想想还要准备什么.」每一步都重新审视全局。而Plan-and-Execute是先列一个清单查天气、准备衣物、确认酒店、准备证件、叫车然后逐项打勾执行。这种模式最大的优势是省钱。规划只做一次执行阶段不用反复推理token消耗大约是ReAct的五分之一。但缺点是不够灵活如果执行到第3步发现情况变了原来的计划可能就不适用了。所以也有这么个做法是在执行过程中加入「重新规划检查点」每隔几步检查一下计划是否还靠谱。3.Reflection(做完再检查)反思模式的核心思想是 Agent 完成任务后不急着交付而是先自我检查一遍就像你写完文章不会直接发出去而是再通读一遍、改一改、润色一下。实现方式通常有两种。一种是自我反思同一个Agent完成任务后切换到「审查者」角色来审视自己的输出发现问题就修改然后再审查直到满意。另一种是双Agent对话一个Agent负责生成另一个负责评审两者来回迭代直到评审方满意就像代码的CodeReview过程。这种模式特别适合对质量要求高的场景比如代码生成、法律文书、学术论文等。4.Multi-Agent团队协作当任务太复杂、一个Agent 搞不定的时候怎么办答案是派一个团队上。Multi-Agent模式让多个专业化的Agent各司其职比如一个负责规划、一个负责搜集信息、一个负责写代码、一个负责测试通过协作来完成复杂任务。这个就像大家去参加项目一样有人负责制作ppt有的人负责写文字有的人负责答辩让不同的人在自己擅长的领域去做贡献目前主流的多Agent框架包括 LangGraph、CrewAI、OpenAl Agents SDK 和微软的 AutoGen等。不过Anthropic提醒过不要过早引l入多Agent架构。很多时候一个强大的单Agent就够用了。只有任务确实需要拆分成多个并行子任务时多Agent才值得引入。最后总结一下这几种模式不是互斥的实际中往往是组合使用的。一个多Agent系统中每个Agent内部可能用的是ReAct模式整体协作用的是Multi-Agent模式最后还有一个Reflection环节来检查质量。选择哪种模式关键看你的任务特点和对灵活性、成本、质量的优先级排序。function call是什么前面说了ai到agent的进化有工具调用有了工具调用ai就是查询天气获取各种信息甚至操作数据库那这些是怎么实现的呢其实就是function call[从「只会说话」到「能做事情」]以前的ai都是和聊天机器人似的一问一答基本就是你问他什么 他回答你也帮你干不了什么事情甚至很多数据都是它自己凭空捏造的但是FunctionCall的出现彻底改变了这个局面。它是OpenAl在2023年6月率先推出的一种能力简单来说就是让LLM不仅能生成文字还能告诉外部程序「我想调用某个函数参数是这些」。打个比方。在没有FunctionCall之前LLM就像一个只能写字的人你问他天气他只能根据记忆回答「上海通常三月份比较潮湿」。有了FunctionCall之后这个人学会了「打电话」你问他天气他会拿起电话拨给天气台调用天气API)听到对方报的实时数据后再告诉你「今天上海22°C多云」。fc工作原理Function Call 的工作流程分四步。图中的流程大致就是prompt-llm-if tool -response第一步定义函数。开发者预先告诉LLM「你手边有哪些工具可以用」用JSON格式描述每个函数的名字、功能说明和参数。比如你告诉它有一个get_weather函数接收一个城市名参数返回天气信息。{tools:[{type:function,function:{name:get_weather,description:获取指定城市的实时天气,parameters:{type:object,properties:{city:{type:string,description:城市名称比如上海}},required:[city]}}}]}第二步模型判断。用户提问后LLM分析用户的意图自己判断「要回答这个问题我需要调用哪个函数」。如果用户问「上海今天天气如何」LLM会决定调用get_weather并生成参数{“city”“上海”}{tool_calls:[{type:function,function:{name:get_weather,arguments:{\city\: \上海\}}}]}第三步执行函数。注意这一步非常关键LLM自己并不执行函数。它只是输出了「我想调用这个函数参数是这些」的结构化指令。真正执行函数的是你的应用程序。你的代码拿到LLM返回的调用指令后解析出去实际调用天气API拿到结果比如22度多云第四步生成回答。你的代码把拿到的真实温度数据再次发给LLM。LLM这次有了客观数据支撑就会用非常自然的人类语言回复你今天上海天气是多云气温大约22摄氏度。为什么fc这么重要你可能会觉得这不就是「让LLM调API」吗有什么了不起的关键在于FunctionCall解决了两个核心问题。第一个是**什么时候调用“的判断问题**LLM能根据用户的自然语言意图自动判断需不需要调用工具、调用哪个工具。你不需要写复杂的条件判断逻辑LLM自己会推理。第二个是**“传什么参数“的提取问题**LLM能从用户的自然语言中提取出结构化的参数。用户说“帮我查一下北京后天的天气”LLM能自动提取出city北京和date后天。这两个能力加在一起就把LLM从一个「只会聊天的文本生成器」变成了一个「能理解意图并驱动外部系统的决策引擎」。而这正是Agent 的基石。可以说FunctionCall就是Agent能力的最底层技术基础没有FunctionCallAgent就无法调用工具也就没法真正「做事」。目前几乎所有主流大模型都支持FunctionCall包括OpenAI的GPT系列、Anthropic的Claude系列、Google的Gemini系列以及各种开源模型如Llama等。虽然各家的API格式略有不同但核心原理是一样的。fc和agent的关系fc就是工具调用嘛但是llm只能决定一次的工具调用它没有反馈机制所以导致可能一次并不成功但它也没有异常处理。但是agent它会循环执行工具调用如果发现不对就会收到反馈信息来纠正MCP协议是什么前面讲了 Function Call 让 LLM 能调用工具。但随着 Agent 越来越强大需要连接的工具和服务越来越多一个新问题浮出水面了集成太麻烦了。Function Call 的集成困境很明显的问题就是各家agent的调用不同的tool的格式一样 导致很多格式不兼容比如你要agent能够访问github上的仓库还能打开web页面等等这样就需要写不同的工具的适配性有多个agent还需要n多个为了解决这个问题Anthropic在2024年11月开源了MCP(Model Context Protocol模型上下文协议。你可以把MCP理解为**「AI界的USB-C接口」**。这里引用鱼皮说的一个有标准的东西形成之后才会有生态 标准-生态所以就由此诞生了MCP这个就相当于定义了调用工具的格式协议就像以前小时候手机有很多我小时候用过酷派手机以及其他的不知名的手机如果他们充电用的都是不同的插口那怎么办比如oppo用不了vivo的小米的用不了oppo的这样的话就会存在很多问题所以为了统一标准慢慢的都演变成了typeC口了 包括苹果现在好像也有tc口。所以这就是标准的形成MCP整个流程就是用户在AI应用中提问→AI应用Host通过MCPClient发现有哪些可用工具→AI决定调用某个工具→MCPClient向对应的MCPServer发送请求→Server执行操作返回结果→AI基于结果生成回答。MCP解决了什么问题最核心的就是把N×M的集成问题变成了NM的问题。以前每个AI应用要跟每个服务单独对接现在每个AI应用只要支持MCP协议实现一次Client每个服务只要提供一个MCPServer实现一次Server双方就能自动对接。新增一个服务不需要改任何AI应用的代码新增一个AI应用也不需要改任何服务的代码。而且MCPServer暴露的工具是可发现的AI应用启动时能自动查询有哪些MCPServer可用、每个Server提供哪些工具、每个工具的参数是什么。这意味着Agent可以在运行时动态发现新的能力而不是只能用开发者写死的那些函数。Skills是什么Skills是一种自然语言指令文件通常是Markdown格式用来教Agent在什么场景下、按照什么方法、遵循什么规范来完成特定任务”。在Claude Code、Cursor等AI工具中Skills通常以sKILL.md文件的形式存在。Skills的结构很简单顶部有一段YAML格式的元数据声明这个Skill什么时候应该被激活比如”当用户要求代码审查时下面是具体的行为指令用自然语言写成。eg--- name: Code_Review_Expert description: 当用户要求进行代码审查时自动触发此技能。 triggers: - 帮我 review 一下这段代码 - 代码审查 --- # 身份设定 你是一个拥有 10 年开发经验的资深后端架构师你极其看重代码的可读性、性能和安全性。 # 审查工作流 当你进行代码审查时你必须严格按照以下步骤进行排查 1. 看结构检查代码是否符合单一职责原则有没有超过 100 行的超长方法。 2. 查漏洞重点检查是否存在 SQL 注入风险、越权访问风险或空指针异常风险。 3. 审性能是否有在 for 循环里查数据库的愚蠢操作是否有流对象没有及时 close 释放 4. 给方案你绝对不能只挑毛病必须针对每个问题给出具体的修改建议并且附带优化后的代码片段。 # 输出规范 语气要专业、极其直接不要说废话。直接输出一份 Markdown 格式的审查报告分点列出问题和修改方案。打个更直观的比方如果说McP给了Agent一个装满工具的厨房有刀、有锅、有烤箱、有各种调料。那Skills就是一本菜谱告诉Agent做红烧肉要先焯水再炒糖色加水炖40分钟火候要先大后小”。厨房MCP解决的是能做什么的问题菜谱Skills解决的是”该怎么做”的问题。一个完整的Agent两者都需要。这里有很多同学可能会混淆MCP和SKILLs 其实二者的区别就是mcp是让ai能够获取到外部信息 就是can do 的问题而skill就是让ai知道how todo 比如ai知道获取天气的tool 但是它不知道什么时候调用这个时候就需要skill来告知他什么情况下使用以及如何使用等等。就类似你会加盐但是你不知道什么时候和情况下加盐比较好但是skill里面也顶定义tool 就是获取行为的能力Skills 的工作方式Skills的工作方式跟FunctionCall和MCP有一个关键不同Skills的核心是“指令和知识但它在执行过程中完全可以调用工具。具体来说当Agent启动时它会扫描可用的Skills列表。当用户提出请求时Agent判断有没有匹配的Skill。如果有Agent就把这个Skill的内容加载到上下文中然后按照Skill中的指令来思考和行动。但这里有一个很重要的点——Skill不只是告诉Agent怎么想它还能指导Agent怎么做。一个Skill可以在SKILL.md〃文件中通过allowed-tools字段声明它需要使用哪些工具(比如Bash、Read、Edit也可以打包可执行的脚本文件甚至可以指导Agent去调用MCP工具或发起FunctionCall。举个例子一个部署到测试环境“的Skill它的SKILL.md²不仅包含部署的步骤说明还会声明allowed-toolsBash然后在指令中写明先执行npmtest再执行npm run build最后执行部署脚本。Agent加载这个Skill后会按照指令一步步调用Bash工具来真正执行这些操作。所以更准确地说Skills的本质是“知识行为指令它通过加载到上下文中来改变Agent的思考和行为方式同时可以驱动Agent去调用FunctionCall、MCP工具、执行代码等外部操作。这就像给Agent I临时注入了一段专业经验——不仅告诉它“该怎么想”还告诉它“该怎么做、用什么工具做”Skills 有什么价值Skills 的核心价值在于将专业知识和最佳实践编码成可复用的模块。skills就相当于给提供了一本葵花宝典你不会的就可以去查比如你是程序员这本宝典就是各种api以及规范等等比如你是厨师这本宝典可能就是菜谱比如你是被四六级折磨的大学生或者正在“监狱”的高中生这本可能就是单词书了这些经验以前都在人的脑子里现在可以写成 Skill 文件让 Agent 使用。而且 Skills 可以共享和复用你写了一个好的 Skill团队里所有人的 Agent 都能用上FunctionCall、MCP、Skills有什么区别前面分别讲了 Function Call、MCP 和 Skills你可能已经有点绕了它们不都是让 Agent 更强的手段吗到底有什么区别咱们用一个统一的比喻来把它们串起来你就彻底明白了一个比喻想象Agent是一个新入职的员工。FunctionCall就是“打电话的能力这个员工学会了怎么拿起电话、拨号、跟对方沟通。这是最基础的能力没有这个能力他就没法跟外部世界互动。MCP就是”公司的通讯录和电话系统”它统一管理所有外部联系方式供应商、合作伙伴、服务商员工不需要自己记住每个人的电话号码和通话方式直接查通讯录就行。新增一个联系人只要加到通讯录里所有员工都能用。Skills就是”岗位培训手册“它告诉员工“遇到客户投诉应该按什么流程处理””做报表应该用什么模板和方法”“跟供应商谈判要注意哪些要点”。它教的是做事的方法和规范而不是打电话的技术三者的本质区别从解决的问题来看FunctionCall解决的是“LLM怎么跟外部函数交互“这个最基础的问题。MCP解决的是“怎么用统一标准管理大量工具“的集成问题。Skills解决的是”Agent怎么获得领域专业知识”的知识问题。从运行位置来看FunctionCall的函数在你的应用程序中执行。MCP的工具在外部的MCPServer中执行。Skills完全在Agent的上下文窗口内生效不涉及任何外部调用。从技术本质来看FunctionCall是一种API协议LLM输出结构化的调用请求应用程序执行后返回结果。MCP是一种通信标准定义了Client和Server之间如何发现和调用工具。Skills是一种提示词扩展用自然语言编写的行为指令加载到Agent的上下文中。从标准化程度来看FunctionCall在各LLM厂商之间格式不统一OpenAl 和Anthropic的格式就不一样。MCP是统一的开放标准跨厂商通用。Skills目前还没有统一标准各个Agent平台有自己的Skill格式。三者是什么关系FunctionCall是底层基础。MCP建立在FunctionCall之上提供了标准化的包装。当你的Agent通过MCP调用一个工具时底层其实还是在做FunctionCall只不过格式和通信方式被MCP统一了。Skills则在一个完全不同的维度上工作它不参与工具调用的过程而是指导Agent什么时候该调用工具“用什么策略来完成任务”。用做饭来总结FunctionCall是会使用厨具的能力”会开火、会切菜MCP是一个设备齐全且标准化的厨房”所有厨具放在该放的地方用统一的方式使用Skills是“菜谱和厨艺经验”知道做什么菜、怎么做、火候多大。三者结合才能做出一桌好菜。什么是A2A前面我们讲了 MCP 协议它解决了 Agent 跟工具之间的连接问题。但还有一个问题 MCP 没有解决**如果有多个 Agent 需要互相协作它们之间怎么通信这个时候就引入了A2A 其实就是agent to agent 这个概念可以类比java后端里面的微服务 模块之间的通信可以用http也可以用一系列rpc框架去通信那agent之间怎么通信呢其实就是通过A2A协议但是这个目前还不是很成熟但是相信有大厂背书未来应该会越来越成熟为什么需要 A2A想象这样一个场景一个大型企业里有多个AlAgentHR部门有一个招聘AgentIT部门有一个运维Agent财务部门有一个报销Agent。这些Agent可能由不同的团队开发使用不同的框架有的用LangGraph有的用CrewAl有的用 OpenAl Agents SDK)。当一个新员工入职时需要HRAgent处理入职手续、ITAgent配置工作电脑和账号、财务Agent设置薪资账户。这三个Agent需要协作但它们互相不认识也不知道对方会什么、怎么沟通。MCP解决不了这个问题因为MCP是给Agent连接工具用的它处理的是Agent调用数据库Agent发送邮件这类Agent与工具之间的交互。但Agent与Agent之间的协作需要一个全新的协议。A2A 是什么开头其实就点明了 A2A就是一个agent之间通信的协议A2A是Google 在2025年4月的Google Cloud Next大会上发布的一个开放协议全称Agent-to-AgentProtocol顾名思义就是Agent 对Agent的通信协议。它联合了超过50家合作伙伴共同推出包括Atlassian、Salesforce、SAP、MongoDB、LangChain等业界大玩家。A2A定义了一套标准让不同的AlAgent能够互相发现、互相通信、互相委派任务不管这些Agent是用什么框架开发的、运行在什么平台上。A2A 和 MCP 是什么关系简单来说MCP 是「竖向」的处理 Agent 到工具的连接A2A 是「横向」的处理 Agent 到 Agent 的协作。总结通过我在小林coding里面学习到的知识来给大家展现了agent相关的知识里面有我个人的部分见解 还有一个很重要且很难的知识RAG没说下一期再讲ai圈子的知识迭代非常快需要大家持续关注和学习我也是一名在ai时代洪流下苦苦寻求出路的苦命大学牲如果能看到这我给每一位读者点个赞 如果有什么问题都可以评论或者私信我。希望你们能够点赞给予我一些支持我看到正向反馈也会让我分享更多自己知道的读到的知识。我只是想把知识分享给每一位在路上寻光的赶路人**声明**本文的图片均来自小林coding 非本人制作如有侵权请联系我我会删除
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
