Hermes

背景

一個個人實驗室，我把一群 AI agent 當成一間軟體公司在跑——秘書、PM、資深工程師、QA、系統維運——去摸清 agent 協作真正的天花板。2026 年重建三次：OpenClaw 1.0 在 Telegram、2.0 在 Discord 做成事件驅動團隊，然後是 Hermes。

問題

這條路大家都會走一遍：先是 context 問題，接著是幻覺，然後陷入不斷調 prompt 想壓住它的迴圈。加了持久化記憶（Postgres）讓 agent 不再健忘，但沒讓它變聰明——我最忙的 agent 在長對話裡照樣崩掉，撈錯記憶、還用一套自洽又篤定的說法幻覺。記憶變大，不是變好。

限制

單一模型會把自己哄到相信自己的幻覺，所以沒有東西能靠一個模型說了算就出貨。產出必須在好幾個並行專案裡都維持可信。而底下那個 context window 的限制，從來不是我打算硬解的。

做法

• 繞過 context 限制，而不是硬撞 context window 是前沿大廠的題目，不是我打算硬解的。我改建在 Nous Research 的 Hermes agent 框架上——它的記憶會越用越利——然後繞著限制設計，而不是硬磨它。
• 限定範圍、跨模型驗證 與其去調單一模型的 prompt，我給每個 agent 一個窄的守備範圍、跑在不同規格的模型上，讓模型之間互相驗證——這是防幻覺的關鍵動作。
• 別對著快速演進的工具過度打造 我為了更多資料自主權，開始自己做任務看板；做到一半，Hermes 自己出了看板加設定——所以我把自己那套丟掉，不重複造。先讀懂當下的天花板，再把力氣花在剛好合身的應用上。

成果

現在 agent 包辦大部分的 coding，一套 Opus 開發／Haiku QA 的回退迴圈負責驗證，我自己的精力放在架構與方向掌舵。我對天花板保持誠實——規模一大，agent 的自主性還不可靠、幻覺難以預測。我在 2026 年 2 月就在跑的 multi-agent 樣貌，後來跟 Sakana AI 發表的 Fugu 很接近——他們的是訓練出來的 orchestrator，我的是手工搭的、而且早了幾個月。有一個產品撐過每一次重建：Ivy，一個獨立的保險諮詢 agent（Sonnet），從 OpenClaw 2.0 一路帶進 Hermes。一條主線：別去優化下一代模型會免費修好的東西——讀懂天花板在哪，打造剛好合身的應用。

技術棧

Nous Research Hermes · Claude Opus（開發）+ Haiku（QA）· Gemini · Discord · Postgres · Redis · Python async · 自架