先说结论：QM 在解决“谁的 AI、能看什么、能替谁做事”
个人智能体进入团队后，真正麻烦的不是再接一个模型，而是身份、上下文和副作用。QM 为每位成员与每个 Slack 房间或项目建立独立 scope，各自持有 memory、文件、凭据视图、定时任务、Web app 和持久沙箱；需要协作时再通过共享房间和授权把能力拼起来。底层 harness 也可替换，Pi、OpenCode、Codex 与 Claude Code 都能驱动同一个核心，这使“团队的工作状态”不必完全锁死在一家模型厂商里。
这套架构对中文内容团队很有想象力。选题组可以读取公共信号，作者拥有自己的草稿空间，编辑在共享 room 里审校，运营只拿到测试发布权限；定时任务还可以监控链接失效或数据更新。但想象力不是生产证据。仓库创建仅数日，星数快速增长，第三方讨论仍在追问它相对现有 agent、共享机器人和人工流程究竟提供了多少独特价值。部署不是下载一个桌面应用，还要准备 Fly.io 或 AWS、数据库、对象存储、身份邮件、模型和可能的浏览器服务，并承担持续账单与值班责任。
中文团队应先做“假数据红队”，再谈接邮箱和生产系统
首轮测试可以只放公开稿件与伪造联系人，让三个账号分别扮演作者、编辑和运营。尝试在个人 scope 读取别人的草稿，在共享房间诱导 agent 泄露私有 memory，用网页内容做提示注入，让浏览器执行未再次审批的动作，并检查日志能否还原“谁授权了什么”。随后测试删除账号、撤销授权、轮换凭据和清理制品，观察持久数据是否真的消失。只有这些都能被团队理解和运维，才值得接入真实 Slack、邮箱、云盘或生产仓库。
还要把“审批”拆开看。人类点击允许，只证明接受了当时界面展示的动作，不保证脚本、浏览器页面或模型后续行为安全；审计日志能帮助追责，也不能阻止泄漏。QM 最值得写的角度不是“YC 开源了公司版 OpenClaw”，而是它把多用户 agent 的组织层问题具体化了，同时用一份异常坦率的安全文档告诉团队：权限、凭据、浏览器、数据生命周期与运维，仍然需要自己负责。