2026-01-24

今日は11時までぐっすり眠り、全身が軽くなった気がします。こんなに自由に寝たのは久しぶりです。

1. 今日やったこと：

   1. node-unitの新バージョンをリリースしました。安心してリリースできた理由は、十分なエンドツーエンドテストを実施したからです。具体的には、DockerでTimescaleDB（PostgreSQL 17）を起動し、2つのnode-unitを起動して、データベースに21個の@yuants/portalを挿入し、最終的に1対1の状態に収束するテストを行いました。

      このテストでは、未割り当てのdeploymentが多数ある状態で2つのnode-unitを起動すると、交代でdeploymentを獲得する様子を観測できます。本当に不足している点としては、CPU・メモリを実際に占有するワークロードと、何らかの理由でnode-unitがオフラインになるシナリオが挙げられます。

   2. 新しいマルチエージェント版のlegionmindを使用して、Yuanでvendor-gate earnアカウントの出力フローの問題を解決しました。エージェントにまずlegionを使ってドキュメントを作成させ、以下のドキュメントを出力させました。

      .legion/tasks/vendor-gate
      ├── context.md
      ├── docs
      │   ├── api-doc.md
      │   ├── pr-body.md
      │   ├── report-walkthrough.md
      │   ├── rfc.md
      │   ├── spec-bench.md
      │   ├── spec-dev.md
      │   ├── spec-obs.md
      │   └── spec-test.md
      ├── plan.md
      └── tasks.md
      

      これは一応形になったワークフローだと思います。ただし、新しいマルチエージェントシステムと既存のlegionmindのドキュメント作成に競合がいくつかありました。各処理の境界を慎重に検討する必要があります。例えば、各ドキュメントの書き方の規範は個別のスキルに分け、legionmindはあくまでワークフローの説明にすべきです。各エージェントは、いくつかの小さなスキルをロードして自分の作業を補助できるようにするべきです。

      まだ不十分な点もあります。初回の作業で、アカウントフローを=account-actions-with-credential.ts=に出力してしまうミスがありました。これは、vendor-okxを参考にしてearnアカウントを接続するよう指示したためです。現時点では、okxのearnアカウントのみがアカウントとして接続されています。しかしAIは、その中にある時代遅れのプラクティスも学習してしまいました。現在の取引所接続の標準では、アカウントはすべて=provideExchangeServices=経由で公開するものであり、=provideAccountActionsWithCredential=で接続するものではありません。

      これらの知識は、新しいAIエージェントには備わっていません。このような知識をどうモデル化すべきか、またAIエージェントに対して、このようなプロジェクトコンテキストを外部脳としてどう提供すべきか。これは深く考える必要のある問題であり、明日じっくり検討したいと思います。

   3. 午後は料理をしてsyの友人たちをもてなしました。とても疲れました。明日は引き続き仕事をしようと思います。

2. 考えたこと：

   • 上記の通り、AIエージェントのためのコンパクトな外部脳をどう設計するか、慎重に検討する必要があります。最も簡単な方法としては、一連のAGENT.mdから始めることです。以前試しましたが、これらのドキュメント自体のメンテナンスオーバーヘッドもかなり高いです。ゴミと本当に記録に値する経験を区別するのは難しい問題です。今のところ、記憶は他のプロンプトと似ていますが、エージェント自身が記憶を更新するループを持っている点が異なります。最も重要なのは、AIエージェントの作業結果をどう評価するかです。

   • 上記に関連して、興味深い記事を読みました。自分の言葉で要約します。まず、エージェントの1ステップの作業に対する評価は以下のように分類できます。

     1. 静的ツール評価：コンパイラ、リンター、単体テスト、E2Eテスト
     2. モデル評価：別のLLMが定義したプロンプトに従って判断
     3. 人手評価：私が判断

     次に、エージェントの体系的な評価は2つに分けられます。

     1. 能力型：そのエージェントが何をできるかを問う。合格率が低い場合もある。例えばlegionを使ってより大きく難しいタスクを段階的に実行する場合、新しい境界を探索する感覚です。
     2. 回帰型：以前できたことを維持できているか。例えばタスクを繰り返しテストし、安定して実現できることを確認します。

     新しい能力が導入されたら、能力型から回帰型に移行すべきです。

     この記事では、pass@Kとpass^Kという2つの重要な指標も挙げられていました。

     • pass@k：k回の試行のうち少なくとも1回成功する。試行回数が多いほど、少なくとも1回成功する確率が上がる。適用例：「少なくとも1つの有効な解が見つかればよい」というシナリオ。
     • pass^k：k回の試行すべてが成功する必要がある。試行回数が多いほど、一貫性を維持するのが難しくなる。適用例：ユーザーが毎回信頼できるプロダクションエージェントを期待するシナリオ。

     参考記事：こちらの記事

   • 体力がまだ不足しています。午後少し作業し、夜料理をしただけで疲れを感じました。いつになったらCZのように眠らなくてもよくなるのでしょうか？

3. 明日の予定：

   1. 評価エージェントのモデルを検討し、マルチエージェントシステムを引き続き改良する。
   2. クラスタのセキュリティ問題。必ず取り組む。
   3. legion-github-bridgeの対応。