Tool use、memory、planning，Agent 面试到底考哪个

一句话总结

Agent 面试的真正考点从来不是三个模块各自的技术实现，而是你对"何时该让模型停下来"的直觉判断。面试官在 debrief 会议室里争论的，不是你写了多少行 tool call 的代码，而是当模型在 planning 过程中陷入循环时，你会不会设计一个优雅的退出机制。不是 memory 存得多快，而是你有没有意识到大部分 production 故障源于过度记忆而非记忆不足。不是 tool use 调用了多少 API，而是你有没有在成本与延迟之间做过真实的取舍。这三个模块在面试中被拆解成六道以上的独立评分维度，但候选人往往把 80% 的时间花在准备自己擅长的那个模块，却在交叉地带被一票否决。

适合谁看

这篇文章写给两类人：一类是正在准备 Google、OpenAI、Anthropic 或国内头部 AI 公司 Agent 方向面试的工程师，你的背景可能是传统 backend 出身，被 recruiter 以"LLM application"的名义约到了 Agent 组的 loop；另一类是从业 2-4 年、正在从纯模型训练往 system 方向转的 researcher，你写过不少 LangChain 代码，但从未在 production 环境里处理过十万量级的并发 tool call。如果你还在把 Agent 面试等同于"考 RAG 加几个 tool"，你需要重新校准。如果你已经刷过几十道 LeetCode 并发题但说不清 ReAct 和 Reflexion 在 latency budget 上的本质差异，这篇文章会直接告诉你面试官在 whiteboard 环节真正想看到的停顿点。薪资参考：硅谷 Agent 方向 PM/TL base $140K-$220K，RSU $60K-$200K/年，bonus $20K-$50K；国内头部公司对应总包 80-150 万人民币区间，但期权流动性差异极大，面试时谈 package 的重心应该放在 RSU 的 refresh 机制而非 signing bonus。

为什么面试官问完 tool use 就开始追问"如果 API 挂了"——这不是在考容错，是在考你对 Agent 本质的理解

Tool use 在面试中的第一个陷阱，是候选人急于展示自己调用外部工具的能力，却忽略了面试官真正关心的维度：工具失败后的行为链。一个典型的面试场景是：面试官让你设计一个能查询天气预报并据此推荐穿搭的 Agent。你开始画架构图，讲到 OpenWeatherMap API 时眉飞色舞，提到 retry with exponential backoff 时自我感觉良好。然后面试官打断你："如果 API 返回了 200 但数据是空的，你的 Agent 会怎么做？" 这是第一个分水岭。大部分候选人的直觉是做默认值回退，但这是错误的判断——正确的做法是当即切断当前 plan 的一个分支，将不确定性显式注入 memory，并在后续决策中降低该工具的置信权重。不是"处理异常"，而是"让异常成为决策输入的一部分"。

第二个层次更隐蔽。面试官会继续追问："你的 tool schema 怎么定义？" 很多人在此处暴露致命伤：他们把 tool 描述写成自然语言段落，而不是结构化的、可供模型自我反思的元数据。正确的做法是让每个 tool 携带自身的成本、延迟、可靠性评分，这些评分在 runtime 被动态更新，并参与 planning 时的优先级排序。这不是在炫技，而是 production 中的刚需——OpenAI 的 function calling 在 2023 年下半年的某次更新后，tool 的描述长度直接影响 token 消耗和 latency，一个臃肿的 schema 能让单次调用从 800ms 涨到 2.5s，在并发场景下这就是服务降级。

