Agent / LLM 方向面经整理（思路引导 + 推荐回答）

每章开头有一小段本章思路引导（这类题整体上在考什么、怎么组织话）。每道题下先有一行思路（答题时先想什么），再是推荐回答（可参考的表述骨架）。请把里面的名词、数字换成你项目里的真实情况，别整段背。

一、写在前面

如果投的岗位对后端技术栈有一两条要求，你没有相关经历但业务还是放了简历进来，最好针对 JD 里那两条单独准备一下。其实就算 JD 没写死，HTTP、流式、异步这类也算互联网底座，有时间还是摸一遍皮毛，面试里至少能接住话头、显得你是主动补过的人。

没正经后端经历的（比如我），体感是面试官一般不会往死里抠实现细节，更在意知识广度和积极性：你有没有针对他们的栈新学东西、工作之余有没有继续啃。忙成狗还得学，这事没得商量，只能认。

下面从「项目深挖」按模块往下写；项目主线（Agent、LangGraph、上下文、工具、评测）通常是追问最深的，RAG 和训练会顺着简历二选一挖到底，后端更像扫一圈广度。

二、项目深挖（Agent）

本章思路引导

这块考的是项目是不是你亲手推过：能不能画白板（输入→编排→工具→观测）、状态放哪、失败怎么回滚，以及每个技术选型背后的取舍，而不是堆名词。习惯用「总览一句 → 分三层展开 → 主动说一个代价或没做的点」；和 Claude Code / 中台对比的题，考的是边界感（数据域、合规、集成成本），别答成「我们更强」这种空话。

Q1 整个 Agent 的设计思路、架构？

思路：
先想白板上四条线：编排谁调谁、state 放哪、工具与观测、失败怎么回滚；对方在看你能不能拆模块讲验收。

推荐回答：
我们整体是「编排层 + 模型层 + 工具层 + 观测层」。用户任务进来先归一成内部任务协议，编排层用状态机/图决定下一步是规划、调工具还是直接回复；状态（对话、计划、工具中间结果）集中放在可序列化的 state 里，方便断点续跑。模型负责理解与生成，工具负责和外部世界交互，日志与 trace 单独打，失败走重试或降级路径。这样拆的好处是：换模型、加工具、改流程时边界清楚，评测也能按模块拆开看瓶颈。

Q2 为什么用 LangGraph？有什么缺点？是不是过度设计？

思路：
技术选型题必答 trade-off：LangGraph 的收益是显式状态与可恢复，代价是复杂度；再答「什么业务不需要图」。

推荐回答：
选 LangGraph 主要是因为流程不是一条直线：有多分支、人机确认、需要 checkpoint 恢复。它把「状态 + 边」写清楚，比 while 循环里塞 if-else 好维护。缺点是团队要接受图的心智模型，小改动有时要动边和 reducer，样板代码偏多；若业务只是「分类 → 单次检索 → 回答」，用简单 ReAct 循环就够，上图确实偏重。是否过度设计看三点：有没有真实的中断恢复需求、流程会不会频繁改、团队能不能 hold 住这套抽象。

Q3 为什么要自研，不直接用 Claude Code 或公司内部 Agent？

思路：
考你是否理解现成产品的边界：数据域、集成、审计、评测指标；自研要落到「薄编排 + 自有工具」这类可执行形象。

推荐回答：
现成产品解决的是通用问题，我们这边要的是和内部系统、权限、数据域深度耦合，以及可审计、可灰度、成本可控。CC 或内部平台若能满足八成，我们也不会重复造轮子；实际上往往是接口粒度、记忆策略、评测指标和业务不一致，自研一层「薄编排 + 自有工具」更划算。若公司已有统一 Agent 中台，也可以答：我们在中台上做领域适配层，而不是从零造引擎。

Q4 如果项目要基于 CC 直接改造，你具体会怎么做？

思路：
改造题考路径感：先协议与数据边界，再工具/RAG/评测/监控，别一上来换大模型。

推荐回答：
先不动核心对话能力，做四件事：一是任务与上下文协议对齐（哪些进 CC、哪些留在外层服务）；二是把敏感数据与工具执行放在内网网关后，CC 只拿脱敏后的摘要或检索块；三是补评测与回归（固定用例 + 沙箱执行）；四是监控与配额（token、工具错误率、延迟）。改造顺序上先接工具与 RAG，再迭代记忆与多步任务，最后才考虑是否替换底层模型，降低一次性风险。

Q5 项目里的工具链能不能 Skill 化？

思路：
考粒度与治理：哪些链路值得 Skill 化、版本与示例怎么维护；别全肯定或全否定。

推荐回答：
能，但要挑路径。高频、参数模式稳定、有明确成功失败判据的工具调用链，适合收成 Skill：带说明、示例、边界和默认参数。强依赖本地环境、一次性脚本、或每次参数差异很大的，保留为裸 Tool 更省事。Skill 化之后要做版本号和兼容策略，否则模型读到旧说明会乱调。我们项目里可以举例：例如「查库 → 格式化 → 写报告」这类流水线_skill 化，单次 grep 类仍当 Tool。

Q6 项目能持续演进吗？是否还有演进价值？

思路：
用指标和 roadmap 说话，避免空喊「有价值」；可说 plateau 之后转成本或沉淀组件。

