本播客由扣子空間（coze.cn）一鍵生成

編譯 | 宇琪、Tina

前幾天，吳恩達與 LangChain 聯合創始人 Harrison Chase 展開了一場對話，而這場對話的背景，正是當前 AI 領域既充滿機遇又挑戰重重的一個現實。

過去幾年，AI 工具公司構建出一套功能強大、模塊豐富的工具體系。LangGraph、RAG 等組件就像樂高積木，讓開發者可以靈活拼裝、快速搭建系統。但在真實場景中，往往會卡在某個細節模塊，比如上下文管理或評估邏輯。有經驗的人能迅速換個解法幾天解決，沒經驗的可能要多繞幾個月的彎路。AI 開發的“殘酷”之處也在于此——沒有哪一個工具能包打天下，關鍵在于是否熟練掌握并高效組合整套工具鏈。

另一方面，工具之間的變化也很快。例如，隨著 LLM 的上下文長度持續增加，一年半前的很多 RAG 最佳實踐，今天可能就不適用了。而 MCP 的出現則補上了另一個明顯的市場空缺，讓工具、API、數據源之間的集成變得更容易。但正如吳恩達所言，MCP 仍處在“蠻荒階段”——網上有很多服務端實現，但“很多其實跑不起來”，身份驗證和 token 管理也尚不成熟。

而且， 在 Agent 與 Agent 通信方面，吳恩達坦言，如今大多數人（包括他本人）仍在努力讓一個 Agent 正常運行；而要讓兩個不同人的 Agent 成功協作，則幾乎像是完成了兩個奇跡。

我們翻譯了這場對話，讓大家了解吳恩達對 Agent 構建路徑、MCP 現狀、工具組合能力等核心問題的最新判斷與實踐思路。

1 Agentic 架構核心在任務分解與流程編排

Harrison Chase：你提議我們不去糾結一個應用是不是“Agent”（代理），而是去關注它有多“Agentic”（具備代理性）。能不能再解釋一下這個觀點？

吳恩達：我之所以提出這個觀點，是因為我發現大家在不停地爭論：“這個是 Agent 嗎？”“這個不算吧？”——各種不同的定義爭議：它夠不夠自主？是不是符合某個標準？

我當時的感覺是，與其花那么多時間爭論這個是不是 Agent，不如我們整個社區換個方式思考：把“Agenticness（代理性）”看作一個光譜——有些系統代理性強，有些弱。

你想做一個稍微具備一點自主性的 Agentic 系統，或者一個非常自主的系統，都是可以的，沒必要非得爭論“這算不算 Agent”。

所以我提議，我們就叫這些系統“Agentic systems”，然后專注于怎么構建它們。這種思維方式，其實幫我們節省了大量爭論時間，讓我們能更快進入實操階段。

Harrison Chase：你怎么看這個光譜——從“低自主性”到“高自主性”？現在大家在構建系統時，大多處在哪個位置？

吳恩達：很多企業里的實際工作，是讓員工在網頁上填寫表單、搜索信息、查數據庫有沒有合規風險、判斷是否可以向某些客戶銷售某類產品；或者是復制粘貼一些數據，再做個搜索，再粘貼到另一個表單中。這些業務流程，往往是非常線性的，偶爾出現一點小循環或小分支，通常意味著流程失敗，比如因為某個條件不滿足被拒絕。所以，我看到大量的機會，都來自這些簡單流程。

而我也注意到，企業在把已有流程轉變為“Agentic workflow（代理性工作流）”時，仍面臨很大挑戰：比如，你應該把流程拆分到什么樣的粒度？任務要分成哪些微步驟？當你構建了一個原型，但效果不夠好時，你要改進哪一個步驟才能提升整體效果？這種“從復雜任務中拆解出可執行的微步驟”、設計工作流結構、加評估機制等能力，其實現在還比較稀缺。

當然，更復雜的 Agentic 工作流也非常有價值，尤其是包含大量循環的那些。但就“數量”來說，現在的機會，還是主要集中在這些更簡單的線性流程里，大家正在一步步把它們系統化、自動化。

