AI Agent开发面经合集

写在前面

【WeThinkIn出品】栏目专注于分享Rocky的认知思考与经验感悟，范围涵盖但不限于AI行业。

干货AIGC、AI Agent、LLM算法工程师/开发工程师面试面经秘籍分享（持续更新）：<a href="https://gw-c.nowcoder.com/api/sparta/jump/link?link=https%3A%2F%2Fgithub.com%2FWeThinkIn%2FAIGC-Interview-Book" rel="nofollow noopener noreferrer" target="_blank">WeThinkIn/AIGC-Interview-Book</a>欢迎大家Star～

大家好，我是Rocky。

面试问题汇总

1. 介绍一下自己的项目，整体架构和技术栈是什么？

回答：

项目介绍要围绕一个真实业务闭环，而不是罗列框架名称。推荐按照“业务问题 -> Agent 链路 -> 关键模块 -> 指标与结果”的顺序回答。

可以先说用户、任务和原流程痛点，再给出架构：接入层负责鉴权和会话，编排层负责状态机/Workflow/Agent Loop，模型层负责规划、结构化输出和工具选择，知识层提供 RAG，工具层访问业务 API，状态层保存短期上下文和长期记忆，最后由评测、日志和告警形成闭环。

技术栈需要与职责绑定，例如 Python/FastAPI 负责模型和 Agent 服务，LangChain/LangGraph 负责组件复用与图式编排，Redis/PostgreSQL 保存会话和任务状态，向量库承担 ANN 检索，消息队列支持长任务异步化，OpenTelemetry/日志平台负责链路追踪。若实际使用的是其他组件，应如实替换。

最后必须说明数据流、一次请求的状态变化、关键取舍、成功率/延迟/成本等指标，以及自己真正负责的模块。面试官更关心“为什么这样设计、哪里失败、怎么验证”，而不是技术栈的数量。

2. 项目中 Agent 的完整流程是怎样的？

回答：

典型 Agent Loop 可以表示为：

<div class="math math-display">

\text{Request}\rightarrow\text{State/Context}\rightarrow\text{Plan/Route} \rightarrow\text{Tool Call}\rightarrow\text{Observation}\rightarrow\text{Validate} \rightarrow\text{Final or Next Step}

</div>

具体过程是：接入层鉴权并创建 conversation_id、task_id；读取当前会话、用户偏好和任务相关知识；模型进行意图识别、任务拆分或路由；如果需要外部能力，就生成符合 schema 的工具调用；服务端校验参数、权限、预算和幂等键后执行工具；将工具结果作为 observation 写回状态；验证器检查格式、事实、业务规则和停止条件；未完成时继续下一轮，完成时生成最终答复并保存摘要、引用和可观测轨迹。

循环必须有最大步数、总 token/费用预算、单步超时和全局 deadline。工具失败要分类处理：可重试的瞬时错误重试，不可重试的参数错误要求模型修正或直接降级，副作用工具要使用幂等键并支持人工确认。Agent 的本质不是“模型调用工具一次”，而是带状态、观察和停止条件的受控决策循环。

3. 项目过程中针对 Agent 做过哪些优化？具体怎么调优？

回答：

我会先用 trace 把一次任务拆成模型耗时、排队耗时、工具耗时、检索耗时、重试次数、上下文 token 和失败节点，再按瓶颈优化，而不是凭感觉改 Prompt。

常见优化包括：

• 对简单意图走固定 Workflow 或小模型路由，复杂任务才进入 Agent Loop；
• 将工具描述、Prompt 和输出 schema 精简，减少无效上下文；
• 对独立检索/工具调用并行执行，对模型、Embedding 和静态结果做缓存；
• 使用结构化输出、参数校验和状态机减少无效循环；
• 对工具错误分类，设置有限重试、指数退避、熔断和可解释降级；
• 调整 RAG 的召回、Rerank、上下文压缩和引用策略；
• 对长任务采用异步队列、checkpoint 和断点续跑，避免请求超时丢失进度。

