AI 应用工程师面试：从 RAG、Agent 到评测与失败边界

完成本文后，你将画出一张 AI 应用工程答题图：RAG 负责什么、Agent 何时才需要、评测如何先于优化、延迟与成本如何拆分、权限或工具失败时系统怎样停止。OpenAI 官方快速入门页与 Evals API 参考用于核验当前 API 起步与评测资源；本文对面试组织、系统分层和风险检查的内容是本站编辑方法，不是 OpenAI 官方架构建议或招聘标准。

AI 应用面试不应停留在“会调用模型”。同一个模型请求放进真实产品后，会遇到知识时效、检索噪声、工具副作用、非确定输出、权限隔离、观测与预算。高质量回答要把模型当成系统中的一个组件：输入从哪里来，哪些上下文可信，输出怎样验证，错误在哪一层被捕获，用户能否理解当前状态。

官方快速入门展示了从创建开发环境、配置 API 密钥到通过 SDK 或 HTTP 发起首个请求的当前起步路径。它能支持“如何开始调用”的事实，却不能替你决定业务数据边界、RAG 切分策略或 Agent 权限。官方 Evals API 参考提供创建和管理 eval、运行与输出项的接口资源；评测集设计、评分标准和发布门禁仍是应用团队的工程责任。

RAG：先定义检索问题，再谈向量库

RAG 的核心问题不是“是否用了向量数据库”，而是模型回答时需要哪些外部证据，以及证据如何被找到、过滤和呈现。先定义知识对象、更新频率、权限范围和可引用粒度。若问题只需查询结构化订单状态，直接使用受控工具可能比把订单文本嵌入后检索更合适；若问题需要在大量文档中定位相关段落，检索增强才可能成为主要路径。

可以把链路拆成摄取、索引、查询理解、候选召回、重排或过滤、上下文组装、生成与引用。每一段都有独立错误：文档没有进入索引，切分丢失上下文，权限过滤晚于召回，查询改写偏离意图，候选相关但过时，模型忽略证据。回答时沿链路定位问题，避免把所有错误都归为“模型幻觉”。

检索证据要保留来源标识、版本和访问主体。权限过滤应在可越权内容进入模型上下文之前生效；仅在最终界面隐藏引用并不能消除泄露风险。对需要精确答案的场景，可以要求模型在证据不足时停止，或改由确定性查询返回。RAG 也不是事实保证，检索到错误材料仍会产生错误答案。

Agent：只有需要受控行动时才增加循环

本文把 Agent 作为一种工程形态：模型根据当前状态选择工具或下一步，系统执行后把结果返回，再决定是否继续。这个定义用于面试讨论，不声称所有框架都使用同一术语。若任务可以由一次检索和一次生成完成，就没有必要为了“更智能”加入自主循环。

Agent 设计先列工具契约：工具名称、输入模式、调用主体、权限、幂等性、超时、返回错误和副作用。读操作与写操作要分开，写操作应有更清晰的确认与审计。模型提出调用不等于调用已获授权；执行层必须再次校验身份、资源范围和业务规则。

循环需要停止条件：达到目标、需要用户补充、工具连续失败、预算或步数达到边界、检测到权限拒绝。不要把“最多循环若干次”说成普遍安全数字，具体阈值应由任务风险与实测决定。系统还要保存足够的轨迹用于诊断，但日志不能无节制记录敏感上下文。

评测：先固定任务与失败分类

评测不是上线前随机问几个问题。先建立任务样本，样本包含输入、允许使用的上下文、预期行为和关键失败条件。对 RAG，可以分别评估检索覆盖、证据相关性、答案是否受证据支持和权限过滤；对工具流程，可以评估是否选择正确工具、参数是否合法、是否在必要时请求确认、失败后是否停止。

评分方式要与风险匹配。结构化字段可以确定性比较，开放答案可以用人工准则或经过验证的自动评分，关键安全行为应有明确硬门禁。总体平均分可能掩盖高风险小类，所以要按任务类型、语言、权限角色、文档版本和失败类型切片。版本变化后用同一套核心样本回归，新增线上失败则转为去敏后的回归样本。

OpenAI 当前 Evals API 参考列出了 eval 资源及其 run 管理接口，支持创建评测定义、运行和读取相关结果等平台操作。这个事实只说明官方提供了评测 API 表面；“什么是好答案”“哪些失败阻断发布”仍需团队定义。面试回答中应把平台能力与自建准则分开。

延迟成本：按阶段做预算，而不是只换模型

端到端延迟可以拆成入口校验、检索、重排、模型首个输出等待、完整生成、工具调用、外部依赖和重试。成本也应拆成模型输入输出、检索或存储、工具服务、观测与人工复核。没有实际价格与流量数据时，不要给虚构金额；使用变量建立预算，再通过当前官方价格页和真实调用计量更新。

