如果你詢問任何正在使用大型語言模型（LLM）構建智能代理的開發(fā)者，他們很可能會告訴你，智能代理在規(guī)劃和推理方面的不足是影響其可靠性的一個主要問題。

• 智能代理的規(guī)劃究竟是什么？
• 目前人們是如何克服這一缺陷的？
• 我們對智能代理未來規(guī)劃和推理的發(fā)展趨勢有何預測？

接下來的文章將一一解答這些問題。

編輯注：本文經(jīng)翻譯并二次整理自planning-for-agents一文。

規(guī)劃和推理的真正含義是什么？

智能代理的規(guī)劃和推理，指的是它如何思考并決定采取哪些行動，這既包括短期行動也包括長期行動。LLM需要評估所有可用信息，然后決定需要采取哪些步驟，以及當前應該首先執(zhí)行哪一步。

大多數(shù)情況下，開發(fā)者會使用函數(shù)調(diào)用技術來讓LLM選擇要執(zhí)行的行動。這項技術最初由OpenAI在2023年6月引入，隨后在2023年末至2024年初被其他公司采納。通過函數(shù)調(diào)用，開發(fā)者可以為不同的函數(shù)提供JSON格式的模式，并讓LLM生成符合這些模式的對象。

函數(shù)調(diào)用主要用于讓智能代理選擇立即要執(zhí)行的行動。然而，要成功完成一個復雜的任務，通常需要按照順序執(zhí)行一系列行動。對于LLM來說，進行長期規(guī)劃和推理是一項更具挑戰(zhàn)性的任務，原因有二：首先，LLM需要考慮一個長期目標，然后迅速回到需要立即執(zhí)行的短期行動；其次，隨著智能代理執(zhí)行的行動越來越多，這些行動的結果會反饋給LLM，導致上下文窗口擴大，可能會使LLM分心，影響其性能。

和LLM世界中的大多數(shù)事物一樣，很難準確衡量當前模型在規(guī)劃和推理方面的表現(xiàn)。有一些合理的基準測試，比如Berkeley Function Calling Leaderboard，用于評估函數(shù)調(diào)用的能力。我們也進行了一些研究，以評估多步驟應用的效果。但最好的方法是為你的特定問題構建一個評估集，并嘗試自己進行評估。

??根據(jù)經(jīng)驗，我們可以得出一個普遍的結論：規(guī)劃和推理目前還沒有達到現(xiàn)實世界任務所需的水平。

如何改進智能代理的規(guī)劃能力？

改進智能代理規(guī)劃能力的一個簡單方法是確保LLM擁有進行合理規(guī)劃和推理所需的所有必要信息。雖然這聽起來很基礎，但實際上，傳入LLM的提示往往沒有包含足夠的信息。增加一個檢索步驟或澄清提示指令，可以輕松地實現(xiàn)改進。這就是為什么實際查看數(shù)據(jù)并了解LLM實際看到的內(nèi)容至關重要。

接下來，我建議你嘗試改變你的應用程序的認知架構。這里所說的“認知架構”，指的是你的應用程序用于推理的數(shù)據(jù)工程邏輯。你可以考慮兩種類型的認知架構來提高推理能力：通用認知架構和特定領域認知架構。

通用認知架構與特定領域認知架構

通用認知架構試圖以一種通用的方式實現(xiàn)更好的推理，可以應用于任何任務。例如，“計劃和解決”架構，這篇論文提出了一種先制定計劃，然后執(zhí)行計劃中每個步驟的架構。另一個例子是Reflexion架構，這篇論文探討了在智能代理完成任務后增加一個明確的“反思”步驟，以評估任務是否完成得當。

盡管這些想法顯示出了一定的改進，但它們通常對于生產(chǎn)環(huán)境中的智能代理來說過于通用。相反，我們看到智能代理通常采用特定領域的認識架構。這通常體現(xiàn)在特定領域的分類/路由步驟、特定領域的驗證步驟等方面。一些關于規(guī)劃和反思的通用思想可以在這里應用，但它們通常是以特定領域的方式應用的。

以AlphaCodium論文為例，它通過使用所謂的“流程工程”（談論認知架構的另一種方式），實現(xiàn)了最先進的性能。下面是一個他們使用的流程圖。

AlphaCodium流程圖

這個流程非常特定于他們試圖解決的問題。他們告訴智能代理按步驟做什么 - 想出測試，然后想出解決方案，然后迭代更多的測試等。這種認知架構高度特定于領域 - 它不會幫助您寫文章，例如。

為什么特定領域認知架構如此有幫助？

我傾向于從兩個角度來看待這個問題。

首先：你可以將這視為向智能代理傳達它應該做什么的另一種方法。你可以通過提示指令或在代碼中硬編碼特定的轉換來傳達指令。任何一個都是有效的！代碼是極好的傳達你想要發(fā)生的事情的方式。

其次：這本質上是從我們作為工程師的角度，將規(guī)劃責任從LLM中移除。我們基本上是在說：“不用擔心規(guī)劃，LLM，我會為你做的！”當然，我們并沒有從LLM中移除所有的規(guī)劃，因為我們?nèi)匀灰笏谀承┣闆r下進行一些規(guī)劃。

例如，讓我們回顧一下上面的AlphaCodium示例。流程中的步驟基本上是我們?yōu)長LM做的規(guī)劃！我們告訴它首先編寫測試，然后編寫代碼，然后運行測試等。這可能是作者認為編寫軟件的好計劃。如果他們正在計劃如何解決一個問題，這就是他們會怎么做的。而不是在提示中告訴LLM - 它可能會忽略它，不理解它，沒有所有細節(jié) - 他們通過構建特定領域的認識架構來告訴系統(tǒng)要做什么。

??我們看到的幾乎所有高級“智能代理”實際上都有一個非常特定領域和自定義的認知架構。

我們正在使用LangGraph使構建這些自定義認知架構變得更容易。LangGraph的一個主要關注點是可控性。我們設計LangGraph非常低級和高度可控 - 這是因為我們看到這種可控性是100%需要創(chuàng)建可靠的自定義認知架構。

規(guī)劃和推理的未來會是什么樣子？

LLM領域一直在迅速變化和發(fā)展，我們在構建應用程序時，尤其是構建工具時，應該牢記這一點。

我目前的立場是，通用推理將越來越多地被吸收到模型層中。模型將變得越來越智能，無論是通過規(guī)模還是研究突破 - 似乎很愚蠢去反對這一點。模型也會變得更快，更便宜，所以將大量上下文傳遞給它們將變得越來越可行。

然而，我相信無論模型變得多么強大，你總是需要以某種形式向智能代理傳達它應該做什么。因此，我相信提示和自定義架構將一直存在。對于簡單任務，提示可能就足夠了。對于更復雜的任務，您可能希望將它應該如何行為的邏輯放在代碼中。代碼優(yōu)先方法可能更快，更可靠，更易于調(diào)試，并且通常更容易/更符合邏輯地表達。

我最近在播客上與Sequoia的Sonya和Pat討論了這個話題。他們畫了一個很好的圖表，展示了提示、認知架構和模型的角色/重要性可能如何隨時間演變。

圖片

所以，盡管LLM的規(guī)劃和推理肯定會變得更好，我們也堅信，如果您正在構建特定任務的智能代理，那么您將需要構建一個自定義認知架構。

本文轉載自 ??AI小智??，作者： AI小智