小米 AI Agent 二面：金融理赔的确定性与追责

《面试题目》

1. 请你先做一个自我介绍，然后讲讲传统后端和 LLM 应用开发的核心差异。
2. LLM 应用的确定性怎么保证？概率性怎么处理？你怎么看这个问题？
3. 幻觉怎么处理？格式不稳定怎么处理？上下文丢失呢？
4. 上下文丢失怎么处理？模型版本变化怎么处理？有没有兜底方案？
5. Prompt 注入怎么防？有哪些具体手段？你实际用过哪个？
6. 如何设计一个面向保险理赔的 Agent？整体方案是什么？
7. 理赔场景需要哪些工具？工具调用顺序怎么编排？依赖关系怎么处理？
8. 如果用户材料不全，Agent 怎么处理？怎么引导用户补充？
9. 多轮对话中用户改了口供，怎么处理？之前的结论怎么回滚？
10. 理赔金额计算错误怎么办？怎么校验？谁来兜底？
11. 高风险操作怎么二次确认？人工审核怎么介入？什么时候转人工？
12. 你怎么做权限控制？租户隔离怎么做？数据怎么隔离？
13. 数据脱敏怎么做？脱敏后怎么排查问题？会不会丢关键信息？
14. 审计日志怎么设计？记录哪些字段？怎么保证不可篡改？
15. 如果 Agent 给出错误结论，怎么追责？责任怎么划分？
16. 你怎么做 Agent 的可观测性？Trace 怎么设计？关键指标有哪些？
17. 关键指标有哪些？告警阈值怎么设？怎么发现异常？怎么定位？
18. 线上故障怎么排查？熔断降级怎么做？如果模型服务挂了怎么兜底？
19. 你怎么控制成本？有哪些具体策略？省了多少？怎么算的？
20. 如果让你设计一个金融风控 Agent，你会怎么做？和理赔有什么区别？
21. 规则引擎和模型怎么配合？谁先谁后？冲突了听谁的？
22. 误杀和漏杀怎么权衡？哪个更重要？为什么？
23. 你怎么做 A/B 测试？流量怎么切？怎么评估效果？
24. 你怎么评估 Agent 的业务价值？ROI 怎么算？
25. 如果让你从零搭建一个金融 Agent 平台，你会怎么做？分几步？
26. 团队怎么分工？你怎么推进？遇到阻力怎么办？
27. 你怎么保证上线质量？有没有灰度？怎么回滚？
28. 你销售多智能体项目里，多个 Agent 怎么协作的？怎么分钱？
29. 销售场景里，Agent 怎么处理客户异议？话术怎么设计？
30. 销售转化率怎么评估？Agent 贡献了多少？怎么归因？
31. 反问：团队现在做的是金融哪块业务？
32. 手撕：实现一个幂等状态机，支持支付请求的 INIT / REQUESTED / SUCCESS / FAILED / UNKNOWN 状态流转。

《参考解析》

传统后端与 LLM 应用的核心差异，以及该在哪一层要确定性。 传统后端的输出由代码路径决定，同样的输入必然得到同样的结果；LLM 应用的输出是采样结果，输入相同输出也可能不同，而且失败是「看起来像对的错」——格式对、语气对、事实错，这让传统的异常处理失效。工程上的应对不是追求「让模型确定」，而是把确定性推到系统边界：模型负责理解与生成候选，边界之外的判定、计算、写库、外发全部交给确定性代码。具体做法包括结构化输出约束（函数调用/JSON Schema）、让模型只填内容字段而由代码拼装最终产物、关键数值一律由代码或外部系统计算而非模型口算、以及在流程里设置校验节点，校验不过就重试或转人工。概率性则通过工程冗余来吸收：重试、多候选取一致（自一致性）、以及把不影响主流程的部分做成软失败。上下文丢失本质上是状态管理问题，靠外部持久化 + 每轮重建关键上下文解决，而不是指望模型记住。

