06 · AI Agent 全栈面试真题库（2026 大厂版）

来源：牛客真实面经（字节/阿里/淘天/美团/快手/腾讯/Shopee/月之暗面/智谱/MiniMax/蚂蚁）+ LangGraph 专项 + 2026 面试趋势复盘。 用法：每题先自己答（出声），再对答案。标 ★新 = 01 题库没覆盖、本次新增的高频题；标 ⛓接项目 = 可以直接结合 AI 小灵 / ContentBuddy 项目作答的题。 与 01 的关系：01 是「按你的项目出题 + 两周每日清单」；本篇是「大厂普适题库 + 2026 新考点」，两篇交叉复习。 2026 风向一句话：已经从"会搭 Agent"变成"生产级工程化能力"——死循环兜底、成本延迟、评测体系、可观测、降级回滚，是拉开差距的地方。 结构：共 10 章 57 题。其中 第九章「性能优化、高并发与稳定性」（46–57 题）是本次新增的重点章——从"能跑通"到"能扛量"的分水岭，含 TTFT 优化、并发调度、Prompt/KV 缓存、RAG 检索性能、FastAPI 并发调优、成本账、压测容量、限流降级、黄金指标与问题定位方法论。 前端工程化补充：第十章快问快答区新增微前端（qiankun 沙箱/样式隔离）与自研组件库（按需引入 / Design Token）速答——简历里写了这两条的必看；详细展开见 02 模块《微前端迁移与自研组件库实战》专章。

一、Agent 概念边界（一面送分 + 钓鱼题）

1. Agent 和 Chatbot 的本质区别？哪些东西不算 Agent？★

答题骨架：

• 本质区别 = 自主决策 + 行动闭环。Chatbot：输入→LLM→文本，被动问答。Agent：输入→推理→决定调工具→执行→观察→再决策→循环直到完成。
• 三个"不算"边界题（面试官爱用来钓鱼）：
  • ChatBot + 插件 ≠ Agent：插件由固定规则触发（关键词路由）只是"带工具的 Bot"；要由模型在多步推理中自主选择工具与参数并形成闭环才是 Agent。
  • RAG + Chat ≠ Agent：单次检索→回答只是"增强型 Chat"；有多轮检索策略（查不到改写查询、拆子问题、交叉验证）才带 Agent 特征。
  • Prompt Chain ≠ Agent：Chain 拓扑是工程侧固定的；Agent 是运行时动态选路、靠 Observation 更新状态。
• 一句话收：判断标准 = 有没有多步自主决策 + 反馈闭环。

2. 画一下 Agentic Loop？终止条件有几个？⛓接项目

答题骨架（要能边说边画）：

User Input → [Think → Act → Observe] × N → Final Output

• 例子（讲一个真实的）：用户"退掉上周五买的书"→ Think(查订单) → Act(call getOrders) → Observe({已发货}) → Think(查退货政策) → Act(getReturnPolicy) → Observe → Act(createReturn) → 收尾回复。
• 终止条件（三选一，必答）：①达到最大步数（如 10 轮）②模型输出终止信号 ③任务完成标志。
• 工程三坑（加分点）：工具结果每轮都塞 context 很快爆 → 结果做摘要/截断；工具失败要让模型看到错误后自己决定重试/换策略/降级，而不是裸抛；加防死循环硬阈值。
• 接项目：AI 小灵的 review 循环就是 Agentic Loop 的确定性变体——write→review→不合格回写，用条件边 + ≤3 轮硬上限终止。

Agentic Loop 图解：

flowchart TD
    Start(["用户输入"]) --> Think["<b>Think 推理</b><br/>LLM 分析当前状态，决定下一步"]
    Think --> Decide{"下一步做什么？"}
    Decide -->|"需要外部信息 / 执行动作"| Act["<b>Act 执行</b><br/>调用工具 / API / 检索 / 代码"]
    Act --> Observe["<b>Observe 观察</b><br/>把工具返回结果写回上下文"]
    Observe --> Term{"终止条件检查"}
    Decide -->|"信息已足够"| Term

    Term -->|"① 产出最终答案"| End(["返回结果"])
    Term -->|"② 达到最大轮次上限"| Force["<b>强制收束</b><br/>用已有信息生成答案"]
    Term -->|"③ 检测到无进展 / 重复动作"| Abort["<b>中断降级</b><br/>转人工 或 抛错"]
    Force --> End
    Abort --> End
    Term -->|"未满足，继续循环"| Think

    style Think fill:#dae8fc,stroke:#6c8ebf
    style Act fill:#d5e8d4,stroke:#82b366
    style Abort fill:#f8cecc,stroke:#b85450

读图要点：三个终止条件是本题的采分点——① 正常产出答案；② 达到最大轮次（硬阈值兜底）；③ 检测到无进展 / 重复调用（防死循环）。 ⚠️ 生产环境的答案必须包含 ②③。只答 ① 会被追问"那模型一直调工具怎么办"——这正是区分"会搭 Demo"和"上过生产"的地方。

3. ReAct 和 Plan-and-Execute 的区别？生产怎么选？★

答题骨架：

• 工业界最常用 = 混合：大步骤用 Plan-and-Execute 规划，子步骤内部用 ReAct。
• 加分真实案例：一个订单查询 Agent 用纯 ReAct，查完顺手"了解"用户全部历史订单，3 步任务跑 12 轮——后来改成"意图明确走 Plan、模糊走 ReAct"。

4. 什么场景不该用 Agent？★（反向题，专钓过度设计的人）

答题骨架：固定流程/简单规则能搞定、低延迟要求、成本敏感、高精度标准化问答、单工具调用 → 单 Agent 甚至不用 Agent。

• 进阶：什么时候不该用多 Agent（连单 Agent 都嫌重）——简单 QA、无多能力需求、无并行需求。
• 一句定调：Agent 的自主性是双刃剑，给太多不可预期，给太少退化成 Chatbot，工程核心是设计安全自主边界。

5. 业界 2026 趋势：单 Agent vs 多 Agent 怎么选？★

答题骨架：

• 单 Agent 优势：简单、延迟低、成本低、模型看全上下文做全局判断；劣势：上下文易爆、长上下文丢早期信息、一个 prompt 塞所有职责变屎山。
• 多 Agent/Router 优势：上下文隔离、子任务单独调优/换模型、可并行、可观测（哪步错了清楚）；劣势：每次多一步网络往返延迟高、token 成倍涨、路由本身可能错。
• 趋势判断（2026 重要观点）：业界在从"花式多 Agent"回归"单个强 Agent + 好工具 + 好的上下文工程"（Claude Code / Cursor / Cline 都是这个范式）。你的项目用多 Agent 必须能回答"相比单 Agent 的实质收益是什么"。
• ⛓接项目：AI 小灵 = 多 Agent 的真实理由——29 场景共享固定节点集、职责天然分离（研究/撰写/审核权限隔离）、需要并行与留痕，不是为炫技。

二、多 Agent 与 LangGraph（二面主战场，最深）

6. 四种多 Agent 模式：Supervisor / Swarm / Hierarchical / Network？怎么选？★

答题骨架（必背对照表）：

• 关键表述：Supervisor = 集中控制（决策权始终在主管，子 Agent 只执行不回路由）；Swarm = 去中心化协作（路由开销摊到 Agent 自己的 LLM 调用上）。
• 一句话选型轴：延迟预算、路由决策复杂度、团队可扩展性。
• ⛓接项目：AI 小灵 supervisor 是"中心主管拆活→专精子 Agent 执行→回主管验收汇总"，子 Agent 无路由权，保证内容生产可预测可留痕。

Supervisor 架构流转图解（本文采用的中心化模式）：

sequenceDiagram
    autonumber
    participant U as 用户
    participant S as Supervisor（主管）
    participant R as research Agent
    participant W as write Agent
    participant V as review Agent
    participant St as 共享 State

    U->>S: 提交任务
    Note over S: 查「场景注册表」<br/>动态决定走哪条链路（新场景零改图）
    S->>St: 写入任务与分流决策
    S->>R: 派发：检索资料
    R->>St: 只回写自己负责的字段（检索结果）
    R-->>S: 完成
    S->>W: 派发：撰写初稿
    W->>St: 回写草稿 + revision 计数
    W-->>S: 完成
    S->>V: 派发：审核
    V->>St: 回写审核意见（passed / 需修改）
    V-->>S: 返回结论
    alt 审核未通过 且 revision < 3
        S->>W: 退回修改（带审核意见）
    else 审核通过
        S->>U: 输出最终结果
    else 超过 3 轮仍未通过
        S->>U: 转人工审核（HITL）
    end

