AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载Kimi Code本仓库为gh_mirrors/ki/kimi-code在 agent-core-v2 引擎中提供了一种自动权限模式auto permission mode。开启后工具审批将全程自动放行Agent 无需暂停等待人工确认。本文以官方维护的进入提醒文档 permission-mode-auto-enter-reminder.md 为主线结合其配套的退出提醒、上下文注入服务、权限策略链与测试用例完整讲解自动模式的语义约束、提醒注入机制、环境变量开关与源码级实现原理帮助你安全、正确地驾驭这一无人值守运行模式。一、自动权限模式是什么三种模式中的 auto在 Kimi Code 的权限体系中每个 Agent 会话都运行在一种权限模式下。模式定义见 types.tsexport type PermissionMode manual | yolo | auto;manual手动模式是permissionModeKey的默认初值见 permissionModeOps.ts。工具调用需要逐个人工审批。yolo无确认模式一切工具调用直接放行不做安全审查。auto自动模式处于该模式时工具审批自动处理但仍保留危险命令防护的语义边界详见下文策略链分析。默认权限模式可通过配置节defaultPermissionMode设置其取值 Schema 为[manual, auto, yolo]定义在 configSection.tsexport const DEFAULT_PERMISSION_MODE_SECTION defaultPermissionMode; export const DefaultPermissionModeSchema z.enum([manual, auto, yolo]);模式切换会持久化为可回放的permission.set_mode事件PermissionSetMode事件类型定义见 permissionModeOps.ts并触发onDidChangeMode事件通知订阅方接口见 permissionMode.ts。二、进入提醒的完整原文与逐条语义当 Agent 会话切换到auto模式时官方会在上下文中注入如下提醒文件原文见 permission-mode-auto-enter-reminder.mdAuto permission mode is active. Tool approvals will be handled automatically while this mode remains enabled. - Continue normally without pausing for approval prompts. - Do NOT call AskUserQuestion while auto mode is active; decide and continue. - ExitPlanMode is also approved automatically, without the user reviewing the plan. An auto-approved plan is NOT a signal from the user to start executing — follow the users original instructions on whether to proceed.逐条解读如下工具审批自动处理只要自动模式保持开启工具审批tool approvals就会被自动放行Agent 无需为每个工具调用暂停等待人工确认。不要因审批而暂停Agent 应正常继续执行不得为了等待审批提示而中断回合。禁止调用 AskUserQuestion自动模式下不得调用AskUserQuestion向用户提问而应基于已有上下文自行决策并继续。这一约束不仅是提醒文本更是强制的策略权限策略链中专门注册了 auto-mode-ask-user-question-deny当mode auto且工具名为AskUserQuestion时直接返回deny拒绝信息为 AskUserQuestion is disabled while auto permission mode is active; decide and continue.与提醒文本互相印证。ExitPlanMode 自动获批 ≠ 用户批准执行自动模式下ExitPlanMode也会被自动批准但自动获批的计划不是用户授权开始执行的信号——Agent 必须遵循用户最初的指令来决定是否继续例如用户要求只做计划、先不要执行则不得开始执行。第 4 条是自动模式最容易产生歧义的语义。从源码看ExitPlanMode在自动模式下确实被自动批准工具执行逻辑在this.permissionMode.mode auto分支直接返回auto-approved结果见 exitPlanModeTool.ts输出文本明确写到 this plan was auto-approved without user review — the user has NOT explicitly approved it并要求 Agent 遵循用户原始指令决定是否执行exitPlanModeTool.ts。CHANGELOG 也记录了这条行为变更CHANGELOG.md 提到 auto 模式下计划退出会被标记为auto-approved未经用户审阅从而让 Agent 不再把自动批准误当成用户开始执行的信号。三、退出提醒模式还原后的提示与进入提醒配套的是退出提醒 permission-mode-auto-exit-reminder.mdAuto permission mode is no longer active. Tool approvals and permission checks are back to the current mode. - Continue normally, but expect approval prompts or denials when a tool requires them.语义要点自动模式不再生效后工具审批与权限检查恢复到当前模式manual/yolo的规则。Agent 应继续正常工作但需要预期当某个工具需要审批时会出现审批提示或拒绝结果。四、提醒的注入机制PermissionModeInjection 与 Context Injection进入/退出提醒并非硬编码写在主流程里而是通过上下文注入Context Injection框架动态写入上下文。核心实现在 permissionModeInjection.tsexport class PermissionModeInjection extends Service { constructor( private readonly permissionMode: PickIAgentPermissionModeService, mode, injector: IAgentReminderService, IAgentStateService private readonly states: IAgentStateService, ) { super(); this.states.contributeState(permissionModeLastModeKey); this._register( injector.register(PERMISSION_MODE_INJECTION_VARIANT, (ctx) this.reminder(ctx)), ); } // ... private reminder({ injectedPositions }: ContextInjectionContext): string | undefined { const currentMode this.permissionMode.mode; const previousMode this.lastMode; if (currentMode previousMode) { if (injectedPositions.length 0 || currentMode ! auto) return undefined; return AUTO_MODE_ENTER_REMINDER; } this.lastMode currentMode; if (currentMode auto) return AUTO_MODE_ENTER_REMINDER; if (previousMode auto) return AUTO_MODE_EXIT_REMINDER; return undefined; } }该注入器以变体名permission_mode注册到IAgentReminderServicepermissionModeInjection.ts。其判定逻辑可以概括为一张状态表场景当前模式上一次模式上下文中是否已有注入注入内容模式切换为 autoauto≠ auto—进入提醒模式切换出 auto≠ autoauto—退出提醒模式未变且为 autoautoauto无例如被压缩剔除进入提醒重新公告模式未变且为 autoautoauto已有不注入模式未变且非 automanual/yolo相同—不注入底层支撑一IAgentReminderService 上下文注入框架PermissionModeInjection注册的 Provider 会在每个回合开始前被调用框架位于 reminderService.tsinjectEntry调用 provider将返回内容通过wrapSystemReminder包裹成system-reminder文本systemReminder.ts并以role: user的消息追加进上下文记忆origin.kind injection、variant记为permission_modereminderService.ts。provider 收到的ContextInjectionContext包含injectedPositions历史中已注入位置、lastInjectedAt、lastInjection、isNewTurn等信息定义见 types.ts。PermissionModeInjection正是利用injectedPositions判断提醒是否已存在于上下文中从而避免重复注入。注入触发点注册在 Agent 循环的onWillBeginStephook 上变体context-injectorreminderService.ts并监听ContextSpliced上下文拼接/压缩事件在压缩后重新注入reminderService.ts。该服务由ReminderFeature注册为 Agent 级服务reminderFeature.ts。底层支撑二AgentPermissionModeService 装配与状态AgentPermissionModeServicepermissionModeService.ts在构造时通过agentState.contributeState注册permissionMode与permissionMode.configured两个状态键permissionModeService.ts依据环境变量KIMI_CODE_PERMISSION_MODE_REMINDER决定是否实例化PermissionModeInjectionpermissionModeService.tssetMode分发PermissionSetMode事件并触发onDidChangeModepermissionModeService.tssetModeAndBroadcast在主 AgentMAIN_AGENT_ID上向子 Agent 广播模式并上报afk_toggle/yolo_toggle遥测permissionModeService.ts。注意afk_toggle遥测自动模式本质上服务于Agent 无人值守AFK场景这也是该模式被设计为全程自动审批的原因之一。五、自动模式的权限策略链哪些放行、哪些拦截自动模式并不等于无条件放行一切。AgentPermissionPolicyService按注册顺序依次求值各策略返回第一个非空结果permissionPolicyService.ts。与 auto 模式直接相关的策略如下auto-mode-ask-user-question-deny第一优先级auto 模式下拦截AskUserQuestion返回 denyauto-mode-ask-user-question-deny.ts。这从策略层面强制了提醒文本中不得调用 AskUserQuestion的要求。auto-mode-approveauto 模式下返回approve实现工具审批自动处理auto-mode-approve.tsevaluate(): PermissionPolicyResult | undefined { return this.modeService.mode auto ? { kind: approve } : undefined; }危险命令防护dangerous-command-ask在 auto 模式下该策略直接跳过返回 undefineddangerous-command-ask.ts即危险命令由 auto 策略直接放行因此auto 模式适用于你信任任务内容、可接受无人值守执行的场景。该策略在非交互nonInteractive启动时不会被注册permissionPolicyService.ts。yolo-mode-approvemode yolo时无条件放行yolo-mode-approve.ts。default-tool-approve一批默认工具Read、Grep、Glob、ExitPlanMode、EnterPlanMode等始终放行default-tool-approve.ts。从策略链可以看出auto 与 yolo 的差别在于yolo 无条件放行且不注册任何 ask/deny 拦截策略顺序上 yolo-mode-approve 在 auto 之后但 auto 模式下 ask-user-question-deny 会先命中而 auto 仍保留对AskUserQuestion的强制 deny避免 Agent 在无人值守时向用户抛出问题导致回合停滞。六、环境开关KIMI_CODE_PERMISSION_MODE_REMINDER提醒注入的默认开关是环境变量KIMI_CODE_PERMISSION_MODE_REMINDER定义见 permissionModeService.ts。其判定逻辑为if (parseBooleanEnv(bootstrap.getEnv(PERMISSION_MODE_REMINDER_ENV)) ! false) { this._register(new PermissionModeInjection(this, reminder, this.agentState)); }即只有显式设置为false/0时才禁用提醒注入其余情况未设置、true、1均默认启用。因此# 保持默认启用自动模式提醒注入 kimi-code # 关闭自动模式提醒注入不推荐会丢失进入/退出提示 KIMI_CODE_PERMISSION_MODE_REMINDER0 kimi-code # 显式开启 KIMI_CODE_PERMISSION_MODE_REMINDER1 kimi-code对应测试用例见 permissionMode.test.ts设0时registeredInjection为undefined不注册注入设1时注入以变体名permission_mode正常注册。七、测试验证提醒注入的完整行为契约permissionMode.test.ts 覆盖了提醒注入的边界行为可作为理解该机制的行为契约模式切换触发提醒setMode(auto)后运行注入返回包含 Auto permission mode is active 与 ExitPlanMode is also approved automatically 的进入提醒再切回manual返回退出提醒L164-L177。幂等去重同一回合内第二次运行注入返回undefined避免重复注入L170-L173。压缩/撤销后重新公告上下文中的提醒被 splice 剔除后auto 模式会被重新公告L179-L187非 auto 模式下 splice 后不会注入L189-L194。会话恢复时重新公告即使历史中已有 live reminder新实例首次运行注入仍会重新公告 auto 模式L196-L223。模式事件可回放permission.set_mode事件落盘后可被重放重建模式状态L225-L252。此外permissionPolicyService.test.ts 验证了 auto 模式下AskUserQuestiondeny 策略位于默认放行之上L144-L151、auto 模式批准多种命令、并在 auto 模式下不采用 git-cwd 审批L621-L628。八、与 Plan 模式的协同EnterPlanMode / ExitPlanMode 语义自动模式与计划模式的协同规则在工具描述 enter-plan-mode.md 与 exit-plan-mode.md 中有明确约定EnterPlanMode在所有权限模式下都无需审批直接进入计划模式。auto 模式下不使用AskUserQuestion基于已有上下文做最佳决策ExitPlanMode不询问用户直接退出计划模式。yolo / manual 模式下ExitPlanMode仍将计划呈现给用户审批。这也解释了提醒文本第 4 条的关键目的auto 模式下计划自动获批但 Agent 仍须以用户最初指令为准不可把自动获批当作执行许可。对应实现见 exitPlanModeTool.ts。九、实操建议与适用边界适用场景需要 Agent 长时间无人值守完成明确任务对应遥测afk_togglepermissionModeService.ts时使用 auto 模式它比 yolo 更克制——保留了对AskUserQuestion的强制拒绝防止回合因提问而停滞。安全注意auto 模式下危险命令策略被跳过、审批全部自动放行因此不要在你不完全信任的任务内容上开启自动模式如需额外安全网可结合permission.rules配置允许/拒绝/询问规则见 configSection.ts与dangerousCommandGuard默认开启环境变量KIMI_CODE_DANGEROUS_COMMAND_GUARDconfigSection.ts定制边界——但注意 auto 模式会跳过危险命令策略规则兜底需要在模式层之外生效。提醒开关默认开启的提醒注入可在KIMI_CODE_PERMISSION_MODE_REMINDER0下关闭但保留提醒有助于模型在长会话、压缩恢复后不丢失当前处于自动模式的上下文。计划审批认知auto 模式下ExitPlanMode的自动获批绝不等于用户批准执行Agent 应严格依据用户原始指令推进避免越权执行用户明确要求暂停/等待的任务。参考文件索引进入提醒原文permission-mode-auto-enter-reminder.md退出提醒原文permission-mode-auto-exit-reminder.md注入实现permissionModeInjection.ts模式服务与装配permissionModeService.ts、permissionMode.ts、permissionModeOps.ts默认模式配置节configSection.ts权限策略链permissionPolicyService.ts、auto-mode-approve.ts、auto-mode-ask-user-question-deny.ts、dangerous-command-ask.ts、default-tool-approve.ts上下文注入框架reminderService.ts、types.ts、systemReminder.ts测试契约permissionMode.test.ts、permissionPolicyService.test.ts赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Codewhale Auto-Review 全自动权限审查机制解析与 Claude Code / Kimi Code 的 Auto 模式对齐设计Codewhale Auto Review 全自动权限审查机制解析与 Claude Code / Kimi Code 的 Auto 模式对齐设计 本篇以仓库内人工智能AI Agent代码智能体CLI工具调用MCP ClientsOpenChamber 权限自动放行Permission Auto-Accept跨端权威策略运行时与安全网机制深度解析OpenChamber 权限自动放行Permission Auto Accept跨端权威策略运行时与安全网机制深度解析 导读 权限自动放行PermissAI Agent人工智能代码智能体交互助手Anarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发Anarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发 本文以 Anarlog 仓库中的发布技能清单 .cuAI Agent代码智能体人工智能大模型CLI上一篇洛雪音乐播放异常修复高效解决方案下一篇从根源解决音乐播放异常3个维度的系统排查指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kimi Code 自动权限模式（Auto Permission Mode）指南：从进入提醒到源码级运行机制
AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载Kimi Code本仓库为gh_mirrors/ki/kimi-code在 agent-core-v2 引擎中提供了一种自动权限模式auto permission mode。开启后工具审批将全程自动放行Agent 无需暂停等待人工确认。本文以官方维护的进入提醒文档 permission-mode-auto-enter-reminder.md 为主线结合其配套的退出提醒、上下文注入服务、权限策略链与测试用例完整讲解自动模式的语义约束、提醒注入机制、环境变量开关与源码级实现原理帮助你安全、正确地驾驭这一无人值守运行模式。一、自动权限模式是什么三种模式中的 auto在 Kimi Code 的权限体系中每个 Agent 会话都运行在一种权限模式下。模式定义见 types.tsexport type PermissionMode manual | yolo | auto;manual手动模式是permissionModeKey的默认初值见 permissionModeOps.ts。工具调用需要逐个人工审批。yolo无确认模式一切工具调用直接放行不做安全审查。auto自动模式处于该模式时工具审批自动处理但仍保留危险命令防护的语义边界详见下文策略链分析。默认权限模式可通过配置节defaultPermissionMode设置其取值 Schema 为[manual, auto, yolo]定义在 configSection.tsexport const DEFAULT_PERMISSION_MODE_SECTION defaultPermissionMode; export const DefaultPermissionModeSchema z.enum([manual, auto, yolo]);模式切换会持久化为可回放的permission.set_mode事件PermissionSetMode事件类型定义见 permissionModeOps.ts并触发onDidChangeMode事件通知订阅方接口见 permissionMode.ts。二、进入提醒的完整原文与逐条语义当 Agent 会话切换到auto模式时官方会在上下文中注入如下提醒文件原文见 permission-mode-auto-enter-reminder.mdAuto permission mode is active. Tool approvals will be handled automatically while this mode remains enabled. - Continue normally without pausing for approval prompts. - Do NOT call AskUserQuestion while auto mode is active; decide and continue. - ExitPlanMode is also approved automatically, without the user reviewing the plan. An auto-approved plan is NOT a signal from the user to start executing — follow the users original instructions on whether to proceed.逐条解读如下工具审批自动处理只要自动模式保持开启工具审批tool approvals就会被自动放行Agent 无需为每个工具调用暂停等待人工确认。不要因审批而暂停Agent 应正常继续执行不得为了等待审批提示而中断回合。禁止调用 AskUserQuestion自动模式下不得调用AskUserQuestion向用户提问而应基于已有上下文自行决策并继续。这一约束不仅是提醒文本更是强制的策略权限策略链中专门注册了 auto-mode-ask-user-question-deny当mode auto且工具名为AskUserQuestion时直接返回deny拒绝信息为 AskUserQuestion is disabled while auto permission mode is active; decide and continue.与提醒文本互相印证。ExitPlanMode 自动获批 ≠ 用户批准执行自动模式下ExitPlanMode也会被自动批准但自动获批的计划不是用户授权开始执行的信号——Agent 必须遵循用户最初的指令来决定是否继续例如用户要求只做计划、先不要执行则不得开始执行。第 4 条是自动模式最容易产生歧义的语义。从源码看ExitPlanMode在自动模式下确实被自动批准工具执行逻辑在this.permissionMode.mode auto分支直接返回auto-approved结果见 exitPlanModeTool.ts输出文本明确写到 this plan was auto-approved without user review — the user has NOT explicitly approved it并要求 Agent 遵循用户原始指令决定是否执行exitPlanModeTool.ts。CHANGELOG 也记录了这条行为变更CHANGELOG.md 提到 auto 模式下计划退出会被标记为auto-approved未经用户审阅从而让 Agent 不再把自动批准误当成用户开始执行的信号。三、退出提醒模式还原后的提示与进入提醒配套的是退出提醒 permission-mode-auto-exit-reminder.mdAuto permission mode is no longer active. Tool approvals and permission checks are back to the current mode. - Continue normally, but expect approval prompts or denials when a tool requires them.语义要点自动模式不再生效后工具审批与权限检查恢复到当前模式manual/yolo的规则。Agent 应继续正常工作但需要预期当某个工具需要审批时会出现审批提示或拒绝结果。四、提醒的注入机制PermissionModeInjection 与 Context Injection进入/退出提醒并非硬编码写在主流程里而是通过上下文注入Context Injection框架动态写入上下文。核心实现在 permissionModeInjection.tsexport class PermissionModeInjection extends Service { constructor( private readonly permissionMode: PickIAgentPermissionModeService, mode, injector: IAgentReminderService, IAgentStateService private readonly states: IAgentStateService, ) { super(); this.states.contributeState(permissionModeLastModeKey); this._register( injector.register(PERMISSION_MODE_INJECTION_VARIANT, (ctx) this.reminder(ctx)), ); } // ... private reminder({ injectedPositions }: ContextInjectionContext): string | undefined { const currentMode this.permissionMode.mode; const previousMode this.lastMode; if (currentMode previousMode) { if (injectedPositions.length 0 || currentMode ! auto) return undefined; return AUTO_MODE_ENTER_REMINDER; } this.lastMode currentMode; if (currentMode auto) return AUTO_MODE_ENTER_REMINDER; if (previousMode auto) return AUTO_MODE_EXIT_REMINDER; return undefined; } }该注入器以变体名permission_mode注册到IAgentReminderServicepermissionModeInjection.ts。其判定逻辑可以概括为一张状态表场景当前模式上一次模式上下文中是否已有注入注入内容模式切换为 autoauto≠ auto—进入提醒模式切换出 auto≠ autoauto—退出提醒模式未变且为 autoautoauto无例如被压缩剔除进入提醒重新公告模式未变且为 autoautoauto已有不注入模式未变且非 automanual/yolo相同—不注入底层支撑一IAgentReminderService 上下文注入框架PermissionModeInjection注册的 Provider 会在每个回合开始前被调用框架位于 reminderService.tsinjectEntry调用 provider将返回内容通过wrapSystemReminder包裹成system-reminder文本systemReminder.ts并以role: user的消息追加进上下文记忆origin.kind injection、variant记为permission_modereminderService.ts。provider 收到的ContextInjectionContext包含injectedPositions历史中已注入位置、lastInjectedAt、lastInjection、isNewTurn等信息定义见 types.ts。PermissionModeInjection正是利用injectedPositions判断提醒是否已存在于上下文中从而避免重复注入。注入触发点注册在 Agent 循环的onWillBeginStephook 上变体context-injectorreminderService.ts并监听ContextSpliced上下文拼接/压缩事件在压缩后重新注入reminderService.ts。该服务由ReminderFeature注册为 Agent 级服务reminderFeature.ts。底层支撑二AgentPermissionModeService 装配与状态AgentPermissionModeServicepermissionModeService.ts在构造时通过agentState.contributeState注册permissionMode与permissionMode.configured两个状态键permissionModeService.ts依据环境变量KIMI_CODE_PERMISSION_MODE_REMINDER决定是否实例化PermissionModeInjectionpermissionModeService.tssetMode分发PermissionSetMode事件并触发onDidChangeModepermissionModeService.tssetModeAndBroadcast在主 AgentMAIN_AGENT_ID上向子 Agent 广播模式并上报afk_toggle/yolo_toggle遥测permissionModeService.ts。注意afk_toggle遥测自动模式本质上服务于Agent 无人值守AFK场景这也是该模式被设计为全程自动审批的原因之一。五、自动模式的权限策略链哪些放行、哪些拦截自动模式并不等于无条件放行一切。AgentPermissionPolicyService按注册顺序依次求值各策略返回第一个非空结果permissionPolicyService.ts。与 auto 模式直接相关的策略如下auto-mode-ask-user-question-deny第一优先级auto 模式下拦截AskUserQuestion返回 denyauto-mode-ask-user-question-deny.ts。这从策略层面强制了提醒文本中不得调用 AskUserQuestion的要求。auto-mode-approveauto 模式下返回approve实现工具审批自动处理auto-mode-approve.tsevaluate(): PermissionPolicyResult | undefined { return this.modeService.mode auto ? { kind: approve } : undefined; }危险命令防护dangerous-command-ask在 auto 模式下该策略直接跳过返回 undefineddangerous-command-ask.ts即危险命令由 auto 策略直接放行因此auto 模式适用于你信任任务内容、可接受无人值守执行的场景。该策略在非交互nonInteractive启动时不会被注册permissionPolicyService.ts。yolo-mode-approvemode yolo时无条件放行yolo-mode-approve.ts。default-tool-approve一批默认工具Read、Grep、Glob、ExitPlanMode、EnterPlanMode等始终放行default-tool-approve.ts。从策略链可以看出auto 与 yolo 的差别在于yolo 无条件放行且不注册任何 ask/deny 拦截策略顺序上 yolo-mode-approve 在 auto 之后但 auto 模式下 ask-user-question-deny 会先命中而 auto 仍保留对AskUserQuestion的强制 deny避免 Agent 在无人值守时向用户抛出问题导致回合停滞。六、环境开关KIMI_CODE_PERMISSION_MODE_REMINDER提醒注入的默认开关是环境变量KIMI_CODE_PERMISSION_MODE_REMINDER定义见 permissionModeService.ts。其判定逻辑为if (parseBooleanEnv(bootstrap.getEnv(PERMISSION_MODE_REMINDER_ENV)) ! false) { this._register(new PermissionModeInjection(this, reminder, this.agentState)); }即只有显式设置为false/0时才禁用提醒注入其余情况未设置、true、1均默认启用。因此# 保持默认启用自动模式提醒注入 kimi-code # 关闭自动模式提醒注入不推荐会丢失进入/退出提示 KIMI_CODE_PERMISSION_MODE_REMINDER0 kimi-code # 显式开启 KIMI_CODE_PERMISSION_MODE_REMINDER1 kimi-code对应测试用例见 permissionMode.test.ts设0时registeredInjection为undefined不注册注入设1时注入以变体名permission_mode正常注册。七、测试验证提醒注入的完整行为契约permissionMode.test.ts 覆盖了提醒注入的边界行为可作为理解该机制的行为契约模式切换触发提醒setMode(auto)后运行注入返回包含 Auto permission mode is active 与 ExitPlanMode is also approved automatically 的进入提醒再切回manual返回退出提醒L164-L177。幂等去重同一回合内第二次运行注入返回undefined避免重复注入L170-L173。压缩/撤销后重新公告上下文中的提醒被 splice 剔除后auto 模式会被重新公告L179-L187非 auto 模式下 splice 后不会注入L189-L194。会话恢复时重新公告即使历史中已有 live reminder新实例首次运行注入仍会重新公告 auto 模式L196-L223。模式事件可回放permission.set_mode事件落盘后可被重放重建模式状态L225-L252。此外permissionPolicyService.test.ts 验证了 auto 模式下AskUserQuestiondeny 策略位于默认放行之上L144-L151、auto 模式批准多种命令、并在 auto 模式下不采用 git-cwd 审批L621-L628。八、与 Plan 模式的协同EnterPlanMode / ExitPlanMode 语义自动模式与计划模式的协同规则在工具描述 enter-plan-mode.md 与 exit-plan-mode.md 中有明确约定EnterPlanMode在所有权限模式下都无需审批直接进入计划模式。auto 模式下不使用AskUserQuestion基于已有上下文做最佳决策ExitPlanMode不询问用户直接退出计划模式。yolo / manual 模式下ExitPlanMode仍将计划呈现给用户审批。这也解释了提醒文本第 4 条的关键目的auto 模式下计划自动获批但 Agent 仍须以用户最初指令为准不可把自动获批当作执行许可。对应实现见 exitPlanModeTool.ts。九、实操建议与适用边界适用场景需要 Agent 长时间无人值守完成明确任务对应遥测afk_togglepermissionModeService.ts时使用 auto 模式它比 yolo 更克制——保留了对AskUserQuestion的强制拒绝防止回合因提问而停滞。安全注意auto 模式下危险命令策略被跳过、审批全部自动放行因此不要在你不完全信任的任务内容上开启自动模式如需额外安全网可结合permission.rules配置允许/拒绝/询问规则见 configSection.ts与dangerousCommandGuard默认开启环境变量KIMI_CODE_DANGEROUS_COMMAND_GUARDconfigSection.ts定制边界——但注意 auto 模式会跳过危险命令策略规则兜底需要在模式层之外生效。提醒开关默认开启的提醒注入可在KIMI_CODE_PERMISSION_MODE_REMINDER0下关闭但保留提醒有助于模型在长会话、压缩恢复后不丢失当前处于自动模式的上下文。计划审批认知auto 模式下ExitPlanMode的自动获批绝不等于用户批准执行Agent 应严格依据用户原始指令推进避免越权执行用户明确要求暂停/等待的任务。参考文件索引进入提醒原文permission-mode-auto-enter-reminder.md退出提醒原文permission-mode-auto-exit-reminder.md注入实现permissionModeInjection.ts模式服务与装配permissionModeService.ts、permissionMode.ts、permissionModeOps.ts默认模式配置节configSection.ts权限策略链permissionPolicyService.ts、auto-mode-approve.ts、auto-mode-ask-user-question-deny.ts、dangerous-command-ask.ts、default-tool-approve.ts上下文注入框架reminderService.ts、types.ts、systemReminder.ts测试契约permissionMode.test.ts、permissionPolicyService.test.ts赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Codewhale Auto-Review 全自动权限审查机制解析与 Claude Code / Kimi Code 的 Auto 模式对齐设计Codewhale Auto Review 全自动权限审查机制解析与 Claude Code / Kimi Code 的 Auto 模式对齐设计 本篇以仓库内人工智能AI Agent代码智能体CLI工具调用MCP ClientsOpenChamber 权限自动放行Permission Auto-Accept跨端权威策略运行时与安全网机制深度解析OpenChamber 权限自动放行Permission Auto Accept跨端权威策略运行时与安全网机制深度解析 导读 权限自动放行PermissAI Agent人工智能代码智能体交互助手Anarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发Anarlog 桌面版本发布全流程从 Nightly 候选验证到 Stable 稳定版发布与多平台分发 本文以 Anarlog 仓库中的发布技能清单 .cuAI Agent代码智能体人工智能大模型CLI上一篇洛雪音乐播放异常修复高效解决方案下一篇从根源解决音乐播放异常3个维度的系统排查指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
