Hermes Agent 初探：一个会长记性的个人 Agent，以及它和 OpenClaw 的比较

最近 AI Agent 项目有点像小区门口新开的咖啡店：每家都说自己懂你、能陪你、还会替你干活。Hermes 这个名字也占便宜，在中文世界里很容易被调侃成“AI Agent 中的爱马仕”，听起来像是要卖包，其实卖的是记忆、技能和自动化。问题是，真坐下来点一杯，才发现有的只是换了杯套，有的确实在重新设计吧台。Hermes Agent 就属于后面这一类，至少它让我愿意多看两眼。

Hermes Agent 让我感兴趣的地方，不是它又支持了几个模型，也不是又接了几个聊天平台，而是它把一个个人 agent 当成长期运行、持续学习、有记忆、有技能库、有消息入口的系统来做。这个方向对我这种老程序员很有吸引力。毕竟我们见过太多“聪明三分钟”的工具：当场回答很漂亮，第二天再问，像从没认识过你。

这篇初探基于我在 2026-04-25 查阅的 Hermes Agent、OpenClaw 和 OpenAI 官方文档。先说结论：Hermes Agent 更像一个“会成长的个人运行时”，OpenClaw 更像一个“平台覆盖很广的本地个人助理系统”。二者不是谁替代谁，而是设计重心不同。

Hermes Agent 是什么

按官方 README 的说法，Hermes Agent 是 Nous Research 做的一个 self-improving AI agent。它的关键词大概有六个：

• 长期记忆：能保留 session、搜索历史对话，并建立用户画像。
• Skills：能从经验中沉淀技能，并在使用中改进。
• Gateway：可以从 CLI，也可以从 Telegram、Discord、Slack、WhatsApp、Signal、Feishu/Lark 等平台对话。
• Scheduler：内置 cron，可做日报、备份、巡检之类的定时任务。
• Subagent：支持委派和并行工作流。
• Provider routing：可接 DeepSeek、OpenRouter、Nous Portal、OpenAI、Hugging Face、自定义 OpenAI-compatible endpoint 等。

如果只看功能清单，它当然显得很“全”。但真正的看点不在“全”，而在“闭环”。功能多只是热闹，闭环跑起来才有价值。

普通聊天机器人通常是这样：

用户输入 -> 模型回答 -> 会话结束

Hermes 想做的是：

用户输入 -> 工具执行 -> 记忆沉淀 -> 技能生成/改进 -> 后续任务复用

这条线如果跑顺，它就不只是“问答工具”，而是一个慢慢长出工作习惯的个人 agent。说得朴素一点，它不该只会今天帮你写脚本，还应该记得上次这个脚本为什么差点把生产日志目录扫没了。

Hermes Agent 的味道：它不只是聊天的套壳

如果只用一句话概括 Hermes Agent，我会这样说：

它把 Agent 当成一个长期运行的个人操作系统雏形，而不是一次性问答窗口。

按官方 Features 和 Architecture 文档，Hermes 的能力可以拆成几层：

这套设计的味道很明确：外面多入口，里面一个核心；上面多场景，下面统一调度。

很多 agent 项目一开始像个聪明的 CLI，后来想接聊天平台、接定时任务、接 API server，就开始到处长分支。Hermes 的思路更像是先把 AIAgent 作为核心发动机，再让 CLI、Gateway、ACP、API Server 这些入口都去调用它。这样做当然不轻，但长期看，系统不会那么快变成“每个入口都有一套半重复逻辑”的老房子。

我看中的几个地方

我认为 Hermes 最值得看的地方有五个。

第一个是长期性。

它不是只处理一个 prompt，而是认真处理 memory、session、compression、skills、scheduler 这些脏活累活。Agent 真要进入日常工作，最麻烦的恰恰不是“这次回答聪不聪明”，而是“它下周还记不记得规矩，能不能接着上次的上下文干活”。

第二个是入口和核心分离。

CLI、Feishu、Telegram、API Server、ACP 看上去是不同产品形态，但背后都尽量落到同一个 agent loop。这个设计值得借鉴。很多内部工具失败，不是模型不行，而是入口越接越多，每个入口都复制一套业务逻辑。维护者看见就想请假。

