hermes

能力需求

我使用 hermes 的话，是为了解决我的一些痛点。

传统上，我在开发的时候，或者说是让 AI 辅助我的时候，我一般是倾向于去使用 Codex、OpenCode 的 agent。以开发为例，首先是生成一个开发文档，这个一般现在还是我自己做。主要就是这个文档内容较多的时候，有比较多的步骤的时候，我可能写实际实施过程中会希望能够先完成一个部分，然后再进行一遍审查。审查完通过没有问题了，然后提 PR，然后看它的 CI check 是否通过，通过了再合并，然后再进入下一个流程，如此循环。如果我去使用 Codex 的话，我可能每个不同的环节都需要自己去手动敲新的指令，比较复杂，不能够自动实施。主要就是连接各个环节的作用。
还有一个就是，简单地使用这个 Codex 的话，它不能够很好地作为我的个人助手。我当前的资产比较多、比较复杂。比如说，我有一个自己的个人知识库 Thought Forest（知识森林），还有一些项目，比如说 Memberflow，还有 Bodysense，这些是在开发的；还有一些 VPS，还有 mvim-config，还有 hermes-agent、agent-harness 这些仓库。他们可能会需要在多个服务器上面配，并且他们也是有点交错的。在传统的 agent 中，它可能就比较难知道我的完整的个人信息以及我的这些资产。而我又是希望能够随意开启新绘画的时候，它都能够同步地知道我的这些信息，方便去实施。

使用 hermes 的时候遇到的问题：然后接下来是我在实际使用 Hermes 的时候遇到的一些问题。一个就是执行环节的问题。Hermes 本身的 agent 的能力是比较受到质疑的，所以一般的话是偏向于继续把任务交给 Codex 之类的 agent 去实施，就像我上面说的。Hermes Agent 只是作为一个连接作用。这时候就遇到一个问题，就是模型调用还有并行实施的问题。

并行实施

[2026/8/15 12:13] hermes: ✅ 回归全绿(10 项 EC=0 + GC/DC/INV=0)。审查在进行——它发现了一个值得关注的差异:**closure-policy 变更**:merge-base 阻塞 missing/deactivated 账号且只查 `requested|revoking|closing`;共享 port 现在查 `requested|revoking|revoked|closing|closed` 且只检查 closure-operation 存在性。**被删测试覆盖旧 predicate,替代测试只验证函数对象被转发**——这可能是 Step 3 的真实行为变化,审查在深挖。等 verdict:

---

[2026/8/15 12:16] Alex:

补充一下，有这么多的任务，你能否分析一下它是否有些是可以并行执行、互不干扰的？

你可以自己去给它拆分一下，然后交给 Agent 去实施你自己统筹管理好，注意不要弄乱，不要冲突，不要重复实施之类的

[2026/8/15 12:16] hermes: ⚡ Interrupting current task. I'll respond to your message shortly.  

[2026/8/15 12:18] hermes: 审查还在跑。继续等:  

[2026/8/15 12:23] hermes: 审查接近结论:1 P1(closure policy 行为变更)+ 1 保留的 baseline smell + 1 spec P1。等最终 verdict + P1 详情:

上面是我和 Hermes 的一段聊天记录。

大致就是 Hermes 正在执行一个任务，然后我中途有了点想法，就想让他去拆分一下任务，然后并行实施。

但结果就是 Hermes 他现在由于正在实施内容，一直在关注实施的问题，他就会暂时无法接收到、暂时不去管我的内容，而是一直在实施，一直在监听之前的任务。

[!tip] 我的希望 Hermes 应该有一个主进程，然后还有多个子进程。在进行具体实施的时候，主进程应该直接把任务交给子进程去实施。在子进程实施的过程中，主进程不会去持续地监听、观察，而是能够继续去处理后续的请求。比如说，我后续又希望它能够尝试并行拆分任务，主进程就可以继续交给另一个子进程，让它去分析并实施这个任务。在接收到子进程返回的消息并确认后，主进程就能够在下一次（即第一个子进程实施结束后）开始进行并行开发；或者也可以直接让第一个子进程先停止，然后直接开始并行实施。并且，这个子进程的并行实施，主要也就是交给各个 Agent 的实例去试试

Hermes 应该有一个主进程，然后还有多个子进程。
在进行具体实施的时候，主进程应该直接把任务交给子进程去实施。在子进程实施的过程中，主进程不会去持续地监听、观察，而是能够继续去处理后续的请求。
比如说，我后续又希望它能够尝试并行拆分任务，主进程就可以继续交给另一个子进程，让它去分析并实施这个任务。在接收到子进程返回的消息并确认后，主进程就能够在下一次（即第一个子进程实施结束后）开始进行并行开发；或者也可以直接让第一个子进程先停止，然后直接开始并行实施。
并且，这个子进程的并行实施，主要也就是交给各个 Agent 的实例去试试

模型调用

现在还有一个问题，就是我现在在 Hermes 中有两种模型：一种是作为 Hermes 大脑的模型，另一种是用于 codex，opencode 开发（实施）模型。

对于这种情况，我是有一些调度策略的考量。比如说，使用比较便宜的 OpenCode go套餐里的 deepseek v4 Flash 模型作为 Hermes 的大脑模型，然后使用官方的 DeepSeek API 作为一个备选。

简单来说，可以抽象为：Hermes 大脑的模型池里有两个通道，优先级最高的是 OpenCode go套餐，第二个是 DeepSeek 官方 API。而对于开发（实施）的各种模型，情况就会比较复杂，首先有一些公益种类的，还有一些商用种类的，然后还有一些是我的套餐。我希望能有一个比较优雅的方案去帮助我们做调度。确保最大化，最高效，最性价比。

[!tip] 我的设望有一个工具能够实现以下功能：

统一管理各种渠道的信息，并图形化地展示渠道状态

让各种 profile 都通过它来统一管理各个渠道，并通过事件的形式通知所有 profile，让它们知道变动

管理各个渠道的优先级

问题

对了，上面还有一个提到的问题：现在我的客户端有多个 provider（日常的或者某种相互开发），我发现他们对于我新导入的中间人信息是不同步的。比如我在 Memo 里头临时添加了一个，但它没有同步过去。

补充：我看到 Hermes 最近好像新增了什么看板，还有更丰富层级的模型 model 配置。似乎是可以解决并行实施的问题。

还有针对这个模型调度的问题的话，我看到说它不同的 profile 其实是共享一个独立的 OS Home。也就是说，配置的终转站信息是通用的吗？只是profile不知道吗还有我的 provide，我的拆分是否出现了问题？

我实际使用之中可能会需要它日常去帮我学习调查一些事件。主要就是开发项目有 Memberflow、Bodysense、Digital Biome 等多个项目。我是按照现在的 profile 拆分，按项目拆分，按用途拆分，还是去按照身份拆分呢？