这两年 AI Agent 方向的岗位已经从“招不到人”变成“面不完的人”。我跟身边做面试官的朋友聊了一圈大家最统一的反馈是简历上写 Agent 项目的人越来越多但能扛住三轮追问的少之又少。很多候选人把 Hugging Face 上的 demo 跑通了就敢写“精通 Agent 开发”结果一问 ReAct 循环的终止条件、工具返回结果怎么进上下文、多智能体之间怎么同步状态立刻卡壳。我自己过去半年密集面了十几家 LLM 应用公司从做 AI 客服的创业团队到搞企业级知识库的中型厂再到研究多智能体框架的大组几乎每一次面试都会在 Agent 相关的考点上过一遍。高频考点的重复率真的非常高。整理完之后我筛了一遍去掉那些纯粹聊行业趋势的虚题剩下的硬核考点其实就摆在一个闭环里概念、架构、工程、场景。这套题库覆盖了 90% 的高频考点不管是准备社招还是校招按这个清单去复习比漫无目的刷题高效得多。1. 先搞清楚方向AI Agent 面试到底在筛选什么1.1 从 JD 反推考点分布不要只看标题写“Agent 工程师”就觉得是纯算法岗。AI Agent 岗位的 JD 看起来五花八门但拆开看要求的核心能力高度集中对 LLM 的理解深度、工程落地的能力、架构设计能力以及业务场景的敏感度。我统计了一下自己面过的公司的 JD 关键词出现频率最高的是“大模型应用开发”“RAG”“LangChain 或类似框架”“多智能体”其次是“向量数据库”“提示词工程”“部署经验”。这意味着面试官真正关注的是你能不能把一个 Agent 从零搭起来、跑得稳、算得清成本而不是你会不会背几个新概念。很多候选人喜欢在简历里写“精通 AutoGPT”但现实中 AutoGPT 这种通用 Agent 在正式产品里基本没法直接用面试官听到这类描述反而会重点考察你对它局限性的理解。1.2 三个必须具备的底层认知第一个认知是 Agent 的本质是“循环”。LLM 本身是无状态的一次推理输出一个结果就结束了。Agent 要完成任务必须把“推理 → 行动 → 观察 → 再推理”这个循环跑起来。这是 ReAct 的核心也是面试中所有追问的起点。第二个认知是 Agent 的能力边界由工具决定。模型再聪明没有合适的工具就只能空谈。面试官一定会问“你给 Agent 设计了哪些工具”“工具描述怎么写的”“参数 Schema 怎么定义的”因为工具的质量直接决定 Agent 的实际效果。第三个认知是 Agent 的成本不只是 API 费用。一次 Agent 任务涉及多轮模型调用每轮都要携带系统提示词、历史对话、工具返回内容Token 消耗量是普通 Chat 场景的几十倍。不考虑成本优化的 Agent 项目在面试官眼里都是玩具。1.3 简历里最常见的三类“假 Agent”项目第一类是“只有工具调用没有循环”。很多项目只是让模型调了一次搜索 API然后生成回答这在面试官眼里只是 LLM API不是 Agent。第二类是“把 RAG 包装成 Agent”。RAG 是检索增强生成它的核心是召回和生成整个过程没有多步决策。如果连 RAG 和 Agent 的区别都说不清楚面试基本就凉了。第三类是“纯调包没有任何自研”。框架能帮你省时间但面试官问起框架内部的执行流程、钩子机制、上下文构建逻辑如果答不上来项目就会被判定为“会用但没有理解”。这也是为什么这套题库的第一部分先帮你把概念底子打扎实。2. 核心概念与原理题这 8 道题决定基础分2.1 Agent 与 LLM、RPA、ChatBot 的本质区别这是开场白级别的送分题但送分题架不住答不好。很多人的回答是“Agent 能用工具”这个答案太浅了。完整一点的说法是LLM 是纯粹的概率语言模型输入一段文本输出一段文本没有目标导向也没有行动能力。ChatBot 在 LLM 之上加了多轮对话的记忆但依然停留在“对话”这个层不会主动去执行一个任务。RPA 能执行流程化的操作但它不知道为什么要做也不能根据中间结果调整策略。Agent 则把这三者串起来了它有感知能力能接收环境反馈有规划能力能把目标拆成步骤有记忆能力能基于历史决策有行动能力能调用工具改变环境状态。用生活化的比喻来解释LLM 像一本百科全书你问它才答RPA 像一条流水线按预设程序走Agent 则像一个小团队负责人拆目标、定计划、派人干活、根据结果调整方案。2.2 Agent 的四大核心能力拆解面试官提完“什么是 Agent”大概率会接着问“Agent 的核心能力有哪些”。标准框架是感知、规划、记忆、行动。感知是这个循环的起点。对 LLM 而言感知就是把环境信息映射成文本输入比如把数据库查询结果、网页内容、用户反馈都转成模型能理解的文本。规划是 Agent 和普通程序最不一样的地方。简单场景用单步决策遇到复杂任务就需要任务分解比如把“写一篇行业分析报告”拆成“收集数据→分析趋势→撰写大纲→逐段生成→检查引用”。这里面试官会追问“如果任务分解错了怎么办”所以你要提到重规划Re-plan机制执行过程中发现子任务无法完成要回到规划层重新拆分。记忆分短期和长期。短期记忆是当前任务窗口内的对话和中间状态长期记忆是跨会话存储的历史经验和知识通常用向量数据库存 embedding需要时做相似度检索。记忆这块延伸问法很多后面专门展开。行动就是调用工具。但行动不只是“调 API”还包括行动的可靠性工具调用超时怎么办、返回结果格式异常怎么办、工具本身执行了但结果不符合预期怎么办。这些在真实项目里比模型选型更折磨人。2.3 ReAct、Plan-and-Execute、Reflexion 架构横向对比这道题几乎是必考而且面试官会要求你边讲边画流程。不要用 mermaid直接在白板上画圈就能说清楚。ReAct 是 Reason Act 交替进行的模式模型在“思考”和“行动”之间循环拿到问题 → 思考需要什么信息 → 调用工具 → 观察结果 → 继续思考直到得出最终答案。它的优点是灵活适合工具调用密集、需要边做边看的场景缺点是轮次不可控任务复杂时容易陷入死循环。Plan-and-Execute 的思路是先规划后执行模型先把整体任务拆成步骤清单然后一步步执行步骤之间可以有先后或并行关系。它的优点是 Token 消耗相对可控因为不需要每轮都重新推理整体计划缺点是一旦计划有误后续执行全跑偏必须有纠错机制。Reflexion 是让 Agent 对自己的失败进行反思把错误原因整理成文本存到记忆里下次类似任务不再犯同样的错。面试时提这个架构能加分因为说明你考虑到了 Agent 的自我进化而不仅仅是执行任务。这三个架构不是互斥的生产环境里通常是组合使用用 Plan-and-Execute 拆分大任务每个子任务内部用 ReAct 做工具调用再引入 Reflexion 做失败复盘。我在实际项目中就是这样搭的。2.4 记忆机制短期、长期与向量检索面试问答记忆是 Agent 面试里最容易暴露水平的一道题因为它牵扯到工程细节。短期记忆的核心是上下文窗口管理。窗口是有限的对话长了就得做滑动窗口或摘要压缩。面试官常问“如果任务执行了 20 轮怎么确保模型不忘记最开始的目标”答案是把用户原始目标固化在系统提示词里每一轮都带着全局规划而不是只依赖对话历史。长期记忆的核心是存储与检索。最常用的方案是把历史信息切成文本块用 embedding 模型转成向量存进向量数据库需要时用余弦相似度或内积检索出 Top-K 相关内容。但这里有个隐藏考点检索到的内容如果不经过重排直接塞给模型很容易被无关信息干扰。面试官如果深挖会问你选什么向量数据库、为什么选它、索引类型是什么、数据量到了什么量级。你不要只回答“用的 Chroma”要说出选型逻辑数据量小、开发期用 Chroma 或 FAISS 轻量起步数据量上来就要换支持分布式索引的 Milvus 或 Qdrant。更重要的是说清楚为什么不把全量上下文塞给模型——成本太高而且信息太杂会拉低模型注意力。2.5 工具使用与 Function Calling 的底层逻辑Function Calling 是 Agent 连接外部世界的桥梁。你需要理解它的本质模型不是直接执行函数而是输出一个结构化的调用意图包含函数名和参数由工程代码去真正执行。面试官会问函数描述怎么写才容易被模型正确调用这里有个很实操的经验函数名要望文生义参数描述要写清楚每个字段的含义、格式、取值范围最好给一个示例值。描述太含糊模型就会传错参数。比如一个查天气的函数参数“location”写成“用户所在城市字符串”模型基本不会用错如果只写“信息”模型大概率会把整个问题原封不动传进去。还有一个经典问题“工具返回结果很长怎么处理”答案是可以先做摘要再送回上下文或者提取关键字段。很多初学者把整个数据库表结构直接塞回给模型Token 爆炸不说关键信息反而被淹没。再进阶一点的考法是问你 MCPModel Context Protocol这类工具协议标准。MCP 的出现是为了解决工具接入碎片化的问题它让工具以统一标准接入 Agent 平台。这一题能答出来面试官会认为你关注了生态前沿不是只会翻文档。2.6 多智能体协作的常见模式多智能体是 2026 年面试的加分重点因为应用层开始从“单 Agent 完成一条线”转向“多 Agent 协同完成一张网”。常见模式有这么几种。主从模式一个 Orchestrator 负责任务拆解、下发指令、汇总结果多个 Worker 各司其职。这种模式最容易落地也最容易解释清楚面试首选讲它。对等模式多个 Agent 权限平等互相传递消息协作适合流程复杂的场景但消息一致性不好保证生产环境下用得少。辩论模式多个 Agent 对同一问题输出不同观点再通过评审机制选出最佳答案。这种方式能在一定程度上提升回答质量但 Token 成本翻好几倍要算清楚账。面试官会追一个问题“多 Agent 之间怎么通信”你要能说出消息协议、数据格式、并发控制这些东西。我的经验是别一上来就搞复杂的角色扮演先让每个 Agent 的职责边界足够清晰再定义好消息 Schema最后才是上框架。2.7 Agent 效果评估的方法论“你的 Agent 效果怎么样”这句话背后藏着一整套评估体系。功能做出来不算完得能证明它好用。离线评估准备一组基准测试集记录任务成功率、工具调用准确率、最终答案相关性、关键信息是否遗漏。测试集不需要很大但场景要覆盖常见分支和异常分支。在线评估观察真实用户请求下的完成率、用户反馈、延迟、成本。没有观测数据的 Agent 项目面试时容易被戳穿——面试官只要问“怎么知道你的 Agent 真的变好了”很多人就哑火了。这里有个很出彩的细节给 Agent 做回归测试。每次改动提示词或工具逻辑都要跑一遍历史用例防止“修了一个 bug 又引出三个新 bug”。面试时把这个细节讲出来专业度直接上升一个台阶。2.8 “Agent token”这类词汇题怎么答才显专业这道题我单独拎出来是因为“ai agent token是什么意思”这类问题在搜索引擎里被大量搜索说明它是很多人的知识盲区。Token 在 Agent 项目里要分三层理解。第一层是基础单位。Token 是模型处理文本的最小单元中文大致一个字对应 1-2 个 token英文一个词约 1-3 个 token。这一层答出来只是及格。第二层是 Agent 的 Token 消耗结构。Agent 比普通对话烧钱是因为每次循环都要把系统提示词 历史记忆 工具返回结果全都重新传给模型。如果你觉得“Agent 不就是多调几次 API 嘛”你算一下账就会知道一次 10 轮的工具调用流程Token 消耗可能是单次对话的 30 到 50 倍。第三层是成本优化手段。面试官想听到的是用更精简的系统提示词、工具返回内容先摘要不要整块塞回、历史对话做滑动窗口、相似历史用向量检索召回而不是全量携带。这层答出来说明你不只是用过 Agent而是真的在真实项目里被 Token 账单教育过。3. 工程实现题从搭建到部署面试官最爱的追问区3.1 主流 Agent 框架横向对比与选型逻辑框架题考察的是“你会不会用”更考察“你知不知道什么时候该自己写而不是用框架”。我把常见框架按特点整理了一张表。框架特点适合场景应注意的坑LangChain / LangGraph生态最全组件多社区活跃通用落地首选抽象层多出问题要花时间看源码AutoGen微软出品多智能体对话能力强多角色协作研究场景学习曲线陡消息流转黑盒化MetaGPT模拟软件公司角色分工生成文档、代码类长任务单任务消耗巨大项目型才划算Dify / FastGPT可视化工作流LLMOps 平台化业务同学也能搭 Agent 场景编排灵活度不如写代码自由自研框架完全可控按需定制核心业务、算法细节需要掌控的场景开发成本高需要成熟工程团队选型逻辑上我的建议是跟面试官讲清楚“业务需求驱动选型”这个过程而不是说“因为火所以用”。比如你做一个客服助手用户意图明确、流程固定Dify 这类可视化平台效率最高但如果要做复杂的动态规划、工具按需组合、多 Agent 状态协同LangGraph 这类代码级框架才够灵活。3.2 基于 Rust 的 AI Agent为什么面试官突然开始考这个“基于 Rust 语言做 AI Agent”是今年热词里一个相当值得关注的方向。很多候选人会愣住觉得 Rust 和 AI Agent 不太搭。实际上这个考点的背后是 Agent 走向工业化的真实需求。Rust 的优势在内存安全和并发性能。Agent 运行时要并行处理多个工具调用、多个子任务还要保证长时间稳定运行Rust 在这方面比 Python 有优势。Python 的 GIL 和动态类型在高压并发下容易出问题Rust 则可以把 Agent 跑成高性能的常驻服务天然适合资源受限的边缘场景和低延迟网关。我在一个 IoT 项目里用 Rust 写过轻量级 Agent 调度层主要负责把工具调用的请求并发分发、收集结果、超时重试再用 Tokio 做异步调度配合 serde 做消息序列化。这个场景下 Python 的并发瓶颈确实能感受到Rust 的体验是实打实的“快”。但面试时不要刻意吹 Rust。你要展现的是“我理解 Rust 适合 Agent 的什么层”LLM 推理本身还是靠外部 API 或 Python 生态Rust 负责的是工程骨架层比如网关、调度、状态管理。能说出这个分工比背诵 Rust 语法亮点靠谱得多。3.3 用 Django 集成 Agent一个真实的 Web 落地场景“用 AI Agent 开发 Django”这个热词说明很多业务团队在尝试把 Agent 装进现有的 Web 体系里。Django 作为最常用的 Python Web 框架和 Agent 集成这件事本身就是一个可以写进简历的高质量项目。我自己的做法是Django 负责 REST API、用户权限、业务数据模型Agent 作为一个独立的异步服务跑在后端。视图函数收到用户请求后把任务扔进 Celery 队列由 Worker 调用 Agent 流程再把结果存库通过 WebSocket 推送给前端。这样 Agent 的长时间执行不会阻塞 Web 请求这是最基础的架构要求。面试官可能会问“Agent 状态怎么和 Django 的用户体系打通”。你要提前想好Agent 的每次任务都绑定一个用户 ID所有工具调用都要做权限校验。比如 Agent 可以替用户查询订单但不能越权修改别人的订单数据。还有一个小坑Django 的 ORM 操作在异步任务里要注意连接池管理不能直接在主线程里建连接然后扔给 Worker 用容易出“MySQL server has gone away”这种诡异问题。3.4 Token 管理、上下文窗口与成本优化实战成本优化题是工程面里性价比最高的一道题因为答好了能直接证明你有实战经验。我的配置思路分四层。第一层是精简系统提示词。系统提示词每次调用都带着写 500 字和写 2000 字一次任务跑 10 轮就差了 15000 token。把非必要内容从系统提示词里挪到用户侧动态注入是第一步。第二层是工具返回压缩。工具返回原始内容可能几千 token但 Agent 真正需要的往往只有几十字。可以先用摘要链把结果浓缩或者只提取结构化字段再拼成文本。第三层是记忆裁剪。短期记忆做滑动窗口只保留最近 4-6 轮长期记忆用向量检索选取最相关的 Top-K 块而不是把历史全部携带。第四层是模型分级。日常工作流里用便宜快速的模型做规划、摘要、分类只在最终生成或复杂推理时调用更强的模型。这个思路叫“模型路由”在成本优化上效果非常显著。算成本的时候有个公式可以现场演示总 Token 数 ≈ 系统提示词 Token 历史对话 Token 查询和工具结果 Token 模型输出 Token乘以调用轮数再乘以每千 Token 单价。面试官会欣赏你能现场算账的人。3.5 Agent 和 RAG 的区别与结合方式RAG 和 Agent 是面试中经常被并列提起的两个概念但它们解决的问题不一样。RAG 解决的是“模型不知道”的问题通过检索把外部知识塞进上下文Agent 解决的是“模型不做”的问题通过多步决策去调用工具完成闭环。生产环境里两者通常结合使用面试官希望听到的正是这种结合思路。我的常规做法是Agent 先解析用户意图如果判断需要特定知识支撑就调用一个“知识检索”工具这个工具内部走的是 RAG 链路——向量召回、重排、拼接上下文。RAG 变成了 Agent 工具箱里的一个强力工具而不是 Agent 本身。这里有个常见面试追问“有了 RAGAgent 还需要微调模型吗”你可以回答能检索解决的不微调因为微调成本高、更新慢需要模型风格或输出格式强一致的任务才考虑微调。这种优先级排序的思路是面试官想听的。3.6 部署与可观测性日志、追踪与评测三件套Agent 项目的复杂度指数级高于传统 Web 项目因为一轮交互里可能触发十几个工具调用、多层上下文传递。排查问题的难度也因此剧增。面试聊部署一定要主动体现出可观测性思维。日志不能再只打印“收到请求完成任务”。在 Agent 的场景下关键日志至少包括推理输出、工具选择决策、工具入参、工具出参、异常重试记录、Token 消耗数。每一条都要带 request_id 串联方便全链路回溯。追踪层面Langfuse、LangSmith、Phoenix 这类工具可以解决 LLM 调用的追踪问题。你在简历里如果写用了这类工具面试官会接着问“追踪到的数据用来做什么”。答案是做成评测样本的一部分把线上失败样本收集起来回归持续修复 Agent 的薄弱点。4. 场景应用题这些业务场景题才是拉开差距的地方4.1 让小红书自动发消息一个最经典的小而全 Agent 案例“ai agent 让小红书自动发消息”这个热词背后藏着典型的 Agent 自动化内容生成需求。面试官喜欢拿这类场景来考察候选人的完整设计能力。这个场景麻雀虽小五脏俱全要理解用户意图、生成内容、匹配视觉素材、规划发布时间、对接外部接口。完整的方案是这样的Agent 收到“今天想发布一条健身相关内容”的需求后先调用一个“选题规划”工具生成 3 个选题然后调用内容生成模块写正文再用图片生成模型产出配图最后调用平台的发布接口完成推送。整个过程涉及 4 次以上的工具调用和至少 2 次决策反馈这是标准的 Agent 流程。面试官一定会问“平台没有开放接口怎么办”我的答案是做合规化处理优先使用平台官方 API如果平台未开放可以在合规授权的前提下用 RPA 方案模拟用户操作。但要注意任何绕过平台限制的行为都有风险这个边界要在项目里预设好。合规性是这一类自动化项目里最不该踩的坑。这个案例最值钱的分析点其实是“为什么不用普通脚本而要上 Agent”因为脚本只能按固定流程执行而 Agent 可以根据发布后的互动反馈调整接下来的内容方向。比如观察到“跑步”类内容互动率高Agent 会主动增加相关选题的比例这是普通自动化做不到的。4.2 客服 Agent 的“最后一公里”难题客服是 Agent 落地最成熟的场景面试被问到的概率极高。很多项目都能做到“第 80 分”也就是大部分常见问题能回答但剩下 20% 的疑难情况才是面试官关心的。难点一多轮对话里的指代消解。用户说“那它呢”Agent 得先搞清楚“它”指什么。维护一个实体记忆槽位是常见的解法。难点二知识时效性。模型训练数据是过时的客服知识库每天都在变必须实时走 RAG 召回最新内容。难点三处理失败时的降级路径。用户已经生气了Agent 还在机械回答怎么办这时需要设置一个“情绪判断”模块或识别到多次未解决就转人工。面试里把这个“人机协同”机制讲清楚甚至比 Agent 本身的实现更能打动面试官。4.3 企业知识库问答的隐形坑企业知识库问答是很多公司的第一个 Agent 项目但它比想象中难坑主要在文档解析和检索质量。PDF 里的表格转成向量之后检索效果往往很差扫描件必须过 OCR否则纯纯的垃圾进垃圾出。面试官如果顺着这个往下问你可以引出“混合检索”的概念向量检索召回语义相关的内容再用关键词或 BM25 保证精确匹配最后两者做融合排序。这是工业级问答系统和玩具 demo 之间的关键分野。要不要微调 embedding 模型也是一个加分考点。通用 embedding 在垂直领域的效果一般如果数据量够用领域语料继续训练 embedding 模型是可以显著提升召回质量的。这个点能答出来面试官会认为你有深度优化经验。4.4 多 Agent 协作的工厂场景实例多 Agent 在面试中可以作为场景题出现比如“设计一个订单履约的 Agent 系统”。这种题考的是架构能力和职责边界划分。我的答题框架是先定义角色订单管理 Agent、库存 Agent、物流 Agent、售后 Agent再定义协作流程用户下单 → 订单 Agent 通知库存 Agent 锁库存 → 物流 Agent 生成配送单 → 订单 Agent 汇总反馈。每个 Agent 维护自己的独立状态通过事件总线异步通信。面试官会追问“跨 Agent 的数据一致性怎么保证”。你可以回答引入分布式事务的最终一致性思路关键节点写事件日志失败就重试或人工介入。这个答案能把话题从“概念”拉回“工程”是面试官最喜欢的走向。4.5 从“AI Agent 白皮书”看面试官想听到的行业判断本子前面聊的都是硬技术但面试官偶尔会在最后抛出一个开放式问题“你怎么看待 AI Agent 的未来。”不要聊空洞的“趋势”也不要背新闻稿。可以参考一些公开白皮书的框架比如阿里云发布的多智能体白皮书里面提到的方向就很有参考价值从单体 Agent 走向多智能体协作、从任务自动化走向决策智能化、从消费级应用走向产业级落地。我的答题思路是抓三个关键词接口标准化、上下文工程、人机边界。Agent 生态成熟的前提是接口和工具接入层有统一标准就像当年互联网统一到 TCP/IP 一样模型能力增长红利期过后围绕上下文的工程能力会成为竞争焦点最后是人与 Agent 的边界哪些场景全自动哪些场景必须人工兜底这不仅是技术问题更是信任问题。面试官问这类题不是要一个准确预测而是要看候选人有没有独立的纵深思考。你说“Agent 会替代客服”那是人云亦云你能说出“替代的边界在于责任如何划定”那是真的理解了这个领域。5. 高频面试题速查表与答题框架5.1 40 道高频题自测清单我把这几年真正在考场上遇到过的题整理成了一张速查表你可以对着自查每道题都能不看资料说出 1-2 分钟的完整回答再约面试模拟。分类题目考察重点概念什么是 AI Agent它的核心能力和普通程序的区别基本定义是否清晰概念Agent 与 LLM、RAG、ChatBot、RPA 的区别与联系边界认知是否准确概念Agent token 是什么意思为什么 Agent 更耗 TokenToken 消耗结构的理解概念什么是 System Prompt如何设计它来锚定 Agent 行为提示词工程基础概念为什么 Agent 需要记忆记忆分类与实现方式记忆机制的工程理解概念模型温度参数如何影响 Agent 的规划与行动推理参数与效果的关系架构解释 ReAct 循环的工作流程和适用场景主流架构理解架构Plan-and-Execute 和 ReAct 的区别什么时候选哪个架构对比和取舍架构什么是 Reflexion如何实现 Agent 的失败反思是否关注前沿机制架构多智能体协作有哪几种模式生产环境怎么选多 Agent 设计能力架构如何评估一个 Agent 系统的质量和性能评估体系的设计能力工具Function Calling 的原理是什么模型如何决定调用哪个工具工具调用底层理解工具工具描述怎么写命中率更高举一个失败例子实操经验工具工具返回结果太长怎么处理如何压缩回填上下文Token 优化意识工具什么是 MCP它解决了什么问题生态前沿关注度工具工具执行超时或报错时Agent 如何恢复兜底设计能力记忆短期记忆和长期记忆的实现方案各有哪些记忆落地能力记忆上下文窗口满了怎么办怎么压缩历史窗口管理实操记忆向量数据库怎么选索引和分片策略是什么存储选型经验记忆用户的问题跨多轮Agent 怎么保持对目标的跟踪状态管理能力RAGRAG 与 Agent 有什么区别它们如何结合概念边界和协同RAG混合检索怎么做为什么只有向量搜索不够工业级检索理解RAG文档解析和表格处理有哪些坑怎么解决数据处理经验安全Agent 如何防止提示词注入工具权限怎么管控安全意识工程流式输出在 SSR/WebSocket 中如何落地前后端集成经验工程如何实现多轮工具调用的可靠重试和幂等分布式可靠性基础工程Agent 的响应延迟怎么优化哪些环节最耗时端到端性能优化工程多租户场景下 Agent 数据隔离怎么做架构设计能力部署如何在生产环境做 Agent 的全链路日志追踪可观测性思维部署并发量上来后Agent 服务的瓶颈在哪容量规划能力场景设计一个电商售前导购 Agent场景方案能力场景设计一个自动化内容发布 Agent对应小红书场景全流程设计与合规意识场景Agent 在客服场景如何处理恶意或异常输入鲁棒性和安全场景如何组织多 Agent 流水线完成一份行业报告复杂任务编排开放过去六个月你遇到的 Agent 项目最大困难是什么真实性验证开放你认为 Agent 发展最大的瓶颈是什么行业理解深度开放你平时怎么获取 AI Agent 的最新信息学习能力和信息渠道实操请复盘你做的 Agent 系统架构、流程、效果、成本综合复盘能力实操如果让你重新做一遍哪里会改反思和改进能力实操线上 Agent 数据回放如何做如何从失败中迭代持续优化闭环这张表不是让你背答案而是让你用来校准能力地图。你能秒答的题目划掉支支吾吾的题目标红那就是你接下来要补的方向。5.2 一套万能的 STAR 答题框架面试里讲项目经验最怕讲成“我用了 LangChain接了个向量库效果还行”。面试官听完啥信息也没有。用 STAR 框架来组织回答信息密度会高很多。Situation背景说明项目要解决的问题比如“客服团队每天要处理 2000 条重复咨询希望通过 Agent 分流至少 30%”。Task你的任务说明你在项目里的角色和职责不是“我负责 Agent 开发”而是“我负责整体架构设计、工具层开发、线上效果评估”。Action你的行动这是重点要讲出决策过程。“我对比了 LangGraph 和自研方案因为业务需要灵活的提示词编排最终选了 LangGraph工具层我封装了订单查询和售后流程设计了参数 Schema 和异常重试机制评估上我搭建了 500 条测试集持续回归。”Result结果用数据说话。“上线后分流率提升到 35%平均响应时长从 2 分钟降到 10 秒成本每天 30 元。”如果你能补一句“后来发现订单查询类的场景准确率最高售后争议类仍有 20% 转人工”会更有可信度。这套框架讲下来大概 3 分钟信息密度足够面试官也能从里面挑细节来追问。追问答得上就是一场高质量的面试对话。5.3 面试官最反感的三种行为第一种只背概念一问细节就崩。“你知道 ReAct”但你问“如果工具返回结果和预期不符你会怎么处理”只能答“重新调用一次”。这暴露了没有真实调试经验。第二种无限推崇框架说不出原理。简历里写“熟悉 LangChain”但追问 LangGraph 里条件边的判断逻辑、记忆块是怎么注入上下文的完全答不上来。框架是工具不是能力本身。第三种回避失败和成本。问项目最大的坑说“都很顺利”问成本优化说“公司不差钱”。面试官最想听的就是你踩过的坑和踩完之后形成的判断避而不谈等于主动放弃了这个展示深度思考的机会。写在最后的个人体会这套题库整理完回头看我自己的面试经历真正拿到 offer 的几轮都不是因为我会的题多而是因为我讲问题的方式像“做技术的同行在交流”而不是“考生在答题”。面试官问到不会的题目时我的习惯是说一句“这个问题我没有深入验证过但我基于目前的认知判断是……”然后把思考过程讲出来。这一招在很多场面试里反而成了加分项。最后针对准备 Agent 面试的朋友再补两个小建议。第一建一个自己的 Agent 实验仓库把架构、代码、踩坑记录都放进一个公开或私有仓库里面试时直接拿出真实项目来讲比任何八股都有效。第二定期跑一个 Agent 测评集把每个版本的 Token 消耗、成功率、失败原因记录成表格这些数据就是你在面试里最有说服力的证据。按这份清单扎实准备你上场之后会发现大多数问题其实都在这张表里。 
长河君 · 2026/10/27 11:51:34 · 阅读 1.2k AI Agent面试高频考点全解析：从核心概念到工程实践
这两年 AI Agent 方向的岗位已经从“招不到人”变成“面不完的人”。我跟身边做面试官的朋友聊了一圈大家最统一的反馈是简历上写 Agent 项目的人越来越多但能扛住三轮追问的少之又少。很多候选人把 Hugging Face 上的 demo 跑通了就敢写“精通 Agent 开发”结果一问 ReAct 循环的终止条件、工具返回结果怎么进上下文、多智能体之间怎么同步状态立刻卡壳。我自己过去半年密集面了十几家 LLM 应用公司从做 AI 客服的创业团队到搞企业级知识库的中型厂再到研究多智能体框架的大组几乎每一次面试都会在 Agent 相关的考点上过一遍。高频考点的重复率真的非常高。整理完之后我筛了一遍去掉那些纯粹聊行业趋势的虚题剩下的硬核考点其实就摆在一个闭环里概念、架构、工程、场景。这套题库覆盖了 90% 的高频考点不管是准备社招还是校招按这个清单去复习比漫无目的刷题高效得多。1. 先搞清楚方向AI Agent 面试到底在筛选什么1.1 从 JD 反推考点分布不要只看标题写“Agent 工程师”就觉得是纯算法岗。AI Agent 岗位的 JD 看起来五花八门但拆开看要求的核心能力高度集中对 LLM 的理解深度、工程落地的能力、架构设计能力以及业务场景的敏感度。我统计了一下自己面过的公司的 JD 关键词出现频率最高的是“大模型应用开发”“RAG”“LangChain 或类似框架”“多智能体”其次是“向量数据库”“提示词工程”“部署经验”。这意味着面试官真正关注的是你能不能把一个 Agent 从零搭起来、跑得稳、算得清成本而不是你会不会背几个新概念。很多候选人喜欢在简历里写“精通 AutoGPT”但现实中 AutoGPT 这种通用 Agent 在正式产品里基本没法直接用面试官听到这类描述反而会重点考察你对它局限性的理解。1.2 三个必须具备的底层认知第一个认知是 Agent 的本质是“循环”。LLM 本身是无状态的一次推理输出一个结果就结束了。Agent 要完成任务必须把“推理 → 行动 → 观察 → 再推理”这个循环跑起来。这是 ReAct 的核心也是面试中所有追问的起点。第二个认知是 Agent 的能力边界由工具决定。模型再聪明没有合适的工具就只能空谈。面试官一定会问“你给 Agent 设计了哪些工具”“工具描述怎么写的”“参数 Schema 怎么定义的”因为工具的质量直接决定 Agent 的实际效果。第三个认知是 Agent 的成本不只是 API 费用。一次 Agent 任务涉及多轮模型调用每轮都要携带系统提示词、历史对话、工具返回内容Token 消耗量是普通 Chat 场景的几十倍。不考虑成本优化的 Agent 项目在面试官眼里都是玩具。1.3 简历里最常见的三类“假 Agent”项目第一类是“只有工具调用没有循环”。很多项目只是让模型调了一次搜索 API然后生成回答这在面试官眼里只是 LLM API不是 Agent。第二类是“把 RAG 包装成 Agent”。RAG 是检索增强生成它的核心是召回和生成整个过程没有多步决策。如果连 RAG 和 Agent 的区别都说不清楚面试基本就凉了。第三类是“纯调包没有任何自研”。框架能帮你省时间但面试官问起框架内部的执行流程、钩子机制、上下文构建逻辑如果答不上来项目就会被判定为“会用但没有理解”。这也是为什么这套题库的第一部分先帮你把概念底子打扎实。2. 核心概念与原理题这 8 道题决定基础分2.1 Agent 与 LLM、RPA、ChatBot 的本质区别这是开场白级别的送分题但送分题架不住答不好。很多人的回答是“Agent 能用工具”这个答案太浅了。完整一点的说法是LLM 是纯粹的概率语言模型输入一段文本输出一段文本没有目标导向也没有行动能力。ChatBot 在 LLM 之上加了多轮对话的记忆但依然停留在“对话”这个层不会主动去执行一个任务。RPA 能执行流程化的操作但它不知道为什么要做也不能根据中间结果调整策略。Agent 则把这三者串起来了它有感知能力能接收环境反馈有规划能力能把目标拆成步骤有记忆能力能基于历史决策有行动能力能调用工具改变环境状态。用生活化的比喻来解释LLM 像一本百科全书你问它才答RPA 像一条流水线按预设程序走Agent 则像一个小团队负责人拆目标、定计划、派人干活、根据结果调整方案。2.2 Agent 的四大核心能力拆解面试官提完“什么是 Agent”大概率会接着问“Agent 的核心能力有哪些”。标准框架是感知、规划、记忆、行动。感知是这个循环的起点。对 LLM 而言感知就是把环境信息映射成文本输入比如把数据库查询结果、网页内容、用户反馈都转成模型能理解的文本。规划是 Agent 和普通程序最不一样的地方。简单场景用单步决策遇到复杂任务就需要任务分解比如把“写一篇行业分析报告”拆成“收集数据→分析趋势→撰写大纲→逐段生成→检查引用”。这里面试官会追问“如果任务分解错了怎么办”所以你要提到重规划Re-plan机制执行过程中发现子任务无法完成要回到规划层重新拆分。记忆分短期和长期。短期记忆是当前任务窗口内的对话和中间状态长期记忆是跨会话存储的历史经验和知识通常用向量数据库存 embedding需要时做相似度检索。记忆这块延伸问法很多后面专门展开。行动就是调用工具。但行动不只是“调 API”还包括行动的可靠性工具调用超时怎么办、返回结果格式异常怎么办、工具本身执行了但结果不符合预期怎么办。这些在真实项目里比模型选型更折磨人。2.3 ReAct、Plan-and-Execute、Reflexion 架构横向对比这道题几乎是必考而且面试官会要求你边讲边画流程。不要用 mermaid直接在白板上画圈就能说清楚。ReAct 是 Reason Act 交替进行的模式模型在“思考”和“行动”之间循环拿到问题 → 思考需要什么信息 → 调用工具 → 观察结果 → 继续思考直到得出最终答案。它的优点是灵活适合工具调用密集、需要边做边看的场景缺点是轮次不可控任务复杂时容易陷入死循环。Plan-and-Execute 的思路是先规划后执行模型先把整体任务拆成步骤清单然后一步步执行步骤之间可以有先后或并行关系。它的优点是 Token 消耗相对可控因为不需要每轮都重新推理整体计划缺点是一旦计划有误后续执行全跑偏必须有纠错机制。Reflexion 是让 Agent 对自己的失败进行反思把错误原因整理成文本存到记忆里下次类似任务不再犯同样的错。面试时提这个架构能加分因为说明你考虑到了 Agent 的自我进化而不仅仅是执行任务。这三个架构不是互斥的生产环境里通常是组合使用用 Plan-and-Execute 拆分大任务每个子任务内部用 ReAct 做工具调用再引入 Reflexion 做失败复盘。我在实际项目中就是这样搭的。2.4 记忆机制短期、长期与向量检索面试问答记忆是 Agent 面试里最容易暴露水平的一道题因为它牵扯到工程细节。短期记忆的核心是上下文窗口管理。窗口是有限的对话长了就得做滑动窗口或摘要压缩。面试官常问“如果任务执行了 20 轮怎么确保模型不忘记最开始的目标”答案是把用户原始目标固化在系统提示词里每一轮都带着全局规划而不是只依赖对话历史。长期记忆的核心是存储与检索。最常用的方案是把历史信息切成文本块用 embedding 模型转成向量存进向量数据库需要时用余弦相似度或内积检索出 Top-K 相关内容。但这里有个隐藏考点检索到的内容如果不经过重排直接塞给模型很容易被无关信息干扰。面试官如果深挖会问你选什么向量数据库、为什么选它、索引类型是什么、数据量到了什么量级。你不要只回答“用的 Chroma”要说出选型逻辑数据量小、开发期用 Chroma 或 FAISS 轻量起步数据量上来就要换支持分布式索引的 Milvus 或 Qdrant。更重要的是说清楚为什么不把全量上下文塞给模型——成本太高而且信息太杂会拉低模型注意力。2.5 工具使用与 Function Calling 的底层逻辑Function Calling 是 Agent 连接外部世界的桥梁。你需要理解它的本质模型不是直接执行函数而是输出一个结构化的调用意图包含函数名和参数由工程代码去真正执行。面试官会问函数描述怎么写才容易被模型正确调用这里有个很实操的经验函数名要望文生义参数描述要写清楚每个字段的含义、格式、取值范围最好给一个示例值。描述太含糊模型就会传错参数。比如一个查天气的函数参数“location”写成“用户所在城市字符串”模型基本不会用错如果只写“信息”模型大概率会把整个问题原封不动传进去。还有一个经典问题“工具返回结果很长怎么处理”答案是可以先做摘要再送回上下文或者提取关键字段。很多初学者把整个数据库表结构直接塞回给模型Token 爆炸不说关键信息反而被淹没。再进阶一点的考法是问你 MCPModel Context Protocol这类工具协议标准。MCP 的出现是为了解决工具接入碎片化的问题它让工具以统一标准接入 Agent 平台。这一题能答出来面试官会认为你关注了生态前沿不是只会翻文档。2.6 多智能体协作的常见模式多智能体是 2026 年面试的加分重点因为应用层开始从“单 Agent 完成一条线”转向“多 Agent 协同完成一张网”。常见模式有这么几种。主从模式一个 Orchestrator 负责任务拆解、下发指令、汇总结果多个 Worker 各司其职。这种模式最容易落地也最容易解释清楚面试首选讲它。对等模式多个 Agent 权限平等互相传递消息协作适合流程复杂的场景但消息一致性不好保证生产环境下用得少。辩论模式多个 Agent 对同一问题输出不同观点再通过评审机制选出最佳答案。这种方式能在一定程度上提升回答质量但 Token 成本翻好几倍要算清楚账。面试官会追一个问题“多 Agent 之间怎么通信”你要能说出消息协议、数据格式、并发控制这些东西。我的经验是别一上来就搞复杂的角色扮演先让每个 Agent 的职责边界足够清晰再定义好消息 Schema最后才是上框架。2.7 Agent 效果评估的方法论“你的 Agent 效果怎么样”这句话背后藏着一整套评估体系。功能做出来不算完得能证明它好用。离线评估准备一组基准测试集记录任务成功率、工具调用准确率、最终答案相关性、关键信息是否遗漏。测试集不需要很大但场景要覆盖常见分支和异常分支。在线评估观察真实用户请求下的完成率、用户反馈、延迟、成本。没有观测数据的 Agent 项目面试时容易被戳穿——面试官只要问“怎么知道你的 Agent 真的变好了”很多人就哑火了。这里有个很出彩的细节给 Agent 做回归测试。每次改动提示词或工具逻辑都要跑一遍历史用例防止“修了一个 bug 又引出三个新 bug”。面试时把这个细节讲出来专业度直接上升一个台阶。2.8 “Agent token”这类词汇题怎么答才显专业这道题我单独拎出来是因为“ai agent token是什么意思”这类问题在搜索引擎里被大量搜索说明它是很多人的知识盲区。Token 在 Agent 项目里要分三层理解。第一层是基础单位。Token 是模型处理文本的最小单元中文大致一个字对应 1-2 个 token英文一个词约 1-3 个 token。这一层答出来只是及格。第二层是 Agent 的 Token 消耗结构。Agent 比普通对话烧钱是因为每次循环都要把系统提示词 历史记忆 工具返回结果全都重新传给模型。如果你觉得“Agent 不就是多调几次 API 嘛”你算一下账就会知道一次 10 轮的工具调用流程Token 消耗可能是单次对话的 30 到 50 倍。第三层是成本优化手段。面试官想听到的是用更精简的系统提示词、工具返回内容先摘要不要整块塞回、历史对话做滑动窗口、相似历史用向量检索召回而不是全量携带。这层答出来说明你不只是用过 Agent而是真的在真实项目里被 Token 账单教育过。3. 工程实现题从搭建到部署面试官最爱的追问区3.1 主流 Agent 框架横向对比与选型逻辑框架题考察的是“你会不会用”更考察“你知不知道什么时候该自己写而不是用框架”。我把常见框架按特点整理了一张表。框架特点适合场景应注意的坑LangChain / LangGraph生态最全组件多社区活跃通用落地首选抽象层多出问题要花时间看源码AutoGen微软出品多智能体对话能力强多角色协作研究场景学习曲线陡消息流转黑盒化MetaGPT模拟软件公司角色分工生成文档、代码类长任务单任务消耗巨大项目型才划算Dify / FastGPT可视化工作流LLMOps 平台化业务同学也能搭 Agent 场景编排灵活度不如写代码自由自研框架完全可控按需定制核心业务、算法细节需要掌控的场景开发成本高需要成熟工程团队选型逻辑上我的建议是跟面试官讲清楚“业务需求驱动选型”这个过程而不是说“因为火所以用”。比如你做一个客服助手用户意图明确、流程固定Dify 这类可视化平台效率最高但如果要做复杂的动态规划、工具按需组合、多 Agent 状态协同LangGraph 这类代码级框架才够灵活。3.2 基于 Rust 的 AI Agent为什么面试官突然开始考这个“基于 Rust 语言做 AI Agent”是今年热词里一个相当值得关注的方向。很多候选人会愣住觉得 Rust 和 AI Agent 不太搭。实际上这个考点的背后是 Agent 走向工业化的真实需求。Rust 的优势在内存安全和并发性能。Agent 运行时要并行处理多个工具调用、多个子任务还要保证长时间稳定运行Rust 在这方面比 Python 有优势。Python 的 GIL 和动态类型在高压并发下容易出问题Rust 则可以把 Agent 跑成高性能的常驻服务天然适合资源受限的边缘场景和低延迟网关。我在一个 IoT 项目里用 Rust 写过轻量级 Agent 调度层主要负责把工具调用的请求并发分发、收集结果、超时重试再用 Tokio 做异步调度配合 serde 做消息序列化。这个场景下 Python 的并发瓶颈确实能感受到Rust 的体验是实打实的“快”。但面试时不要刻意吹 Rust。你要展现的是“我理解 Rust 适合 Agent 的什么层”LLM 推理本身还是靠外部 API 或 Python 生态Rust 负责的是工程骨架层比如网关、调度、状态管理。能说出这个分工比背诵 Rust 语法亮点靠谱得多。3.3 用 Django 集成 Agent一个真实的 Web 落地场景“用 AI Agent 开发 Django”这个热词说明很多业务团队在尝试把 Agent 装进现有的 Web 体系里。Django 作为最常用的 Python Web 框架和 Agent 集成这件事本身就是一个可以写进简历的高质量项目。我自己的做法是Django 负责 REST API、用户权限、业务数据模型Agent 作为一个独立的异步服务跑在后端。视图函数收到用户请求后把任务扔进 Celery 队列由 Worker 调用 Agent 流程再把结果存库通过 WebSocket 推送给前端。这样 Agent 的长时间执行不会阻塞 Web 请求这是最基础的架构要求。面试官可能会问“Agent 状态怎么和 Django 的用户体系打通”。你要提前想好Agent 的每次任务都绑定一个用户 ID所有工具调用都要做权限校验。比如 Agent 可以替用户查询订单但不能越权修改别人的订单数据。还有一个小坑Django 的 ORM 操作在异步任务里要注意连接池管理不能直接在主线程里建连接然后扔给 Worker 用容易出“MySQL server has gone away”这种诡异问题。3.4 Token 管理、上下文窗口与成本优化实战成本优化题是工程面里性价比最高的一道题因为答好了能直接证明你有实战经验。我的配置思路分四层。第一层是精简系统提示词。系统提示词每次调用都带着写 500 字和写 2000 字一次任务跑 10 轮就差了 15000 token。把非必要内容从系统提示词里挪到用户侧动态注入是第一步。第二层是工具返回压缩。工具返回原始内容可能几千 token但 Agent 真正需要的往往只有几十字。可以先用摘要链把结果浓缩或者只提取结构化字段再拼成文本。第三层是记忆裁剪。短期记忆做滑动窗口只保留最近 4-6 轮长期记忆用向量检索选取最相关的 Top-K 块而不是把历史全部携带。第四层是模型分级。日常工作流里用便宜快速的模型做规划、摘要、分类只在最终生成或复杂推理时调用更强的模型。这个思路叫“模型路由”在成本优化上效果非常显著。算成本的时候有个公式可以现场演示总 Token 数 ≈ 系统提示词 Token 历史对话 Token 查询和工具结果 Token 模型输出 Token乘以调用轮数再乘以每千 Token 单价。面试官会欣赏你能现场算账的人。3.5 Agent 和 RAG 的区别与结合方式RAG 和 Agent 是面试中经常被并列提起的两个概念但它们解决的问题不一样。RAG 解决的是“模型不知道”的问题通过检索把外部知识塞进上下文Agent 解决的是“模型不做”的问题通过多步决策去调用工具完成闭环。生产环境里两者通常结合使用面试官希望听到的正是这种结合思路。我的常规做法是Agent 先解析用户意图如果判断需要特定知识支撑就调用一个“知识检索”工具这个工具内部走的是 RAG 链路——向量召回、重排、拼接上下文。RAG 变成了 Agent 工具箱里的一个强力工具而不是 Agent 本身。这里有个常见面试追问“有了 RAGAgent 还需要微调模型吗”你可以回答能检索解决的不微调因为微调成本高、更新慢需要模型风格或输出格式强一致的任务才考虑微调。这种优先级排序的思路是面试官想听的。3.6 部署与可观测性日志、追踪与评测三件套Agent 项目的复杂度指数级高于传统 Web 项目因为一轮交互里可能触发十几个工具调用、多层上下文传递。排查问题的难度也因此剧增。面试聊部署一定要主动体现出可观测性思维。日志不能再只打印“收到请求完成任务”。在 Agent 的场景下关键日志至少包括推理输出、工具选择决策、工具入参、工具出参、异常重试记录、Token 消耗数。每一条都要带 request_id 串联方便全链路回溯。追踪层面Langfuse、LangSmith、Phoenix 这类工具可以解决 LLM 调用的追踪问题。你在简历里如果写用了这类工具面试官会接着问“追踪到的数据用来做什么”。答案是做成评测样本的一部分把线上失败样本收集起来回归持续修复 Agent 的薄弱点。4. 场景应用题这些业务场景题才是拉开差距的地方4.1 让小红书自动发消息一个最经典的小而全 Agent 案例“ai agent 让小红书自动发消息”这个热词背后藏着典型的 Agent 自动化内容生成需求。面试官喜欢拿这类场景来考察候选人的完整设计能力。这个场景麻雀虽小五脏俱全要理解用户意图、生成内容、匹配视觉素材、规划发布时间、对接外部接口。完整的方案是这样的Agent 收到“今天想发布一条健身相关内容”的需求后先调用一个“选题规划”工具生成 3 个选题然后调用内容生成模块写正文再用图片生成模型产出配图最后调用平台的发布接口完成推送。整个过程涉及 4 次以上的工具调用和至少 2 次决策反馈这是标准的 Agent 流程。面试官一定会问“平台没有开放接口怎么办”我的答案是做合规化处理优先使用平台官方 API如果平台未开放可以在合规授权的前提下用 RPA 方案模拟用户操作。但要注意任何绕过平台限制的行为都有风险这个边界要在项目里预设好。合规性是这一类自动化项目里最不该踩的坑。这个案例最值钱的分析点其实是“为什么不用普通脚本而要上 Agent”因为脚本只能按固定流程执行而 Agent 可以根据发布后的互动反馈调整接下来的内容方向。比如观察到“跑步”类内容互动率高Agent 会主动增加相关选题的比例这是普通自动化做不到的。4.2 客服 Agent 的“最后一公里”难题客服是 Agent 落地最成熟的场景面试被问到的概率极高。很多项目都能做到“第 80 分”也就是大部分常见问题能回答但剩下 20% 的疑难情况才是面试官关心的。难点一多轮对话里的指代消解。用户说“那它呢”Agent 得先搞清楚“它”指什么。维护一个实体记忆槽位是常见的解法。难点二知识时效性。模型训练数据是过时的客服知识库每天都在变必须实时走 RAG 召回最新内容。难点三处理失败时的降级路径。用户已经生气了Agent 还在机械回答怎么办这时需要设置一个“情绪判断”模块或识别到多次未解决就转人工。面试里把这个“人机协同”机制讲清楚甚至比 Agent 本身的实现更能打动面试官。4.3 企业知识库问答的隐形坑企业知识库问答是很多公司的第一个 Agent 项目但它比想象中难坑主要在文档解析和检索质量。PDF 里的表格转成向量之后检索效果往往很差扫描件必须过 OCR否则纯纯的垃圾进垃圾出。面试官如果顺着这个往下问你可以引出“混合检索”的概念向量检索召回语义相关的内容再用关键词或 BM25 保证精确匹配最后两者做融合排序。这是工业级问答系统和玩具 demo 之间的关键分野。要不要微调 embedding 模型也是一个加分考点。通用 embedding 在垂直领域的效果一般如果数据量够用领域语料继续训练 embedding 模型是可以显著提升召回质量的。这个点能答出来面试官会认为你有深度优化经验。4.4 多 Agent 协作的工厂场景实例多 Agent 在面试中可以作为场景题出现比如“设计一个订单履约的 Agent 系统”。这种题考的是架构能力和职责边界划分。我的答题框架是先定义角色订单管理 Agent、库存 Agent、物流 Agent、售后 Agent再定义协作流程用户下单 → 订单 Agent 通知库存 Agent 锁库存 → 物流 Agent 生成配送单 → 订单 Agent 汇总反馈。每个 Agent 维护自己的独立状态通过事件总线异步通信。面试官会追问“跨 Agent 的数据一致性怎么保证”。你可以回答引入分布式事务的最终一致性思路关键节点写事件日志失败就重试或人工介入。这个答案能把话题从“概念”拉回“工程”是面试官最喜欢的走向。4.5 从“AI Agent 白皮书”看面试官想听到的行业判断本子前面聊的都是硬技术但面试官偶尔会在最后抛出一个开放式问题“你怎么看待 AI Agent 的未来。”不要聊空洞的“趋势”也不要背新闻稿。可以参考一些公开白皮书的框架比如阿里云发布的多智能体白皮书里面提到的方向就很有参考价值从单体 Agent 走向多智能体协作、从任务自动化走向决策智能化、从消费级应用走向产业级落地。我的答题思路是抓三个关键词接口标准化、上下文工程、人机边界。Agent 生态成熟的前提是接口和工具接入层有统一标准就像当年互联网统一到 TCP/IP 一样模型能力增长红利期过后围绕上下文的工程能力会成为竞争焦点最后是人与 Agent 的边界哪些场景全自动哪些场景必须人工兜底这不仅是技术问题更是信任问题。面试官问这类题不是要一个准确预测而是要看候选人有没有独立的纵深思考。你说“Agent 会替代客服”那是人云亦云你能说出“替代的边界在于责任如何划定”那是真的理解了这个领域。5. 高频面试题速查表与答题框架5.1 40 道高频题自测清单我把这几年真正在考场上遇到过的题整理成了一张速查表你可以对着自查每道题都能不看资料说出 1-2 分钟的完整回答再约面试模拟。分类题目考察重点概念什么是 AI Agent它的核心能力和普通程序的区别基本定义是否清晰概念Agent 与 LLM、RAG、ChatBot、RPA 的区别与联系边界认知是否准确概念Agent token 是什么意思为什么 Agent 更耗 TokenToken 消耗结构的理解概念什么是 System Prompt如何设计它来锚定 Agent 行为提示词工程基础概念为什么 Agent 需要记忆记忆分类与实现方式记忆机制的工程理解概念模型温度参数如何影响 Agent 的规划与行动推理参数与效果的关系架构解释 ReAct 循环的工作流程和适用场景主流架构理解架构Plan-and-Execute 和 ReAct 的区别什么时候选哪个架构对比和取舍架构什么是 Reflexion如何实现 Agent 的失败反思是否关注前沿机制架构多智能体协作有哪几种模式生产环境怎么选多 Agent 设计能力架构如何评估一个 Agent 系统的质量和性能评估体系的设计能力工具Function Calling 的原理是什么模型如何决定调用哪个工具工具调用底层理解工具工具描述怎么写命中率更高举一个失败例子实操经验工具工具返回结果太长怎么处理如何压缩回填上下文Token 优化意识工具什么是 MCP它解决了什么问题生态前沿关注度工具工具执行超时或报错时Agent 如何恢复兜底设计能力记忆短期记忆和长期记忆的实现方案各有哪些记忆落地能力记忆上下文窗口满了怎么办怎么压缩历史窗口管理实操记忆向量数据库怎么选索引和分片策略是什么存储选型经验记忆用户的问题跨多轮Agent 怎么保持对目标的跟踪状态管理能力RAGRAG 与 Agent 有什么区别它们如何结合概念边界和协同RAG混合检索怎么做为什么只有向量搜索不够工业级检索理解RAG文档解析和表格处理有哪些坑怎么解决数据处理经验安全Agent 如何防止提示词注入工具权限怎么管控安全意识工程流式输出在 SSR/WebSocket 中如何落地前后端集成经验工程如何实现多轮工具调用的可靠重试和幂等分布式可靠性基础工程Agent 的响应延迟怎么优化哪些环节最耗时端到端性能优化工程多租户场景下 Agent 数据隔离怎么做架构设计能力部署如何在生产环境做 Agent 的全链路日志追踪可观测性思维部署并发量上来后Agent 服务的瓶颈在哪容量规划能力场景设计一个电商售前导购 Agent场景方案能力场景设计一个自动化内容发布 Agent对应小红书场景全流程设计与合规意识场景Agent 在客服场景如何处理恶意或异常输入鲁棒性和安全场景如何组织多 Agent 流水线完成一份行业报告复杂任务编排开放过去六个月你遇到的 Agent 项目最大困难是什么真实性验证开放你认为 Agent 发展最大的瓶颈是什么行业理解深度开放你平时怎么获取 AI Agent 的最新信息学习能力和信息渠道实操请复盘你做的 Agent 系统架构、流程、效果、成本综合复盘能力实操如果让你重新做一遍哪里会改反思和改进能力实操线上 Agent 数据回放如何做如何从失败中迭代持续优化闭环这张表不是让你背答案而是让你用来校准能力地图。你能秒答的题目划掉支支吾吾的题目标红那就是你接下来要补的方向。5.2 一套万能的 STAR 答题框架面试里讲项目经验最怕讲成“我用了 LangChain接了个向量库效果还行”。面试官听完啥信息也没有。用 STAR 框架来组织回答信息密度会高很多。Situation背景说明项目要解决的问题比如“客服团队每天要处理 2000 条重复咨询希望通过 Agent 分流至少 30%”。Task你的任务说明你在项目里的角色和职责不是“我负责 Agent 开发”而是“我负责整体架构设计、工具层开发、线上效果评估”。Action你的行动这是重点要讲出决策过程。“我对比了 LangGraph 和自研方案因为业务需要灵活的提示词编排最终选了 LangGraph工具层我封装了订单查询和售后流程设计了参数 Schema 和异常重试机制评估上我搭建了 500 条测试集持续回归。”Result结果用数据说话。“上线后分流率提升到 35%平均响应时长从 2 分钟降到 10 秒成本每天 30 元。”如果你能补一句“后来发现订单查询类的场景准确率最高售后争议类仍有 20% 转人工”会更有可信度。这套框架讲下来大概 3 分钟信息密度足够面试官也能从里面挑细节来追问。追问答得上就是一场高质量的面试对话。5.3 面试官最反感的三种行为第一种只背概念一问细节就崩。“你知道 ReAct”但你问“如果工具返回结果和预期不符你会怎么处理”只能答“重新调用一次”。这暴露了没有真实调试经验。第二种无限推崇框架说不出原理。简历里写“熟悉 LangChain”但追问 LangGraph 里条件边的判断逻辑、记忆块是怎么注入上下文的完全答不上来。框架是工具不是能力本身。第三种回避失败和成本。问项目最大的坑说“都很顺利”问成本优化说“公司不差钱”。面试官最想听的就是你踩过的坑和踩完之后形成的判断避而不谈等于主动放弃了这个展示深度思考的机会。写在最后的个人体会这套题库整理完回头看我自己的面试经历真正拿到 offer 的几轮都不是因为我会的题多而是因为我讲问题的方式像“做技术的同行在交流”而不是“考生在答题”。面试官问到不会的题目时我的习惯是说一句“这个问题我没有深入验证过但我基于目前的认知判断是……”然后把思考过程讲出来。这一招在很多场面试里反而成了加分项。最后针对准备 Agent 面试的朋友再补两个小建议。第一建一个自己的 Agent 实验仓库把架构、代码、踩坑记录都放进一个公开或私有仓库里面试时直接拿出真实项目来讲比任何八股都有效。第二定期跑一个 Agent 测评集把每个版本的 Token 消耗、成功率、失败原因记录成表格这些数据就是你在面试里最有说服力的证据。按这份清单扎实准备你上场之后会发现大多数问题其实都在这张表里。