从RAG到Agent：构建智能系统的核心组件逻辑拆解

1. 从“概念满天飞”到“逻辑一锅端”为什么我们需要拆穿这些技术最近和不少同行聊天发现一个挺有意思的现象Skill、MCP、RAG、Agent、OpenClaw……这些词在技术圈里越来越高频几乎成了每个技术分享会、每篇行业分析报告的“标配”。但聊深了很多人其实是在“复读”概念比如“我们用了RAG增强大模型”、“我们正在构建Agent工作流”再追问一句“具体是怎么实现的这几个东西在你系统里到底是怎么串起来的”往往就语焉不详了。这感觉就像手里拿了一堆乐高积木的零件每个零件概念都包装精美说明书技术博客也告诉你它能干什么但真让你拼出一辆能跑的汽车一个可用的系统却不知道从哪块开始搭也不知道零件之间怎么卡扣。更麻烦的是这些概念的定义边界本身就在快速演变不同厂商、不同框架下的“Agent”可能指代完全不同的东西这就导致了大量的混淆和“鸡同鸭讲”。所以今天我不打算再单独介绍任何一个概念。我的目标是像拆解一台精密的机械钟表一样把这五个常被并列提及的技术“热词”——Skill、MCP、RAG、Agent、OpenClaw——的底层逻辑彻底拆穿。我们要看的不是它们各自华丽的宣传页而是它们作为“系统组件”时内部的齿轮是如何咬合的动力是如何传递的。我会用一个贯穿始终的虚拟场景——“智能旅行规划助手”——来具象化每一步让你看完之后不仅能说清每个是什么更能理清它们在一个真实、可运行的系统中究竟扮演什么角色以及最重要的它们之间到底谁依赖谁谁调用谁数据流和控制流是怎么走的。2. 基石与燃料RAG如何成为系统的“长期记忆体”我们首先从RAG检索增强生成开始因为它往往是整个智能系统得以构建的“数据基石”。没有高质量、可信的数据输入后续所有的“思考”和“行动”都是空中楼阁。2.1 RAG的本质不是“增强”而是“约束与接地”很多人把RAG简单理解为给大模型“联网搜索”或“查资料”这个理解太浅也容易导致后续设计出现偏差。RAG的核心逻辑我称之为“用确定性的知识约束生成过程的不确定性”。大语言模型LLM本质是一个基于海量数据训练的概率模型它“擅长”的是根据上文生成概率上最合理的下文。这带来了两大问题1.幻觉它可能生成听起来合理但完全错误的事实。2.信息滞后它的知识截止于训练数据无法获取最新或私有信息。RAG的解决方案非常“工程化”它不试图改变LLM的内部机制那太难了而是在LLM的“输入端”做文章。具体流程分三步索引Indexing将你的知识库文档、数据库、API文档等进行切片、向量化存入向量数据库。这一步的关键是“切片策略”切得太碎失去上下文切得太大检索不准。对于旅行场景我们可能将城市攻略、酒店政策、航班时刻表分别处理。检索Retrieval当用户提问“帮我推荐一下东京三天两夜的行程”时系统不是直接把问题扔给LLM而是先将问题向量化去向量数据库中查找与之最相关的“知识片段”Top-K个。这里的关键是“检索器”的质量和“相似度阈值”的设置。生成Generation将检索到的相关片段作为“证据”或“参考”和用户的原始问题一起组合成一个新的、更丰富的提示Prompt交给LLM并指令它“请基于以下提供的资料回答用户的问题。” 这相当于给天马行空的LLM套上了“缰绳”。在旅行助手场景中用户问“京都岚山小火车三月的班次多吗”。没有RAGLLM可能基于过时的记忆瞎编。有了RAG系统会先从最新的岚山观光铁路官网抓取并索引的文档中检索出“三月班次表”和“樱花季特别加开通知”的片段连同问题一起交给LLM。LLM的生成就被“锚定”在了这些真实信息上输出可信的答案。所以RAG是静态知识的接入层。它让系统具备了“长期记忆”和“事实核查”能力是后续一切“智能行动”的燃料和依据。没有准确的数据检索Agent的决策就是盲目的。2.2 实操中的坑RAG不等于开箱即用理解了原理实操时才会避开这些坑“垃圾进垃圾出”的向量化直接用通用模型如text-embedding-ada-002对专业领域文档做向量化效果可能很差。例如航班代码“CA1501”和“国航1501”在语义上应该接近但通用模型可能无法理解。解决方案是使用领域数据微调嵌入模型或在切片时加入元数据如“此为航班号”。检索精度不足简单的相似度检索可能找不到真正相关的信息。比如用户问“适合带老人去的轻松景点”检索出的可能是“景点人气排行榜”而不是“无障碍设施完善”的景点描述。需要引入重排序Re-ranking模型对初步检索结果进行二次精排或者使用混合检索结合关键词检索和向量检索。上下文长度与信息丢失检索出的Top-K个片段在拼接到Prompt里时可能超过LLM的上下文窗口。你需要一个“摘要”或“精炼”层或者设计更智能的切片/检索策略确保送进去的都是精华。提示不要把RAG当成一个黑盒魔法。搭建RAG流水线时务必设计一个评估体系比如回答的准确性、引用来源的相关性。这是迭代优化的唯一依据。3. 能力的模块化封装Skill与MCP如何定义“能做什么”有了数据RAG系统现在“知道”了一些事情。接下来它需要“能做”一些事情比如查询实时航班、预订酒店、计算汇率。这就是Skill和MCP登场的时候。它们解决的是“能力调用”的标准问题。3.1 Skill原子化的“可执行动作”你可以把Skill理解为一个单一的、功能明确的“小程序”或“API封装”。每个Skill完成一件具体的事。在我们的旅行助手系统中search_flights_skill: 输入出发地、目的地、日期调用航司或OTA的API返回航班列表。book_hotel_skill: 输入酒店ID、入住信息调用预订API返回订单号。get_currency_rate_skill: 输入货币对调用汇率API返回实时汇率。rag_query_skill: 这其实是我们上一章构建的RAG查询流程的封装。输入自然语言问题返回基于知识库的答案。Skill的核心特点是接口标准化。无论内部是调用REST API、执行数据库查询还是运行一段脚本对外主要是对Agent都暴露一个统一的调用方式通常包括技能描述、所需输入参数格式、返回结果格式。3.2 MCPSkill的“运行环境”与“通信协议”如果说Skill是一个个独立的家电冰箱、洗衣机那么MCPModel Context Protocol模型上下文协议就是为这些家电提供标准电源插座、通信协议和遥控器的“智能家居平台”。它是由Anthropic提出并开源的一套协议旨在标准化LLM与外部工具Skill之间的交互方式。MCP的核心价值在于解耦和标准化对LLMAgent而言它不需要知道每个Skill的具体实现和调用地址。它只需要和MCP服务器通信。MCP服务器会告诉LLM“我这里有哪些可用的工具Skill每个工具怎么用参数说明。” LLM做出使用决策后只需发出标准化指令MCP服务器会负责找到对应的Skill并执行。对Skill开发者而言你只需要按照MCP的协议格式通常是一个JSON Schema来定义你的Skill并注册到MCP服务器上你的Skill就能立刻被任何兼容MCP的LLM所发现和使用无需为每个LLM做适配。在旅行助手场景中我们开发了search_flights_skill并按照MCP协议将其注册到本地的MCP服务器上。当我们的Agent比如基于Claude或GPT启动时它会连接这个MCP服务器。MCP服务器会返回一个工具列表“可用的工具有1. 航班搜索参数from, to, date 2. 酒店预订参数hotel_id, check_in…” Agent在规划行程时就能自然地“知道”它可以调用这些工具并通过MCP服务器来执行调用。MCP与普通API网关的区别MCP是专门为LLM设计的“工具发现与调用层”它更强调对自然语言的友好性比如工具的描述是为LLM理解的并且通常支持动态的工具注册与发现更加灵活。3.3 为什么需要这套组合从“硬编码”到“动态编排”没有Skill和MCP的抽象我们往往会把工具调用逻辑硬编码在Agent的提示词或代码里“如果用户要查航班就调用http://api.example.com/flights。” 这带来巨大的维护成本每增加一个工具就要修改Agent的代码工具接口变了Agent也得跟着改。有了SkillMCP系统架构变得清晰Skill层关注“如何做好一件事”是能力的实现者。MCP层关注“如何让Agent知道并能调用这些事”是能力的路由者和协议转换者。Agent层下一章详述关注“在什么情况下、为了什么目标、去调用哪件事”是能力的调度者和决策者。这就实现了动态的能力扩展。你开发了一个新的weather_forecast_skill只需注册到MCP服务器Agent在下一次运行时就能自动获得这个新能力无需停机升级。4. 大脑与决策中枢Agent如何调度一切完成目标现在我们的系统有了“记忆”RAG和“手脚”Skill via MCP。谁来指挥手脚、利用记忆去完成一个复杂的用户目标呢这就是Agent智能体的角色。Agent是系统的“大脑”和“决策中枢”。4.1 Agent的核心循环感知-规划-执行-反思一个典型的任务型Agent如ReAct模式的工作流是一个循环感知Perception接收用户输入的目标如“为我规划一个为期一周的日本关西深度游预算中等喜欢文化和美食。”规划Planning将宏大目标分解为可执行的子任务序列。这一步极度依赖LLM的推理能力。它可能会生成一个计划“步骤1通过RAG查询关西地区大阪、京都、奈良的核心文化美食景点。步骤2根据查询结果和用户‘预算中等’的偏好通过Skill搜索大阪和京都中心区域的酒店。步骤3根据酒店位置通过Skill查询城市间的交通方式火车票。步骤4整合信息生成每日详细行程草案。”执行Execution根据规划逐步执行子任务。这里就是调用MCP暴露的Skill。例如执行“步骤1”时Agent会构造一个查询“关西地区大阪、京都、奈良有哪些代表性的文化景点和美食街区适合中等预算。” 然后调用rag_query_skill。拿到结果后触发“步骤2”调用search_hotels_skill。反思Reflection观察执行结果判断是否偏离目标或遇到问题。例如搜索酒店后发现预算内的酒店全部满房Agent需要“反思”“酒店预订失败需要调整计划要么扩大搜索范围如住稍远一点要么调整旅行日期。” 然后重新进入规划阶段调整计划。这个循环会一直进行直到所有子任务完成最终将结果整合输出给用户或者遇到无法逾越的障碍如所有航班售罄并向用户报告。4.2 Agent的“思考过程”暴露为什么Chain-of-Thought很重要一个强大的Agent不应该是一个黑盒。在开发调试时我们必须能看到它的“思考链”。这就是为什么大多数Agent框架如LangChain, LlamaIndex的Agent都会强烈支持并展示Chain-of-Thought思维链。在旅行助手场景中用户说“我想去个暖和的地方潜水”。一个没有思考链的Agent可能直接调用search_flights_skill目的地参数却不知道填什么。而一个有思考链的Agent它的内部推理过程可能是这样的思考用户想要“暖和”和“潜水”。我需要先理解哪些地方符合这个条件。 行动调用rag_query_skill查询“全球哪些海岛或沿海地区在[当前月份]气候温暖且适合潜水” 观察RAG返回了“泰国普吉岛11月-4月旱季水温适宜”、“马来西亚仙本那”、“菲律宾长滩岛”等信息。 思考用户没有指定出发地。我需要询问用户出发城市以便搜索航班。 行动向用户提问“请问您从哪个城市出发呢”这个“思考-行动-观察”的链条让我们能够诊断Agent在哪里出了问题是RAG检索的信息不对是规划的逻辑有误还是Skill调用失败了这对于构建可靠的系统至关重要。4.3 多Agent协作当任务复杂到需要“团队”单个Agent的能力可能有瓶颈。对于极度复杂的旅行规划比如涉及跨国多城市、会展、商务接待、家庭旅游的组合我们可以引入多Agent系统规划Agent专门负责宏观任务分解和资源协调。研究Agent专门负责调用RAG深入研究目的地信息、签证政策、风俗禁忌。预订Agent专门负责与各种预订Skill交互处理航班、酒店、门票的查询与下单。预算Agent专门负责跟踪和控制各项开支确保不超预算。这些Agent通过一个“协调者”或者通过共享的工作区如黑板模式进行通信与协作。这就像是组建了一个专业的旅行策划团队每个人各司其职共同完成大项目。5. 框架与基础设施OpenClaw及其他框架扮演的角色当我们谈论Skill、MCP、RAG、Agent时我们是在谈论概念和组件。而要把这些组件高效、稳定、可维护地组装成一个完整的应用我们需要框架和基础设施。这就是OpenClaw以及LangChain、LlamaIndex、AutoGen等框架的用武之地。5.1 OpenClaw的定位一体化的智能体开发与部署平台根据其官方描述和设计理念OpenClaw的目标不仅仅是另一个Agent框架它更像一个“开箱即用的智能体操作系统”。它试图将我们前面讨论的所有层级整合到一个统一的平台中基础设施层它可能提供了内置的向量数据库连接器、模型网关方便切换不同的LLM简化了RAG和模型调用的基础设置。能力层它很可能原生支持或深度集成了MCP协议让Skill的注册、发现和管理变得非常方便。你可能不需要自己搭建MCP服务器而是在OpenClaw的界面里配置你的Skill。智能体层它提供了可视化的Agent工作流编排工具。你可以通过拖拽的方式将RAG查询节点、条件判断节点、Skill调用节点、LLM推理节点连接起来构建复杂的Agent逻辑而无需编写大量胶水代码。部署与运维层它可能关注于如何将你编排好的智能体打包成API服务或应用并提供监控、日志、版本管理等生产级功能。简单比喻如果说LangChain是给了你一套丰富的乐高零件和拼接手册低代码/代码优先那么OpenClaw更像是给了你一个已经搭好主体结构、并配有图形化组装界面的机器人套件高代码/配置优先让你能更关注业务逻辑而非底层通信。5.2 主流框架的横向对比与选型思考了解OpenClaw的同时我们也需要知道其他选项才能做出合理选型LangChain生态最繁荣的“瑞士军刀”。它的核心价值在于提供了大量的“链”Chain和“代理”Agent模板以及数以百计的第三方工具集成。它非常灵活但学习曲线较陡需要你亲手用代码组装一切。适合需要高度定制化、技术能力强的团队。LlamaIndex最初专注于RAG现已发展为强大的数据层框架。它在数据连接、文档处理、高级检索如子查询、多步检索方面非常出色。它的Agent抽象也更偏向于“基于数据的智能”。如果你的应用核心是复杂RAGLlamaIndex是绝佳起点。AutoGen由微软推出专注于多智能体对话。它让创建多个能相互对话、协作的Agent变得异常简单。如果你的场景本质上是需要多个专家角色通过讨论来解决问题如产品设计评审、复杂谈判模拟AutoGen是首选。OpenClaw如前所述强调整体平台和开箱即用。如果你的团队希望快速搭建一个功能全面的智能体应用且不希望深入太多底层细节或者需要一个统一的管理控制台OpenClaw这类一体化平台值得评估。选型关键点没有最好的只有最合适的。问自己几个问题你的团队更擅长编码还是配置你的应用核心是复杂RAG、复杂工作流还是多Agent协作你对生产级部署和监控的需求有多强回答这些问题才能找到最适合你的“脚手架”。6. 逻辑串联与实战推演构建“旅行规划助手”全流程现在让我们把前面所有拆解的零件按照真实的系统运行逻辑串联起来看看从用户输入到最终输出数据和控制流是如何流动的。假设我们使用一个以OpenClaw为基座集成了自定义Skill和RAG的系统。场景用户输入“我下个月15号从北京出发想去日本玩5天预算1万左右请帮我做个计划。”系统内部推演入口与初始化用户请求到达系统后端。后端初始化一个“旅行规划主Agent”该Agent在OpenClaw平台中已被预先编排好基础工作流。OpenClaw平台为该Agent注入初始上下文可用的LLM如GPT-4、已连接的知识库RAG向量索引、以及通过MCP协议发现的所有已注册Skill列表航班搜索、酒店查询、RAG问答、天气查询、汇率换算等。阶段一需求分析与信息收集Agent规划 RAG主Agent启动“规划”阶段LLM分析用户请求识别出关键约束时间下个月15号5天、出发地北京、目的地日本、预算1万。子任务生成LLM规划出第一步“需要确定具体目的地城市和可行行程。先查询日本在对应季节的旅游推荐和预算情况。”执行RAG查询Agent通过MCP调用rag_query_skill传入查询“从北京出发5天日本旅行预算1万元人民币左右下个月15号左右出发有哪些推荐的行程和城市组合请考虑交通时间和费用。”获取知识rag_query_skill从向量数据库中检索出相关的旅行攻略、博客文章、预算分析片段组合成提示词发送给LLM得到一份初步的文本建议例如“推荐关西地区大阪、京都、奈良或东京周边。5天关西游较为宽松预算可控。东京周边可搭配镰仓、箱根。”Agent反思与决策主Agent收到RAG的答案后进行“反思”“信息给出了两个方向。需要用户选择或根据更细的偏好决定。”由于用户未指定Agent决定先提供选项并询问偏好。阶段二交互细化与实时查询Agent决策 Skill调用Agent与用户交互主Agent通过系统向用户输出“根据您的预算和时间推荐关西地区大阪、京都、奈良或东京周边游。您更偏好传统文化关西还是现代都市与周边结合东京”用户响应用户选择“关西”。Agent继续规划LLM更新计划“用户选择关西。下一步需要核实具体日期下个月15号的航班和酒店可行性以确认预算。”执行实时查询Agent通过MCP调用search_flights_skill参数from北京 to大阪 date下个月15号。Skill调用外部航班API返回航班列表和价格。Agent再调用search_hotels_skill参数city大阪 check_in下个月15号 nights4。Skill返回酒店列表和价格。Agent进行预算核算与调整LLM收到航班和酒店数据后进行计算“往返机票约3000元4晚酒店约2500元剩余4500元用于交通、餐饮、门票。基本符合预算。但需要预留弹性。” Agent可能决定调用currency_rate_skill查询日元汇率以更精确计算。阶段三整合与输出Agent生成信息整合主Agent将RAG提供的景点信息、Skill查询到的实时航班酒店信息、预算核算结果全部作为上下文发送给LLM。最终生成LLM基于所有这些“记忆”和“事实”生成一份结构化的、个性化的旅行计划草案包括每日行程、航班酒店建议、预算分配、注意事项等并通过系统呈现给用户。在整个流程中RAG提供了静态的、背景性的知识去哪玩有什么景点。Skill提供了动态的、操作性的能力查航班、订酒店。MCP让Agent能够无缝地、标准化地发现和调用这些能力。Agent是总指挥负责理解目标、制定计划、决定在何时调用何种子能力RAG或Skill并处理过程中的意外。OpenClaw是舞台和调度中心它提供了让Agent、RAG、Skill通过MCP能够高效协作运行的环境和工具链。7. 避坑指南从概念到落地的关键挑战理解了逻辑但在真正动手构建时你会遇到一系列非常实际的挑战。以下是我从多个项目中总结出的核心避坑点7.1 幻觉的“转移”而非“消除”这是对RAG最大的误解。很多人以为上了RAG就万事大吉。实际上RAG并不能完全消除幻觉它只是把幻觉的风险从“无中生有”转移到了“错误关联”或“错误解读”。坑检索到了正确的文档片段但LLM在生成时错误地组合或解读了这些片段的信息。例如文档A说“景点A周一闭馆”文档B说“景点B周二闭馆”。当用户问“周二哪些景点闭馆”时LLM可能错误地回答“景点A和B都闭馆”。应对提示词工程在Prompt中强化指令如“请严格仅根据提供的资料回答问题如果资料中没有明确提及请回答‘根据现有资料无法确定’。”引用溯源要求LLM在回答时标注出答案所依据的原文片段引用。这不仅能增加可信度也便于人工复核和调试。后处理校验对于关键事实如价格、日期可以设计简单的规则或另一个小的校验模型对输出进行二次检查。7.2 Agent的“规划漂移”与无限循环Agent的自主规划能力是一把双刃剑。它可能陷入死循环或者制定出完全不切实际的计划。坑在旅行规划中Agent可能规划出“上午在大阪中午在京都下午在奈良”这种地理上不可能实现的行程。或者在查询酒店失败后它可能不断重复“搜索酒店-失败-再搜索同一家酒店”的循环。应对设定明确的约束与超时在Agent的初始指令或系统层面设定最大步数Max Steps或最长思考时间。超过限制则强制终止并反馈给用户。提供世界模型或常识通过RAG或硬编码规则向Agent注入一些基本常识约束。例如在知识库中加入“大阪到京都乘坐特急列车约30分钟”、“同一酒店房态短时间内不会变化”等信息。设计细粒度的反思触发条件不要只让Agent在失败后反思。可以设定在关键决策点如确定城市后、预订前强制进行反思评估当前计划的合理性。7.3 Skill设计的“语义鸿沟”问题LLM理解的自然语言指令与Skill需要的结构化API参数之间存在巨大的鸿沟。坑用户说“找个离地铁站近的便宜酒店”。LLM需要将其转化为search_hotels_skill的调用参数可能包括location地铁站附近这需要地理编码price_range便宜这需要定义阈值。这个转换极易出错。应对丰富的Skill描述在MCP注册Skill时提供极其详尽、包含示例的自然语言描述帮助LLM理解何时以及如何使用该技能。例如“此技能用于搜索酒店。参数‘max_price’指每晚最高预算单位为人民币。‘location’可以是地标名如‘心斋桥’系统会尝试解析其坐标。”参数规范化与验证在Skill内部或MCP层对传入的参数进行清洗、标准化和验证。例如将“便宜”映射到一个具体的价格区间如0-400元或者调用地理编码服务将“离地铁站近”转换为一个坐标和半径。分层Skill设计对于复杂查询可以设计一个“酒店需求分析Skill”先由LLM调用它将用户模糊需求转化为结构化查询对象再由这个Skill去调用底层的search_hotels_skill。7.4 评估与监控的缺失这是项目从Demo走向生产最大的拦路虎。一个智能系统没有量化评估就像蒙着眼睛开车。坑不知道RAG的检索准确率是多少不知道Agent的任务完成成功率是多少出了问题无法快速定位是哪个环节RAG、Agent逻辑、Skill API导致的。应对建立分阶段评估体系RAG层评估检索相关性RecallK、答案准确性基于检索片段的QA准确率。Agent层评估任务完成率、步骤效率平均完成步数、人工满意度评分。Skill层评估API调用成功率、响应延迟。全链路日志与追踪必须记录每个用户会话的完整“思考链”包括Agent的每一步决策、调用的每一个Skill及其输入输出、每一次RAG检索的查询和结果。这是调试和优化的唯一依据。OpenClaw这类平台通常会在这一点上提供内置支持。设计人工审核与干预通道对于关键操作如实际下单、支付或当系统置信度较低时必须设计流程让人工介入确认。走到这一步你会发现拆穿这些“热词”的底层逻辑最终目的不是为了堆砌时髦的技术而是为了清醒地设计。你知道RAG是你的知识库Skill是你的手脚MCP是你的神经接口Agent是你的大脑而框架是你的骨架和神经系统。当用户提出一个需求时你脑子里能清晰地映射出数据流将如何穿过这些组件控制流将如何决策以及可能在哪里卡住。这份清晰的蓝图才是应对这个快速变化领域最大的底气。剩下的就是在具体项目中针对每一个环节做扎实的工程实现、持续的数据喂养和耐心的调优迭代了。