編譯｜冬梅

近期，在 LangChain 舉辦的智能體大會 Interrupt 上，吳恩達與 LangChain 創始人 Harrison Chase 進行了一場關于 AI Agent 的對談。整場交流的核心并不是簡單討論 Agent 有多強，而是圍繞一個更現實的問題展開：當 AI Agent 讓軟件開發變快之后，真正的瓶頸會轉移到哪里？

吳恩達首先提到，過去一年 AI 領域的熱度和炒作超出了他的預期。相比之下，更值得關注的是編程智能體的快速進步。他說，六個月前自己幾乎主要使用 Claude Code，現在則開始混合使用 OpenAI Codex、Gemini CLI、OpenCode 等工具。編程智能體的能力邊界變化很快，甚至連在手機上寫代碼這樣的工作流，也開始變得自然。

但編程智能體帶來的最大變化，不只是寫代碼更快，而是軟件生產鏈條被重新分配。吳恩達提出了“產品管理瓶頸”的概念：當代碼實現速度提升 10 倍甚至 100 倍之后，限制團隊效率的就不再只是工程實現，而是“到底該做什么”。需求定義、用戶反饋、優先級判斷、產品邊界，都會變得更重要。

與此同時，營銷、法務、設計、合規也可能變成新瓶頸。過去一個產品開發三個月，等法務一周簽字可以接受；但如果現在一天就能做出產品，再等一周，法務本身就成了阻礙。

因此，未來的軟件團隊會更小、更快，也更依賴通才型人才。

吳恩達提到，他越來越多地組建一到十人的小團隊，成員往往是高上下文、高授權、技術能力強的工程師。他們不只寫代碼，還會借助 AI 完成產品定義、營銷文案、服務條款初稿等工作。AI 不會讓工程師瞬間變成優秀營銷人員或律師，但可以讓他們先產出一個可用初稿，再交給專業人員把關。

在 Agent 開發方式上，吳恩達用了“樂高積木”的比喻。

今天的開發者面對的不只是模型，還有 RAG、Agent 框架、評估工具、Guardrails、UI 組件、身份認證、數據庫等大量構建模塊。開發者越了解這些模塊，越能快速組合出可用系統。但問題是，API、SDK 和工具變化太快，模型未必知道最新用法。因此，Agent 的能力不只取決于模型本身，也取決于它能否獲得及時、準確、可執行的上下文。

談到企業落地，吳恩達認為，很多企業正在做自下而上的 AI 創新，但這種“百花齊放”往往只能帶來點狀提效，難以形成真正轉型。比如銀行用 AI 自動化貸款審批，如果只是把一小時人工審核變成 AI 審核，價值有限；更大的機會是重構整個流程，推出“10 分鐘獲批”的貸款產品。這需要營銷、數據、審批、盡調、執行等環節一起變化。

他也提醒企業，不要只把 AI 當作降本工具。成本節省有上限，增長才更有想象空間。客服、呼叫中心、drive-through 點餐等場景中，AI 的價值不只是減少人工，而是更快服務更多客戶，改善體驗，進而帶動業務增長。

在技術選型上，吳恩達特別強調要警惕供應商鎖定。AI 模型和 Agent 工具變化太快，沒人能確定一年后最強的模型是誰。因此，企業應盡量保留選擇權，不要輕易因為折扣簽下過長合約。LangSmith 這類供應商中立的觀測和管理工具，以及開放權重模型，都有助于企業在快速變化中保持靈活性。

最后，他把企業 Agent 的關鍵基礎落到數據架構上。過去企業主要圍繞結構化數據做治理，但 Agent 真正要發揮作用，必須能處理文本、PDF、圖片、音頻、視頻等非結構化數據。現實是，很多企業數據分散、權限體系為人而非 Agent 設計、治理和可觀測性不足。吳恩達判斷，未來幾年，企業會啟動大規模數據架構重構，讓數據真正變得 AI-ready、agent-ready。

