AI Agent 今年 4 月在開發者社群格外火熱，AutoGPT 成為 Github 歷史上漲星最快的專案。火熱的背後是 Agent 的思路為我們帶來了 Software 2.0 的圖景：LLM 作為推理引擎能力不斷增強，AI Agent 框架為其提供結構化思考的方法，軟體生產進入“3D 列印”時代，可以根據使用者需求進行個性化定製，agent 框架打造每個知識工作者信賴的 AI 工作夥伴。

但人們會高估短期影響， Agent 在實際知識工作中還不夠可靠。而且在未來，我們也認為 Autonomous Agent 不會是好的商業落地方向，因為其太過強調 LLM 的自驅和自動化規劃。

因此，我們認為agent 產品需要具備的特性是，要給產品設計者和使用者提供干預空間。目前實踐中最具代表性的有兩類：中間層的 Agent Framework 和垂直領域的 Vertical Agent。前者能讓行業中的領域專家為自己打造 Agent 工作夥伴和工作流分身，使未來的組織更加精簡；後者能在某一個領域中深耕行業的最佳實踐，並收集到高質量的專有工作流資料。其中 Coding Agent 是這兩個方向的結合，潛力很大能成為未來所有 Agent 與人類之間的翻譯官。

長期來看，我們對 AI Agent 需要保持耐心。一方面，OpenAI 等大模型公司會在 Agent 標準定義和模型推理能力上持續進化：11 月 OpenAI Devday 可能會踏出定義標準的第一步，當前 next token prediction 的模型對連續的複雜推理問題有根本性瓶頸，需要用更復雜、結構化的資料和目標函式來進一步學習。另一方面，Agent 的應用落地還需要 Generative UI 帶來的人機互動方式的革新，就像曾經施樂實驗室對個人 PC GUI 的定義。

我們在本文中探討了對 AI agent 的思考，並對這個領域看好的創業公司進行了 mapping。

AI agent 是有能力主動思考和行動的智慧體。當我們提出需求時，agent 有能力自行感知環境、形成記憶、規劃和決策行動，甚至與別的 agent 合作實現任務。對比之下，LLM 是被動的推理引擎，使用者每 prompt 點撥一次才會回覆一次。

由於 LLM 的能力邊界還在快速拓展，其產品形態仍有待探索，LLM-based Agent 的元件和定義還存在模糊的地方。我們根據現有的實踐，歸納了三種理解方式：

  未來的 AI-native 應用都會有 agent 的思路，產品形態可能是 Copilot，也可能還未出現。這一框架下 LLM 是核心推理引擎，而 agent 是使 LLM 揚長避短、結構化思考的方法論。

傳統軟體中有很多規則和啟發式演算法，帶來了高可靠性、確定性，但也使其難以靈活解決長尾問題。優秀的 AI agent 應用需要充分發揮 LLM 推理 (reason)、扮演 (act) 和互動 (interact) 的能力。

短期內，這樣的應用會犧牲一定軟體的可靠性，因此 agent 應用的落地現狀並不樂觀。但是沿著當前的技術路徑走下去，可以預期在長期達到與當前的傳統軟體接近的可靠性。

•  合作機制 orchestration：存在多模型、多 agent 分工與互動的機制設計，能實現複雜的工作流。例如程式設計場景下可能有 developer agents 和 quality assurance agents，類比開發團隊裡的工程師和測試；產品戰略場景下可能有 growth agents 和 monetization agents，類比公司中投放和商業化團隊在使用者規模和商業收入上的多目標博弈。

•  與環境互動 grounding：Agent 能理解自己的不足，並適時從外部尋找合適的工具解決問題。人和動物的區別是人會使用工具，agent 框架能幫助 LLM 認識自己的能力邊界，從外部環境中尋找合適的工具。

•  個性化記憶 memory：能記憶使用者偏好和工作習慣，使用越久越瞭解使用者。未來的 agent 作為人類的工作夥伴會接受大量文字和多模態資訊，過程中積累的使用者偏好和工作習慣會使產品成為知識工作者最信賴的夥伴。

•  主動決策 decision：Agent 有能力在虛擬環境中探索、試錯、迭代。目前的 LLM 應用還缺少在環境中連續決策的能力，因為 next token prediction 落子無悔的預測形式和人類的思考方式是截然不同的：開發者在 coding 解題的時候，會對一系列假設方案進行實驗總結出最優解，而不是在一開始就能夠得到最優解。

以上四個特點的實現時間由短到長排序：

•  短期：Orchestration 和 grounding 短期內值得重點探索，當下 LLM 能力還不夠強，需要自己與外部環境互動找到合適的工具，並且由使用者專家對 AI 的工作流進行設計和編排，使其成為靠譜的合作伙伴。如果當前的應用在這兩個方向上沒有足夠深的編排和實踐，不能稱為是 AI agent 應用。

•  中期：Memory 是需要重點強化的方向。隨著人類與 AI agent 的信任加深之後，如何讓人機協作帶來新的資料飛輪是一個相當重要的問題。有了個性化記憶的生成模型，是 Gen AI 時代新形態的推薦引擎。

