tryAGI/LangChain：把 LangChain 的抽象搬進 .NET，代價與邊界在哪裡
C# implementation of LangChain. We try to be as close to the original as possible in terms of abstractions, but are open to new entities.
秒懂
- 它是什麼？
- 這是一個以 C# 重寫 LangChain 抽象的專案，套件名為 LangChain，走 MIT 授權。它的價值在於把檢索、提示模板、鏈式組合這套流程帶進 .NET，但維護者自己在 README 裡就說明了單靠他一人難以推進。
- 適合誰用？
- 如果你已經在 .NET 生態裡，需要 RAG 流程的現成抽象（文件載入、切分、向量檢索、提示模板、鏈式組合），而且能接受把 LangChain 這個套件名稱加進相依清單，這個專案值得先花半天跑通 README 那段 Harry Potter PDF 範例再決定。反之，如果你的團隊已經深度使用 Semantic Kernel，或需要企業級支援承諾與穩定的發版節奏，就不要為了抽象層而多引入一套相依。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 4 天前。
- 用什麼語言寫的？
- 主要是 C#（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是 .NET 缺少 LangChain 式抽象這件事
README 開頭把定位寫得很直白：C# implementation of LangChain，並且說「我們盡量在抽象上貼近原版，但對新實體保持開放」。這句話同時交代了目標讀者與方法論。目標讀者是寫 C# 的人，他們看過 Python 那邊的 LangChain 範例，想在同一套概念下做檢索增強生成，而不是自己從 HttpClient 開始拼裝。
專案對 Semantic Kernel 的態度也寫在 README 裡：它有用，而且這個專案會在可能的地方使用它，但 Semantic Kernel 沒有覆蓋所有情境，而且與 Microsoft 生態綁得比較緊。所以這裡的差異不是「誰比較好」，而是覆蓋範圍與生態歸屬。你如果只是要呼叫一個聊天模型，兩邊都能做；你如果要把 PDF 載入、切塊、寫進向量資料庫、再組合成一條可重複執行的鏈，這個專案提供的是現成的組合件。
需要提醒的是，README 的維護者筆記語氣相當坦白：維護者說自己一個人不太可能做出重大進展，目標是聯合 C# 開發者的力量，並承諾盡量在 24 小時內接受 Pull Request。這段話是理解整個專案風險輪廓的關鍵，它不是一份企業產品的路線圖，而是一個希望聚集貢獻者的開源專案。
從 PDF 到答案：資料流經過哪些具體環節
README 給的範例把整條資料流攤開來看，這比任何架構圖都清楚。第一步是建立 provider 與模型物件：OpenAiProvider 讀取環境變數 OPENAI_API_KEY，接著實例化 OpenAiLatestFastChatModel 與 TextEmbeddingV3SmallModel，前者負責生成，後者負責把文字轉成向量。
第二步是向量資料庫。範例用 SqLiteVectorDatabase(dataSource: "vectors.db") 建出一個本機檔案資料庫，再呼叫 AddDocumentsFromAsync<PdfPigPdfLoader>，把 PDF 的 URL 交給 DataSource.FromUrl，並指定 dimensions: 1536。這裡有個容易踩到的細節：註解明講 TextEmbeddingV3SmallModel 的維度必須是 1536，寫錯的話向量寫進去也查不出正確結果。textSplitter 參數傳 null 時，預設是 CharacterTextSplitter(ChunkSize = 4000, ChunkOverlap = 200)，也就是按字元切、每塊 4000、重疊 200。
第三步是檢索與生成。GetSimilarDocuments 拿問題去換回五份最相似的文件，再把它們塞進提示模板交給 llm.GenerateAsync。範例裡的提示詞要求模型只根據上下文回答，答不出來就說不知道。README 也示範了第二條路：用 Set、RetrieveSimilarDocuments、CombineDocuments、Template、LLM 這幾個運算子以 | 串成一條 chain，最後用 chain.RunAsync("text") 取結果。兩種寫法做的事一樣，差別在於鏈式版本把每個步驟變成可替換的節點，除錯時可以用 llm.UseConsoleForDebug() 把中間過程印出來。
安裝與啟動：套件、環境變數、關鍵參數
取得方式走 NuGet，套件識別碼是 LangChain，README 的徽章連到 nuget.org/packages/LangChain 的預覽版本頁面。範例註解列出這條路徑需要三個套件：LangChain、LangChain.Databases.Sqlite、LangChain.DocumentLoaders.Pdf。也就是說核心抽象與資料庫、文件載入器是分開的套件，你不需要為了一個 SQLite 向量庫把整包相依都拉進來。
執行的前置條件是環境變數 OPENAI_API_KEY。範例的寫法是讀不到就丟 InconclusiveException，這個例外型別通常出現在測試框架裡，暗示這段程式碼原本是測試而不是文件。
幾個必須記住的設定值：dimensions 要對齊嵌入模型的輸出維度，TextEmbeddingV3SmallModel 是 1536；collectionName 可以省略，但當你要在同一個資料庫放多個集合時就得給；textSplitter 傳 null 會套用預設切塊策略。另外 README 提到，如果 wiki 上的程式碼過期，可以去看 src/Meta/test/WikiTests.cs，那裡有對應的測試，examples 目錄與 src/tests/LangChain.IntegrationTests/ReadmeTests.cs 也是可參考的來源。這種「文件即測試」的安排，至少讓範例不會無聲腐爛。
維度、切塊與成本：幾個容易被忽略的約束
範例註解裡留了一組價格數字：從零開始跑（建立嵌入並呼叫 LLM）是 0.015 美元，資料庫已存在時重跑是 0.0004 美元。這兩個數字來自專案自己的註解，不是第三方基準，但它點出了一個實際的設計後果：第一次建立向量索引是昂貴且耗時的一步，重複查詢則便宜得多。這也解釋了為什麼範例選擇把向量寫進本機 SQLite 檔案，而不是每次啟動重算。
維度是硬約束。1536 這個數字和模型綁死，換嵌入模型就得重建整個集合，不能只改參數。切塊策略同理，ChunkSize 4000 與 ChunkOverlap 200 是預設值，對長篇小說這種連續敘事或許還行，但對結構化的技術文件或程式碼，按字元切的預設值很可能把一個完整的段落或函式切成兩半，而 ChunkOverlap 只有 200 字元，補不回被切斷的語意。
還有一個容易低估的成本：提示詞裡塞進五份文件，每次呼叫的 token 量會明顯放大。範例的問題「誰喝了獨角獸的血」只需要一句話回答，卻附上五份上下文。檢索數量 amount 是可以調的，但調小會影響召回，調大則直接反映在帳單上，這個取捨在 README 裡沒有給建議。
與 Semantic Kernel 的差異不只是 API 形狀
README 主動拿 Semantic Kernel 做對照，這在開源專案裡不算常見，也讓替代方案的討論有具體依據。兩者的分歧點在於生態歸屬與覆蓋範圍：Semantic Kernel 由 Microsoft 維護，與 Microsoft 生態緊密整合；這個專案則明說自己願意使用第三方函式庫，目標是提供「最廣泛的實用實作選擇」。
反映在 API 上就是鏈式組合那一段。Set、RetrieveSimilarDocuments、CombineDocuments、Template、LLM 用 | 串起來，這套寫法直接對應 Python LangChain 的 LCEL 風格，對照過 Python 文件的人幾乎不用重新學。Semantic Kernel 走的是 plugin 與 planner 的路線，概念模型不同。如果你團隊的既有程式碼已經圍繞 Semantic Kernel 的 kernel 物件與 plugin 註冊建立起來，把檢索流程換成這裡的 chain，等於在同一個服務裡維護兩套抽象。
反過來說，如果你需要的是與 ASP.NET Core、Azure 服務、Microsoft.Extensions 相依注入的深度整合，Semantic Kernel 的生態位階是這個專案短期內追不上的。選擇的關鍵不在功能清單，而在你的程式碼庫已經被哪一套概念滲透得多深。
維護節奏與授權：採用前該看清的兩件事
README 列出的近期版本是 v0.15.0（2024-06-27）、v0.14.0（2024-05-03）、v0.13.0（2024-03-06），大約一到兩個月一個版號，而且全部是 0.x。0.x 版號在語意化版本慣例下意味著 API 沒有穩定承諾，次要版號就可能帶來破壞性變更。對照 repo 的 last push 時間，主分支的活動比發版節奏更頻繁，這代表 main 上可能有尚未進入正式版的內容。
維護者筆記裡那句「我一個人不太可能做出重大進展」，加上公開徵求核心團隊成員、承諾贊助與分潤，說明這個專案在人力上是有缺口的。這不是缺點陳述，而是採用時必須納入的風險評估：如果你的產品依賴它，你得有能力在必要時自己修，或至少讀得懂 src 底下的實作。
授權是 MIT，README 明確表示在可預見的未來沒有變更授權的計畫，但同一組織內以它為基礎的專案可能有不同授權。這裡的界線在於「這個 repo」與「同一組織的其他專案」不是同一件事，如果你要引用的是組織內其他專案，得個別確認。以上是對條文的描述，不構成法律意見，商用前請自行或請法務確認。
什麼情況下它會是錯的工具
第一種情況是你需要穩定的 API 契約。0.x 版號加上活躍的主分支，意味著升級時要有心理準備改程式碼。如果你的服務有嚴格的變更凍結期，每次升版都要重新驗證整條鏈，這個成本要算進去。
第二種情況是你的檢索需求很單純。如果你只是要對一份固定的內部文件做問答，而且文件不常變，自己寫一段呼叫嵌入 API、存進任何向量庫、查詢時組提示詞的程式碼，可能比引入一整套抽象更省事。這個專案的價值在於組合件的數量與一致性，不在於單一功能。
第三種情況是你需要的模型或向量資料庫在 repo 裡還沒有對應實作。README 說對新實體保持開放，但開放不等於已經有。範例只展示了 OpenAI 與 SQLite 這條路徑，其他 provider 與資料庫的支援程度，得自己去 src 底下確認，不能從 README 推斷。
第四種情況是團隊完全沒有 C# 以外的 LangChain 經驗。這套抽象的命名與組合方式來自 Python 版本，沒有那個背景的人第一次看到 Set | Retrieve | Combine | Template | LLM 這種寫法，學習曲線不會比直接用 Semantic Kernel 平緩。
編輯結論
如果你已經在 .NET 生態裡，需要 RAG 流程的現成抽象（文件載入、切分、向量檢索、提示模板、鏈式組合），而且能接受把 LangChain 這個套件名稱加進相依清單，這個專案值得先花半天跑通 README 那段 Harry Potter PDF 範例再決定。反之，如果你的團隊已經深度使用 Semantic Kernel，或需要企業級支援承諾與穩定的發版節奏，就不要為了抽象層而多引入一套相依。採用前先確認三件事：目標框架版本與套件實際支援的 TFM 是否對得上、你要用的 provider（OpenAI 以外的模型、其他向量資料庫）在 repo 裡是否已有對應實作、以及最近一次發版與 main 分支之間的落差有多大。
社群筆記