很多团队把 RAG、Agent、MCP、Skill 当成同一层东西在选型，结果检索逻辑塞进工具描述里、工具调用写成提示词、Skill 和 MCP Server 二选一纠结半天。这篇不重复各自定义，而是给一张四层关系图和一张职责对照表，再补上分工定完之后真正要做的工程动作：超时、降级、日志、评测各自该落在哪一层。
很多团队在选型会上把 RAG、Agent、MCP、Skill 摆成一排，像在挑四选一的方案，最后往往落成一个怪东西：检索逻辑写进了工具描述，工具清单塞进系统提示词，Skill 和 MCP Server 纠结半天不知道该做哪个。问题不在技术，在于没先把它们摆到各自该在的位置上。
这篇不重复定义。它给一张纵向关系图、一张职责对照表，再补上分工定完之后真正要干的工程动作——超时、并发、降级、日志、评测分别该落在哪一层。判断标准给到能直接照着做的颗粒度，同时说清什么场景下这套分层纯属多余。
四层关系图：谁在调谁，谁不该管谁
把四者摆成一条纵向链路来看最省事：Skill 是任务级的做法约定，Agent 是决定下一步做什么的执行者，MCP 是把手伸向外部系统的那根管子，RAG 是给模型补资料的取数环节。自上而下的依赖关系是——Agent 可以调用若干 MCP 工具，MCP Server 背后可以是一个 RAG 检索接口，而 Skill 描述的是 Agent 在什么情况下、按什么顺序去用这些工具。
| 层 | 在链路里的位置 | 常见的错位写法 |
|---|---|---|
| Skill | Agent 的行为约定，不直接执行 | 当成 MCP 用，或者写成一段提示词 |
| Agent | 决策与终止判断 | 把接口地址、字段名写进系统提示词 |
| MCP | 能力暴露与参数校验 | 业务规则塞进工具描述，检索也当工具 |
| RAG | 取数、切片、召回与重排 | 承担要不要调工具、要不要重试的决策 |
- 先画链路图再动手，画不出来的地方往往就是后面要重构的地方
- 凡是「什么条件下做什么」的判断，归 Skill；「能不能做」的能力，归 MCP
- 检索是取数动作，不是工具能力，除非它需要多轮交互或外部副作用
- 单一问答场景、没有外部系统要接、也没有多步任务的，压根不需要四层，一个检索接口加一次模型调用就够了
职责对照表：每一层该写什么、不该写什么
分层画完，接下来是往里填东西。填错层的代价通常不是跑不起来，而是排查时找不到责任边界——检索慢了却在改提示词，工具报错却在重训召回。下面按层给一份该写与不该写的对照。
| 层 | 该写 | 不该写 |
|---|---|---|
| Skill | 先查什么再查什么、结果怎么判合格、什么情况下不适用 | 接口地址、鉴权方式、具体字段名 |
| Agent | 决策逻辑、终止条件、步数上限 | 接口细节、切片参数、重排模型选择 |
| MCP | 输入输出结构、失败语义、参数校验规则 | 业务流程分支、提示词模板 |
| RAG | 切片策略、召回与重排、结果格式 | 要不要调工具、要不要重试、要不要改问法 |
- 先写失败语义给每个 MCP 工具定义清楚超时、无结果、权限不足分别返回什么；验证方式是让调用方在拿到错误后能不改代码就决定重试还是换路。
- 再写判定规则把「结果算不算合格」写进 Skill，而不是写进检索层；验证方式是拿一批已知好坏的结果去跑，看判定是否只在 Skill 里触发。
- 最后定终止条件Agent 层必须写明什么情况下停：步数上限、连续无新信息、还是拿到合格结果；验证方式是构造一个永远查不到的任务，看它会不会自己停。
职责写错层，通常不会当场报错，只会在三个月后的某次排查里让你多花一整天。
分工定完还要补的四件事：超时、并发、降级、日志
分工只在纸面上解决「谁负责」，运行时还得解决「慢了、堵了、挂了、贵了分别怎么办」。这四件事如果混成一个大设置，任何一处抖动都会拖垮整条链路。具体秒数和并发上限要看接口的实际延迟基线，去 /tools/speed-test 和 /ai-status 核对当时的数字，别照抄别人的配置。
- 超时按层设：检索、工具调用、模型生成分开配，别用一个大超时兜住全流程
- 并发分两笔账：MCP 并发和检索并发各自设上限，检索结果缓存通常比加机器划算
- 降级要有顺序：检索失败走空上下文继续答，工具失败返回结构化错误交给 Agent 决定，别让整条链一起断
- 日志按层打标：一次请求要能回答「哪一层慢、哪一层错、哪一层贵」，字段口径对着 /tools/quality-check 来定
验收：怎么证明这套分工没白分
分层做得好不好，不看架构图好不好看，看它能不能帮你更快定位问题。验收的思路是把用例按层拆开，让每次失败都能落到具体的层上，而不是只有一个说不清的总分。
| 用例类型 | 主要考哪层 | 先看的信号 |
|---|---|---|
| 只考检索 | RAG | 召回失败率、无结果占比 |
| 只考工具选择 | Agent 与 Skill | 工具选择错误率、无效步数 |
| 多步串联 | 整条链路 | 首字延迟、中途放弃的位置 |
| 工具描述改动后 | MCP 与 Agent | 选择率变化、误触发次数 |
- 分层造用例，分开跑；混在一起测，出了问题谁也说不清是哪一层的锅
- 优先看信号不看绝对值，召回失败率、工具选择错误率、无效步数、首字延迟这几项更能定位分工问题
- 动过 Skill 文案或工具描述就重跑一遍；工具描述改动对选择率的影响，往往比换模型还明显
- 纯探索阶段的内部演示不适用这套：跑通主链路就行，先别铺完整评测集
常见问题
RAG、Agent、MCP 是不是必须一起上？
不是。三者解决的是不同问题：RAG 补资料，Agent 做多步决策，MCP 接外部系统。只缺资料就只上 RAG；任务本身一步就能完成，加 Agent 只会增加不稳定因素。建议先明确当前最痛的是「不知道」还是「做不到」，再决定加哪一层。
Skill 和 MCP Server 到底该选哪个？
看你要的是知识还是能力。Skill 是写给人看、给模型读的流程约定，改起来快，适合「先查 A 再查 B」这种顺序问题；MCP Server 是真正连到外部系统的手，涉及鉴权、写操作、状态变更的必须走它。两者经常一起用，而不是二选一。
分层之后链路变长，延迟涨了怎么办？
先把每一层的耗时量出来，别猜。常见做法是检索结果做短时缓存、能并行的工具调用并行发、把非必要的校验从主链路上挪走。如果延迟主要来自模型生成本身，那要优化的是检索条数和上下文长度，而不是加机器。