第三个是工具系统有分层。

Hermes 区分 skills、tools、toolsets、plugins。这个分层很实用：

• 能用说明文档和现有命令解决的，放 skill。
• 必须稳定执行、有认证、有状态的，做 tool。
• 要扩展系统边界的，走 plugin。

这比“所有能力都塞成 function calling”要清醒。函数调用不是万能胶，什么都粘上去，到头来会粘住自己的手。

第四个是调度和自动化不是外挂。

Hermes 的 cron job 会创建新的 agent session，可以挂 skill，可以把结果投递到平台，还会由 gateway tick 触发。这一点很关键。它不是“晚上十点跑个 shell 脚本再 curl 一下模型”，而是把定时任务放回 agent 运行时里。这意味着 memory、skills、provider fallback、delivery 都能复用。

第五个是模型供应商可替换。

DeepSeek、OpenAI、OpenRouter、本地模型、自定义 endpoint 都可以进入 provider 体系。今天模型市场变化太快，系统如果只围着一个 provider 写，半年后就容易变成遗迹。Provider resolution 和 fallback 这类设计，看着不性感，但很救命。

坑也不少：好东西不是免费午餐

当然，Hermes 也不是银弹。它的几个缺点，恰好来自它的野心。

第一个问题是复杂度高。

官方架构文档里，AIAgent 承担了 prompt assembly、provider 选择、tool dispatch、fallback、compression、session persistence 等职责。能力集中带来一致性，也带来学习成本。你要是只想要一个“群里自动回复 FAQ”的小 bot，用 Hermes 可能像开卡车去买菜，能到，但停车费不便宜。

第二个问题是配置面大。

模型、gateway、Feishu 权限、cron、tools、memory、API server、provider key，全都要管。对个人折腾很爽，对团队生产环境则意味着要有配置治理、密钥治理、权限治理。否则 agent 没出错，人先被配置绕晕。

第三个问题是长期记忆有边界。

Hermes 的内置 memory 是 bounded、curated memory，不是无限数据库。这个设计是对的，但也意味着你不能指望它“什么都永远记得”。真正重要的项目知识，还是要沉淀到文档、repo、wiki 或明确的 skill 里。记忆适合放偏好和经验，不适合当唯一事实源。

第四个问题是自动化质量取决于信息源。

比如每天写科技新闻综述，如果没有 web/search 能力或固定 RSS 源，它只能靠模型已有知识胡乱补。模型再强，也不能凭空知道昨晚发生了什么。这里没有魔法，只有数据源、检索、验证和输出约束。

第五个问题是安全边界必须自己守住。

一旦接入 shell、浏览器、文件系统、Feishu、API key，它就是一个有行动能力的系统。Hermes 提供 allowlist、approval、gateway auth 等机制，但机制只是安全带，不是替你开车的人。这个边界要自己守。

架构上有哪些东西值得抄

我觉得 Hermes 对我们做内部 agent、个人自动化系统，至少有四个可抄的设计原则。

1. 一个核心，多种入口

不要为 CLI 写一套逻辑，为 Feishu 写一套逻辑，为 API Server 再写一套逻辑。入口可以多，核心尽量少。

CLI / Feishu / API Server / ACP
        |
        v
     Agent Core
        |
        v
Tools / Memory / Provider / Session

这样做的好处是：入口增加时，能力自然复用；核心修 bug 时，所有入口一起受益。

2. 能力分层，不要全塞进工具调用

Agent 系统里常见一个坏味道：所有东西都做成 tool。结果工具 schema 越来越长，模型越看越晕，开发者也越看越烦。

Hermes 的 skills/tools/plugins 分层提醒我们：

• 知识和流程，优先 skill。
• 稳定动作，才做 tool。
• 横向扩展，才做 plugin。

这套分层适合很多企业内部场景。比如“发布流程说明”更像 skill，“查工单状态”更像 tool，“接入 Jira/Feishu/GitLab”更像 plugin。

3. 记忆要小而准，不要大而糊

