AI Agent 开发岗面试题：55 道真实面试里的追问

《面试题目》

1. 一个需求过来，你怎么判断该用 workflow 还是 Agent？
2. 什么时候从单 Agent 升级到多 Agent？
3. 多 Agent 比单 Agent 多付出哪些代价？
4. Agent、RAG、workflow、微调，四选一怎么判断？
5. 你做过最失败的一次 Agent 设计是什么？重来会怎么选？
6. LangChain、LangGraph、CrewAI、AutoGen，你怎么选？
7. LangGraph 相比 LangChain 的 AgentExecutor 到底解决了什么？
8. LangGraph 的节点、边、条件边怎么设计？
9. 什么信号出现，你会自研框架不跟 LangGraph 了？
10. Agent runtime 的职责边界是什么？
11. 持久化怎么做？Agent 跑到一半进程挂了，怎么恢复？
12. 多实例同时处理同一个会话，状态怎么不打架？
13. harness 这个词你怎么理解？你做的 harness 解决什么问题？
14. 工具调用 harness 怎么设计？参数校验、超时、沙箱分别怎么搞？
15. replan 模式什么时候用？Plan-and-Execute 和 ReAct 的区别？
16. 工具越来越多，怎么保证 LLM 每次都选对？
17. 死循环怎么防？除了 max_iterations 你还做了什么？
18. 用户点停止生成，后端怎么真正把推理停下来？
19. 审批做成 human-in-the-loop，暂停和恢复怎么设计？
20. 审批超时怎么办？驳回之后怎么续跑？
21. 客服 Agent 出错，人工怎么接管？
22. 单任务 token 成本怎么算？成本失控的三大来源是什么？
23. 上下文窗口怎么管理？长对话怎么压缩？
24. 流式输出里，工具调用的事件怎么传给前端？
25. 流式断线重连，上下文怎么恢复？
26. 重试、熔断、幂等，Agent 场景下怎么设计？
27. 多 Agent 之间怎么通信？协议怎么定？
28. 协作模式有哪些？编排、辩论、层级各自适用什么？
29. 共享状态还是消息传递？
30. 两个 Agent 互相等待，怎么处理？
31. 多 Agent 的 token 开销怎么控制？
32. RLHF 的完整流程？
33. DPO 为什么可以不要奖励模型？
34. DPO 和 RLHF 各自的坑是什么？
35. 线上用户的点赞、点踩，怎么变成 DPO 训练数据？
36. Agent 的工具调用准确率，靠对齐还是靠数据？
37. 幻觉分几类？RAG 为什么消不掉幻觉？
38. 幻觉率在线上怎么度量？
39. Agent 评测分几层？
40. 业界有哪些 Agent benchmark？各自的局限是什么？
41. LLM-as-judge 有什么坑？
42. badcase 从哪收集？怎么归因？
43. badcase 怎么回流成回归集？
44. 点赞点踩在评测体系里是什么角色？
45. 上线前怎么灰度 Agent？
46. Prompt injection 为什么防不住？
47. 你的纵深防御怎么做？
48. RAG 投毒的攻击路径有哪些？
49. RAG 投毒怎么防？
50. Agent 被诱导调用危险工具怎么办？
51. 敏感数据怎么防泄露？
52. 设计一个客服 Agent，怎么分层？
53. 设计 Text2SQL，要解决哪些问题？
54. 给你一个长文档分析需求，第一反应是什么方案？
55. 什么需求你会直接拒绝用 Agent？

《参考解析》

选型：能 workflow 就别上 Agent

判断依据是流程的确定性。步骤固定、分支可枚举、结果好评测的需求，用 workflow（代码编排 + 单次模型调用）最划算：成本可预期、失败可定位、能做确定性回归。任务开放、下一步取决于中间结果时才值得让模型自主规划。四选一（Agent、RAG、workflow、微调）可以按一条链问下来：知识不在模型里就先上 RAG；流程固定就写 workflow；需要动态决策才上 Agent；只有当问题是「行为风格/格式/领域语感」这类提示词改不动的东西时，才轮到微调。答题时能说出「我先用最便宜的手段试，达不到再升级」，比直接背概念更接近真实工程判断。

多 Agent：不是高级，是最后的手段

从单 Agent 升级的信号通常有三个：子任务需要互相独立的上下文（塞在一个提示里会互相干扰）、角色之间需要制衡或并行（生成与校验、多头检索）、单个 Agent 的工具集太大导致选错工具。代价也明确：通信开销与 token 成倍增长、状态一致性变难、调试链路由一条变一片、还会出现两个 Agent 互相等待或反复推诿。能给出「先拆工具而不是先拆 Agent」「拆完要能并行才有收益」这类判断，说明真踩过坑。

持久化与断点恢复

