可运维的智能体平台

1. CLI 智能体的时刻

OpenClaw、Hermes 以及一批类似的 CLI 智能体,已经悄然成为很多人日常使用的工具。你打开终端,和智能体对话,它记得你昨天在做什么,会执行命令、修改文件、提交 PR。

从本质上看,这些工具是个人助手。它们的技术栈也忠实地反映了这一点:看起来就像本地软件。记忆存在 Markdown 文件里。会话是磁盘上的 JSONL。Embedding 放在一个小小的 SQLite 数据库中。技能是 skills 文件夹下的目录。配置是某个隐藏目录里的 dotfile 和 JSON 文件。

对"一个人一台机器"来说,这样的设计完全合理。状态紧贴工作内容,工作区就是智能体,根本不需要操心运维 —— 智能体自己运维自己。

2. 规模化时撞上的那堵墙

当你不再是单个用户时,这个模型立刻失效。

想象你在运行一个内部平台,公司每个员工都有一个自己的智能体;或是一个 SaaS,每个客户都拥有一个专属智能体;又或者你管理着一支专项机器人队伍 —— 调研、值班、销售、QA。现在你手上有 10 个、100 个、1000 个智能体。

而用个人助手那套技术栈,你根本无法真正运维它们:

• 记忆藏在文件里,散落在每个智能体的工作区中。
• 技能是一堆文件夹,谁也无法集中审计。
• MCP 服务按每个智能体、每台机器分别配置。
• 会话是 JSONL,被困在智能体所在的那台机器上。
• 密钥就在代码旁边 —— 在 dotfile、环境变量、shell 历史里 —— 智能体可以直接读取。这是严重的安全风险。

想给所有智能体推送一条新指令?你得 SSH 上十台机器。想在每个智能体上安装一个技能?你得写一个部署脚本。想知道整个舰队到底在做什么?只能 tail 日志。

这就是笔记本与数据中心之间的差距。CLI 智能体那一套是笔记本形态的。

3. 内部状态 vs 外部状态

让 OpenHermit 的设计豁然开朗的,是一个简单的区分:内部状态与外部状态。

智能体的内部状态,是构成"智能体本身"的一切 —— 即使把它搬到另一台机器,你也要带走的东西:

• 系统指令
• 长期记忆
• 会话与消息历史
• 技能
• MCP 服务
• 定时任务
• 配置
• 密钥
• 用户、角色与通道身份

而智能体的外部状态,是它当前正在做的事 —— 工作区。仓库文件、产生的产物、临时笔记、桌面上那半成品的东西。

让人豁然开朗的类比是:你的记忆住在大脑里;你在编辑的文件住在电脑里。这是两种不同的载体,两种不同的生命周期,两种不同的访问模式。CLI 智能体把它们塌缩到一起 —— 一切都变成工作区里的文件。这就是 bug 所在。

4. OpenHermit 的设计

一旦接受了这种切分,设计就自然而然了:

• 所有内部状态住在 PostgreSQL。 会话、记忆、指令、技能、MCP、定时任务、通道、配置、密钥 —— 每一行都按 agent_id 做隔离。一个数据库,可观测、可备份、可查询、可管理。
• 只有外部状态是文件。 工作区还是工作区 —— 每个智能体一个独立的 Docker 容器,与宿主隔离,智能体在里面做真正的工作。
• 前面坐着一个网关。 认证、路由、智能体生命周期、定时任务 —— 一个所有智能体共享的控制平面。
• 一个管理层负责整个舰队。 网关之上是 CLI 和 Web UI,你可以在同一个地方看到并操作每一个智能体。

这不是什么新想法 —— 它和我们运行其他生产服务的形态如出一辙。我们只是把它套用到了智能体上而已。

5. 这样能解锁什么

一旦内部状态被集中起来,那些原本根本做不到的舰队操作,变得轻而易举。

想给所有 100 个智能体安装一个新技能?一条命令:

$ hermit skills enable standup-digest --all

或在管理界面里点一下。完成 —— 舰队中每个智能体都会立刻收到。

想给所有 100 个智能体添加一个 MCP 服务?

$ hermit mcp enable mcp_github --all

想给每个智能体推送一条新的系统指令 —— 比如新的合规规则、语气调整、安全边界?

$ hermit instructions append rules "Never share PII in messages." --all

想轮换一个密钥、审计一次会话、回放一个事件、为某个用户禁用某个通道、重新调度一个任务?它是表中的一行。它是你能写出来的一条查询。它是一次 API 调用。

智能体依旧彼此独立 —— 每一个都在自己的沙箱里干自己的活 —— 但作为整体,它们是可运维的舰队。整个产品用一个词概括,就是这个。

未来方向

OpenHermit 并不想取代你笔记本上的 CLI 智能体。OpenClaw 和 Hermes 在它们擅长的领域非常好用,"个人助手"这个形态对"一个人一台机器"是合适的。

当你不再只是一个人时 —— 当智能体成为你向团队、客户、或一群专项角色提供的服务时 —— OpenHermit 才是你伸手要拿的东西。当它们需要被部署、被观测、被升级、被加固、被回滚,像其他生产系统一样时。

用一句话概括:可运维的智能体平台。

和我们一起构建

OpenHermit 是开源项目(MIT 许可证),而且仍在快速演进。如果上面这些 —— 内部 / 外部状态切分、舰队运维模型、智能体即服务 —— 让你有共鸣,我们非常欢迎你的参与。Issue、PR、设计讨论、通道适配器、技能、MCP 集成、文档,以及你在自己环境里跑它的故事,都欢迎。

仓库地址在 github.com/HCF-STUDIOS/openhermit。给它点个 star,提一个 issue,开一个 PR,或者在 Discussions 里聊聊 —— 告诉我们,你希望一个"舰队形态"的智能体运行时长什么样。