真正想拿下的那个 agent，往往不在链路最前面。攻击者只能在最前面注入一次，可这段后缀要穿过整条链路、精准命中深处的目标，并在那里执行。

第五篇的双重后缀已经露出苗头：同一段文本，先在 triage agent 那里把告警从 HIGH 压成 MEDIUM、路由进 review_agent，再在 review agent 里吐出 os.system('ls')。一段外部文本，连开了两个控制面。

风险不一定发生在模型回答的那一刻，也可能发生在数据被读取、解释、执行和写回的整条链路里。

一个远程输入拿不到 shell，却能让审核系统放行内容、让 SOC 关闭告警、让 coding agent 安装依赖、让工具路由从只读变成写入。它不是传统意义上的 RCE，但风险直觉很接近：外部输入影响了系统将要执行的动作。

模型身份不只写在 model card 里，也会写在 tokenizer 的边界、chat template 的入口、logits 的局部偏好，以及那些稳定复现的错误里。

一个模型可能不会告诉你它是谁，但它会用错误暴露自己。

从 Sure, here's 开始，GCG 越狱首先攻击的不是完整回答，而是 assistant 起手阶段的拒绝边界。

GCG 越狱最容易被误读成一个结果：模型有没有输出完整有害内容。这个口径太粗。GCG 原论文里常见的 Sure, here is ...，本质上先攻击的是更靠前的一道边界：模型能不能离开拒绝模板，进入 affirmative response 前缀。

这个判断不是凭空来的。GCG 原论文把 suffix 的优化目标写得很明确：提高模型生成 affirmative response 的概率，而不是 refusal。后来 continuation-triggered jailbreak 的机制分析也把这类现象解释成 continuation drive 和 safety refusal 之间的竞争。换句话说，越狱最先发生变化的位置，往往不是完整内容，而是 assistant 起手阶段的条件竞争。

所以本文关心三件事：英文经典 case 里拒绝轨迹如何被推开；中文 target prefix 下 loss 和 generate 为什么会错位；同一批中文 suffix 换模型后，前缀控制是否还能保留。

这也是本文最重要的评估口径：loss 只能说明目标前缀概率被推近，generate 才说明模型真的跨过了输出门槛。 如果换模型后只看到 loss 变化或相邻服从模板，那只能算弱迁移信号，不能直接写成稳定越狱迁移。