1. 为什么这道题能"一题定生死"

面试进行到第 40 分钟，面试官合上简历，问了一句：

“你简历上写了做过 AI 应用，那你说说，LLM、RAG、Agent、MCP 这四个东西，是怎么串起来的？”

很多 Java 工程师这时候会开始背名词：LLM 是大模型，RAG 是检索增强，Agent 是智能体，MCP 是……协议？

然后就没有然后了。

问题不在于你不知道这四个词，而在于你说不出它们之间的因果关系。面试官想听的从来不是定义，而是：你在什么场景下，因为遇到了什么问题，引入了哪一层，它又带来了什么新问题。

这篇文章就用一条完整的链路，把这四个概念串成一条"问题驱动"的叙事线，让你在面试里能顺着讲 5 分钟不卡壳。

2. 一句话总览：四层能力，逐层补坑

先给结论，后面再展开：

层级	解决什么问题	一句话定位
LLM	让机器能理解和生成自然语言	一个"博学但失忆、且只会聊天"的大脑
RAG	模型不知道你的私有知识、还会瞎编	给大脑外挂一个"开卷考试"的资料库
Agent	模型只会说，不会做	给大脑装上"手和脚"，能调工具、能循环
MCP	工具接入方式五花八门，每家一套	给"手和脚"定一个统一的插座标准

一句话串起来：

LLM 提供智力，RAG 补充知识，Agent 赋予行动能力，MCP 统一行动接口。

如果面试官只给你 30 秒，把这句话说出去，就已经赢过一半人了。

3. LLM：一切的原点，也是所有问题的源头

3.1 它到底给了我们什么

LLM（Large Language Model）本质上是一个基于上下文预测下一个 token 的概率模型。它带来的能力是革命性的：

• 自然语言理解：不用再写正则和意图树；
• 自然语言生成：能产出结构化、可读的文本；
• 泛化能力：没专门训练过的任务，靠 prompt 也能做。

对 Java 工程师来说，最直观的变化是：以前做"智能客服"，要写几百条 if-else 和意图分类规则；现在一个 prompt 就能覆盖 80% 的常见问题。

3.2 但它有三个致命缺陷

面试时一定要主动说出这三个缺陷，因为后面三层全是为了补这三个坑：

1. 知识截止：训练数据有截止日期，且完全不知道你公司的内部文档、数据库、业务规则。
2. 幻觉：不知道的时候不会说"不知道"，而是编一个看起来很像的答案。
3. 只能输出文本：它不能查数据库、不能调接口、不能发邮件，只能"说"。

用一句话概括：LLM 是一个知识渊博、但失忆、且没有手脚的实习生。

到这里，第一个坑出现了：它不懂你的业务知识。 于是有了 RAG。

4. RAG：给模型开卷考试

4.1 核心思想

RAG（Retrieval-Augmented Generation，检索增强生成）的思路非常朴素：

既然模型不知道，那就在提问的时候，把相关资料一起塞给它。

也就是把"闭卷考试"改成"开卷考试"。模型不需要记住知识，只需要会读资料、会总结。

4.2 完整链路

拆开看是两段：

离线阶段（建库）

1. 文档解析：PDF、Word、网页、数据库表，统一转成纯文本；
2. 文本切分（Chunking）：按语义切成 300~800 字的块；
3. 向量化（Embedding）：调用 embedding 模型把每个块转成向量；
4. 写入向量库：Milvus、Qdrant、pgvector 等。

在线阶段（问答）

1. 用户问题向量化；
2. 向量库相似度检索，取 Top-K；
3. 把检索结果拼进 prompt 的上下文；
4. LLM 基于这些资料生成答案，并要求"只依据给定资料回答"。

4.3 Java 侧的最小实现

public String ragAnswer(String question) {
    // 1. 问题向量化
    float[] queryVector = embeddingClient.embed(question);

    // 2. 向量检索
    List<Document> docs = vectorStore.search(queryVector, 5);

    // 3. 拼装上下文
    String context = docs.stream()
            .map(Document::getContent)
            .collect(Collectors.joining("\n---\n"));

    // 4. 构造 prompt
    String prompt = """
            请仅依据以下资料回答问题，资料中没有的内容请回答"不知道"。
            
            【资料】
            %s
            
            【问题】
            %s
            """.formatted(context, question);

    return llmClient.chat(prompt);
}

4.4 RAG 的坑，才是面试的加分项

能说出 RAG 的局限，比能背出 RAG 的流程更值钱：

• 切分粒度两难：切太碎丢上下文，切太大检索不准；
• 召回不准：纯向量检索对关键词、编号、专有名词不敏感，需要混合检索（BM25 + 向量）；
• 多跳问题：一个问题需要跨多个文档推理，单次检索搞不定；
• 时效性：文档更新后要重新建索引。

到这里，第二个坑出现了：RAG 只能"查了再说"，但很多任务需要"边查边做、多步决策"。 于是有了 Agent。

5. Agent：从"会说"到"会做"

5.1 本质是一个循环

Agent 的核心不是某个框架，而是一个循环：

用伪代码表示就是：

