过去大半年我一直在做Agent方向的设计评审和面试。这个岗位名字可能五花八门但做的事情高度一致把大模型从会聊天推到会干活而且是能在生产环境里稳定干活。为了叙述方便下面统一叫Agent工程化。面了这么多候选人之后我最大的体感是大部分人对Agent的开发是有感觉的——扯起Prompt、工作流、工具调用头头是道但一旦话题切到评测怎么做、线上出了问题靠什么定位、并发上来会不会被打爆、多Agent到底该不该上对话质量就断崖式下降。这篇文章就是把我面试中固定要用的5个关键问题连同我背后的考察逻辑完整复盘一遍。如果你正要去面Agent方向的岗位建议拿它做自查清单如果你是带团队的也可以直接把这套问题搬回去用。1. Agent面试和普通后端面试到底差在哪1.1 这个岗位真正在找什么样的能力我理解很多候选人会觉得奇怪我算法八股背得挺熟怎么Agent面试还是被挂。因为Agent工程化岗位要的不是能调通模型的人而是能把一个概率系统变成确定性服务的人。普通后端面试考察的是确定的逻辑、稳定的API、可预期的性能Agent面试在此基础上多了一层麻烦系统里有一个非确定性引擎LLM。它可能今天答对、明天答错输入差一个字输出就差十万八千里还会一本正经地把错误信息当事实输出。所以这个岗位在找三种能力。第一种是对模型行为边界的理解——知道哪些能力应该交给推理哪些应该交给代码和规则。第二种是对任务流程的工程拆解——能把业务目标拆成步骤、状态、分支和失败处理。第三种是对生产环境的敬畏——评测、观测、限流、降级、回滚每一样都要落在系统设计里。这三种能力光靠背Prompt技巧背不出来必须在真实项目里被问题逼过一遍。1.2 从开发到部署的五段链路和考察全景我面试时不会东一榔头西一棒槌地问而是沿着Agent的生命周期走一条完整的线设计工作流 - 验证质量 - 排障复盘 - 稳定上线 - 横向扩展。对应地我固定会问五个问题序号我会问的方向对应链路我想收集的信号1一条Agent工作流怎么设计才不是玩具代码开发期模块分层、状态管理、失败路径2凭什么说Agent的输出是对的测试期评测体系、结构化校验、兜底策略3Agent管线崩了靠什么定位运行期链路追踪、回放、异常定位思路4Agent从原型到线上哪些坑躲不掉部署期并发、缓存、超时重试、灰度回滚5当Agent不止一个边界怎么划扩展期单/多Agent判断力、路由、协议隔离这五个问题不是孤立的知识点它们有一条隐形主线风险。LLM不可控、外部工具会挂、系统会过载、代码会出错。工程化的本质就是在每个环节给风险加一层控制。候选人回答任何一个问题时只要主动谈风险控制在我这里的得分一定会上去。1.3 面试评分表上我最看重的四个维度在具体讲五个问题之前先透个底我打分不看重候选人是不是追到了最新模型也不看重他用过哪个主流框架。我评分的核心是四个维度。架构合理性模块边界是否清晰状态是否被妥善管理扩展是否有明确方向损失控制意识当某一步失败时候选人能讲清楚代价是什么、如何止损、如何兜底可观测意识候选人有没有主动设计日志、trace、回放的意识而不是出了事才想到补成本敏感度每个环节的token成本、推理延迟候选人心里有没有一笔账。这四个维度会在后面的五个问题里反复出现。你说完任何一个方案我都会在心里问一句如果这个环节出了事你的方案疼不疼2. 问题一一条Agent工作流怎么设计才不算玩具代码2.1 我一般会怎么问假设我们现在要给内部做一个文档问答Agent它需要检索企业文档、支持多轮追问、还能调用一个外部计算工具。你不用写代码先告诉我整体工作流怎么组织代码大概会分哪几层。这个问题很开放但它能直接暴露一个关键事实——候选人脑子里有没有一张工程图。回答只有先把问题给模型模型决定调工具我执行完再交回给它的候选人我基本能确定他只写过Demo。这个回答描述的是一次循环不是一套可维护的系统。如果候选人反过来问几句比如多轮对话的记忆放哪里外部工具失败怎么办这一步的权限边界是什么我会比较开心。因为真正设计过系统的人第一反应一定是补边界条件而不是急着给方案。一个只能顺着思路往下讲的候选人和一个能主动堵住漏洞的候选人差距就在这些反问里。2.2 高分答案的骨架编排层、执行层、基础层我认可的典型结构是三个平面。编排层负责整条任务的管理。它定义Agent的入口状态、目标拆解方式、步骤推进逻辑和终止条件。这层可以把运行流程实现为有限状态机例如IDLE - PLANNING - EXECUTING - WAITING_INPUT - DONE / FAILED。每一步之间是显式转换不是靠模型自由发挥跳转。执行层负责把编排层的决策落地。比如调用检索接口、格式化结果、检查工具返回、把结果重新组装成模型能读的文本。基础层则是模型接口、各类外部工具、状态存储、配置中心。为什么这样分因为这是标准的分层思想。编排层决定了Agent下一步做什么执行层决定具体怎么做基础层决定用什么资源做。三层各改各的互相不污染。举例来说你想把某个工具的返回格式从JSON换成XML只需要改执行层你想在工具执行前增加一道审核确认只动编排层即可。很多失败Demo的问题就是把这三层全塞进一大段Prompt和回调里最后谁也改不动。2.3 状态管理这一题能筛掉一半候选人工作流设计里我最深追的就是状态管理。常见追问是如果任务执行到一半进程重启了你能恢复现场继续跑吗很多候选人完全没有想过这个问题。他们会说把对话历史全部塞进上下文重启后让模型接着读不就行了吗其实这样在多数情况下都恢复不了——模型并不知道当前任务执行到了哪一步、哪些工具已经跑成功、哪些还没跑。Agent在运行期至少有三类状态。交互状态是用户和Agent的多轮对话任务状态是当前计划、已完成步骤、待办步骤、中间产物外部状态是工具调用的幂等键、写操作结果、外部系统事务标记。合理的做法是把任务状态结构化成快照存进数据库或缓存每完成一个关键步骤写一版。下面是一个很简化的快照示例{ task_id: task_001, goal: 整理本季度销售数据并生成摘要, plan: [检索数据, 计算同比, 写摘要], completed_steps: [检索数据, 计算同比], next_step: 写摘要, checkpoint_time: 2025-06-12T10:30:00Z }有这个快照进程崩了、任务超时、用户重新进来都可以从next_step接着跑而不是从头再来。我自己在做一个内部小工具Agent时就踩过这个坑状态全放内存服务一重启用户只能重来。后来补上检查点机制体验立刻不一样。我特别看重这个点因为它区分了脚本和系统。2.4 失败路径的追问重试、备选、降级第二个深追点是失败处理。我会直接追加如果把第三步的工具调用超时了你会让Agent做什么好的回答不是让模型自己决定而是设计一组明确的动作。首先是重试1到2次带退避避免雪崩。然后是备选路径如果A检索服务超时是否可以用B索引的只读副本如果天气服务不返回是否可以换一个数据源。再往下是降级明确告诉用户当前拿不到完整信息先给出已获得的部分结果或者把任务转人工。还有一个细节值得提给每一步设置硬超时。很多Agent卡死的根因就是某次工具调用没有超时上限一条任务能原地等一分钟。设置单步执行上限全局执行上限后系统哪怕出问题也只是局部问题不会整条任务悬死。能答出这些层次的候选人说明他真正把Agent当成一套分布式系统在设计。3. 问题二凭什么说Agent的输出是对的3.1 这个问题为什么一票否决第二个问题我会非常直接Agent跑通了你用什么方法证明它的输出是对的而且能持续对这个问题能淘汰大批候选人因为他们对对的定义很模糊。你想LLM是采样生成的同一个Prompt今天跑和明天跑结果可能不一样一个任务里又有多次推理和多次工具调用任何一环错了最后结论都可能是错的。如果候选人没有评测体系只有一个Demo那他交上来的系统在线上就是一颗定时炸弹。什么叫持续对不是这次对而是每次改动任何参数、提示词、模型版本后行为都能回到基线以上。没有回归评测的Agent根本不敢做迭代。这里我是拿出品控标准来要求候选人的模型输出是概率的那你就必须用工程手段把概率问题变成可统计、可比较、可收敛的问题。3.2 三层评测集从任务级到步骤级到回归护城河靠谱的做法是建立三层评测集。端到端任务评测用完整业务场景看Agent最终能不能达成目标。比如帮用户把本季度销售Excel整理成报告跑完整条链路按可量化的标准判分而不是仅仅看起来还可以。子步骤评测单独验证中间的零件。比如工具调用生成的参数是否正确、检索到的文档片段是否和问题相关、摘要是否忠于原文。这一步的价值是精确定位质量瓶颈避免整条任务失败后还要一层层猜。回归评测是最容易被忽视的一层。把曾经翻过车的case不断补充进去每改一次Prompt、换一次模型、调整一次工作流就把这批case重跑一遍确认真实行为没有退化。我面试时会问你上个月修过的最有价值的一个bug有没有变成评测用例这个问题基本能看出候选人的工程习惯。这里给一个常用指标参考指标含义为什么重要任务成功率完整目标达成的比例反映端到端效果工具调用准确率工具名称与参数是否合法防止脏请求打到外部系统无效动作率模型做了不该做的操作衡量Agent的克制力错误信息率输出中包含不实信息的比例幻觉的直接度量平均步数/耗时/token成本一次任务消耗多少资源衡量效率与成本收益3.3 输出校验闭环不能只靠模型自觉评测集是事后验证但工程上还需要运行时守门。我特别认可候选人谈到输出校验闭环Agent让模型输出的时候尽量约束成结构化格式比如JSON拿到结果后先用JSON Schema或自定义校验器检查不合法就修正或重试仍然不行就进入兜底。更细的一层是针对每个工具定义参数校验器。例如一个查询订单的工具参数订单号必须是合法编号日期范围的结束时间必须晚于开始时间。模型填错了直接拦截不让脏参数发出去。这个动作看起来简单但能把很多模型胡来的问题挡在系统外面。我见过一些前期图省事不做校验的团队线上最常出现的故障就是工具收到一堆莫名其妙的参数外部系统被搅得乌烟瘴气。还有一点值得谈结构化输出不是限制模型的创造力而是把模型语言的自由度和工程接口的确定性做隔离。它让系统的其他部分可以稳定依赖输出格式不用处理自然语言的歧义。3.4 兜底策略成熟系统要敢承认不知道一个让我比较看重的回答是候选人会不会主动设计兜底。因为不管评测集多全、校验多严总会有模型答不上的输入。成熟的Agent至少要有几级兜底。一是明确拒绝并给出替代路径比如我暂时查不到你可以先确认订单号。二是降级方案比如主模型判断不了换个更保守的小模型或固定Prompt走一遍。三是从自由生成降级到选择题让用户在有边界的选项里确认意图。四是转人工把上下文结构化整理后交给坐席继续处理。我举一个印象不错的例子。某客服Agent在拿不准用户意图时不会硬猜而是转成我先帮您记录稍后专人跟进同时把对话摘要、已尝试的动作、置信度一并传给人工。这样既控制了风险又保留了体验。工程化不是逼模型全知全能而是给不确定留一条不丢分的退路。4. 问题三Agent管线崩了你靠什么定位4.1 一次真实事故问出最原始的排障本能第三个问题我习惯直接抛场景现在线上一个Agent某次任务跑了30秒、调用了7次工具最后给用户一个完全错误的结论。你会怎么开始排查这个问题很像后端面试里的线上超时怎么查但Agent更难中间有多次LLM推理、多次工具调用错误还有传导性。普通日志给到手里基本是一大堆无结构的文本根本看不出是哪一步出了错——到底是检索到了一篇不相关的文档还是模型规划错了还是工具参数传错了又或者是最后生成的时候把信息拼错了。没有结构化的记录排查就是大海捞针。很多候选人到这里会卡住原因很简单他从来没把观测当成Agent系统的必备组件来设计而是当成事后补救。可观测性这种东西事后补是补不回来的因为事故发生时你根本不知道要留下哪些现场。4.2 给一次任务一条trace把决策切成可观测的切片正确的起点是链路追踪。给每次任务分配一个trace_id再把任务里的动作都记成带父子关系的span。关键的span有这么几类LLM调用过程包括上游Prompt全文、模型名称、返回内容、token数、耗时工具调用过程包括方法名、入参、出参、报错信息、耗时编排决策过程包括进入了哪个分支、为什么进入、状态快照ID中间结果比如检索命中的文档标题、摘要等关键产物。我常用的一个span字段模板字段例子排查价值span_id / trace_id一条trace下的span_01关联整条链路event_typellm_call / tool_call / state_transition快速定位环节input_summary本轮Prompt关键片段检查上下文是否被污染output_summary模型输出或工具结果摘要判断哪一步产出异常costtoken数与延迟判断是否在异常烧钱error报错信息或拒答标记快速过滤失败段为什么这么强调调用链记录因为Agent最常见的Bug就是上下文污染某轮错误信息混进了下一轮的Prompt结果模型被带偏。如果你的系统连上一次模型输出了什么都没留这种问题根本无法复现。有trace之后你可以把每一步的input/output摊开看问题往往一眼就能找到。4.3 回放能力把线上一次锅变成本地一个用例比日志更进一步是我特别看重的回放能力。把线上一次任务完整的输入事件、中间产物、模型返回都保存下来然后在测试环境重放一遍。这个能力有三层价值。第一可复现。线上偶发问题如果能被重放就不再是幽灵Bug。第二可验证修复。修完代码后拿同一份回放数据跑一遍确认行为符合预期。第三可沉淀。重放并通过修复的事件顺手就变成第3章里说的回归评测用例。要做好回放关键是提前设计事件审计表。你是先记录好完整数据还是等出事后才发现缺字段这个差别非常大。很多人踩过一个坑事故发生后日志里只有最终回答没有中间的模型输入输出等于没留现场。所以我会在系统设计阶段就要求所有LLM调用、工具调用都默认落审计表至少在排查窗口内保留完整原始数据。4.4 区分模型抽风和代码Bug的排查顺序Agent排障里最头疼的是同一输入时好时坏。我通常按下面的顺序来定位。第一步先看trace确认哪一步产出的东西开始异常。第二步把这一步的输入摘出来用固定Prompt固定模型参数反复跑5到10次。第三步如果稳定出错说明多半是逻辑或上下文问题如果时好时坏说明模型随机性占主导。第四步再把同样的输入降级到更简单的模型或Prompt上跑一遍判断是不是因为复杂推理导致问题。第五步检查是不是历史消息太长把注意力带偏精简上下文后重试。我遇到过的多数线上Case最后都指向同一个原因上下文里塞了太多无关历史信息模型忘了当前目标。这种问题不是换一个大模型就能解决的而是要在工程上做上下文裁剪和注意力聚焦。能把这个经验讲出来的候选人我会认为他真实地在生产环境里调过Agent。5. 问题四Agent从原型到线上哪些坑是躲不掉的5.1 第一笔账你这个服务扛得住100个并发吗进入部署话题我会问一个很直白的问题线上突然来了100个并发任务你的服务会怎么样注意这里考察的不是你调了多少并发参数而是候选人心里有没有一笔成本账。一次Agent任务通常不止一次LLM调用可能是3到8次。假设平均每轮输入加输出合计5000 token一次任务就是2万到4万 token。100并发、假设每个任务需要4轮推理一分钟可能就是80万到160万token的量级。这个量级换到成本上非常可观延迟也会迅速恶化。好的回答会先做容量规划单任务的推理次数、token量、外部工具调用量然后设计队列和并发控制让请求排队而不是无脑往模型服务上怼。很多方案会把并发线程数拉得很高结果模型服务被打爆、超时率直线上升。正确的思路是流控优先能力为王先保证核心任务能稳定完成再谈吞吐。5.2 缓存不是每个问题都值得让模型再算一遍Agent部署上的一个低成本高收益优化是缓存。很多问题的答案是稳定可复用的没有必要每次都让模型从头推理。缓存有三个级别。精确缓存完全相同的输入直接返回历史结果适合固定模板类任务。模块级缓存缓存中间计算结果比如文档检索结果、工具返回数据、规划结果。语义缓存用向量检索把近似意图的旧答案召回适合高频、低敏感性的场景。用缓存要注意边界和安全。涉及用户私有数据的一定不能进共享缓存需要按租户或用户维度隔离还要设计失效策略比如让Agent永远不会被缓存卡在某天之前的旧答案里。另外带了随机性的模型输出建议做低层缓存而不是全文缓存否则用户会明显感觉答案永远一样。5.3 超时、重试、熔断、限流保护下游就是保护自己Agent系统的下游有好几个模型服务、外部工具、数据库。每一个都值得做可靠性设计。这里不复杂但需要系统化。超时方面给单次LLM调用设置硬超时上限比如10到15秒给单工具调用设置更短上限比如5秒防止一步卡死全任务。重试方面遇到模型服务5xx或限流时用指数退避重试但最多2到3次不要无限重试。熔断方面连续N次失败就快速打开熔断开关短时间内不再把流量打到已经故障的系统上。限流方面按用户维度、任务维度、总维度分别控防止某个用户或某类任务吃光全部资源。一个特别要注意的细节是幂等键。工具调用时如果客户端超时了服务端其实可能已经执行成功了没有幂等键重试会重复执行操作特别是在转账、发送消息这类场景里会出大问题。所以凡是会写外部系统的Agent动作都要设计幂等机制。5.4 灰度上线与版本回滚Agent是代码、Prompt、模型的三合一最后一个是版本管理。后端项目发版会回滚代码Agent系统更麻烦一个线上行为往往由代码版本、Prompt版本、模型版本、工具配置共同决定。上线一个新Prompt可能就砸掉一批case切换模型版本也可能引发行为漂移。我的提醒是每一个线上Agent发布都应该是一个可回滚的组合包。把代码、Prompt、模型标识做成配置化依赖发布时锁定版本组合先做灰度喂给种子用户或用模拟流量跑一遍用评测集卡质量线成功率下滑超过阈值就自动切回保留最近N个版本的回滚能力不只是代码侧模型侧也要能切回上一版本。没有这套版本意识的Agent系统每次改Prompt都是在玩火。敢把改Prompt也可能上线事故讲得这么具体的候选人是真的踩过这个坑的。6. 问题五当Agent不止一个边界怎么划6.1 先回答要不要单Agent能解决的别硬上多Agent最后一个问题常从你现在的Agent会越来越多切入如果每个部门都想有自己的Agent你打算怎么组织很多候选人一听就兴奋开始说我要搭一个多Agent编排平台。但我的第一个期待是反问。好的候选人会先判断需求单Agent加工具能不能覆盖一个工作流里顺序调用几个工具已经能解决绝大多数业务问题。多Agent不是银弹。每多一个Agent就多一份模型调用成本、多一段链路延迟、多一个容易出错的分发和汇总环节。我见过一个内部演示项目把读文档、做摘要、列大纲拆成了三个角色Agent互相聊天结果又慢又贵最后一步提示词错误整条链路都挂了。如果把它放回工作流里顺序执行半天就能维护完。所以当候选人表现出多Agent需要克制的判断力时我会给高分。6.2 边界怎么划权限、上下文、协议三件套如果确实要上多Agent边界设计是核心。我的经验是划三层边界。第一层是权限边界。给不同Agent挂不同最小权限凭证比如只读Agent不能调用写接口数据敏感类Agent不能访问全量库。不要让一个万能Agent掌握所有工具那是对系统安全的极度不负责。第二层是上下文边界。不要让所有Agent共享一个大Context否则一个Agent的中间错误会污染全局。每个Agent维护自己的记忆只在需要时通过结构化消息对外传递结果。第三层是协议边界。Agent之间不要传递自由散文用统一的Message Schema和动作编码比如明确的消息类型、payload结构、错误码。这能让整个系统像微服务一样可测、可观测。很多多Agent翻车的原因就是A的输出直接塞给B的Prompt两边措辞一变配合就乱了。6.3 路由与编排让谁来干这件事可控制多Agent系统还需要回答任务如何分发。我认可一种稳妥模式前置路由 集中编排。入口处先用分类器或规则识别意图把任务路由到对应子Agent子Agent执行完按标准协议返回结果主控流程统一收集结果、处理冲突、决定是否追加追问。整个过程是集中式控制子Agent之间不自由协商。为什么这么设计因为自由协商意味着大量无谓的模型往返费钱费时且结果不可控集中式编排则把决策点集中在少数代码里可以配置、可以测试、可以回滚。从故障域角度看这种模式也更好。某个子Agent出问题时主控可以把它的任务降级为固定规则流程或转人工而不是让整个编排死掉。多Agent的工程价值不是看起来智能而是拆得开、挡得住、换得起。6.4 什么时候我才会考虑多Agent最后再补一个判断标准我什么时候会主动选多Agent而不是用单Agent加工具一是模块间有强烈的领域隔离需求比如一个Agent负责内容生成、一个Agent负责审核两者需要不同权限、不同模型、不同数据源。二是某个子能力有独立的迭代节奏团队想并行开发、独立上线。三是不同子任务对延迟、成本、模型的偏好明显不同比如检索类用轻量模型写作类用更强模型。如果这些条件都不太满足那我倾向于先从单Agent加好工具链开始。系统变复杂的驱动力应该来自真实约束而不是架构审美。能讲清楚这条的候选人我认为他真的想过什么不该做。把五个问题聊完之后说一点我自己的体会。做Agent方向的技术面试我最终收的信号一直不是你用没用过某某框架、是不是追到了最新模型而是三件非常朴素的事情出问题能不能查降级之后能不能兜量起来之后能不能扛。你在任何一个方向上准备好一个真实的踩坑故事把排查链条讲清楚都比背十个八股概念有用。准备面试的朋友建议把所有Agent知识点都折叠到从开发到部署这条线上想一遍而不是散装地记忆。这是我面了一轮又一轮之后最想强调的一点。