How I Use Hermes Agent to Run an Agent Team

なぜ見るべきか

これ、モデルの新機能の話じゃない。エージェントを十個動かしたときに本当に詰まる場所の話なんですよね。どのagentがどのrepoを触ってる、どのマシンが空いてる、どのモデル枠がまだ残ってる、どの通知で自分を中断していいのか。要は司令塔（control plane）が要るって話で、ここが今いちばん地味に効くポイントだと思う。

トレンド・構図

エージェントが「一回コードを書いて」から「一群のシステムを長期で見張る」方に動いてる。で、そうなった瞬間にチャット窓だけじゃ足りなくなる。状態ファイル、権限の境界、ルーティングが要る。著者はそれをMarkdownのanchorファイルに外出ししてる。賢いプロンプトより、状態を外に出すことが基盤なんだ、っていう整理。

洞察

チャット履歴は議事録に近い。検索はできるけど、システムの事実として使うには向いてない。だから人が読めてagentが書き換えられて、壊れたら追跡もできるMarkdownっていう泥臭いやり方が、逆に安定する。記憶をブラックボックスにしないで明面に置く、っていう答えがここの肝だと思う。情報を寿命で分けてるのも実用的。長期記憶・anchor・skills・session searchで更新頻度が違うものを混ぜない。

機会

軽量なcontrol planeは作れる。ローカルのMarkdown/YAML、Gitのrepo、モデル枠、サーバの健康状態を読んで、「次の一手・本当の詰まり・担当者」だけ返す。大きな基盤を先に作らず、毎日五つのdashboardを見ずに済む、これだけ固めればいい。あとはquiet cronの個人AI ops。普段は黙ってて、異常時だけ実行可能な一言を出す。通知の最大の敵は誤報じゃなくて、毎日の異常なしで無視されることなんですよね。

気になる点

anchorファイルの衝突を誰が裁くのか、ここが抜けてる。二つのagentが同じ状態を同時に書いたとき、ロックもバージョンも回滚も文章には出てこない。あと、モデル枠やサーバ状態をどう自動で集めてるのか。これが手書きスクリプト頼みなら、見た目より複製コストは高い。そっちの泥臭い部分が実は製品化の鍵だと思う。