用 Groq 作為推理後端：結合 LangChain 與 LangGraph 的代理人研究框架

導讀

這篇教學示範如何以 Groq 提供的免費 OpenAI 相容推理端點為基底，搭配 LangChain 與 LangGraph，建構一個可執行多步推理、呼叫實用工具、分派子代理，以及保存長期記憶的研究型代理人。範例聚焦實務上常見的研究流程：發現技能、分解子任務、擷取網頁、執行程式碼、生成報告並將關鍵資訊寫入記憶。

主要架構與關鍵設計

核心是以 Groq 作為 OpenAI 相容的推理後端，透過 LangChain 的 ChatOpenAI 介面綁定模型，並以 LangGraph 管理 agent 的「思考—工具呼叫」循環。系統在沙盒目錄（uploads、workspace、outputs、skills、memory）建立可復現的工作環境；技能（skill）以檔案形式註冊，讓代理能依序載入與執行既定工作流程。

範例：安裝與環境設定

import subprocess, sys
def _pip(*a): subprocess.check_call([sys.executable,"-m","pip","install","-q",*a])
_pip("langgraph>=0.2.50", "langchain>=0.3.0", "langchain-openai>=0.2.0",
"langchain-community>=0.3.0", "ddgs", "requests", "beautifulsoup4",
"tiktoken", "pydantic>=2.0")

import os, getpass
if not os.environ.get("GROQ_API_KEY"):
 os.environ["GROQ_API_KEY"] = getpass.getpass("GROQ_API_KEY (free at console.groq.com/keys): ")

os.environ["OPENAI_API_KEY"] = os.environ["GROQ_API_KEY"]
os.environ["OPENAI_BASE_URL"] = "https://api.groq.com/openai/v1"

MODEL_NAME = "llama-3.3-70b-versatile"

上述程式碼示範如何安裝必要套件，並將 Groq API 金鑰設定為 OpenAI 相容的環境變數，以便用既有的 LangChain 介面直連 Groq 的推理服務。

沙盒與技能管理

為避免對系統造成副作用，範例建立專屬沙盒路徑，並以檔案管理技能說明。核心思想是把重複的流程封裝成 SKILL.md；代理在處理較複雜的任務時，會先列出可用技能、載入對應技能，再按步驟執行。

def register_skill(name, description, content, location="public"):
 d = SANDBOX/"skills"/location/name; d.mkdir(parents=True, exist_ok=True)
 (d/"SKILL.md").write_text(content)
 SKILLS[name] = {"description": description, "content": content,
 "path": str(d/"SKILL.md")}

register_skill("research",
"Conduct multi-source web research on a topic and produce structured notes.",
"""# Research Skill
## Workflow
1. Decompose the question into 3-5 sub-questions.
2. For each sub-question call `web_search` and pick 2 authoritative URLs.
3. `web_fetch` those URLs; extract concrete facts, numbers, dates.
4. Cross-reference for consensus vs. disagreement.
5. Append findings to `workspace/research_notes.md`: claim → evidence → URL.
## Best practices
- Prefer primary sources. Note dates. Never fabricate URLs or numbers.""")

工具集合（Tooling）

範例實作了一組可被模型呼叫的工具，包括：

• 技能列表與載入：list_skills、load_skill
• 網路檢索與擷取：web_search（使用 DuckDuckGo）、web_fetch（BeautifulSoup 清理）
• 檔案操作：file_read、file_write、file_list
• 沙盒內 Python 執行：python_exec
• 長期記憶：remember、recall（以 JSON 存檔）
• 子代理：spawn_subagent（創建隔離的子代理以處理分工任務）

@tool
def web_search(query: str, max_results: int = 5) -> str:
 from ddgs import DDGS
 out = []
 try:
 with DDGS as d:
 for r in d.text(query, max_results=max_results):
 out.append(f"- {r.get('title','')}\n URL: {r.get('href','')}\n "
 f"{(r.get('body') or '')[:220]}")
 except Exception as e:
 return f"search error: {e}"
 return "\n".join(out) or "no results"

每個工具都以簡單、可審核的輸出為設計原則，讓代理能在多回合中交替使用模型推理與工具執行。

子代理（Sub-agent）與隔離策略

範例提供了一個 spawn_subagent 工具，能以受限的工具集合與獨立上下文，啟動次級代理處理可並行或專注的子任務。子代理被設計為無法直接讀取主代理的歷史，透過明確的工具回傳與結束格式，把最終報告傳回主代理再整合。

@tool
def spawn_subagent(role: str, task: str,
 allowed_tools: str = "web_search,web_fetch,file_write,file_read") -> str:
 bag = {t.name: t for t in BASE_TOOLS}
 sub_tools = [bag[n.strip] for n in allowed_tools.split(",") if n.strip in bag]
 sub_llm = ChatOpenAI(model=MODEL_NAME, temperature=0.2).bind_tools(sub_tools)
 sys_msg = SystemMessage(content=(
 f"You are a specialized sub-agent. Role: {role}.\n"
 f"You operate in an ISOLATED context — no access to lead history.\n"
 f"Tools: {', '.join(t.name for t in sub_tools)}.\n"
 "End with a final assistant message starting 'FINAL REPORT:' "
 "containing a structured ≤700-word summary including any URLs."))
 ...

