就目前調研下來的功能來説。開發AI智能體，入門選langchain沒錯，架構很成熟，能力很強，基本上所有的場景都可以覆蓋，可以很好管理起大型的AI應用架構。而且js、java、python各種語言都支持。

上手很快，但是用好的話還是多花些時間學習他的底層實現邏輯。

這篇文檔，會介紹一下AI應用開發的一些基礎知識。

• 連接模型
• MCP的介紹以及如何實現MCP客户端、服務端
• 工具調用
• 智能架構分析
• langchain的介紹以及幾種應用模式
• LangGraph原理分析

這篇僅僅是一個入門引導，告訴你所用到的基礎知識，每一模塊需要你自己再去深入研究學習。

1. 連接大模型

這個比較好理解，就是通過API接口調用大模型服務。

1.1 使用接口連接大模型

模型就是一個在線的服務。可以通過API接口，用http調用模型。

官方文檔：https://platform.openai.com/docs/api-reference/introduction

幾個重要的參數：

• model 模型
• prompt 提示詞
• input 用户輸入
• temperature 温度，範圍在0到2之間。越大輸出內容的隨機性越高。
• tools 工具，支持工具調用的模型可以傳此參數，讓模型選擇需要執行的工具。
• max_tool_calls 最大工具調用次數，一次響應中可處理的對內置工具的總調用次數上限。此最大次數適用於所有內置工具調用的總和

請求案例：

輸出內容：

如果有工具調用，會輸出tool_calls，內容是需要調用的工具以及參數：

1.2 官方封裝的SDK

OpenAI官方封窗的SDK，可以簡化調用步驟。也有的平台自己封裝了一層，例如ollama，會有一些參數的差異。

https://platform.openai.com/docs/libraries?language=javascript

langchain也有專門的llm包。主流的模型基本都支持。

文檔地址：https://docs.langchain.com/oss/javascript/integrations/llms

2. 理解工具調用

工具調用是應用程序與模型之間的多輪對話：

流程：

1. 定義工具（函數）
2. 告訴 LLM 有哪些工具可用
3. 用户提問
4. LLM 決定是否調用工具
5. 執行工具並返回結果
6. LLM 基於結果生成最終答案

工具調用最重要的2步就是

• 定義工具
• 根據模型相應結果，執行工具

這就是如何把工具的定義和執行，獨立管理起來。並使用一個協議通用化，讓所有的大模型都可以調用，這就是的MCP協議誕生。

用代碼演示一下：這裏是放了幾個關鍵的代碼。

3. 理解MCP協議

大模型的工具調用，使用JSON Schema 來定義參數結構，告訴大模型，有哪些工具使用，模型會根據用户的意圖選擇合適的工具調用。

MCP是一個模型上下文協議。顧名思義，它只是一個協議。類似Http協議一樣。是一個通信規則。大家都遵守這個規則，這樣每個人開發的工具，只要遵守這個協議，大家都能使用。極大的加速生態的發展。

藉助MCP，模型可以連接數據源（例如本地文件、數據庫）、工具（搜索引擎、計算器）和工作流（例如專用提示詞），從而使它們能夠獲取關鍵信息並執行任務。

MCP的官方文檔：https://modelcontextprotocol.io/docs/getting-started/intro

3.1 MCP又分為客户端和服務端。

• 服務端:负責提供能力，如搜索、數據庫訪問或執行命令；
• 客户端:负責連接模型與這些服務端，實現上下文擴展與工具調用。

如果用上面的工具調用對比

• 服務端提供工具的定義+工具的實際執行。
• 客户端負責將工具的傳遞給模型，執行工具的調用

3.2 MCP SDK

MCP也有SDK，提供核心功能和全面的協議支持

這是官方提供的開發工具包：https://modelcontextprotocol.io/docs/sdk

3.3 簡易的MCP服務端

引入SDK -> 創建服務實例 -> 註冊資源/工具 -> 連接到通信器

安裝，引入SDK，創建服務實例

註冊工具：

將 MCP 服務器連接到 Streamable HTTP 傳輸。

3.4 簡易的MCP客户端

引入並新建客户端

通過StreamableHTTPClientTransport連接到服務器，實現和服務的通信。

