ReAct vs Plan and Execute：面试官逼你二选一，你怎么站队？

面试官问："ReAct 和 Plan and Execute 你选哪个？"——这道题没有标准答案，但回答的方式直接暴露你对 Agent 架构的理解深度。选 ReAct 的人被认为缺乏全局观，选 Plan and Execute 的人被质疑没有灵活性，那到底怎么站队？

本文整理自近期多场真实面试中的 AI 相关问题，从 Agent 架构之争出发，串联 Function Call、MCP 协议、RAG、上下文管理、文档解析六大核心话题。不只是"背答案"，更要知道"为什么这么做"。

一、👔 面试官：讲一下你对 Agent 的理解？ReAct 和 Plan and Execute 有什么区别？

🙋‍♂️候选人：Agent 就是让大模型不只是"说话"，还能"做事"——通过工具调用、规划推理来主动完成复杂任务。ReAct 是边想边做，Plan and Execute 是先规划再执行。

👔面试官：那你觉得什么场景该用 ReAct，什么场景该用 Plan and Execute？

🙋‍♂️候选人：如果任务步骤不确定、需要根据中间结果灵活调整，用 ReAct；如果步骤之间有强依赖、执行顺序基本固定，用 Plan and Execute。

👔面试官：那你就不能两个都用吗？

💡 简要回答

Agent = LLM + 工具 + 记忆 + 规划。ReAct 和 Plan and Execute 不是二选一的关系，而是两个不同粒度的策略——ReAct 是"一步一想"，Plan and Execute 是"先全局规划，再逐步执行"。实战中最好的做法是混合使用：Plan and Execute 做全局规划，ReAct 做每步内的灵活执行。

📝 详细解析

Agent 的核心组成

Agent 不是一个单一的技术，而是一个架构模式。它的四个核心组件：

• LLM：负责理解和推理，是 Agent 的"大脑"
• 规划：把复杂目标拆解成可执行的步骤
• 工具调用：让 Agent 能与外部世界交互（搜索、查数据库、调用API）
• 记忆：短期记忆（对话上下文）+ 长期记忆（持久化的知识）

ReAct vs Plan and Execute

ReAct 的执行流程：

ReAct 的优势是实时感知——每一步执行完都能根据结果调整策略。但缺点也很明显：如果某一步推理出错，后续步骤可能连锁崩溃，而且没有全局规划容易"走弯路"。

Plan and Execute 则是在开始执行前先让 LLM 生成一个完整的步骤列表，然后按列表逐个执行。适合那种"你很清楚要干什么，只是需要一步步来"的场景。比如数据分析：先获取数据 → 清洗数据 → 统计分析 → 生成可视化 → 写总结报告，这些步骤的依赖关系是固定的。

实战建议：复杂项目中，可以考虑混合策略——先用 Plan and Execute 做全局规划，每个步骤内部用 ReAct 做灵活执行。这样既有全局视角，又有局部灵活性。面试中被逼二选一的时候，说出这个混合方案，基本就能让面试官意识到你不止停留在"用过"的层面。

二、👔 面试官：你们项目里 RAG 是怎么做的？文档切分策略是什么？

🙋‍♂️候选人：我们用的是经典的 RAG 流程——文档解析、分块、向量化、检索、生成。切分策略上，主要基于语义段落和重叠窗口。

👔面试官：重叠窗口的 overlap 设多少？为什么不是0？

🙋‍♂️候选人：overlap 设的是 chunk_size 的 10% 左右，避免语义在切分边界处断裂。

💡 简要回答

RAG 的核心是把"检索"和"生成"解耦，用向量检索从知识库中找到相关片段，再交给大模型基于这些片段生成回答。文档切分是 RAG 效果的地基，切不好，后面再怎么优化都是白搭。

📝 详细解析

RAG 全链路

一个完整的 RAG 流程分为离线索引和在线检索生成两个阶段：

1. 离线阶段：把文档解析成纯文本 → 按策略分块 → 每个块调用 Embedding 模型生成向量 → 存入向量数据库（如 Milvus）
2. 在线阶段：用户问题 → 向量化 → 在向量数据库中做相似度检索 → 取出 Top-K 片段 → 拼接到 Prompt 中 → 调 LLM 生成回答

文档切分策略

切分是 RAG 里最容易被忽视、但对效果影响最大的环节。常见的几种策略：

