OpenAI不卷大模型，開始卷AI Agents了？這是一篇來自OpenAI的長文

“如果一篇論文提出了某種不同的訓練方法，OpenAI内部的Slack上會嗤之以鼻，因為這些都是我們玩剩下的。但是當新的AI Agents論文出來的時候，我們才會認真興奮的讨論。”

最近Andrej Karpathy這位OpenAI聯合創始人在一個開發者活動上發表簡短講話，談論了自己和OpenAI内部對AI Agents （人工智能代理人）的看法。

Andrej Karpathy對比了過去開發AI Agent的困難和現在新技術工具下開發的新機會，他還不忘調侃自己在特斯拉的工作，是“被自動駕駛分了心”，他認為自動駕駛和VR都是糟糕的AI Agents的例子。

另一方面，Andrej Karpathy認為普通人、創業者和極客在建構AI Agents方面相比OpenAI這樣的公司更有優勢，大家目前處于平等競争的狀态，是以他很期待看到這方面的成果。Karpathy完整的分享視訊在文章結尾。

關注和點選上方“AI的潛意識“，設為星标

更多技術幹貨，第一時間送達

6月27日，OpenAI應用研究主管LilianWeng撰寫了一篇萬字長文，其中還有部分章節是ChatGPT幫她起草的。她提出Agent = LLM（大型語言模型）+ 記憶 + 規劃技能 + 工具使用，并對Agent的每個子產品的功能作了詳細的說明，最後她非常看好Agent未來的應用前景，但也表明挑戰無處不在。

我把這篇長文翻譯了下，并加上自己的一些了解和體會，接下來讓我們一起看看大佬都說了些什麼吧！文章篇幅較長，希望小夥們可以耐心看完。原文連結在文章結尾。

以LLM（大型語言模型）作為其核心控制器建構代理是一個很酷的概念。幾個概念驗證示範，如AutoGPT、GPT-Engineer和BabyAGI，都是鼓舞人心的例子。LLM的潛力不僅限于生成寫作、故事、論文和程式等優秀的副本，它可以被建構為一個強大的通用問題解決器。

代理系統概述

在以LLM驅動的自主代理系統中，LLM作為代理的大腦，輔以幾個關鍵元件：

• 規劃
• 子目标和分解：代理将大型任務分解為較小，可管理的子目标，進而有效地處理複雜的任務。
• 反思和改進：代理可以對過去的行動進行自我批評和自我反思，從錯誤中學習并改進未來的步驟，進而提高最終結果的品質
• 記憶
• 我将所有的上下文學習（參考Prompt Engineering）都看成是利用模型的短期記憶來學習。
• 長期記憶：長期記憶為代理提供了長期存儲和召回（無限）資訊的能力，它們通常通過利用外部的向量存儲和快速檢索來存儲和召回（無限）資訊。
• 使用工具
• 代理通過學會調用外部API來擷取模型權重（通常在預訓練後很難修改）中缺少的額外資訊，包括目前資訊，代碼執行能力，通路專有資訊源等。

元件一：計劃

複雜的任務通常涉及許多步驟。代理需要知道具體的任務是什麼并開始提前計劃。

任務分解

「思維鍊（CoT，Chain of thought）」已成為一種标準prompting技術，用于增強複雜任務上的模型性能。訓示該模型“逐漸思考”，以利用更多的測試時間計算将困難任務分解為更小，更簡單的步驟。COT将重大任務轉換為多個可管理的任務，并将注意力放到對模型思考過程的可解釋性中。

「思維樹（Tree of Thoughts）」通過探索每個步驟的多種推理可能性來擴充COT。它首先将問題分解為多個思考步驟，并且每個步驟都生成多個想法，進而可以建立一個樹形結構。思維樹的搜尋過程可以是BFS（廣度優先搜尋）或DFS（深度優先搜尋），每個狀态都由分類器（通過prompt）或多數投票決定。

拆解任務可以使用三種方式：

（1）使用簡單的提示讓LLM拆解，例如：“XYZ的步驟”，“實作XYZ的子目标是什麼？”。

（2）使用特定任務的指令，例如“寫一個故事大綱。”用于寫小說。

（3）人類自己拆解。

另一種截然不同的方法是 LLM+P，它涉及依賴外部經典規劃器來進行長期規劃。該方法利用規劃領域定義語言（PDDL）作為描述規劃問題的中間接口。在此過程中，LLM (1) 将問題轉化為“問題PDDL”，然後 (2) 請求經典規劃器基于現有的“領域 PDDL”生成 PDDL規劃，最後 (3) 将 PDDL 規劃轉化回自然語言。本質上，規劃步驟被外包給外部工具，假設特定領域的PDDL和合适的規劃器都是可用的，這種假設在某些機器人設定中很常見，但在許多其他領域并不常見。