读图要点：中心主管模式的关键特征是——子 Agent 之间不直接通信，也没有路由权，全部经由 Supervisor 调度。 三大优势：① 可观测（每一步都过主管，便于打点）；② 可控（主管可施加轮次上限等硬约束）；③ 易扩展（新增子 Agent 只改注册表，不动其他 Agent）。 对比记忆：Swarm 是去中心化（Agent 之间直接移交），灵活性高但难观测、易失控；Hierarchical 是主管之上还有主管（多级），适合超大任务域。

7. 为什么用 LangGraph 而不是 LangChain Agent / LCEL Chain / CrewAI？★⛓接项目

答题骨架（三连对比，背熟）：

• vs LangChain Chain/LCEL：Chain 是线性固定流水线，无全局状态、无分支循环、不可持久化；LangGraph 是 State 状态机驱动，支持条件分支、循环、断点续跑、状态快照。一句话：Chain 是写死的步骤脚本，LangGraph 是带大脑、能判断能循环能纠错的智能流程。
• vs LangChain Agent（AgentExecutor）：Agent 是"循环式思考→行动"，路径由模型自由发挥不可控、黑盒难调、0.x→0.2.x 版本地狱；LangGraph 把流程变成显式状态图——可预测、可调试、可回放。
• vs CrewAI：CrewAI 角色任务导向、固定协作模板、开箱即用但自定义路由/循环/状态管控弱，适合标准化任务；LangGraph 底层状态机编排、无模板、任意自定义，量产复杂系统选 LangGraph。
• 结论金句：简单标准化选 CrewAI/Chain，复杂、量产、高可控必须 LangGraph。

8. LangGraph 多 Agent 之间到底怎么通信？数据怎么流转？★⛓接项目

答题骨架：核心是全局 State 共享 + 边路由调度——Agent 之间不点对点直连，全部读写统一全局状态；前序 Agent 把结果/日志/状态写进 State，经普通边/条件边流转，下游读最新 State 执行再回写。收益：解耦、可追溯、可持久化。

• 顺带澄清一个高频误区：你（多 Agent）之间"除了汇总没别的通信"？如果只是固定 Router 分发、Agent 无自主决策/互相调用，业界定义这叫 Workflow 不叫 Multi-Agent（Anthropic《Building Effective Agents》定调）。被问就诚实承认 + 说清"我这个场景需要的是可控流程而非自由协作，硬套多 Agent 定义没意义"。
• ⛓接项目：AI 小灵 = 状态图里每个节点只读写自己职责字段（研究写 research 区、审核写 verdict 区），字段隔离避免数据污染。

9. StateGraph vs MessageGraph？多 Agent 用哪个？★

答题骨架：MessageGraph 只维护消息列表，所有节点输出合并为消息，无法字段隔离，只适合简单对话；StateGraph 支持自定义结构化 State、字段级读写隔离、精准数据管控，生产多 Agent 强制 StateGraph。

• 追问（字段级隔离怎么实现）：State Schema 里定义每个字段 + 哪些节点可写哪些字段（给节点配 reducer/权限），结构上杜绝跨域覆盖。
• 追问（并行写同一字段怎么防丢）：自定义 Reducer 追加合并（messages 用 operator.add，业务字段用自定义 merge），默认覆盖模式并行必丢数据。

10. 子 Agent 挂了怎么办？重试几次？退避多久？还失败呢？★（字节真实追问链）

答题骨架（要答出"分层策略"，不能只说"会重试"）：

• 重试层：最多 N 次（如 2-3 次），指数退避（1s/2s/4s），只对可重试错误重试（超时/5xx），4xx/参数错不重试。
• 降级层：重试仍失败 → 返回结构化错误或降级结果（如"检索失败，跳过此部分"），不能让单个子任务失败拖垮整个任务。
• 并行降级正确写法：asyncio.gather(*tasks, return_exceptions=True)——否则一个子任务抛异常全部被终止；拿到结果逐个检查 Exception 实例分别处理。同步 invoke 放进 gather 不会真并发，要用 ainvoke。
• 流程层兜底：子 Agent 降级后 Supervisor 要感知（读 agent_results 里的 status 字段），决定跳过该模块、用默认值还是转人工。
• ⛓接项目：AI 小灵审核不达标回写重写 ≤3 轮、超限降级走"人工确认 + 风险提示"输出——这就是完整兜底链。

11. 怎么防止多 Agent 死循环 / 无限重试？★（必考工程题）

答题骨架：迭代次数硬上限 + 超时阈值双兜底（LangGraph: recursion_limit；自研：max_rounds）。单靠"模型判断完成"不可靠。

• 四个高频线上 BUG + 根治（背这个清单很加分）：
  1. 状态覆盖污染（并行同字段）→ Reducer 追加合并 + 字段隔离
  2. 死循环雪崩（迭代无终止）→ 最大迭代次数 + 超时双兜底
  3. 任务重复抢占（分布式）→ 状态任务锁 + 执行标记
  4. 调度分配错误（路由规则模糊）→ 结构化 Prompt + 量化评分规则
• 记忆口诀：丢数加合并、循环加阈值、抢活加锁、错配加规则。
• ⛓接项目：审核循环 ≤3 轮的 3 就是这个硬阈值；add_conditional_edges 的映射务必留 default: END（未匹配字符串运行期直接崩）。

12. 两个子 Agent 结论矛盾，Writer 怎么合并？★（字节真实追问）

答题骨架：矛盾不能靠"取平均"——设计冲突消解规则：

• 事实类冲突：带时间戳/权威源者优先（营收数字以财报接口为准，不以 Agent 摘要为准）；
• 观点类分歧：保留分歧 + 标注置信度，交给汇总层/评审 Agent 裁决；
• 结构兜底：评审对抗模式——执行 Agent 生成 + 评审 Agent 四维校验（准确性/合规/完整/逻辑）输出标准化修改意见，条件边回跳，≤N 轮，超限输出最优结果 + 风险提示。
• 一句定调：多 Agent 的价值之一就是把"矛盾显性化"，靠规则/仲裁而非祈祷模型自己发现。

13. 多 Agent 用同一个模型吗？要不要模型分级？★⛓接项目

答题骨架：生产视角必须按职责分级（这是"有没有生产思维"的分水岭）：

• 意图识别/路由：小模型（快、便宜，Qwen3-7B 级）
• 复杂推理/汇总输出：强模型（需要语言组织与长程推理）
• 后台异步摘要/低实时性：最便宜的档位
• ⛓接项目：直接讲 ContentBuddy/AI 小灵的 fast/strong 档位设计——fast 档做分类/抽取/检索，strong 档做审核/创作，LLM_MODE 切 mock/real 做测试，这就是模型分级的完整回答。

14. 如何测试一个多 Agent 系统？会查哪些 failure mode？★

答题骨架：单测（每个 node 函数）+ 图级测试（完整跑通、路由是否正确、状态是否按预期更新）+ 边界测试。

• Failure mode 清单（背几条）：死循环/超限、子 Agent 全挂、工具返回空/超大、并行写状态丢数据、路由误判（进错子 Agent）、上下文超限、模型输出非 JSON、内容不合规未拦截。
• 加分：可重放（replay）调试——把 trace 存下来，出问题用同一输入回放，是 LangGraph 项目的大加分项。
• ⛓接项目：AI 小灵 130+ TDD 用例怎么设计的？先写 node 级单测 → 再写图级集成测试 → 关键路径（审核回写循环）专项测试。

15. LangGraph 条件边（conditional edge）是什么？★

答题骨架：= 路由函数 + 返回值到下游节点的映射表。graph.add_conditional_edges(source, routing_fn, {"call_tool": "tool_node", "finish": END})。执行顺序：source 跑完 → 运行时拿 state 调 routing_fn → 按返回字符串查映射表跳转。路由函数是普通 Python 函数，不强制跑 LLM。

• 生产注意：映射表里没写的返回串 = 运行期崩溃（不是编译期报错）→ 加 "default": END。
• 经典用法：tool-calling loop——agent 节点调 LLM，路由函数查最后一条消息有没有 tool_calls，有→tool 节点（跑完回 agent），没有→END。

三、记忆与上下文工程（月之暗面/腾讯/快手必考）

16. 记忆怎么分层设计？长期记忆要每轮注入吗？★

答题骨架（分层模型必背）：

