前段时间，公司的技术总监问我一个问题，为什么OpenClaw是用TypeScript开发的，而Hermes用的Python。当时问我的时候，我是有点懵逼的，从来没思考过这个问题。作为一个曾经多年的web工作者，现在从事AI应用工程的开发者。我给出的答案是，AI应用一端连接着大模型，一端连接着使用者。在传统的技术领域内围绕大模型的语言是Python，Python擅长数据处理、RAG等，而TypeScript是围绕着使用者的语言，拥有更好的接入生态，例如hooks，流式对话等。OpenClaw和Hermes是基于自身特征选择了不同的方向。 后来我回想起来这个问题，觉得自己的回答没有说到重点，所以我整理思路，写下这篇文章解答为什么两者选择了不同语言进行开发。
工程分层视角下的AI应用
要聊语言选择，还需要从工程分层角度讲起，我们可以将AI应用分成6个运行层和1个横切治理平面。如下表所示
| 层级 | 回答的问题 | 主要职责 |
|---|---|---|
| 1. 基础设施层 | 系统跑在哪里？ | 部署、容器、网络、算力、监控、扩缩容 |
| 2. 模型能力层 | 智能能力从哪里来？ | LLM、Embedding、Rerank、ASR、TTS、多模态 |
| 3. 数据与知识层 | AI 依据什么信息判断？ | RAG、文档、知识库、向量库、记忆、用户上下文 |
| 4. AI 编排 / Agent Runtime 层 | AI 如何完成任务？ | Prompt、Context、Workflow、Tool Calling、Memory 策略、Agent 状态 |
| 5. 业务服务层 | 业务规则和真实动作在哪里？ | 用户、权限、订单、工单、审批、项目、核心业务 API |
| 6. 交互体验层 | 用户如何使用 AI？ | Web、App、语音、IM、管理端、Chat UI |
| 横切：评估与治理层 | 如何证明它可靠、可控、可上线？ | 日志、评测、安全、灰度、成本、审计、人工兜底 |
依次说明6个运行层大致的工程内容，
第1层基础设施和第2层模型能力层属于开发者的低频关注区，这2个层级在一般AI应用开发层面都是使用第三方厂商，不会自研开发。
对于大多数的AI应用业务，工程工作集中在3-6层，其中第5层业务服务我认为是企业的原始业务能力的沉淀和延伸，就算不做AI应用，很多公司也有这样一层来做业务，以前叫API接口，现在AI 应用通常在第 4 层把这些业务能力包装成 Tool、Function Calling 或 MCP Server 给 Agent 调用；第6层交互体验层是UI交互的多样变种，本质是业务入口，在绝大多数场景下都不算重点（干web的都懂）；真正的工程核心是第3层数据与知识层和第4层业务编排、Agent Runtime层。工程核心中的第3层是偏执行的体力活，需要大量的时间和精力对数据进行组织治理；第4层业务编排层偏设计，是行业know-how的映射，业务核心逻辑。
最后说一说横切的评估与治理层，宗旨是提供 AI应用的全链路可观测性，但不同的AI应用关注的侧重点也不同，我们可以通过接下来的分析进行理解。
OpenClaw的工程重心
在OpenClaw的官网上，有如下的描述
What is OpenClaw?
OpenClaw is a self-hosted gateway that connects your favorite chat apps and channel surfaces — built-in channels plus bundled or external channel plugins such as Discord, Google Chat, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp, Zalo, and more — to AI coding agents like Pi. You run a single Gateway process on your own machine (or a server), and it becomes the bridge between your messaging apps and an always-available AI assistant.
OpenClaw 是一个自托管 Gateway 网关，可将你常用的聊天应用和渠道界面——包括内置渠道，以及 Discord、Google Chat、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo 等内置或外部渠道插件——连接到像 Pi 这样的 AI 编码智能体。你只需在自己的机器上（或服务器上）运行一个 Gateway 网关进程，它就会成为你的消息应用与一个始终在线的 AI 助手之间的桥梁。
OpenClaw将自己描述成自托管的Gateway网关，回到前文所说的6个层运行，Gateway应该归类到第4层的Agent Runtime里，OpenClaw关注的典型对象是channel、event、routing、plugin、node，总结来说OpenClaw工程关注点是连接状态，举几个典型场景案例
用户在哪个通道？
消息属于哪个 thread？
哪个 device node 在线？
哪个插件提供哪个能力？
哪个 tool 暴露给哪个 agent？
事件如何路由？
OpenClaw 的风险是连接系统不可靠，常见的失败模式是消息丢失、通道断连、事件乱序、插件冲突、权限泄露、节点失联等。
在评估与治理层，OpenClaw中的关注点方向如下
| 治理对象 | OpenClaw |
|---|---|
| 权限治理 | 通道权限、设备配对、插件授权 |
| 日志治理 | 消息事件、连接状态、tool 调用 |
| 安全治理 | 外部通道、节点、插件、sandbox |
| 质量治理 | 消息是否送达、工具是否可用 |
基于以上的内容，在工程视角的第4层Agent Runtime中OpenClaw可归纳成 Gateway Runtime，解决的核心问题是Agent 如何接入外部系统。
理解了OpenClaw的主要诉求，将OpenClaw的诉求与TypeScript的技术生态做一个对应
| OpenClaw Gateway 需求 | TypeScript生态优势 |
|---|---|
| 大量 WebSocket / HTTP / Event | Node 异步 IO 成熟 |
| 多通道消息对象 | TS 类型系统适合约束 message / event / payload |
| 插件生态 | npm 分发天然适合 plugin marketplace |
| 前端、CLI、Gateway 类型共享 | TS 可复用接口定义 |
| JSON / Schema / Tool 参数 | TS 对结构化对象表达强 |
| 多端 UI / Web 管理面 | React / Electron / Web 生态成熟 |
TypeScript 适合 OpenClaw 的 Gateway 生态，因为 Gateway 的核心是“连接、协议、事件、插件、前后端一致性”
Hermes的工程重心
我们看看Hermes在官网上的定义
What is Hermes Agent?
It's not a coding copilot tethered to an IDE or a chatbot wrapper around a single API. It's an autonomous agent that gets more capable the longer it runs. It lives wherever you put it — a $5 VPS, a GPU cluster, or serverless infrastructure (Daytona, Modal) that costs nearly nothing when idle. Talk to it from Telegram while it works on a cloud VM you never SSH into yourself. It's not tied to your laptop.
它并非依附于IDE的代码辅助工具，也不是套用于单一API的聊天机器人外壳。它是一款自主智能Agent，运行时间越久，能力越强。你可以将它部署在任意环境：月租 5 美元的虚拟专用服务器（VPS）、GPU 集群，或是 Daytona、Modal这类无服务器架构平台 —— 闲置状态下几乎零成本。你无需手动通过远程登录（SSH）连接云虚拟机，就能在Telegram上远程指挥它在云端后台运行任务。它完全不受限于你的本地笔记本电脑。
Hermes将自己描述成自主智能Agent，对应工程视角第4层的Agent Runtime里，Hermes关注的典型对象是memory、skill、trajectory、prompt assembly、agent loop，总结来说Hermes工程关注点是认知状态，举几个典型场景案例
用户是谁？
过去做过什么？
哪些经验值得沉淀？
哪个 skill 需要更新？
当前任务轨迹是什么？
哪些历史 session 可复用？
Hermes 的风险是 Agent 记忆和学习机制被污染,常见的失败模式是错误技能沉淀、历史污染、上下文压缩失真、坏经验反复复用
在评估与治理层，Hermes的关注点方向如下
| 治理对象 | Hermes |
|---|---|
| 权限治理 | 记忆写入权限、工具授权、长期用户画像 |
| 日志治理 | session、trajectory、memory mutation、skill update |
| 安全治理 | memory poisoning、skill poisoning、错误经验固化 |
| 质量治理 | 经验是否可复用、记忆是否正确、skill 是否有效 |
基于以上的内容，在核心的第4层Agent Runtime中Hermes可归纳成 Cognitive Runtime，解决的核心问题是Agent 如何长期执行和成长。
将Hermes的核心诉求与python的技术生态做一个对应
| Hermes 需求 | Python 优势 |
|---|---|
| Agent Loop 快速迭代 | Python 控制流和实验代码快 |
| 记忆处理 / 文本处理 | Python NLP、数据处理生态强 |
| Skill 自生成 / 文件操作 | Python 适合脚本化和本地自动化 |
| 轨迹、评测、RL | Python 是 AI 实验和评测主生态 |
Python 适合 Hermes 的自我改进记忆生态，因为它的核心是“Agent Loop、记忆处理、技能沉淀、工具执行、实验迭代”。
工程视角下的对比总结
对OpenClaw和Hermes在不同层级下的重点做个对比
| 层级 | OpenClaw | Hermes |
|---|---|---|
| 数据与知识层 | Context | Memory |
| AI 编排 / Agent Runtime 层 | Gateway Runtime | Cognitive Runtime |
| 横切：评估与治理层 | 连接治理 | 记忆治理 |
最后总结：
OpenClaw 设计重心是 Agent 与外部世界的连接状态，连接状态天然靠近 TypeScript / Node 的事件与协议生态。
Hermes 设计重心是 Agent 内部的认知状态，认知状态天然靠近 Python 的 AI、数据、脚本和实验生态。
二者不是谁包含谁，而是在 Agent Runtime 层走向了两个方向：OpenClaw 把 Runtime 做成外部连接平台，Hermes 把 Runtime 做成内部成长内核。
当然选择差异不是语言能力的边界。TypeScript 也可以做记忆系统，Python 也可以做 Gateway。这里讨论的是语言生态与项目工程重心的匹配程度。
都看到这里了，点个关注吧。