這場對話的重點是：AI Agent 不只是讓代碼寫得更快，它正在倒逼企業重新思考產品、組織、數據、流程和技術選型。真正能從 Agent 中受益的企業，不是簡單自動化某個環節，而是有能力圍繞 Agent 重構整個業務系統。

以下為完整版對話，經 AI 前線編譯：

編程智能體的崛起

Harrison Chase：距離我們上次對話已經過去一年了，這一年 AI 領域發生了很多事情。哪些事情的發展速度超出了你的預期？哪些事情又比你想象得更慢？

吳恩達：我覺得，首先是一些熱度和炒作程度超出了我的預期。另外，一些末日敘事也獲得了比我預想中更多的關注，這有點遺憾。比如所謂的“工作崗位末日”，我并不認為那會真的發生。更積極的一面是，編程智能體的發展速度可能比我預想得更快。

現在的前沿編程智能體發展非常快。雖然外界總說 AI 每三個月就徹底改變一次，這種說法并不完全準確，但在編程智能體上，它確實有點像真的。我們能用編程智能體完成的事情，其前沿能力變化非常快，而且競爭非常激烈。

大概六個月前，我幾乎全都在用 Claude Code。現在我仍然大量使用 Claude Code，但也越來越多地使用 OpenAI Codex，同時也會混合使用 Gemini CLI。我也支持 OpenCode，因為它是開放的代碼。

所以我們使用的編程智能體組合變化得非常快。

一年前我也不會想到，自己會在手機上寫這么多代碼。很多工作流都在快速改變。比如像在座很多人一樣，我辦公室里也有一臺 Mac Mini，這些開發工作流變化得非常快。

另外，智能體式工作流也正在真正進入企業。這一點也讓人感覺不錯。

Harrison Chase：順著軟件工程這個話題，在你看來，軟件工程的未來會是什么樣？

吳恩達：大概一年前，我寫過“產品管理瓶頸”這個問題。它的意思是，如果構建軟件變得快得多，那么決定要構建什么，也就是產品管理工作，包括定義項目范圍、獲取客戶反饋、決定做什么，就會變成瓶頸。

過去一年，我感覺這個產品管理瓶頸以一種好的方式變得更嚴重了，因為軟件構建變得快多了。

但事實證明，當寫軟件變快 10 倍甚至 100 倍之后，不只是產品管理會成為瓶頸，幾乎所有其他事情都會變成瓶頸。

我有些團隊已經遇到了營銷瓶頸。因為我們能構建太多功能，營銷人員反而很難跟上，搞清楚一個新功能到底做了什么，然后再思考該如何對外傳播。

過去，如果一個產品需要法律合規，你花三個月構建它，再等一周讓法務簽字，可能還可以接受。但現在，如果你一天就能構建出來，然后還要等一周法務簽字，那就變成了法律合規瓶頸。設計也會成為瓶頸，其他環節也一樣。

所以我經常思考，未來的軟件工程團隊會如何組織。但我不認為自己已經知道答案。

不過，我越來越多地在組建非常小的團隊，可能是一到十個工程師。這些人通常是通才型、高上下文、高授權的工程師。團隊會被給到一組非常寬的護欄，然后他們就可以在這個范圍內瘋狂推進、構建并發布代碼，甚至推動一些傳統上不屬于工程范疇的決策，比如寫營銷文案。

假設你有一個團隊，它需要軟件工程、產品管理、一點服務條款、一些營銷文案、一些設計。也就是說，這個團隊需要五種職能，但只有兩個人。

那么按照定義，或者用“鴿巢原理”來說，這兩個人里的每一個人都必須承擔不止一個角色。

好消息是，我不覺得自己是一個很好的營銷人員。但當我使用 AI 時，我仍然不是一個好營銷人員，只是和沒有 AI 助手相比，稍微沒那么差。

