編寫程式碼的 Agent 改變了 Stripe 的工程工作方式，但對於銷售代表、財務分析師、技術客戶經理等非工程師來說，他們感覺自己沒有跟上 Claude Code 和 Codex 帶起的這波 AI 浪潮。現有的工具都無法滿足 Stripe 在資料安全要求和特定工作流程上的需求：查詢資料倉儲、在銷售通話前研究客戶帳戶、事件分流、建立營收情境模型，或是準備合規審查。這一切在我們推出 Stripe 的知識 AI Agent 之後徹底改變。
GIF
在我們四月推出後的兩週內，Stripe 大部分員工都開始使用 Stripe 的知識 AI 平台，也就是 Kai。如今，83% 的員工是每週活躍使用者，其中包括幾乎所有的 GTM（行銷、銷售、客戶成功經理和技術客戶經理）。大多數 Kai 工作階段都需要多個回合，使用者會進行深入研究、建立特定的產出物，或在分享給內外部之前持續優化成果。有了 Kai，Stripe 的每位員工都擁有一個專門為協助他們日常工作而打造的 Agent。
為什麼我們打造知識 AI 平台
對於編寫程式碼的任務，具體的變更內容各不相同，但執行任務所需的工作流程和工具大致相同。你編輯檔案、執行測試、提交。程式語言各不相同，但工作的形態相當一致，這就是為什麼單一 Agent 架構就能運作得很好。知識工作則位於這個光譜的另一端。像是研究客戶帳戶或準備合規審查這類任務，需要不同的工具、不同的資料、不同的輸出，以及對「完成」的不同定義。
在 Kai 之前，我們有兩種用於知識工作的 AI 選項：
- NoCode Agent Builder：任何人都能建立和部署可使用工具、針對特定工作流程的 Agent。透過這套系統建置了超過 4,000 個 Agent。然而，我們很快注意到，團隊撰寫的提示詞在概念上很類似，但品質參差不齊，而且這些微型 Agent 的大量增生也越來越難以監控和維護。
- 編寫程式碼的 Agent：這類 Agent 功能強大，但也帶來另一組風險。由於我們的目標是提升所有 Stripe 員工的生產力，有些使用者改變了工作流程，選擇使用編寫程式碼的 Agent。然而，安全疑慮很快浮現，同時也為程式碼品質團隊帶來了全新的支援負擔——這個團隊過去從未支援過非工程師。
從這些經驗中，我們體會到打造知識 AI 平台必須做好三件事：在不集中化的情況下擴展專業知識、在使用者工作的任何地方滿足他們的需求，以及落實程式碼世界中不存在的安全護欄。
在不集中化的情況下擴展專業知識
要服務 Stripe 使用者所需的專業知識範圍非常驚人。知道如何處理帳單升級案件分流或建立營收情境模型的人，並非集中在某處，當然也不在打造 Agent 基礎架構的團隊裡。他們分散在數十個專業領域——GTM、財務、行銷、法務、資料科學等等——每個領域都有自己的工具、資料來源、工作流程，以及對「什麼是好的結果」的判斷標準。再把 Stripe 營運的所有產品和國家乘上去，結果就是極度複雜。Kai 必須將這種複雜性建模，讓使用者察覺不到它的存在，讓任務自然而然就完成。
Agent 必須無所不在
Agent 出現在哪裡，與它知道什麼同樣重要。不是每個人都會在瀏覽器分頁中工作，會在終端機中工作的人更少。因此，知識 Agent 不能只是一個單一產品，它必須是一個平台，具備足夠的靈活性，能嵌入到任何工作發生的地方。
舉例來說，我們的財務團隊使用一個內部應用程式來模擬 Stripe 營運預算的複雜變更：Agent 需要讀取上下文、研究相關文件、提出有效的變更，並總結差異，而且全程不能把使用者帶離這個應用程式。
打造一個獨立的 Agent 產品行不通。這樣做會迫使使用者離開他們熟悉的工作流程，改用一個全新的應用程式。為每個介面分別打造 Agent 產品同樣行不通；這會難以維護，而且使用多種工具的使用者會獲得很破碎的體驗。平台必須在使用者所在之處滿足他們。
從零打造安全護欄
編寫程式碼的 Agent 運作的環境中，有數十年累積下來既快速又可驗證的安全護欄：編譯器會拒絕無效語法，測試會捕捉回歸錯誤，git 讓每個錯誤都能被復原。知識工作則幾乎沒有這類機制的支援。
以 Stripe 的核心不變原則為例：「你不應該在單一分析中合併兩個不相關客戶情境的資料。」使用者可能對兩個情境都擁有合法的存取權，但它們絕不能出現在同一個工作階段中。隔離的邊界不是「這個人能憑他的授權 token 存取什麼？」，而是「基於這個情境，這個任務應該被允許查看什麼？」。平台必須落實這些使用者依賴的隱性安全護欄。
我們如何打造 Kai
單一巨石架構的 Agent 根本無法有效地把所有這些限制都編碼進去。而要求每個領域團隊各自獨立打造安全、代管、高效能的 Agent 基礎架構，也無法規模化。為了應對這個挑戰，我們用三個層級來打造 Kai：
- 與介面無關的 API（Surface-agnostic APIs）：為同一個 Agent 提供多種介面
- AgentStudio：讓領域擁有者建置和管理自己的 Kai Agent
- 執行環境（Execution environments）：在幾秒內完成安全交付，無需任何人操心基礎架構
與介面無關的 API
Kai 隨附一個具明確設計觀點的網頁應用程式和 Slack 整合，但最主要的基礎元件是驅動這兩者的底層 API。Agent 是一項服務，而不是應用程式，介面只是進入這個服務的客製化視圖。
大多數 Stripe 員工透過內部代管的網頁應用程式與 Kai 互動。不需要設定任何基礎架構——從第 0 天起，每位員工就能使用。
任何內部工具也都能嵌入 Kai，而且許多工具已經這麼做了。舉例來說，在我們的商業智慧平台工作的員工，可以直接在他們既有的應用程式中向 Kai 提問，因為我們的 Chrome 擴充功能會把 Kai 的能力帶入網頁版的第三方工具。
客製化應用程式透過 API 嵌入 Kai，將 Agent 體驗帶入所有工作流程
AgentStudio
AgentStudio 是領域擁有者的控制平面。團隊用它來建置、測試和監控他們的技能、客製化 Kai Agent，以及工具選擇。例如，GTM 團隊擁有一個針對他們的工作流程調校的 Kai Agent。它預設載入團隊的技能、連接他們的資料來源，並以使用者期望的格式呈現輸出。AgentStudio 會在每個資產旁邊顯示使用數據和品質訊號，讓領域擁有者無需詢問平台團隊就能看出哪些做法有效。
技能會依 Stripe 內部的領域分類組織，並由領域專家管理
執行環境
這個層級讓平台的承諾得以實現。核心基礎元件，包括 Agent harness、沙盒（sandbox）、工作流程編排和存取控制框架，都刻意與 Stripe 面向產品的 Agent 共享。內部知識工作處理的是與外部產品相同的敏感資料，服務的也是相同的使用者，因此需要同樣等級的安全和合規標準。共享這個基礎層能強制要求紀律，並形成一個飛輪效應：執行環境的改進會同時嘉惠內部 Agent 和產品 Agent。
這個 Agent harness 使用 LangChain 的 deepagents 建置，運行在 Kubernetes 上，具備每個工作階段獨立的安全沙盒，以及多租戶虛擬檔案系統。在一個工作階段中，Agent 使用虛擬檔案系統來建立產出物並反覆迭代，同時使用安全的程式碼執行沙盒來進行分析和資料處理。
它的設計目標是在長時間、複雜的工作階段中維持狀態——最近有一個工作階段達到了 932 個回合。憑藉 Kai 深層的任務管理能力，單一對話可以包含數百個回合，以及數百次工具和 LLM 呼叫，而且不會逾時或讓上下文視窗超載。這很重要，因為知識工作很少只是一次性提問。它是不斷自我累積的迭代推理，而工作階段必須在品質不衰減的情況下持續維持這個狀態。
使用者行為正在改變，工作階段越來越常用於深入的多回合協作
harness 最有趣的部分之一，是它如何選擇要使用的正確技能。Kai 連接了 1,000 多個技能和工具，涵蓋各種內部系統——從追蹤關鍵指標的商業智慧儀表板，到組織內部執行的專案管理工具，以及 Zoom 和 Google Workspace 等第三方服務。任何人都可以向它提問，並相信它會載入正確的上下文、使用正確的工具來完成任務。編寫程式碼的 Agent 在這裡有天然優勢：它們工作的資料夾本身就為技能和上下文提供了自然的組織方式。在後續的文章中，我們會深入探討如何在沒有這種既有結構的情況下解決這個問題，其中包括採用混合 RAG/LLM 方法等技術。
影響與成果
成果相當驚人。GTM 的新進員工是 Kai 的原生使用者，使用量多出 2.7 倍；而在同一批新進員工中，重度使用者成交的價值比低度使用者高出 80%。當客戶經理（Account Executive）使用 Kai 時，與同一批銷售人員在沒有使用 Kai 的週數相比，他們產生的銷售活動量是 2 倍、創造的機會多 17%、產生的營收機會多 26%、成交的交易多 39%。整體而言，Kai 每年幫助將 25,000 小時從行政工作轉移到創造營收的工作。
在財務和營運領域，Kai 正在幫助 Stripe 員工分析雜亂的資料、產生定期彙整摘要，並將零散的上下文轉換為可用的產出物。
在工程領域，Kai 現在已經成為一個自然的起點，可以用來詢問系統問題、研究執行請求（run requests）、分析日誌、草擬計畫，以及呼叫更專業的 Agent 和技能。
而在整個 Stripe，每天有超過 5,000 個工作階段以資料分析為核心。這讓 Kai 成為一個獨特的槓桿點：只要注入關於資料品質和我們分析層的正確上下文，我們就能確保大多數問題在預設情況下得到正確的回應。
Stripe 員工的直接回饋也印證了這些統計數據：他們表示自己感覺「更有能力擁抱 AI」，而且「對 Kai 就是能精準做對感到驚嘆」。但我們最喜歡的故事是，有一位非工程師在參加完 Kai 的介紹說明會後，立刻著手協作建立一份彙整摘要，把 Asana、Slack 和 Jira 整合成一個自動化流程。
我們還沒贏
在 Stripe，我們最喜歡的口號之一是「我們還沒贏」，這句話也很適合用來形容 Kai。我們正處於這段旅程的最早期階段，還有更多事情想完成：
- 更好的狀態管理：像 Kai 這類通用型 Agent 在反覆進行工具呼叫、下載大型文件等過程中會產生大量狀態。我們持續調校兩部分：傳送給 LLM 的「作用中」上下文，以及存放在 S3 或虛擬檔案系統等狀態儲存中的「延伸」上下文。
- 反思與自我改進：我們正在打造一個品質改善迴圈，讓 Kai 能反思涉及某個技能的軌跡、提出改進建議、進行測試，並提交變更供技能擁有者審查。
- 更好的協作基礎元件：使用者在 Kai 工作階段中產生了大量目前「鎖在工作階段裡」的上下文，但這不是完成工作的正確方式。我們想讓使用者能夠跨工作階段分享 Kai 產出的內容，並讓多個人（以及多個 Agent！）能在同一份產出物上協作。
編寫程式碼的 Agent 最先讓 AI 對軟體工程師來說變得具體可感。Kai 則把同樣的槓桿感帶給了 Stripe 各地的知識工作者。有趣的是，雖然我們已經大幅提升了生產力，但我們還不知道天花板在哪裡——而我們很興奮能繼續突破極限。如果你覺得打造能驅動內部生產力和外部 Agent 的 Agent 系統，正是你想挑戰的事，我們正在招募。
