AI 是否做得越來越少？從全自動到混合架構的演化之路

當我們談論人工智慧的進步時，通常期待它能處理越來越多的任務。但在實際應用中，一個有趣的現象正在發生：許多開發者發現，隨著 AI 系統的成熟，真正需要 AI 介入的部分反而越來越少。這不是退步，而是一種更精明的進化。本文將深入探討這個看似矛盾的趨勢，以及它對未來 AI 應用開發的啟示。

從完全依賴 AI 到混合架構的轉變

六個月前，當開發者開始建構 AI 代理系統時，最直覺的做法是讓大型語言模型（LLM）處理所有事情。每一個任務、每一個決策點都交給 AI 來判斷和執行。這種做法看似充分利用了 AI 的能力，但實際運作後卻發現了許多問題。LLM 確實會自信地推進各項任務，但準確性並不總是令人滿意。更重要的是，這種全 AI 的架構在成本、速度和可預測性上都存在明顯的瓶頸。於是，一個重要的轉變開始發生：開發者逐漸意識到，不是所有任務都需要 AI 的「智慧」，許多可預測的、結構化的工作用傳統程式碼處理反而更快、更準確、更經濟。這個認知帶來了架構上的根本性改變，從完全仰賴 AI 轉向混合模式。如今，在一個成熟的 AI 代理系統中，65% 的工作流程節點實際上是以非 AI 程式碼運行的。這個數字可能會讓人感到驚訝，但它反映了一個重要的設計原則：讓確定性程式碼處理可預測的任務，讓 LLM 專注於處理模糊和需要判斷的部分。這種分工不僅提高了整體系統的效能，也大幅降低了運營成本。

工具約束與發現機制的重要性

在意識到完全依賴 AI 的問題後,第一個改進措施是引入工具約束機制。透過限制 LLM 可以呼叫的工具範圍,開發者能夠有效控制 AI 的行為邊界,避免它在執行任務時偏離預期路徑。但僅有約束還不夠,因為當可用工具變多時,AI 需要一個有效的方式來發現和選擇合適的工具。這就是為什麼需要引入發現工具（Discovery tool）的原因,它幫助 AI 在眾多選項中找到最適合當前任務的工具。這個機制類似於給 AI 一個「工具目錄」,讓它能夠根據任務需求快速定位到正確的資源。這種做法確實帶來了改善,但仍然沒有從根本上解決效率和可靠性的問題。真正的突破來自於對架構的重新思考,也就是接下來要討論的藍圖系統。工具約束和發現機制在這個演化過程中扮演了重要的過渡角色,它們讓開發者開始思考如何更精細地控制 AI 的行為,而不是簡單地把所有任務都丟給它處理。

藍圖架構：重新定義 AI 的角色

藍圖（Blueprint）架構代表了一種根本性的思維轉變。與其讓 AI 決定每一步該做什麼,不如預先定義好工作流程的結構,明確指出哪些節點需要 AI 介入,哪些可以用確定性程式碼處理。藍圖是用程式碼撰寫的工作流程圖,它明確規範了節點、節點之間的轉換、觸發條件以及錯誤處理機制。一個典型的藍圖可能看起來像這樣：從程式碼提取域名,然後用程式碼在 Attio 中查找,接著用程式碼進行 Harmonic 資料豐富化,之後讓 LLM 生成摘要（這是唯一需要 AI 的步驟）,最後用程式碼將結果插入 Notion。這種架構與傳統的「技能」或「提示」有本質區別。技能告訴 LLM 該做什麼,而藍圖則告訴整個系統何時才需要動用 LLM。這是一個關鍵的區別,因為它將控制權從 AI 手中拿回,交給了更可預測、更可控的系統架構。藍圖本質上是一個有向圖,每個節點有兩種類型：確定性節點（程式碼）和代理性節點（LLM）。節點之間的轉換可以根據條件分支,這提供了必要的靈活性,同時保持了整體的可預測性。這種設計哲學的核心是認識到,大多數業務流程實際上是高度結構化和可預測的,只有在特定的決策點或需要處理非結構化資料時,才真正需要 AI 的能力。

