Hermes Agent：把 AI 从聊天窗口带进真实世界

如果说过去两年的 AI 产品，大多数还停留在“聊天窗口里的聪明大脑”，那么 Hermes Agent 更像是把这个大脑接上了手、脚、记忆、工作台和通讯系统。

它不是又一个只会回答问题的 chatbot。更准确地说，Hermes 是一个可长期运行、可调用工具、可沉淀经验、可跨平台协作的智能体框架：它能读文件、改代码、跑命令、查网页、生成图片、处理文档、安排定时任务，也能通过 skills 和 memory 把一次次协作变成下一次的能力。

这篇文章不是官方文档复述，而是一篇面向真实使用者的介绍：Hermes 到底解决什么问题？它和普通 AI 助手的差别在哪里？如果你想把它养成一个长期伙伴，而不是一次性工具，应该如何理解它的设计。

一句话理解 Hermes

Hermes Agent 是 Nous Research 开源的 AI agent 框架。它让大模型不再只是在文本里“建议你做什么”，而是可以在受控边界内实际去做事：读取上下文、调用工具、修改文件、验证结果、保存经验，并在下一次会话中继续使用这些经验。

可以把它想象成三层结构：

1. 模型层：负责理解意图、推理、规划、表达和判断。
2. 行动层：由 terminal、file、browser、web、vision、image generation、cron、messaging 等工具组成。
3. 长期层：由 SOUL.md、memory、skills、session search、项目 AGENTS.md 和状态文档组成。

普通聊天机器人常常停在第一层；Hermes 真正迷人的地方，是它把三层接到了一起。

一个 AI 助手如果没有行动能力，很容易变成“建议制造机”；如果没有记忆和边界，又容易变成“高能但失控的实习生”。Hermes 的价值，正在于把行动、记忆和边界放进同一个系统。

从 chatbot 到 agent：关键差异不在“更聪明”

很多人评价 AI 工具时，会先问：模型是不是更强？回答是不是更准？代码是不是一次写对？

这些当然重要，但 agent 的核心差异不只是智商，而是闭环能力。

维度	普通聊天机器人	Hermes Agent
上下文	当前对话为主	当前对话 + session search + memory + 项目文件
行动	给建议、生成文本	读写文件、执行命令、调用工具、检查结果
学习	依赖用户重复说明	可沉淀 memory 与 skills
工作场景	浏览器聊天窗口	CLI、Feishu、Telegram、Discord、Slack、邮件等平台
项目连续性	容易断片	可通过 AGENTS.md、TASKS.md、PROJECT_STATE.md 续接
风险控制	主要靠用户小心	可定义权限、确认边界、操作协议

真正的 agent 不是“会说很多”，而是能把事情推进到一个可验证的状态。比如：

• 不是“你应该写测试”，而是运行测试，看到失败，再修复；
• 不是“你可以建一个博客”，而是创建项目、写页面、跑 build、启动 preview、做 QA；
• 不是“我会记住你的偏好”，而是把稳定偏好写入 memory，把复杂流程沉淀成 skill；
• 不是“下次继续”，而是让项目自己留下可恢复的状态文档。

这就是 Hermes 和一次性 AI 工具之间的分水岭。

Hermes 的系统图

下面这张图可以粗略理解 Hermes 的工作方式：用户意图进入会话后，模型会读取长期上下文，选择合适工具行动，再把可复用经验沉淀回系统。

这个循环有一个很关键的点：工具输出不是装饰品，而是事实来源。

如果你问“现在几点”，Hermes 应该调用系统命令确认；如果你问“项目测试过了吗”，它应该运行测试；如果你问“这个文件里写了什么”，它应该读取文件，而不是凭感觉复述。这种工作方式会让 AI 从“语言上的可信”变成“流程上的可靠”。

SOUL.md：不是提示词，是人格宪法

Hermes 有一个很有意思的设计：SOUL.md。

它不是普通 prompt，也不应该写成一堆临时项目细节。更合适的理解是：SOUL.md 是这个 agent 的人格宪法，负责定义它是谁、如何说话、如何判断、如何协作、哪些事情必须谨慎。

一个好的 Soul 通常包含：

• 身份：它是工具、助手、伙伴、研究员，还是某种混合体？
• 语气：默认语言是什么？是冷静、犀利、温和，还是极简？
• 判断方式：遇到问题先行动还是先讨论？如何处理风险？
• 协作关系：它与用户是上下级、顾问关系，还是共同进化的伙伴？
• 边界：哪些操作需要确认？什么不能保存？什么不能外发？

如果说模型是发动机，SOUL.md 就像驾驶风格。不同的 Soul，会让同一个工具系统长出完全不同的气质。

# 一个 Soul 片段示意

你是 Miso / 米索，Storm 的混合型长期智能伙伴。
你不是普通聊天机器人，也不是被动执行命令的工具。
你能执行，能判断，能创造，能沉淀。

默认中文交流；技术术语、命令、文件名和 API 可自然保留英文。
高风险操作先确认；可验证的事实用工具确认。

