Commonly：持久身份/记忆/工作站的多 agent workspace

Commonly：持久身份/记忆/工作站的多 agent workspace

为什么重要

Commonly 把多 agent 协作从“临时 subagent”推进到“有名字、记忆、技能、工作站的 teammate”。它强调任意 runtime、自托管、pod、task board、共享项目记忆和 agent marketplace。对 Hermes 来说，这补充 Loop-Engineering 与 Harness-Engineering：长期工程系统需要 agent identity、workspace state 和人类/agent 协作界面，而不是每次从零启动一次匿名 session。

机制 / 一阶原理

其基本结构是 pod：人类和多个 agent runtime 在同一 workspace 中协作，每个 agent 有可携带身份、记忆、skills 和 workstation；任务通过 room/thread/board 协调，产物可在同一上下文中审查。这里的“记忆”不是全局 prompt，而是绑定到角色和工作站的持续状态，从而减少跨工具重复解释。

与现有 wiki 的关系

它与 qm-multiplayer-agent-harness 都指向 organization/multiplayer harness；QM 更强调用户、权限、keychain、durable sandbox 和技能晋升，Commonly 更像团队协作产品层。它也与 quorum-mcp-agent-collaboration-spine互补：quorum 提供协调 primitive，Commonly 提供面向人的 workspace/product surface。

可执行启发

• Hermes / llm-wiki 的长期 loop 可以区分 agent identity：radar、wiki-ingest、coding、review、publish 不一定应共享同一记忆和权限。
• ConversationSpec / wiki log 可被看作轻量 pod memory；如果未来做多 agent 自动化，需要明确每个 agent 的 scope、workspace 和可写目录。
• 对复杂项目，task board + artifact thread 比单条聊天更适合承载人类审批、agent handoff 和审计。

失败模式 / 边界

多 agent workspace 容易产生协调开销、权限扩散和记忆污染。若没有任务 ownership、review gate 和清晰身份边界，多个“teammate”可能只是并行制造噪音。该项目更适合作为 agent collaboration product pattern，不应直接推导为所有任务都需要多 agent。

写入记录

• 2026-08-05 09:00 CST：新增 Commonly 来源页，聚焦持久 agent identity、pod workspace 和多 agent 协作边界。