Hermes 内置 memory 有字符限制，这点我很喜欢。记忆不是垃圾桶，不能什么都倒进去。

好的 memory 应该像便签纸：

• 记录用户偏好。
• 记录项目惯例。
• 记录工具坑点。
• 记录已经验证过的经验。

真正的大知识，应该放在文档和代码库里，让 agent 按需读取。否则 memory 写着写着就会变成“老工程师的抽屉”：什么都有，真找东西时全靠缘分。

4. 定时任务应该是 agent task，不只是 cron script

传统 cron 擅长“到点执行命令”，不擅长“到点理解问题”。而 agent cron 的价值在于：它可以加载技能、读取上下文、调用工具、生成判断、投递到人所在的平台。

这对 OPC 特别有意义。一个人公司最缺的不是想法，而是稳定重复执行的“小职能”：日报、线索收集、竞品观察、客户反馈归类、内容选题、代码健康检查。把这些做成 agent task，比每天靠意志力点开十个网页靠谱。

这也是 Hermes 给我的最大启发：Agent 的价值不只是回答问题，而是把一部分重复判断变成可持续运行的系统。

和 OpenClaw 做个比较

OpenClaw 也是个人 AI assistant，重点放在本地运行、多平台消息入口和个人使用体验。官方 README 里列出的渠道覆盖很夸张，包括 WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、Microsoft Teams、Matrix、Feishu、LINE、WeChat、QQ 等。它还强调 Gateway、multi-channel inbox、multi-agent routing、voice、live canvas、browser/canvas/cron/tools 等能力。

所以如果你问“谁支持的平台多”，OpenClaw 当前更像一个大杂货铺，货架很长；Hermes 则更像一个正在认真打磨工作流闭环的工具箱。前者热闹，后者较真。

选这种工具，不能只数功能点。功能清单像超市小票，看着很长，但真正决定你能不能长期用下去的，是它的责任边界：谁负责入口，谁负责记忆，谁负责工具，谁负责定时任务，谁负责兜底。边界清楚，系统才不容易长歪。

我个人的判断是：

• 如果你的第一需求是“我想在各种聊天软件里找一个本地助理”，OpenClaw 的平台覆盖更有吸引力。
• 如果你的第一需求是“我想让 agent 持续学习我的项目、沉淀技能、跑在 VPS 或云环境里”，Hermes Agent 更值得研究。
• 如果你已经有 OpenClaw 数据，Hermes 的迁移命令降低了试用成本。

这也解释了为什么 Hermes 官方 README 专门写了 “Migrating from OpenClaw”。迁移内容包括 persona、memories、user-created skills、command allowlist、messaging settings、部分 API keys、workspace instructions 等。这里要注意：迁移不是魔法，不代表行为完全等价。Agent 系统迁移最麻烦的从来不是文件搬家，而是“它到底什么时候该相信什么、执行什么、拒绝什么”。

先装起来：Hermes Agent 的最小路径

官方提供的一键安装方式是：

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装后通常先做三件事：

source ~/.zshrc
hermes
hermes model
hermes gateway setup

这里的顺序有讲究：

1. hermes 先确认 CLI 能跑。
2. hermes model 配置模型 provider。
3. hermes gateway setup 再接入聊天平台。

很多工程工具出问题，不是因为最终配置复杂，而是因为第一步没站稳就开始叠楼。先让 CLI 能正常对话，再接 Feishu，再加 scheduler 和 API server，人会少掉很多奇怪的脾气。

接入 DeepSeek / OpenAI-compatible API：三种含义别混了

“Hermes Agent 集成 OpenAI API”这句话容易让人误会。更准确地说，Hermes 支持两类事情：

1. 把某个模型服务当作 Hermes 的模型提供方：比如 DeepSeek、OpenAI、OpenRouter、自定义 OpenAI-compatible endpoint。
2. 把 Hermes 暴露成 OpenAI-compatible API server：其他客户端调 Hermes。

这两个方向刚好相反，别写到一起糊成一锅。

方向一：让 Hermes 调 DeepSeek

