高风险场景防护

Q：为什么在复杂的 Agent 闭环场景中，仅靠 RAG 无法彻底解决幻觉问题？

来源：淘天 AI Agent 一面 【腾讯金融科技一面追问：知识库无内容但模型输出正确时的信任边界】

新手答：“加了 RAG 就不会幻觉了。”

高手答：

RAG 解决的是幻觉的一个来源：知识空白——模型不知道答案，所以编造一个。有了 RAG，模型至少有参考材料可以依据。但 RAG 本身会引入新的幻觉类型，而且 Agent 场景下还有 RAG 根本覆盖不到的幻觉。

RAG 引入的新幻觉类型：

幻觉类型	表现	根因
检索失败幻觉	召回了错误文档，模型基于不相关内容生成答案	检索质量差，语义匹配不精准
忠实度失败幻觉	召回了正确文档，但模型忽略文档内容，用自己的“知识”回答	模型对训练数据的先验太强，覆盖了检索结果
合成幻觉	模型正确读取了多篇文档，但在文档之间建立了不存在的关联	多文档推理时，模型“脑补”了跨文档的因果关系
上下文溢出幻觉	检索了太多 chunk，模型从噪声片段中提取信息生成错误内容	上下文窗口中信噪比太低

Agent 特有的幻觉——RAG 完全无法解决：

1. 工具幻觉：模型“发明”不存在的工具名称来调用，或者在没有实际调用工具的情况下伪造工具返回结果。RAG 检索的是知识文档，管不了模型对工具的幻觉。
2. 规划幻觉：模型生成看似合理但实际不可执行的计划——步骤之间存在循环依赖、某个步骤依赖了不存在的前置条件、或者计划的步骤顺序违反了业务约束。
3. 状态幻觉：模型“记住”了当前对话中从未出现过的信息——来自训练数据的记忆和当前上下文混淆，产生虚假的“回忆”。

为什么 RAG 是必要但不充分的：

RAG 是防幻觉的一层防线，但只是一层。完整的防幻觉体系需要多层叠加：

第一层：RAG → 解决知识空白
第二层：输出校验 → 检查事实性和格式正确性
第三层：工具调用验证 → 模型请求的工具是否存在、参数是否合法
第四层：计划合理性检查 → 规划的步骤是否可执行、是否有循环依赖
第五层：高风险决策人工介入 → 关键节点不信任模型的任何输出

每层解决一类幻觉，单独任何一层都不够。

差距在哪：新手以为 RAG 是银弹——加了就不幻觉了。高手理解 RAG 只解决知识空白幻觉这一种，且 RAG 本身会引入检索失败、忠实度失败、合成幻觉、上下文溢出四种新问题。更关键的是，Agent 场景下的工具幻觉、规划幻觉和状态幻觉是 RAG 根本覆盖不到的。面试官考的是你对幻觉问题的全面认知——不是”知道 RAG 能防幻觉”，而是”知道 RAG 防不了什么”。

追问：从数据、检索、生成三个方面，系统性降低 Agent 幻觉的具体手段？

上面讲了 RAG 的局限，这道追问要求给出全链路的降幻觉方案：

阶段	手段	原理	实操要点
数据层	知识库去噪	源头数据有错，模型必然输出错误答案	定期校验文档时效性，设置过期标记，矛盾文档人工仲裁
数据层	元信息标注	让模型知道数据的来源和可信度	每条文档标注来源、更新时间、可信度等级
数据层	负样本构建	让模型学会说”我不知道”	在训练/评测数据中加入知识库无答案的 query，训练拒答能力
检索层	提升召回精度	减少”检索到了但不相关”的噪声	混合检索 + Rerank + 分数阈值过滤
检索层	置信度评分	给检索结果附带可信度信号	Rerank 分数低于阈值时标记”低置信度”，提示模型谨慎使用
检索层	冲突检测	召回矛盾文档时主动标记	对 Top-K 结果做两两一致性检查，发现矛盾时提示模型
生成层	引用约束	强制模型标注信息来源	Prompt 中要求”每句话必须标注来源文档编号，无来源则不说”
生成层	输出校验	生成后做事实性检查	提取输出中的事实性声明，逐条与检索文档比对
生成层	受限解码	限制模型的输出空间	结构化输出（JSON schema）、枚举约束、正则过滤

三层协同的关键认知：

数据层 → 治本（源头质量决定上限）
检索层 → 减噪（信噪比决定模型能不能用对信息）
生成层 → 兜底（即使前两层有遗漏，最后一层仍能拦截）

三层缺一不可：
- 只做数据层 → 检索不准照样幻觉
- 只做检索层 → 数据本身有错没用
- 只做生成层 → 输入全是噪声，校验也救不回来

---

Q：支付等高敏感操作场景下，Human-in-the-Loop 流程怎么设计？

来源：蚂蚁 AI应用开发 二面 【淘宝闪购一面同题：人工强制中断 Agent 执行与 HiL 处理】

新手答：”敏感操作前弹个确认框让用户点确认。”

高手答：

