Agentic AI：單智能體 vs 多智能體系統的核心差異
在 LangGraph 中基于結構化數據源構建
在 LangGraph 中構建不同的 agent 系統 | Image by author
如果你剛開始搭建不同的 agentic 系統，一個有趣的切入點是比較單智能體工作流與多智能體工作流，或者說更靈活的系統與更可控的系統之間的差異。
本文將幫助你理解什么是 Agentic AI，以及如何用 LangGraph 和 LangSmith Studio 構建 agentic 系統。
我們會用兩種不同的架構構建一個 researcher，以便對比結果、判斷哪種做得更好。
本文涉及的資源在這里(???https://github.com/ilsilfverskiold/Awesome-LLM-Resources-List/tree/main/guides/langgraph??)。運行基本都是免費的，除了會用到一些 OpenAI tokens。
使用場景
為了構建一個具體的東西，我們會搭建一個 tech 研究 agent，它能找出昨天或過去一周的趨勢，再判斷什么值得報道。
在匯總與收集研究這種任務上，Agentic AI 非常能打。
本文會用一個 API 來匯總科技圈大家在討論和分享的內容，然后讓 agentic 系統基于我們的用戶畫像判斷重要性并為我們做摘要。
數據源提供了結構化數據，agentic 系統可以據此工作
這個 agent 不會在正文里添加引用，我們關注的是在只設置單智能體與設置多個協同智能體兩種情況下，它分別能覆蓋到多少信息。
因此本文的重點更在 agentic 的構建，而不是數據源本身。
我們的多智能體系統在 LangSmith Studio 中的樣子，運行需要幾分鐘
我們先用一個簡單的 agent（能訪問不同的 API endpoints）搭建系統，然后再擴展為多團隊、更多工具的系統，看質量差異。
開始之前，我會先給入門者做個簡短復習。如果你對 agentic 系統很熟，可以跳過前面的一些部分。
Agentic AI 與 LLMs
Agentic AI 是用自然語言來編程。與其寫死板、顯式的代碼，不如用自然語言指令讓大語言模型（LLMs）負責路由數據并調用動作，實現自動化。
在工作流里使用自然語言并不新鮮，我們已經用了多年的 NLP 來抽取和處理數據。
新的是我們現在能給語言模型更多自由度，讓它們處理歧義并做出動態決策。
但 LLMs 能理解復雜語言，并不意味著它們天然會校驗事實或保證數據完整性。
我更把它們看作一個溝通層（至少目前如此），位于結構化系統與既有數據源之上。
我通常這樣向非技術同事解釋：它們有點像我們。沒有干凈、結構化的數據，我們也會開始“編”。LLMs 也是一樣。
所以，就像我們一樣，它們會盡力而為。如果想要更好的輸出，就要為它們構建能提供可靠數據或可操作系統的環境。
因此，在 Agentic 系統中，我們會為它們接入不同的數據源、工具和系統。
當然，就算我們_可以_在更多地方使用更大的模型，也不代表我們總是_應該_這么做。LLMs 在理解細膩自然語言時大放異彩，比如客服、研究或 human-in-the-loop 協作。
但對于結構化任務（例如提取數字并發送到某處），你應該優先使用傳統方法與自動化。
LLMs 并不比計算器更擅長算術。所以，不是讓 LLM 直接算，而是給 LLM 一個計算器的調用能力。
因此，只要_可以_用程序化的方式構建工作流的部分，通常都更優。
盡管如此，LLMs 擅長適應現實世界的“臟輸入”和理解模糊指令，把兩者結合起來是構建系統的好方法。
如果你還很新手，并且仍有些困惑，可以去看看我其他更詳細的內容。等我們動手搭建時，可能會更清晰。
Agentic 框架與 LangGraph
很多人第一次做 agent 就直接上 CrewAI 或 AutoGen，但我們有很多選擇。
我之前在這里寫過一些綜述，閱讀量超過 10 萬，想要總覽可以先看。
LangGraph 技術性更強，也更復雜，它是基于 LangChain 的圖式框架。很多開發者都偏愛它，所以至少做點東西是值得的。
我現在更喜歡無框架的做法，但會借鑒各框架里學到的好東西，所以學習它們仍然有價值。
不過 LangGraph 有不少抽象層，你可能會想重構部分以便更好地控制與理解。
這里我不詳細展開 LangGraph，所以我單獨做了一個簡短指南給需要復習的人。
在這個用例里，你可以不寫代碼就跑起來工作流，但如果你來此是為了學習，也可以順便理解 LangGraph 的工作方式。
單智能體 vs 多智能體系統
在開工之前，先說說單智能體與多智能體的差異。
如果你圍繞一個 LLM 并給它一堆 tools來構建系統，你就是在做單智能體工作流。它很快，而且如果你是 agentic AI 新手，你可能覺得模型“應該能自己搞定”。
但說到底，這些工作流也是一種系統設計。
就像任何軟件項目一樣，你需要規劃流程、定義步驟、組織邏輯，并決定每一部分如何行為。
這就是多智能體工作流的用武之地。
并不是所有多智能體都是層級式或線性的，有些是協作式的。協作式工作流也更偏靈活，我覺得在當下能力水平下，這類工作流相對更難駕馭。
不過，協作式工作流同樣會把不同功能拆解為獨立模塊。
當你只是試驗時，協作式工作流非常合適，但它不一定能提供完成實際任務所需的精確度。
在本文要搭的工作流中，我已經知道該如何使用這些 APIs，因此我需要引導系統以正確方式使用它們。
我們會對比一個單智能體的設置與一個層級式多智能體系統：由一個 lead agent 把任務分發給一個小團隊，讓你看看它們在實踐中的行為差異。
構建單智能體
構建單智能體時，我們用一個 LLM 和一個 system prompt，然后給它若干 tools 的訪問權。
智能體會基于用戶的問題自行決定該用哪個 tool、何時用。
單智能體的挑戰在于“可控性”。
不論 system prompt 多么詳細，模型都可能不按我們要求執行（更受控的環境也可能如此）。如果我們給太多 tools 或選項，它很可能不會全部使用，甚至用錯。
你能寫進指令里讓它“照做”的空間是有限的。
為說明這一點，我們會構建一個 tech news agent，它能訪問多個自定義數據的 API endpoints，并且 tools 中有多種可選參數。
由智能體決定使用多少工具、如何組織最終摘要。
提醒一下，我是用 LangGraph 來構建這些工作流的。這里不會深講 LangGraph，如果你想學基礎以便修改代碼，看這里（這份指南寫于 2025 年 4 月）。
你可以在這里找到單智能體工作流。要運行它，你需要 LangSmith 的賬號（可訪問 LangSmith Studio）以及安裝了 Python 3。
有了賬號后，把單智能體工作流 clone 到你的電腦。
目錄結構如下：
single-agent-workflow/
├─ my_agent/
│ ├─ agent.py
│ ├─ requirements.txt
│ ├─ utils/
│ ├─ nodes.py
│ ├─ state.py
│ └─ tools.py
├─ README.md
├─ langgraph.json創建一個 .env 文件并添加 Google API key。這個單智能體我們會用 Gemini。
GOOGLE_API_KEY=KEY_HERE然后創建環境：
python3.11 -m venv venv_py311
source venv_py311/bin/activate安裝 LangGraph CLI：
pip install -U "langgraph-cli[inmem]"requirements 在 my_agent 文件夾下，也需要安裝：
pip install -r my_agent/requirements.txt安裝完成后，你可以在 LangSmith Studio 打開這個單智能體工作流：
langgraph dev這會自動打開 LangSmith Studio（之前叫 LangGraph Studio）。
這里還需要創建一個 assistant，默認是 Anthropic，而我們這個 agent 使用 Gemini。
點擊左下角按鈕管理 assistants。
請確保創建一個模型為“gemini”的新 assistant，并點擊“create new assistant” | Image by author
會彈出上圖類似的 modal。把模型設為“gemini”，然后點擊“Create New Assistant”。
回到主界面后，你可以設置起始消息。
比如告訴它你的身份、希望獲取每日/每周/每月的信息（見下例）。
{"messages": ["I'm a tech investor, give me what's up in tech for the last week"]}在 LangSmith Studio 里會像這樣顯示：
點擊提交，結果會很快，因為我們是單智能體。
它會先在 3 個不同類別下檢查一些 trending keywords，然后對其中幾個關鍵詞再看大家都在說什么。
如果你想了解這些 tools 是如何創建的，去看看代碼即可，本質上就是調用一個 API。
最終結果類似這樣（當然取決于你運行的時間，信息每天都會變化）：
Here's a summary of the trending tech topics from the past week:
Companies:
Apple: Apple is facing scrutiny over its App Store practices, including a UK monopoly case and concerns about attention to detail. There are also reports of reduced iPhone Air production and its potential move to include ads in the Maps app.
Meta: Meta is undergoing layoffs in its AI division, which has generated negative sentiment. There is also discussion around a mod that disables the recording light on Meta's Ray-Ban glasses, raising privacy concerns.
GM: GM's decision to ditch Apple CarPlay and Android Auto in future vehicles has sparked controversy and negative reactions from users.
Samsung: Samsung is planning to introduce ads on its smart fridges, drawing criticism. There's also news about the upcoming Galaxy XR event and a new chief design officer.
[...]如果你不想自己運行 agent 又想看完整結果，點這里。結果還可以，但你會發現它挖掘得不夠深。
當然我們可以繼續追問它，但你可以想象，如果任務再復雜一些，它就會在工作流里開始走捷徑。
關鍵在于：agent 系統不會“自動照著我們腦海中的方式思考”，我們必須對它進行編排，讓它按我們的意愿工作。
只要有人在環，比如做問答，這沒問題。
在這個場景里，如果人類問一個問題、agent 去取回對應信息，那會很好用。
但如果是深度研究，我們需要更復雜一點的系統。可以用工作流式（每個環節做一件事），也可以嘗試構建一個層級式系統，讓一個 agent（或團隊）對某一件事負責。
測試多智能體工作流
搭建多智能體系統要比給單智能體配幾樣工具難多了。
你需要在此之前仔細思考系統架構，以及數據如何在 agents 之間流動。
這里我搭的多智能體工作流使用兩個團隊（research team 和 editing team），每個團隊下有若干 agents。
我們多智能體系統中的團隊/agents 架構示意 | Image by author
每個 agent 只能訪問特定的一小組 tools（不宜過多），并有清晰的指令。
這種對每個 agent 的職責收斂，對于較低級別的 LLMs（例如 Gemini Flash 2.0）非常有益；不過我仍然喜歡用更強的 LLM 來做 summarizing（這里我們用 GPT-5 作為 summarizer agent）。
我們引入了一些新工具，比如一個 research pad，充當共享空間（一個團隊寫入發現，另一個團隊讀?。Ｗ詈笠粋€ LLM 會讀取所有已研究與編輯的內容來生成摘要。
另一種替代 research pad 的方式是在 state 中存儲數據到 scratchpad，為每個團隊或 agent 隔離短期記憶。但這也意味著需要仔細思考每個 agent 的記憶應包含什么。
我還決定把 tools 再豐富一些，以便在前期就提供更充實的數據，這樣 agents 就不必對每個關鍵詞逐個拉取來源。在這里我之所以這么做，是因為可以用常規編程邏輯來搞定。
要點：如果能用常規編程邏輯，就用它。
工作流在這里為你準備好了。加載之前，請在 ??.env?? 文件中同時添加你的 OpenAI 與 Google API keys。
GOOGLE_API_KEY=KEY_HERE
OPENAI_API_KEY=KEY_HERE
ANTHROPIC_API_KEY=KEY_HERE只有在你要嘗試更換 agents 時才需要設置 Anthropic key（但如果不設可能會報錯；遇到報錯就新建一個只包含 Gemini 的 assistant）。
剩下步驟與單智能體類似：創建環境、安裝依賴并打開工作流。
langgraph dev打開后你會看到它看起來比單智能體復雜多了。
在這個工作流中，routes（edges）是動態設置的，而不是像單智能體那樣手動設定。如果你去看代碼，會顯得更復雜。
運行時同樣需要像上次那樣給一個消息。
我這次把 prompt 寫得更詳細了一點，這算是有點“作弊”，你可以試試更簡單的。
{"messages": ["{"messages": ["I'm an investor and I'm interested in getting an update for what has happened within the week in tech, and what people are talking about (this means categories like companies, people, websites and subjects are interesting). Please also track these specific keywords: AI, Google, Microsoft, and Large Language Models"]}"]}最好還是用你之前的設置，這樣才能有可比性，但隨你。
一旦開始運行會花挺久，你可以先離開，幾分鐘后再回來。
trending keywords agent 可用的 tools 比單智能體要復雜，因此返回更慢。
總體而言，這類系統需要時間來收集與處理信息，這點我們需要習慣。
稍后你可以在根目錄下的“notes”文件夾看到它收集的筆記。示例見這里。
最終的摘要大致如下：
FINAL RESEARCH SUMMARY
Tech Research Summary
Weekly Tech Investor Brief (week ending Oct 28, 2025)
Key Happenings
Oct 27: ICE signed a $5.7M contract for AI-powered social media surveillance (Reddit: r/technology)
Oct 27: "Windows 10 deadline boosts Mac sales" thread trended, highlighting OS/device churn (Hacker News)
Oct 26: Microsoft 365 Copilot arbitrary data exfiltration via Mermaid diagrams disclosed (Hacker News)
Oct 26: "It's insulting to read AI-generated blog posts" topped HN, reflecting AI content fatigue (Hacker News)
[...]
Why It Matters
AI demand is moving from hype to operational scrutiny. Government adoption (e.g., ICE's Oct 27 contract) signals durable budgets for AI monitoring and analytics, but also heightens regulatory and civil liberties overhang—an opening for compliant AI, privacy-tech, and auditing vendors. Enterprise posts on Microsoft 365 Copilot exfiltration and Teams attendance monitoring underscore a near-term buyer focus on security, governance, and employee trust, not just raw AI features.
Platform competition intensified. Google's Oct 23 Earth AI updates and Google AI Studio "vibe coding" push indicate a bid to reduce time-to-production for AI apps, a likely driver of cloud/TPSU demand and developer lock-in. Meanwhile, community gravitation to open and self-hosted stacks (ComfyUI momentum; S3-compatible storage chatter) reflects a cost-control and control-residency theme—relevant for hybrid vendors and open-core plays.
Consumer backlash is shaping product roadmaps. GM's removal of CarPlay/Android Auto is trending because it challenges perceived table-stakes features, risking brand equity and sales. Apple's reported ads in Maps and YouTube's deepfake measures reflect a broader tension between monetization, safety, and user experience—areas where differentiated policy and design can become competitive moats.
[...]新聞內容當然會因運行時間不同而變化。我是在 10 月 28 日運行的，所以示例報告對應這一天。
關于結果，就留給你自己判斷：更復雜的系統 vs 簡單系統，在過程控制與輸出質量上的差異。
一些收尾說明
我這里用的是一個不錯的數據源。沒有這一點，你就需要加很多錯誤處理，這會讓一切更慢。
干凈、結構化的數據是關鍵。沒有它，LLM 發揮不出水平。即便數據靠譜，也不完美。你仍需打磨 agents，確保它們按預期行事。
你可能已經注意到，這個系統是可用的，但還沒到“完美”。還有不少地方要改進：把用戶查詢解析得更結構化、為 agents 加護欄讓它們總是使用自己的 tools，以及優化摘要的有效性，確保研究文檔言簡意賅。
我們需要更好的錯誤處理，或許還要加入“長期”記憶，以更好理解用戶真正需要什么。State（短期記憶）在你優化性能與成本時尤其重要。
現在我們只是把每條消息都塞進 state 并讓所有 agents 都能訪問，這不理想。理想情況下應該按團隊分離 state。在這個案例里我還沒做這件事，但你可以嘗試在 state schema 中引入 scratchpad 來隔離每個團隊所知。
本文轉載自??AI大模型觀察站??，作者：AI研究生
