最近 Agent 项目越来越多，但大多数还停留在“能不能调用工具、能不能完成任务”的层面。Hermes 真正有意思的地方，不是它又接了多少模型和平台，而是它试图解决一个更长期的问题：AI 能不能记住你的工作方式，把经验沉淀成技能，并在下一次任务里少走弯路。

当下AI 开源圈，前有各种 coding agent，后有多平台agent gateway，中间还有一堆号称能接工具、能跑终端、能自动完成任务的 autonomous agent。看多了以后，人其实还是会有点麻木。

因为大多数 Agent 项目讲到最后，都像是在重复同一句话：

“我能调用工具。

我能执行任务。

我能帮你写代码。

我能接入各种平台。

我能让 AI 不只是聊天，而是真的干活。”

这些话当然没错，但听多了就会有一个问题：如果只是“让模型多调用几个工具”，那 Agent 赛道是不是已经没什么新故事了？所以两个多月前我第一次看Hermes Agent的时候，也有类似的怀疑。

Nous Research做了一个开源 Agent，支持自托管，能长期运行，有 memory，有 skills，能接 Telegram、Discord、Slack、WhatsApp、Signal、Email、Feishu、Wechat…也能跑 CLI、cron、terminal、browser、MCP。

乍一听，好像又是一个“给大模型装上手脚”的项目。

但越往下看，越觉得它真正有意思的地方，不是它能不能执行任务，而是它试图回答一个更难的问题：不单要会干活，更重要是“会成长”

当模型不够强的时候，我们还能把问题归因于“能力不足”。但当模型已经能写代码、查资料、调工具、跑命令、生成文档、拆任务之后，真正影响长期体验的，反而变成了另一个东西：经验能不能留下来。

Hermes 的切入点就在这里。

它不是单纯想做一个更会聊天的 AI，也不是只想做一个更强的coding copilot。它想做的是一个长期在线、可以常驻服务器、能记住用户习惯、能把重复任务沉淀成 skills，并且能随着使用时间增长而逐渐变强的Agent runtime。

说白了，Hermes 想做的不是“这一次帮你完成任务”。

它想做的是“下一次别再从零开始”。

这才是它值得认真看的地方。

大多数 Agent 的问题，不是不会干活，而是不会积累经验

我们先把问题拉回到真实使用场景。

假设你是一个 AI 产品经理，你每天会让 AI 做很多事：整理竞品、拆解产品、生成 PRD、写会议纪要、追踪开源项目、分析用户反馈、做功能方案、写文章、检查数据、整理信息源。

刚开始用 AI 的时候，你会觉得很爽。

因为它确实能帮你省时间。

但用久了以后，你会发现一个非常烦的问题：你不是在训练一个助手，而是在反复培训一个临时工。

每次开始一个任务，你都要告诉它：

• 我是谁。
• 我要什么风格。
• 我不喜欢什么表达。
• 这个任务以前怎么做过。
• 这个项目有什么历史背景。
• 哪些资料是可信的。
• 哪些说法不要再用了。
• 输出结构应该怎么排。
• 最后怎么验收才算完成。

更夸张的是，有些事情你已经讲过十遍了，但下一次它还是不知道。

这就导致一个非常现实的使用瓶颈：AI 单次能力很强，但长期协作很弱。

它像一个很聪明、但永远不入职的外包。

你每次都能让它干活，但每次都要重新onboarding。

这也是为什么很多人用 AI 用到后面，会从“惊艳”变成“疲惫”。不是因为 AI 没价值，而是因为你发现，自己花了很多精力在反复解释上下文、反复修正偏好、反复告诉它同一套工作流。

Hermes 想解决的就是这个问题。

它把 Agent 的重点从“单次任务执行”推向“长期经验积累”。

这个转向很关键。

因为如果 Agent 只是会调用工具，它最多是一个执行器。

如果 Agent 会记住经验、沉淀流程、复用路径，它才有可能变成一个长期助手。

如果这些经验还能被定期自动写成可读、可审计、可修改的 skills，它就不只是记忆，而是开始形成一种“程序性经验”。

这就是 Hermes 和很多普通 Agent 项目的区别。

它真正押注的，不是模型下一次回答得更聪明，而是系统下一次执行得更熟练。

