多代理協作平台 qm 開源：yc-software 讓 AI 代理有身分
qm 是一套開源的多代理協作平台，讓公司裡每個人擁有自己的 AI 代理。記憶、檔案、權限各自獨立，又能在同一個 Slack 頻道一起工作。截至 2026-08-02 讀取，它在 GitHub 上有 5.1k 星、515 個 fork。
qm 到底是什麼東西？
qm 是 yc-software 開源的「工作用多人代理框架」（multiplayer agent harness），跑在 Slack 與網頁上，讓一間公司的多個 AI 代理同場工作而互不污染。harness 指的是驅動模型幹活的那層外殼——負責身分、記憶、工具與排程的程式，模型是裡面可以替換的引擎。
官方 README 的定位寫得很直白：多數代理是照個人助理設計的，硬要讓一個代理服務整間公司，複雜度會迅速失控。qm 的解法是把「範圍」（scope）當成一等公民——每個人、每個房間（頻道、群組訊息、專案）各自擁有自己的記憶、檔案、金鑰視圖、權限、排程任務、網頁應用，以及一個長存沙箱。
三個術語先講白話：金鑰視圖（keychain view）是這個範圍看得到哪些密碼與 API key 的那份清單，不多也不少；sandbox 沙箱是一台隔離的虛擬電腦，代理在裡面裝工具、跑指令，裝過的東西會留著；定時排程是按時間自動觸發的任務，沒人盯著也會動。
為什麼這個專案值得現在看？
因為它踩中的痛點已經積了兩年，而現在才有人把它寫進架構層。發稿日是 2026-08-02，我們當天讀到的 repo 頁面是 5.1k 星、515 個 fork、40 次 commit。
40 次 commit 是非常年輕的專案。一個成熟度還這麼低的 repo 已經累積到五千顆星，我的解讀（作者觀察，非官方說法）是：共鳴來自它要解的問題，完成度在這件事上還排不上號。
過去兩年，公司導入 AI 幾乎都跑同一個劇本：先是幾個人各自買訂閱，接著行政開一個共用帳號給全公司用，然後三個問題準時報到——記憶混在一起、權限沒人管、事後查不到誰讓 AI 做了什麼。多數團隊用「使用規範」處理這三件事，也就是發一份 PDF 叫大家自律。qm 把它們搬到架構層，讓越權在技術上就不成立。
「作用域隔離」實際上隔離了什麼？
官方列出的隔離項目共七類，個人與共享房間各自持有一份。這是它跟一般共用帳號最實質的差別。
| 隔離項目 | 個人範圍 | 共享房間（頻道／專案） |
|---|---|---|
| 記憶 | 個人獨立記憶 | 房間自己的記憶 |
| 檔案 | 個人範圍的檔案 | 房間範圍的檔案 |
| 金鑰視圖 | 只看得到自己的 | 只看得到房間被授權的 |
| 權限 | 個人設定 | 房間設定 |
| 排程任務 | 個人擁有 | 房間擁有 |
| 網頁應用 | 個人擁有 | 房間擁有 |
| 長存沙箱 | 個人專屬沙箱 | 房間專屬沙箱 |
技能（skills）也是範圍所有制：預設屬於某個範圍，靠授權分享出去，要推廣到全公司需要管理員核可，也支援從 git repo 匯入技能包。管理端可設定組織層級的安全姿態，以及開放哪些 harness 與模型可用。
架構上，qm 的核心是 headless 的——headless 指沒有自帶介面、只靠程式呼叫運作：一個中央核心處理身分、政策與排程，Postgres 存 session 歷史、記憶與佇列，代理只有一組小而固定的工具，其中 execute 這個工具負責在該範圍自己的沙箱裡跑指令。網頁 UI、管理面板、公開入口都是核心 HTTP API 上的可選外掛，Slack 則是核心啟動並監管的行程內外掛。技術棧是 TypeScript 直接跑在 Node.js 上，HTTP 層用 Fastify。前面提到的「安全姿態」（security posture）講白話就是整間公司的預設安全等級要調到多嚴，由管理員一處設定、全組織吃到。
模型不綁單一供應商這點值得單獨記一筆：README 明說 Pi、OpenCode、Codex、Claude Code 都能驅動同一個核心，所以部署不會被任何一家綁死。對台灣中小企業來說，這是實際會影響三年後帳單的設計選擇。
qm 跟個人訂閱、跟公司共用帳號差在哪？
差在誰擁有記憶、誰管得動權限、以及出事時查不查得到。下表把三種常見狀態攤開比。
| 比較維度 | 員工各自買訂閱 | 全公司共用一個帳號 | qm 這類多代理協作平台 |
|---|---|---|---|
| 身分 | 個人帳號，公司看不到 | 一個帳號，誰做的都分不出 | 每人一個身分，跨 Slack 與網頁一致 |
| 記憶 | 各自累積，離職就消失 | 全部混在一起 | 人與房間各自獨立 |
| 金鑰與憑證 | 員工自己貼進去 | 一組共用，範圍最大 | 依範圍給金鑰視圖 |
| 權限管理 | 沒有 | 靠口頭約束 | 組織層級設定安全姿態與可用模型 |
| 協作 | 各做各的，成果無法共享 | 勉強共享，互相污染 | 頻道、群組、專案內共同工作 |
| 換模型成本（推論） | 每人各自重來 | 整批重來 | 設定值切換，核心不動 |
| 事後追查 | 幾乎不可能 | 幾乎不可能 | 有 session 歷史可查，見下節保留意見 |
「換模型成本」那一列標了推論：官方只寫了 Pi、OpenCode、Codex、Claude Code 能驅動同一個核心、管理端可設定可用模型，沒有承諾任何遷移成本數字。多供應商切換落在設定層、不必重寫流程，這是我們從這個架構推出來的判斷，官方文件並未這樣寫。
公司要導入多個 AI 代理協同工作，怎麼設計權限跟查核才安全？
順序是：先切身分，再切金鑰，最後才開自動化。權限的單位要是「人＋房間」而非一個公司帳號，因為代理的風險來自它讀得到什麼，而讀取範圍是跟著對話發生的地方走的。同一個人在業務頻道與財務頻道該看到的東西並不相同。
落地成四層檢查：
- 身分層：每個員工一個代理身分，離職時能單獨停用。共用帳號一旦出事，你連該停誰都不知道。
- 金鑰層：代理不該看到明文憑證。qm 的設計是每個範圍有自己的金鑰視圖，這個概念比「把 API key 貼進 prompt」安全一個等級。
- 輸出層：對外的信、報價、合約一律走人工閘門。這條與工具無關，純粹是紀律。
- 排程層：定時排程與自動監看最後才開，因為它們是唯一會在沒人看著時動手的東西。
這裡要說一句難聽的實話：qm 的 README 沒有把查核日誌列為功能項。它有身分、有政策、有 Postgres 保存 session 歷史，這些是事後查核的原料，但公開文件並未承諾一份現成的審計軌跡介面。把「有 session 歷史」講成「查得清楚每一次動作」，是導入案子半年後爆掉的典型起點。真要拿它撐合規需求，先去讀 repo 裡的 SECURITY.md 與 adrs 目錄確認實作，並預期自己得補一段日誌匯出。
這對台灣中小企業意味著什麼？
意味著「AI 治理」這件事從投影片變成了可以直接讀的程式碼，但不代表你該自己架。我的判斷按規模分三種，講清楚各自該做什麼。
20 人以下、沒有專職工程人力：不要自己架 qm。它需要 Postgres、Node 環境、Slack app 設定與沙箱維運，這些成本會直接吃掉你想省下的人力。該抄的是三個原則——一人一代理、金鑰不讓代理看見明文、自動排程最後開。用現成的商用工具落實這三條，比硬扛開源專案划算得多。
20 到 100 人、有一到兩個工程師、團隊已經住在 Slack 上：值得派一個人花兩週做概念驗證。驗收標準寫死三條：不同員工的代理讀不到彼此的檔案、頻道代理拿不到個人金鑰、每一次外部動作查得到是誰觸發的。第三條若做不到，就是前面說的查核缺口，你會知道自己要補多少。
已經在賣 AI 導入服務的公司：這是競品，同時是地基。客戶問「你們跟開源的差在哪」的時候，答不出來就會被砍價。授權條款以 repo 的 LICENSE 為準，商用前務必自己確認。
一位老闆上個月跟我說，他公司十幾個人全在用 AI，但他完全不知道誰把什麼資料貼出去過。他從頭到尾沒有為 AI 設計過身分，工具換幾套都補不回來。qm 的價值在於它把這個問題的答案寫成了可以讀的架構，你不用付顧問費就能看懂該怎麼切。
想抄這套架構，這週可以先做什麼？
三個動作，不需要寫任何程式。
第一，列出公司現在有幾個 AI 入口——訂閱帳號、外掛、自動化流程全算。多數老闆會發現實際數字是他以為的兩到三倍。
第二，對每個入口回答三個問題：誰擁有它、它讀得到哪些資料、它出事你多久會知道。第三題答不出來的，先關掉。
第三，把「一人一代理」寫進下一季的 IT 規劃。共用帳號能撐到十個人，撐不到三十個人。
這套「先盤點入口、再切身分、最後才自動化」的順序，是我們替客戶做 AI 落地時固定的第一階段。如果你想看這個盤點怎麼變成一份可執行的體檢報告，AIRUN 的 AEO 服務頁 有更完整的方法說明。
我們的判斷
qm 現在不適合當你的正式系統，適合當你的架構教科書。一個提交次數還停在兩位數的專案不該承載公司命脈，但它把「AI 代理需要身分、範圍與權限」這件事講得比市面上任何一份白皮書都清楚，而且免費。
真正該從這件事帶走的判斷是：AI 進公司的下一個瓶頸不在模型能力，在治理。模型每三個月都在變強，你的權限設計如果還停在一個共用帳號，換再強的模型也只是把風險放大。先把身分切好，剩下的才有得談。
常見問題
qm 可以直接拿來當公司的正式 AI 系統嗎？
以公開資訊看，還太早。整個 repo 的提交次數目前還停在兩位數，是很新的專案，官方也未公布穩定版本承諾或商業支援方案。合理用法是拿它做兩週的概念驗證，驗證作用域隔離與 Slack 協作是否符合你的流程，正式上線前要自己補監控、備份與查核紀錄輸出。把它當架構參考，比當現成產品安全。
qm 有完整的查核日誌嗎？
官方 README 沒有把查核日誌列為功能項。它列出的是身分、政策、以及 Postgres 持久層保存 session 歷史與佇列，這些是事後查核的原料，不等於一份現成的審計軌跡介面。要用它撐合規需求，得先讀 repo 內的 SECURITY.md 與 adrs 目錄確認實作細節，並預期自己要補一段日誌匯出。
換模型會不會被綁死在某一家？
官方明確說可以換。README 指出 Pi、OpenCode、Codex、Claude Code 都能驅動同一個核心，管理端還能設定組織允許哪些 harness 與模型。這代表模型選擇落在設定層，換供應商時不用重寫流程。這一點是它比多數封閉助理更值得參考的地方。
沒有工程師的小公司該怎麼辦？
別自己架。qm 需要 Postgres、Node 環境、Slack app 設定與沙箱維運，這些成本會吃掉你想省的人力。可以照抄的是它的三個原則：一人一代理、金鑰不讓代理看見明文、自動排程最後才開。用現成的商用工具落實這三條，效果比硬架開源專案好。
為什麼權限的單位要是「人加房間」而不是部門？
因為 AI 代理的風險來自它讀得到什麼，而讀取範圍是跟著對話發生的地方走的。同一個人在業務頻道和財務頻道該看到的東西不同，用部門切會過寬。qm 把每個房間都當成獨立範圍，各自有記憶、檔案與金鑰視圖，就是為了讓越權在架構上不成立，而不是靠使用規範提醒。
導入多代理系統，最常見的爆點是什麼？
自動排程開太早。代理在有人盯著時出錯，最多是一次難堪；在沒人盯著時按表操課地出錯，是連續數十次且延遲數天才被發現。我們的作法是新流程先跑純手動觸發兩週，確認輸出穩定、日誌看得懂，再把定時排程打開，且第一個月維持每日人工抽查。
AIRUN 對抗式創業體檢 AgentFlow Solutions（双云行銷試運行）