企業 AI 治理怎麼做？Stripe 內部 AI 助理解碼：哪幾層用買的、哪幾層自己造，技能裝到 150 個就到頂

先給你兩個數字，都是 Stripe 自己公布的。

83% 的 Stripe 員工，每週都在用一個叫 Kai 的內部 AI 助理。第一個能跑的版本，是一位工程師花一週做出來的。

這兩個數字現在正在各種投影片上飛。我猜你也看到了，而且你老闆很可能已經轉給你了。

但這篇要講的，是被這兩個數字蓋住的東西。

因為在那一週之前，Stripe 已經在同一件事上失敗過兩次，其中一次的規模是 4,000 個沒人管的小 agent。而在那一週之後，他們撞到一個很反直覺的牆：技能裝超過 150 個，前沿模型開始挑錯技能。

一週，是第七天。前面那幾年沒人拍照。

為什麼 Claude Code 救不了你的業務和財務

Stripe 的工程師早就有自己的 AI 幫手。他們自研的編程 agent 叫 Minions，每週合併掉一千多個 pull request（程式碼合併請求），程式碼從頭到尾由它寫，人只負責 review（資料來源：stripe.dev《Minions: Stripe's one-shot, end-to-end coding agents》）。

但公司裡更多的人不寫程式。業務、財務分析師、技術客戶經理。

Claude Code、Codex 這一波起來的時候，這些人被留在原地。想用，前面擋著三道門：終端機、資料權限、安全審批。

想像一下，你早上開會，行銷主管跟你說她想用 AI 幫忙跑上個月的檔期成效。你說好啊，公司有訂 Claude。她點開一看，要裝 CLI、要設環境變數、要申請 BigQuery 的讀取權限、要走一次資安表單。她填到第三格就放棄了，回去繼續手動貼 Excel。

不是她不想學。是這條路本來就不是為她鋪的。

Stripe 先踩的兩個坑，第一個是治理災難

這段是我覺得整個案例對台灣公司最有用的部分。

Stripe 在做出 Kai 之前，試過兩條路，兩條都不太行。

第一條路：無代碼 agent 搭建器。

讓每個人都能拖拉出一個專做某件事的小 agent，還能自己掛工具。聽起來很民主，很賦能。

結果搭出來 4,000 多個。

Stripe 自己在部落格裡寫得很誠實：問題不在數量，而是「各團隊寫出概念上相似、但品質參差的提示詞，這些微型 agent 大量增生之後，越來越難監控和維護」（原文出自 stripe.dev《Meet Stripe's Knowledge AI Platform》）。

你把這句話裡的「agent」換成「Excel」，就是台灣一堆公司過去十年的樣子。

每個部門都有自己那份神主牌報表，欄位定義都不太一樣，寫公式的那個人去年離職了，現在沒人敢動。

第二條路：直接叫非工程師去用編程 agent。

真的有人這樣幹了，而且為了遷就工具，把自己原本的工作流程改掉。

兩件事馬上冒出來。安全問題，還有：負責程式碼品質的團隊，突然要開始支援一群他們從來沒服務過的使用者。

這一點很少人講，但它才是真正的成本。你以為你只是開放了一個工具，實際上你是幫工程團隊憑空生出一個客服部門。

全文的軸：寫程式的形狀是固定的，知識工作不是

踩完這兩條路，Stripe 提煉出一個判斷。後面所有的設計都是從這句話長出來的，我認為它也是整篇最值錢的一句：

「對編程任務來說，每次改的東西不一樣，但完成任務所需的流程和工具大致相同。你改檔案、跑測試、提交。程式語言會變，但工作的形狀相當一致，這就是為什麼單一套 agent 架構能運作得很好。知識工作正好在光譜的另一端。」

我把它翻成生意人的話。

寫程式永遠是那個環：改檔案、跑測試、提交。Ruby 換成 Java，形狀還是那個形狀，所以一套架構通吃。

但知識工作不是。

研究一個客戶帳戶，跟準備一次合規審查，用的工具不一樣、資料不一樣、產出不一樣，連「什麼算做完了」的定義都不一樣。

再拉回台灣的現場。你們公司的客服在做的事、行銷在做的事、倉管在做的事，形狀根本不同。客服要的是照話術回覆、判斷要不要退；行銷要的是拉三個平台的數字做成一張老闆看得懂的圖；倉管要的是把安全庫存跟出貨排程對起來。

你拿同一套提示詞、同一份權限、同一個成功定義去套這三個人，當然套不上去。

這就是為什麼「我們找一套厲害的 AI 工具給全公司用」這句話，在工程部門成立，在其他部門通常不成立。

買地基，自己造護欄

那 Kai 那一週是怎麼來的？

答案是最難的那一層，他們用買的。

Kai 蓋在 LangChain 開源的 agent harness（代理編排框架）Deep Agents 上面。LangChain 官方部落格寫得很直白：Deep Agents 把工具呼叫迴圈、middleware 組合、串流、狀態管理這些「從零打造要花好幾個月才能穩定下來」的東西先接好了。