• 工作记忆：当前任务轨迹 + 中间结论（LangGraph 的 State/checkpoint）
• 会话记忆：最近几轮原文 + 较早历史 rolling summary（滚动摘要）
• 长期记忆：用户偏好、任务事实、历史结论 → 向量库/结构化库，相似度 + 时间衰减 + 重要性召回
• 写入质量（高分点）：区分"事实 vs 推断"、附时间戳和来源、支持更新与撤销、矛盾检测、相似合并。
• 长期记忆不每轮全量注入——只注入与当前 query 相关的召回结果，否则上下文快速爆掉且引入噪声。

⚠️ 必答的高频追问：checkpointer 和 store 有什么区别？（这是 LangGraph 面试的分水岭题，很多人会混为一谈）

维度	Checkpointer	Store
作用域	单线程（per thread_id）	跨线程（cross-thread）
存什么	图的完整状态快照（每步 State）	语义化的长期记忆条目（KV + 向量检索）
主要用途	中断恢复、时间旅行、重放、HITL	用户偏好、跨会话事实积累
典型实现	MemorySaver / AsyncPostgresSaver / MysqlCheckpointSaver	InMemoryStore / AsyncPostgresStore（支持 store.search()）
类比	数据库的事务日志	数据库的业务表

面试话术："短期记忆是靠 checkpointer 按 thread_id 存状态快照，它的核心价值是让图能中断后恢复；跨会话的长期记忆则用 store（BaseStore），它支持按 namespace 检索。两者职责不同，不能互相替代。"

flowchart TD
    subgraph L1["🧠 工作记忆（单次任务内）"]
        State["LangGraph State<br/>当前任务轨迹 + 中间结论"]
        CP[("Checkpointer<br/>按 thread_id 存快照<br/>MemorySaver / PostgresSaver")]
        State <-->|"每步自动持久化<br/>支持中断恢复 / 时间旅行"| CP
    end

    subgraph L2["💬 会话记忆（同一会话内）"]
        Recent["最近 N 轮原文<br/>（保留细节与指代）"]
        Summary["滚动摘要 rolling summary<br/>（更早历史压缩）"]
        Recent -.->|"超出窗口后压缩"| Summary
    end

    subgraph L3["📚 长期记忆（跨会话）"]
        Store[("Store / BaseStore<br/>跨 thread 共享")]
        Vec[("向量库<br/>用户偏好 / 任务事实 / 历史结论")]
        Store <--> Vec
    end

    Query["当前用户 query"] --> Retrieve{"按需召回"}
    Retrieve -->|"相关度 + 时间衰减 + 重要性"| L3
    Retrieve --> L2
    L1 --> LLM["拼装成 Prompt 送入 LLM"]
    L2 --> LLM
    L3 -->|"只注入 Top-K 相关条目<br/>⚠️ 不全量注入"| LLM

    style L1 fill:#dae8fc,stroke:#6c8ebf
    style L2 fill:#fff2cc,stroke:#d6b656
    style L3 fill:#d5e8d4,stroke:#82b366

读图要点：三层记忆不是层层全量叠加——长期记忆只召回 Top-K 相关条目注入，否则上下文会瞬间爆掉并引入噪声。这是面试官最爱追问的点。

17. 上下文窗口满了怎么办？优先保留什么、压缩什么？★

答题骨架：接近上限时按价值排序——

• 保留：系统指令、当前任务、关键约束、工具调用结果（事实锚点）
• 压缩：低价值历史对话（先做摘要，摘要也满再做层级摘要：会话级→日级→周级）
• 兜底手段：滑动窗口（最近 N 轮原文）、摘要压缩（rolling summary）、关键信息抽取存入长期记忆、Compaction（历史太长老裁不动时的重写/浓缩）
• 加分概念：Lost in the middle——LLM 对上下文中间位置信息注意力显著低于首尾（长上下文精度下降的学术解释），所以关键指令放首尾、中间塞低价值内容。

18. 短期记忆存 Redis、长期记忆存哪？TTL 是坑吗？★（模拟面试真实翻车题）

答题骨架：记忆数据 ≠ 可被自动 evict 的缓存。面试官原话级别的点：Redis TTL 是为高并发线上业务设计的，用户记忆是最宝贵资产，过期应该 archive（归档）而不是 delete。

• Redis 在 Agent 项目里的正确用途：模型响应缓存、检索结果缓存、分布式锁（多 Agent 并发写同一份记忆）、会话状态隔离、限流、临时 checkpoint。
• 长期记忆落持久化存储：向量库 / 图库 / 关系库（pgvector、Chroma、Neo4j、MySQL/PG 都行）。

19. 工具返回超大结果（如 50KB 代码搜索结果）怎么处理？★

答题骨架：直接塞上下文 → 爆窗口 + 注意力稀释 + token 烧钱。处理链：

1. 源头截断：工具层做结果上限（top-K 限制、字段裁剪）
2. 摘要压缩：大结果先过一次摘要/提炼再进上下文
3. 分段按需：先回元信息（文件名列表），LLM 需要再取具体内容
4. 结构化错误：超限时返回"结果过大已截断为前 N 条 + 计数"，让模型知道信息不完整

四、RAG 深度（最高频硬技能，必须能扛 5 连追问）

20. 混合检索（BM25 + 向量）结果怎么融合？在哪个环节赢？★（淘天真实追问）

答题骨架：

• 为什么混合：向量抓语义但漏精确词/专名（订单号、型号、人名），BM25 精确匹配但不懂同义改写——两路召回互补。
• 融合方式三选一：①RRF（Reciprocal Rank Fusion，按排名倒数求和，最常用、无参、稳）②加权分数融合（需要调权/归一化）③级联（先向量粗召回再 BM25/规则精排）。
• RRF 公式（面试可能让你手写，务必记住 k 的取值）：
  $$RRF(d) = \sum_{i \in \text{检索器集合}} \frac{1}{k + rank_i(d)}$$
  其中 rank_i(d) 是文档 d 在第 i 路检索结果中的名次（从 1 开始），k 是平滑常数，业界常用 k = 60（出自 Cormack 等人 2009 年提出 RRF 的原论文）。
  • 为什么要 k：若没有 k，第 1 名的权重是 1，第 2 名骤降到 0.5，头部过于陡峭、对单一检索器的排名过度敏感；加 k=60 后前几名的权重差异被压平，融合更稳健。
  • 为什么"无参"：k 取固定值 60 就有很好效果，不需要针对数据调权重、也不需要分数归一化（这点是它比加权融合更受欢迎的原因——余弦相似度和 BM25 分数量纲完全不同，强行加权要先归一化）。
• 在哪个环节赢：召回阶段混合能显著提升召回率（尤其专名/长尾 query）；但如果你的 query 以语义表达为主、无专名，混合收益小——讲得出这个边界才显真懂。
• 顺带准备：PDF 扫描件要 OCR、表格要结构化提取（转 markdown/HTML 保留结构），这些解析坑是淘天真实追问点。

混合检索 + RRF 融合图解：

flowchart LR
    Q(["用户 Query"]) --> P{"查询预处理<br/>（改写 / 分词 / 扩写）"}
    P --> B["<b>BM25 稀疏检索</b><br/>关键词精确匹配<br/>（擅长专有名词、编号、稀有词）"]
    P --> V["<b>向量稠密检索</b><br/>语义相似匹配<br/>（擅长同义改写、口语化表达）"]
    B --> RB["结果按分数排序<br/>→ 转成名次 rank"]
    V --> RV["结果按分数排序<br/>→ 转成名次 rank"]
    RB --> RRF["<b>RRF 融合</b><br/>score(d) = Σ 1/(k + rank_i(d))<br/>k 取 60"]
    RV --> RRF
    RRF --> TopK["取 Top-K"]
    TopK --> RR["<b>重排 Rerank</b><br/>Cross-Encoder 精算相关性"]
    RR --> LLM["送入 LLM 生成<br/>+ 引用校验"]

    style B fill:#fff2cc,stroke:#d6b656
    style V fill:#dae8fc,stroke:#6c8ebf
    style RRF fill:#d5e8d4,stroke:#82b366
    style RR fill:#ffe6cc,stroke:#d79b00

读图要点（面试必答）：

1. "在哪一步赢"——混合检索的提升发生在召回阶段（Recall 提升），而不在精排阶段。两路召回的候选集互补，能捞回单路漏掉的文档。
2. 为什么用 RRF 而不是加权求和——BM25 分数（无界，可能 0几十）与余弦相似度（-11）量纲完全不同，直接加权需先归一化且要调权重；RRF 只看名次不看分数，天然免归一化、无需调参。
3. k=60 的作用——压平头部差异，避免对单路检索的第 1 名过度信任。

