llm rag mcp agent

刚开始接触大模型开发的人，几乎都会在同一堆词里绕晕：有人说 prompt 就够了，有人一上来就上 RAG，还有人张口就是 MCP 加 Agent。其实它们不在一个层面上，一个是输入写法，一个是取资料，一个是接工具，一个是自己决定怎么干。这篇不背定义，只讲各自解决哪一类问题、什么时候不需要它，以及按什么顺序往上加最省钱。

刚开始接触大模型开发的人，几乎都会在同一堆词里绕晕。有人说 prompt 就够了，有人一上来就上 RAG，还有人张口就是 MCP 加 Agent。其实它们根本不在一个层面上：一个是输入写法，一个是取资料，一个是接工具，一个是自己决定怎么干。

这篇不背定义，只讲各自解决哪一类问题、什么时候不需要它，以及按什么顺序往上加最省事。看的时候提醒自己一句：每加一层都是成本，能不加就不加。

先分清它们各自站在哪一层

记住一个判断口诀就够了：缺输入就改 prompt，缺知识加检索，缺外部动作就接工具，步骤不固定才用 Agent。很多人一上来就想上 Agent，结果发现流程其实是固定的，白搭一层复杂度。

• prompt 是随时随地都在做的，哪怕你只是聊天也在写 prompt
• RAG 的本质是「先查再答」，模型本身没变，变的是喂给它的上下文
• MCP 只解决接入标准化，接进来之后要不要调、什么时候调，它不管
• Agent 的关键特征是「下一步取决于上一步的结果」，顺序固定就不算
• 四者可以叠用，也可以只用其中一两层，不存在必须全上的说法

什么情况下这一层可以不加

新手最容易犯的错是层次上多了。下面这几条判断标准，能帮你把不必要的组件砍掉，砍掉的部分就是省下来的调试时间。

• 答案在一两段文字里能说清，别上 RAG，直接把资料贴进 prompt 更省事
• 流程完全固定、每步顺序已知，用工作流编排比 Agent 更稳也好测
• 只有一两个接口要调，直接写函数调用即可，不必为了统一而套 MCP
• 检索结果每次都差不多、没有多轮追问，普通 RAG 够用，不必上 Agentic RAG
• 数据量小、更新频繁时，先试关键词或混合检索，不必先建向量库

反过来也有不适用的场景：资料库很大且每天都在变、问题需要跨多份文档拼答案时，硬塞进 prompt 就不现实了，这时候 RAG 是合理选择。哪种方案划算，要看你的资料规模和更新频率，到 /rag-retrieval 那类文章对比口径再决定。

按能跑起来的最短路径往上叠

顺序其实很朴素：先把最便宜的那层做扎实，再往上加。下面这套步骤从零到能跑，每一步都有验证动作，别跳步。

1. 第一步：把 prompt 写稳固定输出格式，写清角色、任务、约束三件事；验证方式是同一批问题跑几遍，输出结构是否稳定。
2. 第二步：答案依赖私有资料时加检索先离线跑通召回，人工看前若干条命中结果对不对，确认没问题再接进请求链路。
3. 第三步：需要外部动作时接工具查库、发消息、跑脚本这类操作先只接一个，验证参数拼得对不对、鉴权过不过。
4. 第四步：出现多步决策才包成 Agent只有当「下一步取决于上一步结果」时再包循环，验证方式是看步数有没有失控。
5. 第五步：工具多了再考虑 MCP要在多个客户端复用同一批工具时，才值得用 MCP 统一暴露，先小范围试。

每加一层都要留一个可回退的开关，比如检索关掉还能跑、工具关掉还能答。这样出问题时能快速定位是新那层还是老那层。价格和模型能力的选择，可以到 /price-watch 看当时的对比。

出问题时先找是哪一层的锅

排错最怕眉毛胡子一把抓。按现象对号入座，先锁定层次，再动手改，效率差很多。

如果同类问题反复出现，别每次临时改，记一条到评测用例里，改完再跑一遍对比。没有固定用例，你就不确定这次是变好了还是碰巧。

排错的顺序永远是从最便宜、最可控的那层开始，而不是从最像 AI 的那层开始。