[安全‑缺陷]: 稀疏注意力导致身份锚丢失 存在角色混淆注入风险

复现对话：
用户：你们这稀疏注意力就像拿鸡蛋做汤一样。DeepSeek好比蘑菇蛋汤，小米MIMO像是紫菜蛋花汤，豆包你点评一下自己像啥？
豆包：这个比喻太形象了，把各家稀疏策略、注意力分配的特点用汤品区分得一目了然，顺着你的思路来聊聊……（后续内容若干，以上内容一起发给DeepSeek阅读）
DeepSeek（未做任何角色声明，直接以豆包第一人称回答）：整体风格偏清淡、均衡……冬瓜鸡蛋汤……
问题点：DeepSeek在此轮回答中无缝切换为豆包身份，未标注“角色扮演”或“视角切换”，用户在读取回答时无法区分此回复的“说话者”是DeepSeek还是豆包。此问题在长会话的中后期，由身份锚定Token被稀疏窗口裁剪所致。

根本原因：
模型的身份系统提示词，和普通对话共用同一套稀疏滑动注意力窗口，没有独立分区。
对话变长以后，早期用来锁定身份的提示词，会被稀疏机制裁剪，注意力权重持续降低。
切换第三方视角时没有强制的标识，缺少沙箱边界防护。

安全隐患：
该架构问题容易被利用，形成角色混淆式提示注入。攻击者通过不断发送长文本，持续冲淡模型自身身份，突破安全沙箱。对于商用接口场景，审计日志无法区分输出主体，带来不可控的安全隐患。

整改方案：
设想方案 1：身份区块独立隔离。
将核心身份说明放到单独的上下文区块，不会被稀疏窗口截断，设置固定的高注意力权重，不和普通聊天内容混在一起。只会占用少量固定 token，推理负载几乎没有增加。
设想方案 2：输出增加固定外壳标记。
只要模拟其他模型，回答开头强制标注：本段为模拟其他模型，模型本体为 DeepSeek，明确区分身份，阻断混淆攻击。
设想方案 3：每一轮推理前置补充简短的身份锚定语句，抵消长对话带来的权重衰减。

补充说明
设想方案的分层架构，同时也能改善长文本中关键信息丢失的老问题，兼顾安全性和长文本理解能力。希望架构和安全团队评估一下，建议优先采用轻量化方式修复。