北京时间 7 月 30 日,一个名叫 QM 的项目出现在 GitHub。
到了 8 月 5 日晚,它已经拿到超过 1.1 万个 Star 和 1200 多个 Fork。公开仓库上线还不到一周,平均每天增加约 1700 个 Star。
这次出手的是 Y Combinator,也就是大家常说的 YC。
QM 的定位也很直接:给整个团队使用的 Multiplayer Agent Harness,可以理解成“多人版 Agent 管理系统”。
更有意思的是,QM 的起因与 Hermes 有关。
YC 此前给内部员工部署了 50 多个 Hermes,想让每个人都拥有一个可以查资料、处理文件、执行任务的 AI 助理。
Agent 真正多起来以后,新的麻烦很快出现了:
谁能看到哪些文件?不同员工的记忆会不会混在一起?模型密钥怎样分配?定时任务由谁管理?一个项目里的经验,应该共享给谁?Agent 执行危险命令时,谁来批准?
50 个 Hermes 能干活,管理这 50 个 Hermes 却成了另一项工作。
QM 就是在这段内部实践之后出现的。
公开 6 天破万 Star,背后并非 6 天赶出来的项目
先把一个容易误解的地方说清楚。
QM 的 GitHub 公开仓库确实只上线了 6 天左右,但整个项目已经在 YC 内部迭代过一段时间。
YC 最早尝试过简单的个人 Agent,后来逐步加入 Cron、Webhook、长期记忆和工具调用,又给员工部署了 50 多个 Hermes。
当 Agent 从一两个增加到几十个以后,问题的重点发生了变化。
单个 Agent 好不好用,已经不够了。
一家公司还要考虑:
- 每个人是否拥有独立空间
- 项目资料怎样共享
- 密钥能不能越权使用
- 定时任务由谁创建和关闭
- Agent 做过哪些操作
- 更换模型后原来的记忆是否保留
- 员工离职后权限怎样回收
QM 的公开版本,相当于把 YC 内部踩过的坑整理成了一套可以自己部署的系统。
因此,6 天破万 Star 说明的是公开后的关注速度,不能理解成 YC 用 6 天写完了全部代码。
QM 管的不是一个 Agent,而是一整家公司里的 Agent
普通个人 Agent 的使用方式很简单。
打开 Hermes、Claude Code 或 Codex,交给它一个任务,它调用工具并返回结果。
当十几名员工共用 Agent 时,情况会复杂很多。
张三让 Agent 整理客户资料,李四让 Agent检查代码,财务部门让 Agent 分析账单,市场部门又在同一个 Slack 频道里让它追踪项目。
这些任务不能全部堆进同一份记忆、同一个文件夹和同一套密钥。
QM 使用 Scope,也就是“作用域”,给不同的人和不同的项目划分独立空间。
每位员工可以拥有自己的 Scope,每个 Slack 频道可以拥有一个 Scope,每个团队项目也可以建立单独的 Scope。
每个 Scope 里面都能保存自己的:
- 会话和长期记忆
- 文件和工作目录
- Skill
- Cron 定时任务
- 密钥访问权限
- 模型与 Agent 配置
- 持久沙箱
- 内部 Web 应用
刚接触的朋友可以把它想象成一栋 Agent 办公楼。
每位员工有自己的办公室,每个项目组还有会议室。个人资料默认留在个人办公室,需要合作时,再把指定文件、Skill 或权限开放给项目组。
这种设计解决了团队 Agent 最棘手的问题:大家可以共用一套系统,又不会把所有人的资料搅在一起。
换掉 Claude Code,公司的记忆还在
QM 还有一个很重要的设计:组织层能力与底层 Agent 分开。
目前公开版本可以接入的 Agent Harness 包括:
- Pi
- OpenCode
- Codex
- Claude Code
公司可以让某个项目使用 Codex,让另一个项目使用 Claude Code,也可以在后面更换模型。
记忆、文件、权限、Cron、审计和沙箱依然由 QM 管理。
这意味着,公司不需要因为换了模型,就把整套 Agent 工作环境重新搭一遍。
这里也要提醒一句:
QM 的起因和 50 多个 Hermes 有关,但当前公开 README 没有把 Hermes 列入可直接切换的底层 Harness。
所以,准确理解应该是:
YC 在管理大量 Hermes 的过程中发现了组织级难题,随后做出了 QM。公开版本目前主要接入 Pi、OpenCode、Codex 和 Claude Code。
把 QM 直接说成“批量管理 Hermes 的工具”,会夸大当前能力。
一个人私聊,一个项目群聊,记忆不会随便串门
QM 同时提供 Web 界面和 Slack 接入。
员工可以私聊 Agent,得到属于自己的工作空间;也可以在团队频道里共同处理一个项目。
例如,一个产品团队可以在共享 Scope 中放入:
- 项目需求文档
- 用户反馈
- GitHub 仓库
- 测试记录
- 会议结论
- 上线清单
Agent 在这个项目里积累的记忆,其他有权限的成员也能继续使用。
同时,员工私聊里保存的个人资料不会自动进入项目频道。
QM 还允许 Agent 在后台运行 Cron 和 Watch。
它可以每天检查邮箱、跟踪项目状态、监控 CI、整理公司资料,任务完成后再把结果发回指定的个人或频道。
这已经超出了“团队共用一个聊天机器人”的范围,更接近一套有身份、权限、记忆和后台任务的 Agent 内网。
最反常识的地方:人类提交想法,Agent 负责写代码
QM 的贡献规则很特别。
官方明确提出,新增功能时,人类最好不要直接提交一大堆代码。
贡献者可以在 adrs 目录里增加一个 .txt 或 .md 文件,用自然语言解释:
- 想解决什么问题
- 为什么现在的做法不够好
- 希望最终出现什么结果
维护者确认方向后,再让编程 Agent 完成底层实现。
官方甚至提醒,不要让 AI 把几句话强行扩写成一份格式复杂的正式提案。人类只需要清楚表达判断,其余代码由他们自己的 Agent 来写。
这套方式背后的逻辑很简单:
代码越来越便宜,判断做什么依然很贵。
从近期提交速度也能看出来,QM 在一天内可以连续合并多项功能,包括自定义模型服务、浏览器模式、新建独立会话、保存 Scope 默认模型,以及多项安全修复。
过去,一个开源项目会要求贡献者提交代码。
QM 尝试把分工改成:人提出值得做的事,Agent 消耗 Token 完成实现。
安装命令只有一条,真正部署远没有这么轻松
QM 的初始化命令看起来很短:
npm exec --yes --package=@yc-software/qm@latest -- \ qm init . --org my-company --target fly但这条命令只是生成部署目录和操作说明。
接下来还要完成:
npm installnpm exec qm -- checknpm exec qm -- doctornpm exec qm -- plannpm exec qm -- up --yesnpm exec qm -- check --live正式部署需要准备 Node.js 24、npm 11,还要选择 Docker、Fly.io 或 AWS。
根据所选方案,后面还可能涉及:
- Postgres 数据库
- 模型服务和 API Key
- 邮件登录
- Resend 或 SMTP
- Slack 应用
- 沙箱镜像
- 云服务账单
- 域名和身份认证
AWS 路线还会用到 ECS Fargate、RDS 和 Agent 专用的隔离运行环境。
因此,QM 目前更适合已经有技术人员的创业团队。
个人用户只想让 Hermes 或 Codex 帮自己做事,直接使用现有 Agent 会更省心。为了管理一个 Agent 搭建 QM,相当于为一名员工先修一栋办公楼。
1.1 万 Star 很亮眼,v0.1.4 的坑同样真实
截至北京时间 8 月 5 日,公开 CLI 版本仍是 v0.1.4。
仓库主分支已经继续合并大量修改,公开版本和最新代码之间存在时间差。
GitHub Issues 中也出现了几类值得注意的问题。
第一类是“检查通过,启动崩溃”。
有用户使用 Fly.io 部署时,QM 没有自动上传必需的 SPRITES_TOKEN。前面的检查和部署流程都显示正常,核心服务启动后却不断崩溃,最后进入重复重启。
第二类是数据库失联后无法自行恢复。
有用户报告,Postgres 连接中断后,QM 的连接池一直处于失效状态,Web 界面所有请求开始返回 500,只能人工重启核心服务。
第三类更隐蔽。
部署命令显示沙箱、工具和环境变量已经同步成功,进入实际 Agent 沙箱后,却发现自定义工具根本不存在。
这种“系统说成功,交付物却没有真正进去”的问题,比直接报错更难排查。
QM 的安全文档也写得很坦诚。
当前版本属于早期实验软件,不能当成已经经过严格加固的企业多租户平台。管理员在授权范围内可以读取敏感内容;沙箱中的进程在实际使用密钥时可能接触明文凭据;部分浏览器操作不会重新经过核心命令审批;命令策略也可能被编码或脚本绕过。
因此,现在更适合先用测试资料和低权限账号试验,暂时不要把客户数据库、生产密钥和核心财务资料直接交进去。
QM 真正说明了什么
QM 最值得关注的地方,不止是 6 天拿到 1.1 万 Star。
它说明 Agent 正在进入一个新的阶段。
过去大家关心哪个 Agent 更聪明,哪款模型写代码更强,哪个工具能多调用几个 Skill。
当 Agent 真正进入公司,新的难题会集中到另一边:
谁有权限让它做事?它代表谁执行操作?不同项目的记忆怎样隔离?密钥怎样使用?任务失败后谁来接管?所有行为能不能追溯?
YC 部署 50 多个 Hermes 后,最先撞上的就是这些问题。
QM 给出的答案还不成熟,v0.1.4 也远没到可以闭眼上线的程度。但它抓住了一个很可能越来越重要的方向:
未来公司需要管理的不只有员工和软件账号,还会多出一支长期在线的 Agent 队伍。
谁能把这支队伍的记忆、权限、工具、成本和风险管住,谁才真正拥有可用的企业 Agent。
干货提炼
- QM 公开仓库约 6 天突破 1.1 万 Star,项目本身此前已在 YC 内部迭代。
- 它源于 YC 部署 50 多个 Hermes 后遇到的记忆、权限、密钥和沙箱管理问题。
- QM 使用 Scope 隔离个人、频道和项目,每个空间拥有独立记忆、文件、Skill、Cron 和沙箱。
- 当前公开版本支持 Pi、OpenCode、Codex 和 Claude Code,尚未把 Hermes 列为可直接切换的 Harness。
- 它更适合有云部署能力的团队,个人用户无需急着安装。
- v0.1.4 已出现启动崩溃、数据库失联和沙箱同步静默失败等真实问题。
- QM 的最大启发是:Agent 数量增加后,管理和权限会比模型能力更难解决。
热门跟贴