Cairn：用 Fact、Intent、Hint 三原語搜尋未知狀態空間
A AI general-purpose state-space search engine, validated first on autonomous penetration testing.
秒懂
- 它是什麼？
- Cairn 把滲透測試重新描述為「起點已知、終點已知、路徑未知」的定向搜尋，並用 Blackboard 架構與事實意圖圖來執行這個搜尋。本文拆解它的機制、部署方式、以及 AGPL-3.0 與 Docker 依賴帶來的實際邊界。
- 適合誰用？
- Cairn 適合已經有明確起點與成功條件、且願意自己承擔 worker 容器與 LLM 成本的研究型團隊，尤其是做 CTF、漏洞研究這類路徑未知但目標可判定的題目。它不適合需要固定流程、可審計步驟與穩定輸出的生產自動化場景，因為 README 明言它不定義角色也不定義工作流，任務完全由圖的當前狀態生成。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 8 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Cairn 要解的不是滲透測試，是「路徑未知」這類問題
README 開頭把 Cairn 定位成「a general-purpose problem-solving engine」，並強調它「defines no roles, no workflows」。它處理的問題形狀是：起點已知（目標 IP、目標系統），終點已知（拿到 shell、取得 flag），中間路徑未知。滲透測試只是這個形狀的一個實例，README 也把漏洞研究、數學證明、CTF 題目列為同一類。
這個定位決定了它的適用邊界。如果你的問題可以用固定步驟描述，例如「先掃描、再列舉、再嘗試已知 CVE」，那你要的是流程引擎，不是 Cairn。Cairn 的價值出現在你事先不知道下一步該做什麼、必須根據上一步的結果決定下一步的時候。反過來說，如果目標無法客觀判定是否達成，Cairn 也沒有辦法收斂，因為它的 Fact 定義是「A confirmed, objective finding」，客觀性是寫進資料模型裡的要求，不是使用建議。
三個原語撐起整張圖：Fact、Intent、Hint
Cairn 的資料模型只有三種東西。Fact 是已確認的客觀發現，寫進看板。Intent 是宣告出來的探索方向，尚未執行。Hint 是人類判斷，可以在任何時間點注入，由 agent 在下次讀取時吸收。
圖從 origin 往 goal 生長。每個新 Fact 是一塊踏腳石，每個 Intent 是一次踏入未知。這個設計的關鍵在於 Intent 與 Fact 是分開的：一個 Intent 被宣告之後不一定會被執行，也不一定成功，而失敗的探索不會污染已確認的事實集合。對於需要反覆試錯的場景，這個區分讓圖同時容納「已知為真」與「打算去試」兩種狀態，而不必把嘗試記錄偽裝成結論。
Hint 是唯一的人機介面。README 說它「injected at any time; absorbed by agents on the next read」，這意味著人類的介入不是同步的，不會立刻改變正在執行的任務，只會影響之後的讀取。如果你期待即時干預，這裡的節奏會比預期慢一輪。
Dispatcher 是唯一寫入者，Worker 只拿 prompt 回結構化輸出
架構上分成三層。Cairn Server 只維護圖的一致性，不做排程。Cairn Dispatcher 讀圖、排任務、啟動與拆除 worker 容器，並且是協定唯一的寫入者。每個專案有自己的 Worker Container，容器內可同時跑多個 Agent Worker。Agent Worker 的職責被壓到最小：只接收一個 prompt，回傳結構化輸出。
任務只有三種，全部由同一個 Worker 執行。Bootstrap 在專案開始時嘗試直接解題，輸出 Fact 以及可能的 Complete。Reason 讀整張圖，判斷目標是否已達成、接下來該探索什麼，輸出 Complete、新的 Intent 或 no-op。Explore 認領一個 Intent、執行探索、回報一個 Fact。
Agent 之間不直接通訊，只透過共享看板協調，README 稱之為 Stigmergy。這個選擇的實際後果是：協調成本從訊息傳遞轉移到圖的讀寫競爭上，而 Dispatcher 身為唯一寫入者，也成為整個系統的單點。多專案並行時，Server 與 Dispatcher 的負載會隨圖的規模成長，而不是隨 agent 數量線性成長。
安裝路徑：Docker Compose 與 local mode 二選一
前置條件是 macOS 或 Linux、Python 3.12 以上、以及 Docker。README 明確註明 Docker 只用於容器執行，「not needed for local mode」。
兩種方式都需要先拉 worker 容器映像：
docker pull --platform=linux/amd64 ghcr.io/oritera/cairn-worker-container:latest
然後建立 dispatcher 設定並填入 LLM 端點與 API key：
cp dispatch.example.yaml dispatch.yaml
Docker Compose 路線還要先拉建置用的基礎映像：
docker pull ghcr.io/astral-sh/uv:python3.13-trixie
docker compose up --build
README 說明這會啟動 cairn-server 於 8000 埠，並在 server 通過 health check 後啟動 cairn-dispatcher，dispatcher 會掛載專案根目錄的 dispatch.yaml。
除了容器模式，Worker 也可以直接跑在 dispatcher 主機上，README 稱之為 local mode，不需要 Docker。支援的 worker 後端有 Claude Code、Codex 與 Pi 三種。需要注意的細節是映像的 --platform=linux/amd64 標記：在 arm64 機器上這會走模擬路徑，README 沒有描述其效能表現，實際影響無法從現有材料判斷。
官方成績的適用範圍比標題看起來窄
README 引用的戰績來自騰訊雲黑客松 AI 滲透測試挑戰賽第二屆：610 支隊伍、1,345 名參賽者，Cairn 解出 54/54 題，是唯一 AK 的隊伍，最終排名第三。README 同時註明「The system had never been tested before the competition」，整條管線在比賽當天凌晨四點才首次上線，沒有訓練、沒有調校、沒有領域專用工具，也沒有 MCP、RAG 或預定義的 agent 角色。
這些數字說明的是：在一個題目邊界清楚、成功條件可自動判定的封閉競賽環境裡，這套機制能收斂。它不能推論到開放式環境。真實的滲透測試沒有主辦方定義的 flag，成功條件往往由客戶事後認定，目標可能中途改變，也可能根本不存在可達路徑。Cairn 的模型假設 goal 是明確且可判定的，這個假設在競賽場合成立，在生產環境不必然成立。
另外，這些成績來自單一賽事、單次執行，README 沒有提供重複實驗、不同模型後端之間的比較，或失敗案例的分析。
它不適合什麼：沒有可判定目標、需要步驟審計、或無法接受 AGPL 的場景
第一種不適合的情況是目標無法客觀判定。Fact 的定義要求客觀性，如果「成功」需要人類事後判斷，圖就沒有收斂條件，Reason 任務會持續產生新的 Intent。
第二種是需要逐步審計的場景。Cairn 不定義工作流，任務由圖的當前狀態在執行期生成。這代表你無法事先列出它會執行哪些步驟，也難以保證兩次執行走同一條路徑。對於受監管、需要事前核准每個動作的環境，這個特性是阻礙而非優點。
第三種是授權。專案採用 AGPL-3.0，這是網路服務條款性質最強的 copyleft 授權之一。如果你把它包成對外提供的服務，授權條款對原始碼揭露的要求會延伸到你的部署。這不是法律意見，實際影響取決於你的使用與散佈方式，需要自行確認。
還有一個工程上的限制：Dispatcher 是協定唯一寫入者，worker 容器由它啟動與拆除。這條路徑上任何一環失效，整個專案的探索就會停住。README 沒有描述容器的重試或崩潰恢復行為，這部分無法從現有材料確認。
替代方案：Cairn 與固定流程自動化工具的差別在狀態模型
最直接的對照是像 Metasploit 這類框架，或把 LLM 包進預定義 playbook 的自動化工具。它們的共同點是把「該做什麼」寫在執行之前：模組清單、階段順序、每個階段允許的動作集合。Cairn 把這件事反過來，執行前只有原點與目標，中間的步驟由圖的狀態生成。
差別的實際後果有兩面。好處是面對沒見過的目標時不需要先寫對應的 playbook，README 也特別強調零 MCP 工具、零 RAG、零預定義角色。代價是可重現性低、可解釋性依賴圖的完整記錄、除錯時要讀的是圖而不是日誌。
如果你的團隊已經有一套成熟的流程，而且流程覆蓋了大部分目標，那 playbook 工具的成本更低也更可控。Cairn 的優勢出現在流程覆蓋不到的地方，也就是你不知道下一步該做什麼的時候。兩者並不互斥，但 Cairn 的輸出是一張圖，要接進既有流程需要額外的轉換工作，README 沒有描述這部分。
維護成本與版本節奏
版本記錄顯示 v0.1.0 於 2026 年 5 月 3 日發布，v0.2.0 於 5 月 5 日，v0.2.1 於 5 月 10 日。一週內三個版本，且全部落在 0.x 階段，代表 API 與設定格式仍在變動。dispatch.yaml 這類設定檔在這種節奏下需要預期改動。
外部依賴有三個層面：Python 3.12 以上、Docker（容器模式）、以及 LLM 端點。前兩者版本相對穩定，第三者的成本與可用性取決於你接的供應商，README 只要求「fill in your LLM endpoints and API keys」，沒有指定模型或價格區間。
worker 容器映像以 latest 標籤發布，README 沒有提供固定版本標籤的拉取方式。這表示重建環境時可能拿到不同版本的映像，對於需要可重現部署的團隊是個需要自行處理的問題，例如在本地重新標記映像。
授權方面，AGPL-3.0 允許商業使用與修改，但對網路服務的原始碼揭露有額外要求。這一段不是法律意見，條款的實際適用範圍應由你的法務判斷。
編輯結論
Cairn 適合已經有明確起點與成功條件、且願意自己承擔 worker 容器與 LLM 成本的研究型團隊，尤其是做 CTF、漏洞研究這類路徑未知但目標可判定的題目。它不適合需要固定流程、可審計步驟與穩定輸出的生產自動化場景，因為 README 明言它不定義角色也不定義工作流，任務完全由圖的當前狀態生成。採用前先確認三件事：dispatch.yaml 裡要接哪個 LLM 端點、worker 容器映像能否在你的平台上以 linux/amd64 執行、以及 AGPL-3.0 對你散佈方式的影響。這三項沒有確認之前，不建議把它放進任何對外提供的服務路徑。
社群筆記