调优要固定评测集和版本，做单变量消融，观察任务成功率、工具调用正确率、首 token/总延迟、token 成本、重试率和安全违规率。线上灰度时同时设置 P99、错误率和用户负反馈护栏，避免只优化某一个离线指标。

4. Agent 优化有哪些常见手段？

回答：

可以从模型、上下文、工具、编排、系统和评估六层回答：

1. 模型层： 模型路由、提示模板、结构化输出、必要时微调/蒸馏，控制温度和最大输出。
2. 上下文层： 只注入任务相关信息，做摘要、压缩、去重、优先级排序和检索，避免无边界拼接历史。
3. 工具层： 减少工具重叠，提供清晰 schema、示例、错误码、权限和幂等语义，让工具返回机器可读结果。
4. 编排层： 简单任务使用 Workflow，复杂任务使用图式状态机；限制最大步数，加入路由、验证、反思和人工审批。
5. 系统层： 并行调用、缓存、批处理、异步化、超时、重试、熔断、限流、checkpoint 和灰度发布。
6. 评估层： 建立任务集和轨迹集，评估最终结果、工具选择、参数正确率、过程效率、成本、延迟和安全。

优化的原则是先测量再修改。Agent 的问题可能来自错误规划，也可能来自工具契约、检索证据、上下文过长或服务超时；只改 Prompt 往往会把系统问题掩盖成偶然的模型波动。

5. 基于项目设计一个场景，如果遇到类似问题应该怎么解决？

回答：

场景题先不要急着选框架。我会先澄清用户目标、输入输出、时延、准确率、数据权限、外部副作用、失败代价和人工介入要求，再决定是 Workflow 还是 Agent。

例如设计一个“根据企业内部规范生成并提交变更申请”的 Agent：

1. 先检索并引用当前版本规范，识别申请类型和缺失字段；
2. 用结构化 schema 生成申请草稿，规则引擎校验字段、权限和风险等级；
3. 对只读查询可以自动执行，对写入/提交动作必须二次确认或人工审批；
4. 提交前再次检查版本、重复申请和幂等键，提交后轮询状态并把结果写入任务状态；
5. 任一工具失败都保留 checkpoint，按错误类型重试、换工具或返回人工处理，不让模型自行绕过权限。

评估包含字段准确率、规范引用正确率、工具参数正确率、审批拦截率、任务完成率、延迟和成本。这个回答体现的是问题拆解、约束建模、风险分级和可验证闭环，而不是只说“让大模型自主规划”。

6. 语义检索是如何实现的？

回答：

语义检索通常分为离线建库和在线检索两部分。

离线侧对文档解析、清洗、按标题/段落/语义边界分块，保留文档 ID、版本、权限、时间和来源等 metadata；用 Embedding 模型将块编码为向量，写入向量数据库或 ANN 索引，同时维护倒排索引。

在线侧先规范化 Query，必要时做意图识别、改写和过滤条件提取；用同一表示空间的 Embedding 编码 Query，进行向量召回，并与 BM25/关键词、规则和结构化过滤融合；对候选用 Cross-Encoder Rerank，按阈值或 token 预算截断，去重后注入上下文并携带引用。

向量相似度可以写成：

<div class="math math-display">

s(q,d)=\frac{e_q^{\mathsf T}e_d}{\lVert e_q\rVert_2\lVert e_d\rVert_2}

</div>

工程上不能只看相似度。要验证 Recall@K、MRR/nDCG、证据支持率、无结果率、延迟、索引更新时效和权限过滤正确率；专业术语、编号、代码和新词通常需要保留关键词召回。

7. 向量数据库在项目中具体承担什么作用？

回答：

向量数据库的核心职责是对高维 Embedding 做近似最近邻检索，并把向量与文档 ID、租户、权限、版本、时间等 metadata 关联起来。它解决的是“从大规模候选中快速找语义相近对象”，不是替代知识库、业务数据库或事实校验系统。

典型能力包括向量写入和更新、ANN 索引构建、Top-K 相似度查询、metadata 过滤、分区/分片、持久化、备份和扩容。HNSW 适合低延迟和较高召回，IVF/PQ 等方案更关注大规模内存和成本；具体选择要由数据规模、更新频率、召回要求和 P99 决定。

