从Gateway到Learning Loop：AI Agent的两种架构范式

“架构不是技术细节的堆砌，而是对AI本质的理解。你认为AI是服务、工具还是伙伴，决定了你的架构选择。“

核心观点 / 起源

一个架构师准备为团队构建AI编程助手。他下载了ClaudeCode、OpenClaw、Hermes Agent的源码，打开后愣住了。

ClaudeCode的核心是一个100KB+的replBridge.ts，负责本地终端与云端API的桥接。OpenClaw的核心是Gateway模式，20多个消息平台统一接入。Hermes Agent的核心是Learning Loop，Agent从每次执行中学习并生成新技能。

三个都是AI编程助手，为什么架构如此不同？

这不是技术细节的差异，而是对”AI Agent是什么”这个根本问题的不同回答。

ClaudeCode：远程桥接架构

打开ClaudeCode的源码，你会看到这样的架构：

本地终端 ←→ replBridge ←→ Anthropic API ←→ Claude模型
         (OAuth认证)    (会话持久化)

replBridge.ts是整个系统的心脏，100KB+的代码处理OAuth认证、消息双向传输、会话状态的云端持久化、网络异常的重连机制。

QueryEngine.ts管理对话流：构建系统提示词、调用工具（Read、Write、Bash等）、处理多轮对话、上下文压缩和管理。

coordinator/负责任务协调：多代理调度（Explore、Plan、General-purpose）、子任务分发、结果聚合。

这是一个典型的客户端-服务器架构。本地终端只是一个”瘦客户端”，真正的计算发生在Anthropic的服务器上。

ClaudeCode的架构回答了一个问题：如何让用户以最低成本获得最强AI能力？

答案是：把AI当作云服务。就像你不会在本地搭建AWS，你也不需要在本地运行Claude模型。你需要的只是一个终端，一个网络连接，剩下的交给Anthropic。

这带来了显著的优势：零本地资源需求（无需GPU）、自动扩展（高峰期自动扩容）、多端同步（CLI、Web、IDE插件共享会话）、企业级可靠性（SLA保障、24/7支持）。

但代价也很明显：网络依赖（离线无法使用）、延迟敏感（每次请求都需要网络往返）、数据上云（代码必须上传到Anthropic服务器）、供应商锁定（深度绑定Anthropic API）。

这是”计算即服务”的架构——把AI能力当作云服务消费，就像你消费AWS Lambda一样。

OpenClaw：Gateway模式

OpenClaw的架构完全不同：

消息渠道层 → Gateway统一协议 → Agent路由 → 工具执行 → 沙箱隔离
(20+平台)     (RPC协议)        (多实例)    (本地/远程)  (安全边界)

Gateway是核心。它做了一件事：把20多个消息平台统一成一个协议。

无论你从WhatsApp、Telegram、Discord还是CLI发消息，Gateway都把它们转换成统一的内部格式，路由到Agent实例。Agent处理完后，Gateway再把响应转换回对应平台的格式。

这带来了强大的灵活性：多渠道接入（WhatsApp、Telegram无缝切换）、多Agent路由（不同渠道路由到不同实例）、沙箱隔离（主会话信任，非主会话隔离）、DM配对机制（陌生人需要配对码才能访问）。

OpenClaw的架构回答了另一个问题：如何让用户完全掌控AI助手？

答案是：把AI当作本地守护进程。就像Nginx在你的服务器上持续运行，OpenClaw的Agent也在你的机器上持续运行。多个渠道连接到同一个Agent实例，但数据不离开你的机器。

这带来了不同的优势：隐私保护（代码可以完全本地处理）、灵活性（自选LLM、自定义工作流）、多渠道无缝切换、成本可控（可使用便宜的模型或本地模型）。

但代价同样存在：配置复杂度（需要设置多个渠道、选择模型）、维护负担（开源项目，需要自己解决问题）、能力上限（受限于所选LLM）、单点风险（Gateway成为关键路径）。

这是”自主托管”的架构——把控制权交给用户，代价是复杂度。

过程 / 推演

Hermes Agent：Learning Loop

