如何構建終極的AI自動化系統：多代理協作指南
自GPT Researcher首次發布以來，僅僅一年時間，構建、測試和部署AI代理的方法已經取得了顯著進步。從最初的zero-shot或few-shot prompting，迅速發展到代理的function calling、RAG，再到現在的Agent工作流（也稱為flow engineering）。
吳恩達 最近指出：“我認為AI代理工作流今年將推動巨大的AI進步，甚至可能超過下一代基礎模型。這是一個重要的趨勢，我鼓勵所有從事AI工作的人士關注。”
在本文中，你將了解到為什么多Agent工作流是目前的最佳實踐，以及如何使用LangGraph構建一個最佳的自主研究多Agent助手。
想要跳過教程，可以直接查看GPT Researcher與LangGraph的最終代碼實現https://github.com/assafelovic/gpt-researcher/tree/master/multi_agents。
LangGraph簡介
LangGraph是LangChain的擴展，旨在創建Agent和多Agent流程。它增加了創建循環流程的能力，并內置了短期記憶——這兩個特性對于創建Agent至關重要。
LangGraph為開發人員提供了高度的可控性，對于創建定制代理和流程非常重要。幾乎所有生產中的代理都針對它們試圖解決的特定用例進行了定制。LangGraph為您提供了創建任意定制代理的靈活性，同時提供了一個直觀的開發人員體驗。
讓我們開始構建吧！
構建終極的自主研究代理
通過利用LangGraph，研究過程可以通過利用具有專業技能的多個Agent，在深度和質量上得到顯著提升。每個代理都專注于特定的技能，這樣可以實現更好的關注點分離、可定制性，并隨著項目的增長而進一步發展。
受到最近STORM論文的啟發，這個例子展示了一個AI代理團隊如何協作開展給定主題的研究，從規劃到出版。這個例子還將利用領先的自主研究代理GPT Researcher。
研究代理團隊
研究團隊由七位LLM Agent組成：
- 主編— 負責監督整個研究過程和管理團隊。這是“主”代理，使用LangGraph協調其他代理。該代理作為主要的LangGraph接口。
- GPT Researcher— 一個專門的自主代理，負責對給定主題進行深入研究。
- 編輯— 負責規劃研究大綱和結構。
- 審稿人— 根據一組標準驗證研究結果的正確性。
- 校對者— 根據審稿人的反饋校對研究結果。
- 作家— 負責編寫最終報告。
- 出版商— 負責將最終報告發布到多種格式，如PDF、Docx、Markdown等。
架構設計
正如下面所示，自動化過程基于以下階段：規劃研究、數據收集與分析、審查與修訂、撰寫報告，以及最終的出版：
研究過程的自動化階段圖
更具體地說，流程包括以下步驟：
- 檢索數據（gpt-researcher）— 根據給定的研究任務，在互聯網上進行初步研究。這一步對于LLM來說至關重要，因為它可以基于最新和相關信息來規劃研究過程，而不是僅依賴于預訓練數據。
- 編輯— 根據初步研究結果規劃報告的大綱和結構。編輯還負責啟動基于計劃大綱的并行研究任務。
對于大綱中的每個主題（并行進行）：
- 研究員（gpt-researcher）— 對子主題進行深入研究并撰寫草稿。這個代理利用GPT Researcher的Python包，進行優化、深入和事實性的研究報告。
- 審稿人— 根據一組指南驗證草稿的正確性，并為校對者提供反饋（如果有的話）。
- 校對者— 根據審稿人的反饋校對草稿，直至滿意為止。
- 作家— 負責整合并撰寫包含引言、結論和參考文獻部分的最終報告。
- 出版商— 將最終報告發布到多種格式，如PDF、Docx、Markdown等。
由于代碼量較大，我們不會深入到所有代碼細節，但會重點介紹我發現有價值的部分。
定義圖形狀態
LangGraph的一個我最喜愛的特性是state management（狀態管理）。在LangGraph中，狀態通過結構化方法實現，開發人員定義一個GraphState來封裝應用程序的整個狀態。圖中的每個節點都可以修改這個狀態，允許基于交互的不斷發展的上下文進行動態響應。
在技術設計的每個開始階段，考慮整個應用程序的數據模式是關鍵。在這種情況下，我們將這樣定義一個ResearchState：
class ResearchState(TypedDict):
task: dict
initial_research: str
sections: List[str]
research_data: List[dict]
# 報告布局
title: str
headers: dict
date: str
table_of_contents: str
introduction: str
conclusion: str
sources: List[str]
report: str如上所示，狀態被分為兩個主要部分：研究任務和報告布局內容。隨著數據在圖代理中流通，每個代理將基于現有狀態生成新數據并更新它，以便后續處理圖中的其他代理。
然后，我們可以這樣初始化圖形：
from langgraph.graph import StateGraph
workflow = StateGraph(ResearchState)使用LangGraph初始化流程
如前所述，多Agent開發的好處之一是可以獨立構建每個Agent，使其具有專業和限定的技能。以Researcher代理為例，它使用了GPT Researcher Python包：
from gpt_researcher import GPTResearcher
class ResearchAgent:
def __init__(self):
pass
async def research(self, query: str):
# 初始化研究員
researcher = GPTResearcher(parent_query=parent_query, query=query, report_type=research_report, config_path=None)
# 對給定的查詢進行研究
await researcher.conduct_research()
# 編寫報告
report = await researcher.write_report()
return report如上所示，我們創建了Research代理的一個實例。現在假設我們已經為團隊的每個代理都做了同樣的事情。創建完所有代理后，我們將使用LangGraph初始化流程：
def init_research_team(self):
# 初始化代理
editor_agent = EditorAgent(self.task)
research_agent = ResearchAgent()
writer_agent = WriterAgent()
publisher_agent = PublisherAgent(self.outputdir)初始化研究團隊
# 定義Langchain StateGraph與ResearchState
workflow = StateGraph(ResearchState)
# 為每個代理添加節點
workflow.add_node("browser", research_agent.run_initial_research)
workflow.add_node("planner", editor_agent.plan_research)
workflow.add_node("researcher", research_agent.run_parallel_research)
workflow.add_node("writer", writer_agent.run)
workflow.add_node("publisher", publisher_agent.run)
# 添加邊以連接節點
workflow.add_edge('browser', 'planner')
workflow.add_edge('planner', 'researcher')
workflow.add_edge('researcher', 'writer')
workflow.add_edge('writer', 'publisher')
# 設置起始節點和結束節點
workflow.set_entry_point("browser")
workflow.add_edge('publisher', END)
return workflow如上所示，創建LangGraph圖非常直接，主要包括三個函數：add_node、add_edge和set_entry_point。首先，你可以向圖中添加節點，然后連接邊，并最終設置起始點。
如果你一直關注代碼和架構，會發現審稿人和校對者代理在初始化中缺失。接下來，我們將討論這部分內容。
圖中圖：支持有狀態的并行化
這是我使用LangGraph時,最令我激動的部分。這個自主助手的一個亮點是能夠針對每個研究任務并行運行，然后根據預定義的指南進行審查和修訂。
在優化速度的同時，了解如何在流程中利用并行工作至關重要。但如果所有Agent都報告相同的狀態，如何觸發并行代理工作呢？這可能導致競態條件和最終數據報告的不一致性。為解決這個問題，可以創建一個子圖，該子圖將從主LangGraph實例觸發，并且這個子圖將持有每個并行運行的獨立狀態，從而解決了上述問題。
按照之前的步驟，我們定義LangGraph狀態及其代理。由于這個子圖主要審查和修訂研究草稿，我們將定義狀態以草稿信息為主：
class DraftState(TypedDict):
task: dict
topic: str
draft: dict
review: str
revision_notes: str在DraftState中，我們主要關注討論的主題，以及審閱者和修訂注釋，因為它們需要相互溝通，以完成子主題研究報告的最終確定。為了創建循環條件，我們將利用LangGraph的另一個重要特性——條件邊：
async def run_parallel_research(self, research_state: dict):
workflow = StateGraph(DraftState)
workflow.add_node("researcher", research_agent.run_depth_research)
workflow.add_node("reviewer", reviewer_agent.run)
workflow.add_node("reviser", reviser_agent.run)
# 設置起始點，以及從研究員到審閱者，再到校對者的邊
workflow.set_entry_point("researcher")
workflow.add_edge('researcher', 'reviewer')
workflow.add_edge('reviser', 'reviewer')
# 添加條件邊，根據審閱者的反饋決定是接受還是修訂
workflow.add_conditional_edges('reviewer',
(lambda draft: "accept" if draft['review'] is None else "revise"),
{"accept": END, "revise": "reviser"})通過定義條件邊，圖會根據審閱人的反饋決定是進入校對者節點還是結束流程。回顧我們構建的主圖，你會看到這個并行工作是在名為“researcher”的節點下進行的，該節點由主編代理觸發。
運行研究助手
在完成代理、狀態和圖形的構建后，是時候啟動我們的研究助手了！為了便于定制，助手根據給定的任務.json文件運行：
{
"query": "AI 是否處于炒作周期？",
"max_sections": 3,
"publish_formats": {
"markdown": true,
"pdf": true,
"docx": true
},
"follow_guidelines": false,
"model": "gpt-4-turbo",
"guidelines": [
"報告必須采用APA格式編寫",
"每個子部分必須包含使用超鏈接的支持來源。如果不存在，則刪除子部分或重寫為前一部分的內容",
"報告必須用西班牙語編寫"
]
}任務對象非常直觀，但請注意，如果follow_guidelines?為false，則會導致圖形忽略修訂步驟和定義的指南。此外，max_sections字段定義了要研究的子標題數量，這將影響報告的長度。
運行助手將生成最終的研究報告，并提供Markdown、PDF和Docx等格式。
想了解更多或運行示例，請訪問GPT Researcher x LangGraph的開源頁面。
展望未來
展望未來，有許多令人興奮的發展前景。人為干預對于優化AI體驗至關重要。讓人類幫助助手修訂和專注于正確的研究計劃、主題和大綱，將提升整體的質量和體驗。此外，確保AI流程中的人為干預可以確保結果的正確性、可控性和確定性。值得高興的是，LangGraph已經原生支持這些功能，如這里所示。
此外，支持對Web和本地數據的研究將是許多商業和個人用例的關鍵。
最后，可以進一步努力提高檢索來源的質量，并確保最終報告構建在最佳的故事線上。
LangGraph和多代理協作的下一步發展可能是，助手能夠根據給定的任務動態規劃和生成圖形。這一愿景允許助手為特定任務選擇一組特定的代理，并根據圖形的基本原理規劃其策略，這將開啟一個全新的可能性世界。鑒于AI領域的創新速度，不久的將來我們可能會看到GPT Researcher的一個新顛覆性版本。我們期待著未來的發展！
本文轉載自 AI小智，作者： AI小智