•  長期：Decision 則是長期目標，也是需要 OpenAI、Anthropic 等大模型公司一起去解決的問題。目前的 next token prediction 模型和 chat-based UI，目標函式太簡單很難讓 agent 真正學會主動探索、試錯，需要模型複雜推理能力和產品形態的雙重進化。

說到這裡不難發現，當前這個領域還有很多問題等待解決，但我們仍然非常看好 AI Agent 的前景有很強的信心——

Andrej Karpathy 在著名部落格 "Software 2.0" 中探討過人工智慧改變軟體開發的方式：Software 2.0 意味著我們可以用大量的資料和算力來解決以前需要大量人力和成本來解決的複雜問題。AI agent 正是這一方式的具象化，因此開發者們對 AutoGPT 的興奮和 hype 都是情理之中。

AI agent 是達到這一圖景的可實現路徑：

一方面，成熟的 AI Agent 可以使軟體生產大幅降低成本。未來 Coding 工作流中會很多 agent 臨時寫成的軟體和測試方案，不追求長期的可複用性，可以隨用隨拋。因為其生產是自動化的，軟體生產的邊際成本趨近於 0（我們傾向於認為未來inference cost 會指數級降低）。目前一家軟體行業巨頭動輒上萬甚至十萬人，有了 AI agent 之後研發需要耗費的人力將大幅降低。

另一方面，軟體可以靈活地解決更多長尾需求，實現軟體生產的“3D列印”。現在能夠被抽象成大產品，讓公司願意投入大量人力開發的的軟體多是使用者量大、標準化、群體性的需求：聊天框、dashboard、CRM 系統。就像工廠出於成本考慮，訂單量大到一定程度才願意為產品開模生產。

但其實有很多相對小眾、長尾的需求沒有被充分滿足，需要使用者自己去實現使用過程中的最後一公里。這個問題在 SaaS 系統中經常出現，也帶來了比較重的運營和服務成本。而 AI Agent 有潛力能從根本上解決這一問題，就像從工廠流水線生產變成“3D列印”、服裝的大貨生產變成“小單快反”，為使用者帶來更個性化的產品。

Andrej Karparthy 在 State of LLM 演講中把 LLM 比作人類的系統 1。這一概念來自行為經濟學：人類思考模式可以被分為兩個系統，系統1是快速、直覺性的，負責我們的自動反應和本能決策；系統2是慢速、分析性的，負責我們的深思熟慮和複雜決策。

LLM 能勝任系統1的工作，因為它能夠快速地處理大量資訊並生成反饋，就像人類在聽到某事時的快速理解和回答。但 LLM 也會出現幻覺（hallucination）帶來的捏造事實問題，這一點同樣很像人類的系統 1 中常見的思維謬誤和本能反應。

AI agent 的長期目標則是使 LLM 勝任系統2的工作，為 LLM 搭建一套框架來進行深度思考和分析，從而做出更復雜和可靠的決策。一個典型的例子就是 chain/ tree of thoughts 系列研究，透過 prompting 加上 Python glue code 框架去模擬人類的複雜推理過程，激發出 LLM 更強的智慧。

模擬系統 2 的路徑會成為未來大模型公司和 Agent 創業公司共同思考和探索的問題。只通過 prompting 這類比較淺的方式無法從根本上進行最佳化，一定需要優秀的 framework 以及模型的設計最佳化來做到。這一定是 11 月 OpenAI Devday 進行釋出時會考慮的目標。

移動網際網路時代，AI重塑了人類接受資訊和知識的方式，誕生了 TikTok 這樣重要的資訊流產品。而來到 Gen AI 時代，LLM-based Agent 將改變人們進行知識工作的方式，誕生優秀的工作方式產品。

工作方式產品指的是人們可以根據自己的工作習慣進行定製化設計，設計自己合作的 AI 同事。當前的 Saas 產品是根據工作者的普遍需求取交集設計的。但實際應用中每個人的使用習慣都有所不同，尤其是高手會有特殊的使用方式。但目前相對機械死板的軟體設計並沒有給使用者靈活設計工作分身的空間。

而 AI agent 有能力實現這一需求。這一點在很多行業專家對 LLM 的使用中能夠初見端倪，例如陶哲軒把 GPT-4 當作了自己科研中的 thinking partner，未來好的 agent framework 將讓大家更好地設計和打造自己的合作伙伴。關於這一點，陶哲軒是這麼說的：

Agent 是在大模型語境下，可以理解成能自主理解、規劃、執行復雜任務的系統。LLM 是整個系統的“大腦”，圍繞其語言理解能力，Agent 系統有以下幾個模組組成：

LLM 是無狀態（stateless）的，大引數量使產品無法基於每一次互動的經驗來更新模型的內部引數。不過由於 LLM 能理解大量語義資訊，Agent 系統可以在模型之外建立一個記錄資訊的記憶系統，來模仿人類大腦那樣從過往的經驗中學習正確的工作模式。

以下分類根據醫學中人類的幾種記憶方式類比，將 AI agent 的記憶系統分為短期記憶與三種長期記憶：

