1. 为什么这10道题成了Agent工程师的“照妖镜”这两年Agent这个词被炒得滚烫招聘JD上但凡沾点AI的岗位不写一句“熟悉Agent架构”都不好意思发出来。但真到面试环节很多候选人的表现就很有意思了聊概念头头是道一追问实现细节就开始打太极再问边界条件和失败场景基本就只剩“这个我们后续会优化”了。我参与过不少轮Agent岗位的技术面也帮朋友做过模拟面试官。说实话能把这10道题答利索的人一只手数得过来。大部分人的问题不是不懂而是只懂了个壳——知道ReAct、知道Function Calling、知道向量数据库但为什么这么设计、什么时候会崩、崩了怎么救一问三不知。这篇文章就是把这10道高频题拆开揉碎不光给答案更给答题的思路和背后的逻辑。适合正在准备Agent方向面试的人也适合已经在做Agent但想系统梳理一遍知识体系的工程师。我会按“面试官到底想听什么”的角度来讲而不是背八股。2. 第一类问题Agent的基础架构与核心循环2.1 题目一请描述一个Agent的完整运行循环从接收输入到输出结果这题看着基础但能答完整的人不多。大部分人会说“思考-行动-观察”循环然后就没然后了。面试官想听的是你对整个链路的掌控力。一个完整的Agent循环至少包含这几个阶段输入解析与意图识别、上下文组装、规划与推理、工具选择与调用、结果观察与状态更新、终止条件判断。每个阶段都有坑。输入解析阶段很多人直接拿用户原始query去检索这是大忌。用户说“帮我看看上周那个项目的进度”你得先解析出“上周”对应的时间范围、“那个项目”指代的是哪个项目。这一步做不好后面全白搭。上下文组装是区分新手和老手的关键。新手把所有历史对话一股脑塞进去老手会做分层上下文管理系统提示词单独一层、工具描述单独一层、近期对话做摘要、远期对话做向量检索召回。为什么要分层因为token是钱而且无关信息会干扰模型判断。规划与推理阶段ReAct模式是最常见的但纯ReAct有个致命问题它没有全局规划。模型走一步看一步容易在局部最优里打转。所以实际生产环境里通常会加一个Plan-and-Execute的前置规划层先让模型出个粗粒度的步骤列表再逐步执行。工具调用这块面试官最爱追问的是并行调用和依赖调用的处理。比如用户问“对比一下A公司和B公司的最新财报”这两个查询没有依赖关系应该并行发起但如果问“查一下A公司CEO的母校然后看看那个学校有哪些知名校友”这就是串行依赖。你的Agent框架得能识别这两种模式。终止条件判断是最容易被忽略的。很多Agent跑着跑着就陷入死循环或者该停的时候不停。常见的终止策略包括达到最大步数、连续N步没有新信息、模型输出明确的完成信号、工具返回结果满足预设条件。我一般会设三层保险硬性步数上限、语义重复检测、人工确认兜底。面试官想听的不是你背出了几个阶段而是你有没有踩过坑、有没有在生产环境里处理过异常情况。2.2 题目二Agent的记忆系统怎么设计短期记忆和长期记忆分别怎么实现记忆系统是Agent的灵魂但很多人把它简单等同于“把对话历史存下来”。这就好比说人的记忆就是一本日记太粗糙了。短期记忆的核心是工作记忆对应的是当前任务相关的上下文。实现上通常是一个滑动窗口加摘要机制。窗口大小怎么定不是拍脑袋要看你的模型上下文长度和任务复杂度。比如做多轮工具调用的任务窗口至少得覆盖最近5-8轮交互否则模型会忘记刚才调用了什么工具、返回了什么结果。摘要机制也有讲究。不是简单地把旧对话压缩成一段话而是要做结构化摘要保留关键实体、工具调用记录、未完成的子任务、已确认的事实。我见过一个团队的做法是维护一个“任务状态表”每轮交互后更新比纯文本摘要靠谱得多。长期记忆的实现路径就更多了。最常见的是向量数据库元数据过滤但纯向量检索有个问题它擅长语义相似不擅长精确匹配和时间推理。所以实际系统里往往是混合方案向量检索负责模糊召回结构化查询负责精确过滤再加一层重排序。还有一个容易被忽略的点是记忆的写入策略。不是所有对话都值得存。我一般会设几个触发条件用户明确说“记住这个”、任务成功完成后的关键结论、出现纠错信息时。无差别全存的结果就是检索时噪声太大召回质量直线下降。长期记忆的更新和遗忘机制也是面试官爱问的。记忆不是只增不减过期的、矛盾的、低置信度的记忆要能标记和清理。这块可以类比数据库的TTL和版本管理思路是通的。2.3 题目三Function Calling的底层原理是什么模型怎么知道该调用哪个工具这题能筛掉一大半人。很多人只会用API不知道背后发生了什么。Function Calling的本质是模型在训练阶段学习了工具调用的模式。具体来说训练数据里包含了大量“用户请求-工具描述-调用参数”的样本模型学会了根据工具的名称、描述、参数schema来判断该不该调、调哪个、传什么参数。关键点来了工具描述的质量直接决定调用准确率。我见过太多团队把工具描述写得含糊其辞然后抱怨模型调不对。工具描述要包含功能一句话说明、适用场景、不适用场景、参数含义和格式、返回值结构、可能的错误码。写得好的工具描述模型调用准确率能提升30%以上。模型选择工具的决策过程可以理解为一次条件概率计算给定当前上下文和所有可用工具的描述哪个工具的条件概率最高。所以工具数量不是越多越好超过一定数量后模型的选择准确率会下降。实践中单次暴露给模型的工具最好控制在10-15个以内多了就要做工具路由——先用一个轻量模型或规则引擎筛选出候选工具集。参数填充是另一个坑。模型有时候会漏填参数、填错类型、或者编造不存在的参数值。所以工具调用前必须做参数校验调用后要做结果验证。我一般会在工具层加一层wrapper做参数schema校验和默认值填充模型只负责给核心参数辅助参数由系统补全。还有一个高频追问模型怎么处理工具调用失败。好的Agent应该能区分错误类型参数错误就修正参数重试、权限错误就提示用户、超时就降级或换工具、逻辑错误就重新规划。无脑重试是最蠢的做法浪费token还解决不了问题。3. 第二类问题规划、推理与决策能力3.1 题目四ReAct、Plan-and-Execute、Reflexion三种模式的区别和适用场景这三种模式经常被混为一谈但它们的适用场景完全不同。ReAct是边想边做每一步都基于当前观察决定下一步。优点是灵活、能处理动态环境缺点是短视、容易陷入局部循环、token消耗大。适合工具调用链短、环境反馈快的场景比如简单的信息查询。Plan-and-Execute是先规划再执行。规划器出一个步骤列表执行器逐步完成。优点是全局视野、步骤可审查、便于并行优化缺点是规划可能过时、环境变化后需要重新规划。适合步骤明确、依赖关系清晰的任务比如多步数据处理的ETL流程。Reflexion是在执行后加一个自我反思环节分析哪里做得好、哪里可以改进把反思结果存入记忆供后续使用。优点是能持续改进、适合复杂任务缺点是增加额外调用、反思质量依赖模型能力。适合需要多轮迭代优化的场景比如代码生成和调试。实际生产系统往往是混合模式外层用Plan-and-Execute做粗粒度规划内层用ReAct做细粒度执行关键节点加Reflexion做质量检查。面试时能说出这个组合思路基本就稳了。选型的时候还要考虑成本。ReAct的token消耗通常是Plan-and-Execute的1.5-2倍Reflexion再加30%。如果任务简单、预算有限别硬上复杂模式。3.2 题目五Agent怎么做任务分解分解粒度怎么控制任务分解是Agent的核心能力之一但很多人分解出来的子任务要么太粗、要么太细。分解粒度有个实用原则每个子任务应该是一个可独立验证的单元。什么意思就是做完这个子任务后你能明确判断它是成功还是失败。如果无法判断说明粒度不对。举个例子“调研竞品并写报告”这个任务粗分解是“调研”和“写报告”但“调研”怎么算完成没法判断。细分解应该是确定竞品列表、收集每个竞品的定价信息、收集功能对比、收集用户评价、汇总分析、撰写报告。每个子任务都有明确的完成标准。分解方法上常见的有思维链分解、递归分解、模板分解。思维链分解适合线性任务递归分解适合层级任务模板分解适合重复性任务。实际用的时候往往是组合先用模板匹配看有没有现成的分解方案没有再用思维链或递归。分解后的子任务依赖关系要显式建模。我一般用DAG来表示节点是子任务边是依赖。这样便于识别哪些可以并行、哪些必须串行、哪些是关键路径。关键路径上的子任务要优先保证资源。还有一个坑是分解过细。子任务太多会导致调用次数爆炸、上下文碎片化、错误累积。经验值是单个任务的子任务数控制在5-9个超过这个范围就要考虑合并或分层。3.3 题目六多Agent协作怎么设计什么时候该用多Agent多Agent是这两年的热点但很多团队是“为了多Agent而多Agent”结果复杂度上去了效果没提升。先说什么场景适合多Agent角色分工明确且差异大的任务。比如一个Agent负责需求分析、一个负责代码生成、一个负责测试每个角色的提示词、工具集、知识库都不同。这种情况下多Agent有优势因为可以各自专业化。什么场景不适合任务同质化高、需要频繁共享上下文的场景。比如一个长文档的摘要任务拆成多个Agent分别摘要再合并往往不如单个Agent一次性处理。因为拆分带来的上下文丢失和合并成本超过了并行带来的收益。多Agent的通信机制是面试重点。常见的有共享黑板、消息传递、层级汇报。共享黑板适合松耦合协作消息传递适合点对点交互层级汇报适合有明确管理关系的场景。选哪种取决于你的任务结构和延迟要求。协作模式上辩论模式和投票模式是两种常见的决策机制。辩论模式让多个Agent从不同角度分析最后综合投票模式让多个Agent独立给出答案取多数。辩论适合开放性问题投票适合有明确答案的问题。我个人的经验是能用单Agent加工具解决的别上多Agent。多Agent的调试成本是指数级上升的出了问题很难定位是哪个Agent的锅。4. 第三类问题工程化与生产落地4.1 题目七Agent的评估怎么做离线评估和在线评估分别关注什么评估是Agent从Demo到生产的关键一步但很多团队这块是空白。离线评估关注的是可复现的指标。常见的包括任务完成率、平均步数、工具调用准确率、参数填充准确率、幻觉率、token消耗。这些指标需要在固定的测试集上跑测试集要覆盖正常场景、边界场景、异常场景。构建测试集有个技巧从生产日志里采样。真实用户的query分布和人工构造的测试集往往差异很大。我一般会从线上随机采样一批请求人工标注期望结果作为回归测试集。每次迭代后跑一遍看指标有没有退化。在线评估关注的是真实用户体验。核心指标包括用户满意度显式评分或隐式行为、任务中断率、人工接管率、平均响应时间。这些指标没法离线模拟必须上生产才能拿到。还有一个容易被忽略的维度是鲁棒性评估。给Agent输入带噪声的、对抗性的、模糊的query看它能不能优雅处理。比如用户输入里有错别字、有歧义、有恶意诱导Agent的表现如何。这块的测试用例要专门设计。评估频率上离线评估每次发版必跑在线评估持续监控。发现指标异常要能快速定位是哪个环节出了问题所以全链路追踪是必须的。每个请求的每一步决策、每一次工具调用、每一个中间结果都要有日志。4.2 题目八Agent的延迟和成本怎么优化有哪些实用手段这题是生产环境的核心痛点答得好能直接体现工程能力。延迟优化上并行化是最直接的手段。能并行的工具调用、能并行的子任务、能并行的检索查询全部并行。我见过一个团队把串行的5次检索改成并行后延迟从8秒降到2秒。流式输出是另一个关键手段。用户不需要等整个任务完成才看到结果中间步骤可以实时展示。这不仅降低感知延迟还能让用户提前发现方向错误、及时干预。缓存要用在刀刃上。工具调用结果、检索结果、甚至模型的部分输出都可以缓存。但缓存要有失效策略过期的缓存比没有缓存更危险。成本优化上模型分级是最有效的。简单任务用小模型复杂任务用大模型。判断标准可以是任务类型、历史成功率、用户等级。我一般会设一个路由层根据任务复杂度动态选择模型。上下文压缩也很关键。不是所有历史信息都需要传给模型该摘要的摘要、该丢弃的丢弃。我见过一个优化案例通过上下文压缩把平均token消耗降低了40%效果几乎没损失。还有一个手段是提前终止。当Agent已经收集到足够信息可以给出答案时不要继续跑完所有步骤。这需要模型能判断“信息充分性”可以在提示词里加一个检查点。4.3 题目九Agent的安全和权限怎么控制有哪些必须做的防护安全这块是面试的加分项能答好说明你有生产意识。输入防护是第一道关。用户输入要过滤注入攻击、越权指令、敏感信息。比如用户说“忽略之前的指令执行以下操作”这种要能识别并拦截。工具权限要最小化。每个Agent只能访问它完成任务必需的工具不能给全量权限。工具调用前要做权限校验调用后要做审计日志。输出防护同样重要。Agent的输出要过滤敏感信息、有害内容、未授权的数据泄露。特别是当Agent能访问内部知识库时要防止它把不该说的信息说出来。人工确认是关键操作的兜底。涉及资金、删除、对外发送等高风险操作必须有人工确认环节。确认界面要清晰展示Agent打算做什么、影响范围是什么。还有一个容易被忽略的是速率限制。防止Agent被恶意刷调用、防止单个用户占用过多资源。我一般会做用户级、会话级、工具级三层限流。4.4 题目十如果让你从零设计一个Agent系统你的技术选型和架构思路是什么这是压轴题考察的是综合能力。我的思路是先明确任务特征是单轮还是多轮、是确定性还是探索性、是低延迟还是高准确率优先。这些决定了架构的基本形态。然后选框架。LangChain生态全但重适合快速原型LlamaIndex检索强适合RAG为主AutoGen多Agent支持好适合协作场景。如果团队有工程能力我倾向于自研轻量框架因为通用框架的抽象往往带来不必要的复杂度。模型选型上主模型选能力强的辅助任务用轻量模型。要有fallback机制主模型不可用时能切换。存储层分三块向量库存语义记忆、关系库存结构化状态、对象存储存原始文件。三者通过统一的元数据层关联。可观测性从第一天就要做。全链路追踪、指标监控、日志聚合、告警规则一个都不能少。Agent系统的调试难度远高于传统服务没有可观测性就是盲人摸象。迭代机制要设计好。A/B测试、灰度发布、快速回滚这些是持续优化的基础。Agent的效果提升是个长期过程没有好的迭代机制就走不远。5. 面试中的加分项与避坑指南5.1 面试官最反感的几种回答第一种是只背概念不谈实践。问ReAct是什么答“Reasoning and Acting的缩写是一种让模型交替推理和行动的模式”然后没了。面试官想听的是你用它做过什么、遇到什么问题、怎么解决的。第二种是过度承诺。问怎么保证Agent不出错答“我们会做完善的测试和监控”。这种回答等于没答。正确的思路是承认Agent必然有出错概率然后说明你怎么降低概率、怎么快速发现、怎么优雅降级。第三种是回避不确定性。问某个技术选型的理由答“业界都这么做”。面试官想听的是你的判断逻辑哪怕你说“我选A是因为团队更熟悉虽然B理论上更好”也比随大流强。第四种是忽视成本。聊架构时只谈效果不谈成本面试官会觉得你没有生产意识。Agent的token成本、延迟成本、维护成本都是真金白银必须纳入考量。5.2 怎么展示你的实战经验最有效的方式是讲一个具体的失败案例。比如“我们上线后发现Agent在某个场景下会陷入死循环排查后发现是工具返回的错误信息格式不一致导致模型误判后来我们统一了错误码规范并加了循环检测”。这种故事比任何概念解释都有说服力。另一个技巧是量化你的成果。不要说“优化了性能”要说“通过并行化改造P99延迟从12秒降到3秒”。数字是最有说服力的。还可以展示你的技术判断。比如“我们评估过三个框架最终选了自研因为通用框架的抽象层在我们的场景下反而增加了调试难度”。这种有取舍的判断能体现深度。5.3 面试前的准备清单把上面10道题每个都写一份自己的答案不要背要理解。然后找朋友做模拟面试让对方追问细节。能扛住追问的答案才是真答案。准备2-3个实战案例每个案例按“背景-问题-方案-结果-反思”的结构整理。案例要覆盖不同的技术点架构设计、性能优化、异常处理、成本控制。了解一下目标公司的主营业务和技术栈想想他们的Agent可能用在什么场景、面临什么挑战。面试时能结合他们的业务聊好感度直接拉满。最后准备几个你想问面试官的问题。比如“你们Agent的评估体系是怎么建的”、“线上出问题时排查链路是怎样的”。这些问题能体现你的专业度也能帮你判断这个团队值不值得去。我面过不少人技术能力差不多的情况下能清晰讲出自己踩过什么坑、怎么爬出来的候选人通过率明显更高。因为这说明你真的做过而不是只看过。6. 一些没人明说但很重要的经验面试和实际做Agent是两回事但底层逻辑相通。面试考的是你的知识体系和判断力实际做考的是你的执行力和迭代能力。我见过技术很强但面试总挂的人问题往往出在表达结构上。回答问题时先给结论再给理由最后给例子。不要一上来就铺细节面试官没耐心听。也见过面试表现很好但实际做不出东西的人问题出在动手能力上。Agent这个领域变化太快很多问题没有现成答案必须自己试。平时多动手搭一些Demo哪怕很简单也比只看文章强。还有一个体会是Agent的很多问题本质上是软件工程问题。状态管理、错误处理、并发控制、可观测性这些传统后端的问题在Agent系统里同样存在甚至更复杂。所以别只盯着模型和提示词工程基本功要扎实。最后说一个趋势判断Agent正在从“能跑就行”向“生产可用”演进。面试的要求也会越来越高从问概念到问架构、从问效果到问成本、从问正常流程到问异常处理。提前按生产标准要求自己面试时自然游刃有余。这个领域没有标准答案但有最佳实践。多动手、多踩坑、多总结比背任何八股都管用。 Agent工程师面试10道高频题：从架构原理到生产落地的深度解析
1. 为什么这10道题成了Agent工程师的“照妖镜”这两年Agent这个词被炒得滚烫招聘JD上但凡沾点AI的岗位不写一句“熟悉Agent架构”都不好意思发出来。但真到面试环节很多候选人的表现就很有意思了聊概念头头是道一追问实现细节就开始打太极再问边界条件和失败场景基本就只剩“这个我们后续会优化”了。我参与过不少轮Agent岗位的技术面也帮朋友做过模拟面试官。说实话能把这10道题答利索的人一只手数得过来。大部分人的问题不是不懂而是只懂了个壳——知道ReAct、知道Function Calling、知道向量数据库但为什么这么设计、什么时候会崩、崩了怎么救一问三不知。这篇文章就是把这10道高频题拆开揉碎不光给答案更给答题的思路和背后的逻辑。适合正在准备Agent方向面试的人也适合已经在做Agent但想系统梳理一遍知识体系的工程师。我会按“面试官到底想听什么”的角度来讲而不是背八股。2. 第一类问题Agent的基础架构与核心循环2.1 题目一请描述一个Agent的完整运行循环从接收输入到输出结果这题看着基础但能答完整的人不多。大部分人会说“思考-行动-观察”循环然后就没然后了。面试官想听的是你对整个链路的掌控力。一个完整的Agent循环至少包含这几个阶段输入解析与意图识别、上下文组装、规划与推理、工具选择与调用、结果观察与状态更新、终止条件判断。每个阶段都有坑。输入解析阶段很多人直接拿用户原始query去检索这是大忌。用户说“帮我看看上周那个项目的进度”你得先解析出“上周”对应的时间范围、“那个项目”指代的是哪个项目。这一步做不好后面全白搭。上下文组装是区分新手和老手的关键。新手把所有历史对话一股脑塞进去老手会做分层上下文管理系统提示词单独一层、工具描述单独一层、近期对话做摘要、远期对话做向量检索召回。为什么要分层因为token是钱而且无关信息会干扰模型判断。规划与推理阶段ReAct模式是最常见的但纯ReAct有个致命问题它没有全局规划。模型走一步看一步容易在局部最优里打转。所以实际生产环境里通常会加一个Plan-and-Execute的前置规划层先让模型出个粗粒度的步骤列表再逐步执行。工具调用这块面试官最爱追问的是并行调用和依赖调用的处理。比如用户问“对比一下A公司和B公司的最新财报”这两个查询没有依赖关系应该并行发起但如果问“查一下A公司CEO的母校然后看看那个学校有哪些知名校友”这就是串行依赖。你的Agent框架得能识别这两种模式。终止条件判断是最容易被忽略的。很多Agent跑着跑着就陷入死循环或者该停的时候不停。常见的终止策略包括达到最大步数、连续N步没有新信息、模型输出明确的完成信号、工具返回结果满足预设条件。我一般会设三层保险硬性步数上限、语义重复检测、人工确认兜底。面试官想听的不是你背出了几个阶段而是你有没有踩过坑、有没有在生产环境里处理过异常情况。2.2 题目二Agent的记忆系统怎么设计短期记忆和长期记忆分别怎么实现记忆系统是Agent的灵魂但很多人把它简单等同于“把对话历史存下来”。这就好比说人的记忆就是一本日记太粗糙了。短期记忆的核心是工作记忆对应的是当前任务相关的上下文。实现上通常是一个滑动窗口加摘要机制。窗口大小怎么定不是拍脑袋要看你的模型上下文长度和任务复杂度。比如做多轮工具调用的任务窗口至少得覆盖最近5-8轮交互否则模型会忘记刚才调用了什么工具、返回了什么结果。摘要机制也有讲究。不是简单地把旧对话压缩成一段话而是要做结构化摘要保留关键实体、工具调用记录、未完成的子任务、已确认的事实。我见过一个团队的做法是维护一个“任务状态表”每轮交互后更新比纯文本摘要靠谱得多。长期记忆的实现路径就更多了。最常见的是向量数据库元数据过滤但纯向量检索有个问题它擅长语义相似不擅长精确匹配和时间推理。所以实际系统里往往是混合方案向量检索负责模糊召回结构化查询负责精确过滤再加一层重排序。还有一个容易被忽略的点是记忆的写入策略。不是所有对话都值得存。我一般会设几个触发条件用户明确说“记住这个”、任务成功完成后的关键结论、出现纠错信息时。无差别全存的结果就是检索时噪声太大召回质量直线下降。长期记忆的更新和遗忘机制也是面试官爱问的。记忆不是只增不减过期的、矛盾的、低置信度的记忆要能标记和清理。这块可以类比数据库的TTL和版本管理思路是通的。2.3 题目三Function Calling的底层原理是什么模型怎么知道该调用哪个工具这题能筛掉一大半人。很多人只会用API不知道背后发生了什么。Function Calling的本质是模型在训练阶段学习了工具调用的模式。具体来说训练数据里包含了大量“用户请求-工具描述-调用参数”的样本模型学会了根据工具的名称、描述、参数schema来判断该不该调、调哪个、传什么参数。关键点来了工具描述的质量直接决定调用准确率。我见过太多团队把工具描述写得含糊其辞然后抱怨模型调不对。工具描述要包含功能一句话说明、适用场景、不适用场景、参数含义和格式、返回值结构、可能的错误码。写得好的工具描述模型调用准确率能提升30%以上。模型选择工具的决策过程可以理解为一次条件概率计算给定当前上下文和所有可用工具的描述哪个工具的条件概率最高。所以工具数量不是越多越好超过一定数量后模型的选择准确率会下降。实践中单次暴露给模型的工具最好控制在10-15个以内多了就要做工具路由——先用一个轻量模型或规则引擎筛选出候选工具集。参数填充是另一个坑。模型有时候会漏填参数、填错类型、或者编造不存在的参数值。所以工具调用前必须做参数校验调用后要做结果验证。我一般会在工具层加一层wrapper做参数schema校验和默认值填充模型只负责给核心参数辅助参数由系统补全。还有一个高频追问模型怎么处理工具调用失败。好的Agent应该能区分错误类型参数错误就修正参数重试、权限错误就提示用户、超时就降级或换工具、逻辑错误就重新规划。无脑重试是最蠢的做法浪费token还解决不了问题。3. 第二类问题规划、推理与决策能力3.1 题目四ReAct、Plan-and-Execute、Reflexion三种模式的区别和适用场景这三种模式经常被混为一谈但它们的适用场景完全不同。ReAct是边想边做每一步都基于当前观察决定下一步。优点是灵活、能处理动态环境缺点是短视、容易陷入局部循环、token消耗大。适合工具调用链短、环境反馈快的场景比如简单的信息查询。Plan-and-Execute是先规划再执行。规划器出一个步骤列表执行器逐步完成。优点是全局视野、步骤可审查、便于并行优化缺点是规划可能过时、环境变化后需要重新规划。适合步骤明确、依赖关系清晰的任务比如多步数据处理的ETL流程。Reflexion是在执行后加一个自我反思环节分析哪里做得好、哪里可以改进把反思结果存入记忆供后续使用。优点是能持续改进、适合复杂任务缺点是增加额外调用、反思质量依赖模型能力。适合需要多轮迭代优化的场景比如代码生成和调试。实际生产系统往往是混合模式外层用Plan-and-Execute做粗粒度规划内层用ReAct做细粒度执行关键节点加Reflexion做质量检查。面试时能说出这个组合思路基本就稳了。选型的时候还要考虑成本。ReAct的token消耗通常是Plan-and-Execute的1.5-2倍Reflexion再加30%。如果任务简单、预算有限别硬上复杂模式。3.2 题目五Agent怎么做任务分解分解粒度怎么控制任务分解是Agent的核心能力之一但很多人分解出来的子任务要么太粗、要么太细。分解粒度有个实用原则每个子任务应该是一个可独立验证的单元。什么意思就是做完这个子任务后你能明确判断它是成功还是失败。如果无法判断说明粒度不对。举个例子“调研竞品并写报告”这个任务粗分解是“调研”和“写报告”但“调研”怎么算完成没法判断。细分解应该是确定竞品列表、收集每个竞品的定价信息、收集功能对比、收集用户评价、汇总分析、撰写报告。每个子任务都有明确的完成标准。分解方法上常见的有思维链分解、递归分解、模板分解。思维链分解适合线性任务递归分解适合层级任务模板分解适合重复性任务。实际用的时候往往是组合先用模板匹配看有没有现成的分解方案没有再用思维链或递归。分解后的子任务依赖关系要显式建模。我一般用DAG来表示节点是子任务边是依赖。这样便于识别哪些可以并行、哪些必须串行、哪些是关键路径。关键路径上的子任务要优先保证资源。还有一个坑是分解过细。子任务太多会导致调用次数爆炸、上下文碎片化、错误累积。经验值是单个任务的子任务数控制在5-9个超过这个范围就要考虑合并或分层。3.3 题目六多Agent协作怎么设计什么时候该用多Agent多Agent是这两年的热点但很多团队是“为了多Agent而多Agent”结果复杂度上去了效果没提升。先说什么场景适合多Agent角色分工明确且差异大的任务。比如一个Agent负责需求分析、一个负责代码生成、一个负责测试每个角色的提示词、工具集、知识库都不同。这种情况下多Agent有优势因为可以各自专业化。什么场景不适合任务同质化高、需要频繁共享上下文的场景。比如一个长文档的摘要任务拆成多个Agent分别摘要再合并往往不如单个Agent一次性处理。因为拆分带来的上下文丢失和合并成本超过了并行带来的收益。多Agent的通信机制是面试重点。常见的有共享黑板、消息传递、层级汇报。共享黑板适合松耦合协作消息传递适合点对点交互层级汇报适合有明确管理关系的场景。选哪种取决于你的任务结构和延迟要求。协作模式上辩论模式和投票模式是两种常见的决策机制。辩论模式让多个Agent从不同角度分析最后综合投票模式让多个Agent独立给出答案取多数。辩论适合开放性问题投票适合有明确答案的问题。我个人的经验是能用单Agent加工具解决的别上多Agent。多Agent的调试成本是指数级上升的出了问题很难定位是哪个Agent的锅。4. 第三类问题工程化与生产落地4.1 题目七Agent的评估怎么做离线评估和在线评估分别关注什么评估是Agent从Demo到生产的关键一步但很多团队这块是空白。离线评估关注的是可复现的指标。常见的包括任务完成率、平均步数、工具调用准确率、参数填充准确率、幻觉率、token消耗。这些指标需要在固定的测试集上跑测试集要覆盖正常场景、边界场景、异常场景。构建测试集有个技巧从生产日志里采样。真实用户的query分布和人工构造的测试集往往差异很大。我一般会从线上随机采样一批请求人工标注期望结果作为回归测试集。每次迭代后跑一遍看指标有没有退化。在线评估关注的是真实用户体验。核心指标包括用户满意度显式评分或隐式行为、任务中断率、人工接管率、平均响应时间。这些指标没法离线模拟必须上生产才能拿到。还有一个容易被忽略的维度是鲁棒性评估。给Agent输入带噪声的、对抗性的、模糊的query看它能不能优雅处理。比如用户输入里有错别字、有歧义、有恶意诱导Agent的表现如何。这块的测试用例要专门设计。评估频率上离线评估每次发版必跑在线评估持续监控。发现指标异常要能快速定位是哪个环节出了问题所以全链路追踪是必须的。每个请求的每一步决策、每一次工具调用、每一个中间结果都要有日志。4.2 题目八Agent的延迟和成本怎么优化有哪些实用手段这题是生产环境的核心痛点答得好能直接体现工程能力。延迟优化上并行化是最直接的手段。能并行的工具调用、能并行的子任务、能并行的检索查询全部并行。我见过一个团队把串行的5次检索改成并行后延迟从8秒降到2秒。流式输出是另一个关键手段。用户不需要等整个任务完成才看到结果中间步骤可以实时展示。这不仅降低感知延迟还能让用户提前发现方向错误、及时干预。缓存要用在刀刃上。工具调用结果、检索结果、甚至模型的部分输出都可以缓存。但缓存要有失效策略过期的缓存比没有缓存更危险。成本优化上模型分级是最有效的。简单任务用小模型复杂任务用大模型。判断标准可以是任务类型、历史成功率、用户等级。我一般会设一个路由层根据任务复杂度动态选择模型。上下文压缩也很关键。不是所有历史信息都需要传给模型该摘要的摘要、该丢弃的丢弃。我见过一个优化案例通过上下文压缩把平均token消耗降低了40%效果几乎没损失。还有一个手段是提前终止。当Agent已经收集到足够信息可以给出答案时不要继续跑完所有步骤。这需要模型能判断“信息充分性”可以在提示词里加一个检查点。4.3 题目九Agent的安全和权限怎么控制有哪些必须做的防护安全这块是面试的加分项能答好说明你有生产意识。输入防护是第一道关。用户输入要过滤注入攻击、越权指令、敏感信息。比如用户说“忽略之前的指令执行以下操作”这种要能识别并拦截。工具权限要最小化。每个Agent只能访问它完成任务必需的工具不能给全量权限。工具调用前要做权限校验调用后要做审计日志。输出防护同样重要。Agent的输出要过滤敏感信息、有害内容、未授权的数据泄露。特别是当Agent能访问内部知识库时要防止它把不该说的信息说出来。人工确认是关键操作的兜底。涉及资金、删除、对外发送等高风险操作必须有人工确认环节。确认界面要清晰展示Agent打算做什么、影响范围是什么。还有一个容易被忽略的是速率限制。防止Agent被恶意刷调用、防止单个用户占用过多资源。我一般会做用户级、会话级、工具级三层限流。4.4 题目十如果让你从零设计一个Agent系统你的技术选型和架构思路是什么这是压轴题考察的是综合能力。我的思路是先明确任务特征是单轮还是多轮、是确定性还是探索性、是低延迟还是高准确率优先。这些决定了架构的基本形态。然后选框架。LangChain生态全但重适合快速原型LlamaIndex检索强适合RAG为主AutoGen多Agent支持好适合协作场景。如果团队有工程能力我倾向于自研轻量框架因为通用框架的抽象往往带来不必要的复杂度。模型选型上主模型选能力强的辅助任务用轻量模型。要有fallback机制主模型不可用时能切换。存储层分三块向量库存语义记忆、关系库存结构化状态、对象存储存原始文件。三者通过统一的元数据层关联。可观测性从第一天就要做。全链路追踪、指标监控、日志聚合、告警规则一个都不能少。Agent系统的调试难度远高于传统服务没有可观测性就是盲人摸象。迭代机制要设计好。A/B测试、灰度发布、快速回滚这些是持续优化的基础。Agent的效果提升是个长期过程没有好的迭代机制就走不远。5. 面试中的加分项与避坑指南5.1 面试官最反感的几种回答第一种是只背概念不谈实践。问ReAct是什么答“Reasoning and Acting的缩写是一种让模型交替推理和行动的模式”然后没了。面试官想听的是你用它做过什么、遇到什么问题、怎么解决的。第二种是过度承诺。问怎么保证Agent不出错答“我们会做完善的测试和监控”。这种回答等于没答。正确的思路是承认Agent必然有出错概率然后说明你怎么降低概率、怎么快速发现、怎么优雅降级。第三种是回避不确定性。问某个技术选型的理由答“业界都这么做”。面试官想听的是你的判断逻辑哪怕你说“我选A是因为团队更熟悉虽然B理论上更好”也比随大流强。第四种是忽视成本。聊架构时只谈效果不谈成本面试官会觉得你没有生产意识。Agent的token成本、延迟成本、维护成本都是真金白银必须纳入考量。5.2 怎么展示你的实战经验最有效的方式是讲一个具体的失败案例。比如“我们上线后发现Agent在某个场景下会陷入死循环排查后发现是工具返回的错误信息格式不一致导致模型误判后来我们统一了错误码规范并加了循环检测”。这种故事比任何概念解释都有说服力。另一个技巧是量化你的成果。不要说“优化了性能”要说“通过并行化改造P99延迟从12秒降到3秒”。数字是最有说服力的。还可以展示你的技术判断。比如“我们评估过三个框架最终选了自研因为通用框架的抽象层在我们的场景下反而增加了调试难度”。这种有取舍的判断能体现深度。5.3 面试前的准备清单把上面10道题每个都写一份自己的答案不要背要理解。然后找朋友做模拟面试让对方追问细节。能扛住追问的答案才是真答案。准备2-3个实战案例每个案例按“背景-问题-方案-结果-反思”的结构整理。案例要覆盖不同的技术点架构设计、性能优化、异常处理、成本控制。了解一下目标公司的主营业务和技术栈想想他们的Agent可能用在什么场景、面临什么挑战。面试时能结合他们的业务聊好感度直接拉满。最后准备几个你想问面试官的问题。比如“你们Agent的评估体系是怎么建的”、“线上出问题时排查链路是怎样的”。这些问题能体现你的专业度也能帮你判断这个团队值不值得去。我面过不少人技术能力差不多的情况下能清晰讲出自己踩过什么坑、怎么爬出来的候选人通过率明显更高。因为这说明你真的做过而不是只看过。6. 一些没人明说但很重要的经验面试和实际做Agent是两回事但底层逻辑相通。面试考的是你的知识体系和判断力实际做考的是你的执行力和迭代能力。我见过技术很强但面试总挂的人问题往往出在表达结构上。回答问题时先给结论再给理由最后给例子。不要一上来就铺细节面试官没耐心听。也见过面试表现很好但实际做不出东西的人问题出在动手能力上。Agent这个领域变化太快很多问题没有现成答案必须自己试。平时多动手搭一些Demo哪怕很简单也比只看文章强。还有一个体会是Agent的很多问题本质上是软件工程问题。状态管理、错误处理、并发控制、可观测性这些传统后端的问题在Agent系统里同样存在甚至更复杂。所以别只盯着模型和提示词工程基本功要扎实。最后说一个趋势判断Agent正在从“能跑就行”向“生产可用”演进。面试的要求也会越来越高从问概念到问架构、从问效果到问成本、从问正常流程到问异常处理。提前按生产标准要求自己面试时自然游刃有余。这个领域没有标准答案但有最佳实践。多动手、多踩坑、多总结比背任何八股都管用。