QM Agent 在 2026 年 7 月公開的重點，是把個人 AI 助理改造成有身分、作用域與稽核的多人工作系統；截至 8 月 4 日，GitHub 約有 9,700 顆星。 這套開源 Agent harness 來自 Y Combinator（YC）的內部經驗。它替每位員工與每個專案分開管理檔案、記憶、金鑰、權限與持久沙箱，也讓 Pi、OpenCode、Codex、Claude Code 共用同一個控制核心。

熱度很真實，安全保證卻不能跟著放大。QM 的官方安全文件把它定義為早期實驗性軟體，適用邊界是同一組織內已驗證的使用者。面向敵對使用者的強固多租戶服務，超出它目前的設計範圍。這個但書，正是評估 QM 最重要的起點。

YC 為什麼從 50 多個 Hermes Agent 轉向 QM

OpenClaw 讓個人 Agent 進入瀏覽器、郵件、檔案與本機命令列。它的官方安全指南也明講：一個 Gateway 以單一可信任操作者為設計前提；互不信任的使用者應拆成不同 Gateway，最好連作業系統帳號或主機也分開。Hermes Agent 的安全政策更直接，把作業系統層級隔離列為對抗惡意模型的唯一安全邊界，預設終端後端則在主機執行命令。

這兩個專案都已補上許多安全控制。真正難處是組織一旦把個人助理複製成一整隊，身分、權限、共享狀態與維運成本會一起放大。YC 在 QM 官方頁寫得很具體：團隊先做過 Ruby Agent loop，後來替員工配置超過 50 個 Hermes Agent；規模到這裡，管理就開始變得棘手。

QM 因此把產品重心放在 harness，也就是夾在使用者、模型、工具與執行環境中間的控制層。它沒有另做一個專屬推理核心。每次工作仍可交給 Pi、OpenCode、Codex 或 Claude Code，QM 負責決定這次對話屬於誰、能拿到哪些資料、哪些動作要批准，以及結果該送回哪裡。

這個定位也解釋了開源速度。QM GitHub 儲存庫建立於 2026 年 7 月 29 日；截至 8 月 4 日查核時已有約 9,700 顆星、1,000 多個 fork，最新版為 7 月 31 日發布的 v0.1.4。YC 從 2005 年以來投資超過 5,000 家公司；原始素材所稱的「2025 年至今」並不正確。

QM 官方頁說明產品定位：為新創團隊提供多人 Agent harness

作用域才是多人 Agent 的核心

在個人 Agent 裡，「我」通常只有一個。接到團隊後，系統至少要同時回答四個問題：誰發出要求、在哪個專案、可讀取哪些資源、最後可以對哪個外部系統產生副作用。少任何一層，漂亮的多人介面都可能只是把同一把主機鑰匙交給更多人。

QM 以 scope（作用域）拆開每個人與每個房間。官方 README 列出的隔離內容包括記憶、檔案、Keychain 檢視、權限、排程、Web App 與持久沙箱。個人對話留在個人 scope；Slack 頻道、群組與專案則使用共享 scope。相同身分與設定可以在 Web UI 和 Slack 之間延續。

本機介面測試可以看到這種設計如何落到操作層：建立「AI 研究」專案、加入第二位成員後，兩邊能在同一段對話裡接續提問，也能同步查看工具與命令進度。未加入共享專案的一般成員，看不到另一人的個人專案。這證明了使用者介面的基本隔離路徑，但不能推論管理員完全無法讀取私人內容。

QM 的安全政策指出，組織管理員是具特權的內容讀取者。只要該次讀取符合 scope 授權，管理員可以直接讀取逐字稿、模型請求、文件、記憶、連接器與 Keychain metadata，而且不需要使用者另行同意；系統會留下稽核紀錄。企業在導入前要把這項權力寫進內規、存取流程與告知機制。

QM、OpenClaw、Hermes Agent 的安全邊界差在哪裡

三者不能只用「安全」或「不安全」二分。官方文件描述的是不同信任模型，部署者要先選對模型，再談功能。