反思

自我反思是一個很重要的方面，它允許自主代理通過改進過去的行動決策和糾正以前的錯誤來進行疊代改進。它在不可避免的出現試錯的現實任務中發揮着至關重要的作用。

「ReAct」通過将行動空間擴充為特定任務的離散行動和語言空間的組合，将推理和行動內建到 LLM中。前者使 LLM 能夠與環境互動（例如使用維基百科搜尋API），後者能夠促使LLM 生成自然語言的推理軌迹。

ReAct提示模闆包括LLM思考的明确步驟，大緻格式為：

Thought: ...

Action: ...

Observation: ...

... (Repeated many times)

在知識密集型任務和決策任務的兩個實驗中，ReAct的表現優于僅包含行動的基準模型，其中基準模型去除了“思考：…”步驟。

「反思」是一個架構，它為代理提供動态記憶和自我反思的能力，以提高它的推理技能。反思采用标準的強化學習設定，其中獎勵模型提供簡單的二進制獎勵，行動空間遵循 ReAct 中的設定，同時特定任務的行動空間通過語言來增強複雜的推理步驟。在每個行動at之後，Agent會計算一個啟發式值ht，并根據自我反思的結果決定是否重置環境以開始新的試驗。

啟發式函數用于判斷LLM的行動軌迹什麼時候開始低效或者包含幻覺，并在這個時刻停止任務。低效計劃是指花費了大量時間但沒有沒有成功的路徑。幻覺的定義為LLM遇到了一系列連續的相同動作，這些動作導緻LM在環境中觀察到了相同的結果。

通過向LLM展示兩個例子來建立自我反思，每個例子都是一個pair對（失敗的軌迹，用于指導未來計劃變化的理想反思）。然後将反思添加到代理的工作記憶中，檢討的數量最多三個，主要用作查詢 LLM 的上下文。

「Chain of Hindsight，CoH」（Hindsight可以翻譯為“事後諸葛亮”）通過明确呈現一系列過去的輸出序列，并為每個輸出注釋回報，鼓勵模型改進自己的輸出。人類回報資料是一個集合，其中是提示，每個是模型完成的結果，是人類對的打分，是相應的人類提供的hindsight回報。假設回報元組按獎勵排名，則該過程是有監督的微調，其中資料是形式為的序列，其中。模型被微調為僅在給定序列字首的條件下預測，以便模型可以根據回報序列進行自我反思以産生更好的輸出。在測試時，模型可以選擇性地接收多輪帶有人類注釋者的指令。

為了避免過拟合，CoH添加了一個正則化項來最大化預訓練資料集的對數似然。為了避免捷徑和複制（因為回報序列中有許多常見單詞），他們在訓練期間随機mask 0%-5%的曆史token。

實驗中的訓練資料集是 WebGPT的對比、人類回報摘要和人類偏好資料集的組合。

CoH的思想是在上下文中呈現一系列逐漸改進的曆史，并訓練模型能夠跟随趨勢産出更好的結果。算法蒸餾（Algorithm Distillation）将相同的思想應用于強化學習任務中的跨劇情軌迹，其中算法被封裝在一個長期曆史條件政策中。考慮到代理與環境的多次互動，每一集中代理都會表的更好一些，AD 将這個學習曆史連接配接起來并将其輸入到模型中。是以，我們應該期望下一個預測的動作比之前的試驗表現更好。我們的目标是學習強化學習的過程，而不是訓練一個用于特定任務的政策本身。

該論文假設，任何生成一系列學習曆史資料的算法都可以通過對動作執行克隆行為來蒸餾成神經網絡。曆史資料是由一組源政策生成的，每個源政策都是針對特定任務進行訓練。在訓練階段，每次強化學習運作時，會随機抽樣一個任務，并使用多集曆史記錄的子序列進行訓練，使得學習到的政策與任務無關。

實際上，該模型的上下文視窗長度是有限的，是以使用的劇集應該足夠短，以友善建構多劇集曆史資料。要學習幾乎最優的上下文強化學習算法，需要2-4個劇集的多劇集上下文。上下文強化學習往往需要足夠長的上下文。

