LLM 系统中的软约束与硬约束：为什么失配会导致真正的失败

提示词更改是一种团队经常低估的特定生产危害。对 LLM 生产事故的研究表明，提示词修改（通常由一名工程师为了改进某个用例的质量而进行）会导致其他行为的退化。一个为了提高简洁性而添加的软约束可能会削弱早先为了提高安全性而添加的软约束。约束通过 Pull Request 不断累积，且没有冲突检测，因为“保持简洁”和“始终彻底解释你的推理”不会产生编译错误。它们产生的是行为漂移，并在两周后体现在生产指标中。

硬性约束实现模式​

针对结构化保证的约束解码。 现代推理引擎支持语法约束生成（grammar-constrained generation），在每个生成步骤中，有效的 Token 集合都会被过滤，仅保留可能出现在结构有效输出中的 Token。通过这种方式强制执行的 JSON Schema 验证，从构造层面（by construction）杜绝了格式错误的 JSON 输出，而不仅仅是依靠指令（by instruction）。这与“客气地要求模型”有着本质的区别。像 XGrammar 和 Guidance 这样的实现方式，在带来极低延迟开销的同时实现了这一点——而且由于它们缩小了搜索空间，约束生成的执行速度往往比无约束生成更快。

请注意约束解码能解决什么，以及不能解决什么。句法约束（Syntactic constraints）——“输出必须是符合此 Schema 的有效 JSON”——是可以解决的。语义约束（Semantic constraints）——“user_id 字段中的值必须对应一个拥有执行此操作权限的真实用户”——则无法解决。约束解码无法强制保证正确性，只能保证结构。你仍然需要通过语义验证来确保正确性。

工具定义作为架构约束。 在 Agent 系统中，模型的行为边界由你赋予它的工具决定。一个没有数据库访问工具的客户服务 Agent，无论用户如何措辞，都无法访问数据库。这从根本上比在系统提示词（system prompt）中写下“不要访问数据库”更加鲁棒。绕过工具级别的约束需要完全不同程度的妥协——攻击者需要注入新的工具定义，这需要访问 Agent 的配置权限，而不仅仅是对话。

保持工具集精简。非重叠的工具定义可以减少错误和滥用的风险暴露面。当 Agent 拥有三个都可能适用于某个请求的工具时，工具选择就变成了一个软约束问题。而当 Agent 只有一个明确适用的工具时，它就是结构性的。

基础设施层级的访问控制。 最小权限原则（Principle of least privilege）同样适用于 LLM Agent，就像适用于任何服务账号一样。如果 Agent 的数据库凭据仅允许对特定表的读取访问，那么任何提示词注入（prompt injection）都无法导致 Agent 写入数据或从它无权访问的表中窃取数据。约束是在数据库层强制执行的。模型的意图、指令或恶意注入的指令在此时都无关紧要。

这要求将 LLM 驱动的系统视为一个安全边界（security boundary），而不是一个受信任的内部服务。模型默认处理的是不可信的输入。进入上下文窗口（context window）的任何外部内容——用户消息、检索到的文档、电子邮件、网页——都具有潜在的对抗性。应当据此限制模型的权限范围。

边界处的输入净化（Sanitization）。 在用户输入到达模型之前，对其进行标准化处理。清除不可见的 Unicode 字符（Unicode 标签字符，范围在 U+E0000–U+E007F 之间，曾被用于生产环境中的攻击，通过嵌入不可见的指令来绕过文本级防护栏）。应用长度限制。在 IP 和会话级别进行频率限制。检测已知的注入模式。这些措施虽然不能拦截所有问题，但在模型看到输入之前就减少了风险暴露面。

跨层级的深度防御。 OWASP 对生产环境 LLM 系统的建议是，对于任何安全关键型的控制，至少设置三个独立的约束层。面对有动机的攻击者或意料之外的输入分布，单一的防护栏（guardrail）是不够的。目标是让一次成功的绕过必须破解多个独立的机制，而不是仅仅找到一个漏洞。

匹配执行强度与风险​

操作层面的问题在于，如何在资源有限的情况下，根据约束类型分配工程力量。一个简单的基于风险的框架：

对于 安全关键型控制（Security-critical controls）——未经授权的工具访问、PII 处理、特权操作、金融交易——硬性约束是不可逾越的底线。软约束不是安全控制措施。OWASP 明确指出：“诸如最小权限访问之类的关键控制应当被独立强制执行，无论提示词中写了什么。” 针对安全关键行为的提示词指令应被视为深度防御的一部分，而不是主要的防御手段。

对于 结构正确性要求（Structural correctness requirements）——输出格式、Schema 合规性、必填字段——在推理引擎支持的情况下，请使用约束解码。如果你调用的是不支持约束解码的第三方模型，请使用“带有拒绝机制的输出验证”，而不是“修复机制”。修复循环产生的输出虽然能通过格式检查，但往往无法通过后续的语义检查。

对于 语义正确性要求（Semantic correctness requirements）——事实准确性、业务逻辑正确性、跨引用的一致性——将软约束与相应层级的验证相结合。提示词中的“确保准确”是必要的，但并不充分。需要增加语义验证：针对知识库的事实核查、针对生成代码的 AST 验证、针对生成 SQL 的 Schema 感知验证、针对多轮输出的一致性检查。

对于 用户体验和质量控制（User experience and quality controls）——语气、冗长度、响应风格——软约束是合适的。违规的风险只是一个不太理想的响应，而不是安全事故。在此处投入硬性约束会增加基础设施的复杂性，却无法获得成比例的可靠性收益。

实践测试​

对于你正在考虑的任何约束，一个有用的启发式准则是：如果该约束在每百万次请求中被违反一次，会发生什么？如果答案是“用户收到的响应稍微长了一点”，那么软约束就足够了。如果答案是“用户私有数据泄露”、“生产系统执行了未经授权的操作”或“应用程序被攻击者利用”，那么你需要硬约束，而且你可能需要在多个层面上实现它。

软约束使 LLM 变得好用。硬约束使它们变得安全。工程上的错误在于构建了这样一个系统：在周一，0.01% 的软约束违反率并不重要；但在周五，由于生产流量增长了两个数量级，这导致了一场事故。应根据失败的后果来匹配执行机制，而不是根据实现的难度。

做得好的团队不会将提示词工程视为架构的替代品。他们使用提示词来塑造行为，但这种行为发生在一个即使模型表现不佳也能生存下去的系统中。这才是值得构建的约束系统。