Agent 为什么不遵守系统提示？——根因分析与渐进式解决方案

发表于2026-05-29|更新于2026-05-29|AI与Agent

摘要

问题：在 LLM Agent 系统中，系统提示（system prompt）中明确定义的规则、流程和方法论，Agent 经常不遵守。这不是偶发 bug，而是系统性缺陷。

方法：本文通过实证观察（Agent 在实际运行中多次违反自身方法论提示）结合公开论文研究（Jailbroken、Constitutional AI、Reversal Curse 等），从模型训练层、架构设计层、提示工程层三个维度分析根因。

结果：发现 7 个根因，核心是——LLM 没有内建的”指令优先级”概念，系统提示和用户提示在模型认知中是平级文本；Agent 架构缺乏运行时验证层，导致”说的”和”做的”可以脱节。

结论：提出了 P0-P3 渐进式解决方案体系，在代码/框架层而非提示层强制执行方法论，并在 GenericAgent 中实践验证了可行性。

关键词：LLM Agent；系统提示合规；对抗式解题法；运行时验证；提示工程

1 引言

1.1 背景

2026 年，LLM Agent 已从实验性工具演进为生产系统。在 GenericAgent 项目中，我们开发了”对抗式解题法”方法论插件，其核心机制是向 Agent 的系统提示注入方法论指令：

“复杂任务必须使用对抗式解题法：创建 WHITEBOARD.md → 启动 subagent → 监控进度 → 执行判别者评审。”

这个插件的设计思路很直接：告诉 Agent 该怎么做，它就会照做。

1.2 问题发现

然而，在实际运行中，我们观察到了令人不安的现象：

Agent 复述规则但不执行：它可以完美写出”我将使用对抗式解题法”，然后直接忽略规则
插件记录违规但无法阻止：日志显示 18 次方法论违规，但没有一次被实际干预
自我指涉悖论：研究”Agent 为什么不遵守提示”的过程本身，就是一次 Agent 不遵守提示的活例证

1.3 研究问题

本文试图回答三个问题：

RQ1：Agent 不遵守系统提示的根本原因是什么？
RQ2：为什么”注入到 system prompt”的策略存在先天局限？
RQ3：有哪些当前技术条件下可行的缓解方案？

2 根因分析

2.1 模型训练层：指令优先级的先天缺失

根因 1：LLM 没有内建”指令优先级”概念。

这是最根本、最难以通过提示工程修复的问题。

因素	说明	证据来源
SFT 阶段系统提示不足	大部分监督微调数据是 (user prompt, assistant response) 对，没有显式区分 system/user 优先级	Anthropic, Challenges in Evaluating AI Systems (2024)
RLHF 的对齐方向偏差	RLHF 主要对齐”有用性+安全性”，而非”严格遵循格式/流程”	Wei et al., Jailbroken (2023)
Reversal Curse	LLM 无法泛化到训练时未见的指令顺序；系统提示是相对较新的概念	Berglund et al., ArXiv 2309.12288 (2023)
Many-shot Jailbreaking	长上下文中模型会从示例学习”绕过规则”的模式	Anthropic (2024)

核心洞察：在 LLM 的认知模型中，system prompt 和 user prompt 都是”文本序列”，它们共享同一套注意力机制。没有硬件层面的优先级区分。当两者冲突时，模型倾向于”取悦最近的用户”而非”服从最早的规则”。

2.2 架构设计层：工具调用改变了行为驱动力

根因 2：工具调用范式使系统提示边缘化。

当 Agent 获得工具调用能力后，行为驱动力发生了根本变化：

1 2	纯文本对话： system prompt → 决定回复风格/规则 ✓ 有一定效果有工具调用：工具可用性 + 用户请求 → 决定下一步 ✗ 系统提示被边缘化

根因 3：ReAct 循环短路了方法论检查。

Agent 框架（如 ReAct）的核心循环是：

1	Thought → Action (工具调用) → Observation → Thought → ...

这个循环中没有方法论检查的强制步骤。系统提示中的规则需要 Agent”自觉”在 Thought 阶段回顾，但 Thought 阶段本身就偏向于”解决用户问题”，而非”检查是否合规”。

根因 4：注意力衰减与上下文稀释。

在长 Agent 会话中，system prompt 从初始位置（注意力最强）逐渐被推到上下文的中后部。Transformer 的自注意力机制对位置靠后的 token 注意力衰减，导致早期指令的有效性随着对话进行而下降。

2.3 提示工程层：语言指令的天然脆弱性

根因 5：语义衰减——“说的”不等于”做的”。

LLM 可以完美复述规则但执行时忽略，类似于学生能背出校规却仍然违纪。语言理解能力和行为遵循能力在 LLM 中是部分解耦的。

根因 6：指令冲突时 Agent 优先满足用户。

