牛客网上一条 2026 年 4 月底的复盘帖子里有个细节值得反复看楼主提到面试官追问「如果工具返回空结果下一个 Thought 怎么处理」当场卡壳。这个追问方向比「ReAct 三元素是什么」高了至少两个难度台阶——它测的不是背诵能力是你在真实 Agent 运行时见过多少次翻车、想过多少种恢复路径。这个追问像没打算让我活着出去本卷「ReAct 与推理范式」是这个系列里信息密度最集中的一卷。ReAct、Chain-of-Thought、Plan-and-Execute、Tree-of-Thought 这四种推理范式几乎是 2025 年以来所有 AI Agent 岗位面试的标准配置题。但真正能拉开差距的地方从来不在定义而在这几个问题每个范式的失败路径是什么工具调用失败后的恢复策略怎么设计当你选了一个范式另外三个为什么不适合你的场景这些追问方向本卷全部展开。ReAct 循环的原子级拆解从三元组到真实 Agent 代码ReAct 的全称是「Reasoning Acting」核心思想是把模型的推理过程和工具调用交替进行。标准描述框架是四步循环Thought推理当前状态→ Action选择并调用工具→ Observation接收工具返回结果→ 循环直到输出最终答案。每一步 Observation 都会反馈到下一步的 Thought 里模型基于最新的观察结果重新生成推理再决定下一步干什么。这个循环之所以在 Agent 开发里广泛落地有三个结构性原因。第一工具调用的结果不会自动驱动下一步决策必须有一个中间层来完成「结果→判断」的转换Thought 充当了这个翻译角色。第二ReAct 产生的执行轨迹是可回溯的——每一步的 Thought 说清楚为什么选这个 Action工具返回了什么下一步怎么调整这个链条比黑盒模型调用更容易调试。第三每一步 Action 都可以绑定任意工具天然支持多工具协同的场景。但真正让面试官拉开差距的问题是Thought 阶段怎么控制推理质量模型自己生成的推理过程可能走偏特别是在 Few-shot 示例不够充足的情况下Thought 输出的中间结论可能是错的但模型会继续沿着这个错误结论往下走到最后一步才发现方向错了。这类问题的解法通常是在 Thought prompt 里加结构化约束比如「在生成下一步 Action 之前先检查上一条 Observation 是否符合预期」。ReAct 在 LangChain 中的实现细节用 LangChain 的create_agent构建一个 ReAct Agent实际上是在底层构造一个 Graph 结构Model Node 负责生成 Thought 和 ActionTools Node 负责执行工具并返回 Observation两者之间通过状态State传递数据形成一个循环直到满足 stop condition 才退出。这里有一个面试里经常被追问的实现细节工具调用的并行与串行策略。LangChain Agent 在单步里可以发多个并行工具调用——当 Thought 判断「这些工具彼此独立谁先返回不影响结果」时把它们打包成一次并行请求能显著降低延迟。但有些场景必须串行当前一个 Action 的返回结果是下一个 Action 的输入参数时必须等前一个 Observation 落地才能发起下一步请求。混用两种策略的核心判断依据是「工具之间是否有数据依赖」而不是「哪个更快」。循环终止条件有三个常见实现方式。第一个是max_iterations设置最大循环次数防止 Agent 进入死循环。第二个是stop word emit模型在 Thought 里主动输出「final answer」或其他约定的终止词Agent 检测到这个词就退出循环。第三个是两个条件的组合——多数生产级 Agent 会同时设置迭代上限和终止词检测双重保险。在面试里描述这个设计时重点要讲清楚「为什么需要终止条件」而不是只讲「怎么设置」因为面试官想知道你思考过「Agent 跑飞了怎么办」这个现实风险。线上 Agent 跑飞一次比代码里十个 TODO 还刺激可解释性与可观测性ReAct 轨迹天然比黑盒模型调用更适合调试原因在于每一步 Thought 都是显式的——它把模型的隐式推理过程翻译成了可阅读的文本序列。调试时可以直接定位到「第几步的 Thought 出了问题」而不是像纯 completion 模式那样只能靠猜「模型为什么会输出这个」。LangSmith 在这个环节扮演了推理可视化的角色。打开一个 ReAct Agent 的 LangSmith trace你能看到的不是一条平铺的文本而是按步骤展开的时序图每一步的 Thought 内容、触发的工具调用、返回的 Observation以及这一步的延迟和 token 消耗全部可查。对于线上 Agent 的问题定位LangSmith trace 是目前最实用的手段——候选人在面试里如果能举出「我在 trace 里发现第三步 Observation 超时人工降级后换了一个轻量工具」这样的具体例子比背一百句「我非常重视可观测性」更有说服力。面试里回答「你如何设计 Agent 的可观测性」标准框架是三层运行时可见trace 可查、异常可定位每步有日志、问题可复现状态可回放。三层缺任何一层回答都像在背 PPT。ReAct vs 模型为什么分不清这个你就接不住这道追问这节讲一个基础但面试高频的基础判断模型是推理引擎Agent 是自主系统。这个区分在多数候选人的理解里停留在「模型就是 Agent 的一部分」这个层面但面试官真正在追问的是当你把模型换成更强或更弱的版本Agent 的哪些能力会受影响哪些不会这个思维实验答不清楚说明你对 Agent 架构边界的理解还停在「搭积木」层面。模型Model的职责是生成输出。它接收文本输入输出文本或结构化内容不感知环境不决定下一步做什么也不执行任何动作。这些能力属于 Agent 层。Agent 具备感知、决策、执行三项核心能力感知是获取环境输入——用户消息、外部 API 返回结果、工具的执行状态决策是基于当前状态选择下一步 Action——调用哪个工具、传什么参数、是否需要多步协同执行是把决策转化成实际的工具调用或最终输出。这三步构成 Agent 区别于模型的根本标志。ReAct 循环能够落地恰恰是因为这三项能力都被显式建模了Observation 是感知Thought 是决策Action 是执行。没有这个三层能力的抽象ReAct 就只是一个「模型工具调用」的粗糙拼装而不是一个真正能自主运行的 Agent 系统。MCP vs Skill为什么 Anthropic 从「接工具」走向「封装能力」这个问题是 2025 年底到 2026 年初在 Agent 面试里出现频率激增的追问方向很多候选人在「接住追问」之前要先搞清楚这两个概念的演化逻辑。MCPModel Context Protocol解决的是「工具怎么接进来、怎么被调用」这个接口层问题。它本质上是一套标准化协议定义了工具的暴露方式、调用格式和返回规范——类似 REST API 时代的接口文档把「谁来写工具」和「谁来用工具」解耦了。但 MCP 有一个根本性局限它不关心什么时候用、用几个、按什么顺序用。只有 MCP 的情况下模型需要在自己的 Thought 里临时决定使用哪个工具、调用几次、先后顺序这个决策过程没有约束质量不稳定当模型推理能力有限或任务复杂时这个问题尤为突出。SkillAnthropic 在 Claude Code 里引入的概念解决的不是接口层问题而是「一个任务怎么完成」这个能力层问题。它把触发条件、执行流程和工具组合打包成一个能力单元——一个 Skill 通常包含 Reference什么情况下触发、Script执行脚本和 Context上下文。这相当于把「最佳实践」提前固化减少模型在运行时做临时决策的负担。当一个任务有固定的处理模式时用 Skill 比用裸 MCP 更稳定因为决策路径已经被提前设计好了而不是交给模型在每次推理时现想。面试里描述这两者的关系可以用一个工程判断收尾MCP 是基础设施Skill 是业务能力。MCP 解决的是「能不能接进来」Skill 解决的是「接进来之后怎么用才对」。仅有 MCP 的 Agent 和有 Skill 封装的 Agent在运行时稳定性上的差距往往在生产环境里才显现得最清楚。MCP 接进来了模型临时一决策线上炸了Chain-of-ThoughtCoTZero-shot 和 Few-shot 在 Agent 场景里的效果差异与选型判断Chain-of-Thought 和 ReAct 不是同一个层次的概念。ReAct 是执行框架规定了「推理-行动-观察」的循环结构CoT 是推理策略规定了「在生成最终答案之前模型内部怎么组织中间推理步骤」。两者的关系是ReAct 里的 Thought 阶段可以叠加 CoT让 Thought 输出的推理过程更稳定、更结构化。Zero-shot CoT 的做法是直接在 prompt 里加一句「Let’s think step by step」让模型自己生成推理链。优势是灵活不需要准备示例缺点是输出不稳定特别是在多步骤任务上模型可能生成看似合理但方向走偏的中间推理最后结论错误。Few-shot CoT 则是给 2 到 5 个带完整推理链的示例input → reasoning → output让模型在模仿这些示例的过程中学会结构化推理输出相对稳定但需要人工准备高质量示例成本更高。在 Agent 场景里的选型有明确规律简单工具调用场景单工具、单步骤、调用结果直接可用的任务Zero-shot CoT 足够灵活且响应快复杂多步骤任务跨工具协调、多步规划、中间结果需要组合判断的场景Few-shot CoT 效果更好稳定性的收益大于示例准备的成本。参考 AI Engineering Field Guide 中的 eval 结果描述Few-shot CoT 在复杂任务上比 Zero-shot CoT 平均提升 15-20% 的任务完成率1。CoT 与 ReAct 的叠加方式实操层面ReAct 的 Thought prompt 可以设计成这样在系统 prompt 里给一个结构化模板要求每次 Thought 输出必须包含「当前状态描述」「候选 Action 分析」「选择理由」三个字段然后加一句「Let’s think step by step」引导模型在模板框架内展开推理。对于更正式的 Few-shot 叠加直接在 prompt 里放 2-3 个「Thought-Action-Observation」的三元组示例让模型学习这个循环结构。两种方式的本质区别是一个靠约束 prompt 引导推理方向一个靠示例让模型模仿推理模式。选型判断任务复杂度 × 示例成本这个判断有一个简洁的决策框架任务复杂度高且示例可复用 → Few-shot CoT任务简单或每次场景不同 → Zero-shot CoT。示例准备成本是关键变量——Few-shot 的示例质量直接影响推理稳定性如果每次任务场景差异太大示例难以复用维护成本会抵消稳定性收益此时不如用 Zero-shot 靠 prompt 约束兜底。Plan-and-Execute规划与执行分离架构的工程落地与面试回答范式Plan-and-Execute 是四种推理范式里架构最重的一种核心思想是把 Agent 的工作流拆成两个独立阶段Planner负责理解任务全局拆成子任务列表Executor负责逐个执行工具调用最后把结果汇总给 Planner 做下一步决策。两者解耦支持独立优化——Planner 可以用推理能力更强的模型Executor 用响应更快的轻量模型分别调参互不干扰。这个架构的适用场景有明确边界任务边界清晰但步骤多且 Planner 需要更高推理能力的场景最适合 Plan-and-Execute。比如一个复杂的数据分析任务需要先从多个 API 获取原始数据然后清洗再做聚合分析最后生成报告——这个任务天然适合先规划再执行因为「什么时候开始清洗」和「清洗到什么程度」需要全局视角不是单步 Action 能决定的。相比之下一个「查一下北京今天天气」的单工具调用任务用 ReAct 就够了Plan-and-Execute 的架构开销反而是浪费。在 LangGraph 里实现 Plan-and-ExecutePlanner 和 Executor 各是一个 Agent通过共享的 State 传递任务列表和执行结果。Planner 的输出是一张子任务清单每完成一项Executor 就在 State 里更新这一项的状态pending / done / failedPlanner 读取 State 决定下一步继续还是结束。这种实现方式的关键优势是Planner 可以被跳过——当 Executor 发现当前任务足够简单不需要 Planner 介入时可以直接处理这个降级路径在复杂任务占比较高的场景里能显著降低平均响应时间。Plan-and-Execute vs ReAct核心区别与选型框架两者最根本的区别是循环结构ReAct 是单循环每一步推理后立即执行并观察适合「做一步看一步」的渐进式任务Plan-and-Execute 是双循环先规划再执行适合「先想清楚整体方案再动手」的长任务。这个区别直接决定了两者的适用场景分布ReAct 的典型场景单工具调用、多工具顺序调用调用顺序由任务本身决定不需要动态规划、实时响应要求高的交互式任务。Plan-and-Execute 的典型场景多步骤规划任务、跨系统协调任务、需要 Planner 拥有全局视野才能正确分解的复杂任务、需要 Executor 和 Planner 使用不同模型资源池的异构系统。面试里回答「你用过哪种、为什么选它」标准框架是先描述任务特征单步还是多步、是否需要全局规划、实时性要求再描述选型判断过程评估过哪些备选方案、为什么最终排除最后给结果数据如果能拿出任务完成率或延迟改善的数字面试官会追着问。光背「我用过 Plan-and-Execute」在有追问深度的面试里撑不过两轮。常见追问Planner 挂了怎么办这个问题是 Plan-and-Execute 架构里面试官最常挖的追问方向因为它直接暴露候选人对「系统容错」的真实理解深度。三个关键追问点。**第一个Executor 能不能绕过 Planner 直接处理简单任务** 答案取决于 Executor 有没有足够的上下文判断能力——如果任务简单到不需要 Planner 输出子任务清单Executor 可以直接处理但需要在 State 里记录「本次未经过 Planner」方便后续回溯审计。第二个Planner 的规划结果如何校验规划输出是一张子任务清单清单本身的合理性怎么验证常见方案是 Planner 输出后加一个「自检步骤」让 Planner 验证自己的输出是否覆盖了原任务的所有关键点或者让 Executor 在执行前做一次初步校验发现明显遗漏就回退给 Planner。**第三个规划失败后的 fallback 策略是什么** 典型的 fallback 链是Planner 重试一次调整 prompt 参数→ Planner 降级为简化版规划只拆成两步而非完整规划→ 直接切 ReAct 单步执行降级为最原始但最稳定的方案。这三级 fallback 设计比「Planner 挂了就算了」要专业得多。Planner 重试一次还挂行降级 ReAct 我先顶着Tree-of-ThoughtToT树状搜索在Agent推理里的应用与BFS/DFS策略对比ToTTree-of-Thought在四种推理范式里是架构最抽象、面试追问最刁钻的一个。它的核心思想不是「沿着一条链走到底」而是在每个推理节点生成多个候选方向并行探索评估后再决定剪枝还是回退——像下棋时不是只走一步看一步而是在关键节点同时推演几种可能的局面再选最优。这个设计背后的动机是当任务存在多条可行路径、且路径之间差异很大时单链推理无论是 ReAct 还是 Plan-and-Execute一旦选错方向就会绕很远才能折返ToT 用树结构保留多个方向的探索空间在每个分支节点做评估从而避免过早 commits 到一个可能是次优的路径上。与 ReAct 的根本区别ReAct 是单链ToT 是树结构ReAct 在 Thought 阶段生成一个推理方向然后执行ToT 在 Thought 阶段生成多个候选分支每个分支都有自己的 Action 和 Observation最终通过评估函数选出最优路径或汇总多个分支的结果。BFS与DFS在ToT中的适用场景BFS广度优先搜索和 DFS深度优先搜索是 ToT 树搜索的两种基础策略选择哪个取决于任务对「并行性」和「深度探索」的权重分配。BFS 适合的场景是「多方案并行评估、取最优」当任务天然有多个可行方案且这些方案之间没有严格的依赖关系时BFS 让所有方案同时探索在同一深度评估比较选出最优后停止其他分支。比如代码生成任务ToT 可以同时生成三种实现方案在相同编译或测试深度下比较执行效果选出最稳定的一个。代价是状态空间大内存消耗高——当分支数超过十个、每条路径的中间状态都很大时BFS 的内存开销可能成为瓶颈。DFS 适合的场景是「先验证一条路径可行性、不行再回退」当任务路径之间有强依赖关系比如前一步的结果直接影响下一步的可行性或者你更关心「能不能找到一条有效路径」而不是「找到最优路径」时DFS 先沿着一条路径深挖到底发现不行就回退到上一个决策节点再走另一条。比如复杂 bug 定位ToT 的 DFS 策略会沿着一个假设路径追踪日志找到问题就停找不到就回退到分支点走下一个假设——这个过程比 BFS 的并行探索更节省内存但可能陷入局部最优在 bug 定位场景里就是「绕了一大圈发现路径A根本走不通但已经浪费了很多时间」。面试里回答「你选 BFS 还是 DFS」标准框架是先描述任务对并行性和探索深度的权重再描述候选路径的数量和状态空间大小最后给出选型判断。这个框架比「背住 BFS 适合并行、DFS 适合深挖」要专业得多因为面试官真正在筛的是「你能不能根据任务特征做架构决策」而不是「你有没有背住两种策略的定义」。DFS 陷进局部最优绕了三层才发现路径本身有问题树搜索的剪枝策略ToT 里剪枝策略的设计直接决定搜索效率也是面试官最常追问的工程细节。第一种是基于评估函数的早停每个分支在探索过程中持续评估分数score当分数低于预设阈值时停止该分支的继续探索。这是最常见的剪枝策略本质是把「质量控制」前移——不用等整条路径跑完才发现这个方向不行而是在每一步都判断「这个方向是否还值得继续」。关键工程点是评估函数怎么设计、阈值怎么定——过低会让很多有效路径被误剪过高会让无效分支继续占用资源。第二种是基于深度的限制防止无限递归设置最大探索深度。超过深度的分支即使没找到解也强制停止避免在无效方向上无限消耗资源。这个策略简单但有效特别是在任务复杂度不可预估时比如用户输入的复杂度超出模型预期深度限制是系统的最后一道安全阀。第三种是基于回溯的恢复当某条路径探索失败时回到上一个决策节点从那里选择下一个未被探索的分支继续。这要求 State 维护每个决策节点的完整上下文——不只是当前探索到哪一步还要记录「还有哪些分支没走、每个分支的评估状态」。没有这个恢复机制DFS 的回退就只是「知道这条路不行」但「不知道从哪重新开始」。评估函数阈值设低了有效路径被误剪线上全挂了面试追问路径四范式的横向对比与「你用过哪种、为什么选它」的应答框架这一节把 ReAct、CoT、Plan-and-Execute、ToT 四个推理范式放在一起做横向对比。这张图是本卷最核心的工具图面试前务必在脑子里过一遍「你项目里用的是什么流程」的回答范式这个问题是 Agent 面试里最常见的开放式追问表面上是让你描述项目技术选型实际上在同时筛三个维度你有没有真实动手做过项目、你能不能说清楚选型理由、你有没有数据支撑判断。回答的标准结构分四步。第一步描述任务背景和约束——不是复述一遍简历上的项目名称而是说清楚「这个任务的复杂度在哪、实时性要求是什么、工具调用数量大概多少」。比如「我做的那个客服 Agent 需要同时接入订单系统、库存系统和物流系统用户问一个问题可能涉及多个系统交叉查询响应延迟要求在三秒以内。」这句话里的「三个系统」「交叉查询」「三秒延迟」三个约束直接决定了后面的选型方向。第二步描述选型判断过程——评估过哪些备选方案、为什么最终排除、为什么选了这个。这部分最容易被面试官追问细节比如你说「排除了 Plan-and-Execute 因为架构太重」面试官会追问「你觉得多重算重、有没有量化的指标」。能给出具体数字延迟从 800ms 降到 350ms、工具调用成功率从 72% 提升到 91%的候选人和只会说「效果很好」的区别面试官一眼就能看出来。第三步描述实现亮点——至少一个「踩坑后改进」的真实细节。这个细节比任何正面描述都更能证明你真的做过比如「一开始用的是零样本 CoT但发现多步骤任务的错误率在 35% 左右后来加了两组带完整推理链的示例错误率降到 12%但响应时间增加了 200ms这个 trade-off 我们最后在系统里做了动态切换——简单任务用零样本复杂任务切换到少样本」。第四步给效果数据——任务完成率、延迟改善、错误率等可量化指标。如果面试官追问「这个数字怎么测出来的」要能说清楚 evaluation 的设计方法而不是随口报一个没有出处的数字。### 6.2 追问「如果ReAct循环卡住了怎么诊断和修复」这个问题是面试官真正在筛的能力不是背流程是 debug 能力。卡住的原因可能有很多Thought 推理方向走偏、工具返回结果不符合预期、循环没有终止条件导致无限迭代、Observation 超时导致状态丢失。诊断的标准路径是先用 LangSmith trace 定位卡住的节点——是卡在 Thought 阶段还是 Action 阶段还是 Observation 阶段不同节点的修复策略完全不同。卡在 Thought 阶段通常是推理 prompt 不够约束模型生成了方向走偏的推理解决方法是加结构化模板或 Few-shot 示例强制推理方向。卡在 Action 阶段通常是工具选择逻辑有问题解决方法是检查工具描述是否足够清晰、增加工具选择的约束条件或者在工具调用前加一层校验逻辑。卡在 Observation 阶段通常是工具返回格式不符合预期或者返回结果为空解决方法是设计容错路径——当 Observation 是空或格式异常时Thought 应该知道怎么降级处理而不是继续按原计划执行。修复完成后还要做回归验证用 LangSmith 把同类型的任务跑一遍确认卡住的问题确实解决了而不是在这个节点修好了又在另一个节点引入新的卡住。trace 里 Thought 阶段一直在循环Action 一个没发出去项目落地没有完整Agent项目怎么补、简历里怎么写、面试里怎么讲这一节解决的是「我已经看完了四种范式的定义但我没有完整项目经验面试怎么讲」这个真实痛点。这个问题在本科生和研究生里出现的频率最高也是最容易在面试里暴露「只会背概念、不会动手」缺陷的地方。### 7.1 最小可面试的Agent项目结构一个能通过面试技术追问的最小 Agent 项目需要满足三个条件单 Agent 的 ReAct 循环、至少三个自定义工具、LangSmith trace 可视化。这三个条件是最低门槛缺任何一个都会在技术面第一轮被追问打穿。单 Agent 的 ReAct 循环要能完整展示你实现的 Agent 在每一步是怎么做 Thought 的、选择了哪个 Action、收到了什么 Observation、下一步 Thought 怎么基于这个 Observation 做调整。这个循环要在 LangSmith 里清晰可见面试官可以直接点进去看每一轮的推理细节。三个自定义工具不能是简单的「查天气」「搜新闻」这种标准示例——面试官一看就知道是你从教程里抄的。好的自定义工具应该贴合你简历里描述的项目背景比如你做的是校园信息助手三个工具就分别是「查课表」「查成绩」「查空教室」你做的是代码审查助手三个工具就是「读 diff」「运行测试」「写评论」。工具要有实际业务场景的上下文面试官追问「这个工具在什么情况下会被调用」时你才能答得上来。至少一个「工具调用失败后的恢复路径」是项目亮点的关键。面试官不关心你为什么没有失败过他们关心的是「失败之后你的 Agent 怎么处理」。最简单的设计一个工具超时后Thought 分析超时原因决定是重试、降级换工具还是上报用户。这个恢复路径要在 trace 里可见面试官会顺着 trace 追问每一步的决策逻辑。### 7.2 简历关键词写法简历上写「用过 Agent 开发」是最没有信息量的描述——它告诉面试官的信息是「你接触过这个领域」而不是「你做过什么、做到什么程度」。简历关键词的正确写法是把具体技术栈和结果指标写进去。第一个原则不要只写「Agent开发」要写具体范式。「ReAct推理框架」「Plan-and-Execute两阶段规划」「ToT树搜索策略」这三个词的分量完全不同面试官看到「ToT树搜索」就知道你探索过更深层的推理架构不是只在 ReAct 层面打转。第二个原则加上工具和协议的名称。「接入MCP协议」「支持Anthropic Skill封装」「使用LangGraph作为Agent Runtime」这几个关键词任何一个拿出来都能引出一段技术追问而「做过Agent」这三个字能引出的只有「那你讲讲你做的Agent是什么」。第三个原则写结果指标。「Tool Call成功率从68%提升到89%」「平均响应延迟降低240ms」「多步骤任务完成率提升22%」这三个数字比任何描述性语言都更能证明项目质量。面试官会追着问「这个数字怎么测的、基准线是什么」你要是说不清楚这反而是个减分项但如果你能说清楚这三个数字能把面试的技术深度拉高一个档次。### 7.3 面经里描述项目的标准框架第一层任务背景——解决什么问题为什么需要 Agent 而不是直接调用 API。这里要有一个清晰的理由如果是「需要多步推理才能完成的任务」就说清楚哪几步、为什么不能一步到位如果是「需要根据中间结果动态调整调用策略」就举一个具体场景。这个理由说得不清楚面试官会怀疑你是不是真的理解为什么要用 Agent。第二层技术选型——为什么选这个范式评估过哪些备选方案。这个层面的回答要有层次感先说评估了哪些方案比如「评估了ReAct、Plan-and-Execute和直接模型调用三种方案」再说每个方案为什么被排除「直接模型调用不支持多步推理、Plan-and-Execute架构太重不适合我们的实时性要求」最后说为什么选了这个「ReAct的循环粒度刚好匹配我们的任务复杂度单步工具调用占比高实测响应时间最优」。第三层实现亮点——至少一个「踩坑后改进」的真实细节。这个亮点必须是具体的比如「发现工具返回结果有时序问题导致并发调用时状态不一致后来在State里加了版本号字段每次工具调用前校验版本号不匹配就重试」——这个细节比「我遇到了并发问题后来解决了」要高出十个层次。第四层效果数据——任务完成率、延迟改善、错误率等可量化指标。没有数据的项目描述是不完整的但数据必须来自真实 evaluation不能现场编造。如果你的项目没有做过系统化的 evaluation诚实地说「还没有系统评估数据正在搭建 evaluation 框架」比编一个数字安全得多。面试问到效果数据才发现 evaluation 框架还没搭延伸入口原文归档https://tobemagic.github.io/ai-magician-blog/posts/2026/05/03/ai面试八股文-vol13reactreact-不是一种算法是一种工程契约从问题域到面试追问的完整映射/公众号计算机魔术师参考文献[1] 原始资料[EB/OL]. https://github.com/alexeygrigorev/ai-engineering-field-guide/blob/main/interview/questions/04-ai-system-design.md. (2026-05-03).