IBM 发布 LLMON 与 Granite 4.1 8B，间接注入压至 0.02% 却折损数学推理

把一段恶意的越狱指令塞进检索文档里，普通微调模型在 OPI 基准测试上几乎百发百中，攻击成功率高达 96.3% 到 100%。2026 年 11 月 12 日，IBM 在 Hugging Face 端出了一套叫 LLMON（LLM Object Notation，读作 lemon）的大模型原生标记语言，直接把这项指标干到了 0.02% 和 0.1%。乍看之下，困扰行业三年的提示词注入顽疾，似乎被几个特殊符号终结了。但翻开 IBM 在 10 月 28 日公开的后训练评估论文、模型卡细节和 GitHub 仓库的 Issue 列表，你会看到另一幅景象：一旦走出静态单轮测试，进入多轮红队博弈，这套防线的失守率依然超过六成，而且 8B 模型的高阶数学与代码推理能力还为此摔了一跤。

先把牌面上的信息过一遍。IBM 早在 2026 年 3 月就提出了 LLMON 的底层构想，这次是以 Apache 2.0 协议正式开源了两个实验性预览模型（granite-4.1-3b-llmon-preview 与 granite-4.1-8b-llmon-preview），同步放出了 generative-computing/llmon 工具库（内含 JSON 无损互转工具，并支持通过 LoRA 微调像 ScienceWorld 科学实验环境那样的自定义领域标签），还在自家的 Mellea 框架里集成了原生自动转换支持。

• 解决什么痛点.传统 JSON 是给确定性语法解析器设计的，不是给因果语言模型看的；同时，长链路 Agent 把系统指令和外部不可信数据混在同一个平面文本通道里，极易被间接提示词注入劫持，或是被无关的旧对话污染回答。
• 核心账面战绩.在静态间接提示词注入测试中，3B 模型从 Instruct 版切换到 LLMON 版后，OPI 攻击成功率从 100.0% 骤降至 0.1%，ASB 攻击成功率从 99.2% 降至 5.6%；8B 模型的 OPI 攻击成功率从 96.3% 降至 0.02%，ASB 从 52.8% 降至 3.1%，在 StruQ 等基准上也呈现出同样的压制趋势。
• 直接受影响的人.正在用 RAG 或多工具流水线搭建企业级 Agent 的开发者，以及所有试图在 ChatML 对话模板之外寻找下一代上下文协议的基础模型团队。

为什么 JSON 喂给大模型总是天然脆弱

过去几年，几乎所有工程团队都在干同一件事：逼着大模型吞下 JSON，再求着它吐出合法的 JSON。但从 Transformer 的视角看，JSON 简直是一场语法灾难。

JSON 的花括号、双引号和冒号，跟普通文章里的标点符号共用同一套词表。对解析器清清楚楚的转义反斜杠，到了大模型眼里只是一团模糊的统计规律；更要命的是，JSON 靠数括号深度来表示嵌套层级，而自回归模型最不擅长的事，就是在几千个 Token 的长跨度里数清楚还差几个右花括号。

IBM 的解法是直接改词表和改寻址方式。LLMON 在分词器里硬塞了 6 个单 Token 保留分隔符：<|open|>（开始标签）、<|close|>（结束标签头）、<|open_end|>（结束块）、<|self_close|>（闭合空字段）、<|.|>（分隔嵌套标签路径组件）和 <|:|>（分隔标签与标识符）。结构符号和正文内容从词表层就彻底分家，嵌套路径在局部直接声明，模型再也不用跨着几千字去配对括号。

更关键的一步在语法层。传统的 ChatML 模板只分角色（system、user、assistant），微软的 Spotlighting 靠编码或分隔符给不可信数据打胶带，OpenAI 的指令层级靠训练让模型听高优先级角色的话。LLMON 则把提示词拆成了带两字符单 Token 唯一 ID 的独立数据块，并在上下文最底部加了一个 exec 执行块。

这套设计像极了编程语言里的函数调用与传参：每个组件标上 exec: True 或 False，只有被底部 exec 块用 ID 点名的指令才算数，被点名的 data 块只当成待处理的原材料，而没被点名的历史残余或外部杂音直接晾在一边。每次寻址一个块，固定只花 2 个 Token。

0.02% 注入率神话背后，红队测试与模型卡藏着另一本账

如果只看官方博客里的柱状图，你会觉得提示词注入已经成了历史名词。但只要把底层论文和 GitHub 仓库翻开对比，光环就会迅速褪色。

为了教会模型看懂这套指针，IBM 没有在现成的 Instruct 模型上打补丁，而是直接从 Granite 4.1 Base 底座模型出发重头训练。团队用 440 万条样本、46 亿 Token 跑了 3 个 epoch 的全量 SFT，专门在上下文里塞入大量没被 exec 块绑定的诱饵指令和无关数据，逼着模型学会装聋作哑；接着又跑了 5 个阶段的 GRPO 强化学习，最后用约 1,000 对模型自己生成的注入攻防偏好对做了 DPO。

