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