Agent 領域的競爭正在變激烈。在過去一年中，許多 Agent 框架變得普及：例如使用 ReAct 結合 LLM 進行推理和行動、使用 multi-agent 框架進行編排，或者是使用類似 LangGraph 這樣更可控的框架。

關於 Agent 的討論並不全是 Twitter 上的炒作。大約 51%的受訪者目前正在生產中使用 Agent。根據 Langchain 按公司規模的資料，100-2000 員工的中型公司在 Agent 投入生產方面最為積極，比例達到63%。

此外，78%的受訪者有在近期內將採用將 Agent 投入生產的計劃。很明顯，大家對 AI Agent 有很強烈的興趣，但實際要做好一個 production-ready 的 Agent 對許多人來說仍然是一個難題。

儘管技術行業通常被認為是早期的 Agent 使用者，但所有行業對 Agent 的興趣都在與日俱增。在非技術公司工作的受訪者中，有90%已經或計劃將Agent投入生產（與技術公司的比例幾乎相同，為89%）。

Agent 最常用的 use case 包括進行研究和總結（58%），其次是透過定製化的 Agent 簡化工作流程 （53.5%）。

這些反映了人們希望有產品來處理那些過於消耗時間的任務。使用者可以依賴 AI Agent 從大量資訊中提取關鍵資訊和見解，而不是自己從海量的資料中篩選，再進行資料回顧或研究分析。同樣，AI Agent 可以透過協助日常任務來提升個人生產力，使使用者能夠專注於重要事項。

不僅個人需要這種效率的提升，公司和團隊也同樣需要。客服（45.8%）是 Agent的另一個主要應用領域，Agent 幫助公司處理諮詢、故障排除，並加快跨團隊的客戶響應時間；排在第四、第五位的是更底層的 code 和 data 應用。

隨著 Agent 實現功能變得更加強大，就需要管理和監控 Agent 的方法。追蹤和可觀測性工具位列必備清單之首，幫助開發人員瞭解 Agent 的行為和效能。很多公司還使用 guardrail（防護控制）以防止 Agent 偏離軌道。

在測試 LLM 應用程式時，離線評估（39.8%）比線上評估（32.5%）被更常被使用，這反映了即時監控 LLM 的困難。在 LangChain 提供的開放式回答中，許多公司還讓人類專家手動檢查或評估響應，作為額外的預防層。

儘管人們對 Agent 的熱情很高，但在 Agent 許可權上普遍還是比較保守。很少有受訪者允許他們的 Agent自由地讀取、寫入和刪除。相反，大多數團隊只允許讀取許可權的工具許可權，或需要人類批准 Agent 才可以做更有風險的行動，如寫入或刪除。

不同規模的公司在 Agent 控制方面也有不同的優先順序。不出所料，大型企業（2000名以上員工）更加謹慎，嚴重依賴 “read-only” 許可權以避免不必要的風險。他們也傾向於將 guardrail 防護與離線評估相結合，不希望客戶看到任何問題。

與此同時，小型公司和初創公司（少於100名員工）更專注於追蹤以瞭解其 Agent 應用程式中發生了什麼（而不是其他控制）。根據 LangChain 的調查資料，較小的公司傾向於專注於透過檢視資料來理解結果；而大型企業則在全面範圍內設定了更多的控制措施。

保證 LLM 的高質量 performance 很難，回答需要有高準確性，還要符合正確的風格。這是 Agent 開發使用者們最關心的問題——比成本、安全等其他因素的重要性高出兩倍多。

LLM Agent 是機率式的內容輸出，意味著較強的不可預測性。這引入了更多的錯誤可能性，使得團隊難以確保其 Agent 始終如一地提供準確、符合上下文的回應。

對於小型公司尤其如此，效能質量遠遠超過了其他考慮因素，有 45.8 %的人將其作為主要關注點，而成本（第二大關注點）僅為22.4%。這一差距強調了可靠、高質量的效能對於組織將 Agent 從開發轉移到生產的重要性。