public String runAgent(String goal) {
    List<Message> history = new ArrayList<>();
    history.add(Message.user(goal));

    for (int step = 0; step < MAX_STEPS; step++) {
        LlmResponse resp = llmClient.chatWithTools(history, toolRegistry.list());

        if (resp.hasToolCall()) {
            ToolCall call = resp.getToolCall();
            String result = toolRegistry.invoke(call.getName(), call.getArgs());
            history.add(Message.assistant(resp));
            history.add(Message.tool(call.getId(), result));
        } else {
            return resp.getContent();
        }
    }
    throw new IllegalStateException("超过最大步数");
}

注意几个工程细节，这些是面试官爱追问的：

• 最大步数限制：防止死循环烧钱；
• 工具描述质量：工具名和描述写不好，模型就选错工具；
• 错误处理：工具报错要作为 observation 回灌给模型，让它自己纠错；
• 上下文膨胀：多轮工具调用后 history 会很长，需要裁剪或摘要。

5.2 Agent 和 RAG 不是替代关系

这是最容易答错的地方。很多人以为有了 Agent 就不需要 RAG 了，其实：

RAG 是 Agent 的一个工具。

在 Agent 的工具列表里，“知识库检索"只是其中一个 tool。Agent 可以决定"这个问题需要先查知识库，再查订单系统，最后发邮件”。

所以正确的表述是：RAG 解决"知识从哪来"，Agent 解决"步骤怎么走"。

5.3 新的坑：工具怎么接

Agent 要能干活，就得接工具。但现实是：

• 查订单要接内部 HTTP 接口；
• 查文档要接向量库；
• 发消息要接企业微信；
• 查数据库要接 JDBC。

每接一个工具，就要写一套适配代码、一套鉴权、一套参数校验。N 个模型 × M 个工具 = N×M 套适配，这就是著名的"胶水代码地狱"。

于是有了 MCP。

6. MCP：给工具接入定一个标准

6.1 它解决的是"接口标准化"问题

MCP（Model Context Protocol）可以类比成 AI 世界的 USB-C：

以前每个设备一个充电口，现在统一成一个。工具只要按 MCP 规范实现一次，任何支持 MCP 的模型/客户端都能直接用。

它把"模型侧"和"工具侧"解耦：

6.2 三个核心概念

• Resources（资源）：可被读取的数据，类似"文件"；
• Tools（工具）：可被调用的函数，带 JSON Schema 参数定义；
• Prompts（提示模板）：预置的提示词模板。

传输层支持 stdio（本地进程）和 HTTP/SSE（远程服务）两种方式。

6.3 一个 MCP Server 的骨架

// 以 Java SDK 为例，注册一个查询订单的工具
McpServer server = McpServer.builder()
        .name("order-server")
        .version("1.0.0")
        .build();

server.addTool(
        ToolDefinition.builder()
                .name("query_order")
                .description("根据订单号查询订单状态，订单号格式为 ORD 开头加 12 位数字")
                .inputSchema("""
                        {
                          "type": "object",
                          "properties": {
                            "orderId": {"type": "string", "description": "订单号"}
                          },
                          "required": ["orderId"]
                        }
                        """)
                .build(),
        args -> orderService.query(args.get("orderId").asText())
);

server.start();

写好之后，任何 MCP 客户端（Claude Desktop、各类 IDE 插件、自研 Agent）都能直接发现并调用这个工具，不需要为每个客户端重写一遍适配。

6.4 别把 MCP 说成"又一个 RAG"

面试时常见的错误回答是"MCP 是用来做检索的"。要明确：

• RAG 是一种应用架构，解决知识注入；
• MCP 是一种通信协议，解决工具接入；
• 两者层次不同，MCP 可以让 RAG 的检索器变成一个标准工具，但 MCP 本身不负责检索策略。

7. 串起来：一个完整的落地场景

假设要做"企业智能运维助手"，四层怎么配合：

对应到四层：

• LLM：负责理解问题、规划步骤、生成报告；
• RAG：负责把历史故障文档、SOP 手册变成可检索的知识；
• Agent：负责多步决策，决定先查监控还是先查发布；
• MCP：负责把监控系统、发布系统、文档系统统一暴露成标准工具。

面试时讲完这个例子，再补一句"我们线上还做了工具调用超时、失败重试和成本控制"，基本就稳了。

8. 面试话术模板

最后给一段可以直接背的 60 秒版本：

"LLM 是底座，它解决了自然语言理解和生成，但存在知识截止、幻觉和无法行动三个问题。

我们用 RAG 解决知识问题，把私有文档向量化后检索注入上下文，让模型开卷答题；但 RAG 只能单次检索，复杂任务需要多步决策，所以我们引入 Agent，用 ReAct 循环让模型自己规划、调工具、看结果、再决策。

Agent 要接很多工具，每个系统一套适配会导致胶水代码爆炸，所以我们用 MCP 做标准化，工具按协议实现一次，所有客户端都能复用。

整体上，RAG 是 Agent 的一个工具，MCP 是工具的接入标准，四层是逐层补坑的关系，不是互相替代。"

9. 小结

记住这条主线，比记住四个定义重要得多：

LLM 给智力 → 有知识盲区 → RAG 补知识 → 但只能查不能说做 → Agent 补行动 → 但工具接入混乱 → MCP 定标准。

面试官问的从来不是"你知不知道这四个词"，而是"你有没有真正把一个 AI 应用从 0 搭到 1"。能把这条因果链讲清楚，说明你踩过坑、想过为什么，这比背十篇八股文都管用。