从自托管到 Skills：重新理解 Hermes Agent

如果用一句话概括 Hermes Agent，我想Nous Research会这么说：它是一个自托管、长期运行、带记忆和技能系统的Agent runtime。

第一个是自托管。

Hermes不是一个纯 SaaS 产品，也不是只能跑在某个封闭平台里的助手。它可以部署在本地电脑、GPU 集群，甚至 serverless 环境里。对开发者、研究者来说，这意味着你可以把它放在自己的基础设施里，让它长期运行，而不是每次打开网页临时聊一会儿。

第二个是长期运行。

这个点比很多人想象得重要。因为 Agent 一旦长期运行，它就不再只是一个问答窗口，而更像一个 daemon。你可以通过 CLI 找它，也可以通过 Telegram、Discord、Slack、WhatsApp、Signal、Email 找它；你可以主动发指令，也可以让它通过 cron 定时执行任务，比如日报、备份、网页监控、日志审计、资料整理。

第三个是记忆。

但 Hermes 的记忆不是简单地把所有聊天记录无限塞进上下文。它有 durable memory，有会话搜索，有 SQLite + FTS5 的历史检索，有 USER.md 和 MEMORY.md 这样的整理型记忆文件。核心思想不是“什么都记”，而是“把高价值信息留下来”。

第四个是 skills。

这是 Hermes 最值得看的部分。在 Hermes 里，skill 不是一个普通知识库条目，也不是一段随手写的提示词。它更像一份任务操作手册：什么时候用、怎么做、容易踩什么坑、如何验证结果。比如你经常让它帮你写开源项目分析文章。第一次它可能会摸索：先查资料，再看 GitHub，再整理架构，再对比竞品，再输出观点。但如果这个流程被沉淀成 skill，下一次它就不需要重新想一遍，而是可以直接调用已有的程序性经验。

这就像一个新人第一次做竞品分析，需要你手把手教。做了几次以后，他会形成自己的 SOP。再往后，你只要说“按我们之前那套方式做”，他就知道怎么执行。

Hermes 的 skills，就是让 Agent 形成这种 SOP 的机制。

所以，不要把 Hermes 理解成一个“聊天机器人加工具调用”。

更准确的理解是：它是一个把记忆、工具、任务经验和技能沉淀放进同一个运行时里的 Agent 系统。

这句话听起来不如“AI 自动帮你干活”那么性感，但它更接近真实生产力系统的核心。

因为真正长期有用的 AI，不是每次都灵光一现，而是能把做过的事情变成下一次的基础。

Hermes 的关键，不是 memory，而是“程序性记忆”

很多 AI 产品都说自己有 memory。

但 memory 这个词其实很容易被误解。

多数人一听到 AI 记忆，就会想到：它记得我的名字，记得我喜欢什么风格，记得我上次聊了什么。

这当然有用，但还不够。

对一个长期 Agent 来说，更重要的不是“记住事实”，而是“记住怎么做事”。

比如：

• 它不只是记得你是 AI 产品经理，而是记得你写产品分析文章时喜欢先从现实问题切入，再拆工作流、成本、边界和产品判断。
• 它不只是记得你常用某个开源项目，而是记得这个项目的部署流程、配置坑点、常见错误和验证命令。
• 它不只是记得你要写日报，而是记得日报数据从哪里取、怎么分类、哪些异常要提醒、最后用什么格式发到哪个渠道。

这类记忆不是普通事实，而是程序性记忆。

它的价值不在于“知道”，而在于“会自动做”。

Hermes 的 skills 就是在做这件事。模型在完成任务后，根据系统提示中的启发式条件，自行决定是否调用 skill_manage 写入/更新 skill。官方源码里 SKILLS_GUIDANCE 明确写着：完成复杂任务 “5+ tool calls”、修复棘手错误、发现复杂workflow后，用 skill_manage 保存为 skill；用 skill 时如果发现过期/不完整/错误，要立即 patch。

一个 skill 通常会包含使用场景、执行步骤、注意事项、验证方法。它不是让模型凭感觉发挥，而是把某类任务的成功路径写下来，让 Agent 后续可以复用。

这比黑盒向量记忆更接近产品经理能理解的工作流资产。

