對話百度孫珂：想玩好AI Agent，大模型的“外掛”生意怎麼做？_風聞

原創：親愛的數據

（一）

若説大模型應用開發是淘金，

加速應用開發的框架，工具，平台則是“生產淘金鏟子”。

有人淘金，總有人生產鏟子。

機會一定會被頭部廠商捕捉。

而開源產品總是先出發。

LangChain是一個開源的大模型應用框架。

2023年3月，LangChain與亞馬遜雲、谷歌和微軟雲等系統集成。

當然，大模型應用開發的難易程度，取決於開發者的水平。

有開發者感慨：“LangChain真香”。

也有小白開發者吐槽：“與LangChain纏鬥了幾個小時，只是為了用它的兩個功能。”

LangChain可提升大型語言模型的應用程序開發效率，

提供了用於構建應用的工具和模塊。

舉個例子，假如一個手機APP叫“綠了麼”。

用大模型加持“綠了麼”APP的時候，

LangChain會參與一個這樣的Pipeline（執行任務的過程）：

首先，“綠了麼”APP把問題發送給大模型。

其次，大模型理解並回答問題。

第三，大模型的答案發送回“綠了麼”APP。

在這個Pipeline上，除了大模型的工作，剩下的工作LangChain可以接手。

LangChain是一種軟件框架，便於開發各種大模型原生應用。

調戲過大模型的人都知道，開箱即用的玩法就是在那個窗口裏輸入提問。

只能一問一答這麼個玩，就太侷限了。

很快，人們開始思考，不如把大模型變成一個超級組件，和別的東西“拼”在一起玩。

但有時候會有點小麻煩。

若在大企業部署就更麻煩，牽扯到很多API，以及其他麻煩事（身份驗證，流量控制，鑑別權限）。

這時候就需要大模型外掛。

我再換個例子來聊：

一個被大模型加持的AI Agent由三部分構成。

第一，信號採集，

第二，處理端，

第三，執行端。

先説大模型在哪。

大模型在第二個部分處理端裏面。

這時候大模型是Agent的一部分，而工程化的連接工作存在於第一部分和第三部分，這些工作可以自動化，並且交給大模型外掛。

或者説，把信號採集和執行端合起來的需求都交給大模型外掛。

除了大模型幹好自己的工作，剩下的大模型外掛接手。

外掛接收外界請求，大語言模型來生成答案，外掛將答案轉換為響應，並將響應返回給 API。API它是軟件系統之間相互交互的一種手段。API 定義了軟件系統如何相互調用，並提供一個標準的接口，外掛自動生成大語言模型服務的API。

這個AI Agent工作的例子不復雜，外掛當然充當省事神器。

結論來了，大模型要實現豐富的功能就要調用“外掛”。

外掛是一個挺大的概念，種類多，使用方法頗多。

外掛可以是自動調用API的工具，

也可以是RAG框架只做了一個問答功能。

​AI Agent自己可以是外掛，AI Agent也可以調用另一個AI Agent做外掛。

多AI Agent的情況下，一個AI Agent是其他AI Agent外掛。

譚老師我趕緊説，禁止俄羅斯套娃梗。

如此看來，大模型“外掛”的生意體量，也會非常可觀。

（二）

那麼，早期AI Agent和大模型加持下的AI Agent有何不同？

早古時期強化學習裏的Agent有很多例子：

在機器人遊戲中，Agent是機器人本身。

Agent 的目標：贏得遊戲。

Agent 的狀態：遊戲的當前狀態。

Agent 的動作：遊戲的下一步操作。

動作可以是向左、向右移動，或者跳躍。

首先，Agent感知環境的狀態，比如機器人的當前位置。

其次，根據感知到的狀態，Agent（機器人）使用策略函數來選擇動作。

策略函數是一個從狀態到動作的映射，

它可以是確定性的，也可以是概率性的。

再次，Agent 執行選擇的動作，改變環境的狀態。

最後，Agent 從環境中獲得獎勵。

遊戲機器人，戰死零分，戰勝得分。

早期AI Agent 只能感知有限的環境信息，只能有限自動化地完成部分規定好的響應，適應能力並沒有打開。

此時此景，譚老師我總結一句，彼時AI Agent，格局沒有打開。

大模型加持下的Agent，能針對開放環境做自主的行為規劃。

並且在自己所能夠操作的，能控制的範疇內，儘可能使用它能使用的工具，以及對這個開放環境的信息進行響應。

完成這一過程，需要用到Agent的四個基本能力：理解、生成、邏輯、記憶。

它們分別代表了 AI Agent 對外部世界的感知、對信息的處理、對決策的制定和對經驗的積累。

假設有一個 AI Agent 正在幫助用户查找明星全部緋聞，並總結成故事線。

AI Agent 首先需要理解用户的需求，這需要具備理解能力。

然後，AI Agent 需要搜索互聯網，理解發生了什麼。

再生成貼合事實的，有前因後果的故事線，這需要具備生成，邏輯和記憶能力（歷史新聞）。

