自GPT Researcher首次發(fā)布以來，僅僅一年時間，構(gòu)建、測試和部署AI代理的方法已經(jīng)取得了顯著進步。從最初的zero-shot或few-shot prompting，迅速發(fā)展到代理的function calling、RAG，再到現(xiàn)在的Agent工作流（也稱為flow engineering）。

吳恩達 最近指出：“我認為AI代理工作流今年將推動巨大的AI進步，甚至可能超過下一代基礎模型。這是一個重要的趨勢，我鼓勵所有從事AI工作的人士關(guān)注?！?/p>

在本文中，你將了解到為什么多Agent工作流是目前的最佳實踐，以及如何使用LangGraph構(gòu)建一個最佳的自主研究多Agent助手。

想要跳過教程，可以直接查看GPT Researcher與LangGraph的最終代碼實現(xiàn)https://github.com/assafelovic/gpt-researcher/tree/master/multi_agents。

LangGraph簡介

LangGraph是LangChain的擴展，旨在創(chuàng)建Agent和多Agent流程。它增加了創(chuàng)建循環(huán)流程的能力，并內(nèi)置了短期記憶——這兩個特性對于創(chuàng)建Agent至關(guān)重要。

LangGraph為開發(fā)人員提供了高度的可控性，對于創(chuàng)建定制代理和流程非常重要。幾乎所有生產(chǎn)中的代理都針對它們試圖解決的特定用例進行了定制。LangGraph為您提供了創(chuàng)建任意定制代理的靈活性，同時提供了一個直觀的開發(fā)人員體驗。

讓我們開始構(gòu)建吧！

構(gòu)建終極的自主研究代理

通過利用LangGraph，研究過程可以通過利用具有專業(yè)技能的多個Agent，在深度和質(zhì)量上得到顯著提升。每個代理都專注于特定的技能，這樣可以實現(xiàn)更好的關(guān)注點分離、可定制性，并隨著項目的增長而進一步發(fā)展。

受到最近STORM論文的啟發(fā)，這個例子展示了一個AI代理團隊如何協(xié)作開展給定主題的研究，從規(guī)劃到出版。這個例子還將利用領先的自主研究代理GPT Researcher。

研究代理團隊

研究團隊由七位LLM Agent組成：

• 主編— 負責監(jiān)督整個研究過程和管理團隊。這是“主”代理，使用LangGraph協(xié)調(diào)其他代理。該代理作為主要的LangGraph接口。
• GPT Researcher— 一個專門的自主代理，負責對給定主題進行深入研究。
• 編輯— 負責規(guī)劃研究大綱和結(jié)構(gòu)。
• 審稿人— 根據(jù)一組標準驗證研究結(jié)果的正確性。
• 校對者— 根據(jù)審稿人的反饋校對研究結(jié)果。
• 作家— 負責編寫最終報告。
• 出版商— 負責將最終報告發(fā)布到多種格式，如PDF、Docx、Markdown等。

架構(gòu)設計

正如下面所示，自動化過程基于以下階段：規(guī)劃研究、數(shù)據(jù)收集與分析、審查與修訂、撰寫報告，以及最終的出版：

研究過程的自動化階段圖

更具體地說，流程包括以下步驟：

• 檢索數(shù)據(jù)（gpt-researcher）— 根據(jù)給定的研究任務，在互聯(lián)網(wǎng)上進行初步研究。這一步對于LLM來說至關(guān)重要，因為它可以基于最新和相關(guān)信息來規(guī)劃研究過程，而不是僅依賴于預訓練數(shù)據(jù)。
• 編輯— 根據(jù)初步研究結(jié)果規(guī)劃報告的大綱和結(jié)構(gòu)。編輯還負責啟動基于計劃大綱的并行研究任務。

對于大綱中的每個主題（并行進行）：

• 研究員（gpt-researcher）— 對子主題進行深入研究并撰寫草稿。這個代理利用GPT Researcher的Python包，進行優(yōu)化、深入和事實性的研究報告。
• 審稿人— 根據(jù)一組指南驗證草稿的正確性，并為校對者提供反饋（如果有的話）。
• 校對者— 根據(jù)審稿人的反饋校對草稿，直至滿意為止。
• 作家— 負責整合并撰寫包含引言、結(jié)論和參考文獻部分的最終報告。
• 出版商— 將最終報告發(fā)布到多種格式，如PDF、Docx、Markdown等。

由于代碼量較大，我們不會深入到所有代碼細節(jié)，但會重點介紹我發(fā)現(xiàn)有價值的部分。

定義圖形狀態(tài)

LangGraph的一個我最喜愛的特性是state management（狀態(tài)管理）。在LangGraph中，狀態(tài)通過結(jié)構(gòu)化方法實現(xiàn)，開發(fā)人員定義一個GraphState來封裝應用程序的整個狀態(tài)。圖中的每個節(jié)點都可以修改這個狀態(tài)，允許基于交互的不斷發(fā)展的上下文進行動態(tài)響應。

在技術(shù)設計的每個開始階段，考慮整個應用程序的數(shù)據(jù)模式是關(guān)鍵。在這種情況下，我們將這樣定義一個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

如上所示，狀態(tài)被分為兩個主要部分：研究任務和報告布局內(nèi)容。隨著數(shù)據(jù)在圖代理中流通，每個代理將基于現(xiàn)有狀態(tài)生成新數(shù)據(jù)并更新它，以便后續(xù)處理圖中的其他代理。

然后，我們可以這樣初始化圖形：

from langgraph.graph import StateGraph
workflow = StateGraph(ResearchState)

