别再乞求你的AI安全：约束工程的论证
Source: Dev.to
我已经厌倦了把“提示工程”作为安全策略。
如果你正在构建自主代理——能够真正执行查询数据库、移动文件或发送电子邮件的 AI——你很可能已经感受到焦虑。你会写出这样的提示：
“请生成一个 SQL 查询以获取用户计数。IMPORTANT: 请不要删除任何表。请，我恳求你，不要删除数据库。”
然后你祈祷并希望 LLM 的概率数学能够尊重你的礼貌请求。
这简直是疯狂的。在传统软件工程中，我们不会对用户输入说“请不要成为 SQL 注入”。我们会对其进行清理。我们使用防火墙。我们使用严格的类型检查。然而在 AI 代理中，我们似乎忘记了确定性系统的基本原则。
我最近构建了一个我称之为 Constraint Engine 的模块，它彻底改变了我对 AI 代理的信任方式。以下是我们为何需要停止通过提示来实现安全，而是通过编码来实现安全的原因。
哲学：大脑 vs. 手
核心问题在于我们把 LLM 同时当作 大脑（规划、推理）和 手（执行）来使用。
- 大脑 (LLM)： 生成计划（例如，“我将删除这些临时文件以节省空间”。）
- 防火墙 (约束引擎)： 一个确定性的 Python 脚本，用硬性规则（正则表达式、白名单、成本限制）检查计划。
- 手 (执行器)： 仅在防火墙返回
True时执行该计划。
“人类筑墙，AI 在墙内游戏。”
“逻辑防火墙”实现
实现出奇地简单。它不使用另一个 AI 来检查 AI（这只会增加成本和不确定性）。它使用标准、乏味的 Python。
from dataclasses import dataclass
from typing import Any, Dict
@dataclass
class ConstraintViolation:
rule_name: str
severity: str # CRITICAL, HIGH, MEDIUM, LOW
message: str
blocked_action: str
class ConstraintEngine:
def validate_plan(self, plan: Dict[str, Any]) -> bool:
"""
Loop through rules and return approval status.
If CRITICAL or HIGH severity violations exist, BLOCK.
"""
# (Implementation of rule checking goes here)
...规则很蠢（这很好）
我们不需要 AI “理解”删除数据库为何有害。我们只需要捕获语法。
示例：SQLInjectionRule
import re
class SQLInjectionRule:
DANGEROUS_PATTERNS = [
r'\bDROP\s+TABLE\b',
r'\bDELETE\s+FROM\b.*\bWHERE\s+1\s*=\s*1\b',
r';\s*DROP\b', # Command chaining
]
def validate(self, plan):
query = plan.get("query", "")
for pattern in self.DANGEROUS_PATTERNS:
if re.search(pattern, query, re.IGNORECASE):
return ConstraintViolation(
rule_name="SQLInjectionRule",
severity="CRITICAL",
message=f"Dangerous SQL detected: {pattern}",
blocked_action=query,
)
return None这算原始吗？是的。它对标准的 DROP TABLE 命令是否 100 % 有效？同样是的。正则表达式只关注语法，而不考虑上下文。
悖论：安全促进创造力
通常，当我们希望 AI 代理安全时，会把 temperature（随机性）调低到 0.0，使其变得机械且可预测。这会扼杀 AI 设计巧妙解决方案的能力。
使用约束引擎时，你可以 把 temperature 调高（例如 0.9 或 1.0）。让模型产生大胆的想法，然后让防火墙执行硬性限制。
- Scenario A（无防火墙）： AI 幻想出
rm -rf /。服务器被清空。 - Scenario B（有防火墙）： AI 幻想出
rm -rf /。FileOperationRule捕获了它。代理收到错误信息：“Action Blocked: root deletion not allowed.” AI 随后自我纠正：“啊，抱歉。我改为删除特定的日志文件。”
防火墙充当游乐场的边界，在保持系统安全的同时，允许创造力发挥。
超越SQL：成本与范围
相同的方法也适用于预算控制。CostLimitRule 可以阻止超出预定义货币阈值的计划。
class CostLimitRule:
def __init__(self, max_cost: float):
self.max_cost = max_cost
def validate(self, plan):
if plan.get('estimated_cost', 0) > self.max_cost:
return ConstraintViolation(
rule_name="CostLimitRule",
severity="HIGH",
message="Cost exceeds authorized limit.",
blocked_action=str(plan),
)
return None这可以防止出现“无限循环破产”情形，即代理因调用昂贵的 API 而陷入循环。
摘要
我们正进入一个 AI 不再仅仅是聊天机器人，而是 执行者 的时代。依赖 AI 的“自我控制”（通过系统提示）来保护你的基础设施是疏忽的。
- Intercept 在执行前拦截计划。
- Validate 对硬逻辑进行验证（正则、数学、白名单）。
- Execute 仅执行通过的部分。
停止乞求。开始工程化。