•  工作記憶（Working Memory）：這一輪決策所需要用到的所有資訊。其中包括上下文內容，例如從長期記憶中檢索到的知識；也包括 LLM context 以外的資訊，例如 function call 時使用其他能力所產生的資料

•  事件記憶（Episodic Memory）：Agent 對過去多輪決策中所發生事情的記憶。每一次 LLM 有了新的行為和結果，agent 都會把內容寫進情節記憶。例如在 Generative agents 小鎮中，虛擬小鎮的 agent 居民會把自己每天看到的事、說過的話計入事件記憶。要使得使用者得到個性化的使用體驗，這一部分的最佳化是至關重要的。

•  語義記憶（Semantic Memory）：Agent 對自身所在世界的語義知識記憶，一般透過外部向量儲存和檢索來呼叫。這一部分記憶可以用類似知識圖譜的思路，使 agent 之間的知識更方便共享和更新。同樣以 Generative agents 小鎮為例，agent 居民會記憶其他居民的愛好、生日等資訊，這都是語義記憶。

•  程式記憶（Procedural Memory）：在一些特定場景下，agent 執行操作的 workflow 會透過程式碼的形式在框架中寫出來。這類記憶使部分行為能夠按照更可控的工作流來執行。以 Generative agents 小鎮類比，agent 居民會有自己的行為習慣，比如每天晚上要去某條街散步等等。

面對不同的任務，Agent 系統有一個完整的行動策略集，在決策時可以選擇需要執行的行動。以下羅列幾個最常見、重要的行為，實際應用中根據不同場景會有補充和優先順序的差異：

•  工具使用：智人與其他動物的重要區別是其使用工具的能力，而 LLM 同樣可以透過這一點來揚長避短。AI Agents 可以透過文件和資料集教會 agent 如何呼叫外部工具的 API，來補足 LLM 自身的弱項。例如複雜的數學計算就不是 LLM 的長處，呼叫 Calculator() 可以事半功倍。

•  職責扮演：AI agent 系統中，不同 LLM 需要進行分工的機制設計。就像在工廠和公司制中常常出現的角色配合和博弈那樣，LLM 之間也需要各司其職，按照各自的職責去完成任務，形成一個完整的協同組織。

•  記憶檢索：指的是從長期記憶中找到與本次決策相關的資訊，將其放到工作記憶、交給 LLM 處理的過程。

•  推理：從短期工作記憶生成新知識，並將其存入長期記憶中

•  學習：將新的知識和對話歷史加入長期記憶，讓 Agent 更瞭解使用者

•  程式設計：AI agent 可以實現很多長尾的開發需求，讓軟體變得接近定製。而程式設計是最適合 AI agent 去自己迭代和收集反饋（是否能有效執行）的環境，因為能自己形成反饋的閉環

前面提到很多行動可以由 Agent 進行規劃和執行，而決策這一步就是從中選擇最為合適的一個行為去執行。

•  事前規劃：LLM 能夠將一個大目標分解為較小的、可執行的子目標，以便高效的處理複雜任務。對於每一個目標，評估使用不同行為方案的可行性，選擇其中期望效果最好的一個。

•  事後反思：Agents 可以對過去的行為進行自我批評和反省，從錯誤中吸取經驗教訓，並加入長期記憶中幫助 agent 之後規避錯誤、更新其對世界的認知。這一部分試錯的知識將被加入長期記憶中

Autonomous agent 指的是完全由 LLM 自驅的規劃工作流、並完成任務的 agent 產品，最典型的就是今年 3 月釋出的 AutoGPT 和 BabyAGI。AutoGPT 釋出以來已經是 Github 歷史上漲星速度最快的專案。甚至不到 3 個月就超越了 PyTorch，可見其思想影響力之大。

以 AutoGPT 為首的 Autonomous agent 其實是把學術圈很多 agent 的點子（例如 ReAct、Reflexion、Generative Agents）用一個簡潔的 Python 專案的方式聚合在了一起，讓所有開發者感受到了 LLM 作為推理引擎的強大，引發了大量開發者進行各種有趣的實驗。最開始大家體驗到的是以下優點：

•  智慧程度和普適性高，能較好的理解和推理複雜的任務並且做出規劃

•  能高效的判斷並使用外部工具，整個過程的銜接非常流暢

但隨著使用深入，發現其實驗性強於實用性，大部分問題並不能真的解決：

•  效果不穩定，多步推理能力不夠：大部分產品 demo 看上去效果驚豔，但是對於抽象複雜的問題，能有效解決的比例不到 10%（讓AI自我規劃容易產生死迴圈，或者會出現一步走錯，步步走錯的問題），只適合解決一些中等難度的問題。這需要等 LLM 的下一次技術突破，尤其是其複雜推理能力的提升

•  外部生態融合度不高：第三方 api 支援的數量和生態不多（基本以搜尋和檔案讀取功能為主），很難做到比較完整的跨應用生態

而以上的這兩個缺陷正是 existing company 的優勢，第一點是 OpenAI/Anthropic 這類 LLM 公司的目標，第二點是 Apple/Google/Microsoft 這類有自己軟硬體生態、作業系統公司最適合做的。