使用LangGraph初始化流程

如前所述，多Agent開發(fā)的好處之一是可以獨立構(gòu)建每個Agent，使其具有專業(yè)和限定的技能。以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

如上所示，我們創(chuàng)建了Research代理的一個實例?，F(xiàn)在假設我們已經(jīng)為團隊的每個代理都做了同樣的事情。創(chuàng)建完所有代理后，我們將使用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)
    
    # 為每個代理添加節(jié)點
    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)
    
    # 添加邊以連接節(jié)點
    workflow.add_edge('browser', 'planner')
    workflow.add_edge('planner', 'researcher')
    workflow.add_edge('researcher', 'writer')
    workflow.add_edge('writer', 'publisher')
    
    # 設置起始節(jié)點和結(jié)束節(jié)點
    workflow.set_entry_point("browser")
    workflow.add_edge('publisher', END)
    
    return workflow

如上所示，創(chuàng)建LangGraph圖非常直接，主要包括三個函數(shù)：add_node、add_edge和set_entry_point。首先，你可以向圖中添加節(jié)點，然后連接邊，并最終設置起始點。

如果你一直關(guān)注代碼和架構(gòu)，會發(fā)現(xiàn)審稿人和校對者代理在初始化中缺失。接下來，我們將討論這部分內(nèi)容。

圖中圖：支持有狀態(tài)的并行化

這是我使用LangGraph時,最令我激動的部分。這個自主助手的一個亮點是能夠針對每個研究任務并行運行，然后根據(jù)預定義的指南進行審查和修訂。

在優(yōu)化速度的同時，了解如何在流程中利用并行工作至關(guān)重要。但如果所有Agent都報告相同的狀態(tài)，如何觸發(fā)并行代理工作呢？這可能導致競態(tài)條件和最終數(shù)據(jù)報告的不一致性。為解決這個問題，可以創(chuàng)建一個子圖，該子圖將從主LangGraph實例觸發(fā)，并且這個子圖將持有每個并行運行的獨立狀態(tài)，從而解決了上述問題。

按照之前的步驟，我們定義LangGraph狀態(tài)及其代理。由于這個子圖主要審查和修訂研究草稿，我們將定義狀態(tài)以草稿信息為主：

class DraftState(TypedDict):
    task: dict
    topic: str
    draft: dict
    review: str
    revision_notes: str

在DraftState中，我們主要關(guān)注討論的主題，以及審閱者和修訂注釋，因為它們需要相互溝通，以完成子主題研究報告的最終確定。為了創(chuàng)建循環(huán)條件，我們將利用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')
    # 添加條件邊，根據(jù)審閱者的反饋決定是接受還是修訂
    workflow.add_conditional_edges('reviewer',
                                   (lambda draft: "accept" if draft['review'] is None else "revise"),
                                   {"accept": END, "revise": "reviser"})

通過定義條件邊，圖會根據(jù)審閱人的反饋決定是進入校對者節(jié)點還是結(jié)束流程?；仡櫸覀儤?gòu)建的主圖，你會看到這個并行工作是在名為“researcher”的節(jié)點下進行的，該節(jié)點由主編代理觸發(fā)。

運行研究助手

在完成代理、狀態(tài)和圖形的構(gòu)建后，是時候啟動我們的研究助手了！為了便于定制，助手根據(jù)給定的任務.json文件運行：

{
  "query": "AI 是否處于炒作周期？",
  "max_sections": 3,
  "publish_formats": {
    "markdown": true,
    "pdf": true,
    "docx": true
  },
  "follow_guidelines": false,
  "model": "gpt-4-turbo",
  "guidelines": [
    "報告必須采用APA格式編寫",
    "每個子部分必須包含使用超鏈接的支持來源。如果不存在，則刪除子部分或重寫為前一部分的內(nèi)容",
    "報告必須用西班牙語編寫"
  ]
}

任務對象非常直觀，但請注意，如果follow_guidelines?為false，則會導致圖形忽略修訂步驟和定義的指南。此外，max_sections字段定義了要研究的子標題數(shù)量，這將影響報告的長度。

運行助手將生成最終的研究報告，并提供Markdown、PDF和Docx等格式。

想了解更多或運行示例，請訪問GPT Researcher x LangGraph的開源頁面。

展望未來

展望未來，有許多令人興奮的發(fā)展前景。人為干預對于優(yōu)化AI體驗至關(guān)重要。讓人類幫助助手修訂和專注于正確的研究計劃、主題和大綱，將提升整體的質(zhì)量和體驗。此外，確保AI流程中的人為干預可以確保結(jié)果的正確性、可控性和確定性。值得高興的是，LangGraph已經(jīng)原生支持這些功能，如這里所示。

此外，支持對Web和本地數(shù)據(jù)的研究將是許多商業(yè)和個人用例的關(guān)鍵。

最后，可以進一步努力提高檢索來源的質(zhì)量，并確保最終報告構(gòu)建在最佳的故事線上。

LangGraph和多代理協(xié)作的下一步發(fā)展可能是，助手能夠根據(jù)給定的任務動態(tài)規(guī)劃和生成圖形。這一愿景允許助手為特定任務選擇一組特定的代理，并根據(jù)圖形的基本原理規(guī)劃其策略，這將開啟一個全新的可能性世界。鑒于AI領域的創(chuàng)新速度，不久的將來我們可能會看到GPT Researcher的一個新顛覆性版本。我們期待著未來的發(fā)展！

本文轉(zhuǎn)載自 AI小智，作者： AI小智