Agent 進入工程時代！吳恩達詳解AI Agent 建構全流程，核心不在模型，而是任務拆解與評估機制

在最新的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 合作的能力。” （有新Newin）