前沿部署工程的技术核心：检索增强生成、评测、Agent 与工具使用，外加成本与延迟。每一项做到优秀是什么样子，以及它们在面试流程中如何出现。

作者：LUKAS HOFFMANN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 6 月 21 日 · 阅读时长 9 分钟

练习这些内容：RAG 与 Agent 设计问题 · LLM 与 GenAI 问题 · 核心概念讲解 · 必知的 FDE 问题

前沿部署工程的技术核心不是训练模型。而是四项决定一个强大模型能否真正在客户环境中运转的技能：用检索增强生成将回答锚定在客户的数据上，用评测证明系统有效，用 Agent 和工具使用让它能够采取行动，以及对成本和延迟有切实的把握，使其能在生产环境中存活。掌握这些，你就覆盖了技术面试的大部分内容。下面说明每一项做到优秀是什么样子，以及它们在面试中如何出现。想练习题目，可直接前往 RAG 与 Agent 设计和 LLM 与 GenAI题集。想了解 AI 版本的前沿部署工程师与经典版本的区别，请参阅AI 前沿部署工程师角色。

检索增强生成：锚定在客户的真实场景中

RAG 是 FDE 工作的主力，因为客户不想要一个了解整个互联网的模型。他们想要一个能基于自己的数据回答问题的模型：他们的政策、他们的工单、他们的文档。检索增强生成会获取相关片段并喂给模型，使回答基于真实来源，而不是模型的记忆。

做到优秀意味着能够调试它，而不只是画出架构图。你应该对分块的选择、关键词搜索与基于嵌入的向量搜索之间的区别、以及为什么混合搜索加上重排序步骤通常优于单独使用任何一种方法了如指掌。更重要的是，你应该对失败模式烂熟于心。生产环境中最常见的两个坑：系统向没有查看权限的用户展示了某份文档，以及模型自信地引用了一个实际上并不支持其论断的检索片段。面试官听到你主动说出这些失败模式，就知道你运行过真正的 RAG 系统，而不只是读过相关资料。如果底层术语还比较模糊，概念库会逐一拆解每个概念。

评测：你如何赢得信任

评测是区分“能做演示的人”和“能交付系统的人”的技能。演示只能证明系统成功过一次。评测套件则证明系统不会以那些会让你的客户在他们的客户面前难堪的方式失败。

好的评测工作始于真实的测试集，而不是凭感觉。你要从客户的领域中提取真实案例，涵盖三类：简单案例、模糊案例，以及正确答案是“源数据中未提及”的对抗性案例。你要运行系统并阅读失败案例，而不仅仅是看总体数据。92% 的通过率毫无意义，如果那 8% 的失败案例全都是高风险问题。当任务是开放式的时候，你可能会用 LLM 作为评判者，但优秀的候选人会立即指出这个评判者的弱点，比如偏向更长的回答，并解释他们会如何在一个样本上对照人工标注来验证它。这就是对每个利益相关者最终都会问的问题的回答：你怎么知道它有效。必知集合中的评测类别正是针对这种推理能力的训练。

Agent 与工具使用：能力与克制

Agent 让模型能够采取行动：调用函数、查询数据库、提交工单，然后根据结果决定下一步做什么。它们很强大，但也常被过度使用，面试官对此心知肚明。

这里的优秀表现体现在克制上。优秀的候选人只有在任务需要多步骤工具调用和分支决策时才会选择 agent，否则更倾向于使用更简单、更可预测的链式流程。当确实需要 agent 时，你会谈到清晰的工具边界、硬性终止条件以防止它无限循环，以及工具调用失败或返回垃圾数据时的错误处理。真正体现实际经验的细节是幂等性。一旦 agent 能够在客户系统中执行真实操作，一个天真地重复尝试导致重复扣费或重复提交工单的情况就不再是假设了。你要通过幂等键来为此做好设计。在一个单链就能处理的任务上动用多 agent 集群是一个可靠的危险信号，它在 RAG 与 agent 设计环节中频繁出现。

Decision: do you need an agent?
  Single call answers it           -> just call the model
  Fixed sequence of known steps    -> a chain, not an agent
  Branching, tool results drive    -> agent, with limits:
      next step                       - explicit tool boundaries
                                      - termination condition
                                      - idempotent actions
                                      - failure handling per tool

成本与延迟：优秀候选人悄悄折戟之处