獲取可用工具列表

4. 構建智能體Agent

4.1 什麼是 Agent 框架？

Agent 框架（Agent Framework）

 是讓 LLM 擁有「目標理解、規劃、行動、記憶」能力的結構化系統。

它把原本“問答式”的語言模型，變成能自動決策、執行工具、管理任務的智能體。

“語言模型 + 記憶 + 工具 + 調度 = 智能體（Agent）”

4.2  Agent 框架設計模式（常見架構）

4.2.1 RAG模式 (Retrieval-Augmented Generation)

檢索增強生成

核心思想： 解決了 LLM 無法獲知“私有數據”和“實時數據”的痛點。它是一種特殊的“工具使用”，這個工具就是“搜索引擎”或“向量數據庫”。

工作流程：

1.索引 (Index): （離線）將你的私有文檔（PDF, MarkDown...）切片、向量化，並存入向量數據庫。

2.檢索 (Retrieve): （在線）當用户提問時，系統首先將用户的問題向量化，去數據庫中檢索出最相關的“上下文”片段。

3.增強 (Augment): 系統將這些“上下文”片段拼接到原始提示詞（Prompt）中，形成一個“增強提示詞”。

4.生成 (Generate): 將這個“增強提示詞”發給 LLM，並明確指示：“請根據我提供的上下文來回答問題”。

應用框架：LlamaIndex 是圍繞此模式構建的；LangChain 和 Spring AI 都有強大的 RAG 模塊。

4.2.2 ReAct 模式（Reason-Act Loop）

Agent 框架最基本、最核心的運行循環。它認為 LLM 不能一步到位解決問題，而是需要像人一樣“邊想邊做”，在“思考”和“行動”之間迭代，直到問題解決。

工作流程：

1.Reason (思考): 用户提出問題（Task）。LLM 進行“思考”，分析現狀和目標，決定下一步是回答還是行動。

2.Act (行動): 如果 LLM 決定行動，它會選擇一個“工具”（Tool）並生成調用該工具所需的參數。

3.Observe (觀察): 系統執行工具（如調用 API、查詢數據庫），並獲得一個“觀察結果”（Observation）。

4.Repeat (循環): LLM 接收這個“觀察結果”，進入下一次“思考”循環，評估新信息，並決定下一步動作。

5.Final Answer (終止): 當 LLM 認為所有信息都已足夠，它會生成最終答案，循環結束。

應用框架： 幾乎所有 Agent 框架（LangChain, LlamaIndex, Spring AI）的默認 Agent 邏輯都是基於 ReAct 模式的。

4.2.3  Plan-and-Execute 計劃-執行 模式

與 ReAct 的“走一步看一步”不同，此模式主張“謀定而後動”。它將“規劃”和“執行”徹底分離。

工作流程：

1. 規劃 (Planning): 首先，一個專門的“規劃者” Agent（或是一個特定的提示）會根據用户最終目標，生成一個完整的、多步驟的計劃（A plan）。
2. 執行 (Executing): 然後，一個或多個“執行者” Agent 會嚴格按照這個計劃，一步一步地執行，不再（或很少）返回“規劃者”那裏修改計劃。

與 ReAct 的對比：

• ReAct： 適合探索性、需要實時反饋的任務（如“幫我查資料”）。
• Plan-and-Execute： 適合目標明確、步驟固定的任務（如“幫我寫一份市場分析報告，包含A、B、C三個部分”）。

✅ 優點：結構清晰，適合長任務

 ⚠️ 缺點：計劃可能不夠靈活

框架：

• LangChain (Python/JS): 提供了 PlanAndExecute Agent Executor

4.2.4  Multi-Agent 調度模式

多個 Agent 各司其職，由調度器協調：

• Planner：規劃任務
• Worker：執行工具調用
• Reviewer：檢查結果並反饋

類似「公司分工結構」，CrewAI、OpenDevin 就是這種模式。

4.2.5 圖（Graph）與狀態機模式 (Graph / State Machine)

ReAct 模式的終極進化。ReAct 是一個簡單的“循環”，但在複雜任務中，我們需要的不是“循環”，而是有向圖（Graph）。

工作流程：

