all-agentic-architectures：35 種代理架構的統一合約與可執行教科書

它解決什麼問題，為誰而寫

代理式 AI 的文獻散亂，每個模式各有實作風格，研究人員或工程師要比較 Reflexion 與 LATS 的差異，往往得讀不同程式庫、處理不同 API。這個專案把 35 種模式，從 Reasoning 到 Memory 再到 Tools，全部封裝成單一的 Architecture 類別，統一使用 .run(task) 介面，回傳相同的 ArchitectureResult 結構。它的目標讀者很清楚：想快速理解某個模式的實際運作、或想在自家任務上比較多種架構的人。README 稱它為「library 與 living textbook」，因為每個模式都附帶一份已執行的 Jupyter notebook，理論是對著真實執行結果寫的，不是用合成範例。這對學習者特別有價值，因為你可以看到某個架構在真實 LLM 輸出下如何表現，而不是看一個刻意設計的成功案例。

deterministic-picker：對抗 LLM 評分失靈的紀律

這個專案最核心的技術主張，不是某個特定架構，而是「deterministic-picker pattern」。README 描述了一個常見問題：LLM 作為評分器（LLM-as-Scorer）時，經常出現「flat-band pathology」，也就是模型給的分數缺乏鑑別度，全部擠在同一個區間，導致無法判斷哪個輸出較好。解法是讓 LLM 先承諾分類特徵，例如布林值或列舉值，再由 Python 組合這些訊號來做最終決定。這個模式應用到 35 個架構中的 13 個，另外 9 個則在設計上就免疫。換句話說，專案不是把評分丟給 LLM 了事，而是把 LLM 限制在它相對可靠的範疇，例如判斷「這段文字是否包含事實錯誤」，而不是要求它給出 0 到 10 的連續分數。這個取捨值得注意：它增加了實作的複雜度，因為每個評分點都要設計分類問題，但換來的是更穩定的比較基準。

安裝與啟動：從 pip 到第一個執行

安裝指令直接從 README 來：pip install "agentic-architectures[nebius,faiss,tavily]"。額外依賴用 extra 標記，例如 nebius 代表 Nebius 提供者，faiss 用於向量檢索，tavily 是搜尋工具。使用方式很簡潔，先取得 LLM 實例，再建立特定架構：from agentic_architectures import get_llm，然後 from agentic_architectures.architectures import Reflection，接著 arch = Reflection(llm=get_llm(), max_iterations=2, target_score=8)，最後 result = arch.run("Write a haiku about a glacier.")。輸出在 result.output，分數在 result.metadata["final_score"]。從原始碼複製專案時，README 建議建立虛擬環境，執行 pip install -e ".[dev,test,docs,nebius,faiss,tavily,networkx]"，複製 .env.example 成 .env 並填入 NEBIUS_API_KEY 等金鑰，最後用 pytest -q 跑測試，號稱 283 個測試約 30 秒完成。這個流程清楚，但注意 get_llm() 沒有參數時預設用哪個提供者，README 沒說明，你得自己查文件。

架構家族與統一介面的實際意義

35 個架構被分成幾個家族，包括 Reasoning & Reflection（Reflection、Reflexion、Chain-of-Verification）、Sampling & Search（Self-Consistency、Tree of Thoughts、LATS）、Retrieval RAG（Agentic RAG、Corrective RAG、Self-RAG、Adaptive RAG、GraphRAG）、Memory（Episodic + Semantic、MemGPT、Voyager）、Tools & Actions（Tool Use、ReAct、Planning、SWE-Agent、Computer Use）。每個家族內的模式差異很大，例如 Tree of Thoughts 需要樹狀搜尋，而 Reflection 只是單一迴圈，但它們都共用同一個 .run(task) 介面。這對下游程式碼是優點：你可以在不改變呼叫方式的情況下，把 Reflection 換成 LATS，只要調整建構參數。但這也隱含一個限制：統一介面可能無法暴露每個架構的特殊功能，例如 LATS 的樹狀結構參數，或 MemGPT 的記憶管理細節。若你需要深入控制某個模式的內部機制，這個抽象層可能太厚。

支援的 LLM 提供者與執行環境

