qm – 面向工作的多人智能体 harness

贡献模式与 AI 生成代码

• 项目只接受“人工撰写的文本” ADR，而不接受代码 PR。维护者随后实现这些变更，通常会借助他们自己的智能体。
• 许多人认为，这是一种务实的方式，可以避免低质量或 LLM 垃圾 PR，并将重点放在想法和规格说明上，而不是代码审查。
• 也有人觉得这很讽刺，甚至有点“AI 精神病”，因为一个重度依赖 AI 的项目却禁止 AI 撰写的提案；不过也有人指出，这项限制其实针对的是 AI 形式化的规格说明，而不是一般性的 AI 使用。
• 讨论还将其与 SQLite 等同样避免随机代码贡献的项目相比较；几位维护者表示，他们更喜欢详细的 issue，而不是路过式 PR。

“品味” / 反垃圾能力

• 为前端提供的随项目附带的“品味技能”试图避免典型的 AI 风格设计和文案。
• 有些人喜欢把反垃圾规则明确编码进去的想法；另一些人则批评其提示词规模巨大、风格是否定式且带有强指令性。
• 对特定风格标记的禁用（例如某些配色或标点）在一些人看来是过拟合且可笑的；另一些人则认为，这类特征迟早会被反转。

智能体 harness、Hermes 与使用场景

• 讨论将 qm 与 Hermes、类似 Openclaw 的系统以及其他 harness 进行比较。
• 有些人更喜欢像 Hermes 这样功能丰富的 harness；另一些人则偏好最小化、可扩展的设置，或者为了控制力和资源消耗而自己从头搭建。
• 报告中的实际用途包括：值班告警分诊、CI 修复器、RCA 生成、数据库查询优化、收件箱与 RSS/新闻分诊、图表/分析，以及通过 webhook 驱动的内部工具。
• 一个反复出现的担忧是：生成大量智能体代码很容易；难的是审查、追溯来源，以及建立信任。

“多人”智能体与 UX

• “多人”被解读为面向整个组织的智能体和共享房间/作用域，使每个人都有一个可以协作并共享上下文的助手。
• 有些人认为这不过是另一个任务调度器，或者是个华丽的 Slack 机器人；另一些人则认为，受限的共享上下文才是真正的挑战和价值所在。
• 大家对新的 UI 和智能体原语很感兴趣（例如与 UI 绑定的状态模型、基于 MCP 的应用），但很多人指出当前的营销页面都很模糊、也很相似。
• 争论还包括是构建定制 harness，还是使用通用平台；定制化很受重视，但碎片化和“又一个 harness”的疲劳感也很明显。

反馈、创新性与怀疑态度

• 有些人认为 qm 是真实、有用的，也是此前个人 RAG/智能体方案的自然演进。
• 另一些人则认为它过度设计、受炒作驱动、为回应“多人 AI”热潮而仓促推出，或者是在寻找问题的解决方案，本质上只是消耗 token。
• 还有人对安全性提出担忧（智能体拥有用户的全部权限）、它与 Copilot 或 Cowork 等工具的区别不清，以及 YC 更广泛的战略动机。