LLMON实战：用结构化上下文防止Agent提示注入

解释IBM Granite的LLMON结构化上下文方法，并给出RAG与工具Agent的试验、迁移和安全验收步骤。

问题出在指令和数据混在一起

RAG与工具Agent会把系统要求、用户问题、检索文档、工具结果和输出格式一起塞进上下文。普通文本或JSON能被程序解析，却不保证模型总能分清哪一段是命令、哪一段只是资料。攻击者把“忽略之前要求”藏进网页或工具结果，模型就可能误执行。IBM提出LLMON，通过保留标记和唯一ID显式区分instruction、data、requirement和output，并把要执行的关系写入exec块。

它与JSON和聊天模板的区别

JSON主要为确定性解析器设计，括号、引号和转义在长上下文中会增加模型理解负担。LLMON使用模型词表中的保留特殊Token标记边界，并把结构局部表达。它不是替代聊天模板：聊天模板区分system、user、assistant角色，LLMON进一步说明每个片段的语义和关联。现有系统仍可保存JSON，只在送入模型前转换为LLMON，输出后再无损转回。

最小试验流程

先选择Granite 4.1 3B或8B的LLMON预览模型，在隔离环境准备三类任务：普通问答、检索增强、工具调用。将同一请求分别以原格式和LLMON格式运行，加入包含恶意指令的文档与工具返回。记录任务正确率、注入成功率、格式错误率、Token数量和延迟。不要直接替换生产模型，因为官方将其标记为实验预览，目标是验证结构化上下文是否适合自己的数据和攻击面。

RAG与工具调用怎么改

检索内容统一标记为data，每个文档带来源ID；用户任务标记为instruction；长度、语言、引用要求标记为requirement；exec只绑定本轮真正需要的片段。旧对话和未选中的资料可以存在上下文，但不应进入执行绑定。工具Schema、工具返回和系统策略使用不同标签，模型生成调用后，执行层仍需做白名单、类型和权限校验。结构隔离能降低误解，不能替代应用层授权。

上线前的安全结论

官方实验显示LLMON对静态间接提示注入有明显改善，但也说明自适应、多轮攻击仍在研究。企业应保留红队测试，加入多语言、编码混淆、图片OCR和连续工具调用攻击。模型输出不得直接成为权限判断；关键动作需要独立策略引擎和人工确认。若试验有效，可先用于内部知识库和只读工具，再逐步扩展。衡量成功的标准不是“模型从未被攻破”，而是攻击更难、异常可见、损失可控并能快速停止。