这是最少被花时间学习、却导致最多无声拒绝的技能。你可以设计出一个漂亮的 RAG 加 agent 系统，但当面试官问它在每天一百万次查询下的成本是多少，而你没有任何估算框架时，你就会失去全场。

优秀意味着用粗略的数字为每个设计收尾。估算每次查询的 token 数，乘以所选模型的每 token 价格，再乘以数量，得出客户可以据此做出反应的每日成本。然后给出延迟预算：如果用户在等待响应，每一次额外的检索跳转和每一个 agent 步骤都会增加 p95 延迟，一个喋喋不休、耗时八秒的 agent 无论多准确都不会上线。你采取的手段是具体的：缓存、对简单案例使用较小的模型并在需要时升级到更大的模型，以及削减不必要的 agent 步骤。你不需要精确的数字。一个站得住脚的粗略估算就能证明你考虑到了生产环境，而这正是这个岗位存在的全部意义。

这些内容如何在流程中相互配合

这四项并不是零散的冷知识。一场典型的 FDE 设计面试会给你一个模糊的客户问题，并观察你是否按顺序运用它们：界定问题范围、用检索来落地、判断是否需要 AI Agent、规划如何用评测证明它有效，最后以成本和延迟的分析收尾。优秀的候选人能自然地走完这条主线，因为这就是实际工作的运行方式。

如果你想培养这种直觉，不要把它们当作阅读清单来学习。而是要反复练习真实问题，直到这些动作成为本能。先从 RAG 和 Agent 设计入手应对最常见的设计面试，再叠加 LLM 和 GenAI 的基础知识，并保持概念库随时可查，弥补任何仍感薄弱的地方。

把它转化为 Offer。练习这些对应到的真实问题和概念：

常见问题

四项，按它们决定面试结果的频率排序：检索增强生成、评测、Agent 与工具使用，以及对成本和延迟的推理。模型训练很少被问到。这份工作的核心是在客户的系统内部把一个强大的模型部署好，所以考察的技能是落地、度量、编排和预算控制，而不是从零构建模型。

深入到能调试它，而不只是画出它。你应该能够分析分块策略、关键词搜索与向量搜索的区别以及混合检索何时优于两者、重排序，以及各种失败模式：模型从用户不应看到的文档中生成答案，或者自信地引用一个并不支持该论断的分块。仅仅说出各个模块的名称是不够的。

因为演示只能证明系统成功一次，而评测能证明它不会以让客户难堪的方式失败。评测是 FDE 赢得利益相关者信任的方式——当对方问“你怎么知道它有效”时。能够设计包含真实案例和对抗性案例的评测集，并且关注失败案例而非平均表现的候选人，传递出他们真正向真实用户交付过产品的信号。

克制。优秀的答案只在任务确实需要多步工具使用时才使用 Agent，否则更倾向于更简单的链式流程。好的设计意味着清晰的工具边界、终止条件、工具调用失败时的错误处理，以及针对陷入循环或幻觉出工具的 Agent 的应对方案。在简单任务上动用多 Agent 集群是一个危险信号。

讨论 (5)

成本和延迟部分是最值得反复打磨的。一个候选人可以撑起整场 RAG 设计讨论，却在面试官问到“每天一百万次查询要花多少钱”时，在九十秒内失去全场。走进面试间之前，先准备好回答这个数字的框架。

这是设计面试中最常见的隐性淘汰原因。补救的成本很低：始终以粗略的单次查询 token 计算和 p95 延迟预算来收尾设计。哪怕只是一个粗略估算，也能表明你考虑过生产环境，而这正是这个岗位的全部意义所在。

读者提问：关于评测这部分，面试官是期望你了解某个特定框架，还是更看重思考方式？我读过关于 LLM-as-judge 的内容，但从未搭建过评测工具。

几乎总是看思考方式。能说出 LLM-as-judge 这样的方法没问题，但他们想听到你分析它的失效模式，比如评判模型偏向更长的回答，以及你会如何在一部分样本上用人工标注来验证评判模型。评测工具只是管道工程，判断力才是关键信号。

很好的清单。我想在 Agent 部分补充一点：幂等性。一旦你的 AI Agent 能在客户系统中执行真实操作，重试导致重复扣费就不再是假设性问题了。部署业务较重的公司的面试官恰恰会追问这一点。