判斷面向 OpenClaw Hermes Agent QM
主要租戶模型 每個 Gateway 一個可信任操作者邊界 單租戶個人 Agent 同一組織內的已驗證使用者
多人分隔方式 敵對使用者應拆 Gateway、作業系統帳號或主機 需要權限分隔時應拆 Agent instance 與 allowlist 個人、房間、群組與專案各自有 scope
預設執行立場 可信任單人情境可讓 host exec 不逐次詢問 預設終端後端直接在主機執行 Auto 為預設；Strict 可要求每個 harness 工具呼叫都經人工批准
控制層定位 個人助理 Gateway 與工具政策 個人 Agent 本體與外部介面 身分、政策、排程、稽核與多 harness 的共用核心
官方揭露限制 Prompt injection 不能只靠 system prompt 解決 行程內掃描、核准與 allowlist 都只是 heuristic 命令政策可繞過，部分瀏覽器操作不會重新進入核心核准流程

這張表無法證明 QM 自動高出一個安全等級。它代表 QM 原生建模了團隊需要的治理物件；OpenClaw 與 Hermes Agent 則清楚要求使用者自行建立更強的外部隔離。兩者的差別在預設架構要解什麼問題，Agent 風險依然存在。

QM 官方頁回顧 YC 先前的 Ruby Agent loop 與 50 多個 Hermes Agent 部署

三種安全 posture 仍需要真正的沙箱

QM 讓組織選擇三種安全姿態。Strict 幾乎每次工具呼叫都暫停等待人工核准；Auto 先用分類器檢查帶來源標記的外部文字與工具結果；Dangerous 不做內容篩檢，也不在工具呼叫間暫停。預先宣告的命令政策仍會在三種模式套用，例如阻擋遞迴刪除或破壞性 SQL。

名稱容易讓人產生錯覺。官方文件承認，命令政策只分析 shell 文字，編碼、混淆或先寫入腳本再執行都可能繞過。瀏覽器 runner 裡的操作也未必重新進入命令政策與人工核准。Auto 的篩檢不涵蓋所有命令輸出、背景行程、multimodal 結果與 webhook payload；分類器無法替代授權機制。

金鑰也有相同邊界。QM 能依 owner、audience、單次或長期授權、到期與撤銷狀態管理 credential grant；金鑰在儲存時可加密。Agent 真正要呼叫服務時，憑證仍會以環境變數或檔案形式出現在沙箱，沙箱內的行程可以讀到明文。所謂 Keychain 隔離，降低了拿錯鑰匙的機率，沒有阻止已遭入侵的 Agent 行程外洩可用憑證。

這也是持久沙箱必須被當成敏感電腦的原因。它保留工具與檔案，換來跨回合效率；同時也累積狀態。QM 目前的檔案 artifact 沒有到期時間，精確模型請求預設會被保存，組織 kill switch、secret scanning 與部分治理回復機制仍不完整。

從 Web UI 或 Slack 到沙箱，QM 的 7 步流程

下面的流程保留原始測試所描述的順序，並以官方架構補齊權限邊界：

  1. 使用者從 Web UI 或 Slack 發起對話。
  2. QM 核心解析 principal 與 scope，判斷這次工作屬於個人、群組、頻道或專案。
  3. 系統依組織姿態與 scope 規則，決定自動處理、限制工具，或等待人工核准。
  4. 選定的 harness 與模型產生回應；Pi、OpenCode、Codex、Claude Code 可共用同一套核心介面。
  5. execute 等工具在該 scope 的持久沙箱執行命令，並取得已授權的檔案與 credential grant。
  6. 核心把結果送回原本的 Web 或 Slack 對話，並保存 session、工具紀錄與安全事件。
  7. 管理者利用稽核資料追查行為、調整政策與修正工作流程。稽核能協助調查，無法阻止已經發生的動作。

這七步真正有價值的地方，是把模型呼叫放進可追蹤的組織流程。系統沒有保證所謂的「自我進化」。記憶與稽核讓下一次判斷有更多上下文，是否真的改善仍需要評測、版本控管與人工責任。

自架構降低客製分支，維運責任則回到團隊

QM 採 MIT License，部署在組織自己的 Fly.io 或 AWS 帳戶。核心之外的公司設定、工具、Skill、沙箱映像與基礎設施放在 deployment directory，理論上可以減少直接修改上游核心。需要更深客製時，官方建議用獨立的私有儲存庫同步 upstream，並把公司專屬內容留在 deploy/layers/<org>/。

這個結構解決的是升級衝突，沒有替團隊承擔營運。部署者仍要管理雲端帳戶、身分提供者、Postgres、物件儲存、加密金鑰、模型供應商、瀏覽器供應商與初始管理員權限。官方初始化流程也不會自動啟用 production deployment CI。若公司沒有平台工程與資安責任人，MIT License 的零授權費不等於低總持有成本。

