智能體堆棧的賭注

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 智能體需要平台

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

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

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

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

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

五年展望

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

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

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

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