安全問題對於需要嚴格合規，並敏感處理客戶資料的大型公司也普遍存在。

挑戰不止於質量。從 LangChain 提供的開放式回答中，許多人對公司是否要持續投入開發和測試 Agent 仍保持懷疑。大家提到兩個突出的阻礙：開發 Agent 需要的知識很多，且需要一直跟進技術前沿；開發部署 Agent 需要的時間成本很大，是否能可靠執行的收益又不太確定。

在開放性問題中，大家對 AI Agent 展示出的這些能力有很多稱讚：

• 管理多步驟任務：AI Agent 能夠進行更深入的推理和上下文管理，使它們能夠處理更復雜的任務；

• 自動化重複性任務：AI Agent 繼續被視為處理自動化任務的關鍵，這可以為使用者解放時間，讓他們去解決更有創造性的問題；

• 任務規劃和協作：更好的任務規劃確保正確的 Agent 在正確的時間處理正確的問題，特別是在 Multi-agent 系統中；

• 類似人類的推理：與傳統LLM不同，AI Agent可以追溯其決策，包括根據新資訊回顧並修改過去的決策。

此外大家還有兩個最期待的進展：

• 對開源 AI Agent 的期待：人們對開源 AI Agent 的興趣明顯，許多人提到集體智慧可以加速 Agent 的創新；

• 對更強大的模型的期待：許多人正在期待由更大、更強大的模型驅動的 AI Agent 的下一次飛躍—在那時，Agent 能夠以更高的效率和自主性處理更復雜的任務。

問答中很多人也提到了 Agent 開發時最大的挑戰：如何理解 Agent 的行為。一些工程師提到他們在向公司 stakeholder 解釋 AI Agent 的能力和行為時會遇到困難。部分時候視覺化外掛可以幫助解釋 Agent 的行為，但在更多情況下 LLM 仍然是一個黑箱。額外的可解釋性負擔留給了工程團隊。

在 State of AI Agent 報告發布之前，Langchain 團隊已經在 Agent 領域寫了自己的 Langraph 框架，並透過 In the Loop 部落格討論了很多 AI Agent 中的關鍵元件，接下來就是我們對其中關鍵內容的編譯。

首先每個人對 AI Agent 的定義都略有不同，LangChain 創始人 Harrison Chase 給出的定義如下：

對其實現方式，文章中引入了 Cognitive architecture（認知架構） 的概念，認知架構是指 Agent 如何進行思考、系統如何去編排程式碼/ prompt LLM：

• Cognitive：Agent 使用 LLM 來語義推理該如何編排程式碼/ Prompt LLM;

• Architecture: 這些 Agent 系統仍然涉及大量類似於傳統系統架構的工程。

下面這張圖展示了不同層次 Cognitive architecture 的例子：

• 標準化的軟體程式碼（code） ：一切都是 Hard Code ，輸出或輸入的相關引數都直接固定在原始碼中，這不構成一個認知架構，因為沒有 cognitive 的部分；

• LLM Call ，除了一些資料預處理外，單個 LLM 的呼叫構成了應用程式的大部分，簡單的 Chatbot 屬於這一類；

• Chain：一系列 LLM 呼叫，Chain 嘗試將問題的解決分成若干步，呼叫不同的 LLM 解決問題。複雜的 RAG 屬於這一種：呼叫第一個 LLM 用來搜尋、查詢，呼叫第二個 LLM 用於生成答案；

• Router：在前面的三種系統中，使用者可以提前知道程式會採取的所有步驟，但在 Router 中，LLM 自行決定呼叫哪些 LLM ，採取怎樣的步驟，這增加了更多的隨機性和不可預測性；

• State Machine ，將 LLM 與 Router 結合使用，這將更加不可預測，因為這樣結合放入迴圈中，系統可以（理論上）做無限次的 LLM 呼叫；

