編按：本文綜合整理自 YC Software 的 QM 官方儲存庫、QM 安全政策、Y Combinator 多人 AI 題目說明與 Hacker News 討論，並加入 Siami 編輯部觀點與分析。
AI Agent 正從個人程式助理走進公司日常，但真正困難的問題不只是模型會不會寫程式，而是不同員工如何安全地共用同一套能力。YC Software 新開源的 QM 將自己定位為「工作用多人 Agent 框架」，透過 Slack 與 Web 介面，讓個人可以獨立工作，也能在頻道、群組與專案裡和同事共同使用代理。
QM 採 MIT 授權，官方說明顯示，系統並非單純在聊天機器人外再套一層介面，而是把身分、權限、記憶、工具、排程與持久運算環境納入同一個公司級核心。專案公開後迅速登上 Hacker News 熱門榜，檢查時已累積 511 分與 107 則討論。
從個人助理走向「多人共用代理」
多數 AI Agent 以單一使用者為中心：一個人擁有自己的對話、檔案與工具權限。當公司想讓整個團隊使用同一套系統時，情況立刻變複雜。財務、人資、工程與行銷不能共享所有憑證；私人草稿不該自動出現在公共頻道；某個人的背景任務也不應修改另一個人的工作環境。
QM 的解法是以 scope 劃分邊界。每名員工、每個房間與每個專案都有自己的：
- 記憶與 session 歷史
- 檔案與持久沙箱
- 金鑰與登入服務的可見範圍
- 工具權限與安全政策
- cron 排程、監看任務及 Web App
- 可共享或由管理員核准的 skills
員工可以在私人 scope 裡調整代理，讓它熟悉自己的工作方式；需要協作時，再進入 Slack 頻道或專案 scope，使用該空間允許的共同記憶與工具。這種設計試圖避免「全公司只共用一個超級帳號」，也降低代理把私人脈絡帶到公開房間的機率。
架構：Postgres、無頭核心與持久沙箱
官方架構圖把 QM 分為三個主要部分。第一層是 Postgres，保存 session、記憶、佇列與其他持久資料；第二層是 headless core，處理 API、身分、政策、排程與 agent loop；第三層則是每個 scope 的隔離沙箱，保存檔案、工具以及登入後的服務。
每次對話都會經過中央核心，再由選定的模型與 harness 產生結果。QM 宣稱可讓 Pi、OpenCode、Codex 與 Claude Code 共用同一核心，因此部署者不必把整套公司工作流程綁死在單一模型供應商。Web UI、管理後台、公開 portal 與 Slack 都是核心 API 上的外掛介面。
這項架構帶來幾個值得注意的設計選擇：
- 狀態集中管理：session 與記憶存入 Postgres，而不是散落在員工電腦或聊天平台。
- 運算環境持久化：每個 scope 有自己的沙箱，安裝過的工具與工作檔案可以保留。
- 模型與 harness 可替換：核心介面將 session store、sandbox、memory 和 harness 抽象化。
- 公司客製內容外置：組織設定、私有工具、skills 與基礎設施放在 deployment directory，不必直接修改上游核心。
官方列出的實際用途包括搜尋公司文件與資料庫、整理信箱、建立內部 Web App、操作既有程式庫、執行測試、開啟 Pull Request、監控 CI，以及在共享頻道追蹤專案進度。
安全不是附加功能，而是產品核心
讓代理擁有員工憑證並能操作公司系統，風險遠高於一般問答機器人。QM 採用「代理代表目前使用者行動」的模型：它能看到什麼、能執行什麼，取決於該使用者與 scope 的權限；系統同時記錄代理行為供事後稽核。
官方文件提供三種安全姿態：
- Strict：除少數無副作用的結束動作外，每次 harness 工具呼叫都暫停等待人工核准。
- Auto：預設模式，由分類器先檢查帶有來源標籤的外部資料與工具結果，再交給模型。
- Dangerous：不做內容篩檢，工具呼叫之間也不暫停，適合願意承擔風險的受控環境。
即使選擇 Dangerous，預先宣告的命令政策仍持續生效，包含核准規則及對遞迴刪除、破壞性 SQL 等操作的硬性拒絕。這個細節很重要：安全模式不應只是一個「全部開放」開關，最低層的不可逆風險仍需獨立防守。
不過，官方也明確把威脅模型、營運者假設與已知限制放進 SECURITY.md。企業評估時不能只看到「隔離沙箱」就視為安全完成，仍需確認沙箱逃逸風險、外部內容的 prompt injection、憑證輪替、稽核紀錄保存，以及管理員本身的權限邊界。
數據解讀：511 分、107 則討論透露什麼
QM 在 feeds.json 初次收錄時為 302 分、68 則留言；數小時後，Hacker News 官方 API 已上升到 511 分、107 則討論。快速成長顯示「多人 AI」並非只有 YC 內部感興趣，開發者正在尋找比單人 coding agent 更完整的組織協作層。
但高熱度不等於產品已通過企業驗證。討論裡同時出現三種聲音：一派認為每人 scope 加共享房間正面處理了多人代理最難的權限問題；另一派質疑市場已有 Claude Cowork、OpenClaw、Hermes 與其他平台，QM 的差異仍不夠清楚；也有人特別關注公司級上下文和安全設計，準備比較實作細節。
數字還有另一個限制：HN 分數反映開發者關注與討論意願，不代表部署數、穩定性或安全事故率。QM 才剛公開，真正重要的指標將是實際組織採用、權限錯誤發生率、跨模型切換成本、升級維護負擔，以及能否在不暴露敏感資料的前提下完成跨部門協作。
為什麼這件事重要
企業導入 AI 的下一個瓶頸，很可能不是模型智力，而是「誰能讓代理看什麼、做什麼，以及出了問題由誰負責」。個人助理只需處理一名使用者的信任邊界；多人代理卻必須同時理解私人空間、共享專案、公司政策與外部資料來源，任何一次 scope 混淆都可能變成資料外洩。
QM 值得關注之處，在於它把多人協作視為底層架構問題，而非新增一個群組聊天按鈕。每個人與房間分別擁有記憶、檔案、憑證視圖和沙箱，代表「上下文隔離」與「運算隔離」被設計在產品核心。再加上 harness 可替換，企業理論上能在不同模型之間轉移，而不必重建所有 Slack 身分、排程和工作資料。
另一方面，這種平台也會成為新的高價值控制面。集中式 Postgres、公司金鑰、代理稽核紀錄與持久沙箱一旦遭入侵，攻擊者得到的不只是聊天內容，而可能是跨系統行動能力。因此，開源碼只是開始，部署者仍需自行建立最小權限、網路隔離、備份、金鑰輪替、內容來源標示與人工核准程序。
一個反差：AI 寫程式，人類提交文字
QM 的貢獻規則引發社群注意。專案不接受一般形式的外部程式碼貢獻，而是要求貢獻者以人類親筆撰寫的 .txt 或 .md 描述想改什麼；維護者確認方向後，再由專案方處理實作。規則也明確請貢獻者不要讓 AI 把簡單想法膨脹成正式提案。
這反映 agentic development 的新工作分工：當 coding agent 已能快速產生大量程式碼，稀缺資源可能從「誰能打出 patch」轉向「誰能清楚描述真實問題、設計邊界與驗收標準」。同時，這種模式也讓外部開發者較難直接修補錯誤，維護團隊必須證明自己有能力吸收並回應大量文字提案。
接下來該觀察什麼
QM 提供部署 CLI，讓組織建立自己的 deployment repository，並把系統跑在營運者自己的雲端帳戶。這讓資料控制權比全代管 SaaS 更清楚，但也把維運、雲端成本、更新與事故處理責任交還部署者。
未來評估時可持續觀察：
- scope 權限是否有可驗證的繼承與收緊規則
- 外部資料在 Auto 模式下如何標示來源並攔截 prompt injection
- Postgres 中的 session 與記憶能否完整匯出並跨 harness 使用
- 私有 deployment layer 與上游核心同步時，是否容易產生安全差異
- Slack、Web 和背景 cron 是否共享一致的身分與稽核紀錄
- 模型切換是否只是介面相容，還是真能保存工具能力與工作脈絡
Hacker News 的初步反應既有興奮也有懷疑，正好說明多人 Agent 仍處在定義產品邊界的階段。QM 已提出一套具體答案：個人 scope、共享房間、中央政策、持久沙箱與可替換 harness。它是否會成為標準做法，仍要靠真實部署與安全紀錄證明。
多人 AI 的關鍵，不是讓所有人同時對同一個機器人說話，而是讓代理永遠知道自己此刻代表誰、能使用哪些憑證，以及哪些記憶絕不能帶進下一個房間。
網友熱門留言 (4)