推荐回答：
有价值的前提是能量化：准确率、成本、延迟、覆盖场景是否在变好。演进方向一般是：评测集扩大与难例覆盖、工具稳定性、记忆与上下文策略、多模态或更深业务集成。若指标已经 plateau，就转向维护与成本优化，或把能力沉淀成公司内部组件。这样答比空喊「有」更可信。

Q7 项目怎么评测？数据集自建吗？能沙箱吗？怎么监控？

思路：
闭环题：离线集怎么建、沙箱隔离什么、线上监控什么指标；各举一类即可串起来。

推荐回答：
离线用自建 + 抽样真实日志脱敏：按任务类型分层，包含成功路径和故意设计的失败路径。能沙箱的话，工具执行在隔离容器或受限 API 代理里跑，避免评测污染生产。在线看 A/B 或灰度桶的完成率、重试率、用户显式纠正率。监控上打全链路 trace：每步模型耗时、工具错误码、token 用量、幻觉类规则命中（如未引用却断言），异常进告警和 badcase 池。

Q8 准确率还有什么优化方案？

思路：
分层答优化（检索/生成/工具/数据/模型），体现你量过瓶颈；忌只答换大模型。

推荐回答：
分层说：检索侧（改写、混合检索、rerank、chunk 策略）、生成侧（约束输出格式、强制引用、拒答策略）、工具侧（参数校验、超时与重试）、数据侧（badcase 回流改 prompt 或改文档）、必要时换模型或做小域 SFT。避免只答「换更大的模型」，面试官更希望听到你从哪一层量到了收益。

Q9（对比 CC）有了 Claude Code，为什么还要做类似项目？

思路：
差异化 + 诚实：没差异化就不该做；合规与嵌入业务系统是比「又一个聊天」更硬的点。

推荐回答：
CC 面向通用编码与开源生态，我们面对的是特定数据域、合规和内部工具链，需要可控的发布节奏和定制记忆/评测。重复的不是「聊天写代码」这一件事，而是把能力嵌进现有工单、权限和 SLA 里。若完全没有差异化，确实不该做，这点可以主动承认，再强调我们的差异化落点。

Q10 和 Claude Code 相比，核心差异？哪里更好、哪里不如？

思路：
对比题各举一条具体优劣，忌一边倒吹牛或贬低业界产品。

推荐回答：
更好的一般在：领域工具齐全、内部知识接入深、成本和数据可控、能按业务改评测标准。不如的常见在：通用代码能力、生态插件、产品化体验。答的时候各举一条具体的，避免一边倒吹牛或一边倒贬低。

Q11 分层上下文管理，每一层管的是什么？

思路：
分层不是背名词：每层谁写谁读何时淘汰，比罗列层名重要。

推荐回答：
常见分法：系统/安全层（角色、禁止项）、会话短期（最近几轮原文或滑动窗口）、任务 working memory（当前子目标、计划步骤）、长期记忆（跨会话摘要、用户偏好、可检索事实）、工具层缓存（大工具结果折叠或存引用）。关键是每层谁写、谁读、何时淘汰要说清，否则分层只是名词堆砌。

Q12 摘要生成用什么模型？摘要质量怎么保证？

思路：
模型档位 + 模板约束 + 抽检/自动指标 + 涉敏闸门，四块凑齐就完整。

推荐回答：
模型选小一点的专用摘要模型或主模型的低温度调用即可，看成本与延迟；关键在模板：要求保留实体、数字、约束、未决问题，避免「总结成空话」。质量上用抽检 + 自动指标（如与原文的实体重叠率、关键句是否被删）、badcase 回灌改模板。摘要写进长期记忆前要可加人工或规则闸门（涉敏字段不落摘要）。

Q13 有没有试过 subagent？多个 agent 起什么作用？

思路：
分工与代价：为何拆 subagent、没上生产的原因（协调/延迟）可以说实话。

推荐回答：
试过或规划过都可以诚实说。作用主要是分工：例如检索 Agent、执行 Agent、评审 Agent 拆开，减轻单上下文压力，也方便单独限步和重试。没上生产可以说原因：协调成本、一致性、延迟，以及当前任务复杂度是否值得。

Q14 主 agent 和子 agent 怎么通信？

思路：
通信三种形态选一种你熟悉的展开，必提超时与失败冒泡。

推荐回答：
实现上常见三种：编排器下发子任务并收结果（像 RPC）；共享 checkpoint / 黑板状态（读写约定 schema）；消息队列/事件总线（解耦但调试难）。要提超时、子任务失败如何冒泡到主任务、以及如何避免两个 agent 同时写乱状态。

Q15 有没有遇到 agent 死循环？怎么解决？

思路：
工程手段优先于 prompt：步数、重复检测、无进展终止、state 里计数。

推荐回答：
遇到过或预防性做过都可以。手段包括：全局最大步数、同一 (tool, args) 重复检测、连续无进展（observation 不变）则强制停止或换策略、计划节点要求显式「完成」标记、必要时人机介入。实现上把「步数与重复计数」放在 state 里，图里单独做条件边，比只靠 prompt 稳。

三、LangGraph 专项

本章思路引导

对方想确认你真用过图编排：checkpoint 与 thread、state schema、幂等与异常边，而不是只看过文档。答的时候尽量落到「我们 thread_id 怎么映射」「工具非幂等怎么摆中断点」这种可追问细节；说不清就诚实说没上生产，别编 API。

Q16 LangGraph 的中断恢复具体是怎么做的？

