30 工具背后的秘密工具系统注册、调度与沙箱安全《Claude Code 架构解密》读书笔记 · 第05篇对应章节第4章 — 工具系统Agent 的手脚p.94-111导语一个最简单的工具调用switch-case 加几个函数就能搞定。但 Claude Code 的工具系统为什么需要四层架构、九步管线、三层取消控制器、七层 Shell 防御因为当 LLM 可以执行rm -rf /、并发修改文件、随时被 CtrlC 中断时简单就是最大的危险。本篇拆解 Claude Code 如何用 Fail-Closed 哲学在赋予 Agent 最大自主权的同时守住安全底线。一、架构图解工具系统的四层纵队Claude Code 用四层架构回应工具系统的五大挑战安全性、并发性、可中断性、可扩展性、可观测性┌─────────────────────────────────────────────────────┐ │ Layer 3: 查询引擎 (QueryEngine / query.ts) │ │ → 从 LLM 响应中提取 tool_use 块驱动执行 │ ├─────────────────────────────────────────────────────┤ │ Layer 2: 执行编排 (StreamingToolExecutor) │ │ → 并发控制、分区策略、错误级联、流式响应 │ ├─────────────────────────────────────────────────────┤ │ Layer 1: 单工具执行 (toolExecution.ts) │ │ → 输入验证 → Hook → 权限决策 → call() → 后置 Hook │ ├─────────────────────────────────────────────────────┤ │ Layer 0: 工具注册表 (tools.ts Tool.ts) │ │ → 工具发现、过滤、合并、排序 │ └─────────────────────────────────────────────────────┘自底向上注册表提供有哪些工具单工具执行管怎么安全地跑一个编排层管多个工具怎么协调查询引擎管何时调用。二、核心点拆解2.1 六大分类与工具描述即 Prompt30 内置工具按安全级别分为六大类类别安全级别代表工具设计直觉文件操作需确认(写)/自动(读)Read、Write、Edit、NotebookEdit核心生产力Edit 有 read-before-write搜索与发现自动放行Grep、Glob、Bash(find)只读、并发安全Shell 执行需确认Bash、TaskStart、TaskStop最大攻击面七层防御Agent 协作需确认Agent(子Agent)、TeamCreate跨进程隔离外部集成需确认WebFetch、WebSearch、MCP网络出站SSRF 防护辅助工具自动放行TodoWrite、AskUserQuestion纯状态无副作用关键洞察安全级别与工具的副作用范围正相关。只读工具默认放行写入工具需要确认跨边界工具需要最严格审查。注册表的isReadonly、isDestructive、isConcurrencySafe三个布尔标记正是这种分类的形式化表达。工具描述即 PromptBashTool 的 description 里写明不要用 Bash 来 grep/find/cat引导 LLM 优先使用专用工具——这不是技术约束而是 Prompt 引导。描述的措辞影响工具选择描述的长度影响 Prompt Cache 经济性描述的稳定性影响缓存命中率。软约束Prompt 引导与硬约束权限检查互补形成软硬结合的控制策略。2.2 Fail-Closed 注册表编译期锁死安全注册表的核心是ToolInput, Output, Progress泛型接口和buildTool函数。设计哲学体现在默认值选择constTOOL_DEFAULTS{isEnabled:()true,isConcurrencySafe:()false,// 保守假设不安全isReadonly:()false,// 保守假设会写入isDestructive:()false,checkPermissions:allow,}Fail-Closed 的不对称代价一次误判安全可能导致数据丢失一次误判危险最多让用户多点一次确认。系统选择宁杀勿放。编译期类型体操buildTool的返回类型通过 TypeScript 条件类型和映射类型自动填充默认值——调用方不需要任何运行时 null 检查。把运行时的防御转移到编译期的约束这是 TypeScript 类型系统的优雅应用。Prompt Cache 稳定性排序内置工具分区在前MCP 工具在后两组内部按名称排序。混排会导致 MCP 工具的动态插入/删除使所有下游缓存键失效浪费大量 token 费用。四维模式过滤Simple 模式仅保留 Bash/Read/EditREPL 模式隐藏原始工具强制走 REPLCoordinator 额外暴露 Agent/TaskStopDeny 规则让模型看不到已禁用工具。容错设计如果 REPLTool 被 deny 规则移除原始工具自动重新可见——过滤是减法但减到零时要兜底。2.3 九步执行管线一次工具调用的完整旅程当 LLM 返回tool_use块时toolExecution.ts中的runToolUse启动九步管线步骤操作设计亮点1findToolByName含别名回退“KillShell” → “TaskStop”向后兼容比 API 整洁更重要2Abort 检查用户中断流式 fallback3Zod Schema 验证safeParse失败返回 InputValidationError4工具自定义验证如 FileEditTool 的 read-before-write5Bash 分类器投机预检并行启动不阻塞主流程——乐观并行策略6输入回填~展开为绝对路径防 Hook 白名单绕过7PreToolUse Hooks可修改输入、返回权限决策8权限决策解析Hook → 规则 → canUseTool → 最终决策9tool.call() PostToolUse Hooks执行 结果映射步骤 5 的投机预检在用户审批权限弹窗期间并行启动 Bash 分类器。用户批准了结果已就绪用户拒绝了结果被丢弃。用少量计算资源换取可感知的延迟降低。步骤 6 的路径回填~/../../etc/passwd在回填前可以绕过基于路径的白名单规则。看似简单的路径展开防御意义极大。流式桥接模式工具的onProgress回调和最终结果通过同一个 Stream 通道输出上层消费者用for await统一处理。Callback → Pull-based Stream 的经典桥接。函数式副作用注入ToolResult中的contextModifier函数让核心 call 方法保持纯输出副作用修改权限状态、更新文件缓存通过组合子注入。便于测试只需检查返回的 contextModifier 是否正确不需要 mock 全局状态。错误分类的防呆设计TelemetrySafeError_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS——这个极长的类名迫使开发者手动输入完整名称时审视我真的验证了这条消息不包含代码或文件路径吗。以 API 设计的摩擦换取安全意识。2.4 三层 AbortController精细化取消语义rootAbortController (根级: 用户 CtrlC) └── siblingAbortController (中级: Bash 错误级联) └── toolAbortController (叶级: 单工具控制)关键语义Bash 工具执行出错 → abortsiblingAbortController→ 级联取消所有并行兄弟工具——但不会冒泡到根级。查询循环不会因为一个 Bash 错误就终止整个 turn。而非sibling_error类型的 abort如权限拒绝则会冒泡到根级。为什么要区分两种取消Bash 命令失败是正常的编译错误、测试失败Agent 应该看到错误并调整策略权限被拒是致命的继续执行没有意义。内存安全用WeakRef持有子 AbortController 的引用避免已完成的工具因为事件监听器被根级 controller 引用而无法被 GC 回收。并发状态机每个工具经历四个状态queued → executing → completed → yielded。结合 Fail-Closed 默认值isConcurrencySafe: () false系统默认走最安全的串行路径。分区批处理算法将工具列表按并发安全性切割成交替的并行/串行分区输入: [Grep, Grep, Edit, Glob, Glob] 分区: [[Grep, Grep], [Edit], [Glob, Glob]] 执行: 并行(Grep×2) → 串行(Edit) → 并行(Glob×2)并发执行时上下文修改被延迟收集批次完成后按原始顺序统一应用消除并发竞态风险。2.5 BashTool 的七层防御BashTool 是安全复杂度最高的组件——它允许执行任意 Shell 命令既是最强能力也是最大攻击面层级防御机制效果Layer 1AST 解析 (Tree-sitter)复杂命令(管道、子shell) → 直接进入人工审批Layer 2精确匹配规则deny/ask/allow 的精确命令匹配Layer 3前缀/通配符规则复合命令不匹配前缀规则安全保守Layer 4路径约束白名单目录限制Layer 5Sed 约束白名单 sed 模式Layer 6只读自动放行命令白名单 flag 白名单Layer 7分类器审批LLM 语义匹配 投机执行固定点迭代清洗在规则匹配前需要剥离环境变量前缀和安全包装器如 timeout、nohup提取实际命令。交替执行stripAllLeadingEnvVars和stripSafeWrappers直到不再产生新候选——处理nohup Foobar timeout 5 rm -rf /这类多层嵌套时必须反复交替才能到达底层。deny 规则用激进剥离allow 规则用保守剥离。Sed 模拟执行不直接执行sed -i而是解析参数用JavaScript String.replace()写入文件。为什么因为 GNU sed vs BSD sed 的行为差异分隔符处理、转义规则、临时文件策略——模拟执行保证权限预览和实际写入结果完全一致实现所见即所得。同步转后台热切换用户按 CtrlB 时当前 generator 被停止同一个 ShellCommand 实例被迁移到 LocalShellTask 继续执行不重启进程。运行了 10 分钟的编译任务可以无缝切换到后台。2.6 FileEditTool原子写入与脏写防护双重时间戳校验LLM 读取文件和写入修改之间文件可能被外部进程修改。解决方案是 validateInput 阶段和 call 阶段各校验一次mtimeMs。Content FallbackWindows 上云同步软件和杀毒扫描经常更新 mtime 而不改变内容。如果只看时间戳会产生大量误报内容比较是更贵但更准确的后备手段。同步原子写入故意使用同步 APIreadFileSync/writeFileSync而非 async因为 JavaScript 事件循环可能在await的 read 和 write 之间插入其他操作导致 TOCTOUTime-of-Check-to-Time-of-Use问题。同步操作虽然阻塞事件循环但保证读写原子性。2.7 延迟工具与自修复引导当 MCP 动态注入的工具 schema 尚未发送给 API 时LLM 尝试调用该工具不会简单报错而是返回“This tool’s schema was not sent to the API — call ToolSearch with query ‘select:${tool.name}’ first”LLM 从错误消息中学习正确流程先调用 ToolSearch 加载工具再使用下次不再犯。与其设计一个防止所有错误的完美系统不如设计一个能从错误中优雅恢复的弹性系统。三、横向对比维度LangChain ToolsOpenAI Function CallingClaude CodeVercel AI SDK工具定义Python 装饰器 PydanticJSON SchemaTypeScript Zod编译期约束Schema纯声明式默认安全策略Fail-Open默认允许执行无内置安全层Fail-Closed未声明字段走最严格无内置安全层并发控制并行函数调用API 层无内置并发控制分区批处理 三层 AbortController无内置并发控制执行管线无简单的 run() 调用9 步管线每步可拦截中间件模式Shell 安全无内置不支持BashTool 七层纵深防御不支持可扩展性自定义 Tool 类函数列表MCP 协议 延迟加载自定义工具对工具描述简单 docstringJSON description 字段嵌入行为引导的 Prompt 工程description 字段三个关键差异安全默认值的哲学分歧LangChain 假设开发者知道自己在做什么Claude Code 假设开发者可能犯错。这种差异源于使用场景——LangChain 面向开发者构建应用Claude Code 直接面向终端用户。并发模型的内化OpenAI 在 API 层面支持parallel_tool_calls但执行层并发控制交给开发者。Claude Code 将并发编排内化为框架能力开发者无需处理竞态条件。Shell 执行的独特挑战Claude Code 是少数将 Shell 执行作为一等工具的框架因此需要七层防御。设计洞察工具系统的复杂度与 Agent 自主权正相关。Claude Code 选择了高自主权 高防御的路线因为限制自主权也限制了能力上界。四、实战启示启示一Fail-Closed 应该是你的默认选择任何涉及安全属性的可选声明默认值都应该是最严格的。原因很简单——误判安全的代价远高于误判危险。在你的系统中isConcurrencySafe默认falseisReadonly默认falseisEnabled默认true唯一例外因为禁用工具比启用更危险。启示二软硬结合的控制策略比纯硬约束更有效工具描述即 Prompt 是一种软约束——不阻止 LLM 使用 Bash 做 grep而是引导它优先选择专用工具。与硬编码的权限检查互补形成双层防线。在自研 Agent 系统中Prompt 层面的行为引导和代码层面的权限校验应该同时存在。启示三取消语义需要分层设计单一的全局取消信号不够用。用户中断、兄弟工具失败、单工具超时——这三种场景的正确做法完全不同。三层 AbortController abort reason 分类 条件冒泡实现了精细化的错误级联控制。在分布式系统中这对应着局部故障不应导致全局崩溃。启示四弹性恢复优于完美预防延迟工具的自修复引导展示了弹性系统思维允许 LLM 犯错但让错误信息成为学习机会。在工程实践中构建一个能从错误中优雅恢复的系统比构建一个防止所有错误的系统更可行也更健壮。五、设计模式速查模式核心思想适用场景Fail-Closed 默认值安全相关属性默认选最严格任何可选安全声明的注册表分区批处理编排按并发安全性切割交替分区混合读写操作的批处理三层取消语义嵌套 AbortController reason 分类多层嵌套异步任务取消确定性写入用宿主语言模拟 Shell 命令需要预览和确认的写入操作固定点迭代清洗循环剥离直到收敛多层嵌套结构的解析规范化函数式副作用注入contextModifier 组合子保持核心逻辑纯净的场景工具描述即 Prompt工具描述作为 LLM 行为引导LLM 工具选择优化工具沙箱隔离白名单式进程级文件系统隔离第三方工具的安全执行下期预告工具系统给出了 Agent 能做什么的能力清单但谁来决定 Agent “可以做什么”下一章——第5章权限模型是全书最厚的一章57页Claude Code 用四级信任机制、8维资源分类、14个权限检查点、YOLO 分类器来回答这个问题。第06篇将深入权限决策体系的核心框架看 14 层授权逻辑如何为每一行代码执行把关。思考题如果引入工具组概念一组工具作为一个事务执行三层 AbortController 架构需要怎样调整是否需要增加第四层
30+ 工具背后的秘密：工具系统注册、调度与沙箱安全
发布时间：2026/6/28 9:45:09
30 工具背后的秘密工具系统注册、调度与沙箱安全《Claude Code 架构解密》读书笔记 · 第05篇对应章节第4章 — 工具系统Agent 的手脚p.94-111导语一个最简单的工具调用switch-case 加几个函数就能搞定。但 Claude Code 的工具系统为什么需要四层架构、九步管线、三层取消控制器、七层 Shell 防御因为当 LLM 可以执行rm -rf /、并发修改文件、随时被 CtrlC 中断时简单就是最大的危险。本篇拆解 Claude Code 如何用 Fail-Closed 哲学在赋予 Agent 最大自主权的同时守住安全底线。一、架构图解工具系统的四层纵队Claude Code 用四层架构回应工具系统的五大挑战安全性、并发性、可中断性、可扩展性、可观测性┌─────────────────────────────────────────────────────┐ │ Layer 3: 查询引擎 (QueryEngine / query.ts) │ │ → 从 LLM 响应中提取 tool_use 块驱动执行 │ ├─────────────────────────────────────────────────────┤ │ Layer 2: 执行编排 (StreamingToolExecutor) │ │ → 并发控制、分区策略、错误级联、流式响应 │ ├─────────────────────────────────────────────────────┤ │ Layer 1: 单工具执行 (toolExecution.ts) │ │ → 输入验证 → Hook → 权限决策 → call() → 后置 Hook │ ├─────────────────────────────────────────────────────┤ │ Layer 0: 工具注册表 (tools.ts Tool.ts) │ │ → 工具发现、过滤、合并、排序 │ └─────────────────────────────────────────────────────┘自底向上注册表提供有哪些工具单工具执行管怎么安全地跑一个编排层管多个工具怎么协调查询引擎管何时调用。二、核心点拆解2.1 六大分类与工具描述即 Prompt30 内置工具按安全级别分为六大类类别安全级别代表工具设计直觉文件操作需确认(写)/自动(读)Read、Write、Edit、NotebookEdit核心生产力Edit 有 read-before-write搜索与发现自动放行Grep、Glob、Bash(find)只读、并发安全Shell 执行需确认Bash、TaskStart、TaskStop最大攻击面七层防御Agent 协作需确认Agent(子Agent)、TeamCreate跨进程隔离外部集成需确认WebFetch、WebSearch、MCP网络出站SSRF 防护辅助工具自动放行TodoWrite、AskUserQuestion纯状态无副作用关键洞察安全级别与工具的副作用范围正相关。只读工具默认放行写入工具需要确认跨边界工具需要最严格审查。注册表的isReadonly、isDestructive、isConcurrencySafe三个布尔标记正是这种分类的形式化表达。工具描述即 PromptBashTool 的 description 里写明不要用 Bash 来 grep/find/cat引导 LLM 优先使用专用工具——这不是技术约束而是 Prompt 引导。描述的措辞影响工具选择描述的长度影响 Prompt Cache 经济性描述的稳定性影响缓存命中率。软约束Prompt 引导与硬约束权限检查互补形成软硬结合的控制策略。2.2 Fail-Closed 注册表编译期锁死安全注册表的核心是ToolInput, Output, Progress泛型接口和buildTool函数。设计哲学体现在默认值选择constTOOL_DEFAULTS{isEnabled:()true,isConcurrencySafe:()false,// 保守假设不安全isReadonly:()false,// 保守假设会写入isDestructive:()false,checkPermissions:allow,}Fail-Closed 的不对称代价一次误判安全可能导致数据丢失一次误判危险最多让用户多点一次确认。系统选择宁杀勿放。编译期类型体操buildTool的返回类型通过 TypeScript 条件类型和映射类型自动填充默认值——调用方不需要任何运行时 null 检查。把运行时的防御转移到编译期的约束这是 TypeScript 类型系统的优雅应用。Prompt Cache 稳定性排序内置工具分区在前MCP 工具在后两组内部按名称排序。混排会导致 MCP 工具的动态插入/删除使所有下游缓存键失效浪费大量 token 费用。四维模式过滤Simple 模式仅保留 Bash/Read/EditREPL 模式隐藏原始工具强制走 REPLCoordinator 额外暴露 Agent/TaskStopDeny 规则让模型看不到已禁用工具。容错设计如果 REPLTool 被 deny 规则移除原始工具自动重新可见——过滤是减法但减到零时要兜底。2.3 九步执行管线一次工具调用的完整旅程当 LLM 返回tool_use块时toolExecution.ts中的runToolUse启动九步管线步骤操作设计亮点1findToolByName含别名回退“KillShell” → “TaskStop”向后兼容比 API 整洁更重要2Abort 检查用户中断流式 fallback3Zod Schema 验证safeParse失败返回 InputValidationError4工具自定义验证如 FileEditTool 的 read-before-write5Bash 分类器投机预检并行启动不阻塞主流程——乐观并行策略6输入回填~展开为绝对路径防 Hook 白名单绕过7PreToolUse Hooks可修改输入、返回权限决策8权限决策解析Hook → 规则 → canUseTool → 最终决策9tool.call() PostToolUse Hooks执行 结果映射步骤 5 的投机预检在用户审批权限弹窗期间并行启动 Bash 分类器。用户批准了结果已就绪用户拒绝了结果被丢弃。用少量计算资源换取可感知的延迟降低。步骤 6 的路径回填~/../../etc/passwd在回填前可以绕过基于路径的白名单规则。看似简单的路径展开防御意义极大。流式桥接模式工具的onProgress回调和最终结果通过同一个 Stream 通道输出上层消费者用for await统一处理。Callback → Pull-based Stream 的经典桥接。函数式副作用注入ToolResult中的contextModifier函数让核心 call 方法保持纯输出副作用修改权限状态、更新文件缓存通过组合子注入。便于测试只需检查返回的 contextModifier 是否正确不需要 mock 全局状态。错误分类的防呆设计TelemetrySafeError_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS——这个极长的类名迫使开发者手动输入完整名称时审视我真的验证了这条消息不包含代码或文件路径吗。以 API 设计的摩擦换取安全意识。2.4 三层 AbortController精细化取消语义rootAbortController (根级: 用户 CtrlC) └── siblingAbortController (中级: Bash 错误级联) └── toolAbortController (叶级: 单工具控制)关键语义Bash 工具执行出错 → abortsiblingAbortController→ 级联取消所有并行兄弟工具——但不会冒泡到根级。查询循环不会因为一个 Bash 错误就终止整个 turn。而非sibling_error类型的 abort如权限拒绝则会冒泡到根级。为什么要区分两种取消Bash 命令失败是正常的编译错误、测试失败Agent 应该看到错误并调整策略权限被拒是致命的继续执行没有意义。内存安全用WeakRef持有子 AbortController 的引用避免已完成的工具因为事件监听器被根级 controller 引用而无法被 GC 回收。并发状态机每个工具经历四个状态queued → executing → completed → yielded。结合 Fail-Closed 默认值isConcurrencySafe: () false系统默认走最安全的串行路径。分区批处理算法将工具列表按并发安全性切割成交替的并行/串行分区输入: [Grep, Grep, Edit, Glob, Glob] 分区: [[Grep, Grep], [Edit], [Glob, Glob]] 执行: 并行(Grep×2) → 串行(Edit) → 并行(Glob×2)并发执行时上下文修改被延迟收集批次完成后按原始顺序统一应用消除并发竞态风险。2.5 BashTool 的七层防御BashTool 是安全复杂度最高的组件——它允许执行任意 Shell 命令既是最强能力也是最大攻击面层级防御机制效果Layer 1AST 解析 (Tree-sitter)复杂命令(管道、子shell) → 直接进入人工审批Layer 2精确匹配规则deny/ask/allow 的精确命令匹配Layer 3前缀/通配符规则复合命令不匹配前缀规则安全保守Layer 4路径约束白名单目录限制Layer 5Sed 约束白名单 sed 模式Layer 6只读自动放行命令白名单 flag 白名单Layer 7分类器审批LLM 语义匹配 投机执行固定点迭代清洗在规则匹配前需要剥离环境变量前缀和安全包装器如 timeout、nohup提取实际命令。交替执行stripAllLeadingEnvVars和stripSafeWrappers直到不再产生新候选——处理nohup Foobar timeout 5 rm -rf /这类多层嵌套时必须反复交替才能到达底层。deny 规则用激进剥离allow 规则用保守剥离。Sed 模拟执行不直接执行sed -i而是解析参数用JavaScript String.replace()写入文件。为什么因为 GNU sed vs BSD sed 的行为差异分隔符处理、转义规则、临时文件策略——模拟执行保证权限预览和实际写入结果完全一致实现所见即所得。同步转后台热切换用户按 CtrlB 时当前 generator 被停止同一个 ShellCommand 实例被迁移到 LocalShellTask 继续执行不重启进程。运行了 10 分钟的编译任务可以无缝切换到后台。2.6 FileEditTool原子写入与脏写防护双重时间戳校验LLM 读取文件和写入修改之间文件可能被外部进程修改。解决方案是 validateInput 阶段和 call 阶段各校验一次mtimeMs。Content FallbackWindows 上云同步软件和杀毒扫描经常更新 mtime 而不改变内容。如果只看时间戳会产生大量误报内容比较是更贵但更准确的后备手段。同步原子写入故意使用同步 APIreadFileSync/writeFileSync而非 async因为 JavaScript 事件循环可能在await的 read 和 write 之间插入其他操作导致 TOCTOUTime-of-Check-to-Time-of-Use问题。同步操作虽然阻塞事件循环但保证读写原子性。2.7 延迟工具与自修复引导当 MCP 动态注入的工具 schema 尚未发送给 API 时LLM 尝试调用该工具不会简单报错而是返回“This tool’s schema was not sent to the API — call ToolSearch with query ‘select:${tool.name}’ first”LLM 从错误消息中学习正确流程先调用 ToolSearch 加载工具再使用下次不再犯。与其设计一个防止所有错误的完美系统不如设计一个能从错误中优雅恢复的弹性系统。三、横向对比维度LangChain ToolsOpenAI Function CallingClaude CodeVercel AI SDK工具定义Python 装饰器 PydanticJSON SchemaTypeScript Zod编译期约束Schema纯声明式默认安全策略Fail-Open默认允许执行无内置安全层Fail-Closed未声明字段走最严格无内置安全层并发控制并行函数调用API 层无内置并发控制分区批处理 三层 AbortController无内置并发控制执行管线无简单的 run() 调用9 步管线每步可拦截中间件模式Shell 安全无内置不支持BashTool 七层纵深防御不支持可扩展性自定义 Tool 类函数列表MCP 协议 延迟加载自定义工具对工具描述简单 docstringJSON description 字段嵌入行为引导的 Prompt 工程description 字段三个关键差异安全默认值的哲学分歧LangChain 假设开发者知道自己在做什么Claude Code 假设开发者可能犯错。这种差异源于使用场景——LangChain 面向开发者构建应用Claude Code 直接面向终端用户。并发模型的内化OpenAI 在 API 层面支持parallel_tool_calls但执行层并发控制交给开发者。Claude Code 将并发编排内化为框架能力开发者无需处理竞态条件。Shell 执行的独特挑战Claude Code 是少数将 Shell 执行作为一等工具的框架因此需要七层防御。设计洞察工具系统的复杂度与 Agent 自主权正相关。Claude Code 选择了高自主权 高防御的路线因为限制自主权也限制了能力上界。四、实战启示启示一Fail-Closed 应该是你的默认选择任何涉及安全属性的可选声明默认值都应该是最严格的。原因很简单——误判安全的代价远高于误判危险。在你的系统中isConcurrencySafe默认falseisReadonly默认falseisEnabled默认true唯一例外因为禁用工具比启用更危险。启示二软硬结合的控制策略比纯硬约束更有效工具描述即 Prompt 是一种软约束——不阻止 LLM 使用 Bash 做 grep而是引导它优先选择专用工具。与硬编码的权限检查互补形成双层防线。在自研 Agent 系统中Prompt 层面的行为引导和代码层面的权限校验应该同时存在。启示三取消语义需要分层设计单一的全局取消信号不够用。用户中断、兄弟工具失败、单工具超时——这三种场景的正确做法完全不同。三层 AbortController abort reason 分类 条件冒泡实现了精细化的错误级联控制。在分布式系统中这对应着局部故障不应导致全局崩溃。启示四弹性恢复优于完美预防延迟工具的自修复引导展示了弹性系统思维允许 LLM 犯错但让错误信息成为学习机会。在工程实践中构建一个能从错误中优雅恢复的系统比构建一个防止所有错误的系统更可行也更健壮。五、设计模式速查模式核心思想适用场景Fail-Closed 默认值安全相关属性默认选最严格任何可选安全声明的注册表分区批处理编排按并发安全性切割交替分区混合读写操作的批处理三层取消语义嵌套 AbortController reason 分类多层嵌套异步任务取消确定性写入用宿主语言模拟 Shell 命令需要预览和确认的写入操作固定点迭代清洗循环剥离直到收敛多层嵌套结构的解析规范化函数式副作用注入contextModifier 组合子保持核心逻辑纯净的场景工具描述即 Prompt工具描述作为 LLM 行为引导LLM 工具选择优化工具沙箱隔离白名单式进程级文件系统隔离第三方工具的安全执行下期预告工具系统给出了 Agent 能做什么的能力清单但谁来决定 Agent “可以做什么”下一章——第5章权限模型是全书最厚的一章57页Claude Code 用四级信任机制、8维资源分类、14个权限检查点、YOLO 分类器来回答这个问题。第06篇将深入权限决策体系的核心框架看 14 层授权逻辑如何为每一行代码执行把关。思考题如果引入工具组概念一组工具作为一个事务执行三层 AbortController 架构需要怎样调整是否需要增加第四层
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