第三个层次是面试官很少明说但始终在观察的：你有没有在 tool use 和 planning 之间建立反馈闭环。一个真实的 debrief 场景：某候选人在 designing 一个数据分析 Agent 时，设计了一个能调用 Python 解释器的 tool，代码写得漂亮，但在面试官追问"如果代码运行超时，你的 planning 模块如何调整后续策略"时，候选人回答"会设置超时时间然后报错"。HC 讨论时的原话是："他把 tool 和 plan 当成了两个黑盒，中间缺了一层 execution trace 的沉淀。" 最终 this candidate 被降档到 L4，尽管他的 coding 是 strong hire。不是 tool 写得不够多，而是 tool 的 output 没有被 structured 进 planning 的上下文窗口。真正的 Agent 架构中，tool use 的每一次调用都会产生一个 execution node，这个 node 携带状态机（pending / running / success / failed / ambiguous），planning 模块在每一步 reranking 时都会读取这些 node 的全局视图。面试官想看到你在 whiteboard 上画出这条线，而不是在听到"feedback loop"时才恍然大悟。

Memory 面试的隐藏考点：不是"怎么存"，而是"敢不敢忘"

Memory 是 Agent 面试中最容易被低估的模块，因为候选人的准备方向往往是反的。你花三天研究 vector database 的索引算法，面试官却在第一轮就问你："如果你的 Agent 已经和用户聊了 20 轮，其中 5 轮是闲聊，3 轮是任务执行，2 轮是澄清需求，你的 summary memory 怎么压缩？" 这不是在考你的 summarization prompt 写得好不好，而是在考你对"遗忘"的设计胆略。不是记忆容量越大越好，而是主动遗忘的决策机制才是区分 senior 和 staff 的分水岭。

一个具体的面试场景来自某头部公司的实际 loop：面试官给出一个长达 40 轮的客服对话历史，要求候选人在 5 分钟内决定哪些信息需要保留到下一轮对话。候选人的本能反应是按时间衰减加权，最新的轮次保留完整，旧的做摘要。面试官的 follow-up 直接击穿这个策略："用户在三轮前提到'我明天要出差'，但上一轮又说'算了，计划取消了'，你的 memory 里现在有什么？" 正确的判断是：这两个 statement 不能简单用覆盖或删除处理，而应该作为一个"已失效的意图"被标记，因为用户未来可能重新激活这个意图（"还是去吧，改签"），而你的 Agent 如果完全忘记，会表现得像一个全新的客服，摧毁用户信任。不是存最新的，而是维护一个带 validity flag 的 belief state。

更深入的考点在 memory 的读写冲突。一个常被忽略的 insider 细节：production Agent 很少用单一的 memory store，而是分层——episodic memory（对话历史）、semantic memory（用户画像）、procedural memory（任务模板）。面试中的高级陷阱是让候选人设计一个场景：planning 模块正在读取 semantic memory 中的用户偏好，同时 tool use 模块的异步回调试图更新同一个 key（用户刚通过某个 action 修改了偏好）。大部分候选人会提到锁机制，但正确的判断是：Agent 的 memory 不应该被设计成一个强一致性系统，而是最终一致性的、带版本冲突检测的 event sourcing 架构。不是"防止冲突"，而是"让冲突可被 planning 模块感知并决策"。某次 HC 讨论中，一个候选人在这一层的回答让面试官记录了这样的 note："Understanding of eventually consistent memory in LLM context is rare. Candidate described version vector approach with explicit conflict resolution delegation to planner." 这是 strong staff signal。

Memory 的终极面试题往往以看似无关的形式出现："你的 Agent 运行三个月了，vector DB 里有 10 万条记录，查询延迟从 50ms 涨到 800ms，怎么办？" 这个问题的答案不是"换索引"或"做分区"，而是反问面试官这些记录的生命周期策略是什么。不是"怎么让查询变快"，而是"什么样的 memory 值得被持久化"。一个设计良好的 Agent 应该在 memory 写入时就打上衰减曲线和保留置信度，让系统层面的清理成为常态，而不是等到性能崩溃才做 emergency surgery。面试官在这里想听到的，是你有没有在架构层面为"遗忘"预留位置，而不是在答辩时才意识到这是一个问题。

Planning 模块：面试官在 whiteboard 前观察的，是你"停下来"的时机