因为它可读。

你能打开看。

它可改。

你能手动修。

它可审计。

你知道 Agent 到底学了什么。

它可版本化。

你可以回滚、对比、管理。

它可共享。

团队之间可以复用类似的技能。

而 Hermes 的核心差异化来自“做模型的人重新理解了 Agent 应该如何与模型共同进化”这一独特视角 。

这个选择非常关键。

因为今天我们谈 AI 自我进化，很容易滑向一种玄学叙事：模型自己变强了，系统自己优化了，Agent 自己学会了。

但问题是，如果你看不见它怎么变强，就不敢真的把任务交给它。

Hermes 的路径更现实：模型本身不一定变，变的是运行时的知识、流程和技能库。

这就像一个员工没有换脑子，但他有了越来越多的工作手册、复盘记录、操作模板和检查清单。

从产品角度看，这比“黑盒变聪明”更有落地价值。

因为用户真正需要的不是一个神秘进化的 AI，而是一个可控、可查、可改、可持续变熟练的系统。

为什么它选择 server-first，而不是 IDE-first？

Hermes 有一个很重要的产品选择：它不是从 IDE-first 开始，而是从 server-first 开始。

这和 Claude Code、Codex 这类 coding agent 的路线不太一样。

Claude Code 和 Codex 的核心场景很明确：代码库、终端、编辑器、PR、测试、调试、重构。它们很适合软件工程任务，尤其适合围绕 repo 的深度执行。

但 Hermes 不只想活在代码编辑器里。

它想常驻在你的服务器上，成为一个跨入口、跨任务、长期在线的 Agent。

这个选择会带来很多良好的AI产品成效：

• 如果 Agent 只在 IDE 里，它主要服务开发任务。
• 如果 Agent 常驻服务器，它就可以服务更广的个人和团队任务。
• 如果 Agent 只在某次会话里，它结束后就消失。
• 如果 Agent 是长期 daemon，它就可以持续监听、定时执行、跨平台响应。
• 如果 Agent 只绑定一个入口，它的上下文容易被入口切碎。
• 如果 Agent 背后是同一个 runtime，不同渠道就可以共享记忆和 skills。

这就是 Hermes 为什么支持 CLI、Gateway、API、Batch、Python Library，也支持 Telegram、Discord、Slack、Email 等平台。

它不是为了炫技说“我入口很多”。

多入口背后的产品逻辑是：用户不应该为了找 Agent 而切到固定应用，Agent 应该出现在用户本来工作的地方。

你在终端里，就用 CLI。

• 你在 Telegram 里，就发消息。
• 你在 Slack 里，就让它进工作流。
• 你想做定时任务，就用 cron。

你想把它接到别的系统，就用 API。

这样一来，Hermes 更像一个个人 Agent 操作系统的雏形，而不是一个单点工具。

当然，server-first 也不是白来的。

它会带来更高的部署门槛，也会带来更大的安全压力。

因为一个常驻服务器、能读写文件、能跑终端、能开浏览器、能接 MCP、能调用外部工具的 Agent，已经不是“帮你写几句话”的级别了。它有真实权限，也会产生真实后果。

这就是 Hermes 后面绕不开的安全问题。

能力越强，信任门槛越高。

Hermes 和 OpenClaw、Claude Code、Codex 的关系，不是简单替代

当然，聊 Hermes，就必然绕不开这几个参照物：OpenClaw、Claude Code、OpenAI Codex、OpenHands / OpenDevin。

但我不太建议用“谁替代谁”的方式看它们。

更好的方式是看它们分别站在哪一层。

OpenClaw 更像多平台 agent gateway。它的核心价值是把多个聊天平台、多个 agent、多个入口串起来，做路由、会话和多渠道连接。它更像入口层和调度层。

Claude Code/OpenAI Codex更像专业 coding agent。它的强项是深入代码库、修改文件、运行命令、调试和重构。它更像开发者工作流里的垂直执行器，它和云端任务、沙箱、PR、团队工作流产品体系结合更深，产品化程度更高。

OpenHands / OpenDevin 更像软件工程 agent 平台。它的中心是工程任务自动化、sandbox、GitHub / GitLab 集成、SDK 和企业化扩展。