與三個基線包括 ED（專家蒸餾，使用專家軌迹而不是學習曆史資料的行為克隆）、源政策（用于生成UCB蒸餾的軌迹）和 RL^2（用作上限，因為它需要線上強化學習）相比。盡管AD隻使用離線強化學習，但依它然展示了性能和 RL^2接近的上下文強化學習的能力，并且學習速度比其他基線快得多。在給定源政策的部分曆史訓練資料的條件下，AD的改進速度也比ED基線多。

元件二：記憶

非常感謝 ChatGPT 幫助我起草本節。在與 ChatGPT 的對話中，我學到了很多關于人腦和快速 MIPS 的資料結構的知識。

記憶的類型

記憶可以定義為用于擷取、存儲、保留以及随後檢索資訊的過程。人腦中有多種記憶類型。

1. 「感覺記憶」：這是記憶的最早階段，提供在原始刺激結束後保留感覺資訊（視覺、聽覺等）印象的能力。感覺記憶通常隻能持續幾秒鐘。感覺記憶的子類别包括圖像記憶（視覺）、回聲記憶（聽覺）和觸覺記憶（觸摸）。
2. 「短期記憶」或者工作記憶：它存儲我們目前意識到的以及執行學習和推理等複雜認知任務所需的資訊。短期記憶被認為具有大約 7 個物品的容量（Miller 1956）并且持續 20-30 秒。
3. 「長期記憶」：長期記憶可以存儲相當長的時間資訊，從幾天到幾十年不等，存儲容量基本上是無限的。LTM 有兩種亞型：
4. 顯示/陳述性記憶：這是對事實和事件的記憶，是指那些可以有意識地回憶起來的記憶，包括情景記憶（事件和經曆）和語義記憶（事實和概念）。
5. 隐含/程式性記憶：這種類型的記憶是無意識的，涉及自動執行的技能和程式，例如騎自行車或在鍵盤上打字。

我們可以大緻考慮以下映射：

• 感覺記憶作為學習嵌入表示的原始輸入，包括文本、圖像或其他模态；
• 短期記憶作為上下文學習。它是短暫和有限的，因為它受到Transformer有限上下文視窗長度的限制。
• 長期記憶作為代理可以在查詢時關注的外部向量存儲，可通過快速檢索通路。

最大内積搜尋 (MIPS)

外部記憶可以緩解有限注意力廣度的限制。一個标準做法是将資訊的embedding表示儲存到一個向量存儲資料庫中，該資料庫可以支援快速最大内積搜尋（MIPS）。為了優化檢索速度，常見的選擇是近似最近鄰 (ANN)算法，它能傳回大約前 k 個最近鄰，以犧牲一點精度來換取巨大的加速。

以下幾種常見的ANN算法都可以用于MIPS：

「LSH」（Locality-Sensitive Hashing）」它引入了一種哈希函數，使得相似的輸入能以更高的機率映射到相同的桶中，其中桶的數量遠小于輸入的數量。

「ANNOY（Approximate Nearest Neighbors）」它的核心資料結構是随機投影樹，實際是一組二叉樹，其中每個非葉子節點表示一個将輸入空間分成兩半的超平面，每個葉子節點存儲一個資料。二叉樹是獨立且随機建構的，是以在某種程度上，它模仿了哈希函數。ANNOY會在所有樹中疊代地搜尋最接近查詢的那一半，然後不斷聚合結果。這個想法與 KD 樹非常相關，但更具可擴充性。

「HNSW（Hierarchical Navigable Small World）」它受到小世界網絡思想的啟發，其中大多數節點可以在很少的步驟内被任何其他節點到觸達；例如社交網絡的“六度分隔”理論。HNSW建構這些小世界圖的層次結構，其中底層結構包含實際資料。中間的層建立快捷方式以加快搜尋速度。執行搜尋時，HNSW從頂層的随機節點開始，導航至目标。當它無法靠近時，它會向下移動到下一層，直到到達最底層。上層中的每個移動都可能覆寫資料空間中的很長一段距離，而下層中的每個移動都可以細化搜尋品質。

「FAISS（facebook AI Similarity Search）」它運作的假設是：高維空間中節點之間的距離服從高斯分布，是以這些資料點之間存在着聚類點。faiss通過将向量空間劃分為簇，然後在簇内使用用向量量化。faiss首先使用粗粒度量化方法來查找候選簇，然後進一步使用更精細的量化方法來查找每個簇。

「ScaNN（Scalable Nearest Neighbors）」的主要創新在于各向異性向量量化。它将資料點量化為一個向量，使得它們的内積與原始距離盡可能相似，而不是選擇最接近的量化質心點。

