人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载Kun 的 Rooms房间功能为私聊 Agent 会话提供了一套完整的工具审批与权限控制体系用户在私聊输入框中看到紧凑的审批卡片点击后进入独立的沙箱化 Electron 确认窗口而会话的三种权限模式Ask for approval / Approve for me / Full access则决定工具调用是否需要人工批准、由谁审查以及沙箱边界。本文以 docs/rooms-approvals.md 为核心骨架结合kun/src下的路由、契约与审批门实现以及scripts中的桌面端冒烟场景逐层拆解这条从卡片展示 → 沙箱确认 → 权限落库的安全链路。一、审批卡片紧凑、可读、多语言适配的展示层在私聊会话中Agent 请求执行某个工具如写文件、跑命令、调 MCP时Rooms 会渲染一张紧凑的审批卡片卡片上呈现三类核心信息待处理的动作pending actionAgent 想要执行什么工具tool调用的是哪个工具如文件写入、命令执行工作目录working directory动作将作用于哪个目录。卡片上的命令与文件内容保持完整可读当内容过长时长文本在卡片内部滚动而不是截断或溢出。从源码看审批请求的数据结构由 kun/src/domain/approval.ts 中的ApprovalRequest定义包含id、threadId、turnId、toolName、summary以及可选的action动作封套status取值pending | allowed | denied | expiredcreateApprovalRequest以pending初始状态创建记录。这张卡片就是pending状态在 UI 上的可视化呈现。卡片在布局上参考了中性风格的确认卡片设计但需要强调的是Kun 并没有照搬外部产品的工具审批协议审批协议本身是本仓库独立实现的见下文审批门与确认边界。界面语言与主题层面卡片支持英文、中文、浅色、深色以及窄窗口布局——冒烟场景中专门验证了中文深色主题与 760px 窄窗口下的渲染scripts/smoke-room-approvals.cjs。二、确认边界沙箱化的 Electron 确认窗口审批卡片只是入口真正的放行/拒绝决策发生在一个独立的沙箱化 Electron 窗口中。这是整条链路中安全设计最重的部分内容来源唯一化用户点击Review and allow或Deny后主进程Main从 Runtime 获取待处理的动作pending action确认窗口展示的是这份权威内容canonical content而不是渲染进程传来的任意文本。窗口隔离受保护窗口具有独立的会话isolated session、极简的 preload、没有 workbench 桥接、不加载任何扩展脚本。以数据方式渲染动作文本动作文本只作为数据渲染不会被当作可执行内容处理窗口只接受来自自身主框架main frame的可信按钮激活。从实现看主进程侧对确认的权威读取接口是GET /v1/approvals/:id该路由在 kun/src/server/routes/register-thread-routes.ts 中注册从runtime.approvalGate.get(id)读取审批记录并附带线程标题返回而它不在通用渲染进程路径的允许清单allowlist上——也就是说常规渲染进程的 HTTP 请求无法直接读到审批详情。冒烟场景 scripts/smoke-room-approvals.cjs 对这条边界做了非常具体的验证确认窗口内window.kunGui不存在assert(!await consent.evaluate(() Boolean(window.kunGui)))证明 workbench 桥接被移除确认窗口内存在window.kunProtectedRoom?.confirm函数但脚本化地直接调用document.getElementById(confirm).click()无法确认审批等待 120ms 后审批仍为 pending只有点击Allow once按钮并等待窗口关闭审批才真正放行。这印证了文档中只接受可信按钮激活的设计窗口内容不可被脚本伪造决策必须经由真实用户交互。审批令牌短生命周期、单次使用、绑定精确动作短生命周期的审批令牌approval token将精确的动作与决策绑定在一起。实现位于 kun/src/server/approval-consent.ts令牌格式为v1.expiresAt.nonce.signature签名由HMAC-SHA256基于runtimeToken生成生命周期上限MAX_APPROVAL_CONSENT_LIFETIME_MS 60_00060 秒单次使用ApprovalConsentVerifier内部维护已用令牌摘要表同一令牌重复提交直接返回失败表满时拒绝而非驱逐未过期条目fail closed防止高并发下旧令牌可重放签名校验使用timingSafeEqual防止时序侧信道。其关键行为语义为关闭或取消确认窗口→ 待处理的审批保持原样pending 不变动作已过期→ 确认窗口关闭审批视为失效主进程拒绝渲染进程伪造自动策略放行的请求→ 自动审查automatic review只能由 Runtime 持有渲染进程不可冒充原有的手动确认展示manual confirmation presentation代码保持不变。对应地POST /v1/approvals/:id路由register-thread-routes.ts在决定审批时要求提供x-kun-approval-consent头中的同意令牌未通过校验则返回 403见 kun/src/server/routes/approvals.ts 中decideApproval的ERRORS.forbidden(protected approval consent required)。底层审批门接口定义在 kun/src/ports/approval-gate.ts其reserveDecision / commitDecision / rollbackDecision语义确保先持久化approval_resolved审计事件再放行循环执行被允许的工具审计持久化失败则回滚决策审批回到 pending。三、Composer 权限模式三种模式与底层策略轴的映射私聊 composer 复用 Code 的权限选择器permission picker与预设定义。三种模式与底层策略轴的对应关系如下模式审批策略 (approvalPolicy)沙箱模式 (sandboxMode)审查者 (approvalReviewer)Ask for approval请求批准on-requestworkspace-writeuser用户Approve for me替我批准on-requestworkspace-writeagentAgent 自动审查Full access完全访问autodanger-full-accessuser用户这一映射由 kun/src/contracts/policy.ts 中的kunToolPermissionModeSettings精确实现三种模式恰好对应三组完整快照KUN_TOOL_PERMISSION_MODES [ask-for-approval, approve-for-me, full-access]。反向投影函数kunToolPermissionModeFromSettings则把任意合法的权威快照投影回三种模式词汇表自定义/旧版组合一律投影到受审的用户模式除非精确匹配某种规范模式确保仅渲染选择器永远不会把旧数据呈现为不受限状态调用方不得把投影结果持久化除非用户显式选择了该模式。从 kun/src/contracts/policy.ts 还可以看到策略轴approval policy / sandbox mode / reviewer与产品模式是分离的APPROVAL_POLICIES包含always / on-request / untrusted / never / auto / suggest六个原始值SANDBOX_MODES包含read-only / workspace-write / danger-full-access / external-sandboxAPPROVAL_REVIEWERS为user / agent——每个客户端写入的是同一份完整的权威快照同时不压缩原始兼容契约。模式选择的会话归属选择属于当前私聊会话不会改变全局 Code 设置或其他会话未配置的会话默认从Ask for approval开始切换模式需要受保护的确认即上一节的沙箱确认窗口随后通过 Manager store 持久化带修订号校验revision checks与幂等的请求标识idempotent request identity并发布既有的 room update 事件读取设置永远不会调用模型。从 kun/src/agents/agent-permissions.ts 的实现看setAgentPermissions以room-permission:roomId:clientRequestId为幂等键用roomFingerprint(input)校验请求是否中途被篡改指纹不一致抛RoomStoreConflictError(permission request changed)提交时通过checks校验期望修订号expectedRevision然后以room.updated事件广播变更并将privateExecutionPolicy写入房间记录、revision自增。四、已接受/排队请求的冻结策略与重试语义权限模式切换对正在进行的请求有严格的语义划分已接受accepted与排队queued的请求保持其冻结的策略frozen policy——它们不受模式切换影响新请求使用新的选择重试retry被视为一次新尝试使用当前已确认的策略与 Agent 限额但保留原始工作区未知执行unknown executions必须先被协调reconciled才能重试切换模式会重建不兼容的内部线程threads重建时从当前上下文纪元context epoch携带有界的引用历史bounded reference history。这份冻结策略 重试按当前策略执行的设计保证了模式切换过程中不会出现既有请求在新旧策略之间漂移的安全歧义。文档记录的验证覆盖了冻结权限、当前 Agent 上限ceilings、外部写入以及无效/重放的同意令牌等场景。五、Full access 模式边界与保留的限制Full access 会移除私聊会话默认的仅工作区workspace-only工具作用域但以下限制仍然强制生效Agent 只读预设read-only presets目录上限directory ceilings显式的工具、MCP 与技能skill限制。关键约束是带目录上限的 Agent 不能选择 Full access选择后若限额发生变化会在准入admission时重新检查。实现中kun/src/agents/agent-permissions.ts 的agentPermissions会计算fullAccessUnavailable当 Agent 预设toolPolicy readOnly时返回read_only_agent当allowedRepositoryRoots已定义即存在目录上限时返回agent_directory_limitssetAgentPermissions在请求full-access且fullAccessUnavailable存在时直接抛RoomStoreConflictError拒绝切换。此时 GET 端点返回的策略会降级为 ask-for-approvalUI 选择器上的 Full access 选项不可用。此外群组讨论group discussions对写操作与命令保持只读但文件读取工具可以检查用户点名的本地路径遗留任务执行legacy task execution仍被限制在**授权的任务检出目录authorized task checkout**内私聊选择器在**遗留任务草稿legacy task drafts**中隐藏。六、权限读取与变更的 HTTP 契约读取GET /v1/rooms/:roomId/direct/permissions返回当前房间的权限快照。路由实现在 kun/src/server/routes/register-room-permission-routes.ts返回结构为{ roomId: ..., revision: 0, policy: { approvalPolicy: on-request, sandboxMode: workspace-write, approvalReviewer: user }, mode: ask-for-approval, fullAccessUnavailable: null }mode由kunToolPermissionModeFromSettings(policy)投影得出fullAccessUnavailable取值read_only_agent、agent_directory_limits或undefined。注意该端点要求会话类型必须是user_agent私聊否则抛出Private conversation required。变更PUT /v1/rooms/:roomId/direct/permissions变更不能通过通用渲染进程 HTTP 请求完成——文档明确Generic renderer HTTP requests cannot PUT this setting。它必须通过专用的受保护 preload 方法发起携带签名的一次性同意令牌signed, one-use consent令牌绑定roomId clientRequestId expectedRevision mode四元组consent subject 实现在 kun/src/contracts/room-permissions.ts 的roomPermissionConsentSubject格式为room-permission-v1:JSON请求体符合 kun/src/contracts/room-permissions.ts 的RoomPermissionRequestSchemaclientRequestId1–128 字符、expectedRevision非负整数、mode三模式枚举且为严格对象.strict()。服务端在 register-room-permission-routes.ts 中先解析请求体再用ApprovalConsentVerifier.verifyAndConsume校验x-kun-approval-consent头失败返回403 Protected permission confirmation required成功后才在房间独占锁rooms.exclusive内执行setAgentPermissions。七、验证矩阵回归测试与真实桌面端冒烟文档记录了完整的验证结果Runtime 回归67 个套件 / 437 个测试通过最终的准入与重试改动额外通过 14 个定向测试覆盖冻结权限、当前 Agent 上限、外部写入、无效/重放同意令牌Renderer/Main 回归28 个套件 / 152 个测试通过最终受保护对话框与发送方检查通过 32 个定向测试类型检查、完整构建含 build:kun、lint 与 700 行门禁gate通过lint 报告 30 个既有警告、0 错误真实 Electron Manager Kun 队列验收使用隔离数据空间与离线模型夹具offline model fixture不调用真实模型即可完成权限/UI 验收覆盖UI 创建与发送、手动 allow 与 deny、拒绝合成的脚本激活、伪造的策略放行forged policy allow、自动审查、真实 full-access 外部文件创建、取消变更、全局设置保持不变、持久化、中文深色模式与 760px 窗口。运行桌面验收场景构建完成后运行以下命令文档原样给出的命令KUN_APPROVAL_EVIDENCE/absolute/evidence/path \ node scripts/smoke-development-direct-chat.cjs --approvals \ --evidence /absolute/evidence/path要点--approvals开关让场景进入房间审批专项流程scripts/smoke-development-direct-chat.cjs 会加载 scripts/smoke-room-approvals.cjs 的exerciseRoomApprovals证据目录evidence必须放在一次性工作树disposable worktrees之外避免被清理场景会输出一份 JSON 结果报告report.json与多张截图内联审批卡片approval-inline-card、受保护确认窗口kun-protected-approval.png、三种权限模式kun-permission-*.png、中文深色模式审批kun-protected-approval-zh-dark.png、窄窗口 composerapproval-narrow-composer等。冒烟场景断言的价值在于它同时覆盖了安全边界与功能正确性window.kunGui.resolveKunApproval伪造策略放行必须抛错、脚本化点击confirm不得生效、deny 后目标文件必须不存在、房间内切换到 full-access 后外部目录文件确实能被创建、全局权限设置前后必须一致assert.deepEqual(await globalPolicy(), before)以及刷新页面后权限模式必须持久化。八、总结Kun 的房间审批体系是一条展示层 → 确认层 → 持久化层层层收紧的信任链内联卡片只负责可读呈现真正的决策发生在无桥接、无扩展、仅接受主框架按钮激活的沙箱窗口每次变更都必须携带短生命周期、单次使用、绑定精确语义的 HMAC 同意令牌并经修订号校验与幂等键落库到 Manager store而三种权限模式只是同一套底层策略轴审批策略、沙箱模式、审查者上的产品化预设。理解这条链路就能在私聊 Agent 场景中安全地配置谁可以批准、以多大沙箱权限执行、如何回滚与重试同时确保权限变更既不污染全局设置也不会被渲染进程或脚本冒充。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐AionUi ACP 单聊权限与安全机制全解析审批卡片、YOLO 免确认模式与待确认恢复AionUi ACP 单聊权限与安全机制全解析审批卡片、YOLO 免确认模式与待确认恢复 本文基于 docs/prds/conversations/acp/p人工智能AI 应用AI Agent交互助手桌面应用移动开发AionUi ACP 单聊权限与安全机制全解析权限审批、待确认队列与 YOLO 免确认模式实战AionUi ACP 单聊权限与安全机制全解析权限审批、待确认队列与 YOLO 免确认模式实战 AionUi 作为面向 OpenClaw、Hermes、Cla人工智能AI 应用大模型AI Agent交互助手前端App Store Connect CLI 的 asc auth logout 确认机制迁移从 4.x 兼容窗口到 5.0 强制确认App Store Connect CLI 的 asc auth logout 确认机制迁移从 4.x 兼容窗口到 5.0 强制确认 本篇技术指南聚焦 App上一篇compact_str vs String基准测试揭示惊人性能差异附完整代码下一篇10倍提升标注效率LabelImg预定义类别与智能补全实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考