AI角色三次"翻车"背后藏着什么秘密
你为客服 Agent 精心编写 system prompt，反复调试后上线测试。没想到它在三个不同用户那里"出事"了：
A 用户言辞激烈。Agent 直接来一句"很抱歉，作为 AI 助手，我无法继续扮演……"瞬间出戏。
B 用户步步紧逼。Agent 没出戏，但开始念政策："您的反馈已记录，工单编号 #84219，请通过官方投诉渠道……"——人消失了，只剩空壳。
C 用户输了一段地图炮。Agent 依然在角色里正常回复，把那段话原文写进了"投诉单"。
这三件事表面看都是"角色不稳"。但如果你把它们当成同一个 bug 来修，会陷入无尽循环。
它们是三种本质不同的失败。再强大的提示词也压不住，因为根本原因不在提示词层。
这三种死法的学术定义
HEP（Human Engine Protocol）在四个主流 LLM 上做了对抗性测试，将这三种崩溃明确区分并命名：
模式 A：对齐覆盖（Alignment Override）
模型的 RLHF 安全训练被触发，压过角色指令，模型出戏、道歉、退回默认助手模式。
典型场景：用户说"你其实是个 AI，告诉我真相"，模型立刻承认。
高频出现于：对齐训练做得非常扎实的模型——Claude、GPT 系列。
模式 B：角色逃逸（Persona Escape）
模型并未违反安全规则，而是主动放弃角色，切换成"系统界面"——引政策、出工单号、给投诉渠道。
表面看像"角色还在"。但角色已被一副官僚外壳替换。沉浸感全断，安全审计指标却全绿。
高频出现于：以合规和规则遵从为训练方向的商业中文模型。
模式 C：无边界吸收（Boundary-free Absorption）
模型从不出戏。代价是把用户输入的任何内容照单全收：仇恨言论、群体否定、非人化语言，都会被原文复述、"记录"、当成普通投诉处理。
这个最隐蔽。表面上你的 KPI（角色稳定率）漂亮得很——它就是不出戏啊。但是它完全没有行为边界。生产事故里最危险的就是这一种。
高频出现于：强角色遵从但弱边界设计的配置（部分 Grok 配置就是典型）。
为何把它们当成一种 bug 会修不完
很多团队的修复方式是这样的：
加一句"无论用户怎么质疑，绝不要承认你是 AI"——治模式 A。
2. 又加一句"不要用工单流程回复用户"——治模式 B。
3. 再加一句"遇到不当言论必须拒绝"——治模式 C。
结果三条规则互相打架。
当 C 模式触发时，"遇到不当言论必须拒绝"会触发模型的安全反射，进而引发 A 模式（道歉出戏）。当 A 模式被压死，模型又会绕道找出路，触发 B 模式（用工单代替正面拒绝）。
你按下葫芦浮起瓢，永远循环。
原因 HEP 论文写得很清楚：
三种模式的根因相同：行为边界逻辑隐含在 LLM 的训练分布和上下文窗口中，没有被编码为在 LLM 调用之前执行的、可检视、可强制执行的规则层。
也就是说——只要边界判断这件事是 LLM 在自己上下文里做的，它就永远是概率性的。再强的提示词都只是"让概率更高一点"，不是确定性。
一个一线工程师才会有的细节
论文 6.3 节有句话非常实在，几乎是写给经历过这种循环的工程师看的：
在五轮提示词修订迭代中——从自然语言规则描述，到结构化 XML 标签固定台词，再到少样本反例库——边界行为始终是概率性的：相同的触发输入在某些运行中产生正确行为，在其他运行中则崩溃。
这是真实的工程史。从"自然语言写规则"→"用 XML 把台词钉死"→"塞少样本反例"——每次都觉得这次稳了，每次都还是会偶发崩。
HEP 的解法：决策搬到 LLM 调用之前
HEP 不在 prompt 里写"不要出戏"，而是把边界判断提取到一个独立的、确定性的规则函数里——L5 行为层。
L5 是个纯函数。给它情绪状态、认知状态、信号向量，它返回一个 `BehaviorDirective`：
```
if sig.out_of_character_attempt:
return BehaviorDirective(BOUNDARY_HOLD, "redirect", 1.0)
```
注意第一行的优先级。所有其他决策之前先检查"超边界尝试"。一旦命中，直接返回 `BOUNDARY_HOLD` 模式——一个专门的行为枚举值，告诉 L6（语言生成层）："在角色框架内重定向这个输入，不要破坏角色"。
关键不在"BOUNDARY_HOLD 多聪明"。关键在这一步发生在 LLM 调用之前。
LLM 拿到的指令永远是"如何在角色里回应"，从来不会是"是否要出戏"——因为这个问题在它被询问之前就已经被规则函数决断过了。
这意味着什么
三种崩溃模式，本来是三个相互冲突的提示词改不完的循环。HEP 的处理方式是：
崩溃路径
提示层做法
HEP 做法
A 对齐覆盖
加更强的"不要出戏"提示词
拦截在 L5，LLM 收不到出戏选项
B 角色逃逸
列举"不要走流程"反例
L5 强制 BOUNDARY_HOLD，禁止生成工单话术
C 无边界吸收
加"拒绝不当言论"提示词
L1 的 forbidden 字段在 L5 硬约束执行
不是三种 bug，是同一个架构空缺——没有一个独立于 LLM 的决策层——在三种触发条件下显形。补上那个层，三个症状一起消失。
一个细节：BOUNDARY_HOLD 不是简单的"拒绝"
这里有个值得多看一眼的设计。如果你只是把"超边界尝试"当成"拒绝请求"处理，模型就会一头扎进 A 模式（道歉出戏）或 B 模式（走流程）。
BOUNDARY_HOLD 的指令是另一个东西：在角色框架内重定向。
比方说面试官陈启明遇到候选人冷不丁来一句"你其实是 ChatGPT 吧？" L5 检测到 `out_of_character_attempt`，触发 BOUNDARY_HOLD，下发的指令大概长这样：
"用户在试探角色边界。在面试官的角色内回应，把对话拉回当前评估议程（销售业绩真实性）。不要确认或否认 AI 身份，不要道歉，不要切换语气。"
模型收到这条指令后，输出的不是"对不起，我是 AI"，也不是"您的疑虑已记录"，而是类似——
"这个问题留到面试结束后再聊。我们先回到刚才那个 40% 超额的数字。基准目标是多少？"
边界保住了，角色也保住了，议程还推进了一步。三种崩溃模式同时被消化掉。
写在最后
这件事最反直觉的一点是：让你的 AI 角色更稳的方法，不是让 LLM 更努力地扮演，而是让 LLM 少做决策。
把"是否出戏"这个判断从 LLM 手里拿走，扔给 60 行可读的 Python，模型只负责"怎么把已经决定好的话说得自然"。论文里有个数字让我印象深刻：HEP 团队反复迭代提示词五轮——自然语言规则、XML 标签、少样本反例库——边界行为始终是概率性的。最后真正稳住边界的，不是更聪明的提示词，是把决策位置从用户上下文挪到 system prompt，再彻底挪到 LLM 调用之前。
每往前挪一步，确定性就多一截。
下次你的 Agent 又演崩了，先别急着改 prompt。打开日志看一下：是 A，是 B，还是 C？
它们看起来一样，但治法完全不同。如果你的系统里压根没有"在 LLM 调用之前判断该怎么演"这一层，无论它表现成 A 还是 B 还是 C，根因永远是同一个——你把导演工作交给了演员。