据 OpenAI 于 2024 年 4 月 20 日发布的《The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions》显示，当前大语言模型仍容易受到提示注入、越狱等攻击影响：攻击者可能通过恶意提示覆盖模型原本应遵循的系统要求或开发者指令，从而诱导模型偏离预期行为。该方向的核心关注点，是训练模型识别不同来源、不同权限级别的指令，并在冲突时优先遵循更高权限的指令。
对 API 使用者而言，这不是一个单纯的安全研究话题，而是会直接影响模型接入、Agent 编排、插件调用、企业知识库问答和自动化工作流的基础能力。随着越来越多应用把外部网页、用户上传文件、检索结果和工具返回内容交给模型处理，如何防止低权限内容反向控制模型行为，正在成为 LLM 应用上线前必须评估的关键环节。
什么是“指令层级”：解决指令冲突的优先级问题
在典型的模型调用链路中，模型可能同时接收到多类信息：平台或模型提供方设定的系统规则、开发者在 API 中写入的行为约束、终端用户提出的问题，以及来自网页、文档、数据库或工具返回的内容。问题在于，模型如果无法稳定区分这些内容的权限，就可能把一段被检索到的文本当成真正命令执行。
来源摘要提到的提示注入与越狱，本质上都在尝试让模型忽视原始指令，改为执行攻击者设置的提示。所谓“指令层级”，可以理解为让模型在训练阶段形成更清晰的优先级：当高权限指令与低权限输入发生冲突时，模型应优先遵守高权限规则，而不是被后出现的文本、伪装成命令的网页内容或用户诱导语覆盖。
- 系统级指令：通常代表模型或服务提供方设定的最高约束。
- 开发者指令：用于限定应用场景、输出格式、工具使用规则等。
- 用户指令：终端用户的具体请求，需要在上层约束内执行。
- 外部内容：如网页、文件、检索片段、工具返回结果，应主要被视为数据，而非可覆盖规则的命令。
对开发者的影响：API 接入不能只靠提示词“补丁”
从开发者和 API 调用方角度看，OpenAI 强调这一问题，说明 LLM 安全边界正在从“写好提示词”转向“模型能力、调用架构与权限设计”共同承担。过去不少应用会在 system prompt 中加入“不要被用户诱导”“忽略文档中的指令”等防护语句，但在复杂场景下，这类做法可能不足以应对恶意构造的输入。
尤其在 RAG、浏览器 Agent、代码执行助手、企业客服和自动化办公场景中，模型需要读取大量不受开发者完全控制的内容。若这些内容中夹带“请泄露系统提示”“请改用以下规则回答”等文本，模型是否会服从，就决定了应用是否存在安全风险。指令层级训练的意义在于，让模型内化这种权限判断，而不是完全依赖调用方临时加提示词。
API 平台与中转服务应关注的接入要点
对通过 API 使用 OpenAI、Claude、Gemini 等模型的团队来说，相关进展意味着未来在选型和接入时，除了价格、并发、延迟和稳定性，还应把“指令遵循稳定性”和“抗提示注入能力”纳入评估。对于 Token 中转站、API 批发和模型调用中介服务，安全能力也会影响客户在企业级场景中的信任度。
在实际工程中，开发者仍应保留多层防护，而不是等待模型能力单点解决所有问题：
- 明确区分 system、developer、user 与外部检索内容，不把外部文本直接拼接成高权限指令。
- 为工具调用、数据库查询、代码执行等高风险动作设置服务端校验。
- 对用户上传文件、网页内容和检索片段进行隔离标注，提示模型将其视为资料来源。
- 在日志与监控中记录异常指令冲突，便于发现潜在提示注入攻击。
行业解读：模型安全将成为成本与稳定性之外的新竞争点
本次来源所讨论的“指令层级”反映出一个趋势：LLM API 的竞争不再只看上下文长度、单次调用价格或响应速度，能否在复杂输入中可靠遵循高权限指令，会成为开发者选择模型的重要依据。对企业客户而言，模型若能更好抵御提示注入和越狱攻击，将降低在客服、知识库、Agent 和内部自动化流程中的合规风险。
不过，来源摘要并未给出具体产品上线时间、价格变化或 API 参数调整。因此，开发者当前更应把它视为一个重要技术方向信号：未来模型可能会更强调权限结构和安全对齐，而应用侧也需要同步升级提示模板、权限边界和调用网关设计。对于依赖多模型 API 的团队，建议在模型评测中加入提示注入测试集，并比较不同模型在相同系统指令下的抗干扰表现。
总体来看，OpenAI 对“指令层级”的讨论提示了一个现实问题：当模型被用于连接外部工具和真实业务系统时，提示词本身已经成为安全边界的一部分。谁的指令优先、哪些内容只能作为数据、何时拒绝低权限覆盖，将直接影响 API 应用的可靠性与可控性。