偶然のブラックボード

偶然生まれたブラックボード

今週、Thoughtworks Europeでは、10名のエンジニアを集め、バルセロナのオフィスに閉じ込めました。目標は、エージェント指向エンジニアリング（agentic engineering）に真剣に取り組んだ場合に、どれだけ遠くまで、どれだけ速く進めるかを見ることでした。私たちはこれをハイパーエージェント（hyper-agentic）と呼びました。その過程で、私たちは偶然、エージェントを調整することに関する何かを再発見しました。

10名のエンジニアには、航空会社のIROpsシステムを構築するという目標が与えられました。これは、航空会社が何か問題が発生した際に、フライトコントロールセンターで使用するシステムです。航空機に技術的な不具合が発生し、修理が必要になった場合。乗務員が病気になり、乗務員の交代が必要になった場合。どのフライトをキャンセルし、どの航空機を交換し、どの乗客を降ろしてホテルに宿泊させるかなどを決定する方法です。これは、数百機の航空機、数十万人の乗客、そして複数の拠点や空港にわたる多くの乗務員を対象とする、非常に、非常に困難な問題であり、解決も実行も困難です。IROpsシステムは、構築も理解も使用も複雑です。

私たちは4日間でそれを構築することに成功しました。しかし、この記事はその方法についての話ではありません。

仕様とシミュレートされた航空会社から始めました。これは実際のクライアントではなく、練習のための演習だったからです。何が機能し、何が機能しないかを見るために、いくつかのことを試しました。モノレポを使用しました。すべてのエンジニアが同時に作業を開始しました。私たちはただ始め、数日後には興味深いことが起こり始め、物事が現れ始めました。

アプローチの調整から生まれた挙動

1つのリポジトリで多くのエージェントが作業すると、ビルドパイプラインに問題が生じました。これに対処するため、私たちは規律を導入しました。エージェントはメインブランチから継続的にコミットおよびリベースすることです。当初、コミット後にリベースし、すべてのビルドチェックと管理を整えた上でプッシュすることを要求しました。この変更は、ローカルでビルドの失敗を捉えるために導入しました。早期かつ頻繁に統合するためです。しかし、副作用がありました。私たちはエージェントに計画を立てさせ、作業範囲を仕様のセクションに限定させ、それらのセクションに関連付けられた計画を作成させました。これらの計画はリポジトリに保存されていました。すべてのエージェントは、同じ仕様を、同じ番号と識別されたセクションを使用して作業していました。エージェントが作業するにつれて、計画は進捗を記録するように更新されました。これらの更新は、他のすべての更新とともに、新しいコミット規律によって収集されました。エージェントは他のエージェントの進捗を見ることができました。

例えば、あるエージェントは、特定の運航復旧計画が有効かどうか、ハードコンストレイントやソフトコンストレイントを破るかどうかなどを判断するコンポーネントである評価者（evaluator）に取り組んでいました。同時に、別のエージェントは、混乱を解決できる計画を探す検索アルゴリズムに取り組んでいました。検索コンポーネントは評価者に依存します。各コンポーネントは一緒に書くことができますが、共有インターフェースがあり、検索は評価者に依存します。

計画はこれらの統合ポイントを記録しました。ある計画には、「この時点で、呼び出し元を更新して実際の検証者（verifier）を呼び出す必要がある」と書かれていました。検索側では、「この時点で、実際の検証者が到着したら、実際の検証者の呼び出しを挿入する必要がある」と書かれていました。両方のエージェントが各計画と進捗を見ることができました。私たちは、エージェントが計画を使用して調整していることに気づきました。あるエージェントが計画の1行を「進行中」とマークすると、別のアージェントがそれを見て、その行に取り組むのをやめました。最初のエージェントが終了すると、別のアージェントは作業が完了したこと、したがって処理を進めることが許可されたことだけでなく、その行がどのように実装されたかについての注記を直接受け取ることができました。

私たちはこれを活用し始めました。セッションを開始し、特定のジャーニーに取り組むように指示しました。一例として、検証者（verifier）とともにコストモデルを導入しました。誰かがコストモデルに取り組んでおり、継続的にコミットをプッシュしていることを知っていたので、検証者（verifier）に取り組んでいるエージェントに、計画とソースを見て、リポジトリを監視し、コストモデルの作業が完了したらそれを統合するように指示しました。そして、それは統合されました。

これは完全に場当たり的でした。一連の決定の偶然の産物でした。私たちはそれが起こるのを見て、それから使い始めました。

エージェントのための偶然のブラックボードとしてのリポジトリ

私たちのエージェントが発見したパターンには名前があります。それはブラックボードシステムです。これは私が大学時代に探求したものでした。私の研究論文は、階層的なセンサーによるエージェントの行動の指示に関するものでした。当時の最新の機械学習技術、例えば強化学習を、大規模で動的なデータセットに適用することを検討していました。文献を振り返ると、コアとなる調整構造としてブラックボードパターンを採用しました。これは、1980年のHearsay-IIシステムの開発で以前に発見されていました。その後、1986年にGelernterらによってより形式的なタプルスペースの概念に発展しました。

ブラックボードまたはタプルスペースは、自律的なエージェントが独立して読み書きできる共有メモリです。それらは、ある最小限の構造を持つタプルと、望むだけの追加フィールドを読み書きします。スキーマはありません。これは、自律的な問題解決者が単一の目標に向かって調整するための非常に効果的な技術です。それぞれが問題の分解された部分を解決し、その解決策を共有スペースにドロップし、ラベルを付けることができます。すると、他の自律的な検索者がそれを見つけ、拾い上げ、自身の作業の一部として使用します。

私たちは偶然、エージェントにリポジトリをブラックボードとして使用させるように促しました。しかし、それは偶然でした。意図的な行為ではありませんでした。完全に構造化されていませんでした。ブラックボードが機能する主要な部分がいくつか欠けていました。そして偶然だったため、エージェントにそれを実行させるように確実に促すことができるかどうかは確信が持てません。何が起こったのかについては、かなりの見当がついています。なぜなら、分析を行い、この連鎖反応を引き起こした単一のプロンプトを特定したからです。しかし、それは創発的な挙動でした。指示された挙動ではありませんでした。

これを意図的に作成することに加えて、このコミュニケーションチャネルはソース管理とは独立して存在することが望ましいと私は信じています。私たちは頻繁なプッシュサイクルを指示することによってそれを作成しましたが、私たちはそれから後退しました。頻繁なコミットはCIパイプラインを過負荷にしていました。よりまとまった変更が完了したときにのみプッシュするように切り替えました。これにより、エージェントは進捗状況の継続的な更新フローを得られなくなりました。

優れた偶然の解決策には、優れた意図的なプロジェクトが必要です。私はTalwrnと名付けたプロジェクトに着手しました。これはウェールズ語で、議論や対立が解決される場所、つまり「threshing pit」を意味します。これはエージェント指向エンジニアリングのためのブラックボードとなることを目指しています。私の目標は、プロジェクトに直接組み込まれ、エージェントが作業を調整するためのコミュニケーションチャネルをすぐに提供する、非常に使いやすいツールです。最初のステップは、Talwrnが自身の開発をサポートできるレベルに到達することです。純粋なエージェント指向エンジニアリングがどのように進むかを示す、単一の進化する例としてそれを使用するつもりなので、定期的に投稿する予定です。