AI Agent 面试记录

按时间讲比堆关键词顺：multipart 与 Content-Length、断点与校验、落盘与临时目录、异步扫描别堵主链路、解析要流式、下游用 MQ 解耦、背压与限流、进度查询与清理审计。优化从「别一次性读进内存」说到 sendfile、mmap、worker 池，已经足够体面。

摸肚子的小胖子

321人浏览 · 2026-05-07 11:19:20

摸肚子的小胖子 · 2026-05-07 11:19:20 发布

AI Agent 面试记录

最近面了一些 AI Agent 方向的岗位，面完按记忆把题串起来写下面这篇，分享给可能用得上的朋友。内容是好几场面谈里碎片问题的合集，不保证每家公司问法一样；单独看每个问题都像八股，串在一起会发现面试官的注意力经常在两条线上晃：

一条是这东西在线上会不会出事；
一条是你知不知道自己在用什么、没用上什么。

说明： 不是换工作，单纯去面试了一下，留个记录方便以后复盘。

下面按我自己后来复盘时觉得顺的思路写——从项目怎么讲，一路滑到 LangGraph、记忆、Agent 形态、工具协议、RAG，最后落到后端那几道「看起来基础、其实能问穿」的题。后半截仍保留一份提纲式的 checklist（RL、随机提问、Python 八股），方便对着补空。

一、JD 里夹后端、简历却偏 Agent 时

JD 里夹一两条后端要求、简历主战场却是 Agent 的情况越来越多。简历能过的话，业务面通常不会按科班把你问到红黑树，但会看你在链路上有没有常识、愿不愿意补。没后端经历就把流程画全、故障点能指当底线，有余力再摸 asyncio 和你用的 web 框架的请求生命周期。HTTP、流式、异步、装饰器这类属于「互联网底座」，哪怕岗位没写，抽空过一遍也不亏——属于那种会了不加分太多，不会就很显眼的类型。

二、从项目讲起：先别急着报框架名

几乎所有 Agent 岗都会从项目开刀。容易踩的坑是开场三十秒就把 LangGraph、LangChain、某某向量库全报一遍，对方听完礼貌点头，接着问「用户一句话进来之后，系统里第一个写日志的地方在哪」——这种题一卡，框架名就白报了。

人家要的不是技术选型朗诵，而是一条能画出来的因果链：业务上解决什么问题，输入输出边界在哪，谁负责把自然语言变成可执行步骤，谁调工具、谁汇总，失败之后状态落在哪一层。这些讲清楚以后，再提 LangGraph 只是「我用图来承载这条链」，顺序不能反。

2.1 为什么用 LangGraph、有什么缺点、是不是过度设计

这三问通常连着来，本质是在测有没有做过取舍。

图框架的价值在于把「分支 + 状态 + 可持久化的人机协同」从业务代码里抽出去；checkpoint 和 interrupt 一旦真的用在审批、补全、半自动流程里，省掉的胶水代码是实打实的。反过来，如果图退化成线性三步——调模型、调工具、再调模型——框架带来的复杂度未必划算，调试时还要在框架抽象和实际问题之间来回跳，版本升级也容易踩雷。

过度设计不是道德判断，而是可量化的问法：图的边和条件是不是对应了真实业务分支？checkpoint 里存的东西有没有生命周期策略？答不上来，很可能确实用重了。

2.2 为什么不直接用 Cursor Composer、Claude Code 或公司现成的 Agent

听起来像抬杠，其实是在问边界与主权。自研或半自研通常不是为了证明「我比产品强」，而是为了：数据路径可控、工具与权限模型跟内部系统对齐、评测指标跟业务定义一致、排期和回滚不绑在外部发版节奏上。

2.3 基于现成方案改造怎么说才像干过活

可以拆成四层说：协议层（工具 schema、上下文怎么对齐）、资产层（prompt / skill / 评测集怎么迁移）、运行层（灰度、熔断、限流、观测）、组织层（谁维护版本、事故怎么归因）。中间提一句「别 fork 到死，先 adapter 再接」比空喊「我们会二次开发」具体得多。保留产品对话与编辑能力的前提下，外层加企业连接器、策略层、评测与沙箱、必要时封装记忆与检索，风险收口在适配层。

2.4 工具链能不能 Skill 化、项目有没有演进价值

连着问时，多半在看你想不想把东西当成产品养。Skill 化在我理解里不是把 markdown 换个名字，而是把「高频任务的打法」变成可版本、可组合、可测的资产：入口收敛到少量稳定工具，流程和边界写清楚，配上回归用例。工具偏原子能力；Skill 偏流程与约定（何时用哪些工具、模板、失败重试策略）。