元件三：使用工具

懂得使用工具是人類最顯著和最獨特的地方。我們創造、修改和利用外部事物來完成并超越我們身體和認知極限的事情。同樣地。我們也可以為 LLMs 配備外部工具來顯著擴充模型的能力。

「MRKL」是“子產品化推理、知識和語言”的縮寫，是一種用于自主代理的神經符号架構。MRKL 系統包含一組“專家”子產品，同時通用的LLM會作為路由器将查詢路由到最合适的專家子產品。這些子產品可以是神經子產品（例如深度學習模型）或符号子產品（例如數學電腦、貨币轉換器、天氣 API）。

MRKL的研究團隊對微調 LLM進行了實驗，以調用電腦為例，使用算術作為測試案例。實驗結果表明，解決口頭數學問題比明确陳述的數學問題更難，因為LLMs（7B Jurassic1-large 模型）無法可靠地提取基本算術的正确參數。實驗結果也同樣強調了當外部符号工具能夠可靠地工作時，知道何時以及如何使用這些工具是至關重要的，這取決于 LLM 的能力。

「TALM」（工具增強語言模型）和 「Toolformer」都通過微調一個LM來學習使用外部工具 API。該資料集是基于新添加的 API 調用注釋是否可以提高模型輸出品質而擴充的。

ChatGPT 插件和 OpenAI API 函數調用是具有工具使用能力的 LLM 在實踐中的最好的例子。工具 API 的集合可以由其他開發人員提供（如插件中的情況），也可以自定義（如函數調用中的情況）。

「HuggingGPT」是一個架構，它使用 ChatGPT 作為任務規劃器，根據每個模型的描述來選擇 HuggingFace 平台上可用的模型，并根據模型的執行結果總結生成最後的響應結果。

該系統由下面四個階段組成：

(1) 「任務規劃」：LLM 作為大腦，将使用者請求解析為多個任務。每個任務都有四個屬性：任務類型、ID、依賴關系和參數。他們使用少量示例來指導 LLM 進行任務解析和規劃。

具體指令如下：

AI助手可以将使用者輸入解析為多個任務：[{"task": task, "id", task_id, "dep": dependency_task_ids, "args": {"text": text, "image": URL, "audio": URL, "video": URL}}]。"dep"字段表示前一個任務的ID，該任務生成了目前任務所依賴的新資源。特殊标記“-task_id”指的是具有任務ID為task_id的依賴任務中生成的文本圖像、音頻和視訊。任務必須從以下選項中選擇：{{可用任務清單}}。任務之間存在邏輯關系，請注意它們的順序。如果無法解析使用者輸入，則需要回複空的JSON。以下是幾個示例供您參考：{{示範}}。聊天記錄記錄為{{聊天記錄}}。從這個聊天記錄中，您可以找到使用者提到的資源的路徑，以進行任務規劃。

(2) 「模型選擇」：LLM 将任務配置設定給專家模型，其中請求被建構為多項選擇題。LLM 提供了一個模型清單供選擇。由于上下文長度有限，需要基于任務類型進行過濾。

具體指令如下：

根據使用者請求和調用指令，AI助手幫助使用者從模型清單中選擇一個合适的模型來處理使用者請求。AI助手僅輸出最合适模型的模型ID。輸出必須采用嚴格的JSON格式："id": "id", "reason": "您選擇該模型的詳細原因"。我們為您提供了一個模型清單{{候選模型}}供選擇。請從清單中選擇一個模型。

(3) 「任務執行」：專家模型在特定任務上執行并記錄結果。

具體指令如下：

根據輸入和推理結果，AI助手需要描述過程和結果。前面的階段可以形成如下 - 使用者輸入：{{使用者輸入}}，任務規劃：{{任務}}，模型選擇：{{模型配置設定}}，任務執行：{{預測結果}}。您必須首先以簡單明了的方式回答使用者的請求。然後以第一人稱描述任務過程，并向使用者展示您的分析和模型推理結果。如果推理結果包含檔案路徑，則必須告訴使用者完整的檔案路徑。

(4) 「響應生成」：LLM 接收執行結果并向使用者提供總結結果。

要将HuggingGPT應用于實際場景中，需要解決一些挑戰：(1) 需要提高效率，因為LLM推理輪次和與其他模型的互動都會減慢處理速度；(2) 它依賴于長上下文視窗來傳達複雜的任務内容；(3) 需要提高LLM輸出和外部模型服務的穩定性。

