智慧體堆疊的賭注

以下文章最初發表在《Elevate》通訊上，經作者許可在此轉載。

揭開當今大多數“生產級智慧體”的引擎蓋，你看到的並非智慧。相反，你會發現定製的管道、脆弱的會話邏輯、共享的服務賬戶，以及一個靠希望維繫的安防模型。這一切本可以變得更好。

如果你在過去18個月裡將智慧體投入生產，你早已知道模型和工具已經取得了顯著進步。你也知道，那些仍在折磨你值班團隊的難題，並非靠提示就能解決。我們正面臨一個堆疊天花板，它悄然製造了一個治理和可靠性鴻溝，下一代智慧體系統無法跨越。

目前，行業處於我稱之為“過度授權”的狀態：自主系統被授予廣泛許可權去完成任務，然後任其在執行時和在生產環境中發現——模式漂移、API變更，或下游服務開始返回不應洩露的個人身份資訊。智慧體標記任務為“完成”，卻留下一串損壞的狀態。人類在週一才發現問題。

這不是構建智慧體的人們的失敗，而是他們所構建的堆疊的失敗。

以下是每個嚴謹團隊在未來12個月內必須做出的四個架構選擇。

1. 智慧體需要身份，而非共享憑證

每個將智慧體投入生產環境的工程師都熟悉這種特殊的恐懼：你擁有執行有用工作的智慧體，卻幾乎無法看到它們接觸了哪些工具、移動了哪些資料，或使用了哪些憑證。我稱之為治理債務——安全與審計風險的無聲積累，最終迫使全面重寫，通常發生在第一個事件升級到首席資訊安全官之後。

根本原因是當今大多數智慧體都是幽靈。它們沒有身份。它們借用服務賬戶、繼承人類的OAuth令牌，並在應用程式碼和提示中“承諾”遵守規則。在真實的企業環境中，提示中的承諾並非策略。

我的賭注是，智慧體身份必須從應用層下移到平臺層。

區別在於附加式安全與嵌入式安全。附加式安全看起來像每個工具呼叫前的中介軟體，禮貌地要求智慧體守規矩：易於繞過，延遲成本高，且對你現有的身份與訪問管理來說不可見。嵌入式安全則像焊在鋼架上的讀卡器。智慧體有一個獨特、不可偽造的身份，在網路和平臺級別得到識別，並在源頭執行策略。如果智慧體嘗試訪問未授權的資料庫，連線永遠不會開啟。沒有中介軟體，沒有模糊地帶。

正確實施後，這將把“一支由負債組成的艦隊”轉變為更像管理勞動力的東西：每個動作可歸因，每個許可權可審計，每個智慧體可透過一次呼叫撤銷。

2. 智慧體需要通用上下文，而非刮取的視窗

上下文管理是每個構建者正在支付的稅。團隊正在耗費大量工時（和令牌）在無差異的管道上——自定義序列化、定製會話儲存、手工記憶層——僅僅為了讓智慧體在執行多步驟任務時不忘目標。

更糟的是，智慧體能獲取的上下文通常是孤立的。基於瀏覽器的智慧體只能看到當前標籤頁；桌面封裝器只能看到使用者拖入的檔案。兩者都無法輕易地同時跨系統推理——這些系統是業務真正所在的地方：客戶關係管理、企業資源計劃、資料倉儲、工單系統、轉錄、專案計劃。

智慧體需要在平臺級別整合的通用上下文。如果我們不解決這個問題，我們應該誠實地承認，智慧體AI的天花板不過是“稍微好一點的電子表格自動完成”，我們應該停止撰寫關於它的願景文章。

3. 智慧體需要能夠承受筆記型電腦合上

這裡是不太舒服的版本：當今許多作為“智慧體”釋出的東西，實際上還未準備好跨企業部署。

我想精確一些，因為過去六個月前沿確實取得了進展。像Claude Code、OpenClaw和類似平臺的環境是強大的——持久任務狀態、定時執行、多智慧體協調、以及能夠在斷連後生存的長時間會話不再是幻想。這些不是玩具。問題已經向前推進了。

現在的問題是，智慧體能否持續執行一週而非一小時？能否跨三次交接、兩次憑證輪換和一個審批關口，而無需人類監視會話？它在星期二完成的工作能否在星期五被當時不在場的人審計？一個能經受住WebSocket斷開的會話只是基本要求。而能經受住一個季度的任務才是企業真正需要的門檻。

真正的工作不適用於會話，且大部分工作也不適用於一天之內。採購工作流程跨越數週和十幾次交接；合規審計持續一個月；事件調查超過三個值班輪次。

當今大多數智慧體面臨硬性天花板——有時基於時間，有時基於令牌，有時基於治理——當它們觸及時，任務失敗，人類從指令碼結束處收拾殘局。

企業級自主性需要持久的、雲原生的執行，其基準遠高於“會話保持連線”。具體來說，這意味著：

• 狀態和檢查點預設能在重啟、斷連、重新部署和模型版本變更後倖存——而非依靠本地Redis和祈禱作為附加。
• 上下文超越視窗：長期記憶、摘要、智慧體例項間的交接，使得持續數週的任務不會因為單次執行耗盡令牌而死亡。
• 任務超越會話：能夠跨越數天、交接和憑證輪換持續工作的智慧體，並留下在你睡覺時發生事情的可審計軌跡。
• 一流的人機協作原語：智慧體能暫停並請求許可權執行新操作，而非默默自認為有許可權。
• 帶護欄的永續性。這才是門檻。達不到這點，你只是在構建碰巧執行很久的演示。

4. 智慧體需要平臺

我在最優秀的團隊中常見到的最可悲的模式是：才華橫溢的工程師將頻寬消耗在堆疊問題上，而這些並不使他們的產品差異化。自定義記憶、自制評估框架、自建可觀測性、手寫重試邏輯、幾乎能用的追蹤系統。這些都不是智慧體時代的難點，也不是使用者付費給你的原因。

真正的價值在於領域推理和業務邏輯——那些對你的公司、你的客戶、你的監管環境特有的判斷。所有底層應該是你構建其上的平臺，而不是你需要構建的管道。

這就是為什麼開源原語成熟現在如此重要。開源編排框架的存在，正是為了不讓腳手架被任何單一供應商的路線圖鎖定。適用於雲端計算、容器和持續整合/持續交付的模式——從開源原語本地開始，準備好擴充套件時升級到託管平臺——正是智慧體平臺需要複製的模式。

團隊應該能夠在筆記型電腦上使用與生產環境相同的構建塊進行原型設計，並在無需重寫的情況下跨越邊界。

這才是讓團隊停止與管道鬥爭，迴歸到產品上的工程標準。

五年展望

在未來五年中領先的團隊，並非靠更聰明地編寫樣板程式碼脫穎而出。他們透過選擇合適的智慧體基礎，並將其工程工時投入到只有他們能解決的問題上而領先。

每個月花在重建通用堆疊（身份、上下文、持久化、編排）上的時間，都是沒有花在真正讓你的智慧體值得部署的邏輯上的時間。

智慧體堆疊必須成為一個已解決的問題。唯一真正的問題是，你是想再次自己解決它，還是構建在一個從頭就為智慧體設計的平臺上。

我的賭注是後者。我認為你也應該這樣。