因此儘管 AutoGPT 是好的思想實驗，但通用的 Autonomous agent 並不適合 startup 作為商業方向。

既然 Autonomous agent 不是好的商業方向，現階段適合創業公司的機會就是需要人為干預和設計的 agent 產品。目前有兩類介入使 Agent 更可控的思路，這兩類產品從不同的視角切入，我們認為都有未來的商業前景。

當下 AI Agent 領域中 startup 湧現的方向有二：一類是中間層，提供設計 agent 的 infra 工具，由使用者介入為 agent 提供規劃思路；一類深入細分垂類，運用 agent 思路設計 Copilot 產品，由產品設計者介入是 agent 思路更為可控。

中間層 Infra 關注的是提供實用可複用的 agent framework，降低開發 agent 的複雜度，併為 Agent 的合作提供機制設計。對於這樣的中間層基礎設施類工具，可以考慮從模組化、適配性、協作等方面進行創新：

a. 模組化設計：這是降低複雜性的關鍵。模組化設計可以讓開發者專注於特定的功能，而不需要關心整個系統的複雜性。有了獨立可解耦的感知、決策、執行模組，開發者可以靈活組合以適應不同需求。

這裡的模組化要求對 LLM 和 Agent 都有很深的理解，因為在低程式碼領域，模組化的顆粒度是一直備受討論的話題，抽象程度太高只能實現簡單任務，抽象程度低了其互動又難以承載。而在 agent 這樣更新的領域設計難度就更大了，Langchain 最近就遭遇了這樣的陣痛。

b. APIs 和 SDKs： 設計通用的介面與協議，讓不同的Agent可以相容配合。這些工具應當包括各種外掛，以便於在不同的環境中靈活地部署和使用 Agents。這裡潛在的風險是 OpenAI 有在密切關注與設計 agent 領域的 api，其與 LLM 的密切耦合會對該方向上目前的創新有降維打擊。

c. 合作機制設計：將 agent 應用到企業中去是一個複雜的問題，需要考慮許多因素：如與企業/使用者資料的共享、安全、許可權管理機制等；還有各 agent 之間的合作分工、層級方式，就像我們前面提到過的 Agent Framework 與工廠制、公司制存在著一定的相似度。理想情況下， Agent Framework 應該提供一種方式，使得各個 Agent 能輕鬆地協作，同時保證資料的安全和隱私。

而 Vertical Agent 則是深入某個垂直領域，理解該領域專家的工作流，快速形成 PMF 開始累積使用者資料。未來的 Copilot 類產品一定是多個 agent 在這一領域上的合作所實現的，也可能誕生更新的產品形態。這一領域的核心競爭力是領域知識針對性和互動反饋:

a. 領域知識：Agent 需要理解並掌握領域知識，以便於處理特定領域的問題。這可能包括專門的訓練資料、領域專家的輸入等。

b. 工作流理解：每個垂直領域都有自己的工作流，Agent 應用開發者需要選擇具體場景，理解真實使用者的工作流程，並探索如何與 AI 協同。例如，在法律領域，Agent 應用開發需要理解法律的工作流程，比如 Harvey 專攻的訴訟索賠流程。

c. 資料反饋：收集反饋資料的機制是非常重要的，這一點在 Coding 領域尤有著顯著的優勢。這可以幫助 Agent 不斷改進，更好地滿足使用者的需求。

d. 多 Agent 協作：在某些情況下，可能需要多個 Agent 合作來解決問題。例如，一個 Agent 可能負責收集資料，另一個 Agent 負責分析資料，再有一個 Agent 負責做出決策。這就需要一個強大的協作機制來支援這些 Agents 的合作。同時，也要避免Copilot形成過度依賴，保持使用者的主體地位來進行管理和 review 也同樣重要。

以下就基於 Agent Framework 和 Vertical Agent 這兩個重要方向，展開講講 AI agent 領域景觀。

前面提到過 AI Agent 未來的發展，會給各行各業的專家定製自己 AI 合作伙伴的能力。而 Agent 平臺就是各種能力 agent 的聚合平臺：不同agent專供不同細分領域或細分功能，例如“文章總結 agent”，“投資顧問 agent”。

這樣的平臺同時具有 PGC 和 UGC 特點，官方會定義一些預設的 Agent 設定，使用者可以在相對低程式碼（prompt 為主）的環境下自定義一些agent，並提供第三方API介面來實現多 agent 之間的協同和合作。此類產品的主要評價標準是：平臺 agent 的豐富度、自主開發易上手程度。其中 Fixie AI 是這一領域最具有代表性的公司。

Fixie.AI是一家於2022年在西雅圖成立的初創公司，他們將自己定位為“大語言模型的自動化平臺”，用於構建、託管和擴充套件AI Agent。創始人 Zach Koch 是Shopify 前產品總監，也曾擔任 Google Chrome 和 Android 團隊的產品主管；另外兩位創始人則來自 Xnor.ai（邊緣端 AI 解決方案公司，被 Apple 收購）、OctoML 等團隊。在 23 年初，他們得到了 Redpoint 領投的 1200 萬美元，成為了 Agent 平臺中的引領者。

