作者：Cage
編輯：Penny
排版：Gisele
AI Agent 今年 4 月在開發(fā)者社區(qū)格外火熱，AutoGPT 成為 Github 歷史上漲星最快的項(xiàng)目�；馃岬谋澈笫� Agent 的思路為我們帶來了 Software 2.0 的圖景：LLM 作為推理引擎能力不斷增強(qiáng)，AI Agent 框架為其提供結(jié)構(gòu)化思考的方法，軟件生產(chǎn)進(jìn)入“3D 打印”時(shí)代，可以根據(jù)用戶需求進(jìn)行個(gè)性化定制，agent 框架打造每個(gè)知識(shí)工作者信賴的 AI 工作伙伴。
但人們會(huì)高估短期影響， Agent 在實(shí)際知識(shí)工作中還不夠可靠。而且在未來，我們也認(rèn)為 Autonomous Agent 不會(huì)是好的商業(yè)落地方向，因?yàn)槠涮^強(qiáng)調(diào) LLM 的自驅(qū)和自動(dòng)化規(guī)劃。
因此，我們認(rèn)為agent 產(chǎn)品需要具備的特性是，要給產(chǎn)品設(shè)計(jì)者和用戶提供干預(yù)空間。目前實(shí)踐中最具代表性的有兩類：中間層的 Agent Framework 和垂直領(lǐng)域的 Vertical Agent。前者能讓行業(yè)中的領(lǐng)域?qū)＜覟樽约捍蛟?Agent 工作伙伴和工作流分身，使未來的組織更加精簡(jiǎn)；后者能在某一個(gè)領(lǐng)域中深耕行業(yè)的最佳實(shí)踐，并收集到高質(zhì)量的專有工作流數(shù)據(jù)。其中 Coding Agent 是這兩個(gè)方向的結(jié)合，潛力很大能成為未來所有 Agent 與人類之間的翻譯官。
長(zhǎng)期來看，我們對(duì) AI Agent 需要保持耐心。一方面，OpenAI 等大模型公司會(huì)在 Agent 標(biāo)準(zhǔn)定義和模型推理能力上持續(xù)進(jìn)化：11 月 OpenAI Devday 可能會(huì)踏出定義標(biāo)準(zhǔn)的第一步，當(dāng)前 next token prediction 的模型對(duì)連續(xù)的復(fù)雜推理問題有根本性瓶頸，需要用更復(fù)雜、結(jié)構(gòu)化的數(shù)據(jù)和目標(biāo)函數(shù)來進(jìn)一步學(xué)習(xí)。另一方面，Agent 的應(yīng)用落地還需要 Generative UI 帶來的人機(jī)交互方式的革新，就像曾經(jīng)施樂實(shí)驗(yàn)室對(duì)個(gè)人 PC GUI 的定義。
我們?cè)诒疚闹刑接懥藢?duì) AI agent 的思考，并對(duì)這個(gè)領(lǐng)域看好的創(chuàng)業(yè)公司進(jìn)行了 mapping。
以下為本文目錄，建議結(jié)合要點(diǎn)進(jìn)行針對(duì)性閱讀。
01 關(guān)于 AI agent 的四個(gè)關(guān)鍵問題
02 AI agent landscape
03 AI Agent 的未來展望
01.
關(guān)于 AI agent的
四個(gè)關(guān)鍵問題
What are agents:
怎么理解 AI Agent
AI agent 是有能力主動(dòng)思考和行動(dòng)的智能體。當(dāng)我們提出需求時(shí)，agent 有能力自行感知環(huán)境、形成記憶、規(guī)劃和決策行動(dòng)，甚至與別的 agent 合作實(shí)現(xiàn)任務(wù)。對(duì)比之下，LLM 是被動(dòng)的推理引擎，用戶每 prompt 點(diǎn)撥一次才會(huì)回復(fù)一次。
由于 LLM 的能力邊界還在快速拓展，其產(chǎn)品形態(tài)仍有待探索，LLM-based Agent 的組件和定義還存在模糊的地方。我們根據(jù)現(xiàn)有的實(shí)踐，歸納了三種理解方式：
1. AI agent 是 AI-native software 的開發(fā)方法，不是獨(dú)立的商業(yè)賽道或產(chǎn)品形態(tài)。
未來的 AI-native 應(yīng)用都會(huì)有 agent 的思路，產(chǎn)品形態(tài)可能是 Copilot，也可能還未出現(xiàn)。這一框架下 LLM 是核心推理引擎，而 agent 是使 LLM 揚(yáng)長(zhǎng)避短、結(jié)構(gòu)化思考的方法論。
2. 優(yōu)秀的 AI Agent 產(chǎn)品比傳統(tǒng)軟件更靈活，比 LLM 更可靠。
傳統(tǒng)軟件中有很多規(guī)則和啟發(fā)式算法，帶來了高可靠性、確定性，但也使其難以靈活解決長(zhǎng)尾問題。優(yōu)秀的 AI agent 應(yīng)用需要充分發(fā)揮 LLM 推理 (reason)、扮演 (act) 和交互 (interact) 的能力。
短期內(nèi)，這樣的應(yīng)用會(huì)犧牲一定軟件的可靠性，因此 agent 應(yīng)用的落地現(xiàn)狀并不樂觀。但是沿著當(dāng)前的技術(shù)路徑走下去，可以預(yù)期在長(zhǎng)期達(dá)到與當(dāng)前的傳統(tǒng)軟件接近的可靠性。
3. Agent 和早期的 LLM-based 應(yīng)用相比，有幾個(gè)顯著差異點(diǎn)：
合作機(jī)制 orchestration：存在多模型、多 agent 分工與交互的機(jī)制設(shè)計(jì)，能實(shí)現(xiàn)復(fù)雜的工作流。例如編程場(chǎng)景下可能有 developer agents 和 quality assurance agents，類比開發(fā)團(tuán)隊(duì)里的工程師和測(cè)試；產(chǎn)品戰(zhàn)略場(chǎng)景下可能有 growth agents 和 monetization agents，類比公司中投放和商業(yè)化團(tuán)隊(duì)在用戶規(guī)模和商業(yè)收入上的多目標(biāo)博弈。
與環(huán)境交互 grounding：Agent 能理解自己的不足，并適時(shí)從外部尋找合適的工具解決問題。人和動(dòng)物的區(qū)別是人會(huì)使用工具，agent 框架能幫助 LLM 認(rèn)識(shí)自己的能力邊界，從外部環(huán)境中尋找合適的工具。
個(gè)性化記憶 memory：能記憶用戶偏好和工作習(xí)慣，使用越久越了解用戶。未來的 agent 作為人類的工作伙伴會(huì)接受大量文本和多模態(tài)信息，過程中積累的用戶偏好和工作習(xí)慣會(huì)使產(chǎn)品成為知識(shí)工作者最信賴的伙伴。
主動(dòng)決策 decision：Agent 有能力在虛擬環(huán)境中探索、試錯(cuò)、迭代。目前的 LLM 應(yīng)用還缺少在環(huán)境中連續(xù)決策的能力，因?yàn)?next token prediction 落子無悔的預(yù)測(cè)形式和人類的思考方式是截然不同的：開發(fā)者在 coding 解題的時(shí)候，會(huì)對(duì)一系列假設(shè)方案進(jìn)行實(shí)驗(yàn)總結(jié)出最優(yōu)解，而不是在一開始就能夠得到最優(yōu)解。
以上四個(gè)特點(diǎn)的實(shí)現(xiàn)時(shí)間由短到長(zhǎng)排序：
短期：Orchestration 和 grounding 短期內(nèi)值得重點(diǎn)探索，當(dāng)下 LLM 能力還不夠強(qiáng)，需要自己與外部環(huán)境交互找到合適的工具，并且由用戶專家對(duì) AI 的工作流進(jìn)行設(shè)計(jì)和編排，使其成為靠譜的合作伙伴。如果當(dāng)前的應(yīng)用在這兩個(gè)方向上沒有足夠深的編排和實(shí)踐，不能稱為是 AI agent 應(yīng)用。
中期：Memory 是需要重點(diǎn)強(qiáng)化的方向。隨著人類與 AI agent 的信任加深之后，如何讓人機(jī)協(xié)作帶來新的數(shù)據(jù)飛輪是一個(gè)相當(dāng)重要的問題。有了個(gè)性化記憶的生成模型，是 Gen AI 時(shí)代新形態(tài)的推薦引擎。
長(zhǎng)期：Decision 則是長(zhǎng)期目標(biāo)，也是需要 OpenAI、Anthropic 等大模型公司一起去解決的問題。目前的 next token prediction 模型和 chat-based UI，目標(biāo)函數(shù)太簡(jiǎn)單很難讓 agent 真正學(xué)會(huì)主動(dòng)探索、試錯(cuò)，需要模型復(fù)雜推理能力和產(chǎn)品形態(tài)的雙重進(jìn)化。
說到這里不難發(fā)現(xiàn)，當(dāng)前這個(gè)領(lǐng)域還有很多問題等待解決，但我們?nèi)匀环浅？春?AI Agent 的前景有很強(qiáng)的信心
So what: 為什么 AI agent 重要？
1. AI Agent 將使軟件行業(yè)降低生產(chǎn)成本、提高定制化能力，進(jìn)入軟件的“3D 打印”時(shí)代
Andrej Karpathy 在著名博客 "Software 2.0" 中探討過人工智能改變軟件開發(fā)的方式：Software 2.0 意味著我們可以用大量的數(shù)據(jù)和算力來解決以前需要大量人力和成本來解決的復(fù)雜問題。AI agent 正是這一方式的具象化，因此開發(fā)者們對(duì) AutoGPT 的興奮和 hype 都是情理之中。
AI agent 是達(dá)到這一圖景的可實(shí)現(xiàn)路徑：
一方面，成熟的 AI Agent 可以使軟件生產(chǎn)大幅降低成本。未來 Coding 工作流中會(huì)很多 agent 臨時(shí)寫成的軟件和測(cè)試方案，不追求長(zhǎng)期的可復(fù)用性，可以隨用隨拋。因?yàn)槠渖a(chǎn)是自動(dòng)化的，軟件生產(chǎn)的邊際成本趨近于 0（我們傾向于認(rèn)為未來inference cost 會(huì)指數(shù)級(jí)降低）。目前一家軟件行業(yè)巨頭動(dòng)輒上萬甚至十萬人，有了 AI agent 之后研發(fā)需要耗費(fèi)的人力將大幅降低。
另一方面，軟件可以靈活地解決更多長(zhǎng)尾需求，實(shí)現(xiàn)軟件生產(chǎn)的“3D打印”�，F(xiàn)在能夠被抽象成大產(chǎn)品，讓公司愿意投入大量人力開發(fā)的的軟件多是用戶量大、標(biāo)準(zhǔn)化、群體性的需求：聊天框、dashboard、CRM 系統(tǒng)。就像工廠出于成本考慮，訂單量大到一定程度才愿意為產(chǎn)品開模生產(chǎn)。
但其實(shí)有很多相對(duì)小眾、長(zhǎng)尾的需求沒有被充分滿足，需要用戶自己去實(shí)現(xiàn)使用過程中的最后一公里。這個(gè)問題在 SaaS 系統(tǒng)中經(jīng)常出現(xiàn)，也帶來了比較重的運(yùn)營(yíng)和服務(wù)成本。而 AI Agent 有潛力能從根本上解決這一問題，就像從工廠流水線生產(chǎn)變成“3D打印”、服裝的大貨生產(chǎn)變成“小單快反”，為用戶帶來更個(gè)性化的產(chǎn)品。
2. LLM 扮演人類思考的系統(tǒng) 1（快思考），AI Agent 扮演人類思考的系統(tǒng) 2（慢思考）
Andrej Karparthy 在 State of LLM 演講中把 LLM 比作人類的系統(tǒng) 1。這一概念來自行為經(jīng)濟(jì)學(xué)：人類思考模式可以被分為兩個(gè)系統(tǒng)，系統(tǒng)1是快速、直覺性的，負(fù)責(zé)我們的自動(dòng)反應(yīng)和本能決策；系統(tǒng)2是慢速、分析性的，負(fù)責(zé)我們的深思熟慮和復(fù)雜決策。
LLM 能勝任系統(tǒng)1的工作，因?yàn)樗軌蚩焖俚靥幚泶罅啃畔⒉⑸煞答仯拖袢祟愒诼牭侥呈聲r(shí)的快速理解和回答。但 LLM 也會(huì)出現(xiàn)幻覺（hallucination）帶來的捏造事實(shí)問題，這一點(diǎn)同樣很像人類的系統(tǒng) 1 中常見的思維謬誤和本能反應(yīng)。
AI agent 的長(zhǎng)期目標(biāo)則是使 LLM 勝任系統(tǒng)2的工作，為 LLM 搭建一套框架來進(jìn)行深度思考和分析，從而做出更復(fù)雜和可靠的決策。一個(gè)典型的例子就是 chain/ tree of thoughts 系列研究，通過 prompting 加上 Python glue code 框架去模擬人類的復(fù)雜推理過程，激發(fā)出 LLM 更強(qiáng)的智能。
模擬系統(tǒng) 2 的路徑會(huì)成為未來大模型公司和 Agent 創(chuàng)業(yè)公司共同思考和探索的問題。只通過 prompting 這類比較淺的方式無法從根本上進(jìn)行優(yōu)化，一定需要優(yōu)秀的 framework 以及模型的設(shè)計(jì)優(yōu)化來做到。這一定是 11 月 OpenAI Devday 進(jìn)行發(fā)布時(shí)會(huì)考慮的目標(biāo)。
3. 推薦系統(tǒng)讓每個(gè)人看到個(gè)性化的信息， AI Agent 將讓每個(gè)人有個(gè)性化的工作方式，為每一個(gè)知識(shí)工作者提供 AI 合作伙伴和工作分身
移動(dòng)互聯(lián)網(wǎng)時(shí)代，AI重塑了人類接受信息和知識(shí)的方式，誕生了 TikTok 這樣重要的信息流產(chǎn)品。而來到 Gen AI 時(shí)代，LLM-based Agent 將改變?nèi)藗冞M(jìn)行知識(shí)工作的方式，誕生優(yōu)秀的工作方式產(chǎn)品。
工作方式產(chǎn)品指的是人們可以根據(jù)自己的工作習(xí)慣進(jìn)行定制化設(shè)計(jì)，設(shè)計(jì)自己合作的 AI 同事。當(dāng)前的 Saas 產(chǎn)品是根據(jù)工作者的普遍需求取交集設(shè)計(jì)的。但實(shí)際應(yīng)用中每個(gè)人的使用習(xí)慣都有所不同，尤其是高手會(huì)有特殊的使用方式。但目前相對(duì)機(jī)械死板的軟件設(shè)計(jì)并沒有給用戶靈活設(shè)計(jì)工作分身的空間。
而 AI agent 有能力實(shí)現(xiàn)這一需求。這一點(diǎn)在很多行業(yè)專家對(duì) LLM 的使用中能夠初見端倪，例如陶哲軒把 GPT-4 當(dāng)作了自己科研中的 thinking partner，未來好的 agent framework 將讓大家更好地設(shè)計(jì)和打造自己的合作伙伴。關(guān)于這一點(diǎn)，陶哲軒是這么說的：
目前通過努力，人類專家可以將 LLM 不起作用的想法修改為正確和原創(chuàng)的論點(diǎn)。2023級(jí)別的AI已經(jīng)可以為數(shù)學(xué)家生成建議性的提示和有前景的線索，并積極參與決策過程。我期待 2026 級(jí)別的AI，如果使用得當(dāng)，將成為數(shù)學(xué)研究以及許多其他領(lǐng)域中值得信賴的合作者。
實(shí)現(xiàn)這一需求對(duì)業(yè)界和學(xué)界的知識(shí)工作都將帶來巨大的變革。公司的組織架構(gòu)將有一部分外包給 AI agents，頂級(jí)組織也可以變得規(guī)模很小，這一趨勢(shì)已經(jīng)在 MidJourney, Character 這樣的新公司身上初見端倪。 同樣的思路也發(fā)生在科學(xué)領(lǐng)域：傳統(tǒng)的基于知識(shí)的革命需要的時(shí)間很長(zhǎng)，計(jì)數(shù)基本單位是按十年計(jì)，而 AI agent 有能力將其縮短為按年計(jì)。
Framework:
理想的 Agent 框架是什么樣的？
Agent 是在大模型語境下，可以理解成能自主理解、規(guī)劃、執(zhí)行復(fù)雜任務(wù)的系統(tǒng)。LLM 是整個(gè)系統(tǒng)的“大腦”，圍繞其語言理解能力，Agent 系統(tǒng)有以下幾個(gè)模塊組成：
1. 記憶：
LLM 是無狀態(tài)（stateless）的，大參數(shù)量使產(chǎn)品無法基于每一次交互的經(jīng)驗(yàn)來更新模型的內(nèi)部參數(shù)。不過由于 LLM 能理解大量語義信息，Agent 系統(tǒng)可以在模型之外建立一個(gè)記錄信息的記憶系統(tǒng)，來模仿人類大腦那樣從過往的經(jīng)驗(yàn)中學(xué)習(xí)正確的工作模式。
以下分類根據(jù)醫(yī)學(xué)中人類的幾種記憶方式類比，將 AI agent 的記憶系統(tǒng)分為短期記憶與三種長(zhǎng)期記憶：
短期記憶：
工作記憶（Working Memory）：這一輪決策所需要用到的所有信息。其中包括上下文內(nèi)容，例如從長(zhǎng)期記憶中檢索到的知識(shí)；也包括 LLM context 以外的信息，例如 function call 時(shí)使用其他能力所產(chǎn)生的數(shù)據(jù)
長(zhǎng)期記憶：
事件記憶（Episodic Memory）：Agent 對(duì)過去多輪決策中所發(fā)生事情的記憶。每一次 LLM 有了新的行為和結(jié)果，agent 都會(huì)把內(nèi)容寫進(jìn)情節(jié)記憶。例如在 Generative agents 小鎮(zhèn)中，虛擬小鎮(zhèn)的 agent 居民會(huì)把自己每天看到的事、說過的話計(jì)入事件記憶。要使得用戶得到個(gè)性化的使用體驗(yàn)，這一部分的優(yōu)化是至關(guān)重要的。
語義記憶（Semantic Memory）：Agent 對(duì)自身所在世界的語義知識(shí)記憶，一般通過外部向量存儲(chǔ)和檢索來調(diào)用。這一部分記憶可以用類似知識(shí)圖譜的思路，使 agent 之間的知識(shí)更方便共享和更新。同樣以 Generative agents 小鎮(zhèn)為例，agent 居民會(huì)記憶其他居民的愛好、生日等信息，這都是語義記憶。
程序記憶（Procedural Memory）：在一些特定場(chǎng)景下，agent 執(zhí)行操作的 workflow 會(huì)通過代碼的形式在框架中寫出來。這類記憶使部分行為能夠按照更可控的工作流來執(zhí)行。以 Generative agents 小鎮(zhèn)類比，agent 居民會(huì)有自己的行為習(xí)慣，比如每天晚上要去某條街散步等等。
2. 行動(dòng)：
面對(duì)不同的任務(wù)，Agent 系統(tǒng)有一個(gè)完整的行動(dòng)策略集，在決策時(shí)可以選擇需要執(zhí)行的行動(dòng)。以下羅列幾個(gè)最常見、重要的行為，實(shí)際應(yīng)用中根據(jù)不同場(chǎng)景會(huì)有補(bǔ)充和優(yōu)先級(jí)的差異：
工具使用：智人與其他動(dòng)物的重要區(qū)別是其使用工具的能力，而 LLM 同樣可以通過這一點(diǎn)來揚(yáng)長(zhǎng)避短。AI Agents 可以通過文檔和數(shù)據(jù)集教會(huì) agent 如何調(diào)用外部工具的 API，來補(bǔ)足 LLM 自身的弱項(xiàng)。例如復(fù)雜的數(shù)學(xué)計(jì)算就不是 LLM 的長(zhǎng)處，調(diào)用 Calculator() 可以事半功倍。
職責(zé)扮演：AI agent 系統(tǒng)中，不同 LLM 需要進(jìn)行分工的機(jī)制設(shè)計(jì)。就像在工廠和公司制中常常出現(xiàn)的角色配合和博弈那樣，LLM 之間也需要各司其職，按照各自的職責(zé)去完成任務(wù)，形成一個(gè)完整的協(xié)同組織。
記憶檢索：指的是從長(zhǎng)期記憶中找到與本次決策相關(guān)的信息，將其放到工作記憶、交給 LLM 處理的過程。
推理：從短期工作記憶生成新知識(shí)，并將其存入長(zhǎng)期記憶中
學(xué)習(xí)：將新的知識(shí)和對(duì)話歷史加入長(zhǎng)期記憶，讓 Agent 更了解用戶
編程：AI agent 可以實(shí)現(xiàn)很多長(zhǎng)尾的開發(fā)需求，讓軟件變得接近定制。而編程是最適合 AI agent 去自己迭代和收集反饋（是否能有效執(zhí)行）的環(huán)境，因?yàn)槟茏约盒纬煞答伒拈]環(huán)
3. 決策：
前面提到很多行動(dòng)可以由 Agent 進(jìn)行規(guī)劃和執(zhí)行，而決策這一步就是從中選擇最為合適的一個(gè)行為去執(zhí)行。
事前規(guī)劃：LLM 能夠?qū)⒁粋�(gè)大目標(biāo)分解為較小的、可執(zhí)行的子目標(biāo)，以便高效的處理復(fù)雜任務(wù)。對(duì)于每一個(gè)目標(biāo)，評(píng)估使用不同行為方案的可行性，選擇其中期望效果最好的一個(gè)。
事后反思：Agents 可以對(duì)過去的行為進(jìn)行自我批評(píng)和反省，從錯(cuò)誤中吸取經(jīng)驗(yàn)教訓(xùn)，并加入長(zhǎng)期記憶中幫助 agent 之后規(guī)避錯(cuò)誤、更新其對(duì)世界的認(rèn)知。這一部分試錯(cuò)的知識(shí)將被加入長(zhǎng)期記憶中
Is it now: 現(xiàn)狀如何？
1. Autonomous Agent 有很強(qiáng)的啟發(fā)意義，但缺乏可控性，不是未來的商用方向
Autonomous agent 指的是完全由 LLM 自驅(qū)的規(guī)劃工作流、并完成任務(wù)的 agent 產(chǎn)品，最典型的就是今年 3 月發(fā)布的 AutoGPT 和 BabyAGI。AutoGPT 發(fā)布以來已經(jīng)是 Github 歷史上漲星速度最快的項(xiàng)目。甚至不到 3 個(gè)月就超越了 PyTorch，可見其思想影響力之大。
以 AutoGPT 為首的 Autonomous agent 其實(shí)是把學(xué)術(shù)圈很多 agent 的點(diǎn)子（例如 ReAct、Reflexion、Generative Agents）用一個(gè)簡(jiǎn)潔的 Python 項(xiàng)目的方式聚合在了一起，讓所有開發(fā)者感受到了 LLM 作為推理引擎的強(qiáng)大，引發(fā)了大量開發(fā)者進(jìn)行各種有趣的實(shí)驗(yàn)。最開始大家體驗(yàn)到的是以下優(yōu)點(diǎn)：
智能程度和普適性高，能較好的理解和推理復(fù)雜的任務(wù)并且做出規(guī)劃
能高效的判斷并使用外部工具，整個(gè)過程的銜接非常流暢
但隨著使用深入，發(fā)現(xiàn)其實(shí)驗(yàn)性強(qiáng)于實(shí)用性，大部分問題并不能真的解決：
效果不穩(wěn)定，多步推理能力不夠：大部分產(chǎn)品 demo 看上去效果驚艷，但是對(duì)于抽象復(fù)雜的問題，能有效解決的比例不到 10%（讓AI自我規(guī)劃容易產(chǎn)生死循環(huán)，或者會(huì)出現(xiàn)一步走錯(cuò)，步步走錯(cuò)的問題），只適合解決一些中等難度的問題。這需要等 LLM 的下一次技術(shù)突破，尤其是其復(fù)雜推理能力的提升
外部生態(tài)融合度不高：第三方 api 支持的數(shù)量和生態(tài)不多（基本以搜索和文件讀取功能為主），很難做到比較完整的跨應(yīng)用生態(tài)
而以上的這兩個(gè)缺陷正是 existing company 的優(yōu)勢(shì)，第一點(diǎn)是 OpenAI/Anthropic 這類 LLM 公司的目標(biāo)，第二點(diǎn)是 Apple/Google/Microsoft 這類有自己軟硬件生態(tài)、操作系統(tǒng)公司最適合做的。
因此盡管 AutoGPT 是好的思想實(shí)驗(yàn)，但通用的 Autonomous agent 并不適合 startup 作為商業(yè)方向。
2. Agent Framework 和 Vertical Agent 是 AI agent 商業(yè)上最可行的兩個(gè)方向，需要持續(xù)探索人機(jī)交互的方式
既然 Autonomous agent 不是好的商業(yè)方向，現(xiàn)階段適合創(chuàng)業(yè)公司的機(jī)會(huì)就是需要人為干預(yù)和設(shè)計(jì)的 agent 產(chǎn)品。目前有兩類介入使 Agent 更可控的思路，這兩類產(chǎn)品從不同的視角切入，我們認(rèn)為都有未來的商業(yè)前景。
當(dāng)下 AI Agent 領(lǐng)域中 startup 涌現(xiàn)的方向有二：一類是中間層，提供設(shè)計(jì) agent 的 infra 工具，由用戶介入為 agent 提供規(guī)劃思路；一類深入細(xì)分垂類，運(yùn)用 agent 思路設(shè)計(jì) Copilot 產(chǎn)品，由產(chǎn)品設(shè)計(jì)者介入是 agent 思路更為可控。
中間層 Infra 關(guān)注的是提供實(shí)用可復(fù)用的 agent framework，降低開發(fā) agent 的復(fù)雜度，并為 Agent 的合作提供機(jī)制設(shè)計(jì)。對(duì)于這樣的中間層基礎(chǔ)設(shè)施類工具，可以考慮從模塊化、適配性、協(xié)作等方面進(jìn)行創(chuàng)新：
a. 模塊化設(shè)計(jì)：這是降低復(fù)雜性的關(guān)鍵。模塊化設(shè)計(jì)可以讓開發(fā)者專注于特定的功能，而不需要關(guān)心整個(gè)系統(tǒng)的復(fù)雜性。有了獨(dú)立可解耦的感知、決策、執(zhí)行模塊，開發(fā)者可以靈活組合以適應(yīng)不同需求。
這里的模塊化要求對(duì) LLM 和 Agent 都有很深的理解，因?yàn)樵诘痛a領(lǐng)域，模塊化的顆粒度是一直備受討論的話題，抽象程度太高只能實(shí)現(xiàn)簡(jiǎn)單任務(wù)，抽象程度低了其交互又難以承載。而在 agent 這樣更新的領(lǐng)域設(shè)計(jì)難度就更大了，Langchain 最近就遭遇了這樣的陣痛。
b. APIs 和 SDKs： 設(shè)計(jì)通用的接口與協(xié)議，讓不同的Agent可以兼容配合。這些工具應(yīng)當(dāng)包括各種插件，以便于在不同的環(huán)境中靈活地部署和使用 Agents。這里潛在的風(fēng)險(xiǎn)是 OpenAI 有在密切關(guān)注與設(shè)計(jì) agent 領(lǐng)域的 api，其與 LLM 的密切耦合會(huì)對(duì)該方向上目前的創(chuàng)新有降維打擊。
c. 合作機(jī)制設(shè)計(jì)：將 agent 應(yīng)用到企業(yè)中去是一個(gè)復(fù)雜的問題，需要考慮許多因素：如與企業(yè)/用戶數(shù)據(jù)的共享、安全、權(quán)限管理機(jī)制等；還有各 agent 之間的合作分工、層級(jí)方式，就像我們前面提到過的 Agent Framework 與工廠制、公司制存在著一定的相似度。理想情況下， Agent Framework 應(yīng)該提供一種方式，使得各個(gè) Agent 能輕松地協(xié)作，同時(shí)保證數(shù)據(jù)的安全和隱私。
而 Vertical Agent 則是深入某個(gè)垂直領(lǐng)域，理解該領(lǐng)域?qū)＜业墓ぷ髁�，快速形�?PMF 開始累積用戶數(shù)據(jù)。未來的 Copilot 類產(chǎn)品一定是多個(gè) agent 在這一領(lǐng)域上的合作所實(shí)現(xiàn)的，也可能誕生更新的產(chǎn)品形態(tài)。這一領(lǐng)域的核心競(jìng)爭(zhēng)力是領(lǐng)域知識(shí)針對(duì)性和交互反饋:
a. 領(lǐng)域知識(shí)：Agent 需要理解并掌握領(lǐng)域知識(shí)，以便于處理特定領(lǐng)域的問題。這可能包括專門的訓(xùn)練數(shù)據(jù)、領(lǐng)域?qū)＜业妮斎氲取?/p>
b. 工作流理解：每個(gè)垂直領(lǐng)域都有自己的工作流，Agent 應(yīng)用開發(fā)者需要選擇具體場(chǎng)景，理解真實(shí)用戶的工作流程，并探索如何與 AI 協(xié)同。例如，在法律領(lǐng)域，Agent 應(yīng)用開發(fā)需要理解法律的工作流程，比如 Harvey 專攻的訴訟索賠流程。
c.數(shù)據(jù)反饋：收集反饋數(shù)據(jù)的機(jī)制是非常重要的，這一點(diǎn)在 Coding 領(lǐng)域尤有著顯著的優(yōu)勢(shì)。這可以幫助 Agent 不斷改進(jìn)，更好地滿足用戶的需求。
d. 多 Agent 協(xié)作：在某些情況下，可能需要多個(gè) Agent 合作來解決問題。例如，一個(gè) Agent 可能負(fù)責(zé)收集數(shù)據(jù)，另一個(gè) Agent 負(fù)責(zé)分析數(shù)據(jù)，再有一個(gè) Agent 負(fù)責(zé)做出決策。這就需要一個(gè)強(qiáng)大的協(xié)作機(jī)制來支持這些 Agents 的合作。同時(shí)，也要避免Copilot形成過度依賴，保持用戶的主體地位來進(jìn)行管理和 review 也同樣重要。
以下就基于 Agent Framework和 Vertical Agent這兩個(gè)重要方向，展開講講 AI agent 領(lǐng)域景觀。
02.
AI agent landscape
1. Agent Framework
1.1 Agent Platform
前面提到過 AI Agent 未來的發(fā)展，會(huì)給各行各業(yè)的專家定制自己 AI 合作伙伴的能力。而 Agent 平臺(tái)就是各種能力 agent 的聚合平臺(tái)：不同agent專供不同細(xì)分領(lǐng)域或細(xì)分功能，例如“文章總結(jié) agent”，“投資顧問 agent”。
這樣的平臺(tái)同時(shí)具有 PGC 和 UGC 特點(diǎn)，官方會(huì)定義一些默認(rèn)的 Agent 設(shè)定，用戶可以在相對(duì)低代碼（prompt 為主）的環(huán)境下自定義一些agent，并提供第三方API接口來實(shí)現(xiàn)多 agent 之間的協(xié)同和合作。此類產(chǎn)品的主要評(píng)價(jià)標(biāo)準(zhǔn)是：平臺(tái) agent 的豐富度、自主開發(fā)易上手程度。其中 Fixie AI 是這一領(lǐng)域最具有代表性的公司。
Case Study：Fixie AI
Fixie.AI是一家于2022年在西雅圖成立的初創(chuàng)公司，他們將自己定位為“大語言模型的自動(dòng)化平臺(tái)”，用于構(gòu)建、托管和擴(kuò)展AI Agent。創(chuàng)始人 Zach Koch 是Shopify 前產(chǎn)品總監(jiān)，也曾擔(dān)任 Google Chrome 和 Android 團(tuán)隊(duì)的產(chǎn)品主管；另外兩位創(chuàng)始人則來自 Xnor.ai（邊緣端 AI 解決方案公司，被 Apple 收購(gòu)）、OctoML 等團(tuán)隊(duì)。在 23 年初，他們得到了 Redpoint 領(lǐng)投的 1200 萬美元，成為了 Agent 平臺(tái)中的引領(lǐng)者。
其平臺(tái)中有大量官方和用戶創(chuàng)建的 agent。創(chuàng)建的成本比較低，只需要LLM+一些代碼（讓LLM鏈接到外部數(shù)據(jù)如數(shù)據(jù)庫(kù)或API）再通過 Fixie 提供的工具即可讓用戶輕松的構(gòu)建自己的Agent并且將其托管到平臺(tái)中。
以一個(gè)客服 agent 為例，實(shí)際使用時(shí)當(dāng) Fixie AI 收到用戶提的 support ticket：T恤的碼數(shù)出現(xiàn)錯(cuò)誤時(shí)，LLM 會(huì)對(duì)加工其退換貨請(qǐng)求，然后將其拆解為以下幾個(gè)任務(wù)：
1. Call 訂單歷史 agent ：獲取訂單詳細(xì)信息中的貨品號(hào)
2. Call 庫(kù)存 agent：了解當(dāng)前該 SKU 的實(shí)際存貨
3.Call 標(biāo)簽 agent：為該顧客的地址發(fā)一張退貨表親
4. Call 郵件回復(fù) agent：向該顧客生成一封客服郵件，溝通以上步驟獲得的信息
這樣的Agent 系統(tǒng)背后大致是以下圖的架構(gòu)實(shí)現(xiàn)的。當(dāng)一個(gè)任務(wù)啟動(dòng)之后，首先會(huì)由 Fixie 官方 agent 使用 Anthropic Claude 2 模型理解用戶需求，拆解成需要執(zhí)行的任務(wù)。然后再將這個(gè)交給 Router agent（AI 分工總管），這個(gè) agent 的職責(zé)是負(fù)責(zé)從 agent 庫(kù)中找到最合適的 agent，進(jìn)而去執(zhí)行任務(wù)。
Fixie 團(tuán)隊(duì)在搭建平臺(tái)的同時(shí)，還發(fā)現(xiàn) Gen AI 應(yīng)用的前端開發(fā)需要更好的框架，于是基于 JSX 和 React 開發(fā)了 AI.JSX 。在前端框架中了一種能夠直觀、靈活地編排多個(gè) LLM 調(diào)用的機(jī)制。在這個(gè)框架下，用戶可以依靠 LLM 從一組標(biāo)準(zhǔn) React 組件動(dòng)態(tài)構(gòu)建 Generative UI。盡管這與 Agent 不直接相關(guān)，但 Generative UI 的確是未來 AI 應(yīng)用最重要的部件之一。
其他典型案例：Spell, MindOS, Dify, Character.AI, Myshell
值得一提的是類似 Character AI 的產(chǎn)品現(xiàn)階段并不是 Agent 平臺(tái)，但有 agent 平臺(tái)的潛力。因?yàn)楫?dāng)其平臺(tái)上有大量 Chatbot 時(shí)，平臺(tái)可以根據(jù)用戶的需求為其選擇合適的角色來進(jìn)行一段對(duì)話/完成一個(gè)任務(wù)，實(shí)現(xiàn)娛樂場(chǎng)景 function call 不同 IP 下的 agent。
1.2 Agent Workflow
前面提過 Autonomous agent 并不可靠，因?yàn)槠淇煽匦院懿�。而提高可控性最好的方式就是去�?AI 設(shè)計(jì) workflow，把規(guī)劃職責(zé)部分轉(zhuǎn)移給用戶。
這類 workflow 平臺(tái)和前面的 UGC 平臺(tái)最大的差異是切入點(diǎn)不同，更專注企業(yè)端客戶的工作流程。把業(yè)務(wù)流程交給企業(yè)中的業(yè)務(wù)實(shí)操者，而非 LLM來規(guī)劃，因此會(huì)更容易在企業(yè)端落地。
Case Study: Voiceflow
這是一家在語音領(lǐng)域有過一段時(shí)間積累的老公司，最早致力于為亞馬遜智能音箱 Alexa 構(gòu)建構(gòu)建交互式語音娛樂平臺(tái)，后來他們開始專注于客服 Chatbot 軟件。與傳統(tǒng)其他客服軟件不同的是，他們希望為客服提供盡可能多的可能性，而 LLM 的出現(xiàn)為他們的愿景帶來機(jī)會(huì)。
他們把產(chǎn)品改造成了適合 LLM agent 的設(shè)計(jì)平臺(tái)，可以在其中設(shè)計(jì) LLM 的工作流。
其中有幾個(gè)比較有特色的功能：
意圖識(shí)別與管理
對(duì)于 AI 對(duì)話類產(chǎn)品，用戶的話題常常會(huì)“跑偏”。Voiceflow 允許設(shè)計(jì) Chatbot 的用戶設(shè)置意圖（Intent）變量并對(duì)意圖進(jìn)行實(shí)時(shí)檢查，當(dāng)用戶偏離正確路徑時(shí)，會(huì)引導(dǎo)用戶回到正軌上。
從用戶回答中提取結(jié)構(gòu)化信息
在一些重要的回答輪次中，用戶可以指定 AI 從用戶的回答中提取某些關(guān)鍵信息，并將該信息提取為狀態(tài)變量，在之后的對(duì)話中再次用到。
這類產(chǎn)品的開發(fā)門檻不高，但是對(duì)企業(yè)端落地非常實(shí)用，需要兼具對(duì)工作流需求和對(duì) LLM 的理解
類似產(chǎn)品：Steamship, Ironclad Rivet
2. Vertical Agent
2.1 Coding Agent
Coding 是 agent 方向中我最看好能快速落地的，且有可能成為未來所有 Agent 的底層翻譯員。開發(fā)領(lǐng)域解決的問題形式化、輸入的數(shù)據(jù)結(jié)構(gòu)化，非常適合 AI 學(xué)習(xí)和收集數(shù)據(jù)反饋：生成的代碼是否達(dá)到開發(fā)者的預(yù)期，用戶如何與開發(fā)出的應(yīng)用進(jìn)行交互等等。
而且開發(fā)領(lǐng)域也有著清晰的工作流，成本更低的垂直生成模型，而 Devops 等 Infra 工具則相對(duì)零散。因此開發(fā)領(lǐng)域使用 agent 思路的產(chǎn)品是最多的，我們根據(jù)各產(chǎn)品的形態(tài)將其分為 6 類：
這 6 個(gè)方向中中，我最看好 LLM-first IDE 和 Generative UI 這兩個(gè)領(lǐng)域能誕生獨(dú)角獸。因?yàn)檫@兩個(gè)領(lǐng)域本身的數(shù)據(jù)飛輪是最為閉環(huán)，且?guī)淼?impact 也是最大的：
方向1: LLM-first IDE
可以根據(jù) LLM 需要學(xué)習(xí)的用戶行為設(shè)計(jì)埋點(diǎn)，更好地收集開發(fā)中的行為反潰并且 IDE 可以將開發(fā)中的版本控制、測(cè)試等流程完整地涉及，覆蓋一個(gè)項(xiàng)目開發(fā)上限的完整生命周期。隨著 LLM 對(duì)開發(fā)工作流的逐漸滲透，云 IDE 的開發(fā)協(xié)作平臺(tái)可能成為新的開發(fā)者入口。
Case Study: Cursor
Cursor 是一款由 Anysphere 團(tuán)隊(duì)開發(fā)的 IDE，他們得到 OpenAI 生態(tài)基金的投資，在 GPT-4 發(fā)布的第一時(shí)間就將其加入了自己的產(chǎn)品中。
他們將自己的產(chǎn)品稱為 AI-first IDE，其產(chǎn)品 UI 與 VS Code 接近，加入了很多 LLM 原生的 feature，比 Github Copilot 能做得更深入�？梢哉J(rèn)為是 AI agent 化的 VS Code + Github Copilot：
Cursor 可以直接輸入鏈接，LLM 會(huì)閱讀開發(fā)者文檔進(jìn)行總結(jié)，并在之后的開發(fā)過程中隨時(shí)檢索使用。這一點(diǎn)符合 agent 能進(jìn)行外部行為和世界知識(shí)記憶的特點(diǎn)：
在 debug 檢查錯(cuò)誤的階段，Cursor 也用了 agent feature 去進(jìn)行自動(dòng)化反思。當(dāng)出現(xiàn)問題時(shí)點(diǎn)擊下圖中藍(lán)色的 auto debug，agent 將開始產(chǎn)生一個(gè)基于項(xiàng)目所有代碼的 debug 思維鏈，并重新生成正確的代碼直到解決了問題。相比起來，Github Copilot 如果出現(xiàn)類似問題，只能在 Chat UI 中告訴 Copilot 出現(xiàn)問題時(shí)的報(bào)錯(cuò)方式，通過對(duì)話的形式來試圖解決。Cursor 在 IDE 中的 debug 和調(diào)試是更為深入和閉環(huán)的。
cursor 自動(dòng) debug
cursor 手動(dòng) debug
github copilot chat debug
方向2：Generative UI
Generative UI 是 Chat UI 和 GUI 結(jié)合最重要的組件之一。當(dāng)靈活的 UI 生成實(shí)現(xiàn)之后，AI 應(yīng)用中隨用隨拋的軟件創(chuàng)造就距離不遠(yuǎn)了：用戶可以根據(jù)自己的長(zhǎng)尾需求生成臨時(shí)的 UI 完成任務(wù)。
我們?cè)谥暗难芯恐刑岬竭^，目前在真正存在數(shù)據(jù)飛輪的 AI 產(chǎn)品只有兩個(gè)：Github Copilot 和 Midjourney。而 Generative UI 的用戶反饋既可以是 Copilot 式的代碼優(yōu)化，也可以是 MJ 的四選一，想象空間很大。
Case Study: Vercel v0
v0 是由 Vercel 團(tuán)隊(duì)打造的 AI 前端代碼生成工具。其使用過程非常直接：用戶使用自然語言描述需求，v0 根據(jù)需求描述來生成組件代碼。然后用戶繼續(xù)對(duì)不滿意的地方提出修改意見，將其迭代為 v1、v2... 直到滿足用戶的要求。
由于前端的特殊屬性，其 UI 和交互方式更加直觀：當(dāng)我們想將一個(gè)生成網(wǎng)頁的標(biāo)題改為漸變色時(shí)，只需要選擇標(biāo)題部分并提出“增加一個(gè)漸變色”，產(chǎn)品便會(huì)只對(duì)這一部分代碼進(jìn)行修改。
這款產(chǎn)品目前還在測(cè)試階段，但展現(xiàn)出的能力很優(yōu)秀，代碼生成基本正確且能很好的理解用戶需求�？梢詤⒖家粋�(gè)用戶目前使用 v0 生成機(jī)票訂購(gòu)頁面的實(shí)例：https://v0.dev/r/Sn4TuN1FuGP
第一步用戶用比較長(zhǎng)的 prompt 描述了頁面中核心文本框和內(nèi)容的形式。
第二步在網(wǎng)頁下方加入導(dǎo)航頁引向別的頁面：
第三步，在網(wǎng)頁中加入幾個(gè)建議的旅游方向：
此外其他幾類產(chǎn)品也有著各自比較值得關(guān)注的點(diǎn)：
Coding Copilot 類的助手產(chǎn)品是 Github Copilot 最擅長(zhǎng)的領(lǐng)域，其產(chǎn)品同時(shí)包括了代碼編輯、代碼生成，和 Chat 形式的問答式編程，對(duì)于該方向可以做的產(chǎn)品基本都在 Github 的射程之內(nèi)，其他創(chuàng)業(yè)公司的機(jī)會(huì)可能相對(duì)小一些。他們目前做得不夠好的，就是企業(yè)用戶的離線部署和隱私安全。
余下的三個(gè)方向，都是開發(fā)領(lǐng)域相對(duì)垂直的方向，之前有一些 devops 工具，但是有了 LLM 確實(shí)能夠更好的解決對(duì)應(yīng)的問題：
Codebase semantic search 問題中 LLM 解決的是之前的 indexing 和 keyword search 所不能覆蓋的 case，并且 LLM 有能力在宏觀上對(duì)代碼的結(jié)構(gòu)進(jìn)行一定的理解。
Fix code issues 產(chǎn)品中 LLM 解決的是之前按規(guī)則修復(fù) issue 不夠 scalable 的問題。有了 LLM 的理解和生成能力，確實(shí)能夠高效地解決很多之前有難度的長(zhǎng)尾問題。
Code migration 中 LLM 發(fā)揮的作用與 Fix code issues 的作用接近。區(qū)別在于 fix code issues 是一個(gè)特別高頻、瑣碎的需求，而 code migration 是一個(gè)相對(duì)低頻但 heavylifting 的工作，前者的實(shí)現(xiàn)可能性和容錯(cuò)率更高一些。
2.2 個(gè)人助理
對(duì)于很多硅谷的優(yōu)秀投資人/創(chuàng)始人而言，executive assistant 的同事非常重要，優(yōu)秀的行政同事能夠做到最合理的日程管理和對(duì)外溝通。但這件事情本身并不是 ChatGPT 這類產(chǎn)品能夠?qū)崿F(xiàn)的，因?yàn)?strong>助理任務(wù)往往需要很多隱式上下文（latent context）。優(yōu)秀的助理安排線上 zoom meeting 和線下飯局時(shí)需要考慮的因素很多：見面對(duì)方的重要性、當(dāng)天的其他日程、交通天氣、地理位置和偏好等等。這些任務(wù)的實(shí)現(xiàn)很需要 agent 的記憶和工具模塊來獲得一些背后隱藏的信息。
Case Study: Lindy.ai
Lindy.ai 是一款基于辦公場(chǎng)景的智能個(gè)人AI助手產(chǎn)品，幫助用戶智能化處理日常辦公任務(wù)。Lindy 由來自 Uber 的產(chǎn)品 head Flow Crivellow成立，該團(tuán)隊(duì)在 LLM 浪潮來臨前的創(chuàng)業(yè)方向是線上協(xié)同辦公。也正是基于他們對(duì)辦公場(chǎng)景比較深的理解，他們對(duì)自己產(chǎn)品的定位是 personal AI executive assistant。
其主要產(chǎn)品功能包括：
智能日程規(guī)劃及預(yù)定
郵件起草及發(fā)送
每日日程總結(jié)
會(huì)議紀(jì)要撰寫及總結(jié)
主要應(yīng)用場(chǎng)景：
銷售：根據(jù)會(huì)議更新CRM
招聘：自動(dòng)搜索候選人并發(fā)送郵件
日程規(guī)劃：自動(dòng)發(fā)送日程郵件和更新日歷
市場(chǎng)營(yíng)銷：起草營(yíng)銷方案
類似產(chǎn)品：MultiOn
2.3 寫作 Agent
從 GPT-3 開始，個(gè)人寫作助手類產(chǎn)品就是最快能夠?yàn)橛脩籼峁﹥r(jià)值、產(chǎn)生收入的。撰寫工作郵件、銷售文案等場(chǎng)景加入了 LLM 的文本理解、生成能力都有著比較明顯的效果優(yōu)化，因此我們會(huì)看到去年的 Jasper、今年的 Writer.ai 都在用戶反饋和商業(yè)化收入上做到了不錯(cuò)的效果。
但這一領(lǐng)域常被詬病的問題是沒有 moat，其產(chǎn)品核心的創(chuàng)作能力來自 LLM 的技術(shù)壁壘。而 Agent 的出現(xiàn)給 writing agent 了一個(gè)新的技術(shù)路徑： 讓我們的寫作助理可以自由的與網(wǎng)絡(luò)交互， 通過瀏覽能力和調(diào)用工具能力的增強(qiáng)來提升寫作體驗(yàn)，并且能將產(chǎn)品的功能延伸至其他領(lǐng)域，比如在線預(yù)定行程、在線購(gòu)買物品等同樣需要 agent action 的用戶行為。
Case Study: Hyperwriter
Hyperwriter 是由來自紐約的 AI 公司 Otherside AI 開發(fā)的產(chǎn)品，很大部分 AI for writing 公司一樣，他們的產(chǎn)品以輔助寫作的 Chrome 插件為最早的形態(tài)。
隨著 Agent 類產(chǎn)品的發(fā)布，他們很快在自己的插件中開始結(jié)合 agent 的能力。團(tuán)隊(duì)在 8 月發(fā)布了第一個(gè) agent 方向微調(diào)的大模型 Agent-1，可以做到在 Google Chrome 中通過閱讀前端代碼，理解網(wǎng)頁布局，并找到正確的地方填寫參數(shù)。在他們對(duì)外的 demo 中，該 agent 在 UI 設(shè)計(jì)非常難用的 GCP 界面能夠成功在正確的文本框填寫內(nèi)容、完成操作。
我們?cè)陬A(yù)約去美國(guó)機(jī)票的時(shí)候也使用了這個(gè) agent 插件，總體感覺優(yōu)點(diǎn)和缺點(diǎn)比較鮮明。優(yōu)點(diǎn)是：
功能比較強(qiáng)大，能理解指令自動(dòng)訪問網(wǎng)頁，找到對(duì)應(yīng)的參數(shù)位置然后填寫
能清晰實(shí)時(shí)地看到他的每一步規(guī)劃和操作
但其缺點(diǎn)也對(duì)于現(xiàn)在的 agent 應(yīng)用有普世性：
每一步操作中，模型思考碎碎念的步驟很多，效率較低
因?yàn)榇竽Ｐ偷?latency 不夠低，有明顯的卡頓感
容易進(jìn)入死循環(huán)，缺少自己糾錯(cuò)和反問的能力：寫指令時(shí)沒有寫單程還是來回，agent 的操作就卡住了需要人工介入
總的來說，寫作和瀏覽場(chǎng)景都是適合 agent 發(fā)揮的領(lǐng)域。但確實(shí)對(duì)于這個(gè)方向的創(chuàng)業(yè)公司來說，需要意識(shí)到這是 OpenAI、Anthropic 等大模型公司一定也會(huì)涉足探索的方向，需要盡快積累用戶數(shù)據(jù)獲得獨(dú)特的優(yōu)勢(shì)。
2.4 數(shù)據(jù)分析 Agent
數(shù)據(jù)分析的大部分工作是可以離線完成的，例如數(shù)據(jù)可視化、探索性實(shí)驗(yàn)等。因此相比編程開發(fā)而言，數(shù)據(jù)分析對(duì) latency、穩(wěn)定性的要求更低，對(duì)其分析能力、數(shù)據(jù)安全性的要求更高。同時(shí) LLM 的確對(duì)結(jié)構(gòu)化數(shù)據(jù)有了更好的理解和加工能力，讓很多原本重復(fù)、機(jī)械的 BI 任務(wù)能夠自動(dòng)完成。
因此 OpenAI code interpreter 上線之后，用戶主要的 use case 都集中在做數(shù)據(jù)分析上。Code Interpreter 在這一領(lǐng)域的局限也相當(dāng)明顯：無法處理超過 1000 行的數(shù)據(jù)表，沒有辦法規(guī)�；靥幚韲�(yán)肅任務(wù)。而且這個(gè)方向也不是 OpenAI 的主要重心，這就為創(chuàng)業(yè)公司留下了機(jī)會(huì)。
目前在 Analytics + LLM 方向的公司很多，其中大部分都有使用 Agent 思路。最為代表性的是三家基于 Notebook 形式的產(chǎn)品：Julius AI 是一個(gè) AI-native 新產(chǎn)品中的代表，而 Hex 和 Deepnote 這兩家相對(duì)成熟一些的公司也在自己的 Notebook 產(chǎn)品中集成了 Analytics Agent。
Case Study: Julius AI
Julius AI founding team 的核心成員 Matt Brockman 來自上文 Hyperwrite（其公司為 Otherside AI）的團(tuán)隊(duì)。獨(dú)立創(chuàng)業(yè)后他們的產(chǎn)品得到了 YC 和 AI Grant 的支持。
他們的產(chǎn)品是基于外部 LLM api 的能力進(jìn)一步優(yōu)化數(shù)據(jù)能力開發(fā)的 agent 應(yīng)用。實(shí)際使用中，開展一個(gè)分析前需要設(shè)置這次分析的主題和對(duì)話風(fēng)格。這一步使用了其 Agent 的職責(zé)扮演能力：
設(shè)置完成后，需要讀取此次分析所用的數(shù)據(jù)。添加時(shí)可以像使用 excel 一樣看到數(shù)據(jù)預(yù)覽，并且對(duì)其中內(nèi)容直接進(jìn)行變換。例如下圖中使用自然語言進(jìn)行的數(shù)據(jù)清洗和標(biāo)注：
在執(zhí)行數(shù)據(jù)分析時(shí)，Julius 也能夠執(zhí)行多步的數(shù)據(jù)加工處理：數(shù)據(jù)聚合、可視化，再到最后的建模分析和模型評(píng)估。每一步 agent 會(huì)盡量把自己的操作過程用文字表達(dá)出來，同時(shí)也可以查看其執(zhí)行時(shí)的代碼以 review 準(zhǔn)確性：
Julius 目前的使用體驗(yàn)確實(shí)明顯優(yōu)于 Code Interpreter，能更好更快地處理數(shù)據(jù)、且能比較準(zhǔn)確地理解用戶意圖。同時(shí)也能感覺到目前的 analytics agent 還在一個(gè)處理 toy case 的階段，并不能用于處理復(fù)雜的任務(wù)。
在現(xiàn)實(shí)的數(shù)據(jù)分析場(chǎng)景中，往往需要對(duì)數(shù)據(jù)和業(yè)務(wù)場(chǎng)景進(jìn)行更多維度的理解和探索，規(guī)劃自己的分析思路。但目前 Julius、Hex、Deepnote 這些產(chǎn)品都不能在接觸到數(shù)據(jù)集，之后主動(dòng)根據(jù)需求去規(guī)劃和拆解一些分析任務(wù)。這個(gè)需要更多的業(yè)界合作和數(shù)據(jù)積累才能夠有效地實(shí)現(xiàn)，成為數(shù)據(jù)科學(xué)家的工作伙伴和分身。
03.
AI Agent 的
未來展望
1. AI Agent 需要更模塊化的框架，11 月 OpenAI devday 有機(jī)會(huì)定義標(biāo)準(zhǔn)
現(xiàn)在在 AI 應(yīng)用領(lǐng)域，繞不開的話題是 OpenAI 會(huì)做什么、不會(huì)做什么。對(duì)于 AI Agent 領(lǐng)域也是如此，Andrej Karpathy 多次表示了對(duì) Agent 前景的看好，OpenAI 很可能會(huì)在 11 月的 devday 發(fā)布定義 AI Agent 的 api 和開發(fā)框架。我們對(duì) OpenAI 的發(fā)布有以下預(yù)測(cè)：
OpenAI 發(fā)的 Agent 框架可能與他們?cè)?16 年發(fā)布的 OpenAI Gym 接近。當(dāng)時(shí) Greg 等人寫的框架為之后的 RL 研究使用的環(huán)境定義了統(tǒng)一的標(biāo)準(zhǔn)：obs, reward, done, info = env.step(action) 這樣的形式很出色地將 RL 中的學(xué)術(shù)概念模塊化，這次他們也很可能會(huì)對(duì) AI Agent 做類似的框架定義，例如 Memory, Action, Agent class 等。
Agent api/framework 會(huì)和 fine-tune api 兩者結(jié)合會(huì)成為比較完備的 to B 服務(wù)體系。企業(yè)可以通過定義 agent 更好地使用 LLM 并收集領(lǐng)域數(shù)據(jù)和行為序列，為 fine-tune 提供更完整的數(shù)據(jù)反饋；同時(shí) fine-tune 又可以支持在某個(gè)領(lǐng)域有更專業(yè)、可靠的 agent，兩者一起能使 LLM 在企業(yè)端更容易落地。這對(duì) Anthropic 這樣的競(jìng)爭(zhēng)者在后續(xù)的 api 發(fā)布會(huì)帶來挑戰(zhàn)。
2. AI agent 概念在強(qiáng)化學(xué)習(xí)領(lǐng)域早已出現(xiàn)，LLM-based agent 在探索試錯(cuò)的能力上要向 RL-based agent 學(xué)習(xí)
上文中 OpenAI Gym 的圖片中也出現(xiàn)了 Agent 這個(gè)詞，其實(shí) AI 領(lǐng)域 agent 的概念并非第一次出現(xiàn)，強(qiáng)化學(xué)習(xí)中的智能體也是非常符合 AI agent 的定義，但是技術(shù)路徑完全不同。RL-based agent 是通過大量與環(huán)境的交互試錯(cuò)，評(píng)估不同行動(dòng)的結(jié)果，根據(jù)獎(jiǎng)勵(lì)或懲罰來更新其策略，最終學(xué)會(huì)如何執(zhí)行任務(wù)。
但強(qiáng)化學(xué)習(xí)一直距離大規(guī)模落地存在著距離，因?yàn)槠渎毮茉谝恍〔糠謭?chǎng)景之下使用，泛化能力較弱。這一小部分場(chǎng)景的特點(diǎn)是：其環(huán)境下的策略有限、能用數(shù)學(xué)完美地模擬復(fù)現(xiàn)。例如圍棋、Flappy Bird 這類非開放、有明確輸贏目標(biāo)的游戲，RL 能夠做到比最優(yōu)秀的人類更出色。但是當(dāng) agent 被放在一個(gè)隨時(shí)可能變化的場(chǎng)景中，如通用機(jī)器人、自動(dòng)駕駛想達(dá)到的目標(biāo)，一旦當(dāng)環(huán)境出現(xiàn)變化時(shí) RL-based agent 的泛化能力就會(huì)遇到瓶頸。
泛化能力正是 LLM 的強(qiáng)項(xiàng)，也是這次 LLM-based agent 大火的重要原因。且大模型壓縮了大量世界的語義信息，讓模型有能力在接觸環(huán)境時(shí)真正理解環(huán)境中每一個(gè)物品是什么、發(fā)揮什么作用，進(jìn)而根據(jù)用戶需求并進(jìn)行規(guī)劃和執(zhí)行。這解決了很多之前 RL 無法定義的長(zhǎng)尾問題。
但技術(shù)上的 tradeoff 也帶來了很多落地困難的問題，其中與強(qiáng)化學(xué)習(xí)對(duì)比最欠缺的是：當(dāng)前的 LLM agent 還沒有高效從錯(cuò)誤中學(xué)習(xí)的能力。由于 LLM 本身訓(xùn)練成本高，不可能根據(jù)每個(gè)任務(wù)和犯錯(cuò)經(jīng)驗(yàn)去調(diào)整參數(shù)，目前還沒有特別好的從錯(cuò)誤中吸取經(jīng)驗(yàn)的 practice。trial-and-error 模式的可行性是對(duì) AI agent 的挑戰(zhàn)。目前強(qiáng)化學(xué)習(xí)還只在 LLM 的 RLHF 階段出現(xiàn)，在 agent 領(lǐng)域引入 RL 的思想可能能幫助 AI Agent 有進(jìn)一步的突破。
3. AI agent 應(yīng)用的真正成熟還需要等待 LLM 的優(yōu)化：復(fù)雜推理能力不夠強(qiáng)、延遲過高
讓我們回到 agent 這個(gè)詞的本意：代理人，也就是具備主動(dòng)決策能力、代為行使權(quán)力的智能體。這兩個(gè)修飾詞之間是有因果關(guān)系的，這對(duì) AI agent 的實(shí)際落地有啟發(fā)：只有證明了 AI 的決策可靠，用戶才愿意交給 Agent 代為行使權(quán)力。
目前 AI Agent 實(shí)際落地的問題中有兩個(gè)瓶頸是來自于 LLM 作為推理引擎不夠強(qiáng)大：
現(xiàn)有的LLM雖然在某些領(lǐng)域的任務(wù)上表現(xiàn)不錯(cuò)，但對(duì)于需要多步復(fù)雜推理的任務(wù)，表現(xiàn)還是很弱。這主要是因?yàn)長(zhǎng)LM的訓(xùn)練目標(biāo)是next token prediction，而不是進(jìn)行復(fù)雜的推理。所以在需要鏈狀推理的任務(wù)上，LLM的表現(xiàn)仍有很大提升空間。這個(gè)提升空間來自于模型架構(gòu)和數(shù)據(jù)上的優(yōu)化�？梢杂酶鼜�(fù)雜的訓(xùn)練任務(wù)使LLM學(xué)習(xí)復(fù)雜推理，如問答、閱讀理解、分步規(guī)劃等。
同時(shí)，LLM 響應(yīng)輸入和執(zhí)行任務(wù)的速度還很慢。目前尚在技術(shù)早期，大家對(duì) LLM 的延遲寬容度還比較高。但未來對(duì)于許多應(yīng)用來說，低延遲是至關(guān)重要的，其速度直接影響了知識(shí)工作者的工作效率。例如最極端的，在自動(dòng)駕駛汽車或高頻交易系統(tǒng)中，延遲的減小可能會(huì)直接影響到系統(tǒng)的性能和安全性。 因此需要通過知識(shí)蒸餾、模型壓縮等方法縮小模型大小，降低計(jì)算量，并且等待大模型推理硬件和算法側(cè)的持續(xù)優(yōu)化。
其中，延遲優(yōu)化是工程問題，需要業(yè)界的時(shí)間來漸進(jìn)式優(yōu)化；更難的瓶頸還在復(fù)雜推理能力上，這是個(gè)需要被解決的科學(xué)問題，將隨著科研的進(jìn)展和 agent 行為序列數(shù)據(jù)的累積逐漸明朗。
4. Multi-agent 協(xié)作會(huì)產(chǎn)生比 Chatbot 大一個(gè)數(shù)量級(jí)的文本量，帶來成本控制和激勵(lì)機(jī)制的挑戰(zhàn)
在 AI agent 框架中，其中的 AI 之間會(huì)有大量的文本/代碼溝通與協(xié)作，因此 AI agent 產(chǎn)生的 token 數(shù)會(huì)有數(shù)量級(jí)的上升，需要模型側(cè)進(jìn)行持續(xù)的成本優(yōu)化。AI 小鎮(zhèn)框架開源之后，根據(jù)開發(fā)者的測(cè)試一個(gè) agent 一天需要消耗 20 美金價(jià)格的 token 數(shù)，因?yàn)槠湫枰洃浐托袆?dòng)的思考量非常大。這一價(jià)格是比很多人類工作者更高的，需要后續(xù) agent 框架和 LLM 推理側(cè)的雙重優(yōu)化。
與成本對(duì)應(yīng)的是合作機(jī)制中的多 agent 場(chǎng)景下需要更明確的目標(biāo)和激勵(lì)機(jī)制，類比強(qiáng)化學(xué)習(xí)中的 reward function。這一個(gè)方向是目前還沒有好的實(shí)踐，可能是 web 3 token 機(jī)制適合引入的方向。數(shù)字貨幣與代碼，可能是未來 Agent 生產(chǎn)和協(xié)作過程中相當(dāng)重要的生產(chǎn)要素。由于篇幅限制，這一點(diǎn)就暫不詳細(xì)展開了。
總的來說，我們對(duì) AI Agent 需要保持耐心。一方面，OpenAI 等大模型公司會(huì)在 Agent 標(biāo)準(zhǔn)定義和模型推理能力上持續(xù)進(jìn)化：11 月 OpenAI Devday 可能會(huì)踏出定義標(biāo)準(zhǔn)的第一步，連續(xù)的復(fù)雜推理問題對(duì)于當(dāng)前 next token prediction 的模型存在根本性的瓶頸，需要用更復(fù)雜、結(jié)構(gòu)化的數(shù)據(jù)和目標(biāo)函數(shù)來進(jìn)一步學(xué)習(xí)。另一方面，Agent 的應(yīng)用落地還需要 Generative UI 帶來的人機(jī)交互方式的革新，就像曾經(jīng)施樂實(shí)驗(yàn)室對(duì)個(gè)人 PC GUI 的定義。這也需要業(yè)界持續(xù)探索和創(chuàng)新才能逼近正確答案。
Reference
1. Theodore Sumers, Shunyu Yao, Karthik Narasimhan, Thomas L. Griffiths. Cognitive Architectures for Language Agents: https://arxiv.org/pdf/2309.02427.pdf
2. https://e2b.dev/blog/the-state-of-ai-agents-reliability-sdks-benchmarking-and-market-trends
