在最新的 LangChain Interrupt 峰會上，AI Fund 創始人吳恩達與 LangChain 聯合創始人 Harrison Chase 展開了一場對話。

作為 AI 教育和創業孵化的重要推動者，吳恩達圍繞 Agent 構建方法論、評估機制、語音與協議基礎設施，以及開發者與創業者應具備的直覺判斷力展開系統性闡述。

他提出，“agenticness” 應被理解為連續程度，而非標簽判斷；未來 AI 構建者的核心競爭力，不在提示設計，而在流程建模與執行速度。

“agenticness” 是程度而非標簽

吳恩達回顧了一年多前與 Harrison 同臺演講的場景。那時他們正試圖說服行業相信 Agent 是一個值得投入關注的方向。“那時候，大家還不確定 Agent 是不是一個重要的東西。”他說。那之后，隨著 Agent 概念走紅，“agenticness” 這個詞也迅速被市場營銷人員廣泛使用，漸漸變得語義模糊。“這個詞被濫用了，大家開始用它指代各種系統，但實際含義已經不明確了。”

他指出，當時很多人在爭論“這個系統到底是不是 Agent”、“它是否真正具備自主性”，但這類爭論本身并沒有太大價值。與其浪費時間在這些語義層面的問題上，不如換一種方式思考。他提出“agenticness 是一個光譜”的概念：不同系統具有不同程度的 agenticness，從幾乎無自主性到高度自主都是合理的存在，只要系統具備一定程度的自主性，都可以歸入 agentic 系統的范疇。

“如果你想構建一個具備一點點或者很多自主性的 agentic 系統，那都是合理的。沒必要去糾結它是否‘真正是 Agent’。”吳恩達說。

這種包容性的定義有助于整個社區從語義糾纏中解放出來，更高效地推進實際落地工作。他表示，這種思路確實起到了積極作用，讓更多開發者從“是否為 Agent”的問題中抽身，專注于系統是否能解決實際問題。

Agent 建模經驗嚴重不足

當被問到當前構建者處于怎樣的“agenticness 光譜”階段時，吳恩達表示，他所在團隊會使用 LangGraph 去處理一些較復雜的問題，比如多步驟流程自動化。“但我也看到很多現實中的商業流程其實是線性的，或者是線性中夾雜一些失敗分支。”他說。

他舉例說明，在一些業務中，人類目前仍在重復完成一系列可預測的操作，比如：填寫表格、在網頁搜索信息、訪問數據庫確認是否涉及合規、判斷是否可以銷售某樣物品。這類流程其實是“復制—粘貼—再搜索—再粘貼”的循環，結構相對固定。

這些流程本質上非常適合 agent 化處理，但最大挑戰是，許多公司還不知道如何將其轉化為 agentic 系統。“比如應該以什么樣的粒度去拆分任務？如果原型效果不佳，該從哪個步驟優先改進？這類知識在業界其實是非常稀缺的。”

盡管有更復雜的 agentic 工作流存在，比如多循環、多代理系統，但吳恩達指出，當前階段構建者面臨的主要問題仍集中在簡單流程的建模與拆解上。“我們現在最缺的，其實是讓這些結構化流程自動化的‘中間技能’。”

Agent 系統需要系統直覺，快速且實用

談到構建 Agent 所需的關鍵技能時，吳恩達表示，系統管道的搭建能力是第一步。他指出，在現實業務流程中，往往涉及多個角色：合規、法務、人力資源等。每個角色都執行特定任務，Agent 系統需要模擬這些角色的邏輯，將流程順利銜接。

那么開發者該怎么做？是用 LangGraph？還是 MCP Host？是否需要模塊化集成不同子任務？這些都取決于任務本身。而很多團隊在遇到系統出錯時，反而不知道問題在哪，也不知道下一步該優化哪個部分。

“我發現很多團隊其實花太多時間依賴人工評估。每次系統調整之后，就人工看輸出是否正確。”吳恩達說。他認為評估機制的缺失，是當前 Agent 構建過程中最大的“看不見的問題”。

他主張快速搭建“哪怕很爛”的初級評估系統，比如針對某一失敗步驟，寫一個只覆蓋 5 個輸入示例的檢測腳本，用一個簡單模型去判斷系統是否回歸。“它不需要完全替代人眼，而是去承擔那些重復性判斷任務。”