Hermes Agent的架构更加激进：

用户任务 → Agent执行 → 提取经验 → 创建/改进技能 → 下次更好
         ↑                                              ↓
         └──────────── 持续反馈循环 ────────────────────┘

这不是简单的”执行任务”，而是一个闭环学习系统。

当你第一次让Hermes Agent部署Docker容器，它会摸索着完成。但关键在于：它会自动把这个过程提炼成一个”Docker部署”技能，持久化到本地。

下次你说”部署到staging”，它不需要重新思考，直接调用这个技能，零延迟。

更重要的是，这个技能会在使用中自我改进。如果你修正了它的某个步骤，它会更新技能定义。如果你在不同项目中使用，它会泛化技能逻辑。

这是通过三层记忆系统实现的：短期记忆（当前会话上下文）、工作记忆（任务相关的临时信息）、长期记忆（持久化的技能和知识）。

还有两个关键机制：Agent-curated memory（Agent自己决定记住什么）和Periodic nudges（定期自我提醒，巩固知识）。

Hermes Agent的架构回答了第三个问题：AI能否从经验中学习？

答案是：可以，而且应该。

传统AI助手的问题是什么？每次你问同样的问题，它都要重新思考。你教会它一个项目的架构，下次还得再教一遍。这是巨大的浪费。

Hermes Agent改变了这一点。它不是静态的工具，而是会成长的伙伴。

这带来了独特的优势：自我改进（30天后处理重复任务的速度比第一天快5倍）、个性化（自动适应你的工作方式）、零配置学习（从执行轨迹中自动提取）、轻量级（可以在$5的VPS上运行）。

但这也带来了新的挑战：成熟度风险（发布仅2个月）、质量控制（自动生成的技能可能有错）、不可预测性（行为随时间变化，难以审计）、学习曲线（理解闭环学习机制需要时间）。

这是”共同进化”的架构——AI不是工具，而是会成长的伙伴。

三种架构的本质差异

ClaudeCode的回答：AI Agent是一个远程服务。就像AWS Lambda，你调用它，它返回结果。状态在云端，计算在云端，你只需要一个终端。优势是可靠、强大、零运维，代价是依赖网络、数据上云。

OpenClaw的回答：AI Agent是一个本地守护进程。就像Nginx，它在你的机器上持续运行。多个渠道连接到同一个Agent实例。优势是隐私、控制、灵活，代价是配置、维护、能力受限。

Hermes Agent的回答：AI Agent是一个学习系统。就像人类助手，它从经验中学习。不是执行预定义的任务，而是创造新的能力。优势是适应性、个性化、进化，代价是不确定性、质量控制。

如何选择架构范式

**选择远程桥接（ClaudeCode），如果你：**需要最强的AI能力、团队没有运维能力、需要企业级SLA和支持、可以接受数据上云。

**选择Gateway模式（OpenClaw），如果你：**对隐私有严格要求、需要多渠道接入、有技术能力配置和维护、想要完全控制。

**选择Learning Loop（Hermes Agent），如果你：**有大量重复性任务、希望AI适应你的工作方式、愿意尝试新技术、能接受早期产品的不稳定性。

实际上，这三种架构并非互斥。未来可能出现的融合方向：ClaudeCode + 本地缓存（敏感代码本地处理）、OpenClaw + 学习能力（Gateway + 技能自动生成）、Hermes Agent + 云端模型（本地学习 + 云端推理）。

结语 / 反思

回到开头的问题：AI Agent应该如何设计？

答案取决于你认为AI Agent是什么。

如果你认为它是服务，选择远程桥接。把复杂度交给服务提供商，你专注业务。

如果你认为它是工具，选择Gateway模式。掌握控制权，代价是配置和维护。

如果你认为它是伙伴，选择Learning Loop。与AI共同成长，代价是不确定性。

架构不是技术细节的堆砌，而是对AI本质的理解。

ClaudeCode说：AI是强大的云服务。 OpenClaw说：AI是可控的本地工具。 Hermes Agent说：AI是会成长的伙伴。

你的选择，反映了你对AI未来的判断。