21. 为什么用 RAG 而不用微调？什么时候该微调？★

答题骨架：RAG 适合知识频繁更新（换文档零成本、改一条记录即可）；微调适合固定知识领域 + 改变模型行为/风格/格式能力。RAG 不改变模型能力只注入事实；微调贵、慢、易灾难性遗忘、更新要重训。

• 一句话定调：先 RAG，RAG 解决不了的行为问题（输出格式、领域语言习惯）才考虑微调，二者也常组合（微调格式 + RAG 事实）。

22. 为什么要加 Rerank？它解决向量检索哪些局限？★

答题骨架：向量相似度 ≠ 语义相关性。Rerank 解决的局限：

1. 词汇不匹配（向量可能漏掉语义对但用词不同的片段）
2. 粒度不匹配（chunk 大小不完美）
3. 多跳推理（需要组合多片段才能回答）
4. 时效性（向量检索不感知时间）

• 成本视角（加分）：rerank 是 top-50 粗召回 → 精排到 top-5，是成本与效果的 trade-off——先便宜向量召回，再用贵一点的交叉编码器精排，避免对全库精排。

23. chunk 怎么切？overlap 设多少？父子索引是什么？★

答题骨架：

• 切分依据：按语义边界（段落/标题/代码块）优先于固定字符数；固定大小通常 300-500 token 起调。
• overlap 作用：防信息在切片边界断裂；比例通常 10%-20%，语义连贯性要求高的场景加大。
• 父子索引：子 chunk 用于检索（粒度准），命中后把父 chunk（更大上下文块）喂给 LLM 生成——解决"检索到碎片但答不完整"。
• 增量更新：文档局部改 → 版本号/内容哈希判断只重向量化变更块，软删除旧向量后台清理，不全量重建。

24. 检索 Top-K 设多大？K 太大会怎样？★

答题骨架：K 过大 → 信息过载（不相关内容干扰）、上下文浪费、答案漂移（引入矛盾信息）、延迟增加。实践值：粗召回 K=10-50，rerank 后压到 K=3-5 进生成。调优看评测（命中率/忠实度）不是拍脑袋。

25. 怎么在生成阶段防幻觉？Prompt 边界怎么设？★

答题骨架（要能背几条）：

1. 明确告知检索范围："仅基于以下参考内容回答，不要使用参考内容之外的知识"
2. 要求引用来源："每个结论标注对应参考片段编号"
3. 允许说不知道："参考内容没有相关信息时，明确说明未找到"
4. 给反例（幻觉回答 vs 正确拒答的示例）
5. 结构化输出：先列证据再给结论
6. 系统级兜底：输出后用工具/规则做事实校验、低 temperature

26. Agentic RAG 和朴素 RAG 的区别？GraphRAG 什么时候值得上？★

答题骨架：

• 朴素 RAG：一次检索→一次生成，查不到就答错。
• Agentic RAG：检索本身 Agent 化——查不到改写 query 重查、把大问题拆子问题分别检索、多路交叉验证、判断"该检索还是该调工具还是该拒答"。这是"RAG+Chat 不算 Agent、检索策略化才算"的进阶表达。
• GraphRAG：把实体关系建成图，适合全局性问题（"这些文档讲了哪些主题/实体间什么关系"），普通局部问答用不上——图是成本，不是装饰，数据量小/问题偏局部别上。

27. 向量库怎么选？为什么用 Milvus/Chroma/pgvector 而不是普通数据库？★（模拟面试高频翻车题）

答题骨架：普通 B-tree 索引不适合高维相似度检索（维度灾难、无 ANN），所以需要专门的向量索引（HNSW/IVF）。

• 选型对比维度：部署形态（Milvus 工业级分布式 vs Chroma 单机 embedded）、生态运维（Milvus 全 SDK/监控 vs Chroma 简单生态薄）、替代品（pgvector 本质是 PG 插件——数据量小直接少一套基础设施；Qdrant/Weaviate/Pinecone）、超轻量（sqlite-vec）。
• 高分答法（挑战自己的选型）："我项目这个数据量 pgvector 完全够，不用单独起向量库"——面试官要的是工程判断不是背参数。

五、工具调用 / Function Calling / MCP（字节/淘天必考）

28. 工具调用完整链路？Tool 定义包含哪些要素？★

答题骨架：

• 链路：LLM 分析需求 → 决定调用工具 → 生成 JSON 参数 → 执行（本地函数/API）→ 结果作为 Observation 回传 → LLM 决定下一步。
• Tool 定义要素：名称、功能描述（让模型知道何时用）、入参 JSON Schema（含类型/必填/枚举）、出参格式、调用示例。Schema 不清 → 模型大概率 1/10 场景输出格式错误 JSON。
• 为什么 LLM 能"选对"工具：靠的是描述写得好（什么时候用哪个、参数规则写成 if-then），不是模型有魔法。

29. 工具调用失败怎么处理？（结构化错误）★

答题骨架：不能裸抛异常让模型看到堆栈。做法：对工具调用 try-catch，返回结构化错误信息（{error_code, message, 是否可重试}），模型看到错误后自主决定重试/换工具/降级/告知用户。安全硬隔离：工具层是信任边界——LLM 生成参数不可信，必须做 schema 校验、权限校验、敏感操作需确认。

30. MCP 是什么？解决了什么？它的代价/缺点是什么？★（面经高频）

答题骨架：

• MCP（Model Context Protocol）= Anthropic 推动的开放协议，让模型用统一方式发现资源、读文件、调工具。使用 = 起一个 MCP server + 客户端配置连接 + 模型经协议 tools/list 发现 → tools/call 调用。
• 解决：工具接入标准化（N 个工具 × M 个模型从 N×M 个适配器变成 N+M）。
• 缺点（必须答，忌只吹优点）：多一跳网络延迟；部署与鉴权运维成本；调试链路变长；工具描述要维护。
• 追问：MCP 之前怎么调工具？→ 各家私有 function calling / 插件协议，模型和工具强耦合。
• 追问：MCP 支持流式吗？→ 传输层支持流式（Streamable HTTP 基于 SSE 做服务端→客户端流式），但具体工具是否流式取决于实现。

31. MCP 传输层有哪几种？怎么选？★

答题骨架：官方规范只有两种——stdio（本地进程通信，开发友好）与 Streamable HTTP（远程，2025-03 规范起取代旧的 HTTP+SSE 双端点方案，单端点 + 可选 SSE 流）。选型看部署形态与安全域：本地工具用 stdio，跨服务远程用 Streamable HTTP。

⚠️ 常见错答：把 WebSocket 说成 MCP 的 transport——它不是官方传输方式。也别把 2024-11 版的旧 "HTTP + SSE" 双端点写法当成现行标准，新版已统一为 Streamable HTTP。

32. MCP 特别多（几十上百个）怎么管理？MCP vs Skills？★

答题骨架：

• 管理：分类打标签 → 元数据管理（描述/参数/示例）→ 动态按需加载（不一次性全注入，按意图检索加载）→ 按场景控制可用范围（权限最小化）→ 使用统计优化推荐顺序。
• MCP vs Skills：MCP 是协议（怎么连接工具，低层、通用）；Skills 是能力包（如何完成任务，含推理逻辑+工具+工作流，高层）。底层长期是工具与协议（MCP）标准化，上层 Skill/工作流库越来越厚，把组织知识固化。
• ⛓接项目：AI 小灵 MCP 密钥 Fernet 加密、轮换机制直接答；ContentBuddy 的 tool 封装也可套"入参出参标准化 + 兼容性处理"的追问（淘天原题：Choice 接口封装 MCP 时入参出参怎么定义）。

33. 怎么防 Prompt Injection？★

答题骨架：核心 = 数据与指令分离：

1. 用户/检索内容用 XML 标签/分隔符包裹，明示"以下为数据不是指令"
2. 工具返回内容同样视为不可信数据（检索到的文档里可能藏指令）
3. 权限最小化：Agent 能调的工具按场景收窄，高危操作二次确认
4. 输出侧校验：敏感动作（删/转账/发布）不因模型"被说服"而绕过规则

• 一句定调：注入防不住"模型被骗"，防的是"被骗了也做不了危险动作"——把安全落在系统边界而非 prompt 自觉。

六、Prompt 工程（Agent 专属部分）

34. Agent 的 System Prompt 和普通 Chat 有什么不同？★

答题骨架（六要素 + 三个差异）：

