嘿，大家好！這里是一個專注于AI智能體的頻道！

今天跟大家聊一些關于Agent發展的事情。如果說去年是RAG的元年，大家都在naive RAG中添加各種技巧，使其變成Adavanced RAG。今年應該就是Agent的元年，年初RAG的迭代變成了Agentic RAG的發展方向，上半年Agent、Agentic、workflow等名詞的爆火。當然后來到年終，RAG炒作到了RAG2.0、GraphRAG等上面，最近的RAG炒作變成了MemoryRAG，或者RAG已死等等相關的~

盡管智能體Agent很熱門，但它們真的很難，很少有Agent能夠在消費者或企業用戶中取得成功。

Agent的定義：基于LLM的Agent是將多個處理步驟（包括對LLMs的調用）串聯在一起的系統，以實現所需的最終結果。Agent通常具有一定量的條件邏輯或決策能力，以及他們可以在步驟之間訪問的長短期記憶。

初代Agent：Agent的想法其實蠻早的，去年外網上經常能看到Agent的身影，表示他們的系統有多牛掰。初代的Agent主要是基于ReAct的架構，這個架構比較抽象，完全由引擎LLM來主導。引擎做出決策，工具調用完的結果回到引擎。他這種非常非常極端的抽象，導致他很難落地使用。盡管理論很美好，但是現實擊垮了理想。

一年中，無數的人，企業再探索下一代Agent是什么？一個新的構建原則是，用更清晰的方式定義出業務流程，定義出可能的路徑。而不是ReAct的那種完全的開放性。

不論是否使用外部的Agent框架，我們可以看到整個解決方案空間變小的一個趨勢，也就是說每個Agent可以做的事情更少了，也就意味著更容易定義出Agent。反過來這種模式能產生更強大的Agent。

Agent的組成形式：大多數的Agent都有一個路由-Route的模塊/組件，用于決定agent下一步應采取的步驟。通常用LLM或分類器來充當，它對要采取的路徑做出意圖判斷。 agent在執行過程中可能會不斷返回到該路由組件，每次都會帶來一些更新的信息。路由將獲取該信息，將其與可能的后續步驟的現有知識相結合，并選擇下一步要采取的操作。

Agent采取的后續操作通常由一個組件來表示，組件可能是一個代碼塊?？赡軙{用多次LLM，甚至是一個復雜的業務流程。

最簡單的Agent形式，我們只有一個路由，決定調用哪個工具或函數，循環迭代。

高級的Agent, 路由的調用不在是一個簡單的工具或函數了，可能包含更復雜的組件，更深層次的鏈式調用。這是目前生產場景下最常見的形式。

如果將LLM調用的分支，工具，狀態混在一起，結構會變得更加的復雜。下圖，路由決定調用哪些技能來回答用戶的問題。它也可能根據這個問題更新共享狀態。每項技能還可以訪問共享狀態，并且可能進行一個或多個LLM調用實現對用戶的回復。

最后幾個問題：

應該使用框架來開發Agent嗎？例如langgraph、llamaindex

因為我們自己構建了一個助手。我們的助手使用多層路由架構，其分支和步驟與當前框架的一些抽象相呼應。在 LangGraph 穩定之前，我們就開始構建我們的助手。因此，我們不斷地問自己：如果我們從頭開始，我們會使用當前的框架抽象嗎？他們能勝任這項任務嗎？

目前的答案還沒有。整個系統過于復雜，不適合基于 Pregel 的架構。如果你粗看，可以將它映射到節點和邊緣，但軟件抽象可能會妨礙整體的開發。就目前情況而言，我們更傾向于更喜歡代碼實現而不是框架。

然而，我們也看到了agent框架方法的價值。它們也在不斷變得更好，擴大它們的用處以及可以用它們做什么。隨著這些框架的改進，我們未來可能會進行遷移。

你真的需要Agent嗎？哪些類型的應用需要Agent？

常見的有3個標準：

• 應用是否是基于輸入數據，然后進行迭代的流程？
• 應用是否需要根據之前采取的操作或反饋，來適應和遵循不同的流程？
• 是否存在可以采取的行動的狀態空間？狀態空間可以通過多種方式遍歷，而不僅僅限于線性路徑。

構建Agent，可能會面臨哪些問題？

首先是長遠的規劃。盡管理想中的Agent很強大，但他們仍然難以將復雜的任務分解為邏輯計劃。更難的是，他們還會陷入循環，阻礙他們找到解決方案。另外一個常見的就是工具調用時候的格式錯誤。這些通常是因為LLM的能力限制，可能還需要一定的人工干預來糾正方向。

另一個需要注意的問題是由于解決方案空間巨大而導致性能問題。 agent可以采取的可能行動和路徑數量龐大，因此很難獲得一致的結果，并且往往讓成本變高。所以目前都傾向于受限智能體，它們只能從一組可能的行動中進行選擇，從而有效地限制了解決方案的空間。

本文轉載自 ??探索AGI??，作者： 獼猴桃