1. 定義節點 (Nodes)： 你將 Agent 的不同“能力”定義為圖上的“節點”（Node）。例如：“工具調用”是一個節點，“RAG”是一個節點，“人類輸入”是一個節點，“生成最終答案”是另一個節點。
2. 定義邊 (Edges)： 你定義節點之間的“邊”（Edge），即路由邏輯。
3. 路由邏輯 (Routing)： 關鍵在於，這個“路由邏輯”可以是動態的。你可以讓 LLM 在每一步執行後，決定下一步應該“跳轉”到哪個節點。

應用框架： 這是 LangGraph (LangChain 的子項目) 的核心模式。它允許你用代碼顯式地定義 Agent 的“心智流圖”，使 Agent 的行為極其可控且易於調試。例如，你可以定義一個規則：“如果工具調用失敗3次，則自動跳轉到‘請求人類幫助’節點”。

4.3 常見 Agent 框架對比以及選擇

如何選擇：如果你不確定，從 LangChain 開始。

• 它是事實上的行業標準，學習它的概念（ReAct, Tools, Memory）對你理解所有其他框架都有幫助。先用它構建一個單 Agent。

如果你的核心是 RAG，從 LlamaIndex 開始。

• 它在處理數據方面是最好的，能讓你快速構建出基於私有知識的智能體。

當你發現“單 Agent 搞不定”，再轉向多 Agent。

• 當一個任務過於複雜，一個 Agent 總是“想不清楚”時，就是引入多 Agent 的時機。
• 用 CrewAI 開始實驗，它的結構化方法能幫你理清思路。
• 在 CrewAI 遇到瓶頸時（如需要更靈活的 Agent 間通信），再去研究 AutoGen。

5. langchain

LangChain 是一個用於 構建基於大語言模型應用的開發框架。

它的核心目標是

讓開發者更容易地將大模型與外部數據、邏輯流程、工具系統結合，構建出可交互、可調用的智能體（Agent）。

簡單來説，LangChain = LLM + 數據 + 工具 + 記憶 + 推理流程。

LangChain底層是基於LangGraph，一個專注於智能體的編排管理的底層框架。

5.1  什麼是 LangChain？能做什麼？原理是什麼？邊界在哪裏？

LangChain 是一個讓 AI 模型（如 GPT-4、Claude）能夠使用工具、訪問數據、記住對話的開發框架。

❌ 普通 AI：就像一個只會説話的顧問

- 只能回答問題

- 沒有工具

- 沒有記憶

✅ LangChain + AI：就像一個有助手團隊的超級顧問

- 可以搜索網絡 🔍

- 可以查數據庫 📊

- 可以寫代碼並執行 💻

- 可以記住之前的對話 🧠

- 可以調用其他專家 AI 👥

5.2  LangChain 能做什麼？

1️⃣ 讓 AI 使用工具（Tool Calling）

能做的事情：

• 🔍 搜索互聯網
• 📧 發送郵件
• 📅 操作日曆
• 💾 查詢數據庫
• 🧮 執行計算
• 📝 讀寫文件
• 🎨 生成圖片
• 🔊 語音合成
• ...任何你能想到的 API 調用

***

2️⃣ 管理複雜對話流程（Agents & Workflows）

核心能力：

• 🔄 ReAct 循環 ：思考 → 行動 → 觀察 → 重複
• 📋 任務規劃 ：自動分解複雜任務
• 🎯 目標導向 ：持續執行直到完成
• 🔀 條件分支 ：根據結果選擇不同路徑

***

3️⃣ 記憶管理（Memory）

記憶類型：

• 💬 *\對話歷史\*：記住所有聊天內容
• 📝 *\長期記憶\*：跨會話保存用户信息
• 🧠 *\語義記憶\*：向量存儲，智能檢索相關信息
• 📊 *\狀態管理\*：保存任務進度、變量等

***

4️⃣ 連接數據源（RAG - 檢索增強生成）

應用場景：

• 📚 企業知識庫問答
• 📄 文檔分析
• 🔍 智能搜索
• 📖 代碼庫問答

***

5️⃣ 多 Agent 協作（Multi-Agent Systems）

6. LangGraph

langchain就是基於LangGraph構建的。

