给小白看懂：Skill / Agent / 多Agent协同 / MCP / LLM / AI应用，是什么？各自干嘛？

基础分层总览（先记住这条链）

  1. LLM（底层大语言模型）：推理底座，“大脑”，只会读文本、续写文本；没有工具、没有记忆、没有流程调度。
  2. Skill：单任务静态SOP手册，定义【什么时候触发、步骤、输出格式、红线约束】，纯描述性规则包。
  3. Agent（单智能体）：具备循环规划+反思+多步执行能力的智能体，可以自己拆分子任务、判断下一步、循环执行。
  4. 多Agent协同：由多个职责独立的Agent组成协作团队，分工配合、互相通信，共同完成大型目标。
  5. MCP（Model Context Protocol）：标准化协议层，解决「LLM/Agent怎么统一调用外部工具、外部资源」，相当于工具通用接口规范。
  6. AI应用（豆包 / Codex / ChatGPT客户端等）：载体，提供会话、文件、工具调用、组件调度能力，把各种组件串起来。

一句话极简关系： LLM是大脑；MCP是统一工具总线；Skill是单任务操作说明书；单Agent是会自主规划分步干活的执行者；多Agent协同是分工不同、相互配合的执行者团队；AI应用是整套运行平台。

一、逐个详细定义、职能、能做/不能做

1. LLM 底层大语言模型

代表：Seed、GPT‑4o、Claude Opus、DeepSeek‑R1 职能： 接收一段文本上下文，基于预训练知识做理解、推理、文本生成。只输出token序列。 特点： 原生无文件访问、无网络、不能执行命令、不会自动循环、不知道外部世界；没有内置流程。
能做： 理解自然语言、推理、写文本、生成代码、做判断。
不能做： 直接读本地文件、执行脚本、访问网络、自动多步骤循环、自动调用工具。

2. Skill

核心载体：SKILL.md + 配套模板/参考文档 职能： 单一任务的静态标准化SOP。只描述一件事：这个任务在什么场景触发、执行顺序、输出格式、禁止事项、异常怎么处理。 它是静态文档，没有循环、没有自主决策逻辑。 触发方式：手动调用 $skill-name / AI应用识别关键词自动加载。
能做： 固定流程约束，稳定输出格式，减少幻觉；附带参考模板、资料；可Git版本管理。 适合：周报整理、代码评审清单、固定格式文档生成、标准化检查。
不能做： 不会自己拆分复杂任务、不会循环重试、不会自动调用多个工具；不能自主决定下一步。

本质：给LLM一套“照着做”的说明书，一步式任务优先。

3. Agent

载体：由AI应用调度，通常包含规划器、执行器、反思环节 职能： 自主规划 + 多步循环执行。拿到一个大目标之后，Agent会：

  1. 拆解目标成多个子任务
  2. 判断当前缺什么信息，决定要不要调用工具/MCP
  3. 执行一步，拿到结果后反思：是否完成、是否需要重试、是否进入下一个子任务
  4. 直到满足终止条件再结束

Agent 可以加载多个Skill作为它的子任务能力库。 ✅ 能做： 复杂长任务、多步骤编排、动态判断分支、循环执行、按需调用工具、组合多个Skill。 适合：项目调研、批量文档处理、复杂运维排查、多步骤工程任务。 ❌ 不能做： Agent的规划、判断依然依赖底层LLM，依然会幻觉；Agent本身不是模型，是一套执行框架；任务越复杂，越容易跑偏。

关键区分： Skill = 固定脚本，流程写死，顺序不能自己改； Agent = 会动态规划，根据中间结果改变下一步动作。

4. MCP（Model Context Protocol）

职能：工具与资源的标准化通信协议 解决一个痛点：过去不同工具、不同AI客户端、不同Agent，调用方式各不相同（每个工具一套自定义提示词、一套调用格式）。 MCP定义统一规范：工具怎么声明能力、怎么接收参数、怎么返回结果；文件、数据库、API、本地脚本都可以封装成MCP Server。

  • MCP Server：提供能力（读文件、查数据库、执行shell、访问git）

  • MCP Client：Agent / LLM 侧，通过标准协议去调用这些能力 ✅ 能做： 一套标准，跨客户端、跨Agent复用工具；工具和Agent解耦；新增工具不用改Agent逻辑。 ❌ 不能做： MCP只是通信协议，不会思考、不会规划、不会写流程；它只是一根标准化的“工具数据线”。

    类比：MCP = USB标准；MCP Server = U盘、键盘；Agent/Skill = 使用外设的程序。

