Kimi Code CLI v2.6.0新增跨会话保存的权限规则，并为Tower多智能体协作加入artifact任务，交付物须经用户对当前完整提交明确验收后才能合并。人工验收控制的是成果接纳，而非逐步批准执行；Tower工作树也不构成安全沙箱，使用前仍需检查自动执行权限、敏感文件及完整提交内容。
Kimi在2026年11月12日的官方版本日志中列出Kimi Code CLI v2.6.0，新增可在会话启动时自动加载的持久化权限规则，并为Tower多智能体协作加入artifact任务类型：智能体交付报告、构建产物等文件后，必须获得用户对当前提交的明确验收，才能合并。
这次更新针对的是编程智能体的执行与交付流程，而非发布新基础模型。两项变化分别回答两个问题：智能体调用工具时，哪些操作可以放行、拒绝或要求确认；任务结束后，谁批准把成果纳入项目。它们并不等同于一套完整的安全隔离机制，交付验收也不意味着执行过程中的每一步都会等待人工批准。
权限可以跨会话保存，但项目规则有信任边界
按照官方配置文档，用户级权限规则保存在config.toml中，随会话启动加载。项目级规则则来自项目目录下的.kimi-code/local.toml，但只在本地环境、且工作区已被信任时读取；远程项目规则暂不支持。
这使权限设置不必只依附于一次临时交互。开发者可以将允许、拒绝和逐次询问的要求写成规则，在后续会话中继续使用。不过，项目规则修改后需要新开会话，不会通过热重载立即生效。将配置文件改好，与正在运行的任务已经采用新规则，是两件不同的事。
规则冲突时，拒绝（deny）优先于询问（ask），询问又优先于允许（allow）。换言之，一条匹配的允许规则，不会覆盖同时匹配的拒绝规则。版本日志还将“会话启动时应用config.toml中的权限规则”列为修复项，明确包括非交互打印模式中的三类规则；因此，此次更新既涉及持久化配置，也涉及这些配置是否真正进入执行路径。
匹配能力同样有范围。配置文档说明，多数支持参数规则的内置工具可以按命令或路径等对象匹配，但AgentSwarm、MCP工具和自定义工具只能按工具名称匹配，不支持参数模式。不能因为规则可以持久保存，就推断所有外部工具的具体动作都已获得同样精细的约束。
artifact验收的是整次提交，不只是展示的文件
Tower官方指南将其描述为实验性的多智能体协作模式：主智能体担任协调者，把较大的任务拆分成子任务，由工作智能体在各自的Git分支和工作树中并行处理，再按条件整合成果。Tower此前已经存在；v2.6.0新增的是artifact任务及其验收流程，而不是首次引入多智能体协作。
指南把任务分为三类。build用于代码修改，需要已提交的差异和独立审查，再进行实际合并；survey用于只读调查，以零差异结束，不进行Git合并；新增的artifact则面向需要写出文件的业务交付，例如分析报告、渲染结果或训练输出。
artifact的核心要求，是工作智能体在分配范围内提交交付文件，并标出关键产物。Tower向用户展示这些文件及其他已提交文件的数量，用户也可查看完整清单。未提交的文件不属于可验收、可合并的交付物。
这里最容易被误解的是批准的范围：用户验收的是当前分支顶端的整个提交状态，而不只是界面重点展示的几份文件。关键产物列表之外的其他已提交改动，也在这次授权之内。对于同时包含报告、数据文件和辅助代码的任务，仅阅读报告预览，并不等于已经检查了全部将被合并的内容。
验收还绑定具体版本。工作智能体新增提交，或者分支经过rebase、提交顶端发生变化后，都需要重新获得用户验收。自动或非交互运行不会代替人批准，而是让artifact停留在等待验收的状态。因此，无人值守任务可以推进到交付节点，却不能据此被理解为可以无人值守地完成最终接纳。
artifact不要求独立审查者；独立代码审查也不能代替用户对artifact的明确验收。这不是在原有审查流程上统一增加一道检查，而是为不同类型的工作设置不同的完成条件。
人工把关发生在合并前，不等于执行沙箱
Tower默认关闭，用户需要显式启用这一实验功能。指南同时警告，只有协调者支持Ask When Needed权限模式，工作智能体与审查者以Never Ask模式自动运行，不会为单个动作逐次请求用户批准。
这一区别决定了如何理解“人工验收”：它控制的是成果能否合并，不是将此前的所有工具调用变成人工操作。指南明确表示，Git工作树能够分开文件写入，却不是安全沙箱；任务范围和合并检查属于流程约束，不是安全边界。工作智能体仍可读取仓库内容，并以用户所拥有的权限运行工具。
初始化阶段也有需要留意的文件处理。官方说明，Tower可能将未提交或未跟踪的文件快照纳入工作分支；创建新的基准分支时，也可能把这些改动提交进去。在尚未初始化Git的目录中，它会建立仓库并创建包含现有文件的初始提交。因此，密钥、敏感资料和大型文件是否混在工作目录中，是启动协作前就需要处理的问题，不能等到最后验收关键产物时才考虑。
持久化的含义也应分开看：退出进程后，磁盘上的Tower状态、分支和工作树可以保留，但运行中的工作智能体与审查者会停止，后续需要重新启动。保存任务状态，并不等于后台执行者始终存活。
改善控制流程，仍需实际项目验证
编程智能体的权限问题，不只在于界面有没有出现审批提示，还在于用户规则是否在主会话、委派任务和非交互路径中得到执行。本站此前关于Qwen Code v0.27.3审批规则修复的报道涉及另一款工具在自动编辑、后台子代理与非交互调用中的授权处理。这提供了相近的工程背景，但不是Kimi此次更新效果的验证，两者的具体规则不能直接互换。
对Kimi Code用户而言，此次变化提供了更明确的配置入口和交付关口：权限可以预先保存，业务产物的合并需要绑定具体提交的人类验收。与此同时，采用Tower仍需核对自动执行权限、工作目录中的敏感文件、完整提交内容，以及重新提交后的验收状态。
以上机制来自官方版本日志与当前操作文档。本报道未安装运行v2.6.0，也未复现多智能体任务；所核验材料没有提供足以判断此次更新降低错误率、安全事故率或总体返工量的独立对照数据。更清晰的授权与验收流程，是工具行为的变化，而不是任务结果已被证明可靠的结论。