思路：
checkpoint + thread + 幂等；中断点别落在非幂等工具中间除非有补偿。

推荐回答：
依赖 checkpoint：每个节点前后把完整 state（含 channel 合并结果）持久化到配置的 saver（内存/Redis/SQLite 等）。中断后用 thread_id 加载最新 checkpoint，从下一节点或失败节点重放。要注意工具副作用是否幂等；非幂等工具要么用事务/补偿，要么中断点设计在「纯推理」之后。

Q17 节点间复杂数据怎么传递？

思路：
schema、reducer、大对象外置与版本兼容；这是「真做过图」才会碰到的点。

推荐回答：
靠 TypedDict 或 Pydantic 定义的 state schema，大字段用「引用 ID + 外存」避免把巨型工具输出塞进每次 checkpoint。列表类字段用 reducer（如 append、merge dict）控制并发写入。复杂结构要版本化字段名，避免后续加节点时反序列化失败。

Q18 要用 LangGraph 做 A2A（Agent 到 Agent）怎么做？

思路：
对端当外部节点或 tool；协议、鉴权、超时、多实例一致性提一句。

推荐回答：
把对端当「外部节点」：本图里一个节点负责发请求（HTTP/gRPC/消息队列），对端返回结构化结果再写回 state；或把对端封装成 tool，由模型决定何时调用。协议层要约定消息格式、鉴权、超时与幂等。多实例部署时 thread_id 与 checkpoint 存储要一致，避免两个 worker 各写各的。

Q19 checkpoint 怎么存？怎么恢复？

思路：
checkpointer 选型、thread 映射、合规保留周期；开发/生产分开说。

推荐回答：
LangGraph 侧用 checkpointer 接口，开发常用 MemorySaver，上线用 PostgresSaver、Redis 等。存的是序列化后的 state snapshot + metadata（thread_id、checkpoint_ns）。恢复时 graph.get_state(config) 或从指定 checkpoint_id 继续 invoke。要和业务上的「会话 id」映射好，并考虑加密与保留周期合规。

Q20 长期运行 checkpoint 越来越多、上下文越来越长怎么办？

思路：
checkpoint 与 context 两条线都要裁剪：TTL、摘要、拆 thread，和业务对齐恢复粒度。

推荐回答：
checkpoint 按策略裁剪：只保留最近 N 个或按时间 TTL，或合并为「里程碑 checkpoint」。上下文侧做摘要压缩、工具输出折叠、只保留任务相关字段进模型窗口。长期任务可拆 thread 或子图，避免单 thread 无限增长。和业务对齐「最坏情况下能恢复到什么粒度」。

Q21 节点执行异常怎么处理？

思路：
分类异常：可重试 vs 不可重试，错误边与观测别吞。

推荐回答：
节点内 try/except，区分可重试（网络抖动）与不可重试（参数非法）：可重试走退避重试边，不可重试写错误 state 并走错误边或交给「修复」节点。不要让异常吞掉；关键路径打日志和指标。对 LLM 调用单独处理 rate limit 与空响应。

Q22 在现有 LangGraph agent 上新加功能，怎么做？好扩展吗？

思路：
扩展性实话实说：新节点新边、state 契约向后兼容、工具注册表。

推荐回答：
加功能优先加节点与新边，尽量不改已有字段语义；若必须改 state，做向后兼容（默认值、迁移函数）。工具用注册表动态挂接，减少改核心图。扩展性实话实说：流程稳定时扩展性好；若早期 state 设计随意，后期会痛，可以举自己一次重构例子。

四、上下文与记忆

本章思路引导

考的是上下文工程而不是背「长期记忆」四个字：窗口、成本、指代、工具大段输出怎么挤占有效 token。重点讲谁写谁读谁删、规则与模型怎么分工；项目题没有标准答案，用你真实存储与触发条件答，比模板安全。

Q23 长对话系统会遇到哪些问题？怎么解决？

思路：
窗口、成本、遗忘、工具输出占位；对策和场景一一对应。

推荐回答：
问题主要是窗口溢出导致早期指令被遗忘、指代消解变差、成本上升、长工具输出挤占有效 token。对策：滑动窗口 + 周期性摘要、结构化记忆（键值表）、任务分片开新会话、工具结果摘要写回、必要时用子 agent 分担上下文。

Q24 长期记忆和短期记忆怎么区分？长期记忆保存策略？怎么判断、怎么执行？

思路：
定义短/长期生命周期 + 写入触发 + 执行流水线；忌「什么都进长期」。

推荐回答：
短期：当前任务几轮对话和临时变量，生命周期随会话结束可丢。长期：用户偏好、跨会话事实、项目背景，需显式写入策略（例如用户确认「记住这个」、或系统检测到重复出现的高置信事实）。判断可用规则（实体类型、是否涉敏）+ 小模型打分是否值得记。执行上是「写入队列 → 去重合并 → 存储（向量库/表）→ 检索时注入」。

Q25 哪些上下文可以删？哪些不能删？为什么？怎么判断？

思路：
安全与任务关键信息慎删；大段重复工具输出可折叠；规则为主模型为辅。

推荐回答：
不能删：系统安全约束、用户明确约束、未完成任务的关键条件、最近一次工具错误信息（除非已解决）。可以删或折叠：重复的工具大段输出、已进摘要的原文、过期轮次。判断用优先级规则为主，模型为辅；删除前可做「若删则无法回答某类问题」的探测（可选）。