高敏感操作的 Human-in-the-Loop 不是简单的”确认框”，而是一套分层的审批和风控体系：

1. 操作分级

风险等级	示例	审批策略
低风险	查询余额、查看订单	无需确认，自动执行
中风险	修改收货地址、取消订单	Agent 复述操作内容 + 用户确认
高风险	支付、转账、删除账户	完整参数展示 + 显式确认 + 二次验证

2. 信息展示原则

确认环节必须展示完整的操作参数和不可逆后果，而非模糊描述。对比：

• 差：“确认支付吗？” → 用户不知道付多少、付给谁
• 好：“确认向 XX 店铺支付 299.00 元购买 YY 商品？此操作不可撤销。” → 所有关键参数透明

3. 超时与兜底

用户不响应时，Agent 不能无限等待，也不能自动执行。设计超时机制：超过 N 分钟未确认 → 取消操作 + 通知用户。默认行为永远是“不执行”而非“自动执行”。

4. 审计日志

每次高风险操作记录完整的审计链：谁触发的、Agent 的推理过程、展示了什么信息、用户是否确认、最终执行结果。这既是合规要求，也是出问题时的回溯依据。

差距在哪：新手把 HITL 简化为“弹确认框”。高手设计了操作分级、信息展示规范、超时兜底、审计日志四层机制——这不是 UX 问题，是安全工程问题。面试官考的是你对 Agent 安全性的理解深度——高敏感场景下，默认行为必须是“不执行”。

---

Q：Agent 的 Self-Reflection 机制怎么识别输出中的逻辑错误？

来源：蚂蚁 AI应用开发 二面

新手答：“让模型自己重新检查一遍输出。”

高手答：

Self-Reflection 识别逻辑错误的核心是把开放的生成任务转化为约束更强的判断任务。

为什么评估比生成更准？

生成一个正确答案需要模型在巨大的输出空间中找到唯一正确路径。而判断一个答案是否正确，只需要检查它是否满足一组已知约束——这是一个小得多的搜索空间。类比：写出一篇好文章很难，但挑出一篇文章里的逻辑错误相对容易。

识别逻辑错误的三种策略：

1. 对比验证：让模型用不同的推理路径重新解决同一个问题，对比两次结果。如果结论一致，可信度高；如果矛盾，说明至少有一个推理链存在逻辑错误，需要人工或进一步分析定位

2. 分步回溯：在 ReAct 模式下，逐步检查 Thought-Action-Observation 链：

   • 每个 Thought 的推理前提是否成立
   • 每个 Action 是否是当前 Thought 的合理推论
   • Observation 是否被正确解读（模型可能误解工具返回值）

3. 规则约束检查：用硬编码规则检查输出的形式化属性——数值范围、格式合规、必要字段是否齐全。这不需要模型能力，但能捕获大量低级逻辑错误

差距在哪：新手的”自检”没有方法论。高手解释了 Self-Reflection 有效的底层原理（评估空间 < 生成空间），并给出了三种具体的逻辑错误识别策略。面试官考的是你对这个机制的理解是”知道名字”还是”理解原理”。

追问：Reflection 连续失败 3 次后，系统怎么降级？

来源：字节 AI 一面

Reflection 不是万能的——如果模型的推理链本身就有系统性偏差，再怎么 reflect 也修不回来。连续失败后的处理必须是阶梯式降级，而不是无限重试：

三次重试的策略必须不同——用同样的方式重试 3 次毫无意义：

次数	策略	原理
第 1 次	原路 reflect，检查推理链	可能只是偶发错误
第 2 次	换推理路径（不同 Prompt 或不同工具）	排除路径依赖导致的系统性偏差
第 3 次	降级任务（拆分子问题或放宽约束）	确认是否超出模型当前能力边界

熔断后的关键动作：不是简单报错，而是保存完整的失败上下文（三次尝试的推理链、工具调用记录、中间结果），让人工介入时不需要从零开始排查。

---

Q：高风险在线环境中，Agent 的异常管控方案怎么设计？

来源：淘宝闪购 Agent 一面

新手答：“加个 try-catch 兜底，出错就重试。”

高手答：

高风险环境下的异常管控不是单点防护，是四层纵深防御体系：

第一层：操作分级与审批链路

操作类型	示例	管控策略
只读	查询、检索、读文件	自动执行，无需审批
可逆写入	创建草稿、修改配置	执行后可回滚，异步审计
不可逆操作	删除数据、发起支付、发布上线	必须人工确认，双人复核

不同级别走不同审批链路——Agent 在 plan 阶段就判断操作级别，不是等到执行时才检查。

第二层：熔断与降级机制

• 连续失败熔断：同一工具连续 N 次（通常 3 次）调用失败，自动终止该工具的调用权限，转人工处理
• 异常率降级：监控窗口内（如 5 分钟）错误率超阈值，整个 Agent 自动降级为“只读模式”
• token 预算熔断：单次任务 token 消耗超过预算上限，强制终止并汇报

第三层：沙箱隔离

