YC 開源 QM：真正難題是公司級權限邊界
YC QM 是一套給公司使用的多人 Agent harness。它從超過 50 個 Hermes Agent 的管理經驗出發，把員工、專案、記憶、憑證與沙箱放進可治理的 scope，透露公司級 Agent 接下來真正要解的問題。
最後更新：
目錄+
Y Combinator 曾替員工配置超過 50 個 Hermes Agent。最後浮現的問題不是 Agent 不夠聰明，而是每個 Agent 都帶著自己的設定、記憶、登入狀態與工作環境。
2026 年 7 月 31 日，YC 公開了內部使用的多人 Agent 系統 QM。它不是新模型，也不是展示十幾個 Agent 同時工作的 Demo，而是一套用來管理公司 Agent 的 harness。
QM 最重要的訊號是：當 Agent 從個人工具走進公司，問題很快就會從「它會不會做事」變成「誰有權讓它做事」。
QM 是什麼？
QM 是一套將多人身分、個人與共享 scope、Agent loop、長期狀態及隔離執行環境放進同一個核心的工作用 harness。
根據 YC 公開的使用範圍，QM 已進入會計、法務、活動與工程工作，連 QM 本身也由 QM 協助開發。整個專案採 MIT 授權，原生提供 Slack 與 Web 介面。
名稱 QM 是 Quartermaster 的縮寫，原意是船上負責協調物資、維持內部運作的人。這比「AI 員工平台」更接近它的角色：QM 不必親自完成所有工作，它更像一個讓多位員工與多個 Agent 在正確位置工作的控制層。
如果你只需要一個人使用的自動化助手，可以先從 OpenClaw 的實際使用場景理解個人 Agent 能解哪些問題。QM 面對的則是下一個階段：當這些能力進入整間公司，信任邊界要怎麼重畫。
YC 從 Ruby loop 走到 50 個 Hermes Agent
QM 不是憑空出現的產品。
YC 最早用 Ruby 做了一個基本 Agent loop，再加入一些能存取內部資料的工具。這套系統能力有限，卻容易讓員工在第一天就取得價值。之後，他們逐步加入 cron 與 webhook，讓 Agent 能在沒有人盯著畫面時執行背景工作。
OpenClaw 出現後，YC 又為員工配置超過 50 個 Hermes Agent，讓每個人擁有更有彈性的個人助理。
但 fleet 一大，管理成本就跟著出現：
- 每個 Agent 的模型、技能與工具可能不同。
- 記憶與檔案分散在個人環境。
- 憑證與登入狀態很難統一管理。
- 背景排程不容易被組織集中檢查。
- 個人工作流難以安全地變成共享能力。
YC 想保留 Hermes 的彈性，又想要第一套系統容易管理的特性。QM 就是這兩種需求的交集。想先理解 Hermes 生態的讀者，可以搭配 Hermes Agent 生態系整理閱讀。
Multi-agent 和 multiplayer 差在哪？
多代理系統通常在回答這些問題：誰負責研究、誰負責寫程式、誰負責測試，以及 Agent 之間如何交接工作。
這些設計以「完成一個目標」為中心。即使同時啟動許多 Agent，它們往往仍服務同一個使用者或同一條工作流。
QM 使用的詞是 multiplayer agent harness。可以用一句話分開兩者：
多代理回答誰來做事；多人 Agent 平台回答它代表誰、能碰什麼，以及結果歸誰。
進入公司後，財務的 Agent 不應讀到工程師的私人記憶；專案頻道裡的 CI Agent 不應自動取得法務文件；某位員工授權的 Gmail 憑證，也不能因為 Agent 被加入共享頻道就變成全員可用。
公司不能只是共用一個權限無上限的超級 Agent。即使 Claude Code 已經能支援多人共享工作環境，終端協作和公司級權限治理仍是兩個不同問題。
QM 的核心不是 Agent，而是 Scope
在 QM 裡，每位員工與每個 room 都有自己的 scope。Room 可以是 Slack 頻道、群組對話或共享專案。
每個 scope 分別擁有自己的：
- 記憶與檔案
- Keychain view 與權限
- Cron 與背景任務
- Web App
- Durable sandbox
員工可以在 personal scope 保存寫作偏好、私人文件與個人排程；進入專案後，Agent 看到的則是 shared scope 的檔案、技能、權限與記憶。
這裡的 scope 不只是資料夾。它同時是記憶邊界、權限邊界與責任邊界。
如果這套抽象能成立，它可能比「建立更多專業 Agent」更重要。公司真正缺少的往往不是第十個研究 Agent，而是一套能確定前九個 Agent 沒有拿錯憑證、讀錯資料或把結果交給錯誤對象的系統。
中央治理，分區執行
QM 的架構可以拆成三個部分。
第一部分是 Postgres，負責保存 session、memory、queue 與其他需要長期存在的狀態。
第二部分是 headless core，負責 API、身分、政策與排程。Slack、Web UI、Admin 和 Portal 都能作為核心上方的介面。
第三部分是每個 scope 自己的 durable sandbox。Agent 透過固定工具表面進入沙箱執行指令，安裝的工具、檔案與工作狀態可以持續保留。
模型和 Agent harness 則可以替換。官方目前列出 Pi、OpenCode、Claude Code 與 Codex，都能驅動同一套核心。
這個設計透露出一個實際判斷：模型會持續更換，公司不應把長期工作狀態綁死在單一模型供應商身上。真正需要保留的是身分、權限、技能、資料連接方式與執行紀錄。
為什麼 YC 選擇開源與自有部署？
YC 沒有只把 QM 做成一個所有公司登入使用的 SaaS，而是提供 MIT 授權的核心，讓組織部署到自己的雲端帳號。
公司 Agent 會接觸內部文件、資料庫、Email 與正式系統。對許多團隊來說，能控制雲端帳號、資料庫、網路與加密金鑰，是使用這類平台的前提。
每間公司的工作方式也不同。公司自己的設定、sandbox tools、skills、plugin images 與基礎設施可以放在 deployment layer，核心程式則持續跟上游同步。
我的判斷是，QM 想建立的不只是一個產品，而是一份公司 Agent 的參考架構。未來真正有價值的部分，可能不是它支援多少模型，而是 scope、grant、sandbox、shared skill 與 deployment layer 會不會逐漸成為共同概念。
公司 Agent 的下一個市場可能是 Agent IT
個人電腦普及後，公司需要 IT 管理帳號、裝置、軟體與權限。SaaS 普及後，又出現 SSO、SCIM、MDM 與 DLP。
如果未來每位員工與每個專案都有 Agent，公司同樣需要新的管理層：
- 誰可以建立 Agent？
- Agent 能使用哪些模型與工具？
- 哪些技能能全公司共用？
- 誰能授權 Email、資料庫與內部系統？
- 員工離職後，記憶與排程怎麼處理？
- 發生錯誤時，能不能還原完整行動紀錄？
這些問題不屬於模型本身，也不是多代理編排框架能單獨解決的。它們更像 Agent 時代的 IT 管理。
QM 還在早期，但它已經把這個市場輪廓畫了出來。
真正的分水嶺不是 Agent 數量
過去談多代理，大家常用 Agent 數量展示能力。十個 Agent 同時研究、寫程式、測試與審查，看起來像一支不會休息的團隊。
但進入真實公司後，Agent 愈多，問題不只是 token 花得更多。更大的問題是：它們是否共享了不該共享的記憶、取得了不該取得的憑證，或代表錯誤的人採取無法挽回的行動。
下一階段的 Agent 基礎設施，不是讓 Agent 變多，而是讓它們在正確的邊界內工作。
如果你目前只需要把口述想法整理成文字，而不是部署公司級平台，可以先使用範圍較窄的 Typeless AI 語音轉錄。工具愈窄，通常愈容易理解它的資料與權限範圍。
利益揭露：Typeless 連結為聯盟連結；若你透過連結訂閱，本站可能獲得分潤，不影響你的價格與本文判斷。
下一篇會先回答最基本的一題：個人 AI 助手和公司級 Agent，差別到底在哪裡？
常見問題
YC 的 QM 是什麼？
QM 是一套給公司使用的多人 Agent harness，統一處理 personal／shared scope、記憶、檔案、憑證、排程、沙箱，以及 Slack 和 Web 介面。
QM 和一般多代理框架有什麼不同？
一般多代理框架多半處理 Agent 如何分工。QM 更關心多位員工與專案如何共用平台，又不混合身分、記憶與權限。
QM 現在適合直接接上公司機密嗎？
不應只因為 YC 在內部使用就直接接上機密。QM 仍是早期開源項目，導入前需要依自己的資料、憑證、網路與工作流完成安全審查。