常駐 AI 代理需要持續監視並回應事件，而事件來源之多，遠超它在上下文視窗裡所能追蹤的範圍。Comma 的分散式 AI 代理框架 Salix 讓 AI 代理可以把小巧的 eBPF 程式載入到叢集中，並讓它們 24/7 持久執行：監視事件，呼叫 Jev 做快速的智慧判斷，並在發生值得關注的事情時喚醒 AI 代理主迴圈。
只有內迴圈是不夠的
大家熟悉的 AI 代理迴圈很簡單：把上下文發給模型，執行它傳回的工具呼叫，追加結果，然後重複。這個迴圈擅長做事，卻不擅長等待。
讓 AI 代理「合約簽回來時告訴我」，或者「盯著這個儲存庫，凡是涉及計費的改動都標出來」，內迴圈只有兩個糟糕的選項。一是輪詢：每隔幾分鐘醒來一次，重新讀一遍收件箱，再花一次完整的模型呼叫得出「什麼都沒發生」的結論。二是把任務交給心跳或 cron 排程，這其實還是輪詢，只是間隔更長、延遲更差。無論哪種方式，系統裡最昂貴的部分，即大型模型讀取大段上下文，在每個週期都要執行一次，而幾乎每個週期都風平浪靜。
常駐 AI 代理真正需要的是一個外迴圈：它守在事件流上，完成低成本的過濾，只在有值得思考的事情時才回報給模型。而且每個 AI 代理監視的物件和方式各不相同，所以這個外迴圈不能是一個固定的產品功能，必須由 AI 代理自己來寫。
在 Salix 中，這個外迴圈叫作 Loop。
Loop 是一個小小的 C 程式
Loop 是由 AI 代理編寫的單個 C 檔案，編譯為 eBPF 後，在叢集上緊挨著它所屬的 AI 代理執行。每個 Loop 的結構都一樣：
它等待一個計時器或事件，檢查某些情況，偶爾喚醒 AI 代理。AI 代理透過 loop.sdk 工具拿到完整的 SDK 標頭檔和程式設計指南，編寫程式，用 loop.build 編譯，再用 loop.create 啟動。沒有範本，也沒有 DSL。只要 AI 代理能用 C 描述這項監視任務，就能把它跑起來。
為什麼選 C 和 eBPF，而不是比如說容器裡的 Python 指令碼？原因在於我們設計 Salix 時所依據的那些數字。Salix 執行著數百萬個 AI 代理，每個 CPU 核心上超過 100 個。AI 代理不可能擁有一個始終開著的沙箱，它的監視任務也一樣。Loop 必須足夠便宜，便宜到可以為每個 AI 代理永遠執行下去，並且執行在共享的多租戶節點上，執行沒有經過任何人工審查的程式碼。
eBPF 與這些要求出奇地契合：
它很小。 一個處於等待狀態的 Loop 只佔幾十 KB 常駐記憶體。沒有處理程序，沒有直譯器，也沒有堆。
它可以安全地執行不受信任的程式碼。 目標平台沒有系統呼叫，沒有函式指標，也沒有無界堆疊。程式能做的，只有在自己的記憶體上做計算，以及呼叫我們交給它的主機函式。
它等待時幾乎不花錢。 阻塞在
sf_event_next或sf_sleep_ms中的 Loop，除了記憶體之外沒有任何開銷。
代價是一種受限的 C 方言，SDK 指南對此毫不諱言：只能用整數 C（沒有浮點數，沒有有號除法），堆疊框架 4 KiB，呼叫深度最多 8 層，不能遞迴，沒有 sprintf，同時存活的控制代碼最多 128 個。事實證明模型對此適應良好。它們本來就會 C，而這些約束正是編譯器報錯能講清楚的那一類。
Spinfoam：每個 Loop 之下的執行環境
Loop 執行在我們的 eBPF 迴圈執行環境 spinfoam 上。Spinfoam 建構於 async-ebpf 之上，這是一個使用者空間 eBPF 執行環境：對非同步友好、完全搶佔式，其核心的記憶體安全性經過了形式化驗證。
使用者空間 eBPF，做成非同步
Spinfoam 不是核心 eBPF。它是一個普通的 Rust 處理程序，每個 Salix 節點一個，不需要核心的 eBPF 支援，也不需要任何特權，在 Linux 和 macOS 上表現一致。Salix 透過 stdin 和 stdout 上的 JSON-RPC 與它通訊。雙方的職責劃分非常嚴格：spinfoam 負責本地執行、程式之間的隔離、取消，以及有界的訊息投遞；Salix 負責一切需要在崩潰後保留下來的東西：排程放置、持久狀態、重啟策略、憑證和網路。
async-ebpf 中的「async」，正是讓 Loop 看起來像普通順序 C 程式碼的關鍵。每個載入的程式都有一次長期存在的呼叫，執行在自己的協程上。當程式呼叫 sf_sleep_ms、sf_event_next 或 sf_host_call 時，輔助函式會掛起協程，把等待交給 Tokio。C 堆疊和程式的全域變數原封不動地留在原處。等計時器觸發、事件到達，或者 Salix 應答了主機呼叫，協程就從下一行繼續執行。AI 代理寫的是 for (;;) { wait; check; wake; }，從來不用碰回呼。
「完全搶佔式」則讓共享執行變得安全。所有訪客程式碼都執行在同一個 Tokio 執行緒上，一個看門狗執行緒會中斷任何長時間執行而不讓出的程式。一個在 for (;;) {} 裡空轉的 Loop 會像其他程式一樣失去時間片，停止它也不需要它配合。一個有 bug 的 Loop 拖不垮它的鄰居。
大多數 Loop 幾乎把所有時間都花在等待上，所以這種設計可以排布得非常密集。在我們的驗收測試中，10,000 個小型監控 Loop（全部由內嵌編譯器編譯）在一個執行執行緒上執行，每個約佔 64 KB 常駐記憶體。載入並啟動全部 10,000 個 Loop 用了 3.07 秒。向每個 Loop 投遞一個事件，並應答每個 Loop 隨之發起的主機呼叫，用了 1.56 秒。控制請求的 p99 延遲保持在四分之一毫秒以內。整個處理程序在載入期間使用四個作業系統執行緒，空閒時使用兩個。
可以檢驗的記憶體安全
在一個處理程序裡執行成千上萬個由 AI 代理編寫的程式，前提是它們都碰不到不屬於自己的記憶體。在 async-ebpf 中，這一保證始於記憶體佈局，終於機器檢驗的證明。
先說佈局。每個程式的資料都位於一個指標籠中：這是一塊預留區域，周圍布有隨機化的保護分頁。訪客堆疊被配置成一個個單一框架的「孤島」，彼此之間隔著不可存取的間隙，間隙寬度超過任何 eBPF 記憶體指令能夠到達的範圍，因此越出自身堆疊框架的函式會觸發錯誤，而不會讀到呼叫者的堆疊框架。JIT 程式碼分頁永遠不會同時可寫又可執行。
再說證明。async-ebpf 會在每個 eBPF 函式首次執行時將其編譯為原生程式碼。它的 x86_64 後端經過特意的結構設計，使其中做決策的部分可以被證明：
驗證器是可靠的。 對於它接受的程式，在每一條執行路徑上，程式都不會到達未定義的指令，不會跳進某條指令的中間或跳出程式，並且框架指標始終是目前呼叫深度對應的框架基底位址。
函式是封閉的。 除了區域呼叫或傳回，控制流永遠不會離開函式，正因如此，JIT 才能一次只編譯一個函式。
產生的程式碼是記憶體安全的。 如果檢查器接受了一個函式，那麼其原生程式碼的每一次執行都只會存取一組允許的位址（它的堆疊框架、它自己的訪客記憶體區域、它自己的堆疊和常值池），並在返回時保持呼叫者的狀態不變。延遲編譯的被呼叫函式也能用同一條定理組合起來。
位元組與模型一致。 彙編器發出的每條指令，都能解碼回模型所推理的那條指令。
這些證明在兩處與硬體相連。一個可執行的模擬器被證明是 Lean 機器模型的一次執行，並有一項差異測試讓兩萬條隨機指令序列同時在模擬器和真實處理器上執行。每次呼叫之前，執行環境都會對照定理的前提條件檢查具體的記憶體佈局，一旦不滿足就拒絕執行。
哪些內容沒有被證明，我們也說得很清楚。可信運算基礎包括 x86 指令語義（經過硬體測試，但未經證明）、入口跳板、故障處理程式、記憶體對映、每個輔助函式呼叫的主機端，以及 Charon 和 Aeneas 本身。這條定理關乎記憶體安全，不涉及功能正確性或資訊外洩。而且它只覆蓋 x86_64 後端；arm64 後端經過測試，但未經證明。
這些證明把訪客限制在它自己的記憶體裡。Loop 對外部世界做的一切都要經過主機呼叫，而這條邊界歸 Salix 管：也就是下文介紹的能力白名單和權限規則。
編譯器也執行在沙箱裡
Loop 由 AI 代理自己編譯，因此編譯器同樣要處理不受信任的輸入。Spinfoam 內嵌了 TinyCC，並把它編譯成 eBPF，像其他訪客一樣執行在 async-ebpf 上。每次建構都會得到一個全新的編譯器執行個體，配有 8 MiB 的記憶體池、一個只包含提交的原始檔和 SDK 標頭檔的純記憶體檔案系統、15 秒的時限，並且無法存取網路、處理程序或主機檔案。編譯輸出同樣被視為不受信任。每個目的檔在載入時都要經過同樣的驗證，無論它是否來自這個編譯器。
這就是為什麼 loop.build 不需要工具鏈、不需要容器，也不需要節點上的任何特權。AI 代理的 C 原始碼從不接觸原生編譯器。
喚醒 AI 代理才是昂貴的部分
Loop 可以獨立執行，但如果它沒法告訴 AI 代理任何事，那就毫無用處。它唯一的途徑是 agent.notify：
通知會作為一條普通訊息投遞到 Loop 的目標 Session。只有在這時，AI 代理主迴圈才會執行，也只有在這時才會消耗模型 token。安靜的一小時完全不花 token。
dedup_key 比看上去更重要。Loop 會被重啟，事件會被重新投遞，訪客程式也可能重試一次不確定是否成功的呼叫。Salix 以 loop:<id>:<dedup_key> 的形式投遞喚醒，因此同一封郵件、同一個 issue 或同一條警報只會喚醒 AI 代理一次。
正因為喚醒是昂貴的部分，它也有預算。一個 Loop 每十分鐘最多喚醒它的 AI 代理六次。如果一個 Loop 持續一小時都停在這個上限，它就會以 budget 為原因被暫停，並告知 AI 代理。一個有 bug 或過於積極的 Loop，最終會變成一個可見的、已暫停的 Loop，而不是一張帳單。
不靠大型模型也能快速判斷
監視任務的難點通常不在於「有沒有變化」，而在於「這個變化重不重要」。這封郵件是不是擁有者今天必須處理的？這個 PR 有沒有碰到我們關心的那部分系統？用整數 C 寫的 Loop 自己回答不了這些問題，而對每個事件都呼叫一次前沿模型，又會讓我們回到原點。
所以 Loop 多了一項能力：decide。它把一個小而具型別的問題發給快速決策模型（Jev），並拿回結構化的答案。下面是我們郵件監視原型裡的問題：
decide 支援用 choice 從候選項中選出一個，用彼此獨立的是非題處理多項匹配，以及用 score 給出有序的相關度。它只傳回判斷結果，不讀取資料來源，不執行工具，也不授予權限。資料由 Loop 提供，問題由 Loop 提出，門檻值也由 Loop 在自己的程式碼裡判斷。
有兩個設計選擇讓它運轉良好：
不確定也是有效答案。 明確的
none或defer選項表示「我判斷不了」，這是一個成功的結果，而不是傳輸錯誤。Loop 會保留該事件，而不是捏造一個「安靜」的判斷。它便宜到可以對每個事件都執行。 我們的價格目錄中，
typesafe/jev-1.13.0每百萬輸入 token 收費 $0.042，輸出 token 免費。這個價格足以篩查每一封郵件，而不只是關鍵詞過濾器放行的那些。
結果是一個兩級系統：小模型篩查每個事件，大型模型只看通過篩查的那些。
事件進來，持久留存
計時器足以應付輪詢，但很多來源可以主動推送。每個 Loop 都有一個信箱，外部系統可以透過三種方式向它投遞：
Salix API：使用群組 API 金鑰呼叫
POST /v1/agent-groups/:group_id/loops/:loop_id/events；一個私密 webhook URL，AI 代理可以用
loop.webhook啟用、輪換或撤銷它；來自使用者已連線應用的 Composio 觸發器，到達時會帶上提供者的事件 ID 和觸發器 slug。
上述任何一種方式傳回 202，都表示 PostgreSQL 已經把事件儲存在對應的 Loop 上，但並不表示 Loop 已經處理了它。訪客程式在到達安全點時呼叫 loop.ack：安全點可以是一個「安靜」的判斷，也可以是一次持久的交接，例如一次成功的 agent.notify。在此之前，事件一直處於待處理狀態；Reconciler 會在 Loop 遷移或重啟後重播待處理事件，並且無論如何每分鐘都會重播一次。如果一個事件在 15 分鐘內沒有被確認，Loop 就會明確地失敗，待處理事件會被保留下來，由 AI 代理決定重試還是丟棄。
建構過程中的一個教訓：spinfoam 的信箱是在接收時對事件 ID 去重，而不是在業務完成時。在早期原型中，我們以為模型呼叫失敗後，提供者重新投遞事件就能完成重試。實際上並沒有：重新投遞的事件被正確地當作重複項丟棄了。所以重試應當由訪客程式負責，它保留事件並進行有限次數的重試；崩潰後的恢復則由持久收件箱負責。現在我們把這條規則寫進了 SDK 指南。
確認、持久的 Session 接收、可見的訊息和外部副作用，是四個相互獨立的事實。我們為每一個都指定了各自的負責方，要求下游使用穩定的去重鍵，並且不承諾外部副作用恰好執行一次。
在不斷變化的叢集上永續執行
「24/7」說起來容易，但在節點來來去去的叢集上做起來很難。Loop 執行在持有其 AI 代理租約的節點上，並跟隨這份租約遷移。
放置。 AI 代理的伺服器端處理程序認領租約時，會接管它的活躍 Loop。AI 代理被鈍化或被隔離時，會釋放這些 Loop。活躍的 Loop 會讓它的 AI 代理保持駐留，因此一個帶有 Loop 的空閒 AI 代理會續租，而不是停駐。
化身。 Loop 每載入一次，它的化身編號就遞增一次，這是 Loop 記錄行上的一個隔離值。來自非當前化身的物件的主機呼叫會被拒絕，來自它的
ack也一樣。滯留在即將離開的節點上的過期 Loop 副本無法再採取任何行動。檢查點。
loop.state.put最多儲存 16 KiB，下次載入時會以config.state的形式取回。AI 代理只為游標和最後看到的 ID 做檢查點，而不是儲存一切。故障。 發生故障時，Loop 會從檢查點重新載入，每小時最多三次。超過之後它會變為
failed，並告知 AI 代理一次。擱淺。 一個週期性的清掃任務會找出沒有掛載物件、或掛載在已離開節點上的活躍 Loop，並重啟它們的所屬方。
Loop 在執行環境之外還有一份事實來源。loop.build 把編譯好的 ELF 寫入 AI 代理的檔案系統，loop.create 記錄它的路徑和 SHA-256。每次載入都會重新讀取檔案並校驗雜湊，因此 Loop 要麼執行的恰好是建立時的那個程式，要麼根本不執行。
Loop 被允許做什麼
Loop 是由模型編寫、在無人監督的情況下晝夜執行的程式碼。它的權限必須小於 AI 代理，而不是與之相等。
Loop 只能呼叫一份封閉的主機能力白名單：agent.notify，loop.state.*、loop.ack 和 loop.log 呼叫，被歸類為唯讀的 Salix 工具，環境和裝置工具，SSH 工具，讀取對話，web.http_request，用於已連線應用的 composio.execute，以及 decide。對其他任何名稱，Spinfoam 都以 SF_DENIED 拒絕。這裡根本沒有可能出錯的授權步驟。
每次呼叫都要經過與普通 AI 代理輪次相同的工具分發和資訊流檢查。Loop 以建立者的身分行事，透過委託主體 schedule|loop:<id>|<creator>，遵循建立者的披露規則和 Loop 的封存來源。事件酬載只是資料。它們不攜帶任何許可權，也無法擴大 Loop 能做的事情，這正是上文的決策提示明確把郵件當作不受信任輸入的原因。
最後，配額讓整個系統保持有界：每個 AI 代理最多 20 個活躍 Loop，每個群組最多 100 個；每個 Loop 最多 32 個待處理事件，每個 16 KiB；webhook 入口另有速率限制。
指令碼：同一個執行環境，只跑一個輪次
一旦有了一個安全、廉價、能執行 AI 代理所寫 C 程式碼的執行環境，第二種用途便浮現出來。script.run 會在單次工具呼叫內，把一個整數 C 程式編譯並執行一次，執行時可以透過 salix.call 存取呼叫方輪次自己的工具。指令碼沒有記錄行，沒有化身，沒有檢查點，也沒有 agent.notify。它讓 AI 代理能把許多次工具呼叫打包成一個確定性程式，而不必經歷多次模型往返。我們隨產品提供的技能中，有兩個就是以這種方式執行的 C 程式。
為自己編寫事件系統的 AI 代理
綜合起來，當 Comma AI 代理被要求盯住某件事時，它會做到傳統 AI 代理做不到的三件事：把監視任務寫成程式；叢集只需幾 KB 的代價，就能讓這個程式按需一直執行下去；再由一個小模型逐個事件地判斷，大型模型到底需不需要醒來。
內迴圈仍是 AI 代理思考的地方，外迴圈則是它保持關注的地方。Salix 讓 AI 代理兩者都能親手建構。