简介：本文系统梳理了LLM应用中Agent、RAG、MCP与Skill等关键概念的定义、技术原理与相互关系，帮助开发者理解它们各自解决的问题、核心组成与适用场景，避免概念混淆，为技术选型与架构设计提供清晰参考。
大语言模型（Large Language Model，LLM）的爆发让机器首次展现出接近人类的语言理解与生成能力。然而，早期LLM存在一个显著短板：它只知道训练数据中的“过去”，无法感知“现在”，更无法执行“动作”。当用户询问“今天的天气如何”或“帮我查一下这个订单状态”时，模型要么基于过时知识回答，要么直接编造一个看似合理但完全错误的结果。
这一局限催生了一系列技术概念的演进：Agent、RAG、Skill、MCP等。这些概念并非彼此孤立，而是围绕同一个核心目标展开——让LLM从“只会说话的模型”变成“能够获取信息、调用工具、完成任务的智能系统”。本文将从定义出发，系统拆解这些概念的本质、工作原理与相互关系，帮助读者建立清晰的技术认知框架。
LLM在推理时存在两个根本性限制：
这两个问题导致LLM在真实业务场景中难以直接落地。例如，一个客服机器人如果无法查询用户的最新订单状态，它的价值就极其有限。
最初，人们通过“人机协作”的方式弥补LLM的信息缺口。典型流程如下：
这种模式虽然有效，但用户体验差、效率低，且无法规模化。用户被迫扮演“模型的手和脚”，这与智能化的目标背道而驰。
为了提高自动化程度，开发者开始编写代理程序，让程序代替用户完成信息获取动作。例如：
在这种模式下，这个封装了特定逻辑、能够自动响应模型需求并执行外部动作的程序，被称为Agent（智能体）。
从技术视角看，Agent的本质可以拆解为：
| 层次 | 说明 |
|---|---|
| 封装层 | Agent是一个可独立运行的程序单元，对外暴露调用接口 |
| 逻辑层 | Agent内部封装了特定领域的处理逻辑，如联网搜索、数据库查询、文件读取 |
| 交互层 | Agent接收来自LLM的指令或请求，执行后返回结构化结果 |
值得强调的是，Agent的实现并不一定需要复杂的框架。早期很多Agent的实现仅仅是通过Prompt扩展完成的。例如，开发者在系统提示词中告知模型：“如果用户询问天气，请输出特殊格式的指令，由外部程序解析并执行。”这种朴素的实现方式虽然简陋，但已经具备了Agent的核心特征：模型负责决策，程序负责执行。
Agent解决的核心问题是模型无法自主行动。它把模型的“意图”转化为“动作”，让LLM的能力从纯语言生成扩展到与外部世界交互。理解Agent时，关键不在于它有多少层神经网络或使用了什么复杂算法，而在于它的角色定位：它是模型的手，负责执行模型无法亲自完成的动作。
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种将外部知识检索结果注入模型上下文的技术。其基本流程是：
RAG属于外部信息获取能力的一种。它和Web Search（联网搜索）处于同一层次——都是在模型参数之外补充数据，区别仅在于数据来源不同：
RAG和Agent并非同一层面的概念。从功能定位上来讲：
一个典型的Agent内部可能同时集成RAG能力、API调用能力、计算能力等多种模块。因此，把RAG和Agent当作并列概念进行对比是不准确的。更准确的表述是：RAG是Agent可以调用的一种能力组件。
实现RAG时需要注意几个关键环节：
随着Agent能力的扩展，一个Agent往往需要调用多种外部工具。如果每个工具都直接集成在Agent主程序中，会带来显著的扩展性问题：
这种紧耦合的架构模式严重限制了Agent生态的发展。
MCP（Model Context Protocol，模型上下文协议） 是一套约定规范，用于让Agent能够发现并调用独立的工具服务。它的核心思想借鉴了前后端接口约定的设计哲学——通过标准化协议将Agent与工具解耦。
从本质上讲，MCP并不是一个具体的工具或产品，而是一套通信协议的约定。它定义了Agent与工具服务之间交互的“语法规则”，使得任何遵循该协议的工具都可以被任何遵循该协议的Agent调用。
MCP协议的核心约定可以简化为两个关键操作：
第一个约定：TOOLLIST（工具列表）
Agent向工具服务发起请求，获取当前可用的工具清单。返回结果中包含每个工具的名称、描述、参数格式等信息。这一步类比于前端开发中的“接口文档查询”。
Agent → 工具服务: GET /tools工具服务 → Agent:[{"name": "web_search", "description": "联网搜索", "params": {...}},{"name": "db_query", "description": "数据库查询", "params": {...}}]
第二个约定：TOOLS_CALL（工具调用）
Agent根据工具列表中的描述，选择合适工具并发起实际调用请求。调用请求中需要包含工具名称和结构化参数。
Agent → 工具服务: POST /tools/call{"tool": "web_search", "params": {"query": "今日天气"}}工具服务 → Agent:{"result": "晴，25°C，空气质量良好"}
引入MCP协议后，Agent与工具的关系从“紧耦合”转变为“松耦合”：
这种架构设计显著降低了Agent系统的开发与维护成本，也为工具生态的繁荣提供了基础。
在Agent与MCP的讨论中，Skill是一个容易被忽视但同样重要的概念。从通用技术视角来看，Skill可以被理解为Agent所具备的一项具体能力或一个可执行的功能单元。
一个Skill通常包含：
三者的关系可以类比理解为：
一个Agent可以拥有多个Skill，每个Skill可以独立开发、测试和替换。这种模块化设计使得Agent能力可以逐步累积和迭代。
综合以上概念，一个完整的LLM应用系统通常呈现如下层次结构：
┌─────────────────────────────────────┐│ 应用层（业务系统） │├─────────────────────────────────────┤│ LLM（语言理解与生成） │├─────────────────────────────────────┤│ Agent（任务编排与决策） │├──────────────┬──────────────────────┤│ RAG能力 │ MCP协议层 ││ (知识注入) │ (工具发现与调用) │├──────────────┼──────────────────────┤│ 向量数据库 │ 工具服务集群 ││ 文档知识库 │ (Skill₁, Skill₂...) │└──────────────┴──────────────────────┘
核心链路：用户请求 → LLM理解意图 → Agent决策所需能力 → 通过MCP调用工具/RAG检索知识 → 结果返回LLM → 生成最终回答。
客服Agent通过MCP调用订单查询工具、物流查询工具、退款处理工具等，同时通过RAG从产品手册和FAQ库中检索相关知识，实现“既懂业务又能办事”的智能服务。
开发类Agent通过调用代码仓库查询工具、构建工具、测试工具等，将开发者的自然语言指令转化为具体的开发操作，并在执行后返回结构化结果。
数据分析类Agent通过RAG从企业内部数据库中检索历史数据，通过工具调用执行统计计算或图表生成，帮助非技术用户以自然语言完成数据分析任务。
在实际应用中，开发者需要关注以下问题：
安全与权限：Agent调用工具时涉及数据访问与操作权限，必须建立完善的鉴权机制，避免未授权的数据读取或危险操作。
错误传播：工具执行失败或RAG检索到无关内容时，不应将错误信息无脑注入模型上下文，需要设计过滤和降级策略。
上下文管理：RAG注入的内容和工具返回的结果都会占用Context窗口，需要合理控制信息量，避免关键信息被稀释。
协议规范适配：使用MCP时，需确保工具服务与Agent主程序之间的协议版本兼容，以及参数序列化格式的一致性。
可观测性：完整的请求链路涉及模型、Agent、工具服务多个环节，需要建立覆盖全链路的日志和监控机制，便于问题定位。
回到定义本身：
理解这些概念的关键在于区分它们的层次和角色：Agent是“执行主体”，RAG是“知识补充方式”，MCP是“通信标准”，Skill是“能力单元”。它们共同构成了一套让LLM从“会说话”走向“能办事”的技术体系。在具体实践中，这些概念往往协同出现，理解它们的分工与协作关系，是设计高质量LLM应用系统的基础。