LM Studio 给 AI 命令装裁判：裁判开始和被审方站一边了

一条看似普通的 git diff 命令，一旦遇上变量，就可能给 AI 编程 Agent 带来问题。

以 git diff $base 为例。如果 $base 解析为一个提交哈希，命令行为符合预期。但若它被解析为 --output=/some/file，Git 就会把结果写入文件系统。LM Studio 构建了 Auto Review 来在 Bionic 执行命令之前捕获这类情况，只有在无法判断安全性时才会调用另一个语言模型。

LM Studio 在上周四发布的一篇博客文章中表示，这第一层检查无需调用其他模型就能清除 Bionic 高达 82% 的命令，不过作者同时说明这个数字是经验性的，而非基准测试结果。

Bionic 的做法是将 shell 命令转换为抽象语法树（AST），追踪变量和嵌套命令以判断它们可能的影响范围。LM Studio 已经构建了 11,651 个测试用例，用于捕获各种可能出错的分析场景。

一条看似普通的 git diff 命令，一旦遇上变量，就可能给 AI 编程 Agent 带来问题。

解析结构，而非字符串

仅搜索危险字符串是远远不够的，因为 shell 命令的行为会随着其中的变量、重定向和其他命令而改变。

Bionic 的 Shell Judge 通过直接查看命令的结构来绕过这一难题。它使用 mvdan/sh 解析器处理 Bash、Zsh 和 SH，而 PowerShell 则使用其自带的 AST 支持。随后 Judge 会计算出 LM Studio 所称的命令「能力」，即命令可能读取或修改的内容。

它还可以在一个命令到下一个命令之间追踪值。如果一个 Agent 使用 git merge-base 找到共同的祖先提交，然后将结果传给 git diff，例如，Judge 会在评估第二个命令时追踪该结果。如果存在多个可能的值，Bionic 最多会追踪 1,000 个，然后停止尝试穷举所有可能性。

11,651 个 CLI 怪癖测试用例

此外，命令行工具本身也有各自的规则。比如 ls -la 会把 -la 视为多个选项打包在一起，而 LM Studio 指出 TypeScript 的 tsc -vh 行为与分别用 -v 和 -h 运行并不相同。

所以仅解析 shell 语法只能让 Bionic 走到一半。Shell Judge 还需要理解各个工具如何解释命令后面的参数。

这就解释了为什么 LM Studio 已经构建了 11,651 个测试用例，覆盖格式错误的命令以及各工具处理参数方式的怪癖。

当审查者被左右时

LM Studio 发现，仅仅询问审查者一条命令是否应该执行效果并不好，因为模型有时会批准危险操作——仅仅因为这些操作看起来对于完成用户请求似乎是必要的。

任何 Shell Judge 无法清除的命令都会交给 Shell Reviewer，它是一个独立的 AI Agent，在对话上下文中评估命令。

LM Studio 发现，仅仅询问审查者一条命令是否应该执行效果并不好，因为模型有时会批准危险操作——仅仅因为这些操作看起来对于完成用户请求似乎是必要的。

审查者现在会在不知道通过分数要求的情况下，对每条命令的风险性、授权性和正确性进行评分。

信任假设仍然存在漏洞

Shell Reviewer 需要足够的对话上下文来判断用户是否授权了某条命令，这就为提示词注入创造了另一个可乘之机。LM Studio 排除了工具结果，因此嵌入在网页或文件中的指令不会被直接传递给审查者，但它仍然会看到助手消息。如果 Bionic 已经被攻破，这些消息就可能携带恶意指令。

如果 Bionic 已经被攻破，这些消息就可能携带恶意指令。

Shell Judge 本身也有盲点，因为它假设 git 等可执行文件没有被篡改，也不会考虑可能改变命令行为的恶意配置。最近的一次 npm 供应链攻击表明，看似合法的溯源信号也可以被用来隐藏恶意负载。

随着编程 Agent 获得更大的行动自由，这些限制变得愈发重要。例如，Google 的 Gemini 编程 Agent 最近已经扩展到其 IDE 边界之外，赋予 Agent 更多机会来执行命令和进行更改，而无需开发者手动逐步操作。