AI 智能體，業務規模提升百倍的關鍵

撰文：vas

編譯：AididiaoJP，Foresight News

AI 不是魔法，但也沒有簡單到「搭個 AI 程序、自動搞定一切、坐等收益」的程度。大多數人其實並不清楚 AI 究竟是什麼。

而那些真正明白的人（不到 5%）嘗試自己去搭建，結果往往失敗。智能體會出現「幻覺」、會在任務中途忘記自己做到哪一步、或者在不該調用工具的時候錯誤調用。演示時它運行完美，一到生產環境就立刻崩潰。

我部署 AI 程序已經一年多了。我的軟件職業生涯始於 Meta，但半年前我離職創立了一家公司，專門為企業部署生產可用的 AI 智能體。現在我們年經常性收入已達到 300 萬美元，並且還在增長。這不是因為我們比別人聰明，而是因為我們反覆試錯、失敗多次，終於摸清了成功的公式。

以下是我在構建真正可用的智能體過程中學到的一切。無論你是初學者、專家，還是介於兩者之間，這些經驗都應該適用。

第一課：語境就是一切

這聽起來可能特別明顯，你或許也早就聽說過。但正因為它如此重要，才值得反覆強調。很多人以為構建智能體就是把各種工具連起來：選個模型、開放數據庫權限、然後你就撒手不管了。這種做法會立刻失敗，原因有幾個：

智能體不知道什麼是重點。它不知道五步之前發生了什麼，只能看到當前這一步，然後猜接下來該做什麼（而且常常猜錯），最後碰運氣。

語境，往往是價值百萬的智能體與一文不值的智能體之間最根本的差別。你需要重點關注並優化這幾個方面：

智能體記得什麼：不僅是當前任務，還包括導致現狀的完整歷史。比如處理發票異常時，智能體需要知道：異常是怎麼觸發的、原始發票是誰提交的、適用哪條政策、這個供應商上次出問題是怎麼處理的。沒有這些歷史，智能體就是在瞎猜，這比沒有智能體還糟。因為如果靠人處理，問題可能早就解決了。這也解釋了為什麼有人吐槽「AI 真難用」。

信息如何流動：當你有多個智能體，或者一個智能體處理多步流程時，信息必須在各階段間準確傳遞，不能丟失、損壞或被誤解。負責分類請求的智能體，必須把乾淨、結構化的語境傳給負責解決問題的智能體。如果交接不嚴謹，下游全亂。這意味著每個環節都要有可驗證的結構化輸入和輸出。一個例子是 Claude Code 裡的 /compact 功能，它能在不同 LLM 會話之間傳遞上下文。

智能體對業務領域的瞭解：處理法律合同審查的智能體，必須清楚哪些條款關鍵、風險預估、公司實際政策是什麼。你不能只丟給它一堆文檔，就指望它自己悟出重點，這是你的責任。而你的責任也包括：用結構化的方式為智能體提供資源，讓它真正具備領域知識。

糟糕的語境管理表現為：智能體因為忘記已獲得答案而重複調用同一工具；或者因收到錯誤信息而調用錯誤工具；又或者做出與前面幾步矛盾的決定；甚至每次都把任務當全新的處理，無視以往相似任務中存在的明顯模式。

良好的語境管理則讓智能體像一位經驗豐富的業務專家：它能在不同信息間建立聯繫，無需你明確告訴它這些信息有什麼關係。

語境，是區分「只能演示」的智能體和「真正在生產環境運行並交付成果」的智能體的關鍵。

第二課：AI 智能體是成果倍增器

錯誤的看法：「有了它，我們就不用招人了。」

正確的看法：「有了它，三個人就能幹以前十五個人的活。」

智能體終將替代部分人力勞動，不承認這一點只是自欺欺人。但積極的一面是：智能體不會取代人類判斷，而是消除圍繞人類判斷產生的各種摩擦，比如查找資料、收集數據、交叉比對、格式整理、任務分發、跟進提醒等等。