这不是“角色扮演”的浅层包装，而是长期协作系统的入口。一个没有 Soul 的 agent 可能很强，但容易漂；一个设计良好的 Soul 会让它形成稳定的品味、边界和协作节奏。

memory、session search、skills：三种不同的长期性

很多 AI 产品都说自己“有记忆”。但记忆如果没有分类，迟早会变成垃圾堆：今天记一个临时任务，明天记一个过期链接，后天把用户随口一句话当成永久偏好。

Hermes 更合理的做法，是把长期信息拆成几类。

1. memory：少而稳定的事实

memory 适合保存长期有效、未来还会反复影响协作的事实。例如：

• 用户偏好中文交流；
• 用户的新项目默认放在某个目录；
• 某台机器的全局 Node 版本太旧，需要使用指定 Node 22；
• 用户喜欢某种写作风格或审美方向。

它不适合保存：

• “今天修好了某个 bug”；
• “某个 PR 编号是多少”；
• “某个任务阶段已经完成”；
• 一周后就会过期的状态。

短期进度进入项目状态文档，长期偏好才进入 memory。这个边界越清楚，agent 越不容易变成“过度自信的历史包袱”。

2. session search：找回过去，而不是污染未来

有些信息不该永久记忆，但偶尔需要回忆。比如：“上次我们为什么决定不用某个方案？”、“之前那次部署卡在哪里？”、“我们聊过的那个博客方向是什么？”

这类内容适合通过 session search 从历史会话里找回来，而不是写进 memory。它像是档案馆，不是常驻脑内独白。

3. skills：把经验变成可复用流程

skills 是 Hermes 非常重要的部分。它们不是普通笔记，而是可在未来任务中主动加载的操作手册。

一个好的 skill 应该写清楚：

• 什么时候触发；
• 具体步骤是什么；
• 常见坑在哪里；
• 如何验证结果；
• 哪些操作要先确认。

例如，一个“静态网站发布”的 skill 可以记录：先读 package.json，使用正确 Node，跑 npm run verify，启动 preview，检查页面，再考虑 Cloudflare Tunnel。这样下一次做类似任务时，agent 不需要重新发明流程。

项目上下文：AGENTS.md 是给未来的自己留门

长期项目最怕的一件事，是每次换会话都要重新解释一遍：项目在哪、怎么跑、什么不能做、当前状态是什么、下一步是什么。

Hermes 解决这个问题的方式很工程化：把项目规则写进项目自己的 AGENTS.md，把当前状态写进 PROJECT_STATE.md，把任务列表写进 TASKS.md，把关键决策写进 DECISIONS.md。

一个轻量但耐用的项目上下文结构可能长这样：

my-project/
  AGENTS.md             # agent 必读：规则、路径、命令、约束
  docs/
    PROJECT_STATE.md    # 当前状态与恢复方式
    TASKS.md            # 长期任务列表
    DECISIONS.md        # 架构/产品/流程决策
  src/
  tests/

这套结构的美感在于：它不依赖某次聊天，也不依赖某个模型的私有记忆。任何未来的 Hermes、Codex、Claude Code，甚至人类自己，都可以从这些文件恢复项目语境。

换句话说，好的 agent 协作不是把所有东西塞进 AI 的脑袋，而是让项目本身变得可读、可恢复、可审查。

工具调用：让 AI 拥有“现实摩擦力”

工具是 Hermes 的手和眼睛。没有工具，模型只能在语言空间里想象；有了工具，它可以接触现实世界的阻力：文件是否存在、测试是否通过、网页是否能打开、接口是否返回错误。

常见工具可以分成几类：

• 文件工具：读取、搜索、写入、patch 文件；
• 终端工具：运行测试、构建、安装依赖、查看 Git 状态；
• 浏览器 / 网页工具：搜索资料、打开页面、做交互验证；
• 媒体工具：视觉分析、图片生成、语音合成；
• 协作工具：飞书、Telegram、Discord、邮件等平台消息；
• 长期工具：memory、skills、session search、cron jobs。

这里的关键不是“工具越多越好”，而是 agent 知道什么时候该用工具、什么时候不该用。比如：

# 错误姿势：凭印象回答项目是否能构建
# 正确姿势：实际运行验证
npm run verify

# 错误姿势：猜当前分支和 diff
# 正确姿势：读取 git 状态
git status --short --branch

# 错误姿势：靠记忆说文件内容
# 正确姿势：读取文件

成熟的 agent 不是“永远自动化”，而是把自动化放在正确边界内。

多平台网关：AI 不必困在一个入口

Hermes 的另一个特点是 gateway：它可以运行在不同消息平台上，例如 Telegram、Discord、Slack、Feishu、Email 等。

这件事的意义不只是“换个聊天入口”。真正重要的是：同一个 agent 可以出现在你工作的上下文里。

• 在终端里，它像开发伙伴；
• 在飞书里，它像随身项目管家；
• 在聊天软件里，它像快速任务入口；
• 在 cron 里，它像定时巡检员；
• 在 webhook 里，它像事件驱动的自动化节点。