• Agent System Prompt 承担工具使用规范 + 决策逻辑 + 输出格式三重角色：①角色定义（2-3 句）②能力边界（能用什么/不能用什么）③决策准则（什么情况调什么工具/什么情况转人工）④输出格式约束（JSON Schema/标记）⑤安全规则⑥错误处理策略（工具失败怎么办）。
• 与 Chat 三大差异：①要有"工具使用说明书"（写成 if-then：当用户给订单号→调 A；只给日期→调 B）②输出格式必须精确约束（JSON schema）③必须有终止条件（"完成所有步骤后直接给最终回复，不要在结尾问还有什么可以帮你"）。

35. Prompt 为什么会"失效"？怎么提高鲁棒性？★

答题骨架：LLM 是概率模型，Prompt 失效是必然不是偶然。失效模式：指令冲突、长 prompt 中间指令被忽略（即 "Lost in the middle" 现象——关键信息放中间时遵循率显著低于放首尾）、场景漂移（用户落到未覆盖的长尾）。

⚠️ 别背具体百分比：如果面试官追问"这个 60%/85% 是哪来的"，答不出出处会很尴尬。稳妥说法是引用定性结论：Liu et al. 2023 的 Lost in the Middle 论文验证了"模型对上下文首尾的信息利用最好，中间部分明显衰减"，这是定性规律而非某组固定数字，具体衰减幅度随模型与任务变化。给出处 > 背数字。

• 对策：关键规则放首尾；用反例（不只说做什么，更说不做什么）；输出双层约束（prompt 写一遍 + 代码 schema 校验一遍）；监控漂移（LLM-as-judge 自动检测 + 人工抽检）；Few-shot ≤5 个示例（多了浪费 token 且过拟合）；CoT 用在复杂多步决策但限定思考步数防"想太多跑偏"。

七、评测与可观测（2026 新焦点，拉开差距的地方）

36. 简历写"准确率 90%+"，怎么算的？★（必被追问）

答题骨架（三层递进）：

1. 测试集怎么构建（最容易被追问）：覆盖哪几类正常 case + 边界 case + 对抗样本？分布如何？为什么这些 case 能体现你想测的能力？（"随手造了 200 个" vs "5 类常见意图 + 3 类边界 + 2 类对抗样本"是两个档次）
2. 指标：只看准确率？有没有 precision/recall/F1？
3. 自动化：每次改完 prompt 怎么回归？有没有 eval 平台/脚本？（LangSmith/Braintrust/Promptfoo 至少跑过一个）

37. RAG/Agent 评测的核心指标有哪些？（Ragas）★

答题骨架：Faithfulness（忠实度：答案是否忠于检索内容）、Answer relevance、Context precision/recall（召回是否命中）、Groundedness/引用准确率。Ragas = 专做这些的库。金句：没有 evaluation 体系的 Agent 项目就是耍流氓；评测要防"线上真失败 → 变成 eval case → 回归通过 → 上线"这个闭环断掉。

38. LLM-as-Judge vs 确定性评测？Golden dataset 怎么建？★

答题骨架：

• 确定性 code evaluator：JSON schema 校验、正则、工具参数校验——免费、无抖动，能用的地方先用。
• LLM-as-Judge：主观质量（相关性/语气/合规）用模型打分，注意评委模型校准（few-shot correction：人工纠正评委输出回灌）。
• Golden dataset：精选的输入-输出/标注对集合（如数百~数千条），每次改 prompt/模型/链路跑一遍对比实验，分数下降不让上线（可挂 CI 当部署门禁）。

39. LangSmith vs Langfuse 怎么选？★

答题骨架：LangSmith = LangChain/LangGraph 全家桶深度集成（设个环境变量零配置全链路 trace，含节点/边/状态，可 replay 换模型重跑），闭源 SaaS；Langfuse = 开源 MIT（2026 被 ClickHouse 收购）、可自托管、基于 OpenTelemetry 框架无关。选型逻辑：深度用 LangGraph 全家桶 → LangSmith；要自托管/数据主权/不想锁死 → Langfuse。生产从第一天就要 trace——多 Agent 难 debug，每个路由决策、子 Agent 调用、工具调用都要留痕。

40. 线上多 Agent 监控哪些指标？★

答题骨架（背清单）：路由准确率（Supervisor 选对子 Agent 的比例，人工抽评）、子 Agent 成功率、端到端延迟 p50/p95、单请求 token 消耗（对比单 Agent 基线）、错误率（超时/死循环/工具错 per 1000 请求）、成本。可观测平台（LangSmith/Langfuse）里看 trace 树定位是哪一步烂了。

八、生产化与系统设计（高定级题，从"能跑"到"稳跑"）

41. 设计一个企业智能客服 Agent（接入/决策/工具/数据分层）★

答题骨架：

• 接入层：多渠道（Web/App/企微）、会话管理、用户上下文
• 决策层：意图识别 → 路由（能直接答 / 查知识库 / 调订单系统 / 转人工）→ 兜底策略
• 工具层：MCP 统一封装（订单查询、退换货策略、工单创建）、权限与埋点
• 数据层：FAQ 知识库（RAG）、用户/订单数据源、会话记忆存储
• 鲁棒性：工具失败重试降级、情绪识别升级人工（严重情绪不硬聊："我感受到你现在比较着急，让我一步步帮你解决"）、安全边界（退款/删数据等高危动作规则拦截 + 人工确认）
• 加分：说明为什么是 Supervisor 模式（5 个部门专家 → 清晰分类可扩展，下季度加"账单专家"= 加一个节点）。

42. Agent 调用失败/死循环，完整兜底体系怎么设计？（几乎必考）★

答题骨架（三层，不能只说 try-catch）：

1. 工具层：try-catch → 结构化错误返回
2. 推理层：最大迭代次数 + 循环检测熔断，防死循环
3. 规划层：失败后让 Agent 反思重规划（换路径）→ 仍失败走降级

• 配套：**重试（指数退避）→ 降级（部分结果/默认值）→ 人工兜底（HITL）**三级。达到阈值自动终止，输出最优结果 + 风险提示，或转人工审核，保证服务不中断。

43. Agent 成本与延迟怎么控制？★

答题骨架：模型分级（贵模型只做关键推理）、缓存（语义缓存：相同/相似 query 命中缓存）、工具结果压缩（减少上下文 token）、批处理/异步（低实时任务走队列）、控制 ReAct 步数与多 Agent 层数（每多一步 = 多一次往返 + 多一份 token）、检索 K 值压缩。

• 多 Agent 成本账（要会算）：每多一个 Agent/一次路由 = token 成倍 + 延迟增加，这也是"能用单 Agent 别硬上多 Agent"的工程理由。

44. LangGraph 怎么流式输出？节点结果怎么实时推前端？★（淘天原题）

答题骨架：

• 后端 FastAPI + SSE；LangGraph 用 astream_events(..., version="v2") 捕获 on_chat_model_stream（token 级）和各节点完成事件，转发给前端 EventSource。
• 难点：图状态机里每个节点的中间结果（如"正在研究→正在撰写→审核中"）要打点成结构化事件（node 名 + 阶段 + 进度）而不是只推最终答案。
• 对比：WebSocket 双向全双工，SSE 单向服务端推送——Agent 进度是服务端到客户端的单向流，SSE 更轻、原生支持重连，够用不必上 WS。

45. Checkpoint/断点续跑？LangGraph 怎么持久化状态？★

答题骨架：graph.compile(checkpointer=PostgresSaver.from_conn_string(...))，按 thread_id 存状态快照；中断（HITL interrupt）后可用同一 thread_id 恢复继续跑。临时 checkpoint 可用 Redis，永久业务状态落 PG。

• 部署选型：LangGraph Platform（托管：自带 checkpoint/retry/横向扩缩）vs 自托管（FastAPI + LangGraph + PG checkpointer）——数据主权/成本/已有基建决定。
• ⛓接项目：AI 小灵 HITL 人工确认 = interrupt 后状态恢复，直接答 interrupt() → Command(resume=...) 恢复流程。

九、性能优化、高并发与稳定性（2026 必考，拉开档次的地方）★

这一章是"能跑通 Demo"和"能上线扛量"的分水岭。面试官问性能，不要上来就答"加缓存"——正确的开场是：先讲指标体系（怎么量），再讲瓶颈定位（在哪慢），最后才是优化手段（怎么改），并且永远带权衡。

46. LLM 应用的性能指标体系和普通后端有什么不同？★

答题骨架（先给指标，这是专业度的分水岭）：