具體買到什麼？三件：

★ 虛擬檔案系統：Kai 是跑在雲端的正式服務，不是你電腦上的小程式。他們用 S3 撐起一套虛擬檔案系統，讓 agent 跨回合讀寫、引用檔案。 ★ 沙盒：跑 Python 查資料、畫圖、拆 PDF 和簡報，全在隔離環境裡。而且 agent 站在沙盒外面用呼叫的方式進去，不是自己住在裡面。 ★ 上下文壓縮：長對話會把記憶塞爆，這層負責摘要，閾值、摘要模型、輸出大小都能調來平衡成本。

那自己造什麼？

安全邊界、公司常識、權限分層。也就是那些只有你們公司才有的東西。

如果你問我，這跟開店的道理一模一樣。

沒有人會自己刻金流串接，你就是去接 91APP、接 Shopify、接綠界。沒有人自己蓋物流。但是，也沒有任何一家廠商能賣給你「你們家的退貨政策」。

你的檔期折扣級距怎麼抓、什麼樣的客訴要往上報、哪個供應商的到貨天數要抓多一週，這些東西沒有 SaaS 賣。這就是你自己得造的那一層護欄。

想搞懂 harness 這層到底在管什麼，我之前寫過一篇 Agent Harness 是什麼？擺脫 LangChain，像 Claude Code 一樣高效編排 AI，那篇把引擎那一層拆得比較細。

還有一個細節值得抄。Stripe 的技能庫走的是「聯邦制」：懂怎麼處理一筆計費升級、怎麼建營收模型的人，散在 GTM、財務、法務、資料科學幾十個領域，本來就不會坐在做 AI 基礎建設的那個團隊裡。所以技能由各團隊自己維護，業務營運的 Kai 跟財務的 Kai，預設裝的技能就不一樣。

150 個技能，就是天花板

Stripe 現在有 500 多個內部 MCP 工具、1,000 多個技能、來自 100 多個團隊。聽起來很威。

但 LangChain 官方部落格裡有這麼一句：在 frontmatter 有 1024 字元上限的條件下，團隊發現當技能超過 150 個、再加上他們的系統提示詞，前沿模型的品質就開始下降。

而且原文接著承認：技能數量仍然是一個挑戰，團隊還在找更好的解法。

重點是什麼？

不是模型不夠聰明。是你塞給它的選項太多，它挑錯了。

Stripe 現在的做法是兩段式：先讓模型判斷要載入哪些技能，技能再決定要載入哪些工具，而不是一次把所有工具攤開。另外把幾個基礎技能「釘死」，不管模型怎麼判斷都一定在。他們接下來要加的，是用 RAG 或分類器先做一輪預篩。

我知道你在想什麼：我們公司連 15 個技能都沒有，150 關我什麼事？

關係大了。因為 150 這個數字真正的意思是：你以為的擴充空間，比你想的小很多。

技能庫是會自己長大的。寫一個、抄一個、看到別人分享的順手又加一個，中間沒有任何一步感覺像在犯錯。等到某一天你打開那個資料夾，多半已經沒有人說得出裡面到底有什麼、哪幾個還在用。

問題從來不是總量嚇人，是模型每一次動作，都得先在這一堆東西裡面挑對那一個。

這件事我在 為什麼你的 Agent Skills 越加越多、AI 卻越不聽話 那篇從工藝面講過怎麼寫一個好技能。Stripe 這次給的是另一半：企業規模下的實測數字。

一個人的資料夾會亂，一家公司的技能庫只會更亂。

先把立場標清楚

在你把這篇當結論收走之前，先別急著拜。

這個案例的主線材料，是 LangChain 在寫自家客戶的成功案例，而 Deep Agents 正是 LangChain 的產品。補充材料是 Stripe 自己發的部落格。

兩邊都是球員兼裁判。

所以 83%、16 倍成長、行銷 95% 這些數字，全部是 Stripe 自評口徑，沒有第三方核驗。

Stripe 另外還宣稱業務端用了 Kai 之後成交數提升、每年挪出 25,000 小時從行政轉到創造營收的工作。這類數字我建議直接當廣告看，因為它沒有對照組，你不知道同期業績成長有多少是市場給的。

那還有什麼可以信？

我的判斷是：機制可信，成效打折。

「4,000 個 agent 難以維護」「超過 150 個技能品質下降」這兩件事對他們是自曝其短，講出來對自己沒好處。一個人講出對自己不利的話，那句話的可信度會高一點。

至於「一個工程師一週」，那是真的，但前提是 Stripe 花了十年蓋內部工具鏈與安全層，又為了這件事補做了一次 Python 原生的內部服務重建。你看到的一週，是那些投資的利息，不是本金。

台灣公司這個月就能動的四件事

切入重點。