• Agentic 的系統：大家也會稱為“ Autonomous Agent ”，使用 State Machine 時，對於可以採取哪些操作以及在執行該操作後執行哪些流程仍然存在限制；但當使用 Autonomous Agent 時，這些限制將被刪除。LLM 來決定採取哪些步驟、怎樣去編排不同的 LLM ，這可以透過使用不同的 Prompt 、工具或程式碼來完成。

簡單來說，一個系統越是“ Agentic ”，LLM 就越大程度地決定系統的行為方式。

Agent 可靠性是一個很大的痛點。常常會有公司使用 LLM 構建了 Agent，卻提到 Agent 無法很好地規劃和推理。這裡的規劃和推理是什麼意思呢？

Agent的計劃和推理指的是 LLM 思考要採取什麼行動的能力。這涉及短期和長期 reasoning ，LLM 評估所有可用資訊，然後決定：我需要採取哪些一系列步驟，哪些是我現在應該採取的第一個步驟？

很多時候開發者使用 Function calling（函式呼叫）來讓 LLM 選擇要執行的操作。Function calling 是 OpenAI 於 2023 年 6 月首次新增到 LLM api 的能力，透過 Function calling ，使用者可以為不同的函式提供 JSON 結構，並讓 LLM 匹配其中一個（或多個）結構。

要成功完成一項複雜的任務，系統需要按順序採取一系列行動。這種長期規劃和推理對於 LLM 非常複雜：首先 LLM 必須考慮一個長期的行動規劃，再回到要採取的短期行動中；其次，隨著 Agent 執行越來越多的操作，操作的結果將反饋給 LLM ，導致上下文視窗增長，這可能會導致 LLM “分心”並表現不佳。

改進規劃的最容易解決的辦法是確保 LLM 擁有適當推理/計劃所需的所有資訊。儘管這聽起來很簡單，但通常傳遞給 LLM 的資訊根本不足以讓 LLM 做出合理的決定，新增檢索步驟或闡明 Prompt 可能是一種簡單的改進。

之後，可以考慮更改應用程式的認知架構。這裡有兩類認知架構來改進推理，通用認知架構和特定領域的認知架構：

通用認知架構可以應用於任何任務。這裡有兩篇論文提出了兩種通用的架構，一個是 “plan and solve” 架構，在 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models 一文中提出，在該架構中，Agent 首先提出一個計劃，然後執行該計劃中的每個步驟。另一種通用架構是 Reflexion 架構，這一架構在 Reflexion: Language Agents with Verbal Reinforcement Learning 中提出，在該架構中，Agent 執行任務後有一個明確的 “反射” 步驟，以反映它是否正確執行了該任務。這裡不贅述，詳細可看上兩篇論文。

儘管這些想法顯示出改進，但它們通常過於籠統，無法被 Agent 在生產中實際使用。（譯者注：這篇文章釋出時還沒有 o1 系列模型）

相反，我們看到 Agent 是使用特定領域的認知架構構建的。這通常表現在特定領域的分類/規劃步驟、特定領域的驗證步驟中。規劃和反思的一些思想可以在這裡應用，但它們通常以特定領域的方式應用。

AlphaCodium 的一篇論文中舉了一個特定的例子：透過使用他們所謂的 “流工程”（另一種談論認知架構的方式）實現了最先進的效能。

可以看到 Agent 的流程對於他們試圖解決的問題非常具體。他們告訴 Agent 分步驟做什麼：提出測試，然後提出解決方案，然後迭代更多測試等。這種認知架構是高度專注特定領域的，不能泛化到其他領域。

在紅杉資本對 Reflection AI 創始人 Misha Laskin 的訪談中，Misha 提到他正在開始實現他的願景：即透過將 RL 的 Search Capability 與 LLM 相結合，在他的新公司 Reflection AI 中構建最佳的 Agent 模型。他和聯合創始人 Ioannis Antonoglou（AlphaGo、AlphaZero 、Gemini RLHF 負責人）正在訓練為 Agentic Workflows 設計的模型，訪談中的主要觀點如下：

