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 常见问题速查表

5.3 我踩过的那些坑

说几个实际项目中踩过的坑，都是面试中可以拿出来讲的真实经验。

第一个坑是工具描述写得太技术化。早期我做数据库查询工具，描述写的是“执行 SQL 查询语句”，结果模型经常生成不合法的 SQL。后来改成“根据自然语言查询条件检索数据，输入查询条件描述，返回匹配的数据记录”，模型的表现立刻好了很多。教训是：工具描述要面向模型的理解能力，而不是面向开发者的技术习惯。

第二个坑是忽略了工具返回结果的格式。有个工具返回的是嵌套很深的 JSON，模型经常解析错误。后来我把返回结果扁平化，只保留关键字段，并且用自然语言描述返回内容，问题就解决了。教训是：工具返回给模型的内容要尽量简单直接，不要考验模型的 JSON 解析能力。

第三个坑是没有做 context 压缩。一个长对话场景，跑了十几轮之后 Token 消耗飙升，而且模型开始“忘记”前面的信息。后来加了滚动摘要，每五轮把之前的对话压缩成一段摘要，问题就解决了。教训是：context 管理要提前设计，不要等到出问题才补救。

第四个坑是评估做得太晚。项目快上线了才开始做评估，发现一堆问题但来不及改。后来养成了习惯，项目初期就搭建评估 pipeline，每次改动都跑回归测试。教训是：评估不是上线前的检查项，而是开发过程中的基础设施。

5.4 面试中的加分项与减分项

最后说一些面试中的软性观察。加分项包括：能主动说出方案的取舍和适用边界，而不是一味说“这个方案好”；能举出具体的数字和案例，比如“优化后延迟从 8 秒降到 3 秒”；能承认自己踩过的坑和当时的解决方案；对新技术保持关注但有自己的判断，不盲目追新。

减分项包括：只谈概念不谈实现，问细节就卡住；把所有问题都归结为“调 prompt”，缺乏系统思维；对成本和性能没有概念，觉得“能跑就行”；过度依赖框架，说不清楚底层原理。

面试本质上是在验证你的经验是否真实、你的能力是否匹配岗位需求。把上面这些内容吃透，结合自己的实际项目经验去准备，通过率会有明显提升。这个领域变化很快，保持动手、保持踩坑、保持总结，比背任何题库都管用。