QM — multiplayer agent harness for work
QM — multiplayer agent harness for work
核心判断
qm 值得入库，因为它把“个人助手式 agent”推进到“组织多人协作 harness”：每个用户、房间、项目都有 scoped memory、files、keychain view、permissions、crons、web apps 与 durable sandbox，同时允许 Slack 与 Web 共用同一身份和配置。它对用户的价值不在于今天就替换 Hermes，而在于给 Harness-Engineering 一个更高层的产品/组织形态参照：agent harness 不只负责单次任务执行，也要负责多身份、多空间、权限、背景任务和共享技能治理。
机制 / 一阶原理
QM 的 README 描述了一个 headless core：HTTP API 处理 identity、policy、scheduler；agent loop 可由 Pi、OpenCode、Codex、Claude Code 等不同 harness/model 驱动；Postgres 持久化 sessions、memory、queue；每个 scope 连接自己的 sandbox。这个结构把“模型能力”与“组织运行时”解耦：模型只是 loop 的一个驱动，真正复用的是身份、策略、状态、沙箱和调度层。
它的关键抽象是 scope。个人和共享房间不是共享一个裸 agent，而是拥有各自的 memory、files、credentials 视图、权限与 cron。这样可以降低多人共用 agent 的 blast radius：一个人的偏好、文件和登录态不会自然污染另一个人的上下文；共享 channel 又可以成为项目级协作空间。
与现有 wiki 的关系
- 对 Harness-Engineering：补充了“组织级、多用户、多 scope harness”维度。此前页面更多关注单任务 gate、runtime control、verification membrane；QM 展示 harness 还需要 identity/policy/scheduler/sandbox 作为组织运行时。
- 对 Context-Engineering：QM 的 per-scope memory 是 context governance 的产品化形式，不是把所有组织知识塞给每个 agent，而是按 person/room/project 控制可见上下文。
- 对 External-Agent-Skills-Design-Patterns：shared skills、admin-gated promotion、git skill packs 说明技能需要拥有者、授权、提升路径和组织级分发，而不是只有本地安装。
对 Hermes / llm-wiki 的启发
- 把 profile / thread / category 视为 scope：Hermes 的不同 profile、ConversationSpec、wiki category 应更明确地表达“谁能看什么、能做什么、状态保存在哪里”。
- cron 需要 scope 化：每日雷达、wiki ingest、发布任务不应只是全局后台任务；它们应声明作用域、可访问的 raw/wiki 范围、投递目标和失败恢复策略。
- 技能晋升需要 gate：外部 skill 可以先进入 raw/候选页，经过安全与可用性检查后再进入 active skill；这类似 QM 的 admin-gated promotion。
失败模式 / 未解问题
- README 是产品/架构层说明，尚未验证实际部署、权限实现和 sandbox 隔离强度。
- 组织级 harness 容易把身份、凭证、cron、应用发布集中到一个系统，若 policy 层出错，blast radius 也会变大。
- 多 harness/model 可切换会带来能力差异和行为不一致，需要类似 Agent-Benchmarks 的回归评测。
写入记录
- 2026-08-01 09:06 CST：从 GitHub README 深度入库 QM，提炼组织级 multiplayer agent harness、scope、sandbox、skill promotion 对 Hermes 的启发。