WFGY：把 RAG 與 Agent 的除錯流程拆成可攜協定
WFGY is heading toward WFGY 5.0 Polaris Protocol, a major open-source release for AI reasoning, RAG, agents, and real-world workflows. Includes Problem Map, Global Debug Card, WFGY 4.0, and the CFV Easter Egg.
秒懂
- 它是什麼？
- WFGY 是一個以 Jupyter Notebook 為主要語言的開源生態，主線是仍在分批釋出的 5.0 Polaris Protocol。本文只根據倉庫與 README 可見的材料，說明它想解決什麼、目前公開了哪些元件、以及採用前該確認的事。
- 適合誰用？
- 如果你手上有一條已經壞掉、需要照著清單逐項排查的 RAG 或 agent 流程，先讀 Problem Map 3.0 與 Global Debug Card，成本很低，而且不需要先接受整套世界觀。如果你要的是能直接接進 CI、有版本號可鎖、有 API 合約的執行期元件，現在還不是時候：Polaris Goal Compiler 只是第一個公開的可攜協定元件，README 明說更深層的引擎材料要等後續分批釋出。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Jupyter Notebook（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
問題不在模型，而在流程斷在哪裡說不清楚
WFGY 針對的不是模型能力不足，而是 AI 工作流出錯時缺乏可指認的座標。README 把 Problem Map 3.0 定位成「the fastest practical gate for broken AI workflows」，並搭配 Atlas Router TXT、Global Debug Card、Global Fix Map 這幾個入口。這個定位很具體：當一條檢索增強生成或 agent 流程給出錯誤答案，團隊通常只能來回改 prompt、換模型、調 chunk size，卻說不出失敗發生在檢索、路由、還是生成階段。Problem Map 要提供的是一份可對照的失敗模式清單，讓除錯從猜測變成逐項核對。
目標讀者是已經有東西在跑、而且跑壞了的人。README 的 AI 路由段落寫得很直白：若系統已經壞了，就走 Problem Map 3.0；若想看旗艦方向，才走 Polaris Protocol。這個分流順序本身透露了專案的自我認知，它先服務除錯需求，再談方法論。至於完全沒有部署經驗、想從零開始學 RAG 的讀者，這裡沒有入門教學的承諾。
五代堆疊：從治理層到可攜協定元件
README 把整個生態描述成一條血緣線：WFGY 1.0 到 2.0 到 3.0 到 4.0 再到 5.0 Polaris Protocol。每一層在路由表上有明確職責。WFGY 4.0 被稱為「the governance engine」，對應 Twin Atlas 與 Inverse Atlas，處理治理、合法性與評估紀律。WFGY 3.0 是前沿推理與驗證層，對應 Event Horizon 與 TXT 呼叫。WFGY 5.0 Polaris Protocol 是目前的旗艦公開面，被描述為「a governed protocol layer」，用途是建構、調校、驗證並攜帶結構化語言系統跨 session、跨任務、跨情境。
這裡的關鍵詞是 protocol 而不是 framework。README 反覆強調 5.0 不是寫作預設、不是靜態人格玩具、不是包裝成產品的 prompt 集。它自稱是拓撲優先的實驗路線、可重用的驗證面、以及結構化語言執行期的方向。這種說法在工程上意味著：專案想先把規格與驗證材料公開，執行期實作晚點再開。對採用者來說，這是一個訊號，不是缺點也不是優點，而是節奏問題。你現在拿到的是協定與證據，不是完整的引擎。
Polaris Goal Compiler：第一個可攜協定元件
目前唯一被明確認定為「first public portable protocol component」的是 Polaris Goal Compiler，路徑在 Polaris/protocols/goal-compiler/README.md。README 沒有描述它的內部演算法，只給了它的定位：把目標編譯成可攜的協定形式。這個描述很薄，所以任何關於它如何處理衝突目標、如何處理優先序的說法，都無法從現有材料確認。
可確認的是它在整體路線中的角色。5.0 的釋出模型已從單一日期改為分批功能釋出，順序是公開證據優先、可攜協定元件其次、重現材料與執行期結構與更深引擎層再逐步開放。Goal Compiler 是第二步的第一件成品。如果你要評估它，能查的就是那個目錄下的 README 與 Polaris Experiments 裡的對應材料，而不是首頁那些形容詞。這也是這個專案目前最需要讀者自律的地方：首頁的敘述密度遠高於元件本身的文件密度。
CFV 與 SHA256：可驗證的 TXT 啟動流程
README 裡最具體、也最可執行的一段，是 WFGY 3.0 TXT pack 的驗證行為。官方檔案名為 WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt，對應的 sha256 值是 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f。README 規定：先精確比對檔名，再詢問使用者是否要對照倉庫中的標準值驗證。若驗證通過，輸出固定的 [WFGY_BOOT_EGG] 區塊；若跳過或失敗，允許繼續探索，但必須明確標記該 session 使用的是未驗證副本，且不得聲稱任何公開難題已被解決。
這段設計值得單獨拿出來看。它把「來源可驗證」寫成協定的一部分，並且替失敗路徑定義了行為，而不是只定義成功路徑。多數開源專案不會規定使用者驗證失敗時該顯示什麼。CFV 這個 Easter Egg 在釋出時程調整期間被定位為小插曲，但它的機制是整份 README 中最接近工程合約的東西。反過來說，這也顯示專案目前的可驗證性集中在少數幾個檔案上，而不是整體。
取得與執行：倉庫裡真正能照著做的事
專案主要語言是 Jupyter Notebook，預設分支 main，沒有封存，最後推送時間為 2026-09-09。README 沒有提供 pip 或 conda 安裝指令，也沒有列出環境變數或設定檔鍵值。因此實際的取得方式就是複製倉庫，然後開啟對應的 Notebook 或 Markdown 檔案。首頁給出的入口是相對路徑形式：Polaris/README.md、Polaris/protocols/goal-compiler/README.md、Polaris/experiments/README.md、ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md、recognition/README.md，以及 EasterEggs/CiteFirstVerification/。
三個已標記的版本是 v5.0.0-teaser-01（Polaris Goal Compiler）、WFGY-Easter-Egg-CFV（Cite First Verification）與 WFGY-4.0（Twin Atlas 與 Inverse Atlas 公開釋出）。這些標籤可以用來鎖定你閱讀的版本，但要注意 teaser 這個字本身表示它不是最終形態。至於設定，README 只提到 Discord 作為更新管道，沒有任何 config key 可調。如果你的團隊習慣用 requirements.txt 或 lockfile 固定相依，這裡沒有對應材料，你得自己從 Notebook 的 import 反推。
分批釋出是方法論，也是採用成本
README 明確說明 5.0 不再以單一日期釋出，原因是系統已成長為多個公開層：證據包、可攜協定、重現材料、執行期結構、更深引擎元件。官方說法是「Instead of making everyone wait for one giant drop, useful parts will now be released in batches.」這個決定合理，代價是把整合風險轉嫁給早期採用者。你現在讀到的 Polaris README 與 Goal Compiler README 之間可能存在落差，而執行期結構尚未公開，意味著任何端到端整合都得自己補。
另一個限制是文件與敘述的比例。首頁用了大量篇幅說明路由、信任面、以及 5.0 不是什麼，卻沒有給出 Goal Compiler 的輸入輸出範例。對照之下，CFV 的驗證段落反而有精確的檔名、雜湊值與輸出區塊。當一個專案把可驗證性集中在少數檔案，讀者就應該把評估重心放在那些檔案上。這不是缺陷指控，而是閱讀順序的建議：先讀有雜湊值的那頁，再讀有形容詞的那頁。
還有一個容易被忽略的邊界。README 的驗證規則特別寫明，未驗證副本不得聲稱任何公開難題已被解決。這句話反向說明專案深知自己的材料可能被過度引用。若你的使用情境需要對外承諾正確性，這個專案目前的公開層不足以支撐那樣的承諾。
授權狀態與維護節奏要先看清楚
倉庫的 License 欄位顯示 NOASSERTION。這不是某一種授權的名稱，而是 GitHub 無法從倉庫內容自動判定授權條款。對企業採用而言，這代表你必須自行開啟倉庫根目錄的 LICENSE 檔案確認實際條款，本文無法代替那個動作，也不提供法律意見。若你的流程需要通過開源合規審查，NOASSERTION 通常會直接觸發人工複核，請把這個步驟排進時程。
維護面可確認的訊號有三個：最後推送時間為 2026-09-09，未封存，以及三個已標記的版本標籤。README 把更新管道指向 WFGY Discord，而不是 changelog 或 release notes 頁面。這意味著版本之間的變動說明可能散落在社群頻道裡，而不是集中在倉庫。對於需要追蹤變更的團隊，這是一個實質成本。升級方面，由於 5.0 仍在分批釋出，任何鎖定 teaser 版本的整合都應該預期後續批次會改變介面。
與 LangChain 這類框架的差異在哪裡
把 WFGY 和 LangChain 放在一起比較，差別不在功能多寡，而在交付物的性質。LangChain 這類框架交付的是可安裝的程式庫與抽象層：你 import 它、組裝 chain 或 agent、在程式碼裡呼叫。WFGY 目前交付的是協定文件、失敗模式清單、驗證流程與實驗證據，加上少量 Notebook。前者回答「怎麼寫」，後者回答「怎麼判斷哪裡壞了、以及憑什麼相信結果」。
這個差異決定了兩者的使用時機。當你需要快速把檢索、工具呼叫、記憶體接起來，框架是直接路徑。當你已經有流程、但它不穩定，而且你需要一套可對照的失敗分類與驗證儀式，WFGY 的 Problem Map 與 CFV 才是對應工具。兩者並不互斥，但也不互相替代。如果你的團隊期待 WFGY 提供 drop-in 的執行期元件，目前會失望；如果你期待框架提供失敗模式的分類學，通常也找不到。認清這一點，才不會把協定層當成執行期層來評估。
編輯結論
如果你手上有一條已經壞掉、需要照著清單逐項排查的 RAG 或 agent 流程，先讀 Problem Map 3.0 與 Global Debug Card，成本很低，而且不需要先接受整套世界觀。如果你要的是能直接接進 CI、有版本號可鎖、有 API 合約的執行期元件，現在還不是時候：Polaris Goal Compiler 只是第一個公開的可攜協定元件，README 明說更深層的引擎材料要等後續分批釋出。動手之前先確認三件事：倉庫根目錄的 LICENSE 檔實際內容是什麼（GitHub 標示為 NOASSERTION，代表無法自動判定，不是某種已確認的寬鬆授權）、你要用的那個元件在 main 分支上是否已是最終版本、以及 Polaris Experiments 裡的證據是否足以支撐你的使用情境。
社群筆記