其平臺中有大量官方和使用者建立的 agent。建立的成本比較低，只需要LLM+一些程式碼（讓LLM連結到外部資料如資料庫或API）再透過 Fixie 提供的工具即可讓使用者輕鬆的構建自己的Agent並且將其託管到平臺中。

以一個客服 agent 為例，實際使用時當 Fixie AI 收到使用者提的 support ticket：T恤的碼數出現錯誤時，LLM 會對加工其退換貨請求，然後將其拆解為以下幾個任務：

1. Call 訂單歷史 agent ：獲取訂單詳細資訊中的貨品號

2. Call 庫存 agent：瞭解當前該 SKU 的實際存貨

3.Call 標籤 agent：為該顧客的地址發一張退貨表親

4. Call 郵件回覆 agent：向該顧客生成一封客服郵件，溝通以上步驟獲得的資訊

這樣的Agent 系統背後大致是以下圖的架構實現的。當一個任務啟動之後，首先會由 Fixie 官方 agent 使用 Anthropic Claude 2 模型理解使用者需求，拆解成需要執行的任務。然後再將這個交給 Router agent（AI 分工總管），這個 agent 的職責是負責從 agent 庫中找到最合適的 agent，進而去執行任務。

Fixie 團隊在搭建平臺的同時，還發現 Gen AI 應用的前端開發需要更好的框架，於是基於 JSX 和 React 開發了 AI.JSX 。在前端框架中了一種能夠直觀、靈活地編排多個 LLM 呼叫的機制。在這個框架下，使用者可以依靠 LLM 從一組標準 React 元件動態構建 Generative UI。儘管這與 Agent 不直接相關，但 Generative UI 的確是未來 AI 應用最重要的部件之一。

其他典型案例：Spell, MindOS, Dify, Character.AI, Myshell

值得一提的是類似 Character AI 的產品現階段並不是 Agent 平臺，但有 agent 平臺的潛力。因為當其平臺上有大量 Chatbot 時，平臺可以根據使用者的需求為其選擇合適的角色來進行一段對話/完成一個任務，實現娛樂場景 function call 不同 IP 下的 agent。

前面提過 Autonomous agent 並不可靠，因為其可控性很差。而提高可控性最好的方式就是去幫 AI 設計 workflow，把規劃職責部分轉移給使用者。

這類 workflow 平臺和前面的 UGC 平臺最大的差異是切入點不同，更專注企業端客戶的工作流程。把業務流程交給企業中的業務實操者，而非 LLM來規劃，因此會更容易在企業端落地。

這是一家在語音領域有過一段時間積累的老公司，最早致力於為亞馬遜智慧音箱  Alexa 構建構建互動式語音娛樂平臺，後來他們開始專注於客服 Chatbot 軟體。與傳統其他客服軟體不同的是，他們希望為客服提供儘可能多的可能性，而 LLM 的出現為他們的願景帶來機會。

他們把產品改造成了適合 LLM agent 的設計平臺，可以在其中設計 LLM 的工作流。

其中有幾個比較有特色的功能：

對於 AI 對話類產品，使用者的話題常常會“跑偏”。Voiceflow 允許設計 Chatbot 的使用者設定意圖（Intent）變數並對意圖進行即時檢查，當用戶偏離正確路徑時，會引導使用者回到正軌上。

在一些重要的回答輪次中，使用者可以指定 AI 從使用者的回答中提取某些關鍵資訊，並將該資訊提取為狀態變數，在之後的對話中再次用到。

這類產品的開發門檻不高，但是對企業端落地非常實用，需要兼具對工作流需求和對 LLM 的理解

類似產品：Steamship, Ironclad Rivet

Coding 是 agent 方向中我最看好能快速落地的，且有可能成為未來所有 Agent 的底層翻譯員。開發領域解決的問題形式化、輸入的資料結構化，非常適合 AI 學習和收集資料反饋：生成的程式碼是否達到開發者的預期，使用者如何與開發出的應用進行互動等等。

而且開發領域也有著清晰的工作流，成本更低的垂直生成模型，而 Devops 等 Infra 工具則相對零散。因此開發領域使用 agent 思路的產品是最多的，我們根據各產品的形態將其分為 6 類：

可以根據 LLM 需要學習的使用者行為設計埋點，更好地收集開發中的行為反饋。並且 IDE 可以將開發中的版本控制、測試等流程完整地涉及，覆蓋一個專案開發上限的完整生命週期。隨著 LLM 對開發工作流的逐漸滲透，雲 IDE 的開發協作平臺可能成為新的開發者入口。

Cursor 是一款由 Anysphere 團隊開發的 IDE，他們得到 OpenAI 生態基金的投資，在 GPT-4 釋出的第一時間就將其加入了自己的產品中。

他們將自己的產品稱為 AI-first IDE，其產品 UI 與 VS Code 接近，加入了很多 LLM 原生的 feature，比 Github Copilot 能做得更深入。可以認為是 AI agent 化的 VS Code + Github Copilot：

Cursor 可以直接輸入連結，LLM 會閱讀開發者文件進行總結，並在之後的開發過程中隨時檢索使用。這一點符合 agent 能進行外部行為和世界知識記憶的特點：

