编程智能体的“自动模式”究竟自动到什么程度，往往比模型能力更值得先问。月之暗面9月4日发布Kimi Code CLI 0.41.0，重新命名三档权限，并明确最激进的Never Ask模式会自动处理所有工具审批，连关机、重启或递归删除这类危险命令也可不中断执行。与此同时，实验性Tower多智能体协作进入Web端，执行规模扩大与授权边界被放在了同一次更新里。

三档权限不是快慢选择，而是风险分层

Always Ask是默认模式，只读操作可以直接进行，编辑文件、运行命令等动作都逐项确认，适合陌生代码库、高价值环境和需要精确审计的变更。Ask When Needed通过/yolo进入，会自动批准常规工具调用，但访问.env、SSH密钥等敏感文件，执行shutdown、reboot、rm -rf等危险命令，或退出Plan模式前仍然询问。

Never Ask通过/auto进入，是完全无人值守模式：所有审批由系统自动处理，智能体也不再向用户追问，而是自行决定。0.41.0特别说明，内置危险命令防护在前两档仍会拦截并请求确认，但在Never Ask中不再激活。变化并非全局取消防护，而是把“是否接受不间断执行”交给模式选择者。

Tower把一次授权放大成多个执行单元

Web端新增的Tower可通过/tower命令或输入框加号菜单启用，还能指定基础分支，让多个智能体围绕同一目标协作。版本同时修复了通过配置启用却无法启动、非Git目录不能使用，以及子智能体恢复后权限模式不一致等问题；被恢复的子智能体会沿用当前模式，并按自身配置匹配权限规则。

这使权限的影响从单个终端会话扩展到并行任务。一个宽松授权如果被多个子智能体继承，写入范围、命令数量和失败传播面都会扩大。基础分支可以帮助组织代码起点，却不等于受保护分支、密钥隔离、资源配额、网络出口控制或可回滚环境。

生产环境需要把“询问”换成外部门禁

Kimi Code允许关闭dangerous_command_guard，默认值为开启。官方给出的边界很清楚：只有环境已经在智能体之外限制命令时，才应关闭这道内置策略。对企业而言，外部门禁至少应包括隔离容器或临时虚拟机、最小权限凭据、只允许目标目录写入、受保护分支、命令白名单、网络出口限制，以及可查询的工具调用日志。

无人值守任务还应设置停止条件，例如最大步骤数、运行时长、费用和并发上限；删除、部署、付款、对外发送等不可逆动作则保留独立审批。即使模型不向人提问，基础设施也必须能拒绝越界调用、保存证据并在失败后恢复。每一次提权还应留下机器可读记录，便于复盘谁在何时、基于什么上下文放行了哪项操作，并定期用故障注入验证停止开关和恢复链路确实有效。否则“没有弹窗”只是把决策从用户界面移到了事故之后。

小编判断：更强自治必须匹配更硬的隔离

0.41.0的价值不只是改名，而是把不同模式真正会做什么写得更直白。Always Ask适合建立信任，Ask When Needed适合可控批处理，Never Ask则应被视为一种部署形态，而不是方便开关。Tower仍处实验阶段，官方没有公布任务成功率、并发上限、成本、故障隔离或具名客户数据，因此不宜直接承担关键生产流程。

ATYUN观点：团队可以先在一次性分支和无长期凭据的沙箱里运行Tower，把每个子任务限制在可回滚范围，再用变更差异、测试结果和审计日志决定是否合并。真正成熟的无人值守编程，不是让智能体永远不问，而是让高风险动作即使没有人盯着，也跨不过系统预先画好的边界。