连环追问题
真实面试不会只问一个点。面试官经常从一个概念开始，连续追到实现、失败、成本和安全。这份文件按“追问链”训练。
使用方法
从“为什么要做 RAG”开始，面试官可能连续追问 chunk、权限、引用、无答案、成本和回滚。练习时每回答一层都留下一个可验证的工程动作，别只换一组术语继续说。
每条追问链都要练到能连续讲 3-5 分钟。不要每题单独背，要把它们串成一条故事线。
追问链 1：从 RAG 问到上线
Q1：RAG 是什么？
RAG 是把外部知识检索进生成过程的系统链路，用来降低知识过时和事实幻觉风险。
Q2：为什么不能直接把所有文档塞进 prompt？
成本高、噪声大、上下文可能爆，而且引用和权限不好追踪。
Q3：chunk 怎么切？
按文档结构和语义切。政策按条款，FAQ 按问答对，技术文档按标题和段落。chunk 太小丢上下文，太大噪声多。
Q4：召回差怎么办？
先查入库，再查 chunk，再查 query 改写、embedding 模型、top_k、混合检索和 rerank，不要一上来改 prompt。
Q5：答案没证据怎么办？
应该明确说知识库没有找到足够依据，不能让模型硬编。可以建议用户换关键词、指定范围或转人工。
Q6：怎么评估？
检索层看 recall@k、MRR，生成层看答案正确率、引用准确率、无答案识别率，系统层看成本、延迟、权限违规率。
Q7：上线后最怕什么？
最怕权限过滤做晚、文档更新不同步、引用不支持结论、用户把无答案问题逼成确定答案。
追问链 2：从 Agent 问到 tool loop
Q1：什么是 Agent？
Agent 是围绕目标做多步决策，并调用工具获取信息或影响外部系统的工程体。
Q2：Agent 和 Chatbot 区别是什么？
Chatbot 偏单轮生成，Agent 偏多步执行。Agent 有工具、状态、循环、终止条件和日志。
Q3：tool loop 怎么写？
用户输入进入 messages，模型判断 tool call，代码校验并执行工具，工具结果按 tool_call_id 回传，模型继续判断，直到 final answer 或触发停止条件。
Q4：为什么不能直接执行模型生成的参数？
模型输出不是可信输入。必须做类型校验、权限校验、范围校验和危险动作确认。
Q5：怎么防止死循环？
最大轮数、重复调用检测、预算限制、错误阈值和人工介入。
Q6：怎么知道 Agent 哪一步错了？
看 trace：每轮模型输入摘要、tool call、工具参数、工具结果、usage、latency、error 和最终输出。
追问链 3：从工具调用问到 MCP
Q1：工具调用解决什么问题？
让模型把实时查询、计算、写操作和外部系统交给代码执行。
Q2：工具 schema 怎么写？
工具要窄，参数明确，required 清楚，描述里写什么时候用和什么时候不要用。
Q3：工具多了怎么办？
做工具路由和动态裁剪，不要一次性把所有工具都塞给模型。
Q4：MCP 解决什么问题？
把外部工具和资源用统一协议暴露给模型应用，方便接入、复用和管理。
Q5：MCP 能替代权限校验吗？
不能。MCP 是接入协议，不是安全边界。权限、参数校验和审计仍要在工具服务侧做。
追问链 4：从多 Agent 问到冲突处理
Q1：什么时候用多 Agent？
任务能清晰拆分、子任务可验收、上下文需要隔离、并行能提升效率时。
Q2：为什么多 Agent 不一定更好？
协调成本、延迟、冲突和调试难度都会上升。
Q3：Agent 之间传什么？
传结构化结果：任务目标、证据编号、已确认结论、未确认项、下游动作。不要传完整聊天记录。
Q4：结论冲突怎么办？
要求双方给证据，比较来源权威性、更新时间和任务目标，必要时保留不确定性。
Q5：同一个文件多个 Agent 都要改怎么办？
单写者原则。其他 Agent 只提交 patch 或评论，patch 带 base version，应用前检查版本，冲突由主管或人工合并。
追问链 5：从成本问到缓存
Q1：一次 Agent 任务成本怎么算？
按每轮 input、cached input、cache write、output 分开算，再加 embedding、rerank、搜索、工具和重试成本。
Q2：为什么不能 total_tokens 乘单价？
因为输入、输出、缓存命中、缓存写入价格可能不同，reasoning tokens 也可能属于输出侧细分。
Q3：cached_tokens 一直是 0 怎么办？
看前缀是否稳定、长度是否足够、是否混入时间戳/request_id、工具列表顺序是否变化、cache key 是否切太碎。
Q4：怎么提高缓存命中率？
稳定内容放前面，动态内容放后面，工具定义和示例顺序固定，同类请求复用稳定 key。
Q5：缓存命中率越高越好吗？
通常是好事，但不能牺牲正确性。不能为了命中缓存把个性化或权限相关内容错误地移到后面。
追问链 6：从评估问到回归
Q1：怎么评估 Agent？
看结果、过程、成本和安全。结果看成功率，过程看工具调用，成本看 token 和延迟，安全看越权和注入。
Q2：eval set 怎么设计？
覆盖正常、边界、无答案、工具错误、安全攻击、多轮任务和长尾样本。
Q3：LLM-as-Judge 怎么用？
用明确 rubric 评开放任务，再做人类抽检校准。能规则判断的不要交给 judge。
Q4：prompt 改了怎么防回归？
固定 eval set 跑前后对比，看成功率、引用准确率、成本、延迟和安全样本是否退化。
Q5：线上发现质量下降怎么办？
先看 prompt version、model version、tool version、knowledge base version 和 trace，不要只凭感觉改 prompt。
追问链 7：从安全问到权限
Q1：Prompt Injection 是什么？
攻击者通过用户输入、网页或检索内容诱导模型忽略系统指令或执行危险动作。
Q2：怎么防？
外部内容当数据不当指令，工具执行前做权限和参数校验，危险动作确认，输出脱敏，日志审计。
Q3：为什么权限过滤要在检索前？
因为如果无权限内容进入 prompt，就已经泄露到模型流程里了。输出后脱敏只是最后一道防线。
Q4：哪些动作必须确认？
删除、退款、支付、发外部消息、修改权限、导出敏感数据、覆盖文件。
Q5：安全能不能靠 system prompt？
不能。system prompt 是软约束，真实安全靠代码权限、工具边界、审计和人工确认。
追问链 8：从模型选型问到部署
Q1：模型越大越好吗？
不一定。大模型能力强但贵、慢。分类、抽取、路由可以用小模型，复杂推理和长上下文任务再用大模型。
Q2：模型路由怎么做？
按任务类型、复杂度、成本、延迟和风险路由。小模型做预判，大模型处理关键步骤。
Q3：量化有什么用？
降低显存和部署成本，可能提升吞吐，但可能损失质量，需要评估。
Q4：batching 有什么影响？
提高吞吐，但可能增加单个请求等待时间。高并发服务要在吞吐和延迟之间平衡。
Q5：为什么长上下文影响并发？
长上下文增加 KV cache 占用，显存压力变大，可同时服务的请求数下降。
追问链 9：从代码审查 Agent 问到误报控制
Q1：代码审查 Agent 看什么？
优先 correctness、安全、数据丢失、并发、事务、测试缺口，再看可维护性和风格。
Q2：只看 diff 够吗？
通常不够。需要补相关函数、类型、测试、规范和接口约束。
Q3：怎么减少误报？
补上下文、只输出高置信问题、限制评论数量、不确定时标为疑问、用人工反馈回流。
Q4：能不能自动改代码？
默认不直接改。生成补丁要基于明确版本，应用前检查文件变化，跑测试并人工确认。
追问链 10：从客服 Agent 问到转人工
Q1：客服 Agent 主要模块是什么？
意图识别、知识库、业务工具、权限确认、人工接管、监控评估。
Q2：读操作和写操作怎么区分？
读操作如查政策、查订单状态，可以自动化。写操作如退款、改地址、取消订单，需要确认和审计。
Q3：用户很生气怎么办？
先承接情绪，再给事实和下一步；涉及投诉、高价值客户或模型不确定时转人工。
Q4：模型乱承诺怎么办？
承诺类内容加口径检查，退款赔付等敏感动作由工具和规则控制，超出政策转人工。
追问链 11：从模型输出问到结构化可靠性
Q1：为什么不能直接把模型输出写进数据库？
因为输出即使是合法 JSON，也可能字段值错误、缺少必要条件或违反业务规则。模型输出只是候选决策，必须经过解析、schema 校验、业务校验、权限检查和必要的人工确认。
Q2：Structured Output 能保证正确吗？
不能。它主要约束结构，不保证事实和语义。比如 amount: 100 结构正确，但用户账户可能没有这笔订单。后端仍需校验资源归属、状态和金额。
Q3：工具调用为什么要设计幂等键？
因为网络超时无法说明请求是否执行成功，客户端或 Agent 可能重试。幂等键让服务端把同一业务动作识别为同一次请求，避免重复退款、重复发信或重复创建任务。
Q4：哪些错误能重试？
网络超时、连接重置、明确的 429/503 通常可以指数退避重试；参数错误、权限拒绝、资源不存在不能原样重试；写操作超时要先查询幂等键或业务状态，再决定是否重试。
Q5：如果工具执行成功但模型没收到结果怎么办？
服务端要根据 request ID 查询执行记录，补发结果或恢复任务，而不是让模型再次盲目执行。对不可恢复的情况应给用户明确状态，并提供人工处理入口。
追问链 12：从 Agent 问到生产运行时
Q1：一个 Agent 运行时最少要保存什么？
任务 ID、当前状态、用户目标、阶段、消息或摘要、工具调用记录、预算、重试次数、版本信息、错误和下一步状态。长期记忆与一次任务状态要分开存。
Q2：为什么不能只把完整聊天记录存起来？
完整记录适合审计和回放，但直接全部塞回上下文会带来 token 成本、噪声和上下文腐化。运行时要保留原始记录，同时生成结构化任务状态、摘要和按需检索的记忆。
Q3：checkpoint 解决什么问题？
它在关键节点持久化状态，使任务可以暂停、恢复、人工审核或从失败步骤继续。checkpoint 不是简单保存最后一条消息，还应包含状态版本、已完成副作用和可恢复边界。
Q4：恢复时如何避免重复执行工具？
记录每次工具调用的幂等键、参数摘要和执行状态。恢复后先查调用记录：已成功就复用结果，进行中就查询状态，失败且可重试才重试。不能根据“模型还没看到结果”推断工具没执行。
Q5：什么时候需要人工接管？
高风险副作用、权限异常、证据冲突、连续失败、预算即将耗尽或用户明确要求人工时接管。接管时要给人工完整摘要、证据、待确认动作和审计记录，而不是只把一堆原始消息丢过去。
追问链 13：从多模态问到工程落地
Q1：多模态 Agent 和文本 Agent 的主要差异是什么？
输入不再只有文本，还要处理图片、音频、视频、版面、时间戳和坐标；输出也可能需要引用页码、框选区域或生成文件。因此要增加媒体存储、转码、OCR、内容安全和结果定位。
Q2：什么时候用 OCR，什么时候直接用视觉模型？
固定文档、批量处理和需要精确文本检索时，OCR 加结构化解析更稳定、成本更可控；复杂版面、表格、图表、签章和视觉关系需要视觉模型复核。生产系统经常两者组合，不把一个模型当万能解析器。
Q3：多模态结果怎么评估？
除了答案正确率，还要看 OCR 字段准确率、页码/坐标定位准确率、表格结构恢复率、音频转写错误率、跨模态引用支持率和不同分辨率下的鲁棒性。
Q4：图片或文件里的恶意指令怎么处理？
OCR 文本、图片文字、文件元数据都视为不可信数据，不能改变系统指令。工具权限和外部动作仍由代码控制，图片解析结果要经过内容安全和敏感信息检查。
Q5：文件很大时怎么控制成本？
先做页级或时间段级路由，定位候选区域，再对相关片段做高质量视觉理解；缓存 OCR 和中间结果，限制总页数、分辨率、帧率和最大 token。需要全篇审阅时也要异步化并提供进度。