所以我發現，這種小團隊很有效：成員是高上下文的通才，技術能力很強，同時能夠使用前沿技術，在其他角色上也承擔一部分工作。

比如，坦率地說，所有工程師都可以用 AI 起草一版服務條款，然后再交給律師，讓律師最終潤色后發布。我發現這些流程能讓團隊移動得快得多。這一點非常令人興奮。

Harrison Chase：這些人的理想背景是什么？他們本來就是工程師嗎？還是來自其他學科，然后第一次學習寫代碼？你觀察到的情況是什么？

吳恩達：我最密切合作的很多人，確實擁有很深的工程和技術背景。同時，他們也被充分授權，是略帶通才屬性的人。他們會進入其他角色，并在 AI 的支持下獲得混合技能，而這些技能可能原本并不是他們受過訓練的領域。

我認為人們可以從任何方向成功轉型。我見過產品經理在寫代碼方面變得強很多，然后參與到這類團隊中。

不過，因為 AI 編程本身和工程關系很深，工程師在理解前沿技術上可能天然有優勢。所以我最常看到工程師成功扮演這種角色。

但也確實有少數產品經理能做到。我也見過營銷人員以非常有效的方式學習寫代碼。還見過運營人員開始構建越來越多產品。

我認為任何背景的人都有可能學會做很多這類事情。但目前做得最好的最大群體，似乎仍然是工程背景出身的人。

不過，我們鼓勵來自任何背景的人都嘗試看看，自己是否能扮演這些角色。

如何進入 AI 軟件工程領域

Harrison Chase：對于那些想進入這種新軟件工程領域的人，你有什么建議？比如有哪些工具值得嘗試，應該具備什么心態，或者應該學習哪些技能？

吳恩達：我最近在用一種方式思考軟件工程的未來，這是我腦子里的一個心智模型。現在有很多工具提供商，提供各種構建模塊，比如 RAG、智能體框架、評估工具、護欄等。這些都是 AI 構建模塊。

同時，也有很多非 AI 構建模塊，比如用戶界面組件、身份認證機制、前端和后端、持久化數據庫等等。

所以我認為，在計算機科學里，我們一直都有一套非常棒的構建模塊。而隨著智能體式編程的發展，構建模塊正在快速增加，因為越來越多人在構建開源模塊、專有 API 模塊，或者其他類型的構建模塊。所以我們周圍有很多非常棒的構建模塊。

我發現，如果開發者能夠很好地掌握足夠多的構建模塊，他們通常就可以用組合的方式，把這些模塊快速拼裝起來，構建軟件。

你可以想象用樂高積木搭東西。如果我手里只有一塊白色樂高積木，我能搭一些東西，但不會太有意思。但如果我再加入黑色、黃色、棕色、綠色的積木，再加上一些形狀奇特的樂高零件，那么隨著我擁有的樂高積木種類變多，我能搭出的東西會以組合式方式增長，甚至呈指數增長。

我認為，我們現在能使用的很多構建模塊，也有類似效果。

我發現，那些開發者如果能很好地理解這些構建模塊能做什么，就會變得非常強。

DeepLearning.AI 也提供了很多短課程，幫助大家掌握來自不同機構和開發者的這些優秀構建模塊。另一個挑戰是，如何使用編程智能體，快速把這些構建模塊組裝成你想要的軟件。

現在編程智能體面臨的一個問題是，很多構建模塊太新了，以至于編程智能體并不知道該如何使用它們。

舉個例子，直到最近，很多領先編程智能體所基于的模型，知識截止時間都早于 nano-banana 發布的時間。所以它們并不知道 nano-banana 存在，也不知道如何調用 nano-banana API。

所以我和我的朋友 Rohit Prasad 一直很關注一個項目，叫 Context Hub。它有點像面向 AI 智能體的 Stack Overflow。