Q26 除了上下文压缩还有哪些方案？

思路：
外置记忆、拆会话、结构化计划、多 agent 分上下文，任选两条讲清适用条件。

推荐回答：
外置记忆（RAG/知识库）、子会话拆分、把状态存在数据库只传摘要进模型、用结构化计划代替全文历史、多 agent 各持一部分上下文、对工具输出只保留结论字段。

Q27 项目里长期记忆是怎么设计的？（结合真实项目）

思路：
这里必须接你真实项目：存储、触发、冲突策略；没有就答规划与 trade-off。

推荐回答：
按你实际写：存储用 Postgres + 向量库或仅表结构；写入触发条件；是否分层（事实层/偏好层）；冲突时新覆盖旧还是保留多版本；读取时 top-k 与相关性阈值。没有完美方案，诚实说 trade-off 即可。

Q28 项目在上下文工程上做了哪些工作？

思路：
挑 2～3 个落地动作说透：模板、裁剪、工具折叠、评测对齐上下文等。

推荐回答：
可答：Prompt 模板与变量治理、动态裁剪策略、工具返回的 max token 截断与二次摘要、多模态对齐（图文顺序）、调试时可视化 state、与评测集对齐的「标准上下文」构造。挑 2～3 个最有量的说透。

五、Agent 架构通识

本章思路引导

这里偏范式与权衡：ReAct vs Plan&Execute、多 Agent 通信、评测与 harness。面试官希望听到适用场景各举一反例，以及你对 benchmark 是否真读过题设；harness 能说清「可重复环境 + 自动打分 + 日志」就够用。

Q29 ReAct 循环怎么限制？怎么保证稳定性？

思路：
硬预算 + 软约束（白名单、重复、无进展）； observation 质量影响稳定性。

推荐回答：
硬限制：最大步数、最大工具调用次数、时间预算、token 预算。软限制：工具白名单、计划校验节点、重复调用检测、无进展则终止或请求澄清。稳定性还依赖工具幂等与清晰 observation，避免模型被噪声带偏。

Q30 Plan & Execute 和 ReAct 的应用场景和区别？

思路：
探索 vs 可审计流水线各举一例；可补一句混合架构。

推荐回答：
ReAct 是边想边做，适合环境反馈密、路径不确定的探索任务。Plan & Execute 先出完整或阶段性计划再执行，适合步骤可预估、需要可审计流程的任务（如固定流水线）。P&E 缺点是计划可能一开始就不对；ReAct 缺点是步数多、成本高。很多系统两者混用：粗计划 + 细 ReAct。

Q31 多智能体架构都有哪些？

思路：
列 2～3 种架构 + 工业界常见「编排器+专家」即可，忌空泛多 agent。

推荐回答：
层级（主管拆任务给工人）、流水线（A 输出给 B）、对等协商、黑板/共享内存、市场拍卖式任务分配。工业里常见的是「编排器 + 若干专家 agent」，不要太迷信「很多个聊天机器人」。

Q32 多 agent 怎么通信？

思路：
消息、共享状态、编排器中转 + 死锁与 schema 版本。

推荐回答：
直接消息、共享状态、通过编排器中转。要考虑顺序、锁、死锁（两个 agent 互相等）、以及消息 schema 版本。简单场景用编排器最省心。

Q33 怎么让 Agent 越用越聪明？

思路：
飞轮：日志、badcase、评测、工具库；别只答微调。

推荐回答：
靠数据飞轮：badcase 回流、工具与 prompt 迭代、评测驱动改检索与约束；有预算可做偏好学习或小域微调。产品侧收集「用户纠正」比单纯堆对话更有用。强调评测与日志，别只答「微调」。

Q34 了解过 CC 的架构设计吗？主要流程是什么？

思路：
知道就说主链路，不知道别编内部细节。

推荐回答：
若了解：可概括为用户意图 → 上下文与文件状态管理 → 模型规划 → 工具/终端执行 → 结果写回上下文，循环直到任务结束。若不了解：直说只用过产品、没读内部架构，避免编细节。

Q35 Agent 有哪些评测标准？了解哪些 benchmark？

思路：
维度 + 1～2 个熟 benchmark 的题设，忌罗列名字。

推荐回答：
维度：任务成功率、平均步数、工具错误率、成本、人工评分。benchmark 可提 SWE-bench（代码修复）、AgentBench、WebArena、工具调用类榜单、GAIA 等，选熟悉的讲一两条评测设置，别罗列十几个名字。

Q36 harness 工程了解吗？主要内容？项目里怎么用？还能补什么？

思路：
harness = 可重复环境 + 打分 + 日志；再补一条业务向可增强点。

推荐回答：
Harness 一般指可重复实验环境：固定镜像/依赖、标准输入输出、自动打分、日志采集。我们项目里用于回归固定用例、对比 prompt/模型版本。可补充：更接近真实业务的「半合成」环境、对抗性用例、性能压测与成本统计。

六、Tool

本章思路引导

工具链考工程稳定性：超时、重试、熔断、错误怎么回灌给模型、怎么防死循环和乱序并行。大 tool 集设计考的是治理（动态子集、schema、监控），不是把 100 个 API 名字塞进 prompt。

Q37 工具调用失败怎么办？怎么保证稳定性？

思路：
分类错误、结构化返回、重试与熔断；忌把 stack 全扔给模型。