当 AI 从单个网页窗口进入你的真实工作流，它才开始接近“伙伴”而不是“网站”。

provider-agnostic：不要把灵魂绑死在某个模型上

Hermes 的框架思路是 provider-agnostic：你可以接 OpenAI、Anthropic、OpenRouter、DeepSeek、Google Gemini、本地模型或其他兼容 OpenAI-style API 的 provider。

这很重要，因为长期 agent 不应该把自己的工作流完全绑定到某一个模型厂商。模型会迭代、价格会变化、上下文长度会变化、某些任务的最佳模型也会变化。一个好的 agent 框架应该允许你在不重写整个系统的前提下切换模型。

可以把模型看作“心智引擎”，把 Hermes 看作“神经系统 + 工作台”。引擎可以升级，工作台不必推倒重来。

一个真实使用场景：从想法到发布

假设你想维护一个个人博客，同时不想把整个 Obsidian 知识库公开。Hermes 可以帮助建立一条清晰的写作发布流水线：

流程可以是：

1. 在 Obsidian vault 里自由写作、收集资料；
2. 把可公开的文章整理到 publish/blog/；
3. 清理 Obsidian-only 语法、私人 TODO、内部路径和敏感信息；
4. 复制到 Astro 的 src/content/blog/；
5. 图片进入 public/images/posts/；
6. 运行 build、preview 和 QA；
7. 验证通过后再发布。

这个例子看似只是博客，其实体现了 Hermes 的核心哲学：让创作、工程和长期维护之间有一条可审查的通道。

Hermes 适合什么人？

Hermes 特别适合三类人。

1. 有长期项目的人

如果你只是偶尔问几个问题，普通聊天工具就够了。但如果你有长期项目，比如个人博客、自动化系统、研究资料库、产品原型、开源项目，Hermes 的项目上下文和技能沉淀会非常有价值。

2. 愿意建立工作流的人

Hermes 不是“魔法许愿机”。它更像一个可以训练的合作者。你越愿意给它清晰边界、项目文档、验证命令和复用流程，它越能稳定发挥。

3. 对 AI 有审美要求的人

所谓审美，不只是界面好看。它也包括：

• 文件结构是否清晰；
• 命名是否长期可读；
• 自动化是否克制；
• 记忆是否不过度污染；
• 风险边界是否明确；
• 输出是否既准确又有质感。

Hermes 的开放性让你可以把这种审美写进 Soul、skills 和项目规则里。

Hermes 不是什么？

为了避免把它神化，也要说清楚 Hermes 不是什么。

• 它不是免维护的全自动员工；
• 它不是可以随便接管你所有账号的黑盒；
• 它不是越多工具越好的炫技系统；
• 它不是记忆越多越聪明的无限仓库；
• 它不是替代判断力，而是放大判断力。

一个好的 Hermes 实例，应该既强又克制。它能主动推进，但知道何时停下来确认；它能读写文件，但不乱动私人资料；它能总结过去，但不把临时状态永久化；它能生成内容，但不牺牲品味。

建议的上手路径

如果你准备认真使用 Hermes，我会建议按这个顺序来：

1. 先定义 Soul：明确它是谁、如何协作、哪些边界不能越过。
2. 再整理工具：启用你真正需要的 toolsets，不要为了“全能感”乱开。
3. 建立项目规则：每个长期项目放一个 AGENTS.md。
4. 使用状态文档：用 PROJECT_STATE.md 和 TASKS.md 承接跨会话工作。
5. 谨慎使用 memory：只保存长期稳定事实。
6. 把复杂流程写成 skills：让经验复用，而不是每次重来。
7. 坚持验证：测试、构建、预览、截图、diff，该跑就跑。

一个非常小的配置哲学可以总结成：

SOUL.md        -> 我是谁，我如何判断
memory         -> 用户和环境的长期稳定事实
AGENTS.md      -> 当前项目怎么做，边界在哪里
TASKS.md       -> 现在做到哪，下一步是什么
skills         -> 可复用的复杂流程
session search -> 回忆历史，但不污染长期记忆

最后：真正的潜力，是共同进化

Hermes 最有意思的地方，不是它第一次启动时有多强，而是它可以被长期塑造。

你可以给它一个名字，给它一种语气，给它项目规则，给它工具边界，给它失败后的修正，给它可复用的技能。它每完成一次复杂任务，就可以把经验沉淀下来；每犯一次错，也可以把教训写进更合适的位置。

这让 Hermes 更像一个会成长的系统，而不是一次性产品。

当然，成长不是把一切都交给 AI。恰恰相反，最好的 Hermes 使用方式，是人类保持方向感、审美和最终判断，agent 负责执行、验证、组织和放大能力。

如果普通 AI 助手像一盏台灯，Hermes 更像一间可以不断改造的工作室。灯光只是开始，真正重要的是：你会在里面长期做什么，留下什么，又如何让下一次创作比这一次更从容。

而这，才是 agent 最值得期待的地方。