Harrison Chase：你做了很多深度學習相關的教學，也有很多課程是為了幫助大家理解和構建 AI Agents。那么你覺得對于 Agent 構建者來說，哪些技能是最應該掌握的？

吳恩達：我覺得最大的挑戰在于：很多業務流程里，牽涉到的是合規、法務、人力等團隊的具體操作。那你要怎么構建一個“管道”把這些流程數字化？是用 LangGraph 做集成？還是看看 MCP 是否也能幫助實現？

一個很重要但常被忽略的點是：要搭建一個正確的 Eval（評估）體系，不只是評估整個系統的效果，還要能追蹤每一步驟，這樣你才能快速定位“是哪一步壞了”，“是哪個 Prompt 沒有發揮作用”。很多團隊在這個過程中可能進展比應有的慢——他們一直靠人手評估，每次改完 Prompt，就一個個看輸出，人工判斷，這會極大影響效率。

我認為，構建系統性評估機制是最理想的方式。但問題是，很多團隊還沒有這種“下一步該做什么”的直覺。技能不足的團隊經常會走進“死胡同”——比如花幾個月去優化一個永遠也做不好的組件。而經驗豐富的團隊會說：“這個方案我們放棄吧，換一條路線。”

我希望我能總結出更高效的方式，教會大家這種“經驗性判斷”，因為很多時候你必須在幾分鐘甚至幾小時內，看著 LangChain 的 Trace 輸出、判斷當前狀態，然后迅速做出決策，而這仍然是非常困難的。

2 從工具到體系：AI 系統構建進入模塊化時代

Harrison Chase：你認為這種“經驗性判斷”，更多是和 LLM（大模型）本身的限制有關，還是更偏向產品結構、任務拆解這些“構建能力”？

吳恩達：我覺得兩者都有。過去幾年，AI 工具公司構建了一套非常強大的工具體系，包括 LangGraph 在內。你可以思考如何實現 RAG，如何構建聊天機器人，如何做記憶系統、構建 Eval、加上 Guardrails 等等。

我經常會用一個類比：如果你手上只有一種顏色的樂高積木，比如只有紫色的，你其實很難拼出復雜的結構。但現在我們有了更多類型的“積木”工具：紅的、黑的、黃的、綠的，各種形狀和功能。你擁有的積木越豐富，組裝成復雜結構的能力就越強。

我們提到的那些 AI 工具，它們其實是不同形狀的“樂高積木”。在構建系統時，你可能就正好需要那個“彎曲奇怪形狀的那一塊”，有經驗的人知道用哪一塊，能迅速完成任務。但如果你從沒做過某種類型的 Eval，可能會因此多花三個月時間，走彎路。而有經驗的人會直接說：“我們用 LLM 做 Judge，評估方式換成這個，三天就能搞定。”

這也是 AI 比較“殘酷”的地方之一——它不是一個工具能解決所有問題。寫代碼時，我自己也會用一堆不同的工具。我不能說自己精通每一個，但我熟悉足夠多，可以快速組合。而且，工具之間的變化也很快。例如，隨著 LLM 的上下文長度持續增加，一年半前的很多 RAG 最佳實踐，今天可能就不適用了。

我記得 Harrison 在這方面很早就開始探索了，比如早期的 LangChain RAG 框架、遞歸摘要等。而現在，由于上下文窗口擴大了，我們可以往里面直接塞入更多信息。RAG 并沒有消失，但調參難度已經大大降低——現在有一大段“都還行”的參數區間。

所以，隨著 LLM 的持續進化，我們兩年前的一些直覺，有些可能就已經不再適用了。

Harrison Chase：有哪些“樂高積木”組件是現在被低估了，但你會推薦大家去關注的？

吳恩達：雖然大家現在都在談論評估這件事，但很多人其實并沒有真正去做。我不太明白為什么不做，可能是因為大家通常認為寫一個評估系統是一項巨大而嚴謹的任務。但我自己是把評估當成一個可以在 20 分鐘內快速搭起來的小工具，可能做得不夠完美，但可以作為我人工 Eyeball（眼球）評估的補充。

