AI Agent 对比系列（三）：工具系统 — 它们怎么「干活」？

AI Agent 对比系列三工具系统 — 它们怎么「干活」《AI Agent 对比系列》第三篇 · 整合对比版本系列通过对比两个真实开源 AI Agent——OpenClaw和Hermes Agent——带你深入理解 AI Agent 的工具系统它们有哪些工具、从哪里来、怎么控制、怎么扩展。上一篇记忆系统篇——AI Agent 怎么在对话之间记住你。本篇工具系统篇——AI Agent 的「手脚」是怎么组织和运行的。先来做个实验实验 1 — 数工具对你的 Hermes 运行hermes tools看看多少工具集是打开的。对 OpenClaw 问「你现在能做什么把你的所有工具列出来按类别分。」你会看到两份差距很大的清单——不是因为谁比谁强而是两套完全不同的组织哲学。实验 2 — 动手试试打开浏览器帮我搜一下今天的新闻把结果抓回来。如果配置了浏览器和搜索工具你会在一个聊天框里看到 Agent 驱动一个真正的浏览器去查网页。一个消息通道里的聊天框在驱动一个真正的浏览器。核心认知工具 注册在中央目录的函数大模型本身没有手脚。它的每个「能力」都是一个注册在系统中的函数由 Agent Loop 在推理循环中按需调用。聊天机器人ChatGPT你问 → 它答 AI Agent 你派活 → 它思考 → 选工具 → 调工具 → 拿到结果 → 继续思考 → 输出但这里有一个关键的设计问题工具越多Agent 能做的事越多——但工具列表越长模型挑工具的成本越高。每种工具都有自己的 Schema参数定义全发给模型的话上下文里塞几百 KB 的工具定义模型都不知道该看哪个。两套工具系统解决的是同一个矛盾——如何让 Agent 有尽可能多的能力同时不让工具列表撑爆上下文、又让你能控制住它——但解法截然不同。工具系统的「骨架」三层架构对比Hermes注册中心 松耦合管道┌──────────────────────────────────────────────┐ │ Agent Looprun_agent.py │ │ 决定要不要调工具调哪个结果怎么处理 │ └─────────────────────┬────────────────────────┘ │ ┌─────────────────────▼────────────────────────┐ │ 模型工具桥接层model_tools.py │ │ 把工具定义翻译成 LLM 认识的 function-calling │ │ 把 LLM 返回的 tool_call 翻译成实际函数调用 │ └─────────────────────┬────────────────────────┘ │ ┌─────────────────────▼────────────────────────┐ │ 中央注册表tools/registry.py │ │ 70 已注册的工具按 toolsets 分组 │ │ 每个工具带name / schema / handler / check_fn │ └─────────────────────┬────────────────────────┘ │ ┌────────┬───────┼───────┬────────┐ ▼ ▼ ▼ ▼ ▼ Terminal File Browser Web MCP 6种后端 读写编辑 5种后端 4种后端 动态注册三层松耦合Registry 不管谁是 LLMmodel_tools 不管怎么执行Agent Loop 不管工具内部逻辑。OpenClaw三层来源 三层过滤┌─────────────────────────────────┐ │ Agent Runtime │ │ (Agent Loop 模型调用) │ └──────────┬──────────────────────┘ │ 工具可见性过滤 ▼ ┌─────────────────────────────────────────────────┐ │ 有效工具列表发给模型 │ │ 经过 profile/allow/deny/plugin 层层过滤后 │ └─────────────────────────────────────────────────┘ │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ 内置工具 │ │ 插件工具 │ │ MCP 服务器工具 │ │ (built-in)│ │ (plugin) │ │ (MCP servers) │ └──────────┘ └──────────┘ └──────────────────┘三层聚合工具来自不同渠道汇聚后经策略层过滤再给到模型。核心差异Hermes 的架构是分发式——所有工具进注册表统一处理OpenClaw 是聚合式——不同来源的工具各自独立通过策略层合并过滤。三大机制对比机制一工具怎么注册进来的HermesOpenClaw方式registry.register()AST 自动发现api.registerTool()显式注册发现启动时扫描tools/*.py自动导入含register()调用的模块插件通过manifest.json声明MCP 通过配置注册新增工具写一个 .py 文件放tools/目录重启自动生效装插件、配置 MCP server或开发自定义插件失败处理单个工具加载失败只影响自己不炸全局插件加载失败整体回退Hermes 的核心创新在auto-discovery不需要手动维护工具列表AST 扫描自动识别哪些 .py 文件注册了工具。OpenClaw 则更传统每个工具必须通过api.registerTool()显式声明。机制二工具怎么被过滤HermesOpenClaw机制check_fn运行时可用性门控Tool Profile Allow/Deny 运行时约束粒度工具级每个工具独立 check配置级Profile 预定义整组工具判断依据API Key 存在二进制装了服务在跑用户身份聊天通道沙箱环境Provider 能力默认行为check_fn 不通过 → 模型根本看不到这个工具Profile 不包含 → 模型根本看不到这个工具两套思路的本质区别Hermes 的 check_fn 是技术性过滤——“这个工具现在能用吗”钥匙到位了没OpenClaw 的 Profile 是策略性过滤——“这个场景下应该让 Agent 看到什么工具”该给员工哪套钥匙机制三工具怎么被调用两地最终都走 Agent Loop 分发但细节不同HermesOpenClaw特殊工具4 个 agent-loop 工具todo/memory/session_search/delegate_task不走 registry由 Agent Loop 直接处理部分工具如ask_user也有特殊路由错误包裹双层 try/except确保 LLM 永远拿到 JSON 而不是原始异常适配层转成目标模型能理解的格式异步显式异步桥接CLI 用持久事件循环Gateway 用线程同步架构为主终端后端6 种local/docker/ssh/singularity/modal/daytonasandbox/gateway/host工具全景图各自有什么工具类别HermesOpenClaw终端/运行时terminal process6 后端exec process code_execution文件操作read_file / write_file / patch / search_filesread / write / edit / apply_patchWeb 搜索web_search / web_extractweb_search / web_fetch / x_search浏览器navigate / click / type / scroll / snapshot / vision5 后端browser独立浏览器控制图片生成image_generate9 种模型image_generate视觉分析vision_analyzeimage看图语音text_to_speechtts视频video_generate / video_analyzevideo_generate / music_generate定时任务cronjobcron / heartbeat_respond子任务delegate_task / execute_codesessions_spawn / sessions_send / sessions_list消息通过 Gateway 平台适配器message直接发消息到聊天通道目标管理todo / clarifycreate_goal / update_goal / get_goal / ask_user技能skill_view / skill_manage / skills_listskill_workshop集成MCP Server 工具 Home Assistant Spotify Computer UseMCP Server 工具 插件系统特殊session_searchFTS5 历史对话检索gateway / nodes网关状态查询各自的数量级指标HermesOpenClaw内置工具7028 个 toolsets10 大类别默认配置全量注册按 toolsets check_fn 过滤CLI 典型 17/25coding profile开发常用工具集合扩展方式.py 自动注册 / MCP / 插件ClawHub 插件 / MCP / 自定义插件社区生态Skills Hubagentskills.io 标准ClawHub 插件市场安全机制两个 Agent 都意识到工具给了能力就必须有约束HermesOpenClaw执行保护DANGEROUS_PATTERNS 模式匹配rm -rf、mkfs、DROP TABLE、curl sh 等Sandbox 隔离 elevated 提升审批审批流程CLI 交互式 / Gateway 异步回调 / 智能 LLM 辅助审批配置审批后exec 暂停等用户点批准缓存审批结果 session 内缓存可选永久加入 allowlist按会话/通道管理分层单层危险命令检测三层Sandbox → Tool Policy → Elevated差异思路Hermes 相信多数命令是安全的标记少数危险模式OpenClaw 相信默认隔离沙箱明确授权才逃逸。扩展路径对比难度HermesOpenClaw⭐启用已有的 toolsethermes tools装 ClawHub 插件⭐⭐装一个技能写 SKILL.md 教怎么用工具写一个 Skill教怎么用已有工具⭐⭐⭐配置 MCP 服务器当前已接入 Dify MCP12 个工具配置 MCP 服务器⭐⭐⭐⭐写一个 .py 文件放tools/目录自动注册开发自定义插件Tool Gateway付费订阅一个密钥覆盖 Web/图片/TTS/浏览器无类似统一网关人类类比Hermes 自由职业者背着一个大工具箱工具箱Registry→ 每个工具有独立的锁check_fn → 钥匙到了才能用 → 没有预设场景遇事现找工具 → 6 种不同工作台终端后端可选OpenClaw 管理者有预设的办公桌办公桌Profile→ 按角色分配文件夹和权限 → 你是 coding 岗拿 coding 钥匙 → 开箱就有常用工具不需要配 → 想用特殊设备填申请审批流Hermes 越干工具越多但每个工具自带锁钥匙不到位就是摆设。OpenClaw 开箱配好了一套工具按身份和场景渐进放开。选择指南场景更推荐需要多种终端执行环境本地 容器 远程 云端Hermes6 种后端需要精细化的身份/通道权限控制OpenClawProfile Allow/Deny开箱不想配太多默认就能干活OpenClawcoding profile经常加新工具想写文件就生效Hermes.py 自动注册需要社区插件生态捡现成的OpenClawClawHub已经配了 MCP 服务器两者都支持无显著差异想一个订阅覆盖所有工具能力HermesTool Gateway小测验对你的 Hermes 运行hermes tools数数当前启用了多少个工具集对照 OpenClaw 的 Profile 表看你的需求更靠近 coding 还是 full思考如果你的 Agent 有一个能力没发挥出来——是因为它没有这个工具还是因为工具被过滤/没配钥匙下期预告文章内容感知系统篇AI Agent 怎么接收外界信息——视觉分析、语音合成、文档理解感知管道在 Agent Loop 中的位置信息源声明Hermes 信息来源Tools Toolsets、Tools Runtime、Tool Gateway、Architecture、本地 config.yaml 及hermes tools实测输出OpenClaw 信息来源docs.openclaw.ai/tools、docs.openclaw.ai/gateway/config-tools、本地 OpenClaw 运行时文档Hermes 当前实例0.18.2CLI 工具集 17/25 启用Dify MCP 已接入本文以 Hermes 的分析框架为主线组织融合 OpenClaw 的视角进行对比。两个 Agent 的完整独立版本可从各自工作区获取。