当所有AI Agent都有记忆和本地执行能力，开源项目凭什么活？——从“大厨竞争”到“老板思维”

本文欲回答的核心问题： 在 Codex 和 Claude Code 等闭源产品疯狂补齐长期记忆、本地执行、后台任务等功能后，像 Hermes 和 OpenClaw 这样的开源 Agent 是否还有生存空间？它们凭什么不害怕？

半年前，当你用 Hermes 或者 OpenClaw 的时候，心里还挺踏实的。
长期记忆，有。本地跑任务，能。接消息 App，没问题。24 小时不关机，基操。
那会儿 Codex 和 Claude Code 写代码确实猛，但这些持久化的活儿还差口气。

现在再看看。

Codex 有了 memories、skills、subagents、AGENTS.md、定时任务。
Claude Code 有了 CLAUDE.md、auto memory、hooks、skills、background agents、scheduled tasks、Slack 通道。
全在补课。疯狂补。

旧护城河被一口一口吃掉了。

所以今天不想掰扯 Hermes 比 Codex 多了几个功能。没意思。那种比较已经过时了。
想聊一个更底层的东西：当大家都有记忆、都能本地跑、都能定时干活以后，开源 Agent 还能不能活，凭什么活。

先看一张对比表（来源：原文配图《旧护城河被吃掉了》）。

过去的优势（Hermes/OpenClaw 领先） 现在 Codex/Claude Code 的动作 真正变化
长期记忆（memories） memories / auto memory 不是有没有记忆，而是记忆归谁
本地执行（CLI 读写文件、跑命令） CLI 读写文件、跑命令 本地跑已成标配
skills / hooks / subagents skills、hooks、subagents 快速补课，工作流能力不再稀缺
后台任务 / 24小时运行 background agents、scheduled tasks 24小时任务不再稀缺
项目规则（AGENTS.md） AGENTS.md / CLAUDE.md 项目上下文开始产品化
消息入口（App） Slack / Channels / 桌面端 入口心智也在逼近助理
工具连接（MCP 等） MCP、plugins、automation 连接能力变成基础设施

看完这张表，有件事已经很明显了：现在还拿“有记忆、能本地执行”当护城河，说实话，不够硬了。Codex 和 Claude Code 也在干这些。

真正的问题变了。

大厨越强，越需要老板：开源 Agent 的新定位

本段核心问题： 如果不再比拼功能列表，Hermes 和 OpenClaw 应该扮演什么新角色才能活下去？

开一家餐厅。
Codex 和 Claude Code 是两位顶级大厨。刀工一流，火候精准，什么菜都能做出来。
但这俩大厨各带各的厨房、各用各的菜谱、各记各的笔记。
让 Claude Code 做了一道招牌菜，Codex 完全不知道。教会 Claude Code 爱吃几分熟、不爱放香菜，这些习惯到了 Codex 那边一片空白。

Hermes 和 OpenClaw 想做的，不是什么第三个大厨。
是餐厅老板。

老板不需要比大厨更会颠勺。老板干的活儿是另一套：

  • 记住每个客人的口味和习惯——这是记忆。
  • 决定今天哪个大厨炒哪个菜——这是调度。
  • 管好食材采购和库存——这是权限和工具链。
  • 保证厨房 24 小时能转——这是后台运行。

大厨越强，餐厅越赚钱，但得有人干老板的活儿。
Codex 和 Claude Code 越强，那些只想当第三个大厨的 Agent 会死得越来越快。
但越强，也越能证明一件事：需要一个老板层来管这些大厨。

下图清晰地展示了这种角色分工（来源：原文配图《Hermes/OpenClaw vs Codex/Claude Code》）：

  • 顶层（Hermes/OpenClaw）：餐厅经理/编排层，负责记忆、权限、调度、日志、模型路由。具体包括长期记忆、短期记忆、知识库、向量存储；角色权限、资源权限、操作审批；任务分解、并发控制、队列管理、优先级策略；执行日志、审计追踪、错误告警、可观测性；模型选择、负载均衡、降级策略、成本控制。
  • 下层（Codex / Claude Code）：顶级主厨，各自拥有顶级代码生成与推理能力。
  • 最底层：工具箱、知识库、API 服务、数据源、外部系统。

反思： 我见过太多团队一上来就纠结“哪个 Agent 写代码更强”，却忽略了真正的瓶颈从来不是单点能力，而是如何把不同能力的 Agent 组织起来、分配任务、合并结果。这个认知转变，比选型本身重要十倍。

记忆到底是谁的：从“产品功能”到“个人资产”