官方目前提供的初始化路徑如下。<slug> 與 <fly-or-aws> 是部署者自行替換的值：

npm exec --yes --package=@yc-software/qm@latest -- \
  qm init . --org <slug> --target <fly-or-aws>
npm install

適合先行試驗的場景，是同一家公司內部、已驗證的使用者，以低權限資料和可回復工作開始。需要對外提供服務、彼此敵對的多租戶、受高度監管資料，或無法接受管理員特權讀取的情境，都超出 QM 目前公開安全邊界。

QM 官方頁說明自架與開源方向，並連至官方程式碼儲存庫

導入前的驗收清單

團隊不必先問「QM 會不會成為下一個 OpenClaw」。更實際的問題是，現有風險能否被明確分派給一位負責人。

  • 身分：只允許組織內已驗證使用者，外部訪客另走獨立的 App 邊界。
  • 作用域：用兩個測試帳號驗證個人、群組與專案資料不會跨 scope 讀寫或送錯對象。
  • 金鑰：採最小權限、短效 credential grant，並測試到期、撤銷與事件調查。
  • 沙箱：使用真正的主機或微型虛擬機隔離，另外限制檔案系統與外連。
  • 人工核准：用實際危險命令與瀏覽器操作測試 Strict，不能只看 UI 標籤。
  • 保存政策：決定 session、模型請求、記憶與 artifact 的刪除期限，補上 QM 尚未提供的清理機制。
  • 管理員治理：記錄誰能讀敏感內容、何時可讀、如何通知當事人，以及如何稽核管理員。

常見問題

QM Agent 是什麼

QM Agent 是 Y Combinator 於 2026 年 7 月開源的多人 Agent harness。它以同一個核心管理身分、scope、政策、排程、稽核與持久沙箱，再把推理工作交給 Pi、OpenCode、Codex 或 Claude Code。

QM 比 OpenClaw 或 Hermes Agent 安全嗎

QM 原生提供較完整的組織治理物件，但官方沒有宣稱它已通過安全認證。它仍是早期實驗性軟體，命令政策、瀏覽器核准、憑證明文使用與資料保存都有已知限制。架構更貼近團隊，風險仍未消失。

QM 管理員看得到私人對話嗎

一般成員受到 scope 與授權限制。組織管理員則是具特權的內容讀取者；只要符合 scope 授權，就能讀取逐字稿、文件、記憶與相關 metadata，操作會被稽核，但不需要使用者另行同意。

QM 可以直接開放給客戶或朋友使用嗎

不建議把互動式 Agent 直接當成公開多租戶服務。QM 官方邊界是單一組織內的已驗證使用者；公開 App 的 capability link 只是另一個有限邊界，而且持有連結的人即可存取該 App。

現在適合把 QM 放進正式環境嗎

適合從低風險內部流程做受控試驗，前提是團隊能管理雲端、身分、沙箱、金鑰、外連與稽核。含機密資料、外部多租戶或監管責任的正式環境，應先完成部署專屬的威脅模型、滲透測試與事件應變設計。

權威來源

Author Insight

我最在意的是，QM 終於迫使團隊把「誰能讓模型做什麼」寫成系統物件。可切換幾套 Agent 反而居次。這比再加一個聰明模型有用得多。只是作用域與稽核仍是控制面，尚未構成真正的隔離邊界；最後一道防線依然是主機、網路、憑證與人。

Tenten 在導入可執行命令的 AI 工作流程時，會先把身分、機密、沙箱、外連與稽核拆成可驗收條目，再讓模型接觸真實系統。若你的團隊正在評估 QM 這類多人 Agent，可透過 Tenten AI 顧問服務 規劃試點與安全驗收。

術語表

  • Agent harness：包住模型迴圈的控制層，負責工具、狀態、權限、執行與回傳。
  • Scope（作用域）：定義一次工作屬於哪位使用者、房間、群組或專案，以及可存取的資源。
  • Keychain：依 scope 呈現與授權憑證的介面；憑證使用時仍可能在沙箱內成為明文。
  • Durable sandbox（持久沙箱）：跨回合保留檔案與已安裝工具的執行環境。
  • Security posture（安全姿態）：組織選擇的 Strict、Auto 或 Dangerous 控制模式。
Share this post
Ewan Mak

I'm a Full Stack Developer with expertise in building modern web applications that fast, secure, and scalable. Crafting seamless user experiences with a passion for headless CMS, Vercel and Cloudflare

Loading...