那 Hermes 站在哪里：长期记忆层、技能沉淀层和个人 runtime 层。

它不是最强的代码编辑器，也不一定是最成熟的多渠道 gateway，更不是最产品化的闭源工程平台。

它的差异点在于：它想让 Agent 长期学习你怎么做事。

这就决定了它和其他系统可能不是替代关系，而是编排关系。

• Hermes 可以调用 Claude Code。
• Hermes 可以委托 Codex。
• Hermes 可以接入 OpenHands。
• Hermes 可以通过 MCP 调用更多工具。
• Hermes 可以把这些垂直能力包进自己的长期任务流里。

这就像一个团队里，不同角色分工不一样。

• Claude Code/OpenAI Codex像一个很强的工程师。
• OpenClaw 像一个多渠道前台和路由系统。
• OpenHands 像一个工程作业平台。
• Hermes 则更像一个长期记得你怎么工作的协调者和经验库。

所以，Hermes 的竞争点不只是“我能不能写代码”。

它真正的竞争点是：谁来长期保存用户的任务经验？谁来把反复执行的流程变成 skills？谁来跨平台调度这些能力？谁来让 Agent 不再每次从零开始？

从AI产品经理视角看，Hermes 改的不是功能，而是工作方式

如果只看功能清单，Hermes 当然有很多点可以讲：多模型、多入口、记忆、skills、工具调用、浏览器控制、终端、MCP、子 Agent、cron、自托管。

但产品分析最怕停在功能清单。

因为功能多，不代表产品成立。

真正要问的是：它改变了哪段工作流？

Hermes 改变的，是“AI 协作从一次性外包，走向长期雇佣”的工作方式。

一次性外包的特点是：每次重新说明需求，每次重新交代背景，每次重新验收，每次重新踩坑。

长期雇佣的特点是：越做越熟，越做越知道你的偏好，越做越能复用以前的经验。

Hermes 想让 Agent 从前者变成后者。

这对AI产品经理很重要。

因为未来很多 AI 产品的竞争，可能不只是“谁的模型更强”，而是“谁的工作流资产积累得更深”。

模型能力会变成基础设施。

工具调用会变成标配。

多入口会逐渐普及。

真正难的是，用户和系统之间长期形成的协作资产。

这些资产包括：用户偏好、任务历史、执行路径、失败经验、验证方式、模板结构、工具组合、团队 SOP、安全边界、上下文检索方式…..

如果一个 Agent 每次任务都能把这些东西沉淀一点点，它的长期价值就会不断增加。

这也是为什么Hermes的slogan “The agent that grows with you”虽然听起来有点理想化，但实则清脆悦耳，极快拉进与用户的距离

因为用户真正想要的，不是一个永远很聪明但永远陌生的 AI。

而是一个越来越熟悉自己工作方式的 AI。

但“越用越懂你”背后，有一个被低估的问题：记忆不是越多越好

讲到这里，很容易得出一个表层结论：既然长期记忆这么重要，那 Agent 多记一点不就好了？

并不是。

长期记忆最大的问题，恰恰是不能乱记。

人脑会遗忘，某种程度上是优点。

组织会归档，也需要清理。

产品知识库要维护，否则就会变成垃圾场。

Agent memory 也是一样。

如果一个 Agent 把所有东西都当成重要信息，最后结果不是更聪明，而是更混乱。

它可能记住过期偏好。

• 记住一次性的任务要求。
• 记住错误结论。
• 记住用户随口说的话。
• 记住低价值细节。
• 记住被 prompt injection 污染的信息。

然后这些记忆会在未来任务里反复影响它。

这就是 memory hygiene 的问题。

Hermes 的有界记忆设计，某种程度上就是在对抗“无限记忆”的诱惑。它不试图把所有历史原文都塞进上下文，而是通过压缩、筛选、检索和总结保留高价值信息。

但这里有一个产品难点：谁来判断什么是高价值？

• 如果完全交给模型判断，它可能会误判。
• 如果完全交给用户判断，用户负担太重。
• 如果没有清理机制，记忆会污染。
• 如果清理太激进，又会丢掉有用经验。

这件事听起来像技术细节，但其实是长期 Agent 的核心产品能力。

