写在前面：AI 面试的“硬骨头”，你能啃到第几块？
近两年，简历上若缺少 Agent、RAG、Function Call、工作流编排 这类关键词，几乎不好意思声称自己在从事 AI 应用开发。然而面试官绝非等闲之辈，只要抓住这些术语深挖下去，不少人就会暴露短板。
许多应聘者自信满满地答道：“就是 Reason + Act 嘛，边推理边行动。” 这种回答不能说错。
但问题在于，如果你只能给出这个层面的解释，那么在稍微严格的面试官眼中，你大概率只是翻阅了几篇公众号文章、跑过一个 Demo 而已。真正参与过生产系统的人都知道，面试官一旦顺着这个话题往下追问，后面全是硬核难题：
Function Call到底是如何工作的？ReAct和Plan-and-Execute的本质差异是什么？- 你的文档切分策略为什么这样设计？切得太碎或太大分别有哪些隐患？
- 你的 Prompt 是如何一步步调优的？你用什么方法证明它真的变好了，而非玄学？
- 你项目中最困难的部分，究竟是“把模型接上”还是“把系统做稳定”？
此时，不少人就会开始露馅。AI 面试最怕的情形就是：表面词汇很新，实际回答很虚。
今天咱们就借助 ReAct 这个切入点，将 5 个最容易遭遇连环追问的高阶问题连贯地串讲透彻。
第一问：ReAct 究竟是什么？别只停留在“Reason + Act”
ReAct 这个词，不少人都能脱口而出，但真正讲清楚的人不多。它绝不仅仅是“边推理边行动”六个字，本质上，它是一种让模型将思考过程与工具调用交替进行的决策范式。
可以理解为一个循环流程：
用户问题 -> 模型判断已知与未知 -> 决定是否调用工具 -> 执行工具 -> 读取结果 -> 再次判断 -> 直至能给出答案
举例来说，用户提问：“请帮我总结某招股书的营收增长和主要风险点，并用结构化报告输出”。
一个成熟的 ReAct Agent 不会直接瞎答，而是会经历类似这样的链路：
- 先识别意图：“总结 + 归因 + 风险提炼”
- 发现当前上下文不够，需要检索相关文档片段
- 调用检索工具，拿回多个 chunk
- 发现 chunk 太多，继续筛选和聚合
- 最后基于证据生成结构化答案
因此 ReAct 的关键，不在于“会调用工具”，而在于：先判断信息是否足够，在每一步动态决定下一步行动，让模型根据外部反馈不断修正路径。这与传统工作流最大的不同是，它不是一条写死的链，而是带有反馈闭环的动态决策过程。
更务实的理解是：ReAct 不是流程编排，而是让模型在行动中自主思考。
第二问：Function Call 到底是怎么工作的？
这道题特别容易让面试者卡壳。很多人会脱口而出：“就是让模型去调用一个函数啊。” 还是太浅。
真正的工作流程其实如下：
- 开发者将工具的名称、描述、参数 Schema 传给模型
- 模型判断是否需要调用工具
- 如果需要，模型返回结构化的调用意图
- 业务系统不直接执行，而是先做参数校验
- 校验通过后，由宿主程序真正执行工具
- 把执行结果再反馈给模型
- 模型基于结果继续推理，决定下一步动作
这看起来很像模型“会调用函数”，但你一定要明白：模型只是生成了一份“调用建议”，例如：
{"tool_name": "search_docs", "arguments": {"query": "招股书 营收增长 风险点", "top_k": 5}}
真正执行动作、跑代码、发请求的，是你的 Agent Runtime 或宿主系统。这一点为什么重要？因为它直接关乎线上系统的安全性。
如果不对模型返回的参数做校验就直接执行，就可能出现参数类型错乱、越权访问、工具误调用、甚至连环调用导致下游服务被击穿。因此成熟系统一般会加装多层防线：JSON Schema 校验、参数兜底、工具白名单、超时控制、重试与熔断、结果裁剪与脱敏。
面试中听到这类回答，面试官基本就能判断应聘者已不止停留在 SDK 层面了。
第三问：Plan-and-Execute 和 ReAct，到底有什么区别？
这道题特别适合用作压力面试，因为它不仅考概念，更考架构取舍能力。
不少人会这样比较：ReAct 是边想边做，Plan-and-Execute 是先做计划再执行。对，但不够深入。
真正的区别在于它们对“决策时机”的处理完全不同。
ReAct：局部决策，走一步看一步
思考 -> 调工具 -> 看结果 -> 再思考 -> 再调工具
- 优点： 灵活，对不确定任务友好，遇到新信息能及时修正。
- 缺点： 容易走弯路，工具调用次数可能很多，成本不稳定。
Plan-and-Execute：先做全局规划，再分步执行
先产出任务计划 -> 子任务1 -> 子任务2 -> 子任务3，再逐个执行
- 优点： 路径清晰，更容易控制成本和步骤数，适合长任务、多阶段任务。
- 缺点： 前面的计划一旦走歪，后面容易全盘跑偏，对环境变化和途中反馈不敏感。
所以两者并非谁更高级，而是谁更适合当前场景。比较成熟的回答思路是：
- 开放式问题、信息不完整、工具反馈不确定： 更适合
ReAct。 - 任务链路长、步骤明确、需要成本可控： 更适合
Plan-and-Execute。 - 复杂生产场景： 常常是两者混搭，先粗规划，再局部 ReAct。
有经验的工程师甚至会指出，这些模式本质上都是在做任务分解，只是 ReAct 把“分解”融进了推理循环里。这才是高度概括的认知，而非简单的概念罗列。
第四问：你的文档切分策略是什么？为什么这道题比你想象得难？
很多人做 RAG，真的就只会一句：“我用的固定长度切分，overlap 设 150 字。” 这话一出口，面试官十有八九就会追问：为什么固定长度？为什么 overlap 取这个值？你怎么证明这样切比较合理？
这道题难就难在，它根本没有银弹。切分策略本质上是在平衡三个要素：
- 召回率
- 语义完整性
- 上下文噪音
切得太碎，会发生什么？单个 chunk 语义不完整，指代关系断裂，模型拿到的是一堆“碎片证据”，检索命中也答不全。切得太大呢？无关信息变多，向量表达被稀释，排名精度下降，上下文窗口被快速吃满。
所以真正靠谱的切分，通常不是按字符数一刀切，而是分层切：文档级 -> 章节级 -> 段落级 -> 必要时再做滑窗切分。如果是技术文档、合同、招股书、FAQ，它们的切分策略通常完全不同：
- FAQ / 短问答： 按问答对切最合适。
- 技术文档： 优先按标题层级、段落和代码块边界切。
- 合同 / 法律文本： 优先保持条款完整性。
- 长报告 / 招股书： 按章节语义分组，再在组内做滑窗。
真正高分的回答，不是背一个数字说“我切 500 字”，而是能说清楚：为什么这么切、这个策略服务什么业务目标、你怎么评估效果。比如可以这样回答：“我服务的是招股书问答场景，核心目标是保证每个 chunk 覆盖一个完整的风险点，所以我以章节为边界，对长章节再进行语义滑窗，并用 MRR 和命中率来验证阵容效果。”
第五问：Prompt 你是怎么一步步优化的？怎么测质量？
这题特别“毒”。因为很多人搞 Prompt 的真实过程就是：改一句，跑一遍，感觉好像好了，再改一句。这在 demo 阶段问题不大，但一上生产，这基本等于玄学炼丹。
一个真正工程化的 Prompt 优化流程，至少包含 4 个部分：
1. 先定义“好”的标准
不先定义指标，后面全是空谈。常见维度包括：回答正确率、幻觉率、工具调用正确率、首次命中率、平均 token 消耗、平均响应时延。
2. 构造评测集
别拿两三个顺手样例测了就告诉别人“效果不错”。你需要一批覆盖真实场景的数据：简单问题、歧义问题、对抗性问题、超长上下文问题、工具容易误调用的问题。
3. 做版本化对比
Prompt 不能瞎改，每次改动都得能回答：改了什么、为什么改、哪些样例变好了、哪些变差了。
4. 联合看线上反馈
离线评测很重要，但线上才是真战场。很多问题只会在线上暴露：用户表达比测试集脏得多、工具返回不稳定、多轮对话会把上下文拉歪、某些提示词会导致 token 暴涨。所以成熟团队往往会同时观测：离线评测结果、A/B 实验、用户满意度、失败样本回放、成本曲线。
一句很有说服力的话是：“我们不是靠灵感调 Prompt，而是靠指标和测试集来驱动优化。” 这句话很容易让你跟只会调提示词的人拉开差距。
面试里的高分收尾话术
如果面试官从 ReAct 一路追到了 Function Call、任务编排、RAG、Prompt 优化，你最后可以试试用这段话收住整条线：
“这些问题的本质，其实都在探讨一件事：如何把一个语言模型，嵌入到一个稳定、可控、可评测的业务系统里。从 ReAct 的决策范式，到 Function Call 的安全边界，到 RAG 的证据链质量，再到 Prompt 的工程化迭代，每一步的核心都不是让模型更强，而是让整个系统更可靠。这也正是 AI 工程化最有意思的地方。”
这段话的价值在于，它能让面试官感受到，你看的是整个系统，而不是一个功能点。
为什么现在大厂特别爱问这类题？
因为这类问题太容易筛人了。表面上，大家简历里都能写：做过 Agent、接过 Function Call、做过 RAG、调过 Prompt。但只要顺着追问 5 分钟，马上就能分辨出：谁只是调了个 SDK，谁搭了个 demo，谁真正踩过线上坑，谁有能力把系统继续做深。
表面上这题问的是：你对 ReAct 的理解。实际上它考的是：你对 Agent 决策范式的理解、对工具调用边界的理解、对 RAG 证据链质量的理解、对 Prompt 工程化优化的理解、以及你有没有把 AI 应用做成“系统”而不是“玩具”。