Hermes 当前把 DeepSeek 列为内置 provider，环境变量名是 DEEPSEEK_API_KEY。如果你的目标模型是 deepseek-v4-pro，最小配置可以这样写到 ~/.hermes/.env：

DEEPSEEK_API_KEY=sk-xxxxxxxx

然后用交互式配置选择 DeepSeek：

hermes model

或者直接试一条命令：

hermes chat --provider deepseek --model deepseek-v4-pro

如果你偏爱手工配置，也可以在 ~/.hermes/config.yaml 里把默认模型固定下来：

model:
  provider: "deepseek"
  default: "deepseek-v4-pro"

之后在 Hermes 会话里，如果 DeepSeek provider 已经配置好，可以用：

/model deepseek:deepseek-v4-pro

这里我会优先把 DeepSeek 当作内置 provider，而不是绕到 custom endpoint。这样配置更短，也少一个 base URL 写错的机会。

方向二：让 Hermes 调 OpenAI 或其他 OpenAI-compatible endpoint

OpenAI 官方文档建议把 API key 放在环境变量里，SDK 会自动读取；Hermes 当前文档则强调，模型、provider、base URL 的 source of truth 是 ~/.hermes/config.yaml。换句话说，旧式 OPENAI_BASE_URL、LLM_MODEL 这种 .env 写法不要再当成主路径。

如果你接的是 OpenAI、公司内部代理、LiteLLM、vLLM 或其他 OpenAI-compatible endpoint，建议走 hermes model：

hermes model
# 选择 "Custom endpoint"
# 填入 API base URL、API key、Model name

也可以手工写 config.yaml：

model:
  provider: "custom"
  default: "gpt-5.2"
  base_url: "https://api.openai.com/v1"
  api_key: "use-env-or-secret-helper-here"

我不太建议把真实 API key 明文写进 config.yaml。更稳妥的做法是让 hermes model 写入本地配置，或者通过系统密钥管理/环境变量注入。OpenAI API reference 也明确提醒，API key 是 secret，不应该暴露在浏览器或客户端代码里。

如果你有 named custom provider，也可以用类似下面的方式切换：

/model custom:openai-prod:gpt-5.2

如果你自己写外部服务调用 OpenAI，当前官方文本生成文档建议新项目优先看 Responses API，而不是继续沿用老的 Chat Completions 心智模型。老接口不是不能用，只是新项目没必要先背旧包袱。

方向三：让其他客户端按 OpenAI API 调 Hermes

Hermes 还提供 API Server，能把 hermes-agent 暴露成 OpenAI-compatible HTTP endpoint。这样 Open WebUI、LobeChat、LibreChat、ChatBox，甚至 OpenAI Python SDK，都可以把 Hermes 当后端。

在 ~/.hermes/.env 里打开：

API_SERVER_ENABLED=true
API_SERVER_KEY=change-me-to-a-long-random-secret
API_SERVER_HOST=127.0.0.1
API_SERVER_PORT=8642

启动 gateway：

hermes gateway

然后用 OpenAI SDK 连接 Hermes：

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8642/v1",
    api_key="change-me-to-a-long-random-secret",
)

response = client.responses.create(
    model="hermes-agent",
    input="请总结一下当前项目的风险清单。"
)

print(response.output_text)

这个模式适合两类场景：

• 你喜欢某个前端 UI，但想让背后执行的是 Hermes 的工具、记忆和 skills。
• 你想在一个内部系统里调用 Hermes，但不想为它单独写一套客户端协议。

不过要记住一个限制：Hermes API server 文档说明，model 字段更多是客户端兼容用，实际使用哪个底层 LLM，仍由 Hermes 服务器端配置决定。别以为客户端传了 deepseek-v4-pro，Hermes 就一定会绕过自己的配置去调用这个模型。

如果你想把辅助模型也指向 OpenAI，比如图像分析，可以在 config.yaml 里显式写：

auxiliary:
  vision:
    provider: "main"
    model: "gpt-4o"

接入 Feishu/Lark：推荐 WebSocket，少折腾公网回调

Hermes 的 Feishu/Lark 文档已经比较完整。它支持私聊、群聊、cron 结果投递、文本、图片、音频、文件，还支持 Feishu 文档评论里的 @ 智能回复。