因为用户愿意让 Agent 记住自己，前提是用户相信它记得对、忘得掉、改得了、查得到。

这四件事缺一不可。

1. 记得对，是质量问题。
2. 忘得掉，是控制问题。
3. 改得了，是纠错问题。
4. 查得到，是可见性问题。

如果一个长期 Agent 只能说“放心，我会记住你”，但用户看不到它记了什么，也不能方便地删除和修改，那这不是信任，而是风险。

所以 Hermes 的 memory 和 skills 设计虽然很有价值，但真正能不能产品化，取决于它能否把记忆治理做成用户可理解、可操作、可回滚的系统。

自进化不是玄学，真正关键是可审计

朋友们，读到这里，不妨让我们再讨论个事，关于Hermes里的一个很容易被营销化的词：self-evolution。

不经想起前几个月openclaw爆火后，随之出现的项目”Evolver”，“自进化”这是个伟大的方向，也是个机关纵深的迷宫命题。

听起来很酷，好像 Agent 会自己变强、自己修正、自己写代码、自己优化系统。

因为如果一个系统真的能自我修改，而你又不知道它改了什么，那用户不会觉得兴奋，只会觉得害怕。

当然，还好的是，Hermes 比较现实的地方在于，它的自进化不主要发生在模型权重里，而是发生在 skills、prompts、tool descriptions 和 runtime 知识层。

更进一步，Hermes 的 self-evolution 路径不是让 Agent 直接乱改主分支，而是通过评估、候选改进、测试、大小限制、benchmark 和 PR review，把改动外部化、流程化、可审查化。

这个思路很重要。

因为长期 Agent 的自我改进，一定不能是黑盒的。

它必须能回答几个问题：改了什么？为什么改？依据什么评估？有没有通过测试？谁批准？怎么回滚？是否影响已有任务？是否引入新风险？

如果这些问题回答不了，“自进化”就不是产品能力，而是事故源头。

所以，Hermes 的正确打开方式，不是把它理解成“AI 会自己成长，所以不用管了”。

恰恰相反，它更像是在探索一种“可治理的成长”。

• 让 Agent 可以学习，但学习结果要外化。
• 让 Agent 可以改 skill，但改动要可见。
• 让系统可以优化 prompt，但要经过评估。
• 让经验可以沉淀，但要允许审计和回滚。

这比“完全自主”听起来保守，但更接近真实产品。

因为在生产环境里，可信比酷更重要。

Hermes 最适合谁？不是所有人都该马上用

如果你问Nous Research团队Hermes现在适合普通用户吗？那收到的答复大概率是否定的。

至少不是开箱即用那种适合。

因为 Hermes 的价值和门槛是绑定在一起的。

它适合愿意自托管、愿意配置模型、愿意管理工具权限、愿意维护 skills、愿意理解 Agent 风险的用户。

典型人群可能是：开发者、AI 研究者、power user、小团队技术负责人、需要长期自动化的内容团队、需要多入口任务调度的个人、愿意把 AI 作为基础设施来搭的人。

他们会把 Hermes 部署在 VPS、云服务器或本地机器上，让它长期运行，接入自己的工具链、消息平台和工作流。

但如果一个用户只是想“打开网页，让 AI 帮我写几句话”，Hermes 反而是杀鸡用牛刀了。

这不是缺点，而是产品定位问题。

Hermes 不是轻量消费级 AI 助手。

它更像一个给技术型用户和小团队准备的 Agent runtime。

它的价值不是一分钟惊艳你，而是一个月后少让你重复很多事。

这种产品很难用传统消费级指标去评价。

因为它不一定第一天最好用，也不一定最省心。

但如果 skills 和 memory 真的跑起来，它的复利会出现在长期使用里。

这就像 Notion、Obsidian、Raycast、Zapier、n8n 这类工具，刚开始都需要配置和搭建，但一旦和你的工作流绑在一起，就会形成迁移成本。

Hermes 想形成的，也是这种长期工作流粘性。

只是它的对象从“工具配置”变成了“Agent 经验”。

从商业化看，Hermes 最值钱的不是 Agent，而是 skill 生态

如果 Hermes 未来要做大，它最有想象力的地方，可能不是单个 Agent 本身，而是 skills 生态。