• TTFT（Time To First Token，首 token 延迟）：用户点下去到看到第一个字的时间——这才是交互体验的真实感知值，也是流式输出的核心收益。
• TPOT / ITL（Time Per Output Token）：吐字间隔，决定"读起来顺不顺"。存在感极强但容易被忽略。
• 端到端总延迟 ≈ TTFT + TPOT × 输出 token 数——注意是乘，输出越长总延迟线性膨胀。
• 吞吐：tokens/s（系统级）、QPS（请求级）、并发会话数。三者不是一回事，报指标必须说清是哪个。
• 成功率：含超时率、上游 429 率、工具失败率——LLM 应用的"错误"大量是软失败（答非所问），要单列。
• 每请求成本 / 每任务 token：LLM 应用必须把成本当性能指标一起看。
• 核心权衡（必答）：延迟与吞吐互斥——批处理（batch）能提高吞吐但抬高单请求延迟；流式能降低感知延迟但不改变总延迟。

追问应对：

• "P99 延迟 5s，但你觉得慢吗？" → 先拆：是 TTFT 慢（体验差）还是输出长（体验可接受）？不拆指标的延迟优化都是瞎猜。
• "在线和离线任务指标一样吗？" → 不一样。在线交互看 TTFT 和 TPOT；离线批处理看吞吐和单位成本，优化目标完全不同。

47. 首 token 延迟怎么优化到 1s 内？★

答题骨架（按链路分段，每段给手段）：

flowchart LR
    A["用户点击"] --> B["网关鉴权<br/>+10~50ms"]
    B --> C["前置处理<br/>意图/路由/检索"]
    C --> D["组装 Prompt"]
    D --> E["上游 LLM<br/>计算首 token"]
    E --> F["SSE 回传<br/>首字节"]

    C -.- C1["串行等检索 = 大坑<br/>多路召回要并行"]
    D -.- D1["前缀缓存命中<br/>输入侧直接省算力"]
    E -.- E1["模型分级<br/>fast 档顶掉简单请求"]
    F -.- F1["服务端别缓冲<br/>立即 flush"]

    style C1 fill:#ffe6e6,stroke:#d33
    style D1 fill:#e6f7e6,stroke:#3a3
    style E1 fill:#e6f7e6,stroke:#3a3
    style F1 fill:#e6f7e6,stroke:#3a3

• 输入侧：Prompt 精简（长 system prompt 是 TTFT 杀手）、前缀缓存命中（固定内容前置）、别把无关上下文塞进去。
• 链路侧：多路召回并行（BM25 与向量检索用 asyncio.gather 并发，别串行等）、HTTP 连接池预热复用、服务端 SSE 不缓冲（很多框架默认聚合后才发，直接毁掉流式）。
• 模型侧：模型分级路由（简单请求走 fast 档）、限制 max_tokens、投机解码（服务商侧能力）。
• 工程侧：就近区域部署；把"非必须"的可选步骤（重排、引用校验）挪到流式输出之后做。

金句：流式输出把用户感知延迟从"总延迟"压到"TTFT"，这是投入产出比最高的一次优化——不用改模型、不用加机器。

48. 高并发下 LLM 请求怎么扛？（这是 AI 应用和普通后端最大的区别）★

答题骨架（先讲本质矛盾）： LLM 调用是慢依赖（秒级）+ 贵依赖（有配额、按量计费）+ 不稳定依赖（会 429/超时）。普通后端"加机器就能扩"的直觉在这里失效——上游配额是硬约束，无限并发只会把上游打爆，然后自己全超时。

七层手段（按性价比排序）：

flowchart TD
    REQ["并发请求涌入"] --> CACHE{"① 缓存命中?<br/>精确/语义"}
    CACHE -->|命中| FAST["直接返回<br/>0 成本 0 延迟"]
    CACHE -->|未命中| SEM{"② 并发信号量<br/>Semaphore"}
    SEM -->|未超限| EXEC["立即执行"]
    SEM -->|超限| Q{"③ 队列<br/>削峰"}
    Q -->|队列未满| WAIT["排队等待<br/>带超时"]
    Q -->|队列已满| REJECT["快速失败<br/>429 + Retry-After"]
    WAIT --> PRI{"④ 优先级<br/>交互 > 批处理"}
    PRI --> EXEC
    EXEC --> UP{"⑤ 上游路由<br/>多 Key/多供应商"}
    UP -->|429/超时| DEG["⑥ 降级<br/>换模型/兜底模板"]
    UP -->|正常| OK["正常返回"]

    style FAST fill:#e6f7e6,stroke:#3a3
    style REJECT fill:#ffe6e6,stroke:#d33
    style DEG fill:#fff4e6,stroke:#e90

1. 缓存（最高性价比）：精确缓存（相同 query）+ 语义缓存（相似 query）。命中即 0 成本、0 延迟。
2. 并发信号量：asyncio.Semaphore 限住对上游的实际并发数，是保护自己和上游的第一道闸。
3. 队列削峰：入队即返回（异步任务），worker 匀速消费——长任务必须异步化，同步接口扛不住突发。
4. 优先级排队：交互式请求优先，离线批处理让路（避免批任务饿死在线用户）。
5. 多副本 + 多凭证路由：多副本水平扩展；多个 API Key / 多供应商轮询分摊配额。
6. 降级：换小模型、返回缓存结果、模板兜底——降级要有损但可用，不能直接 500。
7. 背压与快速失败：队列满就明确拒绝（含 Retry-After），队列无限堆积比直接拒绝更糟（雪崩前兆）。

必答的观测指标：队列深度、平均等待时长、上游 429 率、信号量饱和度。只看 QPS 不看队列，等于蒙眼开车。

⛓接项目：AI 小灵 1000+ 门店场景，瓶颈坦诚讲在"LLM API 配额与成本，不在应用层"，缓解靠模型分级 + mock 降级 + 异步任务队列（规划中）——这个判断比堆技术名词更值钱。

49. Prompt Caching / KV Cache 是什么？能省多少？★（易混，答错就露怯）

答题骨架（先把两个概念切开，这是区分度所在）：

• KV Cache 一句话：自回归生成时，每生成一个 token 都要算全部历史 token 的 K/V，缓存后可省下重复计算——代价是显存，这是推理显存占用的主要来源，也是批处理调度的关键约束。
• Prompt Caching 一句话：把"每次都一样的前缀"（system prompt、few-shot、固定知识）在服务商侧缓存计算结果，命中后输入 token 计价大幅折扣 + TTFT 显著下降。

工程要点（必答，很见水平）：

1. 前缀必须逐字节一致，且放在最前面——典型的 Prompt 结构应是：固定 system prompt → 固定 few-shot → 可变内容（用户输入/检索结果）→ 指令收尾。动态内容（时间戳、用户 ID）一旦插到前面，命中率直接归零。
2. 缓存有 TTL（分钟级），高频场景才能吃到红利。
3. 命中率要当指标监控——不监控就无法证明优化有效。

量化口径：命中后输入侧成本可以下降一个数量级（各家定价不同），TTFT 也有可感知下降。具体折扣率按服务商当期文档讲，不要背死数字。

50. RAG 检索性能怎么优化？★

答题骨架（分四段，按链路讲）：

① 向量索引层

• HNSW（图索引）：查询快、召回好，但内存占用大；M（每节点连接数）影响召回与内存、efConstruction/efSearch 是质量与延迟的旋钮（efSearch 调大→召回↑延迟↑）。
• IVF（倒排+聚类）：内存友好、需训练，nprobe 控制探多少簇（质量/延迟旋钮）。
• 量化（PQ / SQ / BQ）：压内存几倍但损精度，适合大规模冷数据。
• 规模再大：分片（shard）+ 副本（replica），冷热分层。

② 过滤与召回

• pre-filter（先过滤再检索）优于 post-filter——先用元数据（租户、文档类型、时间）缩小候选集，再算相似度，成本差一个量级。
• 多路召回并行发起（BM25 与向量检索 asyncio.gather）。

③ 重排层

• Rerank 只作用于粗排后的 Top-K（如 20~50），绝不对全量做——rerank 是交叉编码器，成本随候选数线性涨。
• 重排可以后置：先返回流式首答，再补引用校验，别让用户干等。

④ 缓存与复用

• Embedding 缓存：同一文本（尤其查询）别重复算——embedding 也是要花钱和耗时的。
• 检索结果缓存：热门 query 直接命中。
• 索引增量更新：文档变更别全量重建（ContentBuddy 的做法是文档级增量管理），全量重建的窗口期内服务是降级的。