LangGraph 是 LangChain 體系中一個功能強大的庫，它專門用於構建有狀態、可循環、可控制的 AI 應用，特別是複雜的 Agent（智能體）。

理解 LangGraph 原理的核心在於，它把 Agent 的工作流程從一個簡單的“線性鏈條”升級為了一個“圖（Graph）”。LangGraph像一個流程圖。它可以有分支（如果A，則B；否則C），也可以有循環（執行A，然後檢查B，如果不滿足條件，就重新執行A）。

這種圖結構對於構建能思考、能修正、能與人交互的複雜 Agent 至關重要。

6.1 LangGraph 的三大核心原理

LangGraph 的工作原理主要建立在三個基本概念之上：狀態（State）、節點（Nodes） 和 邊（Edges）。

6.1.1 📈 狀態 (State)：Agent 的“記憶”

狀態是 LangGraph 的核心。它是一個共享的數據結構，在整個圖的運行過程中持續存在並被傳遞。

• 作用：它扮演着 Agent 的“短期記憶”和“工作區”。
• 如何工作：每個節點在執行時都會讀取當前的狀態，執行完任務後，更新這個狀態，然後將更新後的狀態傳遞給下一個節點。
• 示例：狀態可以包含 {"messages": [...], "current_task": "...", "tool_output": "..."}。一個節點讀取 messages，另一個節點添加 tool_output。

6.1.2 ⚙️ 節點 (Nodes)：Agent 的“執行者”

節點是圖中的“工作單元”或“行動者”。它們是實際執行任務的組件。

• 作用：一個節點就是一個 Python 函數或 LangChain 的 Runnable（如一個 LLM 調用、一個工具執行）。它負責處理一項具體工作。
• 如何工作：節點接收當前的狀態作為輸入，執行其邏輯（例如，調用 LLM 進行思考、調用工具獲取信息），然後返回一個狀態更新（一個字典，包含要更改或添加的數據）。
• 示例：
• 一個 agent 節點：調用 LLM 判斷下一步該做什麼。
• 一個 action 節點：根據 LLM 的決定，執行一個工具（如搜索）。
• 一個 updater 節點：將工具的執行結果添加到消息歷史中。

6.1.3 ↔️ 邊 (Edges)：Agent 的“決策邏輯”

邊是圖中的“連接器”和“決策者”。它們定義了節點之間的流程和方向，決定了在當前節點完成後，接下來應該去哪個節點。

• 作用：邊控制着整個 Agent 的邏輯流。
• 如何工作：LangGraph 中有兩種主要的邊：
• 常規邊 (Normal Edges)：這是簡單的、固定的連接。例如，add_edge("node_A", "node_B") 意味着在 node_A 完成後，總是去執行 node_B。
• 條件邊 (Conditional Edges)：這是 LangGraph 最強大的功能。它是一個函數，會檢查當前的“狀態”，並根據狀態中的信息動態決定下一步去哪裏。

6.2 示例：一個 Agent 的工作流程

假設我們要構建一個“能使用工具的AI助手”，它的工作流程如下：

6.2.1 定義狀態 (State)：

messages: 聊天曆史列表。

6.2.2 定義節點 (Nodes)：

call_model：調用 LLM。輸入是 messages，輸出是 LLM 的回覆。

call_tool：執行工具。輸入是 LLM 回覆中的工具調用請求，輸出是工具的運行結果。

6.2.3 定義邊 (Edges)：

1.入口：設置 call_model 為起始節點.

2.條件邊 (核心邏輯)：在 call_model 之後，添加一個名為 should_continue 的條件邊。這個“邊函數”會檢查 call_model 節點輸出的 LLM 回覆：

• 如果 LLM 只是正常回復（沒有請求工具）：流程結束，將回復返回給用户。
• 如果 LLM 請求調用工具（例如搜索）：流程轉向 call_tool 節點。

3.常規邊：在 call_tool 之後，添加一條常規邊，循環回 call_model 節點。這樣，Agent 就能帶着工具的運行結果再去調用 LLM，讓 LLM 根據新信息進行下一步思考。

這個流程就實現了一個“思考 -> 行動 -> 觀察 -> 再思考”的循環，這是所有高級 Agent 的基礎。下面一個LangGraph示例核心代碼：