一句话结论：Tutti 是七个样本里唯一把"多人"写进定位的项目，也是发布纪律最好的——star 最少（3.6k）、建仓最晚（2026-06-12），却连续 8 个 release 全是正式版。它把"让多个 agent 在同一工作区里共享上下文、接力干活"做成了产品，用 ACP 协议层 + runtimeprep 运行时准备层的双层架构真真切切接了引擎（全仓 363 个文件引用 ACP）。但有两件事必须说透：第一，引擎接入深度严重偏袒 Codex（2170 行 vs Kimi 127 行，17 倍差距，且只有 Codex 做了 Windows 适配）；第二，宣传的"多人协作"七项功能（Group chat / 多人同屏 / 跨设备 / agent 借用 / 免部署分享……）全部在闭源 VM 版，开源版一格 ✓ 都没有，且 VM 版需邀请码。Apache-2.0 保证了你能自由改代码，不保证你能用到它宣传的完整体验。

0. 先给结论

三个有意思的点：

1. 发布纪律是七个样本里最好的——最近 8 个 release 全部 prerelease=False（v0.2.25 → v0.2.31），且维护了一个 stable 滚动 tag（始终指向最新稳定版）。对比：OpenClaw 版本号倒挂（9.1-beta 早于 8.1 正式）、QwenPaw 全是 beta、Maka 无 release。star 数最少的 Tutti 反而是唯一持续发正式版的——star 数与工程成熟度在本体系的七个样本里呈负相关。

2. 双层引擎架构是七个样本里没有的分层——第 1 层 acp_provider_*.go（ACP 协议适配）负责"怎么和引擎对话"，第 2 层 runtimeprep/（运行时准备）负责"怎么让引擎跑起来"（配置注入、skill 装配、模型缓存、目录同步、Windows 兼容）。全仓 363 个文件引用 ACP，是真集成不是营销词。

3. 后端用 Go 而不是 Node——守护进程 tuttid 和 CLI 都是 Go 写的（45.4%），这是它和其余 Electron 系样本的关键差异。Go 的并发模型和稳定性更适合做"多 agent 同时写同一批文件"的 daemon 层。

三个最大的问题：

1. 引擎接入深度严重不对等——Codex 16 文件 2170 行，Kimi 1 文件 127 行，17 倍差距。且只有 Codex 有 Windows 变体文件（4 个 _windows.go），其余引擎在 Windows 上一个字都没写过。测试密度更反常：Codex 0.12（最低）vs OpenCode 0.56（最高），Kimi / ComputerUse / BrowserUse 测试为零。投入最重的地方恰恰是保障最薄的地方。

2. 宣传的"多人"全在闭源侧——README 的 "Two Versions of Tutti" 对照表明确：Group chat / Work with others / Work with others' agents / Simultaneous editing / Agent borrowing / Across devices / No-deploy sharing，七项全部是 VM 版专属，开源版一格 ✓ 都没有。而 VM 版是 Early Access，创建 Room 需要邀请码。开源版里 Big @ 只能在"你自己的 agent 之间"引用，跨人引用要 VM 版。

3. README 支持列表与代码对不上——宣称"当前支持"的 Hermes，代码里没有 hermes.go（走的是 RTK Python 插件机制，不是原生 adapter）；宣称"in development"的 OpenClaw 确实只有 52 行零测试；但 Cursor / OpenCode / Kimi / ComputerUse / BrowserUse 在代码里都有完整实现，README 却一个字没提。README 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。

1. 赛道定位：七个样本里唯一把"多人"写进定位的

七个样本的赛道分层（按"它到底在解决什么问题"）：

个人助理层      OpenClaw（388k）· QwenPaw（34.8k）
                  ↑ 一对一，人 ↔ 单个 agent
工作区层        iPolloWork（5.2k）· Maka（4.4k）· Orca（58.8k）
                  ↑ 人 ↔ agent 在同一工作区，单人为主
能力分发层      OpenWork（23.3k）
                  ↑ 不抢桌面入口，把 MCP 能力做成产品
协作空间层      Tutti（3.6k）← 唯一把"多人"写进定位的
                  ↑ 人 + 多 agent 在同一空间协同

Tutti 的定位不是"再做一个 agent 桌面"，而是"让你已有的 agent 订阅在同一个工作区里协同"——Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。这是七个样本里唯一站在"协作空间层"的项目：它不造引擎、不卖模型，做的是"跨 agent 的上下文共享与接力"。

它和 OpenWork 的关键差异：OpenWork 是跨工具的能力分发（把自己做成 MCP server 让各引擎来连），Tutti 是同一空间内的人与 agent 协作（人 + 多 agent 同屏）。OpenWork 的"多"是引擎侧的多，Tutti 的"多"是参与者侧的多。

2. 业务维度

目标用户

• 同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者
• 需要 agent 之间共享上下文、接力同一件事的小团队
• 想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人
• 需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版）