为什么？

因为 Agent runtime 可以有很多个。

模型 provider 可以有很多个。

工具调用框架也会越来越多。

但高质量 task skills，可能会成为真正稀缺的资产。

一个好的 skill，不只是提示词模板。

它包含任务理解、步骤拆解、工具选择、边界条件、失败处理和验收方法。

这类东西很像组织知识，也很像经验 SOP。

比如：

• 如何写一篇高质量开源项目分析文章。
• 如何审查一个 GitHub 仓库是否值得采用。
• 如何做 AI 产品竞品分析。
• 如何完成某个云服务部署。
• 如何把会议纪要转成产品需求。
• 如何监控某个网页变化并生成提醒。

如何让 coding agent 按团队规范提交 PR。

这些 skills 如果可读、可审计、可迁移，就有机会成为 Agent 时代的新型知识资产。

这也是 Hermes 最乐观的路径：它不只是做一个 Agent，而是推动 skills 成为开放 Agent 生态里的能力标准。

如果未来不同 Agent、不同模型、不同工具平台都能复用类似结构的 skills，那 Hermes 的价值就不只在“我这个 Agent 能做什么”，而在“我定义了一种沉淀 Agent 经验的方式”。

这件事很大。

因为今天 AI 应用的一个核心问题是：经验很难迁移。

你在一个平台调好的 prompt，很难迁到另一个平台。

你在一个 Agent 里跑通的流程，很难迁到另一个 Agent。

你教会某个系统的工作方式，很难变成团队共享资产。

如果 skills 能变成标准化、可版本化、可审计、可安装的程序性记忆，那么 Agent 生态会从“每个产品各自聪明”，走向“经验可以流动”。

这比单个产品爆火更有长期意义。

但 Hermes 也有三道坎：成本、安全和信任

讲到这里，可能有人会觉得 Hermes 很有前景。

是的，它方向很有价值。

但我也不想把它写成一个无脑看好的项目。因为越是长期 Agent，越容易遇到硬问题。

第一道坎是成本。

很多人算 AI 成本，只算单次模型调用价格。

但 Agent 的成本不是这么算的。

• Agent 会多轮推理。
• 会调用工具。
• 会搜索。
• 会读文件。
• 会压缩上下文。
• 会反复验证。
• 会启动子 Agent。
• 会在后台跑任务。
• 会保存和检索历史。

所以，一个长期运行的 Agent，真实成本一定要放到整条链路里看。

单次回答便宜，不代表长期运行便宜。

单个模型便宜，不代表多工具、多轮任务便宜。

开源项目免费，不代表运维、配置、安全、排错免费。

Hermes 面向 power user 和小团队还好，因为这类用户愿意为控制权和长期收益付出成本。但如果要走向更大用户群，成本可解释性会变得非常重要。

第二道坎是安全。

Hermes 的能力边界很强：terminal、browser、web、MCP、文件系统、子 Agent、后台任务、skills 自修改。

这些能力每增加一个，风险面就扩大一圈。

• 危险命令怎么确认？
• 文件权限怎么隔离？
• MCP 凭证怎么过滤？
• prompt injection 怎么防？
• 跨会话数据怎么隔离？
• 后台 Agent 能不能执行外部副作用？
• skill 安装和修改怎么审计？
• 出错后怎么回滚？

这些不是边角问题，而是核心产品问题。

因为 Hermes 的卖点就是长期运行和自主执行。你越强调它能做事，就越要证明它不会乱做事。

第三道坎是信任。

长期 Agent 的信任不是靠一句“我会保护你的隐私”建立的。

它来自用户持续看到系统可控。

• 用户要能看到它记了什么。
• 能知道它为什么调用某个工具。
• 能限制它能做什么。
• 能禁止它改什么。
• 能回滚它学错的东西。
• 能区分用户修改、Agent 修改和上游更新。
• 能在关键动作前确认。
• 能在出问题后追溯。

如果这些做不到，“越用越强”就会变成“越用越不可控”。

这是 Hermes 最大的产品悖论：

它必须足够自主，才有价值；

它又必须足够受控，才值得信任。

这也是所有长期 Agent 都会面对的问题。

AI 产品经理应该从 Hermes 看见什么？