幻觉、格式不稳、模型版本变化的兜底。 格式不稳用结构化输出 + 校验 + 有界重试解决，重试仍失败就走降级路径（退回模板或转人工），绝不能把解析失败的半截结果当成功往下传。幻觉在金融场景要按风险分级：低风险的知识性表述可以容忍，凡是进入金额、责任认定、承诺类的话术必须做到「无出处不说」。落地手段是强制引用与事实校验（结论必须能映射到保单条款、理赔单、政策库里的具体条目，校验不过即拦截）。模型版本变化是很容易被忽略的一类风险：上游模型小版本更新就可能让提示词效果漂移、工具调用率变化，所以要做模型版本固定 + 变更前跑回归集 + 保留一键切回的能力，同时把提示词与模型版本一起版本化，任何一次上线都能说明「这批结果是哪个组合跑出来的」。兜底方案要有明确的分级：模型不可用 → 切备用模型或渠道；备用也失败 → 走规则/模板的确定性流程；再不行才是排队与人工。每一级都要能在监控上看见切换次数，否则降级会长期静默存在。

保险理赔 Agent 的工具编排与多轮一致性。 理赔 Agent 的骨架建议是「材料解析 → 责任判定 → 金额计算 → 结论与告知」四段，每段有明确的输入输出契约。工具上至少需要保单查询、条款检索、理赔单读写、影像/OCR、身份与反欺诈校验、金额计算器、以及工单与转人工接口。编排要点是依赖关系显式化：用任务图或步骤机描述「哪些可以并行（如多项材料解析）、哪些必须串行（先定责才能算钱）」，不要靠模型自由决定顺序；每个工具声明前置条件与幂等键，失败时按依赖回溯重跑而不是整单重来。材料不全的处理原则是「一次问清、可续传、不猜」：解析后输出缺失项清单（区分必填与可选），生成结构化的补件请求，支持用户分次上传并保留已解析结果，绝不推测缺失字段的值。用户改口供要按「留痕 + 重算 + 作废旧结论」处理：每轮输入带版本号，条款适用的结论依赖的材料版本变化时，把受影响的中间结论标为失效并沿依赖链重算，同时保留历史版本用于审计与纠纷复盘——这比「覆盖」更符合金融场景的证据要求。

金额校验、二次确认与转人工的触发条件。 金额计算应该完全脱离模型：模型只负责把材料映射成计算所需的输入（赔付类型、比例、免赔额这些参数抽取），计算走确定性代码，再用规则做上下限校验（是否超过保额、是否与同类案件分布明显偏离、关键字段是否为空），偏离超阈值就拦截转人工。二次确认的设计要区分「谁确认」：影响用户权益的动作由用户确认（展示计算依据与结果，要求显式点击），超出权限的动作由有权限的角色确认（坐席/审核员），自动化只能做「准备动作」而不能做「终局动作」。转人工的触发条件建议写成可枚举的清单：置信度低于阈值、规则校验不通过、金额超过阈值、涉及拒赔或免责条款、用户明确要求人工、以及连续两轮无法推进。实践中还有一个反直觉的点：转人工不是失败，而是产品的一部分，因此要把「转人工率」「转人工时带过去的信息完整度」也当成指标来优化，让坐席接手时不需要用户再讲一遍。

权限、租户隔离、脱敏与审计日志。 权限模型按「用户—角色—动作—数据范围」四元组设计，数据范围落到具体维度（自己、团队、机构），并且所有查询在数据访问层强制注入范围条件，不做「先查全量再过滤」。多租户隔离要区分逻辑隔离与物理隔离：常规 SaaS 用逻辑隔离（每表带 tenant_id + 行级安全策略 + 每租户独立密钥做字段加密），涉及敏感或监管要求高的客户再上独立库/独立部署。脱敏与可排查性的平衡靠分层：展示层与常规日志脱敏，原始数据在受控的「证据库」里加密保存，排查时通过带审批的通道临时授权访问并全程留痕。审计日志的字段至少要有事件 id、时间、操作主体（人/Agent/系统）、租户、会话与 Trace id、动作类型、输入摘要、输出摘要、使用的模型与版本、命中的规则、以及结果状态；不可篡改的实现是追加写的日志存储 + 逐条哈希链（每条记录包含前一条的哈希），再定期把根哈希做外部锚定，任何删改都会破坏链式校验。这也顺带回答了「怎么追责」：追责的前提是能还原「谁在什么上下文里基于什么信息做了什么决策」，所以可回溯性比「让模型保证正确」更重要。