舉個例子：財務團隊依然需要為異常情況做決策，但有了智能體，他們不用再花 70% 的結賬周時間去翻找缺失單據，而是能用這 70% 的時間真正解決問題。智能體完成所有基礎工作，人類只做最終審批。根據我為客戶服務的經驗，實際情況是：企業並不會因此裁員。員工的工作內容會轉變，從繁瑣的手工操作轉向更有價值的任務，至少目前如此。當然，長遠來看，隨著 AI 進一步發展，這種情況可能會改變。

真正從智能體中獲益的公司，不是那些只想把人類踢出流程的，而是那些意識到：員工大部分時間花在了「鋪墊性工作」上，而不是真正創造價值的部分。

按這個思路設計智能體，你就不用再死磕「準確率」：智能體做它擅長的，人類也專注做人類擅長的。

這也意味著你能更快部署上線。不需要智能體處理所有極端情況，只要它把常見情況處理好，同時把複雜異常轉給人類——並附上足夠語境，讓人能快速解決。至少，現階段應該這樣做。

第三課：記憶與狀態管理

智能體如何在一個任務內以及跨任務保存信息，決定了它能否規模化運作。

常見的有三種模式：

獨立智能體：單獨處理完整工作流，從開始到結束。這種最好搭建，因為所有語境都在一處。但隨著流程變長，狀態管理會成挑戰：智能體必須記住第三步做的決定，等執行到第十步時還要用上。如果語境窗口滿了，或者記憶結構不對，後期的決策就會缺乏早期信息支撐，導致出錯。

並行智能體：同時處理同一問題的不同部分。速度更快，但引入了協調問題：結果如何合併？如果兩個智能體得出矛盾結論怎麼辦？必須制定清晰的協議來整合信息、解決衝突。通常需要引入一個「裁判」（人或另一個 LLM）來處理衝突或競態條件。

協作智能體：按順序交接工作。智能體 A 分類，傳給 B 做研究，再傳給 C 執行解決方案。這種模式適用於有清晰階段的工作流，但交接環節最容易出問題。智能體 A 學到的東西，必須以智能體 B 能直接使用的格式傳遞下去。

大多數人犯的錯誤是：把這些模式當作「實現方案」來看。實際上，它們是架構決策，直接決定了你的智能體能力邊界。

例如你要搭建一個處理銷售合同審批的智能體，就必須決定：是讓一個智能體全程負責？還是設計一個路由智能體，把任務分發給定價審核、法務審核、高管審批等不同專長的智能體？只有你清楚背後的實際業務流程，希望你最終也能把這些流程教給你的智能體。

怎麼選？取決於每個環節的複雜度、階段間需傳遞多少語境、以及各環節是需要實時協同還是按序執行。

如果架構選錯了，你可能要花幾個月去調試一些根本不是 bug 的問題。那其實是你的設計、你要解決的問題以及你的解決方案之間的架構錯配。

第四課：主動攔截異常，而非事後報告

做 AI 系統時，很多人的第一反應是：做個儀表板吧，把信息展示出來，讓大家看到發生了什麼。拜託，真的別再搞儀表板了。

儀表板沒什麼用。

你的財務團隊早知道有票據缺失，銷售團隊也早知道有些合同卡在法務那裡。

智能體應該在問題發生時直接攔截，並轉給對應的人去解決，同時提供解決所需的一切信息，立刻執行。

發票來了但文件不全？別隻是記到報告裡。立刻標記，弄清楚誰該補什麼材料，把問題連同完整語境（供應商、金額、適用政策、具體缺什麼）轉給他。同時阻止這筆交易入賬，直到問題解決。這步很關鍵，否則問題會在組織裡到處「洩漏」，你想補救都來不及。

合同審批超過 24 小時沒動靜？別等到週會再提。自動升級，附上交易詳情，讓審批人不用到處查系統就能快速決定。要有緊迫感。

供應商沒按時完成里程碑？別等誰去發現。自動觸發應急預案，在有人意識到問題之前就啟動應對流程。

你 AI 智能體的職責是：讓問題無法被忽視，且解決起來極其輕鬆。

要直接暴露問題，而不是通過儀表板間接呈現。