► 第一：先數。你公司現在總共有幾個 AI agent 在跑？ 行銷開的 GPTs、客服接的 bot、營運串的 n8n 流程，全部列出來，寫上誰維護、上次更新是什麼時候。數不出來，你就已經在養第二個 4,000 了。這件事一個下午做得完，但九成的公司沒做過。

► 第二：做一張買造分界表，今天先填十格。 模型、harness、沙盒、資料連接器先歸「買」；權限、稽核、退貨規則、折扣邏輯、客訴升級規則先歸「自造」。每一格都要寫上 owner、現在用什麼工具、下一步做什麼。寫不出 owner 的那格，就不是策略，是願望。

► 第三：技能庫上線第一天就設淘汰機制。 每個技能都要有主人、有上次更新日期，三個月沒被叫到就進待審清單。Stripe 在 150 撞牆，你只會更早撞。

► 第四：把專家知識的所有權還給專家，而且先做一個部門就好。 退貨規則讓客服主管維護，檔期折扣邏輯讓行銷主管維護。以前這些東西要靠一份沒人敢改的 Excel 和一位不能離職的資深員工撐著；現在它可以是一份有主人、有版號、AI 讀得懂的技能包。這跟黃仁勳講的「模型是租來的，know-how 才是你的」是同一件事，我在 這篇 展開過。但別一次餵全公司，Stripe 也是先做給業務跟財務。

最後

這一整個案例，如果只能留一句，我會留這句：

寫程式的形狀是固定的，知識工作不是。

所以別再問「哪一套 AI 工具比較強」。

先問你自己：哪幾層不歸我做，哪幾層只有我能做，以及我打算怎麼防止第二個 4,000 出現。

常見問題

Q：企業要自建內部 AI 平台，哪幾層該用買的、哪幾層得自己造？ A：依 Stripe 的分層，通用的 agent 基礎建設用買的：工具呼叫迴圈、虛擬檔案系統、沙盒執行環境、上下文壓縮。這幾層跟你的產業無關，自己造只是重造輪子。自己造的是「只有你們公司才有」的那層：安全邊界與權限分層、內部系統與資料的接法、以及各部門的判斷規則與作業常識。

Q：Agent Skills 裝太多會怎樣？有沒有上限？ A：有。LangChain 官方部落格記載，Stripe 團隊在 frontmatter 1024 字元上限的條件下，發現技能超過 150 個再加上系統提示詞，前沿模型的品質開始下降，也就是開始挑錯技能。要注意這是 Stripe 在自家系統提示詞條件下的實測，不是所有模型的通則。實務上的解法是兩段式載入（先選技能、技能再帶出工具）、把基礎技能釘死，以及替技能庫設淘汰機制。

Q：為什麼給工程師的 AI 工具不能直接給業務和財務用？ A：兩個原因。第一是門檻，終端機、資料權限、安全審批這三道門會直接把非工程師擋在外面。第二是形狀，編程任務的流程高度一致（改檔案、跑測試、提交），一套架構能通吃；知識工作每個任務用的工具、資料、產出、完成定義都不同，套不上去。Stripe 實際試過把編程 agent 開放給非工程師，結果是資安風險加上工程團隊憑空多出一群要支援的使用者。

Q：公司裡已經長出一堆沒人管的小 agent，該怎麼收拾？ A：Stripe 用無代碼搭建器長出 4,000 多個微型 agent，他們的結論是問題不在數量，而在概念相似但品質參差的提示詞四散各處，監控與維護跟不上。收拾的順序是：先盤點（列出全部、標上維護者與最後更新日）、再收斂（把重複的合併成一份有主人的技能）、最後才談平台。跳過盤點直接蓋平台，你只會多一個沒人用的平台。

Q：Deep Agents 是什麼？跟 LangChain、跟 agent harness 什麼關係？ A：Deep Agents 是 LangChain 開源的 agent harness，也就是「模型以外的那一整套」：工具呼叫迴圈、middleware 組合、串流、狀態管理。Stripe 的 Kai 就蓋在它上面，再往上疊自己的安全與基礎設施層、設定層、以及使用者介面。簡單分工：harness 管 agent 怎麼跑、MCP 管資料從哪來、skill 管事情照什麼流程做。

資料來源

• How Stripe Built Kai, its Company-Wide AI Agent, on Deep Agents，LangChain 官方部落格，作者 Sofia Sulikowski，2026 年 8 月 3 日。（請注意：Deep Agents 為 LangChain 自家開源產品，此文為該公司撰寫的客戶案例）
• Meet Stripe's Knowledge AI Platform，stripe.dev 官方部落格。（Stripe 自述）
• Minions: Stripe's one-shot, end-to-end coding agents，stripe.dev 官方部落格。
• 本篇的起點是中文 AI 解讀站「小互」在 2026 年 8 月 5 日發表的 Stripe 公司內部 Agent 開發實踐。該文正文後段為付費內容，本文所有事實與數字均改以上述 LangChain 與 stripe.dev 一手來源查核後撰寫，未使用該文付費段內容。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。