他認為最理想的狀態是：開發者能在幾分鐘到幾小時內，迅速基于 LangSmith 等工具做出決策。這種基于真實數據、真實失敗路徑的“觸覺型直覺”，才是系統構建中最寶貴的經驗。“沒有這種觸覺，你可能花幾個月優化某個組件，但有經驗的人一眼就知道這個方向做不出來。”

工具即積木，認知覆蓋決定效率高低

吳恩達強調，現在 AI 社區已經出現大量強大的工具，但開發者間的工具認知差距非常大。他將其比喻為“彩色樂高積木”：過去如果只有一種積木，比如紫色積木，那你能搭出來的東西非常有限。但現在我們有紅色、藍色、綠色、各種形狀、大小的樂高，你可以搭出幾乎任何結構。

這些樂高積木的存在，比如 LangGraph、Retriever、RAG、Memory、Email Generator、Guardrail 機制等，構成了構建 agentic 系統的技術庫。而真正掌握這些工具的開發者，能在系統失敗時迅速重組結構，而不是陷入冗長 debugging。

“我寫代碼的時候也會混合用很多工具。我不需要是每個工具的專家，但我知道它們能做什么，能解決什么問題。”吳恩達說。

他補充道，在過去一兩年中，RAG（檢索增強生成）的最佳實踐也發生了變化。大模型的上下文窗口增大，意味著許多過去對超參數的調節現在不那么緊迫。很多舊的直覺已經不再適用，開發者必須不斷更新自己的“工具知識圖譜”，否則就會嚴重落后。

語音棧與 MCP 協議被低估了

在討論哪些關鍵領域仍被忽視時，吳恩達直言，語音技術棧與 MCP 協議是最值得關注的方向。他認為語音應用的價值遠未被開發出來。

“用戶寫提示詞其實是很高門檻的。長文本需要組織語言、反復修改，這會讓人不愿意開口。”但語音是時間向前推進的過程，用戶說出來就可以繼續下去，哪怕說錯了也能反悔，互動過程更加自然。

他說，在與 Reald Avatar 合作構建的虛擬分身中，一開始系統響應時間為 5～9 秒，用戶體驗非常糟糕。后來他們加入了“預響應機制”，即大模型會先說出“讓我想想”、“這個問題挺有趣”等緩沖語句，填補這幾秒的空白，大幅提升了體驗。

他們還發現，給語音系統加上“呼叫中心背景音”也會緩解等待感。這種小技巧雖然簡單，卻是構建語音系統時非常重要的工程方法論。“語音 Agent 的運行邏輯和文本 Agent 是完全不同的。”

同時，他也強調 MCP 協議在未來多模型系統中的價值。當前企業在構建 Agent 時常常需要連接多個數據源、API、服務接口，如果每一對都要手寫適配器，維護成本極高。

“MCP 是一次真正意義上的接口標準化嘗試。”吳恩達表示。他指出，目前 MCP 服務端實現仍不穩定，很多認證機制不完善、Token 管理不一致，但整體方向是正確的。未來 MCP 應該發展出分層式資源發現機制，不再是列出一大堆平鋪的 API，而是讓 Agent 能結構化地發現調用路徑。

他總結道，我們正在邁向一個“n 個 Agent 對接 m 個數據源”的世界，MCP 的存在讓它從 n×m 的維護成本變成 n+m 的接口管理，這是一次計算復雜度的飛躍。

勝負手取決于技術理解和執行速度

在對談最后，吳恩達談到 AI Fund 的工作。他表示，AI Fund 并不做外部投資，而是共同創辦公司。他們在篩選合作對象時最看重兩點：

一是“技術理解力”。他說，現在很多人講市場、講定位、講 go-to-market 策略，這些當然重要，但都是可以短期內補課的。而對技術的理解、對系統的建構直覺，是長時間積累的稀缺能力。

二是“執行速度”。吳恩達表示，他見過一些團隊，在 2 周內完成其他團隊 3 個月才能做完的事情。而這類速度，幾乎是成敗的分水嶺。“很多團隊從來沒見過‘一個優秀團隊到底能有多快’。”他說。

他最后說，無論是否是程序員，未來最重要的技能就是“能精確表達你想讓計算機做什么”。他說：“哪怕你是 CFO、法律顧問、前臺，如果你能寫一點 Python，哪怕很基礎，也能極大提升你和 AI 合作的能力。”

?精選內容?