金融风控 Agent 与规则引擎的配合、误杀漏杀的权衡。 风控和理赔的差别在于目标函数：理赔追求「该赔的赔到、不该赔的不赔」，风控追求「在可接受的误杀率下把欺诈压到最低」，且负样本极少、分布随时间漂移。规则引擎和模型的正确配合是「模型提分、规则定策」：模型输出风险概率与理由特征，规则引擎根据分数区间、名单、场景与业务约束决定最终动作（通过、加验、人工、拒绝）。冲突时以规则为准，因为规则代表的是合规与业务底线，模型只在规则留出的空间里做区分度。误杀和漏杀哪个更重要取决于场景的损失结构：信贷欺诈通常漏杀更贵（一次欺诈可能吃掉几十笔正常收益），所以阈值偏低、宁可多转人工；而营销风控或额度调整往往误杀更贵（伤体验伤收入），阈值应偏保守。做这个权衡不能拍脑袋，要用成本矩阵算：把两类错误各自的钱数与发生率乘起来，选期望损失最低的阈值，并定期用回溯数据重估。评估上除了 AUC，更要看业务口径的指标（拦截率、误杀率、人工复核通过率、以及在固定人工产能下的净收益）。

A/B、ROI 与从零搭平台的推进节奏。 A/B 在 Agent 场景的难点是样本量、指标滞后与体验污染：建议先做单元级实验（提示词/模型/工具策略）在离线评测集上筛，再做线上小流量灰度看业务指标，流量切分按用户或会话维度保持一致性（同一个用户不要一半新一半旧），并提前固定主指标与护栏指标（投诉率、转人工率、平均处理时长、成本）。ROI 的口径要说清三件事：省下的人力成本（按处理量与单位工时折算）、带来的增量收益（转化提升、赔付准确率带来的损失下降）、以及新增的模型与基础设施成本，三者放同一时间窗口里算，并给出对照组。从零搭平台的路径建议分四步：先做单场景闭环（一个流程、少量工具、完整可观测），再把工具与权限体系沉淀成平台能力，然后补评测与灰度发布机制，最后扩展到多场景与多租户。团队分工上，平台侧负责编排、工具网关、状态与观测，业务侧负责场景提示词、判据与评测集，质量侧负责红线用例与人工复核校准；推进遇到阻力的破法通常是用一个可量化的闭环小胜仗换取信任，而不是先要大而全的平台预算。

销售多智能体协作、归因与手撕幂等状态机。 销售多智能体的切分一般是「线索评估、话术生成、客户答疑、跟进节奏」几个角色，协作的关键同样是接口而非智能：角色之间传结构化的客户画像与阶段状态，动作（发消息、改阶段）走统一网关并做频控与合规检查，避免多个 Agent 同时触达同一个客户。「怎么分钱」这类问题本质是归因，实践上很难做到精确归因，务实口径是按「接触序列 + 影响窗口」做多触点归因（首触、末触、时间衰减），并把 Agent 发起的动作与人工动作分开统计，先保证口径稳定可复现，再谈精确。销售转化评估要看漏斗每一段的转化率与响应质量，而不是只看最终成交，归因则用留出实验（对一部分线索完全不启用 Agent）作为基线，否则很难剥离自然成交。手撕幂等状态机这道题考的其实是分布式事务的常识：状态集合 INIT / REQUESTED / SUCCESS / FAILED / UNKNOWN，其中 UNKNOWN 是「发出去了但没拿到结果」，必须靠查询对账来收敛，不能当失败处理。设计要点：只允许合法迁移（如 INIT→REQUESTED、REQUESTED→SUCCESS/FAILED/UNKNOWN，终态不可再迁移），迁移用「带版本号或前置状态条件的 CAS」实现（比如数据库 UPDATE ... WHERE id=? AND status=? 影响行数为 1 才算成功），幂等靠业务幂等键（请求 id）加唯一索引，重复请求直接返回既有结果；UNKNOWN 状态要有对账任务按幂等键向对方查询并推进状态。写代码前先把状态图与非法迁移的返回约定讲清，比直接开始写更容易拿分。