推荐回答：
分类处理：超时重试（指数退避）、4xx 参数错误反馈给模型自纠、5xx 与熔断后降级（缓存结果或换工具）。稳定性还要 schema 校验、超时上限、并发限制、幂等 key。把错误信息结构化返回给模型，比返回一大段 stack trace 更安全。

Q38 工具循环调用怎么办？

思路：
与限步、重复检测、任务完成信号联动；可点根因是任务定义或 observation。

推荐回答：
与全局步数限制配合；检测「相同工具+相同参数」连续出现；要求模型在 observation 里看到「已完成」信号才能结束；图里可加「无新信息则中断」边。根本原因是任务定义不清或工具返回值没有推进状态，可从产品侧收紧。

Q39 Tool 和 Skill 区别？哪个更适合 agent 演进方向？

思路：
Tool 原子、Skill 编排；演进答分层不是二选一。

推荐回答：
Tool 是原子能力，偏 API；Skill 是带说明与步骤的可复用工作流，往往组合多个 Tool。演进方向通常是「底层 Tool/MCP 稳定 + 上层 Skill 沉淀最佳实践」，不是二选一，而是分层。

Q40 设计有 100 个 Tool 的 Agent，你会怎么设计？

思路：
动态子集、治理、监控、meta-tool；忌 100 个全塞 system prompt。

推荐回答：
不会把 100 个全塞进 system prompt。做法：按域分组、动态检索当前任务相关的子集（tool retrieval）、统一命名与 schema 治理、版本与弃用标记、监控每个 tool 的成功率与延迟、文档自动生成给模型看摘要。复杂工具链用 meta-tool 或 Skill 收口。

Q41 多个工具怎么并行执行？顺序怎么确定？

思路：
依赖图拓扑 + 执行器校验；无依赖才并行。

推荐回答：
无依赖的可并行（asyncio、线程池或 LangGraph 并行边）；有读写依赖的拓扑排序定序。让模型先出「依赖图」或简单标注顺序码，再由执行器校验，避免模型乱序导致竞态。

七、Skill

本章思路引导

把 Skill 当成可复用的业务 playbook + 版本，MCP 当成协议层，分层说清楚就不会和 Tool 混成一团。演进方向题适合答「底层协议/工具标准化，上层 Skill 沉淀」，显得务实。

Q42 Skill 是什么？怎么理解？

思路：
用 playbook 比喻：目标、步骤、工具、示例、失败处理。

推荐回答：
Skill 可以理解成「带说明书的小 playbook」：目标、前置条件、推荐步骤、可调用的工具列表、输入输出示例、失败时怎么处理。它比裸 Tool 更贴近业务语言，减少模型试错的次数。

Q43 Skill 和 MCP 的区别？

思路：
协议层 vs 应用层；举例 Skill 编排多个 MCP。

推荐回答：
MCP 是连接模型与外部资源/工具的协议与传输层；Skill 是应用层封装，往往内部会调用 MCP 或 HTTP。一个 Skill 可以编排多个 MCP 资源；MCP 本身不负责「怎么做这件事」的业务步骤。

Q44 你的项目能不能 skill 化？会怎么设计？

思路：
高频路径、版本、评测用例、CI；结合项目举一条流水线。

推荐回答：
按高频路径拆 Skill 目录：每个 Skill 一个 markdown/spec + 可选脚本入口，版本化；评测集中为每个 Skill 建最小用例；与 CI 联动防破坏。结合你项目举 1～2 条真实流水线。

Q45 你觉得 Agent 演进方向是 skill 还是工具？

思路：
底层工具/协议标准化，上层 Skill 厚；一句定调即可。

推荐回答：
底层长期还是工具与协议（如 MCP）标准化；上层演进是 Skill/工作流库越来越厚，把组织知识固化下来。对用户表现为「更会干活」，对工程表现为「更好测、更好管」。

八、MCP

本章思路引导

知道 MCP 解决什么问题、怎么接、代价是什么即可；传输层能对应到 stdio / SSE 场景选型，说明你真的跑通过，不是背定义。

Q46 MCP 是什么？怎么使用？优缺点？

思路：
是什么、怎么用、优缺点、运维成本；忌只吹优点。

推荐回答：
MCP（Model Context Protocol）是 Anthropic 推动的开放协议，用来让模型以统一方式发现资源、读文件、调工具。使用上就是起一个 MCP server，在客户端配置连接，模型通过协议拉 tools/list 再调用。优点是生态互通、接入清晰；缺点是多一跳延迟、部署与鉴权运维成本、调试链路变长。

Q47 MCP 传输层了解吗？

思路：
stdio 本地、SSE 远程流式，对应你部署场景。

推荐回答：
常见有 stdio（本地进程）、HTTP+SSE（远程流式）、部分场景 WebSocket。stdio 适合本地开发；远程多用 SSE 长连接传事件。选型看部署形态与安全域。

九、RAG

本章思路引导

整条链路从解析 chunk 到拒答要能串起来；向量库 vs 普通库、rerank vs LLM 裁判都是成本与效果 trade-off。行业文档、Code-RAG、关系型文档考的是索引设计意识，不必扯玄学。

Q48 用的什么向量库？数据量？为什么不用普通数据库检索？

思路：
量级真实答；语义检索为何用向量 + 小数据 hybrid 的诚实边界。