AI 智能體可以通過它獲取最新文檔，了解有哪些最新 API、SDK 和構建模塊可以使用；同時，智能體也可以向文檔提供反饋，幫助改進文檔，讓所有人受益。

實際上，有一些 API 是我自己經常使用的，但我總覺得它們的語法有點煩人，很難記住。但通過 Context Hub 加載最新文檔后，我可以讓編程智能體替我完成這些 API 調用。

所以它確實讓我的編碼工作加速了很多。

AI 正在如何改變教育

Harrison Chase：這里我補充兩點。我們也發布過一個叫 Context Hub 的東西，所以我們在名字上撞車了，但這是非常不同類型的 Context Hub。Andrew 這個 Context Hub 對使用編程智能體更有幫助，所以大家可以去試一下。順著這個話題，在這個新的 AI 世界里，你如何看待教育的變化？你是否已經把一些新的實踐融入 DeepLearning.AI 的課程運行方式，或者融入你對教育的思考？

吳恩達：我們正在嘗試很多方式來改善教育體驗。就培訓內容而言，已經很明確的是，人們需要學習的東西發生了顯著變化。對于開發者來說，他們需要學習編程智能體，學習這些構建模塊，也許還要學習一些產品管理，或者類似的通用技能，讓自己更有效。

所以，我們需要學習的內容正在變化。DeepLearning.AI 和 Coursera 也一直在嘗試提供這類培訓。

但除了“學什么”之外，還有“怎么交付培訓”的問題。我們思考“如何學習會被改變”已經很久了，但感覺真正的變化其實還沒有完全到來。

幾周前，我們上線了一個預覽版新網站，叫 CodeDream.ai。它背后的愿景是：不要只是上在線課程，而是來進行一場對話。

這不是一門課，而是一場對話。我們想構建的體驗是，你可以和我進行一場模擬視頻通話。

比如，如果你想往后一靠，聽我以一對一視頻通話的形式給你講 Context Hub 和編程智能體，你可以這么做，我會給你展示一些想法。

如果你想打斷“我”，也就是打斷我的 AI，然后問問題，你可以隨時這樣做。我個人也在大量嘗試的一件事，是用 JavaScript 替代視頻和幻燈片。這是什么意思？也就是說，當我在視頻里演示某個東西時，如果你能點擊進入這個視頻，然后在視頻窗口里輸入自己的 prompt 或查詢，那會怎么樣？

也就是說，視頻區域不是一個只能播放的靜態視頻，而是可交互的。這樣可以創造更多和學習內容互動的方式。

如果你感興趣，可以去試試 CodeDream.ai，和我或者我的 AI 進行某種對話。我會以 AI 形式向你展示如何使用 Context Hub 的編程智能體。

坦率地說，我們現在每天仍在迭代和改進這些體驗。

Harrison Chase：你剛才說可以點擊視頻并輸入內容，這個功能現在已經上線了嗎？還是一個未來方向？

吳恩達：已經上線了。你可以想象一下，它不是我在視頻里共享屏幕，而是我在視頻里“共享 JavaScript”。因為它運行的是 JavaScript 代碼，而不是預先錄好的視頻，所以你可以和我所謂的“屏幕共享”內容互動。

如果你有喜歡或不喜歡的地方，我們也非常歡迎反饋。不過，我確實覺得，教育轉型在過去被過度炒作了。我認為某些變化正在到來。

但今天來說，上在線課程仍然是主流。我希望我們能擁有比在線課程好得多的東西。當然，我們現在確實已經有比十年前更好的課程了。它們互動性更強。比如今天早上，我們剛發布了一門關于 Transformer 的新課程，由 AMD 的 Sharon Jo 講授。我發現，相比十年前主要就是視頻，現在我們構建了更多交互式可視化內容。現在的課程里有很多比十年前更有趣、可以動手玩的東西。

但那種更大的教育變革，我確實花了很多時間在思考。

企業 AI 采用：哪些有效，哪些還不夠