工作流程的四大類型分析

透過對實際運行數據的分析,我們可以將工作流程分為四大類型,每種類型對 AI 的依賴程度截然不同。第一類是完全確定性的工作流程,佔總量的 29%,包括交易管道更新、聊天訊息處理和電子郵件路由等。這些任務完全不需要 LLM 的參與,因為它們遵循固定的規則和邏輯。第二類是輕度混合型工作流程,佔 36%,包括公司研究、電子報處理和人物研究。這類工作流程的 67-91% 由程式碼執行,只在需要提取資訊和綜合分析時才呼叫 LLM,而且通常只需要一到三輪對話,並使用受約束的工具。例如,在公司研究中,資料的爬取、清理和結構化都由程式碼完成,只有在需要從大量文字中提取關鍵洞察或生成摘要時,才會將處理好的文字片段交給 LLM。第三類是深度混合型工作流程,佔 21%,包括部落格文章撰寫、文件分析和錯誤修復。這些任務需要多次 LLM 呼叫,透過迭代來提升品質。這類工作流程中,AI 和程式碼的互動更加頻繁和深入,但即使如此,仍有相當比例的工作由確定性程式碼處理。第四類是完全代理性的工作流程,只佔 14%,主要是資料轉換和錯誤調查等任務。有趣的是,這些往往是編碼任務,而不是評估工作流程中的決策點。在這些情況下,LLM 需要自由探索的空間,因為問題的本質是開放性的,沒有預定義的路徑可循。這種分類清楚地顯示,即使在所謂的「AI 系統」中,真正需要 AI 智慧的部分其實是少數。

為什麼這種演化是進步而非退步

乍看之下,AI 做得越來越少似乎是一種倒退,但實際上這是系統成熟的標誌。這種演化背後有幾個重要的原因。首先是成本考量。LLM 的呼叫成本遠高於執行傳統程式碼,當系統每天處理數千個任務時,這個差異會累積成可觀的開支。透過將可預測的任務交給程式碼處理,可以大幅降低運營成本。其次是速度和可靠性。程式碼的執行速度通常比 LLM 推理快得多,而且結果是確定的、可重現的。這對於需要即時回應或高可靠性的應用場景至關重要。第三是可維護性和可除錯性。當工作流程主要由結構化的程式碼組成時,開發者更容易理解系統的行為,追蹤問題,並進行優化。相比之下,完全依賴 LLM 的系統就像一個黑盒子,當出現問題時很難診斷和修復。第四是可擴展性。隨著業務成長,系統需要處理的任務量會急劇增加。如果每個任務都需要 LLM 處理,會很快遇到擴展瓶頸。而混合架構允許系統在不過度依賴 AI 資源的情況下擴展。更重要的是,這種架構實際上讓 AI 發揮了更大的價值。當 AI 不再被瑣碎的、可預測的任務淹沒時,它可以將計算資源集中在真正需要智慧判斷的地方。這就像一個公司裡,高階主管不應該被行政雜務纏身,而應該專注於需要經驗和判斷力的策略決策。所以問題的答案是：AI 做得更少了嗎？是的。但系統做得更多了嗎？也是肯定的。這不是矛盾,而是更聰明的資源配置。

臨時腳手架還是長期策略？