• 开发、预发布、生产环境严格隔离，Agent 在生产环境仅可调用白名单内的工具
• 文件系统操作限制在指定目录，禁止跨目录访问
• 网络请求限制在白名单域名，防止数据外泄

第四层：结构化审计日志

每步操作记录完整上下文——时间戳、操作类型、输入参数、输出结果、决策依据。不只是“出了问题能查”，更重要的是支持事后回滚：可逆操作的回滚路径在执行前就规划好。

差距在哪：新手只想到异常捕获和重试。高手展示了操作分级、熔断降级、沙箱隔离、审计日志四层纵深防御，且是在 plan 阶段就做分级判断而非执行时才检查。面试官考的是你对”高风险”场景的工程化管控能力——不是出了问题怎么救，而是怎么设计系统让问题不会扩散。

---

Q：金融系统不能让 Agent 真实操作（钱放出去就是大问题），怎么设计？

来源：京东后端 Agent 开发一面

新手答：「加个审批流程，操作前让人确认。」

高手答：

金融场景的核心约束是操作不可逆且代价极高——一笔转账出去就收不回来。这不是加个确认按钮能解决的，需要从架构层面把 Agent 的「决策权」和「执行权」彻底分离。

三层架构：Agent 只建议，不操作：

关键设计原则：

原则	实现方式	目的
决策与执行分离	Agent 只输出结构化的「操作建议」（JSON），不持有任何写权限的 API key	Agent 永远无法直接操作资金
影子模式（Shadow Mode）	Agent 的建议和人工操作员的决策并行运行，只记录不执行，统计 Agent 建议的准确率	上线前验证 Agent 决策质量
模拟环境	提供一套和生产完全隔离的沙箱环境，Agent 可以在里面自由操作（假数据、假账户）	开发和测试阶段不碰真钱
渐进式放权	影子模式准确率达标 → 小额自动执行（如 <100 元）→ 大额仍需人工	风险可控地逐步信任 Agent

影子模式的工作方式：

阶段 1（纯影子）：Agent 给建议 → 人工做决策 → 事后比对 Agent 建议和人工决策是否一致
阶段 2（辅助决策）：Agent 给建议 → 人工参考 Agent 建议做决策 → 记录采纳率
阶段 3（有限自主）：低风险操作 Agent 自动执行 → 高风险操作仍走人工
阶段 4（全面自主）：大部分操作 Agent 自动执行 → 异常触发人工介入

每个阶段都需要达到量化指标（准确率 > 99.9%、误操作率 < 0.01%）才能进入下一阶段。

差距在哪：新手只想到审批流程——这只是防线之一。高手从架构层面把 Agent 的决策权和执行权分离，且给出了影子模式 → 渐进放权的完整上线路径。面试官考的是你对金融级安全要求的理解——不是「加个确认」就够的，而是 Agent 从设计上就不应该有操作资金的能力。

---

Q：Agent 系统的安全护栏怎么设计？敏感词拦截的工程方案有哪些？

来源：小红书AI应用开发一面

新手答：“用正则表达式匹配敏感词，匹配到就拒绝回答。”

高手答：

Agent 安全护栏不是一道过滤器，是一个三层纵深防御体系——输入侧拦截、推理侧约束、输出侧审计：

第一层：输入侧拦截

方案	原理	优劣
Aho-Corasick 多模匹配	将敏感词表构建有限自动机，O(n) 一次扫描匹配所有词	速度极快（微秒级）、无误判，但无法处理变体（谐音、拆字）
正则 + 变体展开	对每个敏感词生成变体规则（空格插入、同音字替换）	覆盖常见绕过手段，但维护成本高
语义分类器	用 BERT/小模型对输入做意图分类（正常/攻击/敏感）	能识别隐晦表达，但有延迟（10-50ms）且需要训练数据

生产环境组合方案：Aho-Corasick 做第一道快筛（拦截明确敏感词）→ 语义分类器做第二道深筛（识别绕过和隐晦攻击）。两层串行，第一层通过才进第二层。

第二层：推理侧约束

在 System Prompt 中注入硬性规则（“绝不输出暴力、色情、政治内容”），配合模型自身的 RLHF 安全训练。但不能完全依赖——模型约束可以被 jailbreak 绕过，所以必须有第三层。

第三层：输出侧审计

模型生成完毕后，对输出再跑一次敏感检测。这层是最后防线——即使输入侧漏了、模型被绕过了，输出侧也能兜住。

工程细节：

• 敏感词表需要分级（禁止词 vs 警告词），不同级别不同处理策略
• 拦截后的用户体验要考虑——不是简单返回“违规”，而是给出合理的引导回复
• 所有拦截事件必须记日志，用于后续分析绕过模式和更新词表

差距在哪：新手只想到正则匹配——这是最弱的方案，绕过成本极低。高手展示了三层纵深防御（输入/推理/输出）+ 两种互补的检测技术（规则快筛 + 语义深筛）。面试官考的是你对安全系统”纵深防御”理念的理解——单点防线一定会被突破，只有多层才能可靠。