我建议优先用 WebSocket 模式。理由很简单：少一个公网 webhook，就少一堆 TLS、反向代理、签名校验、回调地址验证的麻烦。不是不能做，而是没必要一开始就给自己加戏。

1. 创建 Feishu/Lark App

最简单路径：

hermes gateway setup

选择 Feishu/Lark，用手机扫码创建。若扫码创建不可用，就到开发者后台手工创建应用：

• Feishu: https://open.feishu.cn/
• Lark: https://open.larksuite.com/

然后复制 App ID 和 App Secret，启用 Bot capability，再回到 hermes gateway setup 填入。

2. 配置 WebSocket 模式

在 ~/.hermes/.env 中配置：

FEISHU_APP_ID=cli_xxx
FEISHU_APP_SECRET=secret_xxx
FEISHU_DOMAIN=feishu
FEISHU_CONNECTION_MODE=websocket

# 强烈建议生产环境设置
FEISHU_ALLOWED_USERS=ou_xxx,ou_yyy
FEISHU_GROUP_POLICY=allowlist
FEISHU_HOME_CHANNEL=oc_xxx

FEISHU_DOMAIN 的取值：

• feishu：中国大陆飞书
• lark：国际版 Lark

启动：

hermes gateway

然后在 Feishu 私聊这个 bot。群聊里默认需要 @ bot，它才会处理消息。这个设计挺合理：否则某天群里吵架，agent 在旁边认真总结“各位的需求分歧主要有三点”，场面会比较难看。

3. 如果必须用 Webhook 模式

Webhook 模式适合你已经有公网 HTTPS 入口的场景：

FEISHU_CONNECTION_MODE=webhook
FEISHU_WEBHOOK_HOST=127.0.0.1
FEISHU_WEBHOOK_PORT=8765
FEISHU_WEBHOOK_PATH=/feishu/webhook
FEISHU_ENCRYPT_KEY=your-encrypt-key
FEISHU_VERIFICATION_TOKEN=your-verification-token

生产环境要同时设置 FEISHU_ENCRYPT_KEY 和 FEISHU_VERIFICATION_TOKEN。Hermes 文档说明，webhook 模式会做签名/ token 校验、请求大小限制、read timeout 和 rate limiting。安全这件事别省，省下来的时间通常会在事故复盘里加倍还回去。

4. Feishu 权限清单

按场景逐步开权限，不要一上来全开。

如果你只是先验证“能不能在飞书里聊起来”，不要急着开文档评论和文件读取。最小权限跑通，再一层一层加。

应用实例：每天晚上 10 点写一份科技新闻综述

这个例子比较贴近日常使用：每天晚上 10 点，让 Hermes 用 deepseek-v4-pro 给我发一份科技新闻综述，重点关注两个方向。

• AI 应用：不是模型榜单刷屏，而是产品、工作流、行业落地、开发工具的真实变化。
• OPC：One-Person Company，一人公司。关注个人创业、自动化、AI-first business、solo founder 工具链。

先把默认模型设成 DeepSeek：

# ~/.hermes/config.yaml
model:
  provider: "deepseek"
  default: "deepseek-v4-pro"

再确认 gateway 长期运行。Hermes 的 cron 是由 gateway 的后台 tick 触发的，光开一个普通 CLI chat 不会自动跑定时任务：

hermes gateway install
hermes gateway
hermes cron status

如果你已经在 Feishu 里跟 Hermes bot 对话，最自然的方式是在 Feishu 私聊里直接说：

Every day at 22:00, write a Chinese daily tech news briefing and send it back here.
Focus on AI applications and OPC (one-person company).

Requirements:
- Use deepseek-v4-pro as the model if available.
- Summarize 5-8 important items from the last 24 hours.
- For each item include: title, source, why it matters, and one practical takeaway.
- Separate "AI 应用" and "OPC / 一人公司" sections.
- End with "明天值得观察的 3 件事".
- Avoid hype. Mark uncertain information clearly.

Hermes 文档说，cron 支持自然语言和标准 cron 表达式。上面这种从 Feishu 发起的任务，默认会把结果回投到创建任务的聊天来源。你也可以用更明确的 cron 表达式：

