之前，我在头条发了一篇体验文，讲我用 Hermes Agent 半年后的思考：技能只进不出、旧规则绑架结论、越跑越慢。评论区有一条留言格外扎眼：
"可悲啊，网关型 agent 和工具型 agent 是不一样的用法。"
我盯着这条看了很久。
不同类型的 Agent 怎么搭
说实话，他戳到的点是对的——我确实是拿"工具型"的尺子，去量一个"网关型"的产品。但"用法不一样"这五个字，解释不了另一半问题：为什么治理缺失会致命。
所以这一篇，我不写情绪，写方法论。我半年的代价，本质不是选错了产品，是分层没搭对。这篇文章要回答的就一件事：网关型和工具型，到底该怎么搭。
一、先把两个词说清网关型 vs 工具型
网关型 Agent这不是我发明的概念。OpenClaw 的官方架构文档里有一句原话："Gateway 是永远在线的控制面，助手才是产品。" 网关自己不是 AI，它是让 AI 能被够得着的那层基础设施。
分工很干净。网关负责：渠道连接、消息路由、会话持久化、鉴权、定时任务、工具执行调度、配置热加载。Agent 内核负责：LLM 调用循环、上下文组装、流式响应、工具调用决策。
而工具型智能体是无状态的：每次调用从干净上下文起步，退出即销毁，重用几乎零成本。
一句话对照：网关型是永远在线的门房，工具型是随叫随到的工班。
二、三种设计取舍，没有标准答案为什么会有这两种东西？因为业界的头部产品在这条路上做了三种完全不同的取舍。
取舍一：网关是"核心"还是"入口"。 OpenClaw 把网关做成整个系统的神经中枢；Hermes 把它做成薄薄一层适配层，真正的逻辑在 Agent 本体；Claude Code 一开始干脆没有网关，需要时再接。
取舍二：永远在线，还是按需启动。 OpenClaw 和 Hermes 都设计成跑在服务器上常年运行——"Agent 是数字员工，不上班的时候也得在岗"。Claude Code 依赖本地机器，机器关了它也关——"Agent 是工具，不用的时候不需要在线"。永远在线的代价是运维成本和安全暴露面；按需启动的代价是失去主动性：不能定时跑，不能在你离开时继续。
取舍三：默认开放，还是默认拒绝。 OpenClaw 历史上曾出现过 13.5 万个暴露在公网的实例；Hermes 用 fail-closed 的默认值把这个风险从架构层挡掉，代价是初次配置要多麻烦一步。
三种取舍指向的其实是同一个问题：你希望 Agent 是你召唤的工具，还是替你持续工作的员工。 答案不同，用法就该不同。那位读者说"用法不一样"，就这一点而言，他是对的。
三、只用一种，两边都会难受但"用法不一样"救不了我。因为我犯的错不是选型，是只用了一种。
只用网关型，就是我上一篇算过的三层账：技能只进不出，旧规则绑架结论，越跑越慢。这里补一句更狠的：网关型犯的错是复利的。 因为它常驻，前一次的错误会写进记忆和技能，污染此后每一次对话。
只用工具型呢？每次都得从头教，没有沉淀，同一个坑反复踩。而且它跑不了长任务——无状态的东西没法跨小时、跨天接着干，没法在你睡觉时继续，更没法在中途停下来等人批。它不会变笨，但也永远不会变熟。
一边缺治理，一边缺记忆和主动性。就算只算钱，这笔账也一样：网关型前期投入高，但规模化之后边际成本是往下走的；单体前期便宜，可一旦端数和 Agent 数量涨起来，隐性成本就会一路上升。很多人不是没想过搭，是被前期那笔投入吓退了——结果用单体的方式去跑一个常驻的东西，两头的好处没占到，两头的账倒都认了。
结论很清楚：要的是配合，不是二选一。
四、正确姿势是分层：业界已经收敛出两个模型怎么配？业界其实已经收敛出了两个可参考的模型。