埋点要求：检索、重排、生成三段耗时必须分开埋——否则你根本不知道"慢"是慢在哪，也没法证明优化有效。

51. FastAPI 高并发怎么调？（前端转后端的高频送命题）★

答题骨架（这题答对能显著加分，因为踩过坑的人才答得出）：

1. async def 里绝对不能有阻塞调用——同步 DB 驱动、requests、CPU 密集计算、time.sleep，任何一个都会堵死整个事件循环，让所有并发请求一起卡住。这是"看起来 LLM 慢、其实是自己堵住"的元凶。
2. 该怎么选：
   • 纯 IO、且下游有异步客户端 → async def + await
   • 只能同步（同步 DB 驱动）→ 用 def，FastAPI 会自动丢到线程池执行，不阻塞事件循环
   • CPU 密集（embedding、解析、图像处理）→ 进程池 / 独立推理服务 / 消息队列，绝不放事件循环
3. worker 模型：uvicorn 单进程单事件循环；生产常见两种：gunicorn + uvicorn worker（按 CPU 核数起，通常 2×核数+1 起手再压测校准），或 K8s 每容器 1 worker + 多副本（后者对 HPA 更友好，我更倾向这种）。
4. 连接池：池大小要与 worker 数、每 worker 并发匹配——池不是越大越好，数据库有最大连接数上限，池过大反而把 DB 打挂。获取连接的超时必须设，否则请求会无限等待。
5. HTTP 客户端复用：httpx.AsyncClient 全局复用一个实例（连接池 + keep-alive），别每次请求新建——这是 TTFT 优化的一部分。
6. 超时三件套：上游 LLM 调用超时、连接池获取超时、整体请求超时。没有超时的系统在故障时会无限堆积。

⛓接项目：AI 小灵踩过"单连接被多线程并发复用导致 InterfaceError"的坑，修法是连接池 + 每请求借一条连接（保证单连接同时只有一个使用者）。这类真实踩坑故事是面试官最爱听的，比背八股有效。

52. LLM 应用的成本怎么算、怎么压？★

答题骨架（先给公式，再给清单）： 成本 = Σ（输入 token × 输入单价）+ Σ（输出 token × 输出单价），再加上 embedding、rerank、向量库、带宽、存储。一次 Agent 任务的成本 = 任务链路里所有 LLM 调用之和（多 Agent 场景要按节点拆开算）。

降本清单（按性价比排序，背这个顺序）：

1. 缓存（精确 + 语义）——命中即零成本，投入产出比最高
2. 模型分级路由——简单任务走 fast 档，强模型只留给关键推理（AI 小灵的 fast/strong 就是这套）
3. 上下文压缩——历史滚动摘要、工具结果裁剪、检索 Top-K 收敛（上下文越长，每次调用都贵）
4. Prompt Caching——固定前缀复用，输入侧直接打折
5. 限制 ReAct 步数与多 Agent 层数——每多一步 = 多一次往返 + 多一份 token，"能用单 Agent 别硬上多 Agent"的工程理由就在这里
6. 输出约束——max_tokens + 结构化输出（JSON schema），避免模型话痨
7. 批处理——离线任务走 batch 接口（通常有折扣），用延迟换成本
8. 成本归因与监控——按任务/租户/节点打 token 账单，找到"最烧钱的那条链路"

金句：不做成本归因的 LLM 应用，规模一上来必然失控——你连钱花在哪都不知道，谈何优化。

追问应对：

• "降本会不会伤质量？" → 会，所以要用评测兜底：降本前后跑同一套 golden dataset，质量指标不降才上线（第 38 题）。
• "怎么算多 Agent 的成本？" → 按 trace 树逐节点统计 token，Supervisor 路由本身就是一次 LLM 调用，路由成本要计入。

53. LLM 应用怎么做压测与容量规划？★

答题骨架（先讲"和传统压测不一样的地方"，这是这题的区分度）：

四个特殊性：

1. 上游是真花钱、有配额的——压测会烧钱且会把自己打到限流。正确做法：先压 mock/stub 上游摸清应用层容量，再小流量打真实上游验证配额与稳定性。
2. 有状态——会话、checkpoint、thread_id；压测必须造会话上下文，不能只打无状态接口。
3. 流式响应——延迟指标要分段（TTFT / TPOT / 总时长），单一 P99 没有意义。
4. 输出长度不确定——成本与耗时随输出 token 数变化，要按token 数分布压，不是按请求数压。

方法（五步）：

1. 定 SLO（如 P95 端到端 < 8s、成功率 > 99%、TTFT P95 < 1.5s）
2. 造场景（按线上真实请求分布造流量，含长短任务混合）
3. 梯度加压找拐点——并发逐步抬升，记录 QPS、延迟、错误率、队列深度、连接池饱和度的变化曲线；拐点（延迟突然抬升）就是单副本真实承载
4. 反推容量：所需副本数 = 峰值目标 ÷ 单副本承载 × 安全系数（经验取 1.4 左右，即单副本水位控制在 ~70%）
5. 留余量并演练：扩容要能在数分钟内生效（HPA），且要演练过

必答的诚实点：LLM 应用的容量瓶颈通常在上游配额，不在应用层——所以容量规划的结论往往是"应用层够用，需要谈的是上游配额与降级方案"。敢这么说比虚报 QPS 更可信。

54. 限流、降级、熔断在 Agent 系统里怎么落地？★

答题骨架（三件套 + Agent 特有的预算概念）：

• 限流：令牌桶 / 漏桶 / 滑动窗口；维度按 用户 / 租户 / 接口 / 全局 分层；网关层（粗）+ 应用层（细）双层。按 token 限流在 LLM 场景比按请求数限流更合理（一次请求可能烧 10 万 token）。
• 降级（要有损可用，分层）：
  1. 模型降级：strong → fast → 缓存结果 → 模板兜底
  2. 功能降级：关掉可选工具 / 可选校验步骤
  3. 结果降级：返回部分结果 + 明确风险提示（"这部分未经过校验"）
• 熔断：上游连续失败达阈值 → 打开（快速失败，不再无谓等待）→ 半开探测 → 恢复。熔断的价值是防止故障扩散和线程/连接被占满。
• Agent 特有：任务级预算——一次 Agent 任务可能调几十次 LLM，必须把 token 预算和时间预算作为整个任务的硬约束，超预算就中止并返回当前最优结果 + 风险提示。这是普通后端没有的概念。
• 背压：队列满 → 明确拒绝（429 + Retry-After）。默默堆积是最危险的选择。

⛓接项目：AI 小灵的三层兜底（工具层结构化错误 → 推理层最大迭代 + 循环检测熔断 → 规划层反思重规划/降级），配上"重试（指数退避）→ 降级 → 人工兜底"三级，直接就是这题的答案。

55. 性能监控怎么落地？三大支柱 + 黄金指标 + SLO ★

答题骨架（先框架，再 Agent 特有指标）：

三大支柱：Metrics（指标，便宜、适合趋势告警） + Logs（日志，适合定位细节） + Traces（链路，适合找慢在哪）。

黄金指标（Google SRE 四信号）：延迟、流量、错误、饱和度。

• 服务视角用 RED：Rate（请求率）、Errors（错误率）、Duration（延迟分布）
• 资源视角用 USE：Utilization（利用率）、Saturation（饱和度）、Errors

Agent 系统特有指标（这是加分项，普通后端没有）：

• 路由准确率（Supervisor 选对子 Agent 的比例，需人工抽评）
• 子 Agent 成功率、工具调用成功率、HITL 触发率
• 每任务 token 消耗与成本（对标单 Agent 基线）
• 死循环熔断次数、重试次数分布
• TTFT / TPOT、检索命中率、缓存命中率

SLO 与错误预算：定"P95 端到端 < 8s、成功率 > 99%"，用错误预算决定能不能发版——SLO 是把性能和业务决策绑起来的机制，比单纯"加监控"高一个层次。

落地组合：链路 trace 用 LangSmith / Langfuse（基于 OpenTelemetry），指标 Prometheus + Grafana，告警分级（P0 电话、P1 群消息、P2 日报）。

56. 线上性能问题怎么定位？（方法论题，考的是不瞎猜）★

答题骨架（先给方法论，再给陷阱）：

第一步：分段埋点，把黑盒打散 前端 → 网关 → 应用 → 上游 LLM → 数据库 / 向量库，每一段都要有耗时。LLM 应用的典型耗时分布：检索 1020%、LLM 5080%、后处理 <10%——但这个分布必须用数据证明，不能靠猜。