經常會發生這樣的事：我構建了一個系統，然后某個問題不斷出現。我以為修好了，它又壞了，再修好，又壞了。這時候我就會寫一個非常簡單的評估，可能只包含五個輸入樣例，用一些非常基礎的 LLM 作為評審，只針對這個特定的回歸問題做檢測——比如“這個地方是不是又壞了”。我并不會完全用自動化評估取代人工評估，還是會親自看輸出。但這個簡單的評估可以幫我減輕一點負擔，自動跑一下，讓我不用每次都手動去檢查。

然后會發生什么呢？就像我們寫論文一樣，一開始只是搭一個非常簡陋、明顯有缺陷的評估系統。但等你有了初版，你會想“其實我可以改進它”，然后就開始迭代優化。很多時候我就是從一些糟糕透頂、幾乎沒什么幫助的評估開始做起的。然后隨著你查看它的輸出，你會發現“這個評估系統是壞的，但我可以修好它”，就慢慢讓它變得更好。

另一個我想提的點是，雖然大家也討論得挺多，但我覺得還遠遠被低估的，是 Voice stack（語音技術棧）。這是我非常感興趣的領域，我身邊很多朋友也很看好語音應用。我們也看到不少大型企業對語音技術極其感興趣，而且是規模很大的企業、使用場景也很大。

雖然這個社區里也有一些開發者在做語音，但開發者的關注度相比這些企業的關注度還是小得多。而且我們說的也不僅僅是實時語音 API，也不只是 Speech-to-text 那類原生音頻模型——因為那種模型往往很難控制。我更喜歡一種基于 Agentic 工作流的語音技術棧，它更容易控制。我最近在和很多團隊一起做語音棧相關的項目，有些希望很快能對外公布。

還有一個可能不算“被低估”，但我認為更多企業應該去做的事情是——讓開發者使用 AI 輔助編程。很多人應該都見過，使用 AI 輔助的開發者效率遠遠高于不使用的開發者。但我還是看到很多公司，尤其是 CIO、CTO 們，還制定了一些政策，不允許工程師用 AI 編程工具。我知道有時也許是出于合理原因，但我覺得我們需要盡快突破這個限制。坦白講，我和我的團隊，已經完全無法想象在沒有 AI 幫助的情況下寫代碼了。但現在還有很多企業需要接受和適應這一點。

還有一個被低估的觀點是，我覺得“每個人都應該學一點編程”。我們 AI Fund 的一個有趣事實是：我們公司每個人都會寫代碼，包括前臺接待、CFO、法務總顧問……所有人都會寫。不是說我希望他們成為軟件工程師，但在自己的崗位上，他們通過學一點點代碼，能夠更清晰地告訴計算機他們想做什么。這帶來了各個非工程崗位的顯著生產力提升，這個現象我也覺得挺令人激動。

Harrison Chase：說到 AI 編程，你自己現在在用什么工具？

吳恩達：我個人現在會用 Cursor、WindSurf，還有一些別的。

3 語音交互關鍵是對“延遲”的要求

Harrison Chase：如果現在有人想進入語音這個方向，而他們之前已經熟悉了用 LLM 構建 Agent，那你覺得他們的知識遷移性有多強？有哪些是相通的？又有哪些是全新的需要學習的？

吳恩達：我覺得有很多場景語音其實是非常關鍵的，它帶來了某些新的交互方式。

從應用層面看，文本輸入其實是一個“令人畏懼”的交互方式。你去跟用戶說，“告訴我你的想法，這是一個輸入框，寫點文字吧”，很多人會覺得壓力很大。而且文字輸入還能退格，用戶回復速度就更慢。但語音就不一樣了：時間是往前推進的，你說了就說了，也可以臨時改變主意，比如說“我改主意了，忘了我前面說的”，模型其實處理這些的效果還不錯。所以很多時候，語音可以降低用戶使用門檻。我們說“說說你的想法”，用戶就自然地開口了。

語音系統和文本系統最大的區別在于對“延遲”的要求。如果用戶說話了，系統理想中需要在一秒內做出回應（最好是 500 毫秒以內，但至少不能超過一秒），但傳統 Agentic 工作流可能需要幾秒鐘甚至更久的處理時間。比如我們在做一個“我的虛擬分身”項目，你可以在網頁上和自己的虛擬形象對話。我們最初版本有 5~9 秒的延遲——你說完話，沉默九秒鐘，然后分身才回答，這是非常糟糕的體驗。

