> ## Content Index
> Fetch the complete content index at: https://growthhackers.tw/llms.txt
> Use this file to discover other available public pages before exploring further.

# 企業 AI 治理怎麼做？Stripe 內部 AI 助理解碼：哪幾層用買的、哪幾層自己造，技能裝到 150 個就到頂
- URL: https://growthhackers.tw/blog/stripe-kai-agent-platform-governance/
- Published: 2026-08-07T13:00:00.000Z
- Updated: 2026-08-07T13:00:00.000Z
- Description: Stripe 自評 83% 員工每週在用內部 AI 助理 Kai，第一版一位工程師花一週做出來。但在那之前他們先搭出 4,000 個沒人管的小 agent。解碼買地基、造護欄的分層，以及技能超過 150 個就到頂的實測天花板。
- Author: Lewis wang
- Tags: AI agent, AI 治理, Agent Skills, LangChain, 企業 AI

先給你兩個數字，都是 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》](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents?ref=growthhackers.tw)）。

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

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》](https://stripe.dev/blog/meet-stripes-knowledge-ai-platform?ref=growthhackers.tw)）。

![左邊是散落各處、沒人維護的小 agent，右邊是有目錄可查的統一平台](https://growthhackers.tw/content/images/2026/08/inline-4000-agents-v2.png)

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

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

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

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

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

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

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

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

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

我把它翻成生意人的話。

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

但知識工作不是。

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

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

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

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

## 買地基，自己造護欄

那 Kai 那一週是怎麼來的？

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

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

具體買到什麼？三件：

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

那自己造什麼？

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

![Kai 的四層架構：Deep Agents 地基用買的，往上三層自己造](https://growthhackers.tw/content/images/2026/08/inline-buy-build-layers-v1.png)

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

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

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

想搞懂 harness 這層到底在管什麼，我之前寫過一篇 [Agent Harness 是什麼？擺脫 LangChain，像 Claude Code 一樣高效編排 AI](https://growthhackers.tw/blog/what-is-agent-harness/)，那篇把引擎那一層拆得比較細。

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

## 150 個技能，就是天花板

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

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

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

![技能數量越加越多，挑對技能的準確度反而在 150 之後開始下滑](https://growthhackers.tw/content/images/2026/08/inline-150-skills-ceiling-v1.png)

重點是什麼？

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

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

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

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

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

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

這件事我在 [為什麼你的 Agent Skills 越加越多、AI 卻越不聽話](https://growthhackers.tw/blog/writing-great-agent-skills/) 那篇從工藝面講過怎麼寫一個好技能。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 才是你的」是同一件事，我在 [這篇](https://growthhackers.tw/blog/jensen-huang-open-agent-proprietary-knowledge/) 展開過。但別一次餵全公司，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](https://www.langchain.com/blog/how-stripe-built-their-knowledge-ai-platform-on-deep-agents?ref=growthhackers.tw)，LangChain 官方部落格，作者 Sofia Sulikowski，2026 年 8 月 3 日。（請注意：Deep Agents 為 LangChain 自家開源產品，此文為該公司撰寫的客戶案例）
- [Meet Stripe's Knowledge AI Platform](https://stripe.dev/blog/meet-stripes-knowledge-ai-platform?ref=growthhackers.tw)，stripe.dev 官方部落格。（Stripe 自述）
- [Minions: Stripe's one-shot, end-to-end coding agents](https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents?ref=growthhackers.tw)，stripe.dev 官方部落格。
- 本篇的起點是中文 AI 解讀站「小互」在 2026 年 8 月 5 日發表的 [Stripe 公司內部 Agent 開發實踐](https://best.xiaohu.ai/article/stripe-kai-deep-agents/?ref=growthhackers.tw)。該文正文後段為付費內容，本文所有事實與數字均改以上述 LangChain 與 stripe.dev 一手來源查核後撰寫，未使用該文付費段內容。

**協作聲明與免責**

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

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