LLM編排框架對比：LangChain vs. LlamaIndex vs. 原始API呼叫

隨著LLM應用從原型走向生產，開發者面臨一個關鍵架構決策：是使用LangChain、LlamaIndex還是直接使用原始API呼叫？這三種方法服務於不同的抽象層次，選擇錯誤可能在數月後導致生產系統難以維護。

LangChain 是一個通用編排框架，始於2022年10月，擁有119K GitHub星標和500+整合。其核心能力是組合多步驟操作，包括提示模板、模型呼叫、輸出解析、記憶和工具使用。最新版本LangGraph（v1.0，2025年10月穩定）支援有狀態、基於圖的代理工作流，具備持久化能力（SQLite/PostgreSQL/Redis），允許代理暫停並在數小時後恢復。這使其在複雜代理場景中極具價值。然而，LangChain引入約10ms（LangGraph約14ms）的每步驟框架開銷，對於高吞吐量管道可能累積。此外，其堆疊跟蹤可能深達40層，除錯困難。有對比發現，在簡單RAG管道中，LangChain的成本比原生實現高出2.7倍，源於不必要的令牌消耗。LangChain v1.0承諾API穩定性，但早期版本（v0.1-v0.3）經歷了多次破壞性遷移，對現有專案構成遷移成本。

LlamaIndex（44K星標，300+資料聯結器）專注於資料層：攝入、分塊、嵌入、索引和檢索。它使LLM能夠使用者自有資料進行推理，而非編排步驟。其設計圍繞提高檢索精度和效率，特別適合需要強大RAG的應用。LlamaIndex的優勢在於其豐富的聯結器（Notion、Google Drive、Slack、PDF、資料庫等）和針對檢索最佳化的演算法，但它在多步驟工作流和代理方面的靈活性不及LangChain。

原始API呼叫 指直接使用OpenAI、Anthropic等SDK，無額外編排層。這並非原始回退，而是生產團隊在框架複雜性不再物有所值時日益迴歸的方法。它提供最小抽象、完全控制、零框架開銷和清晰的除錯路徑。對於簡單查詢或流水線，它通常更便宜、更快速。然而，它缺乏內建的記憶、工具使用或RAG支援，需要團隊自己構建這些功能，增加了開發初期的工作量。

決策框架 建議根據專案需求選擇：如果構建多步驟工作流、代理或需要狀態持久化，考慮LangChain/LangGraph；如果主要需求是RAG或資料檢索，LlamaIndex更合適；如果應用使用場景簡單、追求高效能或最小化成本，原始API呼叫是最佳起點。許多生產系統組合使用兩者，例如用LlamaIndex提供檢索資料，用LangChain編排後續步驟。

在選擇抽象層級時，務必考慮長期成本。隨著LLM API支出從2024年底的35億美元增長到2025年中的84億美元，框架開銷直接影響預算和系統可靠性。理解每個選項的實際權衡，避免為不需要的抽象付費，是構建健壯LLM應用的關鍵。