模型一：无状态工人 + 持久化状态。 执行单元保持无状态——好扩展、好重试、崩了重开；状态不放执行单元里，放在外面持久化。这正是"网关管状态、工具管干活"的理论版本。
模型二：控制面与数据面分离。 控制面有状态：会话持久化、按 agent 的授权、记忆块、可观测性、成本归属。数据面无状态：快速路由、协议转换、供应商故障切换、按次计费。业界的原话大意是：你不能既给数据面加上治理、又不拖慢它。
这句话有多实在，可以算一笔账：网关的开销是会累积的——每次调用多 7.5 毫秒，一个任务 16 次工具调用，就是 120 毫秒白白蒸发；而压到 0.1 毫秒，用户就完全无感。这就是为什么治理要放在控制面，而不是塞进每一次调用里。
五、四层落地模型把两个模型叠到一起，就得到了下面这张表——本文最有收藏价值的部分：
四层落地模型
层
谁干
放什么
绝不能放什么
门房层（网关）
常驻的网关型
接入口、记上下文、判断"这事该谁干"、派活、汇总
不存全部工具、不自己写文件、不给写权限
工班层（工具型）
一次一用的工具型
确定性子任务：抓取、编码、生成、格式转换
不留长期记忆、不跨任务累积状态
记忆层
分四类存放
工作记忆（当前上下文）/ 情景记忆（历史摘要，带 TTL）/ 语义记忆（知识检索）/ 程序记忆（可复用的成功步骤）
技能不要直接堆在网关脑子里
治理层
人 + 规则
谁清理、谁审批、谁留痕、什么时候过期
不能默认放行
这里有一个关键洞察：所谓"技能"，本质是"程序记忆"——缓存下来能复用的成功步骤。 业界框架大多不原生提供这个能力，谁自己攒，谁就得自己管。这句话直接解释了我上一篇为什么翻车：我把程序记忆交给了最不该自己管的那一层。
六、三个场景，具体怎么搭怎么搭
场景一：早报/巡检。 网关定时触发 → 并行派给几个工具型去抓，各自无状态、失败可单独重试 → 网关汇总成一份 → 人工扫一眼发出去。谁触发？网关。谁执行？工班。谁收口？还是网关。 产品对位：门房用 OpenClaw 或 WorkBuddy；抓网页的工班用 browser-use 这类工具型。
场景二：内容生产。 网关定选题和结构 → 工具型分别写稿、生成配图，每次独立、可重跑 → 人审 → 网关归档，并记住"这个号的口径"。注意：长文别让常驻的网关自己一口气写，它背着太多记忆，写出来容易串味。 产品对位：门房用 WorkBuddy（接渠道、管发布），写稿工班用长上下文好的编码型（如 Claude Code），具体分工可以参考我那篇《市面前 8 的智能体，怎么搭才不浪费钱》里的方案五。
场景三：改代码。 网关拆需求 → 工具型（编码 agent）在沙箱里改、跑测试 → 评审 → 结论回写给网关。关键就一句：给工具型的是仓库权限，给网关的只是"知道仓库在哪"的权限。 产品对位：门房用 OpenClaw，异步交付的活丢给 Codex 这类云端工班——人走开，回来看结果。
七、四条硬规则，当晚就能改技能不落在网关，落在可失效的程序记忆层。 每条带三个字段：来源（哪次任务产生的）、最后使用时间、过期时间。没有过期时间的技能就是负债。网关只保留路由表，不背全部工具。 上下文预算要留给当前任务，不是留给家当清单。权限单向。 网关只能"申请"，不能"直接写"；破坏性操作走执行面的沙箱 + 独立确认。每次写记忆留来源。 几个月后要能回答"这条事实当初从哪来的"。行业里的做法是把 lineage 附在每次记忆写入上，把保留期和过期写进 schema，而不是事后再补。八、还没上手的：今晚就能走的三步前面都是给已经开张的人看的。如果你两样都没配，别从架构开始，从这三步开始。
第一步：先立一个门房，只立一个。 愿意折腾就自托管 OpenClaw，不想碰命令行就用 WorkBuddy 这类成品入口。装完只做三件事：接一个你天天在用的聊天渠道、建一条定时任务、写一条"什么活派出去"的路由规则。别的先不碰——门房的价值在这一步就已经兑现了。
第二步：挑一个确定性任务，派给工班。 标准就一条：每天重复、失败重跑成本低的。抓一次数据、转一个格式、生成一份日报，都行。千万别一上来就派开放式任务——工班的价值是稳，不是聪明。
第三步：给程序记忆立账本。 从第一个技能沉淀开始就带字段，一张 markdown 表都能当账本：
技能：头条封面生成
来源：2026-10-22 封面任务
最后使用：2026-10-29
过期：2027-01-22（90 天）到点没用、没续期，就当它失效。记住第七节那句话：没有过期时间的技能就是负债。
三步走完怎么验证搭对了？看第三周：门房的记忆量有没有失控增长？工班有没有留下不该留的状态？账本里有没有超过 30 天没用又没过期的条目？三个问题都答"没有"，你的分层就立住了。
九、一张决策清单：什么时候其实不用上网关只用工具型就够：原子任务、要求低延迟、不需要跨天、出错重跑成本低——分类、抽取、格式转换、一次性问答、单文件改写。
必须上网关：多端同时在线、要定时或事件触发、任务要跨小时跨天、要中途等人审批、要留痕可审计。
中间态怎么办：如果你现在是"单体"，但已经出现多端状态不一致、调度逻辑散在各处——先抽一个薄薄的转发层，管连接和会话路由；再把定时任务和事件回调逐步上移。 别一次性重写。
收尾回到那条留言。"可悲啊"这三个字里，真正成立的判断不是"你选错了产品"，而是"只配一种，就该挨说"。
门房和工班，从来不是一个岗位。一个负责"知道该干什么"，一个负责"把它干完"。
能力差距不在你选了哪家，在你有没有把不同的伙计合理调配使用。#AI智能体##多智能体##开源AI##智能体#