feat: 工具权限新增智能审批档位，由审批模型自动决定工具调用 - #914
Conversation
bd72ed6 to
f6d04ea
Compare
|
我感觉这个不错 早想加了 但是最好做一下本地验证 给一下截图什么的 如果可以的话 最好可以把审批的模型加到模型配置设置中 |
|
噢 抱歉 看到了 已经有了 你做下本地验证及截图查看效果就行 |
PermissionLevel 新增 LLM 档位: 命中时读取可编辑的审批提示词模板
(支持 {tool_name}/{tool_parameters} 占位符), 附加系统固定的 JSON
输出约束, 经 FunctionType.TOOL_APPROVAL 绑定的模型发起一次非流式
请求, decision 为 approve 放行、deny 拒绝; 接口异常、输出无法解析
或 decision 缺失时转交现有询问弹窗由用户确认。
- FunctionType 新增 TOOL_APPROVAL, 默认映射与回退逻辑自动覆盖,
功能模型配置页补充名称与描述
- 工具权限设置页新增智能审批分组卡片与提示词模板编辑卡片
- ClassicChatSettingsBar / AgentChatInputSection 权限标签补齐 LLM 分支
- 新增文案提供中文与英文资源; 旧存储值解析行为不变
- 按协作规范添加 docs/TODO/llm_tool_approval_20260810
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
f6d04ea to
42d2d2c
Compare
|
请过目： |
附：正常工具审批通过： |
CATMIAOZHI
left a comment
CATMIAOZHI
left a comment
There was a problem hiding this comment.
审查基线：42d2d2c5（feat/llm-auto-approval-permission @ main，单 commit）
整体方向我认可，fail-closed 的回退设计（API 错误 / 输出无法解析 / decision 缺失都转人工而非放行）也与 #697 的思路一致。但结合 #697 之前讨论的 Auto-review 设计，以及我已经在 CATMIAOZHI/Operit 中实际实现并使用的 Guardian / permission reviewer 来看，当前版本还不适合合并。
TL;DR：3 个 P1（同消息注入、无授权上下文、无拒绝循环保护）建议先解决再合并；P2 与 proxy 注意点不阻塞，仅作演进提醒。
我的实现可以直接作为参考：https://github.com/CATMIAOZHI/Operit
我的 Guardian 最初也是沿着 #697 的思路继续实现的。实际做下来，我认为自动审批不能只是在权限分支里增加一次普通 LLM JSON 请求，因为 reviewer 本身已经成为权限安全边界，需要额外处理 prompt 隔离、用户授权上下文、结构化结果、并发、失败回退和拒绝绕过等问题。
详细问题见行内评论（3 个 P1 + 1 个 P2）。另外两个非阻塞点：
-
proxy/package context binding：当前 PR 的调用路径（
checkToolPermission(permissionTool, invocation.rawText)→ 执行同一 invocation）是"审核即执行"，没有问题。但后续如果引入 host 在审核后注入/替换参数，审批就会失效——审核的是一组参数，执行的却是另一组。建议把"reviewer 看到的 action 必须与最终执行的 action 完全一致"作为后续演进的硬约束（我的实现为此专门在 review 前先绑定 host-controlled proxy context）。 -
风险面提醒：Operit 是手机端 agent，在 root 权限下破坏性很大——一旦遭遇提示词注入，恶意文件或命令可能造成不可逆后果（清除用户数据、外发凭据、篡改系统设置等）。基于这个风险面，我倾向于这个功能不只是本 PR 的实现取舍，而需要开发组层面讨论清楚审批边界、默认策略和 fail-closed 语义后再决定合并。
所以我的建议不是否定这个功能，而是当前实现还把 Auto-review 当成 PermissionLevel -> 调一次 LLM -> 解析 JSON；#697 描述、且我实际验证可行的模型更接近 Permission system -> isolated reviewer subagent -> canonical action + authorization context -> capability-bound structured submission -> host enforcement -> audit / circuit breaker。如果这个 PR 要继续推进，可以直接参考我仓库现有 Guardian 的实现思路，未必需要完整照搬，但至少应先解决 3 个 P1 再考虑合并。
|
@Aizosa 我建议你先放缓一下，我们这边需要对这个功能进行安全性可行性评估 |
已根据审阅意见完成安全架构调整，最新提交为 主要修改：
验证结果：
麻烦基于最新提交重新审阅。Workflow 当前仍等待上游维护者批准运行。 |
AAswordman
left a comment
AAswordman
left a comment
There was a problem hiding this comment.
Request changes pending a clean candidate. The latest commits materially address the earlier reviewer-isolation, authorization-context, structured-result, and circuit-breaker concerns: policy and evidence are now separate prompt turns, host enforcement rejects critical/unauthorized cases, and the per-turn breaker is tested.\n\nHowever, Candidate checks currently fail at the initial Plan candidate checks step, so no hygiene, compilation, or unit-test stage ran for the latest merge candidate. Rebase/update the branch as needed and resolve the plan failure so Candidate checks runs successfully before this security-sensitive feature is reconsidered.
4 participants
Changes
工具权限新增第四档「智能审批」（LLM）
PermissionLevel新增LLM档位：命中时由审批模型阅读工具名称与参数后自动决定允许或拒绝；fromString对旧存储值的解析行为不变，未知值仍回到ASKFunctionalPrompts统一维护（TOOL_APPROVAL_PROMPT/_CN中英双语，沿用现有功能提示词的组织与文风），JSON 输出约束并入提示词正文，不对用户开放编辑；提示词末尾直接附上本次工具调用原文<tool name="..."><param name="...">...</param></tool>FunctionType.TOOL_APPROVAL绑定的模型发起一次非流式请求，复用 GREP 功能既有的调用与 JSON 提取模式approve放行、deny拒绝、ask表示模型无法自主判断转人工；接口异常、输出无法解析或decision缺失/非法时同样转交现有询问弹窗由用户确认（该转交是本功能的产品设计，超时行为与 ASK 档一致）The system has rejected this tool execution: <reason>. Either revise the parameters per the rejection reason and try again, or abort this tool invocation entirely.；用户手动拒绝的文案保持原样，两处调用点（ToolExecutionManager 与 package_proxy）行为一致FunctionType新增TOOL_APPROVAL：默认映射与未映射回退逻辑自动覆盖，无需迁移；功能模型配置页补充显示名称与描述，用户可为审批绑定独立的低成本模型ClassicChatSettingsBar与AgentChatInputSection的权限标签 when 补齐LLM分支docs/TODO/llm_tool_approval_20260810/（index + 两个步骤文档）Verification
PermissionLevel/FunctionType的穷尽 when，均已补齐分支；其余命中均为无关的AndroidPermissionLevel🤖 Generated with Claude Code