YC 首度公開內部 AI 架構：一個資料庫、350 個工具、自己會進化的技能系統

本文整理自 Y Combinator Lightcone Podcast 2026 年 5 月播出的單集。

{{< youtube B246K_G7mHU >}}

---

從財務團隊的痛點開始

Y Combinator 從創立以來就用自家開發的軟體運作，公司資料、創辦人資料、財務紀錄全部都跑在自己的系統上。但直到大約一年前，YC 合夥人 Pete Koomen（Optimizely 共同創辦人）和幾位工程師坐下來跟財務團隊開會時，才意識到一個根本性的問題：軟體工程師和領域專家之間的溝通迴圈，效率低得離譜。

流程是這樣的。財務團隊描述一套複雜的工作流程，比如怎麼記帳、怎麼登錄一輪新的定價融資。工程師聽完之後，把這些邏輯寫成確定性的 Ruby 程式碼，然後交回給財務團隊使用。財務再回饋哪裡不對、工程師再改，如此反覆。Pete 在節目中形容這個過程「效率極低」，因為工程師得先搞懂每一條財務規則，才能把它翻譯成程式碼。而財務人員明明最懂這些規則，卻沒有能力自己定義軟體的行為。

同一時間，Pete 自己在家裡的體驗完全不同。Cursor、Windsurf、剛推出的 Claude Code，這些程式碼 Agent 工具讓他覺得自己有了超能力。工作時被困在傳統的開發流程裡，回家卻用 AI 飛速解決問題，這個落差越來越大，最後變成了行動的契機：為什麼不讓財務團隊直接用英文 prompt 來定義自己的工作流程，而不是透過工程師翻譯成 Ruby？

這就是 YC 內部 AI Agent 基礎設施的起點。不是什麼宏大的策略規劃，而是一個很具體的痛點觸發的專案。Jared Friedman（YC 合夥人、Scribd 共同創辦人）在節目中說，YC 一邊輔導 AI 新創公司，一邊自己經歷同樣的轉型。他形容這是一種「強大的共生關係」，而這集 Podcast 也是 YC 第一次公開談論這套內部系統。

深夜偷推的 SQL 工具，改變了一切

Pete 和團隊先是為財務部門做了一個專用的 Agent，然後重寫成更通用的架構：一個 Agent 迴圈加上一個工具註冊表。但真正讓整個系統起飛的轉折點，是 Jared Friedman 做的一件事。

Jared 做了兩個工具。第一個讓 Agent 可以對 YC 的 Postgres 資料庫執行唯讀 SQL 查詢，第二個讓 Agent 可以讀取資料庫的 model 檔案，了解 schema 結構。聽起來很簡單，但 Jared 自己承認，他推上線的時候覺得自己在「犯規」。因為這意味著給 Agent 不受限制地存取整個生產資料庫，而不是像之前那樣只開放特定範圍的資料。他選在深夜偷偷把功能推上線，因為走正式流程的話，很可能會被各種安全顧慮擋下來。

結果呢？Jared 回憶說，「效果好得不可思議。」他後來意識到，這個經驗預示了 OpenClaw 等工具後來的成功模式：阻礙 AI 發揮全部潛力的，往往不是技術限制，而是我們對安全和隱私的過度擔憂。當你稍微放鬆這些限制，AI 的能力會讓人吃驚。Pete 補充了一個觀察：這又是「工作 vs 家裡」落差的例子。在公司被限制在狹窄的框框裡，回家用 Claude Code 或 OpenClaw 卻可以做任何事。他們一直在做的，就是試著縮小這個差距。

一個 Postgres 資料庫的結構性優勢

為什麼一個看似簡單的 SQL 查詢工具能產生這麼大的影響？答案在於 YC 的獨特結構優勢：所有重要資料都存在同一個 Postgres 資料庫裡。

公司表、創辦人表、財務交易紀錄、內部 CRM 筆記、活動管理紀錄，全部在同一個 schema 下。多數公司會把 CRM 外包給 Salesforce，把財務交給 QuickBooks，活動管理用 Eventbrite。但 YC 全都自己做，而這個看似偶然的歷史選擇，在 AI 時代變成了巨大的結構性優勢。Agent 可以跨部門回答任意問題，不需要串接七八個不同的 API。

Pete 舉了一個例子：「請列出過去四個梯次中，投資了太空相關公司的所有投資人。」這個問題橫跨公司資料、投資人資料、產業標籤三個領域。以前要回答它，得找資料團隊寫幾個小時的 SQL 查詢。現在 Agent 可以直接搞定，因為所有脈絡都在同一個地方，加上一點 schema 說明就夠了。Pete 類比說，就像程式碼 Agent 在 monorepo 裡工作效率遠高於在分散的多個 repo 裡，Agent 在統一的 schema 上運作效果也好得多。

Jared 指出了一個更深層的效應：這個工具不只是讓回答問題變快，它大幅增加了人們「敢問」的問題數量和複雜度。以前用 BI 工具查一個複雜問題要好幾個小時，如果不是非常重要，根本不會有人費這個勁。現在門檻消失了，問題像雪崩一樣湧出來。Pete 用經濟學的「傑文斯悖論」來形容這個現象：當你移除資訊取得的摩擦力，需求不是等比例增加，而是爆炸性成長。Garry Tan（YC 執行長）則從另一個角度切入。他認為這就像當年 Google 用 BigTable 把資料反正規化，讓 MapReduce 可以高效處理一樣。現在 AI Agent 也需要類似的「反正規化」，把分散在各處的企業資料整合成 Agent 容易理解和檢索的格式。他自己開發的 G-Brain 系統就在做這件事，裡面整合了 RAG、Graph RAG、RRF 重排序等檢索技術。

從 20 到 350+：共享工具註冊表的力量

