Stripe 的無程式碼代理程式建構器運作得太成功。它生出超過 4,000 個品質參差不齊的內部代理程式，而讓非工程師改用編碼代理程式的另一條路，又帶來沒人想承擔的安全曝險。Stripe 在由 AI 平台團隊與代理程式基礎團隊發布的工程文章中說明的答案，是把這片亂局收攏成一個名為 Kai 的平台。Kai 於 2026 年 4 月在內部上線，目前每週活躍使用率達 83%。
重點摘要
- Kai 把散落的 4,000 多個無程式碼代理程式整併成單一平台，接上超過 1,000 種內部工具與技能，上線兩週內就取得過半採用。
- Stripe 表示，業務代表在使用 Kai 的那幾週，成交件數比同一批人沒用的週次多出 39%，業務活動量則是兩倍。
- 這個平台每天處理超過 5,000 次分析工作階段，其中一次工作階段在沒有逾時、也沒有脈絡衰退的情況下跑到 932 輪。
為什麼知識工作需要另一套框架
編碼代理程式早已改變 Stripe 的工程組織，但該公司認為它們之所以有效，關鍵在環境：編譯器、測試與版本控制會給代理程式可驗證的回饋。業務、財務與法遵工作沒有這些。查詢資料倉儲、分派事故、建模營收情境、準備法遵審查，產出的東西無論對錯看起來都很合理。
因此 Kai 的設計賭注是：防護欄必須從頭打造，而不是繼承而來。平台分成三層。第一層是不綁定介面的 API，代理程式像一項服務，可以從內部網頁應用、嵌在第三方工具裡的 Chrome 擴充功能，或任何一支內部應用程式呼叫。第二層是 Agent Studio，GTM、財務、法務或資料科學的領域負責人不必向平台團隊開單，就能自行打造、監控調校過的代理程式並讀取品質指標。第三層是執行環境，裡頭放著沙箱、協作調度與存取控制。
第三層才是值得注意的架構選擇。Stripe 刻意讓代理程式框架、沙箱、工作流程協作調度與存取控制這些基本元件，和它出貨給客戶的代理程式共用，好讓內部工具與對外產品跑在同一套安全標準上，而不是兩套。框架本身建在 LangChain 的 deepagents 之上，跑在 Kubernetes 上，配有各工作階段獨立的沙箱與多租戶虛擬檔案系統。
唯一一條與權限無關的防護欄
Kai 強制執行一條一般授權機制表達不了的恆定條件：它禁止來自不相關客戶脈絡的資料被併進同一份分析，即使使用者本來就分別有權看到兩邊。存取控制回答的是某人能不能讀某一筆紀錄；這條規則回答的是兩筆紀錄能不能出現在同一個答案裡。對一家分析師本來就同時握有多家商家存取權的支付公司來說，這個區別很要緊。
生產力數字站得住腳嗎
Stripe 的主打數字出自自家統計，但衡量方式並不一致。最紮實的是同一名業務內部的比較：業務代表在使用 Kai 的週次，比同一批人沒用的週次多出兩倍業務活動量、17% 的新機會、26% 的營收機會與 39% 的成交件數。拿一個人跟自己比，避開了讓企業 AI 數字難以採信的多數選擇偏誤。
其他數字就弱了。同一群人裡重度使用者比輕度使用者多成交 80% 金額，屬於橫斷面切分，而高績效者本來就可能更快採用新工具，與成效無關。Stripe 還把每年 2 萬 5,000 小時從行政工作轉往創造營收的工作歸功於 Kai，並提到新進的 GTM 員工使用量是全公司平均的 2.7 倍——後者比較像習慣養成的訊號，而不是生產力。
後續觀察
官方列出的藍圖是狀態管理、讓 Kai 分析自身技能軌跡並把改進提案送交負責人審核的反思迴圈，以及跨工作階段與跨使用者的脈絡共享。Stripe 在文章結尾寫下「我們還沒贏」。這家公司今年在模型存取層一路買、一路做，包括數十億美元的 OpenRouter 收購案；Kai 是同一場賭注轉向內部的版本。
FAQ — 常見問題
Stripe 的 Kai 是什麼？
Kai 是 Stripe 為不寫程式的知識工作打造的內部 AI 代理程式平台，2026 年 4 月上線。它把業務、財務、法務等部門的員工接上超過 1,000 種內部工具與技能，可透過託管網頁應用、Chrome 擴充功能，或從任何內部應用程式呼叫 API 使用。
Stripe 的客戶用得到 Kai 嗎？
用不到。Kai 是給員工用的內部平台。它底層的代理程式框架、沙箱、工作流程協作調度與存取控制框架會和 Stripe 對外的代理程式共用，但 Kai 本身不是 Stripe 販售的產品。
單一個 Kai 工作階段能跑多久？
工作階段不會重設，而是在長時間互動中保留狀態。Stripe 提到近期有一次工作階段跑到 932 輪，處理了數百次工具呼叫與模型互動，期間沒有逾時，脈絡也沒有衰退。