后來我們做了一些“預回應”設計。比如你問我一個問題，我可能會先說：“嗯，這是個有意思的問題”或者“讓我想想”。我們就讓 ARM 模型去做類似這樣的回應，用來掩蓋延遲，這招效果很好。還有一些其他小技巧，比如說，如果你做的是語音客服機器人，在等待期間播放背景音（比如呼叫中心的噪音），而不是完全的靜音，用戶就會更容易接受系統的“遲鈍”。

而且在很多應用中，語音讓用戶更容易進入狀態，降低了“自我審查”的門檻。人們說話的時候，不會像寫字那樣追求完美。他們可以隨便說說，改口、反復、自由表達——這讓我們更容易從他們那里獲取有用信息，也能更好地幫助他們推進任務。

4 “如果說 MCP 還早期，那 Agent 間通信就更早期了”

Harrison Chase：你認為 MCP 在應用構建方式、類型上，帶來了哪些變化？你怎么看它對整個生態的影響？

吳恩達：我覺得 MCP 非常令人興奮。

我個人非常喜歡 MCP，它補上了一個明顯的市場空缺，而 OpenAI 的快速跟進也說明了這個標準的重要性。我覺得 MCP 標準未來還會不斷演進，目前它主要讓 Agent 更容易接入各種數據，但其實不只是 Agent，很多其他軟件也可以受益。

我們在用 LLM 的時候，尤其在構建應用時，往往會花很多時間在“管道”上——也就是各種數據接入工作上。尤其是在大企業環境下，AI 模型其實已經很聰明了，只要給它正確的上下文，它就能做出合理的事情。但我們往往要花大量時間處理接入工作，搞清楚怎么把數據喂給模型，才能讓它輸出你想要的東西。MCP 正是在這方面起到了很大的標準化作用，它讓工具、API、數據源之間的集成變得更容易。

當然，現在 MCP 還是有些“蠻荒”。你在網上能找到很多 MCP 服務端，但很多其實跑不起來。身份驗證系統也很混亂，就算是一些大公司，MCP 服務也存在 token 是否有效、是否過期等問題。

此外，我覺得 MCP 協議本身也還很早期。現在的 MCP 會返回一個很長的資源列表，未來我們可能需要某種分層發現（hierarchical discovery）機制。比如你要構建一個系統——我不知道將來會不會有 LangGraph 的 MCP 接口——但像 LangGraph 這樣的系統，有成百上千個 API 調用，你總不能把所有調用都塞進一個扁平列表里讓 Agent 去自己篩選。

所以我們可能需要一種層級式的資源發現機制。我覺得 MCP 是個非常棒的第一步。我非常鼓勵大家去了解它，它可能真的會讓你的開發更輕松，尤其是如果你能找到一個穩定好用的 MCP 服務端實現來幫你做數據整合的話。

我也認為，從長遠看這點非常重要——如果你有 n 個模型或 Agent，要接入 m 個數據源，那你不該為了每一個組合都單獨寫接入邏輯，工作量不應該是 n × m，而應該是 n + m。而我覺得 MCP 就是朝著這個方向邁出的非常棒的第一步。它還需要繼續演化，但的確是個好起點。

Harrison Chase：還有另一種協議，雖然不像 MCP 那么熱，但也值得關注，就是 Agent 與 Agent 之間的通信。那么你怎么看 Agent 與 Agent 通信的發展？

吳恩達：現在的 Agent AI 依然非常早期。我們大多數人，包括我自己，在讓自己的代碼正常運行這件事上都還在掙扎。所以要讓我的 Agent 和另一個人的 Agent 正常協作，就像是實現了兩個奇跡。

目前我看到的情況是：一個團隊內部自己構建的多 Agent 系統，是可以運轉起來的。因為大家都在同一個團隊，知道協議、約定、接口是什么，也知道怎么打配合——這樣就能跑起來。但要讓一個團隊構建的 Agent 能和另一個完全不同團隊的 Agent 協同，現在來看，還太早。我相信我們終究會實現這一點，但就我自己目前觀察到的，還沒有看到太多真正成功、規模化運行的案例。不知道你們是不是有類似的觀察？

