不少人第一次把这四个词摆在一起看就懵了：明明都能让模型干活，为什么还要分这么细？更常见的情况是，需求来了先纠结选哪个，结果把检索层的问题当成工具层的问题去修。这篇不铺原理，只给一套定位思路和对照表，让你先把「这件事该谁干」判断对，再去找对应的落地做法。
第一次把这四个词摆一起看，确实容易懵：明明都能让模型干活，为什么还要分这么细？更常见的情况是，需求一来就开始纠结选哪个，结果把检索层的问题当成工具层的问题去修，折腾几天发现方向就是错的。这篇不铺原理，只给一套定位思路和对照表，让你先把「这件事该谁干」判断对，再去找对应的落地做法。
判断顺序其实很简单：先看模型本身够不够用，再看缺的是资料还是外部动作权限，最后才考虑要不要引入多步调度。顺序错了，后面每一步都在给上一层擦屁股。下面先给类比，再给对照表，最后给接入顺序。
先把四个角色摆到一张桌上：谁出脑子，谁带手脚，谁给资料
最省事的类比是「一个刚入职的聪明人」。模型本身是那个人的脑子，会推理、会表达，但它没见过你公司的内部文档，也没有任何系统权限，光靠脑子只能答公开常识。给它配上「随手能翻的资料柜」，就是检索这一层在干的事；给它配上「能插进公司系统的标准插口」，就是协议那一层在干的事；让它自己决定先翻哪本资料、再去哪个系统里改一条记录，这就是调度层的活。
- 模型层
- 负责理解与生成，是整条链路里唯一会「思考」的部分
- 上下文供给层
- 负责在回答之前把相关资料塞进提示词，补的是「知道什么」
- 协议层
- 负责用统一方式接上外部系统，补的是「够得着什么」
- 调度层
- 负责拆解目标、决定先做什么后做什么，补的是「怎么一步步做完」
- 四者不是四选一的替代关系，真实系统里通常同时在场，只是分工不同
- 分两层看更清楚：模型与上下文供给属于「知道什么」，协议与调度属于「能做什么」
- 只有一层在动的时候问题最好定位，两层叠一起出错，往往要花成倍时间二分排查
- 如果需求只是单轮问答、资料本来就能直接写进提示词，后面两层加上去只会增加故障面
需求来了先判断动哪一层：一张对照表加排查顺序
拿不准的时候，对照下面这张表找现象。注意「答不准」和「拿不到私有资料」看着像一回事，落脚点完全不同：前者大概率是提示词或资料切分的问题，后者才是检索层进场。改错层最典型的症状是，你加了一堆工具调用，模型照样答不出公司内部的数字。
| 你看到的现象 | 大概率该动的那一层 | 先做的动作 |
|---|---|---|
| 答非所问、格式不稳 | 模型层（提示词） | 把指令写清、给输出示例，单轮先测 |
| 问公司内部资料就胡说 | 上下文供给层 | 先确认资料能不能被检索到，再看切分粒度 |
| 要它去查库存、发工单 | 协议层 | 先确认外部系统有没有可调用的接口 |
| 要完成「先查再改再通知」 | 调度层 | 先把每步单独跑通，再串联 |
| 换了模型结果忽好忽坏 | 模型层 | 固定一批样例，逐个模型对比 |
- 第一步：问模型能不能独立答用不带任何资料的提示词试一遍，答得对就不用往下走；这段话也顺手当了后面的基线。
- 第二步：问缺的是资料还是动作权限缺资料就补上下文供给层，缺动手能力才上协议层；两者都缺时，先补资料，因为检索比接系统好验证。
- 第三步：再决定要不要多步调度只有当任务本身需要多轮、多工具协作时才引入调度层，否则单步调用更稳。
有一个场景不适用这套顺序：如果问题根源是提示词没写清或者输出格式不稳定，先回到模型层改提示词，别急着加架构。很多「上了检索还是不灵」的案子，最后发现是问题问得含糊，检索出来的东西自然也对不上。
叠起来会怎样：延迟、成本、排错难度的变化
每加一层都要多走一次往返。检索多一次查询，工具多一次外部调用，调度可能多好几轮模型调用，整体延迟和调用次数都会往上走。具体涨多少，别凭印象估，去 /price-watch 核对当时的数字，再拿自己的样例实测一遍，两者对得上再下结论。
更麻烦的是排错复杂度。它是叠加上去的：检索层召回不准，上层看到的输入就是错的，你再怎么调工具也救不回来。所以正确做法是按层验证，而不是只看最终输出对不对。
- 模型层：单独测，固定一批样例，先看基线的输出质量与响应时间
- 上下文供给层：单独看召回了什么，把召回的原文调出来人工扫一遍
- 协议层：单独调一次外部接口，先确认返回值本身是对的
- 调度层：看它走了几步、在哪一步停、有没有终止条件
- 联调时：每加一层都用同一批样例对比加之前的结果，否则说不清是谁的功劳
动手时的最小接入顺序：从一层开始，逐层加
顺序对了，工程量能少一大截。第一步永远是把模型单独跑通，确认延迟与输出质量的基线。测速这块可以先用 /tools/speed-test 量一遍，把响应时间和稳定性记下来，后面每加一层再复测一次，变化才看得清。基线的价值在于：没有它，你后面所有「变慢了」都是感觉。
- 第一步：模型单跑只用提示词，不加资料不加工具，跑一批真实样例，记下输出质量与响应时间作为基线。
- 第二步：只加你要的那一层缺资料就只加检索，缺动作就只接工具，加完立刻用同一批样例和基线对比，别一次叠两层。
- 第三步：再补另一层确认上一层稳了再补，并且给工具调用设步数上限与超时，避免一次请求无限套娃。
- 第四步：给调度层设终止条件明确最多走几步、什么情况算失败退出，否则一次异常可能拖很久。
有一个情况要反着来：团队只有一个人维护时，宁可少一层稳一层。多出来的那一层，日常排错时间往往比它省下的开发时间更贵。真需要加，也先把每层的独立测试用例留下来，不然下次出问题还是从零查起。
先判断清楚这件事该谁干，再去想怎么干；层数不是越多越先进，能少一层就少一层。下一步把你手上的需求按那张对照表过一遍，确认该动哪一层；顺便到站内工具目录看有没有现成的检索或工具接入方案，能省掉自己搭一层的时间。→
常见问题
RAG 和 MCP 到底是不是一类东西，为什么总被放一起比？
不是一类。RAG 解决的是「模型该看哪些资料」，管的是上下文供给；MCP 解决的是「模型怎么去够到外部能力」，管的是调用方式。它们能被放一起比，是因为在同一个问题里常常同时出现——既要查私有资料，又要去执行动作，但改起来是两条独立的线，别指望换一个就顺带解决另一个。
那 Agent 是不是就是 RAG 加 MCP？
不是简单的加法。Agent 指的是由模型自己决定下一步做什么、做几轮，RAG 和 MCP 都可能只是它手里的一个环节。反过来，你可以只用 RAG 不给调度，也可以只用 MCP 不碰检索。判断标准是：要不要模型自主决定步骤和轮数，要才是 Agent 那一层的事。
四个词都听过之后，实际做项目该从哪个开始？
从最小可用的那层开始：先把模型单跑通，确认输出质量与延迟基线；如果缺的是私有资料就只加检索，如果缺的是执行能力就只加工具调用。一次只加一层，加完用同一批样例对比。多层一起上，出问题时你分不清是哪一层的锅，排错时间会比开发时间还长。
