Graph of Thoughts：把 LLM 推理寫成一張可執行的運算圖
Official Implementation of "Graph of Thoughts: Solving Elaborate Problems with Large Language Models"
秒懂
- 它是什麼？
- spcl/graph-of-thoughts 把解題流程拆成 Graph of Operations，由 Controller 依序驅動 LLM 執行。它適合想重現論文實驗或研究推理拓撲的人，不適合想找現成產品化推論服務的團隊。
- 適合誰用？
- 要採用這個框架，先確認你的問題能否寫成 Generate、Score、GroundTruth 這類 operations 的序列，並且願意自己接上 LLM 與解析器。研究用途、想復現論文排序與關鍵字計數實驗的人，直接從 examples 目錄跑起最省事。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 175 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是推理結構的表達問題，不是模型能力問題
多數 LLM 應用把思考壓成一條直線：輸入提示、拿到回應、必要時再追問一輪。這種寫法在簡單問答上夠用，但當問題需要先把答案拆開、分別評分、再合併回一個結果時，直線流程就開始扭曲。你要嘛把所有邏輯塞進一段提示，要嘛在程式碼裡手寫分支，兩者都讓實驗難以複現。
GoT 的做法是把解題流程本身當成資料結構。README 的開頭寫得很直接：這個框架讓你「將複雜問題建模為 Graph of Operations（GoO），並以大型語言模型作為引擎自動執行」。注意主詞是 GoO，不是 LLM。框架關心的不是模型多強，而是你怎麼描述一組操作之間的依賴關係。
目標讀者有兩類。第一類是研究人員，想驗證不同推理拓撲（鏈狀、樹狀、圖狀）在同一題目上的差異，並且需要把中間產物存下來比對。第二類是工程師，手上有一個明確可拆解的多步任務，願意為了可控性放棄一點開發速度。README 也說明了框架的彈性：你可以用新的 GoT 方法解題，也可以實作「類似 CoT 或 ToT 的 GoO」。換句話說，它把先前那些方法當成同一套抽象下的特例。
Graph of Operations 與 Controller：誰決定順序，誰負責呼叫模型
從 README 的 Quick Start 可以看出三個角色。operations.GraphOfOperations 是容器，你用 append_operation 把操作依序排進去。範例裡的 CoT 版本只有三步：Generate、Score（評分函式為 utils.num_errors）、GroundTruth（驗證函式為 utils.test_sorting）。
Controller 是執行者。它的建構子吃五個參數：語言模型物件、GoO、Prompter、Parser，以及一個描述初始 thought state 的字典。這個字典值得注意，因為它同時是輸入也是流程狀態。CoT 範例填的是 original、current、method 三個鍵；GoT 範例多了一個 phase 鍵，值為 0，method 則改成 got。同一個題目、同一個模型，差別只在初始狀態與 GoO 的形狀。
Prompter 與 Parser 是這套設計的接縫。Prompter 負責把當前的 thought state 轉成給 LLM 的文字，Parser 負責把模型回傳的字串轉回結構化資料。兩者都以類別形式傳入，也就是說換題目時你換的是這兩個類別，而不是改動 Controller 或 operations 的核心。
執行完之後呼叫 ctrl.output_graph("output_cot.json")，把整張圖寫成 JSON。README 明講，你可以「藉由檢視輸出圖 output_cot.json 與 output_got.json 來比較兩者結果」，而最終 thought state 的分數代表排序清單中的錯誤數量。分數是 num_errors 算出來的，不是模型自評。
安裝與最小可跑路徑：pip、config.json、兩個模組指令
環境門檻是 Python 3.8 或更新版本，README 在 Setup Guide 第一句就寫明了。安裝有兩條路。只想使用套件的使用者直接從 PyPI 裝：
pip install graph_of_thoughts
要改原始碼的開發者則從 GitHub 取下來，在專案目錄內以可編輯模式安裝：
git clone https://github.com/spcl/graph-of-thoughts.git cd graph-of-thoughts pip install -e .
兩條路都要求你先啟用 Python 環境。
真正的摩擦點在 LLM 設定。README 沒有在這一頁給出金鑰格式，而是把讀者導向 Controller 的說明文件：graph_of_thoughts/controller/README.md。程式碼範例則透露了形狀，language_models.ChatGPT("config.json", model_name="chatgpt")，註解寫著「假設當前目錄有含 OpenAI API key 的 config.json」。這表示設定檔路徑是硬傳進建構子的，你要嘛把 config.json 放在工作目錄，要嘛自己改路徑。
想先看它跑起來的樣子，README 提供了兩個模組指令：
python -m examples.sorting.sorting_032 python -m examples.keyword_counting.keyword_counting
README 提醒結果會存在各自的 examples 子目錄下。這兩個指令不需要你自己寫 Prompter 或 Parser，是確認環境與金鑰是否正確的最短路徑。
範例目錄是論文實驗的入口，也是這份程式碼最重的資產
README 把 examples 目錄描述為「包含數個可用此框架解決的問題範例，其中包括論文中所呈現的那些」，並說每個範例都有自己的 README.md 說明如何執行與調整。這是判斷要不要投入時間的關鍵資訊：你不必從空白開始設計 GoO，可以直接讀既有的 Graph of Operations 怎麼被組出來。
論文結果的復現也走同一條路。README 說你可以依 examples 目錄的指示跑論文實驗；如果只想檢視與重繪結果，則用 paper 目錄。這種分工意味著 paper 目錄放的是繪圖與結果資料，不是執行腳本，跑實驗的成本主要落在 LLM 呼叫上。
排序範例的規模在程式碼裡是明示的：32 個數字，題目變數就叫 to_be_sorted。這個規模不是隨便選的，它小到能人工核對錯誤數，又大到讓 CoT 與 GoT 的差異有機會顯現。關鍵字計數範例則展示了另一種題型。兩者都是文字進、文字出的任務，不需要外部工具或檢索。
要注意的是，範例的價值在於示範結構，而不是示範效能。README 沒有給出任何延遲、成本或準確率的數字，只說分數代表錯誤數量，實際數字要你自己跑出來。
限制一：這是一份研究實作，不是維運過的服務
版本節奏說明了一切。v0.0.1 在 2023 年 8 月，v0.0.2 在同年 9 月，兩者都還在 0.0.x 階段。授權欄位顯示為 NOASSERTION，代表 GitHub 無法從倉庫內容自動判定授權，README 也沒有授權段落。要把它放進商業產品的依賴樹之前，這件事必須先釐清，而且我無法從現有材料告訴你它最終是什麼條款。
第二個限制在於抽象層的成本。為了讓同一套 Controller 能跑 CoT 與 GoT，你必須提供 Prompter 與 Parser 兩個類別。對單一、固定的任務來說，這比直接寫一段 prompt 加一次 API 呼叫要多出不少程式碼。框架的彈性只有在你要比較多種推理結構、或要保存中間圖譜時才回本。
第三個限制是失敗模式偏安靜。Controller 依序執行 operations，Score 用你提供的函式打分，GroundTruth 用你提供的函式驗證。如果 Parser 把模型輸出解析錯了，錯誤會以低分的形式出現在圖裡，而不是拋出例外。你必須自己去看 output_got.json 的最終 thought state 分數，才知道這一輪到底發生什麼事。
限制二：什麼情況下它會是錯的工具
如果你的任務是一次問答、一次摘要、一次分類，GoO 只會是一層多餘的間接。你要寫 Prompter、寫 Parser、組 GraphOfOperations、傳初始狀態字典，換來的是一張只有兩三個節點的圖。這種情況下直接用模型 SDK 更短也更清楚。
如果你的瓶頸是檢索或工具呼叫，這個框架也幫不上忙。README 描述的引擎是 LLM，範例是排序與關鍵字計數，都是純文字進出的推理題。它沒有提到向量資料庫、外部 API 或函式呼叫的整合方式。
還有一種情況容易被忽略：需要嚴格延遲保證的線上服務。GoT 版本在排序範例中會經過多個 phase，每個 phase 都牽涉 LLM 呼叫，而 CoT 版本只有一次 Generate。README 沒有給出任何呼叫次數或時間數字，但從「更複雜的 GoT 方法」這個描述可以合理推斷，圖越複雜，呼叫越多。這是設計上的取捨，不是缺陷，但如果你在意尾延遲，就要先量測再決定。
替代方案：LangGraph 走的是狀態機，GoT 走的是運算圖
同類工具裡最常被拿來對比的是 LangGraph。兩者都在處理「多步 LLM 流程」這個問題，但切入點不同。
LangGraph 把流程建模成狀態機：節點是函式，邊是轉移條件，執行時沿著邊推進共用狀態。它的重心在控制流，包含迴圈、條件分支、中斷與續跑。GoT 的重心在資料流：GraphOfOperations 是一串操作，每個操作消費並產生 thought state，Controller 依序執行，最後把整張圖 dump 成 JSON。
差異在可觀測性上最明顯。GoT 的產出是一份圖檔，你可以事後檢視每個 thought state 與它的分數，這對研究比對很直接。LangGraph 的產出是執行軌跡，重心在流程有沒有走對分支。反過來說，GoT 的 operations 是內建集合（Generate、Score、GroundTruth 等），要表達複雜的分支邏輯會比較繞；LangGraph 的節點是任意函式，表達力更自由。
選擇的判準很簡單：你要比較不同推理拓撲、要保存中間思考與分數，選 GoT。你要編排多個工具、多個模型、帶重試與人工介入的生產流程，LangGraph 的模型更貼合。兩者不是同一層的東西，硬要比優劣沒有意義。
維護成本與升級前該確認的事
這個倉庫沒有封存，最後一次推送是 2026 年 3 月。但發佈版本只有 v0.0.1 與 v0.0.2，時間點都在 2023 年 9 月。也就是說，程式碼有在動，語意化版本卻停在很早期。對依賴管理來說，這代表 pip install graph_of_thoughts 拿到的版本與 main 分支可能有一段距離，鎖版本時要特別留意。
升級成本主要來自兩處介面。第一是 Controller 的建構子簽章，因為初始狀態字典的鍵（original、current、method、phase）與你的題目綁在一起，欄位一改，所有呼叫端都要跟著改。第二是 language_models 底下的模型類別，README 只示範了 ChatGPT 一種，並把其餘設定指向 controller/README.md。若上游供應商的 API 有變動，這一層是最先受影響的地方。
授權方面，NOASSERTION 意味著倉庫裡沒有可被自動辨識的授權檔。這不是說它沒有授權，而是說我無法從提供的材料判斷條款內容。要商用之前，請直接檢視倉庫根目錄的授權檔案，必要時詢問維護者，這裡不構成法律意見。
文件的可信度其實不低。README 強調「我們特別用心完整記錄程式碼」，並指出 Controller 與 Operations 兩個模組的說明文件最關鍵。以研究實作而言，願意把模組層級的文件寫到這個程度並不常見，這也是它相對容易上手的原因。
編輯結論
要採用這個框架，先確認你的問題能否寫成 Generate、Score、GroundTruth 這類 operations 的序列，並且願意自己接上 LLM 與解析器。研究用途、想復現論文排序與關鍵字計數實驗的人，直接從 examples 目錄跑起最省事。只想把 LLM 包成服務、需要穩定 API 與版本保證的團隊不該選它：v0.0.2 停在 2023 年 9 月，語言模型走 config.json 的 API key 路線，升級前務必先讀 controller/README.md 確認介面有沒有變動。
社群筆記