推荐回答：
按实际答库名与量级。理由：语义检索需要向量与 ANN 索引，普通 B-tree 不适合高维相似度；但小数据也可用 pgvector 或「全文 + 向量」混合，不是非黑即白。大体量时向量库的索引结构与量化策略更成熟。

Q49 用了哪些检索方式？为什么？

思路：
按数据特点选稠密/稀疏/混合；用线上指标收口。

推荐回答：
可答：稠密向量、BM25 稀疏、混合检索（RRF 或加权）、查询改写、HyDE。选型理由按数据特点：专有名词多可加强稀疏；语义泛化强用稠密；线上效果靠 A/B 和 nDCG/命中率说话。

Q50 为什么要单独 rerank，不用大模型直接选片段？

思路：
成本延迟 vs 精度；两阶段裁判可作为补充。

推荐回答：
大模型当裁判要对每个候选读一遍，候选多时成本高、延迟大；专用 cross-encoder reranker 在小候选集上更省且相关性更稳。也可以两阶段：rerank 缩小后再让大模型精读。小候选集直接用 LLM 排序有时可行，要说明 trade-off。

Q51 构建 RAG 的流程是什么？

思路：
从采集到拒答串流程；体现你做过一整条 pipeline。

推荐回答：
采集与清洗 → 解析（PDF/HTML/表格）→ 切 chunk（大小、重叠、按标题/结构）→ 打元数据 → 向量化与建索引 → 在线检索（可能多路）→ rerank → 拼 prompt 生成 → 引用与拒答策略 → 日志与 badcase 回流改 chunk 或 metadata。

Q52 召回不到数据怎么处理？

思路：
先扩召再诚实无资料；忌硬编。

推荐回答：
放宽 top-k、换改写 query、稀疏通道补召、扩大 chunk 或父文档扩展；仍没有则明确告诉用户「知识库无依据」并禁止编造。同时把该 query 记入队列优化索引或同义词表。

Q53 如果做 Code-RAG，应该怎么做？

思路：
chunk 粒度、调用图、分层索引；大仓库要粗精结合。

推荐回答：
按函数/类切分优于纯固定 token 切；保留 import、调用关系做图或边索引；检索命中后给模型看完整函数上下文；可接 linter/类型检查或「检索+执行反馈」闭环。大仓库要分层索引（文件级粗召 + 符号级精召）。

Q54 有关联关系的文档怎么做 RAG？

思路：
实体/父子 chunk/二次查询；图库可选。

推荐回答：
建实体关系或目录层级：先召实体再沿边扩展 chunk；或 chunk 带 parent_id 检索时一并拉回父节；图数据库可选但成本高，很多团队用 metadata + 二次查询解决。

Q55 行业黑话或内部术语文档怎么做 RAG？

思路：
术语表、query 扩展、embedding 适配、prompt 注入。

推荐回答：
维护术语表与同义词映射；query 扩展阶段注入；embedding 可在术语语料上继续训练或适配；生成前把术语表片段塞进 prompt；严重依赖行话时用小域微调检索模型。

十、后端与软件基础

本章思路引导

互联网底座广度题：能描述全链路、知道往哪查日志就行。流式、SSE、asyncio 和 Agent 网关场景挂钩答，比纯背定义分高。*args / **kwargs 题面常写错，答时顺带点一句。

Q56 接收一个大文件，全流程与关键技术、优化？

思路：
分片、流式、队列、背压；Agent 场景提安全扫描。

推荐回答：
客户端分片上传 + 服务端合并，校验 hash；落盘或直传对象存储；大文件解析用流式读、异步队列削峰；背压与限流防 OOM。优化：零拷贝、分块处理、并行解析可并部分、失败断点续传。Agent 场景还要注意病毒扫描与类型白名单。

Q57 HTTP 请求流程、状态码、故障一般出在哪？

思路：
DNS→TCP→TLS→请求→响应；状态码 + 排障工具链。

推荐回答：
DNS 解析 → TCP 握手 → TLS（HTTPS）→ 发请求行/头/体 → 服务端处理 → 响应。状态码：2xx 成功，3xx 重定向，4xx 客户端问题，5xx 服务端问题。故障可能在 DNS、证书、防火墙、超时、上游应用或数据库；用 curl、抓包、链路追踪和日志关联定位。

Q58 流式响应的过程？

思路：
chunked、代理缓冲、首字节；可挂 LLM 网关。

推荐回答：
服务端边生成边写 chunk（如 chunked transfer），客户端边读边渲染。LLM 场景是上游 token 流 → 网关 → SSE 或 WebSocket → 前端逐字展示。要注意中间代理缓冲关闭、心跳与超时。

Q59 SSE、WebSocket、asyncio 是什么？

思路：
SSE 单向、WS 双工、asyncio 协作式与阻塞坑。

推荐回答：
SSE 是 HTTP 上的单向服务器推送，基于长连接文本流，适合模型 token 流。WebSocket 全双工，适合强交互、二进制多。asyncio 是 Python 单线程协作式并发模型，用 await 挂起 IO，要避免在协程里跑阻塞 CPU 或阻塞 IO。

Q60 Python 装饰器、迭代器、怎么搞流式响应？*args 和 **kwargs（题里若写 **args 按 kwargs 理解）？

思路：
装饰器/生成器/StreamingResponse；顺带 kwargs 笔误。