演进价值别用空话撑，可以落到：新数据源接进来要改几处、线上 bad case 有没有入库闭环、新人接手要不要读五千行 prompt——能讲出成本和收益，比喊「大模型还能更强」诚实。

2.5 评测、数据集、沙箱、监控

想听的是闭环，不是名词表。离线集怎么分层（简单 / 长尾 / 对抗）、标注是谁做的、有没有泄漏进训练；在线除了成功率、延迟、token、工具错误率，人工抽检比例和抽样策略也可以提一句。

沙箱至少要说清隔离了什么：网络、文件系统、进程还是整个容器。监控至少要到 trace id、节点级耗时、失败重放能不能做到。

2.6 准确率还能怎么优化

只答「调 prompt」会显得薄。数据侧：难例挖掘与难例合成；模型侧：换强模型、蒸馏、任务型微调；系统侧：结构化输出、后处理校验、低置信度转人工；RAG 侧：chunk、路由、rerank。不必全做过，但要让人听出你知道问题可能出在哪一层。

三、LangGraph：checkpoint 不是「存档」，是「可重放的状态机快照」

3.1 中断与恢复

只背「序列化进数据库」还不够深。interrupt 在语义上往往是人机协同的挂起点：图跑到某个节点发现缺信息、或需要审批，于是把当前已提交的状态和尚未完成的副作用边界交代清楚。

恢复时要讲清：哪些 channel 的值写进了 checkpoint、pending 的边在 resume 时会不会重跑、外部副作用（发邮件、扣款）有没有幂等键。thread_id 怎么设计、和业务主键是不是一回事，很容易被追问。一种习惯是把「编排用的会话 id」和「领域里的订单号」分开：前者给图用，后者进 state 字段，恢复时用业务键做幂等，避免把领域模型和框架状态糊在一个 giant dict 里。

3.2 节点之间传复杂数据

表面是 TypedDict / Pydantic 堆字段，实质是状态演化策略：哪些字段 append-only、哪些要 merge、哪些在某条边之后清空。LangGraph 的 reducer 不是语法糖，是在约束「并发写同一字段时语义是什么」。团队里若没人写这份约定，半年以后图很容易变成谁也不敢动的黑箱。复杂对象拆可序列化结构，大对象用引用 + 外存，别把整份日志塞进 state。

3.3 checkpoint 存哪、怎么恢复

内存、SQLite、Redis、云 KV 看部署。恢复：load thread_id → hydrate state → 从断点边继续。state schema 升级后老 checkpoint 怎么办，也要能聊两句。

3.4 checkpoint 膨胀与上下文变长

逼你把图内 state 和外置记忆划界。图里只留当前任务推进必需的东西：最近几轮对话、未完成的工具结果、路由需要的标志位。跨会话偏好、海量历史、可检索知识该进库就进库，用检索回填，而不是无限往 checkpoint 里塞。工程上还有 TTL、里程碑裁剪、敏感字段脱敏、多租户命名空间——能说出来，对方就知道你考虑过线上跑一年之后会发生什么。

3.5 用 LangGraph 做 A2A（Agent-to-Agent）

不必装成做过分布式 Agent。把问题降维成「多进程协作里协议与超时」：子图或节点代表另一个 agent，外层负责信封格式、correlation id、超时和幂等；或用消息总线解耦，图只管本地编排。关键不是炫架构名词，而是消息 schema、失败语义、重试会不会重复扣费。

3.6 节点异常

别只列重试、降级、熔断。分类：网络抖动和代码 bug 不是一类事；读多写少的工具重试可以松，写路径要么幂等要么人工介入；把原始堆栈直接喂回模型有时是安全隐患。

3.7 扩展性

自我批评一句「当时 state 切得太粗，加功能要改十个文件」往往比吹嘘「特别好扩展」可信。加节点优于改全局逻辑、子图封装、新字段 backward compatible。

四、上下文与记忆：难的不是「记住」，是「记对」和「别记爆」

4.1 长对话

表面是窗口不够长，底层经常是注意力分配与事实一致性一起崩：早期约束被稀释、工具读回的事实和幻觉混在一起、摘要滚动以后细粒度条件丢失。手段：滑动窗口、摘要、分层 system prompt、关键事实结构化槽位、需要时再 tool 查。

多补一层：摘要不是无损压缩，滚动摘要会带来事实漂移——后面轮次模型以为用户同意的是 A，其实用户早期说的是 B 的否定形式。所以长期记忆写入前要有触发与校验，读出时要有时间戳或置信度，必要时让模型显式引用记忆条目而不是自由发挥。

4.2 长短期怎么分

