上次内部技术分享我抛了个问题谁能一句话说清楚LLM、Agent、Skills、MCP之间的关系结果挺有意思——有人说Agent就是大模型有人说Skills就是提示词模板还有人说MCP是某种新的插件框架。最麻烦的是查过文档的人也未必答得上来因为公开资料里这几个词经常被混着讲官方文档各讲各的几乎没人把它们放进同一张图里对齐过。这篇文章想做的就是把LLM、Agent、Skills、MCP放到同一个台面上逐个拆开再把它们串成一条完整的链路。如果你是大模型应用开发者、AI产品经理或者刚被“Agent开发”这个方向吸引过来的人这篇能帮你省掉大量绕弯的时间。我不打算写教科书式的定义而是从“它们到底各管哪一段”的角度讲配合实际任务流转看完你至少能跟同事对齐概念不再鸡同鸭讲。1. 这四个词放在一起为什么大家越查文档越懵你去看LLM的文档通篇在讲token、上下文窗口、微调去看Agent的文档满屏是规划、记忆、工具调用去看Skills的文档又变成了流程封装、参数模板再看MCP直接进入客户端、服务器、工具注册。单看哪个都像“AI开发的全部”合在一起却不知道谁依赖谁谁包含谁。问题出在一个根上这四个词根本不是同一层级的物种只是都被翻译成了中文后容易被并列看待。1.1 它们从来不是同一层级的物种用一个场景来感受层级差异。你招了一个实习生他聪明、反应快、知识面广这是LLM你给他安排了一个岗位要求他自己拆解目标、判断优先级、安排行动这是Agent他经过三个月训练学会了你团队的周报格式、客户跟进节奏、报价审批流程这是Skills最后他工作要用到的OA系统、客户管理后台、财务软件全部走一套统一接口接入这是MCP。所以严格讲你应该把它们错落排列LLM是能力底座Skills是底座上沉淀出的方法Agent是调用这些方法的执行主体MCP是执行主体与外部世界之间的通信标准。1.2 先记住一句话LLM是引擎Agent是驾驶员Skills是驾驶技能MCP是方向盘与仪表盘之间的标准接口这句话虽然糙但能解决90%的概念混淆。引擎决定马力不决定路线驾驶员决定去哪儿但自己不会造引擎驾驶技能决定过弯怎么踩刹车、上坡怎么换挡接口决定方向盘的动作能不能准确传导到车轮。后面所有章节都在给这句话补细节。你接下来读的时候可以不断回看这句话不容易迷路。2. 先啃最硬的骨头LLM到底是一个什么样的东西很多人把LLM想象成“什么都知道的百科全科老师”这其实是最大的误解也是后续很多概念混淆的起点。2.1 LLM的本质是“会接话的概率引擎”不是“什么都会的知识库”LLM的核心工作方式简单来说是在给定前文的情况下预测下一个最可能的token你可以把token理解为一个词或字符片段。它输出一句话等于在无数个可能的下一词选择中按概率挑了一条路径往下走。举个例子你输入“今天天气真”模型不是在检索天气预报而是在根据海量文本中学到的统计规律判断下一个词更可能是“好”还是“不错”。这个机制带来两个关键推论。第一LLM的“知识”不是结构化存储的事实而是参数里编码的语言模式。它擅长生成符合语境的连贯文本但不保证事实准确性因为它的目标从来不是“说真话”而是“说像话的话”。第二LLM本身不执行任何外部动作它不读你的数据库不调用你的接口不修改你的文件。它只接收文本输出文本。所谓“AI帮我把文件重命名”背后一定有一个中间层读出了文件名、调用操作系统接口完成了改名。2.2 用“患者-医生”类比看LLM的角色把LLM想象成一位经验丰富的医生。你向它描述症状它基于经验给出诊断建议。它没有给你开药方单子上的药也不会帮你缴费取药更不会跟踪你回家后的恢复情况。它做的事情是“根据输入生成输出”。但如果我们把问题换成“医生要不要建议你拍片子”“拍完片子回来后下一步怎么走”就需要一个能持续跟踪、安排检查、解读复查结果的角色——那个角色才是Agent。很多所谓“Agent应用”本质只是把患者-医生对话拉得更长医生全程坐镇但并没有人去执行检查和治疗动作所以它仍然是聊天机器人而不是智能体。2.3 搞懂LLM的能力边界会生成≠会执行基于以上你需要记住三个边界LLM不感知时间你不告诉它“今天是几号”它不知道自己身处何时。LLM不感知环境它不知道用户正在哪个页面、登录了什么账号、本地有什么文件。LLM不保证结果正确同一个问题换个问法可能得到完全相反的答案。这意味着凡是需要接触真实世界状态的工作都需要外部工具而工具怎么被“接进”LLM的工作流就是后面几个概念要解决的事。理解了LLM只是一台会接话的概率引擎再看Agent会顺很多。3. Agent把“会说”变成“会做”的那个壳Agent这个概念的流行程度已经快超过LLM本身了但很多人理解的Agent其实就是“带记忆的Chat机器人”。这个理解太窄。真正的Agent目标是把“会生成文本”变成“闭环完成任务”。3.1 Agent的组成结构我习惯把它拆成四个件模型内核还是那个LLM负责理解意图、生成计划和输出。规划能力把大目标拆解成步骤比如“写季度总结”拆成“收集数据—整理结构—生成初稿—检查格式”。记忆系统短期记忆是当前对话上下文长期记忆是跨会话的关键信息通常需要外部存储。工具使用权能调用函数、API、脚本这一步真正让Agent“手脚落地”。四条里最容易被忽视的是第四条。没有工具调用能力的Agent和高级聊天框没有本质区别有了工具调用能力它才能“说一句话外面发生一件事”。3.2 一个最简单的Agent循环用伪代码描述最朴素的Agent工作循环task 帮我查一下某快递的物流状态如果异常就标记出来 messages [{role: user, content: task}] done False while not done: response llm.call(messages) # 1. 模型生成下一步动作 action parse_action(response) # 2. 解析出要调用的工具和参数 if action.type call_tool: result run_tool(action.name, action.args) # 3. 执行工具 messages.append({role: tool, content: result}) # 4. 把结果回填给模型 elif action.type finish: done True print(response)这个循环里做决定的永远是LLM执行动作的是工具Agent则是“编排循环”的那层逻辑。它不停做“思考—行动—观察—再思考”直到任务完成。3.3 为什么没有AgentLLM只能停留在“顾问”层面没有Agent你每次都要自己把问题拆细再手动把每次的模型输出粘到下一个窗口。有Agent后模型自己判断下一步该做什么、要不要再查一个数据、要不要换一种策略。这就像一个实习生可以用但你要花大量时间带Agent是把他升级成能独立跑流程的半自动员工。所以Agent真正的价值是任务闭环它让模型不只是提供建议而是能对最终结果负责。这里注意这个“负责”目前还是工程意义上的负责它会把任务跑完、跑不通时报错但还谈不上对业务结果有意识。4. Skills真正把“经验”沉淀下来的方式如果说LLM是通用的脑子那Skills就是针对特定场景训练出的“肌肉记忆”。这个概念最近讨论度很高但很多人的理解还停留在“Skills 预设提示词”这个偏差很致命。4.1 Skills不是提示词而是“技能包”提示词是一段写给模型看的文字它的作用是引导模型当前这次输出。而Skills是一套完整的可复用技能封装包含目标描述、输入参数、执行步骤、输出规范和兜底策略。同样是让AI处理客户邮件提示词告诉它“你是一个客服请回复以下邮件”Skills则定义了“如果客户提到退款先查订单状态再判断是否满足政策最后按固定模板回复”。我做过一个很直观的测试。把同一套“会议纪要生成”的流程分别用提示词和Skills实现提示词版本换个模型效果立刻打折措辞稍变就输出混乱Skills版本把步骤、字段、标准拆开写清楚换模型后还能稳定出基本格式。4.2 拆一个“周报生成Skills”给你看下面是我常用的一个简化例子可以看到Skills的骨架name: daily_report_skill description: 根据工作记录生成当日周报 input: work_logs: string # 原始工作记录 focus: string # 今日重点 steps: 1. 清理输入的工作记录按“完成/进行中/问题”分类 2. 提取每条记录的耗时和影响范围 3. 生成“今日完成—明日计划—需要协助”三段式流水线 output: format: markdown sections: - 今日完成 - 明日计划 - 风险与求助 fallback: - 如果输入为空则要求用户补充 - 如果风险为空则标注“无重大风险”你可以看到Skills的粒度介于“一句话提示”和“完整业务系统”之间。它像菜谱不是光说“做一道鱼香肉丝”而是把备菜、调汁、火候全写清楚照着做就能稳定复现。4.3 Skills的沉淀、复用与迁移Skills最大的价值是沉淀和复用。团队里一位有经验的运营把自己处理客诉的完整方法沉淀成一个Skill新同事直接套用效果立刻到及格线以上。不同模型、不同项目间也能迁移——只要把Skills的结构定义清楚换掉底层模型技能依然能用。需要提醒的是Skills的维护很考验抽象能力。封装太粗和提示词没区别封装太细每个场景都要新建维护成本爆炸。我的经验是先从“一周至少用三次”的动作开始沉淀比如批量处理邮件、生成周报、整理会议纪要等结构成熟后再往低频场景扩展。5. MCP给Agent装上一根标准的“外设数据线”最后聊MCP。它全称是Model Context Protocol模型上下文协议领域里常直接叫MCP。很多刚接触的人会把它理解成“又一种插件框架”其实它解决的问题非常明确让AI应用和外部工具之间的对接方式统一起来。5.1 MCP解决的是N×M的对接问题在没有MCP之前每个Agent应用要对接工具都要自己写一套连接逻辑调用某个文档系统写一套调用某个IM机器人再写一套调用某个数据分析库又写一套。工具方也要针对不同的AI应用分别做适配。这在工程上叫N×M的适配矩阵哪边都很累。MCP的思路是做一个中间标准层。AI应用只需要实现MCP客户端工具方只需要实现MCP服务器端两边都只跟标准协议对话。这样对接关系从N×M变成N×1和1×M每一侧的工作量大幅下降。可以想象成USB-C接口统一了充电线下游设备不用再为每种设备准备专属线材。5.2 MCP到底规定了什么MCP没有规定业务逻辑它规定的是“连接方式”。核心是客户端-服务器模型一个MCP服务器对外暴露能力比如提供“查询订单”“发送消息”“读写文件”这些工具MCP客户端运行在AI应用里负责发现这些能力并据此调用。它内部主要定义了三类原语tools可被调用的函数有名称、描述、参数说明模型根据这些描述决定何时调用。resources可被读取的数据比如某个数据库表、某个文档路径模型可以获取内容作为上下文。prompts在客户端侧可复用的提示片段方便标准化的交互。一个最简单的MCP服务器配置文件可能长这样{ name: order-tool-server, capabilities: { tools: [ { name: query_order, description: 根据订单号查询订单状态, inputSchema: { type: object, properties: { order_id: { type: string } }, required: [order_id] } } ] } }模型不会直接执行这个函数而是生成一个“调用query_order参数为order_idxxx”的请求由MCP客户端把请求发给服务器端执行再拿回结果。整个链路里模型只负责理解任务和生成调用意图实际动作由工具服务器完成。5.3 关于MCP和Skills的边界我见到最多人搞混这是目前踩坑最密集的地方。很多人以为Skills和MCP是同类方案可以互相替代其实它们负责完全不同的两件事。Skills定义的是“做事的步骤和格式”它活在应用侧是给模型看的动作编排MCP定义的是“通过什么协议去调用外部能力”它活在应用和工具之间是连接标准。用开会来类比Skills是会议议程和发言模板MCP是会议室里的投影接口和电话线标准。议程再详细投影接不上会还是开不顺畅接口再标准没有人按议程发言会也是瞎扯。所以这两者是互补关系。一个完整的Agent应用通常同时需要它们用Skills把内部流程标准化用MCP把外部工具接入统一化。6. 把四者串起来一次完整任务的执行拆解概念讲再多不如跑一个真实任务。我们以一个不太复杂但足够代表性的场景为例你让AI“帮我整理这周的重点客户跟进情况生成一份汇报然后发给团队群”。6.1 任务在链路中的逐步流转整个任务开始后其实是这样一个链条LLM接收用户的原始指令理解“整理跟进情况”的意图并根据上下文知道“这周”“团队群”意味着要访问日历、客户系统、IM工具。Agent接管目标开始拆解先查哪些客户本周有记录读取跟进内容整理成汇报结构再调用IM工具发送。执行过程中Skills发挥作用。比如“客户跟进总结”这个技能规定按客户优先级排序每个客户只写“进展—风险—下一步”整体控制在一页内。模型不需要临场发挥按技能模板组织即可。查询客户数据、发送群消息这些动作全部通过MCP连接对应服务。Agent通过MCP客户端发现可用工具发起调用拿到真实数据再交给LLM生成最终汇报。整个过程里LLM是内容和决策来源Agent是流程控制者Skills是质量和一致性保障MCP是触达外部世界的通道。6.2 各环节职责速查表环节解决什么问题通俗职责不负责什么LLM理解与生成出主意、写内容不会真实操作任何系统Agent规划与闭环决定做什么调谁来做不会凭空知道外部数据Skills沉淀与复用保证活干得又快又标准不等于外部连接器MCP连接与标准化让外部工具能被统一调用不决定业务流程逻辑这张表建议直接收藏平时判断一个方案“缺了哪层”的时候对照一下基本不会错。比如某个项目效果不好你以为是模型问题查到最后是MCP接入的工具有问题再比如产品一致性差大概率是Skills没沉淀好而不是Agent循环不够复杂。6.3 这个架构里最容易出问题的地方从我观察到的项目看四层架构最常见的故障点在两个位置。一是Agent规划与Skills之间的配合。Agent拆出的步骤和Skills预设的步骤对不上模型就会硬套技能输出“四不像”。解决办法是让Skills的步骤写得足够模块化并且给Agent一个技能选择器让它在多个技能里挑最合适的而不是默认套第一个。二是MCP工具返回的数据格式没约束。模型返回调用请求之后服务器端返回的是一段很乱的文本LLM再聪明也解析不出结构化结果。所以工具返回内容一定要强行定义schema用JSON而不是自然语言模型才能稳定衔接。7. 落地时的常见误区和我的几条实操建议这四个概念在真实团队落地的时候误区相当固定基本集中在三个方向。7.1 误区一以为把模型Web页面当成Agent很多人看到某个模型在网页上能搜索、能画图、能读链接就说“这就是Agent”。严格讲那只能算一种内置了部分工具能力的演示形态。真正的Agent是一个可编程、可持续运行、可以自主决定调用链路的执行框架。如果你没法通过代码控制它的循环、没法替换它的工具集合、没法定义它的记忆策略那它离Agent还差一个工程层的距离。7.2 误区二把Skills做成“万能土办法”有些人图省事把Skills写成巨大无比的一段提示词把所有场景分支都塞进去。结果模型上下文被塞满输出来回摇摆维护起来想死。Skills的精髓是结构化而不是全量化。一个小技能把范围收窄、步骤敲死、输出约束清楚效果远超一个“什么都会一点”的巨型提示词。7.3 误区三把MCP当作AI公司的专属能力MCP不是某家模型厂商为你准备好的内置功能它本质上是一个开放协议工具链能不能用取决于有没有对应的MCP服务器端。如果你的内部系统没有封一层标准接口MCP客户端再好也调用不到。实际落地时通常要自己写少量适配代码把自己的业务工具包成标准接口。7.4 我给不同团队的三条起步建议如果你刚开始涉足这个领域我的建议很朴素第一先别急着打造复杂Agent框架。用现成的循环逻辑先把LLM和MCP链路跑通让模型能真实调用你的一个外部工具哪怕只是读一个文件。第二从高频场景里提炼出第一个Skills。选择你每周都要做的、步骤相对固定的动作封装成结构化技能然后连续用两周复盘哪里和真实流程不符合再迭代。第三做规划时永远问自己一句话这一层到底缺什么回答不了就去找原因是LLM理解不到位、Agent编排不清晰、Skills流程不稳还是MCP工具没接好对症下药比整体推翻重来有效得多。我个人的最终体会是这四个词的能力边界其实都非常清楚把它们理顺之后后面做架构选型、问题排查都能直接对号入座。希望这篇能帮你少走我当初走过的那些弯路也欢迎带着具体案例来讨论——毕竟这类技术演进得很快概念层的共识是一切协作的基础。