Harrison Chase：從軟件工程擴展到其他領域，你如何看待企業采用 AI？它比你預期更快還是更慢？正確的方式是什么？大家可以從中學到什么？

吳恩達：我認為每一家企業，我猜也包括你們所有人的企業，都對 AI 采用非常興奮。我們在很多企業身上看到了一些共同主題。我的一個團隊 AI Aspire，是一家 AI 咨詢公司，由我和商業伙伴 Chris Tann 共同創立。我們一直和大型企業交流，包括財富 50 強、財富 500 強、G2000 企業，討論它們的 AI 戰略和轉型。

有一些一致的主題。

幾乎所有企業都投資了自下而上的創新，也就是所謂“百花齊放”的策略。但總體來看，這種策略的回報并不明顯。所以 CEO 和董事會都在問：AI 的 ROI 在哪里？

我認為我們仍然應該繼續投資自下而上的創新，應該繼續做。但事實是，自下而上的創新通常會產生點狀解決方案，帶來漸進式效率提升。這其實是好事，但它不是 AI 曾經承諾給我們的那種更廣泛的轉型，而我認為我們應該努力交付這種轉型。

我用一個例子說明。我的團隊正在和多家銀行合作。

吳恩達：我們在金融服務領域做了很多工作。以貸款承銷流程為例，它可能有五個步驟：營銷貸款產品、接收申請、審核并批準貸款、做最終盡職調查，以及執行貸款。

很多團隊注意到，中間的貸款審批環節可以用 AI 來做。如果我們能自動化這個環節，那么原本需要人花一小時審查貸款申請，現在可以由 AI 來完成。這很好，我們當然應該做。

但問題是，如果你的整個貸款承銷流程保持不變，只是把原來一小時的人力工作自動化了，那這只是一個小的、漸進式效率提升。

所以有些銀行會說，既然如此，我們不如重新思考整個工作流，推出一個“10 分鐘內獲批”的貸款產品。

因為我們不再需要等一個人一周之后才有一小時空閑去審查申請，我們可以馬上把貸款申請發送給 AI，讓它立即做出決策。但在很多企業里，真正實施這種變化的挑戰在于，它需要一個擁有更大范圍權限的人，重新思考和重新設計整個工作流。

因為現在你要營銷一個“10 分鐘獲批”的產品。你需要把申請立即路由到審批環節，而不是一天后再處理。營銷、數據、基礎設施都需要參與進來。是的，AI 可以做初步決策。但最終盡調和執行環節可能也需要擴展能力。

所以我發現，自下而上的創新非常有價值，它會產生很多想法。但它必須和自上而下的動作結合起來，也就是需要有人擁有更廣的視野和權限，能改變所有這些步驟的運作方式，從而真正創造增長。很多企業都在談降本。

降本沒問題，值得做。但我更想推動大家想象一些 AI 能做的更有想象力的事情，也就是推動增長。

因為我們能節省的錢總是有限的，但增長幾乎沒有實際天花板。所以我發現，更令人興奮的想法通常和推動業務增長有關，而不只是節省成本。

Harrison Chase：你有沒有看到一些通過 AI 推動業務增長的好案例？有沒有哪些案例讓你特別興奮，或者你覺得其他人應該關注和學習？

吳恩達：有。剛才銀行的例子就是真實案例。我們正在和一些銀行、金融機構合作做這件事，其他企業也在做類似的事情。

另外一個模式是客戶服務和呼叫中心。客戶服務和呼叫中心通常被視為降本場景。降本當然不錯。但當你能自動化客戶服務，或者自動化、增強其中一部分時，你就能更快服務更多客戶，從而提供更令人愉悅的客戶體驗，并推動增長。

我也和一些企業交流過，它們正在自動化 drive-through 的語音應用，也就是汽車穿梭餐廳的點單流程。我認為這同樣能帶來更好的客戶體驗，并推動增長。