变现路径

Open-core 双轨，是七个样本里变现路径最清晰的： - 开源版（Apache-2.0）：免费、自托管，单人 + 多 Agent - Tutti · VM（Early Access，需邀请码）：多人 + 多设备 + 云同步 - Tutti 内置 Agent 在 Early Access 期免费，README 明示"后续可能按用量计费"

许可证

Apache-2.0（L1，最开放档）。但 NOTICE 写得极其规范——5 处第三方代码全部精确到文件路径、上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的。⚠️ 其中 VS Code Codicons 的 inspect 图标用的是 CC-BY-4.0（署名要求比 Apache-2.0 更严），再分发时漏掉署名即构成侵权。

护城河

① 双层引擎接入架构（ACP 协议层 + runtimeprep 运行时准备层）；② Workbench 节点模型 + 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊）；③ 多 Agent 实时文件协同编辑（daemon 负责落盘与冲突投影）。真正的壁垒在多人协同的工程实现（Cloud Room + DeviceLink 的 ICE/QUIC），而这部分恰好不在开源侧。

竞争风险

最容易被 Anthropic / OpenAI 官方的协作能力吃掉——Tutti 不拥有任何引擎与模型。更直接的威胁：它宣传的"agent 之间共享上下文"能力，各家引擎自己在做（Claude Code 的 subagent、Codex 的 session resume），Tutti 的跨引擎优势会随着引擎自身变强而稀释。

3. 场景维度

人在环

Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback（Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。执行过程可追溯性在七个样本里仅次于 Maka。

形态

• 桌面应用（Electron）
• TUI / CLI（Go）
• Workbench 节点（Browser / Terminal / App Center）
• 【闭源 VM】Cloud Room 多人多设备

典型用例

• Claude 写完 PRD，让 agent 调设计 App 直接出视觉稿
• 描述一个目标，Tutti 拆成子任务后分派给最合适的 agent
• 用已有订阅额度驱动 Tutti 里的所有内置 App，不额外付费
• 【VM】本地跑的 localhost 站点直接在 Room 里给别人预览，不用部署

交付物

code / 设计稿（AI Canvas / UI-UX 原型）/ 文档 / PPT（Docs / AI PPT 内置 App）/ 会话回放（session-replay）

4. 技术维度

架构总览

┌─────────────────────────────────────────────────────────────┐
│  Electron 桌面端（TypeScript 48.8%）                         │
│  ├─ Agent Board（可视化调度）                                 │
│  ├─ Workbench 节点（Browser / Terminal / App Center）         │
│  └─ 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊）   │
├─────────────────────────────────────────────────────────────┤
│  tuttid 守护进程（Go 45.4%）                                  │
│  ├─ 文件落盘与冲突投影（多 agent 实时协同编辑）                 │
│  ├─ 活动复制 / 状态探针 / 会话回放                              │
│  └─ workspace 级权限与 provision 流程                         │
├─────────────────────────────────────────────────────────────┤
│  双层引擎架构                                                 │
│  ├─ L1: acp_provider_*.go（ACP 协议适配）                     │
│  └─ L2: runtimeprep/（运行时准备：配置/skill/模型/目录/Win）   │
├─────────────────────────────────────────────────────────────┤
│  Go CLI（TUI）                                               │
└─────────────────────────────────────────────────────────────┘

引擎抽象：双层架构是七个样本里没有的分层

第 1 层 packages/agent/daemon/runtime/acp_provider_*.go —— ACP 协议适配 第 2 层 packages/agent/runtimeprep/ —— 运行时准备（配置注入、skill 装配、Windows 兼容、模型缓存、目录同步）

全仓 363 个文件引用 ACP，是真集成，不是营销词。

⚠️ 接入深度极不对等（runtimeprep/，非测试行数）：

Codex 是 Kimi 的 17 倍。 且只有 Codex 有 Windows 变体文件（4 个 _windows.go），其余引擎在 Windows 上一个字都没写过——说明只有 Codex 在 Windows 上被真正验证过。

更反常的是测试密度与实现规模成反比：投入最重的 Codex（2170 行）恰恰是质量保障最薄弱的地方（0.12），因为它的边界情况最多（Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。另有 19 个通用测试文件共 7,851 行（preparer_test.go 单文件 2,906 行）覆盖跨引擎路径，部分弥补了单引擎测试的缺失。

多 Agent 协作

Agent Board 统一调度 + Big @ 跨 agent 引用 + 多 agent 实时文件协同编辑（daemon 落盘与冲突投影）+ 工作流与自动化规则 + Issue/Task/Run 工作流。会话回放（session-replay）与活动复制（activity-replication）是它的特色。

本地优先

开源版本地跑，但协作能力全在云端 VM 侧。

扩展体系

