看到一系列好的文章这里分享一下https://mp.weixin.qq.com/s/0syVbkI0ikrTE9ynkqwpbw语言模型本身只能输出文字。你让它帮我删掉这个目录里的临时文件它能理解这个意图能输出一段描述该怎么做的文字。但如果没有工具系统它什么也做不了——它没有手碰不到文件系统。工具系统是连接模型意图和真实操作的桥梁。每次模型决定要采取一个行动工具系统拦截这个决定检查它是否被允许然后执行把结果返回给模型。这个桥梁的设计要同时回答两个方向的问题向外扩展能力Agent 能调用哪些工具能做什么事能力边界在哪里。向内控制行为谁来决定工具调用是否被允许危险操作如何拦截人如何保持对 Agent 行为的控制。这两个方向的设计取舍在三个框架里给出了三种根本不同的答案。工具调用的基本机制在拆解三个框架之前先把共同的底层机制说清楚。所有框架的工具调用都遵循同一个流程模型输出 tool_use 块↓Harness 拦截解析工具名和参数↓权限检查通过 / 拦截 / 请求确认↓执行工具获取结果↓结果作为 tool_result 注入上下文↓模型继续推理这个流程里有一个关键的设计决策点权限检查发生在哪里由谁来做。是在模型层靠提示词约束是在框架层靠程序逻辑还是在系统层靠沙箱隔离三个框架的根本差异就在这里。OpenClaw开放优先安全靠配置核心设计哲学最大能力按需收紧OpenClaw 的工具系统设计哲学是默认给 Agent 最大的能力让用户自己决定怎么收紧。这和 Unix 的设计哲学很像——系统给你 root 权限你自己决定要不要用。OpenClaw 核心工具集├── exec ← 执行任意 Shell 命令最强也最危险├── read ← 读取文件├── write ← 写入文件├── edit ← 编辑文件├── browser ← 浏览器控制├── memory_search ← 语义搜索记忆└── memory_get ← 读取指定记忆文件exec是整个工具系统里最关键的工具。它能执行任意 Shell 命令意味着 Agent 可以做操作系统层面能做的一切——这既是 OpenClaw 强大的根源也是它安全风险最集中的地方。rm -rf也是 Shell 命令。六层级联权限模型OpenClaw 的权限不是简单的允许/禁止而是一个六层的级联策略系统全局策略Global Policy↓模型提供商策略Provider Policy↓Agent 级策略Agent Policy↓群组级策略Group Policy↓沙箱策略Sandbox Policy↓子 Agent 继承规则Subagent Inheritance工具调用必须通过每一层的检查才能执行。上层策略可以限制下层下层不能突破上层的约束。这个设计的架构价值在于不同的 Agent 可以有不同的权限配置而不是所有 Agent 共享同一套规则。一个专门处理邮件的 Agent可以配置成只有邮件相关的工具权限一个开发 Agent可以有更完整的文件系统访问权限。权限随角色而定而不是全局一刀切。关键的默认设置问题OpenClaw 有一个被广泛批评的设计选择默认配置是宽松的。官方文档承认默认情况下OpenClaw 没有工具权限限制没有命令白名单没有审批要求。这个选择是合理的——对于个人用户快速上手来说宽松的默认值降低了入门门槛。但代价是大量用户在不知情的情况下运行着一个对本机拥有近乎完整权限的 AI Agent。2026 年初安全研究人员发现超过 13.5 万个暴露在公网的 OpenClaw 实例其中 63% 完全没有身份认证。这揭示了一个架构设计的根本问题把安全的责任交给用户配置本质上是把风险外包给了最不了解安全的那批用户。工具拦截事件驱动的扩展点OpenClaw 的工具系统有一个很重要的扩展机制工具执行前会触发事件扩展Extension可以订阅这些事件进行拦截。这是一个正确的架构设计——安全护栏写在程序逻辑里而不是提示词里。程序级别的拦截不会被 Prompt Injection 绕过。但这个机制是可选的不是默认启用的。你需要主动配置扩展才能激活拦截。Claude Code工具即契约权限分三档核心设计哲学每个工具都是一个独立的权限单元Claude Code 的工具系统从泄露的源码里能看到一个非常清晰的架构原则每个工具独立定义自己的 schema、权限级别和执行逻辑没有共享的可变状态。BashTool和FileReadTool在同一个工具注册表里但权限完全不同——Bash 执行可以修改系统状态文件读取是只读的。架构用不同的权限门控来反映这种风险差异而不是对所有工具应用统一策略。这个设计的架构价值在于工具的风险画像是内聚在工具本身里的而不是分散在外部配置里。添加新工具不需要修改权限系统的核心逻辑工具的行为变了权限也随之变化。三档权限模型Claude Code 把所有工具调用分成三个风险等级第一档自动批准只读或天然安全的操作——文件读取、文本搜索、代码导航。这类操作不改变系统状态无需任何中断地执行。第二档按需确认修改受控状态的操作——文件编辑、特定 Shell 命令。默认情况下这类操作需要用户手动确认。2026 年 3 月Claude Code 推出了 Auto Mode目前是 Team/Enterprise 的 Research Preview引入了一个基于 Sonnet 4.6 的背景分类器为这一档提供自动化判断能力。分类器的工作机制值得仔细看它分两个阶段运行——先用一个快速的单 token 过滤器做初步判断通过/标记只有被标记为可疑的调用才进入 chain-of-thought 推理阶段。这个两阶段设计保证了大多数正常操作的低开销把计算资源集中在真正需要深度分析的可疑调用上。分类器的输入范围有一个刻意的设计它能看到用户的请求和工具调用的内容但看不到模型的推理文字也看不到工具的执行结果。这是结构性的防御——防止模型用流畅的解释说服分类器放行也防止恶意内容通过工具输出影响分类判断。安全边界只看行为和原始意图不听理由不看结果。第三档要求明确审批或拦截高风险操作——可能破坏系统状态的 Shell 命令、工作目录之外的文件操作、任何疑似数据外泄的行为。这三档不是固定的用户可以通过配置调整也可以在会话中临时修改比如对某个具体命令选择始终允许。工具即注册表AgentTool 的设计从泄露的源码里能看到一个值得关注的设计AgentTool——子 Agent 本身是工具注册表里的一个普通工具。这意味着生成子 Agent 和调用文件读取在架构层面是同一类操作走同样的权限管道受同样的拦截机制约束。不需要单独的 Agent 编排层不需要特殊的进程模型。子 Agent 是工具注册表的一等公民。这个设计极大地简化了多 Agent 系统的架构复杂度——扩展工具系统就等于扩展 Agent 协作能力。MCP 的工具发现按需加载不是全量注入Claude Code 支持 MCPModel Context Protocol扩展外部工具。设计上有一个值得借鉴的细节连接 MCP 服务器时不会把所有工具的完整 schema 加载进上下文只加载工具名称列表。当任务真正需要某个工具时才加载该工具的完整定义。这和 Skills 的渐进式加载是同一套逻辑先知道有什么可用按需再取完整内容。工具越多这个设计的 Token 节省效果越明显。MCP 服务器的推荐上限是 5-6 个活跃服务因为每个服务会启动一个子进程资源有限制。Hermes Agent工具系统与学习循环的融合核心设计哲学工具执行是情景记忆的输入Hermes Agent 的工具系统有一个和其他两个框架根本不同的设计出发点工具的执行结果不只是当次任务的输出还是情景记忆系统的输入。当 Hermes Agent 完成一个涉及五次以上工具调用的复杂任务它会分析这次执行过程把成功的路径抽象成 Skill 文档。这意味着工具系统的设计必须支持执行过程的结构化捕获——不只是执行了什么还有为什么这样执行、效果如何。这个设计让工具调用的意义发生了扩展每次执行既是当次任务的操作也是未来学习的素材。40 内置工具六种执行后端Hermes Agent 内置了 40 多个工具覆盖文件管理、浏览器自动化、终端执行、邮件、日历、网页搜索等。但工具系统里最值得关注的架构设计是六种执行后端local ← 本机直接执行默认docker ← Docker 容器隔离ssh ← 远程 SSH 执行daytona ← 云端开发环境singularity ← HPC 容器科学计算场景modal ← Serverless GPU 执行同样的工具调用可以在不同的隔离级别下执行。这个设计把工具是什么和工具在哪里执行解耦了。架构价值安全等级和能力需求可以独立调整。你可以在 Docker 后端里运行同样的工具集获得容器级隔离而不需要改任何工具的定义。危险命令的审批机制Hermes Agent 的审批机制和 OpenClaw 的事件拦截、Claude Code 的权限分档都不同基于模式匹配的危险检测 三种审批模式。执行任何命令前Hermes Agent 对比一个危险模式库——递归删除、权限修改、sudo 使用等都在检测范围内。匹配到危险模式触发审批流程。approvals:mode: manual ← 手动确认默认smart ← AI 辅助判断off ← 全自动YOLO 模式timeout: 60 ← 无响应则默认拒绝fail-closed有几个设计细节值得关注Fail-closed 默认策略超时未响应默认拒绝而不是默认放行。在安全设计里这是正确的原则——不确定时选择更保守的行为。容器后端绕过当运行在 Docker、Modal 等容器后端时危险命令检查会被跳过因为容器本身就是隔离边界。这是一个合理的设计取舍——把安全责任从应用层移到基础设施层。YOLO 模式全自动、不拦截。这是为了在受信任的自动化场景下提升效率同时用命名方式YOLO让用户意识到这是一个刻意的高风险选择。v0.7.0 的安全加固凭证保护2026 年 4 月Hermes Agent v0.7.0 做了一次重要的安全加固核心是对凭证泄漏的防御扫描浏览器 URL 和 LLM 响应检测 base64 编码、URL 编码形式的凭证容器执行输出脱敏防止凭证从代码执行结果中泄漏保护目录.docker、.azure、.config/gh文件工具无法访问路径遍历防御阻止 zip-slip 类攻击这些加固说明 Hermes Agent 在安全设计上走的是发现问题、迭代修复的路径而不是从一开始就有完整的安全架构。三种架构哲学的本质差异把三个框架的工具系统设计放在一起能看到三种根本不同的安全哲学OpenClaw最大能力安全靠配置给 Agent 最大的工具权限让用户自己决定收紧到什么程度。这对个人用户友好对安全意识弱的用户危险。Claude Code权限内聚于工具三档自动分级每个工具自带风险画像框架按风险级别自动决定执行策略。安全不依赖用户配置但也因此减少了灵活性。Hermes安全是基础设施问题工具系统服务于学习循环通过执行后端提供基础设施级隔离工具执行和情景记忆深度耦合安全设计随版本迭代演进。工具系统设计的核心取舍分析三个框架之后工具系统设计里有几个核心的架构取舍值得提炼取舍一最大能力 vs 最小权限OpenClaw 选择最大能力降低使用门槛。Claude Code 选择最小权限提高默认安全性。这不是非此即彼的选择而是对目标用户群体的判断——个人用户更需要能力企业用户更需要安全。取舍二应用层安全 vs 基础设施层安全OpenClaw 和 Claude Code 的权限控制在应用层。Hermes Agent 的执行后端把安全下推到基础设施层容器。基础设施层的安全更可靠但设置成本更高。取舍三工具调用是操作 vs 工具调用是素材这是 Hermes Agent 和另外两个框架最根本的差异。当工具执行结果成为情景记忆的输入工具系统就不只是一个执行层而是 Agent 进化能力的基础设施。取舍四拦截在哪一层提示词层的拦截可以被 Prompt Injection 绕过。程序层的拦截不会。容器级的隔离让拦截本身变得不那么必要。三个层次各有成本安全等级递增灵活性递减。