上线时要处理 embedding 模型版本、维度变更、增量更新、删除一致性、冷热数据、租户隔离和索引重建。向量库返回的只是候选证据，还需要 Rerank、权限二次校验、文档版本校验和生成后引用验证。

8. langchain、langgraph 这些框架为什么选择？底层流程了解吗？

回答：

选择框架的理由应该是降低工程成本和提高可观测性，而不是因为“大家都在用”。LangChain 提供模型、Prompt、Parser、Retriever、Tool 等组件抽象，适合快速组合常见链路；LangGraph 在此基础上把 Agent 表达为带共享状态的有向图，节点执行计算，边负责路由，支持循环、条件分支、checkpoint、恢复和人在回路。

底层流程仍然是：应用构造消息和工具 schema，调用模型；模型返回文本或 tool call；框架解析响应并更新 state；路由节点决定下一步；工具节点执行并把 observation 写回；直到满足终止条件。框架不会替模型解决事实性、权限、幂等和业务规则。

如果流程固定、延迟敏感，直接实现轻量状态机可能更容易调试；如果有多分支、长任务、恢复和人工审批，图式框架更有价值。生产中应封装自己的 Provider、Tool、State 和 Trace 接口，避免业务逻辑散落在框架回调中，并锁定版本、评估升级兼容性和额外延迟。

9. 模型输出结果如何控制规则？

回答：

规则控制要形成“生成约束 + 解析校验 + 业务决策 + 执行隔离”四层防线。

生成前给出 JSON Schema、字段枚举、必填项、单位、示例和禁止行为；能使用 constrained decoding 或结构化输出就不要只依赖 Prompt。生成后先做 JSON 解析、类型/范围/枚举、跨字段一致性和引用完整性校验，失败则有限次修复或降级。

涉及业务规则时，规则引擎应由代码维护，例如权限、金额上限、状态机迁移、黑名单和合规策略，不能让模型通过自然语言“判断自己是否有权限”。工具层再次做鉴权、参数校验、幂等和资源限制；写操作、高风险动作和不可逆操作设置人工确认。

最终输出还应记录模型版本、Prompt 版本、校验结果、工具轨迹和拒绝原因。模型负责生成候选意图，确定性规则负责决定是否接受和执行，这才是可审计的控制链路。

10. 记忆模块是怎么设计的？

回答：

Memory 不是把所有历史消息无限追加到 Prompt，而是把历史信息按用途和时效分层。

• 短期记忆： 当前会话消息、工具结果、任务状态和未完成计划，放在 checkpoint/session store 中，服务于当前任务恢复。
• 长期语义记忆： 用户偏好、稳定事实、历史经验和重要事件，以结构化记录或向量索引保存，带时间、置信度、来源和版本。
• 工作记忆： 当前任务的目标、约束、已完成步骤、待办和错误，优先使用结构化 state，而不是让模型从长文本中猜。

写入长期记忆前要做重要性判断、去重、冲突检测、敏感信息过滤和用户授权；读取时按当前 Query、租户、权限和时间衰减检索，经过 Rerank 和 token 预算截断。摘要要保留事实、来源和不确定性，不能把模型猜测写成用户事实。

记忆系统还要支持删除、过期、纠错、审计和隔离。评估它对任务成功率、重复询问率、上下文 token、错误记忆引用和隐私风险的真实贡献，而不是只看“记住了多少内容”。

11. 多轮、多会话场景下 memory 如何处理？

回答：

核心是建立明确的身份层级和状态隔离：tenant_id -> user_id -> conversation_id -> task_id。会话级状态只服务于当前对话，用户级长期记忆可以跨会话使用，但必须经过权限、租户和用途校验；任务级 checkpoint 用于长任务恢复，不能直接当作长期用户画像。

每条消息和记忆记录带时间、来源、版本、有效期和写入原因。并发请求通过版本号、乐观锁或事件序列保证同一会话的更新顺序；重复提交使用幂等键。新旧记忆冲突时，优先考虑更近且证据更强的事实，同时保留冲突状态或要求用户确认，不能简单用最后写入覆盖所有历史。

