1. 为什么“会调API”和“会做Agent”之间隔着一道鸿沟这两年面试Agent岗位的人越来越多简历上写着“熟悉大模型应用开发”“做过RAG问答”“用过LangChain”但真正坐下来聊二十分钟能撑住场面的人少得可怜。问题出在哪大多数人把Agent理解成“大模型加几个工具调用”觉得会写tool_calls解析、能跑通一个ReAct循环就算入门了。但面试官想考察的从来不是你会不会调接口而是你有没有真正思考过一个自主系统在真实环境里怎么活下来、怎么不闯祸、怎么在信息不完整的时候做决策。我参与过不少轮Agent工程师的面试也帮朋友做过模拟面。一个很明显的感受是初级候选人聊的是“我用了什么框架”中级候选人聊的是“我怎么设计流程”而高级候选人聊的是“我在哪里做了取舍、为什么这么取舍、踩过什么坑”。这三层之间的差距就是本文想帮你补上的。下面这10道题基本覆盖了Agent工程师从工程落地到系统设计的核心考察面。我不会只给你标准答案而是把每道题背后的考察意图、回答框架、加分项和致命雷区都拆开讲。你看完之后至少能做到面试时心里有底知道对方到底在问什么。提醒一句下面所有题目和回答思路都基于行业常见实践总结不涉及任何特定公司的真实面试题库。你拿去准备面试没问题但别指望背完就能过——面试官稍微追问一层背答案的人立刻露馅。2. 第一梯队Agent基础认知与架构设计2.1 题目一“你怎么理解Agent和Workflow的区别”这道题几乎是Agent面试的必考题但很多人答得太浅。常见的错误回答是“Agent能自主决策Workflow是固定流程”——这话没错但太像教科书面试官听完没有任何信息增量。我的回答框架是这样的先给一个判断标准再举一个具体场景说明边界在哪里。判断标准可以概括为——控制流的决策权在谁手里。Workflow的控制流是开发者预先编排好的每一步走哪条分支、什么条件触发什么动作都是写死的Agent的控制流是模型在运行时根据上下文动态决定的开发者只给出目标和可用工具具体走几步、走哪条路模型自己判断。但真正拉开差距的是后半句在实际工程中纯Agent和纯Workflow都很少见大多数生产系统是混合架构。比如一个客服场景意图识别和路由用Workflow保证稳定性但具体问题的解决过程交给Agent去灵活处理。为什么因为纯Workflow遇到没见过的输入就崩了纯Agent又太不可控成本和延迟都扛不住。面试官想听的就是这个“混合”的判断这说明你真正落地过而不是只写过Demo。加分项是你能说出一个具体的混合模式比如“前置分类器做路由 子Agent做具体任务 后置校验器做兜底”并且解释每一层为什么这么设计。雷区是只谈概念不谈场景或者把Agent吹得无所不能。2.2 题目二“一个Agent系统通常包含哪些核心模块你怎么划分”这题考察的是你有没有系统性的架构思维。很多人上来就说“大模型、工具、记忆”太粗糙了。我一般会按职责分成五层来讲第一层是感知与输入层负责接收用户输入、环境状态、外部事件做初步的格式化和清洗。第二层是决策与规划层也就是大模型所在的位置负责理解意图、拆解任务、选择下一步动作。第三层是执行与工具层包括所有可调用的API、函数、代码执行环境以及工具的描述和参数校验。第四层是记忆与状态层分短期上下文和长期存储负责让Agent在多轮交互中保持连贯。第五层是监控与治理层包括日志、追踪、成本控制、安全拦截、人工介入通道。这么分的价值在于每一层都可以独立替换和优化。比如你觉得模型决策不够稳可以只换决策层不用动工具层你觉得成本太高可以在治理层加缓存和路由策略。面试官如果追问“哪一层最难做”我会说是治理层——因为它不产出功能但决定了系统能不能上生产。这个回答能体现你对工程复杂度的真实认知。2.3 题目三“Agent的规划能力你一般怎么设计和评估”规划是Agent的核心能力之一但很多人只会说“用ReAct”或者“用Plan-and-Execute”。面试官问这题是想知道你有没有对比过不同规划范式的适用场景。我的回答会先区分三种常见范式ReAct式边想边做、先规划后执行、分层规划。ReAct适合步骤少、环境反馈快的任务优点是灵活缺点是容易绕圈子先规划后执行适合步骤多、依赖关系明确的任务优点是全局视野好缺点是一旦规划错了后面全错分层规划则是把大目标拆成子目标每个子目标再动态展开兼顾全局和灵活但实现复杂度最高。然后关键来了——怎么评估规划质量。我会说三个指标任务完成率、平均步数、无效动作占比。任务完成率看结果平均步数看效率无效动作占比看规划是否精准。如果面试官继续追问“怎么定位规划失败的原因”我会说通过追踪每一步的思考链和动作结果找到第一个偏离预期的节点然后判断是理解错了、工具选错了还是参数填错了。这种层层递进的回答能直接体现你的实战深度。3. 第二梯队记忆、工具与上下文工程3.1 题目四“Agent的记忆系统你怎么设计短期和长期怎么配合”记忆这题特别容易答得空泛。我的建议是先讲清楚记忆的本质是“在有限的上下文窗口里放最该放的信息”。短期记忆就是当前对话的上下文长期记忆是跨会话持久化的信息。难点不在于存而在于取——什么时候把什么信息捞出来塞进上下文。具体设计上我会分三类处理。第一类是对话历史用滑动窗口加摘要压缩近期保留原文远期压缩成摘要。第二类是事实性记忆比如用户偏好、关键实体用结构化存储加向量检索需要时按相关性召回。第三类是经验性记忆比如过去成功解决类似任务的步骤用案例库的方式存遇到相似任务时作为参考注入。配合逻辑是每轮对话开始时先用当前输入去检索长期记忆把高相关的内容和近期对话一起组装成上下文。这里有个实操心得——检索回来的记忆一定要做相关性过滤和去重否则很容易把不相关的旧信息塞进去反而干扰模型判断。我踩过这个坑早期不做过滤结果Agent老是引用几天前的无关对话答非所问。面试官听到这种具体教训信任度会明显上升。3.2 题目五“工具调用的可靠性怎么保证模型选错工具或填错参数怎么办”这题是区分“写过Demo”和“上过生产”的分水岭。Demo里工具调用一次就成功生产里模型选错工具、参数格式错误、调用超时是家常便饭。我的回答会分三层。第一层是预防工具描述要写得极其清晰包括用途、参数含义、返回格式、适用场景和不适用场景。很多人工具描述就写一句话模型当然容易选错。参数层面用JSON Schema做严格约束枚举值列全必填项标清楚。第二层是校验工具调用前做参数校验格式不对直接拦截并返回错误信息让模型重试而不是硬着头皮执行。第三层是兜底调用失败或超时要有重试和降级策略重试时把错误信息反馈给模型让它调整降级则是切换到备用工具或直接返回兜底话术。加分项是提到工具数量的控制。工具不是越多越好超过一定数量后模型的选择准确率会明显下降。我的经验是单次可选工具控制在10到15个以内多了就做分组或路由。这个细节能直接证明你调过真实系统。3.3 题目六“上下文窗口不够用的时候你的裁剪策略是什么”这题看似是工程细节实则考察你对信息优先级的判断力。上下文塞满的时候砍掉什么、保留什么直接决定Agent的表现。我会按优先级排序系统指令和当前任务目标永远保留这是Agent的行动纲领最近几轮对话保留原文因为最相关工具调用结果按重要性筛选成功的、信息量大的保留失败的、冗余的压缩远期历史压缩成摘要长期记忆按相关性动态召回不相关的不占位置。这里有个容易被忽略的点——裁剪不是一次性动作而是持续过程。我通常会在每轮对话后检查token占用接近阈值就触发压缩而不是等爆了再处理。另外压缩摘要的时候要让模型自己总结保留关键决策和结论丢掉寒暄和重复内容。面试官如果追问“压缩会不会丢信息”我会说会所以关键信息要用结构化方式单独存不依赖摘要。这种回答体现的是你对信息损失的清醒认知。4. 第三梯队多Agent协作与系统治理4.1 题目七“多Agent系统什么时候该用怎么划分Agent职责”多Agent是这两年的热点但也是最容易被滥用的架构。面试官问这题往往是想看你有没有“能不用就不用”的克制。我的观点很明确多Agent的价值在于职责隔离和并行处理如果单Agent能做好就不要拆。什么时候该拆三种情况一是任务天然可以并行比如同时调研多个方向二是不同子任务需要不同的工具集和提示词混在一起会互相干扰三是需要对抗性校验比如一个Agent生成、一个Agent审查。职责划分的原则是按能力边界拆不按流程步骤拆。比如“检索Agent”“分析Agent”“写作Agent”是按能力拆合理“第一步Agent”“第二步Agent”是按流程拆往往没必要。每个Agent应该有清晰的输入输出契约通过消息传递协作而不是共享一堆全局状态。踩坑经验是多Agent系统的调试难度是单Agent的数倍因为错误会在Agent之间传播和放大。我早期做过一个三角色协作的系统结果一个Agent理解偏了后面两个跟着错排查了半天才发现源头。所以我的建议是多Agent一定要有全局追踪每个Agent的输入输出都要可观测。4.2 题目八“Agent的成本和延迟怎么优化”这题非常务实能答好的人不多。Agent系统动不动就调用十几次模型成本和延迟很容易失控。我会从四个维度讲。模型分层简单任务用小模型复杂推理用大模型通过路由决定。缓存复用相同或相似的查询结果缓存工具调用结果缓存甚至模型输出也可以做语义缓存。并行化没有依赖关系的工具调用和子任务并行执行能大幅降低延迟。提前终止设置最大步数和超时达到阈值就返回当前最优结果而不是无限循环。这里有个反直觉的经验——很多时候延迟的瓶颈不是模型推理而是工具调用和网络往返。所以优化工具的超时和重试策略比换更快的模型收益更大。我实测过一个场景把串行的工具调用改成并行后端到端延迟降了将近一半。面试官听到这种带数据的经验基本就能确认你是真做过。4.3 题目九“Agent的安全和边界怎么控制怎么防止它做危险操作”这题是生产落地的红线答不好直接出局。Agent能调工具、能执行代码一旦失控后果严重。我的框架是事前、事中、事后三层。事前做权限最小化Agent只能访问它必须的工具和数据危险操作如删除、支付、外发单独隔离并强制人工确认。事中做实时拦截对工具调用做规则校验比如参数范围、频率限制、敏感词检测命中规则直接阻断。事后做审计和回滚所有操作留痕关键操作可撤销。关键原则是永远不要完全信任模型的判断。模型可能被诱导、可能理解错、可能产生幻觉所以安全边界必须由代码来守而不是靠提示词。我见过有人只在系统提示里写“不要做危险操作”这等于没做防护。正确做法是在工具执行层加硬性校验模型说破天也过不去。这个观点面试官通常很认可因为它体现了工程思维而非幻想。4.4 题目十“你怎么评估一个Agent系统的好坏上线后怎么持续优化”最后一题是综合性问题考察你有没有闭环思维。很多人只会说“看任务完成率”太单薄了。我会分两个阶段讲。离线评估阶段用标注好的测试集跑任务完成率、准确率、平均步数、成本和基线对比。在线评估阶段看真实用户的满意度、任务放弃率、人工介入率、单次任务成本。两个阶段要结合离线好不代表线上好因为真实输入的分布和测试集不一样。持续优化的闭环是收集badcase → 归因分析 → 定位是规划问题、工具问题还是记忆问题 → 针对性修改 → 回归测试 → 灰度上线。归因分析是最关键的一步我一般会把失败案例按错误类型分类看哪类占比最高优先解决。比如发现大部分失败是工具选错那就优化工具描述和路由如果是规划绕圈那就调整规划策略。这种数据驱动的优化思路是高级Agent工程师和普通开发者的核心区别。5. 面试现场那些答得漂亮的人做对了什么聊完10道题我想再补充一些面试现场的观察。同样一道题有人答得让面试官频频点头有人答得让人想赶紧结束差别往往不在知识量而在表达方式。第一先给结论再展开。面试官时间有限你先用一句话给出核心判断再解释为什么比绕半天才说到重点强得多。比如问Agent和Workflow的区别直接说“看控制流决策权在谁手里”然后展开节奏就很舒服。第二主动暴露取舍。任何设计都有代价只讲优点的人显得没深度。说“我选A是因为B在这个场景下更贵/更慢/更不可控”立刻显得你思考过全局。面试官最怕听到“这个方案很好”这种没有对比的评价。第三用具体数字和案例。说“延迟降低了一半”比“延迟降低了”有说服力说“工具超过15个准确率下降”比“工具多了不好”有说服力。数字不一定要精确但要体现你观察过、量化过。第四承认不知道的边界。遇到没做过的场景坦诚说“这个我没实操过但按我的理解应该是……”比硬编一个答案强。面试官能分辨真经验和编故事硬编一旦被追问就崩了。第五反问环节别浪费。问“你们现在Agent系统最大的痛点是什么”比问“团队氛围怎么样”更能体现你的专业度。这个问题还能让你提前判断这个岗位值不值得去。6. 准备Agent面试我建议你这样练最后分享一点我自己的准备方法。Agent面试和传统后端面试最大的不同是它极度依赖你对“不确定性系统”的理解而这种理解很难靠刷题获得。我的建议是自己动手搭一个完整的Agent项目不用复杂但要覆盖规划、工具调用、记忆、错误处理这几个核心环节。搭的过程中你会遇到各种真实问题模型不按格式输出、工具调用超时、上下文爆掉、成本失控。这些问题和对应的解决方案就是你面试时最值钱的素材。然后刻意练习表达。把你做过的每个决策都问自己三个问题为什么这么做还有什么替代方案代价是什么能流畅回答这三个问题面试基本就稳了。我见过技术很强但表达混乱的候选人也见过技术一般但讲得清清楚楚的候选人后者往往更容易拿到offer因为Agent岗位需要大量跨团队沟通和方案评审。还有一点关注行业动态但别追热点。新框架、新范式层出不穷但底层的东西变化很慢——规划、记忆、工具、治理这些核心问题几年内不会变。把精力放在理解这些不变的东西上比追每一个新出的框架划算得多。面试本质上是一次双向的信息交换。你在展示能力的同时也在判断这个团队的技术品味和工程文化。准备充分的人才有底气在反问环节挑团队而不是被团队挑。