YC 怎麼把 AI 變成組織共享大腦：從 20 個工具長到 350 個
Y Combinator 合夥人 Pete Koomen 分享 YC 內部如何從零打造 AI agent 基礎設施。從給 agent 開放生產資料庫開始，一年半內建起超過 350 個內部工具，讓非技術人員也能用自然語言編碼自己的工作流程。
本文整理自 Lightcone Podcast 2026 年 5 月播出的單集。
{{< youtube B246K_G7mHU >}}
打開資料庫那一晚
大約一年半前，YC 合夥人 Jared Friedman 做了一件他自己形容為「有點違規」的事。當時 YC 內部剛開始建造自己的 AI agent 系統，最初的工具功能很有限，只能處理特定範圍的任務。Jared 越用越不耐煩，覺得這些窄範圍的工具根本不夠力。某天深夜，他悄悄推上了兩個新工具：一個讓 agent 可以對 YC 的生產用 Postgres 資料庫跑唯讀 SQL 查詢，另一個讓 agent 能讀取資料庫的 model 檔案。
結果好到所有人都意外。YC 跟大多數公司不同，從成立以來就跑在自己寫的軟體上，所有重要資料都存在同一個 Postgres 資料庫裡。公司資料、創辦人資料、財務交易、內部 CRM 筆記，全部在同一個地方。當 agent 拿到這個資料庫的讀取權限，突然之間，任何人都可以問出極其複雜的商業問題。「給我看過去四個批次裡，所有投資過太空相關公司的投資人」，這種以前需要資料科學團隊花好幾個小時寫 SQL 才能回答的問題，現在直接問 agent 就好。
Optimizely 共同創辦人、現任 YC 合夥人的 Pete Koomen 指出，這件事的意義不只是「回答問題變快了」。更根本的改變在於人們問問題的意願。以前要問一個複雜的商業問題，得排進資料科學團隊的待辦清單裡等，大部分人想想就算了。當這個障礙消失，問題的數量和複雜度都爆炸性成長。典型的傑文斯悖論（Jevons Paradox）：使用成本降低時，使用量不是等比例增加，而是指數級增加。
一個資料庫的威力
這個突破背後有一個關鍵前提：YC 的所有資料都在同一個地方。Pete Koomen 認為，這是 YC 在 AI 轉型上的最大優勢。很多公司把不同功能分散在各種第三方 SaaS 工具裡，CRM 用 Salesforce、專案管理用 Asana、財務用 QuickBooks，資料散落在十幾個系統中。但 YC 因為從頭到尾都用自己的軟體，所有資料天然就在同一個 schema 底下。
Garry Tan（Y Combinator 執行長）把這個概念類比為 Google 早年的 Bigtable。當年 Google 工程師意識到，與其讓資料分散在各種有 schema 和 join 的傳統關聯式資料庫裡，不如放進一張大表來做 MapReduce 運算。現在同樣的事正在 AI 時代重演：你需要把組織的資料「去正規化」（denormalize），轉成一種對 agent 來說最容易檢索和理解的格式。這不一定是把所有東西塞進一個 MCP，而是真的把資料整理成 agent 友善的結構，搭配 RAG、GraphRAG、混合式重新排序等檢索技術。
對於那些資料分散在各處的公司，Pete Koomen 的建議很直接：先建一個內部資料倉儲，盡可能把重要的內部脈絡集中到一個地方。他觀察到，就像 coding agent 在單一程式碼庫裡的效率遠高於跨多個 repo 工作，YC 的 agent 在單一資料庫上運作的效果，也遠比讓它們去串接各種外部工具來得好。
工具註冊表：從 20 到 350+
YC 的 agent 系統架構本身很簡單：一個 agent 迴圈、一個共用的工具註冊表（tool registry）、底下一個模型路由器。核心的差異化不在架構，而在工具註冊表裡不斷累積的 YC 專屬工具。
一開始只有大約 20 個工具，包括那個改變一切的 SQL 查詢工具。但隨著各團隊開始發現 agent 的潛力，工具數量快速膨脹。Pete Koomen 最近一查，已經超過 350 個。財務團隊加了記帳和登錄定價輪次的工具，活動團隊加了管理活動的工具，合夥人可以用工具管理 office hours。每個團隊都在往這個註冊表裡加自己的工具，而一旦工具進了註冊表，所有 agent 都能用。整個組織都從單一團隊的貢獻中受益。
而且，這個工具註冊表不只服務 YC 內部的 agent 系統，也能接入跑在個人機器上的 Claude Code。同一套工具，既能在組織層級的 agent 裡使用，也能在個人的 coding agent 裡呼叫。Pete Koomen 認為，對任何想推動 AI 轉型的組織來說，最該優先建立的就是這兩樣東西：一個集中的資料脈絡層，以及一個共用的內部工具註冊表。
Garry Tan 從自己使用 OpenClaw 的經驗出發，補充了一個關鍵概念：工具註冊表需要一個「解析器」（resolver），類似 Claude Code 的技能註冊表或 agents.md 裡的工具清單。他還會定期跑一個叫「check resolvable」的元技能，確保所有工具符合 DRY 原則（不重複）和 MECE 原則（互斥且窮盡）。十個功能重疊的工具不如一個有參數的好工具。這聽起來像是管理顧問的方法論，但套用在 agent 工具管理上效果出奇地好。
讓 Agent 自己變聰明
工具和資料到位之後，YC 開始進入下一個階段：自我改進迴圈（self-improving loops）。
Pete Koomen 描述了一個每天晚上自動執行的 agent。它會讀取當天所有員工和 agent 的對話紀錄，找出哪些地方可以做得更好、哪些脈絡如果事先提供就能更有效率。然後自動改進相關的技能。Garry Tan 把這個叫做「dream cycle」（夢境循環），靈感來自 Andrej Karpathy 提出的自動研究概念，OpenAI 的 Codex 也把類似的功能做進了 /goal 指令裡。
一個具體的案例是 YC 的「兩句話描述」技能。這是 YC 合夥人的核心工作之一：幫創辦人用兩句話講清楚公司做什麼、為什麼值得關注。聽起來簡單，但連最有經驗的創辦人都經常做不好，因為他們對自己的產品有完整脈絡，很難站在外人的角度去解釋。
合夥人 Tom 最初寫了一個 prompt，教 agent 怎麼把公司資訊濃縮成兩句話。這是起點。接著，幾位合夥人帶了一群新批次的創辦人做集體練習，逐一給予反饋。這場練習的完整逐字稿被餵回給 agent，讓它根據合夥人在真實互動中展現的判斷和偏好來改進技能。改進後效果明顯提升。Pete Koomen 直言：這個技能現在寫出來的品質，已經超過他自己能做到的水準。
Garry Tan 認為這就是「組織內超級智慧」的微觀機制。一個人寫了 prompt，多人使用並產生互動紀錄，紀錄被用來自動改進 prompt，改進後又被更多人使用。每一個這樣的迴圈，都讓這項技能超越了任何單一個人的能力。把這個過程應用到組織裡的每一項工作上，就是超級組織。他在節目中直接說：「每一個看這個節目的人，都可以在任何公司做到這件事。不比這更複雜了。」