所以我看到經濟中不同地方正在出現越來越多這樣的例子。

還有一些我知道的案例，但我沒有權限公開講。不過，基于我看到的企業正在做的事情，我非常有信心，未來會出現越來越多這樣的案例。

如何衡量 ROI

Harrison Chase：你剛才提到了 ROI。根據我昨天和今天的很多交流，我知道很多人都在思考這個問題，也在思考如何衡量 ROI。在一些場景里，比如成本節省或者呼叫中心，也許比較容易衡量。但你會如何建議大家思考 ROI 衡量？有什么建議嗎？

吳恩達：我希望我知道答案。我發現，挑戰可能在于企業非常多樣化。所以衡量 ROI 就像衡量業務本身一樣，很難有一個放之四海而皆準的答案。不過有一點是，我最興奮的那些項目，通常是可以衡量的，也應該被衡量，值得被衡量。

有些事情，我們需要“全力揮棒”，去創造非常大的價值。

在這種情況下，我們討論的就不是“這會不會帶來 2% 的增長，再減掉 1% 的實施成本”。有些項目的價值非常明顯，會顯而易見地改變業務。

當然，我們仍然需要衡量它，尤其是如果你是一家上市公司。

但我學到一件事：有時候，推動漸進式收益反而比推動轉型式收益更難。如果你告訴某人，明年把業務結果提升 2%，他可能會覺得，好吧，老板就是讓我多努力 2% 或 5%。

但如果你要尋找能帶來 20% 或 50% 業務增長的方法，你不可能讓全公司每個人都多努力 50%。你必須提出更有創造力的解決方案。

這經常會帶來新的思路。

我在 AI Aspire 學到的一點是，很多企業真的會發給我們一張表，里面有幾百個想法。

比如有一家金融機構給我們發了一張超過 300 個想法的表格，讓我們幫他們判斷，在這些想法中哪些值得真正投入資本。

事實證明，這個分析非常困難。我希望自己足夠聰明，能一眼掃過去就說，這個想法好，那個想法好。但面對這么多想法時，通常需要進行自上而下和自下而上的頭腦風暴。

這需要大量技術分析，判斷哪些事情在技術上可行；也需要大量業務分析，判斷哪些事情可能帶來有意義的變化。

最后需要把這些想法縮小到少數幾個值得投入重要資源的賭注上。

Harrison Chase：這類“全力揮棒”的項目，你通常看到它們是自上而下推動的，對嗎？

吳恩達：沒錯。我認為企業最好不要只做一個瘋狂的大賭注，而是形成一個由少數幾個經過深思熟慮的賭注組成的組合。如果其中任何一個成功，都會對業務產生有意義的影響。

不過，智能體式編程讓我很喜歡的一點是，我們可以運行大量實驗，不斷做原型。原型開發的成本已經大幅下降。

但遺憾的是，你不可能做所有事情。比如在 10 萬美元預算下，你不可能什么都做。到某個階段，對少數幾個項目組合中的每一個投入有意義的資源，是合理的。

也正因為在這個級別上需要資源分配，所以往往需要更多自上而下的動作，來配置所需資源。

駐場工程師是炒作還是真實需求

Harrison Chase：最近關于企業采用 AI，有一個被頻繁討論的話題是 Forward Deployed Engineer，也就是前線部署工程師。未來每家公司都會有 FDE 嗎？你怎么看？為什么你認為他們這么有影響力？未來會如何發展？

吳恩達：在硅谷的流行語里，FDE 確實正處在一個高關注時刻。我知道 Aaron 前一兩天也在臺上非常深入地談過這個話題。我認為 FDE 是一個很好的想法。

很多企業都會需要這種角色。但展望未來，你覺得一家公司里 FDE 的數量，和公司雇傭的普通 AI 工程師數量之間，會是什么比例？