本段核心问题： 当所有工具都有记忆功能后，记忆应该绑定在具体产品里，还是成为用户自己可控的资产？

很多人还在纠结 Hermes 到底有没有长期记忆。坦率地讲，这个问法本身就问错了。

真正该问的是：现在用 Codex 攒的那些记忆，两年后如果想换模型，还能不能带走？

Codex 的 memories 是为了让 Codex 更好地接上上一次的任务。Claude Code 的 memory 是为了让 Claude Code 更懂当前这个项目。都有用，我不否认。
但它们的记忆有个共同点：绑在各自的产品里。

Claude Code 的记忆就像一个厨师的私人小本本。他记得你爱吃辣、不爱香菜，但如果哪天这个厨师走了，口味记录也跟他一块儿走了。这就很离谱了，对吧。

Hermes 和 OpenClaw 想争的是什么位置？
让记忆变成你自己的东西，不是某个模型的附属品。

一个长期用 AI 搞内容的人，记忆应该包括：

  • 选题标准、常看的信息源（不是上次 Claude 帮我搜过啥，是我为什么选这个题）。
  • 标题风格、什么时间段发效果最好。
  • 排版习惯：用几级标题、配图怎么排、结尾怎么写。
  • 哪些信息需要二次核实，哪些直接 pass。
  • 什么场景下用哪个工具最顺手。

这些东西如果只存在 Claude Code 里，换到 Codex 全得重新教一遍。存 Codex 里，换回 Claude 又是白纸一张。

记忆只能服务一个模型，它就是产品功能。
记忆能服务所有模型和工具，它才是你自己的 AI 家底。

场景化案例：假设你是一个独立开发者，每天要用 AI 完成代码审查、Bug 修复、文档生成、社交媒体发布。你花了三个月教会 Claude Code 你的代码风格、常用库、测试习惯。突然有一天，你发现 Codex 在处理某个批量重构任务上效率更高。如果你所有的记忆都锁在 Claude Code 里，迁移成本高到让你放弃——你就被锁定了。而如果你从一开始就把记忆存在一个与模型无关的 runtime 层（比如 Hermes），那么无论是 Claude、Codex、还是本地模型，都能随时读取和写入同一套记忆体系。这才是真正的“记忆自由”。

本地控制面：不只是“能在本地跑命令”

本段核心问题： “本地执行”和“本地控制面”有什么区别？为什么后者才是开源 Agent 真正的护城河？

“本地执行”和“本地控制面”，听起来绕口。其实很简单。

本地执行：Agent 能不能在电脑上读写文件、跑命令。
本地控制面：Agent 的入口、记忆、权限、调度、模型路由、日志，到底归谁管。

现在 Codex CLI 和 Claude Code 都能在项目文件夹里干活。它们确实能本地执行。
但换个角度想：

  • 半夜在 Claude Code 里跑了个任务卡住了，你能绕过去看一眼怎么回事、手动调一下、换个模型重跑吗？
  • 在 Codex 里攒了一堆 workflow，有天想搬到本地模型上跑（因为涉及隐私），搬得动吗？

说实话，不太好搬。

本地执行解决的只是“任务在哪儿跑”。
但本地控制面解决的是“这摊子事到底归谁管”。

Hermes 和 OpenClaw 要争的，不是一个“我也能在本地跑命令”的标签。
而是这个 Agent 的整个生命周期——从触发、执行、记录、调整到复用——全都攥在自己手里。

  • 用谁的模型，自己说了算。
  • 什么时候跑，自己说了算。
  • 结果存哪里，自己说了算。
  • 想换模型就换，出问题了能看到完整日志、能手动介入、能调参数。

用 Codex 或 Claude Code 的感觉不一样。那些工具确实好用，但在人家的厨房里做菜，有些东西看不到、改不了、也搬不走。
Hermes 和 OpenClaw 想做的，是把整间厨房的钥匙还回来。

操作示例（基于原文逻辑推演）：假设你想搭建一个每日自动抓取特定网站、用本地模型做摘要、然后推送到 Telegram 频道的工作流。

  • 在 Codex 中，你可能需要写一个脚本并依赖 Codex 的定时任务功能，但模型选择和数据处理逻辑都被限定在 Codex 的框架内。
  • 在 OpenClaw 中，你可以这样配置：

    1. 触发：每天 8:00（cron）
    2. 执行：调用本地小模型（如 Ollama 上的 Gemma）做网页解析和摘要
    3. 检查：如果摘要置信度低于阈值，自动换用 Claude API 重新生成
    4. 存储：结果保存到本地 SQLite，同时写入长期记忆（供日后检索）
    5. 通知：通过 Telegram bot 发送，并附上执行日志链接
    6. 权限控制：只有特定频道 ID 才能接收，且敏感数据不经过任何第三方服务器