Planning 是 Agent 面试的核心战场，但大多数候选人的准备重心完全错位。他们研究 ReAct、Reflexion、Tree of Thoughts 的论文细节，却在面试中遇到一个根本性的追问时崩溃："你的 Agent 什么时候应该停止 planning，开始执行？" 这不是一个技术问题，而是一个产品判断。不是 plan 得越精细越好，而是"足够好就动"的阈值设计才是 production 的生死线。

一个真实的面试场景：候选人被要求设计一个能自动预订餐厅的 Agent。他画了一个 elaborate 的 plan tree，包含菜系偏好、距离计算、价格区间、评价筛选四个维度，每个维度下有 2-3 层细化。面试官安静听完，问："用户说'随便，快饿死了'，你的 Agent 要 plan 多久？" 候选人的错误回答是想通过 NLP 识别用户 urgency 然后动态调整 planning depth。正确的判断是：planning 的终止条件不应该完全依赖输入解析，而应该内置一个"行动倾向"的累积值，当任何时刻的 execution confidence 超过 inertia threshold 时就立即启动，哪怕 plan 只完成了 60%。不是"根据用户急迫程度调整"，而是"把急迫度建模为系统常量，让 planner 始终偏向行动"。这个设计哲学直接来自机器人学中的"anytime algorithm"传统，但在 LLM Agent 的语境下很少有人迁移过来。

Planning 面试的第二个深水区是 plan 的修正机制，不是"做错了怎么改"，而是"做的时候发现可能错，要不要停"。一个经典的面试官陷阱：让候选人 walk through 一个已经执行了两步的 plan，第三步 tool call 前，模型突然对前两步的执行结果产生了 low confidence 的评估。候选人的典型反应是继续执行然后做 rollback，但正确的判断是立即触发一个"plan revalidation"子流程，这个子流程的触发条件、预算消耗、和原 plan 的关系，都需要在架构设计阶段显式定义。某次 debrief 中，面试官对候选人的评价是："He described a beautiful rollback mechanism, but couldn't articulate when re-planning is cheaper than continuing. Missing the cost model." 这是明确的 no-hire signal，尽管候选人的算法背景很强。

Planning 的第三个维度是面试官最不愿意提前透露的：plan 的可解释性如何影响下游模块。不是"要不要给 plan 加注释"，而是当 plan 被生成后，哪些其他模块有权读取 plan 的结构化 representation，以及这种读取会如何反作用于 plan 本身。一个production 故障的真实案例：某 Agent 的 planning 模块生成了一份包含 A->B->C 步骤的计划，memory 模块读取了这份计划并据此做了预加载，但 planning 模块在后续执行中因外部条件变化将 B 替换为了 B'，memory 的预加载数据却未被 invalidation，导致 B' 执行时使用了错误的上下文。面试中遇到这类问题的正确姿态不是立即给出一个完美方案，而是先识别出"plan 的版本契约"这个问题域，再讨论可能的 consistency model。面试官要看的不是你解决一个具体 bug 的能力，而是你有没有在架构层面预见到这类 cross-module 的隐式依赖。

三轮面试的真实拆解：谁在考什么，时间怎么分配

Agent 方向的面试流程通常被压缩到 3-4 轮，但每轮的考察重心差异极大。以下是基于 2024 年多家公司实际 loop 的拆解，不是"一般情况"，而是"你应该按这个准备"。

第一轮：System Design（45-60 分钟）。这不是传统的高并发系统设计，而是"设计一个能完成某任务的 Agent"。面试官会在 15 分钟左右切入一个具体的摩擦点：tool 的 latency 方差极大怎么办？memory 的召回率和精确率如何 trade-off？关键不是给出完美答案，而是展示你在约束条件下的决策框架。一个 insider 技巧：提前在白板上画出 tool use / memory / planning 三个模块的交互界面，面试官的追问会围绕这些界面的设计选择展开，而不是让你从零开始想。这一轮的准备重心是：对三个模块的 coupling 方式有自己的判断，不是松耦合或紧耦合的简单二分，而是"哪些信息必须同步流动，哪些可以异步批处理"。