Harrison Chase：沒錯，我同意你的看法。如果說 MCP 還早期，那 Agent 間通信就更早期了。

5 用“vibe coding”編程累死我了

Harrison Chase：你怎么看待 vibe coding（氛圍編程）？它和傳統編程相比是否是一種新的技能？它在當今世界中起到什么作用？

吳恩達：我覺得我們很多人現在編程的時候幾乎不再看代碼了，這其實是一種非常棒的進展。不過我覺得“vibe coding”這個名字挺不幸的，因為它會讓很多人誤解，以為這件事只是“靠感覺”——比如這個建議我接受，那個我拒絕，僅憑直覺判斷。

但說實話，當我花一天時間用這種“vibe coding”方式，也就是借助 AI 編碼助手工作后，我通常會感到非常疲憊。這其實是一種非常需要智力投入的活動。所以我認為雖然這個名字不好，但這個現象是真實存在的，而且它的確在發展，而且是件好事。

過去一年里，有一些人在建議別人“不要學編程”，理由是 AI 會自動幫你寫代碼。我認為未來回頭看這將會是史上最糟糕的職業建議之一。如果你回顧過去幾十年的編程發展歷史，每一次編程門檻降低，都會讓更多人開始學習編程。比如從穿孔卡片轉向鍵盤和終端，或者從匯編語言過渡到 COBOL，我甚至找到了一些非常古老的文章，當時就有人聲稱，“我們有了 COBOL，就不再需要程序員了”。但事實是，每次編程變得更簡單，學習編程的人反而變多了。

所以我認為，AI 編碼助手也將推動更多人學習編程。而且，未來最重要的技能之一，無論是對開發者還是非開發者來說，都是“清晰準確地告訴計算機你想做什么，讓它替你完成”這件事。

想要做到這一點，了解一些計算機的基本工作原理其實非常有幫助。我知道你們在座的很多人已經理解了這一點。但這也是我為什么一直建議大家至少學會一門編程語言，比如 Python。

也許你們有人知道，我自己是一個 Python 能力比 JavaScript 更強的人。但在使用 AI 編程助手之后，我寫了比以往更多的 JavaScript 和 TypeScript 代碼。即使是調試那些 AI 幫我生成、而不是我親手寫的 JavaScript 代碼時，理解其中的錯誤類型和含義，對我來說仍然非常重要，幫助我去修復它們。

6 勝負決定于速度和技術能力

Harrison Chase：你最近宣布了一個新基金——AI Fund 的新進展，對于在座有創業想法的人來說，你有什么建議？

吳恩達：AI Fund 是一家 Venture Studio（風險投資孵化器），我們不僅投資公司，而且只投資我們共同創辦的公司。

回顧 AI Fund 的經驗，我覺得創業成功的首要預測因素就是速度。雖然我們身在硅谷，但我發現很多人其實從未真正見識過一支高效團隊可以有多快地執行。如果你見過的話，你會知道，這種速度是傳統企業完全想象不到的。

第二個關鍵預測因素是技術能力。雖然像市場營銷、銷售、定價這些商業技能也很重要，而且相關知識已經積累了很久、相對普及，但真正稀缺的資源是“技術理解力”——因為技術在快速演進。我對擅長 go-to-market（商業推進）的人非常尊重，定價很難，營銷很難，產品定位也很難，但這些知識是更容易被學習到的。真正稀缺的是那些真正懂技術的人，知道什么該做、什么不該做、怎么可以讓事情加速兩倍。所以 AI Fund 非常喜歡和技術背景深厚的人合作，尤其是那些對方向有直覺判斷的人。而商業相關的能力當然也很重要，但它們相對更容易補足。

https://www.youtube.com/watch?v=4pYzYmSdSH4

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

恭喜您獲得「亞馬遜云科技中國峰會」早鳥票！

這里有：

• 3 大主題演講

• 60+ 行業與技術分論壇

• 200+ 全球重磅演講嘉賓

• 10000㎡ 沉浸式體驗區

6 月 19-20 日，共聚上海世博中心！

掃碼免費報名！