实际项目中，递归字符切分 + overlap 是性价比最高的组合。overlap 的作用是让相邻块之间有一段重叠文本，防止关键信息恰好落在切分边界上导致检索不到。

常见误区：很多同学觉得切得越细检索越精准。实际上切得太细会导致每个块信息量不足，模型拿到的上下文碎片化，生成质量反而下降。一般建议 chunk_size 在 512~1024 Token，overlap 在 50~100 Token。

向量检索的目的

向量检索的本质是语义匹配——把文本映射到高维向量空间，语义相近的文本在空间中距离更近。相比关键词检索，向量检索能理解"同义词"和"语义关联"，比如用户问"怎么退款"，能检索到包含"退货流程"的文档。

三、👔 面试官：Function Call 是如何工作的？实现流程是怎样的？

🙋‍♂️候选人：Function Call 就是让大模型在生成回答时，能识别出需要调用外部工具，然后输出一个结构化的工具调用请求，由应用层执行后把结果喂回模型继续生成。

👔面试官：那模型本身会执行工具吗？

🙋‍♂️候选人：不会。模型只负责"决定调什么、传什么参数"，真正的执行是应用层完成的。

💡 简要回答

Function Call 的本质是让 LLM 输出结构化的"工具调用意图"，而不是直接执行工具。整个流程是：模型决策 → 应用层执行 → 结果回传 → 模型继续生成。模型永远不直接接触外部世界。

📝 详细解析

Function Call 完整流程

关键步骤拆解：

第一步：注册工具定义

你需要在请求中告诉模型"你有哪些工具可以用"，这是一个 JSON Schema 格式的描述：

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市的天气信息",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {
              "type": "string",
              "description": "城市名称"
            }
          },
          "required": ["city"]
        }
      }
    }
  ]
}

第二步：模型决策

模型接收到用户消息和工具定义后，会判断是否需要调用工具。如果需要，它不会生成普通文本，而是返回一个 tool_calls 结构，包含工具名和参数。

第三步：应用层执行

这是很多同学搞混的地方——模型不会自己执行工具。你的应用代码拿到 tool_calls 后，需要自己调用对应的函数/API，然后把执行结果以 tool 角色的消息格式回传给模型。

第四步：模型生成最终回答

模型拿到工具返回的结果后，结合原始问题和工具结果，生成最终的自然语言回答。

关键点：Function Call 可以嵌套多轮——模型可能在第一轮调了一个工具，拿到结果后发现还需要调另一个工具，这个过程会自动循环直到模型认为信息足够给出最终回答。你需要在应用层实现这个循环逻辑，设置最大轮数防止无限循环。

四、👔 面试官：当对话达到模型的上下文限制时怎么处理？仅通知用户到达限制很影响体验

🙋‍♂️候选人：可以做上下文压缩或者滑动窗口……

👔面试官：具体怎么做？压缩的精度怎么保证？

💡 简要回答

上下文限制的处理不是单一方案能解决的，需要组合使用：滑动窗口保留近期对话、摘要压缩历史内容、向量检索召回关键信息。核心原则是——让模型"忘掉细节，记住要点"。

📝 详细解析

这是 AI 应用开发中非常实际的问题。GPT-4 的上下文窗口是 128K，Claude 是 200K，看起来很大，但在多轮对话尤其是 Agent 场景下，Token 消耗远比你想象的快——一次工具调用可能就吃掉几千 Token。

常见策略对比

推荐的组合方案

具体实现思路：

1. 实时计算 Token 数：每次发送前计算当前消息列表的总 Token 数，这是所有策略的基础
2. 分层保留：系统提示（System Prompt）必须保留 → 当前用户问题必须保留 → 历史对话按优先级裁剪
3. 摘要触发条件：当历史对话 Token 数超过预算的 60% 时，触发摘要压缩——把最早的 N 轮对话调用 LLM 生成一段摘要，替换原始对话
4. 兜底方案：如果摘要后仍然超限，就把摘要存入向量库，根据当前问题检索最相关的片段

很多同学直觉上认为：直接把所有历史对话都做摘要就好了。但摘要本身也是有损压缩，你每做一次摘要，就丢失一些细节。所以更好的做法是分层——近期对话原样保留（保真），远期对话摘要压缩（保要），超远期向量检索（按需）。