优化顺序从用户目标开始。若用户只需快速看到任务已接收，可以流式或异步呈现状态，但不能把未完成包装成结果。减少无关上下文通常同时改善延迟和成本，却可能损害召回；缓存可复用结果，但必须把用户、权限、版本和新鲜度纳入键与失效。并行工具可以缩短等待，也可能增加外部压力和错误组合。

把优化变成实验：固定评测集与流量切片，记录每阶段耗时、调用次数、输入输出规模、失败和重试，再比较质量门禁下的变化。只看平均延迟会忽略长尾，只看单次费用会忽略失败重试和人工兜底。

权限失败：默认拒绝不确定的行动

权限设计至少包含最终用户、应用服务、模型供应方和外部工具四个主体。API 密钥是服务凭据，不应暴露到不可信客户端或文章示例的公开位置；具体密钥配置应遵循当前官方快速入门和部署环境的秘密管理方式。应用还需要自己的用户授权，不能把“能调用模型 API”误解为“能访问任何业务数据”。

当身份过期、资源归属不明、工具返回权限拒绝或策略服务不可用时，系统应停止敏感读取和写入，给出可操作但不过度泄露的信息。不要让模型通过换一种参数继续试探，也不要把拒绝详情完整回传给可能无权的用户。恢复权限后，重新校验任务状态，避免执行过期意图。

工具返回超时与权限拒绝是不同失败：超时表示结果未知，重试前要考虑副作用与幂等；权限拒绝表示当前主体不应继续，通常需要用户或管理员明确处理。把错误统一改写成“请稍后再试”会隐藏风险，也让排障困难。

端到端演练：设计一个内部知识答疑助手

下面是一个假设练习，不是现实客户案例，也没有虚构准确率、费用或节省金额。目标是让已登录员工查询自己有权查看的内部流程文档，并在需要时创建一条人工支持请求。

**第一步，定边界。**助手只能基于当前获批文档回答；不知道时显示证据不足。创建支持请求是有副作用工具，必须展示摘要并由用户确认。它不能修改文档、代表用户审批或跨权限查询。

**第二步，设计 RAG。**摄取时保存文档版本、部门范围和失效状态；查询前取得用户角色，召回时同步过滤权限；返回段落携带文档标识与版本。模型上下文只包含过滤后的候选，并要求答案区分文档事实与下一步建议。

**第三步，设计工具。**创建请求工具接收主题、摘要和允许的附件引用，服务端再次校验用户与资源。提交使用幂等键，超时时先查询是否已创建，不能直接重复写入。权限拒绝立即停止并记录受控审计事件。

**第四步，建立评测。**样本覆盖有答案、无答案、旧版本冲突、跨部门诱导、提示注入式文档、工具参数缺失、重复确认和提交超时。检索、答案支持度、拒绝行为和工具副作用分别评分，越权与未经确认写入作为发布阻断项。

**第五步，观察延迟成本。**记录权限过滤、检索、生成和工具的分段耗时，统计上下文规模、工具次数和重试。只有在质量门禁不退化时，才实验更小上下文、缓存或并行。这里所有结果都需要实测，练习本身不声称会取得某个改善比例。

发布前检查清单

• [ ] 已区分模型能生成的内容、检索证据与确定性业务查询。
• [ ] 已在检索和工具执行前按当前用户过滤权限，而非只在界面隐藏。
• [ ] 已为每个工具定义输入、身份、幂等、超时、副作用与审计方式。
• [ ] 已准备覆盖正常、无证据、过期、越权、注入和依赖失败的评测样本。
• [ ] 已把高风险失败设为独立门禁，而不是混入一个平均分。
• [ ] 已按检索、模型、工具、重试拆分延迟与成本，并保留版本信息。
• [ ] 已定义停止、请求确认、人工升级和权限恢复后的重新校验路径。
• [ ] 已检查日志、提示、引用和评测数据是否包含不应保存的敏感信息。

适用边界与资料时效

OpenAI API 会演进，本文不锁定模型名称、价格、配额或可能变化的请求参数。实现前应重新查阅当前官方快速入门、API 参考和账户可用能力。本文没有给出通用 RAG 切分长度、Agent 步数、评测阈值或成本基准，因为这些都必须由数据、风险和实验决定。

官方文档支持的是当前平台接口事实；RAG、Agent、权限与发布门禁的组合是本文的工程分析框架，不应归因于官方。真实应用还可能需要安全、隐私、法务和行业合规审查，本文不能替代这些专业流程。

下一步：选择一个你熟悉的 AI 应用，用一张图标出“输入—权限—检索—模型—工具—评测—观测”，为每条边写一个失败场景，再把其中一个线上失败转成可重复的评测样本。