yc-software在GitHub上开源了一个叫QM的项目，MIT许可证，定位是“给工作场景用的多人协作Agent框架”。它同时接入Slack和Web，用TypeScript、Node、Fastify和Postgres搭建核心，模型和执行框架（harness）可以在Pi、OpenCode、Codex、Claude Code之间切换。
这类项目一年能看到几十个，QM值得单独说一说的原因不是它支持哪几个模型，而是它对“企业Agent到底该长什么样”给出了一个和主流做法不太一样的答案：不是一个服务全公司的超级助手，而是每个人、每个协作空间各自有一份独立的记忆、权限、文件和沙箱。
权限隔离才是这个项目的正题
市面上大多数Agent产品的逻辑是“一个助手，权限越开越大”。QM反过来做：员工个人有自己隔离的工作空间，互不干扰；进了Slack频道或项目群，又能和同事共用一个协作空间。每个人和每个房间各自拥有独立的记忆、文件、密钥视图、权限、定时任务和持久沙箱——这意味着同一个Agent核心，在不同场景下其实是不同的“执行身份”。
这套设计解决的是一个真实痛点：企业内部Agent一旦权限统一，出问题的责任也统一——一个人的越权操作，牵连的是全公司数据。QM把这个风险切碎到“人”和“房间”两个粒度上，至少让权限边界变得可追溯。
- 结论.QM真正的创新点在于把身份和记忆按场景拆分，而不是又换了一个更聪明的模型。
可替换模型不是免费的护城河
QM文档强调“不绑定单一供应商”，Pi、OpenCode、Codex、Claude Code都能接到同一个核心上。这和Codex、Claude Code、OpenCode这类偏个人本地使用的编码Agent形成一个对照：后者基本是单人单机跑，QM把同样的执行框架搬进了组织级、多用户、多空间的场景。
但“可换模型”不等于“零迁移成本”。不同harness驱动同一个核心，输出风格、工具调用习惯、稳定性并不天然一致，换一个模型仍要重新验证行为。而且QM本身依赖Postgres、云资源、外部连接器，这些依赖不会因为模型可替换就消失。
自托管把安全和运维都留给了你
QM提供Strict、Auto、Dangerous三种安全姿态，从每一步操作都要人工审批，到完全不做内容筛查、不暂停。默认是Auto，靠分类器筛查外部内容再交给模型处理。命令层面的硬性拒绝（比如递归删除、破坏性SQL）在任何姿态下都生效。
这套机制听起来完备，但项目文档里写得很清楚：SECURITY.md里有威胁模型、运营假设和已知限制，凭证管理、外部内容筛查、审计日志、云端部署，都是操作组织自己的责任。初始化流程不会生成或启用部署CI，仓库本身没有生产部署工作流——这意味着从代码开源到系统能安全跑起来，中间那段路得团队自己走完。
开源交出的是代码，不是安全担保。
还有一个容易踩的坑：官方文档特别提醒，想要私有定制版本，正确做法是普通克隆后新建私有仓库，而不是用GitHub的Fork功能——公开仓库的Fork继承公开可见性，无法直接转私有，而且Fork和原仓库共享对象网络，提交内容仍可能被追溯到。普通克隆没有这个问题，代价是upstream的CI工作流会在自己的账户里真实运行，需要自己补密钥或手动关闭。
- 风险.自托管意味着凭证、审计和云资源配置全靠团队自己搭建和维护，出问题没有厂商兜底。
对正在评估内部Agent基础设施的初创公司CTO和工程团队来说，QM提供的是一个可以拿来改的骨架，不是一个装完就能用的产品。要不要接，取决于团队有没有余力把安全姿态、凭证管理和沙箱运维这几块自己填满。