• 深度是 AI Agent 中缺失的部分。 雖然當前的語言模型在廣度方面表現出色，但它們缺乏可靠完成任務所需的深度。Laskin 認為，解決“深度問題”對於建立真正有能力的 AI Agent 至關重要，這裡的能力是指：Agent 可以透過多個步驟規劃和執行復雜的任務；

• 將 Learn 和 Search 相結合是實現超人效能的關鍵。 借鑑 AlphaGo 的成功，Laskin 強調 AI 中最深刻的理念是 Learn（依靠 LLM）和 Search（找到最優路徑）的結合。這種方法對於建立在複雜任務中可以勝過人類的 Agent 至關重要；

• Post-training 和 Reward modeling 帶來了重大挑戰。 與具有明確獎勵的遊戲不同，現實世界的任務通常缺乏真實獎勵。開發可靠的 reward model，是建立可靠的 AI Agent 的關鍵挑戰

• Universal Agents 可能比我們想象的更接近。 Laskin 估計，我們可能只用三年時間就可以實現“digital AGI”，即同時具有廣度和深度的 AI 系統。這一加速的時間表凸顯了在能力發展的同時解決安全性和可靠性問題的緊迫性

• 通往 Universal Agents 的道路需要一種的方法。 Reflection AI 專注於擴充套件 Agent 功能，從一些特定的環境開始，如瀏覽器、coding 和計算機作業系統。他們的目標是開發 Universal Agents ，使其不侷限於特定任務。

在未來幾年，人機互動會成為 research 的一個關鍵領域：Agent 系統與過去的傳統計算機系統不同，因為延遲、不可靠性和自然語言介面帶來了新的挑戰。因此，與這些 Agent 應用程式互動的新 UI/UX 正規化將出現。Agent 系統仍處於早期階段，但已經出現多種新興的 UX 正規化。下面分別進行討論：

聊天一般分為兩種：流式聊天（streaming chat）、非流式聊天（non-streaming Chat）。

流式聊天是目前最常見的 UX。它是一個 Chatbot，以聊天格式將其思想和行為流回——ChatGPT 是最受歡迎的例子。這種互動模式看起來很簡單，但也有不錯的效果，因為：其一，可以使用自然語言與 LLM 進行對話，這意味著客戶和 LLM 沒有任何障礙；其二，LLM 可能需要一段時間才能工作，流式處理使使用者能夠準確瞭解後臺發生的事情；其三，LLM 常常會出錯，Chat 提供了一個很好的介面來自然地糾正和指導它，大家已經非常習慣於在聊天中進行後續對話和迭代討論事情。

但流式聊天也有其缺點。首先，流式聊天是一種相對較新的使用者體驗，因此我們現有的聊天平臺（iMessage、Facebook Messenger、Slack 等）沒有這種方式；其次，對於執行時間較長的任務來說，這有點尷尬—使用者只是要坐在那裡看著 Agent 工作嗎；第三，流式聊天通常需要由人類觸發，這意味著還需要大量 human in the loop。

非流式聊天的最大區別在於響應是分批返回的， LLM 在後臺工作，使用者並不急於讓 LLM 立刻回答，這意味著它可能更容易整合到現有的工作流程中。人們已經習慣了給人類發簡訊——為什麼他們不能適應用 AI 發簡訊呢？非流式聊天將使得與更復雜的 Agent 系統互動變得更加容易—這些系統通常需要一段時間，如果期望即時響應，這可能會令人沮喪。非流式聊天通常會消除這種期望，從而更輕鬆地執行更復雜的事情。

這兩種聊天方式有以下優缺點：

使用者會考慮向 AI 傳送訊息，這是上面談到的 Chat，但如果 Agent 只是在後臺工作，那我們該如何與 Agent 互動呢？

