ToolKind 提供默认只读语义
从枚举与 is_read_only() 追踪只读默认值和能力过滤边界
本页解决的问题
先给结论「ToolKind 提供默认只读语义」要解决的关键问题是什么？
从枚举与 is_read_only() 追踪只读默认值和能力过滤边界
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
ToolKind 分支，记住 Task 返回 false、源码中没有 TaskOutput 这个 kind，并能解释只读分类与完整权限决策的边界。
is_read_only() == true
这些 kind 的种类默认值为只读。具体工具仍可通过自己的元数据覆盖默认结果。
is_read_only() == false
此处还包含后台任务、媒体生成、部署等种类。Task 明确位于 false 分支。
is_read_only 描述默认副作用语义，不能单独推出「自动执行」或「必须弹窗」。命令规则、工作区权限、沙箱、Hook 与用户批准都会影响最终结果。显示层中 Execute 的标签是 Run Command。pub fn presentation_name(self) -> &'static str {
match self {
ToolKind::Execute => "Run Command",
/* 其他 presentation_name 分支省略 */
}
}
pub fn is_read_only(self) -> bool {
match self {
ToolKind::Read
| ToolKind::Search
| ToolKind::Lsp
| ToolKind::ListDir
| ToolKind::List
| ToolKind::MemorySearch
| ToolKind::MemoryGet
| ToolKind::WebSearch
| ToolKind::WebFetch
| ToolKind::EnterPlan
| ToolKind::ExitPlan
| ToolKind::AskUser => true,
ToolKind::Edit
| ToolKind::Delete
| ToolKind::Write
| ToolKind::Move
| ToolKind::Execute
| ToolKind::Plan
| ToolKind::BackgroundTaskAction
| ToolKind::WaitTasksAction
| ToolKind::KillTaskAction
| ToolKind::Skill
| ToolKind::Task
| ToolKind::ImageGen
| ToolKind::VideoGen
| ToolKind::ImageToVideo
| ToolKind::ReferenceToVideo
| ToolKind::DeployApp
| ToolKind::SearchTool
| ToolKind::UseTool
| ToolKind::Monitor
| ToolKind::GoalUpdate
| ToolKind::Other => false,
}
}grok-build-main 的 crates/codegen/xai-grok-tools/src/types/tool.rs 与 tool_taxonomy.rs，核对日期 2026-07-17。节选中的注释明确标出了省略范围。判断分类，再补齐权限上下文
分别分析 Task、Execute、WebFetch。先写出 kind 默认只读值与显示标签，再列出最终执行前还需要检查的四类控制信号。
ToolKind::is_read_only() 给出可复用的种类默认值。Task 为 false，源码没有 TaskOutput kind，Execute 的统一标签为 Run Command。完整权限判断需要继续读取运行环境与用户控制信号。
「核心视觉 · 教学化决策图」里的风险边界在哪里
「这些 kind 的种类默认值为只读。具体工具仍可通过自己的元数据覆盖默认结果」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「此处还包含后台任务、媒体生成、部署等种类。」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
安全设计必须包含失败和恢复
结合「分别分析 Task 、 Execute 、 WebFetch 。先写出 kind 默认只读值与显示标签，再列出最终执行前还需要检查的四类控制信号」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「核心视觉 · 教学化决策图」走到「is_read_only() == true」
「核心视觉 · 教学化决策图」先把问题落在「ToolKind 语义分类 is_read_only() 种类默认值 工具级覆盖 ToolMetadata 环境控制 规则 · 沙箱 · Hook 用户控制 交互批准 最终执行决策 允许 · 拒绝 · 询问 教学化决策图：表达多层控制关系，不代表单一函数调用链」上；到了「is_read_only() == true」，讨论继续推进到「这些 kind 的种类默认值为只读。具体工具仍可通过自己的元数据覆盖默认结果」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「核心视觉 · 教学化决策图」：ToolKind 语义分类 is_read_only() 种类默认值 工具级覆盖 ToolMetadata 环境控制 规则 · 沙箱 · Hook 用户控制 交互批准 最终执行决策 允许 · 拒绝 · 询问 教学化决策图：表达多层控制关系，不代表单一函数调用链
- 「is_read_only() == true」：这些 kind 的种类默认值为只读。具体工具仍可通过自己的元数据覆盖默认结果
- 「判断分类，再补齐权限上下文」：分别分析 Task 、 Execute 、 WebFetch 。先写出 kind 默认只读值与显示标签，再列出最终执行前还需要检查的四类控制信号
最后的「判断分类，再补齐权限上下文」把讨论落到「分别分析 Task 、 Execute 、 WebFetch 。先写出 kind 默认只读值与显示标签，再列出最终执行前还需要检查的四类控制信号」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。