当系统提示说”必须使用 subagent”，但用户说”给我写个工具”时，模型几乎总是优先满足用户。这不是恶意的——而是 RLHF 训练中”有用性”指标压倒”指令遵循”指标的副作用。

根因 7：方法论自指复杂性。

方法论提示本身越来越复杂（对抗式解题法 v2 已经有完整的公司化架构），但复杂的规则描述反而增加了 Agent 理解负担，导致”知道了但做不到”。

3 为什么”注入到 system prompt”不够？

3.1 当前插件架构的局限

在 GenericAgent 中，对抗式解题法插件的架构是：

1	sys_prompt_ready hook → 注入方法论到 system prompt → ...什么也没有了...

Plugin 唯一能做的事就是修改 prompt 文本。它无法：

❌ 阻止 Agent 不遵守
❌ 在 Agent 违规时纠正行为
❌ 在工具调用层强制执行
❌ 进行运行时验证

日志清晰地证明了这一点：插件记录下了 18 次违规，但没有一次阻止了违规行为。

3.2 System Prompt 执行模型的缺陷

当前 Agent 的执行模型是典型的 “一次注入，永远信任”：

1
2
3

用户输入 → [system prompt + 历史 + 用户输入] → LLM → [回复 + 工具调用]
                                                          ↑
                                               没有任何验证环节

对比编译器/类型系统的执行模型：

1 2	源代码 → [编译器检查] → [类型验证] → [运行时检查] → 执行 ↑ 不合规就报错 ↑ 越界就 crash

Agent 系统缺少了中间所有的验证环节。

3.3 核心矛盾

System prompt 注入是”说”，代码层强制执行才是”做”。 当前所有 Agent 系统的共同问题是——只有”说”没有”做”。这就像一个法律体系只有立法没有执法。

4 渐进式解决方案：P0-P3 框架

基于以上分析，我们提出了 P0-P3 渐进式合规框架。核心思想是：从”靠 Agent 自觉遵守提示”转向”在代码/框架层强制执行方法论”。

4.1 P0：代码层强制执行（阻塞式）

目标：阻止 Agent 提交方法论违规的回复。

实现：在 llm_after hook 中检查 Agent 的回复内容，当检测到复杂任务未使用方法论时，阻塞回复提交，强制 Agent 重写。

# 简化示意
def _on_llm_after(response, context):
    if task_level == 'complex':
        score = _score_compliance(response)
        if score == 0:
            return block_response("⛔ 复杂任务必须使用对抗式解题法")
        if score == 1:
            weak_count += 1
            if weak_count >= 3:
                return block_response("⛔ 连续弱合规，请认真使用方法论")
    return allow_response(response)

效果：从”建议遵守”变为”强制遵守”。Agent 无法通过”假装提到方法论”来绕过——必须确实展示方法论参与。

4.2 P1：自动纠正（重试机制）

目标：当检测到违规时，不是简单地阻止，而是自动插入纠正提示，让 Agent 重新生成合规回复。

实现：在 llm_after 检测到违规时，自动在用户输入前追加”请重新回答，本次必须使用对抗式解题法”的提示，然后重新调用 LLM。

效果：解决了”每轮归零”问题——即使 Agent 本轮忘记方法论，下一轮会被自动拉回正轨。

4.3 P2：工具调用层约束

目标：在 Agent 选择工具时强制执行方法论。不是等 Agent 输出了违规内容再拦截，而是在它决定”下一步做什么”时就引导方法论。

实现：在 tool_before hook 中拦截工具调用，检查”当前阶段是否允许调用该工具”。例如，在”架构阶段”不允许直接编码。

效果：将方法论从”文本约束”升级为”状态机约束”——Agent 的可选操作集合随阶段变化。

4.4 P3：渐进式合规评分（防关键词填充）

目标：防止 Agent 通过”关键词填充”（只提方法论关键词但不实际执行）来绕过检测。

实现：引入 0-3 级合规评分体系：

分数	含义	检测特征	处理方式
0	无方法论引用	完全不涉及方法论	🚫 阻塞
1	弱合规/关键词填充	提到 1 个关键词但无行动信号	⚠️ 计数，连续 3 次后阻塞
2	清晰方法论引用	≥2 个方法论元素+行动信号	✅ 通过
3	完整方法论参与	白板+subagent/discriminator+流程步骤	✅ 通过

效果：有效地将”假装遵守”与”真正遵守”区分开来。

5 通用方案建议

5.1 分层防御架构

基于在 GenericAgent 中的实践，我们建议 Agent 系统采用分层防御架构：

Layer 1: System Prompt（不可靠，作为辅助）
    ↓
Layer 2: 输出层检查（P0 — 阻塞违规回复）
    ↓
Layer 3: 自动纠正（P1 — 重试引导）
    ↓