為了讓 Agent 系統真正發揮其潛力，就需要有這種允許 AI 在後臺工作的轉變。當任務在後臺處理時，使用者通常更能容忍更長的完成時間（因為他們放寬了對低延遲的期望）。這使 Agent 可以騰出時間做更多的工作，通常比在聊天 UX 中更仔細、勤奮做更多推理。

此外，在後臺執行 Agent 能擴充套件我們人類使用者的能力。聊天介面通常限制我們一次只能執行一項任務。但是，如果 Agent 在後臺環境執行，則可能會有許多 Agent 同時處理多個任務。

讓 Agent 在後臺執行，是需要使用者信任的，該如何建立這種信任？一個簡單的想法是：向用戶準確展示 Agent 在做什麼。顯示它正在執行的所有步驟，並讓使用者觀察正在發生的事情。雖然這些步驟可能不會立即可見（就像在流式傳輸響應時一樣），但它應該可供使用者點選並觀察。下一步是不僅讓使用者看到發生了什麼，還讓他們糾正 Agent 。如果他們發現 Agent 在第 4 步（共 10 步）中做出了錯誤的選擇，客戶可以選擇返回第 4 步並以某種方式更正 Agent 。

這種方法將使用者從 “In-the-loop” 轉變為 “On-the-loop”。“On-the-loop”要求能夠向用戶顯示 Agent 執行的所有中間步驟，允許使用者中途暫停工作流，提供反饋，然後讓 Agent 繼續。

AI 軟體工程師 Devin 是實現類似 UX 的一個應用程式。Devin 執行時間較長，但客戶可以看到所採取的所有步驟，倒回特定時間點的開發狀態，並從那裡釋出更正。儘管 Agent 可能在後臺執行，但這並不意味著它需要完全自主地執行任務。有時 Agent 不知道該做什麼或如何回答，這時，它需要引起人類的注意並尋求幫助。

一個具體的例子是 Harrison 正在構建的電子郵件助理 Agent 。雖然電子郵件助理可以回覆基本電子郵件，但它通常需要 Harrison 輸入某些不想自動化的任務，包括：審查複雜的 LangChain 錯誤報告、決定是否要參加會議等。在這種情況下，電子郵件助理需要一種方法來向 Harrison 傳達它需要資訊來響應。請注意，它不是要求其直接回答；相反，它會徵求 Harrison 對某些任務的意見，然後它可以使用這些任務來製作和傳送一封漂亮的電子郵件或安排日曆邀請。

目前，Harrison 在 Slack 中設定了這個助手。它向 Harrison 傳送一個問題，Harrison 在 Dashboard 中回答它，與其工作流程原生整合。這種型別的 UX類似於客戶支援 Dashboard 的 UX。此介面將顯示助手需要人工幫助的所有區域、請求的優先順序以及任何其他資料。

電子表格 UX 是一種支援批次處理工作的超級直觀且使用者友好的方式。每個表格、甚至每一列都成為自己的 Agent，去研究特定的東西。這種批次處理允許使用者擴充套件與多個 Agent 互動。

這種 UX 還有其他好處。電子表格格式是大多數使用者都熟悉的 UX，因此它非常適合現有的工作流程。這種型別的 UX 非常適合資料擴充，這是一種常見的 LLM 用例，其中每列可以表示要擴充的不同屬性。

Exa AI、Clay AI、Manaflow 等公司的產品都在使用這種 UX，下以 Manaflow舉例展示這種電子表格 UX 如何處理工作流程。

Manaflow 的靈感來源於創始人 Lawrence 曾任職的公司 Minion AI，Minion AI 構建的產品是 Web Agent 。Web Agent 可以控制本地的 Geogle Chrome，允許其與應用程式互動，例如訂機票、傳送電子郵件、安排洗車等。基於Minion AI 的靈感，Manaflow 選擇讓 Agent 去操作電子表格類的工具，這是因為 Agent 不擅長處理人類的 UI 介面，Agent 真正擅長的是 Coding。因此 Manaflow 讓 Agent 去呼叫 UI 介面的的 Python 指令碼，資料庫介面，連結API，然後直接對資料庫進行操作：包括閱讀時間、預定、發郵件等等。