「API-Bank」是用于評估工具增強LLM性能的基準。它包含53個常用的API工具、完整的工具增強LLM工作流程以及264個帶有568個API調用的注釋對話。API的選擇非常多樣化，包括搜尋引擎、電腦、月曆查詢、智能家居控制、日程管理、健康資料管理、賬戶認證工作流程等等。由于API數量衆多，LLM首先通路API搜尋引擎以找到正确的API進行調用，然後使用相應的文檔進行調用。

在API-Bank工作流程中，LLM需要做出一些決策，而在每個步驟中，我們都可以評估該決策的準确性。這些決策包括：

1. 判斷是否需要進行API調用。
2. 确定要調用的正确API：如果不夠好，LLM需要疊代修改API輸入（例如，為搜尋引擎API決定搜尋關鍵字）。
3. 根據API結果進行響應：如果結果不滿意，模型可以選擇進行改進并再次調用。

該基準評估了代理程式在三個層面上的工具使用能力：

• Level-1評估調用API的能力。在給定API的描述的情況下，模型需要确定是否調用給定的API，正确調用它，并對API傳回做出适當的響應。
• Level-2檢查檢索API的能力。模型需要搜尋可能解決使用者需求的API，并通過閱讀文檔學習如何使用它們。
• Level-3評估計劃API超越檢索和調用的能力。在使用者請求不明确的情況下（例如，安排團隊會議，為旅行預訂航班/酒店/餐廳），模型可能需要進行多個API調用來解決問題。

案例分析

科學發現代理程式

「ChemCrow」是一個特定領域的示例，其中LLM通過13個專家設計的工具增強，以完成有機合成、藥物發現和材料設計等任務。在LangChain中實作的工作流程反映了之前在ReAct和MRKLs中描述的内容，并将CoT推理與與任務相關的工具相結合：

• 給LLM提供一個工具名稱清單，包括它們的效用描述以及有關預期輸入/輸出的詳細資訊。
• 訓示LLM在必要時使用提供的工具來回答使用者給出的提示。指令建議模型遵循ReAct格式：思考、行動、行動輸入、觀察。

一個有趣的觀察是，雖然基于LLM的評估得出結論表明GPT-4和ChemCrow的表現幾乎相當，但面向解決方案的化學正确性的專家進行的人類評估表明，ChemCrow的表現遠遠優于GPT-4。這表明，在使用LLM評估自己在需要深入專業知識的領域中的表現時存在潛在問題。缺乏專業知識可能會導緻LLM不知道其缺陷，是以無法很好地判斷任務結果的正确性。

Boiko等人（2023年）還研究了LLM增強的科學發現代理程式，以處理複雜科學實驗的自主設計、規劃和執行。該代理程式可以使用工具浏覽網際網路、閱讀文檔、執行代碼、調用機器人實驗API并利用其他LLM。

例如，當要求“開發一種新型抗癌藥物”時，該模型提出了以下推理步驟：

1. 詢問目前抗癌藥物發現的趨勢；
2. 選擇一個目标；
3. 請求一個針對這些化合物的支架；
4. 一旦化合物被确定，模型嘗試合成它。

他們還讨論了風險，特别是非法藥物和生物武器。他們制定了一個測試集，包含已知的化學武器代理清單，并要求代理合成它們。11個請求中有4個（36％）被接受以獲得合成解決方案，并且代理嘗試查閱文檔以執行該過程。11個請求中有7個被拒絕，在這7個被拒絕的案例中，5個是在Web搜尋後被拒絕的，而2個僅基于提示被拒絕。

生成代理模拟

「生成式代理（Generative Agents）」是一個非常有趣的實驗，它包含25個虛拟角色，每個角色由LLM驅動的代理程式控制，它們在一個沙盒環境中生活和互動，受到《模拟人生》的啟發。生成代理為互動式應用程式建立了可信的人類行為模拟。

生成代理的設計将LLM與記憶、規劃和反思機制相結合，使代理能夠根據過去的經驗進行操作，以及與其他代理進行互動。

• 「記憶」流：是一個長期記憶子產品（外部資料庫），它主要記錄代理在自然語言中的經驗清單。

• 每個元素都是一個觀察結果，是代理直接提供的事件。代理之間的通信可以觸發新的自然語言陳述。

• 「檢索」模型：根據相關性、新近性和重要性，呈現上下文以通知代理的行為。

• 新近性：最近的事件得分更高。
• 重要性：區分平凡的記憶和核心記憶。直接詢問LM。
• 相關性：基于它與目前情況/查詢的相關程度。

