AI Agent 开始上班了：YC 开源的 qm，让整个团队共用一套 Agent

最难的从来不是让 Agent 干活，而是让五个人的 Agent 在同一家公司里干活还不互相踩脚。 这是 YC 团队开源项目 qm 在 HN 上拿到 465 分的真正原因——它没有发明更聪明的 Agent，它发明了 Agent 的"工位"。

过去两年的 Agent 产品都是个人助手心智：一个终端、一个沙箱、一个上下文。但现实世界的活儿是协作的——代码评审、值班告警、跨部门查询。qm 的切入点很直接：给每个员工一个独立的工作区，再给每个频道、群组和项目一个共享房间，Agent 在这两种空间里都能干活。

HN 评论区里 knighthacker 一句话点破了要害："多人 Agent 最难的问题不是 agent loop，是作用域（scoping）。 QM 的 per-person scopes 加 shared rooms，是公司级助手的一个合理答案。“这篇文章拆解 qm 到底怎么解决这个问题，以及评论区吵翻天的"人类手写贡献"规则是怎么回事。

• 经验一：Agent 协作的瓶颈是作用域，不是智能。 谁拥有什么记忆、谁能碰什么文件、谁的命令能覆盖谁——这些隔离规则比模型能力更决定一个团队 Agent 系统能不能落地。
• 经验二：安全模型要像权限系统一样分层。 qm 提供 Strict / Auto / Dangerous 三档，外加一个任何档位都生效的预声明命令黑名单——危险命令在"最高权限"模式下也杀不掉。
• 经验三：AI 项目开始反向要求"人类手写”。 qm 贡献规则只要人类写的文字提案、不要代码 PR——因为代码可以交给 Agent，但设计意图必须来自人。

〇、元问题：Agent 从"个人助手"变成"团队员工"，什么变了？

单人 Agent 的默认设计是：一个 Agent = 一个上下文 = 一个用户。 它记住你的偏好、操作你的文件、用你的凭据。这套模型在个人场景完美运转——直到你要把 Agent 交给一个团队。

团队场景立刻撞上三个单人模式不存在的问题：

1. 隔离问题：你的 Agent 记住了你的 API key 和草稿，同事的 Agent 也能看到吗？如果 Agent 的沙箱是共享的，一次误操作就是全公司的灾难。
2. 共享问题：完全隔离也不行——团队需要 Agent 在频道里协作，需要它访问共享项目仓库、共同的知识库、值班告警。
3. 信任问题：当 Agent 以"替某个员工干活"的身份执行命令时，公司怎么审计"谁让 Agent 干了什么"？

这三个问题合起来就是作用域（scoping）——它是 Agent 从个人工具进化成团队基础设施时，唯一绕不过去的设计问题。 qm 的价值不在于它的 Agent 多聪明（它甚至不自研模型，而是把 Pi、OpenCode、Codex、Claude Code 全部接入），而在于它对作用域给出了一个完整、可部署的答案。

一、qm 是什么：给 Agent 划工位

qm（“multiplayer agent harness for work”）是一个开源的多人 Agent 工作台，界面在 Slack 和 Web 上。核心设计是双空间模型：

• 个人空间（personal scope）：每个员工拥有自己完全隔离的工作区——专属记忆、文件、密钥、权限、定时任务、Web 应用、持久化沙箱。“人们把 Agent 定制成’自己的’，同时还能在频道和项目里协作。”
• 共享房间（shared rooms）：频道、群组消息和项目各自拥有独立的作用域，成员共享房间里的 Agent、文件和记忆。

每个 scope（无论是人还是房间）都有自己独立的内存、文件、密钥视图、权限、cron、Web 应用和持久化沙箱——沙箱里装好的工具和环境，下次还在。

这个模型回答了第一个问题（隔离）和第二个问题（共享）：个人空间保证隔离，共享房间保证协作，两者通过权限显式连接，而不是靠"一个巨大的共享上下文"糊弄过去。 这正是大多数把单 Agent 直接扔给团队用的产品翻车的地方。

二、架构：不造模型，造基础设施

qm 的架构相当克制——它刻意不做模型、不锁死 harness：

┌─────────────────────────────────────────────┐
│  Slack 插件 (Bolt)      Web UI (Vite + Lit)  │
│  管理面板 (admin)       公共门户 (portal)     │
└──────────────────┬──────────────────────────┘
                   │ HTTP API
┌──────────────────▼──────────────────────────┐
│         Headless Core (Node + Fastify)       │
│   API · 身份 · 策略 · 调度器                  │
│   Agent loop ← Pi / OpenCode / Codex /       │
│                Claude Code 任意切换          │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  Postgres: sessions · memory · queue        │
│  Per-scope sandbox: files · tools · 登录态   │
└─────────────────────────────────────────────┘

关键决策拆开看：