第二轮：Coding + Debugging（45 分钟）。题目通常是一个简化的 Agent 执行引擎，要求你实现一个能处理 tool call 并更新 state 的 loop。陷阱在于：面试官会在你写完后引入一个并发场景（多个 user request 共享同一个 memory store），或者一个 failure 场景（tool 返回 malformed response）。不是考你的代码速度，而是考你在 pressure 下的调试直觉。一个真实的观察：很多候选人在遇到 malformed JSON 时会写 try-catch 然后 raise，但正确的判断是捕获、log、注入一个"ambiguous"状态到 state machine，让 planning 模块决定下一步。这个细节的差异，在面试官的评分表上是"handles edge cases"和"designs for uncertainty"的区别。

第三轮：Behavioral + Architecture Deep Dive（45-60 分钟）。这一轮常被候选人低估，以为是走过场。实际上，这是 hiring manager 判断你"能不能 own 一个 Agent 模块"的关键。一个典型的问题："Tell me about a time when your Agent did something unexpected in production." 不是让你讲一个 bug 然后讲怎么修的，而是观察你对"unexpected"的定义层次——是 output 不对，还是行为超越了设计的意图边界，还是用户感知到了不一致性。一个 strong 的回答结构：先定义你监控的 metric 是什么（不是 accuracy，可能是 task completion rate 或 user trust score），再讲你如何区分"系统错误"和"设计假设被打破"，最后讲你调整架构而非仅仅修 bug 的过程。

准备清单

在白板上画过至少三个不同约束条件下的 Agent 架构图（latency 敏感、cost 敏感、reliability 敏感），确保你能解释为什么某个模块在这个约束下必须被重构，而不是简单调参。

手写一个简化版 ReAct loop，包含显式的 state machine 和 error propagation 路径，然后故意注入三个不同类型的 failure，观察自己的代码行为。

准备一个"我的 Agent 失控了"的故事，重点不是怎么修的，而是你怎么在架构层面防止它再次失控——这个故事在 behavioral 轮的价值远超 "I optimized latency by 30%"。

系统性拆解面试结构，PM 面试手册里有完整的 Agent 架构实战复盘可以参考，特别是 cross-module interaction 部分的案例分析。

用一张纸列出 tool use、memory、planning 三个模块各自的"不可协商设计原则"，面试中无论被怎么追问，这些原则不能自相矛盾。

找一个同行做 mock，让对方在 system design 轮故意忽略你的 memory 模块，看你会不会主动把它拉回讨论中心——这模拟的是真实工作中 PM 或 executive 的短视。

研究至少一个开源 Agent 框架的 issue 列表，不是看 feature request，而是看 production bug 的根因分析，这些往往比论文更接近面试考点。

常见错误

错误一：把 Agent 面试当成了"三个模块的技术面试"

BAD：候选人回答 planning 问题时说"我用的是 ReAct，它让模型先 think 再 act"，然后被追问 ReAct 的 think 步骤 token 开销时沉默。面试官在 debrief 时的原话："He treated ReAct as a black box recipe, not a design choice."

GOOD：同一个问题，候选人先说"ReAct 的 think-act 分离在延迟敏感场景下是奢侈品，我在 X 场景下会压缩 think 步骤为结构化模板，在 Y 场景下保留自由生成"，然后主动讨论这种 trade-off 的量化依据。

错误二：在 memory 问题上过度工程化

BAD：候选人被问 memory 设计时，立即开始讲 multi-vector indexing、HNSW 参数调优、hybrid search 的权重公式。面试官在第五分钟打断他："你的用户画像和这个对话的上下文，存同一个 vector space 吗？" 候选人愣住，因为他从未把 memory 当作一个有层次的产品来设计。