推荐回答：
装饰器是高阶函数，在函数外加一层横切逻辑（日志、鉴权），记得 functools.wraps 保留元数据。迭代器实现 __iter__/__next__，生成器用 yield 适合流式一块块吐数据。流式响应在 FastAPI/Starlette 里用 StreamingResponse 包异步生成器。*args 收位置参数元组，**kwargs 收关键字参数字典。

Q61 C/C++ 从代码到执行全流程？和 Python 有什么不同？

思路：
编译链接 vs 解释字节码；各说一个工程差异即可。

推荐回答：
C/C++：预处理 → 编译成目标文件 → 链接成可执行文件 → 加载运行。Python：源码编译成字节码，解释器（或 VM）执行，类型多在运行时解析。C/C++ 更贴近内存与性能，无 GC（C++ 对象生命周期手动/RAII）；Python 开发效率高但有 GIL 等限制（IO 多时 asyncio 仍可并发）。

十一、训练相关（GRPO / PPO / LoRA）

本章思路引导

顺着简历里的训练项目挖：KL、rank、调参要有和曲线的关系，梯度检查点说清换显存还是换时间。公式以你读的论文为准，面试里宁可说「这块我回去再核对论文」也别硬编系数。

Q62 GRPO 和 PPO 的区别？

思路：
PPO 有 critic、GRPO 组内相对优势/弱 critic；公式以论文为准。

推荐回答：
PPO 是经典 actor-critic：用价值网络估计优势，clip 约束策略更新。GRPO（Group Relative Policy Optimization）一类方法常在一组采样内算相对优势、弱化或去掉独立 critic，适合奖励稀疏或希望实现更简单的 RLHF 流程。具体公式以你读的论文为准，面试里能说清「组内归一、少一个网络、和 PPO clip 的异同」即可。

Q63 KL 散度具体怎么加？太大或太小有什么问题？

思路：
KL 约束参考模型；大小学不动 vs 跑偏，结合曲线。

推荐回答：
在目标函数里对当前策略相对参考模型（SFT）加 KL 惩罚项，或把 KL 当约束用自适应系数。KL 太大：策略几乎不动，学不到奖励信号。KL 太小：策略偏离参考模型过快，可能模式崩塌、胡言或灾难性遗忘。实际会看 KL 曲线与 reward 曲线一起调系数。

Q64 QLoRA 的 rank 怎么设置？

思路：
r 与显存、效果的折中 + 消融意识。

推荐回答：
r 控制低秩矩阵容量，常见 8、16、32、64；显存紧用偏小，效果不够再加大或增加 target module。最好有消融：同一数据子集上对比 loss/下游指标与训练稳定性，而不是拍脑袋。

Q65 训练参数怎么选？有没有调参测试？

思路：
先复现再小网格；诚实说最敏感的超参。

推荐回答：
学习率、batch、accumulation、warmup、max length、KL coef、clip range、生成温度与 top-p 等都会影响。可以说：先参考论文与开源 run，再在小规模上做网格或贝叶斯搜索，固定随机种子对比验证集。诚实说「调过哪几个、哪个最敏感」比报一堆假数字好。

Q66 LoRA 和 QLoRA 区别？

思路：
冻结+adapter vs 4bit 基座+adapter；显存与精度 trade-off。

推荐回答：
LoRA 在冻结的权重旁加低秩适配器训练。QLoRA 把基座权重量化到 4bit（如 NF4），adapter 仍高精度，用分页优化器等稳定训练，显存大幅下降，有时略损精度，适合单卡大模型微调。

Q67 量化之后对训练效果影响？

思路：
噪声与梯度近似；定性 + 若有实测更好。

推荐回答：
4bit 量化引入噪声，梯度通过适配器与反量化近似传回；多数场景 QLoRA 能逼近全精度 LoRA，极端小数据或极难任务可能掉点。可答：我们观测到某指标变化在 x% 内，或「定性上收敛略慢」。

Q68 梯度检查点原理？对训练速度大概减缓多少？

思路：
重算换显存；减缓给区间或诚实说未测。

推荐回答：
前向时不存所有中间激活，反向时重新算一遍前向拿激活，用算力换显存。减缓比例依赖模型层数与实现，常见文献说 20%～40% 量级，你若有实测报自己的数，没有就说「有减缓、和层数正相关，需按卡和业务权衡」。

十二、随机提问（开放题）

本章思路引导

没有标准答案，考表达是否具体、有没有反思习惯。用真实例子和小故事；涉及源码泄露的题守住底线，不传播未授权细节。踩坑题用 STAR 短答即可。

Q69 平时用过哪些 AI agent 工具？

思路：
列真实工具 + 主要用途一句。

推荐回答：
按真实列举即可：Cursor、Copilot、Claude Code、ChatGPT、各类自动化编排等。顺带一句主要用来写代码、查文档、辅助重构还是任务自动化，别空洞。

Q70 你觉得 AI 工具最大的帮助场景是什么？

思路：
具体场景 + 边界在人。

推荐回答：
个人化举例： boilerplate 生成、跨语言 API 查用法、长日志归纳、单测草稿；强调「省掉重复劳动」而不是「替代思考」。可提边界：架构决策与安全仍要人把关。

Q71 有没有遇到过 AI 应用或工具无法解决的场景？

思路：
真实反例 + 人怎么兜底。

推荐回答：
举真实例子：缺乏上下文的长尾 bug、需要现场权限的操作、强合规不能出域的数据、或需要多轮业务扯皮的需求澄清。说明当时怎么用人兜底。