其工作流如下：Manaflow 的主要介面是一個電子表格（Manasheet），其中每列代表工作流程中的一個步驟，每行對應於執行任務的 AI Agent。每個電子表格的 workflow 都可以使用自然語言進行程式設計（允許非技術使用者用自然語言描述任務和步驟）。每個電子表格都有一個內部依賴關係圖，用於確定每列的執行順序。這些順序會分配給每一行的 Agent 並行執行任務，處理資料轉換、API 呼叫、內容檢索和傳送訊息等流程：

生成 Manasheet 可以的方法為：輸入類似上面紅色框裡的自然語言，如上圖中想向客戶可以傳送定價的郵件，就可以透過 Chat 輸入 Prompt，來生成 Manasheet。透過 Manasheet 可以看到有客戶的姓名，客戶的郵箱，客戶所屬的行業，是否已經發送郵件等資訊；點選 Execute Manasheet 即可執行任務。

“生成式 UI”有兩種不同的實現方式。

一種方式是由模型自行生成需要的的原始元件。這類似於 Websim 等產品。在後臺，Agent 主要編寫原始 HTML，使其能夠完全控制顯示的內容。但是這種方法允許生成的 web app 質量有很高的不確定性，因此最終結果可能看起來波動較大。

另一種更受約束的方法為：預定義一些 UI 元件，這通常是透過工具呼叫來完成的。例如，如果 LLM 呼叫天氣 API，則它會觸發天氣地圖 UI 元件的渲染。由於渲染的元件不是真正生成的（但是有更多選擇），因此生成的 UI 將更加精緻，儘管它可以生成的內容不完全靈活。

舉例來說，在 2024 年曾被稱為最好的 Personal AI 產品的 Dot，就是一個很好的生成式 UI 產品。

Dot 是 New Computer 公司的產品：其目標是成為使用者的長期伴侶，而並不是更好的任務管理工具，據聯合創始人Jason Yuan講，Dot 的感覺是，當你不知道該去哪裡、該做什麼或該說什麼時，你就會求助於 Dot。這裡舉兩個例子介紹產品是做什麼的：

• 創始人 Jason Yuan 常常在深夜讓 Dot 推薦酒吧，說自己想要一醉方休，斷斷續續幾個月，某天下班之後，Yuan 再次問了相似的問題，Dot 竟然開始勸解 Jason，不能再這樣下去了；

• Fast Company 記者 Mark Wilson，也和 Dot 相處了幾個月的時間。有一次，他向 Dot 分享了書法課上他手寫的一個「O」，Dot 竟然調出了幾周前他手寫「O」的照片，誇他的書法水平提高了。

• 隨著使用Dot的時間越來越多，Dot 更加理解了使用者喜歡打卡咖啡館，主動推送給主人附近的好咖啡館，附上了為何這個咖啡館好，最後還貼心的詢問是否要導航.

可以看到在這個咖啡館推薦的例子中，Dot 透過預定義 UI 元件，來達到 LLM-native 的互動效果。

當 Agent 和人類一起工作時會發生什麼？想想 Google Docs，客戶可以在其中與團隊成員協作編寫或編輯文件，但倘如協作者之一是 Agent 呢？

Geoffrey Litt 和 Ink & Switch 合作的 Patchwork專案是人類- Agent 合作的一個很好的例子。（譯者注：這可能是最近 OpenAI Canvas 產品更新的靈感來源）。

協作式 UX 與前面討論的 Ambient UX 相比如何？LangChain創始工程師 Nuno 強調了兩者之間的主要區別，在於是否有併發性：

• 在協作式 UX 中，客戶和LLM 經常同時工作，以彼此的工作為輸入；

• 在環境 UX 中，LLM 在後臺持續工作，而使用者則完全專注於其他事情。

記憶對於好的 Agent 體驗至關重要。想象一下如果你有一個同事從來不記得你告訴他們什麼，強迫你不斷重複這些資訊，這個協作體驗會非常差。人們通常期望 LLM 系統天生就有記憶，這可能是因為 LLM 感覺已經很像人類了。但是，LLM 本身並不能記住任何事物。

Agent 的記憶是基於產品本身需要的，而且不同的 UX 提供了不同的方法來收集資訊和更新反饋。我們能從 Agent 產品的記憶機制中看到不同的高階記憶型別——它們在模仿人類的記憶型別。

論文 CoALA: Cognitive Architectures for Language Agents 將人類的記憶型別對映到了 Agent 記憶上，分類方式如下圖的所示：

1. 程式記憶（Procedural Memory）：有關如何執行任務的長期記憶，類似於大腦的核心指令集

• 人類的程式記憶：記住如何騎腳踏車。

• Agent 的程式記憶：CoALA 論文將程式記憶描述為 LLM 權重和 Agent 程式碼的組合，它們從根本上決定了 Agent 的工作方式。

在實踐中，Langchain 團隊還沒有看到任何 Agent 系統會自動更新其 LLM 或重寫其程式碼，但是確實存在一些 Agent 更新其 system prompt 的例子。

2. 語義記憶(Semantic Memory): 長期知識儲備

• 人類的語義記憶：它由資訊片段組成，例如在學校學到的事實、概念以及它們之間的關係。

• Agent 的語義記憶：CoALA 論文將語義記憶描述為事實儲存庫。

在實踐中上，常常是透過使用 LLM 從 Agent 的對話或互動中提取資訊來實現的。此資訊的確切儲存方式通常是特定於應用程式的。然後這些資訊在將來的對話中檢索並插入到 System Prompt 中 以影響 Agent 的響應。

3. 情景記憶（Episodic Memory）：回憶特定的過去事件

• 人類的情景記憶：當一個人回憶起過去經歷的特定事件（或“情節”）時。

• Agent 中的情景記憶：CoALA 論文將情景記憶定義為儲存 Agent 過去動作的序列。

這主要用於讓 Agent 按預期執行動作。在實踐中，情景記憶的更新透過 Few-Shots Prompt 的方法實現。如果相關更新的 Few-Shots Prompt 足夠多，那麼接下來的更新就透過 Dynamic Few-Shots Prompt 來完成。

如果一開始就有指導 Agent 正確完成操作的辦法，後面面對同樣的問題就可以直接使用這種辦法；相反，如果不存在正確的操作方式，或者如果 Agent 不斷做新的事情，那麼語義記憶就會更重要，反而在前面的例子中，語義記憶不會有太大幫助。

除了考慮要在 Agent 中更新的記憶型別外，開發人員還要考慮如何更新 Agent 的記憶：

更新 Agent 記憶的第一種方法是 “in the hot path”。在這種情況下， Agent 系統會在響應之前記住事實（通常透過工具呼叫）， ChatGPT 採取這種方法更新其記憶；

更新 Agent 記憶的另一種方法是 “in the background” 。在這種情況下，後臺程序會在會話之後執行以更新記憶。

比較這兩種方法，“in the hot path” 方法的缺點是在傳遞任何響應之前會有一些延遲，它還需要將 memory logic 與 agent logic 相結合。

但是， “in the background ”可以避免這些問題 – 不會增加延遲，並且 memory logic 保持獨立。但是“in the background ”也有其自身的缺點：記憶不會立即更新，並且需要額外的 logic 來確定何時啟動後臺程序。

更新記憶的另一種方法涉及使用者反饋，這與情景記憶特別相關。例如，如果使用者對某次互動標評分較高（Postive Feedback），Agent 可以儲存該反饋以備將來呼叫。

基於以上編譯內容，我們期待規劃、互動、記憶三個元件的同時進步，會讓我們在 2025 年看到更多可用的 AI Agent，進入人機協同工作的新時代。

延伸閱讀