GOOD：候选人先画一个两层结构——episodic 按时间序、最终一致性，semantic 按实体聚类、强一致性需求低，然后讲清楚为什么这两层不能简单合并（不是技术不能，而是运维和演化成本的考量）。

错误三：对 planning 的理解停留在"让模型输出步骤"

BAD：候选人描述 planning 时说"模型会生成一个 JSON list，每个元素是一个 step"。面试官追问"如果执行到第三步，前两步的结果和预期不符，你的 JSON 能做什么？" 候选人回答"我会把这个情况作为新的 input 重新 query 模型"。这是典型的把 planning 当作单次生成而非持续过程。

GOOD：候选人描述一个 plan 的 lifecycle：generation -> validation -> execution -> monitoring -> revalidation trigger conditions。每个阶段有明确的 state、transit rule、和 rollback/replan 的 cost model。面试官的追问变成关于 cost model 的具体假设，这是高级信号。

FAQ

Q: 我没有 Agent 的 production 经验，简历会被直接筛掉吗？

不是看你有没有"Agent 工程师"的 title，而是看你的经历中有没有"在一个不确定环境中做出序列决策"的证据。一个真实的 HC 讨论案例：候选人是传统搜索工程师，简历里有一条"优化了 query understanding 模块的意图识别准确率"。面试中他被追问的不是搜索技术，而是"当意图识别有多个候选且置信度接近时，你的系统怎么选择执行路径"——这直接映射到 Agent planning 中的 multi-branch handling。这个候选人最终拿到 offer，因为他的回答展示了在约束下做序列决策的本能。另一个反面案例：候选人的简历写满了 LangChain 和 LlamaIndex 的项目，但面试中无法解释任何一个项目的 latency breakdown，被标记为"tutorial-level experience"。关键不是包装，而是重新 frame 你的经历，让面试官看到 transferable 的决策模式。

Q: Tool use、memory、planning，面试前应该重点准备哪一个？

错误的准备策略是平均分配时间或只准备最强项。正确的判断是：准备它们的交叉地带。一个来自 hiring manager 的观察：最近的 loop 中，cross-functional 问题（两个模块的交互）的权重在增加，因为单一模块的深度已经可以通过 coding 轮验证。具体建议：准备三个"冲突场景"——tool 返回的结果和 memory 中的用户偏好矛盾时怎么办？planning 生成的步骤需要读取的 memory 恰好被更新中怎么办？memory 的压缩导致 planning 的上下文丢失怎么办？这些场景没有标准答案，但面试官想听到你如何定义"足够好"的决策标准。一个在准备清单中加入 PM 面试手册相关章节的候选人提到，手册里的 cross-module debugging framework 帮他结构化了自己的思考，虽然他没有按图索骥，但那个框架让他意识到自己的盲点通常在 tool-memory 的边界。

Q: 面试官问"你的 Agent 怎么评估"时，什么样的答案算好？

这不是在问 metric 列表。一个被标记为 strong hire 的回答结构：先区分 online 和 offline 评估的不同目的，offline 评估 agent 的 plan quality 用黄金数据集，但承认这无法 capture 真实环境中的 tool failure distribution；online 评估用 task completion rate，但立即补充这个 rate 的定义必须在产品层面可争议（比如"预订成功"算不算用户最终确认了，还是系统收到确认邮件就算）；然后引入一个 layer：用户信任度，这通常通过"用户在 agent 执行过程中是否打断或纠正"来 proxy。不是罗列 metric，而是展示你对"什么算对"的多层次定义能力。一个反面教材：候选人列举了 accuracy、precision、recall、F1，然后被追问"你的 Agent 是一个产品，不是论文实验，用户怎么感知到 F1 的提升"时无言以对。正确的判断是：产品层面的评估必须最终连接到用户行为，而用户行为中最难伪造的是"愿意再次使用"。

想系统准备PM面试？

获取PM面试通关手册 →