1. 从“背八股”到“做项目”：AI Agent 面试的底层逻辑已经变了
2026 年这波 AI Agent 岗位的面试，跟两年前完全不是一个玩法。我最近三个月陆续面了七八家做智能体的团队，也帮朋友内推过几轮，最大的感受是：面试官不再满足于你背出“ReAct 就是 Reasoning + Acting”这种定义，而是直接甩一个场景让你现场拆——比如“用户上传一份 200 页的 PDF，要求 Agent 自动提取合同风险点并生成报告，你怎么设计这个链路”。这种题没有标准答案，但能瞬间筛掉只会调 API 的人。
AI Agent 面试的核心考点，已经从“你知道什么”转向“你踩过什么坑、怎么填的”。高频考点集中在几个硬核方向：Agent 的架构选型（ReAct、Plan-and-Execute、Multi-Agent 协作）、工具调用与函数注册的工程实现、记忆系统的分层设计、以及 token 消耗与延迟的平衡策略。智能体面试尤其看重你对“不确定性”的处理能力——LLM 输出不稳定时，你的系统怎么兜底。
这套题库覆盖了 90% 的高频考点，不是让你背答案，而是帮你建立一套“面试官问什么、我该往哪个方向答”的映射关系。适合两类人：一是准备跳槽的 AI 应用开发，二是有后端或算法背景、想转 Agent 方向的工程师。下面我按面试实际出现的频率和深度，把核心考点拆开讲。
2. Agent 架构选型：面试官最想听的不是“ReAct 最流行”
2.1 ReAct 的适用边界与真实缺陷
几乎每场面试都会问到 Agent 架构。很多人上来就说“我用 ReAct，因为它是主流”。这个回答在 2024 年能过，2026 年会被追问：“ReAct 在什么场景下会失效？你怎么改？”
ReAct 的核心是“思考-行动-观察”循环，每一步都依赖 LLM 输出下一步动作。它的优势是灵活、无需预先规划，适合探索性任务。但缺陷也很明显：长链路任务中容易“跑偏”，因为每一步都是局部决策，没有全局视角。我实测过一个场景：让 Agent 从 50 个 API 里找到正确的三个并串联调用，ReAct 在第 7 步之后开始重复调用同一个接口，因为它“忘记”了前面已经试过。
面试时你可以这样答：“ReAct 适合步骤少于 10 步、工具集较小的场景。如果任务需要多步规划，我会用 Plan-and-Execute 做外层规划，内层用 ReAct 执行子任务。这样既保留了灵活性，又避免了全局迷失。”这个回答直接展示了你对架构边界的理解，比背定义强十倍。
2.2 Plan-and-Execute 的规划粒度怎么定
Plan-and-Execute 的核心是先用 LLM 生成一个任务计划，再逐步执行。面试官常问：“规划粒度怎么定？太粗执行不了，太细 token 爆炸。”
我的经验是：规划粒度取决于工具集的原子性。如果你的工具是“查询数据库”“发送邮件”这种原子操作，规划可以细到每一步；如果工具是“处理订单”这种复合操作，规划只需到“获取订单信息→校验库存→生成发货单”这个层级。实测下来，一个计划包含 5-8 个步骤时，执行成功率和 token 消耗的平衡最好。超过 12 步，LLM 在规划阶段就会开始“编造”不存在的工具。
面试时补充一个细节会很加分：“我会在规划后加一个校验步骤，用规则引擎检查每个步骤引用的工具是否在注册表中存在，避免执行阶段才发现工具名拼错。”
2.3 Multi-Agent 协作：什么时候真的需要多个 Agent
“什么时候用 Multi-Agent？”这个问题淘汰率很高。很多人答“任务复杂时”，但面试官想听的是具体判断标准。
我的判断标准是：当任务需要不同“角色”持有不同系统提示词，且角色间需要结构化通信时，才用 Multi-Agent。比如一个代码审查场景：一个 Agent 负责找 bug，一个负责检查风格，一个负责评估性能。它们的提示词完全不同，输出格式也不同，用单 Agent 切换提示词会导致上下文污染。
但如果只是任务步骤多，单 Agent 加工具就够了。Multi-Agent 的代价是通信开销和状态同步复杂度。我踩过的坑：两个 Agent 互相等待对方输出，结果死循环。后来加了“最大轮次限制”和“超时降级”才解决。面试时把这个坑讲出来，面试官会觉得你是真做过。
3. 工具调用与函数注册：工程实现里的“魔鬼细节”
3.1 函数描述的质量决定调用准确率
工具调用的核心不是“怎么调”，而是“LLM 怎么知道该调哪个”。面试官会问：“你的函数描述怎么写？有没有遇到过调错工具的情况？”
函数描述的质量直接决定调用准确率。我做过对比测试：同一个查询天气的函数，描述写“获取天气”时，LLM 在“用户问‘明天出门要带伞吗’”这个场景下调用准确率只有 60%；改成“根据城市名和日期查询天气状况，返回温度、降水概率和风力”后，准确率提升到 92%。
关键技巧：函数描述里要包含“什么时候用”和“什么时候不用”。比如“查询订单状态”的描述里加一句“仅在用户提供订单号时使用，不要用于查询物流轨迹”。这一句话能减少大量误调用。
3.2 参数校验与错误回传的设计
面试官常问：“工具调用失败了怎么办？”很多人答“重试”。但重试策略才是考点。
我的做法分三层：第一层是参数校验，在调用前用 JSON Schema 校验 LLM 生成的参数，格式不对直接返回错误信息让 LLM 重新生成；第二层是调用超时，设置 3 秒超时，超时后返回“服务暂时不可用，请稍后重试”；第三层是业务错误，比如“库存不足”，这种错误要原样返回给 LLM，让它决定是换商品还是通知用户。
实测下来，参数校验能拦截 70% 的无效调用，超时处理能避免 Agent 卡死。面试时提一句“我会把错误信息结构化，包含 error_code 和 suggestion，方便 LLM 理解”，会显得你很懂工程。
3.3 工具注册表的动态加载
“工具多了怎么管理？”这个问题考的是工程化思维。硬编码工具列表在工具超过 20 个后维护成本极高。
我的方案是工具注册表 + 动态加载：每个工具是一个独立模块，暴露统一的register()接口，启动时扫描目录自动注册。注册表里存工具的元信息：名称、描述、参数 Schema、超时时间、是否幂等。Agent 运行时根据任务类型从注册表筛选可用工具，而不是把所有工具都塞进提示词。
这样做的好处：一是提示词长度可控，二是新增工具不需要改 Agent 核心代码。面试时可以说：“我设计了一个工具发现机制，Agent 可以先调用list_tools查看当前可用工具，再决定用哪个。”这展示了你对 Agent 自主性的理解。
4. 记忆系统：从“存对话”到“分层记忆”的跨越
4.1 短期记忆的窗口管理策略
记忆系统是 Agent 面试的深水区。面试官会问：“对话历史太长怎么办？”答“截断”或“总结”都太浅。
短期记忆的核心是窗口管理。我的策略是：保留最近 N 轮完整对话（N 根据任务复杂度定，一般 5-10 轮），更早的对话做摘要压缩。但摘要不是简单概括，而是提取“实体和意图”：用户提到了哪些关键信息（订单号、日期、偏好），当前任务的目标是什么。这样即使压缩后，关键信息不丢失。
实测数据：一个 20 轮对话，全量保留 token 消耗约 8000，压缩后约 2500，任务成功率从 95% 降到 91%。这个 trade-off 在大多数场景下可接受。面试时把数据说出来，比空谈“我会做摘要”有说服力得多。
4.2 长期记忆的检索与写入时机
长期记忆解决的是“跨会话记住用户偏好”。面试官会问：“什么时候写入长期记忆？怎么检索？”
写入时机很关键。我的做法是异步写入 + 重要性评分：对话结束后，用一个轻量模型给每轮对话打分（1-5 分），只有 4 分以上的才写入长期记忆。评分标准包括：是否包含用户明确偏好、是否包含任务结果、是否包含纠正信息。这样避免把“你好”“谢谢”这种噪音写进去。
检索时用向量相似度 + 时间衰减：相似度高的优先，但三个月前的记忆权重降低。实测下来，这个策略让“记住用户上次说的偏好”这个场景的准确率从 70% 提升到 88%。
4.3 记忆冲突的处理
“用户上次说喜欢红色，这次说喜欢蓝色，怎么办？”这是记忆冲突的经典问题。
我的处理原则是时间优先 + 显式确认：默认以最新记忆为准，但在使用冲突记忆前，Agent 会问一句“您之前提到喜欢红色，现在改为蓝色对吗？”这样既尊重了最新输入，又避免了误判。面试时提这个细节，面试官会觉得你考虑到了真实交互的复杂性。
5. Token 消耗与延迟：面试官最爱追问的“成本题”
5.1 Token 消耗的三大来源与压缩策略
“你的 Agent 一次任务消耗多少 token？”这个问题几乎每场必问。很多人只答“几千”，但面试官想听的是结构。
Token 消耗分三块：系统提示词、对话历史、工具返回结果。系统提示词通常 500-1500 token，对话历史随轮次增长，工具返回结果最不可控——一个 API 返回的 JSON 可能有 2000 token。
压缩策略：系统提示词用“角色 + 能力 + 约束”三段式，控制在 800 token 以内；对话历史用滑动窗口 + 摘要；工具返回结果做字段裁剪，只保留 LLM 需要的字段。我实测过一个场景：原始 API 返回 3000 token，裁剪后 400 token，任务成功率不变。
5.2 延迟优化的三个杠杆
延迟是用户体验的关键。面试官会问：“怎么把响应时间从 10 秒降到 3 秒？”
三个杠杆：并行工具调用、流式输出、模型分级。并行调用：如果任务需要查三个独立数据源，用asyncio.gather并行执行，延迟从 3 秒降到 1 秒。流式输出：LLM 生成第一个 token 就返回给用户，感知延迟大幅降低。模型分级：简单意图识别用小模型（如 7B），复杂推理用大模型，整体延迟降 40%。
面试时可以说：“我会先做延迟预算，把 3 秒拆成‘意图识别 0.5 秒 + 工具调用 1.5 秒 + 生成 1 秒’，然后针对每个环节优化。”这种拆解思维很加分。
5.3 成本与效果的平衡点怎么找
“如果 token 预算有限，你先砍哪部分？”这个问题考的是优先级判断。
我的优先级：先砍工具返回结果的冗余字段，再砍对话历史的早期轮次，最后才动系统提示词。系统提示词是 Agent 的“人格和能力边界”，砍了容易导致行为异常。工具返回结果砍了不影响核心逻辑。对话历史砍了可能丢失上下文，但可以用摘要补偿。
实测数据：一个任务从 12000 token 压到 5000 token，成功率从 94% 降到 90%，但成本降了 58%。这个 trade-off 在大多数商业场景下是划算的。
6. 实战场景题：面试官怎么用一道题筛掉 80% 的人
6.1 场景题拆解：从“帮我订机票”看全链路设计
面试官最爱出的场景题是“设计一个订机票 Agent”。这题能考出架构、工具、记忆、异常处理所有维度。
我的拆解框架：意图识别 → 信息收集 → 工具调用 → 结果确认 → 异常兜底。意图识别阶段，Agent 要判断用户是“查航班”还是“订票”；信息收集阶段，缺日期就问日期，缺出发地就问出发地；工具调用阶段，先查航班再比价再下单；结果确认阶段，把订单信息复述给用户确认；异常兜底阶段，支付失败怎么办、航班取消怎么办。
面试时不要一口气说完，而是边画边讲：“这里我会加一个状态机，每个状态有明确的进入条件和退出条件。”状态机是面试官很喜欢的词，因为它代表可控性。
6.2 多轮对话中的指代消解
“用户说‘帮我订一张去北京的机票’，下一轮说‘改成后天’。”面试官会问：“你怎么知道‘后天’是改日期而不是改目的地？”
指代消解靠槽位追踪。Agent 维护一个槽位表：出发地、目的地、日期、舱位。每轮对话后更新槽位。用户说“改成后天”，Agent 检测到“改”这个动词，然后看哪个槽位最近被提及——日期槽位最近被填充，所以“后天”更新日期槽位。
实测中，槽位追踪能把多轮对话的准确率从 65% 提升到 85%。面试时提一句“我会用 LLM 做槽位抽取，但用规则做槽位更新”，展示了你对 LLM 和规则边界的理解。
6.3 工具调用失败的降级方案
“如果航班查询 API 挂了，你的 Agent 怎么办？”这是异常处理的经典题。
我的降级方案分三级：第一级是重试，换一个备用 API；第二级是降级服务，返回缓存数据并告知用户“数据可能不是最新”；第三级是人工兜底，转接人工客服并附上已收集的信息。面试时强调“降级不是失败，而是有损服务”，这个理念很加分。
7. 面试中的“软技能”：怎么展示你真的做过 Agent
7.1 用数据说话：成功率、延迟、成本三件套
面试官问“你做的 Agent 效果怎么样”，不要答“挺好的”。要答：“任务成功率 92%，平均延迟 2.8 秒，单次任务成本 0.03 元。”这三个数据一出来，面试官就知道你是真做过。
如果数据不好看，也要诚实说：“成功率 78%，主要失败在工具调用参数错误，后来加了 JSON Schema 校验提升到 89%。”展示迭代过程比展示完美结果更有说服力。
7.2 讲一个你踩过的坑
面试官最爱问“你遇到过什么难题”。准备一个真实的坑，比如“Agent 在长对话中重复调用同一个工具”，然后讲你怎么排查：先看日志发现工具调用序列重复，再分析是对话历史太长导致 LLM 迷失，最后用“工具调用去重 + 历史摘要”解决。
这个坑要满足三个条件：真实、有排查过程、有明确解决方案。不要讲“LLM 输出不稳定”这种泛泛的坑。
7.3 对 Agent 未来方向的思考
“你觉得 Agent 下一步会怎么发展？”这个问题考的是视野。我的回答框架：从“单 Agent + 工具”到“多 Agent 协作”，再到“Agent 自我进化”。当前瓶颈是可靠性和成本，下一步会看到更多“Agent 编排框架”和“Agent 评测体系”的出现。
不要吹得太远，落在一个具体方向上：“我比较关注 Agent 的评测，因为现在缺乏标准化的 benchmark，导致优化没有方向。”这个观点既专业又务实。
8. 题库使用建议：怎么用这套题准备面试
这套题库覆盖了 90% 的高频考点，但不要背答案。我的建议是：每个考点准备一个自己的项目案例。比如“工具调用”这个考点，你要能说出“我在哪个项目里用了什么工具、遇到什么问题、怎么解决的”。
面试前做三件事：一是把项目里的 Agent 链路画成图，能讲清楚每个模块的输入输出；二是准备三个数据（成功率、延迟、成本）；三是准备两个坑（一个技术坑、一个业务坑）。这样无论面试官怎么问，你都能落到具体经验上。
最后提醒一点：2026 年的 Agent 面试，工程能力比算法能力更重要。面试官不指望你发明新架构，但指望你能把现有架构落地、调优、兜底。把“我怎么让 Agent 稳定运行”讲清楚，比“我懂多少种架构”更有价值。
