收件箱与审批
了解全局收件箱、审批请求、权限请求，以及它们与好友的区别。
Kaiwu 配备了全局收件箱。
收件箱用于汇总展示需要你关注的事项，即便这些事项来自产品的不同模块。
收件箱
收件箱是以下事项的处理中心：
- 审批请求
- 待处理的权限请求
- 好友相关的新待办事项
- 共享会话的动态
- 更新类通知事项
当你需要了解**“当前有哪些事项需要我处理？”**时，即可使用收件箱。
审批请求
对于不应立即执行的操作，审批请求充当了面向用户的审核层。
Kaiwu 不会直接执行这类操作，而是生成审批请求供你先行审阅。
这对于以下操作尤为重要：
- Agent 提议的提示词更新
- 文件系统写入或安装
- 外部资产导出
- 其他专门配置走审批队列的操作
审批请求的组成
审批请求包含以下内容：
- 请求执行的操作
- 该操作的参数
- 简要摘要
- 可选的预览信息，如目标路径或修改计划
- 当前状态
其状态包含：
- 待处理（open）
- 已批准（approved）
- 已拒绝（rejected）
- 已执行（executed）
- 失败（failed）
为什么 Kaiwu 采用审批机制
这为你带来：
- 敏感操作执行前的审核关卡
- 请求内容的持久化记录
- 一套不仅限于提示词功能、可全场景复用的统一模型
审批系统特意设计为基于 ActionSpec 驱动，这意味着该机制具备通用性，而非仅针对提示词或技能做硬编码。
分界面审批关卡
任何操作均可配置为在特定界面上需要审批。
示例：
- 在 App 内直接允许
session.title.set，但在 CLI 中需要审批 - 为会话 Agent 允许
session.stop，但来自外部 MCP 主机时需要审批 - 在某一界面上完全禁用某操作，同时在另一界面上保持可用
- 内置的界面别名同样需要审批，例如 CLI
set-title/ MCPsession_title_set，因为它们最终解析到同一底层操作策略
在设置 → 操作中，Kaiwu 将这些规则存储为按操作、按界面的策略。
这意味着审批并非针对特定操作的一次性硬编码逻辑。 同一套通用审批流程可跨以下场景复用：
- App 按钮
- CLI 会话控制
- 会话 Agent 工具
- 外部 MCP 主机
- 适用的语音驱动操作
权限请求
权限与审批彼此相关，但并非同一概念。
权限请求
权限请求通常用于确认当前会话或 Agent 是否可以使用某个工具，或执行类似工具的操作。
示例：
- 允许执行某条命令
- 允许写入文件
- 允许某种工具调用模式
这类请求关注的是运行时工具访问权限。
用户操作请求
某些请求既非单纯的工具权限，亦非通用的审批队列项。
Kaiwu 还会向用户呈现用户操作请求——当 Agent 需要人类提供结构化回复才能继续执行时，便会触发此类请求。
常见示例：
- AskUserQuestion
- Exit Plan Mode
- 需要批准、拒绝、修改或明确答复的提供商专属请求
这些请求通过统一的通用响应模型处理，无需为每种请求类型单独定制一次性按钮。
如何处理用户操作请求
视具体请求而定，Kaiwu 可能会要求你：
- 批准
- 拒绝
- 请求修改
- 回答一个或多个结构化问题
- 选择提供商专属的审批变体（若存在）
正因如此，Exit Plan Mode 与 AskUserQuestion 即便不是同一种工具，也可以作为面向用户的请求一并呈现。
示例：计划审核流程
当提供商支持计划模式时，常见的用户操作流程如下：
- Agent 提出计划
- Kaiwu 显示 Exit Plan Mode 请求
- 你可以：
- Approve Plan
- Request changes
- 从计划菜单中选择提供商专属的审批变体
以 Claude 为例，审批变体可包括：
- Approve Plan：退出计划模式并正常继续
- Approve Plan (Accept Edits)：退出计划模式，并以更宽松的编辑权限模式继续
- Approve Plan (Bypass All Permissions)：退出计划模式，并以放行一切权限的模式继续
如果选择 Request changes，会话将保持在计划模式，Claude 将修改计划而非直接开始执行。
用户操作请求的呈现位置
用户操作请求可出现在：
- 会话记录中
- 审批/请求详情界面中
- 语音对话中，此时语音 Agent 可以呈现选项并代你提交结构化答复
- 推送通知中，点击即可直接返回需要答复的具体会话
请求通知
启用对应的通知类型后，权限请求和用户操作请求也可以通过推送通知呈现。
当前的移动端交互表现：
- 权限请求可显示
Allow和Deny - 用户操作请求可显示
Answer - 点击通知本身会直接打开对应会话
这些操作按钮旨在提供快速返回路径，而非完整的应用外审批界面：
Allow/Deny会打开 App，在目标服务器已被设备信任的前提下发送权限响应，随后进入会话Answer会打开 App 并定位到对应会话，以便你在上下文中作答
通知中还会包含该工具或请求的简要摘要，使你在进入 App 前便已知晓意图。
权限请求与用户操作请求的区别
在当前的 Kaiwu 版本中，这一区分尤为关键：
- 权限请求 = “是否应允许该工具/操作执行？”
- 用户操作请求 = “Agent 需要人类给出结构化决策或答复，方可继续运行”
两者都会阻塞会话。 两者都能显示在会话记录中或通过通知送达。 但系统在设计上特意将其作为不同的请求类型进行跟踪与渲染。
审批请求
审批请求关注的是通过 Kaiwu 的操作体系执行更高层级的操作。
示例：
- 批准提示词更新提议
- 批准外部资产的导出或安装
- 批准 CLI 或外部 MCP 请求的会话控制操作
这关乎操作执行，而不仅是工具的访问权限。
审批在实践中的运作方式
标准流程如下：
- 某方发起操作提议
- Kaiwu 创建审批请求
- 请求出现在收件箱中
- 你打开该请求并审阅摘要与详情
- 你选择批准或拒绝
- 若批准，Kaiwu 将执行底层操作并记录结果
这为整个产品提供了统一的审核模型，避免了各自为政的一次性确认弹窗。
提示词与技能示例
收件箱中可能出现的提示词相关操作示例：
- Agent 提议修改已保存的提示词
- 某技能的安装或导出需要审批
- 针对文件系统提示词资产的修改进入队列等待审核
正因如此，提示词/技能功能体系与收件箱功能体系紧密相关。
用户须知
收件箱事项特意采用混合汇聚
收件箱不仅服务于提示词。它的定位是贯穿各产品模块的统一待办队列。
审批请求具备持久性
由于审批以真实数据形式存储，在常规的界面跳转中不会丢失，你完全可以稍后审阅，而不会像临时弹窗那样直接关闭消失。
常见工作流
审核提示词相关审批
- 打开收件箱
- 找到对应的审批请求
- 打开该事项
- 审阅摘要与预览信息
- 选择批准或拒绝
处理权限提示
- 若请求已显示在收件箱中，将其打开
- 审阅 Agent 或工具请求执行的具体操作
- 根据你对该会话的授权要求，选择批准或拒绝
- 若 Kaiwu 提供了带作用域的“不再询问”选项，且你希望该会话后续不再对相同工具或命令模式重复提示，可选择该项
回复 AskUserQuestion 或 Exit Plan Mode 请求
- 在会话记录、详情视图或收件箱中打开呈现的请求
- 审阅所提问题或请求的操作
- 批准、拒绝、请求修改、选择计划审批变体，或直接回答问题
- Kaiwu 将通过通用的用户操作响应路径回传该答复
好友单独管理
- 打开好友
- 在该模块中查看好友申请、好友关系或搜索用户
- 仅在收件箱中处理跨功能的关注事项