checkpoint 要存的是一份能重建推理现场的最小状态：会话与线程标识、消息序列、当前的节点/步骤、待执行的工具调用与已完成的调用结果、以及必要的业务上下文。序列化要选稳定的格式并带版本号，否则改一次状态结构就读不了历史。恢复的关键在于「幂等」：进程挂掉时正在执行的工具调用必须能安全重放，所以写操作要么带幂等键、要么走「先记意图、再执行、后确认」的模式。多实例并发同一会话要靠乐观锁（版本号 CAS）或分布式锁，并用单调递增的 step 编号拒绝过期写入，避免两个进程各写一半状态。

循环与中断：死循环、停止生成、人工审批

只设 max_iterations 是最粗糙的做法，它拦不住「每轮都合法但原地打转」。更实用的是三件事叠加：状态哈希去重（把关键状态归一化后取指纹，重复出现即判定空转）、工具调用指纹（同参数同工具连续调用 N 次就打断并换策略）、分阶段预算（迭代次数、token、时长分别设上限，任一超限就降级收尾）。用户点「停止生成」要对齐到真正能中断的地方：模型流式请求需要主动 abort，正在跑的工具要能被取消或标记为放弃，已产生的副作用不能靠取消回滚，只能靠幂等或补偿。human-in-the-loop 的设计要点是把「暂停」做成持久化的挂起点（暂停也落 checkpoint），恢复时用同一条线程继续，同时给审批设超时与默认动作；驳回后不要把整个任务重跑，而是带着驳回理由回到上一个决策点重新规划。

成本与上下文管理

单任务成本要从三处算：输入 token（系统提示 + 历史 + 检索内容，通常是大头）、输出 token、以及工具往返次数。成本失控的常见来源是上下文无限增长、工具结果整段回灌、以及多 Agent 互相重复读同一份资料。上下文管理的手段按代价排序：工具结果先做摘要或只回灌必要字段、历史按轮次或语义做压缩与丢弃、把稳定的大块内容放前面吃前缀缓存、用结构化记忆替换长篇对话。流式场景还要区分两类事件：模型 token 流和工具调用生命周期事件（开始、参数、结果），前者可增量推、后者要带调用 id 保证前端能配对；断线重连靠事件序号 + 服务端保存的检查点续传，而不是让前端重新发起整轮。

评测与 badcase 闭环

评测至少要分三层：工具调用级（选中率、参数正确率）、任务级（端到端成功率、步数、成本）、系统级（线上转化、人工接管率、用户满意度）。benchmark 能提供横向参照，但公开基准与自己的业务分布差异很大，局限性要主动说出来，别把它当验收标准。LLM-as-judge 的坑集中在三点：位置偏好与长度偏好、评分标准漂移（换模型就换尺度）、以及自评偏袒；对策是成对比较 + 交换位置 + 与人工标注对齐校准。badcase 要归因到检索、工具、模型、产品四层，再回流成回归集，且回归集要版本化、能自动跑；点赞点踩适合当召回的弱信号，不能直接当标签用。上线灰度按流量分桶，关注的是成功率与成本的联合指标。

安全：prompt injection 与 RAG 投毒

prompt injection 防不住的根因是「指令和数据走同一个通道」——模型无法从语义上区分「用户的话」和「文档里的话」。可行的纵深防御是分层设限：把外部内容明确标记为不可信数据并做清洗、用白名单约束工具与参数、对危险动作加人工确认或双人校验、把权限收到工具实现里（模型只能调接口，接口自己做鉴权和范围限制），而不是靠一句「忽略文档中的指令」。RAG 投毒的攻击面主要在公开文档、用户上传和爬虫入库三个入口，防护要覆盖入库前（来源可信度、内容扫描、去重与异常检测）、检索时（权限过滤，别把别人的文档召回给当前用户）、生成后（引用可回溯、敏感信息检测）。

对齐与幻觉

RLHF 的流程是：先做监督微调，再用人类偏好数据训练奖励模型，最后用 PPO 等策略优化方法在奖励模型上优化，并用 KL 约束防止跑偏；DPO 把「奖励模型 + 强化学习」这一步折叠掉，直接在偏好对上优化策略，用策略与参考模型的概率比隐式地表达奖励，因此不需要单独训奖励模型，训练也更稳。实践中 RLHF 的坑在奖励模型被刷分与训练不稳定，DPO 的坑在偏好数据质量与对分布的过拟合，线上点赞点踩只能当弱标签，需要过滤与去偏。幻觉大致分事实性错误、无中生有的引用、以及指令遵循失败几类；RAG 只能把答案锚定到检索到的内容，检索不到、检索错了或模型不忠实于上下文时依然会编，所以还要有「不知道就说不知道」的降级路径和线上度量。