整个过程，入口、模型选择、数据流向、权限、日志全部在本地控制面内完成。换一个模型或调整一个步骤，不需要改变整体架构。

不是替代它们，是使唤它们：调度层才是刚需

本段核心问题： 开源 Agent 是否需要比 Claude Code 更会写代码？还是可以换一种方式存在？

好多人的脑子里有个死结：Hermes 得比 Claude Code 更会写代码，OpenClaw 得比 Codex 更会改 PR，才有存在感。
我是真的觉得，完全不用。

Hermes 不需要打败 Claude Code，它只需要能在合适的时机把 Claude Code 叫过来干活。
OpenClaw 不需要打败 Codex，它只需要能把 Codex 塞进自己的工作流里。

什么叫塞进工作流？
举个例子。今天要做一个包含好几个环节的任务：

  1. 代码审查：Claude 最拿手，叫它。
  2. 批量修 bug：Codex 效率更高，叫 Codex。
  3. 有些数据涉及隐私不想上云：本地小模型跑。
  4. 需要从网页上抓数据：浏览器工具上。
  5. 跑完得通知一声：Telegram 或 Slack 发条消息。

这五步，在一个正经的 Agent runtime 里，是一个完整的工作流，不是五个独立的工具各干各的。

Codex 和 Claude Code 是最强工程师。
Hermes 和 OpenClaw 干的是项目经理、权限管理员、记忆系统和调度中心的活儿。

工程师越来越牛，项目经理就没用了？
任务越多、渠道越碎、模型越复杂，调度层反而越刚需。
就像公司招了十个顶级程序员，然后呢？需要项目经理来派活、追进度、统一文档、别让两个人干重复的事——不是再招第十一个程序员。

反思： 我曾经陷入“非此即彼”的思维陷阱，觉得用了 Codex 就不能用 Claude，用了闭源就不能用开源。但在实际工作中，真正高效的模式往往是混用。比如我让 Codex 做大规模重构（它的长上下文和批量编辑很强），让 Claude 做复杂逻辑推理（它的思维链和安全性更好），让本地模型处理敏感数据。而能把这三者无缝串联起来的，恰恰是一个轻量级的调度层。这个调度层的价值，不亚于任何一个大模型本身。

反模型锁定：别把未来押注在一家身上

本段核心问题： 为什么说“模型无关”还不够，要“反模型锁定”？用户如何避免被单一 AI 产品捆绑？

“模型无关”这个词挺好的，但不够狠。应该叫反模型锁定。

认真想想，未来真的会只用一个大模型吗？
大概率不会。

  • 复杂代码审查 → 用 Claude
  • 批量修 bug → 用 Codex
  • 隐私相关 → 用本地模型
  • 低成本分类整理 → 用小模型就够了
  • 关键决策 → 让两个模型互相审查
  • 不是代码的活儿 → 走浏览器、邮件、日历

需求本来就是五花八门的。
但如果把所有工作流、记忆和习惯都沉淀在一个闭源产品里，想换模型的时候成本高得离谱。

这就是锁定。不是技术上的锁定，是习惯和数据的锁定。

闭源 Agent 给出的，是一个越来越聪明的大脑。
开源 runtime 给出的，是挑大脑、换大脑、组合大脑的权力。

Hermes 和 OpenClaw 讲的故事不是“我用的模型更好”，是“想用谁用谁，想换就换，想怎么组合就怎么组合。记忆和 workflow 永远是你自己手上的”。

场景化案例：假设你是一家创业公司的技术负责人，目前团队深度依赖 Claude Code 进行日常开发。某天 Anthropic 突然大幅涨价，或者出了隐私泄露事故，你想迁移到其他模型。如果你的所有 CI/CD 触发器、代码审查规则、测试生成模板、文档输出格式都硬编码在 Claude Code 的配置里，迁移成本可能高达数百人天。但如果你在 OpenClaw 中定义了一套抽象的工作流（例如“审查 PR #123”这个任务，由调度层决定当前调用哪个模型），那么只需修改一行配置，整个团队就能无缝切换到 Codex 或本地模型。你的业务逻辑和 AI 能力提供方彻底解耦——这才是真正的自由。

冷水：最大风险是不稳，而非竞争

本段核心问题： 开源 Agent 真正的威胁来自哪里？是闭源产品的竞争，还是自身稳定性的欠缺？

