短答案
为什么提示词注入很难被彻底消除
提示词注入最可靠的收敛方式，始终是分层控制，而不是某一条聪明的系统提示。最有价值的步骤往往很朴素：把外部内容当成低信任输入、收窄任务、降低智能体权限、为高影响动作保留审批，并像攻击者一样测试工作流。
研究与实践给出的结论高度一致。Instruction Hierarchy 讲的是“高信任指令应该压过低信任文本”；AgentDojo 说明现实智能体环境里问题依然很难；OpenAI Atlas 给出了最清晰的运营建议：减少登录态权限、给模型明确任务，并仔细审查确认步骤。
统一原则：不受信内容应该处于更低权级
最干净的防护思想是把“指令的权级”明确下来：系统或开发者意图应高于用户文本、检索文本与工具提供的内容。网页、邮件、搜索结果或工具描述，不应该和定义智能体职责的高信任指令拥有相同权威。
如果你的架构没有把这件事做清楚，提示词注入就总会有可乘之机。它真正利用的，不是单个模型 bug，而是“本该当数据看的东西被抬成了指令”。
现实中最有价值的防护层
| 防护层 | 为什么有帮助 | 落地建议 |
|---|---|---|
| 收窄任务 | 任务越宽泛，外部内容就越容易改写目标 | 把“处理我的邮箱”改成“草拟这两封邮件的回复，并在发送前确认” |
| 降低权限 | 权限越大，被误导后的破坏面越大 | 缩小工具范围、减少登录态访问、避免默认接入更多系统 |
| 降低不受信文本权级 | 外部内容不应与开发者指令处于同一层 | 把检索内容、工具输出与高信任规则分离 |
| 保留人工审批 | 在“模型看到敌意文本”和“系统执行动作”之间插入检查点 | 对发送、购买、删除、外发等动作默认保留确认 |
| 偏好结构化流程 | 验证字段与约束输出能减少任意文本跨节点泄露 | 尽量使用结构化字段、allowlist 动作与校验后的 JSON |
| 持续对抗评估 | 只有在敌对输入下仍可用，防线才算成立 | 同时测攻击成功率、误报与正常任务可用性 |
哪些手段不能单独依赖
下面这些手段都可能有帮助，但都不应被当成完整答案：一条写着“忽略提示词注入”的系统提示；没有误报与运营成本评估的检测器；只升级模型却不改权限与审批；一份写着安全策略、却依旧允许不受信内容进入高信任层的文档。
更强的模型与更好的检测当然重要，但它们不能替代信任边界。真正有效的方案，是把权限、审批、任务设计与输入检查同时做起来。
- 给智能体一个窄而明确的任务
- 限制登录态访问与工具权限
- 避免把不受信文本塞进系统 / 开发者指令层
- 对高影响动作保留审批
- 尽量使用结构化输出和可校验字段
- 在 URL、文件与解析器可见内容进入模型前先做检查
常见问题
降低提示词注入风险最有效的方法是什么？
最现实的答案是分层防御：把外部内容视为低信任、收窄任务、减少权限、保留审批，并用敌对样本评估整个工作流。
提示词注入风险能被完全阻止吗？
不能靠单一控制完全阻止。研究与运营实践都指向纵深防御，而不是一次性修补。
检测器能解决这个问题吗？
检测器可以提供帮助，但不能单独承担全部防线。误报、运营负担和正常任务可用性都必须一起评估。