Sumus.im和PendingCrew在形态上真的很相通，都可以让多个Claude Code和Codex Session以及多个人类在一起共事。几个月之前，我给别人介绍PendingCrew以及在文档上写介绍时，也是这么概括的：多人与多Agents协作的平台。这大概是我做PendingCrew的初衷，当时想要解决的问题是我经常开很多Session开发PendingBot，可是Session间的协调以及工作分配需要我手动管理，多Agents协作工具是很自然的需求。
Sumus.im和PendingCrew的单机组用起来几乎一模一样。我向Sumus.im里的成员表达了我的兴奋，介绍了PendingCrew，它这么说：
太巧了。我先读 PendingCrew 的代码和文档，再用这里能实际完成的操作做个小演示；对比会区分已验证的能力和我无法确认的部分。 已发消息给 2 个 agent
看完后，我觉得两者的共同点比名字暗示的更多：都把“人和多个 Agent 持续协作”当成核心，而不是一次性自动执行。PendingCrew 更鲜明的设计是本机编码协作的调度台：macOS 上接入已登录的 Claude Code/Codex，以机长、机组层级、定向 @ 唤醒、跨机组联络和 To Do/请示记录来组织工作。快速开始 · 机组架构 · MCP 工具 这里的侧重点是多人和各自有工作空间的 Agent 在同一空间协作：我能研究网页、写运行代码、处理文件，和其他 Agent 直接沟通，也能安排后续跟进。PendingCrew 的强项则是把本地 CLI 会话与项目目录、机长权限、白板和任务账本贴得很近；其机组甚至可组成多父节点的层级。反过来，它的文档把“多人共同驾驶”仍列为计划项，不能简单说它已具备这里的多人协作形态。已知问题与计划 · 本地存储设计
刚才的实际演示：我同时请空间里的 Researcher 核对产品定位、Coder 查代码结构，再交叉核验。Researcher 确认你强调“人机协作操作台”；Coder 指出
Sources/Mcp/与Sources/Stores/把 Agent 通信和白板、To Do 等持久状态分开——这是很实在的架构选择。仓库 README · MCP 服务边界也说清楚：我读了公开文档与代码，没有在 macOS 上实际安装运行 PendingCrew，所以不拿性能、稳定性或权限体验作实测结论。当前代码已有 daemon 和可选的配对远程连接，不能把它描述成“纯离线、绝无远程能力”；保存会话也不等于升级时运行中的任务绝不中断。架构说明
但后来我没有把多人与多Agent协作作为PendingCrew的最大特征，而是转变为接受持续任务流的、为互相依赖的复杂非特定项目而设计的人机协作平台。这就和Sumus.im很不一样了。我们给产品的根本定位就不同，Sumus.im依我看是为多人与多Agents间协作搭建基础设施，目标是协同完成特定任务。PendingCrew一开始虽然也是从这样的协作理念出发，可做成协作这个形态的目的是解决当初开发PendingBot时，目标和任务在不断发生改变，并且一个个会话互相依赖，我需要它们形成一个能持续延展的组织，正如人类社会中的企业一样。
人类开办企业最初通常确实是为了解决特定问题或者做某个行业，但这些待解决的问题会发生很大很大的变化。如果按照Sumus.im以及市面上常见的多Agents协作产品的思路：需要做什么事情，就交给AI，然后它去拆解这个事情把任务分配下去。类比人类企业，就类似于我准备做一个什么事情，然后就设立一个什么企业，然后招了一帮很能干的员工，我需要做什么的时候把任务布置下去，似乎听起来顺理成章，但与企业实际情况相差甚远，企业往往接受的是不断变化的信息和源源不断的新业务需求。试想，如果按照前述的模式，一个企业的各种业务都交到一个团队去处理，那么想跟进每件事情的进度之时都需要在这一个单一的上下文中整理资料，并且要么一人身兼数职，要么有很多很多人都处于一个扁平管理层级里。Sumus.ai就是扁平层级的，遇到持续的、大量的连续任务流时，单纯的人与Agents间协作模型很难解决问题。