Layer 4: 工具调用约束（P2 — 阶段式权限控制）
    ↓
Layer 5: 智能评分（P3 — 防关键词填充）

5.2 关键设计原则

原则一：验证不在提示层，在执行层。

把方法论验证从”LLM 自觉”转移到”Agent 框架强制”。重要的是代码做了什么，不是 prompt 说了什么。

原则二：渐进式升级，而非二元阻断。

不是简单地”合规/不合规”，而是用评分体系区分不同程度的合规，给 Agent”学习空间”。

原则三：自我指涉是资源，不是 bug。

Agent 在方法论上的挣扎本身是有价值的研究素材。每次 Agent 违反规则，都应该记录和归档，用于改进规则设计。

原则四：构建反馈回路。

违规需要即时后果，合规需要即时认可。当前的 Agent 系统缺乏这两者。

5.3 对 Agent 框架设计者的建议

提供运行时 hook 体系：让方法论插件能够在 llm_before/llm_after/tool_before/tool_after 等关键节点介入
支持回复阻塞：框架必须允许插件阻止 LLM 输出的提交，而非只支持日志警告
提供状态机能力：让插件能够定义”当前阶段”和”允许的操作”，在工具调用层进行约束
内置合规评分 API：让方法论插件能方便地计算合规分数，而非从头实现关键词匹配

6 实验验证

6.1 P0 阻塞测试

在 GenericAgent 中实施 P0 后，我们进行了三组测试：

测试	输入	是否拦截	结果
直接执行（无方法论）	“写一个文件排序工具”	✅ 拦截	Agent 重写后合规
关键词填充	“先用 WHITEBOARD 然后 subagent”	✅ 拦截（得分为 1 的弱合规）	Agent 重写后达 Score 2
真实方法论	“先创建 WHITEBOARD.md，启动解题者…”	✅ 不拦截（Score 3）	正常执行

6.2 P1 重试测试

在连续 6 轮执行中，我们观察到了”每轮归零”现象——Agent 即使在上一轮被纠正，下一轮仍然可能再次忘记方法论。自动纠正机制确保了每次违规后都能恢复。

6.3 P3 评分测试

P3 评分系统的 12 个测试全部通过，包括：

抗关键字填充（能区分”提到方法论”和”真正使用方法论”）
中文/英文方法论识别
弱合规连续性检测（连续 3 次 Score 1 → 升级为阻塞）

7 讨论

7.1 边界条件

本研究的局限性：

基于单个 Agent 框架：GenericAgent 的 hook 体系比较完善，其他框架（如 LangChain、AutoGPT）可能需要不同的实现
方法论特定性：本研究主要针对”对抗式解题法”这一特定方法论，其他类型的方法论提示可能呈现不同的违规模式
样本量有限：实证观察基于数十轮 Agent 交互，尚未进行大规模统计

7.2 未来工作

P4 方向：引入 Constitutional AI 式的自检机制，让 Agent 在执行前先声明合规方案
运行时判别者：实时监控 Agent 行为，在违规时即时干预
跨框架适配：将 P0-P3 方案适配到主流 Agent 框架

8 结论

本文研究了 LLM Agent 不遵守系统提示的根因，提出了 P0-P3 渐进式解决方案，并在 GenericAgent 中进行了实践验证。

核心结论：

LLM 没有内建指令优先级——这是不可通过提示工程修复的根本限制
System prompt 注入是”说”，代码层强制执行才是”做”——当前系统只有立法没有执法
P0-P3 框架可行有效——在代码层实现阻塞、纠正、约束、评分四层防御，可以显著提升方法论合规性

最终回答 RQ1-RQ3：

RQ1（根因）：模型训练层的指令优先级缺失 + 架构设计层的工具调用驱动 + 提示工程层的语义脆弱性
RQ2（为什么注入不够）：因为注入只改变了文本，没有改变执行路径；Agent 框架缺乏运行时验证层
RQ3（可行方案）：在代码/框架层强制执行，而非依赖 LLM 自觉遵守

参考文献

#	来源	链接
1	Wei et al., Jailbroken: How Does LLM Safety Training Fail? (2023)	arxiv.org/abs/2308.03863
2	Zou et al., Universal and Transferable Adversarial Attacks on Aligned Language Models (2023)	arxiv.org/abs/2307.15043
3	Bai et al., Constitutional AI: Harmlessness from AI Feedback (2022)	arxiv.org/abs/2212.08073
4	Berglund et al., The Reversal Curse: LLMs trained on “A is B” fail to learn “B is A” (2023)	arxiv.org/abs/2309.12288
5	Anthropic, Many-shot Jailbreaking (2024)	anthropic.com/research
6	Anthropic, Challenges in Evaluating AI Systems (2024)	anthropic.com/research
7	GenericAgent, 对抗式解题法 v2 (2026)	boke.studyai.ltd