Hermes v0.10.0 发布后我第一时间在测试环境里把它跑了起来折腾了两天最有感党的更新就是 Tool Gateway 工具网关。以前调 Agent 能力最头疼的不是模型有多聪明而是工具链一多就乱谁注册的工具、参数格式对不对、超时重试怎么处理、权限边界在哪全都靠人肉约定。v0.10.0 把这一层彻底收拢了用一句话说Tool Gateway 就是所有工具进出的唯一收费站。这篇内容适合正在做 Agent 应用、想把工具调用管起来、或者想知道 Hermes 新版本怎么落地的同学。我尽量把版本里能直接上手的能力拆细讲透也把我在本地和服务器上实测踩过的坑一并写出来。1. 工具网关是什么先搞清楚它解决什么问题1.1 Agent 工具调用的混乱局面工具网关不是什么新概念微服务时代大家就用过 API Gateway。但 Agent 场景里的工具网关其实更复杂它面对的是一批“描述型接口”参数不是强类型而是通过自然语言描述交给模型去理解。传统做法是每个 Agent 进程直接加载一堆 Python 函数调 DeepSeek 这类模型时把函数名、参数 schema、自然语言描述一股脑塞进系统提示词里。表面看没啥问题等工具数量超过二十个、多人协作、还要接 MCP 服务端的时候痛点就全出来了。我自己遇到过的具体问题可以列一串多个不同协议的适配——有的工具是 OpenAI Function Calling 风格有的是 Claude Tool Use 风格还有的是 MCP server每个都要写一套胶水代码权限控制基本靠自觉——进程里所有工具都能被 Agent 调用没有任何审批和边界一个写死的删除接口和一个只读查询接口对模型来说是平等的隔离性差——出错的工具函数直接把整个 Agent 进程拖垮一次工具调用崩溃整个对话就没了测试困难——想替换某个工具的实现必须改代码重启服务灰度发布想都别想。这些问题的根源在于模型驱动的工具调用天生具有不确定性和动态性而过去的架构还在用“进程内函数 import”这种静态方式应对自然会越用越乱。1.2 工具网关的定位与核心收益Tool Gateway 把工具调用拆成三层模型层只维护对话与决策网关层负责注册、路由、执行、鉴权工具层只实现具体业务。这样的拆法带来的第一个直接收益是模型不再直接控制任意代码。模型通过网关发起请求网关校验参数、检查权限、路由到具体的工具实现中间多了明确的边界幻觉和乱调用的杀伤力被大幅削弱。第二个收益是工具变成独立部署单元。工具实现可以是一个子进程、一个容器、一个远程服务甚至是别人搭好的 MCP server统一挂到网关后面。网关做流控和熔断任何一个工具失效都不会拖垮整个 Agent。第三个收益是调用轨迹统一沉淀。以前调试一个 Agent 应用最痛苦的是不知道模型为什么调用了一个工具、传了什么参数、执行结果是什么。走网关之后每一次工具调用都有结构化日志request_id 贯穿全链路排查问题从“猜”变成了“查”。打个比方网关就是大楼里的总线系统每个房间的设备想通电通网必须插到统一的接口上管理员能看每一路电流也能单独切断某个房间的闸这种可控性对生产环境是刚需。总而言之v0.10.0 的 Tool Gateway 解决的不是“能不能调用工具”的问题而是“怎么安全、规范、可持续地管理工具调用”的问题。对个人开发者来说它让配置代替编码对团队来说它把工具调用变成了可审计、可治理的基础设施。1.3 为什么这个版本才推出有人可能会问工具网关这么有用为什么 Hermes 到 v0.10.0 才正式推出我根据 changelog 和实际使用推测主要是因为底层抽象没有成熟之前硬抽一层网关只会更乱。v0.8 之前 Hermes 的工具调用逻辑还是散落在各个 Agent 实现里v0.8 到 v0.9 内部一直在重构“工具描述—执行”抽象层把工具的声明方式统一成 JSON Schema把执行链路改成可插拔。到 v0.10.0 这个抽象层基本稳定再往上挂一个统一入口就是水到渠成的事。另外MCP 生态在这大半年里逐步成熟大量开源的 Model Context Protocol server 涌现能对接的工具提供方变得非常丰富。当“外部工具”比“本地函数”还多的时候单独抽一层网关才有真正的价值。需要注意的是这里提到的 Hermes v0.10.0 是指核心网关运行时版本和有些朋友在用的 Hermes Agent v0.21bot mode、Hermes Desktop 桌面版并不是同一个东西。网关是底座桌面版和 Bot 模式是上层使用形态理解清楚这个关系后面配置起来才不会晕。2. 工具网关能力集全景拆解2.1 工具注册与描述标准化Tool Gateway 的第一个核心能力是把所有工具收敛成一份标准化声明。无论工具底层是什么语言、什么协议在网关里的表达形式统一为四个要素工具名、自然语言描述、输入参数 JSON Schema、输出格式说明。这四个要素里面最容易低估的是自然语言描述的重要性。我在本地注册过一个订单查询工具一开始描述写的是“查询订单”结果模型死活不主动调用。后来我把描述改成“根据订单ID或客户手机号查询订单状态、物流信息和退款进度。当用户询问‘我的订单现在到哪了’‘什么时候发货’时调用此工具”效果立刻不一样。原因是模型选工具的时候不是靠函数名匹配而是靠语义匹配描述越贴近真实业务场景命中率越高。JSON Schema 负责的是参数强校验模型传进来的参数在网关侧就会被挡一道不合法的请求直接返回修正提示给模型而不是把错误带到工具实现里。配置文件里大致是这个形态tools: - name: order_query description: 根据订单ID或手机号查询订单状态、物流信息。当用户询问订单物流或退款进度时调用。 parameters: type: object required: - order_id properties: order_id: type: string description: 订单号21位数字 phone: type: string description: 下单手机号用于辅助校验 output: type: object properties: status: type: string logistics: type: string这里要特别注意参数 description 也是给模型看的不是给人看的。“订单号21位数字”这种表达能让模型在缺少参数时主动追问用户而不是瞎猜一个值填进去。注册环节做扎实后面整个调用链路都会顺畅很多。2.2 统一路由与协议适配注册之后就是路由。Tool Gateway 内部维护着一张工具路由表请求进来后按工具名做精确匹配。但真正体现网关价值的是协议适配层它把 OpenAI Function Calling 风格、Claude 的 tool use block、MCP 的 tools/call、Hermes 自研 SDK 的调用统一翻译成内部标准协议。协议适配层做在最前面有好有坏。好的一面是上层 Agent 始终面对一套协议换工具实现不影响 Agent 侧的代码坏的一面是每一层协议转换都可能丢字段。我实际测试下来最简单可靠的适配策略是先转成内部统一 JSON 格式再统一进路由绝不在各个协议之间直接互转。比如 OpenAI 风格的 tool_call_id 在 MCP 里没有对应概念如果你从 MCP 直接转 OpenAI 格式继续往下传后续的上下文管理会非常别扭。先落到内部格式你至少知道哪个字段缺失了、是在哪个环节缺失的。路由层面还有一个值得说的点调试用的 mock 路由。生产环境调一个真实工具可能需要真实数据、需要花钱调用外部 API但在开发环境你希望有一个永远返回固定结果的影子工具。网关支持把某个工具名直接路由到本地 mock 注册项这让 Agent 联调可以完全脱离真实依赖我自己做 CI 的时候就是靠这个能力跑通全链路的。2.3 权限与安全边界工具网关要解决的另一个核心问题是权限。Agent 场景下的权限模型和传统 API 网关不太一样传统网关鉴权对象是用户而 Agent 场景里有一个额外的概念代表“Agent 的意志”发起调用。也就是说就算当前用户合法也不能让模型拿着用户身份去调用任意工具必须区分用户级权限和工具级权限。在 Hermes v0.10.0 里工具在注册时就可以声明自己需要的权限组常见的权限组可以自己定义比如query只读查询、mutation写操作、admin高危管理操作、ext外部API调用。调用链路上网关会校验调用方是否具备对应该工具权限不通过的直接拒绝并把拒绝原因返回给模型让模型转述给用户而不是简单丢一个 401 了事。我在配置里实际用过这样一段声明tools: - name: order_cancel description: 取消未发货订单。仅在用户明确表达取消意图并二次确认后调用。 permissions: - mutation - ext这里“二次确认”虽然是写在描述里的但权限配置上是硬性的。生产环境中我还建议开一个配置项让 mutation 和 admin 类工具的调用必须二次确认。也就是说模型发起调用后网关并不立即执行而是把这个调用请求推给用户确认用户点击放行之后才真正执行。这个“人在回路”的机制虽然会降低自动化率但在涉及资金、生产变更、数据删除的场景里是保命的设置。2.4 上下文管理与流式转发很多 Agent 框架在工具调用上能跑通但流式体验稀烂。原因是模型端的一次 function call 会被展开成多次子调用模型先输出一段自然语言然后输出一个工具调用块工具执行完把结果送回模型模型再继续输出。用户面对的就是一顿一卡的体验——先是模型说“好的我看一下”然后卡三秒再继续输出。Tool Gateway 对这个问题的处理是在网关层维护请求的上下文关联每次工具调用都带着同一个 request_id流式通道支持中段消息拼接和事件转发。通俗点讲网关相当于给一条会断断续续的水管加了储水罐和分流阀。模型生成的文本流可以先被网关缓冲一段工具调用的中间状态以事件形式推给前端前端拿到之后先展示“正在查询订单”之类的过程提示等工具结果返回模型继续生成文本时再续上流。整个过程对用户来说是连贯的不会被一个长达五秒的工具调用干瞪眼。但流式转发也有代价缓冲策略会影响首字节延迟和吞吐量。我的经验是对小于 2000 字的中短文本不用额外缓冲对工具调用这种可能超过 10 秒的长操作才需要把之前的文本块 flush 出去。网关把这两类策略都做成了参数text_stream 和 tool_stream 可以独立配置实测下来同时开两个通道比混在一个通道里省去不少前端解析的麻烦。2.5 MCP 接入与生态复用v0.10.0 里最受关注的一个能力就是把 MCP server 直接挂到网关上。MCP 是 Model Context Protocol 的缩写用来统一连接外部数据和工具服务。现在社区里有大量现成的 MCP server覆盖文件系统、数据库、浏览器操作、开发工具、知识库检索、项目管理工具等。Tool Gateway 做了一层 MCP 适配器你只需要在配置里声明一个 mcp server 的地址和协议网关启动时会自动拉取它的工具列表把每个工具映射成标准的工具声明直接注册进路由表。这个能力强在“自动暴露”上。以前接一个 MCP server你要先自己看它的文档把想做暴露的工具一个个手写封装函数现在只要在配置里加入一个 endpoint工具就自动出现在模型的候选列表里了。配置大概长这样mcp: servers: - name: file_system url: http://127.0.0.1:9000/mcp enabled: true allowed_tools: - read_file - list_directory - name: knowledge_base url: http://10.0.0.8:9000/mcp enabled: true auth: type: api_key key_env: KB_API_KEY要注意allowed_tools 可以限制网关只暴露这个 MCP server 里的部分工具而不是把人家全部能力都铺给模型。工具越多模型选择准确度就越低在网关层做白名单过滤是非常必要的。2.6 可观测性日志与追踪最后一块核心能力是可观测性。Tool Gateway 对每一次工具调用都输出结构化日志我抓一条实测的日志贴出来给大家感受一下{ request_id: tg_01J3KQ8Z2R6X9C0V5M4P3N2B1A, ts: 2025-11-20T10:23:15.412Z, tool_name: order_query, duration_ms: 231, status: success, params: {order_id: 2025112012345678901}, model: deepseek-chat, route: registry }日志字段里最值得关注的是 request_id、duration_ms 和 status。通过 request_id 可以把一次对话中的多轮工具调用串起来把“模型决定调用—网关路由—工具执行—结果返回”当成一条链路分析。网关还内置了 OpenTelemetry 支持可以把链路数据导出到 Jaeger、Tempo 这类工具里做跨服务追踪。如果你只是一个人调试那看 JSON 日志就够用了生产环境有多个服务协作建议还是把 trace 导出开起来。延迟数据的价值也很大。你很快就能发现慢的往往不是模型而是某个工具背后的外部 API。我之前查过一个“查询用户余额特别慢”的问题逐条看日志发现 95% 的时间都花在调用老系统的 HTTP 接口上和模型、网关都没关系。这个结论在以前没有日志体系的时候至少得猜半天。3. 从零接入让第一个工具跑起来3.1 环境准备与安装部署先准备环境。Hermes v0.10.0 服务端依赖 Python 3.11 和 Node.js 20网关本体是服务端程序Agent 和桌面版是客户端程序。我这里给最常用的安装方式。Ubuntu 环境下我用的是 pip 安装方式sudo apt update sudo apt install -y python3.11 python3.11-venv nodejs npm python3.11 -m venv /opt/hermes source /opt/hermes/bin/activate pip install hermes-runtime0.10.0 hermes init my-gateway cd my-gateway hermes gateway startWindows 环境其实更省事直接装 Hermes Desktop 桌面版它可以作为网关的宿主也可以作为客户端连接远程网关。如果你像我一样习惯在 Windows 上写本地脚本把工具跑在本地再用网关统一管理也完全没有问题。需要提醒一点Hermes 桌面版装好之后如果遇到无法更新的情况绝大多数不是软件本身的问题而是本地网关进程占用着旧版本的数据目录。先把 hermes gateway stop再执行更新成功率会高很多。模型侧配置方面我自己用的是 DeepSeek 的 API配置在网关的 config.yaml 里只要接口是 OpenAI 兼容格式的都可以直接对接。DeepSeek 系列的模型在工具调用场景下表现比较稳函数调用参数命中率好这也是社区里不少人把 Hermes 和 DeepSeek 绑定在一起用、到处搜相关教程的原因。3.2 编写一个真实的工具清单安装好之后第一步就是注册工具。用最经典的“订单查询”来示例。在 my-gateway 目录下新建一个 tools.yaml内容如下tools: - name: order_query description: 根据订单ID或手机号查询订单状态、物流信息和退款进度。用户询问订单物流、发货、退款进度时调用。 type: async timeout: 10s permissions: - query endpoint: type: http url: http://127.0.0.1:9100/query_order method: POST parameters: type: object required: - order_id properties: order_id: type: string description: 订单号 phone: type: string description: 下单手机号选填注意这里我把工具的 endpooint 指向一个本地 HTTP 服务也就是说工具实现可以是任何语言写的 HTTP API。这是网关的设计取向业务实现完全与 Agent 运行时解耦只要你提供 HTTP 接口网关就能把它变成 Agent 可调用的工具。3.3 网关配置核心项接下来修改 config.yaml。这个文件是网关的大脑需要指定的内容分成几块模型接入、工具清单、MCP server、权限策略、限流策略。server: port: 8787 auth: api_key_env: HERMES_API_KEY model: provider: openai_compatible base_url: https://api.deepseek.com api_key_env: DEEPSEEK_API_KEY model_name: deepseek-chat registry: tools_file: tools.yaml auto_reload: true mcp: servers: - name: file_system url: http://127.0.0.1:9000/mcp enabled: true rate_limit: default_qps: 5 burst: 10 sandbox: enabled: true tmpfs_size: 256M net: false其中 auto_reload 设为 true意味着你在 tools.yaml 里新增工具网关会在几秒内自动加载不用手动重启。开发时非常爽但生产环境建议把它关掉改成手动 reload避免配置错误被自动加载到线上。3.4 打通一条完整调用链配置完成启动网关hermes gateway start然后写一个最简单的 Agent 脚本让模型自己去调用工具。Python 侧大致是这样from hermes_runtime import Agent, GatewayConfig agent Agent( gateway_urlhttp://localhost:8787, api_keyYOUR_HERMES_API_KEY, modeldeepseek-chat, ) resp agent.chat(帮我查一下订单 2025112012345678901 现在到哪了) print(resp)跑起来之后网关日志会依次出现模型请求进来、模型选择了 order_query 工具、网关路由到本地 HTTP 接口、工具返回结果、结果回传给模型、模型生成最终回复。整个过程大概两三秒。如果你希望语句不通顺、卡顿明显重点检查两个地方一是模型侧的工具描述是否被正确发送二是在线节点有没有把工具超时时间设得太短。3.5 桌面版接入小记如果你用的是 Hermes Desktop 桌面版接入网关其实比写代码更快。桌面版在“设置 - 工具网关”里填入网关地址和认证密钥就能连上同一个工具库。桌面版的优势是可视化查看每次调用的参数、结果和耗时对调试助手类应用特别方便。桌面版和 Bot 模式的区别在于桌面版是有界面的人工交互形态Bot 模式一般指无人值守的自动任务比如定时执行、消息队列消费、自动回复。v0.21 的 bot mode 其实是把 Agent 封装成了无界面服务它同样依赖 Tool Gateway 去调用工具。我目前的做法是本地调试用桌面版生产跑批用 Bot 模式两套都指向同一个网关节点的不同命名空间互不干扰。4. 生产环境不能回避的硬骨头4.1 工具爆炸与命名空间治理工具多起来之后第一个遇到的问题就是“工具选择质量下降”。当候选工具超过三十个模型开始频繁选错甚至把相似工具搞混。这不是模型能力不够而是工具描述之间的区分度过低。两个工具都叫“查询X”描述里都是“当用户询问X时调用”模型不晕才怪。我的建议是给工具做命名空间管理。Tools 名称统一带上业务前缀比如 order_query、logistics_query、user_query避免语义重叠。同时网关支持按会话或按 Agent 维度屏蔽某些工具比如客服机器人只需要 order_query 和 user_query就不要让它看到 admin 类接口。这个叫“最小工具集”原则按场景只暴露必要的工具模型选择准确率会显著提高。4.2 参数校验与错误重试生产环境最怕的不是“模型不调用工具”而是“模型调用完工具工具炸了”。网关内置的 JSON Schema 校验可以在入参阶段拦截掉格式错误的请求但校验失败时的反馈方式会影响模型能否自己纠错。我实测过两种返回方式。第一种是返回“参数错误”模型收到后完全不知道该怎么改。第二种是返回“order_id 字段缺失订单号应为21位数字请向用户确认订单号后再调用”模型就会主动向用户追问补充信息而不是干巴巴地报错。这看起来像是提示词工程其实是网关的错误信息设计问题。正确的做法是校验错误输出里不仅包含错误原因还包含“给模型看的修正指示”让模型有机会自己修复。重试策略上幂等工具可以开启自动重试非幂等的不要开。订单查询是幂等的网络超时重试一次没问题订单取消这种操作如果重试可能造成重复取消。网关里每个工具都可以单独配置 retry_times 和 retry_interval默认值我给的是 2 次、250ms 间隔。4.3 性能与并发控制很多人以为工具网关会成为性能瓶颈其实恰恰相反网关通常是整个链路里最轻的一环。真正吃性能的是模型 API 和工具本身的业务逻辑。不过网关侧仍要关注两个参数并发上限和队列长度。我给自己的生产关卡设置的经验值是单网关节点 qps 控制在 5突发上限 10队列长度 200。超过队列长度的请求直接快速失败返回 429让上游 Agent 感知重试。注意应用层需要识别 429并做退避不要傻乎乎地满速重试否则会把网关打成雪崩。工具本身的冷启动也要考虑尤其是容器化的工具首次调用要等镜像拉起我一般给这类工具配上 15 秒以上的超时时间然后在启动阶段做预加载。4.4 安全加固的四个细节安全加固这一块最容易在开发环境下被忽视我踩过坑之后给自己总结了四个必查项。第一环境中不要存放明文密钥。网关支持从环境变量读取 API key比如上面的 key_env 配置不写在 yaml 里。第二工具描述和日志里不要塞敏感信息。日志会记录参数如果用户把身份证号传进去那条日志就变成了敏感数据建议在日志配置里开启字段脱敏对 phone、id_card 这类字段做掩码处理。第三对模型输出的工具名做白名单校验。模型有可能幻觉出“order_query_v2”这种不存在的工具名网关在路由之前先比对注册表未注册的请求直接拒绝防止把请求透传给其他内部服务。第四高危操作的工具执行进程尽量放在沙箱里限制网络和临时目录大小。Hermes 有一个 sandbox 配置项我建议所有非必要联网的工具都打开 sandbox。5. 常见问题与踩坑实录5.1 常见问题速查表这一节把我在使用 Tool Gateway 期间实际遇到的问题和排查方法整理成表方便大家快速定位。现象可能原因排查路径解决方案工具注册后模型不调用描述太简略或与场景语义不匹配查看网关日志确认工具是否已在自动加载中注册重写 description补充调用时机和典型句式调用工具时报参数校验错误模型生成的参数缺失必填字段查看日志里的 params 字段在参数 description 中增加格式说明让模型能追问用户流式响应中断或展示卡顿文本流与工具事件混用一个通道检查 text_stream 和 tool_stream 配置分通道转发前端分别处理MCP 工具全部不显示MCP server 地址不可达或鉴权失败启动时查看网关日志中的 mcp 连接记录先本机 curl 测试地址和鉴权方式桌面版无法更新到 v0.10.0本地网关进程占用数据目录手动停止 hermes gateway 再更新Windows 任务管理器结束 hermes 进程后重试Bot 模式调用工具报权限不足Bot 未配置对应权限组检查 bot 身份映射在网关配置中给 Bot 绑定工具所属权限组工具调用很慢但日志显示网关耗时很短慢在工具自身的 HTTP 接口按日志里的 endpoint 地址直接请求工具优化工具侧接口或做缓存5.2 踩坑实录工具描述太简略导致模型不调用这个坑我在 2.1 里已经提过但值得单独再讲一次。当时我写了一堆本地工具统一的描述都是“查询xx”像“查询库存”“查询价格”“查询优惠券”结果模型总是挑其中一个用甚至干脆说“我没有查询功能”。我一开始以为是模型 API 的问题后来把发出去的 system prompt 打出来才发现工具描述区有三十多个工具每个工具只有两个字“查询xx”模型根本没得选只能靠名称猜测。改法也很机械给每个工具写两三句“人话”讲清楚这个工具是干嘛的、什么时候用。描述里融入业务关键词之后比如“查询优惠券当用户询问折扣、优惠、满减活动时调用”模型的调用命中率从 60% 提升到 95% 以上。这个改进不花一分钱效果却极其明显。5.3 踩坑实录MCP 服务连接僵死接 MCP 服务的时候我遇到过三次“工具列表空白”的问题。第一次是地址写错了第二次是服务端需要鉴权而我漏配了第三次最隐蔽MCP 服务端能 ping 通但是网关起来之后再也没刷新工具列表。原因是我把 MCP 配置写在了一个不加载的 profile 里网关根本没有加载那个配置。排查方式就是看网关启动日志启动阶段会自动打印每个 MCP server 的连接状态和工具数量如果日志里没有对应条目多半是配置没被读进去。后来我把 mcp server 的 timeout 设置从默认的 5 秒调到了 30 秒因为有些 MCP 服务端在启动时会做初始化加载5 秒根本不够。这个问题在使用本地文件系统、代码仓库索引这类重 MCP server 时特别明显。5.4 踩坑实录CUA 模式下的权限配置Hermes 的 CUAComputer Use Agent能力在 v0.10.0 之后也有了新的变化。CUA 本质上是把鼠标点击、键盘输入、截屏观察这些“电脑操作”也注册成工具走网关统一调度。我实际跑的时候发现 CUA 类的工具经常提示权限不足。原因是 CUA 工具的权限组默认是 system而我的普通用户身份绑定的权限组是 user天然不匹配。解决方案是在网关配置里为用户显式分配 system 权限或者单独建一个 cua_operator 身份组。但说实话在生产环境我不会随便把 system 权限给用户尤其是涉及文件删除、执行命令这类工具时我会强制打开二次确认。CUA 场景下的确认界面会直接展示“将执行移动鼠标到坐标(123,456)并点击左键”虽然很啰嗦但至少不会让 Agent 在用户不知情的情况下点掉关键弹窗。6. 还能怎么玩进阶扩展思路6.1 把网关变成团队内部工具市场单机玩转 Tool Gateway 之后你会发现它最大的潜力是成为一个“内部工具市场”。你可以在网关的 registry 里注册一批面向业务的工具比如查询订单、查询库存、计算运费、生成对账单。团队里的其他开发者、其他 Agent 服务只要拿到网关的访问密钥就能复用这些工具而不用重新从零封装。工具实现更新时只需要更新网关与工具服务之间那个接口所有下游 Agent 自动受益。我最近正在做的一个内部项目就是把网关的注册表同步到团队 Wiki让运营同学自己在后台申请工具权限。网关支持 admin API可以动态注册、下线工具这一步做成界面之后工具治理就从“开发写代码”变成了“平台运营”。6.2 与 Bot 模式和 CUA 结合做自动化流程顺着网关的思路继续往下想Bot 模式和 CUA 结合之后可以做很有意思的自动化流程。比如一个定时任务每天早上十点Bot 模式拉起 AgentAgent 先通过 Python 工具读取昨天的销售报表再用 CUA 工具打开内部系统网页把数据填进报表页面最后点击提交。整个过程人类只需要在关键提交动作那一步做一次二次确认。这个场景里Tool Gateway 的价值在于让所有操作都留下了痕迹。每一条工具调用都有日志、权限校验、超时控制就算 Bot 模式被注入了恶意指令攻击者能调用的也仅仅是注册表里白名单内的工具而操作者的每一个动作都逃不过审计日志。最后分享一个我在实际使用中的体会工具网关这种东西刚开始搭的时候觉得繁琐多个文件、多一层配置、多一堆日志但随着工具数量增长它会变成你最省心的部分。我现在新写一个工具业务第一件事就是写好 schema 和描述挂到网关而不是直接把函数塞进 Agent 脚本里。这套习惯一旦建立起来Agent 项目的复杂度再翻一倍你都不会觉得乱。