你目前主要靠什么方式来准备AI Agent面试？效果怎么样？
你目前主要靠什么方式来准备AI Agent面试？效果怎么样？
面试AI Agent岗位，如果还在死记硬背那几套经典的ReAct架构图，其实已经有点跟不上现在的节奏了。
我去年底开始陆续面了几家做Agent方向的公司，有大厂也有创业团队，踩了不少坑，也慢慢摸出了一些门道。说说我的准备方法，不一定适合所有人，但确实在几轮面试里帮我拿到了不错的反馈。
我把准备的内容拆成了三个板块：架构、开发、运维。不是为了分类而分类，是因为面试官问的问题基本也是沿着这条线走的——你怎么设计、怎么落地、上线之后怎么管。
一、Agent架构：重点不是"画图"，是讲清楚取舍
很多人准备架构部分，喜欢把ReAct、Plan-and-Execute、LATS这些范式背一遍，面试的时候画个流程图。坦白说，这个在一年前可能还行，现在大部分面试官自己天天在用这些东西，你画的图他比你还熟。
面试官真正想听的，是你在实际场景里做过什么选择，以及为什么。
举个例子，我之前做过一个客服场景的Agent，一开始用的是比较标准的ReAct循环——LLM思考、调用工具、观察结果、再思考。跑通了，但上线之后发现一个严重问题：用户问一个稍微复杂点的问题（比如"帮我查一下上个月的订单，然后把有问题的那几笔申请退款"），Agent经常在中间某一步跑偏，要么重复调用同一个API，要么干脆幻觉出一个不存在的工具名。
后来我们改成了两层架构：上层一个Planner负责拆解任务生成执行计划，下层多个专项Worker各管一块（查询、退款、通知）。Planner不直接调工具，只负责编排；Worker拿到子任务之后，在一个受限的工具集里执行。
这个改动说起来简单，但面试的时候我会把"为什么不一开始就用这个方案"讲清楚——因为两层架构的延迟是更高的，每一步都要多一次LLM调用，在简单问题上反而过度设计了。所以我们最终的方案是做了一个路由层，先对用户意图做分类，简单问题走单步ReAct，复杂问题才走Planner-Worker。
这种回答思路，比你把论文里的架构图背一遍有用得多。面试官想看到的是你有在真实约束条件下做权衡的能力——延迟、成本、准确率，这三个东西永远在打架，你得说清楚你优先保哪个，为什么。
还有一个经常被问到的点是多Agent协作。这个方向最近很火，但我建议准备的时候别光讲概念，要准备一个"多Agent协作翻车然后你怎么修的"案例。比如我们试过让两个Agent互相review对方的输出来提升质量，结果发现它们很容易陷入"互相客气"的死循环——A说"你的方案很好，我补充一点"，B说"你的补充很好，我再完善一下"，来回几轮啥实质性修改都没有，token倒是烧了不少。最后我们加了一个裁判机制，限定了最大轮次，并且在prompt里明确要求"必须指出对方方案的具体缺陷"才能继续对话。
这种踩坑-修复的故事，比你把CrewAI的文档背一遍管用得多。
二、Agent开发：面试官关心的不是你用什么框架
开发这块，我发现一个规律：越是大厂，越不关心你用的是LangChain还是LlamaIndex还是自研框架。他们关心的是你解决具体工程问题的能力。
工具调用（Function Calling）的鲁棒性，是被问得最多的。面试官通常不会直接问"你怎么做Function Calling"，而是给你一个场景，比如"用户说帮我订明天下午三点到五点的会议室，要带投影仪的"，让你设计工具调用的流程。
这里面的坑很多。时间解析就是一个，"明天下午三点"到底是哪个时区的？如果Agent运行在服务端，系统时间是UTC，用户在东八区，这个不处理就会出错。还有参数校验的问题——LLM生成的JSON参数并不总是合法的，我们踩过一个坑是模型偶尔会把数字类型的参数生成为字符串（比如把 3 写成 "3"），下游API直接报400。
我准备面试的时候，专门整理了一套"工具调用的防御性编程清单"：参数类型强校验、必填字段检查、枚举值范围约束、超时和重试策略、调用结果的结构化校验。面试时不用全讲，但当面试官追问的时候，你能一条一条展开，这个印象分是很高的。
Prompt工程这块，面试官的问法也在变。之前可能问你"怎么写一个好的prompt"，现在更多是问"你怎么管理和迭代prompt"。因为在实际项目里，prompt不是写一版就完事的，它会跟着业务需求、模型版本、用户反馈不断调整。
我自己的做法是把prompt当代码管理——用版本控制，每次修改有对应的评测数据集跑回归，评测不过不上线。这个听起来是常识，但很多团队真的就是在代码里直接hardcode一个字符串，改prompt跟改配置似的，完全没有质量门禁。面试时你能讲出一套prompt生命周期管理的实践，是很加分的。
另一个高频考点是RAG（检索增强生成）。这个方向几乎所有做Agent的团队都在用，但面试官的问题已经从"RAG是什么"升级到了"你的RAG pipeline里，召回率和准确率怎么平衡的"，或者"chunk size怎么定的，你试过哪些分块策略，效果差别有多大"。
我的经验是，准备RAG相关的问题，一定要带数据说话。比如我们在某个项目上试过三种分块策略：固定长度（512 token）、按段落分割、按语义相似度聚类。固定长度最简单但边界切割问题严重，经常把一句话切成两半；按段落分割效果好一些但对非结构化文档（比如扫描件OCR出来的文本）不友好；最终我们用的是语义分块，先用embedding模型算相邻句子的相似度，相似度断崖处作为分割点。最终在我们的评测集上，召回率从72%提升到了85%。
你看，有数据的回答和没数据的回答，说服力完全不一样。
三、Agent运维：这是大部分候选人的盲区
很多人准备面试只准备"怎么做"，不准备"上线之后怎么管"。但现在越来越多的面试官会问运维相关的问题，因为Agent系统跟传统后端服务不一样——它的行为是非确定性的，同样的输入可能产生不同的输出，这给监控和排错带来了很大的挑战。
可观测性（Observability） 是第一个要准备的。传统服务监控看CPU、内存、QPS就够了，Agent系统还得监控一些特有的指标：每次请求的LLM调用次数（衡量Agent是不是在"打转"）、工具调用成功率、单次会话的token消耗量、端到端的任务完成率。
我们线上有一个告警规则：如果单次用户请求的LLM调用次数超过8次，就触发告警。为什么是8次？因为我们分析了历史数据，正常的业务流程最多需要5-6次LLM调用，超过8次基本就是Agent陷入循环了。这个数字不是拍脑袋定的，是从线上数据统计出来的。面试时你讲这种"从数据出发定阈值"的思路，比讲一堆理论有说服力。
成本控制也是面试常问的。Agent系统的成本结构跟传统服务差别很大，大头在LLM API调用费用上。我们做过一个优化：对Agent的中间推理步骤用较便宜的小模型（比如GPT-4o-mini），只在最终面向用户的输出用大模型。这一个改动就把单次会话的平均成本降了40%左右，而用户体感上几乎没有差别，因为中间的推理步骤用户根本看不到。
还有一个经常被忽略的点是安全和合规。Agent能调用工具，就意味着它能操作外部系统。面试官可能会问你："如果Agent被恶意prompt注入，执行了不该执行的操作，你怎么防？"这个问题我建议从两个层面回答：一是设计层面，给Agent的工具调用加权限控制，高危操作（比如删除数据、发起支付）必须经过人工审批或二次确认；二是运行时层面，做输入输出的安全过滤，对已知的注入模式做检测，对工具调用的参数做合规性校验。
灰度发布和A/B测试也值得准备一下。Agent系统的更新不像传统服务改个接口那么简单——你改了prompt，可能所有用户的体验都变了。我们的做法是把prompt版本和用户流量绑定，新版本先对5%的流量生效，跑一到两天，看核心指标（任务完成率、用户满意度评分、平均token消耗）没有回退，再逐步放量。这套流程听起来平平无奇，但我面试时发现很多候选人根本没想过这个问题——他们觉得改prompt就是在代码里改个字符串，部署一下就完了。
总结一下我的准备方法
说白了就是三件事：
第一，带着场景准备，不要孤立地背概念。 每个知识点都要能挂到一个具体的业务场景上，最好是你自己做过的。没做过的话，至少要把一个开源项目跑通，自己造一些场景，积累一些真实的踩坑经验。
第二，准备有数据的案例。 "我们做了优化，效果变好了"这种话谁都会说。但如果你能说"召回率从72%到85%"、"单次会话成本降了40%"、"LLM调用次数从平均12次降到5次"，面试官对你的判断力和工程能力的信任度会高很多。
第三，不要忽略运维。 架构和开发大家都会准备，运维是拉开差距的地方。你能讲清楚Agent系统上线之后的监控、告警、灰度、成本控制、安全策略，说明你不只是"能做demo"，而是"能把系统养活"。
以上是我个人的经验，不是什么标准答案，不同公司的侧重点也不一样。但这个三板块的框架，至少能保证你在面试时不会有明显的盲区。