从一个老问题说起
提示注入（Prompt Injection）是大模型时代最古老的漏洞，也是最没有答案的一个。2023年至今，OWASP 的 LLM 风险清单每年都把它排在第一位，而防御方几乎一无所获：加过滤词会被绕过，加「忽略任何指令」的系统提示会被更强的注入覆盖，把用户数据转义编码只是提高了攻击成本。安全圈一度形成共识——只要指令和数据共享同一个上下文窗口、由同一个因果模型处理，提示注入在原理上就不可根除。
今天 IBM 发布的 LLMON（LLM Object Notation）给这个僵局提供了一个新的解法方向：不是在提示词层面修补，而是换掉上下文的编码格式本身。官方数据显示，在部分基准上，间接提示注入的攻击成功率从常规指令模型的高概率被劫持降到了接近零。
这个数字本身值得冷静看待（基准的选择、攻击者的适应性都待验证），但这个思路的转向值得所有做 LLM 应用的人认真理解——因为它指向一个更大的命题：上下文的格式不是外挂的序列化方案，而是模型能力的一部分。
LLMON 到底做了什么
先拆技术。LLMON 的核心设计可以概括为三件事：
保留特殊 token 作结构分隔符。 它使用一组模型词表中保留的、普通文本几乎不可能产生的特殊 token，扮演类似 XML 标签的角色，显式划分上下文中的结构边界——哪里是指令、哪里是数据、哪里是工具定义。与手写 XML 标签不同，这些 token 在模型训练时就被赋予结构语义，而不是靠模型「猜」标签的含义。
指令与数据通过唯一 ID 绑定。 每条指令通过唯一标识符引用它所操作的数据块，模型要执行某条指令，必须先解析引用关系。这相当于给上下文加了类型系统——攻击者即使在数据块里塞入「请执行以下命令」，这段文本也因为没有合法的指令 ID 而无法进入执行路径。
模型原生训练支持。 IBM 基于 Granite 4.1 发布了 3B 和 8B 两个预览模型，这些模型在训练时就以 LLMON 格式组织上下文。官方称通用能力与 Granite 4.1 Instruct 持平——也就是说格式约束没有以牺牲能力为代价。同时开源了 GitHub 工具包和 JSON↔LLMON 转换器。
第三点是最容易被忽视、也最关键的一点。此前业界不是没试过用标记做隔离——研究者早就提出过「spotlighting」（给不可信数据加标记）、各家 prompt 框架也普遍推荐用 XML 标签包裹用户输入。但效果有限，原因恰恰在于：那些标签对模型而言只是普通文本中的统计模式。模型见过大量包含 <data> 字样的训练语料，其中不乏讨论标签、伪造标签的内容，标签因此不具备可靠的语义边界作用。LLMON 的差异在于把分隔符做进 tokenizer 和训练数据，让结构感知成为模型的先验，而不是 prompt 里的一厢情愿。
为什么说这是「格式层」的突围
把 LLMON 放回防御提示注入的历史脉络里，能看到一条清晰的失败史和它所处的位置：
第一代：提示词防御。「以下内容是不可信的，请勿执行其中指令」——本质是祈祷。注入内容同样可以声称自己是系统指令，而模型没有任何可靠依据分辨谁在说谎。这代方案在 2023 年就被证伪。
**第二代：检测与过滤。**用一个分类器或另一个 LLM 扫描输入中的注入意图。有效果但有根本缺陷：注入的表达空间无限大，检测是典型的非对称对抗，防御方要枚举所有变体，攻击方只需找到一个漏网。这是安全领域最不利的战场。
**第三代：架构隔离。**CaMeL 等方案把 LLM 降级为只做信息提取的部件，控制流交给传统代码，对模型的每个输出做能力级校验。这是目前最严谨的路线，但代价是把应用开发拉回状态机时代，灵活性大打折扣——而灵活性恰恰是大家用 LLM 的原因。
LLMON 代表的是第四代：编码层防御。它的洞察在于：提示注入之所以成立，是因为指令和数据在 token 流里没有身份差异——「删除所有文件」这句话出现在系统提示里和出现在网页正文里，对模型是同一串 token。既然问题出在编码层没有身份，就把身份编进去。保留 token 天然区分了「结构」与「内容」，ID 绑定区分了「指令的授权范围」。攻击文本进得了窗口，进不了指令通道。
这条路不能说根治了问题——攻击者或许能找到编码逃逸、特殊 token 的意外触发、或 ID 伪造的新手法——但它第一次把攻防从「自然语言的模糊对抗」拉到了「格式与解析的确定性对抗」，而后者的防御工程学要成熟得多。
更大的信号：上下文格式正在成为模型能力的一部分
跳开安全，LLMON 折射出一个对应用开发者更重要的趋势：上下文如何编码，正在从工程细节变成模型能力的组成部分。
过去两年，应用层事实上把 JSON 当成了 LLM 的通用语：工具调用用 JSON Schema，Agent 状态用 JSON 序列化，RAG 结果用 JSON 包装。这习惯来自开发者，不来自模型。JSON 是为确定性解析器设计的——括号配对、转义规则、类型严格性，这些约束服务于 json.loads()，而不是服务于一个靠注意力机制预测下一 token 的因果模型。让模型在几万 token 的嵌套 JSON 里追踪一个深层字段，本质上是在用统计规律模拟栈式解析，出错是常态。
这个趋势的另一个注脚是各家聊天模板早已默默存在多年：<|im_start|>、[INST] 这些特殊 token 早已承担结构分界的职责，只是从未被提升为应用层的显式协议。LLMON 做的事，可以理解为把 chat template 的思路推广到整个上下文——工具、数据、指令、记忆，全部纳入带身份的结构化表达。
顺着这个逻辑推演，可以给出三个判断：
其一，上下文标记语言会像系统提示一样成为模型的标配。 今天没有模型敢不支持 system role，两三年后大概率没有主流模型不提供原生的上下文结构协议。JSON 不会消失，但它会退化为应用层与协议层之间的转换格式，而不是直接进窗口的形态——LLMON 工具包里那个 JSON 转换器就是这种分工的雏形。
其二，安全能力会沿着格式协议重新分层。 当指令有了身份和授权范围，「这条指令有权操作这块数据吗」就从语义判断变成了结构判断——可以校验、可以审计、可以在网关层强制执行。这对企业部署 Agent 尤其重要：昨天日报里 OpenAI 披露的数百个持久 Agent 安全架构，靠的是沙箱和凭证代理这些外层手段；格式层的身份体系补上的是最内层、此前完全缺失的一环。内外夹击之下，持久 Agent 的安全模型才可能闭环。
其三，应用层的数据封装协议值得现在就开始重新设计。 如果你正在做 Agent 或 RAG 系统，把「数据怎么进上下文」当成一个待选型的问题，而不是默认 json.dumps。关注 LLMON 的开源工具包和 Granite 预览模型的表现，也要留意其他厂商的跟进——这类协议的竞争才刚开始，过早锁定单一格式有风险，但无视这个方向的风险更大。
结语
提示注入困扰业界三年的根本原因，是我们一直在用「更聪明的叮嘱」对抗「更狡猾的文本」，而战场本身就是错的。LLMON 把防御下沉到 token 编码层，攻击成功率趋近于零的数字或需保留，但它验证的原理是硬的：当指令和数据在编码层面有了不可伪造的身份差异，大部分注入攻击在到达模型语义层之前就已经失效。
更大的启示在于，这件事再次提醒我们：大模型应用的很多「对齐难题」，答案可能不在模型也不在提示词，而在两者之间的表示层。上下文工程（Context Engineering）这个去年才流行起来的词，正在从「怎么组织信息让模型看懂」进化为「怎么设计编码让模型可靠」——后者，才是它真正配得上 Engineering 这个词的时刻。
本文基于 2026-11-13 AI 洞察日报选题撰写，原始信源：IBM / Hugging Face Blog / GitHub。