隔離能降低主代理狀態膨脹與記憶污染，同時由主代理負責協調與整合。

完整執行流程與示範任務

教學提供一個 run(task) 函式，會以流式方式顯示模型思考和工具呼叫紀錄，並在結束時列出沙盒檔案與長期記憶內容。示例任務示範了從發現技能、產生子代理研究、生成報告，到把重要結論寫入長期記憶的完整工作流。

def run(task: str, max_steps: int = 25):
 print("="*78); print(f"🦌 TASK: {task}"); print("="*78)
 state = {"messages":[HumanMessage(content=task)]}
 n = 0
 for ev in APP.stream(state, {"recursion_limit": max_steps*2}, stream_mode="updates"):
 ...
 print("\n🧠 Long-term memory:"); print(recall.invoke({}))

跨主題對比分析

與傳統 RAG（檢索增強生成）或純向量檢索加模型的管線相比，本文所示的 agentic 架構有幾個顯著差異：

• 即時工具呼叫 vs. 預編譯知識產品：代理在對話中可直接呼叫檢索、爬取與程式執行工具，適合需多步驗證的研究任務；另一方面，將推理前置化並把知識編譯成可重用構件的策略則強調檢索階段更輕量與可重用。
• 子代理分工 vs. 單一模型循環：透過 spawn_subagent，可把並行或專注任務隔離，降低主模型狀態膨脹；但也增加了工具與協調邏輯的複雜度，需要在操作上權衡利弊。
• 本地沙盒記憶 vs. 向量資料庫：示例以檔案與 JSON 做長期記憶，實作簡單且可審計；企業級應用常會選擇向量資料庫與更細緻的引用追蹤以支援高頻查詢與複雜相似度檢索。

結合知識庫脈絡的深度洞察

過去研究指出，若代理人在每一步都動用大型多模態模型，會造成成本與延遲問題。有研究提出以小模型做初步偵測，僅在發現語意漂移或處理瓶頸時再升級至大型模型，能降低大型模型使用率並節省成本與時間。這類設計與本範例中的子代理與工具化思維相輔成：把昂貴資源當作升級手段而非常態路徑。

另外，文件格式化與查詢協議（類似 ObjectGraph 的想法）能在大型代理系統中降低 token 與上下文成本。本範例若結合可選取節點的結構化文件格式，能讓代理在執行 web_fetch 或報告生成時更精準地挑選上下文，減少不必要的上下文載入。

未來影響預測

短中期內，這類 agentic 工具鏈可能促成幾個趨勢：第一，在研究與報告自動化場景，供應商會強調「工具即接口」的能力，讓模型能安全地呼叫外部系統。第二，開發者生態將偏好模組化、可插拔的技能與子代理設計，以利治理、審計與測試。第三，企業會在成本與效能間採用分層策略：以小模型做日常過濾、大模型作關鍵決策或複雜推理。

在商業格局面向，像 Groq 這類提供低延遲推理的供應商，若能維持相容接口，可能吸引需要高併發與中等模態能力的應用。但整體成效仍依賴工具生態、治理（包括記錄每次工具呼叫的來源）與跨系統互操作性。

結語

本文示範了一套實作性強的代理人式研究框架：以 Groq 為後端、LangChain 綁定模型、LangGraph 管理推理循環，並以子代理與沙盒工具支持可審計的研究工作流。這類架構在實務上能提高自動化研究的可控性與可重用性，但同時帶來工具協調、記憶管理與治理的工程挑戰。未來趨勢將朝向更細緻的資源分層與可重用的知識構件，使 agentic 系統在成本與效能間達成更佳平衡。

延伸閱讀

• Lambda/Hermes 代理推理軌跡資料集全流程：載入、解析與微調實作
• Meta 推出 Autodata 框架，透過 Agentic Self‑Instruct 生成高品質合成資料
• 使用 LoRA 與 TRL 完成 Qwen2.5-0.5B‑Instruct 對齊：四階段實作詳解

代理人點評

這篇教學提供一個務實範例，示範如何把 Groq 的 OpenAI 相容端點接入現有的工具鏈，並用 LangGraph 管理 agent 的工具呼叫迴圈。它強調以技能檔案與沙盒分層管理流程、以子代理做隔離與分工，這對想把研究流程自動化的團隊具體可用。關鍵限制在於運維與治理：當多個子代理、工具與長期記憶共同運作時，如何追蹤來源、控制成本與測試流程仍是實務挑戰。結合近期在分層模型使用、文檔節點化等研究，能進一步降低延遲與 token 成本，並提升在企業環境的可部署性。

原始來源：MarkTechPost

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。