上下文组装时按当前问题检索相关记忆，区分“明确事实”“用户偏好”“历史推测”和“本轮临时状态”，并设置 token 预算。会话结束后可异步摘要，原始记录仍按隐私和审计策略保存；用户应能够查看、更正和删除长期记忆。

12. 如果系统出现异常，整体的容错和异常处理机制怎么设计？

回答：

先建立可观测的错误分类：输入/鉴权错误、模型限流或超时、工具业务错误、网络瞬时错误、解析校验错误、状态存储错误和不可恢复错误。每类错误定义责任边界、重试策略和用户可见结果。

服务层设置 deadline、连接超时、读取超时和最大 Agent 步数；瞬时网络错误使用带抖动的指数退避，非幂等操作必须有幂等键，不能盲目重试。模型服务可以配置备用模型或降级为模板/人工处理；检索失败可以返回无证据状态，不能让模型无依据编造。连续失败触发熔断，恢复后半开探测。

长任务通过队列和 checkpoint 记录每一步输入、输出、状态和副作用；服务重启后从最后安全点恢复，已执行操作由幂等机制避免重复。对部分成功任务要有补偿或人工介入。日志中记录 trace_id、task_id、模型版本、工具名、耗时和错误码，同时对 Prompt、Token 和业务数据脱敏。

容错设计最终要用超时、限流、工具 5xx、空检索、重复消息和状态库故障做故障注入，观察任务完成率、错误恢复率、重复副作用、P99 和用户提示是否可解释。

13. 再给一个上下文处理相关的场景题，如何优化 context 管理？

回答：

例如一个 Agent 需要处理数百页规范文档、几十轮对话和多次工具结果，但模型上下文预算有限。我会先定义当前任务真正需要的证据和状态，再做上下文分层，而不是简单截断末尾消息。

1. 把系统规则、当前目标、硬约束、已确认事实、待办状态、检索证据和历史对话分区；结构化状态优先于自然语言复述。
2. 对历史消息做摘要，但保留时间、参与者、结论、未决问题和证据引用；原始消息放在可检索存储中，需要时按 Query 召回。
3. 文档采用混合检索和 Rerank，按相关性、权威性、新鲜度和权限过滤；对相互矛盾的证据显式标注，不把所有候选拼进去。
4. 给每类信息设置 token 预算和优先级，保留当前约束、工具 schema 和关键证据，淘汰重复说明、已完成步骤和低置信度内容。
5. 输出前检查上下文是否包含必要字段、是否超过预算、引用是否支持结论；对证据不足触发澄清或拒答。

评估要看长上下文下的关键信息召回率、任务成功率、引用忠实度、token 成本和延迟，并与简单截断、摘要、RAG 等方案做对照。上下文工程的本质是给模型构造“当前决策所需的最小充分状态”。

14. 手撕算法：Greedy（贪心相关）

回答：

贪心不是“每一步选当前最小/最大”就一定正确。需要证明两个条件：一是贪心选择性质，存在一个最优解包含当前选择；二是最优子结构，做出选择后剩余问题仍是同类最优问题。面试时应先问清目标函数、输入约束、是否允许排序和是否要求输出方案。

经典例子是区间调度：给定若干活动 (start,end)，选择最多个互不重叠区间。按结束时间升序排序，每次选择结束最早且与已选区间兼容的活动。结束越早，为后续留下的空间越大，可以用交换论证证明该选择不劣。

def max_non_overlapping(intervals):
    intervals.sort(key=lambda pair: pair[1])
    count = 0
    current_end = float("-inf")

    for start, end in intervals:
        if start >= current_end:
            count += 1
            current_end = end

    return count

时间复杂度为 O(n\log n)，主要来自排序，额外空间取决于排序实现。若题目改成“带权区间最大收益”，简单贪心就不成立，需要按结束时间排序并用二分查找前驱，结合动态规划；这也是判断贪心边界的重要追问。

<a href="https://gw-c.nowcoder.com/api/sparta/jump/link?link=https%3A%2F%2Fwww.nowcoder.com%2Fusers%2F648015371" target="_blank"></a>