Q72 平时写的代码有多少是 AI 生成的？

思路：
诚实比例 + review 责任。

推荐回答：
诚实区间即可，例如「脚手架和单测多，核心逻辑自己写和 review」。强调 review、测试与责任在自己，符合团队规范。

Q73 OpenClaw 用过吗？架构上有什么优势？

思路：
用过说体验，没用别编架构优势。

推荐回答：
用过就如实说体验；没用过就说未深度使用，只了解定位为 agent 运行时/编排的一类方案，避免编造「优势列表」。若略知：可谈模块化、工具生态或开源社区（仍要谨慎，不确定就说不知道）。

Q74 OpenClaw 或 Claude Code 还有哪些可改进之处？

思路：
建设性列短板，忌攻击性。

推荐回答：
可谈：长任务可控性、企业级权限与审计、本地与混合部署体验、评测与回归工具链、多模态与垂直领域适配。避免攻击性语气，保持建设性。

Q75 Claude Code 源码泄露有没有了解？有什么创新点？

思路：
合规与职业道德：不展开非法泄露细节。

推荐回答：
若没看：直说未跟进泄露内容，只从公开产品体验谈理解。若看了：点 1～2 个技术点（如上下文组织、工具协议），不要传播未授权源码细节，面试里也不建议展开非法来源。

Q76 从开发者角度，做 agent 最难的部分是什么？

思路：
选一个能接自己项目的难点展开。

推荐回答：
可答：评测与对齐（不知道何时算「对」）、长链路错误放大、工具与环境的不确定性、以及产品预期与模型能力不匹配。选一个能接自己项目故事的。

Q77 自己做 agent 踩过最大的坑？

思路：
STAR 短故事，忌空话。

推荐回答：
用 STAR 简短说：现象（死循环/成本爆/幻觉）→ 根因（缺限步、工具返回不洁、prompt 冲突）→ 修复（状态机、摘要、校验）→ 规范（评测用例 + 代码 review）。必须真实或合理虚构，别太空。

Q78 好的 prompt 和差的 prompt 区别？

思路：
可测、可边界、与 system 一致；对比一句差的。

推荐回答：
好的：目标单一明确、约束与输出格式写清、给反例或边界、与 system 不冲突、可测（能写断言）。差的：含糊任务、让模型猜、和工具说明矛盾、没有失败时行为。可举一个小对比例子。

Q79 除了 Qwen3-VL，还用过哪些多模态大模型？

思路：
按实际列模型 + 场景。

推荐回答：
按实际：GPT-4o、Gemini、InternVL、LLaVA 等。说一个使用场景：图表理解、截图 debug、OCR 等。

Q80 有没有了解端侧部署的模型？

思路：
端侧约束：量化、NPU、延迟功耗；了解有限就说有限。

推荐回答：
可提 llama.cpp、ONNX、TensorRT、手机 NPU、小模型量化（INT8/INT4）；点出约束：延迟、内存、功耗与效果 trade-off。没做过就说了解有限，只读过资料。

十三、Python 八股

本章思路引导

答到点上即可：浅/深拷贝举嵌套 list、装饰器提 wraps、字典提哈希与 3.6+ 顺序、死锁四条件背全。别展开成教材。

Q81 深拷贝和浅拷贝的区别？

思路：
嵌套可变对象 + deepcopy 注意点。

推荐回答：
赋值和浅拷贝对嵌套可变对象（如 list 里套 list）共享内层引用，改内层会互相影响。copy.deepcopy 递归复制独立对象，注意循环引用与自定义类的 __deepcopy__。不可变对象如 tuple 里若有可变元素同样要小心浅层行为。

Q82 Python 修饰器知道吗？

思路：
语法糖 + wraps + 带参装饰器多一层。

推荐回答：
装饰器是接收函数返回函数的语法糖，用于日志、缓存、鉴权等横切关注点。带参数的装饰器是多一层嵌套。用 functools.wraps 保留原函数的 __name__ 和 docstring，便于调试与 introspection。

Q83 Python 字典的底层原理？

思路：
哈希表 + 有序 + 均摊复杂度。

推荐回答：
CPython 字典是哈希表，键必须可哈希；开放寻址或类似策略处理冲突（实现细节以版本为准）。3.6+ 字典保持插入顺序（有序作为语言特性）。扩容会 rehash，均摊 O(1) 查找；最坏哈希冲突下退化需注意。

Q84 死锁的条件是什么？

思路：
四条件 + 打破其一的工程手段。

推荐回答：
四个必要条件：互斥、占有且等待、不可抢占、循环等待。预防思路是打破其一：如统一加锁顺序、超时释放、银行家算法（理论）、尽量减小锁粒度。实际工程里还要配超时与监控。

十四、面试后的一点感受（收尾）

这份清单里，项目主线（Agent 架构、LangGraph、上下文、工具与评测）是追问最深的；RAG 和训练线会顺着简历项目二选一挖到底。后端与网络更像扫盲，证明你没有完全活在模型 API 里。

准备时建议：每个大块练一段「2～3 分钟口述版」——结论一句、展开两点、诚实边界一句（哪里没上生产、哪里只读过文档）。比背一百条定义更能扛住追问。推荐回答只是骨架，一定要换成你项目里的真名词和真数字，面试官一听就能追问下去，才像真的做过。

个人整理；思路引导与推荐回答仅供组织语言与技术方向参考，公式与框架细节以论文与官方文档为准。