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

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

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

Agent的定義：基于LLM的Agent是將多個(gè)處理步驟（包括對(duì)LLMs的調(diào)用）串聯(lián)在一起的系統(tǒng)，以實(shí)現(xiàn)所需的最終結(jié)果。Agent通常具有一定量的條件邏輯或決策能力，以及他們可以在步驟之間訪問的長短期記憶。

初代Agent：Agent的想法其實(shí)蠻早的，去年外網(wǎng)上經(jīng)常能看到Agent的身影，表示他們的系統(tǒng)有多牛掰。初代的Agent主要是基于ReAct的架構(gòu)，這個(gè)架構(gòu)比較抽象，完全由引擎LLM來主導(dǎo)。引擎做出決策，工具調(diào)用完的結(jié)果回到引擎。他這種非常非常極端的抽象，導(dǎo)致他很難落地使用。盡管理論很美好，但是現(xiàn)實(shí)擊垮了理想。

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

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

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

Agent采取的后續(xù)操作通常由一個(gè)組件來表示，組件可能是一個(gè)代碼塊。可能會(huì)調(diào)用多次LLM，甚至是一個(gè)復(fù)雜的業(yè)務(wù)流程。

最簡單的Agent形式，我們只有一個(gè)路由，決定調(diào)用哪個(gè)工具或函數(shù)，循環(huán)迭代。

高級(jí)的Agent, 路由的調(diào)用不在是一個(gè)簡單的工具或函數(shù)了，可能包含更復(fù)雜的組件，更深層次的鏈?zhǔn)秸{(diào)用。這是目前生產(chǎn)場景下最常見的形式。

如果將LLM調(diào)用的分支，工具，狀態(tài)混在一起，結(jié)構(gòu)會(huì)變得更加的復(fù)雜。下圖，路由決定調(diào)用哪些技能來回答用戶的問題。它也可能根據(jù)這個(gè)問題更新共享狀態(tài)。每項(xiàng)技能還可以訪問共享狀態(tài)，并且可能進(jìn)行一個(gè)或多個(gè)LLM調(diào)用實(shí)現(xiàn)對(duì)用戶的回復(fù)。

最后幾個(gè)問題：

應(yīng)該使用框架來開發(fā)Agent嗎？例如langgraph、llamaindex

因?yàn)槲覀冏约簶?gòu)建了一個(gè)助手。我們的助手使用多層路由架構(gòu)，其分支和步驟與當(dāng)前框架的一些抽象相呼應(yīng)。在 LangGraph 穩(wěn)定之前，我們就開始構(gòu)建我們的助手。因此，我們不斷地問自己：如果我們從頭開始，我們會(huì)使用當(dāng)前的框架抽象嗎？他們能勝任這項(xiàng)任務(wù)嗎？

目前的答案還沒有。整個(gè)系統(tǒng)過于復(fù)雜，不適合基于 Pregel 的架構(gòu)。如果你粗看，可以將它映射到節(jié)點(diǎn)和邊緣，但軟件抽象可能會(huì)妨礙整體的開發(fā)。就目前情況而言，我們更傾向于更喜歡代碼實(shí)現(xiàn)而不是框架。

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

你真的需要Agent嗎？哪些類型的應(yīng)用需要Agent？

常見的有3個(gè)標(biāo)準(zhǔn)：

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

構(gòu)建Agent，可能會(huì)面臨哪些問題？

首先是長遠(yuǎn)的規(guī)劃。盡管理想中的Agent很強(qiáng)大，但他們?nèi)匀浑y以將復(fù)雜的任務(wù)分解為邏輯計(jì)劃。更難的是，他們還會(huì)陷入循環(huán)，阻礙他們找到解決方案。另外一個(gè)常見的就是工具調(diào)用時(shí)候的格式錯(cuò)誤。這些通常是因?yàn)長LM的能力限制，可能還需要一定的人工干預(yù)來糾正方向。

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

本文轉(zhuǎn)載自 ??探索AGI??，作者： 獼猴桃