產品接入層

#三種接入形態

控制器的原始碼註解寫明了這條邊界：保證只涵蓋透過本控制器啟動的子行程。

#vacant run：以行程結束作為交付點

2026-09-18 加入。建立在一個觀察上：

若只是要攔下交付，觸發點不在網路協定上，而在代理行程結束的那一刻。

這個訊號完全可靠、不需要任何協定知識、不耗 token，而且跨所有框架成立。

#流程

1. 啟動本機代理伺服器，依一份名單設定代理的 base URL 環境變數；把真實上游位址與金鑰從代理的環境中移除，只留在代理伺服器行程。
2. 記錄工作區的樹雜湊。
3. 啟動代理並等待結束；結束後終止整個行程群組，以防孫行程在凍結後寫入。
4. 在凍結的工作區快照上執行可見驗收，並再量一次樹雜湊；不相等則標為基礎設施失敗。
5. 簽下每次嘗試與每格裁決，以退出碼反映裁決。

#兩條硬規則

#代理伺服器只記錄、不注入

所有請求與回應的原始位元組逐字落盤，開關兩臂的請求位元組逐位元相同。

專案刻意不在對話中注入任何訊息，理由是：注入等於偽造模型或使用者的發言，會傷害「紀錄忠實」這個立論根基。

#圍牆、掛鉤與出口

#圍牆

以 bwrap 建立獨立的網路與掛載命名空間，唯一的出口是主機上一個路徑型 Unix socket，由常駐代理伺服器把守，非模型的路徑一律拒絕。

實測：bwrap 擋掉除閘門以外的一切；負控制 7/7。

#掛鉤

五種代理的框架掛鉤都能攔下 shell 指令。

#出口：能力分離

「判定拒絕」不等於「不可能發布」。出口的問題以能力分離處理：

• release 模組只在通過時鑄造放行憑證（結構取自 SLSA 的驗證摘要證明）。
• publish 模組是唯一有對外寫入能力的元件。它驗證憑證的簽章、產物雜湊、判決、有效期與涵蓋範圍。
• publish 不讀退出碼，也刻意沒有強制發布的選項。

#那次讓我們改掉用詞的稽核

2026-09-20 的 ABPI 稽核（391 格）：

這一條直接導致了 五層語彙 的改寫。

#五種代理的實測

合計 20 條收據鏈 / 40 筆。但三家對同一題的判斷並不一致——公開題庫閘門（10 題 × 3 助手 × 兩批）跑出「三個助手只在 4/10 題上一致」。

#vacant on 與 agentlane

#vacant on

讓使用者在終端機輸入 vacant，從選單挑選本機實際存在的命令列代理，在中介之下啟動。它把 base URL 寫進「這一次執行自己的」暫存設定目錄，不改動使用者的常駐設定檔。

選單上會標出每一種代理的通道驗證到什麼程度，例如「通道已驗」或「通道沒量過，跑完請看 requests_seen」。

#agentlane

長時間執行 vacant on 的量測工具。一格通過需要三個獨立來源對得上：

1. requests_seen ≥ 1
2. 代理伺服器的索引行數 == requests_seen
3. 代理的退出碼有值

每一輪都跑負控制（上游指向關閉的埠）。負控制沒過的那一輪，正控制也不算數。

交付是否被接受刻意不列為判準，以區分通道與模型能力。

第一輪冒煙測試就抓到一個漏洞：OpenCode 忽略指定的工作目錄，把交付寫到別處，導致中介全數通過但每一格都被拒交。另外 OPENCODE_CONFIG_CONTENT 會清掉使用者的 MCP 設定。

#數位分身展件

54 格、630 次真實模型呼叫的展場實驗，提供了一個關於「介面給不給資訊」的直接對照：

同時：重來迴圈救回 0 / 30。另有 82 次代理宣告成功但可見檢查失敗，以及 8 次逾時被殺。

#接下來

• 五層語彙的完整說明：收據
• 這個專題不宣稱什麼：邊界與不保證事項