這和大多數公司用 AI 的方式正相反：他們用 AI 來「看見」問題，而你應該用 AI 來「逼著」解決問題，並且要快。等問題解決率接近 100% 了，再考慮要不要做個儀表板看看。

第五課：AI 智能體 vs 通用 SaaS 的經濟賬

企業不斷購買沒人用的 SaaS 工具是有原因的。

SaaS 容易採購：有演示、有報價、需求清單上有個勾可以打。有人批了，就覺得事情推進了（雖然往往並非如此）。

買 AI SaaS 最糟的是，它往往就擺在那。它沒有融入實際工作流，成了又一個需要登錄的系統。你被迫遷移數據，一個月後它只是又多了一個要管理的供應商。12 個月後它被棄用，但你卻甩不掉，因為切換成本太高，結果就是「技術債」。

基於你現有系統定製的 AI 智能體就會杜絕此類問題。

它在你已經用的工具裡運行，不創造新的工作平臺，反而讓現有工作更快完成。智能體處理任務，人類只看結果。

真正的成本對比不是「開發費 vs 授權費」，而是更簡單的邏輯：

SaaS 積累「技術債」：每買一個工具，就多一個要維護的集成、一個遲早會過時的系統、一個可能被收購 / 轉型 / 關閉的供應商。

自建智能體積累「能力」：每次改進都讓系統更聰明，每個新工作流都拓展了可能性。投資是複利增長，而不是隨時間貶值。

所以我過去一年一直說：通用 AI SaaS 沒有未來。行業數據也在印證：多數採購 AI SaaS 的企業在 6 個月內停用，且完全沒看到生產力提升。真正從 AI 中獲益的，都是那些擁有定製智能體的公司，無論是自研還是找第三方開發的。

這就是為什麼早期掌握智能體的公司會擁有長期的結構性優勢：他們在建設會越來越強的基礎設施。其他人只是在租用遲早要換掉的工具。在這個領域每月都在劇變的時代，每浪費一週，對你的產品路線圖和整體業務都是重大損失。

第六課：部署要快

如果你的 AI 智能體項目規劃一年才能上線，那已經輸了。

計劃趕不上變化。你設計的工作流很可能不符合實際工作方式，而你沒想到的邊緣情況往往最重要。12 個月後 AI 領域可能天翻地覆，你做的可能已是過時的產物。

最多 3 個月，必須進入生產環境。

在這個信息爆炸的時代，真正的能力在於：知道如何有效利用信息，並與之協作而非對抗。要實際幹活：處理真實任務、做出真實決策、留下可追溯的記錄。

我見過最普遍的問題是：內部開發團隊常把本應 3 個月完成的 AI 項目估成 6–12 個月。或者更糟——嘴上說 3 個月，開工後卻用各種「意外原因」不斷延期。這不全怪他們，AI 領域確實複雜。

所以你需要真正懂 AI 的工程師：他們理解 AI 如何規模化運作、見過真實場景中的問題、清楚 AI 的能力與侷限。現在有太多「半桶水」開發者，以為 AI 什麼都能做——這離事實太遠了。如果你是一名想進入企業級應用 AI 領域的軟件工程師，你必須紮實掌握 AI 的實際能力邊界。

總結一下

構建可用的智能體，關鍵在這幾點：

語境決定一切：沒有好上下文的智能體只是昂貴的隨機數生成器。務必做好信息流轉、記憶持久化、領域知識嵌入。以前大家笑話「提示詞工程師」，現在「上下文工程師」就是它的 2.0 版。

為「增效」設計，而非「替代」：讓人做人擅長的事，讓智能體清理道路，使人更專注。

架構比模型選擇更重要：用獨立、並行還是協作智能體，這個決策比選哪個模型關鍵得多。先把架構搞對。

攔截並解決，而非報告與回顧：儀表板是問題的「墳墓」。要建立能逼著問題被快速解決的系統。

快速上線，持續迭代：最好的智能體是已在生產環境運行並不斷改進的那個，而不是還在設計中的那個。（並且要盯緊你的時間表）

其他都是細節。

技術已經就緒，但你可能還沒準備好。

搞明白這一點，你就能把業務規模擴大 100 倍。