SQL 工具只是開始。接下來的一年裡，YC 的工具註冊表從最初的 20 個工具，成長到超過 350 個。

每個團隊都在往註冊表裡加入自己的工具。財務團隊加了記帳、過帳相關的工具；合夥人加了管理面談時段的工具；活動團隊加了活動管理工具。所有重要的 YC 日常業務，現在都有對應的 Agent 工具。而且這些工具不只是內部 Agent 可以用，連個人電腦上跑的 Claude Code 也能呼叫同一套工具。這代表任何一位 YC 員工在自己的終端機裡，就能操作整個組織的工具庫。

Pete 認為這是他們做對的最關鍵的事之一。他觀察到，目前市面上的 Agent 框架，不管是 Claude Code、Codex、OpenClaw 還是 Hermes，都還是為「單人操作」設計的。一個人在一台機器上可以做任何事，但當你要把同樣的超能力擴展到整個團隊、整個組織時，沒有人真正做得好。他把目前的狀態稱為「Agent 的單人玩家時代」，而「多人玩家」問題才是下一個真正需要被解決的難題。

要跨過這個鴻溝，YC 找到了兩個核心原語：一個統一的資料脈絡層（就是那個單一的 Postgres 資料庫），以及一個所有人都能存取的共享工具註冊表。這兩樣東西加在一起，讓通用的 Agent 變成了懂 YC 業務的 Agent。Garry Tan 從他在 OpenClaw 的經驗補充了「技能」（skill）的概念，認為技能是工具之上的抽象層。管理技能庫的關鍵是兩個原則：DRY（Don't Repeat Yourself，不要重複自己）和 MECE（Mutually Exclusive, Collectively Exhaustive，互斥且完全窮盡）。他在 OpenClaw 裡做了一個叫「Skillify」的元技能，能自動把新動作封裝成可重複呼叫的技能，再跑一次檢查確保新技能和既有的不重複。Garry 感嘆，同樣的原語正在 Claude Code、OpenClaw、YC 內部系統裡被獨立發現，就像當年 Unix 開發者同時發現 stack 和 heap 一樣。

夢境循環：每晚自動進化的技能系統

工具註冊表解決了「Agent 能做什麼」的問題，但 YC 還走了更遠一步：讓技能自動變得更好。

Pete 描述了一個每晚執行的自動化流程。一個通用型 Agent 會閱讀當天所有員工與 Agent 的對話紀錄，找出哪些地方可以做得更好，哪些脈絡如果事先提供，Agent 就能更有效率。然後它會自動提出技能改進建議。Garry Tan 把這稱為「夢境循環」（dream cycle），因為它就像系統在睡覺時消化白天的經驗，隔天醒來就變得更聰明。類似的模式也出現在 OpenClaw、G-Brain，甚至 Codex 的 /goal 功能裡，以及 Andrej Karpathy 提出的「自動研究」概念中，這顯示它正在收斂成一個 Agent 架構的基礎原語。

一個具體的例子，可以說明這套循環實際上怎麼運作。YC 有一個「兩句話簡報」技能，每家公司都需要用兩句話說清楚自己在做什麼，以及為什麼值得關注。Garry 解釋，第一句回答的是「這到底是什麼東西」，第二句回答的是「為什麼值得我花時間」。聽起來簡單，但連最有經驗的創辦人都常常說不好，因為他們對自己的公司太熟悉了，反而很難用外人聽得懂的方式表達。

合夥人 Tom 最初寫了一個手工 prompt，教 Agent 怎麼把公司資訊濃縮成兩句話。這個技能被廣泛使用後，其他合夥人做了一件更有意思的事。他們辦了一場春季梯次的團體面談，讓創辦人輪流練習兩句話簡報，合夥人即時給回饋。然後他們把整場會議的逐字稿餵給 Agent，告訴它：根據你從這份對話中學到的東西，改進這個技能。

Pete 說結果令人驚訝，改進後的技能寫出來的兩句話簡報，比他自己寫的還好。Garry 認為這就是「組織級超級智慧」的具體運作機制。不是什麼魔法，就是把組織在做的每一件事，都經過「撰寫 prompt、使用、產生紀錄、自動改進」這個循環。每經過一輪，技能就多整合了幾位合夥人的判斷和經驗，最終超越任何一個個人。他提到 Jack Dorsey 在 Block 也在用同樣的方法，試圖把整間公司變成一個專注支付領域的「迷你 AGI」，而任何看到這集節目的人，都可以在自己的公司套用同樣的做法。

我的觀察：這不只是矽谷的遊戲

YC 的做法有一個明顯的先天優勢：他們從一開始就用自家軟體，所有資料都在同一個地方。多數企業沒有這個條件，光是把散落在十幾個 SaaS 工具裡的資料整合起來，就是一項大工程。

但 Pete 在節目尾聲提出了一個任何組織都能參考的起步方向。第一，把盡可能多的內部脈絡整合進同一個資料倉儲或資料庫，就算做不到完美的單一 schema，至少讓 Agent 能在一個地方找到大部分它需要的脈絡。第二，建立一個內部工具註冊表，讓組織內的 Agent 和員工個人的程式碼工具（比如 Claude Code）都能取用。第三，開始記錄所有的會議和工作紀錄，把逐字稿回饋到技能改進循環裡。

這三件事不需要從零自建整套系統。現在的 Claude Code、Cursor、各種 MCP 工具已經提供了足夠的基礎建設。真正的挑戰其實在組織文化：你願不願意把資料打通？願不願意讓 Agent 有足夠的存取權限？願不願意讓同事看到你怎麼使用 Agent？YC 的經驗很清楚地顯示，技術門檻正在快速降低，但多數企業最難跨越的那道坎，是信任和開放。後面那篇文章會更深入談到這個問題。