hermes cron create "0 22 * * *" \
  "Write a Chinese daily tech news briefing for the last 24 hours. Focus on AI applications and OPC (one-person company). Include 5-8 items, source, why it matters, one practical takeaway, and 3 things to watch tomorrow. Avoid hype and mark uncertainty clearly." \
  --name "Daily AI and OPC brief"

如果从 CLI 创建，默认结果通常会保存到本地输出目录；如果想投递到 Feishu，最好从 Feishu 对话中创建，或者按当前 Hermes 版本支持的 delivery target 配成 feishu。这个细节别嫌麻烦，定时任务最烦人的不是“跑不起来”，而是跑起来以后发到了你找不到的地方。

这类任务还有一个前置条件：Hermes 需要有可用的 web/search 能力，或者你提供固定 RSS/新闻源。否则它只能靠模型已有知识写“昨日新闻”，那就不是综述，是新闻穿越。

我会再加三条质量约束，防止它写成“科技媒体标题党精选”：

一份合格的日报，不应该让你读完觉得“世界又变了”，而应该让你知道：明天哪三件事值得花时间，哪三件事可以先放过。

一个推荐架构

如果要把 Hermes Agent 放进日常工作流，我会从这个小架构开始：

Feishu/Lark
    |
    | WebSocket Gateway
    v
Hermes Agent on VPS / workstation
    |
    | provider routing
    v
DeepSeek API / OpenAI API / OpenRouter / local model
    |
    | optional
    v
Hermes API Server -> Open WebUI / internal tools

这个架构的好处是边界清楚：

• Feishu 负责入口和通知。
• Hermes 负责 session、memory、skills、tools、scheduler。
• DeepSeek/OpenAI/OpenRouter 等 provider 负责模型能力。
• API Server 只在需要被其他系统调用时打开。

每一层都可以独立替换。今天用 DeepSeek，明天换 OpenAI、OpenRouter 或本地模型；今天用 Feishu，明天加 Slack；今天用 CLI，明天接 Open WebUI。能被替换，系统才不容易被某个供应商、某个聊天平台、某个模型名绑死。

安全清单：别让个人 Agent 变成个人事故

Agent 一旦接入聊天平台、文件系统、浏览器、shell 和 API key，它就不再是“玩具聊天机器人”。它更像一个拿着你门禁卡的实习生：聪明、勤快，但权限必须管住。

上线前我建议至少检查这些：

• API key 只放在 ~/.hermes/.env 或密钥系统，不进 Git。
• DeepSeek、OpenAI、OpenRouter 等 provider 的 key 分开管理，别共用一个“万能 token”。
• Feishu/Lark 必须设置 FEISHU_ALLOWED_USERS，群聊默认用 allowlist。
• Webhook 模式必须配置 FEISHU_ENCRYPT_KEY 和 FEISHU_VERIFICATION_TOKEN。
• 不把 Hermes API Server 直接暴露到公网；如必须暴露，放在反向代理、TLS、鉴权和 IP allowlist 后面。
• 先用低权限 bot 跑通，再逐步加文件、文档、卡片审批权限。
• 对高风险工具保留 command approval，不要为了“省一次点击”把生产机器交出去。
• 定期跑 hermes doctor，确认配置没有明显风险。

常见坑

1. Feishu 私聊能用，群聊没反应

先检查三件事：

• 群里是否明确 @ 了 bot。
• FEISHU_GROUP_POLICY 是否是 allowlist。
• 发送者的 open_id 是否在 FEISHU_ALLOWED_USERS 里。

如果 bot identity 没识别出来，再显式配置：

FEISHU_BOT_OPEN_ID=ou_xxx
FEISHU_BOT_USER_ID=xxx
FEISHU_BOT_NAME=MyBot

2. 点击 Feishu 交互卡片报错

检查是否订阅 card.action.trigger，是否启用 Interactive Card。Webhook 模式还要配置 Card Request URL。

3. DeepSeek 配好了，但 Hermes 没用你想的模型

