嗨，你好，我是維元 👋 我將持續分享我在資料科學與人工智慧領域上觀察的趨勢發展與所見所聞 💥 最近看到 LangChain 發布 1.0 版本，而大量轉向以 Agent 為基底的設計模式，這篇文章想聊聊其中的觀察。
為什麼 LangChain 會從原先的 Chain-based 轉變會 Agent-based 呢？
🧩 一、舊版 Chain 模式：線性思維的極限
LangChain 最早（2022–2023）是圍繞「Chain（鏈式流程）」設計的。這種模式把 LLM 流程拆成明確步驟：
https://www.artefact.com/blog/unleashing-the-power-of-langchain-expression-language-lcel-from-proof-of-concept-to-production/
可以在一個 chain 中加上各種不同的模組，裡例如上網查詢、資料檢索、格式化輸入輸出等等；或透過 SequentialChain、MapReduceChain 等方式組合，適合像「問答、摘要、格式化」這種線性任務。
https://www.linkedin.com/pulse/langchain-bridging-gap-between-language-models-namala-wg7le/
🧱 但這種設計很快遇到三個瓶頸：
1️⃣ 流程固定：一旦設定好 chain，LLM 無法根據情況動態決策（要不要查資料、要不要用工具）。
2️⃣ 缺乏狀態與記憶：每次 chain 執行都是 stateless，跨回合上下文不易保存。
3️⃣ 不適合複雜應用：像客服、資料助理、RAG、業務自動化等場景，需要 decision loop 與多工具調度。
→ 結論：Chain 適合單輪任務，不適合長期互動與智能決策。
🤖 二、新版 Agent 模式：具「行為決策」的 AI 執行者
LangChain 過去使用了 ReAct（Reason + Act）框架來驅動 Agent 的思考與行動。ReAct 機制是一種結合「推理（Reasoning）」與「行動（Action）」的高階提示技術，讓大型語言模型能一邊思考、一邊透過外部工具執行具體操作。這種框架讓 LLM 具備更接近人類的問題解決方式 — — 能在分析與行動之間不斷循環，例如先規劃、再蒐集資料、再根據結果調整策略，形成一個動態的思考與執行迴圈。簡而言之，ReAct 讓 LLM 不只是回答問題，而是像人一樣「思考後行動、行動中學習」的智能體。
https://airbyte.com/data-engineering-resources/using-langchain-react-agents
從 LangChain 0.1 開始，社群逐漸轉向「Agent 架構」思維。Agent 不再只是被呼叫的 Chain，而是擁有主動決策權的 LLM 實體。它可以根據當前目標與上下文，自行選擇要執行的工具或策略，例如：
User: 幫我查一下這週天氣，順便寄一封信提醒會議。
Agent:
→ 調用 weather_api→ 調用 email_tool→ 整理結果回覆
LangChain 把這整個邏輯 內建到新的 create_agent() 與 LangGraph runtime 裡，整合進 Agent 的「推理與決策迴圈」：
# pip install -qU "langchain[anthropic]" to call the model
from langchain.agents import create_agent
def get_weather(city: str) -> str:
"""Get weather for a given city."""
return f"It's always sunny in {city}!"
agent = create_agent(
model="anthropic:claude-sonnet-4-5",
tools=[get_weather],
system_prompt="You are a helpful assistant",
)
# Run the agent
agent.invoke(
{"messages": [{"role": "user", "content": "what is the weather in sf"}]}
)
LangChain 1.0 正式將這套架構標準化：
- 使用新的
create_agent()抽象來取代create_react_agent()。 - Agent 的主循環統一透過 LangGraph runtime 來控制。
- 支援 middleware hooks（例如人機協作、上下文壓縮、敏感資訊遮蔽）。
📍關鍵差別是：
Chain 是流程導向（Process-driven），Agent 是行為導向（Behavior-driven）。
⚙️ 三、設計脈絡：為什麼要全面 Agent 化？
這個設計轉向，來自三個主要考量：
1️⃣ LLM 能力提升 → Chain 變太「死」
LLM（GPT-4、Claude 3）能自主推理、規劃，舊 Chain 模式反而限制了它的靈活性。Agent 架構讓模型自己決定「何時思考、何時調用工具」。
2️⃣ 生產環境需求 → 需要持久化與可觀測性
LangGraph 的出現解決了持久狀態（Durable State）與長任務問題。這對「AI 工作流、自動化任務」是關鍵能力。例如客服 Agent、報告生成、資料審查任務，都可長時間運行。
3️⃣ 開發體驗 → Agent 抽象更貼近應用思維
開發者不必再拼 Chain，而是像在設計一個「AI App」的核心行為邏輯。create_agent() 把模型、工具、記憶整合成一個可重複使用的單位。
🌐 四、總結：Chain 沒死，只是退居底層
LangChain 1.0 並非「捨棄 Chain」，而是把它降級成 Agent 的內部組件：
- Chain = 封裝好的功能模塊（tool function）
- Agent = 負責調度 Chain 的決策者
這樣的分層讓開發更清晰：
Chain 是 function，Agent 是 brain。
LangGraph 是 runtime，讓 brain 能長期運作。
🧠 五、更完善的 LangChain 生態系：從 Chain 到 Deep Agents
隨著 LangChain 1.0 的發佈，整個生態系其實已經不只是「一個開發套件」，而是逐漸演化成 多層次的 AI 開發框架：
https://blog.langchain.com/doubling-down-on-deepagents/
🔹 LangChain：抽象與組件層
負責封裝基礎能力，包括：
- Prompt 模板與 Chain 組合
- 工具（Tools）與函式呼叫整合
- 記憶體（Memory）與回合式上下文管理
👉 適合快速構建模組化的 LLM 功能，如問答、摘要、資料格式轉換。
🔸 LangGraph：執行與控制層
LangGraph 是 LangChain 的進階運行時（runtime），用來支援：
- 狀態管理（State Management）：讓任務可長期執行並中斷重啟
- 決策流程（Decision Loop）：支援 Agent 在不同節點之間動態切換
- 中介層（Middleware）：加入人機協作、內容審查、壓縮與追蹤等功能
👉 它讓 LLM 不只是「單次推理」，而能作為「持續運作的智能體」。
🔺 Deep Agents：應用與系統層
在 LangGraph 之上出現的新一層架構，整合多個子 Agent 與專用工具：
- SubAgent（子代理）間可協作與分工
- 可接入檔案系統、資料庫、外部 API
- 形成具備任務記憶與決策能力的複合 AI 系統
整個生態形成了一個由下而上的層級關係：
LangChain → LangGraph → Deep Agents
它從單一任務的 Chain，逐步走向能自主規劃與持續學習的 Agent 系統。
🚀 結語
從 Chain → Agent，不只是技術重構，而是 LangChain 在正式邁向「AI 工程框架」的象徵：
- Agent 成為開發核心單位
- LangGraph 提供生產級運行時
- Middleware 與 content_blocks 成為生態新標準
簡單說：
LangChain 1.0 不再是「寫幾條 Chain」，而是「設計一個會思考、會行動的 AI 系統」。
📰 Data + AI = ∞
📰 Data + AI = ∞ 持續輸出我對資料科學 x 人工智慧領域的觀察與見解，邀請對該主題有興趣的朋友一起加入訂閱、關注 ✌️
⮑ 📰 Data + AI = ∞ 電子報 + 追蹤 資料科學家的工作日常｜維元 Facebook
感謝你的閱讀，我是維元，我們下期見 👋👋👋👋喜歡別忘了訂閱、分享 📰 Data + AI = ∞