说到这儿，得泼盆冷水了。
Hermes 和 OpenClaw 最大的威胁，根本不是 Codex 或 Claude Code 变强。
是它们自己能不能做到一件事：稳。

能读文件、跑 shell、发邮件、控浏览器，权限越大，搞砸的代价越高。
一个误操作删掉重要文件，一条幻觉指令发出不该发的消息。这真不是开玩笑。

长期任务最怕什么？
半夜断了、循环报错、自己把自己绕进去了。

Codex 和 Claude Code 背后有大厂的工程团队兜底，Hermes 和 OpenClaw 的稳定性，说真的，还在路上。

普通人打开 Claude Code 就是点一下。但要搭一套完整的 Agent runtime、配好权限、连好各种通道，这事儿现在的门槛不低。真的不低。

多 Agent、长上下文、后台一直跑，token 烧起来跟水龙头没关似的。
没有好的成本控制机制，月底看到账单会哭的。

Hermes 和 OpenClaw 不怕 Codex 和 Claude 变强。说真的，怕的是自己变成很酷但不稳的玩具。

具体风险点清单（基于原文总结）：

  • 操作安全风险：一个错误命令可能删除重要文件或发送错误消息。需要沙箱、审批流、回滚机制。
  • 长时间任务可靠性：后台运行可能因网络、内存、死循环而中断。需要心跳检测、自动重试、断点续传。
  • 门槛过高：配置完整 runtime（权限、通道、模型路由、记忆存储）需要一定的技术背景，普通用户难以开箱即用。
  • 成本失控：多模型循环调用、长上下文持续运行，若无预算上限和告警，账单可能爆炸。

未来是四层各干各的：模型、产品、Runtime、协议

本段核心问题： 在 AI Agent 生态中，不同层次的角色如何分工？谁会赢家通吃，谁将各司其职？

我不信一个 Agent 吃掉所有 Agent 那套叙事。
更可能的是四层各干各的（来源：原文配图《未来不是谁消灭谁，而是四层各干各的》）：

  1. 模型层：负责智商、推理和生成。例子：GPT、Claude、Gemini、本地模型。
  2. 产品层：负责好用的开发体验。例子：Codex、Claude Code、Cursor、Copilot。
  3. Runtime 层：负责入口、记忆、权限、调度、路由。例子：Hermes、OpenClaw。
  4. 工具协议层：负责连接外部系统。例子：MCP、skills、plugins、hooks。

用户需求流动路径：入口接入（Runtime） → 智能处理（模型层） → 体验交付（产品层） → 工具执行（工具协议层） → 结果返回。

各司其职，互相不替代。

趋势我觉得就几条：

  • Hybrid 架构会是主流：开源 runtime 加闭源前沿模型加本地小模型，三件套。
  • Memory 和 skills 会变成真正的核心资产：长期攒下来的 workflow 比什么模型都值钱。
  • 多 Agent 编排变成日常操作：不是一个 Agent 包揽一切。
  • 安全变成第一产品力：权限、审批、日志、沙箱、回滚、成本上限，全得标配。
  • 市场不会赢家通吃：普通用户用默认入口，power user 和公司保留自托管 runtime。

最后的判断：沉淀在谁的地盘上？

本段核心问题： 两年后，你的 AI 记忆和工作流会存在哪里？一个模型公司的产品里，还是你自己的 runtime 里？

回到开头那个问题：Codex 和 Claude 越来越强，Hermes 和 OpenClaw 凭什么不怕？

如果 Hermes 和 OpenClaw 只想当另一个 Claude Code，它们会输。
大厂的工程、模型、产品化速度，小团队正面硬刚，不是明智的选择。

但如果它们做的是一个不绑定任何模型公司的个人 Agent runtime，能调用 Claude Code、Codex、本地模型、浏览器、邮件、日历、Telegram、Slack 和各种工具，并且把记忆、权限、工作流和调度权老老实实攥在自己手里，那它们还有空间。

Codex 和 Claude Code 越强，这个空间反而越看得清楚。
大厨越来越多、越来越猛，最缺的从来不是再多一个大厨。
最缺的是一个能把所有大厨管明白的老板。

下一场 Agent 战争，比的不是谁更会回答问题。
比的是记忆、权限、工具链和工作流，到底沉淀在谁的地盘上。

别光盯着功能列表看。
两年后 AI 记忆和工作流存在哪儿——某个模型公司的产品里，还是自己的 runtime 里？
这个选择，比现在用哪个模型写代码重要得多。

不难选，但值得认真想。