在整個過程中，四個能力都發揮了重要作用。

由此看來，打開格局的前提，還是大模型能力強。

當然，也少不了大模型外掛的幫助。

（三）

大模型的外掛範圍既然這麼大，五花八門的軟件框架，

從中找到共性，並形成一個平台，那事情會不會變得更方便。

我前面提到，這個提升開發效率，加速開發大模型原生應用的機會，

一定會被頭部廠商捕捉。

我看到百度就是這麼做的，2023年12月20號百度智能雲千帆AppBuilder正式開放。

此前更早，2023年10月17日的百度世界大會上，

一個“三分鐘開發三一重工官網客服”演示，也“揭示”了這個方向上的進展。

並且，我認為，百度AppBuilder不僅設計了“大模型外掛平台”這個產品，而且設計了生態。

第一，產品生態。

李彥宏説，只有擁有數以百萬計的AI應用，大模型才可以算得上成功。

百度劍指百萬量級的應用生態，底座上必有要有好工具支持應用的開發。

百度推出這類產品，也符合了李彥宏常説的那句“卷 AI 原生應用才有價值”。

第二，技術生態。

百度鋒芒所向百萬量級的開發者，開放者粘性能帶動百度大模型使用量。

第三，產業生態。

發展產業生態，需要降開發門檻，促協作創新，加速落地，這些大模型外掛都能助益。

除以上三點，再加一點，帶動B端企業級客户的訂單。

目前看來，很多B端企業心熱大模型技術，苦於不知道怎麼用。

目前百度AppBuilder現有三種（支持知識增強的應用框架RAG、具備思維鏈及工具使用能力的Agent框架、生成式數據分析框架GBI）都是客户需求旺盛的反映。

客户可以快速上手AppBuilder，此後無論照貓畫虎，亦或是激發靈感，有助於

找到大模型的更多用法，成為很好的銷售切入點。

帶着這些思考，2023年年末的最後幾天裏，我在百度大廈見到了百度智能雲技術委員會主席孫珂博士。和上次見到他的時候一樣，他依然身着深色帽衫。我很想把話題聊透，他也非常坦誠。

部分對話已省略，我摘要了核心部分。

譚婧：AI Agent有哪些激動人心的發展方向？

孫珂：如果未來真的技術發展到多AI Agent這個狀態，有可能一個AI Agent永遠可以被另外一個AI Agent拎起來，作為一個插件來使用。在這個狀態下，你可以認為我的這些東西都有可能會被某一個更大的AI Agent拎起來，作為它的一個插件去使用。這個就是我們預見的AI Agent接下來要去發展的一些方向，當然大家正在探索和開發。

譚婧：隨着大模型能力提升，Agent架構會被淘汰嗎？

孫珂：肯定有些策略就沒有用了。但是，作為開發大語言模型原生應用的重要工具，Agent架構可以緊跟趨勢，調整策略，目標是讓人更容易地使用。

譚婧：有一天，Agent架構會消失嗎？

孫珂：有一天，大模型膨脹到它填滿了整個AI Agent，但是，它最終外面還是一個AI Agent，它還是表現出這些行為（信號採集，處理，執行）。

更進一步，大模型是AI Agent的一部分，只要大模型跟現實世界連接，做各種執行動作（action）。最終都需要行為和能力對接，所以，這個工程框架應該會長時間存在。

我想了解，AppBuilder在百度現有AI體系裏面處於什麼位置，又如何發揮作用

譚婧：換個角度來思考，在大模型應用和大模型之間再加一層的辦法可行嗎？

孫珂：千帆大模型平台在百度雲的PaaS層。本質上，你可以認為是在千帆大模型平台之上，長出來的一個A（application) PaaS，應用PaaS，我們內部代號就叫APaaS。

AppBuilder跟千帆大模型平台耦合。耦合點在於計費邏輯，底層計算資源和大模型的調用。當然包括我們以前推出一系列能力引擎PaaS的接口，所以，你可以認為之前的AI PaaS層，是更偏底層的PaaS。

譚婧：和以前MLOPs的關係是什麼？

孫珂：如果你對以前MLOPs那層比較熟悉的話，我認為是在此基礎上又蓋了一層 ，也可以説，在大模型應用和大模型之間再加一層。

譚婧：上一代公有云上的A-PaaS代表產品是什麼？

孫珂：以前，因模型效果所限，側重於模型訓練和部署的PaaS，這種形態的組件，並不容易被真正軟件工程的這種系統所集成。

**譚婧：新舊相比，**我們如何一句話總結這種變化？

孫珂：把大模型的常用能力封裝成了API。

譚婧：能不能講一下AppBuilder的問世時間線？

孫珂：更早之前，我們團隊已經對RAG等各類框架非常熟悉了，後來發現這個框架存在通用化的可能性。

所以，決定先把這個東西實現出來，實現出來以後發現真的是一個很通用的框架，我們就一直這麼做下去，直到AppBuilder現在這個形態。

（完）

《我看見了風暴：人工智能基建革命》，作者：譚婧