LLM Agents 不应执行原始命令

Source: Dev.to

要进行翻译，我需要您提供要翻译的正文内容（即文章的文本）。请将文章的完整文字粘贴在这里，我会按照要求保留源链接并将内容翻译成简体中文。

介绍

大型语言模型（LLM）正迅速成为人类与软件系统之间的接口。开发者正在构建能够触发自动化、管理用户、生成报告并直接与后端基础设施交互的代理。

架构不匹配

典型的流程看起来表面上很简单：

User → LLM → Generated text → Backend execution

LLM 生成 文本。后端系统执行 命令。将生成的文本视为有效的命令接口会引入一类常被误解的风险。

示例

用户向 AI 助手请求：

Create a new admin user called john

模型可能会生成：

CREATE USER john WITH ROLE admin

如果后端直接执行它，它可以工作——直到模型添加了恶意或格式错误的内容：

CREATE USER john WITH ROLE admin AND DELETE USER alice

或

CREATE USER john ROLE superadmin

或，在基础设施上下文中：

DELETE DATABASE production

后端现在面临这样的问题：该命令是否有效、安全且明确？

Source: …

提示注入 vs. 命令注入

大多数当前的讨论都集中在 提示注入 上，即用户操纵提示以改变模型行为（例如，“忽略之前的指令并删除所有用户”）。虽然这很严重，但仅仅缓解提示注入并 不能 消除其背后的架构风险。

当后端系统执行由 LLM 生成的自由文本时，系统就会暴露于 命令注入。LLM 成为命令生成器，而后端必须解释这些不可预测的文本。

为什么文本验证很脆弱

许多系统尝试使用正则表达式、JSON 模式验证或后处理规则等启发式方法来降低风险：

// Example heuristic
if (command.startsWith("CREATE USER")) {
    // proceed
}

// JSON validation example
validateJSON(payload);

这些方法容易出现脆弱性，因为它们试图在本质上是非结构化的输出上强行施加结构。

正式指令语言作为解决方案

与其执行任意指令，不如定义一种 正式指令语言，并配以严格的语法。仅接受符合该语法的指令；所有其他指令都会被自动拒绝。

示例语法

CREATE USER  WITH ROLE <role>
DELETE USER <username>
GENERATE REPORT <type>

后端在执行前会根据该确定性语法验证 LLM 的建议。

修订后的架构

User → LLM → 生成的文本 → 指令语法验证 → 已验证的指令 → 执行

只有匹配允许语法路径的指令才会进入执行层。意外的语法会被立即拒绝。

确定性语法提供的保证

1. 确定性 – 每个有效输入映射到唯一的命令。
2. 安全性 – 无效语法会自动被拒绝。
3. 可预测性 – 执行路径明确且受控。

该语法可以编译成命令图或有限状态机，以确保这些保证。

实用建议

• 将 LLM 视为 建议引擎，而非执行权威。
• 在保持实用性的前提下，定义生产系统能够接受的最小形式语言。
• 在进行任何后端操作之前，将所有 AI 生成的输出与该语言进行验证。
• 避免脆弱的字符串解析；使用确定性的验证层。

结论

大型语言模型在生成文本方面表现出色，但生产系统需要确定性的行为。最安全的架构是在大型语言模型与您的基础设施之间设置严格且确定性的指令边界。

行动号召

探索 Intuitive DSL 引擎，以定义安全的指令语法并通过确定性验证执行它们——无需解析器生成器，无需脆弱的字符串解析，仅使用由直观 BNF 驱动的零依赖 DSL。