在 debug 檢查錯誤的階段，Cursor 也用了 agent feature 去進行自動化反思。當出現問題時點選下圖中藍色的 auto debug，agent 將開始產生一個基於專案所有程式碼的 debug 思維鏈，並重新生成正確的程式碼直到解決了問題。相比起來，Github Copilot 如果出現類似問題，只能在 Chat UI 中告訴 Copilot 出現問題時的報錯方式，透過對話的形式來試圖解決。Cursor 在 IDE 中的 debug 和除錯是更為深入和閉環的。

Generative UI 是 Chat UI 和 GUI 結合最重要的元件之一。當靈活的  UI 生成實現之後，AI 應用中隨用隨拋的軟體創造就距離不遠了：使用者可以根據自己的長尾需求生成臨時的 UI 完成任務。

我們在之前的研究中提到過，目前在真正存在資料飛輪的 AI 產品只有兩個：Github Copilot 和 Midjourney。而 Generative UI 的使用者反饋既可以是 Copilot 式的程式碼最佳化，也可以是 MJ 的四選一，想象空間很大。

v0 是由 Vercel 團隊打造的 AI 前端程式碼生成工具。其使用過程非常直接：使用者使用自然語言描述需求，v0 根據需求描述來生成元件程式碼。然後使用者繼續對不滿意的地方提出修改意見，將其迭代為 v1、v2… 直到滿足使用者的要求。

由於前端的特殊屬性，其 UI 和互動方式更加直觀：當我們想將一個生成網頁的標題改為漸變色時，只需要選擇標題部分並提出“增加一個漸變色”，產品便會只對這一部分程式碼進行修改。

第一步使用者用比較長的 prompt 描述了頁面中核心文字框和內容的形式。

第二步在網頁下方加入導航頁引向別的頁面：

此外其他幾類產品也有著各自比較值得關注的點：

•  Coding Copilot 類的助手產品是 Github Copilot 最擅長的領域，其產品同時包括了程式碼編輯、程式碼生成，和 Chat 形式的問答式程式設計，對於該方向可以做的產品基本都在 Github 的射程之內，其他創業公司的機會可能相對小一些。他們目前做得不夠好的，就是企業使用者的離線部署和隱私安全。

•  餘下的三個方向，都是開發領域相對垂直的方向，之前有一些 devops 工具，但是有了 LLM 確實能夠更好的解決對應的問題：

     •  Fix code issues 產品中 LLM 解決的是之前按規則修復 issue 不夠 scalable 的問題。有了 LLM 的理解和生成能力，確實能夠高效地解決很多之前有難度的長尾問題。

     •  Code migration 中 LLM 發揮的作用與 Fix code issues 的作用接近。區別在於 fix code issues 是一個特別高頻、瑣碎的需求，而 code migration 是一個相對低頻但 heavylifting 的工作，前者的實現可能性和容錯率更高一些。

對於很多矽谷的優秀投資人/創始人而言，executive assistant 的同事非常重要，優秀的行政同事能夠做到最合理的日程管理和對外溝通。但這件事情本身並不是 ChatGPT 這類產品能夠實現的，因為助理任務往往需要很多隱式上下文（latent context）。優秀的助理安排線上 zoom meeting 和線下飯局時需要考慮的因素很多：見面對方的重要性、當天的其他日程、交通天氣、地理位置和偏好等等。這些任務的實現很需要 agent 的記憶和工具模組來獲得一些背後隱藏的資訊。

Lindy.ai 是一款基於辦公場景的智慧個人AI助手產品，幫助使用者智慧化處理日常辦公任務。Lindy 由來自 Uber 的產品 head Flow Crivellow成立，該團隊在 LLM 浪潮來臨前的創業方向是線上協同辦公。也正是基於他們對辦公場景比較深的理解，他們對自己產品的定位是 personal AI executive assistant。

其主要產品功能包括：

•  智慧日程規劃及預定

•  郵件起草及傳送

•  每日日程總結

•  會議紀要撰寫及總結

•  銷售：根據會議更新CRM

•  招聘：自動搜尋候選人併發送郵件

•  日程規劃：自動傳送日程郵件和更新日曆

•  市場營銷：起草營銷方案

類似產品：

從 GPT-3 開始，個人寫作助手類產品就是最快能夠為使用者提供價值、產生收入的。撰寫工作郵件、銷售文案等場景加入了 LLM 的文字理解、生成能力都有著比較明顯的效果最佳化，因此我們會看到去年的 Jasper、今年的 Writer.ai 都在使用者反饋和商業化收入上做到了不錯的效果。

但這一領域常被詬病的問題是沒有 moat，其產品核心的創作能力來自 LLM 的技術壁壘。而 Agent 的出現給 writing agent 了一個新的技術路徑： 讓我們的寫作助理可以自由的與網路互動， 透過瀏覽能力和呼叫工具能力的增強來提升寫作體驗，並且能將產品的功能延伸至其他領域，比如線上預定行程、線上購買物品等同樣需要 agent action 的使用者行為。

Hyperwriter 是由來自紐約的 AI 公司 Otherside AI 開發的產品，很大部分 AI for writing 公司一樣，他們的產品以輔助寫作的 Chrome 外掛為最早的形態。