我認為，大多數企業會擁有更多內部工程師，同時可能嵌入一小支 FDE 團隊。所以我喜歡 FDE，也對這個角色的增長感到興奮。我們應該幫助更多人獲得 FDE 工作。

但我也認為，和很多事情一樣，圍繞它的 hype 可能比現實情況略高。不過它確實是一件好事。

構建智能體工作流是很難的。它需要理解業務，需要面向客戶的能力。為了讓系統可靠，通常還需要做好可觀測性、評估，與客戶合作，判斷某些需求在技術上其實不可行，并和利益相關方一起決定應該自動化哪個工作流，還要幫助企業完成變革管理。

所以這是一個非常有價值的角色，需要很深的技術判斷。讓 FDE 嵌入企業，確實可以大幅加速項目。

但我也看到很多企業面臨另一個挑戰：有沒有可能獲得一個供應商中立的 FDE？

這其實很難，取決于你想讓哪些供應商真正嵌入你的企業。因為我們在 AI 領域看到，領先模型變化非常快。

我不知道一年后領先的 AI 模型會是什么。我也完全不確定一年后領先的編程智能體會是什么。

所以在這種不確定時刻，選擇權非常有價值。

坦白說，很多供應商都會來找我們的企業，提供 20%、30% 的折扣，但條件是簽三年合同，類似這種。

我不是在給建議，只是說我自己怎么做。無論對方提供多大折扣，我個人幾乎從不簽超過一年的合同。因為我非常重視這種選擇權，希望一年后可以和當時最好的供應商合作，而現在我并不知道那會是誰。

當我們和 FDE 合作時，企業會問的一個問題是：如果你讓某家公司派來的少數幾個 FDE 嵌入你的公司，并讓他們把所有東西都深度綁定到某一個 AI 模型或某個平臺上，這會在一兩年后多大程度上降低你的選擇權？

我認為，這正是很多公司正在思考和掙扎的問題。這也是為什么我個人已經多次使用 LangSmith。我認為 Harrison 把 LangSmith 做得非常易用，這一點很棒。

這類更偏供應商中立的工具非常有價值。它們可以幫助企業做觀測，也可以幫助企業在長期保留選擇權。供應商當然很好，企業應該和供應商合作。但從長期看，為自己保留選擇權同樣重要。

構建 Agent 之前，先做好數據戰略

Harrison Chase：說到供應商中立，尤其是在模型層面，過去幾天我們也多次談到開源模型。你怎么看這些模型的發展？你如何看待它們和前沿模型之間的關系？

吳恩達：這件事很有意思。開放權重模型似乎一直穩定地落后前沿模型大概六到九個月。但前沿模型足夠昂貴，所以在很多使用場景里，我的團隊也會大量使用開放權重模型。有時候我們會做微調，有時候不微調。所以我希望大家能繼續支持開放權重模型。

過去兩周，我聽到白宮方面出現了一些讓我擔心的聲音，比如在模型發布前進行檢查。我對此其實非常擔憂，也和政府里的一些朋友保持溝通。

我感覺，針對開源模型和開放權重模型的戰爭仍然在繼續。有時候它以“美國與中國競爭”的名義出現，有時候則以其他各種理由出現。

但我認為，如果我們能共同保護開源和開放權重模型，這會讓世界變得更豐富，也會幫助我們所有人保留選擇權。

Harrison Chase：我和一些人討論過一個問題：在圍繞數據構建 Agent 之前，先把數據戰略做好非常重要。當你和那些正在構建 Agent 的公司合作時，它們大概率也希望這些 Agent 以某種形式連接到數據。你看到哪些做法比較有效？這些要求最終可以歸結為什么？

吳恩達：這是一個很好的問題。在 AI Aspire 和大型企業交流時，一個非常常見的痛點是：它們需要重新思考數據架構。過去 10 年、20 年里，我們投入了大量精力來組織結構化數據，比如表格、關系型數據、電子表格。這當然很好，現在也依然重要。