五、👔 面试官：MCP 是什么？它对开发者带来了哪些便利？

🙋‍♂️候选人：MCP 是 Model Context Protocol，是 Anthropic 提出的一个开放协议，用来标准化大模型与外部工具之间的连接方式。

👔面试官：那它和 Function Call 是什么关系？有了 Function Call 为什么还需要 MCP？

💡 简要回答

MCP 是工具接入的标准化协议，Function Call 是模型调用工具的机制。Function Call 解决的是"模型怎么调工具"，MCP 解决的是"工具怎么接入"。没有 MCP，你每接入一个新工具就要手写 Schema、对接 API；有了 MCP，工具提供方自己实现 MCP Server，你的应用直接连就行。

📝 详细解析

MCP 的核心架构

MCP 采用了 Client-Server 架构：

• MCP Host：你的 AI 应用（比如 Claude Desktop、Cursor 等）
• MCP Client：宿主应用中的客户端，负责与 Server 通信
• MCP Server：工具提供方实现的服务，暴露三类能力：
  • Tools：可调用的函数（搜索、查询数据库、操作文件等）
  • Resources：可读取的数据资源（文件内容、数据库记录等）
  • Prompts：预定义的提示模板

MCP 解决了什么痛点

说白了，MCP 做的事情类似于 USB 协议——在 USB 出现之前，键盘、鼠标、打印机各有各的接口；USB 统一了接口标准后，设备厂商只需要实现 USB 协议就能接入任何电脑。MCP 对 AI 工具接入做了同样的事。

MCP 的典型工具

以实际使用场景举例，常见的 MCP Server 包括：

• 文件系统 MCP：让 AI 读写本地文件
• 数据库 MCP：让 AI 查询 MySQL/PostgreSQL
• GitHub MCP：让 AI 操作 PR、Issue
• 浏览器 MCP：让 AI 搜索网页、提取内容
• 自定义 MCP：你可以为自己的业务系统开发 MCP Server

注意：MCP 不是 Function Call 的替代品，而是 Function Call 的上游。流程是：MCP 负责发现和描述工具 → 应用把 MCP 的工具描述转换为 Function Call 的 Schema → 模型通过 Function Call 决定调用哪个工具 → 应用层通过 MCP 协议实际执行调用。

六、👔 面试官：PDF 解析你是怎么实现的？文档分块具体怎么处理的？

🙋‍♂️候选人：我们用 PyMuPDF 解析 PDF 文本，然后用递归字符切分器做分块……

👔面试官：PDF 里有表格和图片怎么办？表格被切散了怎么处理？

💡 简要回答

PDF 解析的难点不在提取文字，而在保持文档的结构语义——表格、图片、布局信息在纯文本提取时都会丢失。工程上需要根据文档类型选择不同的解析策略，并在分块时尽量保持语义单元的完整性。

📝 详细解析

PDF 解析的三个层次

实际项目中的分层策略：

1. 先用 pdfplumber 提取文本和表格：pdfplumber 能较好地识别表格结构，提取出来的表格可以转成 Markdown 格式，保持行列关系
2. 表格特殊处理：将整个表格视为一个不可切分的语义单元，在分块时跳过表格内部的切分点
3. 图片用多模态模型提取描述：对文档中的图片调用视觉模型生成文字描述，描述文本参与后续的检索
4. 元数据附加：每个分块除了文本内容，还附加来源页码、所属章节标题等元数据，检索时可以用元数据做过滤和排序

分块的工程细节

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["\n\n", "\n", "。", "！", "？", ".", " "],
)

关键参数说明：

• chunk_size：不是字符数而是 Token 数（取决于底层实现），800 Token 大约是 500-600 个中文字符，足够包含一个完整的语义段落
• chunk_overlap：100 Token 的重叠，确保跨块的信息不丢失
• separators：递归分隔符的优先级——优先按双换行（段落边界）切，切不开再按单换行，再按句号，最后按空格。这个顺序很重要，优先级越高的分隔符越能保持语义完整性

表格切分的实战经验：在递归切分之前，先用正则或 pdfplumber 标记表格区域的起止位置，然后在切分时将整个表格作为一个原子单元。如果表格超过 chunk_size，就把表格单独成块，不与前后文本合并。这样做虽然单个块可能偏大，但至少表格的行列关系不会被打散，检索出来的内容对模型是有意义的。

END