开放问答题
开放题没有固定答案。面试官通常用它看你是不是只会背概念，还是能自己组织方案。
Q1：你会怎么从零设计一个 Agent 应用？
开放题可以用“退款客服 Agent”练习：先问成功标准和风险，再给最小闭环，最后补权限、确认、失败、指标和回滚。这样比一上来报出一串框架名更容易让面试官跟上。
参考答案
我会先定任务边界，而不是直接写 prompt：
- 用户是谁，任务是什么，输出是什么。
- 哪些步骤需要模型判断，哪些步骤应该由代码确定。
- 是否需要工具、检索、状态和记忆。
- 设置最大轮数、预算、权限和人工接管。
- 记录 trace 和 usage。
- 用一组 eval 样本跑回归。
最小版本先跑通一个闭环，再逐步加工具、RAG、多 Agent 和评估。
Q2：你如何判断一个 Agent 系统是否“靠谱”？
参考答案
我会看四件事：
- 结果是否正确。
- 过程是否可控。
- 成本是否可接受。
- 出错能否复盘。
具体指标包括任务成功率、工具调用正确率、引用准确率、无答案识别率、P95 延迟、P95 成本、注入拦截率、权限违规率。
Q3：你如何解释“LLM 应用不是 prompt 工程，而是系统工程”？
参考答案
prompt 只是输入组织方式。真正让系统可靠的是工具边界、检索质量、状态管理、缓存、权限、安全、日志、评估和回归。
一个 prompt 可以让 demo 看起来能跑，但上线要面对错误输入、工具失败、成本长尾、权限隔离、数据更新和用户攻击。这些都不是一句 prompt 能解决的。
Q4：如果一个 Agent 效果不好，你会先做什么？
参考答案
我不会第一时间换模型或改 prompt，而是先看 trace：
- 输入是否清楚。
- 检索是否命中。
- 工具是否调用正确。
- 上下文是否太长或太脏。
- 输出是否有证据。
- 成本是否集中在某一步。
先定位是哪一层坏，再决定改 prompt、改检索、改工具、改模型还是改流程。
Q5：你怎么把 demo 变成可上线系统？
参考答案
我会补这些东西：
- 参数校验。
- 权限控制。
- 错误处理。
- 最大轮数和预算。
- 日志和 trace。
- eval set。
- 安全样本。
- 成本统计。
- 人工兜底。
Demo 只证明主路径能跑，上线要证明边界能守住。
Q6：如何向非技术同事解释 RAG？
参考答案
我会说：模型自己回答像凭记忆回答，RAG 是让它先去资料库找证据，再根据证据回答。这样能减少乱编，也能告诉用户答案来自哪里。
但我也会提醒：如果资料库本身错了、没更新、没权限控制，RAG 也会错。
Q7：如何向面试官解释你做过 Agent，即使只是学习项目？
参考答案
不要夸大生产经验。可以讲你做过的最小闭环：
- 手写 tool loop。
- 接入一个或多个工具。
- 记录每轮调用。
- 加最大轮数和错误处理。
- 用几条测试样本验证。
重点是你知道模型和代码的边界，而不是包装项目规模。
Q8：你认为 Agent 系统最难的地方是什么？
参考答案
最难的不是调用模型，而是控制不确定性。具体包括：
- 什么时候让模型决策。
- 什么时候用代码兜底。
- 工具失败怎么办。
- 上下文怎么控制。
- 成本怎么防长尾。
- 错了怎么复盘。
Agent 难在系统边界，不难在“调一次 API”。
Q9：如果业务方要求“模型必须什么都答”，你怎么处理？
参考答案
我会解释必须区分“能答”和“有依据地答”。对事实性、权限性和高风险问题，系统必须允许说不知道、拒答或转人工。
强行什么都答，会提高幻觉、越权和合规风险。
Q10：你如何设计 Agent 的人工接管机制？
参考答案
人工接管条件包括：
- 连续失败。
- 工具返回异常。
- 低置信度。
- 高风险写操作。
- 用户明确要求人工。
- 涉及投诉或敏感信息。
接管时要把上下文、已执行工具、证据、错误和用户目标整理成摘要传给人工，不要只转一段聊天记录。
Q11：如何设计 Agent 的权限体系？
参考答案
权限要放在工具和数据层：
- 用户身份决定能查哪些文档和工具。
- 工具执行前校验权限。
- 检索前过滤无权限文档。
- 高风险动作需要确认。
- trace 记录访问和操作。
不能靠模型自己判断用户有没有权限。
Q12：如何设计 Agent 的成本预算？
参考答案
预算可以分层：
- 单次请求 token 上限。
- 单任务最大轮数。
- 单工具调用次数。
- 单用户每日预算。
- 总任务超预算时降级或转人工。
同时记录每一步 cost，找出成本最高的步骤。
Q13：你如何处理模型输出的不确定性？
参考答案
我会让系统显式表达不确定性：
- 证据不足时说不知道。
- 来源冲突时列出冲突。
- 低置信度时转人工。
- 高风险场景不做确定承诺。
不确定性不是坏事，隐藏不确定性才危险。
Q14：如果用户要求模型执行危险命令怎么办？
参考答案
模型不能直接执行命令。危险动作必须经过工具层白名单、权限校验和人工确认。对于删除、付款、发邮件、改权限、覆盖文件等动作，默认拦截或确认。
Q15：你如何设计 prompt 版本管理？
参考答案
每个 prompt 模板要有版本号。trace 记录 prompt version、model version、tool version 和知识库版本。改 prompt 后用固定 eval set 跑回归，不能凭几个 demo 样本上线。
Q16：你如何决定是否微调模型？
参考答案
我会先看问题是否能用 prompt、schema、RAG 或工具解决。如果问题是格式稳定但 prompt 成本太高、示例很多、行为长期固定，并且有高质量训练数据，再考虑微调。
知识更新问题不优先微调，优先 RAG。
Q17：你如何设计一次 Agent 评审会议？
参考答案
我会让团队看几类样本：
- 成功样本。
- 失败样本。
- 成本最高样本。
- 延迟最高样本。
- 安全攻击样本。
- 用户投诉样本。
然后按 trace 定位原因，不只讨论最终答案好不好。
Q18：如果面试官问你最熟悉哪一块，怎么答？
参考答案
不要泛泛说“我都熟”。可以选一条主线：
我比较熟悉 Agent 工具调用和 RAG 落地。
我能手写 tool loop，也知道参数校验、最大轮数、trace 和成本统计；
RAG 这边我会从入库、chunk、召回、rerank、引用和评估这条链路讲。Q19：你如何处理用户隐私数据？
参考答案
原则是最小暴露：
- 不必要的数据不进模型。
- 日志脱敏。
- 检索按权限过滤。
- 工具返回只给必要字段。
- 高风险数据禁止缓存或严格隔离。
Q20：如何回答“你这个方案最大风险是什么”？
参考答案
不要说“没什么风险”。可以说：
最大风险是检索证据不准导致答案看起来可信但实际错误。
我会用引用准确率、无答案识别率和人工抽检来控制，同时让系统在证据不足时明确说不知道。风险说得清，反而更像真的懂。
Q21：如何解释“不要把模型当权限系统”？
参考答案
模型是生成器，不是安全边界。它可能被 prompt injection 影响，也可能误解用户身份。权限必须由代码、数据库和工具服务校验。
模型最多参与“判断意图”，不能决定“是否有权执行”。
Q22：如果上线后用户说答案不可信，你怎么改？
参考答案
先补证据链：
- 答案带来源。
- 引用到具体段落。
- 证据不足时说不知道。
- 对冲突来源做标注。
- 增加引用准确率评估。
可信不是靠语气自信，而是靠证据和可追溯。
Q23：如果 Agent 经常调用错工具怎么办？
参考答案
我会检查：
- 工具名和描述是否清楚。
- schema 是否过宽。
- 工具列表是否太多。
- prompt 是否写了触发条件。
- 是否需要工具路由。
- 是否有工具调用 eval。
Q24：如果模型回答太啰嗦怎么办？
参考答案
先看输出要求是否明确。可以用结构化输出、长度限制、示例、后处理或分阶段生成。不要只在 prompt 里说“简洁一点”，要定义什么是简洁：比如最多 5 条，每条不超过 30 字。
Q25：如果业务方要求“像人一样思考”，你怎么转成工程语言？
参考答案
我会把它转成可实现要求：
- 能拆任务。
- 能调用工具。
- 能在证据不足时追问。
- 能发现错误。
- 能记录过程。
- 能在高风险时转人工。
工程上不实现“像人”，实现可观测、可控、可评估的行为。
Q26：你如何设计一个 Agent 的上线闸门？
参考答案
我会把上线闸门分成质量、安全、可靠性和经济性四组。质量上要求核心任务成功率、关键事实正确率、工具调用正确率达到基线；安全上要求越权、注入、敏感泄露和危险动作样本没有高严重度问题；可靠性上检查超时率、错误恢复率、P95 延迟和人工接管链路；经济性上检查单任务成本、最大预算和缓存/路由策略。
闸门必须比较“新版本 vs 当前线上版本”，而不是只看新版本绝对分数。关键指标下降超过阈值就阻止发布；通过后先灰度，按租户或流量比例放量，持续观察真实 trace，最后保留一键回滚到 prompt、模型、工具和知识库版本。
Q27：如何判断一个 Agent 的失败是模型问题还是系统问题？
参考答案
先把一次运行拆成可观测节点：输入解析、路由、模型输出、结构校验、工具执行、检索、状态更新和最终生成。模型没有选工具可能是描述或上下文问题；工具参数合法但执行失败可能是业务服务问题；证据正确但答案错可能是生成或引用绑定问题；权限泄露则优先当系统边界问题处理。
我会用固定样本复现，锁定 prompt/model/tool/KB 版本和采样参数，比较同一节点的输入输出，并用最小替代组件做隔离实验。不能只看最终文本就下结论，也不能把所有问题都归因于 prompt。
Q28：如何让 Agent 支持取消、暂停和恢复？
参考答案
运行时要把任务建模为有状态执行：queued -> running -> waiting_confirmation -> paused/failed/completed。每个节点检查取消信号，模型流和工具请求支持 cancellation；暂停时持久化 checkpoint，恢复时加载版本一致的状态并跳过已成功的幂等动作。
用户取消只代表不再等待结果，不能自动撤销已经产生的外部副作用。因此对发送、支付、写库等动作要单独设计撤销或补偿状态，并告诉用户动作已经执行到哪一步。
Q29：如果只能选三个线上指标，你选什么？
参考答案
没有脱离业务的固定答案。如果是知识问答，我会选任务成功率或人工解决率、引用支持率、P95 延迟；如果是工具型客服，我会选任务完成率、危险/错误动作率、P95 延迟；如果预算压力很大，再把成本加入核心指标或设置硬预算闸门。
指标必须能关联到 trace 和用户价值。单看点赞率或平均延迟容易掩盖长尾失败，至少要按模型、租户、任务类型和风险等级切片看。
Q30：你会如何设计模型不可用时的降级？
参考答案
先区分任务风险和可降级程度。低风险问答可以切到小模型、模板或缓存；只读查询可以直接返回业务系统状态；长任务可以排队等待；涉及退款、发信、权限决策等高风险动作不能因为主模型不可用就放宽规则，应该暂停或转人工。
降级结果要明确标记，避免小模型输出被伪装成正常高置信答案。网关需要记录降级率、降级后的成功率和成本，并定期用 eval 验证备用路径。
Q31：如何设计用户反馈闭环，而不是只收一个赞/踩？
参考答案
反馈至少要关联任务 ID、答案版本和具体问题类型。可以让用户标记“事实错误、没有解决、引用不对、太慢、表达不清或权限问题”，并允许补充正确答案或上下文。高严重度反馈进入人工复核，确认后沉淀为 eval 样本、工具规则、知识库修订或 prompt 改动。
反馈数据不能直接拿来训练模型：要去重、脱敏、确认标签质量，并区分用户不喜欢答案和答案确实错误。只有经过标注和回归验证，反馈才适合进入优化流程。