隨著 Agent 類產品的釋出，他們很快在自己的外掛中開始結合 agent 的能力。團隊在 8 月釋出了第一個 agent 方向微調的大模型 Agent-1，可以做到在 Google Chrome 中透過閱讀前端程式碼，理解網頁佈局，並找到正確的地方填寫引數。在他們對外的 demo 中，該 agent 在 UI 設計非常難用的 GCP 介面能夠成功在正確的文字框填寫內容、完成操作。

我們在預約去美國機票的時候也使用了這個 agent 外掛，總體感覺優點和缺點比較鮮明。優點是：

•  功能比較強大，能理解指令自動訪問網頁，找到對應的引數位置然後填寫

•  能清晰即時地看到他的每一步規劃和操作

但其缺點也對於現在的 agent 應用有普世性：

•  每一步操作中，模型思考碎碎唸的步驟很多，效率較低

•  因為大模型的 latency 不夠低，有明顯的卡頓感

•  容易進入死迴圈，缺少自己糾錯和反問的能力：寫指令時沒有寫單程還是來回，agent 的操作就卡住了需要人工介入

總的來說，寫作和瀏覽場景都是適合 agent 發揮的領域。但確實對於這個方向的創業公司來說，需要意識到這是 OpenAI、Anthropic 等大模型公司一定也會涉足探索的方向，需要儘快積累使用者資料獲得獨特的優勢。

資料分析的大部分工作是可以離線完成的，例如資料視覺化、探索性實驗等。因此相比程式設計開發而言，資料分析對 latency、穩定性的要求更低，對其分析能力、資料安全性的要求更高。同時 LLM 的確對結構化資料有了更好的理解和加工能力，讓很多原本重複、機械的 BI 任務能夠自動完成。

因此 OpenAI code interpreter 上線之後，使用者主要的 use case 都集中在做資料分析上。Code Interpreter 在這一領域的侷限也相當明顯：無法處理超過 1000 行的資料表，沒有辦法規模化地處理嚴肅任務。而且這個方向也不是 OpenAI 的主要重心，這就為創業公司留下了機會。

目前在 Analytics + LLM 方向的公司很多，其中大部分都有使用 Agent 思路。最為代表性的是三家基於 Notebook 形式的產品：Julius AI 是一個 AI-native 新產品中的代表，而 Hex 和 Deepnote 這兩家相對成熟一些的公司也在自己的 Notebook 產品中集成了 Analytics Agent。

Julius AI founding team 的核心成員 Matt Brockman 來自上文 Hyperwrite（其公司為 Otherside AI）的團隊。獨立創業後他們的產品得到了 YC 和 AI Grant 的支援。

他們的產品是基於外部 LLM api 的能力進一步最佳化資料能力開發的 agent 應用。實際使用中，開展一個分析前需要設定這次分析的主題和對話風格。這一步使用了其 Agent 的職責扮演能力：

在執行資料分析時，Julius 也能夠執行多步的資料加工處理：資料聚合、視覺化，再到最後的建模分析和模型評估。每一步 agent 會盡量把自己的操作過程用文字表達出來，同時也可以檢視其執行時的程式碼以 review 準確性：

Julius 目前的使用體驗確實明顯優於 Code Interpreter，能更好更快地處理資料、且能比較準確地理解使用者意圖。同時也能感覺到目前的 analytics agent 還在一個處理 toy case 的階段，並不能用於處理複雜的任務。

在現實的資料分析場景中，往往需要對資料和業務場景進行更多維度的理解和探索，規劃自己的分析思路。但目前 Julius、Hex、Deepnote 這些產品都不能在接觸到資料集，之後主動根據需求去規劃和拆解一些分析任務。這個需要更多的業界合作和資料積累才能夠有效地實現，成為資料科學家的工作夥伴和分身。

現在在 AI 應用領域，繞不開的話題是 OpenAI 會做什麼、不會做什麼。對於 AI Agent 領域也是如此，Andrej Karpathy 多次表示了對 Agent 前景的看好，OpenAI 很可能會在 11 月的 devday 釋出定義 AI Agent 的 api 和開發框架。我們對 OpenAI 的釋出有以下預測：

•  OpenAI 發的 Agent 框架可能與他們在 16 年釋出的 OpenAI Gym 接近。當時 Greg 等人寫的框架為之後的 RL 研究使用的環境定義了統一的標準：obs, reward, done, info = env.step(action) 這樣的形式很出色地將 RL 中的學術概念模組化，這次他們也很可能會對 AI Agent 做類似的框架定義，例如 Memory, Action, Agent class 等。

•  Agent api/framework 會和 fine-tune api 兩者結合會成為比較完備的 to B 服務體系。企業可以透過定義 agent 更好地使用 LLM 並收集領域資料和行為序列，為 fine-tune 提供更完整的資料反饋；同時 fine-tune 又可以支援在某個領域有更專業、可靠的 agent，兩者一起能使 LLM 在企業端更容易落地。這對 Anthropic 這樣的競爭者在後續的 api 釋出會帶來挑戰。

