隨著生成式人工智慧技術的進步，成功的商業應用依賴於強大的問題解決能力。在這場變革的前沿是代理系統，這些系統利用基礎模型 (FMs) 的力量來解決複雜的現實挑戰。通過無縫整合多個代理，這些創新解決方案使得在不同環境中能夠自動協作、做出決策和高效解決問題。亞馬遜網路服務 (AWS) 的科學家與學術研究者進行的實證研究顯示，通過代理協作在競爭性任務上提升推理能力取得了顯著進展。
這篇文章提供了逐步指導，教你如何創建一個具有推理能力的協作多代理框架，以將商業應用與基礎模型解耦。它展示了如何將亞馬遜 Bedrock 代理與開源多代理框架結合，使代理之間能夠協作和推理，動態執行各種任務。這個練習將引導你通過使用亞馬遜 Bedrock、亞馬遜 Bedrock 知識庫、亞馬遜 Bedrock 代理和基礎模型來建立一個推理協調系統。我們還探索了亞馬遜 Bedrock 代理與開源協調框架 LangGraph 和 CrewAI 的整合，以便進行調度和推理。
AWS 為亞馬遜 Bedrock 引入了多代理協作能力，使開發者能夠構建、部署和管理多個 AI 代理共同處理複雜任務。這個功能允許創建專門的代理來處理過程中的不同方面，由一個監督代理協調，拆解請求、分配任務並整合輸出。這種方法提高了任務的成功率、準確性和生產力，特別是在複雜的多步驟任務中。
有關這篇文章中討論的示例代碼和演示，請參考 agentic-orchestration GitHub 倉庫和這個 AWS 工作坊。你也可以參考亞馬遜 Bedrock 多代理協作的代碼範例。
代理服務的主要特徵
在生成式人工智慧的背景下，「代理」指的是一種能夠與環境互動、自主收集數據並做出決策以執行複雜任務以達成預定目標的功能。生成式 AI 代理是自主的、以目標為導向的系統，使用基礎模型（例如大型語言模型 (LLMs)）與環境互動並適應。這些代理在計畫、問題解決和決策方面表現出色，使用鏈式思考提示等技術來拆解複雜任務。它們能夠自我反思、改進過程，並通過使用工具和與其他 AI 模型的合作來擴展其能力。這些代理可以獨立運作或協作執行任務，並在各個領域中持續適應新信息和變化的情況。代理可以提高創造力並大規模生成內容，自動化重複性任務，讓人類能夠專注於戰略性工作，從而減少重複行為並節省成本。以下圖示顯示了解決方案的高級架構。
要在 AWS 上實現一個代理，你可以使用亞馬遜 Bedrock 代理的 Boto3 客戶端，如以下代碼示例所示。在為代理創建所需的 AWS 和身份與訪問管理 (IAM) 角色後，使用 create_agent API。這個 API 需要代理名稱、基礎模型識別碼和指令字符串。可選地，你也可以提供代理描述。創建的代理尚未準備好使用。我們專注於準備代理，然後使用它來調用行動並與其他 API 互動。使用以下代碼示例來獲取你的代理 ID；這對於執行與代理的操作至關重要。
# 使用 Python boto3 SDK 與亞馬遜 Bedrock 代理服務互動
bedrock_agent_client = boto3.client(‘bedrock-agent’)
# 創建一個新的 Bedrock 代理
response = bedrock_agent_client.create_agent(
agentName=
agentResourceRoleArn=
description=
idleSessionTTLInSeconds=1800,
foundationModel=
instruction=
)
agent_id = response[‘agent’][‘agentId’]
多代理管道進行代理間協作
多代理管道是 AI 系統內部的協調過程，涉及多個專門代理共同工作以完成複雜任務。在管道中，代理按照順序結構組織，不同的代理處理整體工作流程中的特定子任務或角色。代理之間相互互動，通常通過共享的「草稿板」或消息系統，允許它們交換信息並在彼此的工作基礎上進行。每個代理保持自己的狀態，隨著流程的進展可以用新信息更新。複雜的項目被拆解為可管理的子任務，然後分配給專門的代理。工作流程包括明確定義的任務協調過程，以促進高效的任務分配和與目標的一致性。這些過程可以管理代理之間的互動和代理內部的操作（例如代理如何與工具互動或處理輸出）。代理可以被分配特定角色（例如檢索者或注入者）來解決問題的不同方面。
作為實際示例，考慮一個用 CrewAI 實現的部落格寫作的多代理管道。要使用 CrewAI 創建多代理管道，首先定義將參與管道的個別代理。以下示例中的代理是計畫代理、寫作代理和編輯代理。接下來，將這些代理安排到管道中，指定任務執行的順序以及數據在它們之間的流動。CrewAI 提供機制讓代理之間傳遞信息並協調行動。CrewAI 的模組化和可擴展設計使其非常適合開發簡單和複雜的多代理 AI 應用程序。以下圖示顯示了這個多代理管道。
from crewai import Agent, Task, Crew, Process
# 創建一個部落格寫作的多代理管道，包括計畫者、寫作和編輯代理
# 這段代碼片段僅顯示計畫者代理，該代理調用網頁搜索工具
# 和亞馬遜 Bedrock 的 LLM
class blogAgents():
def __init__(self, topic, model_id):
self.topic = topic
self.model_id = model_id
def planner(self, topic, model_id):
return Agent(
role=”內容計畫者”,
goal=f”””計畫有趣且事實準確的內容，主題為 {topic}。”””,
backstory=f”””你正在計畫一篇有關主題 {topic} 的部落格文章。\n
你通過在網上搜索最新的發展來收集與 {topic} 直接相關的信息。\n
你幫助觀眾學習一些知識，以便對 {topic} 做出明智的決策。\n
你的工作是內容寫作代理撰寫這篇文章的基礎。”””,
allow_delegation=False,
tools=
llm=
verbose=True
)
……
# 創建與部落格代理任務相關的計畫者、寫作和編輯任務。
# 這段代碼片段僅顯示計畫任務。
class blogTasks():
def __init__(self, topic, model_id):
self.topic = topic
self.model_id = model_id
def plan(self, planner, topic, model_id):
return Task(
description=(
f”””1. 優先考慮 {topic} 的最新趨勢、主要參與者和重要新聞。\n
2. 確定目標受眾，考慮他們的興趣和痛點。\n
3. 制定詳細的內容大綱，包括引言、要點和行動呼籲。\n
4. 包括 SEO 關鍵字和相關數據或來源。”””
),
expected_output=f”””以領域專家的深度傳達 {topic} 的最新發展。\n
創建一份全面的內容計畫文檔，包括大綱、受眾分析、
SEO 關鍵字和資源。”””,
agent=planner
)
……
# 定義計畫者代理和計畫任務
planner_agent = agents.planner(self.topic, self.model_id)
plan_task = tasks.plan(planner_agent, self.topic, self.model_id)
……
# 定義一個代理管道來鏈接代理和相關任務
# 以及服務組件、嵌入引擎和執行過程
crew = Crew(
agents=[planner_agent, writer_agent, editor_agent],
tasks=[plan_task, write_task, edit_task],
verbose=True,
memory=True,
embedder={
“provider”: “huggingface”,
“config”: {“model”: “sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2”},
},
cache=True,
process=Process.sequential # 順序過程將一個接一個地執行任務
)
result = crew.kickoff()
如這個代碼示例所示，多代理管道通常是簡單的線性結構，容易設置和理解。它們有明確的任務流從一個代理到下一個代理，對於有明確操作順序的簡單工作流程效果良好。同時，對於複雜的非線性代理互動，管道結構可能不夠靈活，這使得它不太能處理分支邏輯或循環。這對於需要代理之間來回互動的問題可能效率較低。下一部分將介紹一個多代理系統的圖形框架，更適合處理複雜情況。
多代理圖形框架進行非同步協調和推理
多代理框架提供了智能和動態問題解決的重大潛力，使得協作和專門的任務執行成為可能。雖然這些系統可以通過動態啟用和協調代理來提高推理準確性和響應效率，但它們也帶來了潛在的偏見、有限的推理能力和需要強有力監督的挑戰。有效的多代理框架需要仔細的設計考量，如明確的領導、動態的團隊建設、有效的信息共享、像鏈式思考提示的計畫機制、用於上下文學習的記憶系統，以及專業語言模型的戰略協調。隨著技術的發展，平衡代理的自主性與人類的監督和倫理保障將對於釋放這些智能系統的全部潛力至關重要，同時減少潛在風險。
多代理圖形框架是一種使用基於圖形的表示來建模多個自主代理之間的互動和關係的系統。在這種框架中，代理被表示為圖中的節點，每個代理都有自己的一組能力、目標和決策過程。圖中的邊表示代理之間的互動、通信或依賴關係。這些可以包括信息共享、任務委派、協商或協調。圖形結構允許建模代理之間複雜的動態關係，包括循環、反饋循環和層級關係。以下圖示顯示了這個架構。
基於圖形的方法提供了一種靈活且可擴展的方式來表示多代理系統的結構，使得分析、模擬和推理代理互動所產生的突現行為變得更容易。以下代碼片段說明了使用 LangGraph 構建多代理協調的圖形框架的過程。這個框架對於管理和協調系統內多個代理之間的互動至關重要，促進高效和有效的通信與協作。值得注意的是，它強調了即插即用的特性，允許動態變更和靈活性以容納第三方代理。具有此能力的框架可以無縫適應新需求並與外部系統整合，增強其整體的多功能性和可用性。
from langgraph.graph import StateGraph, END
……
# 創建一個圖形以協調多個代理（即節點）
orch = StateGraph(MultiAgentState)
orch.add_node(“rewrite_agent”, rewrite_node)
orch.add_node(‘booking_assistant’, bedrock_agent_node)
orch.add_node(‘blog_writer’, blog_writer_node)
orch.add_node(“router_agent”, router_node)
orch.add_node(‘search_expert’, search_expert_node)
….
# 創建邊以連接代理形成圖形
orch.set_entry_point(“rewrite_agent”)
orch.add_edge(‘rewrite_agent’, ‘router_agent’)
orch.add_conditional_edges(
“RAG_agent”,
decide_to_search,
{
“to_human”: “human”,
“do_search”: “search_expert”,
},
)
orch.add_edge(‘blog_writer’, ‘text2image_generation’)
……
# 編譯圖形以進行代理協調
graph = orch.compile(checkpointer=memory, interrupt_before = [‘human’])
多代理圖形方法特別適用於需要建模和分析自主實體之間複雜動態互動的領域，例如機器人技術、物流、社交網絡等。多代理圖形方法相對於線性多代理管道方法有多個優點和缺點，以下是總結。
優勢和限制
代理服務的出現代表了一種變革性的系統設計方法。與遵循固定預定工作流程的傳統 AI 模型不同，代理系統的特點在於其能夠實時協作、適應和做出決策。從被動到主動的 AI 轉變為開發者和架構師帶來了令人興奮的機會，也提出了獨特的設計挑戰。代理服務的核心是代理推理的概念，這體現了一種靈活的、迭代的問題解決方法，反映了人類的認知過程。通過整合反思、自我改進和工具利用等設計模式，我們可以開發出能夠持續增強和在各個領域擴展功能的 AI 代理。
儘管代理服務前景廣闊，但仍面臨幾個限制，必須解決這些限制才能成功實施生產。管理多個自主代理的複雜性，尤其是隨著數量和範圍的增加，對於維持系統的一致性和穩定性構成了重大挑戰。此外，這些系統的突現行為可能難以預測和理解，妨礙了透明度和可解釋性，而這對於建立信任和問責至關重要。安全性和穩健性是至關重要的問題，因為意外行為或故障可能會產生深遠的後果，這需要強有力的保障措施和錯誤處理機制。隨著代理服務的擴展，維持高效性能變得越來越具挑戰性，需要優化資源利用和負載平衡。最後，缺乏廣泛採用的標準和協議使得代理系統的互操作性成為問題，這使得將這些服務與現有基礎設施整合變得困難。解決這些限制對於在各個領域廣泛採用和成功實施代理服務至關重要。
優勢：
更靈活的代理互動表示，使用圖形結構
更適合複雜工作流程，具有非線性代理通信
更容易表示代理之間的循環和分支邏輯
潛在地對於大型多代理系統更具可擴展性
更清晰的整體代理系統結構可視化
缺點：
與線性管道相比，初始設置更複雜
可能需要更多的前期規劃來設計圖形結構
可能需要額外的資源使用和更長的響應時間
下一步
在多代理協調的下一階段，我們將重點提升代理的推理、反思和自我修正能力。這涉及開發先進的算法（如思維樹 (ToT) 提示、蒙地卡羅樹搜索 (MCTS) 等），使代理能夠從同伴互動中學習、適應新情況，並根據反饋修正其行為。此外，我們正在努力創建一個可生產的框架，以容納各種代理服務。這個框架將設計得靈活且可擴展，能夠無縫整合不同類型的代理和服務。這些努力目前正在進行中，我們將在下一篇博客文章中提供有關我們進展的詳細更新。敬請期待更多關於我們創新多代理協調方法的見解。
結論
多代理協調和推理代表了生成式 AI 生產採用的一次重大飛躍，提供了前所未有的潛力來解決複雜問題和做出決策，將你的應用與個別基礎模型解耦。也必須承認和解決限制，包括可擴展性挑戰、長延遲和不同代理之間可能的兼容性問題。展望未來，提升我們代理的自我和內部推理、反思和自我修正能力將是重中之重。這將涉及開發更複雜的元認知算法、改善代理間的通信協議，以及實施強有力的錯誤檢測和修正機制。
有關這篇文章中討論的示例代碼和演示，請參考 agentic-orchestration GitHub 倉庫和這個 AWS 工作坊。你也可以參考亞馬遜 Bedrock 多代理協作的代碼範例。
作者感謝 Mark Roy、Maria Laderia Tanke 和 Max Iguer 的深刻貢獻，以及 Nausheen Sayed 的不懈協調。
關於作者
Alfred Shen 是 AWS 的高級生成式 AI 專家。他在矽谷工作，擔任過各種行業的技術和管理職位，包括醫療保健、金融和高科技。他是一位專注於代理解決方案和多模態的應用 AI/ML 研究者。
Anya Derbakova 是 AWS 的高級創業解決方案架構師，專注於醫療保健和生命科學技術。她是北卡羅來納大學的畢業生，曾擔任 Blue Cross Blue Shield 協會的首席開發者。Anya 因其對 AWS 專業發展的貢獻而受到認可，曾在 AWS 開發者播客中亮相並參加多個教育系列。她共同主持了一個六部分的迷你系列，專注於 AWS 認證考試準備，著重於成本優化的雲架構策略。此外，她在「Get Schooled on…Architecting」播客中發揮了重要作用，該播客提供了 AWS 解決方案架構考試的全面準備。
本文由 AI 台灣 運用 AI 技術編撰，內容僅供參考，請自行核實相關資訊。
歡迎加入我們的 AI TAIWAN 台灣人工智慧中心 FB 社團，
隨時掌握最新 AI 動態與實用資訊！