别停在定义。短期可以是「仍在当前任务闭环内的、且尚未被结构化吸收的多模态往返」；长期则是跨 session 仍应成立的用户偏好、结论、可检索知识。写入不能默认每轮都存，否则向量库里全是噪声；可组合显式指令、对话结束事件、实体抽取置信度阈值。读取侧要有 query 改写 和 metadata 过滤，否则检索会把很久以前的闲聊拉回来。

4.3 哪些能删、哪些不能删

没有银弹，但有启发式：未完成任务状态、用户硬约束、尚未写进摘要或结构化槽位的工具原始返回，一般别乱动；寒暄、重复表述、已被摘要覆盖的细节可以裁。规则加小模型辅助加业务白名单，线上往往比「全靠大模型自己决定删什么」稳。

4.4 除了压缩

上下文路由（不同子任务用不同窗口）、外置真相源（以数据库为准，不以对话为准）、小模型专责压缩（主模型只消费压缩产物）。项目里长期记忆和上下文工程具体做了什么，各人填各人的坑；没做过也要讲清权限与隐私：记忆是否按用户隔离、有没有删除权、合规上能不能存。

五、Agent 形态：ReAct 和 Plan-Execute 差不只是「先想再做」

5.1 ReAct 循环怎么限制、怎么稳

别只报最大步数。深一点：这是在部分可观测环境里做决策，工具返回就是观测。限制手段包括步数、token、wall-clock 超时、同一工具同参重复检测、对「连续空转」的语义检测。稳定性除了 schema 严格、解析失败重试，还可以谈观测性：每一步输入输出是否可结构化日志、能否离线重放——对线上排障比「我 prompt 写得很严」有用。

5.2 Plan-Execute 与 ReAct

用成本与可修正性讲。ReAct 适合环境反馈密、探索路径不可预见；Plan-Execute 适合步骤大体可枚举、工具调用贵、希望人类先看一眼计划的任务。Plan 错了谁负责？要么计划阶段人机确认，要么执行阶段允许局部重规划，否则一步错带着整链错。tool call JSON 坏了，是自纠一轮还是模板化重问，比空喊约束实在。

5.3 多智能体

层级 supervisor、流水线、对等协作，各自有通信：黑板、队列、RPC、外层 orchestrator。缺点要会讲：调试地狱、责任边界模糊、消息风暴。

5.4 怎么让 Agent「越用越聪明」

别往玄学走：bad case 入库、策略从轨迹里蒸馏、工具文档迭代、评测驱动发布——没有数据闭环，聪明没有落脚点。

5.5 Harness 与 benchmark

Harness 不是「有个测试脚本」，而是一套可复现实验台：环境镜像、依赖 pin、数据集版本、评分器定义、并发与超时、对抗与长尾用例。

SWE-bench、GAIA、AgentBench、τ-bench 等测的不是一类能力，挑一两个说清适用域比报菜名强。CC 类产品公开架构有限，用「模型层 + 工具路由 + 上下文与产品层」这种粗粒度描述反而安全，别装内部人士。

六、工具、Skill、MCP：能力是能力，契约是契约

6.1 工具失败与稳定性

往深了说是错误语义与重试风暴。超时多长取决于下游 p99 和你的 SLA；重试要带 jitter，写路径要幂等键；返回给模型的错误信息要裁剪。循环调用除了同参同结果，还可以谈语义重复：模型用不同措辞刷同一个读接口。

6.2 一百个 tool 的设计

核心是发现与加载：不要一次性把一百份 schema 塞进上下文。分层、meta-tool 列目录、检索式 tool selection、按租户裁剪可见工具集，和后端 RBAC 是同一类问题。

6.3 并行与顺序

无依赖 asyncio.gather 一类并行，有依赖拓扑排序；planner 显式产出 DAG 比全靠模型隐式排序稳。并行时要谈错误聚合与最慢者拖死整体。

6.4 Skill、Tool、MCP 的边界与演进

Tool：可调用的原子能力。Skill：可版本的工作方式说明加少量入口工具。MCP：更像宿主与能力之间的传输与描述契约；stdio 适合本地紧耦合，HTTP/SSE 适合远程服务化。

演进不必二极管：没有 tool 的 skill 是文档，没有 skill 约束的一百个 tool 是灾难；产品化往往是上层 skill 收敛心智负担，下层 tool 保证可执行与审计。

七、RAG：从「能搜到」到「敢引用」中间差了好几道工序

7.1 用什么库、多少数据

潜台词往往是索引生命周期与一致性。全量重建简单但窗口期长；增量 upsert 省时间但要处理删除、更新、embedding 模型升级后的重嵌入。为什么不用普通数据库：不是不能，而是规模、延迟、混合检索上来以后，专用向量索引或至少 pgvector 这类扩展更省事——本质是 ANN 与倒排的组合战，不是向量神秘学。

