工具确认与权限展示

四种权限姿态

客户端通过 session/set_mode 或 aster/permission_posture 修改。后者还能传显式 deny。严格使用闭集值；不能根据按钮文案或模型文字猜 modeId。asterTurn.planFirst 只限制本轮计划行为，不改掉存储的权限模式。

架构图一次工具确认的往返图示描述需要人工确认的调用。批准绑定原请求，原权限与沙箱约束仍成立；超时与断线不会产生批准。

代理通过 ACP request_permission 请求用户选择。每项保留 sessionId、toolCallId、工具名、参数和风险原因。返回代理提供的 optionId，不要合成另一个“等价”选项。

通常包含 allow-once 与 reject-once；只有可学习的 Bash 规则才提供 allow-always。界面应明确后者是在当前工作区保存具体规则，不是对所有未来命令无限授权。复杂命令不应通过截取首词来扩大许可。

示例响应形状如下，id 必须取原请求的 id：

{"jsonrpc":"2.0","id":41,"result":{"outcome":{"outcome":"selected","optionId":"allow-once"}}}

用户关闭面板、超时或断线不是批准。多项确认各自按 ID 处理；旧面板的点击不能发送给新请求。

业务问题也可能借用 permission 通道，但 _meta.question 标记了 allowFreeText、hasChoices；这类请求收集答案，不是授予工具执行权。用户输入应绑定原 question_id。

aster/form/request 是代理发给客户端的扩展请求，用于结构化表单。正常响应包含 values 对象；outcome 为 cancel 或 decline 时视为用户取消。未知字段、空值和校验失败按表单合同处理，不用默认答案替用户提交。

客户端应区分三种控件：批准工具、回答业务问题、运行中追加指令。不要因为它们都可能弹出面板，就让“同意”走同一段执行逻辑。

业务回答走 request_question_answer L209 ↗，可与上面的工具确认入口对照阅读。

MCP 服务可能请求借用宿主模型生成内容。代理以每服务上限包住 ApprovalGated sampling，先核对服务、会话和请求，再通过同意桥处理。工具调用批准不自动批准后续 sampling。

同意通道或可用模型缺失时 sampling 保持拒绝；不能悄悄使用默认凭据。客户端要展示这是服务申请模型调用，避免误导成普通工具读操作。

逐项测试四种姿态、显式 deny、一次性批准、可学习规则、取消问题、自由文本和多项并行确认。确认拒绝时工具确实未执行，回答表单不会改变权限，旧请求不能批准新调用。