这番重锤确实砸出了对静态间接注入的极高免疫力，但代价和盲区同样扎眼。

在 IBM 自家的 ARES 红队评估里，LLMON 3B 和 8B 面对间接攻击的鲁棒性（1 减去攻击成功率）降到了 84.6% 和 79.8%，意味着仍有 15% 到 20% 的攻击能钻进空子。一旦换成直接攻击，两个模型的鲁棒性只剩 37.1% 和 32.7%；到了多轮对话攻击场景，鲁棒性更是跌到 28.0% 和 37.0%——换句话说，攻击者只要多聊几轮，仍有 63% 到 72% 的概率撬开防线。

还有一笔账记在通用能力上。官方博客宣称 LLMON 与常规 Instruct 模型表现持平，但对照 Hugging Face 模型卡上的细分跑分，8B 模型出现了非常剧烈的偏科：

3B 模型也有类似的分化：MMLU 从 67.02 微升至 68.05，GSM8K 从 86.88 微升至 86.96，但 MMLU-Pro 从 49.83 跌到了 46.08，DeepMind Math 从 64.64 跌到了 60.48。让小模型分出大量注意力去盯紧指针绑定和防注入，终究挤占了它在复杂数学和自由推理上的脑容量。

把提示词改成字节码，为什么还是替不了系统沙箱

我很欣赏 IBM 捅破窗户纸的方向：与其在自然语言泥潭里跟攻击者玩文字游戏，不如给大模型设计一套带指针的标记协议。但我不太买账的是，很多团队容易把这种词表层的特殊 Token 误当成硬件级的安全隔离。

计算机科学史上早就演过一出几乎一模一样的大戏。1960 年代，早期的冯·诺依曼架构把程序代码和数据混装在同一片内存里，缓冲区溢出攻击随便就能把数据当成指令执行。后来芯片行业是怎么解决的？靠的是硬件页表里的 NX bit（不可执行位），CPU 电路直接拒绝执行数据页里的任何机器码，那是物理定律级别的铁门。

词表能锁住语法的边界，但锁不住概率模型的走神。

LLMON 看起来像是在大模型里引入了 NX bit，但底子完全不同。就像《左传》里说的，“皮之不存，毛将焉附”，芯片的不可执行位长在硅片逻辑门上，而大模型的 exec 绑定长在注意力权重的概率分布上。IBM 自己在论文和模型卡里也老老实实写了免责声明：LLMON 的指令与数据隔离只是习得行为（learned behavior），绝非强制保证（enforced guarantee）。

工程细节里的裂缝已经开始冒头了。在 GitHub 的 generative-computing/llmon 仓库里，11 月 3 日提交的 Issue #16 直接泼了一盆冷水：在 OpenClaw 无人值守定时运行的真实场景下，配合 8 个工具做测试时，攻击者依然成功触发了 Agent 劫持与提示词注入。而在更早的 10 月 23 日（Issue #1）和 10 月 26 日（Issue #3），开发者就已经发现 short-to-llmon 转换路径在处理包含特殊 Token 字面量的普通文本时，转义和分词逻辑还有漏洞，连列表分隔符该不该设为特殊 Token 都还没吵出定论。

除此之外，还有实打实的迁移成本。LLMON 的标签外壳会凭空吃掉 7%–15% 的额外上下文 Token，论文里甚至还没测算这部分膨胀对推理延迟和吞吐量的拖累；而且它彻底绑死了专用 Jinja 模板，如果直接喂常规的对话格式，模型就会因为分布外（OOD）输入而表现失常。相比之下，微软的 Spotlighting 虽然粗糙，但不用重训底座，随便拿个现成模型就能套用。

• 结论.LLMON 真正有价值的遗产，是在 ChatML 的角色划分之外，跑通了用单 Token 分隔符加底部 exec 块做细粒度指针绑定的上下文新协议，给下一代 Agent 原生通信打了个样。
• 风险.切勿因为静态基准上 0.02% 的漂亮数字就撤掉应用层的工具权限沙箱，多轮攻击下逾六成的失守率、8B 模型在数学推理上的掉点，以及 Issue #1 和 Issue #16 暴露的转义与工具链劫持隐患，说明它目前仍只能当实验预览版看。

回到开头那个 0.02% 的数字。IBM 用 46 亿 Token 的重训证明了，只要把提示词改造得像带指针的函数调用，哪怕是 3B 和 8B 的小模型，也能在单轮静态偷袭面前筑起高墙。但只要底层还是靠注意力机制算概率，标记语言就永远成不了真正的编译器。接下来最值得盯紧的，是这套 exec 指针协议能不能跨出 Granite 家族被更大的开源底座接纳，以及 IBM 能不能在修好 GitHub 上那几个转义和劫持漏洞的同时，把 8B 模型丢掉的那 9 分数学能力找回来。