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