前段时间，公司的技术总监问我一个问题，为什么OpenClaw是用TypeScript开发的，而Hermes用的Python。当时问我的时候，我是有点懵逼的，从来没思考过这个问题。作为一个曾经多年的web工作者，现在从事AI应用工程的开发者。我给出的答案是，AI应用一端连接着大模型，一端连接着使用者。在传统的技术领域内围绕大模型的语言是Python，Python擅长数据处理、RAG等，而TypeScript是围绕着使用者的语言，拥有更好的接入生态，例如hooks，流式对话等。OpenClaw和Hermes是基于自身特征选择了不同的方向。 后来我回想起来这个问题，觉得自己的回答没有说到重点，所以我整理思路，写下这篇文章解答为什么两者选择了不同语言进行开发。

工程分层视角下的AI应用

要聊语言选择，还需要从工程分层角度讲起，我们可以将AI应用分成6个运行层和1个横切治理平面。如下表所示

依次说明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网关，回到前文所说的6个层运行，Gateway应该归类到第4层的Agent Runtime里，OpenClaw关注的典型对象是channel、event、routing、plugin、node，总结来说OpenClaw工程关注点是连接状态，举几个典型场景案例

用户在哪个通道？消息属于哪个 thread？哪个 device node 在线？哪个插件提供哪个能力？哪个 tool 暴露给哪个 agent？事件如何路由？

OpenClaw 的风险是连接系统不可靠，常见的失败模式是消息丢失、通道断连、事件乱序、插件冲突、权限泄露、节点失联等。

在评估与治理层，OpenClaw中的关注点方向如下

基于以上的内容，在工程视角的第4层Agent Runtime中OpenClaw可归纳成 Gateway Runtime，解决的核心问题是Agent 如何接入外部系统。

理解了OpenClaw的主要诉求，将OpenClaw的诉求与TypeScript的技术生态做一个对应

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.

Hermes将自己描述成自主智能Agent，对应工程视角第4层的Agent Runtime里，Hermes关注的典型对象是memory、skill、trajectory、prompt assembly、agent loop，总结来说Hermes工程关注点是认知状态，举几个典型场景案例

用户是谁？过去做过什么？哪些经验值得沉淀？哪个 skill 需要更新？当前任务轨迹是什么？哪些历史 session 可复用？

Hermes 的风险是 Agent 记忆和学习机制被污染,常见的失败模式是错误技能沉淀、历史污染、上下文压缩失真、坏经验反复复用

在评估与治理层，Hermes的关注点方向如下

基于以上的内容，在核心的第4层Agent Runtime中Hermes可归纳成 Cognitive Runtime，解决的核心问题是Agent 如何长期执行和成长。

将Hermes的核心诉求与python的技术生态做一个对应

Python 适合 Hermes 的自我改进记忆生态，因为它的核心是“Agent Loop、记忆处理、技能沉淀、工具执行、实验迭代”。

工程视角下的对比总结

对OpenClaw和Hermes在不同层级下的重点做个对比

最后总结：

OpenClaw 设计重心是 Agent 与外部世界的连接状态，连接状态天然靠近 TypeScript / Node 的事件与协议生态。

Hermes 设计重心是 Agent 内部的认知状态，认知状态天然靠近 Python 的 AI、数据、脚本和实验生态。

二者不是谁包含谁，而是在 Agent Runtime 层走向了两个方向：OpenClaw 把 Runtime 做成外部连接平台，Hermes 把 Runtime 做成内部成长内核。

当然选择差异不是语言能力的边界。TypeScript 也可以做记忆系统，Python 也可以做 Gateway。这里讨论的是语言生态与项目工程重心的匹配程度。

这里是 秩序 AI   希望能通过工程思维定义好AI的边界，让我们在混乱的技术浪潮中获得秩序感。

都看到这里了，点个关注吧。