5. AI应用（豆包 / Codex / ChatGPT 等）

代表：豆包客户端、ChatGPT网页、Codex 职能： 封装LLM，提供用户交互层、会话管理、权限、文件读写、组件调度（加载Skill、拉起Agent、对接MCP服务、调度多Agent集群）。 它是调度中心，负责把用户输入、Skill、工具结果、历史上下文打包传给LLM。 ✅ 能做：加载Skill、拉起Agent、连接MCP服务、管理对话、读写本地文件、展示结果、编排多Agent任务。 ❌ 不能做：本身不具备推理能力，依赖底层LLM。

二、横向对比表（职能差异一目了然）

组件/模式本质核心能力自主规划循环执行工具调用方式适合场景
LLM基础模型权重+推理程序语言理解、推理、文本生成❌❌本身不能调用工具所有上层能力的大脑底座
SkillMarkdown结构化SOP文档单任务固定流程约束、输出规范❌❌流程里写清楚调用MCP工具（被动）高频、固定步骤、边界清晰的单次任务
单Agent执行框架（规划+反思循环）任务拆解、动态分支、多步执行✅✅通过MCP主动按需调用工具复杂、不确定、需要多轮探索的任务
多Agent协同多个独立Agent组成协作系统任务分工、角色隔离、交叉校验、结果汇总✅（每个Agent独立规划）✅子Agent各自通过MCP调用工具，Agent间互相传递消息大型复杂任务、多专业交叉评审、流水线交付
MCP通信协议 + 工具服务标准化暴露外部能力❌❌提供统一调用接口给Agent/Skill统一管理、复用各类外部工具和资源
AI应用完整产品载体调度、会话、加载、权限、界面本身无由内部Agent实现对接MCP服务、加载Skill、拉起Agent、编排多Agent用户直接使用的入口平台（豆包、Codex）

三、四种典型工作链路，看懂怎么配合

链路A：原生LLM直接对话（无Skill、无Agent）

用户直接提问，一次性Prompt交互，没有固定流程封装。 适合：简单问答、随手一问。

链路B：简单任务，只用 Skill + MCP

用户需求：帮我把这周日志整理成标准复盘文档

  1. 用户提问 → AI应用识别，自动加载 weekly-review Skill

  2. Skill文档里写死流程：提取事实 → 分类成果/问题 → 生成行动项；需要读取日志文件时，通过MCP调用文件读取工具

  3. 规则+用户输入+工具返回内容一起送入LLM

  4. LLM严格按Skill里的格式输出结果

    特点：流程固定，没有自主分支，一步走完。

链路C：复杂任务，单Agent + 多个Skill + MCP

用户需求：帮我调研这个项目，整理风险清单，输出评审文档

  1. 用户需求交给Agent

  2. Agent（LLM做规划）拆解子任务：①读取需求文档 ②查阅历史工单 ③风险检查（加载risk-check Skill）④生成评审表（load review Skill）

  3. Agent判断每个子任务需要什么工具，通过MCP Server读取文件、查git记录

  4. 每执行完一步，Agent反思结果是否够用；不够就继续调用工具、继续执行子任务

  5. 全部子任务完成后合并输出最终文档

    特点：路径不固定，Agent自己决定先做什么、要不要重试。

链路D：超大型任务，多Agent协同 + Skill + MCP

载体：多个独立Agent，由AI应用的编排层调度，或内置调度Agent协调 职能： 多个职责独立、分工明确的Agent，互相通信、分工配合，共同完成一个大目标。每个子Agent一般只负责一小块领域，拥有专属的Skill库、约束规则；Agent之间可以传递任务、交换结果、交叉校验。

