前段时间我一直在折腾 Agent。
最开始很简单，所有事情都扔给 Codex。写代码、查资料、做项目，有什么就往里面塞。Codex 桌面端确实很强，所以一开始我也没觉得这样有什么问题。
但用久了以后，我发现“强”跟“适合长期用”其实是两回事。
为什么我不再把所有东西都塞进 Codex
Codex 最明显的问题是对话一长就会变卡。
上下文越来越大，它就不断压缩，再压缩。任务可能还能继续做，但整个体验会越来越重。文件区也是一样，项目做久了以后文件越堆越多，看着就很爆炸。
这也不能完全算 Codex 的问题，因为它本来就是一个 coding harness。它擅长围绕一个项目文件夹工作，但没有必要拿它来做一个长期生活助手。
我想要的长期助手，需要记得我的习惯，知道之前做过什么决定，也需要跟着一个领域一直积累。Codex 目前的记忆能力还做不到这个效果。
而且现实生活也不是按照项目文件夹划分的。
我有工作、生活、Homelab、VPS、娱乐，还有平时随手记下来的各种想法。这些东西不可能都放进同一个工作区，也很难为了每件事都建一个 Codex 项目。
后来我慢慢把原来的一条线拆成了三条：Hermes、OMP 和 Pi。
Hermes 更像助理
Hermes 的 harness 本来就是为长对话 Agent 设计的。它有记忆，Skills 可以继续迭代，还能通过 IM 工具联系。这个对我很重要，因为我很多时候不是坐在电脑前使用 Agent，用手机发一句话方便得多。
我现在没有做一个什么都管的 Hermes，而是按领域拆了几个。
其中一个是日常生活助手。它负责 Gmail 和 Google Calendar，我还给它做了一个日程 Skill。它每天会检查邮件，如果命中了重要规则，就把事情写进日历做待办。没有需要马上处理的事情，就给我做早报。
平时我也会直接告诉它，我刚接收到什么新信息，或者接下来一段时间准备做什么。它可以帮我看日程是不是排得合理，之后再定期复盘，重新分配时间。
我还有一个 Homelab Agent，负责家里的服务和买的那些 VPS。平时看到有意思的项目，有现成部署方案的话，我会让它去做。不过它不负责巡检，也不会拿来开荒一个完整项目。
VPN 目前也单独有一个 Agent。因为我有不少 VPS，又是自组服务器，经常需要改规则、看机器状态。以后我可能会把它合并进 Homelab，没必要一直拆得这么细。
另外还有工作助手，以及一个平时聊天和整理想法的 Agent。后者接了不少检索类 MCP，我可以先和它聊，再让它把值得留下的内容转写到 Notion。工作助手暂时还没怎么用，因为我目前还在待业。
所以我对 Hermes 的理解就是助理。它长期了解我，知道我在做什么，也可以帮我把需求想清楚。但它不是工程师。
OMP 是拿来开荒的
我其实没有 coding 基础，所以光给我一段代码没有太大意义。我需要的是有人把整个项目做出来，而且最后真的能跑。
什么任务会交给 OMP，我现在大概有三个判断。
第一，它是一个项目，不是执行一次部署就结束的活。
第二，没有一个现成范例可以直接照着做，需要从头开荒。如果已经有成熟方案，我一般先让 Hermes 处理。
第三，它需要测试和验证，不能只是代码看起来差不多能用。尤其是我现在做的一些 vibe coding 工具，工程上的事情基本都要靠 OMP 补上。
比如我做了一个找工作的 pool。这里面有爬虫、CLI 调用，还有多轮审查。Hermes 不是做不了思考，而是它的工具和 harness 不适合把这一整套工程搭起来，所以最后是 OMP 来做。
这个博客也是 OMP 搭的。我自己的 API 网关，还有另外几个 vibe coding 项目，也都是同样的逻辑。
Hermes 可以了解我的需求，跟我长期讨论。等需求真的要变成一个东西，再让 OMP 来实现。
Pi 更像我以前用的脚本
Pi 做的是另一类事情。
项目已经搭好了，流程也已经跑通，接下来只是需要重复执行。这种任务继续交给 OMP 就太重了，交给 Hermes 又不够合适，所以我会放到 Pi 里面。
还是拿找工作这件事举例。整个 pool 是 OMP 帮我做的，但日常拉 JD，我会直接交给 Pi。API 网关也是 OMP 建起来的，后续更新上游信息、做巡检，就可以让 Pi 执行。
我其实是把 Pi 当作原来的脚本在用，只不过它可以理解自然语言。
它很轻，也很好改。每个 pool 的限制都可以不一样，状态机可以自己写，模型可以自己配，最后怎么输出也可以自己决定。当然，这些东西目前还是基于 OMP 帮我部署。
这比较接近我自己对 harness 的理解：不是先找一个最强的 Agent，再把所有任务都塞给它，而是针对一个具体场景，配一个刚好够用的东西。
现在三条线连起来，大概就是这样：Hermes 先长期了解我和我的需求，OMP 负责把需求做成项目，流程跑通以后，再交给 Pi 去做那些重复的执行。
先这样跑着
这套分法肯定还会继续变。
比如博客这件事，现在还在测试。等整个写作和发布流程跑顺了，我可能会单独做一个 Hermes 博客 Agent，让它慢慢熟悉我的选题和写东西的习惯。博客本身要改功能，还是交给 OMP；以后如果有固定的发布动作，也可以再拆给 Pi。
我只是把现在的用法记下来，并不是说这样一定正确。每个人做的事情不一样，适合的 harness 肯定也不一样。
至少对我来说，目前这套分工比所有东西都往 Codex 里面塞舒服得多。过几个月再回头看，也许又会是另一套配置。