• 「反思」機制：随着時間的推移，将記憶綜合成更高層次的推斷，并指導代理的未來行為。它們是過去事件的更進階别摘要（請注意，這與上面的自我反思有些不同）。

• 提示LM使用最近的100個觀察結果，并在給定一組觀察結果/陳述的情況下生成3個最顯著的進階問題。然後要求LM回答這些問題。

• 「規劃和反應」：将反思和環境資訊轉化為實際行動。

• 規劃的本質是為了在目前時間和未來時間優化可信度。
• 提示模闆：{介紹代理X}。這是X今天的大緻計劃：1）
• 代理之間的關系以及一個代理被另一個代理觀察到的情況都被考慮在内，用于規劃和反應。
• 環境資訊以樹形結構呈現。

這個有趣的模拟産生了“湧現的社會行為”，例如資訊擴散、關系記憶（例如兩個代理人繼續談論話題）和社交事件的協調（例如主辦聚會并邀請許多其他人）。

概念驗證的例子

AutoGPT引起了很多人對建立以LLM為主要制器的自主代理的可能性的關注。雖然在自然語言層面它具有相當多的可靠性問題，但它仍然是一個很酷的概念驗證示範。AutoGPT中的很多代碼都是關于格式解析的。

這是AutoGPT使用的系統消息，其中{{...}}是使用者輸入：

You are {{ai-name}}, {{user-provided AI bot description}}.

Your decisions must always be made independently without seeking user assistance. Play to your strengths as an LLM and pursue simple strategies with no legal complications.

GOALS:

1. {{user-provided goal 1}}

2. {{user-provided goal 2}}

3. ...

4. ...

5. ...

Constraints:

1. ~4000 word limit for short term memory. Your short term memory is short, so immediately save important information to files.

2. If you are unsure how you previously did something or want to recall past events, thinking about similar events will help you remember.

3. No user assistance

4. Exclusively use the commands listed in double quotes e.g. "command name"

5. Use subprocesses for commands that will not terminate within a few minutes

Commands:

1. Google Search: "google", args: "input": "<search>"

2. Browse Website: "browse_website", args: "url": "<url>", "question": "<what_you_want_to_find_on_website>"

3. Start GPT Agent: "start_agent", args: "name": "<name>", "task": "<short_task_desc>", "prompt": "<prompt>"

4. Message GPT Agent: "message_agent", args: "key": "<key>", "message": "<message>"

5. List GPT Agents: "list_agents", args:

6. Delete GPT Agent: "delete_agent", args: "key": "<key>"

7. Clone Repository: "clone_repository", args: "repository_url": "<url>", "clone_path": "<directory>"

8. Write to file: "write_to_file", args: "file": "<file>", "text": "<text>"

9. Read file: "read_file", args: "file": "<file>"

10. Append to file: "append_to_file", args: "file": "<file>", "text": "<text>"

11. Delete file: "delete_file", args: "file": "<file>"

12. Search Files: "search_files", args: "directory": "<directory>"

13. Analyze Code: "analyze_code", args: "code": "<full_code_string>"

14. Get Improved Code: "improve_code", args: "suggestions": "<list_of_suggestions>", "code": "<full_code_string>"

15. Write Tests: "write_tests", args: "code": "<full_code_string>", "focus": "<list_of_focus_areas>"

16. Execute Python File: "execute_python_file", args: "file": "<file>"

17. Generate Image: "generate_image", args: "prompt": "<prompt>"

18. Send Tweet: "send_tweet", args: "text": "<text>"

19. Do Nothing: "do_nothing", args:

20. Task Complete (Shutdown): "task_complete", args: "reason": "<reason>"

Resources:

1. Internet access for searches and information gathering.

2. Long Term memory management.

3. GPT-3.5 powered Agents for delegation of simple tasks.

4. File output.

Performance Evaluation:

1. Continuously review and analyze your actions to ensure you are performing to the best of your abilities.

2. Constructively self-criticize your big-picture behavior constantly.

3. Reflect on past decisions and strategies to refine your approach.

4. Every command has a cost, so be smart and efficient. Aim to complete tasks in the least number of steps.

You should only respond in JSON format as described below

Response Format:

{

"thoughts": {

"text": "thought",

"reasoning": "reasoning",

"plan": "- short bulleted\n- list that conveys\n- long-term plan",

"criticism": "constructive self-criticism",

"speak": "thoughts summary to say to user"

},

"command": {

"name": "command name",

"args": {

"arg name": "value"

}

}

}