确认你是在改 Hermes 的 server-side model 配置，而不是只在外部客户端请求里传了一个 model 字段。Hermes API Server 模式下，客户端的 model 字段主要用于兼容，真正底层模型由 Hermes 配置决定。最直接的检查方式是看 ~/.hermes/config.yaml 里的 model.provider 和 model.default。

4. 定时任务到了晚上 10 点没动静

先检查：

• hermes gateway 是否在运行。
• hermes cron list 里任务是否是 active。
• 机器时区是否是你以为的时区。
• 任务是从 CLI 创建还是从 Feishu 创建，delivery target 是否符合预期。

5. 迁移 OpenClaw 后感觉行为不一样

这是正常的。迁移工具能搬设置、记忆、skills 和部分密钥，但搬不了“运行时哲学”。建议先用 hermes claw migrate --dry-run 看迁移计划，再小范围验证，不要直接把日常入口切过去。

参考资料

• NousResearch/hermes-agent GitHub README
• Hermes Agent: Feishu / Lark Setup
• Hermes Agent: Features Overview
• Hermes Agent: Architecture
• Hermes Agent: Agent Loop Internals
• Hermes Agent: Persistent Memory
• Hermes Agent: AI Providers
• Hermes Agent: Scheduled Tasks (Cron)
• Hermes Agent: API Server
• openclaw/openclaw GitHub README
• OpenAI API Quickstart
• OpenAI Text Generation Guide
• OpenAI API Reference: Authentication

如果是我，会怎么选

如果让我今天在一台干净的 VPS 上搭一个个人工作 agent，我会先试 Hermes Agent。原因不是它“功能更多”，而是它的 memory、skills、gateway、scheduler 和 provider routing 放在一起后，像一个可以长期运行的工作底座。

但如果目标是“尽快覆盖尽可能多的聊天平台和本地设备体验”，OpenClaw 仍然值得看。它更像一个个人助理入口平台，尤其适合喜欢折腾本地设备、聊天渠道和 companion apps 的人。

我的建议很实在：

1. 先用 Hermes CLI 跑通一个真实任务。
2. 再接 Feishu WebSocket，让它进入日常工作流。
3. 然后配置 DeepSeek deepseek-v4-pro 或其他 provider，观察成本、延迟和质量。
4. 再逐步打开 scheduler、API Server、文档评论回复等高级能力。

Agent 这件事，最怕一上来就“全家桶”。先让它在一个小场景里可靠，再让它长大。人是这样，系统也是这样。目的无他，先活下来，再谈宏大叙事。

思维导图

mindmap
  root((Hermes Agent))
    定位
      长期运行的个人 Agent
      记忆和技能沉淀
      Gateway 加 Scheduler
    特点
      多入口共用核心
      有边界的长期记忆
      Skills Tools Plugins 分层
      Cron 是 Agent Task
    优点
      长期性
      入口和核心分离
      工具系统分层
      自动化复用运行时
      模型供应商可替换
    缺点
      复杂度高
      配置面大
      记忆不能当事实源
      自动化依赖信息源
      安全边界要自己守
    架构借鉴
      一个核心多种入口
      能力分层
      小而准的记忆
      定时任务回到 Agent 运行时
    对比 OpenClaw
      Hermes
        重视闭环
        Memory
        Skills
        Provider routing
      OpenClaw
        平台覆盖广
        本地个人助理
        多渠道入口
      选择标准
        先看主要场景
        再看责任边界
        再看迁移成本
    接入模型
      DeepSeek
        DEEPSEEK_API_KEY
        deepseek-v4-pro
        内置 provider
      OpenAI-compatible
        Custom endpoint
        config.yaml
        API key 不进 Git
      API Server
        OpenAI-compatible endpoint
        前端 UI 可复用
        服务器端决定真实模型
    接入 Feishu
      WebSocket 优先
      私聊和群聊
      cron 结果投递
      权限最小化
    应用实例
      每晚 22 点
      AI 应用
      OPC 一人公司
      新闻综述
      来源和 takeaway
    安全边界
      用户 allowlist
      Secret 管理
      Webhook 校验
      高风险工具审批

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。