13. 面试真题与自测
十三、面试真题与自测¶
这一章的目标不是把题目越攒越多，而是把面试题变成正文的反向索引层。每张卡片看成一个去重后的系统问题。同义问法归到一起，自测时先按卡片编号回忆判断框架，再回到对应正文把执行链、失败模式、排查顺序和评测方法讲完整。后面再来新题时，不会不断长出新的题库碎片，而是稳定沉淀成同一套知识结构。默认要求更高：多数卡片都应该能逼你讲到机制、关键参数或结构、最小实现路径、调优抓手和排查顺序，不只讲一个概念定义。
AI 应用工程¶
这一组题考的是能不能把 AI 应用讲成一条受治理的请求链。回答时区分任务定义、上下文组织、执行组织、运行治理和风险治理分别在负责什么。
APP-01 主动澄清 vs 强行推断¶
核心问题： 用户请求高度模糊时，Agent 什么时候应该先反问澄清，什么时候可以结合检索结果、历史画像或业务上下文先做带边界的推断。
真题节选： “在电商或导购场景下，用户的请求往往高度模糊，Agent 怎么来精准理解这种需求？”“如何设计一套‘主动澄清’决策逻辑？”“什么情况下应该反问用户，什么情况下可以结合历史画像强行推断？”
常见变体： 模糊问题怎么判断能不能直接答。缺失信息会不会改变执行边界。澄清是不是一定比猜测更安全。
回答骨架： 先讲缺失信息是否影响任务边界和执行风险，再讲澄清成本与检索成本，再讲历史画像与会话历史能提供哪些证据，最后讲澄清后的状态更新与无法确认时的降级收口。
排查顺序： 先查是否缺关键槽位，再查会话摘要和用户画像是否脏，再查澄清阈值与决策规则，最后查对外回答是否把不确定性显式说清。
正文对应章节： 05. AI 应用工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。百度 AI Agent 开发一面。字节大模型应用开发一面。
APP-02 长上下文遗忘与 Attention 稀释¶
核心问题： 对话轮次一长，模型为什么会“记得还在，实际上已经遵循不住”，以及这种问题在工程上该怎样识别和缓解。
真题节选： “当对话轮数很多，上下文窗口不够的时候，有哪些处理策略？”“Token 过长导致的 Attention 稀释现象为什么会导致 Agent 的指令遵循能力下降？”“目前有哪些机制可以缓解模型在长上下文对话里的‘信息遗忘’现象？”
常见变体： 为什么长上下文不等于长记忆。指令为什么会被后面材料冲淡。上下文装配优先级应该怎么排。什么叫上下文很长但有效上下文很少。
回答骨架： 先讲长上下文问题本质上不是“窗口不够大”，而是稳定指令、动态证据、结构化状态和低价值历史被混装了，再讲上下文窗口、注意力预算和指令优先级为什么会导致 Attention 稀释和“记得还在但遵循不住”，然后把原样堆历史、摘要、结构化状态、按需检索和 checkpoint 放到同一层比较，明确默认应先做上下文装配和状态提炼、而不是一上来就上更重记忆系统，最后讲线上如何监控遗忘、重复、指令漂移与恢复失败。
排查顺序： 先查上下文装配顺序，再查是否混入低价值长材料，再查关键约束是否被结构化提炼，再查模型输出是否已经出现遗忘、重复或指令漂移。
正文对应章节： 05. AI 应用工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。字节后端 Agent 中台一面。百度 AI Agent 开发一面。
APP-03 记忆压缩、摘要保真与初始约束保留¶
核心问题： 上下文放不下时，怎样压缩历史而不把最早的目标、限制条件和关键事实一起压丢。
真题节选： “摘要总结往往会丢失关键细节，在长文本 Agent 中一般怎么来处理这一块？”“当对话轮数极多且上下文窗口严重不足时，如何在不丢失初始 Attention Sink 的前提下保持生成的连贯性？”
常见变体： 摘要为什么经常越压越空。哪些信息适合摘要，哪些必须结构化保留。如何防止最早的系统约束被覆盖。什么约束应该抬到稳定指令层而不是继续留在摘要里。
回答骨架： 先讲压缩目标不是省 token，而是保住业务事实、初始约束和可恢复状态，再把最近轮次保留、运行摘要、结构化状态、长期记忆回写和 checkpoint 放到同一条压缩链里，说明默认应先保稳定指令和关键字段、再压缩低价值历史，而不是把所有历史一把总结掉，再讲去重、语义合并和初始约束上提到规则层或状态层的条件，最后讲摘要质量评估、回滚机制和“摘要失真时如何退回原始证据”。
排查顺序： 先查被压掉的是否是高约束信息，再查摘要是否只保留语义概述而漏掉条件字段，再查长期记忆写回规则，最后查压缩后是否还保留可恢复的结构化状态。
正文对应章节： 05. AI 应用工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。字节后端 Agent 中台一面。字节大模型应用开发一面。
APP-04 长输出、长任务与断点续跑¶
核心问题： 当单次输出超过 max tokens 或任务本身比一次模型调用更长时，系统怎样把生成过程拆成可恢复的执行链。
真题节选： “任务执行远大于单次 Token 限制时，如何设计以支持断点继续生成？”“单次输出超过 max tokens 时，怎样做断点续生成、续跑状态保存和上下文续接？”
常见变体： 长回答为什么不能只靠‘继续’。长任务和长输出的治理边界有什么不同。什么时候必须切后台任务。
回答骨架： 先讲为什么要把长输出和长任务区分开，再把同步返回、流式返回、后台任务和断点续跑放到同一层比较，说明默认方案、切换条件和副作用边界，再讲任务 ID、checkpoint、结构化进度、续跑上下文和取消机制，最后讲失败恢复、人工接管与结果拼接校验。
排查顺序： 先查是否真的命中了 token 上限，再查有没有保存结构化进度，再查续跑时上下文是否接回了正确状态，最后查最终结果是否出现重复、断裂或顺序错乱。
正文对应章节： 05. AI 应用工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。百度 AI Agent 开发一面。字节后端 Agent 中台一面。
后端中间件与基础设施¶
这一组题看有没有把 Agent 后端当成真正的后端系统来做。重点不是会不会背某个语言 API，而是能说明高并发、超时、取消、任务调度、隔离执行和资源治理分别落在哪一层。
INF-01 异步非阻塞与多下游并发模式¶
核心问题： 为什么 Agent 后端通常更适合 I/O 异步模型，以及多模型、多检索通道、多工具并发时应该怎样组织等待、竞速、超时和降级。
真题节选： “调用大模型 API 时，为什么要使用异步编程？”“并发请求多个模型接口时，等全量汇总和谁先返回先消费有什么区别？”“并发调用多个 embedding 或检索接口时，为什么 I/O 异步通常比多线程更省资源？”
常见变体： 为什么 Agent 后端偏爱非阻塞模型。什么时候必须等齐所有结果。什么时候可以用竞速和部分降级。
回答骨架： 先讲 I/O 密集与 CPU 密集的资源模型，再讲证据必须齐全型链路和竞速降级型链路的差异，再讲超时、取消、背压和结果合流，最后讲观测与成本控制。
排查顺序： 先查瓶颈是在网络等待还是 CPU 解析，再查并发模式是否匹配业务语义，再查单路超时与整体超时设置，最后查是否出现资源堆积和尾延迟放大。
正文对应章节： 04. 后端中间件与基础设施、05. AI 应用工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发一面。字节大模型应用开发二面。
INF-02 模型/API 超时、5xx、重试与降级¶
核心问题： 当模型服务、检索服务或业务 API 超时、失败或部分退化时，Agent 后端如何把错误变成受控的运行时行为。
真题节选： “如果 Agent 调用的底层运维 API 发生超时或 5xx 错误，你在工程上是如何实现容错机制的？”“大模型高并发调用时，如何做限流、降级和成本控制？”
常见变体： 什么错误适合重试。什么错误要立即降级。为什么不能把所有失败都交给模型自己解释。
回答骨架： 先讲错误分类和可重试性，再讲重试预算、熔断、限流与降级策略，再讲用户可见收口和人工接管，最后讲 trace、告警和事后回放。
排查顺序： 先查失败发生在模型、工具还是网络层，再查错误类型是否被正确分类，再查重试是否放大了流量和延迟，最后查降级结果是否仍然满足最低可用边界。
正文对应章节： 04. 后端中间件与基础设施、05. AI 应用工程、10. 系统设计模板。
来源样本： 百度搜索 AI Agent 一面。百度 AI Agent 开发一面。字节大模型应用开发二面。
INF-03 任务调度、执行隔离与沙箱¶
核心问题： 当 Agent 需要跑长任务、调用高风险工具或操作外部环境时，系统怎样做调度、隔离和资源约束。
真题节选： “如何实现一个高可用的任务调度器，要考虑哪些方面？”“如果要实现一个代码执行沙箱，你从后端角度如何限制 CPU、内存和网络访问？”“长任务如何暂停、恢复和人工接管？”
常见变体： 任务执行为什么不能直接绑在请求线程上。沙箱和普通工具调用的治理边界在哪里。如何避免一个任务拖垮整个执行集群。
回答骨架： 先讲请求态和任务态的拆分，再讲调度队列、租约、幂等、状态机和取消恢复，再讲执行隔离、资源限额与审计，最后讲人工审批和异常回放。
排查顺序： 先查调度层是否重复派发或丢任务，再查执行隔离是否失效，再查资源限额和网络策略，最后查失败后是否能够恢复状态和追溯动作链。
正文对应章节： 04. 后端中间件与基础设施、05. AI 应用工程、10. 系统设计模板。
来源样本： 百度搜索 AI Agent 一面。字节后端实习 Agent 一面。百度 AI Agent 开发一面。
INF-04 database/sql 连接池、事务边界与超时¶
核心问题： AI 后端一旦把数据库、长任务和模型调用串到一起，为什么连接池参数、事务范围和超时预算会直接决定尾延迟与数据库压力。
真题节选： “database/sql 的池参数为什么会影响延迟和数据库压力？”“事务、超时、重试、幂等为什么总要一起谈？”
常见变体： MaxOpenConns 为什么不是越大越好。事务里为什么不能放外部调用。数据库慢到底是 SQL 问题还是资源问题。
回答骨架： 先讲 sql.DB、sql.Conn、sql.Tx 的角色差异，再讲“平均在用连接数 ≈ 到达率 × 持有时长”这类连接池直觉和 MaxOpenConns、MaxIdleConns、ConnMaxLifetime、ConnMaxIdleTime 在调什么，再讲最小实现路径里如何用 QueryContext、Rows.Close、rows.Err 和短事务收住资源，最后讲 DB.Stats()、慢查询、排队等待、连接泄漏和外部调用拖长事务怎样排查。
排查顺序： 先查看池里是否在排队，再查看事务是否过长，再查看请求取消有没有传到查询层，最后查看是不是外部调用把连接白白占住。
正文对应章节： 03. Go 后端工程、04. 后端中间件与基础设施。
来源样本： 百度 AI Agent 开发一面。字节后端 Agent 中台一面里的后端追问。
INF-05 缓存、消息队列与对象存储的基础设施取舍¶
核心问题： 当系统从“能跑”升级到“能扛量”，如何判断热点读该进缓存、长任务该进消息链路、文件和中间产物该进对象存储。
真题节选： “cache-aside 为什么容易脏，什么时候值得接受？”“上传、解析、索引这条链里哪些东西不该继续放在数据库里？”
常见变体： 缓存是在加速还是在转移压力。消息队列是在保证成功还是在管理异步推进。对象存储和数据库各自应该保存什么。
回答骨架： 先讲重复读、异步推进和大对象承载分别是什么系统问题，再讲 cache-aside/read-through/write-through/write-behind、消息投递与消费位点、对象 key 与生命周期这些最小机制，再讲 TTL、singleflight、热点键、消费积压、死信、预签名直连和冷热分层这些调优抓手，最后讲它们各自最常见的失效模式与切换条件。
排查顺序： 先查数据库是不是在背不该背的压力，再查缓存命中和回源，再查任务是否在同步链里拖住了请求，最后查文件下载与中间产物是不是还在压应用层。
正文对应章节： 04. 后端中间件与基础设施、10. 系统设计模板。
来源样本： 百度 AI Agent 开发一面。字节后端实习 Agent 一面里的后端延展追问。
INF-06 多模型支持、多租户隔离与模型热切换¶
核心问题： 当系统同时支持多家模型供应商、多种模型档位和多租户策略时，怎样保证模型路由可热更新、租户之间互不影响、在途请求不被配置漂移打断。
真题节选： “如何设计多模型支持架构？”“多租户环境下模型切换是否支持热更新？切换是否相互独立？”“后端 Agent 是否支持多租户同时调用？”
常见变体： provider adapter 应该抽到哪一层。租户为什么不能共用一份全局模型配置。模型切换怎么做到新请求生效、旧请求不漂移。
回答骨架： 先讲 provider adapter 把 Generate/Stream/Embed/RunTools 收成稳定能力接口，再讲 tenant_id + task_type + risk_level + modality 这一类路由键、模型策略快照和限额控制，再讲配置 watch、copy-on-write 或原子快照如何支撑热更新且不影响在途请求，最后讲租户隔离、灰度发布、失败回退和成本治理。
排查顺序： 先查问题出在 provider 适配层还是路由层，再查租户策略是否串了配置，再查热更新是否污染在途请求，最后查模型降级和回退路径是否真的生效。
正文对应章节： 05. AI 应用工程、10. 系统设计模板。
来源样本： 字节 agent 开发实习一面。
INF-07 SSE 流式交互、Session/User 绑定与事件协议¶
核心问题： 当 Agent 需要持续推送文本增量、工具调用状态和中间步骤时，怎样定义 SSE 事件协议，并把 session_id、user_id、tenant_id 的边界讲清楚。
真题节选： “SSE 在前后端是如何交互的？”“后端以什么数据格式推送流式信息？”“Agent 发生工具调用时，SSE 推送的事件结构中通常包含哪些字段？”“Session 和 User ID 是如何绑定的？”
常见变体： SSE 只是 event/data 文本流，为什么还要定义 envelope。 session_id 能不能当授权对象。工具事件为什么要单独打 tool_call_id、step_id 和 status。
回答骨架： 先讲 SSE 在一次请求生命周期里扮演什么角色，再讲 message.delta、tool.call.started、tool.call.completed、error 这类事件对象和最小字段，再讲 user_id/tenant_id 来自鉴权与服务端 session store、session_id 只负责状态归属，再讲断连取消、背压、heartbeat 和下游模型流如何一起收口，最后讲 trace 对齐与回放。
排查顺序： 先查事件协议是否稳定，再查会话绑定和权限来源，再查断连是否真正向下游取消，最后查工具事件与文本事件是否还能在 trace 里对齐。
正文对应章节： 03. Go 后端工程、05. AI 应用工程、08. Agent 工程。
来源样本： 字节 agent 开发实习一面。
RAG 工程¶
这一组题问的是能不能把离线建库、在线检索、线上治理和评测闭环讲成同一个系统。检索不准、引用不稳、冲突证据难处理的问题，都要回到这条主线。
RAG-01 复杂 PDF 版面理解与 OCR 噪声治理¶
核心问题： 面对工业 PDF、图文混排、多栏排版和 OCR 噪声时，怎样先保住结构，再把它们变成可检索证据。
真题节选： “工业 PDF 解析中，复杂版面如何做版面理解并还原结构？”“工业 PDF 一般图文分离，你是如何实现版面解析并保留文档逻辑结构的？”“OCR 结果有噪声或错误时，你是怎么做纠错或提升解析质量的？”
常见变体： 为什么多模态 RAG 常常先死在解析层。结构错了为什么后面再强的检索也救不回来。OCR 噪声为什么会污染关键词通道。
回答骨架： 先讲传统 OCR、版面理解、结构抽取和 MinerU 类保真解析分别解决什么问题，再讲当前默认路线为什么不是只做 OCR，什么条件下必须切到结构保真解析，再讲噪声如何影响 BM25、embedding 和引用，最后讲解析质量评估与回流修正。
排查顺序： 先查源文档和版面识别是否错层，再查 OCR 文本是否脏，再查结构化输出是否丢标题、字段或图表关系，最后查错误是如何继续污染切块和索引的。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发一面。字节大模型应用开发二面。
RAG-02 跨页长表格语义合并与结构归一化¶
核心问题： 跨页长表格为什么不能只按视觉块切开，以及怎样在解析阶段完成行延续识别、表头继承和语义合并。
真题节选： “MinerU 解析出的 Markdown 如果遇到跨页的复杂长表格，如何做语义合并的？”“跨页长表格为什么要在解析阶段做语义合并？”
常见变体： 表格跨页时哪些信息最容易丢。为什么跨页表格问题本质上是结构一致性问题。这一步为什么会影响切块和引用定位。
回答骨架： 先讲跨页表格的主键其实是结构连续性而不是视觉连续性，再讲表头继承、行延续、跨页语义合并和结构归一化，再讲字段抽取、BM25 通道和引用定位怎样依赖这一步，最后讲如何校验合并质量。
排查顺序： 先查跨页处是否被错误切断，再查表头和行号是否被继承，再查归一化后的表结构是否还能回指原页码，最后查检索召回是否已经受损。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-03 固定长度切块 vs 递归字符切片¶
核心问题： 为什么递归字符切片通常比固定长度切块更稳，以及这两者分别适合什么文档形态。
真题节选： “在 RAG 中，递归字符切片相比固定长度切片优势在哪？”“长文档为什么一定要切 chunk 再做向量化？不切会有什么问题？”
常见变体： 切块是语义组织还是纯长度控制。标题、段落和限制条件为什么要尽量保在一起。什么时候固定长度仍然够用。
回答骨架： 先讲切块是在做信息组织，再把固定长度、递归切片和文档结构优先三条路线放在一起比较，说明默认起步方案与切换条件，再讲不同文档类型的取舍，最后讲切块如何影响召回和引用。
排查顺序： 先查问题是切得太碎还是切得太粗，再查标题和正文是否分离，再查块内是否混入多个主题，最后查错误切块如何传导到 rerank 和生成阶段。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发一面。字节大模型应用开发二面。
RAG-04 chunk overlap 的作用、比例与引用定位¶
核心问题： 为什么切块时常常要保留重叠区域，以及 overlap 过大或过小分别会怎样影响召回、去重和引用。
真题节选： “chunk 切分时为什么要有重叠区域？比例一般怎么确定？”“切片时设置重叠区域的作用是什么？这个比例你通常怎么来确定？”
常见变体： overlap 是为了补语义断裂还是为了提升分数。为什么 overlap 太大也会害人。引用定位为什么会受 overlap 影响。
回答骨架： 先讲 overlap 解决的是边界被切坏的问题，再讲比例如何受文档类型、平均块长和引用需求影响，再讲重复召回与上下文污染的代价，最后讲去重和引用回溯。
排查顺序： 先查是否因为边界切断导致漏召回，再查 overlap 是否过大造成重复块泛滥，再查去重策略，最后查引用落点是否已经偏移。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-05 增量索引与局部更新¶
核心问题： 文档发生局部更新时，怎样只重建受影响的解析、切块和索引单元，而不是把整库全部重刷一遍。
真题节选： “文档发生了局部更新，如何做增量索引而不是全量重建？”“如果文档发生了局部更新，如何通过增量索引来避免全量重新向量化？”
常见变体： 更新边界应该落在页、块还是字段。为什么局部更新会牵出版本和引用一致性问题。如何避免旧块和新块并存。
回答骨架： 先讲增量更新的最小单元和版本策略，再讲解析结果、切块结果、向量索引和关键词索引怎样联动更新，再讲删除与失效标记，最后讲引用一致性和回滚。
排查顺序： 先查更新检测是否命中正确范围，再查新旧块切换是否原子，再查缓存和 rerank 索引是否同步刷新，最后查用户看到的引用是不是还指向旧版本。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-06 稀疏召回、稠密召回与 BM25 的工程定位¶
核心问题： 企业检索为什么不能只讲向量，而必须把关键词信号、编号信号和字段信号也单独留出来。
真题节选： “稠密向量和稀疏向量的区别是什么？各自适合什么场景？”“讲一下稠密向量与稀疏向量的区别，分别适合处理什么样的搜索需求？”“BM25 是在全文上做还是在特定 Key-Value 字段上做？”
常见变体： BM25 为什么比 TF-IDF 更适合企业检索。哪些问题更依赖关键词通道。字段级 BM25 和全文 BM25 怎么取舍。
回答骨架： 先讲稀疏与稠密表示的信号差异，再写出 BM25 的最小公式并解释 IDF、词频饱和和长度归一化，再讲 k1、b、倒排索引、分词、停用词、同义词和字段加权如何共同决定效果，再把 BM25、稠密召回、字段化检索和全文检索放在一条选型线上说明默认路线和切换条件，最后讲稀疏通道失效、向量通道失效和合流失败各该怎么查。
排查顺序： 先查问题更像关键词检索还是语义检索，再查关键词索引是否覆盖关键字段，再查 embedding 是否能表达同义关系，最后查两路召回是否在后面正确合流。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-07 Hybrid search、Top-K、rerank 与 cutoff¶
核心问题： 在线检索为什么不是只做一次向量相似度，而是关键词、向量、过滤、精排和截断的分层组合。
真题节选： “是否做过关键词召回和向量召回的融合？具体怎么做的？”“向量检索中 Top-K 设置过大或过小分别会带来什么问题？”“为什么需要 rerank 模型？它解决了向量召回的哪些问题？”“rerank 之后的截断策略是怎么设计的？”
常见变体： Hybrid search 的分数怎么对齐。为什么 Top-K 不是越大越保险。 rerank 到底在解决什么问题。
回答骨架： 先讲过滤边界和两路召回，再讲 Agent 里为什么检索只该在证据缺口出现时触发，而不是每轮固定扫库，再把“直接进模型”“加大 Top-K”“上 rerank”“调 cutoff”放在同一层比较说明默认路线和切换条件，再讲通道内 Top-K、RRF 或分数归一化、cross-encoder rerank、batch、序列截断长度和最终 cutoff 的实现与调优，最后讲检索工具输出契约怎样影响排序、引用和后续状态更新。
排查顺序： 先查过滤是否已经过早漏掉候选，再查关键词和向量召回是否都工作，再查 rerank 输入是否过脏或过多，最后查 cutoff 是否把真正关键证据截掉。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发一面。字节大模型应用开发二面。字节 agent 开发实习一面。
RAG-08 HyDE 与 query 模糊时的召回增强¶
核心问题： 用户问题本身很短、很模糊或没有关键检索词时，怎样先把 query 扩成更容易召回的中间表示。
真题节选： “HyDE 在 query 模糊时是如何提升召回效果的？”“了解 HyDE 吗？介绍一下原理，它在处理模糊提问时有哪些优势？”
常见变体： 为什么用户 query 经常比知识库写法更口语。 HyDE 适合什么场景，不适合什么场景。 query 扩写会不会带来偏题风险。
回答骨架： 先讲 query 模糊导致的召回缺口，再讲 HyDE 通过假设性答案扩 query 的思路，再讲它与重写、澄清、关键词扩展的区别，最后讲偏题风险和评测方式。
排查顺序： 先查原 query 是否真的缺检索信号，再查扩写是否把问题引偏，再查扩写后的召回候选质量，最后查 rerank 是否还能把错误扩写纠回来。
正文对应章节： 06. RAG 工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-09 冲突证据融合与无召回防胡编¶
核心问题： 当检索结果相互冲突或根本没检到证据时，系统应该怎样显式收口，而不是让模型自由发挥。
真题节选： “如果检索结果中存在冲突信息，如何设计自动选择或融合逻辑？”“如果检索到了针对同一故障的两份手册，内容相互冲突，请设计一套逻辑，让模型能够识别冲突并优先选择时效性更高的信息。”“RAG 中如果没有召回到相关知识，如何约束模型避免胡编？”
常见变体： 冲突信息该选最新的还是最权威的。没召回到内容时该拒答还是继续生成。为什么 RAG 不能彻底消灭幻觉。
回答骨架： 先讲证据优先级、时效性、版本和权威性判断，再讲冲突显式化与融合策略，再讲无召回时的拒答和降级边界，最后讲日志留痕与评测回流。
排查顺序： 先查冲突来自源数据还是召回拼接，再查版本和时效字段是否齐全，再查生成阶段是否尊重了冲突标记，最后查无召回时是否仍然放任模型补全。
正文对应章节： 06. RAG 工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-10 GraphRAG 与超长上下文时代的 RAG 定位¶
核心问题： 当问题更偏实体关系推理，或者模型已经支持超长上下文时，RAG 的定位会怎样变化，GraphRAG 又在什么情况下值得引入。
真题节选： “GraphRAG 在处理 Agent 复杂关联查询时的优势在哪里？”“超长上下文模型出现后，RAG 架构的必要性是否会下降？”“随着超长上下文模型的出现，你认为传统 RAG 架构的必要性是否降低了？”
常见变体： GraphRAG 是不是普通 RAG 的替代品。超长上下文是不是意味着以后不用建库了。关系型增强为什么成本更高。
回答骨架： 先讲普通 RAG、GraphRAG 和超长上下文直塞分别在解决什么问题，再讲为什么默认不该直接上更重的 GraphRAG 或纯长上下文方案，以及什么时候才值得切换，再讲收益、成本、更新复杂度和适用边界，最后讲线上治理差异。
排查顺序： 先查问题是不是关系型问题，再查普通检索是否已经足够，再查图结构构建和更新成本，最后查是否真的值得为少量问题引入更重的链路。
正文对应章节： 06. RAG 工程、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-11 embedding 模型选型¶
核心问题： embedding 选型到底在比较什么，为什么不能只看榜单分数。
真题节选： “embedding 模型选型时要考虑哪些指标？”“高维向量会带来什么问题？”
常见变体： 维度越高是不是越好。多语种和领域适配如何权衡。吞吐、价格和时延为什么会反过来影响召回链设计。
回答骨架： 先讲 embedding 在召回链里负责什么，再讲语义质量、维度、吞吐、价格、时延、多语种和领域适配这些核心指标，再讲“向量数 × 维度 × 每维字节数”这类成本直觉和高维向量对存储、索引、缓存的代价，再讲最小选型验证路径与离线、线上评测指标，最后讲什么时候该换模型而不是继续调后处理。
排查顺序： 先查问题是不是模型本身语义表达不足，再查维度和索引成本是否压垮系统，再查语料域不匹配，最后查是不是过滤、切块或 rerank 层的问题被误归给 embedding。
正文对应章节： 06. RAG 工程。
来源样本： 百度 AI Agent 开发一面。快手 AI 应用开发二面。
RAG-12 query rewrite、多 query 与 HyDE¶
核心问题： 当原始 query 表达过短、过口语或缺少检索锚点时，怎样做 query 改写与扩展，又怎样防止把问题引偏。
真题节选： “query rewrite / 多 query 扩展的原理是什么？有什么风险？”“HyDE 在 query 模糊时是如何提升召回效果的？”
常见变体： rewrite、多 query、HyDE 到底分别补哪种召回缺口。 query drift 为什么危险。何时该先澄清而不是先扩写。
回答骨架： 先讲原始 query 可能缺哪些检索信号，再讲 rewrite、多 query 和 HyDE 三条路线分别在补哪种缺口、最小实现对象是什么，以及默认起点和切换条件，再讲 query drift、Recall@K 回归、失败回退和主动澄清边界，最后讲如何判断问题更该扩写还是更该反问用户。
排查顺序： 先查原 query 是否真的缺检索锚点，再查扩写是否引入偏题，再查扩写后的召回质量，最后查 rerank 与最终答案是否继续放大了 drift。
正文对应章节： 06. RAG 工程、05. AI 应用工程。
来源样本： 百度 AI Agent 开发一面。百度搜索 AI Agent 一面。字节大模型应用开发二面。
RAG-13 HNSW、IVF、PQ 与在线更新¶
核心问题： 向量索引为什么会直接影响召回、内存和时延，以及在线更新时怎样避免“索引能查，但数据已经不是同一个版本”。
真题节选： “HNSW 的核心结构是什么？为什么查询效率高？”“IVF、PQ、HNSW 的区别和适用场景？”“向量索引如何支持高并发查询和在线更新？”
常见变体： efSearch 调大意味着什么。 HNSW 为什么快但更吃内存。在线更新为什么会牵出版本一致性和缓存刷新。
回答骨架： 先讲 HNSW、IVF、PQ 各自的核心结构和查询路径，再讲 M、efConstruction、efSearch、nlist、nprobe、子量化器这类关键参数在调什么，再讲向量原始存储和索引额外开销的成本直觉，最后讲在线更新、灰度切换、缓存同步和新旧索引一致性如何收住。
排查顺序： 先查问题是索引召回不够还是排序不够，再查参数是否调得过保守或过激，再查在线更新是否让新旧索引混用，最后查缓存与引用映射是否同步刷新。
正文对应章节： 06. RAG 工程。
来源样本： 百度 AI Agent 开发一面。
RAG-14 多模态接入链路、图像识别取舍与知识库查询工具 IO¶
核心问题： 当 Agent 同时要处理图片、表格、扫描件和文本知识库时，怎样把多模态接入链、检索链和工具输入输出讲成一条统一主线，以及为什么很多系统不会一上来就直接用多模态大模型兜底。
真题节选： “RAG 的主要模式和主要工作流程是怎样的？”“Agent 一般在什么阶段去查询向量知识库？通过什么方式去查询？”“查询知识库的工具函数，其标准输入和输出是什么？”“系统如何实现图像识别等多模态功能？”“为什么不直接使用多模态大模型？”“在没有前端界面的情况下，本地图片是如何传到后端并进行识别的？”
常见变体： 本地图片为什么常走 multipart/form-data 或预签名上传。知识库查询工具为什么不能只返回一段自由文本。 OCR、结构抽取、视觉特征和多模态模型各该放在哪一层。为什么很多工业系统默认先做结构保真解析再决定要不要上多模态模型。
回答骨架： 先讲原件入库、对象存储、OCR/版面解析、结构抽取、索引写入和在线检索这条多模态主链，再讲知识库查询工具的标准输入输出契约和在 Agent 里触发检索的时机，再讲“结构化解析 + 混合检索”与“直接用多模态大模型精读”两条路线的默认方案、切换条件和成本差异，最后讲引用、版本、错误回退和多模态链路排障。
排查顺序： 先查文件入口和媒体元数据是否稳定，再查 OCR 或结构抽取是否保住关键字段，再查检索工具输出是否足够结构化，再查多模态模型是不是被错误地用来兜解析问题，最后查引用和版本回跳是否还能对上原始资料。
正文对应章节： 05. AI 应用工程、06. RAG 工程、08. Agent 工程。
来源样本： 字节 agent 开发实习一面。百度 AI Agent 开发一面。百度搜索 AI Agent 一面。
Tool Calling 与 MCP¶
这一组题考受控执行链。需要把”模型产出一个结构化建议”与”服务端真的执行了一个有副作用的动作”清楚地隔开，再把多工具、多协议接入时的一致性治理补齐。
TC-01 Function Calling 的执行边界¶
核心问题： 模型生成结构化参数之后，后端怎样把它变成真实可控的执行链，而不是把 JSON 当成自动执行指令。
真题节选： “介绍一下 Function Call 原理，模型生成的 JSON 如何通过逻辑触发表层代码执行并返回给模型？”“模型生成的 JSON 为什么不能直接等于真实执行？”
常见变体： Function Calling 和 Tool Calling 的边界是什么。模型到底负责建议还是负责执行。为什么服务端必须继续握着执行权。
回答骨架： 先讲自由文本建议、Function Calling 和受控工作流节点分别处在哪一层，再按“模型建议 -> schema 校验 -> 服务端补参 -> 权限与风险分级 -> 工具执行 -> 结果标准化 -> 模型总结或 SSE 回传”把完整业务流程讲一遍，再讲参数补全、审批插点和失败分类，最后讲 trace、回放与统一 envelope 怎样落地。
排查顺序： 先查模型建议是否选对工具，再查参数是否合法，再查执行层权限和副作用控制，最后查结果回灌是否足够结构化以支持后续总结。
正文对应章节： 07. Tool Calling 与 MCP、05. AI 应用工程。
来源样本： 字节大模型应用开发一面。字节大模型应用开发二面。百度搜索 AI Agent 一面。字节 agent 开发实习一面。
TC-02 JSON 不规范时的服务端兜底¶
核心问题： 当模型输出的 JSON 不合法、不完整或夹杂多余自然语言时，后端如何兜住而不把脏输出直接交给执行层。
真题节选： “Agent 输出 JSON 不规范时，后端如何做兜底处理？”“如果模型输出中有多余的说明文字，你在后端如何提取？”
常见变体： 不规范 JSON 是不是说明 prompt 失败。什么时候适合修复，什么时候必须拒绝执行。为什么兜底逻辑也要做分层。
回答骨架： 先讲 JSON 兜底属于执行控制而不是展示层问题，再讲提取、修复、二次校验和拒绝执行的分层，再讲高风险工具必须走严格校验，最后讲失败样本如何回流优化。
排查顺序： 先查输出是不合法 JSON、字段缺失还是字段越界，再查修复策略是否越权补字段，再查高风险动作是否被拦下，最后查日志里有没有保留原始输出与修复结果。
正文对应章节： 07. Tool Calling 与 MCP、05. AI 应用工程。
来源样本： 百度搜索 AI Agent 一面。字节大模型应用开发二面。
TC-03 MCP vs Skills 与跨协议接入边界¶
核心问题： 当工具来自不同协议、不同团队、不同 server 时，系统如何标准化接入，又为什么标准化接入不等于完成治理。
真题节选： “MCP 与传统 Agent Skills 的区别是什么？”“如何实现在多智能体环境中动态发现并注册跨协议工具？”“多个 MCP server 同时接入时如何治理一致性？”
常见变体： MCP 统一了什么，没统一什么。 Skills 更像工作流包还是协议。 Tool、MCP、Skills 三层到底怎么分。为什么标准化接入之后还要做服务端适配层。
回答骨架： 先讲 Tool 或 Function Calling 解决单次结构化动作建议与执行边界，MCP 解决跨进程或跨系统的标准化接入与能力发现，Skills 解决任务级工作流复用与说明打包，再讲原生工具接口、HTTP 或 SDK 适配和 MCP 的默认起步路线与切换条件，再讲统一适配层、统一 envelope、身份映射和版本治理为什么必须补上，最后讲为什么这些都不替代权限、审批、租户治理和审计。
排查顺序： 先查问题发生在协议接入还是业务治理，再查多 server 输出是否已标准化，再查身份和租户映射，最后查审计、版本和回放能力是否缺失。
正文对应章节： 07. Tool Calling 与 MCP、08. Agent 工程、10. 系统设计模板。
来源样本： 淘天 AI Agent 一面。字节后端 Agent 中台一面。百度 AI Agent 开发一面。
TC-04 候选工具很多时的路由与召回偏差¶
核心问题： 当候选工具规模上百时，怎样设计工具路由、预过滤和召回闭环，避免模型在巨大的工具集合里误选、漏选或重复调用。
真题节选： “当候选工具超过 100 个时，如何设计路由策略？怎么解决检索过程中的召回偏差？”“多工具环境里如何减少无效工具调用和上下文污染？”
常见变体： 工具路由是规则做还是模型做。为什么工具越多越容易上下文污染。如何判断漏掉的是工具发现问题还是策略问题。
回答骨架： 先讲工具元数据和权限先验，再把规则路由、检索式工具发现、LLM Router 和分层路由放在一起比较，说明默认路线与升级条件，再讲候选集控制、失败类型与回流样本如何形成闭环，最后讲离线评测和线上观测。
排查顺序： 先查工具注册元数据是否齐，再查候选集预过滤是否过早漏掉工具，再查模型路由与规则路由的分工，最后查失败样本有没有回流到工具索引与评测集中。
正文对应章节： 07. Tool Calling 与 MCP、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。字节后端 Agent 中台一面。
TC-05 schema description engineering¶
核心问题： 工具 schema 里的 description 为什么会直接影响模型选工具和填参数的准确率，以及它应该写到什么程度。
真题节选： “在定义 Function Calling 的工具 Schema 时，如何通过优化 description 字段来显著提高调用准确率？”“如何进行负向约束或提供调用策略？”
常见变体： description 是注释还是契约。负向约束为什么有用。为什么参数名正确仍然会误调工具。为什么 description 其实是工具选择和参数抽取的控制面。
回答骨架： 先讲 description 不是注释，而是模型和外部能力之间的控制面或 agent-computer interface，再讲用途说明、适用场景、前置条件、负向约束、参数抽取提示和调用策略这几类内容，再给出一个“坏 description / 好 description”的对比例子，说明默认应先把边界写清、而不是只继续加字段，最后讲如何通过误调样本、调用成功率和离线评测迭代 schema。
排查顺序： 先查工具是不是选错了，再查 description 是否没有写清边界，再查字段抽取提示是否含糊，最后查是不是候选工具集合本身就过大或过脏。
正文对应章节： 07. Tool Calling 与 MCP。
来源样本： MiniMax 大模型 Agent 二面。百度 AI Agent 开发一面。
TC-06 Tools / MCP / Skills / 开发型 Agent 能力边界¶
核心问题： 当系统同时具备工具调用、MCP 接入、Skills 复用和开发型 Agent 能力时，如何区分哪一层在负责接入、哪一层在负责任务复用、哪一层在负责治理。
真题节选： “Tool Calling、MCP、Skills 分别在解决什么问题？”“为什么 Skills 不是 MCP，为什么它们都不能替代权限与审计？”“开发型 Agent 的 rules、memory、tools、skills、review 该怎么分层？”
常见变体： coding agent 为什么和业务 agent 属于同一类运行时。 rules、memory、tools、skills、review 为什么不能混成一层。为什么接了 MCP 仍然不等于有了治理。
回答骨架： 先讲单次工具调用、标准化接入和任务级复用分别是什么系统问题，再讲 rules / memory / tools / skills / review 在开发型 Agent 里的边界，并说明它和业务型 Agent 只是任务对象不同，再讲默认轻方案为什么通常是原生工具或轻适配而不是一开始全上重栈，最后讲治理仍然要回到权限、审批、租户、审计和人工 review。
排查顺序： 先查问题是在接入层、任务复用层还是治理层，再查是不是把 skills 当协议、把 MCP 当治理了，再查开发型 Agent 的规则和记忆是否越权扩张，最后查 review 和审批边界是否缺失。
正文对应章节： 07. Tool Calling 与 MCP、08. Agent 工程。
来源样本： 淘天 AI Agent 一面。MiniMax 大模型 Agent 二面。Anthropic / Claude 官方 blog 常见判断链。
TC-07 MCP client/server 连接、协商、调用与回传时序¶
核心问题： 当 Agent 通过 MCP 接入外部能力时，宿主 runtime、MCP client 和 MCP server 分别在负责什么，连接、能力发现、调用和结果回传又是怎样串起来的。
真题节选： “MCP 的交互流程是怎样的？”“Agent 如何与 MCP Server 连接通信？”
常见变体： 为什么不是模型直接和 MCP server 对话。 capability discovery 和普通 SDK 初始化有什么不同。为什么 connect -> initialize -> capability discovery -> route -> call -> normalize -> return 这条时序必须和治理层分开理解。
回答骨架： 先讲宿主 runtime、MCP client、MCP server 三层分别接哪一段复杂度，再讲连接、初始化、能力协商、路由决策、协议调用、结果标准化和模型回灌这条时序，再讲 transport、身份映射、统一 envelope 和错误分类，最后讲 MCP 只解决标准化接入，不替代租户、审批和审计。
排查顺序： 先查连接与初始化，再查 capability discovery 和路由，再查协议调用与返回值，再查宿主 runtime 的标准化和治理层是否把权限、租户、审计补齐。
正文对应章节： 07. Tool Calling 与 MCP、05. AI 应用工程、08. Agent 工程。
来源样本： 字节 agent 开发实习一面。
Agent 工程¶
这一组题考是否真的把 Agent 看成运行时系统。回答时至少要把目标、状态、工具、观察、停止条件、记忆分层和治理机制讲出来。否则容易沦为”会说 ReAct、不会解释运行时”的空答案。
AG-01 长短期记忆、摘要记忆、结构化状态与元记忆¶
核心问题： 在 Agent 知识闭环里，哪些信息应该进入长期记忆，哪些只适合留在短期上下文，哪些应该沉淀为更稳定的系统规则或模板，而不是临时对话材料。
真题节选： “在 Agent 知识闭环中，如何决定哪些信息进入向量数据库，哪些进入上下文窗口，哪些直接转化为模型权重的元记忆？”“Agent 中长短期记忆如何设计？各自存什么，怎么触发读取？”
常见变体： 完整历史持久化和本轮可见记忆有什么区别。什么才算元记忆。为什么线上系统不能把改模型权重当即时记忆。
回答骨架： 先讲短期工作记忆、摘要记忆、结构化状态、长期可检索记忆和元记忆或规则层的分层，再把“生命周期、写入触发、读路径、时效性和是否可被程序直接消费”讲成本质区别，再讲默认把什么放哪一层、什么条件下需要升级到长期或下沉到规则层，最后讲写入与读取触发条件、时效权重和评估治理。
排查顺序： 先查写进去的是稳定事实还是临时中间态，再查读取触发是否过宽或过窄，再查长期记忆是否污染短期上下文，最后查是否把本该写规则层的东西误塞进对话记忆层。
正文对应章节： 08. Agent 工程、05. AI 应用工程。
来源样本： 淘天 AI Agent 一面。百度搜索 AI Agent 一面。字节后端 Agent 中台一面。百度 AI Agent 开发一面。字节 agent 开发实习一面。
AG-02 记忆冲突更新与多 Agent 共享/隔离¶
核心问题： 多轮对话、多个 Agent、多个工具同时写状态时，系统怎样避免记忆互相打架、互相污染或把临时 scratchpad 错当成稳定记忆。
真题节选： “多轮对话中，如果不同轮次的记忆发生冲突，你如何处理？”“在多 Agent 协作系统中，不同 Agent 之间的记忆如何实现隔离与共享？如何避免不同工具间的上下文污染？”
常见变体： 为什么共享一切通常比不共享任何东西更危险。共享什么、隔离什么。冲突时按时间、置信度还是角色来裁决。
回答骨架： 先讲记忆作用域和共享边界，再讲时间戳、版本号、置信度和角色优先级，再讲共享摘要与私有 scratchpad 的划分，最后讲审计、回放和租户边界。
排查顺序： 先查冲突来自多轮对话还是多执行者写入，再查作用域和版本控制，再查冲突仲裁规则是否明确，最后查共享摘要是否已经把私有中间态错误暴露给其他 Agent。
正文对应章节： 08. Agent 工程、10. 系统设计模板。
来源样本： 淘天 AI Agent 一面。百度搜索 AI Agent 一面。字节大模型应用开发一面。字节大模型应用开发二面。
AG-03 ReAct 的工程实现¶
核心问题： ReAct 在工程里到底怎么落地，怎样把“推理-行动-观察”写成可治理的运行时闭环，而不是提示词演示。
真题节选： “你设计的 Agent 是怎么实现 ReAct 模式的？详细讲讲。”“详细讲讲你设计的 Agent 是如何实现的？”
常见变体： ReAct 为什么只是设计范式之一。什么时候适合 ReAct，什么时候更适合 workflow 或规划器。观察结果为什么必须写回状态。为什么不能把 ReAct 当默认总范式。
回答骨架： 先讲目标、状态、工具、观察和停止条件这条最小闭环，再给出一版 ReAct 运行时伪代码，说明状态回写、循环上限、重复调用检测和止损点在哪里，再把 Sequential 或 Routing workflow、ReAct、Plan-Then-Act 和 Planner/Executor 放在同一层比较，说明为什么默认应先上更轻模式而不是直接让模型全程自主决策，最后讲高风险节点的人类审批、失败收口和升级信号。
排查顺序： 先查目标和成功条件是否清楚，再查每轮观察是否真的写回状态，再查停止条件和循环上限，最后查工具结果结构化是否不足以支撑下一步判断。
正文对应章节： 08. Agent 工程、07. Tool Calling 与 MCP。
来源样本： 字节后端 Agent 中台一面。百度搜索 AI Agent 一面。百度 AI Agent 开发一面。
AG-04 Thought Loop、无效工具调用与止损机制¶
核心问题： Agent 在执行过程中为什么会陷入思维死循环、重复工具调用或逻辑塌缩，以及怎样做运行时止损。
真题节选： “在‘推理-行动’循环中，如何设计来纠正逻辑塌缩或无效工具调用？”“Agent 在什么情况下容易陷入思考死循环？”“面对模型在 Agent 执行过程中出现的循环调用或陷入思维死循环问题，有哪些解决方式？”
常见变体： 重复回答到底是 prompt 问题还是状态问题。无效工具调用为什么常和观察结果脏有关。什么时候要直接终止而不是继续试。
回答骨架： 先讲 loop 的常见成因：目标不清、状态不收束、工具结果不结构化、停止条件缺失，再讲去重、循环上限、反思检查和失败收口，最后讲人工接管和异常回放。
排查顺序： 先查状态有没有真实更新，再查工具结果是否被正确解释，再查停止条件和去重规则，最后查模型是否在低价值上下文里反复自证。
正文对应章节： 08. Agent 工程、07. Tool Calling 与 MCP。
来源样本： 淘天 AI Agent 一面。百度搜索 AI Agent 一面。百度 AI Agent 开发一面。
AG-05 reflection 的定位、收益与代价¶
核心问题： reflection 在运行时里到底解决什么问题，应该放在哪些节点上，以及它为什么不是“开了就更聪明”的万能增强。
真题节选： “什么是 Agent 的反思机制？”“对于你的心理咨询 Agent，有没有让模型在回答前先检查一遍自己的语气是否专业？”
常见变体： reflection 和普通多轮 prompting 有什么不同。它更适合回答前还是工具后。为什么反思可能让系统更慢更保守。
回答骨架： 先讲 reflection 是运行时自检，再把 reflection、retry、approval、interrupt/resume 等相邻治理机制区分开，说明它为什么不能替代别的手段，再讲高风险回答前、关键工具调用后和格式复核这几个典型插点，最后讲步数、延迟、保守化倾向与何时值得开启。
排查顺序： 先查需要反思的是语气、合规、格式还是事实，再查反思是否插在正确节点，再查反思是否导致重复推理，最后查它是否真的降低了目标风险而不是只增加延迟。
正文对应章节： 08. Agent 工程。
来源样本： 字节大模型应用开发二面。百度 AI Agent 开发一面。
AG-06 Planning 能力、Hallucination Rate 与轨迹评测¶
核心问题： 除了看最终答案像不像，怎样量化 Agent 的计划能力、执行质量、幻觉率和运行时稳定性。
真题节选： “如何衡量 Agent 的 Planning 能力 vs Hallucination Rate？请列举具体的量化评估指标或自动化评估框架。”“Ragas 评测中，如果检索精度高但答案相关性低，最可能的瓶颈在哪？”
常见变体： Agent 评测为什么不能只看单轮正确率。 planning 和 hallucination 为什么要分层看。 trace 评测和答案评测的边界是什么。
回答骨架： 先讲任务成功率、计划完成率、工具调用正确率和事实支撑率等分层指标，再讲轨迹回放、人工抽检和回归集，再讲与 RAG 指标的接口，最后讲优化方向如何根据指标分层定位。
排查顺序： 先查失败是计划偏航还是证据不足，再查工具调用和状态迁移是否正确，再查答案事实支撑，再查评测集是否覆盖真实失败模式。
正文对应章节： 08. Agent 工程、06. RAG 工程、10. 系统设计模板。
来源样本： 淘天 AI Agent 一面。字节大模型应用开发二面。阿里、字节、百度相关面经里的评测追问。
AG-07 LangGraph state、checkpoint、interrupt/resume¶
核心问题： 图运行时里的 state、checkpoint 和 interrupt/resume 分别在解决什么问题，为什么它们不能被简单地理解成“多存一点上下文”。
真题节选： “LangGraph 的状态对象怎么设计的，如何避免在多轮迭代中 State 序列化变得过于缓慢？”“LangGraph 的 state、checkpoint、interrupt/resume 分别解决什么问题？”
常见变体： checkpoint 保存的到底是什么。 durable execution 和普通对话续聊有什么不同。为什么不是所有历史都该直接塞回模型上下文。
回答骨架： 先讲图运行时里的显式状态对象，再把普通链式流程、图状态机、checkpoint 和 interrupt/resume 放在同一层比较，说明为什么这里需要 state graph 而不是继续堆上下文，再讲状态对象如何控制序列化成本、checkpoint 该保存什么不该保存什么，最后讲恢复路径和人机协同。
排查顺序： 先查状态对象是否膨胀，再查 checkpoint 是否保存了可恢复最小状态，再查恢复时是否把 scratchpad 错回灌给模型，最后查 interrupt 后的人工写回路径是否完整。
正文对应章节： 08. Agent 工程。
来源样本： 字节大模型应用开发二面。百度 AI Agent 开发一面。
AG-08 A2A / Multi-Agent 的状态同步与递归防控¶
核心问题： 当多个 Agent 通过 handoff 或 A2A 协作时，怎样定义状态交接边界和终止机制，避免它们彼此递归对话、重复派单或无限回跳。
真题节选： “谈谈对 A2A 通信的理解。在 A2A 场景下，如何防止两个 Agent 陷入递归对话？”“如果将你的 Agent 拆分成多 Agent，你认为状态同步的难点在哪？”
常见变体： 多 Agent 最大的问题是通信协议还是治理。 handoff 和共享记忆有什么区别。 orchestrator-workers 和真正 Multi-Agent 的边界在哪。为什么 hop 限制和任务 ID 去重必须同时存在。
回答骨架： 先讲多执行者协作中的 handoff、共享状态、共享记忆和显式消息通信分别是什么，再把 orchestrator-workers workflow、supervisor-worker 和真正的 Multi-Agent 或 A2A 放在同一层比较，说明默认为什么不该直接上更重的多执行者运行时，再讲 hop 或 step 上限、任务 ID、状态版本和显式终止信号，最后讲角色边界、失败恢复和人工接管。
排查顺序： 先查是不是同一个任务在回跳，再查状态版本是否冲突，再查角色边界和终止信号，最后查两个 Agent 是否因为共享了错误摘要而互相放大偏差。
正文对应章节： 08. Agent 工程、10. 系统设计模板。
来源样本： 字节大模型应用开发一面。字节后端 Agent 中台一面。百度 AI Agent 开发一面。
AG-09 CoT vs Planning¶
核心问题： 为什么 CoT 只是把推理写出来，而 Planning 是在产出可执行任务表，这两者在恢复、回滚和追踪上的价值完全不同。
真题节选： “请阐述 CoT 与 Planning 的本质区别。为什么说 CoT 只是把推理写出来，而 Planning 是生成可执行任务表？”
常见变体： CoT 能不能替代计划。为什么计划更适合长任务。 workflow、planning 和 agent 三层到底什么关系。什么时候只要局部推理，不需要完整 planning。
回答骨架： 先讲 CoT 和 Planning 各自产出的对象是什么，再分别举出“自由推理文本”和“带 step_id 的可执行计划”两个最小例子，再讲 workflow、planning 和 agent 在控制权上的层级关系，说明为什么 planning 只是比 workflow 更重一层的执行组织，而不是所有任务都要直接上 agent，最后讲它们在恢复、回滚、评测和可执行性上的差异以及切换条件。
排查顺序： 先查系统现在缺的是局部推理还是步骤组织，再查计划是否真的被结构化保存，再查执行是否按计划对齐，最后查失败后有没有恢复入口。
正文对应章节： 08. Agent 工程。
来源样本： MiniMax 大模型 Agent 二面。
AG-10 规划失败恢复¶
核心问题： 多步工具任务中，一个子步骤失败以后，系统怎样决定局部重试、回滚、重规划还是人工接管。
真题节选： “在处理一个需要多步工具调用的复杂任务时，如何设计一个鲁棒的规划机制来应对中间步骤失败？”“请描述具体的重试、回滚或重规划策略。”
常见变体： 计划失败和执行失败怎么分。为什么不是所有失败都从头来过。已经产生副作用的步骤怎么收。
回答骨架： 先讲失败发生在计划层、执行层还是观察层，再把“局部重试 / 参数修复 / 重规划 / 补偿 / 人工接管”写成清晰的恢复分支，再讲 checkpoint 与状态机如何支撑恢复，最后讲副作用边界为什么决定你不能所有失败都从头再来。
排查顺序： 先查是哪一层失败，再查是否有可恢复 checkpoint，再查重试是否越过了副作用边界，最后查重规划是否真的缩小了问题而不是重复生成自然语言。
正文对应章节： 08. Agent 工程、07. Tool Calling 与 MCP。
来源样本： MiniMax 大模型 Agent 二面。百度 AI Agent 开发一面。
AG-11 长期记忆工程¶
核心问题： 长期记忆为什么不能只是“把历史都塞进向量库”，以及向量库、图数据库和结构化存储分别承载什么。
真题节选： “请深入剖析大模型 Agent 的长期记忆模块。”“你会如何设计记忆的存储结构、更新策略和检索机制来确保记忆高效和准确？”
常见变体： 什么该进向量库，什么该进图数据库，什么该落结构化字段。为什么长期记忆需要去重、TTL 和冲突仲裁。时效性为什么和语义相关性一样重要。
回答骨架： 先讲向量数据库、图数据库和结构化存储各自承载哪类记忆，再讲写入触发、合并、去重、TTL、遗忘和来源可信度，再讲“语义相似度 + 新鲜度 + 来源可信度”这类长期记忆排序心智，最后讲长期记忆与短期状态如何分层以及何时不该入长期。
排查顺序： 先查写进去的是不是稳定知识，再查去重和 TTL 是否失效，再查检索是否被旧记忆污染，最后查长期记忆是不是被误当成当前问题的充分证据。
正文对应章节： 08. Agent 工程。
来源样本： MiniMax 大模型 Agent 二面。淘天 AI Agent 一面。百度 AI Agent 开发一面。
AG-12 超长历史下的记忆查询优化¶
核心问题： 历史对话远超上下文窗口时，怎样兼顾查询效率、保真和执行连贯性。
真题节选： “当历史对话记录非常长时，你有哪些策略来优化记忆的查询效率并保证关键信息不丢失？”“请比较滑动窗口、总结压缩、向量检索等不同方案的优劣。”
常见变体： 为什么不能只说截断。滑动窗口、摘要、状态、向量检索和交接快照怎样组合。什么情况下该从堆历史切到建状态。
回答骨架： 先讲滑动窗口、总结压缩、结构化状态、向量检索和交接快照分别解决什么问题，再讲默认组合路线和切换条件，再讲效率、保真、噪声回流和恢复能力之间的取舍，最后讲如何验证关键约束没有在压缩里被吞掉。
排查顺序： 先查问题是效率不够还是保真不够，再查最近轮次和关键状态是否被保住，再查长期检索是否拉回了旧噪声，最后查交接快照和恢复链是否完整。
正文对应章节： 08. Agent 工程、05. AI 应用工程。
来源样本： MiniMax 大模型 Agent 二面。淘天 AI Agent 一面。百度 AI Agent 开发一面。
AG-13 Workflow vs Agent 与模式升级路径¶
核心问题： 什么时候任务还应该停留在 workflow，什么时候才值得升级到 Agent，以及从轻模式到重模式的正确升级顺序是什么。
真题节选： “workflow 和 agent 的边界是什么？”“Sequential、Routing、Parallel、Evaluator-optimizer、Orchestrator-workers 各适合什么问题？”“为什么不该一上来就上 Multi-Agent 或重规划？”
常见变体： Agent 是不是比 workflow 更高级。为什么轻模式往往更稳。升级信号应该看任务复杂度、状态复杂度还是治理成本。
回答骨架： 先讲 workflow 的路径主要由代码预设、agent 的下一步由模型根据观察动态决定，再把 Sequential、Routing、Parallel、Evaluator-optimizer、Orchestrator-workers、ReAct、Planner/Executor、Graph、Multi-Agent 放成一条升级链，说明默认轻方案、为什么不直接上更重模式、以及每一档各自的失效模式，最后讲升级信号、治理前提和何时应该回退到更轻的实现。
排查顺序： 先查任务本身是不是路径稳定问题，再查系统复杂度主要来自入口分流、并行拆分还是中途动态决策，再查当前模式的失败是否真能靠升级解决，最后查团队是否已经具备状态、评测、审批和恢复能力去承接更重运行时。
正文对应章节： 08. Agent 工程、05. AI 应用工程、10. 系统设计模板。
来源样本： MiniMax 大模型 Agent 二面。百度 AI Agent 开发一面。Anthropic / Claude 官方 blog 常见判断链。
AG-14 Agent 状态机、关键状态对象与组件编排¶
核心问题： 当面试官追问“Agent 里到底有哪些组件、有哪些状态、记忆/工具/RAG 是怎么串起来的”时，怎样把运行时对象、状态机和组件边界讲成一条完整控制线。
真题节选： “Agent 的记忆、工具调用、知识库检索等关键组件是如何实现的？”“系统中的 Agent 包含哪些具体状态？”
常见变体： 为什么 Agent 不该只有聊天历史。 goal / slots / current_step / evidence / approval / checkpoint 这些状态对象各在解决什么问题。记忆、RAG 和工具调用为什么应该按同一条状态机编排。
回答骨架： 先讲 Agent 最小状态机里的目标、状态、工具、观察、停止条件，再把 session meta、user/tenant policy snapshot、working memory、structured slots、current plan、tool registry、evidence bag、approval state、checkpoint refs 这组关键对象讲清，再讲记忆、RAG 和工具调用如何围绕同一份状态推进，最后讲状态膨胀、重复执行、恢复路径和人工接管怎么治理。
排查顺序： 先查状态对象是不是缺字段或膨胀，再查记忆、RAG 和工具结果有没有统一写回状态，再查停止条件和审批状态，最后查恢复点和人工接管路径是否完整。
正文对应章节： 08. Agent 工程、05. AI 应用工程、07. Tool Calling 与 MCP。
来源样本： 字节 agent 开发实习一面。
系统设计与项目表达¶
这一组题考的是能不能把前面所有知识收束成”我做过什么、系统怎么跑、为什么这样设计、出了问题先查哪里”。讲不出系统规模、核心链路、关键优化和治理边界时，前面学过的知识点很难真正转化成面试表达。
SD-01 项目介绍里的系统规模、核心链路与关键优化¶
核心问题： 介绍项目时怎样让面试官快速看见你的责任边界、系统规模、核心链路、关键优化和真实上线信息。
真题节选： “自我介绍，重点讲清系统规模、你负责的核心链路和做过的关键优化。”“Agent 项目是实习项目还是个人项目？有没有上线？”
常见变体： 项目介绍为什么不能只讲技术栈。怎么证明自己不是只做了 demo。什么叫把 ownership 讲清楚。
回答骨架： 先讲业务目标和系统规模，再讲自己负责的链路和关键瓶颈，再讲做过的优化和指标变化，最后讲上线状态、失败教训和后续规划。
排查顺序： 先查自己是不是在讲业务名词而不是系统链路，再查指标和责任边界是否具体，再查优化是否能对上真实瓶颈，最后查是否把项目说成了提示词试玩。
正文对应章节： 12. 面试表达模板、10. 系统设计模板、11. 项目驱动学习法。
来源样本： 百度搜索 AI Agent 一面。字节后端 Agent 中台一面。百度 AI Agent 开发一面。
SD-02 设计一个导购、咨询或 AIOps Agent¶
核心问题： 面试官给你一个开放场景时，你能不能把感知、规划、记忆、执行、审批、风控、观测和评测讲成一条分布式链路。
真题节选： “设计一个智能导购助手 Agent？描述其感知、规划、记忆和执行四大模块在分布式架构下的协同逻辑。”“介绍一下 AIOps Agent 的任务编排逻辑与工具调用链路。”
常见变体： 场景题为什么不能从 prompt 开始答。不同业务场景下哪些模块是共性的。审批和人工接管该放在哪一层。
回答骨架： 先讲业务目标和输入输出，再讲状态模型、工具体系和规划执行，再讲记忆、审批、风控和长任务治理，最后讲 trace、评测、租户边界和故障恢复。
排查顺序： 先查是否先把业务目标讲清，再查运行时闭环是否完整，再查高风险节点和人工接管，再查观测、评测和恢复链是否缺失。
正文对应章节： 10. 系统设计模板、08. Agent 工程、05. AI 应用工程。
来源样本： 淘天 AI Agent 一面。字节大模型应用开发一面。百度搜索 AI Agent 一面。
SD-03 Agent 中台、MCP 平台与多团队接入¶
核心问题： 当题目从“做一个助手”升级成“做一个平台”时，系统应该怎样从单条业务链路扩展到能力注册、统一治理和多团队复用。
真题节选： “Agent 中台和单个 Agent 应用的区别是什么？”“MCP 平台题应该从哪些模块回答？”“多团队接入时平台组件如何分层？”
常见变体： 平台题为什么考的是治理能力而不是功能堆叠。能力注册、运行时编排和审计分别放哪。为什么 MCP 仍然只是接入层。
回答骨架： 先讲业务目标与租户边界，再讲能力接入、统一适配和运行时编排，再讲状态记忆、审批风控和观测评测，最后讲故障恢复、回放与复用价值。
排查顺序： 先查是不是把平台题答成单个助手功能题，再查接入层和治理层是否混淆，再查状态、审批和审计能力，最后查多团队复用和版本治理是否被漏掉。
正文对应章节： 10. 系统设计模板、07. Tool Calling 与 MCP、08. Agent 工程。
来源样本： 字节后端 Agent 中台一面。百度 AI Agent 开发一面。
SD-04 高并发 AI 搜索系统与技术选型表达¶
核心问题： 当系统设计题明确追问 QPS、P95、索引规模、缓存、灰度和 A/B 时，怎样把 AI 搜索系统讲成一条能落指标的工程链。
真题节选： “设计一个高并发 AI 搜索系统，核心模块怎么划分？”“缓存如何设计？如何提升命中率？”“AI 系统如何做灰度发布和 A/B 实验？指标怎么定？”
常见变体： 为什么不能只讲检索与模型。峰值流量和索引规模为什么会反过来影响技术选型。灰度和评测为什么要一起讲。
回答骨架： 先讲 QPS、P95、数据规模、索引规模和更新频率，再讲入口、检索、模型、缓存、存储和治理模块，再把 query cache、embedding cache、result cache、Top-K、rerank 和模型并发预算这些关键参数放进主链里说明为什么这样配，最后讲灰度发布、A/B、评测指标与回滚。
排查顺序： 先查瓶颈在入口、检索、模型还是缓存，再查热点查询与索引更新是否冲突，再查灰度是否真的可观测，最后查是不是把整体慢错怪给单个组件。
正文对应章节： 10. 系统设计模板、12. 面试表达模板、06. RAG 工程。
来源样本： 百度 AI Agent 开发一面。MiniMax 大模型 Agent 二面。
SD-05 AI 框架选型：Spring AI、LangChain、LangGraph、Eino 的分层与切换条件¶
核心问题： 当面试官直接追问“为什么选 Spring AI”“对 LangChain 了解多少”“什么时候该换 LangGraph 或 Eino”时，怎样把框架题答成分层判断，而不是社区站队。
真题节选： “为什么选择 Spring AI 框架？”“Spring AI 框架的主要优势是什么？”“对其他主流 AI 框架如 LangChain 有了解吗？”
常见变体： 框架到底是在替你接模型适配、能力编排还是状态治理。为什么现有宿主生态会反过来决定默认起点。什么时候从轻量能力拼装升级到显式状态图或 Go 原生运行时。
回答骨架： 先讲宿主生态、状态复杂度、恢复需求和治理边界这四个选型轴，再把 Spring AI、LangChain、LangGraph、Eino 分别放回模型接入层、能力拼装层、状态图运行时和 Go 侧组件/runtime 分层上解释，接着说明当前默认方案为什么适合现阶段约束，最后讲升级信号、切换成本和不该切换的场景。
排查顺序： 先查当前难点到底在模型适配、能力组合还是状态治理，再查宿主语言和现有工程基线，再查热更新、观测、checkpoint 等需求是否已经超出当前框架边界，最后查是不是把本该靠业务设计解决的问题误甩给了框架。
正文对应章节： 05. AI 应用工程、08. Agent 工程、12. 面试表达模板。
来源样本： 字节 agent 开发实习一面。