实用摘要 / 操作清单（供快速落地）

如果你正在评估或搭建自己的 AI Agent 体系，以下清单基于本文内容提炼：

  1. 盘点你的“记忆资产”：列出你目前存储在各类 AI 工具中的偏好、习惯、工作流。问自己：如果明天换一个模型，这些信息能带走吗？
  2. 区分“本地执行”与“本地控制面”：不要只满足于能在本地跑命令。检查你的 Agent 能否控制入口、模型路由、权限、日志、调度。
  3. 设计“调度优先”架构：不要把所有逻辑写死在某个模型或产品里。抽象出任务类型、触发条件、模型选择策略、结果合并规则。
  4. 实施反模型锁定：至少让核心工作流支持两种以上模型（如 Claude + Codex + 本地模型），并确保记忆存储与模型无关。
  5. 建立稳定性与安全机制：为每个自动化任务设置权限审批、操作沙箱、预算上限、执行日志、自动回滚。
  6. 学习 Hybrid 模式：尝试将开源 runtime（如 Hermes/OpenClaw）与闭源前沿模型组合使用，而不是二选一。

一页速览（One-page Summary）

  • 核心矛盾：闭源产品（Codex/Claude Code）快速复制了开源 Agent 曾经的护城河（记忆、本地执行、后台任务）。
  • 新定位：开源 Agent 不应再做“另一个大厨”，而应做“餐厅老板”——负责记忆、权限、调度、模型路由。
  • 记忆主权：记忆不应绑定在单一模型产品中，而应成为用户自己可控的资产，能被任意模型读写。
  • 本地控制面：比本地执行更重要的是控制面——入口、记忆、权限、调度、日志全部归用户。
  • 调度层价值：不是替代最强模型，而是使唤它们。工作流编排比单点能力更重要。
  • 反模型锁定：未来必然使用多种模型，提前设计模型无关的 runtime 避免被单一厂商捆绑。
  • 最大风险：稳定性、安全性、门槛和成本控制，而非竞争。
  • 四层架构：模型层（智商）、产品层（体验）、Runtime 层（控制权）、工具协议层（连接）。各司其职。
  • 最终判断：两年后的胜负取决于记忆、权限、工作流沉淀在谁的地盘上——模型公司还是你自己的 runtime。

常见问答（FAQ）

Q1：我现在直接用 Claude Code 感觉已经很好了，为什么还要折腾 Hermes 或 OpenClaw？
A：如果你只是偶尔写代码，Claude Code 完全够用。但当你需要长期运行定时任务、混合使用多个模型、管理敏感数据或跨项目复用记忆时，一个独立的 runtime 层会让你避免被单一工具锁定。

Q2：开源 Agent 的稳定性真的能赶上大厂产品吗？
A：目前还有差距。大厂有专门的工程团队做压力测试和快速修复。但开源项目的优势在于透明和可定制——你可以自己修复 bug、调整行为，而闭源产品你只能等待官方更新。

Q3：“反模型锁定”听起来很好，但会不会增加架构复杂度？
A：会。任何抽象都有代价。但多数团队低估了迁移成本，高估了当前模型的长期可用性。建议从非核心工作流开始尝试模型无关设计，逐步积累经验。

Q4：本地控制面需要自己维护数据库、日志系统等，门槛太高怎么办？
A：确实。目前开源项目正在降低门槛（如提供 Docker 一键部署、SQLite 默认配置）。也可以先从部分控制面入手（比如只做模型路由，暂不实现完整记忆持久化）。

Q5：如果我只用 Codex 或 Claude Code，会不会某天突然不能用了？
A：不会突然不能用，但可能面临价格调整、功能变更、隐私政策变化或公司战略转向。风险在于长期依赖，而非短期可用性。

Q6：记忆存在本地，怎么跨设备同步？
A：可以使用 Syncthing、Nextcloud 或自建的 MinIO 来同步记忆存储文件夹。也可以选择将加密后的记忆备份到云存储（如 S3 或 R2），密钥自己保管。

Q7：多 Agent 编排会不会导致 token 消耗暴增？
A：会，所以需要成本控制机制。典型策略包括：设置单任务 token 上限、小模型做预筛选、缓存常见结果、以及为不同任务分配不同预算优先级。

Q8：我非技术背景，也能用 Hermes 或 OpenClaw 吗？
A：目前还需要一定的命令行和配置文件知识。不过随着项目成熟，社区正在开发图形化配置界面和预设模板。如果你愿意花一两个小时学习，可以跑通基础工作流；否则建议继续使用开箱即用的闭源产品。