1. 面试官到底在问什么1.1 一个被答烂了的标准错误面到 Agent 相关岗位的人十个里有八个会给出同一个答案Agent 就是大模型加一套工具接口模型负责思考接口负责执行循环调用直到任务完成。这个回答不算错但它停留在 2023 年。面试官听到这句话基本会判定你只停留在调用 API 的层面没真正做过需要长期运行、需要状态管理、需要多步决策的系统。我面过不少人也被人面过。真正让面试官眼睛一亮的回答往往不是把定义背得多完整而是能说清楚 Agent 和模型加接口之间那道鸿沟到底在哪。这道鸿沟不是概念上的是工程上的状态怎么存、失败怎么恢复、上下文怎么裁剪、工具调用结果怎么验证、多个 Agent 之间怎么协调。这些才是面试官想听的。所以这篇文章不打算给你一个标准答案让你背。我想做的是把这道题拆开告诉你面试官问这句话时脑子里在想什么以及一个真正做过 Agent 系统的人会怎么组织自己的回答。内容会涉及架构设计、状态管理、上下文工程、工具编排、评估体系这几个层面每个层面我都会给出可以落地的思路和踩过的坑。1.2 面试官真正想考察的三层能力把Agent 是什么这个问题拆开面试官其实在同时考察三层东西。第一层是概念边界。你能不能区分 Agent、Workflow、Chain 这几个经常被混用的词。很多人把 LangChain 的 Chain 叫 Agent把固定的多步流程也叫 Agent这在工程上会造成很大的沟通成本。一个合格的回答应该能说清楚Workflow 是路径预先确定的Agent 是路径在运行时由模型决定的。第二层是工程实现。你知不知道一个能跑起来的 Agent 需要哪些组件。不是模型加接口这么简单至少还包括状态存储、上下文管理、工具注册与发现、错误处理与重试、执行轨迹记录。这些组件缺一个系统在真实场景下就会出问题。第三层是权衡判断。你知不知道什么时候不该用 Agent。这是最容易被忽略的一层。很多人学了 Agent 就想 everywhere 用 Agent结果把一个本来用规则引擎就能解决的问题复杂化。面试官如果听到你能主动说出这个场景其实不适合用 Agent反而会觉得你有判断力。三层能力对应三种回答深度。只答第一层是及格答到第二层是良好三层都能答是优秀。下面我按这个框架展开把每一层该说什么、怎么说清楚。2. 概念边界Agent、Workflow、Chain 到底怎么分2.1 用谁来决定下一步来切分区分这几个概念最有效的一个问题是下一步做什么是谁决定的如果下一步是代码里写死的那就是 Workflow。比如先调 A 接口拿到结果后调 B 接口最后格式化输出路径完全确定模型只是其中某一步的一个函数。这种系统稳定、可预测、好调试能用 Workflow 解决的绝对不要上 Agent。如果下一步是模型在运行时根据当前状态决定的那就是 Agent。比如用户问了一个问题我需要判断是查数据库、搜文档还是直接回答这个判断由模型做路径不固定。Agent 的核心特征就是运行时决策。Chain 这个词更偏实现层面指的是把多个组件串起来的编程抽象。一个 Chain 可以是 Workflow 的一部分也可以是 Agent 的一次执行。它是个中性词不描述决策方式。我一般会用一个类比Workflow 是地铁路线固定每站都停Agent 是出租车目的地定了但走哪条路司机现场判断。面试时把这个类比说出来面试官立刻知道你分得清。2.2 为什么这个区分在工程上很重要有人会觉得这是抠字眼其实不是。这个区分直接决定了你的系统怎么设计、怎么测试、怎么运维。Workflow 的测试是确定性的给定输入路径固定输出应该固定。你可以写单元测试覆盖每条路径。Agent 的测试是概率性的同样的输入模型可能走不同的路输出可能不一样。你不能用传统测试方法得用评估集加统计指标。Workflow 的失败是局部的某一步挂了重试那一步就行。Agent 的失败是全局的模型可能陷入循环、可能选错工具、可能在中途丢失目标。你需要额外的机制来检测和纠正。Workflow 的成本是可估算的路径固定调用次数固定。Agent 的成本是波动的模型可能三步搞定也可能绕十步。你需要设置预算上限和提前终止条件。所以当面试官问你怎么理解 Agent你如果能顺势说出这些工程差异就已经超过大多数候选人了。这不是背概念是展示你知道这个概念在真实系统里意味着什么。2.3 一个常见的边界模糊场景实际工作中最麻烦的是介于两者之间的场景。比如一个客服系统大部分问题走固定流程查订单、查物流、退款少部分开放问题需要模型自由发挥。这种系统怎么归类我的做法是分层外层用 Workflow 做路由把明确意图的问题分发给对应的固定流程只有路由不出来的问题才交给 Agent 处理。这样既保证了常见场景的稳定性和低成本又保留了处理长尾问题的能力。面试时如果被问到这类场景能说出不是非此即彼而是分层组合会显得你有实战经验。纯理论的人往往会把 Agent 和 Workflow 对立起来做过的人知道它们经常一起用。3. 工程实现一个能跑的 Agent 需要哪些组件3.1 状态管理Agent 的记忆到底存在哪模型加接口这个说法最大的漏洞就是没有状态。模型是无状态的每次调用都是独立的。但 Agent 要完成多步任务必须记住之前做了什么、拿到了什么结果、当前目标是什么。这些状态存在哪、怎么组织是 Agent 工程的核心问题。状态大致分三类。对话历史是最直观的就是用户和 Agent 的往来消息。执行轨迹是 Agent 自己的动作记录调了哪些工具、参数是什么、返回什么。任务状态是更高层的当前处于哪个阶段、还剩哪些子目标没完成。存储上短期状态一般放在内存或会话缓存里长期状态要落库。我见过不少项目把全部历史塞进上下文窗口跑几轮就爆了。正确做法是分层近期消息保留原文远期消息做摘要执行轨迹只保留关键节点任务状态用结构化字段存。这里有个实操心得执行轨迹一定要带时间戳和唯一 ID。Agent 出问题时你唯一能依靠的就是回放轨迹。没有 ID 你连哪次调用出的错都定位不了。我踩过这个坑一个线上 Agent 偶尔返回错误结果查了两天才发现是某次工具调用超时后模型基于空结果继续推理如果有完整的轨迹记录半小时就能定位。3.2 上下文工程比 Prompt 工程更重要的东西很多人把精力全花在写 Prompt 上忽略了上下文工程。Agent 场景下上下文工程比 Prompt 工程重要得多因为 Agent 的上下文是动态增长的怎么在有限窗口里塞进最有用的信息直接决定系统能不能跑。核心手段有三个。裁剪按相关性排序只保留 top-k 的历史消息。摘要把长段历史压缩成短摘要牺牲细节换空间。检索不把所有历史都放进去需要时再从外部存储里捞。裁剪的关键是相关性怎么算。简单做法是按时间倒序但 Agent 场景下早期的一条关键指令可能比最近的寒暄重要得多。我的做法是给每条消息打标签指令、结果、闲聊指令类永远保留结果类按时间衰减闲聊类优先裁掉。摘要的坑在于摘要会丢信息。模型摘要时可能把关键参数漏掉导致后续步骤失败。我的经验是摘要只用于对话历史执行轨迹和任务状态永远保留原文因为这两类信息精度要求高压缩的代价太大。检索的坑在于检索本身要花时间。如果每步都去检索延迟会很高。折中方案是只在上下文接近上限时才触发检索平时靠裁剪和摘要顶着。3.3 工具注册与发现接口不是越多越好模型加接口里的接口很多人理解成有多少工具就注册多少。这是个大坑。工具太多模型选择困难容易选错工具描述太长占满上下文工具之间有重叠模型分不清该用哪个。正确做法是分层注册加动态发现。核心工具比如搜索、计算、读写文件常驻注册保证随时可用。领域工具按场景分组根据当前任务动态加载。比如用户问的是数据分析就加载数据处理相关的工具不加载图像处理的。工具描述也有讲究。描述要写清楚什么时候用和什么时候不用而不只是功能。比如一个发送邮件工具描述里要写明当用户明确要求发送通知时使用不要用于草稿保存。我见过太多工具描述只写功能结果模型在不该用的时候用了。还有一个细节工具返回结果要结构化。返回一大段自然语言模型还得再解析一遍既慢又容易出错。返回 JSON 或者带明确字段的结构模型能直接提取。这个改动看起来小实测能显著降低工具调用的错误率。3.4 错误处理与重试Agent 最容易翻车的地方Agent 和普通程序最大的区别是它的每一步都可能以多种方式失败。工具超时、返回格式不对、模型选错工具、陷入循环每一种都要有对应的处理策略。工具超时最简单设个超时时间超了就重试重试几次还不行就返回错误让模型决定下一步。返回格式不对要加校验层校验不过就把错误信息回传给模型让它重新调用。模型选错工具比较麻烦通常靠 Prompt 里写清楚工具边界来预防真出错了就在轨迹里标记下次遇到类似情况时把这次错误作为反例放进上下文。最危险的是陷入循环。模型反复调用同一个工具或者在不同工具间来回跳永远不收敛。检测方法是设一个步数上限超过就强制终止。但步数上限设多少有讲究设太小复杂任务做不完设太大出问题时浪费大量调用。我的经验是按任务类型设不同上限简单查询 5 步复杂分析 20 步同时监控实际步数分布动态调整。提示错误处理里最容易被忽略的是部分成功的情况。比如一个任务需要调三个工具前两个成功第三个失败这时候不能简单重试整个任务否则前两个会重复执行。正确做法是记录已完成步骤只重试失败的那一步。4. 权衡判断什么时候不该用 Agent4.1 能用规则解决的别上模型这是我最想强调的一点。Agent 很强大但强大是有代价的延迟高、成本高、不确定性高、调试难。如果一个问题的解决路径是确定的用规则引擎或者固定 Workflow 就好又快又稳又便宜。判断标准很简单如果让你手写 if-else 能覆盖 90% 的情况就别用 Agent。比如表单校验、固定格式转换、简单的条件路由这些用代码写死比让模型判断靠谱得多。我见过一个项目用 Agent 来判断用户输入是查询还是修改其实就是一个关键词匹配的事。结果模型偶尔判断错还得加一堆 Prompt 来纠正最后改回规则匹配问题消失。这个教训是不要用概率工具解决确定性问题。4.2 延迟敏感的场景要慎重Agent 的多步决策意味着多次模型调用每次调用都有延迟。如果用户场景要求秒级响应Agent 可能就不合适。比如实时客服的自动回复用户等三秒就烦了而 Agent 走完一轮决策加工具调用可能就要五到十秒。这种场景更适合用检索加模板或者用一个小模型做快速分类只有复杂问题才升级到 Agent。如果非要在延迟敏感场景用 Agent有几个优化方向用小模型做路由大模型只处理复杂分支并行调用独立的工具缓存常见决策路径。但这些优化都有上限根本上还是要在体验和智能之间做取舍。4.3 高风险场景需要人在回路涉及资金、医疗、法律这类高风险场景Agent 不能全自动。不是技术做不到是责任没法承担。模型判断错了谁来负责这类场景的正确做法是Agent 做建议人做决策。Agent 把分析结果、推荐方案、置信度都摆出来由人确认后再执行。这样既利用了 Agent 的效率又保留了人的判断和责任。面试时如果能主动提到这一点会显得你有风险意识不是那种技术至上、不考虑后果的人。很多团队招 Agent 工程师最怕的就是招来一个什么都敢自动化的人。5. 面试实战怎么组织你的回答5.1 一个可参考的回答框架被问到你怎么理解 Agent时我建议按这个顺序组织先给一句精炼的定义点出运行时决策这个核心特征。然后主动区分 Agent 和 Workflow说明判断标准。接着展开工程实现挑状态管理、上下文工程、错误处理里的一两个点深入讲展示你做过。最后补一句权衡说明什么场景不该用 Agent。这个框架的好处是层次分明从概念到工程到判断正好对应面试官的三层考察。而且你有主动权可以引导面试官往你熟悉的点追问。时间上控制在两三分钟别一口气讲十分钟。讲完留个话头比如状态管理这块我踩过不少坑需要的话可以展开让面试官选择追问方向。5.2 常见追问和应对面试官大概率会追问。几个高频问题你怎么保证 Agent 不跑偏——答评估体系加运行时监控。评估集覆盖典型场景上线后监控执行轨迹发现异常路径就告警。多 Agent 怎么协调——答看场景。简单任务单 Agent 就够多 Agent 适合职责明确、需要并行或需要对抗性验证的场景。协调方式有中心调度和去中心协商两种各有取舍。成本怎么控制——答预算上限加模型分级。简单步骤用小模型复杂决策用大模型设总调用次数和总 token 上限超了就终止。怎么评估 Agent 好不好——答分两层。结果层看任务完成率和准确率过程层看步数、工具调用正确率、循环率。两层都要看只看结果会漏掉过程问题。5.3 别踩的表达雷区有几个说法面试时尽量别用。Agent 就是模型加工具——这是最容易被扣分的显得你理解浅。用了某某框架所以就是 Agent——框架只是实现手段不代表你懂原理。Agent 什么都能做——显得你没判断力不知道边界。还有一个隐性的雷区是只谈技术不谈场景。面试官问 Agent往往是想知道你能不能在真实业务里用好它。如果你全程只讲架构不讲落地会显得纸上谈兵。适当举一两个你处理过的具体场景哪怕简化过也比纯理论有说服力。6. 从面试题到真实系统6.1 面试答案和工程现实的差距面试时你可以把架构讲得很漂亮但真实系统里魔鬼在细节。我做过一个文档处理 Agent面试时讲起来就是模型读文档、调工具提取、汇总输出实际做的时候光文档格式不统一这一条就折腾了两周。真实系统的复杂度来自边界情况。空文档、超大文档、格式损坏的文档、内容矛盾的文档每一种都要单独处理。面试时不会问这些但工作中 80% 的时间花在这些地方。所以我的建议是面试回答里适当提一句实际落地时边界情况很耗精力既显得你有经验又给自己留了余地。别把话说太满说太满面试官一追问细节就露馅。6.2 一个简化但完整的落地思路如果让你从零搭一个 Agent我会这么起步先明确任务边界把能确定的部分用 Workflow 写死只把真正需要决策的部分留给 Agent。然后设计状态结构想清楚哪些状态要持久化、哪些可以丢。接着注册最小工具集先跑通主流程再逐步加工具。最后搭评估集用真实场景的样本测边测边调。这个顺序很重要。很多人一上来就搭复杂架构结果主流程都没跑通。先跑通再优化是 Agent 工程最实用的原则。6.3 持续迭代比一次做对更重要Agent 系统没有一次做对的。上线只是开始真正的功夫在迭代。收集执行轨迹分析失败案例针对性优化 Prompt、工具描述、状态结构。这个过程是持续的不是一次性的。我个人的体会是Agent 系统的质量提升曲线是阶梯式的改一堆东西可能没效果突然某个关键改动让整体上一个台阶。所以别指望线性优化要有耐心持续观察和调整。最后分享一个小技巧给 Agent 加一个解释模式让它每步决策时输出理由。这个理由平时不用但排查问题时极其有用。你能看到模型为什么选这个工具、为什么走这条路比看结果猜原因高效得多。这个功能开发成本很低但回报很高强烈建议加上。