刚接触智能体的人最容易卡在名词堆里：Agent、MCP、RAG、Skills 一起出现，看着都像「给模型加能力」，实际分工完全不同，选错方向就会白写一堆代码。这篇不讲原理，只给一张分工对照表和一套接入顺序：先判断你的瓶颈是「要动手」「要外部数据」「要固定套路」还是「要串起流程」，再决定先动哪一块，并用最小验证确认接对了。
刚接触智能体的人最容易卡在名词堆里：Agent、MCP、RAG、Skills 一起出现，看着都像「给模型加能力」，实际分工完全不同。判断错方向，可能埋头写了两周工具调用，结果真正的毛病是模型压根没拿到正确资料。
这篇不讲原理，只给一张分工对照表和一套接入顺序。思路很简单：先判断你的瓶颈是「要动手」「要外部数据」「要固定套路」还是「要串起流程」，再决定先动哪一块，每加一层都做一次最小验证，确认接对了再往上堆。
一张表分清四件事各管什么
先把角色摆正：Agent 是调度层，决定先做什么、调谁、什么时候停；其余三样都是它手里的资源。RAG 管「知道」，MCP 管「做到」，Skills 管「怎么做」。下面这张表建议存下来，遇到名词混用时就翻出来对一遍。
| 名字 | 管什么 | 典型表现 | 什么时候不该用它 |
|---|---|---|---|
| Agent | 调度与决策 | 拆解目标、选择调用哪个资源、决定何时收尾 | 任务一步就能答完，加编排只是多绕一圈 |
| RAG | 外部数据临时进上下文 | 资料常变、要求答案可溯源到原文 | 资料几乎不变且很短，直接写进提示词更省事 |
| MCP | 把外部系统能力按统一方式暴露出来 | 要查库、发消息、改工单这类会改状态的动作 | 只读一次性问答，不需要执行任何动作 |
| Skills | 固定套路与判断标准 | 步骤稳定、输出格式要求一致、多人共用 | 流程本身还在频繁改，过早固化反而难维护 |
注意一个常见误解：RAG 不改模型权重，它只是把检索到的内容临时塞进上下文；而 MCP 的重点是「能执行、能改状态」，跟「知道」是两回事。把这两个混为一谈，就会出现「检索做得很漂亮，但系统还是什么都不会做」的尴尬。
先接哪个：按瓶颈选，不按热度选
选型顺序不看哪个词火，看你现在最疼的是哪一块。把症状和动作对上号，能省掉大量无效开发。下面四组判断标准按出现频率从高到低排，命中就先做那一块。
- 答非所问、明显编造事实：先补 RAG，重点查资料切分粒度和召回，是否真的把正确段落带回来了
- 需要查库、发消息、改工单：先补 MCP 或同类工具调用，同时给工具加白名单和参数校验
- 每次都得重新讲一遍流程、输出格式老不统一：先沉淀 Skills，把步骤、边界和输出格式写死
- 以上都不缺但就是串不起来：问题在 Agent 编排本身，先缩减步数、加人工确认点，别急着扩能力
这里有个不适用的情况要讲清楚：如果你的场景是单轮问答、资料基本不变、也不需要执行任何动作，那补 MCP 和 Skills 只会让系统更复杂。复杂度是要还债的，能不加就不加。
接入顺序清单与最小验证
顺序上建议老老实实一层一层来：先把单轮调用跑通，再加检索，再加工具，最后才让 Agent 自主多步走。每加一层单独测一次，出问题才定位得到是哪一层的锅。下面这套步骤按顺序执行即可。
- 第一步：跑通单轮调用先用一件最简单的事确认模型调用、鉴权和返回解析都正常。验证方式是固定输入、固定输出，不引入任何外部资源。
- 第二步：验证 RAG 召回拿一条你已知答案的问题，重点看返回里是否真的带回了对应段落。不要只看答案像不像，要看召回内容对不对。
- 第三步：验证 MCP 工具先手动触发一次工具调用，确认鉴权、参数格式和返回结构都对，再把它放进自主循环里让模型自己决定何时调。
- 第四步：验证 Skills 稳定性同一输入连跑几次，看步骤和输出格式是否一致。不稳定说明写得还不够具体，回去补边界条件和判断标准。
- 第五步：最后才放开多步前面四步都稳了，再让 Agent 自主串联。这时候出错，基本可以断定是编排逻辑问题，排查面小很多。
关于各项能力的实际开销和额度限制，站内会持续追踪，具体数字到站内价格追踪页核对当时的数值即可，不要凭印象拍板。
别忘了超时、并发和日志这三道护栏
能力接上之后，真正让你半夜被叫起来的大多是超时、并发和排查困难，而不是模型本身。这三样在动手前就该定好规则，别等出事再补。
- 超时按层设：检索、工具调用、模型生成各设各的阈值，别用一个总超时兜底，不然分不清卡在哪一层
- 并发要压住：工具调用会放大请求量，按额度分档设并发上限，并留退避重试的空间
- 日志至少记四项：请求标识、用了哪个工具或检索源、耗时、返回状态；不然出问题只能靠猜
- 给工具调用留人工确认点：涉及改状态、发消息、写数据的动作，先确认再执行
判断标准也简单：如果一次失败你没法从日志里看出是检索没召回、工具报错还是模型超时，那这套护栏就还没搭好。
往下读之前先对齐口径
最后给几个务实的提醒。名词拿不准先去站内查一轮，避免把「工具调用」和「Agent」混着用；挑框架之前先看目录里它对你选的扩展方式支持到什么程度；最重要的，别一上来就把四样全上。
能跑通一层再加一层，是这套东西唯一不容易翻车的节奏。每加一层都留一次单独验证，问题自然就落在小范围内。
下一步先到站内词典把名词口径对齐，再去框架目录确认你手上的工具支持哪种扩展方式，动手前把这两件事做完，能少走不少弯路。→常见问题
Agent、MCP、RAG、Skills 是必须一起用吗？
不是。四者解决的是不同问题：RAG 补外部资料、MCP 补执行能力、Skills 补固定流程、Agent 负责调度。只用 RAG 做问答完全成立，只用 Skills 做固定套路也成立。只有当你确实需要「自己决定调谁、多步执行」时，Agent 才有必要上场。
RAG 和 MCP 到底该先上哪个？
看你的失败长什么样。回答里事实错误、查不到内部资料，先上 RAG；需要去实际系统里查状态、改数据，先上 MCP。两者不冲突，也可以并存：用 RAG 提供依据，用 MCP 执行动作。先上哪个，取决于当前最疼的那一类问题。
Skills 和写一段长提示词有什么区别？
长提示词是一次性的上下文，Skills 是把步骤、边界和输出要求沉淀成可复用的单元。区别在稳定性和维护：同样的任务反复做、要求每次输出一致时，Skills 更合适；只是一次性问答或探索性任务，写提示词更省事，不必封装。