• Skills：provider_skill.go（655 行）+ stable_skill_bundle.go（308 行）+ codex_skill_roots.go
• Plugins：extension_runtime.go（735 行）——为 Hermes 提供 RTK Python 插件机制（命令重写）
• MCP：codex_mcp.go（65 行）——⚠️ MCP 实现挂在 Codex 名下，不是通用层

权限与沙箱

tutti_cli_policy.go（140 行）提供 CLI 策略控制；workspace 级权限与 provision 流程。相较 QwenPaw（五层安全默认开）与 OpenClaw（沙箱默认关），Tutti 的开源侧没有看到同等强度的执行隔离——它的安全边界更多落在 workspace 与 daemon 层，而非内核沙箱。

可观测性

这是 Tutti 的强项：Agent Board 看板 + 状态探针（agentstatus + account-usage）+ 会话回放 + 活动复制 + goal review / plan feedback。执行过程可追溯性在七个样本里仅次于 Maka。

5. 横向对比（七项目矩阵）

Tutti 在发布纪律和多人协作两项上是七个样本里唯一拿到分的。代价是引擎接入投入严重偏科。

6. 宣称 vs 实测（claim_vs_reality）

① "Currently Claude Code, Codex, and Hermes；OpenClaw is in development"

实际：README 与代码对不上，两个方向都偏。 - 宣称"当前支持"的 Hermes，在 runtimeprep 里没有 hermes.go——它走的是 extension_runtime.go 的 RTK Python 插件机制（provider 标识 acp:hermes，用 Python 插件重写命令），只有测试文件 hermes_test.go(580) 与 hermes_verify_test.go(77)，没有原生 adapter。 - 宣称"in development"的 OpenClaw，确实只有 acp_provider_openclaw.go 52 行、零测试（对比 OpenCode 的 301 行 + 540 行测试）——README 这处倒是诚实的。 - 反过来，Cursor / OpenCode / Kimi / ComputerUse / BrowserUse 在代码里都有完整实现，README 的支持列表却一个字没提。

结论：README 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。 来源：本地源码实测：runtimeprep 目录文件清单 + daemon/runtime/acp_provider_*.go 行数 + grep hermes 引用

② "多引擎中立"

实际：协议层中立（都走 ACP），深度层远不中立。Codex 2170 行 vs Kimi 127 行，17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高），Kimi / ComputerUse / BrowserUse 测试为零。所谓"中立"是接入方式的中立，不是投入与保障的中立。 来源：本地源码 wc -l 实测（实现文件与测试文件分别统计）

③ "Where people and agents build in tune（多人 × 多 Agent）"

实际：开源版里只有 "agents"，"people" 那部分在闭源侧。README 的 Two Versions 对照表明确：Group chat / Work with others / Work with others' agents / Simultaneous editing / Agent borrowing / Across devices / No-deploy sharing——七项全部是 VM 版专属，开源版一格 ✓ 都没有。而 VM 版是 Early Access，创建 Room 需要邀请码。Big @ 在开源版里只能在"你自己的 agent 之间"引用，跨人引用要 VM 版。 来源：README "Two Versions of Tutti" 与 "Tutti vs Tutti · VM" 两张对照表原文

④ "Apache-2.0 开源"

实际：许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半，核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码，不保证你能用到它宣传的完整体验。 来源：本地源码 NOTICE 全文 + README 版本对照表

⑤ "（隐含）体量小 = 成熟度低"

实际：反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的，但发布纪律最好：8 个 release 全是正式版，且维护 stable 滚动 tag。工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程）明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。star 数与工程成熟度在本体系的七个样本里呈负相关。 来源：GitHub releases API + 本地源码 NOTICE 与测试文件实测

7. 结论

该用

• 手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者
• 想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人
• 看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人
• 单人 + 多 Agent 的"接力"场景（开源版够用了）

不该用

• 指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）
• 主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）
• Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）
• 想用一个"开源版"体验完整产品的人（功能完整度约一半）

再看看

• OpenClaw 的 ACP 接入（52 行零测试，"in development"是诚实的，但别指望）
• Hermes 是否会有原生 adapter（目前走 Python 插件机制）
• 引擎接入深度会不会向 Kimi / OpenCode 倾斜（目前 Codex 一国独大）
• VM 版的定价与开放策略（Early Access 期免费，后续"可能按用量计费"）

8. 追踪备注

• 数据日期：2026-09-01
• ★ / Fork / Issues：3,660 / 371 / 185
• 最新版本：v0.2.31 + stable 滚动 tag（2026-09-01 同日）
• 源码镜像：gitinbox/tutti（public，source-only，2026-09-01 同步）
• 结构化档案：data/projects/tutti.yaml
• 下次跟进点：
• OpenClaw ACP 接入从 52 行增长到多少？有没有测试？
• Hermes 是否出现原生 adapter（hermes.go）？
• VM 版是否开放注册 / 公布定价？
• 引擎接入深度是否会向 Kimi / OpenCode 倾斜？
• stable 滚动 tag 的历史追溯问题会不会被解决？

_{本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar}