墨西哥支付方式：是什么?
盡管技術(shù)行業(yè)通常被認(rèn)為是早期的 Agent 使用者，但所有行業(yè)對 Agent 的興趣都在與日俱增。在非技術(shù)公司工作的受訪者中，有90%已經(jīng)或計劃將Agent投入生產(chǎn)（與技術(shù)公司的比例幾乎相同，為89%）。
Agent 最常用的 use case 包括進行研究和總結(jié)（58%），其次是通過定制化的 Agent 簡化工作流程 （53.5%）。
這些反映了人們希望有產(chǎn)品來處理那些過于消耗時間的任務(wù)。用戶可以依賴 AI Agent 從大量信息中提取關(guān)鍵信息和見解，而不是自己從海量的數(shù)據(jù)中篩選，再進行資料回顧或研究分析。同樣，AI Agent 可以通過協(xié)助日常任務(wù)來提升個人生產(chǎn)力，使用戶能夠?qū)Ｗ⒂谥匾马棥?/p>
不僅個人需要這種效率的提升，公司和團隊也同樣需要。客服（45.8%）是 Agent的另一個主要應(yīng)用領(lǐng)域，Agent 幫助公司處理咨詢、故障排除，并加快跨團隊的客戶響應(yīng)時間；排在第四、第五位的是更底層的 code 和 data 應(yīng)用。
隨著 Agent 實現(xiàn)功能變得更加強大，就需要管理和監(jiān)控 Agent 的方法。追蹤和可觀測性工具位列必備清單之首，幫助開發(fā)人員了解 Agent 的行為和性能。很多公司還使用 guardrail（防護控制）以防止 Agent 偏離軌道。
在測試 LLM 應(yīng)用程序時，離線評估（39.8%）比在線評估（32.5%）被更常被使用，這反映了實時監(jiān)控 LLM 的困難。在 LangChain 提供的開放式回答中，許多公司還讓人類專家手動檢查或評估響應(yīng)，作為額外的預(yù)防層。
盡管人們對 Agent 的熱情很高，但在 Agent 權(quán)限上普遍還是比較保守。很少有受訪者允許他們的 Agent自由地讀取、寫入和刪除。相反，大多數(shù)團隊只允許讀取權(quán)限的工具權(quán)限，或需要人類批準(zhǔn) Agent 才可以做更有風(fēng)險的行動，如寫入或刪除。
不同規(guī)模的公司在 Agent 控制方面也有不同的優(yōu)先級。不出所料，大型企業(yè)（2000名以上員工）更加謹(jǐn)慎，嚴(yán)重依賴 “read-only” 權(quán)限以避免不必要的風(fēng)險。他們也傾向于將 guardrail 防護與離線評估相結(jié)合，不希望客戶看到任何問題。
與此同時，小型公司和初創(chuàng)公司（少于100名員工）更專注于追蹤以了解其 Agent 應(yīng)用程序中發(fā)生了什么（而不是其他控制）。根據(jù) LangChain 的調(diào)查數(shù)據(jù)，較小的公司傾向于專注于通過查看數(shù)據(jù)來理解結(jié)果；而大型企業(yè)則在全面范圍內(nèi)設(shè)置了更多的控制措施。
將 Agent 投入生產(chǎn)的障礙和挑戰(zhàn)
保證 LLM 的高質(zhì)量 performance 很難，回答需要有高準(zhǔn)確性，還要符合正確的風(fēng)格。這是 Agent 開發(fā)使用者們最關(guān)心的問題——比成本、安全等其他因素的重要性高出兩倍多。
LLM Agent 是概率式的內(nèi)容輸出，意味著較強的不可預(yù)測性。這引入了更多的錯誤可能性，使得團隊難以確保其 Agent 始終如一地提供準(zhǔn)確、符合上下文的回應(yīng)。
對于小型公司尤其如此，性能質(zhì)量遠(yuǎn)遠(yuǎn)超過了其他考慮因素，有 45.8 %的人將其作為主要關(guān)注點，而成本（第二大關(guān)注點）僅為22.4%。這一差距強調(diào)了可靠、高質(zhì)量的性能對于組織將 Agent 從開發(fā)轉(zhuǎn)移到生產(chǎn)的重要性。
安全問題對于需要嚴(yán)格合規(guī)，并敏感處理客戶數(shù)據(jù)的大型公司也普遍存在。
挑戰(zhàn)不止于質(zhì)量。從 LangChain 提供的開放式回答中，許多人對公司是否要持續(xù)投入開發(fā)和測試 Agent 仍保持懷疑。大家提到兩個突出的阻礙：開發(fā) Agent 需要的知識很多，且需要一直跟進技術(shù)前沿；開發(fā)部署 Agent 需要的時間成本很大，是否能可靠運行的收益又不太確定。
其他新興主題
在開放性問題中，大家對 AI Agent 展示出的這些能力有很多稱贊：
? 管理多步驟任務(wù)：AI Agent 能夠進行更深入的推理和上下文管理，使它們能夠處理更復(fù)雜的任務(wù)；
? 自動化重復(fù)性任務(wù)：AI Agent 繼續(xù)被視為處理自動化任務(wù)的關(guān)鍵，這可以為用戶解放時間，讓他們?nèi)ソ鉀Q更有創(chuàng)造性的問題；
? 任務(wù)規(guī)劃和協(xié)作：更好的任務(wù)規(guī)劃確保正確的 Agent 在正確的時間處理正確的問題，特別是在 Multi-agent 系統(tǒng)中；
??類似人類的推理：與傳統(tǒng)LLM不同，AI Agent可以追溯其決策，包括根據(jù)新信息回顧并修改過去的決策。
此外大家還有兩個最期待的進展：
? 對開源 AI Agent 的期待：人們對開源 AI Agent 的興趣明顯，許多人提到集體智慧可以加速 Agent 的創(chuàng)新；
??對更強大的模型的期待：許多人正在期待由更大、更強大的模型驅(qū)動的 AI Agent 的下一次飛躍—在那時，Agent 能夠以更高的效率和自主性處理更復(fù)雜的任務(wù)。
問答中很多人也提到了 Agent 開發(fā)時最大的挑戰(zhàn)：如何理解 Agent 的行為。一些工程師提到他們在向公司 stakeholder 解釋 AI Agent 的能力和行為時會遇到困難。部分時候可視化插件可以幫助解釋 Agent 的行為，但在更多情況下 LLM 仍然是一個黑箱。額外的可解釋性負(fù)擔(dān)留給了工程團隊。
什么是 Agentic 系統(tǒng)
在 State of AI Agent 報告發(fā)布之前，Langchain 團隊已經(jīng)在 Agent 領(lǐng)域?qū)懥俗约旱?Langraph 框架，并通過 In the Loop 博客討論了很多 AI Agent 中的關(guān)鍵組件，接下來就是我們對其中關(guān)鍵內(nèi)容的編譯。
首先每個人對 AI Agent 的定義都略有不同，LangChain 創(chuàng)始人 Harrison Chase 給出的定義如下：
??
AI Agent 是一個用 LLM 來做程序的控制流決策的系統(tǒng)。
An AI agent is a system that uses an LLM to decide the control flow of an application.
對其實現(xiàn)方式，文章中引入了 Cognitive architecture（認(rèn)知架構(gòu)） 的概念，認(rèn)知架構(gòu)是指 Agent 如何進行思考、系統(tǒng)如何去編排代碼/ prompt LLM：
??Cognitive：Agent 使用 LLM 來語義推理該如何編排代碼/ Prompt LLM;
? Architecture: 這些 Agent 系統(tǒng)仍然涉及大量類似于傳統(tǒng)系統(tǒng)架構(gòu)的工程。
下面這張圖展示了不同層次 Cognitive architecture 的例子：
? 標(biāo)準(zhǔn)化的軟件代碼（code） ：一切都是 Hard Code ，輸出或輸入的相關(guān)參數(shù)都直接固定在源代碼中，這不構(gòu)成一個認(rèn)知架構(gòu)，因為沒有 cognitive 的部分；
? LLM Call ，除了一些數(shù)據(jù)預(yù)處理外，單個 LLM 的調(diào)用構(gòu)成了應(yīng)用程序的大部分，簡單的 Chatbot 屬于這一類；
? Chain：一系列 LLM 調(diào)用，Chain 嘗試將問題的解決分成若干步，調(diào)用不同的 LLM 解決問題。復(fù)雜的 RAG 屬于這一種：調(diào)用第一個 LLM 用來搜索、查詢，調(diào)用第二個 LLM 用于生成答案；
? Router：在前面的三種系統(tǒng)中，用戶可以提前知道程序會采取的所有步驟，但在 Router 中，LLM 自行決定調(diào)用哪些 LLM ，采取怎樣的步驟，這增加了更多的隨機性和不可預(yù)測性；
??State Machine ，將 LLM 與 Router 結(jié)合使用，這將更加不可預(yù)測，因為這樣結(jié)合放入循環(huán)中，系統(tǒng)可以（理論上）做無限次的 LLM 調(diào)用；
? Agentic 的系統(tǒng)：大家也會稱為“ Autonomous Agent ”，使用 State Machine 時，對于可以采取哪些操作以及在執(zhí)行該操作后執(zhí)行哪些流程仍然存在限制；但當(dāng)使用 Autonomous Agent 時，這些限制將被刪除。LLM 來決定采取哪些步驟、怎樣去編排不同的 LLM ，這可以通過使用不同的 Prompt 、工具或代碼來完成。
簡單來說，一個系統(tǒng)越是“ Agentic ”，LLM 就越大程度地決定系統(tǒng)的行為方式。
Agent 的關(guān)鍵要素
規(guī)劃
Agent 可靠性是一個很大的痛點。常常會有公司使用 LLM 構(gòu)建了 Agent，卻提到 Agent 無法很好地規(guī)劃和推理。這里的規(guī)劃和推理是什么意思呢？
Agent的計劃和推理指的是 LLM 思考要采取什么行動的能力。這涉及短期和長期 reasoning ，LLM 評估所有可用信息，然后決定：我需要采取哪些一系列步驟，哪些是我現(xiàn)在應(yīng)該采取的第一個步驟？
很多時候開發(fā)者使用 Function calling（函數(shù)調(diào)用）來讓 LLM 選擇要執(zhí)行的操作。Function calling 是 OpenAI 于 2023 年 6 月首次添加到 LLM api 的能力，通過 Function calling ，用戶可以為不同的函數(shù)提供 JSON 結(jié)構(gòu)，并讓 LLM 匹配其中一個（或多個）結(jié)構(gòu)。
要成功完成一項復(fù)雜的任務(wù)，系統(tǒng)需要按順序采取一系列行動。這種長期規(guī)劃和推理對于 LLM 非常復(fù)雜：首先 LLM 必須考慮一個長期的行動規(guī)劃，再回到要采取的短期行動中；其次，隨著 Agent 執(zhí)行越來越多的操作，操作的結(jié)果將反饋給 LLM ，導(dǎo)致上下文窗口增長，這可能會導(dǎo)致 LLM “分心”并表現(xiàn)不佳。
改進規(guī)劃的最容易解決的辦法是確保 LLM 擁有適當(dāng)推理/計劃所需的所有信息。盡管這聽起來很簡單，但通常傳遞給 LLM 的信息根本不足以讓 LLM 做出合理的決定，添加檢索步驟或闡明 Prompt 可能是一種簡單的改進。
之后，可以考慮更改應(yīng)用程序的認(rèn)知架構(gòu)。這里有兩類認(rèn)知架構(gòu)來改進推理，通用認(rèn)知架構(gòu)和特定領(lǐng)域的認(rèn)知架構(gòu)：
1. 通用認(rèn)知架構(gòu)
通用認(rèn)知架構(gòu)可以應(yīng)用于任何任務(wù)。這里有兩篇論文提出了兩種通用的架構(gòu)，一個是 “plan and solve” 架構(gòu)，在 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models 一文中提出，在該架構(gòu)中，Agent 首先提出一個計劃，然后執(zhí)行該計劃中的每個步驟。另一種通用架構(gòu)是 Reflexion 架構(gòu)，這一架構(gòu)在 Reflexion: Language Agents with Verbal Reinforcement Learning 中提出，在該架構(gòu)中，Agent 執(zhí)行任務(wù)后有一個明確的 “反射” 步驟，以反映它是否正確執(zhí)行了該任務(wù)。這里不贅述，詳細(xì)可看上兩篇論文。
盡管這些想法顯示出改進，但它們通常過于籠統(tǒng)，無法被 Agent 在生產(chǎn)中實際使用。（譯者注：這篇文章發(fā)布時還沒有 o1 系列模型）
2. 特定領(lǐng)域的認(rèn)知架構(gòu)
相反，我們看到 Agent 是使用特定領(lǐng)域的認(rèn)知架構(gòu)構(gòu)建的。這通常表現(xiàn)在特定領(lǐng)域的分類/規(guī)劃步驟、特定領(lǐng)域的驗證步驟中。規(guī)劃和反思的一些思想可以在這里應(yīng)用，但它們通常以特定領(lǐng)域的方式應(yīng)用。
AlphaCodium 的一篇論文中舉了一個特定的例子：通過使用他們所謂的 “流工程”（另一種談?wù)撜J(rèn)知架構(gòu)的方式）實現(xiàn)了最先進的性能。
可以看到 Agent 的流程對于他們試圖解決的問題非常具體。他們告訴 Agent 分步驟做什么：提出測試，然后提出解決方案，然后迭代更多測試等。這種認(rèn)知架構(gòu)是高度專注特定領(lǐng)域的，不能泛化到其他領(lǐng)域。
Case Study:
Reflection AI 創(chuàng)始人 Laskin 對 Agent 未來的愿景
在紅杉資本對 Reflection AI 創(chuàng)始人 Misha Laskin 的訪談中，Misha 提到他正在開始實現(xiàn)他的愿景：即通過將 RL 的 Search Capability 與 LLM 相結(jié)合，在他的新公司 Reflection AI 中構(gòu)建最佳的 Agent 模型。他和聯(lián)合創(chuàng)始人 Ioannis Antonoglou（AlphaGo、AlphaZero 、Gemini RLHF 負(fù)責(zé)人）正在訓(xùn)練為 Agentic Workflows 設(shè)計的模型，訪談中的主要觀點如下：
??深度是 AI Agent 中缺失的部分。?雖然當(dāng)前的語言模型在廣度方面表現(xiàn)出色，但它們?nèi)狈煽客瓿扇蝿?wù)所需的深度。Laskin 認(rèn)為，解決“深度問題”對于創(chuàng)建真正有能力的 AI Agent 至關(guān)重要，這里的能力是指：Agent 可以通過多個步驟規(guī)劃和執(zhí)行復(fù)雜的任務(wù)；
? 將 Learn 和 Search 相結(jié)合是實現(xiàn)超人性能的關(guān)鍵。 借鑒 AlphaGo 的成功，Laskin 強調(diào) AI 中最深刻的理念是 Learn（依靠 LLM）和 Search（找到最優(yōu)路徑）的結(jié)合。這種方法對于創(chuàng)建在復(fù)雜任務(wù)中可以勝過人類的 Agent 至關(guān)重要；
? Post-training 和 Reward modeling 帶來了重大挑戰(zhàn)。 與具有明確獎勵的游戲不同，現(xiàn)實世界的任務(wù)通常缺乏真實獎勵。開發(fā)可靠的 reward model，是創(chuàng)建可靠的 AI Agent 的關(guān)鍵挑戰(zhàn)
? Universal Agents 可能比我們想象的更接近。 Laskin 估計，我們可能只用三年時間就可以實現(xiàn)“digital AGI”，即同時具有廣度和深度的 AI 系統(tǒng)。這一加速的時間表凸顯了在能力發(fā)展的同時解決安全性和可靠性問題的緊迫性
? 通往 Universal Agents 的道路需要一種的方法。 Reflection AI 專注于擴展 Agent 功能，從一些特定的環(huán)境開始，如瀏覽器、coding 和計算機操作系統(tǒng)。他們的目標(biāo)是開發(fā) Universal Agents ，使其不局限于特定任務(wù)。
UI/UX 交互
在未來幾年，人機交互會成為 research 的一個關(guān)鍵領(lǐng)域：Agent 系統(tǒng)與過去的傳統(tǒng)計算機系統(tǒng)不同，因為延遲、不可靠性和自然語言界面帶來了新的挑戰(zhàn)。因此，與這些 Agent 應(yīng)用程序交互的新 UI/UX 范式將出現(xiàn)。Agent 系統(tǒng)仍處于早期階段，但已經(jīng)出現(xiàn)多種新興的 UX 范式。下面分別進行討論：
1. 對話式交互 (Chat UI)
聊天一般分為兩種：流式聊天（streaming chat）、非流式聊天（non-streaming Chat）。
流式聊天是目前最常見的 UX。它是一個 Chatbot，以聊天格式將其思想和行為流回——ChatGPT 是最受歡迎的例子。這種交互模式看起來很簡單，但也有不錯的效果，因為：其一，可以使用自然語言與 LLM 進行對話，這意味著客戶和 LLM 沒有任何障礙；其二，LLM 可能需要一段時間才能工作，流式處理使用戶能夠準(zhǔn)確了解后臺發(fā)生的事情；其三，LLM 常常會出錯，Chat 提供了一個很好的界面來自然地糾正和指導(dǎo)它，大家已經(jīng)非常習(xí)慣于在聊天中進行后續(xù)對話和迭代討論事情。
但流式聊天也有其缺點。首先，流式聊天是一種相對較新的用戶體驗，因此我們現(xiàn)有的聊天平臺（iMessage、Facebook Messenger、Slack 等）沒有這種方式；其次，對于運行時間較長的任務(wù)來說，這有點尷尬—用戶只是要坐在那里看著 Agent 工作嗎；第三，流式聊天通常需要由人類觸發(fā)，這意味著還需要大量 human in the loop。
非流式聊天的最大區(qū)別在于響應(yīng)是分批返回的， LLM 在后臺工作，用戶并不急于讓 LLM 立刻回答，這意味著它可能更容易集成到現(xiàn)有的工作流程中。人們已經(jīng)習(xí)慣了給人類發(fā)短信——為什么他們不能適應(yīng)用 AI 發(fā)短信呢？非流式聊天將使得與更復(fù)雜的 Agent 系統(tǒng)交互變得更加容易—這些系統(tǒng)通常需要一段時間，如果期望即時響應(yīng)，這可能會令人沮喪。非流式聊天通常會消除這種期望，從而更輕松地執(zhí)行更復(fù)雜的事情。
這兩種聊天方式有以下優(yōu)缺點：
2. 后臺環(huán)境 (Ambient UX)
用戶會考慮向 AI 發(fā)送消息，這是上面談到的 Chat，但如果 Agent 只是在后臺工作，那我們該如何與 Agent 交互呢？
為了讓 Agent 系統(tǒng)真正發(fā)揮其潛力，就需要有這種允許 AI 在后臺工作的轉(zhuǎn)變。當(dāng)任務(wù)在后臺處理時，用戶通常更能容忍更長的完成時間（因為他們放寬了對低延遲的期望）。這使 Agent 可以騰出時間做更多的工作，通常比在聊天 UX 中更仔細(xì)、勤奮做更多推理。
此外，在后臺運行 Agent 能擴展我們?nèi)祟愑脩舻哪芰ΑＡ奶旖缑嫱ǔＯ拗莆覀円淮沃荒軋?zhí)行一項任務(wù)。但是，如果 Agent 在后臺環(huán)境運行，則可能會有許多 Agent 同時處理多個任務(wù)。
讓 Agent 在后臺運行，是需要用戶信任的，該如何建立這種信任？一個簡單的想法是：向用戶準(zhǔn)確展示 Agent 在做什么。顯示它正在執(zhí)行的所有步驟，并讓用戶觀察正在發(fā)生的事情。雖然這些步驟可能不會立即可見（就像在流式傳輸響應(yīng)時一樣），但它應(yīng)該可供用戶點擊并觀察。下一步是不僅讓用戶看到發(fā)生了什么，還讓他們糾正 Agent 。如果他們發(fā)現(xiàn) Agent 在第 4 步（共 10 步）中做出了錯誤的選擇，客戶可以選擇返回第 4 步并以某種方式更正 Agent 。
這種方法將用戶從 “In-the-loop” 轉(zhuǎn)變?yōu)?“On-the-loop”。“On-the-loop”要求能夠向用戶顯示 Agent 執(zhí)行的所有中間步驟，允許用戶中途暫停工作流，提供反饋，然后讓 Agent 繼續(xù)。
AI 軟件工程師 Devin 是實現(xiàn)類似 UX 的一個應(yīng)用程序。Devin 運行時間較長，但客戶可以看到所采取的所有步驟，倒回特定時間點的開發(fā)狀態(tài)，并從那里發(fā)布更正。盡管 Agent 可能在后臺運行，但這并不意味著它需要完全自主地執(zhí)行任務(wù)。有時 Agent 不知道該做什么或如何回答，這時，它需要引起人類的注意并尋求幫助。
一個具體的例子是 Harrison 正在構(gòu)建的電子郵件助理 Agent 。雖然電子郵件助理可以回復(fù)基本電子郵件，但它通常需要 Harrison 輸入某些不想自動化的任務(wù)，包括：審查復(fù)雜的 LangChain 錯誤報告、決定是否要參加會議等。在這種情況下，電子郵件助理需要一種方法來向 Harrison 傳達(dá)它需要信息來響應(yīng)。請注意，它不是要求其直接回答；相反，它會征求 Harrison 對某些任務(wù)的意見，然后它可以使用這些任務(wù)來制作和發(fā)送一封漂亮的電子郵件或安排日歷邀請。
目前，Harrison 在 Slack 中設(shè)置了這個助手。它向 Harrison 發(fā)送一個問題，Harrison 在 Dashboard 中回答它，與其工作流程原生集成。這種類型的 UX類似于客戶支持 Dashboard 的 UX。此界面將顯示助手需要人工幫助的所有區(qū)域、請求的優(yōu)先級以及任何其他數(shù)據(jù)。
3. 電子表格 (Spreadsheet UX)
電子表格 UX 是一種支持批量處理工作的超級直觀且用戶友好的方式。每個表格、甚至每一列都成為自己的 Agent，去研究特定的東西。這種批量處理允許用戶擴展與多個 Agent 交互。
這種 UX 還有其他好處。電子表格格式是大多數(shù)用戶都熟悉的 UX，因此它非常適合現(xiàn)有的工作流程。這種類型的 UX 非常適合數(shù)據(jù)擴充，這是一種常見的 LLM 用例，其中每列可以表示要擴充的不同屬性。
Exa AI、Clay AI、Manaflow 等公司的產(chǎn)品都在使用這種 UX，下以 Manaflow舉例展示這種電子表格 UX 如何處理工作流程。
Case Study:
Manaflow 如何使用電子表格進行 Agent 交互
Manaflow 的靈感來源于創(chuàng)始人 Lawrence 曾任職的公司 Minion AI，Minion AI 構(gòu)建的產(chǎn)品是 Web Agent 。Web Agent 可以控制本地的 Geogle Chrome，允許其與應(yīng)用程序交互，例如訂機票、發(fā)送電子郵件、安排洗車等。基于Minion AI 的靈感，Manaflow 選擇讓 Agent 去操作電子表格類的工具，這是因為 Agent 不擅長處理人類的 UI 界面，Agent 真正擅長的是 Coding。因此 Manaflow 讓 Agent 去調(diào)用 UI 界面的的 Python 腳本，數(shù)據(jù)庫接口，鏈接API，然后直接對數(shù)據(jù)庫進行操作：包括閱讀時間、預(yù)定、發(fā)郵件等等。
其工作流如下：Manaflow 的主要界面是一個電子表格（Manasheet），其中每列代表工作流程中的一個步驟，每行對應(yīng)于執(zhí)行任務(wù)的 AI Agent。每個電子表格的 workflow 都可以使用自然語言進行編程（允許非技術(shù)用戶用自然語言描述任務(wù)和步驟）。每個電子表格都有一個內(nèi)部依賴關(guān)系圖，用于確定每列的執(zhí)行順序。這些順序會分配給每一行的 Agent 并行執(zhí)行任務(wù)，處理數(shù)據(jù)轉(zhuǎn)換、API 調(diào)用、內(nèi)容檢索和發(fā)送消息等流程：
生成 Manasheet 可以的方法為：輸入類似上面紅色框里的自然語言，如上圖中想向客戶可以發(fā)送定價的郵件，就可以通過 Chat 輸入 Prompt，來生成 Manasheet。通過 Manasheet 可以看到有客戶的姓名，客戶的郵箱，客戶所屬的行業(yè)，是否已經(jīng)發(fā)送郵件等信息；點擊 Execute Manasheet 即可執(zhí)行任務(wù)。
4. 生成式 UI (Generative UI)
“生成式 UI”有兩種不同的實現(xiàn)方式。
一種方式是由模型自行生成需要的的原始組件。這類似于 Websim 等產(chǎn)品。在后臺，Agent 主要編寫原始 HTML，使其能夠完全控制顯示的內(nèi)容。但是這種方法允許生成的 web app 質(zhì)量有很高的不確定性，因此最終結(jié)果可能看起來波動較大。
另一種更受約束的方法為：預(yù)定義一些 UI 組件，這通常是通過工具調(diào)用來完成的。例如，如果 LLM 調(diào)用天氣 API，則它會觸發(fā)天氣地圖 UI 組件的渲染。由于渲染的組件不是真正生成的（但是有更多選擇），因此生成的 UI 將更加精致，盡管它可以生成的內(nèi)容不完全靈活。
Case Study：
Personal AI 產(chǎn)品 dot
舉例來說，在 2024 年曾被稱為最好的 Personal AI 產(chǎn)品的 Dot，就是一個很好的生成式 UI 產(chǎn)品。
Dot 是 New Computer 公司的產(chǎn)品：其目標(biāo)是成為用戶的長期伴侶，而并不是更好的任務(wù)管理工具，據(jù)聯(lián)合創(chuàng)始人Jason Yuan講，Dot 的感覺是，當(dāng)你不知道該去哪里、該做什么或該說什么時，你就會求助于 Dot。這里舉兩個例子介紹產(chǎn)品是做什么的：
? 創(chuàng)始人 Jason Yuan 常常在深夜讓 Dot 推薦酒吧，說自己想要一醉方休，斷斷續(xù)續(xù)幾個月，某天下班之后，Yuan 再次問了相似的問題，Dot 竟然開始勸解 Jason，不能再這樣下去了；
? Fast Company 記者 Mark Wilson，也和 Dot 相處了幾個月的時間。有一次，他向 Dot 分享了書法課上他手寫的一個「O」，Dot 竟然調(diào)出了幾周前他手寫「O」的照片，夸他的書法水平提高了。
??隨著使用Dot的時間越來越多，Dot 更加理解了用戶喜歡打卡咖啡館，主動推送給主人附近的好咖啡館，附上了為何這個咖啡館好，最后還貼心的詢問是否要導(dǎo)航.
可以看到在這個咖啡館推薦的例子中，Dot 通過預(yù)定義 UI 組件，來達(dá)到 LLM-native 的交互效果。
5. 協(xié)作式 UX（Collaborative UX）
當(dāng) Agent 和人類一起工作時會發(fā)生什么？想想 Google Docs，客戶可以在其中與團隊成員協(xié)作編寫或編輯文檔，但倘如協(xié)作者之一是 Agent 呢？
Geoffrey Litt?和?Ink & Switch?合作的?Patchwork項目是人類- Agent 合作的一個很好的例子。（譯者注：這可能是最近 OpenAI Canvas 產(chǎn)品更新的靈感來源）。
協(xié)作式 UX 與前面討論的 Ambient UX 相比如何？LangChain創(chuàng)始工程師 Nuno 強調(diào)了兩者之間的主要區(qū)別，在于是否有并發(fā)性：
? 在協(xié)作式 UX 中，客戶和LLM 經(jīng)常同時工作，以彼此的工作為輸入；
? 在環(huán)境 UX 中，LLM 在后臺持續(xù)工作，而用戶則完全專注于其他事情。
記憶
記憶對于好的 Agent 體驗至關(guān)重要。想象一下如果你有一個同事從來不記得你告訴他們什么，強迫你不斷重復(fù)這些信息，這個協(xié)作體驗會非常差。人們通常期望 LLM 系統(tǒng)天生就有記憶，這可能是因為 LLM 感覺已經(jīng)很像人類了。但是，LLM 本身并不能記住任何事物。
Agent 的記憶是基于產(chǎn)品本身需要的，而且不同的 UX 提供了不同的方法來收集信息和更新反饋。我們能從 Agent 產(chǎn)品的記憶機制中看到不同的高級記憶類型——它們在模仿人類的記憶類型。
論文 CoALA: Cognitive Architectures for Language Agents 將人類的記憶類型映射到了 Agent 記憶上，分類方式如下圖的所示：
1. 程序記憶（Procedural Memory）：有關(guān)如何執(zhí)行任務(wù)的長期記憶，類似于大腦的核心指令集
? 人類的程序記憶：記住如何騎自行車。
? Agent 的程序記憶：CoALA 論文將程序記憶描述為 LLM 權(quán)重和 Agent 代碼的組合，它們從根本上決定了 Agent 的工作方式。
在實踐中，Langchain 團隊還沒有看到任何 Agent 系統(tǒng)會自動更新其 LLM 或重寫其代碼，但是確實存在一些 Agent 更新其 system prompt 的例子。
2. 語義記憶(Semantic Memory): 長期知識儲備
? 人類的語義記憶：它由信息片段組成，例如在學(xué)校學(xué)到的事實、概念以及它們之間的關(guān)系。
? Agent 的語義記憶：CoALA 論文將語義記憶描述為事實存儲庫。
在實踐中上，常常是通過使用 LLM 從 Agent 的對話或交互中提取信息來實現(xiàn)的。此信息的確切存儲方式通常是特定于應(yīng)用程序的。然后這些信息在將來的對話中檢索并插入到 System Prompt 中 以影響 Agent 的響應(yīng)。
3. 情景記憶（Episodic Memory）：回憶特定的過去事件
? 人類的情景記憶：當(dāng)一個人回憶起過去經(jīng)歷的特定事件（或“情節(jié)”）時。
? Agent 中的情景記憶：CoALA 論文將情景記憶定義為存儲 Agent 過去動作的序列。
這主要用于讓 Agent 按預(yù)期執(zhí)行動作。在實踐中，情景記憶的更新通過 Few-Shots Prompt 的方法實現(xiàn)。如果相關(guān)更新的 Few-Shots Prompt 足夠多，那么接下來的更新就通過 Dynamic Few-Shots Prompt 來完成。
如果一開始就有指導(dǎo) Agent 正確完成操作的辦法，后面面對同樣的問題就可以直接使用這種辦法；相反，如果不存在正確的操作方式，或者如果 Agent 不斷做新的事情，那么語義記憶就會更重要，反而在前面的例子中，語義記憶不會有太大幫助。
除了考慮要在 Agent 中更新的記憶類型外，開發(fā)人員還要考慮如何更新 Agent 的記憶：
更新 Agent 記憶的第一種方法是 “in the hot path”。在這種情況下， Agent 系統(tǒng)會在響應(yīng)之前記住事實（通常通過工具調(diào)用）， ChatGPT 采取這種方法更新其記憶；
更新 Agent 記憶的另一種方法是?“in the background”?。在這種情況下，后臺進程會在會話之后運行以更新記憶。
比較這兩種方法，“in the hot path” 方法的缺點是在傳遞任何響應(yīng)之前會有一些延遲，它還需要將 memory logic 與 agent logic 相結(jié)合。
但是， “in the background ”可以避免這些問題 – 不會增加延遲，并且 memory logic 保持獨立。但是“in the background ”也有其自身的缺點：記憶不會立即更新，并且需要額外的 logic 來確定何時啟動后臺進程。
更新記憶的另一種方法涉及用戶反饋，這與情景記憶特別相關(guān)。例如，如果用戶對某次交互標(biāo)評分較高（Postive Feedback），Agent 可以保存該反饋以備將來調(diào)用。
基于以上編譯內(nèi)容，我們期待規(guī)劃、交互、記憶三個組件的同時進步，會讓我們在 2025 年看到更多可用的 AI Agent，進入人機協(xié)同工作的新時代。
本文章轉(zhuǎn)載微信公眾號@海外獨角獸
