`exec`
更接近通用执行能力，可以读文件、跑命令、观察环境，也因此风险上限最高。
Risk Boundaries
Exec、apply_patch 与审批
如果说插件决定“系统能装进什么能力”，那 Exec 这一层决定“模型在当前环境里到底能做多大动作”。这不是配置细节，而是风险边界。
两类核心工具
能力分层
把 `exec` 和 `apply_patch` 分开理解，会比把它们都看成“执行命令”更稳。
`apply_patch`
适合结构化、小范围、可审查的文件修改，比任意写文件更容易控制和复核。
审批策略
决定哪些动作可以自动执行，哪些必须经用户确认，是所有高权限行为的真正闸门。
什么该自动，什么不该
风险矩阵
并不是所有“能做”的动作都应该交给长期自动化去做。
低风险
查看状态、只读检查、列清单、生成 diff 建议。
中风险
小范围 patch、固定目录内修改、可回滚的脚本执行。
高风险
批量写外部系统、跨机器执行、不可逆删除、无监控的多步骤链路。
为什么 sandbox 不是“麻烦设置”
运行边界
高权限工具最容易被低估的，不是调用本身，而是运行位置和隔离范围。
workspace 边界
先判断当前工具操作的是哪个目录、哪些文件，以及是否会碰到用户未预期的区域。
远程和本地差异
本地能跑不代表 Gateway 主机上也能跑。环境差异和依赖差异经常是根因。
审批拒绝后的行为
需要提前设计未获批准时的降级路径，而不是把整个流程卡死在某一步。
上线前检查
下面这组检查更适合在你真正准备启用这类能力之前过一遍。
先做只读确认
先确定目标文件、目标环境、命令影响范围，再进入写操作。
优先结构化修改
能用 apply_patch 的场景，不要直接走更大范围的任意写入。
高风险动作必须可回滚
至少知道失败后怎么停、怎么恢复、怎么补救。
长期运行前看审批与日志
没有审批边界和日志回看，就不要把动作放进自动化。
相关入口
这一页看完后，通常应该去这些相邻入口收口，而不是停留在单页理解上。
继续浏览
工具系列本来就是一组连续页面。看完当前专题后，最适合继续读的是这些相邻主题。