1. 面试官问Agent时他真正想听的是什么面到Agent这个话题很多候选人张嘴就是“大模型加工具调用”然后开始背Function Calling的流程。我做过几轮技术面试的旁观者也跟不少面试官聊过说实话这个答案一出口基本就定性了——这人只停留在调用API的层面没真正做过Agent系统。面试官问Agent从来不是想听你复述某个框架的文档。他想知道的是你有没有想过一个Agent系统里决策、记忆、执行、反馈这四个环节是怎么咬合的模型只是其中一环接口只是执行层的一个通道。真正区分一个人有没有Agent实战经验的是他能不能说清楚“模型在什么情况下会做出错误决策以及系统怎么兜住这个错误”。这个标题之所以扎心是因为它戳中了一个普遍现象大量教程把Agent简化成了“LLM Tools”的公式导致很多人以为会调几个API就等于会做Agent。但实际项目里模型加接口连最小可用系统都算不上。你还需要考虑状态管理、错误恢复、上下文压缩、工具编排、权限控制、可观测性——这些东西没有一个是模型或接口本身能解决的。这篇文章适合两类人一是正在准备Agent相关面试、想搞清楚面试官到底在考察什么的开发者二是已经动手做过Demo但总觉得系统“不太稳”、想弄明白差在哪里的工程师。我会从面试考察逻辑出发拆解Agent系统的真实架构补充大量实操中才会遇到的细节帮你把“模型加接口”这个答案升级成一套完整的工程认知。2. 为什么“模型加接口”这个答案会被扣分2.1 这个答案暴露了哪三个认知盲区第一个盲区是把Agent等同于一次模型调用。很多人描述Agent时脑子里想的是用户输入→模型判断→调用工具→返回结果。这是一条直线但真实Agent是一个循环。它需要根据执行结果决定下一步可能重试、可能换工具、可能放弃并请求人工介入。没有循环就只是一次带工具调用的推理。第二个盲区是忽略了状态的存在。模型本身是无状态的每次调用都是独立的。但Agent需要记住之前做了什么、失败了什么、当前进度在哪。这些状态存在哪里、怎么组织、怎么在上下文窗口里压缩是工程上的核心问题。面试官问“你的Agent怎么处理多轮任务”其实就是在问状态管理。第三个盲区是没有错误处理的概念。接口会超时、会返回格式错误、会权限不足。模型也会幻觉会调用不存在的工具会陷入死循环。一个只有“模型加接口”的系统遇到这些情况直接崩溃。而真实Agent必须有重试策略、降级方案、熔断机制和人工兜底通道。面试官听到“模型加接口”时心里的判断是这个人没有经历过Agent系统在生产环境里跑起来的痛苦不知道哪里会出问题。2.2 面试官真正在考察的能力维度从我跟一些面试官交流的经验看问Agent问题时他们通常在四个维度上打分。系统设计能力你能不能画出一个完整的Agent架构图说清楚每个模块的职责和交互方式。这包括任务规划、工具注册与发现、上下文管理、执行引擎、结果校验等。边界意识你知不知道模型的能力边界在哪里什么任务适合交给Agent什么任务不适合什么时候该让模型自主决策什么时候该用规则硬编码这种判断力比会调API重要得多。故障处理经验你有没有遇到过工具调用失败、模型输出格式错误、任务陷入循环这些情况你是怎么发现和解决的这些细节骗不了人做过就是做过。权衡取舍Agent系统里到处都是取舍。用大模型还是小模型上下文全量保留还是压缩工具粒度粗还是细每一步选择都有代价面试官想听的是你为什么这么选。2.3 一个真实面试场景的拆解假设面试官问“如果让你设计一个能自动处理客服工单的Agent你会怎么做”答“模型加接口”的人会说用大模型理解工单内容然后调用工单系统的API进行分类和回复。这个答案的问题在于工单可能包含多个问题需要拆解分类可能涉及权限判断回复可能需要查知识库如果模型不确定需要转人工工单系统API可能失败需要重试处理过程中需要记录日志供审计。这些都没有覆盖。而一个有经验的回答会先问清楚工单来源是什么分类体系有多少类回复是自动发送还是人工审核知识库的更新频率如何然后给出一个包含意图识别、任务拆解、工具编排、置信度判断、人工兜底、全链路日志的方案。两者的差距就是“会用模型”和“会做Agent”的差距。3. 一个Agent系统真正需要哪些模块3.1 任务规划与拆解层模型加接口的第一个缺口就是没有规划层。用户给一个复杂任务比如“帮我分析上个月的销售数据并生成报告”模型直接调一个数据分析接口是搞不定的。它需要先拆解第一步获取数据第二步清洗第三步计算指标第四步生成图表第五步撰写文字。每一步的输出是下一步的输入中间任何一步失败都要有应对。规划层的实现方式有好几种。最简单的是静态工作流把步骤写死在代码里模型只负责每一步的具体执行。这种方式稳定但不够灵活。进阶一点的是动态规划让模型根据任务目标自己生成步骤列表然后逐步执行。这种方式灵活但容易跑偏需要加约束。我在实际项目里更倾向于混合模式用规则定义必须执行的骨架步骤在骨架内部允许模型自主决定具体操作。比如数据分析任务获取数据和生成报告是固定步骤但中间用什么方法清洗、算哪些指标可以让模型根据数据特征自己判断。这样既保证了流程可控又保留了一定的灵活性。规划层还有一个容易被忽略的点步骤的粒度。拆得太粗模型一步搞不定拆得太细调用次数爆炸成本和延迟都上去了。我的经验是每个步骤应该是一个模型能在一次调用中完成、且输出可以被明确验证的单元。如果一步的输出无法判断对错说明拆得不够细。3.2 记忆与上下文管理这是“模型加接口”答案里几乎不会提到的部分但它是Agent能不能处理长任务的关键。模型的上下文窗口有限一个跑了二十步的任务历史信息早就超了。你需要决定哪些信息保留哪些压缩哪些丢弃。我一般把记忆分成三层。短期记忆是当前任务的执行轨迹包括每一步的输入输出和状态通常保留最近几轮更早的做摘要压缩。长期记忆是跨任务的知识比如用户偏好、常见问题的解决方案存在外部存储里需要时检索注入。工作记忆是当前步骤直接需要的上下文比如当前处理的文件内容、上一步的输出结果。上下文压缩是个技术活。简单截断会丢失关键信息全量保留会撑爆窗口。我试过几种方案用模型对历史做摘要、用向量检索只取相关片段、用结构化格式只保留关键字段。实测下来结构化摘要加关键字段保留效果最稳。比如每一步只保留“步骤编号、操作类型、输入摘要、输出摘要、状态”比让模型自由发挥写摘要要可靠得多。一个实用的技巧给上下文里的每条信息打上时间戳和优先级标签。当需要压缩时优先保留高优先级和最近的信息低优先级的旧信息直接丢弃。这个策略在长任务里能显著降低上下文占用。3.3 工具注册、发现与编排工具不是越多越好。我见过一个Agent注册了上百个工具结果模型选择困难经常调错。工具编排的核心是让模型在正确的时间看到正确的工具。我的做法是分组注册。按业务领域把工具分成若干组每次只把当前任务相关的组暴露给模型。比如处理订单问题时只暴露订单查询、退款、物流相关的工具不暴露用户管理、数据分析的工具。这样模型的决策空间小了准确率明显提升。工具描述也很关键。很多人写工具描述就一句话“查询订单”模型根本不知道什么时候该用。好的描述应该包含这个工具做什么、什么情况下用、输入参数的含义和格式、返回值的结构、可能的错误。描述越清晰模型调用越准确。编排层面除了让模型自主选择还可以加前置校验和后置校验。前置校验检查模型选的工具和参数是否合法不合法直接拦截并提示模型重新选择。后置校验检查工具返回的结果是否符合预期不符合就触发重试或降级。这两层校验能挡掉大部分低级错误。3.4 执行引擎与反馈循环执行引擎负责实际调用工具、处理返回、决定下一步。这里最核心的是反馈循环的设计。模型调用工具后结果怎么反馈给它是原样返回还是加工后再给我的经验是反馈给模型的结果要结构化、精简、带状态标记。比如工具返回了一大段JSON不要直接塞给模型而是提取关键字段加上“成功/失败”标记和错误码。模型看到精简后的结果更容易做出正确判断。反馈循环里还要处理重试和退避。工具调用失败时不能立刻重试要有退避策略。我一般用指数退避第一次等1秒第二次2秒第三次4秒最多重试三次。如果还失败就触发降级方案比如换备用工具、返回缓存结果、或者转人工。还有一个容易忽略的点循环检测。模型有时候会陷入“调用工具A→失败→重试A→失败”的死循环。执行引擎需要检测这种模式比如同一个工具连续失败三次就强制中断换策略或报错。没有这个机制Agent可能烧掉大量token还解决不了问题。4. 面试中如何把Agent话题答出深度4.1 用“分层架构”替代“模型加接口”当面试官问Agent怎么设计时不要从模型开始讲从分层架构开始讲。我会这样组织回答第一层是接入层负责接收请求、鉴权、限流、路由。第二层是规划层负责任务拆解和步骤生成。第三层是执行层负责工具调用和结果处理。第四层是记忆层负责状态存储和上下文管理。第五层是观测层负责日志、指标、追踪。然后说明模型在哪一层模型主要用在规划层和执行层的决策点但它不是系统的全部。接口在哪一层接口是执行层调用的通道但执行层还包括校验、重试、降级等逻辑。这样回答的好处是面试官能看到你有全局视角知道每个模块的职责和边界。而且这个架构不是背出来的是你真正理解系统后的自然表达。4.2 主动暴露你踩过的坑面试里最加分的不是你说自己做了什么而是你说自己做错了什么、怎么发现的、怎么修的。这比任何架构图都有说服力。比如你可以说“我早期做的Agent没有循环检测结果有一次模型陷入死循环十分钟烧掉了几十万token。后来我加了连续失败计数和强制中断同一个工具失败三次就切换策略。这个教训让我意识到Agent系统里模型不是最不可控的执行引擎的约束才是关键。”或者“我一开始把工具返回的原始JSON直接给模型发现模型经常解析错字段。后来我加了一层结果格式化只提取关键字段并加上状态标记准确率提升了很多。这个细节看起来小但对系统稳定性影响很大。”这种回答传递的信息是你真正跑过系统遇到过问题并且有解决问题的能力。这是“模型加接口”答案完全给不出的。4.3 展示你对成本和延迟的敏感度Agent系统在生产环境里成本和延迟是绕不开的。面试官如果问你“怎么优化”不要只说“用更小的模型”或“加缓存”要具体。我会从三个层面回答。规划层能静态拆解的步骤不要动态生成减少模型调用次数。执行层简单判断用规则复杂判断才用模型工具结果能缓存的缓存避免重复调用。记忆层上下文压缩要激进不必要的历史信息及时丢弃减少token消耗。延迟方面并行化是最大的优化点。多个独立的工具调用可以并行执行不用串行等待。比如同时查订单和查物流两个接口并行调总延迟取决于最慢的那个而不是两者之和。这个优化在实操中效果非常明显。面试官如果追问“怎么衡量Agent系统的好坏”你可以从任务完成率、平均步骤数、工具调用准确率、人工介入率、单任务成本这几个指标来回答。这些指标比“准确率”一个词要专业得多。5. 从Demo到生产Agent系统落地的几个关键决策5.1 模型选型不是越大越好做Demo时用最强的模型没问题但上生产就要考虑成本和延迟。我的经验是分级使用规划层用强模型因为任务拆解需要较强的推理能力执行层的简单判断用小模型甚至规则结果校验用规则或小模型。具体怎么分我会先跑一批真实任务统计每个环节的模型调用次数和token消耗。然后看哪些环节的模型输出可以被规则替代哪些环节换小模型后准确率下降不明显。通常执行层有大量调用是“格式化输出”或“简单分类”这些用小模型完全够用。还有一个决策是用通用模型还是微调模型。如果任务领域很垂直比如只处理特定类型的工单微调一个小模型可能比通用大模型效果更好、成本更低。但微调需要标注数据前期投入大。我的建议是先用通用模型跑通流程积累数据后再考虑微调。5.2 工具粒度粗一点还是细一点工具粒度是个权衡。粒度粗模型调用次数少但每个工具的逻辑复杂出错后难定位。粒度细模型调用次数多但每个工具职责单一容易测试和维护。我倾向于中等粒度一个工具对应一个完整的业务操作而不是一个技术步骤。比如“查询订单状态”是一个工具而不是“连接数据库”“执行查询”“格式化结果”三个工具。这样模型调用次数可控每个工具也有明确的业务含义。但有些情况需要细粒度。比如一个操作需要用户确认才能执行那“准备操作”和“执行操作”就要拆成两个工具中间插入确认环节。再比如一个操作可能失败需要重试拆成细粒度后重试范围更小不会重复执行已经成功的部分。5.3 人工兜底什么时候必须让人介入Agent不是全自动的至少在生产环境里不是。必须设计人工介入的触发条件。我的经验是三类情况必须转人工置信度低于阈值、涉及敏感操作、连续失败超过限制。置信度怎么来可以让模型在输出时附带置信度评分也可以用规则判断比如模型输出格式不符合预期、工具返回了异常状态码。敏感操作包括退款、删除数据、修改权限等这些操作即使模型很确定也应该让人确认。人工介入的体验也很重要。不能只给人工一个“任务失败”的通知要把完整的执行轨迹、当前状态、失败原因、建议操作都展示出来。人工处理完后结果要能回写到Agent系统里让Agent继续后续步骤。这个闭环设计不好人工兜底就会变成人工重做。5.4 可观测性出了问题怎么查Agent系统最怕的是出了问题不知道哪里出的。模型输出不可解释工具调用链路长没有可观测性根本没法排查。我一般会记录四类数据。调用日志每次模型调用和工具调用的输入输出、耗时、状态。决策轨迹模型每一步的决策理由可以让模型输出思考过程。状态快照每个步骤执行后的系统状态方便回放。指标聚合任务完成率、平均步骤数、工具调用成功率、人工介入率等。这些数据不只是用来排查问题还能用来优化系统。比如分析哪些工具调用经常失败哪些步骤模型经常决策错误然后针对性改进。没有这些数据优化就是拍脑袋。6. 几个容易被追问的Agent细节问题6.1 模型输出格式不稳定怎么办这是高频问题。模型有时候返回JSON有时候返回带解释的文字有时候字段名都对不上。我的处理方式是三层防护。第一层是提示词约束在系统提示里明确输出格式给出示例强调“只输出JSON不要有其他内容”。第二层是输出解析器用代码解析模型输出如果解析失败尝试提取JSON片段再失败就触发重试。第三层是重试提示重试时把解析错误的信息反馈给模型让它修正格式。实测下来这三层能解决95%以上的格式问题。剩下的5%通常是模型能力不足或任务本身模糊这种就需要换模型或重新设计任务。6.2 工具调用参数错误怎么处理模型经常传错参数比如该传数字传了字符串该传枚举传了自由文本。处理方式和格式问题类似前置校验加反馈重试。前置校验用JSON Schema定义每个工具的参数格式模型输出后先校验不通过就不执行直接把校验错误反馈给模型让它重新生成。反馈时要具体比如“参数order_id应该是字符串你传了数字”而不是笼统说“参数错误”。如果重试多次仍然错误就要考虑是不是工具描述不够清晰或者模型能力不够。这时候可以简化工具参数把复杂参数拆成多个简单参数或者换更强的模型。6.3 多轮对话里Agent怎么保持一致性多轮对话里用户可能中途改变需求或者补充信息。Agent需要能识别这些变化并调整执行计划。我的做法是每轮对话都重新评估任务状态。具体来说每轮用户输入后先把当前执行状态和用户新输入一起给模型让模型判断是继续当前任务还是修改计划还是开始新任务。这个判断本身也是一次模型调用但能避免Agent“一根筋”地执行旧计划。状态同步也很重要。如果用户修改了某个参数Agent需要更新状态里的对应字段并且检查后续步骤是否受影响。比如用户改了收货地址那物流相关的步骤都要用新地址重新执行。这种依赖关系的管理是Agent系统里比较复杂的部分需要仔细设计状态结构。6.4 Agent的测试怎么做Agent的测试比传统软件难因为输出不确定。我的策略是分层测试。单元测试测每个工具的功能这个和普通函数测试一样。集成测试测固定输入下的执行轨迹不要求最终输出完全一致但要求关键步骤和工具调用符合预期。评估测试用一批真实任务跑端到端统计任务完成率和人工介入率这个需要人工标注或人工评估。评估测试里我会特别关注失败案例。分析失败是因为模型决策错误、工具问题、还是任务本身超出能力范围。这些分析结果直接指导优化方向。没有评估测试Agent的迭代就是盲目的。7. 我在实际项目里总结的几条经验做Agent系统这几年踩过的坑比写过的代码还多。有几条经验我觉得比任何架构图都值钱。第一条先跑通再优化但别在Demo阶段就埋雷。很多人做Demo时图快状态管理用内存、错误处理直接抛异常、日志随便打。结果要上生产时发现到处都要改。我的建议是Demo阶段可以简化但状态存储、错误处理、日志记录这三个基础能力一开始就要有哪怕实现很简单。后面替换实现比从零加要容易得多。第二条模型的输出永远要当作不可信输入。不管模型多强它的输出都要经过校验才能使用。参数校验、格式校验、业务规则校验一层都不能少。我见过太多因为信任模型输出而导致的事故比如模型生成了不存在的订单号直接去查结果报错模型把金额算错了直接提交造成损失。校验的成本远低于出错的成本。第三条上下文管理是Agent系统里最容易被低估的部分。很多人把精力花在模型选型和工具开发上上下文管理随便做做。结果任务一长就出问题要么上下文超限要么关键信息丢失要么模型被无关信息干扰。我的经验是上下文管理要像数据库设计一样认真对待定义清楚什么信息存哪里、怎么检索、怎么压缩、怎么过期。第四条可观测性不是可选项。Agent系统出问题时没有日志和追踪根本没法排查。我一般会在项目第一天就搭好日志和指标采集哪怕只是简单的文件日志。后面再接入更专业的观测工具。这个投入在排查问题时回报巨大。第五条人工兜底不是失败是设计的一部分。不要追求100%自动化那既不现实也不安全。把人工介入设计成系统的一个正常环节而不是异常处理。这样系统更稳用户也更放心。最后说一个面试技巧如果面试官问Agent你可以先反问一句“您是想了解Agent的架构设计还是具体某个环节的实现”这样既能展示你对Agent有全局认知又能把问题聚焦到你最擅长的部分。面试官通常会顺着你的问题走你就掌握了主动权。这个技巧我用过几次效果都不错。 Agent面试别只答模型加接口：从架构到落地的深度解析
1. 面试官问Agent时他真正想听的是什么面到Agent这个话题很多候选人张嘴就是“大模型加工具调用”然后开始背Function Calling的流程。我做过几轮技术面试的旁观者也跟不少面试官聊过说实话这个答案一出口基本就定性了——这人只停留在调用API的层面没真正做过Agent系统。面试官问Agent从来不是想听你复述某个框架的文档。他想知道的是你有没有想过一个Agent系统里决策、记忆、执行、反馈这四个环节是怎么咬合的模型只是其中一环接口只是执行层的一个通道。真正区分一个人有没有Agent实战经验的是他能不能说清楚“模型在什么情况下会做出错误决策以及系统怎么兜住这个错误”。这个标题之所以扎心是因为它戳中了一个普遍现象大量教程把Agent简化成了“LLM Tools”的公式导致很多人以为会调几个API就等于会做Agent。但实际项目里模型加接口连最小可用系统都算不上。你还需要考虑状态管理、错误恢复、上下文压缩、工具编排、权限控制、可观测性——这些东西没有一个是模型或接口本身能解决的。这篇文章适合两类人一是正在准备Agent相关面试、想搞清楚面试官到底在考察什么的开发者二是已经动手做过Demo但总觉得系统“不太稳”、想弄明白差在哪里的工程师。我会从面试考察逻辑出发拆解Agent系统的真实架构补充大量实操中才会遇到的细节帮你把“模型加接口”这个答案升级成一套完整的工程认知。2. 为什么“模型加接口”这个答案会被扣分2.1 这个答案暴露了哪三个认知盲区第一个盲区是把Agent等同于一次模型调用。很多人描述Agent时脑子里想的是用户输入→模型判断→调用工具→返回结果。这是一条直线但真实Agent是一个循环。它需要根据执行结果决定下一步可能重试、可能换工具、可能放弃并请求人工介入。没有循环就只是一次带工具调用的推理。第二个盲区是忽略了状态的存在。模型本身是无状态的每次调用都是独立的。但Agent需要记住之前做了什么、失败了什么、当前进度在哪。这些状态存在哪里、怎么组织、怎么在上下文窗口里压缩是工程上的核心问题。面试官问“你的Agent怎么处理多轮任务”其实就是在问状态管理。第三个盲区是没有错误处理的概念。接口会超时、会返回格式错误、会权限不足。模型也会幻觉会调用不存在的工具会陷入死循环。一个只有“模型加接口”的系统遇到这些情况直接崩溃。而真实Agent必须有重试策略、降级方案、熔断机制和人工兜底通道。面试官听到“模型加接口”时心里的判断是这个人没有经历过Agent系统在生产环境里跑起来的痛苦不知道哪里会出问题。2.2 面试官真正在考察的能力维度从我跟一些面试官交流的经验看问Agent问题时他们通常在四个维度上打分。系统设计能力你能不能画出一个完整的Agent架构图说清楚每个模块的职责和交互方式。这包括任务规划、工具注册与发现、上下文管理、执行引擎、结果校验等。边界意识你知不知道模型的能力边界在哪里什么任务适合交给Agent什么任务不适合什么时候该让模型自主决策什么时候该用规则硬编码这种判断力比会调API重要得多。故障处理经验你有没有遇到过工具调用失败、模型输出格式错误、任务陷入循环这些情况你是怎么发现和解决的这些细节骗不了人做过就是做过。权衡取舍Agent系统里到处都是取舍。用大模型还是小模型上下文全量保留还是压缩工具粒度粗还是细每一步选择都有代价面试官想听的是你为什么这么选。2.3 一个真实面试场景的拆解假设面试官问“如果让你设计一个能自动处理客服工单的Agent你会怎么做”答“模型加接口”的人会说用大模型理解工单内容然后调用工单系统的API进行分类和回复。这个答案的问题在于工单可能包含多个问题需要拆解分类可能涉及权限判断回复可能需要查知识库如果模型不确定需要转人工工单系统API可能失败需要重试处理过程中需要记录日志供审计。这些都没有覆盖。而一个有经验的回答会先问清楚工单来源是什么分类体系有多少类回复是自动发送还是人工审核知识库的更新频率如何然后给出一个包含意图识别、任务拆解、工具编排、置信度判断、人工兜底、全链路日志的方案。两者的差距就是“会用模型”和“会做Agent”的差距。3. 一个Agent系统真正需要哪些模块3.1 任务规划与拆解层模型加接口的第一个缺口就是没有规划层。用户给一个复杂任务比如“帮我分析上个月的销售数据并生成报告”模型直接调一个数据分析接口是搞不定的。它需要先拆解第一步获取数据第二步清洗第三步计算指标第四步生成图表第五步撰写文字。每一步的输出是下一步的输入中间任何一步失败都要有应对。规划层的实现方式有好几种。最简单的是静态工作流把步骤写死在代码里模型只负责每一步的具体执行。这种方式稳定但不够灵活。进阶一点的是动态规划让模型根据任务目标自己生成步骤列表然后逐步执行。这种方式灵活但容易跑偏需要加约束。我在实际项目里更倾向于混合模式用规则定义必须执行的骨架步骤在骨架内部允许模型自主决定具体操作。比如数据分析任务获取数据和生成报告是固定步骤但中间用什么方法清洗、算哪些指标可以让模型根据数据特征自己判断。这样既保证了流程可控又保留了一定的灵活性。规划层还有一个容易被忽略的点步骤的粒度。拆得太粗模型一步搞不定拆得太细调用次数爆炸成本和延迟都上去了。我的经验是每个步骤应该是一个模型能在一次调用中完成、且输出可以被明确验证的单元。如果一步的输出无法判断对错说明拆得不够细。3.2 记忆与上下文管理这是“模型加接口”答案里几乎不会提到的部分但它是Agent能不能处理长任务的关键。模型的上下文窗口有限一个跑了二十步的任务历史信息早就超了。你需要决定哪些信息保留哪些压缩哪些丢弃。我一般把记忆分成三层。短期记忆是当前任务的执行轨迹包括每一步的输入输出和状态通常保留最近几轮更早的做摘要压缩。长期记忆是跨任务的知识比如用户偏好、常见问题的解决方案存在外部存储里需要时检索注入。工作记忆是当前步骤直接需要的上下文比如当前处理的文件内容、上一步的输出结果。上下文压缩是个技术活。简单截断会丢失关键信息全量保留会撑爆窗口。我试过几种方案用模型对历史做摘要、用向量检索只取相关片段、用结构化格式只保留关键字段。实测下来结构化摘要加关键字段保留效果最稳。比如每一步只保留“步骤编号、操作类型、输入摘要、输出摘要、状态”比让模型自由发挥写摘要要可靠得多。一个实用的技巧给上下文里的每条信息打上时间戳和优先级标签。当需要压缩时优先保留高优先级和最近的信息低优先级的旧信息直接丢弃。这个策略在长任务里能显著降低上下文占用。3.3 工具注册、发现与编排工具不是越多越好。我见过一个Agent注册了上百个工具结果模型选择困难经常调错。工具编排的核心是让模型在正确的时间看到正确的工具。我的做法是分组注册。按业务领域把工具分成若干组每次只把当前任务相关的组暴露给模型。比如处理订单问题时只暴露订单查询、退款、物流相关的工具不暴露用户管理、数据分析的工具。这样模型的决策空间小了准确率明显提升。工具描述也很关键。很多人写工具描述就一句话“查询订单”模型根本不知道什么时候该用。好的描述应该包含这个工具做什么、什么情况下用、输入参数的含义和格式、返回值的结构、可能的错误。描述越清晰模型调用越准确。编排层面除了让模型自主选择还可以加前置校验和后置校验。前置校验检查模型选的工具和参数是否合法不合法直接拦截并提示模型重新选择。后置校验检查工具返回的结果是否符合预期不符合就触发重试或降级。这两层校验能挡掉大部分低级错误。3.4 执行引擎与反馈循环执行引擎负责实际调用工具、处理返回、决定下一步。这里最核心的是反馈循环的设计。模型调用工具后结果怎么反馈给它是原样返回还是加工后再给我的经验是反馈给模型的结果要结构化、精简、带状态标记。比如工具返回了一大段JSON不要直接塞给模型而是提取关键字段加上“成功/失败”标记和错误码。模型看到精简后的结果更容易做出正确判断。反馈循环里还要处理重试和退避。工具调用失败时不能立刻重试要有退避策略。我一般用指数退避第一次等1秒第二次2秒第三次4秒最多重试三次。如果还失败就触发降级方案比如换备用工具、返回缓存结果、或者转人工。还有一个容易忽略的点循环检测。模型有时候会陷入“调用工具A→失败→重试A→失败”的死循环。执行引擎需要检测这种模式比如同一个工具连续失败三次就强制中断换策略或报错。没有这个机制Agent可能烧掉大量token还解决不了问题。4. 面试中如何把Agent话题答出深度4.1 用“分层架构”替代“模型加接口”当面试官问Agent怎么设计时不要从模型开始讲从分层架构开始讲。我会这样组织回答第一层是接入层负责接收请求、鉴权、限流、路由。第二层是规划层负责任务拆解和步骤生成。第三层是执行层负责工具调用和结果处理。第四层是记忆层负责状态存储和上下文管理。第五层是观测层负责日志、指标、追踪。然后说明模型在哪一层模型主要用在规划层和执行层的决策点但它不是系统的全部。接口在哪一层接口是执行层调用的通道但执行层还包括校验、重试、降级等逻辑。这样回答的好处是面试官能看到你有全局视角知道每个模块的职责和边界。而且这个架构不是背出来的是你真正理解系统后的自然表达。4.2 主动暴露你踩过的坑面试里最加分的不是你说自己做了什么而是你说自己做错了什么、怎么发现的、怎么修的。这比任何架构图都有说服力。比如你可以说“我早期做的Agent没有循环检测结果有一次模型陷入死循环十分钟烧掉了几十万token。后来我加了连续失败计数和强制中断同一个工具失败三次就切换策略。这个教训让我意识到Agent系统里模型不是最不可控的执行引擎的约束才是关键。”或者“我一开始把工具返回的原始JSON直接给模型发现模型经常解析错字段。后来我加了一层结果格式化只提取关键字段并加上状态标记准确率提升了很多。这个细节看起来小但对系统稳定性影响很大。”这种回答传递的信息是你真正跑过系统遇到过问题并且有解决问题的能力。这是“模型加接口”答案完全给不出的。4.3 展示你对成本和延迟的敏感度Agent系统在生产环境里成本和延迟是绕不开的。面试官如果问你“怎么优化”不要只说“用更小的模型”或“加缓存”要具体。我会从三个层面回答。规划层能静态拆解的步骤不要动态生成减少模型调用次数。执行层简单判断用规则复杂判断才用模型工具结果能缓存的缓存避免重复调用。记忆层上下文压缩要激进不必要的历史信息及时丢弃减少token消耗。延迟方面并行化是最大的优化点。多个独立的工具调用可以并行执行不用串行等待。比如同时查订单和查物流两个接口并行调总延迟取决于最慢的那个而不是两者之和。这个优化在实操中效果非常明显。面试官如果追问“怎么衡量Agent系统的好坏”你可以从任务完成率、平均步骤数、工具调用准确率、人工介入率、单任务成本这几个指标来回答。这些指标比“准确率”一个词要专业得多。5. 从Demo到生产Agent系统落地的几个关键决策5.1 模型选型不是越大越好做Demo时用最强的模型没问题但上生产就要考虑成本和延迟。我的经验是分级使用规划层用强模型因为任务拆解需要较强的推理能力执行层的简单判断用小模型甚至规则结果校验用规则或小模型。具体怎么分我会先跑一批真实任务统计每个环节的模型调用次数和token消耗。然后看哪些环节的模型输出可以被规则替代哪些环节换小模型后准确率下降不明显。通常执行层有大量调用是“格式化输出”或“简单分类”这些用小模型完全够用。还有一个决策是用通用模型还是微调模型。如果任务领域很垂直比如只处理特定类型的工单微调一个小模型可能比通用大模型效果更好、成本更低。但微调需要标注数据前期投入大。我的建议是先用通用模型跑通流程积累数据后再考虑微调。5.2 工具粒度粗一点还是细一点工具粒度是个权衡。粒度粗模型调用次数少但每个工具的逻辑复杂出错后难定位。粒度细模型调用次数多但每个工具职责单一容易测试和维护。我倾向于中等粒度一个工具对应一个完整的业务操作而不是一个技术步骤。比如“查询订单状态”是一个工具而不是“连接数据库”“执行查询”“格式化结果”三个工具。这样模型调用次数可控每个工具也有明确的业务含义。但有些情况需要细粒度。比如一个操作需要用户确认才能执行那“准备操作”和“执行操作”就要拆成两个工具中间插入确认环节。再比如一个操作可能失败需要重试拆成细粒度后重试范围更小不会重复执行已经成功的部分。5.3 人工兜底什么时候必须让人介入Agent不是全自动的至少在生产环境里不是。必须设计人工介入的触发条件。我的经验是三类情况必须转人工置信度低于阈值、涉及敏感操作、连续失败超过限制。置信度怎么来可以让模型在输出时附带置信度评分也可以用规则判断比如模型输出格式不符合预期、工具返回了异常状态码。敏感操作包括退款、删除数据、修改权限等这些操作即使模型很确定也应该让人确认。人工介入的体验也很重要。不能只给人工一个“任务失败”的通知要把完整的执行轨迹、当前状态、失败原因、建议操作都展示出来。人工处理完后结果要能回写到Agent系统里让Agent继续后续步骤。这个闭环设计不好人工兜底就会变成人工重做。5.4 可观测性出了问题怎么查Agent系统最怕的是出了问题不知道哪里出的。模型输出不可解释工具调用链路长没有可观测性根本没法排查。我一般会记录四类数据。调用日志每次模型调用和工具调用的输入输出、耗时、状态。决策轨迹模型每一步的决策理由可以让模型输出思考过程。状态快照每个步骤执行后的系统状态方便回放。指标聚合任务完成率、平均步骤数、工具调用成功率、人工介入率等。这些数据不只是用来排查问题还能用来优化系统。比如分析哪些工具调用经常失败哪些步骤模型经常决策错误然后针对性改进。没有这些数据优化就是拍脑袋。6. 几个容易被追问的Agent细节问题6.1 模型输出格式不稳定怎么办这是高频问题。模型有时候返回JSON有时候返回带解释的文字有时候字段名都对不上。我的处理方式是三层防护。第一层是提示词约束在系统提示里明确输出格式给出示例强调“只输出JSON不要有其他内容”。第二层是输出解析器用代码解析模型输出如果解析失败尝试提取JSON片段再失败就触发重试。第三层是重试提示重试时把解析错误的信息反馈给模型让它修正格式。实测下来这三层能解决95%以上的格式问题。剩下的5%通常是模型能力不足或任务本身模糊这种就需要换模型或重新设计任务。6.2 工具调用参数错误怎么处理模型经常传错参数比如该传数字传了字符串该传枚举传了自由文本。处理方式和格式问题类似前置校验加反馈重试。前置校验用JSON Schema定义每个工具的参数格式模型输出后先校验不通过就不执行直接把校验错误反馈给模型让它重新生成。反馈时要具体比如“参数order_id应该是字符串你传了数字”而不是笼统说“参数错误”。如果重试多次仍然错误就要考虑是不是工具描述不够清晰或者模型能力不够。这时候可以简化工具参数把复杂参数拆成多个简单参数或者换更强的模型。6.3 多轮对话里Agent怎么保持一致性多轮对话里用户可能中途改变需求或者补充信息。Agent需要能识别这些变化并调整执行计划。我的做法是每轮对话都重新评估任务状态。具体来说每轮用户输入后先把当前执行状态和用户新输入一起给模型让模型判断是继续当前任务还是修改计划还是开始新任务。这个判断本身也是一次模型调用但能避免Agent“一根筋”地执行旧计划。状态同步也很重要。如果用户修改了某个参数Agent需要更新状态里的对应字段并且检查后续步骤是否受影响。比如用户改了收货地址那物流相关的步骤都要用新地址重新执行。这种依赖关系的管理是Agent系统里比较复杂的部分需要仔细设计状态结构。6.4 Agent的测试怎么做Agent的测试比传统软件难因为输出不确定。我的策略是分层测试。单元测试测每个工具的功能这个和普通函数测试一样。集成测试测固定输入下的执行轨迹不要求最终输出完全一致但要求关键步骤和工具调用符合预期。评估测试用一批真实任务跑端到端统计任务完成率和人工介入率这个需要人工标注或人工评估。评估测试里我会特别关注失败案例。分析失败是因为模型决策错误、工具问题、还是任务本身超出能力范围。这些分析结果直接指导优化方向。没有评估测试Agent的迭代就是盲目的。7. 我在实际项目里总结的几条经验做Agent系统这几年踩过的坑比写过的代码还多。有几条经验我觉得比任何架构图都值钱。第一条先跑通再优化但别在Demo阶段就埋雷。很多人做Demo时图快状态管理用内存、错误处理直接抛异常、日志随便打。结果要上生产时发现到处都要改。我的建议是Demo阶段可以简化但状态存储、错误处理、日志记录这三个基础能力一开始就要有哪怕实现很简单。后面替换实现比从零加要容易得多。第二条模型的输出永远要当作不可信输入。不管模型多强它的输出都要经过校验才能使用。参数校验、格式校验、业务规则校验一层都不能少。我见过太多因为信任模型输出而导致的事故比如模型生成了不存在的订单号直接去查结果报错模型把金额算错了直接提交造成损失。校验的成本远低于出错的成本。第三条上下文管理是Agent系统里最容易被低估的部分。很多人把精力花在模型选型和工具开发上上下文管理随便做做。结果任务一长就出问题要么上下文超限要么关键信息丢失要么模型被无关信息干扰。我的经验是上下文管理要像数据库设计一样认真对待定义清楚什么信息存哪里、怎么检索、怎么压缩、怎么过期。第四条可观测性不是可选项。Agent系统出问题时没有日志和追踪根本没法排查。我一般会在项目第一天就搭好日志和指标采集哪怕只是简单的文件日志。后面再接入更专业的观测工具。这个投入在排查问题时回报巨大。第五条人工兜底不是失败是设计的一部分。不要追求100%自动化那既不现实也不安全。把人工介入设计成系统的一个正常环节而不是异常处理。这样系统更稳用户也更放心。最后说一个面试技巧如果面试官问Agent你可以先反问一句“您是想了解Agent的架构设计还是具体某个环节的实现”这样既能展示你对Agent有全局认知又能把问题聚焦到你最擅长的部分。面试官通常会顺着你的问题走你就掌握了主动权。这个技巧我用过几次效果都不错。