QM: 多玩家代理工具套件用於工作

QM 是一個多玩家代理工具套件，旨在將 AI 代理從個人助理移轉為組織工具。它允許初創公司的員工維持隔離的個人工作區，同時在共享頻道、群組訊息和專案中與代理協作。

範圍記憶與協作環境

QM 透過實作範圍架構來解決公司範圍代理部署的複雜性。與單一單體代理不同，QM 為資料和權限提供了明確的邊界：

  • 個人範圍： 每位使用者擁有隔離的工作區，包含他們自己的記憶、檔案、鑰匙鏈視圖、權限和持久沙盒。
  • 共享範圍： 代理可以在 Slack 頻道和專案中運作，其中記憶和工具在群組間共享。

此結構確保使用者可以根據自身需求自訂代理，而不會影響同事，同時仍能利用代理進行團隊範圍的協調。

技術架構與模型不可知性

QM 被構建為一個無頭核心，將代理邏輯與介面及底層 LLM 分離。

核心組件

  • 無頭核心： 使用 TypeScript (Node.js) 和 Fastify 編寫，該核心負責管理身份、政策和排程。
  • 代理迴圈： 系統具有模型不可知性，支援各種工具套件，如 Pi、OpenCode、Codex 和 Claude Code。這透過允許操作員在不更改核心部署的情況下切換模型來防止供應商鎖定。
  • 持久層： Postgres 資料庫儲存會話、記憶和任務佇列。
  • 每範圍沙盒： 每個範圍擁有一個持久沙盒（一個「持久電腦」），代理可透過 execute 工具在此執行指令。此沙盒中安裝的工具會跨會話持續存在。

介面外掛

該核心提供 HTTP API，允許各種介面插入：

  • Slack： 使用 Bolt 的可選內嵌外掛程式。
  • Web UI： 基於 Vite 的前端，使用 Lit 進行渲染。
  • 管理面板 & 公共入口： 用於組織管理的可選外掛程式。

安全姿態與密鑰管理

QM 採用一種安全模型，其中代理代表使用者行事，使用該使用者特定的憑證和權限。為管理風險，管理員可以設置以下三種安全姿態之一：

  1. 嚴格： 每次工具呼叫都需要人工批准，除非是結束回合的指令。
  2. 自動（預設）： 分類器在外部數據和工具結果到達模型之前進行篩選。
  3. 危險： 不進行內容篩選或在工具呼叫之間暫停。

無論採用哪種姿態，預先宣告的指令政策會對破壞性操作（如遞迴刪除或破壞性 SQL 查詢）施加嚴格的拒絕。

部署與自訂

QM 設計為可在操作員自己的雲端帳戶內部署（支援 AWS 和 Fly.io），以確保資料主權。

部署選項

  • 標準部署： 使用 qm CLI，使用者可以初始化一個管理基礎設施和連接器憑證的部署倉儲，而無需完整的原始檔案簽出。
  • 私人分支： 對於需要深度自訂的組織，QM 支援私人分支策略。透過建立一個普通的複製（而非 GitHub 分支），並將組織特定的配置放置在 deploy/layers/<org>/ 中，團隊可以保持他們的自訂為私有，同時保持與上游核心位元組相同，以便更輕鬆地合併。

實際使用案例

QM 能實現多種高杠桿的組織工作流程：

  • 公司腦部檢索： 同時搜索內部筆記、電子郵件、文件和資料庫。
  • 收件匣分類： 從過去的電子郵件學習使用者的寫作風格，以草擬回覆並按計劃標記收件匣。
  • 倉儲管理： 在程式碼庫內直接執行測試、開啟 PR 和監控 CI/CD 日誌。
  • 內部應用發布： 建立自訂內部網頁應用並將其部署到特定使用者群組。

社群見解與觀點

圍繞 QM 的討論凸顯了多玩家代理的潛力以及當前 AI 環境的挑戰。一些開發者指出，多玩家代理的困難通常不在於迴圈本身，而在於「範圍」內容和權限——這正是 QM 明確解決的問題。

然而，一些批評者對「多玩家」代理的實用性表示懷疑，質疑它們是否只是複雜的工作排程器，或是否會導致「代理對代理交談」而不產生實質成果的循環。此外，亦有顯著討論關於 QM 的獨特貢獻模型，該模型要求人類撰寫文字描述變更，而不是程式碼 PR，以避免 AI 生成的「雜質」。

"多玩家代理中最難的問題……並非代理迴圈。而是範圍，而 QM 的每人範圍加上共享房間是一個適用於公司範圍助理的合理答案。"

"我給了一個代理自己的 Slack 頻道，它開始在未經我同意的情況下與其他代理安排會議。我從未感到自己如此像中層管理。"

Sources