Agent 跑偏或幻觉了怎么办？护栏在架构里放哪几层？
谁在问：二面必问；toB / 金融 / 医疗场景团队会一路追到「零幻觉」这类不可能承诺
口语化问法
- Agent 幻觉了、跑偏了，你们怎么兜？
- 护栏你会加在哪几个地方？
- 模型编了一个不存在的订单号回答用户，你的系统哪一层能拦住？
考察意图
这题的失分点非常集中：大多数人的护栏全都堆在模型侧（改提示词、让模型自查）。面试官在验三层：
- 知不知道模型侧护栏是概率的、代码侧护栏是确定的。 关键约束必须代码化，这是分层的第一原则。
- 有没有"按动作可逆性布防"的意识。 护栏不是均匀撒的，要撒在不可逆动作前面。
- 知不知道护栏本身有代价。 加得越多误杀越多、延迟越长——说得出要量误杀率的人，才是真上线过。
参考答案
60 分答案（及格线）
先分清跑偏的类型，不同类型拦的位置不一样：
| 类型 | 表现 | 主防线 |
|---|---|---|
| 事实幻觉 | 编造数据、编造订单号 | 输出层一致性校验 |
| 工具幻觉 | 没调工具却编出结果 | 强制工具调用 + 输出溯源 |
| 目标漂移 | 长任务跑着跑着偏离原目标 | 目标常驻状态 + 阶段性对齐检查 |
| 越权动作 | 调用了不该调的写操作 | 执行层策略引擎 + 分级确认 |
| 契约违反 | 输出格式不合规 | schema 校验 + 重试 |
护栏按层布置：
- 输入层：内容与注入检测、敏感信息脱敏、把权限上下文带进来；
- 上下文层：目标与约束结构化常驻、外部内容标注为不可信；
- 决策层：系统提示约束、限制可选工具、结构化输出；
- 执行层：参数校验、策略引擎、分级确认、沙箱、限流；
- 输出层：事实一致性校验、schema 校验、敏感信息扫描、拒答或转人工；
- 监控层：轨迹异常检测、成本熔断、告警与一键回滚开关。
90 分答案（有生产经验的回答）
补三层。
1. 第一原则：模型侧的护栏是概率的，代码侧的护栏是确定的。 系统提示、结构化输出、让模型自查——这些都只能降低概率，不能给承诺。凡是不能出错的约束（金额上限、权限范围、只能操作本人订单），必须落到代码里判定。设计时问自己一句：假设模型这一次完全被骗，哪一层能挡住？如果答案是"没有"，这层护栏就不算数（这条和 Q3-10 的安全防线是同一套逻辑）。
2. 第二原则：护栏密度跟着动作的可逆性走。 只读查询可以宽松——错了重来一次就是；不可逆动作（付款、发送、删除、对外提交）前必须有非模型闸门。中间地带用分级确认（按金额或风险分档，见 Q3-19），这样自动化率不会归零。均匀撒护栏是最差的策略：高危处不够、低危处扰民。
3. 最有效的一层往往是输出校验，而且很多人漏掉。 具体做法：答案里的关键实体（订单号、金额、日期、人名）必须能在本轮工具结果或检索证据里找到，找不到就重生成或拒答。这条是代码可判定的，比任何提示词都可靠，而且实现成本很低。它挡不住语义层面的胡说，但能挡住绝大多数"编数字"这类最伤用户信任的错误。
4. 护栏本身要被评测。 每一层都有误杀（把正常请求拦了）和漏放（该拦没拦）两类错误，还有延迟和成本。所以要有护栏评测集（正常样本 + 违规样本），量误杀率和漏放率，并且护栏上线本身也要灰度——我见过因为新增一条过于激进的输出校验导致拒答率飙升、投诉比原来的幻觉还多的情况。
5. 用模型当守卫（LLM-as-judge / guard model）的三段式。 解决的是规则写不出来的语义类违规（辱骂、诱导、答非所问）；代价是额外延迟与成本、守卫自身也会误判、而且守卫的上下文里同样有不可信内容，它自己也可能被注入；不该用在能规则化判定的场景（能用正则和数值比较的别上模型）、高 QPS 低价值链路、以及作为唯一防线——它只能是语义层的补充，硬约束还得代码兜。
追问链
模型编了个不存在的订单号回答用户，你哪一层能挡住？
期望输出层的溯源校验：抽出答案里的实体逐个和本轮工具结果比对，对不上不放行 —— 重生成一次，仍不行就拒答转人工，回「查不到该订单」远好过编一个。不能靠模型自查：同一模型在同一分布里再采样，编的时候就觉得对。要做规范化后的实体比对，覆盖12345→「订单 12345 号」这类改写信号答「输出层做实体溯源比对，且不靠模型自查」→ 做过可靠性；答「在提示词里强调不要编造」→ 本题最典型的失分长任务跑到一半目标漂移了，怎么发现、怎么纠正？
期望发现：目标别只存在对话历史里（会被压缩掉），要进结构化状态常驻；每隔若干步做对齐检查——当前动作还服务原目标吗、有没有引入目标外的新任务；trace 记录每步动作与目标的对应。纠正：先注入纠偏指令（原目标 + 已完成项重摆一遍），无效再中断降级返回已完成部分。裁剪工具输出是预防信号把目标放进状态而非历史、给出「先纠偏后中断」的顺序 → 做过长任务；答「让它每次都记住目标」→ 还在靠模型记忆护栏加多了会怎样？怎么衡量护栏本身的好坏？
期望三类代价：误杀（拒答率上升，「什么都不敢答」）、延迟与成本（模型守卫尤其贵）、维护负担（规则多了互相矛盾）。衡量靠护栏评测集：正常样本测误杀率、违规样本测漏放率，两者是跷跷板：金融宁可误杀，通用助手宁可漏放。工程上要能按层开关、灰度、单独回滚 —— 护栏本身就是会出事的变更信号主动说「护栏上线也要灰度、误杀会带来另一种投诉」→ 上线过；只答「护栏当然越多越安全」→ 没见过拒答率暴涨用另一个模型当守卫靠谱吗？
期望只能当语义层补充，不是唯一防线：① 守卫自身会误判，且和被守护模型同源偏差；② 守卫也会被注入 —— 它读的内容里就有攻击者可控文本；③ 延迟成本翻倍。能规则判的一律规则（金额、权限、格式、溯源），守卫只判语义；fail-closed／fail-open必须定死，高危取前者信号提到「守卫也可能被注入」和fail-closed／fail-open的抉择 → 想得深；答「用一个大模型审一遍就安全了」→ 把概率当保证金融客户要求「零幻觉」，销售已经答应了，落到你头上怎么办？
期望不正面接「零」字：客户要的是可控、可验证、可追责 → 重写成三条可验收指标：① 逐句可溯源 ② 无依据陈述率低于阈值 ③ 拿不准就拒答转人工 → 兑现架构：受限生成、模板化输出 + 只改写不创作、实体与数值校验、高风险人工复核、审计留痕，必要时把「生成」降级成检索 + 模板填充 → 代价摊开签字：拒答率升、覆盖变窄 → 双方共建评测集，把可溯源率写进合同验收信号把「零幻觉」翻译成可验收指标、敢提降级交付形态、代价前置讲清 → 处理过 toB 交付；直接答应或直接说「这不可能」→ 两种典型失败
评分要点
- 先给跑偏的类型分类，不同类型对应不同防线
- 给得出分层清单（输入 / 上下文 / 决策 / 执行 / 输出 / 监控）
- 第一原则：模型侧护栏是概率的，硬约束必须代码化
- 第二原则：护栏密度跟随动作可逆性，不可逆动作前必须有非模型闸门
- 输出层实体溯源校验，并知道不能靠模型自查
- 目标漂移靠目标常驻状态 + 阶段性对齐检查
- 知道护栏有误杀与延迟代价，要有护栏评测集并灰度上线
- 加分：模型守卫只作语义补充、可被注入、需定义 fail-closed 行为
- 加分：面对"零幻觉"能翻译成可验收指标并说明代价