1. 为什么 AI Agent 面试突然变得这么难1.1 从“会调 API”到“会设计系统”的分水岭2024 年的时候面 AI Agent 岗位你只要能说清楚 ReAct 循环、能写个 LangChain 的 demo基本就能过。到了 2025 年下半年情况完全变了。我身边好几个朋友简历上写着“独立开发过 Agent 应用”结果一面就被问懵了——面试官不再问你“怎么调 OpenAI 的接口”而是问你“你的 Agent 在多轮工具调用中怎么做状态管理”“如果工具返回的结果有歧义你的 Agent 怎么决策”“Token 消耗失控你怎么排查”。这个变化背后的逻辑其实很清晰AI Agent 从“玩具阶段”进入了“工程阶段”。2024 年大家还在探索 Agent 能做什么2025 年开始企业真正把 Agent 往生产环境里塞问题就全暴露出来了。幻觉导致的错误工具调用、长对话下的上下文爆炸、多 Agent 协作时的死锁、工具描述不清晰导致的反复重试——这些全是工程问题不是调个 API 就能解决的。所以面试的考察重心从“你知不知道”变成了“你踩过多少坑、怎么解决的”。这篇文章我会把目前 AI Agent 面试的高频考点做一个系统梳理覆盖从基础概念到架构设计到工程落地的完整链路。不管你是刚入行的开发还是想从传统后端转 Agent 方向这套东西都能帮你把知识体系串起来。1.2 面试官到底想筛出什么样的人我先说一个观察现在招 AI Agent 工程师的团队大致分两类。一类是做大模型应用层的创业公司他们需要你能快速搭出可用的 Agent 产品对工程效率要求极高另一类是大型企业的 AI 平台部门他们需要你设计通用的 Agent 框架对架构能力和稳定性要求极高。这两类面试的侧重点不同但核心考察点有大量重叠。面试官真正想确认的是三件事第一你是否理解 Agent 和传统程序的区别知道哪些地方容易出问题第二你是否有实际调试和优化 Agent 的经验而不是只跑过 demo第三你的知识面是否够宽因为 Agent 涉及 LLM、工具调用、记忆管理、多轮对话、评估体系等多个模块任何一块短板都可能导致系统不可用。我面过不少人最怕遇到的那种是“背了一堆名词但没动过手”的候选人。你问他 Function Calling 的原理他能说得头头是道但你问他“如果模型返回的 function call 参数格式不对怎么办”他就卡住了。这种就是典型的只看了文档没写过代码。所以下面的内容我会尽量把每个考点都落到“实际怎么做”的层面。2. 核心概念与基础原理高频考点2.1 Agent 和 Workflow 的本质区别到底是什么这是几乎每场面试都会问的问题但很多人答不到点子上。常见的错误回答是“Agent 更智能”“Agent 能自主决策”——太模糊了。面试官想听的是你对控制流的理解。Workflow 的控制流是开发者预先定义好的。你写一个 DAG节点 A 执行完走节点 B条件判断走节点 C所有路径都是你写死的。Agent 的控制流是模型在运行时决定的。你给它一个目标它自己决定调哪个工具、调几次、什么时候停。这个区别听起来简单但它带来了一系列工程后果Workflow 的行为可预测测试好写但灵活性差Agent 的行为灵活但不可预测测试和评估难度指数级上升。我一般会用一个具体例子来说明假设你要做一个“帮用户查订单并处理退款”的系统。Workflow 的做法是——先调查订单接口如果订单状态是“已发货”就走退货流程如果是“未发货”就走取消流程每个分支都是你写好的。Agent 的做法是——你把查订单、退货、取消这几个工具都给它让它根据用户输入自己判断该调哪个。前者你永远知道它会做什么后者你永远不知道它下一步会做什么。面试官接着通常会问“那你什么时候用 Workflow什么时候用 Agent”我的回答是任务路径确定、对稳定性要求高的场景用 Workflow任务路径不确定、需要处理开放式输入的场景用 Agent。实际项目中大部分生产系统是两者混合——外层用 Workflow 保证主流程可控内层用 Agent 处理需要灵活判断的环节。2.2 ReAct 循环的工程实现细节ReAct 是 Agent 最基础的推理框架全称是 Reasoning Acting。原理很简单模型先输出思考Thought然后决定调什么工具Action拿到工具返回结果Observation再继续思考循环直到得出最终答案。但面试官不会只让你背这个循环他会问工程细节。比如“ReAct 循环什么时候终止”很多人回答“模型输出最终答案时终止”这没错但不完整。实际工程中你需要设置多重终止条件最大循环次数防止死循环、Token 预算上限防止成本失控、连续无进展检测如果连续两轮 Observation 没有带来新信息就强制终止。再比如“如果模型在 Thought 阶段产生了幻觉调了一个不存在的工具怎么办”这是实际开发中非常常见的问题。解决方案是在解析模型输出时做工具名校验如果工具名不在注册列表中不要直接把错误抛给模型而是返回一个结构化的错误信息告诉模型“工具 X 不存在可用工具列表是 [...]”让模型重新决策。这个细节能体现你是否真正处理过生产环境的问题。还有一个高频追问“ReAct 和 Plan-and-Execute 有什么区别各自适合什么场景”ReAct 是边想边做每一步都依赖上一步的结果适合探索性任务Plan-and-Execute 是先制定完整计划再逐步执行适合步骤明确但需要提前规划的任务。Plan-and-Execute 的优势是可以并行执行独立步骤劣势是计划可能跟不上变化。实际项目中我倾向于用 Plan-and-Execute 做任务分解用 ReAct 做每个子任务的执行。2.3 Function Calling 与 Tool Use 的底层机制Function Calling 是 Agent 调用外部能力的核心机制。面试中常见的考察角度有几个第一个是“模型是怎么知道有哪些工具可用的”。答案是通过 system prompt 中的工具描述。每个工具需要提供名称、功能描述、参数 schema。这里有个关键细节工具描述的质量直接决定了模型能否正确选择工具。我见过太多项目工具描述写得含糊不清导致模型频繁调错工具。好的工具描述应该包含这个工具做什么、什么时候该用、什么时候不该用、每个参数的含义和格式要求。第二个是“模型返回的 function call 参数格式不对怎么处理”。这是实际开发中极其常见的问题。比如你定义了一个参数是 integer 类型模型返回了字符串 “123”。解决方案分两层第一层是在工具执行前做参数校验和类型转换能自动修复的就修复第二层是如果无法修复把校验错误信息返回给模型让它重新生成。千万不要直接抛异常那样整个 Agent 循环就断了。第三个是“并行工具调用怎么处理”。2025 年后的主流模型基本都支持一次返回多个 tool call。工程上你需要判断这些调用之间是否有依赖关系——如果没有依赖可以并行执行提升效率如果有依赖必须串行执行。判断依赖关系本身也是个难题简单场景可以靠人工配置复杂场景需要让模型自己判断。2.4 记忆系统的分层设计Agent 的记忆系统是面试中区分度很高的考点。初级候选人只知道“把对话历史塞进 context”高级候选人能说清楚短期记忆、长期记忆、工作记忆的分层设计。短期记忆就是当前对话的上下文窗口通常直接放在 messages 数组里。但这里有个工程问题对话轮次多了之后context 会爆炸。解决方案有几种——滑动窗口只保留最近 N 轮、摘要压缩把早期对话用模型总结成一段话、关键信息提取只保留实体和意图相关的信息。每种方案都有取舍滑动窗口简单但会丢失早期信息摘要压缩保留信息但增加了一次模型调用关键信息提取效率高但可能漏掉细节。长期记忆通常用向量数据库实现把历史对话、用户偏好、领域知识等存进去需要的时候做语义检索。这里的关键考点是“什么时候触发检索”——是在每轮对话开始前都检索还是只在模型判断需要时才检索前者简单但增加延迟和噪声后者高效但依赖模型的判断能力。实际项目中我倾向于混合策略对话开始时做一次粗检索对话过程中如果模型主动请求记忆检索再做精检索。工作记忆是 Agent 在执行具体任务时的临时状态比如当前任务的步骤列表、已完成的步骤、中间结果等。这部分通常用结构化数据存储不直接放在 context 里而是按需注入。工作记忆的设计直接影响 Agent 处理复杂任务的能力。3. 架构设计与系统实现深度考察3.1 单 Agent 还是多 Agent架构选型的决策逻辑“你这个项目为什么用多 Agent 架构”这是面试中很容易被问倒的问题。很多人做多 Agent 只是因为“看起来更高级”但说不出实际收益。面试官想听的是你对多 Agent 适用场景的理解。多 Agent 的核心价值在于“关注点分离”。当一个任务需要多种截然不同的能力时用一个 Agent 处理所有事情会导致 prompt 过于复杂、工具集过于庞大、模型容易混淆。拆成多个专职 Agent 后每个 Agent 的 prompt 更聚焦、工具集更小、决策更准确。比如一个“自动客服”系统查订单、处理退款、回答产品问题这三件事用一个 Agent 做也不是不行但拆成三个专职 Agent 后每个 Agent 的准确率都会明显提升。但多 Agent 也带来了新问题Agent 之间怎么通信、怎么协调、怎么避免死锁。常见的通信模式有三种——消息传递Agent 之间通过消息队列通信、共享状态所有 Agent 读写同一个状态存储、层级调度一个 Orchestrator Agent 负责分配任务给 Worker Agent。每种模式适合不同场景消息传递适合异步松耦合的场景共享状态适合需要频繁同步信息的场景层级调度适合任务分解明确的场景。面试中还有一个高频追问“多 Agent 系统怎么调试”这确实是个痛点。单 Agent 你可以看完整的对话历史多 Agent 系统的执行路径是发散的很难追踪。我的做法是在每个 Agent 的关键决策点打日志记录输入、输出、决策理由然后用 trace ID 把同一个任务的所有 Agent 调用串起来。这样出问题时可以完整回放整个执行链路。3.2 工具设计与注册的最佳实践工具设计是 Agent 开发中最容易被低估的环节。我见过很多项目模型能力没问题但就是因为工具设计得不好导致 Agent 表现很差。工具粒度的把握是第一个难点。粒度太粗一个工具做太多事情模型很难正确传参粒度太细工具数量爆炸模型选择困难。我的经验是一个工具只做一件事但这件事要有完整的业务含义。比如“查询订单”是一个好工具“查询订单表”就不是——后者暴露了实现细节模型不需要知道你的数据存在哪张表里。工具描述的质量是第二个难点。好的工具描述应该让一个不了解你系统的人也能正确使用。我通常要求团队里的工具描述包含四个部分功能说明这个工具做什么、使用场景什么时候该用、参数说明每个参数的类型、含义、示例值、返回值说明返回什么格式的数据。这四部分写清楚了模型调用的准确率能提升一大截。工具的错误处理是第三个难点。工具执行失败时返回给模型的信息非常关键。不要返回“Error: 500”这种无意义的信息要返回结构化的错误描述比如“订单号 12345 不存在请确认订单号是否正确”。这样模型才能根据错误信息做出正确的下一步决策——是重试、是换一个工具、还是告诉用户信息有误。3.3 上下文工程Token 预算与信息密度Context 管理是 Agent 工程中最考验经验的部分。面试中常问的问题是“你的 Agent 在长对话中怎么保持性能”核心矛盾是context 越长模型能参考的信息越多但成本越高、延迟越大、注意力越容易分散。解决思路是提高信息密度——让每一段放进 context 的内容都是高价值的。具体做法包括第一对话历史做滚动摘要把超过 N 轮的对话压缩成摘要只保留关键决策和结论第二工具返回结果做裁剪只保留模型决策需要的信息不要把整个 API 返回的 JSON 都塞进去第三系统 prompt 精简把不必要的行为约束去掉只保留核心规则第四动态注入根据当前任务阶段只注入相关的工具描述和记忆而不是把所有工具和记忆都塞进去。我做过一个实测一个客服 Agent不做任何 context 优化时平均每轮对话消耗 8000 token做了滚动摘要和工具结果裁剪后降到 3000 token 左右而且回答质量没有下降。这个优化带来的成本降低是非常可观的。3.4 评估体系怎么证明你的 Agent 是好的“你怎么评估 Agent 的效果”这个问题能直接区分出有没有做过生产级项目。跑几个 demo 觉得“效果不错”不叫评估。Agent 的评估比传统模型评估复杂得多因为它的输出是多步的、路径依赖的。我通常从三个维度做评估结果正确性最终答案对不对、过程合理性执行路径是否高效、有没有绕弯路、鲁棒性面对异常输入是否能优雅处理。结果正确性相对好评估准备一批测试用例人工标注标准答案跑一遍看准确率。过程合理性需要看执行轨迹比如完成同一个任务理想路径是 3 步你的 Agent 平均走了 7 步那就说明规划能力有问题。鲁棒性测试需要构造边界 case比如空输入、超长输入、包含特殊字符的输入、工具返回异常时的表现等。评估的频率也很重要。每次修改 prompt、增加工具、调整模型参数后都应该跑一遍回归测试。我建议在项目初期就搭建自动化评估 pipeline不要等到上线前才想起来做评估。4. 工程落地与性能优化实战4.1 从零搭建一个 Agent 系统的完整流程面试中经常会有“给你一个场景你怎么设计 Agent 系统”这类开放题。我以“企业知识库问答 Agent”为例把完整的设计流程拆一遍。第一步是需求拆解。企业知识库问答的核心需求是用户用自然语言提问Agent 从知识库中找到答案并返回。但拆细了有很多子问题——知识库是结构化的还是非结构化的需不需要多轮对话需不需要权限控制回答需要引用来源吗这些问题的答案直接影响架构设计。第二步是工具设计。这个场景至少需要三个工具知识库检索输入查询语句返回相关文档片段、文档详情获取输入文档 ID返回完整内容、答案生成输入问题和文档片段返回结构化答案。注意最后一个工具——很多人会把答案生成放在 Agent 的最终输出里但我倾向于把它也做成一个工具这样可以单独评估和优化答案生成的质量。第三步是流程设计。用户提问后Agent 先调检索工具拿到相关文档片段后判断信息是否充足。如果充足调答案生成工具如果不充足调整查询语句重新检索或者告知用户信息不足。这个判断逻辑就是 Agent 的核心价值所在。第四步是评估和迭代。准备一批标准问答对跑评估看准确率和召回率。分析失败 case看是检索没召回、还是答案生成有误、还是 Agent 的判断逻辑有问题针对性优化。4.2 延迟优化的几个实用手段Agent 的延迟是用户体验的杀手。一个请求如果超过 10 秒用户就会明显感到卡顿。面试中如果问到性能优化能说出具体手段的候选人会加分很多。最有效的优化是流式输出。Agent 的思考过程、工具调用、最终答案都可以流式返回给前端用户看到内容在逐步生成感知延迟会大幅降低。这个优化实现成本不高但效果立竿见影。第二个优化是并行工具调用。前面提到过如果多个工具调用之间没有依赖关系就并行执行。比如同时检索多个知识库、同时查询多个数据源能把串行等待时间压缩到最慢的那个调用的时间。第三个优化是缓存。Agent 系统中很多调用是可以缓存的——相同的工具调用结果、相似的检索查询、常见的问答对。缓存策略需要根据业务特点设计比如知识库检索结果可以缓存较长时间实时数据查询就不能缓存。第四个优化是模型分级。不是所有决策都需要用最强的模型。简单的意图识别、参数提取可以用小模型复杂的推理和规划再用大模型。这样能在保证效果的前提下降低延迟和成本。4.3 成本控制的实战经验Token 成本是 Agent 项目绕不开的问题。我见过一个项目上线第一个月 Token 费用就超了预算的 5 倍原因就是没有做任何成本控制。成本控制的核心思路是“该省的地方省该花的地方花”。具体来说系统 prompt 能精简就精简不要写一大堆用不上的约束工具返回结果做裁剪只保留关键信息对话历史做压缩不要无限增长简单任务用小模型复杂任务才用大模型设置 Token 预算上限超过就降级处理。但有些地方不能省工具描述要写清楚省这点 Token 导致模型调错工具反而浪费更多关键决策的推理过程要保留省这点 Token 导致决策质量下降得不偿失评估和监控的调用不能省没有这些你根本不知道钱花在哪了。我一般会做一个 Token 消耗的监控面板按 Agent、按工具、按对话轮次统计消耗找出消耗大户针对性优化。实测下来做好监控和优化后成本能降低 50% 到 70%。4.4 错误处理与降级策略生产环境的 Agent 必须考虑各种异常情况。面试中问到“你的 Agent 挂了怎么办”能说出完整降级策略的候选人很少。常见的异常包括模型 API 超时或限流、工具执行失败、模型输出格式不符合预期、context 超出限制、循环次数达到上限。每种异常都需要有对应的处理策略。模型 API 异常时重试是最基本的但要设置重试次数和退避策略。如果重试仍然失败需要降级——比如切换到备用模型、返回缓存的答案、或者告知用户稍后再试。工具执行失败时把错误信息返回给模型让它决策同时记录日志用于后续分析。模型输出格式异常时尝试解析和修复修复不了就重新生成。Context 超限时触发压缩或截断策略。循环次数达到上限时返回当前已获得的最佳答案并标注“可能不完整”。这些策略需要在系统设计阶段就考虑进去而不是出了问题再补。我建议在 Agent 框架层面统一处理这些异常而不是每个 Agent 单独实现。5. 高频面试题与排查技巧实录5.1 那些容易被问倒的细节问题我整理了一些面试中高频出现但容易答不好的问题附上我的回答思路。问题一“你的 Agent 怎么处理用户输入中的歧义”这个问题考察的是你对 Agent 决策能力的理解。好的回答应该包含首先识别歧义可以通过模型判断或规则匹配然后决定处理策略——是向用户澄清还是根据上下文推断最可能的意图还是列出所有可能的解释让用户选择。不同策略适合不同场景高风险操作应该倾向于澄清低风险查询可以倾向于推断。问题二“多轮对话中用户突然切换话题怎么办”这考察的是对话状态管理。基本思路是检测话题切换可以通过意图分类或语义相似度判断然后决定是保留还是清空之前的上下文。我的做法是保留但标记让模型知道这是新话题但之前的信息仍然可参考。这样既不会让旧上下文干扰新话题也不会丢失可能有用的历史信息。问题三“Agent 调用工具时怎么防止它调用危险操作”这是安全相关的考点。基本策略包括工具分级读操作和写操作分开写操作需要额外确认、权限控制不同用户可用的工具不同、敏感操作二次确认比如删除数据前让用户确认、操作审计记录所有工具调用日志。这些策略需要在工具注册层面就设计好而不是靠 prompt 约束。问题四“怎么评估 Agent 的推理能力”这个问题比较开放。我的回答思路是设计需要多步推理的任务看 Agent 能否正确分解和执行设计需要工具组合的任务看 Agent 能否选择正确的工具序列设计包含干扰信息的任务看 Agent 能否忽略无关信息。评估指标包括任务完成率、步骤效率、错误恢复能力等。5.2 常见问题速查表问题现象可能原因排查方向解决方案Agent 反复调用同一个工具工具返回结果不清晰模型无法判断是否完成检查工具返回格式和内容优化工具返回值增加状态标识Agent 不调用工具直接回答工具描述不够吸引或模型倾向于直接回答检查 system prompt 和工具描述强化工具使用引导增加“必须使用工具”的约束多轮对话后回答质量下降Context 过长导致注意力分散检查 context 长度和内容实施滚动摘要和 context 压缩工具调用参数格式错误参数 schema 定义不清晰检查参数类型和描述增加参数示例做参数校验和自动修复Agent 陷入死循环缺少终止条件或终止条件不生效检查循环控制逻辑设置最大循环次数和 Token 预算上限多 Agent 协作时任务丢失通信机制不可靠或状态不同步检查消息传递和状态管理增加确认机制和超时重试响应延迟过高串行调用过多或模型选择不当分析调用链路耗时并行化独立调用分级使用模型Token 消耗异常Context 膨胀或工具返回过大统计各环节 Token 消耗裁剪工具返回压缩对话历史5.3 我踩过的那些坑说几个实际项目中踩过的坑都是面试中可以拿出来讲的真实经验。第一个坑是工具描述写得太技术化。早期我做数据库查询工具描述写的是“执行 SQL 查询语句”结果模型经常生成不合法的 SQL。后来改成“根据自然语言查询条件检索数据输入查询条件描述返回匹配的数据记录”模型的表现立刻好了很多。教训是工具描述要面向模型的理解能力而不是面向开发者的技术习惯。第二个坑是忽略了工具返回结果的格式。有个工具返回的是嵌套很深的 JSON模型经常解析错误。后来我把返回结果扁平化只保留关键字段并且用自然语言描述返回内容问题就解决了。教训是工具返回给模型的内容要尽量简单直接不要考验模型的 JSON 解析能力。第三个坑是没有做 context 压缩。一个长对话场景跑了十几轮之后 Token 消耗飙升而且模型开始“忘记”前面的信息。后来加了滚动摘要每五轮把之前的对话压缩成一段摘要问题就解决了。教训是context 管理要提前设计不要等到出问题才补救。第四个坑是评估做得太晚。项目快上线了才开始做评估发现一堆问题但来不及改。后来养成了习惯项目初期就搭建评估 pipeline每次改动都跑回归测试。教训是评估不是上线前的检查项而是开发过程中的基础设施。5.4 面试中的加分项与减分项最后说一些面试中的软性观察。加分项包括能主动说出方案的取舍和适用边界而不是一味说“这个方案好”能举出具体的数字和案例比如“优化后延迟从 8 秒降到 3 秒”能承认自己踩过的坑和当时的解决方案对新技术保持关注但有自己的判断不盲目追新。减分项包括只谈概念不谈实现问细节就卡住把所有问题都归结为“调 prompt”缺乏系统思维对成本和性能没有概念觉得“能跑就行”过度依赖框架说不清楚底层原理。面试本质上是在验证你的经验是否真实、你的能力是否匹配岗位需求。把上面这些内容吃透结合自己的实际项目经验去准备通过率会有明显提升。这个领域变化很快保持动手、保持踩坑、保持总结比背任何题库都管用。