README 列出九個 LLM 提供者：Nebius、OpenAI、Anthropic、Groq、Ollama、Together、Fireworks、Mistral、Google。這表示你可以用同一套程式碼，在不同提供者之間切換，只需要調整 get_llm() 的參數或環境變數。Ollama 的存在代表本地模型也可行，這對不想把資料送到外部 API 的團隊有意義。所有架構都建在 LangGraph 狀態機之上，這是一個重要的依賴決策。LangGraph 提供了狀態管理與節點執行的基礎，但也意味著你必須接受它的抽象。若你的團隊已經熟悉 LangGraph，這會是加分；若你偏好輕量實作，這個依賴可能過重。另外，README 強調「0 MOCKED RUNS」，也就是所有筆記本都是真實執行過的，這增加了可信度，但也代表執行這些筆記本需要實際的 LLM API 金鑰與成本，不是離線就能重現。

限制與不適用的場景

這個專案有一個明確的弱點：它是一個「教科書」與「函式庫」的混合體，但兩者的需求可能衝突。作為教科書，它需要展示每個架構的完整理論，所以筆記本會很長；作為函式庫，它需要穩定的 API 與精簡的介面，但 35 個架構的實作細節可能讓程式碼龐大。README 沒有提到任何效能基準，例如延遲或吞吐量，所以你不能假設這些實作適合生產環境的高併發。另外，它依賴 LangGraph，這表示升級 LangGraph 版本可能破壞你的實作，你需要追蹤相依性。還有一個實際問題：17 項 benchmark 任務的定義沒有在 README 展開，你必須去 docs/benchmarks.md 看細節。若你的任務類型不在那 17 項之內，排行榜的比較對你參考價值有限。最後，雖然有 283 個測試，但測試通過不代表每個架構在所有 LLM 提供者上都表現一致，因為不同模型的輸出品質差異很大。

替代方案與不同取徑

最直接的替代方案是直接使用 LangGraph 或 LangChain 的生態系，自己組合狀態機。這個專案本身就是建在 LangGraph 上，所以它其實是 LangGraph 的上層封裝。差異在於：LangGraph 給你的是積木，你得自己設計每個節點與邊；而這個專案給你的是已經組好的模式，例如 Reflexion 或 LATS，你只要填入 LLM 與參數。另一類替代是像 smolagents 或 microsoft/autogen 這類代理框架，它們各有自己的抽象，但通常專注於工具使用與多代理協作，而不是涵蓋這麼多文獻中的模式。若要比較，你該問的是：你需要的是「模式庫」還是「應用框架」？若你只是想要某個特定模式，例如 GraphRAG，直接看微軟的 GraphRAG 專案可能更深入，因為它專注單一模式，文件與最佳化更完整。而這個專案的價值在於橫向比較，不是縱向深度。

維護成本與授權考量

授權是 MIT，這對商業使用相對友善，你可以自由修改與整合，只需保留版權聲明。最後一次推送是 2026 年 6 月，最近一次釋出是 v0.3.0，日期為 2026 年 5 月，顯示專案仍在活躍開發。但活躍開發也代表 API 可能變動，特別是在 0.x 版本階段，語意化版本（semver）的 minor 版本可能引入破壞性變更。README 提供的測試套件是緩衝，你可以在升級後執行 pytest -q 來驗證相容性。維護成本主要來自兩方面：一是追蹤上游 LangGraph 的更新，因為所有架構都依賴它；二是 LLM 提供者的 API 變動，例如某個提供者改變了回應格式，可能影響 get_llm() 的實作。對於只想學習的人，成本是閱讀 35 份筆記本的時間；對於想整合的人，成本是理解統一介面背後的抽象層是否夠透明。整體而言，MIT 授權降低了法律風險，但活躍的 0.x 版本要求你必須有升級測試的習慣。

編輯結論

若你正在比較 Reflexion、LATS、GraphRAG 或 MemGPT 等代理模式，且希望以同一套 .run(task) 介面快速切換、並以已執行的筆記本作為學習素材，這個函式庫值得採用。它不適合需要高度客製化狀態機、或想完全繞過 LangGraph 的團隊，因為所有架構都建在 LangGraph 之上。也不要期待它是效能最佳化的生產框架，README 強調的是「production-grade」的程式碼品質與測試覆蓋，而非吞吐量。採用前，請先確認你接受的 LLM 提供者（例如 Nebius、OpenAI、Anthropic）是否在你的環境可用，並以 pytest -q 跑過 283 個測試，確認你的依賴版本與 Python 環境相容。最後，檢視 docs/benchmarks.md 的排行榜，確認你關心的任務類型有被覆蓋，因為 17 項任務的定義直接影響你對架構比較的解讀。

官方來源

1. FareedKhan-dev/all-agentic-architectures on GitHub
2. License: MIT
3. Project website
4. README
5. Releases