7.2 检索方式

hybrid 在大多数文本域是合理默认；multi-query 解决表述多样性；HyDE 适合 query 极短或极口语；parent-child 解决小块精准、大块上下文的问题。

7.3 为什么要单独 rerank

除了成本，还有排序目标与生成目标不一致：cross-encoder 类 reranker 对候选列表做细粒度交互，比让生成模型在千级候选上「顺便排一下」更可控，tail latency 也好谈。大模型排十条可以，排一千条是另一套经济账。

7.4 构建流程到生成

深一点可谈引用与拒答：检索块是否带进 citations、模型胡说时后处理能不能校验 span。召回不到时，除了扩 query、降阈值，还要怀疑 chunk 是否切在句中、元数据是否丢、域内词是否没进词表。

7.5 Code-RAG、关联文档、黑话

Code-RAG 多提一句符号级召回与结构感知。关联文档与黑话：关系进 metadata、术语表、query 归一、领域 embedding——关键是别假装一种方法包打天下。

八、后端与基础：基础题答穿，靠的是「链条」不是「定义」

8.1 大文件全链路

8.2 HTTP

从 URL 到 view 返回，把 DNS 缓存、TCP/TLS、反向代理、worker、ORM、连接池串成一条线。状态码抓 401/403、502/504、408 讲清场景。

8.3 流式

别只背 SSE 和 WebSocket：chunked、nginx proxy_buffering off、SSE 的 event 格式和注释心跳，能说到这一层，对方能判断你是不是只调过高层封装。

8.4 SSE、WebSocket、asyncio

SSE 单向、HTTP 友好，适合模型 token 流；WebSocket 全双工；asyncio 协作式并发，阻塞调用会卡死事件循环。

8.5 Python：装饰器、迭代器、`*args` 与 `**kwargs`

装饰器管横切关注点；迭代器管惰性消费；流式结合 yield、async generator、StreamingResponse。注意常见笔误：关键字参数字典是 **kwargs（两个星号），不是 *args 混在「kwargs」那题里。

8.6 C/C++ 到执行与 Python

预处理、编译、汇编、链接对比解释字节码与 VM；提类型检查时机、内存管理、性能特征即可。

九、项目深挖（绑定简历，只列角度）

已有 CC 类产品为何还做类似项目：场景、数据、流程、合规、集成深度。
与 CC 核心差异、优劣：可控性、体验、生态、成本，诚实说。
分层上下文每层管什么：raw 对话、摘要、事实、检索各层职责。
摘要用什么模型、质量怎么保证：小模型摘要 + 抽检、关键句、结构化字段、人工 golden。
Subagent、多 Agent 目的：并行、专长、上下文隔离；成本与通信要说。
主从通信：消息格式、共享 state vs 消息传递、同步点。
死循环：重复 state/重复 tool、步数上限、强制反思节点。

十、强化学习 / 训练（项目里常被追问的提纲）

GRPO 与 PPO： PPO 是 clip 限幅的经典策略梯度路线；GRPO 一类常用组内相对奖励简化 baseline，答方差与实现取舍即可，公式别背飘。
KL 散度： loss 里 KL(policy‖ref) 防偏离参考太远；系数太大更新保守，太小易跑飞；常配合 target KL、自适应系数。
QLoRA 的 rank： r 控容量，在效果与显存/速度间扫。
训练参数： lr、batch、warmup、epoch、max length、梯度累积，结合显存与曲线，有 wandb 对照更好。
LoRA vs QLoRA： 量化基座 + LoRA 省显存，精度与稳定性单独说。
量化对训练效果： 推理量化与训练时 QLoRA 分开谈；一般小幅掉点，靠 rank、数据、超参补。
梯度检查点： 不存中间激活、反向重算换显存；训练变慢常见一截比例，没实测别说死成某一个数。

十一、随机提问（软实力 + 产品感）

用过的工具如实列举，一个具体工作流比十个名字强。AI 最大帮助场景、解决不了的场景，都结合例子答。代码多少是 AI 写的：诚实，强调审查、测试、架构仍人负责。OpenClaw、CC 可改进点：了解多少说多少；涉及未授权源码的话题从合规角度谨慎，可谈公开设计理念。做 Agent 最难：评测、生产稳定性、权限安全、产品边界选深一个。踩坑准备真实短故事。好 prompt：目标清、约束具体、有验收标准；差的：大而空、角色堆砌。

多模态除 Qwen3-VL 外可提用过的模型与场景；端侧：小模型、量化、ONNX/Core ML、隐私与延迟，点到即可。