Approval zh

审批

上游用户审批子系统在 Edge 中的适配。

上游参考：Approval

上游提供了什么

审批子系统（ctx.approval）在工具执行前要求用户明确同意。它以失败关闭模型回答"这个操作能否继续"：

• ApprovalService — 通过组合的应答器（UI 通道用于人工输入，ACP 桥接用于自动化）分发审批请求。
• 四种结果 — allowed-once（允许）、rejected（拒绝）、cancelled（撤回）、unavailable（无应答器）。只有 allowed-once 允许操作。
• 会话策略 — 'ask'（默认，委托给应答器）或 'never'（拒绝所有，用于无头/CI 环境）。策略作为 approval/policy 会话事件持久化。
• 审计轨迹 — 会话日志中的 approval/asked 和 approval/decided 事件，对模型不可见。

当前 Edge 状态

未实现 审批子系统未安装。无 dsh-user-approval 依赖，无 ctx.approval 服务，客户端 bundle 中无审批 UI。

实际效果：所有工具调用无需用户确认即执行。模型可以读写编辑文件、运行 bash 命令、创建目标，无需事先询问用户。这与上游的 'never' 策略行为相同——但没有切换到 'ask' 的选项。

为什么缺失：Edge 的单用户部署模型（每个 DO 一个 owner）意味着每个工具调用都被启动会话的人隐式授权。在这种场景下审批门控增加摩擦但不增加安全性——用户既是请求者也是批准者。

Cloudflare 支持能力

如果需要审批（如共享部署、多用户场景）：

• WebSocket 应答器 — 现有的 mux/host 下行链路可以承载审批请求/响应帧，使用客户端连接协议已定义的 approval/requested 和 approval/responded 帧类型。
• 计划：所有计划均可用。不需要额外的 Cloudflare 产品——它是现有 WebSocket 传输上的 UI 交互层。

架构总结

组件	状态	备注
ApprovalService	未安装	所有工具无需确认即执行
审批 UI	未包含	客户端应答器未组装
审计事件	未记录	会话日志中无 approval 事件

关键观察：审批是有意缺失的，不是意外遗漏。Edge 的单 owner 模型使其多余——owner 通过使用系统隐式批准所有操作。如果共享或多用户部署成为目标，这个子系统将是首先安装的。

TODO

**评估共享部署的审批需求。**如果 Edge 支持多用户或共享工作区场景，应安装审批子系统。需要评估上游插件的 inject 要求和 WebSocket 应答器传输。客户端审批 UI 可能需要加入组装的 bundle。