一個值得思考的問題是,這些藍圖、工具和技能是否只是臨時的腳手架,隨著 AI 能力的提升最終會被淘汰？畢竟,每一次新模型發布,AI 的能力都在擴展。六個月前需要確定性程式碼處理的任務,可能在明天就能完全交給更先進的 LLM 處理。這個觀點有其道理,但可能過於簡化了問題。即使 AI 的能力持續增強,混合架構仍然有其不可替代的價值。首先,物理定律和經濟規律不會改變。即使未來的 LLM 能夠完美執行所有任務,呼叫它們仍然會比執行簡單的程式碼更昂貴、更慢。在商業環境中,效率和成本永遠是重要考量。其次,可預測性和可控性在關鍵業務流程中至關重要。當處理財務交易、醫療決策或安全相關的任務時,企業需要確定性的保證,而不是「通常很準確」的 AI 判斷。混合架構提供了這種保證,透過在關鍵節點使用確定性程式碼。第三,這種架構實際上是一種最佳實踐,而不僅僅是權宜之計。它體現了「使用正確的工具解決正確的問題」的工程原則。就像我們不會用機器學習模型來做簡單的加法運算一樣,不應該用 LLM 來處理所有任務。當然,隨著 AI 能力的提升,確定性程式碼和 AI 之間的界線可能會移動。今天需要精心設計的工作流程,明天可能只需要一個更強大的 LLM 就能處理。但這不意味著混合架構會消失,而是它的具體形式會演化。藍圖中代理性節點的比例可能會增加,但架構本身——明確定義何時使用 AI、何時使用程式碼——仍然是有價值的。

給非技術讀者的簡單說明

如果你不是技術背景,可能會對上述討論感到困惑。讓我用一個簡單的比喻來解釋。想像你在經營一家餐廳,剛開始時你聘請了一位天才廚師（代表 AI）,讓他負責所有事情：採購食材、準備配料、烹飪、裝盤、甚至洗碗。這位廚師確實有才華,但這種安排既昂貴又低效。漸漸地,你意識到可以聘請一些助手來處理標準化的工作：有人專門洗菜切菜（確定性程式碼）,有人負責擺盤（確定性程式碼）,讓天才廚師專注於真正需要創意和判斷的烹飪步驟（AI 處理）。結果是什麼？廚師做的工作變少了,但餐廳的產出增加了,品質更穩定了,成本也降低了。這就是本文討論的混合架構。最初的 AI 系統讓 AI 做所有事情,就像讓廚師負責餐廳的一切。而優化後的系統則是合理分工,讓每個部分都做它最擅長的事。程式碼擅長處理重複的、有明確規則的任務,就像廚房助手擅長洗菜切菜。AI 擅長處理需要理解、判斷和創造的任務,就像廚師擅長調配味道和創新菜式。所以當我們說「AI 做得越來越少」時,並不是說 AI 變得不重要了,而是說我們學會了更聰明地使用它。整個系統變得更高效、更可靠、也更經濟。這就是技術成熟的標誌。

對未來 AI 應用開發的啟示

這種從全 AI 到混合架構的演化,為未來的 AI 應用開發提供了幾個重要啟示。首先,在設計 AI 系統時,不要從「AI 能做什麼」出發,而應該從「這個任務真正需要什麼」出發。對每個任務進行分析,確定它是結構化的還是開放性的,是可預測的還是需要判斷的。只有在任務真正需要 AI 能力的地方才使用 LLM。其次,將系統視為一個有機整體,而不是單純的 AI 應用。最佳的 AI 系統往往是 AI 和傳統程式設計技術的精巧結合。藍圖架構提供了一個很好的範例,展示如何在保持靈活性的同時維持可控性。第三,重視可觀察性和可維護性。隨著 AI 系統在業務中扮演越來越重要的角色,理解系統行為、診斷問題和持續優化的能力變得至關重要。混合架構通過增加確定性元素,大大提升了系統的可觀察性。第四,保持架構的演化能力。AI 技術發展迅速,今天的最佳實踐可能在明天就需要調整。設計系統時應該考慮到這種演化,讓藍圖和工作流程易於修改和更新。最後,關注成本效益。AI 的價值不在於使用了多少 AI,而在於它為業務帶來了多少實際價值。一個使用較少 AI 但更高效、更可靠、更經濟的系統,往往比一個過度依賴 AI 的系統更有價值。這些原則不僅適用於現在,也將在可預見的未來持續相關。無論 AI 技術如何進步,聰明地組合不同技術、為特定問題選擇最合適的解決方案,都將是優秀工程實踐的核心。