对 AI 产品经理来说，Hermes 最值得看的不是某个具体功能，而是它提出了几个长期问题。

第一个问题：AI 产品的核心资产，正在从 prompt 迁移到 workflow。

过去我们讨论 AI 产品，经常讨论提示词怎么写、模型怎么选、上下文怎么塞。

这些当然还重要。

但长期看，更关键的是工作流怎么沉淀。

一个产品如果只是让用户每次写更好的 prompt，它的上限有限。

一个产品如果能把用户反复做的事情沉淀成可复用流程，它才可能形成长期价值。

Hermes 的 skills 就是在往这个方向走。

第二个问题：Agent 的竞争，不只是执行能力，而是经验复利。

执行能力可以被模型进步快速拉平。

但经验复利需要时间积累。

如果一个 Agent 用了一百次后，和第一次使用没区别，那它只是工具。

如果一个 Agent 用了一百次后，明显更懂你的工作流，它才开始像助手。

第三个问题：可见性会成为长期 Agent 的产品底座。

过去很多 AI 产品喜欢把复杂性藏起来，用户只看结果。

但长期 Agent 不一样。

因为它会记忆、会调用工具、会改 skill、会产生副作用。用户不能只看结果，还要看过程、看依据、看权限、看历史。

所以长期 Agent 的 UI，不应该只是聊天框。

它可能需要 memory 管理界面、skill 审计界面、任务轨迹界面、权限控制界面、回滚机制、风险提示、评估报告。

这会让 AI 产品经理的工作发生变化。

以前我们设计的是“用户如何提问”。

现在我们要设计的是“用户如何管理一个会行动、会学习、会犯错的系统”。

这比聊天产品复杂得多。

第四个问题：未来的 AI 产品经理，要更像系统设计者。

因为 Agent 产品不是单点能力，而是一套系统：模型、工具、上下文、记忆、权限、评估、工作流、用户控制、异常处理。

• 你不能只问“这个功能好不好用”。
• 你还要问“这个能力出错时怎么办”。
• 你不能只问“模型能不能完成”。
• 你还要问“完成标准是什么，谁来验收”。
• 你不能只问“能不能自动化”。
• 你还要问“哪些环节必须让人确认”。

Hermes 这种产品，对AI产品经理最大的启发就是：AI 产品正在从交互设计，走向运行时设计。

Hermes 不一定会成为最强Agent，但它抓住了最难的问题

文末，如果要给 Hermes下一个最终判断，我想我会这么说：Hermes虽然不一定会成为用户量最大的 Agent，也不一定会成为最易用的 AI 助手，但它已然抓住了 Agent 时代一个非常关键的问题：AI 如何在真实使用中积累经验。

今天很多 Agent 项目都在回答“AI 能不能做事”。

Hermes 追问的是“AI 做完事以后，能不能留下些什么”。

这个问题更慢，但更重要。

因为真正改变工作方式的，不是某一次惊艳执行，而是长期协作中的经验复利。

一个不会积累经验的 Agent，永远像临时工。

一个能沉淀经验的 Agent，才有机会成为长期同事。

当然，Hermes 现在还不是一个低门槛的大众产品。它有部署门槛，有安全压力，有 memory hygiene 问题，有 skill 质量问题，也有自修改治理问题。

但这些问题并不削弱它的价值，反而说明它进入了 Agent 产品真正困难的区域。

聊天机器人时代，核心问题是回答。

工具调用时代，核心问题是执行。

长期 Agent 时代，核心问题会变成记忆、技能、权限、信任和治理。

Hermes 的意义就在于，它没有只停留在“让 AI 调工具”这一步，而是把 memory、skills、self-improvement、自托管、多入口和长期运行放到了同一个 runtime 里。

这条路很难，但方向值得看。

因为未来我们真正需要的，可能不是一个永远强大但永远陌生的 AI。

而是一个能够长期和我们一起工作，知道我们怎么判断，记得我们踩过哪些坑，能把经验变成流程，也允许我们随时审查和修正它的 AI。

Hermes 不是终点。但它提出了一个很重要的起点：当模型越来越强之后，AI 产品真正的竞争，可能不再是谁更聪明，而是谁更会积累。