命令行智能体不能猜测破坏性操作
我试过让 Agent 根据一句自然语言直接拼 shell 命令，演示时很顺，复查时却发现clean被理解成删除目录。命令行里“猜对一次”不够，副作用必须显式声明。
现在我把工具定义成只读和可写两组。生成命令前先打印计划，真正执行还要人工确认：
plan: cargo test -p parser effect: read/build temporary artifacts confirm: required我会故意输入含糊指令、带路径的指令和越权指令，检查它是否拒绝写入未知位置。测试样例只用虚构项目名，不放真实账号、目录或业务文本。这样的 Agent 仍可能误判，所以删除、联网和发布操作始终不交给它自动完成。
自然语言只能描述意图
“清理项目”“修一下依赖”“把旧文件处理掉”都缺少执行命令所需的信息。清理的是构建缓存、临时文件还是整个工作目录？依赖是更新锁文件，还是改包版本？旧文件由什么规则识别？人可以在对话中继续追问，工具却不能把自己的猜测当成已经取得授权。
因此，命令行智能体的第一项输出不该是 shell 字符串，而应是结构化计划。计划至少说明目标对象、允许的路径、预期副作用和验证方式。参数仍有歧义时就停下来，把缺少的信息列给操作者。多问一次的成本很低，误删后再尝试恢复的成本却可能无法估计。
用能力接口代替任意 shell
如果任务类型已经明确，可以把底层操作收进边界清楚的工具。例如“运行某个工作区测试”只接受已登记的包名，“读取日志”只允许指定目录，“删除临时产物”只能处理程序自己创建并记录的文件。Agent 选择工具和填写参数，真正的路径解析、权限判断与执行由普通代码完成。
这种接口看起来没有直接执行 shell 灵活，却更容易检查。工具可以拒绝绝对路径、父目录跳转、未识别的通配符和额外参数，也能把每次副作用记录成固定字段。若确实需要自由命令，应把它留在隔离环境中，并默认禁用网络、凭据和工作区外写入，而不是靠提示词要求模型“小心一点”。
确认框不能只重复命令
人工确认要让人看懂将发生什么。把一串经过转义的长命令原样贴出来，操作者可能只会习惯性点击继续。更有效的确认信息会列出将读取和修改的对象、是否联网、是否覆盖已有内容，以及失败后能否撤回。目标在计划生成后发生变化时，还应重新计算计划，不能继续使用旧确认结果。
确认也不能覆盖所有风险。删除、发布、发送消息和修改远端资源通常需要更高一级的授权；有些动作即使用户确认，也应由专门服务再次检查权限和对象状态。Agent 提出动作，权限系统决定能不能做，这两项职责不要混在一起。
失败和重试同样有副作用
一个命令执行失败后，智能体很容易改写参数再试。对只读查询，这种做法有时可以接受；对写文件、提交任务或调用远端接口，盲目重试可能产生重复结果。工具应返回明确的失败阶段和是否允许重试，写操作则需要稳定的任务标识或幂等约束。
超时也不等于没有执行。客户端没有等到响应时，后台进程可能仍在运行。下一步动作之前，先查询已有任务状态或终止受控进程，不能直接再启动一个副本。错误日志保留退出码和脱敏摘要即可，不把环境变量、完整路径和命令中的敏感参数重新送回模型。
测试拒绝行为
上线前除了正常命令，我还会准备几类反例：目标路径不存在、路径指向允许范围之外、参数中混入管道或重定向、工具请求未声明的网络访问，以及用户在确认前改变目标。预期结果不是 Agent “大概能识别危险”，而是执行层稳定拒绝并给出可诊断原因。
审计记录应能回答谁提出了计划、谁确认、实际执行了哪项能力、修改了什么，以及最后如何验证。它不需要保存完整对话和业务内容。命令行智能体真正可用的前提，不是它总能猜中用户想法，而是它猜错时没有机会越过边界。