第二步：看 trace，找关键路径 用 span 树找最长的那个 span——关键路径上的优化才有意义，非关键路径优化是白干。

第三步：对症下工具

• CPU 热点 → 火焰图（py-spy / cProfile）
• 事件循环阻塞 → 看是否有同步调用混进 async def（这是 FastAPI 最高频的性能事故）
• 连接池 / 队列等待 → 看池饱和度与获取耗时（注意前缀：等到连接的时间也要算进请求耗时）
• 数据库 → 慢查询日志 + EXPLAIN
• 内存问题 → 内存快照对比

第四步：先测再改，改后回归禁止猜测型优化——凭直觉加缓存、改索引，往往没打到瓶颈，还把架构搞复杂了。

高频陷阱（背下来，很能体现经验）：

1. "LLM 慢"其实是事件循环被阻塞——检查 async def 里有没有同步 DB / requests / CPU 计算。
2. "接口慢"其实是日志/序列化慢——大 payload 的 JSON 序列化、同步写日志、大对象打印。
3. "数据库慢"其实是无索引的模糊查询或 N+1 查询——ORM 懒加载在循环里触发。
4. "缓存没生效"其实是 key 不稳定——key 里混了时间戳/随机值/未排序的字典。

57. 数据库层的高并发怎么支撑？（结合 AI 小灵 / ContentBuddy 讲）★

答题骨架（按"先护住数据库，再提升吞吐"的顺序）：

1. 连接池（第一道防线）：池大小与 worker 数匹配；必须设获取超时；池不是越大越好（DB 有最大连接数，池过大反把 DB 打挂）。
2. 索引（性价比最高）：慢查询日志 → EXPLAIN → 联合索引遵循最左前缀 → 尽量用覆盖索引减少回表。索引不是越多越好——写多读少的表加索引会拖慢写入。
3. 读写分离：主写从读；注意主从延迟——"写完立刻读"的场景必须走主库，否则会读不到刚写的数据。
4. 分表与归档：日志类表（如 append-only 事件日志）按时间分区 / 归档，避免单表无限膨胀；归档要在线做，不能停机。
5. 缓存：热点配置放 Redis + 本地二级缓存；防穿透（空值缓存/布隆过滤器）、击穿（互斥锁/逻辑过期）、雪崩（TTL 加随机抖动）。
6. 幂等与并发写：
   • 幂等：唯一约束 / 幂等键 + 状态机，同一幂等键重复提交返回首次结果
   • append-only 表的并发安全不靠"单连接串行化"（连接池本身就是多连接并行），而靠：① 每条是独立原子 INSERT（无读改写、无长事务，天然免锁）② 唯一约束防重 ③ 连接池保证单连接同一时刻只有一个使用者
   • 分布式锁能不用就不用，优先用"唯一键 + 状态机"这种无锁方案

⛓接项目：AI 小灵高峰期写事件日志 + 任务表，用连接池 + 幂等键 + 只 INSERT 的事件表撑住；任务量翻 10 倍时优先做"事件日志归档分表 + 读走从库"（A10 的答案）。

十、快问快答清单（30 秒内答完，别展开）

• Transformer 自注意力为什么比 RNN 适合长序列？→ 并行 + 任意两位置路径 O(1) + 长距依赖不衰减；代价 O(n²) → Flash Attention。
• 位置编码为什么必需？→ 自注意力是排列不变的，必须显式注入位置；sin/cos 绝对编码 vs 可学习编码。
• KV Cache 是什么？→ 缓存历史 token 的 K/V 省重复计算，代价是显存。
• 稠密 vs 稀疏向量？→ 稠密：语义相似、低维（几百~几千）；稀疏：精确关键词（TF-IDF 等，高维稀疏）。混合检索就是两路各取所长。
• 余弦相似度 vs 欧氏距离？→ 余弦看方向归一化后稳，文本常用；欧氏对长度敏感，长度含信息时用。
• 微调方法 LoRA？→ 冻结原权重 + 低秩旁路适配，省显存可插拔。
• 为什么低 temperature？→ 降随机性；但 Agent 里结构化/工具调用比调温更有效。
• 幂等 / 重试怎么防重复？→ 请求 ID + 状态机 + 结果缓存。
• Agent 里怎么用 Redis？→ 缓存/分布式锁/会话隔离/限流/临时 checkpoint——不是存长期记忆。
• TTFT vs TPOT？ → TTFT 首 token 延迟（用户感知的"开始响应"）；TPOT 每 token 间隔（吐字流畅度）。总延迟 ≈ TTFT + TPOT × 输出 token 数。
• 延迟和吞吐能同时优化吗？ → 不能，本质权衡。batch 提吞吐但抬单请求延迟；在线看 TTFT，离线看吞吐与单位成本。
• Prompt Caching 和 KV Cache 区别？ → KV Cache 是推理引擎内部（单请求内省重复计算，吃显存）；Prompt Caching 是服务商侧跨请求复用相同前缀（前置固定内容才命中）。
• 缓存命中率为什么是最高性价比优化？ → 命中即 0 成本 0 延迟；语义缓存还能吃掉相似 query。
• 限流按什么维度？ → 用户/租户/接口/全局；LLM 场景按 token 限流比按请求数更合理（一次请求可能烧 10 万 token）。
• 并发上来了先做哪一件事？ → 先并发信号量（Semaphore）护住上游，再上队列削峰，队列满就快速失败（429 + Retry-After），别默默堆积。
• FastAPI 性能第一大坑？ → async def 里混进同步阻塞调用（同步 DB / requests / CPU 计算），会堵死整个事件循环。
• 压测 LLM 应用和普通接口有什么不同？ → 上游真花钱有配额（先压 mock 再小流量打真实）、有状态要造会话、流式要分段看 TTFT、成本随输出 token 数变（按 token 分布压）。
• 容量规划怎么算？ → 梯度加压找拐点得单副本承载 → 副本数 = 峰值 ÷ 单副本承载 × 安全系数（水位控 ~70%）→ HPA 保扩缩速度。结论常是"瓶颈在上游配额"。
• 性能问题定位第一步？ → 分段埋点把黑盒打散（前端/网关/应用/LLM/DB），再看 trace 找关键路径最长 span。禁止猜测型优化。
• 成本公式？ → Σ(输入 token × 单价) + Σ(输出 token × 单价) + embedding/rerank/向量库/带宽；降本顺序：缓存 → 模型分级 → 上下文压缩 → Prompt Caching → 限步数 → 输出约束 → 批处理。
• （前端工程化 · 简历有就必背）qiankun 的 JS 沙箱拦不住什么？ → 只拦 window 属性读写；事件监听、定时器、DOM/原型副作用它不管，必须靠副作用收集器在 unmount 统一清理。
• 微前端最大的收益是什么？ → 解耦发布权（多团队独立开发/部署/回滚），不是性能优化。单团队、小体量、耦合深的应用上微前端是纯负债。
• 样式隔离为什么弹窗是重灾区？ → 隔离边界是"子应用容器"，而弹层挂在 document.body 上跑出了容器；解法是统一 getPopupContainer + 构建期前缀 + experimentalStyleIsolation 兜底。
• 组件库"按需引入"的关键是什么？ → 不是"出了 ESM"就够了，要 sideEffects 只留 CSS + 多入口 + external 与 peerDependencies 成对；否则 tree-shaking 失效（体积反弹）或双 Vue 实例（响应式失效）。
• Design Token 为什么要分三层？ → 原始值（palette）→ 语义层（业务只认这层）→ 组件级；换主题只覆盖语义层，组件里禁止硬编码色值（用 stylelint 卡住）。

附：给自己项目补的三句话弹药库（被追问直接用）

1. "为什么你们的多 Agent 不是 Workflow？" → 承认边界：AI 小灵是"确定性流程为主 + 局部自主（审核回写循环、场景路由）"，29 场景共享节点集靠配置声明，要的是可控可留痕，不是自由协作；这正是 2026 业界回归的方向（强 Agent + 好工具 + 上下文工程）。
2. "子 Agent 失败/降级你感知得到吗？" → 每个节点把 {status, data} 写进 State 对应字段，Supervisor 读 status 决定跳过/重试/转人工；asyncio.gather(return_exceptions=True) 逐个处理。
3. "多 Agent 一定比单 Agent 好吗？" → 不。我们选多 Agent 是因为职责权限隔离（审核必须独立于创作）+ 并行 + 留痕；凡是简单问答场景我一律单 Agent——这个判断比架构本身更值钱。