每日突破性工具推薦｜Haystack 3.4.0

研究日期：2026-10-16（Asia/Taipei）｜領域：Python、AI Agent、RAG、Context Engineering｜推薦類型：近期重大更新／代表性工具（fallback）

一、工具定位與適用情境

Haystack 是 deepset 維護、採 Apache-2.0 授權的開源 Python AI 應用編排框架。它將文件擷取、清理、索引、檢索、重排序、提示組裝、模型呼叫與 Agent 工具執行拆成可連接的元件，適合企業知識庫、RAG 問答、文件處理、語意搜尋與需要可追蹤控制流程的 AI Agent。

本次關注版本為 3.4.0 正式版，於 2026-10-15 發布。它不是新成立的專案；本次依 fallback 原則，挑選近期有具體架構進展、活躍維護且具代表性的成熟框架，而非以新穎名稱取代技術價值。

二、突破性重點：讓 Agent 的長期工具結果可回收，而非直接丟棄

3.4.0 的關鍵新增是實驗性 ToolResultOffloadCompactor。長時間執行的 Agent 會累積網頁內容、資料庫查詢、檔案與工具輸出；若全部塞進 LLM context，成本、延遲與上下文上限會持續增加。常見做法是裁剪舊訊息或摘要，但原始證據可能因此遺失。

Haystack 改以**延後卸載（lazy offloading）**處理：當 CompactionHook 判定 context 使用量達門檻，才把較舊的工具結果寫入 ToolResultStore，在對話中留下引用；Agent 若真的需要原文，再透過授權的讀取工具按需取回。較新的工具結果暫時留在 context，因此短任務不必預先支付卸載成本。

這項能力的真正價值是將「對話 token 記憶體」與「外部可回讀的工具證據」分離；不是無限上下文，也不是保證降低每次執行成本。新功能仍標為 experimental，須自行測試回讀與權限邊界。

三、核心架構與運作方式

text

輸入／文件來源
  ↓
Haystack Pipeline：Converter → Retriever → Ranker → Prompt Builder
  ↓
Agent：LLM ↔ Tool / Toolset ↔ State
  ↓ 每次 LLM 呼叫前
before_llm：CompactionHook（估算 context、檢查門檻）
  ├─ 未達門檻 → 保留原訊息，正常呼叫 LLM
  └─ 達門檻 → ToolResultOffloadCompactor
                    ├─ 舊工具結果 → ToolResultStore（例如檔案系統）
                    └─ 對話內容 → 小型引用／指標
                                         ↓
                           需要原文時呼叫受限讀取工具
                                         ↓
                                  回讀指定結果

Pipeline 負責以元件與連線定義資料流；Agent 以模型與工具迴圈處理非固定步驟，並提供 hooks、執行狀態、步數、token 使用量與退出原因等可觀測資訊。CompactionHook 屬於 Agent 的 before_llm 階段；既有 ToolResultOffloadHook 則是在 after_tool 階段對剛產生的結果按策略卸載，兩者觸發時機不同。

四、3.4.0 其他值得注意的更新

Python 支援調整：新增 Python 3.15 支援，最低版本提升為 Python 3.11；Python 3.10 專案需先升級執行環境。
元件屬性存取最佳化：移除無效的 Sockets.getattribute 路徑；官方指出特定 socket 屬性存取微基準約快 14 倍。這不是整體 RAG／Agent 速度提升 14 倍。
資料品質修正：修正 RecursiveDocumentSplitter 的頁碼、重疊區間與空白字元處理；依賴舊切塊行為的索引可能需要重建。
Embedding 預設模型變更：部分 OpenAI／Azure Embedder 預設改為 text-embedding-3-small；既有向量索引不可與不同模型產生的向量直接混用，升級時應明確鎖定模型或重建索引。
容錯與追蹤：工具結果儲存失敗時會保留原始結果並記錄警告，避免因卸載失敗直接中斷 Agent；工具失敗的 tracing 標記也更明確。

五、主要優勢

上下文工程可控：檢索、排序、工具、訊息壓縮與回讀策略可以在同一 Python 工作流內組裝。
保留原始證據：相較直接摘要或刪除工具輸出，卸載後仍有機會按需取得完整內容，適合需追溯引用的 Agent。
模組化與模型中立：可以替換 Document Store、Retriever、Generator 與工具整合，不必把整套應用綁死單一 LLM 供應商。
同步／非同步與監控能力：支援 Pipeline 與 Agent 執行控制、hooks、狀態與使用量追蹤，較適合持續演進的正式系統。

六、與同類工具比較

工具	主要強項	相對 Haystack 3.4.0 的取捨
Haystack 3.4.0	模組化 RAG + Agent + 明確的 context 管理	需要設計 Pipeline、Store 與 Hook 策略
LangGraph	以狀態圖描述長期、可中斷與可恢復的 Agent 流程	複雜狀態編排較直接；Haystack 在檢索元件組合與文件管線較一體化
LlamaIndex	資料連接、索引與知識檢索生態	知識資料整合選項豐富；Haystack 的 Pipeline/Agent hooks 提供另一種顯式控制方式
CrewAI	以角色與任務快速建立多 Agent 協作	團隊式抽象更容易上手；Haystack 更偏底層檢索、工具與資料流工程

上述為架構定位比較，不代表官方效能排行，也不代表競品完全缺少相同能力。

七、缺點、限制與升級風險

新 Compactor 仍屬實驗性：API、序列化格式與實際可靠度需要在目標版本驗證，不宜無測試直接套用關鍵業務。
卸載並非免費：引入儲存 I/O、持久化、清理與回讀延遲；若 Agent 反覆回讀，token 成本未必降低。
資料安全需額外設計：Store 中可能包含機密文件或工具輸出，必須限制路徑、讀取權限、保留期限與跨租戶存取；不可把任意檔案路徑暴露為通用讀取權限。
模型 context 估算存在誤差：Hook 使用模型回報與本地估算，仍須預留輸出 token、工具 schema 與峰值結果空間。
升級相容性：Python 3.10 不再支援；切塊頁碼、文件內容與 Embedding 預設變更可能要求重新索引或顯式設定。
框架本身不是模型服務：實際 LLM 推論費用、API Key、向量資料庫與生產部署仍需自行配置。

八、適合與不適合的使用者／專案

適合：已有 Python 後端、需要可審核 RAG 的團隊；會讀取大量文件或多次呼叫工具的研究 Agent；需要明確控制檢索、回讀、成本與資料生命週期的企業應用。

不適合：只需一次 LLM API 呼叫的輕量產品；純前端 TypeScript 團隊且不想維護 Python 服務；完全不需要原始工具結果回讀的短流程；不願承擔實驗性 API 風險的嚴格穩定系統。

九、結論

推薦理由：Haystack 3.4.0 把 Agent context 壓縮從「刪除／摘要」推進到「按門檻卸載、保留可回讀證據」的工程模型。 這對高頻工具呼叫、長期任務與企業 RAG 的實際成本和可追溯性都具有架構意義。建議先在非正式環境比較原始 token 使用量、回讀成功率、儲存 I/O、回應延遲與答案品質，再決定是否採用實驗性 Compactor。