夜雨聆风📌 全文约 2200 字 · 开源项目深度拆解 · 建议收藏
你有没有想过这样一个问题——为什么所有的 AI Agent 都是"个人助理"？
ChatGPT、Claude、OpenClaw、各种 Agent 框架，全都在解决"一个人怎么用 AI"的问题。但现实是，公司里有一群人。销售要用 AI 写邮件，工程师要让 AI 跑测试，运营要 AI 盯数据——这些需求互相独立，又互相交叉。
给每个人装一个独立的 Agent？数据散了。装一个公共的？权限乱了。
最近在 GitHub 上发现了一个项目，它从根上设计了一套不一样的架构：每个人有独立工作空间，又能在频道和项目里协作。
项目叫 QM，定位是 "Multiplayer agent harness for work"——工作场景下的多人 Agent 框架。
🔗 项目地址：github.com/yc-software/qm
01 · 它到底解决了什么问题
先说结论：QM 解决的是"Agent 从个人工具变成组织基础设施"的架构问题。
市面上大多数 Agent 框架的默认假设是：一个用户，一个 Agent，一个会话上下文。这在个人使用场景下完全够用。但当你试图把 Agent 推广到整个团队时，问题立刻出现：
· 张三的 Agent 记住了他的代码仓库，但李四看不到
· 王五在频道里 @Agent 问了个问题，Agent 的回复所有人都能看到，但它调用的数据来自谁的上下文？
· 管理员想控制哪些人能用哪些模型、哪些工具，发现根本没有权限层
QM 的做法是引入"作用域（Scope）"的概念。每个人有个人作用域，每个频道有共享作用域。作用域之间互相隔离：记忆、文件、凭证、定时任务、沙箱环境，全部按作用域切割。
💡 简单理解：QM 给每个员工分配了一个"AI 工位"，工位之间隔音，但走廊（频道）里可以一起开会。
这个设计直接解决了三个核心痛点：数据隔离、权限控制、协作与独立共存。
02 · 架构拆解：它怎么做到的
QM 的技术架构可以用一句话概括：一个 Headless Core + 可插拔插件 + 按作用域隔离的沙箱。
拆开来看三层：
核心层（Headless Core）：TypeScript 写的头部核心，跑在 Node.js 上，用 Fastify 处理 HTTP 请求。负责身份认证、权限策略、任务调度、Agent 循环。所有逻辑通过统一 API 对外暴露。
持久化层：PostgreSQL。存储用户数据、会话历史、记忆、定时任务队列、审计日志。所有状态都是持久化的，进程重启不丢数据。
沙箱层：每个作用域有自己独立的沙箱环境——文件系统、安装的工具、登录态。Agent 在沙箱里执行命令，互不干扰。
最有意思的设计是模型和 Harness 解耦。QM 支持 Pi、OpenCode、Codex、Claude Code 四种 Harness 驱动同一个核心。你可以今天用 Claude Code，明天切到 Codex，部署不绑定任何供应商。
💡 类比：QM 像一个操作系统内核，Harness 是可替换的"驱动程序"，模型是"CPU"。你不会因为换了个 CPU 就重装整个系统。
前端方面，Web UI 用 Vite 构建、Lit 渲染；Slack 集成用 Bolt 框架，作为核心进程内的插件运行。同一套身份和配置在 Slack 和 Web 之间打通。
03 · 安全模型：三级姿态 + 审计全链路
企业级 Agent 最大的顾虑是什么？安全。Agent 拿着员工的权限去操作，万一执行了不该执行的东西怎么办？
QM 设计了三档安全姿态，组织选一个基线，下级作用域只能收紧、不能放松：
Strict（严格模式）：Agent 每次调用工具都要人工审批，除了结束对话的两个操作不需要
Auto（默认模式）：一个分类器自动筛查外部数据和工具结果，有嫌疑的拦截或转人工。企业可以指向自己的安全代理
Dangerous（危险模式）：不筛查、不暂停。但预声明命令策略（禁止递归删除、破坏性 SQL 等）仍然生效
有三类操作被刻意排除在 Agent 自身 API 之外，只能在 Web 管理后台执行：
· 管理员权限变更——防止被注入的 Agent 自己提权
· 身份伪装——Agent 永远以当前用户身份行动，没有"切换身份"接口
· 命令审批——人工审批决策不能被 Agent 自动绕过
这三个设计直击 Agent 安全的核心矛盾：任何能授权未来行为的决策，必须来自 Agent 外部。
另外，QM 还有 npm 依赖冷却期机制：新发布的 npm 包必须等 7 天才能进入 lockfile。这是为了防范供应链攻击——恶意版本被发现和下架通常在几小时内。
04 · 贡献模式：不要代码，要想法
QM 的贡献方式很反直觉：他们不接受代码 PR，只接受文字描述。
在 CONTRIBUTING.md 里写得很明确：他们更希望你把想法写成一个 .txt 或 .md 文件放到 adrs/ 目录下，像跟同事聊天一样描述你想改什么。如果团队觉得方向对，他们自己用 AI 写代码。
这个策略背后的逻辑是：AI 写代码已经足够好了，人类写代码的瓶颈不在"打字"，在"想清楚要做什么"。与其让贡献者花时间写完美的代码再被 review，不如直接对齐意图。
💡 这是一个值得关注的趋势：开源项目的贡献门槛从"会写代码"降低到"会描述需求"。产品经理和领域专家可以直接参与。
对于想私有化部署的公司，QM 提供两条路：
部署目录模式：创建一个依赖 @yc-software/qm 的独立仓库，用 qm CLI 初始化，所有定制内容放在部署目录里。核心代码零修改。
私有 Fork 模式：用 git clone --bare 镜像到一个私有仓库。组织定制内容放在 deploy/layers/<org>/ 下，核心代码保持与上游字节一致。两个内置 Skill（update-qm 和 upstream-pr）负责双向同步。
05 · 实际用起来能干什么
根据 README 和项目结构，QM 能落地的工作场景包括：
· 统一搜索：跨内部文档、邮件、数据库、网页搜索，Agent 帮你一次找齐
· 代码协作：在已有仓库里跑测试、开 PR、监控 CI、查系统日志
· 邮件分类：学习你的写作风格，按计划处理收件箱，打标签 + 起草回复
· 内部应用：构建内部 Web 工具，发布给指定人员，数据自动更新
· 项目跟踪：在共享频道里跟踪项目进度，自动发送更新和提醒
· 后台任务：定时任务和监控任务在后台跑，没人盯着也持续工作
技术栈方面，核心依赖包括 Anthropic Claude Agent SDK、OpenAI Codex、OpenCode SDK、Slack Bolt、Fastify、PostgreSQL（pg + pg-boss 队列）。版本 0.1.0，MIT 协议，Node ≥ 24.15.0。
06 · 我的判断
看完整个项目，说几个直观判断：
方向对了：多人协作 Agent 是被验证过的需求。Microsoft Copilot for M365 在做类似的事，但它是封闭生态。QM 提供了开源的、可私有化部署的替代方案。
架构成熟度：作用域隔离、Harness 可替换、安全三级模型、审计全链路、依赖冷却期——这些设计在 0.1 版本里出现，说明团队一开始就想清楚了企业级需求。45 个 Issue、69 个 PR 的活跃度也不像玩具项目。
落地门槛：需要 Postgres、Node 24+、Slack App 配置或 Web 部署。对有运维能力的创业团队来说不算高，纯前端团队可能需要一些基础设施学习成本。
适合谁：10-200 人的创业团队，已经在用 Slack 协作，想让 AI Agent 真正融入工作流而不是停留在"每人一个 ChatGPT"的阶段。
🔥 Agent 的下一个战场，不在"更聪明的模型"，在"让一群人各用各的 Agent，又能一起干活"QM 把这个问题从架构层面解决了：作用域隔离数据、共享频道协作、Harness 可替换、安全可分级个人 Agent 解决效率问题，组织 Agent 解决的是协作问题
📌 项目地址：github.com/yc-software/qm · MIT 协议 · Star 支持 ⭐
觉得有用，转发给你的技术合伙人 👇
往期文章：
上线小程序的一次全量审计：它先删了我自己写的云函数，然后才谈新功能