運作方式
每台 Buttress 伺服器於連接埠8089 執行 UDP 傳輸：
- ANNOUNCE — 每 5 秒廣播一次，內含伺服器的
serverInfo（能力、generator 清單、認證狀態）。 - QUERY — launcher 可廣播查詢，伺服器以單播 RESPONSE 回應。回應延遲會隨機化，避免多台伺服器同時回覆造成風暴。
0.0.0.0:8089 綁定接收 socket 以接收進入的查詢，並為每個本機廣播介面綁定一個發送 socket，確保各子網路的廣播從正確的 NIC 送出。
通告內容
serverInfo 包含 generators[] 陣列，列出啟動時計算的各後端硬體能力：
ggml-llm — 它的嵌入與 tokenizer context 都在 LLM 後端上執行 — 因此任何通告該型別的伺服器都是候選。
只有啟用本地函式的伺服器才會帶 functions，而且只包含是否啟用與數量，不含工具清單 — 工具清單放不進一個 UDP 封包。
能力評分
評分為 0-100 數值，由以下項目組成：
無 GPU 的筆記型電腦約 15-25 分；搭載 RTX 4090 的工作站可達 80-90 分。
信任模型
不論已繫結或未繫結，所有伺服器皆會通告，但 launcher 對待方式不同：- 未繫結伺服器（
authentication.required = false）會以未受信任端點呈現。手動或公開客戶端仍可使用，但已繫結的 launcher 會忽略它們。 - 已繫結伺服器（
authentication.required = true）僅在其serverId出現於工作區繫結伺服器清單且通告由工作區於繫結時登錄的對應伺服器專屬通告金鑰簽署時才被信任。
簽署過的通告
每台 Buttress 伺服器都有自己的 Ed25519 通告金鑰對，由bricks buttress bind 產生。公鑰會登錄至 BRICKS 雲端，並透過 myWorkspaceButtress.buttressServers[].serverPublicKey 提供給 launcher；私鑰則保留於伺服器主機的 ~/.bricks-cli/buttress/state.json。
已繫結伺服器送出的每個 UDP ANNOUNCE 與 RESPONSE 都會夾帶針對 { t, d, ts } 的簽章。launcher 會以登錄的公鑰驗證簽章，並套用 30 秒重放視窗 — 缺乏有效簽章的封包永遠不會進入端點池。此舉封閉了「區域網路上的對等節點重新通告已繫結 serverId、藉此取得工作區 bearer token」的偽冒攻擊面。
通訊協定版本已升級為 2.0。執行協定 1.0 與 2.0 的 launcher 與伺服器會無聲地丟棄對方的封包，因此新舊組合會互相隱形而非以未簽署的形式互信。若要升級既有的已繫結伺服器，請重新執行 bricks buttress bind（會產生新的通告金鑰對）並重新啟動 bricks-buttress。
手動覆寫
當自動探索不可行時（裝置位於不同子網，或 Buttress 伺服器位於雲端），BRICKS Controller 的 Config Editor 提供將每個 LLM/STT brick 從 Auto 切換為 Manual 並直接輸入 WebSocket URL 的選項。請參閱從 Foundation 使用 Buttress。HTTP 回退
launcher 也可以直接以已知 IP 透過 HTTP 查詢：serverInfo 結構與 UDP ANNOUNCE 相同。Foundation launcher 在 UDP 廣播被封鎖時（部分企業 Wi-Fi 網路）會於內部使用此路徑。
疑難排解
下一步
工作區繫結
伺服器的
kid 與繫結伺服器清單如何核發。從 Foundation 使用
各 brick 的連線設定：Auto vs Manual、策略、回退。