Manus 把通用 agent 放在云端跑一次任务。Soloco 把组织放进你本机能控制的运行时——多个 agent 协作、数据不出本机、每一步决策都落本地数据库可回看。
| 维度 | Manus | Soloco |
|---|---|---|
| 运行尺度 | 单 agent，一次任务 | 多个 Claude Code 子进程并行，每个扮演不同角色 |
| 生命周期 | 任务完成即结束 | conductor 跨 cycle 持续推进，goal 闭环前一直在跑 |
| 运行位置 | 云端，统一基础设施 | v0.9 本机部署：runtime / 数据库 / 产物全在你电脑上 |
| 数据归属 | 数据流经 Manus 平台 | workspace / subprocess 日志 / 组织快照全部在本机；只有 prompt 与 response 走你自己的 Claude API 订阅 |
| 介入方式 | 给任务、看结果，中间过程少介入点 | 三档介入：规划 / 审批 / 自动，加 checkpoint + question 通道 |
| 协作主体 | 用户和 agent 一对一 | 多角色 agent 分工，conductor 协调 |
| 审计 | 有限的运行日志 | 每个 spawn / cycle / 评估都落 PostgreSQL，UI 直接回看 |
| 数据/平台锁定 | 组织/数据/产物绑定到平台 | 本机部署形态下，数据库 / workspace 都是你磁盘上的普通文件，可直接接管或迁移 |
Manus 给人留下的核心印象是"它能自己把一个任务跑完"——这是一种很有冲击力的演示，对一次性自动化也确实够用：搜资料、做对比、生成一个报告。任务结束，结果交付。
但很多严肃工作不是一次性的。它需要一个组织一直在那里：每天有进展、出现新信息时能更新方向、有可以追溯的决策记录。这种形态不是"跑一次任务"，而是"持续运行的组织"。Soloco 的核心抽象是后者——conductor 跨 cycle 推进、guard 拦下过早完成、用户回答 question 直接进入下轮 prompt。
Manus 的运行栈在云端，这是体验最简化的方案，但也意味着你的目标、过程、产物都流经他们的基础设施。对个人级的轻量任务问题不大；对涉及内部资料 / 客户数据 / 合规边界的工作，这是一个绕不过去的权衡。
Soloco v0.9 的形态是相反的：整个运行栈跑在你电脑上。Postgres / workspace / subprocess 日志 / 组织快照都是本机文件——你可以随时打开 ~/.soloco/ 接管或迁移。唯一对外的是模型 API 调用，那走的是你自己的 Claude API 订阅，账单和数据条款由你和 Anthropic 直接管理。
当一个 agent 替你做了若干个决策——选择走哪个方向、跳过哪个步骤、采纳哪份资料——你需要能回头解释为什么。Soloco 把这些落表：每一次 spawn 的命令和参数、每一轮 cycle 的评估结果、每一次用户介入与答 question，都在 PostgreSQL 里。UI 上能直接回看，不需要翻终端日志。
偶尔丢一个一次性任务进去看结果——Manus 的极简云端体验是合理选择。
需要本机部署 + 跨多步骤 + 跨多角色 + 决策可回看——这些场景下 Soloco 的形态对得上。两者并不互斥，关注点的差别决定了它们的场景边界。
"一次任务"看的是结果质量。"持续组织"还要看可控性、连续性、可回看——这些是只有把它放进真实业务流程时才暴露的需求。