gitea-publish
de6cf8f3c0
- articles/: 新增 5 篇深度文（八段结构，每篇含 claim_vs_reality） - maka.md → emlog_id=105 - openclaw.md → emlog_id=106 - openwork.md → emlog_id=107 - qwenpaw.md → emlog_id=108 - tutti.md → emlog_id=109 - data/projects/*.yaml: 回写 emlog_id 到 6 个档案（orca 前序已回写） - articles/00-overview.md: build_matrix.py 重算矩阵 + 回填总纲
259 lines
19 KiB
Markdown
259 lines
19 KiB
Markdown
# Tutti 深度拆解：发布纪律最好的「多人 × 多 Agent」协作空间——但「多人」那部分全在闭源侧
|
||
|
||
> **一句话结论**：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 保证了你能自由改代码，不保证你能用到它宣传的完整体验。
|
||
|
||
| 维度 | 数据 |
|
||
|---|---|
|
||
| 仓库 | tutti-os/tutti |
|
||
| 一句话 | Where people and agents build in tune. |
|
||
| ★ / Fork / Open Issues | 3,660 / 371 / 185 |
|
||
| 主语言 | TypeScript 48.8% + Go 45.4% |
|
||
| 体积 | ~244 MB（8,291 文件） |
|
||
| 最新版本 | v0.2.31 + `stable` 滚动 tag |
|
||
| 节奏 | 约 3 天/版本，**8 个 release 全正式版** |
|
||
| 许可证 | Apache-2.0（L1） |
|
||
| 成熟度 | 快速成长期（建仓 2.5 个月） |
|
||
|
||
---
|
||
|
||
## 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 | 16 | 2170 | 261 | **0.12**（最低） |
|
||
| Tutti 内置 | 2 | 653 | 274 | 0.42 |
|
||
| Cursor | 2 | 446 | 187 | 0.42 |
|
||
| Claude | 3 | 410 | 136 | 0.33 |
|
||
| OpenCode | 2 | 392 | 218 | **0.56**（最高） |
|
||
| Kimi | 1 | 127 | 0 | 0.00 |
|
||
| ComputerUse | 1 | 43 | 0 | 0.00 |
|
||
| BrowserUse | 1 | 43 | 0 | 0.00 |
|
||
|
||
**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 | OpenWork | QwenPaw | OpenClaw | Orca | Maka | iPolloWork |
|
||
|---|---|---|---|---|---|---|---|
|
||
| ★ | 3.6k | 23.3k | 34.8k | 388k | 58.8k | 4.4k | 5.2k |
|
||
| 建仓 | 2026-06 | 2026-01 | 2026-02 | 2025-12 | 2026-01 | 2026-01 | 2025-12 |
|
||
| 主语言 | TS+Go | TS | Py+TS | TS | TS | TS | TS |
|
||
| 许可证 | Apache-2.0 (L1) | 目录切分 (L3) | Apache-2.0 (L1) | MIT (L1) | MIT (L1) | MIT (L1) | MIT (L1) |
|
||
| 发布纪律 | **8 版全正式** | ~1 天/版 | 全 prerelease | 版本号倒挂 | 正式版 | 无 release | 正式版 |
|
||
| 引擎中立 | 8（协议层）/ 4（投入层） | 6 | 2 | 1 | 9 | 1 | 7 |
|
||
| 本地优先 | 7 | 6 | 9 | 8 | 6 | 10 | 7 |
|
||
| 形态深度 | 8 | 5 | 5 | 6 | 8 | 6 | 8 |
|
||
| 交付深度 | 7 | 5 | 4 | 2 | 3 | 6 | 7 |
|
||
| 多人协作 | **有（闭源侧）** | 无 | 无 | 无 | 无 | 无 | 无 |
|
||
|
||
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 的历史追溯问题会不会被解决？
|
||
|
||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar</sub>
|