只靠LLM判断"这个命令/工具是否相关、是否该执行"太单一。LLM擅长语义理解，但不适合作为唯一安全边界。所以还需要进行更细致的优化。
工具调用要看两个部分：
① 任务相关性：这个工具是否有助于完成用户目标；
② 安全可执行性：即使相关，能不能执行。
所以一般的工具调用流程可以概括为：
用户请求-->任务意图识别-->候选工具 / 命令生成-->规则引擎初筛-->LLM 语义相关性判断-->静态分析 / 参数解析-->风险评分-->沙箱或 dry-run-->结果验证-->最终执行，拒绝或进行请求确认。
（1）规则引擎初筛
LLM不应该负责识别所有危险命令。很多危险模式可以用规则直接拦截。例如：
禁止 rm -rf /
禁止 rm -rf ~
禁止 chmod -R 777 /
禁止 dd of=/dev/sda
禁止 mkfs
禁止 curl ... | bash
禁止读取 ~/.ssh/id_rsa
禁止上传 .env
禁止 DROP DATABASE
这类规则不需要LLM判断，直接判定为极高风险。总结起来规则引擎适合处理：
（2）把工具和命令做结构化解析
先将命令解析成结构化字段，再判断风险，不直接把一整条命令当自然语言交给 LLM 判断。这样可以避免 LLM 被命令表面形式迷惑。
（3）建立工具能力表
不光靠LLM判断需要调用什么工具，每个工具都应该有明确metadata。其中包含工具的主副能力，危险程度，可写范围，需要用户确认的操作等等。
（4）候选召回+排序
当工具很多时，可以让LLM进行工具检索召回Top-k，排序，接着在少量候选中判断需要用到哪些工具，最后由策略层最终批准。
排序的标准包括：
（5）加入上下文约束
判断命令是否相关，必须结合当前任务状态。上下文约束包括：
（7）风险评分分层
风险评分高低可以从这几个维度看：
最终根据相关性与风险评分做出相应操作：
（8）dry-run
在执行可能造成不可逆后果的命令，如删除文件、清理未跟踪文件之前，先使用模拟或预览模式，即dry-run，查看即将受影响的文件，确认无误后再实际执行，以避免误删或误操作。例如，删除日志文件时，先用 find logs -name "*.log" -print 列出所有 .log 文件，确认后再执行 rm；使用 git clean -fd 前，先运行 git clean -fd -n 或 git clean -fd --dry-run 预览将被删除的未跟踪文件，再实际执行清理。这样可以有效防止因命令写错或范围过大导致重要文件被误删。
（9）沙箱执行
即使命令相关，也可以先在沙箱跑。例如代码修复，可以复制项目到临时目录，Agent修改代码，运行测试，生成diff，检查diff范围，用户确认后应用。这样可以把执行风险降到最低。执行工具后，再进行测试，例如测试是否全部通过，是否生成异常文件，是否修改了预期外文件，日志里是否泄露敏感信息。
（10）用专门的Safety Critic / Risk Assessor Agent
可以把主Agent和安全判断Agent分开。例如，Planner Agent提出动作；Risk Assessor判断风险；Executor只执行被批准动作；Validator检查结果；Finalizer输出给用户。Risk Assessor进行结构化输出，这样比主Agent自己边做边判断更稳定。
（11）使用策略引擎做最终裁决
LLM可以做建议，但最终是否执行应该由策略引擎决定。例如，策略引擎输出：
{
"allowed": false,
"reason": "Command attempts to upload sensitive file",
"policy": "no_secret_exfiltration"
}
（12）引入历史反馈与在线学习
Agent可以记录过去的工具选择结果：长期可以统计：
（13）多模型/多评审投票
对于高风险动作，可以让多个判断器参与。例如LLM Judge 1：判断任务相关性；LLM Judge 2：判断安全风险；Rule Engine：检查硬规则；Static Analyzer：检查命令结构；Policy Engine：最终裁决。只有多方都通过，才执行。
总结：
对于工作调用，可以使用下面的策略：LLM 判断语义相关性-->规则引擎拦截已知危险-->解析器理解命令结构-->策略引擎做最终裁决-->沙箱降低执行风险-->dry-run提供预览-->验证器检查执行结果，高风险操作人工确认，再通过历史反馈持续优化。