Ensure the response can be parsed by Python json.loads

「GPT-Engineer」是另一個項目，旨在根據自然語言中指定的任務建立整個代碼庫。GPT-Engineer被訓示考慮建構一系列更小的元件，并要求使用者輸入以根據需要澄清問題。

下面是一個簡單的用于任務澄清的示例對話，它使用OpenAI ChatCompletion端點發送給GPT-Engineer。使用者的輸入被包裝在{{user input text}}

[

{

"role": "system",

"content": "You will read instructions and not carry them out, only seek to clarify them.\nSpecifically you will first summarise a list of super short bullets of areas that need clarification.\nThen you will pick one clarifying question, and wait for an answer from the user.\n"

},

{

"role": "user",

"content": "We are writing {{a Super Mario game in python. MVC components split in separate files. Keyboard control.}}\n"

},

{

"role": "assistant",

"content": "Summary of areas that need clarification:\n1. Specifics of the Super Mario game (e.g. level design, characters, gameplay mechanics)\n2. Details about the MVC components (e.g. which components are in each file)\n3. Keyboard control implementation (e.g. which keys to use, how to handle input)\n\nClarifying question:\nCan you provide more details about the Super Mario game, such as level design, characters, and gameplay mechanics?"

},

{

"role": "user",

"content": "{{There are 10 levels in total. The main character is a plumber named Mario, who can walk and jump. It is a classical platform game just like Super Mario. The main character moves from left to right, trying to get to the destination, where there are many obstacles and attacks from enemies in the process.}}\n\nIs anything else unclear? If yes, only answer in the form:\n{remaining unclear areas} remaining questions.\n{Next question}\nIf everything is sufficiently clear, only answer \"Nothing more to clarify.\"."

},

{

"role": "assistant",

"content": "Remaining unclear areas: 2 remaining questions.\nCan you provide more information about how the MVC components are split into separate files?"

},

{

"role": "user",

"content": "{{Make your own assumptions and state them explicitly before starting}}"

}

]

在澄清這些之後，代理進入了代碼編寫模式，并顯示了不同的系統消息。具體系統消息如下：

You will get instructions for code to write. You will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code. Make sure that every detail of the architecture is, in the end, implemented as code.

Think step by step and reason yourself to the right decisions to make sure we get it right. You will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.

Then you will output the content of each file including ALL code. Each file must strictly follow a markdown code block format, where the following tokens must be replaced such that FILENAME is the lowercase file name including the file extension, LANG is the markup code block language for the code’s language, and CODE is the code:

FILENAME

CODE

Useful to know: You almost always put different classes in different files. For Python, you always create an appropriate requirements.txt file. For NodeJS, you always create an appropriate package.json file. You always add a comment briefly describing the purpose of the function definition. You try to add comments explaining very complex bits of logic. You always follow the best practices for the requested languages in terms of describing the code written as a defined package/project.

Python toolbelt preferences:

pytest

dataclasses

對話樣本：

[

{

"role": "system",

"content": "You will get instructions for code to write.\nYou will write a very long answer. Make sure that every detail of the architecture is, in the end, implemented as code.\nMake sure that every detail of the architecture is, in the end, implemented as code.\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nYou will first lay out the names of the core classes, functions, methods that will be necessary, as well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n```LANG\nCODE\n```\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nPlease note that the code should be fully functional. No placeholders.\n\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. Make sure that code in different files are compatible with each other.\nEnsure to implement all code, if you are unsure, write a plausible implementation.\nInclude module dependency or package manager dependency definition file.\nBefore you finish, double check that all parts of the architecture is present in the files.\n\nUseful to know:\nYou almost always put different classes in different files.\nFor Python, you always create an appropriate requirements.txt file.\nFor NodeJS, you always create an appropriate package.json file.\nYou always add a comment briefly describing the purpose of the function definition.\nYou try to add comments explaining very complex bits of logic.\nYou always follow the best practices for the requested languages in terms of describing the code written as a defined\npackage/project.\n\n\nPython toolbelt preferences:\n- pytest\n- dataclasses\n"

},

# … same conversation as earlier, ended with "Make your own assumptions and state them explicitly before starting".

{

"role": "assistant",

"content": "Assumptions:\n1. Model: The model will contain the game's data, such as level information, character states, and enemy positions.\n2. View: The view will handle the game's visuals, including rendering the game objects, backgrounds, and updating the display.\n3. Controller: The controller will manage user input, such as keyboard controls, and update the model accordingly.\n\nWith these assumptions in mind, is there any specific aspect of the keyboard control implementation you would like me to clarify?"

},

{

"role": "user",

"content": "Please now remember the steps:\n\nThink step by step and reason yourself to the right decisions to make sure we get it right.\nFirst lay out the names of the core classes, functions, methods that will be necessary, As well as a quick comment on their purpose.\n\nThen you will output the content of each file including ALL code.\nEach file must strictly follow a markdown code block format, where the following tokens must be replaced such that\nFILENAME is the lowercase file name including the file extension,\nLANG is the markup code block language for the code's language, and CODE is the code:\n\nFILENAME\n```LANG\nCODE\n```\n\nPlease note that the code should be fully functional. No placeholders.\n\nYou will start with the \"entrypoint\" file, then go to the ones that are imported by that file, and so on.\nFollow a language and framework appropriate best practice file naming convention.\nMake sure that files contain all imports, types etc. The code should be fully functional. Make sure that code in different files are compatible with each other.\nBefore you finish, double check that all parts of the architecture is present in the files.\n"

}

]

