2026 年 7 月 31 日，Y Combinator 把一套自己天天在用的東西丟上 GitHub。不是示範專案，是他們拿來跑會計、法務、活動和工程的那一套。
一句話結論：YC QM 是一套開源（MIT）的「全公司共用」AI agent 系統，每個員工有獨立記憶與沙盒、又能在 Slack 頻道一起用；適合已經被十幾個各自為政的 AI 助理搞到失控的團隊，個人用戶用不上。
資料截至 2026 年 8 月。QM 是很新的專案，功能和指令都可能改，動手前請以 GitHub 上的 README 為準。
YC QM 到底是什麼？
QM 是一個「多人 agent 載體」（multiplayer agent harness）。用白話講：它不是又一個聊天機器人，而是一層讓一整間公司共用 AI agent 的底座。
名字取自 quartermaster——船上負責管理艙底、讓所有東西各就各位的人。這個命名其實已經說完了它想解決的問題：不是讓 AI 更聰明，是讓一堆 AI 不要打架。
幾個關鍵設定：
- 每個人一個獨立空間。員工各自有自己的記憶、檔案、憑證視野、權限、排程和持久沙盒，互不干擾。
- 但可以一起用。同一個 agent 也能拉進 Slack 頻道、群組訊息和專案裡協作，身分和設定在 Slack 與網頁版之間共通。
- 不綁單一供應商。底層 harness 可以換——Pi、OpenCode、Codex、Claude Code 都能驅動同一個核心。哪家漲價或出事，換掉就好。
- 會自己動。cron 和 watch 讓工作在沒人盯的時候跑，例如定時整理信箱、監控 CI。
- 技能可以共享。skill 歸屬於某個範圍、可以授權分享，管理員審核後能推廣到全公司，也能從 git repo 匯入整包。
技術上，核心是 TypeScript 直接跑在 Node 上、HTTP 用 Fastify，資料存 Postgres，Slack 外掛用 Bolt，網頁介面用 Vite 建置、Lit 渲染。授權是 MIT，商用改造都沒問題。
YC 為什麼不直接用現成的個人 AI 助理？
因為他們試過了，而且撞牆。
YC 自己在公告裡把演進史寫得很白。第一版是 Ruby 寫的一個基本 agent 迴圈，接了幾個能讀內部資料的工具。好處是第一天就有人用得出價值，壞處是能做的事情很有限。後來加了 cron 和 webhook 觸發，勉強撐著。
然後 OpenClaw 出現，方向整個變了。YC 一口氣開了 50 多個 Hermes agent，每個員工發一個當個人助理。
光是管理這種規模的一支 agent 隊伍，就已經很吃力。
這句話是整件事的核心。50 個人各自有一個 AI 助理，聽起來很爽，實際上是 50 份設定、50 份憑證、50 個沒人知道在跑什麼的排程。沒有統一的權限模型，也沒有辦法把某個人調好的東西分給其他人。
QM 就是為了同時拿到兩邊——Hermes 的彈性，加上原本那套土砲系統的簡單。順便，他們想要一套自己能持有、自己託管的東西。
QM 跟一般 AI 助理差在哪？
差在「誰擁有這個 agent」。個人助理的設計前提是一個人一份配置；QM 的前提是一間公司一套規則，底下再切出個人空間。
| 面向 | 個人 AI 助理（OpenClaw / Hermes 類） | YC QM |
|---|---|---|
| 設計單位 | 一個人 | 一間公司，底下切個人範圍 |
| 記憶與檔案 | 單一使用者 | 每人、每個房間各自獨立 |
| 介面 | 多為終端機或單一 App | Slack ＋ 網頁，設定共通 |
| 權限控管 | 個人自己決定 | 組織層設定安全姿態，下層只能收緊不能放寬 |
| 模型／harness | 多數綁定特定供應商 | Pi、OpenCode、Codex、Claude Code 可換 |
| 技能分享 | 基本上靠複製貼上 | 授權分享，管理員可推全公司 |
| 託管 | 多為 SaaS | 跑在自己的雲端帳戶 |
| 授權 | 視產品而定 | MIT |
實際能拿來做什麼，README 列了一串，挑幾個比較有感的：把內部筆記、郵件、文件、資料庫和網路一起搜；學你過去的寫信語氣，然後定時整理收件匣、連標籤和回覆草稿一起給；在既有的 repo 裡跑測試、開 PR、盯 CI、查系統日誌；在共用頻道裡追一個專案，自動貼進度和跟進事項。
安全上怎麼防 agent 亂來？
QM 的做法跟本地端編程 agent 一致：agent 以「它服務的那個人」的身分行動，用那個人的憑證和權限，做過的事全部留下稽核紀錄。組織選一種安全姿態，底下範圍只能收得更緊。
| 姿態 | 行為 | 適合誰 |
|---|---|---|
| Strict | 每一次工具呼叫都停下來等人批准（兩個沒有副作用的收尾動作除外） | 碰法遵、客戶個資、財務資料的團隊 |
| Auto（預設） | 分類器先篩過標記來源的外部資料和工具結果，才送進模型；也可以指向自家的篩選代理 | 多數團隊的起點 |
| Dangerous | 不篩內容、工具呼叫之間不停頓 | 隔離環境下的實驗，不建議日常用 |
有一點值得單獨拿出來講：預先宣告的指令政策——例如遞迴刪除、破壞性 SQL 這類硬性阻擋——在三種姿態下都生效，Dangerous 也不例外。換句話說，就算你把防護全關了，`rm -rf` 那類東西還是攔得住。這種設計取捨值得抄。
威脅模型、對維運者的假設、以及已知限制，都寫在 repo 的 SECURITY.md 裡。漏洞回報走私下管道，不要開公開 issue。
自己架一套 QM 要做什麼？
比想像中簡單，因為你不需要 clone 原始碼。QM 的設計是：核心保持通用，所有跟你公司有關的東西（設定、自訂工具與技能、沙盒映像檔、基礎設施）都放在一個獨立的「部署目錄」。
- 建一個組織持有的部署 repo，讓它相依於
@yc-software/qm。 - 跑初始化指令：
npm exec --yes --package=@yc-software/qm@<exact-version> -- qm init . --org <slug> --target <fly-or-aws>
然後npm install。 - 跟著精靈走完：初始化會產生一份給 agent 的部署技能，帶你設定基礎設施、網頁登入、連接器憑證、選用的 Slack 存取、部署與上線驗證。
- 確認跑在自己的雲：每個部署都在維運方自己的雲端帳戶裡；初始化不會產生也不會啟用部署 CI，官方 repo 本身沒有正式環境的部署流程。
如果你的團隊想要相反的取捨——整套程式碼放同一個地方，讓工程師和編程 agent 能一起讀核心與自訂內容，同時自訂的部分保持私有——README 建議走「私有分支」：用一般的 clone 建一個獨立私有 repo，不要用 GitHub 的 Fork 按鈕。理由很實際：公開 repo 的 fork 不能改成私有，而且 fork 跟原 repo 共用同一個物件網路，你推上去的 commit 從公開那側還是抓得到 SHA。
哪些人不該碰 QM？還有什麼替代方案？
不該碰的有三種：一個人用的、沒有人維護雲端部署的、以及只想要一個能聊天的視窗的。QM 的價值全部集中在「多人、多範圍、要管權限」這件事上，抽掉這個前提，剩下的只有麻煩。
替代方案照需求分：
- 個人自動化：OpenClaw 這類個人 agent，裝完就能用，不用管部署。
- 純寫程式：Claude Code、OpenCode、Codex 這類終端機編程 agent；有趣的是它們也能當 QM 的底層 harness，所以不是二選一。
- 視覺化流程：Dify、Langflow、Flowise 這類拖拉介面，非工程師比較容易上手，但權限模型沒有 QM 細。
- 多 agent 協作框架：CrewAI、AutoGen、MetaGPT 偏向「讓幾個 agent 分工完成一個任務」，跟 QM 的「讓一間公司的人共用 agent」不是同一個問題。
這件事對小公司的意義是什麼？
我的看法是：QM 值得看的不是程式碼，是那段演進史。
過去兩年，「每個員工發一個 AI 助理」被當成公司導入 AI 的標準答案。YC 是最早做的一批，用了 50 多個，然後親口說管不動。這件事對還在規劃 AI 導入的公司來說，比任何一份白皮書都有參考價值——問題不在模型不夠強，在於沒有人管記憶、憑證、權限和排程要放在哪。
另一個訊號是 harness 可換這件事。YC 特地把 Pi、OpenCode、Codex、Claude Code 做成可以互換的底層，意思很明顯：他們不打算把公司的營運綁在任何一家模型供應商身上。小公司資源更少，這個原則其實更該學——先把流程和權限固定下來，模型當成可替換的零件。
當然，也要誠實講缺點。QM 才開源幾天，社群還沒長出來，文件之外沒什麼第三方教學可查，踩到坑大概率要自己爬 issue。真的要用在正式環境，先拿一個非關鍵的部門試跑，別一開始就接財務。
常見問題
QM 是免費的嗎？
程式碼本身是 MIT 授權，免費且可商用。但它跑在你自己的雲端帳戶上，所以雲端資源費用和模型 API 的費用要自己付。
QM 一定要接 Slack 嗎？
不用。Slack 是選用的行程內外掛，網頁介面、管理後台和公開入口也都是核心 HTTP API 之上的選用外掛。只用網頁版完全可行。
QM 綁定哪一家的模型？
都不綁。Pi、OpenCode、Codex、Claude Code 都能驅動同一個核心，可以隨時切換，部署不會鎖在單一供應商。
我可以直接 fork QM 來改嗎？
可以改，但官方建議不要用 GitHub 的 Fork 按鈕，改用一般的 clone 建私有 repo。因為公開 repo 的 fork 沒辦法變成私有，而且會跟原 repo 共用物件網路，你的 commit 從公開那側仍然抓得到。
QM 適合幾個人的團隊？
從 YC 自己的經驗推，痛點大概在幾十人這個量級開始明顯。五人以下的團隊通常還不需要這一層，直接用個人 agent 就好。
本文為技術與產業資訊整理，不構成任何投資或採購建議。文中所有規格、指令與授權條款以官方 repo 為準，截至 2026 年 8 月；開源專案更新頻繁，實際操作前請自行核對最新文件。自建部署涉及憑證與資料安全，請自行評估風險。
發表迴響