常時稼働のエージェントは、コンテキストウィンドウでは追いきれないほど多くのソースから届くイベントを、絶えず監視して対応し続けなければなりません。Comma の分散ハーネスである Salix は、エージェントが小さな eBPF プログラムをクラスターにロードし、24 時間 365 日動かし続けられるようにします。このプログラムがイベントを監視し、Jev を呼び出して高速かつ賢い判断を下し、注目すべきことが起きたときにメインのエージェントループを起こします。
インナーループだけでは足りない
おなじみのエージェントループはシンプルです。コンテキストをモデルに送り、返ってきたツール呼び出しを実行し、その結果を追記して、これを繰り返します。このループは仕事をこなすのは得意ですが、仕事を待つのは苦手です。
エージェントに「契約書が署名されて戻ってきたら教えて」や「このリポジトリを見張って、課金に関わる変更があれば知らせて」と頼むと、インナーループには悪い選択肢が 2 つしかありません。1 つはポーリングです。数分ごとに起きて受信トレイを読み直し、何も起きていないと判断するためだけにモデル呼び出しを丸ごと 1 回使います。もう 1 つはハートビートや cron スケジュールに任せる方法ですが、これは間隔が長くなりレイテンシが悪化しただけの、同じポーリングです。どちらにしても、システムで最も高価な部分、つまり大きなコンテキストを読む大規模モデルがティックのたびに動きます。しかも、ほとんどのティックでは何も起きていません。
常時稼働のエージェントが本当に必要としているのはアウターループです。イベントストリームの上に陣取って安価なフィルタリングを行い、考える価値のあることが起きたときだけモデルにエスカレーションする仕組みです。そして、エージェントごとに監視する対象も方法も異なるため、このアウターループを固定のプロダクト機能にすることはできません。エージェント自身が書く必要があります。
Salix では、このアウターループを Loop と呼びます。
Loop は小さな C プログラム
Loop はエージェントが書いた 1 つの C ファイルです。eBPF にコンパイルされ、クラスター上で、それを所有するエージェントのすぐ隣で実行されます。どの Loop も同じ形をしています。
タイマーかイベントを待ち、何かを確認し、ごくまれにエージェントを起こします。エージェントは loop.sdk ツールから正確な SDK ヘッダーとプログラミングガイドを受け取ってプログラムを書き、loop.build でコンパイルし、loop.create で起動します。テンプレートも DSL もありません。監視の内容を C で記述できれば、エージェントはそれを実行できます。
なぜ、たとえばコンテナ内の Python スクリプトではなく、C と eBPF なのでしょうか。理由は、Salix の設計の前提にした数字にあります。Salix は数百万のエージェントを、CPU コアあたり 100 を超える密度で動かします。エージェントに常時起動のサンドボックスを持たせることはできないので、その監視処理にも持たせられません。Loop は、人間が誰もレビューしていないコードを、共有のマルチテナントノード上で、すべてのエージェントについて、いつまでも動かし続けられるほど安価でなければなりません。
eBPF はこの要件に驚くほどよく合います。
小さい。 待機中の Loop の常駐メモリは数十 KB です。プロセスもインタープリターもヒープもありません。
信頼できないコードを安全に実行できる。 ターゲットにはシステムコールも関数ポインターも無制限のスタックもありません。プログラムにできるのは、自分のメモリ上で計算することと、私たちが渡したホスト関数を呼ぶことだけです。
待つコストが低い。
sf_event_nextやsf_sleep_msでブロックしている Loop は、メモリ以外のコストがかかりません。
代償は制限された方言で、SDK ガイドもそれを率直に書いています。整数のみの C（浮動小数点も符号付き除算もなし）、4 KiB のスタックフレーム、最大 8 フレームの深さ、再帰なし、sprintf なし、同時に保持できるハンドルは最大 128 個です。実際には、モデルはこれで問題ありませんでした。モデルはすでに C を知っていますし、これらの制約はコンパイラーのエラーメッセージでうまく説明できる種類のものです。
Spinfoam：すべての Loop を支えるランタイム
Loop は、私たちの eBPF ループランタイムである spinfoam 上で動きます。Spinfoam は async-ebpf の上に構築されています。async-ebpf はユーザー空間の eBPF ランタイムで、非同期処理と相性がよく、完全なプリエンプションに対応し、中核部分のメモリ安全性は形式検証されています。
ユーザー空間の eBPF を非同期に
Spinfoam はカーネルの eBPF ではありません。Salix ノードごとに 1 つ動く普通の Rust プロセスで、カーネルの eBPF サポートも特権も必要とせず、Linux でも macOS でも同じように動きます。Salix は stdin と stdout 上の JSON-RPC で spinfoam と通信します。責務の分担は厳密です。spinfoam は、ローカルでの実行、プログラム間の分離、キャンセル、上限付きのメッセージ配信を担います。Salix は、クラッシュ後も残る必要があるものすべて、つまり配置、永続状態、再起動ポリシー、認証情報、ネットワークを担います。
async-ebpf の「async」こそが、Loop を普通の逐次的な C のように見せている要素です。ロードされた各プログラムは長寿命の呼び出しを 1 つ持ち、それぞれ専用のコルーチン上で動きます。プログラムが sf_sleep_ms、sf_event_next、sf_host_call を呼ぶと、ヘルパーがコルーチンを中断し、待機を Tokio に引き渡します。C のスタックとプログラムのグローバル変数は、そのままの場所に残ります。タイマーが発火するか、イベントが届くか、Salix がホスト呼び出しに応答すると、コルーチンは次の行から再開します。エージェントは for (;;) { wait; check; wake; } と書くだけで、コールバックを目にすることはありません。
一方、「完全なプリエンプション」は、これを共有しても安全にしている要素です。ゲストのコードはすべて 1 本の Tokio スレッド上で動き、監視スレッドが、yield せずに長く走りすぎたプログラムに割り込みます。for (;;) {} で空回りする Loop も他と同じようにタイムスライスを失い、止めるのにその Loop の協力は要りません。バグのある Loop が 1 つあっても、隣の Loop を止めることはできません。
ほとんどの Loop は時間のほぼすべてを待機に費やすので、この設計では高密度に詰め込めます。私たちの検証実行では、すべて組み込みコンパイラーでコンパイルした小さな監視用 Loop 10,000 個が、1 本の実行スレッド 上で、1 つあたり約 64 KB の常駐メモリ で動きました。10,000 個すべてのロードと起動にかかった時間は 3.07 秒でした。すべての Loop にイベントを 1 つずつ配信し、それぞれが応答として行ったホスト呼び出しに答えるまでが 1.56 秒でした。制御リクエストは p99 で 0.25 ミリ秒未満に収まりました。プロセス全体で使った OS スレッドは、ロード中が 4 本、アイドル時が 2 本でした。
検証できるメモリ安全性
エージェントが書いた数千のプログラムを 1 つのプロセスで動かすことが妥当なのは、どのプログラムも自分のものではないメモリに触れられない場合に限ります。async-ebpf では、この保証はメモリレイアウトから始まり、機械検証された証明で締めくくられます。
まずはレイアウトです。各プログラムのデータはポインターケージの中に置かれます。これは、ランダム化されたガードページで囲まれた予約領域です。ゲストのスタックは 1 フレームずつの島として配置され、島と島の間には、どの eBPF メモリ命令も届かないほど広いアクセス不能な隙間があります。そのため、自分のフレームからはみ出した関数は、呼び出し元のフレームを読む代わりにフォールトします。JIT のコードページが書き込み可能と実行可能を同時に満たすことはありません。
次に証明です。async-ebpf は、各 eBPF 関数を初めて実行するときにネイティブコードへコンパイルします。その x86_64 バックエンドは、判断を下す部分を証明できるように構成されています。
バリデーターは健全です。 バリデーターが受理したプログラムのどの実行においても、プログラムが未定義の命令に到達することはなく、命令の途中やプログラムの外へジャンプすることもありません。また、フレームポインターは常に現在の呼び出し深さに対応するフレームベースを指します。
関数は閉じています。 制御が関数を離れるのは、ローカル呼び出しかリターンによる場合だけです。これにより、JIT は関数を 1 つずつコンパイルできます。
生成コードはメモリ安全です。 チェッカーが関数を受理した場合、そのネイティブコードのどの実行も、許可されたアドレスの集合（自身のフレーム、自身のゲスト領域、自身のスタックとリテラルプール）にしか触れず、呼び出し元の状態を保ったまま戻ります。遅延コンパイルされる呼び出し先も、同じ定理によって合成できます。
バイト列はモデルのとおりです。 アセンブラーが出力するすべての命令は、デコードするとモデルが推論の対象とした命令に戻ります。
証明は 2 か所でハードウェアとつながっています。1 つは、実行可能なシミュレーターが Lean のマシンモデルの実行であることの証明で、さらに差分テストでは 2 万個のランダムな命令列をシミュレーターと実際のプロセッサーの両方で実行します。もう 1 つとして、ランタイムは各呼び出しの前に、具体的なメモリレイアウトが定理の仮定を満たしているかを確認し、満たしていなければ実行を拒否します。
証明されていないことも明示しておきます。信頼の基盤には、x86 命令のセマンティクス（ハードウェアに対してテスト済みですが、証明はしていません）、エントリトランポリン、フォールトハンドラー、メモリマッピング、すべてのヘルパー呼び出しのホスト側、そして Charon と Aeneas 自体が含まれます。定理が扱うのはメモリ安全性であり、機能的な正しさや情報漏えいではありません。また、対象は x86_64 バックエンドだけです。arm64 バックエンドはテストしていますが、証明はしていません。
証明によって、ゲストは自身のメモリの中にとどまります。Loop が外の世界で行うことはすべてホスト呼び出しを経由し、その境界は Salix が担います。それが後述する capability の許可リストと権限のルールです。
コンパイラーもサンドボックスの中で動く
エージェントは自分の Loop を自分でコンパイルするので、コンパイラーもまた信頼できない入力を扱う領域です。Spinfoam は eBPF 向けにコンパイルした TinyCC を組み込み、他のゲストと同じように async-ebpf 上で動かします。ビルドのたびに新しいコンパイラーインスタンスが用意され、8 MiB のアリーナ、提出されたソースと SDK ヘッダーだけを保持するメモリ上のファイルシステム、15 秒の期限が与えられます。ネットワーク、プロセス、ホストファイルへのアクセスはありません。出力も同様に信頼できないものとして扱います。すべてのオブジェクトは、コンパイラーから来たものかどうかにかかわらず、ロード時に同じ検証を通ります。
だからこそ、loop.build にはノード上のツールチェーンもコンテナも特権も必要ありません。エージェントの C ソースがネイティブコンパイラーに触れることはありません。
エージェントを起こすことが高くつく
Loop は単独で動きますが、エージェントに何も伝えられなければ役に立ちません。そのための唯一の手段が agent.notify です。
通知は、Loop の対象 Session に通常のメッセージとして配信されます。そこで初めてメインのエージェントループが動き、そこで初めてモデルのトークンを消費します。何も起きない 1 時間なら、トークンのコストはゼロです。
dedup_key は見た目以上に重要です。Loop は再起動されますし、イベントは再配信されますし、ゲストは成功したか確信の持てない呼び出しをリトライすることもあります。Salix はウェイクを loop:<id>:<dedup_key> として配信するので、同じメール、issue、アラートがエージェントを起こすのは 1 回だけです。
ウェイクは高くつくので、予算も設けています。Loop がエージェントを起こせるのは 10 分あたり 6 回までです。この上限に 1 時間張り付いた Loop は理由 budget で一時停止され、そのことがエージェントに通知されます。バグのある Loop や張り切りすぎた Loop は、請求額として跳ね返るのではなく、目に見える一時停止状態の Loop になります。
大規模モデルなしで高速に判断する
監視で難しいのは、たいてい「何かが変わったか」ではなく「その変化は重要か」です。このメールはオーナーが今日中に対応すべきものか。この PR は、私たちが気にしているシステムの部分に触れているか。整数の C で書かれた Loop にはそれを単独で判断できませんし、イベントのたびにフロンティアモデルを呼べば振り出しに戻ってしまいます。
そこで、Loop にはもう 1 つの capability として decide を用意しました。これは小さな型付きの質問を高速な判断モデル（Jev）に送り、構造化された答えを受け取るものです。次に示すのは、メール監視のプロトタイプで使った質問です。
decide は、候補を 1 つ選ぶ choice、複数の該当がありうる場合の個別の yes/no 質問、順位付きの関連度を返す score をサポートしています。返すのは常に判断だけです。ソースを読んだり、ツールを実行したり、権限を与えたりはしません。データを渡し、質問を投げ、自身のコードでしきい値を適用するのは Loop の役目です。
これをうまく機能させたのは、2 つの設計判断でした。
不確実さも正当な答えです。 明示的な
noneやdeferの選択は「判断できない」を意味し、トランスポートエラーではなく成功した結果として扱います。Loop は、静かに済ませる判断をでっち上げる代わりに、イベントを保持します。すべてのイベントに実行できるほど安価です。 私たちの価格カタログでは、
typesafe/jev-1.13.0は入力 100 万トークンあたり $0.042 で、出力トークンは無料です。キーワードフィルターを通過したものだけでなく、すべてのメールを選別できるほどの安さです。
結果として、2 層構成のシステムになります。小さなモデルがすべてのイベントを選別し、大きなモデルはそこを通過したものだけを見ます。
イベントを永続的に受け取る
ポーリングならタイマーで十分ですが、多くのソースは自分からプッシュできます。Loop にはメールボックスがあり、外部システムは次の 3 つの方法でそこにイベントを送り込みます。
Salix API：グループの API キーを使った
POST /v1/agent-groups/:group_id/loops/:loop_id/eventsシークレットの Webhook URL：エージェントが
loop.webhookで有効化、ローテーション、失効を行います。ユーザーが接続したアプリからの Composio トリガー：プロバイダーのイベント ID とトリガー slug 付きで届きます。
これらのいずれかから 202 が返った場合、それは PostgreSQL がそのイベントを Loop に保持したことを意味します。Loop がそれを処理したという意味ではありません。ゲストは安全なポイントに達したとき、つまり静かに済ませるという判断か、agent.notify の成功のような永続的な引き渡しに至ったときに、loop.ack を呼びます。それまでイベントは保留状態のまま残り、Reconciler は Loop の移動や再起動の後に、またそれとは別に 1 分に 1 回、保留中のイベントを再生します。15 分以内に確認応答されなかったイベントは Loop を目に見える形で失敗させ、保留中のイベントはエージェントがリトライまたは破棄できるよう保持されます。
これを構築する中で得た教訓が 1 つあります。spinfoam のメールボックスがイベント ID を重複排除するのは、業務処理の完了時ではなく受け入れ時です。初期のプロトタイプでは、モデル呼び出しが失敗しても、プロバイダーがイベントを再配信することでリトライされると想定していました。しかし実際にはそうならず、再配信は重複として正しく破棄されました。つまり、リトライはイベントを保持して上限付きの回数だけ再試行するゲストの責務であり、クラッシュ後の復旧は永続的な受信箱の責務です。現在はこのルールを SDK ガイドに明記しています。
確認応答、Session への永続的な受け入れ、目に見えるメッセージ、外部への作用は、それぞれ別の 4 つの事実です。私たちはそれぞれに専用の担い手を割り当て、下流には安定した重複排除キーを求め、外部への作用が厳密に 1 回だけ起きることは約束していません。
動き続けるクラスター上で永遠に動かす
「24/7」と言うのは簡単ですが、ノードが入れ替わり続けるクラスターでそれを実現するのは困難です。Loop はそのエージェントのリースを保持するノード上で動き、リースに追従します。
配置。 エージェントのサーバープロセスがリースを取得すると、アクティブな Loop を引き取ります。エージェントがパッシベートまたはフェンスされると、それらを手放します。アクティブな Loop はエージェントを常駐させ続けるので、Loop を持つアイドル状態のエージェントは休止せずにリースを更新します。
インカネーション。 Loop をロードするたびに、そのインカネーション（Loop の行に記録されるフェンス値）が増えます。現在のインカネーションではないオブジェクトからのホスト呼び出しは拒否され、そのようなオブジェクトからの
ackも同様に拒否されます。離脱しつつあるノード上に残った古い Loop のコピーは、何も実行できません。チェックポイント。
loop.state.putは最大 16 KiB を保存し、次のロード時にconfig.stateとして返します。エージェントはすべてではなく、カーソルや最後に見た ID をチェックポイントします。障害。 フォールトが起きると、Loop はチェックポイントから再ロードされます。ただし 1 時間に最大 3 回までです。それを超えると
failedになり、エージェントに 1 度だけ通知されます。取り残し。 定期的なスイープが、オブジェクトが紐づいていないアクティブな Loop や、離脱したノード上のオブジェクトに紐づいたアクティブな Loop を見つけ、その所有者を再起動します。
Loop には、ランタイムの外にも信頼できる情報源があります。loop.build はコンパイル済みの ELF をエージェントのファイルシステムに書き込み、loop.create はそのパスと SHA-256 を記録します。ロードのたびにファイルを読み直してハッシュを確認するので、Loop は作成時のプログラムそのものを実行するか、まったく実行しないかのどちらかです。
Loop に許されていること
Loop はモデルが書いたコードであり、監督なしで 24 時間動き続けます。その権限はエージェントと同等ではなく、エージェントより小さくなければなりません。
Loop が呼べるのは、閉じた許可リストに載っているホスト capability だけです。具体的には、agent.notify、loop.state.*・loop.ack・loop.log の各呼び出し、読み取り専用に分類された Salix ツール、環境ツールとデバイスツール、SSH ツール、会話の読み取り、web.http_request、接続済みアプリ向けの composio.execute、そして decide です。Spinfoam はそれ以外の名前をすべて SF_DENIED で拒否します。設定を誤る余地のある権限付与のステップは、そもそも存在しません。
各呼び出しは、通常のエージェントのターンと同じツールディスパッチと情報フローのチェックを通ります。Loop は委任されたプリンシパル schedule|loop:<id>|<creator> を通じて作成者として動作し、作成者の開示ルールと Loop の封印されたオリジンが適用されます。イベントのペイロードはデータです。権限を持たず、Loop にできることを広げることもできません。前述の判断プロンプトがメールを信頼できない入力として明示的に扱っているのは、このためです。
最後に、クォータによってシステムの規模を有界に保っています。アクティブな Loop はエージェントあたり 20 個、グループあたり 100 個まで、保留イベントは Loop あたり 16 KiB のものを 32 個まで、そして Webhook の受信にはレート制限があります。
スクリプト：同じランタイムを 1 ターンだけ使う
エージェントが書いた C のための安全で安価なランタイムができると、2 つ目の用途が見えてきました。script.run は、整数 C のプログラムを 1 回のツール呼び出しの中で一度だけコンパイルして実行し、salix.call を通じて呼び出し元のターン自身のツールにアクセスさせます。スクリプトには行も、インカネーションも、チェックポイントも、agent.notify もありません。多数のツール呼び出しを、モデルとの何度もの往復ではなく、1 つの決定的なプログラムにまとめるための手段です。私たちが提供しているスキルのうち 2 つは、この方法で実行される C プログラムです。
自身のイベントシステムをプログラムするエージェント
まとめると、監視を頼まれた Comma のエージェントでは、従来のエージェントにはできない 3 つのことが起きます。エージェントが監視をプログラムとして書き、クラスターがそのプログラムを必要な限りわずか数 KB のコストで動かし続け、小さなモデルがイベントごとに、そもそも大きなモデルを起こす必要があるかを判断します。
インナーループは、今もエージェントが考える場所です。アウターループは、エージェントが注意を払う場所です。Salix は、エージェントがその両方を自ら構築できるようにします。