主流3种架构形态：

  1. 路由/调度型（主管Agent + 工人Agent） 有一个主调度Agent，负责理解总需求、拆分任务、分配给专门的子Agent；子Agent做完返回结果给调度Agent，调度Agent汇总、校验、整合输出。
  • 调度Agent：不做具体业务，只做分发、合并、冲突检查
  • 子AgentA：文档评审Agent，绑定评审相关Skill
  • 子AgentB：代码检查Agent，绑定代码规范Skill
  • 子AgentC：数据整理Agent，绑定格式化Skill
  1. 对等协作型（无主管，平等协商） 多个专业Agent对等交换信息，互相补充、交叉校验，适合需要多方意见、交叉复核的场景。 例：方案设计Agent、风险审核Agent、成本评估Agent互相交换输出，共同完成方案评审。
  2. 流水线型（串行接力） 任务固定按顺序流转：AgentA输出 → 交给AgentB处理 → 交给AgentC收尾。
    ✅ 能做： 大型复杂任务拆分、角色隔离、专业分工、交叉复核、并行处理子任务。
    ❌ 不能做： 无法消除底层LLM的幻觉；错误会在链路中传导；协调成本高，简单任务使用会增加延迟与成本。

用户需求：输出一份完整项目技术评审报告

  1. 用户请求送入【调度Agent】

  2. 调度Agent拆解任务：①拉取源码和文档 ②代码合规检查 ③风险识别 ④汇总成报告

  3. 调度Agent下发任务：

    • 交给【代码审计Agent】：加载代码评审Skill，通过MCP连接Git、静态扫描工具
    • 交给【文档核查Agent】：加载文档检查Skill，通过MCP读取需求文档

  4. 两个子Agent独立执行，各自循环、调用MCP工具，产出审计结果

  5. 子Agent把结果回传给调度Agent

  6. 调度Agent校验两份结果有没有矛盾、缺失，再交给【报告生成Agent】，按报告Skill整理成标准文档

  7. 最终返回给用户

    特点：并行分工、角色隔离；每个子Agent内部依然可以使用Skill、调用MCP。

四、高频容易混淆的边界（重点）

  1. Skill 和 Agent Skill 是能力单元、固定说明书；Agent 是调度执行框架。Agent可以把一堆Skill当成工具箱，按需挑选调用。 👉 Skill 不会自己跑多步；Agent会自己安排先调用哪个Skill、什么时候调用工具。
  2. 单Agent 和 多Agent协同 单Agent：一个规划循环，一个角色，自己搞定全部子任务。 多Agent协同：任务横向拆分给多个独立角色，各司其职，可以并行、交叉复核；引入调度层负责协调。简单任务没必要上多Agent，会增加复杂度。
  3. Agent 和 MCP Agent决定什么时候调用工具；MCP定义怎么调用工具。 Agent是决策者；MCP是标准化通道。没有MCP，Agent也可以调用工具，只是每个工具都要单独适配，难以复用。
  4. Skill 能不能写MCP调用？ 可以。Skill的流程里写明：“需要读取附件时，调用mcp文件读取工具”，但它是预设在固定流程里，不是动态按需决策。
  5. LLM ≠ Agent 很多人混淆：Agent里面会用到LLM做规划和反思，但Agent是一套循环框架，LLM只是里面的大脑。

五、各自的边界总结（什么做不了）

  • LLM：不能直接碰外部世界
  • MCP：只负责标准化通信，没有任何业务逻辑和智能
  • Skill：流程写死，不能动态调整计划，不适合开放性复杂任务
  • 单Agent：依然受底层LLM能力限制，会幻觉；任务分支越多，稳定性越差
  • 多Agent协同：幻觉会层层传递，协调难度高，不适合简单需求
  • AI应用：只是平台，不自带智能

六、总括

LLM是大脑；MCP是连接外部资源与工具的标准化总线；Skill是一张张固定任务说明书；单Agent是拿着说明书自主分步干活的执行者；多Agent协同是一群分工不同、互相配合的执行者团队；AI应用，是承载所有这些组件、交付给用户使用的整套平台。

七、小白上手建议

优先从简单的Skill开始做，遵循单一职责原则：一个Skill只负责一件明确的小事。熟练之后再尝试单Agent编排；只有遇到大型、多专业、需要交叉复核的任务，再考虑多Agent协同。不要一上来就搭建复杂的多Agent系统。