但如今 AI 可以處理非結構化數據，比如文本、圖片、PDF 文件、音頻，也許還有視頻。如何組織這些數據，讓它們能在正確的時間、正確的位置被 AI 或 Agent 使用，并創造價值，突然變得比過去重要得多。

我也花了很多時間觀察這個市場。現在有很多供應商開始談如何處理非結構化數據，但我還沒有找到一個真正讓我特別滿意的好方案。

所以在我的團隊里，包括 AI Fund 和 AI Aspire，我們正在做一堆有點瘋狂的實驗，嘗試重新架構我們自己的數據。如果這些實驗真的有效，我之后可能會講更多。

但我確實花了很多時間思考，如何重新架構我們內部的非結構化數據，讓這些數據能在合適的時間交給 Agent 使用。

我預見到，就像很多企業過去曾經面對非常大的結構化數據架構問題一樣，未來幾年，很多企業也會出現非常大的數據架構改造項目。規模可能達到數千萬美元，甚至數億美元。目標是重新思考數據架構，讓數據變得更 AI-ready，或者說更 agent-ready。

非結構化數據與

即將到來的架構重構

Harrison Chase：現有數據架構的問題在哪里？為什么它們還不夠 AI-ready 或 agent-ready？

吳恩達：問題很多。首先是碎片化、治理問題，數據到處都是，沒有統一的共識模式。有些數據甚至還放在某個人的筆記本電腦上。

還有權限問題。很多權限系統原本是為人類設計的，而不是為 Agent 設計的。那么 Agent 是否繼承我的權限？我們如何管理治理和可觀測性？

我覺得我們都見過這種情況：很多企業有大量 PDF 文件，堆在巨大的存儲桶里，過去 20 年都沒人看過。在金融服務領域，很多文檔是出于合規原因被保存下來的。以前沒人有時間看這些東西，所以看它們沒什么意義。但現在，如果讓 AI 去整理和分析這些內容，就會變得非常有價值。

順便說一個小點，這不完全屬于整個數據架構話題，但我想 CJ 接下來會發言。我想分享一個自己在 AI 編程中學到的小經驗。希望 CJ 不介意我這么說。我個人經常使用 MongoDB。

我們當然都喜歡關系型數據庫。但我發現，當我快速迭代和原型開發時，重新設計數據庫 schema 是一件非常煩人的事情。

我們大概都經歷過那種情況：讓 AI 做數據庫遷移，結果它做了一些“聰明”的事，比如把整個數據庫刪掉。雖然這幾乎不會發生，但它不是永遠不會發生，這一點就有點煩人。

所以我發現，如果使用 NoSQL，我可以先把任何我想要的數據扔進數據庫，然后在讀取時再去處理 schema，而不是在寫入數據庫時就固定 schema。這會讓我迭代得快得多。當然，NoSQL 并不總是適合最大規模的生產負載。對于非常大型的企業級生產系統，最終我還是會更多使用關系型數據庫，或者更可擴展的解決方案。

但我認為，如今 NoSQL 的可擴展性比很多人想象得更強，而且它能推動更快的迭代節奏。

我有時候會特別沮喪：已經設計好了一個數據庫 schema，結果突然發現，糟糕，我想加一個字段。然后你就不得不重構整個數據庫，這真的很煩。

所以我認為，這些都是我們為了更快迭代而調整工作流的例子。既然 AI Agent 寫代碼這么快，我們就不要再被其他事情拖慢。

原視頻鏈接：

https://www.youtube.com/watch?v=OaRhpwz_TGM

聲明：本文為 AI 前線原創，不代表平臺觀點，也不構成投資建議，未經許可禁止轉載。

會議推薦

AICon 上海站 9折限時返場，立減580，截止618！更多詳情可掃碼或聯系票務經理 13269078023 進行咨詢。

今日薦文

你也「在看」嗎？