
1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
リサーチエージェントが複雑なプロンプトを受け取ります。すべてを自分でやる代わりに、containers API に POST して 3 つのサブエージェント URL を受け取ります。各サブエージェントは独自のサブエージェントを生成できます。誰もオーケストレーターのことを知りません。HTTP でお互いを呼び出すだけです。
ツリー内の各ノードは hoody-agent サービスを持つ Hoody コンテナです。親と子は URL でしかお互いを知りません。上から見ている中央のプランナーはありません。
プロンプトを受け取ります。どのサブタスクをファンアウトするかを決めます。サブエージェントごとに新しいコンテナを生成するため containers API に POST し、その後それぞれの /api/v1/agent/tasks エンドポイントに自分が所有する作業のスライスを渡して呼び出します。
それぞれが独自のファイルシステム、ターミナル、SQLite を持つ独自のコンテナで動きます。誰も他を破損できません。誰でも助けが必要だと判断したら、親と同じ方法で独自の子を生成できます。プロトコルは対称です。
fact-checker は 5 つのクレームを見て、5 つのコンテナを並列に生成し、5 つの HTTP リクエストを発行し、5 つのレスポンスを待ちます。同じパターン、1 段深く。アイドルコンテナはコストがかからないため、深いツリーは経済的に無料です。
インストールするエージェントランタイムも、設定するメッセージバスも、同期する共有状態もありません。親エージェントは人間が使うのと同じ Containers API を使います: 作成のために POST し、その後子の URL を呼び出します。
// Parent agent (running in its own Hoody container).
// Spawn three sub-agents, hand each one a slice of work,
// await their results in parallel.
const HOODY = 'https://api.hoody.com';
async function spawnChild(name) [
// 1. Create a fresh container with the agent service running.
const res = await fetch(HOODY + '/api/v1/projects/' + PROJECT + '/containers', [
method: 'POST',
headers: [ authorization: 'Bearer ' + TOKEN ],
body: JSON.stringify([
name,
server_id: SERVER,
container_image: 'debian-12',
hoody_kit: true,
ai: true,
]),
]);
const child = (await res.json()).data;
// 2. Hit the child's agent URL like any other HTTP service.
const agentUrl = 'https://' + PROJECT + '-' + child.id + '-agent-1.' + SERVER + '.containers.hoody.com';
return [ id: child.id, agentUrl ];
]
const [scrape, summarize, factCheck] = await Promise.all([
spawnChild('scrape'),
spawnChild('summarize'),
spawnChild('fact-check'),
]);
// 3. Dispatch tasks. Each child runs autonomously,
// can spawn its own children the same way.
const results = await Promise.all([
fetch(scrape.agentUrl + '/api/v1/agent/tasks', [ method: 'POST', body: JSON.stringify([ description: scrapeBrief ]) ]),
fetch(summarize.agentUrl + '/api/v1/agent/tasks', [ method: 'POST', body: JSON.stringify([ description: summarizeBrief ]) ]),
fetch(factCheck.agentUrl + '/api/v1/agent/tasks', [ method: 'POST', body: JSON.stringify([ description: factCheckBrief ]) ]),
]);両方のエンドポイントとも文書化された Hoody API です: POST /api/v1/projects/$PID/containers はエージェントサービスがプリインストールされた新しいコンテナを生成し、POST $CHILD_URL/api/v1/agent/tasks はそれにタスクをディスパッチします。fact-checker はまさに同じコードを実行してクレームごとの検証者を生成できます — 再帰はただの HTTP です。
すべてのエージェントフレームワークはプロセス内関数呼び出しの上の薄いレイヤーです。それらは皆、エージェントがメモリを共有し、Python を共有し、単一のランタイムを共有することを前提とします。Hoody は逆を前提とします: エージェントは別々のコンピューターであり、HTTP は彼らが既に話すプロトコルです。
POST /api/v1/projects/$PID/containers
fetch(child.url + '/api/v1/agent/tasks')
子ごとに 2 回の HTTP コール。親はフレームワークをインポートせず、ツールを登録せず、状態を共有しません。すべてのサブエージェントは URL を持つピアです — 親と同じ形、他の HTTP サービスを呼ぶのと同じ形です。
各エージェントは URL を持つピア。HTTP サービスが他の HTTP サービスを呼ぶのと同じ方法でお互いを呼び出します。
オーケストレーターはありません。メッセージバスもありません。同期する共有状態もありません。並列に動かすエージェントの数を制限するのは、いくら使いたいかだけです — そしてアイドルコンテナはコストがかかりません。
1 つのエージェントでは足りないとき人々が手を伸ばすオーケストレーションフレームワークとエフェメラルランタイムサービス。それぞれが問題のスライスを解きます。HTTP ネイティブのプリミティブは、スライスとそれを包むフレームワークの両方を置き換えます。
エージェントグラフを配線するのをやめてください。1 つを生成してください。残りを生成させてください。