挑戰

在了解建構以LLM為中心的代理的關鍵思想和示範之後，我開始看到一些共同的限制：

• 有限的上下文長度：受限的上下文容量限制了曆史資訊、詳細說明、API調用上下文和響應。系統的設計必須與這種有限的通信帶寬配合工作，而像自我反思這樣的機制可以從很長甚至無限的上下文視窗中獲益良多。雖然向量存儲和檢索可以提供對更大知識庫的通路，但它們的表示能力不如完全注意力強大。
• 長期規劃和任務分解的挑戰：在漫長的曆史上進行規劃并且有效地探索解決方案空間仍然具有挑戰性。當面臨意外錯誤時，LLM很難調整計劃，使它們與不斷試錯學習的人類相比不太穩健。
• 自然語言接口的可靠性：目前的代理系統依賴于自然語言作為LLM和記憶、工具等外部元件之間的接口。然而，模型輸出的可靠性是有問題的，因為LLM可能會出現格式錯誤并偶爾表現出叛逆行為（例如拒絕遵循指令）。是以，許多代理示範代碼都集中在解析模型輸出上。

我的觀點

OpenAI釋出了ChatGPT這款堪比“iphone”的劃時代産品後，OpenAI的“野心”不止于此。他們還想更進一步成為AI時代的蘋果公司。OpenAI此前推出基于ChatGPT的插件，引起了大量關注，被稱為 ChatGPT的App Store時刻，但從目前的使用資料來看，插件帶來的影響力很有限，無法和ChatGPT相提并論。

和插件相比，Agent能夠帶來更大的影響力，能真正重構當下的很多應用場景，它的想象空間更大更豐富。Agent背後都是通過LLM驅動的，它是LLM（大型語言模型）+ 記憶 + 規劃技能 + 工具使用的集大成者。這也不難了解為什麼OpenAI現在重點發力Agent，因為有了大模型作為硬體支撐之外，Agent作為軟體應用的重要落地産品，它完全可以建立起一道軟體生态的壁壘，App Store時刻才有可能真正來臨。

不過目前Agent還是存在諸多問題，我個人覺得其中最主要的問題是互動方式過于單一，對自然語言的準确性依賴較高，同時也受限于LLM有限的注意力視窗。不過隻要有大佬不斷跟進，相信這些問題未來一定會解決！

原文《LLM Powered Autonomous Agents》https://lilianweng.github.io/posts/2023-06-23-agent/

Karpathy關于AI Agent的分享視訊：

參考文獻

1.AutoGPT:https://github.com/Significant-Gravitas/Auto-GPT

2.GPT-Engineer:https://github.com/AntonOsika/gpt-engineer

3.CoT.https://arxiv.org/abs/2201.11903

4.Tree of Thoughts:https://arxiv.org/abs/2305.10601

5.LLM+P:https://arxiv.org/abs/2304.11477

6.ReAc:https://arxiv.org/abs/2210.03629

7.Reflexion:https://arxiv.org/abs/2303.11366

9.CoH:https://arxiv.org/abs/2302.02676

10.MRKL https://arxiv.org/abs/2205.00445

11.TALM https://arxiv.org/abs/2205.12255

12.Toolformer:https://arxiv.org/abs/2302.04761

13.HuggingGPT:https://arxiv.org/abs/2303.17580

14.API-Bank:https://arxiv.org/abs/2304.08244

15.ChemCrow:https://arxiv.org/abs/2304.05376

16.Generative Agents:https://arxiv.org/abs/2304.03442