决策一：harness 可插拔，核心保持通用。 所有 Agent 循环（Pi、OpenCode、Codex、Claude Code）驱动同一个核心，部署不绑定任何单一厂商。每个公司的定制（组织配置、自定义工具和技能、沙箱镜像）全部收进一个部署目录（deployment directory），由 qm CLI 校验和部署。背后的哲学：模型和 Agent 会快速迭代，但"谁拥有什么权限"这件事应该稳定。

决策二：Postgres 是唯一的持久层。 sessions、memory、queue 全部落库，Web UI 和管理面板只是核心 HTTP API 的可选插件，Slack 是核心进程内启动的可选插件。状态所有权属于核心，而不是属于某个前端或某个 Agent 进程——这保证 Agent 换 harness、换模型、甚至换 UI 时，团队的记忆和权限纹丝不动。

决策三：沙箱按 scope 隔离，而不是按进程。 每个 scope 的 Agent 在自己的持久化沙箱里执行命令，装好的工具"常住"在沙箱里。隔离的单位是"工作区"而不是"会话"——这是 qm 和"每个 Agent 一个临时容器"方案的本质区别。

三、安全：三档姿态 + 一条不可逾越的底线

安全是 qm 文档里最重的部分。它的原则和本地编码 Agent（OpenCode、Codex、Claude Code）一致：Agent 以"它为之工作的那个人"的身份行动，使用那个人的凭据和权限，并且一切行为都被审计。 组织选择一个安全姿态，更窄的 scope 只能收紧、不能放松：

但真正值得注意的是那条所有姿态下都生效的预声明命令策略（predeclared command policy）：审批规则和硬性拒绝（比如递归删除、破坏性 SQL）在任何档位都不可绕过——“Dangerous"不等于"无底线”。 这条设计回答了信任问题的一半：即使组织选择最宽松的模式，破坏性命令依然是硬墙。

四、争议：AI 项目要求"人类手写"贡献，是倒退还是清醒？

qm 的 CONTRIBUTING 规则在 HN 上吵了 40 多条评论，原文是：

“We take contributions as human-written text, not code. Describe the change you’d like informally in a .txt or .md file in adrs/, and if we’re aligned we’ll handle the implementation.”

翻译过来：贡献者只写人类文字的想法，代码由维护方（和他们的 Agent）来实现。 这条规则把"写代码"和"想清楚要什么"彻底分开了。

评论区的反应两极分化。tptacek 的解读最犀利："他们的意思就是只想要你的 prompt，不想要你的代码。" ronsor 补了一刀：“Coding agents 极其有用，但设计上经常蠢得离谱。如果你不自己设计软件，你大概率会得到 slop——这永远是 vibe coding 的核心问题。” 支持者则说：与其收 5000 个没人理的 slop PR，不如收 50 个想清楚了的需求文档。

这件事本身比 qm 的功能更有意思：当 AI 写代码成为默认，人类的核心产出物正在从"代码"变成"意图"。 贡献规则只是把这个趋势显式化——代码是廉价的，想清楚要什么才是稀缺的。有意思的是评论区立刻有人指出 qm 自己的 README 就是生成的、提交历史里明晃晃挂着 claude 的名字——“一个 AI 写的项目，要求人类手写提案”，这个循环本身就充满了时代感。

五、未来：Agent 协作的下一个瓶颈是"审查"而不是"运行"

HN 上 stephenway 的评论可能是整场讨论里最有前瞻性的：

“真正有趣的挑战不是运行 agents，是审查它们的工作。 代码 Agent 产出越多，provenance（来源追溯）、审查体验和信任就越重要。仓库平台也需要为此进化。”

qm 现在用审计日志和"agent 以本人身份行动"来回应这个挑战，但评论区普遍认为这只是起点。还有两条值得注意的支线：有人指出"Agent 需要新的 UI 原语——现在只是把聊天框塞进一切"，也有人拿 qm 和 Hermes / Openclaw 类的个人 Agent 对比，结论是定位不同：个人 Agent 管你的机器，qm 管你的公司——argssh 的原话是"我宁愿用 Hermes 做 OS 级别的事"。

总结：Agent 的"工位"时代开始了

qm 真正的贡献不是又一个 Agent，而是第一次认真回答了"Agent 怎么在公司里上班"。 它把单人 Agent 的产品哲学（本地、自主、你的凭据）搬到了团队规模，并为此发明了作用域、姿态和部署目录这些"组织学"概念。

当 Agent 写代码成为默认，下一个竞争点就是 Agent 的治理、隔离和协作——而这需要的不只是更好的模型，是更好的组织设计。

🤖 如果你在评估 Agent 工具的团队化落地——

• 你的团队用 Agent 时，是每人各干各的，还是需要一个共享的"公司 Agent"？
• Agent 以员工身份行动时，你的审计和权限模型准备好了吗？
• 你有没有想过：贡献规则应该收"代码"还是收"意图"？

📬 关注梦兽编程，获取更多 AI Agent 与工程效率分析。

参考来源：

• GitHub: qm — Multiplayer agent harness for work 外部链接
• HN: qm – Multiplayer agent harness for work 外部链接