上文中 OpenAI Gym 的圖片中也出現了 Agent 這個詞，其實 AI 領域 agent 的概念並非第一次出現，強化學習中的智慧體也是非常符合 AI agent 的定義，但是技術路徑完全不同。RL-based agent 是透過大量與環境的互動試錯，評估不同行動的結果，根據獎勵或懲罰來更新其策略，最終學會如何執行任務。

但強化學習一直距離大規模落地存在著距離，因為其職能在一小部分場景之下使用，泛化能力較弱。這一小部分場景的特點是：其環境下的策略有限、能用數學完美地模擬復現。例如圍棋、Flappy Bird 這類非開放、有明確輸贏目標的遊戲，RL 能夠做到比最優秀的人類更出色。但是當 agent 被放在一個隨時可能變化的場景中，如通用機器人、自動駕駛想達到的目標，一旦當環境出現變化時 RL-based agent 的泛化能力就會遇到瓶頸。

泛化能力正是 LLM 的強項，也是這次 LLM-based agent 大火的重要原因。且大模型壓縮了大量世界的語義資訊，讓模型有能力在接觸環境時真正理解環境中每一個物品是什麼、發揮什麼作用，進而根據使用者需求並進行規劃和執行。這解決了很多之前 RL 無法定義的長尾問題。

但技術上的 tradeoff 也帶來了很多落地困難的問題，其中與強化學習對比最欠缺的是：當前的 LLM agent 還沒有高效從錯誤中學習的能力。由於 LLM 本身訓練成本高，不可能根據每個任務和犯錯經驗去調整引數，目前還沒有特別好的從錯誤中吸取經驗的 practice。trial-and-error 模式的可行性是對 AI agent 的挑戰。目前強化學習還只在 LLM 的 RLHF 階段出現，在 agent 領域引入 RL 的思想可能能幫助 AI Agent 有進一步的突破。

讓我們回到 agent 這個詞的本意：代理人，也就是具備主動決策能力、代為行使權力的智慧體。這兩個修飾詞之間是有因果關係的，這對 AI agent 的實際落地有啟發：只有證明了 AI 的決策可靠，使用者才願意交給 Agent 代為行使權力。

目前 AI Agent 實際落地的問題中有兩個瓶頸是來自於 LLM 作為推理引擎不夠強大：

•  現有的LLM雖然在某些領域的任務上表現不錯，但對於需要多步複雜推理的任務，表現還是很弱。這主要是因為LLM的訓練目標是next token prediction，而不是進行復雜的推理。所以在需要鏈狀推理的任務上，LLM的表現仍有很大提升空間。這個提升空間來自於模型架構和資料上的最佳化。可以用更復雜的訓練任務使LLM學習複雜推理，如問答、閱讀理解、分步規劃等。

•  同時，LLM 響應輸入和執行任務的速度還很慢。目前尚在技術早期，大家對 LLM 的延遲寬容度還比較高。但未來對於許多應用來說，低延遲是至關重要的，其速度直接影響了知識工作者的工作效率。例如最極端的，在自動駕駛汽車或高頻交易系統中，延遲的減小可能會直接影響到系統的效能和安全性。 因此需要透過知識蒸餾、模型壓縮等方法縮小模型大小，降低計算量，並且等待大模型推理硬體和演算法側的持續最佳化。

其中，延遲最佳化是工程問題，需要業界的時間來漸進式最佳化；更難的瓶頸還在複雜推理能力上，這是個需要被解決的科學問題，將隨著科研的進展和 agent 行為序列資料的累積逐漸明朗。

在 AI agent 框架中，其中的 AI 之間會有大量的文字/程式碼溝通與協作，因此 AI agent 產生的 token 數會有數量級的上升，需要模型側進行持續的成本最佳化。AI 小鎮框架開源之後，根據開發者的測試一個 agent 一天需要消耗 20 美金價格的 token 數，因為其需要記憶和行動的思考量非常大。這一價格是比很多人類工作者更高的，需要後續 agent 框架和 LLM 推理側的雙重最佳化。

與成本對應的是合作機制中的多 agent 場景下需要更明確的目標和激勵機制，類比強化學習中的 reward function。這一個方向是目前還沒有好的實踐，可能是 web 3 token 機制適合引入的方向。數字貨幣與程式碼，可能是未來 Agent 生產和協作過程中相當重要的生產要素。由於篇幅限制，這一點就暫不詳細展開了。

總的來說，我們對 AI Agent 需要保持耐心。一方面，OpenAI 等大模型公司會在 Agent 標準定義和模型推理能力上持續進化：11 月 OpenAI Devday 可能會踏出定義標準的第一步，連續的複雜推理問題對於當前 next token prediction 的模型存在根本性的瓶頸，需要用更復雜、結構化的資料和目標函式來進一步學習。另一方面，Agent 的應用落地還需要 Generative UI 帶來的人機互動方式的革新，就像曾經施樂實驗室對個人 PC GUI 的定義。這也需要業界持續探索和創新才能逼近正確答案。

1. Theodore Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths. Cognitive Architectures for Language Agents: https://arxiv.org/pdf/2309.02427.pdf