# tutti · 项目档案 # 生成于 2026-09-01 · 由 scripts/new_project.py 从 schema 生成 # 人工补完重点：business / scenario / tech / risk.claim_vs_reality / verdict # 字段规范见 schema/project.schema.yaml # # ⚠️ 本档案的技术维度基于**本地源码实测**（/Users/figmarlite/.../tutti_repo， # Apache-2.0 浅克隆 8291 文件），不是从 README 转述。所有行数均为 wc -l 实测。 id: tutti name: "Tutti" repo: "tutti-os/tutti" homepage: "https://tutti.sh/" added_at: "2026-09-01" status: active identity: tagline: "Where people and agents build in tune." vendor: "Nexight（tutti.sh）" vendor_type: "vendor" region: "未公开（NOTICE 声明 'developed at Nexight'）" first_seen: "2026-06-12" name_note: |- 本体系里**最年轻的样本**（建仓至今 2.5 个月），也是 star 最少的（3.6k）， 但工程规范度排在前列——见下方 risk 与 tech 的实测数据。 business: positioning: |- 站在「多人 × 多 Agent 的实时协作空间层」，是七个样本里**唯一把"多人"写进定位的**。 它不造引擎、不卖模型，做的是"让你已有的 agent 订阅在同一个工作区里协同"： Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。 但它的商业模式是清晰的 open-core：**开源版只给"单人 + 多 Agent"， "多人 + 多设备 + 云同步"全在闭源的 Tutti · VM 侧**（Early Access，需邀请码）。 target_users: - 同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者 - 需要 agent 之间共享上下文、接力同一件事的小团队 - 想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人 - 需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版） monetization: |- **Open-core 双轨**：开源版（Apache-2.0）免费且自托管；Tutti · VM 为 Early Access 商业版，需邀请码创建 Cloud Room。Tutti 内置 Agent 在 Early Access 期免费， README 明示"后续可能按用量计费"。 这是七个样本里**变现路径最清晰的一个**。 license: spdx: "Apache-2.0" name: "Apache License 2.0" openness: L1 redistributable: true key_restrictions: - 需保留 NOTICE 文件——且本项目的 NOTICE 内容相当长（见 tech 备注） - 商标条款：不授予 Tutti / Nexight 商标使用许可 - ⚠️ NOTICE 中有一处 **CC-BY-4.0**（VS Code Codicons 的 inspect 图标）， 这是比 Apache-2.0 更严格的署名要求，再分发时必须保留署名 moat: |- ① 双层引擎接入架构（ACP 协议层 + runtimeprep 运行时准备层），把"接引擎" 拆成了协议适配与运行时准备两件事，这是其余样本没有做的分层； ② Workbench 节点模型 + 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊）； ③ 多 Agent 实时文件协同编辑（daemon 负责落盘与冲突投影）。 真正的壁垒在**多人协同的工程实现**（Cloud Room + DeviceLink 的 ICE/QUIC）， 而这部分恰好不在开源侧。 competitive_risk: |- 最容易被 Anthropic / OpenAI 官方的协作能力吃掉——Tutti 不拥有任何引擎与模型。 更直接的威胁：它宣传的"agent 之间共享上下文"能力，各家引擎自己在做 （Claude Code 的 subagent、Codex 的 session resume），Tutti 的跨引擎优势 会随着引擎自身变强而稀释。 scenario: primary: - 同一 workspace 里并行驱动多个 agent，共享文件与上下文 - agent 之间接力：Codex 接着 Claude 写了一半的活儿继续，无需重述背景 - 用 Big @ 跨 agent / 跨会话引用产出与上下文，用 + 快速引用文件 - 多 agent 实时协同编辑同一批文件，daemon 负责落盘与冲突投影 - 通过内置 Apps 让 agent 直接产出设计稿 / 文档 / PPT（不只是代码） - 【闭源 VM 版】多人同屏、跨设备、借用他人 agent、免部署分享 typical_use_cases: - Claude 写完 PRD，让 agent 调设计 App 直接出视觉稿 - 描述一个目标，Tutti 拆成子任务后分派给最合适的 agent - 用已有订阅额度驱动 Tutti 里的所有内置 App，不额外付费 - 【VM】本地跑的 localhost 站点直接在 Room 里给别人预览，不用部署 industries: - 软件研发 - 产品与设计协作 - 内容生产 interaction_mode: - 桌面应用（Electron） - TUI / CLI（Go） - Workbench 节点（Browser / Terminal / App Center） - 【闭源 VM】Cloud Room 多人多设备 human_in_the_loop: |- Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback （Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。 deliverables: - code - 设计稿（AI Canvas / UI-UX 原型） - 文档 / PPT（Docs / AI PPT 内置 App） - 会话回放（session-replay） tech: form_factor: |- pnpm + Go Workspace 混合 monorepo；桌面端 Electron；守护进程 tuttid（Go）； CLI（Go）；Agent 运行时基于 **ACP（Agent Client Protocol）** + uv / npm / pnpm 托管运行时。语言构成 TypeScript 48.8% / Go 45.4% —— **后端用 Go 而不是 Node， 这是它和其余 Electron 系样本的关键差异**（守护进程的稳定性与并发模型更好）。 stack: - TypeScript 48.8% - Go 45.4%（守护进程 tuttid + CLI） - JavaScript 4.2% - CSS 0.9% - Kotlin 0.3%（Android） - Shell 0.1% engine_abstraction: supported: - Codex（接入最深） - Claude Code - Cursor - OpenCode - Kimi Code - Hermes - OpenClaw（in development） - Computer Use - Browser Use - Tutti 内置 Agent mechanism: |- **双层架构**，这是 Tutti 在引擎接入上最值得记的一笔： 第 1 层 `packages/agent/daemon/runtime/acp_provider_*.go` —— ACP 协议适配 第 2 层 `packages/agent/runtimeprep/` —— 运行时准备（配置注入、skill 装配、 Windows 兼容、模型缓存、目录同步） 全仓有 363 个文件引用 ACP，**是真集成，不是营销词**。 abstraction_layer: "ACP（Agent Client Protocol）+ runtimeprep 准备层" depth_notes: |- ⚠️ **接入深度极不对等，实测数据如下**（packages/agent/runtimeprep/，非测试行数）： Codex 16 文件 2170 行 ← 一国独大 Tutti 内置 2 文件 653 行 Cursor 2 文件 446 行 Claude 3 文件 410 行 OpenCode 2 文件 392 行 Kimi 1 文件 127 行 ComputerUse 1 文件 43 行 BrowserUse 1 文件 43 行 **Codex 是 Kimi 的 17 倍。** 且只有 Codex 有 Windows 变体文件 （codex_directory_windows.go 149 行、codex_file_windows.go、 codex_models_cache_windows.go 等 4 个），其余引擎一个 Windows 变体都没有 ——说明**只有 Codex 在 Windows 上被真正验证过**。 更有意思的是**测试密度与实现规模成反比**： OpenCode 392 行实现 / 218 行测试 = 0.56（密度最高） Cursor 446 / 187 = 0.42 Tutti 内置 653 / 274 = 0.42 Claude 410 / 136 = 0.33 Codex 2170 / 261 = **0.12（投入最大，保障最薄）** Kimi 127 / 0 = 0.00 ComputerUse / BrowserUse 43 / 0 = 0.00 即：**投入最重的 Codex 恰恰是质量保障最薄弱的地方**，因为它的边界情况最多 （Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。 另有 19 个通用测试文件共 7851 行（preparer_test.go 单文件 2906 行） 覆盖跨引擎路径，部分弥补了单引擎测试的缺失。 extension_system: skills: "provider_skill.go（655 行）+ stable_skill_bundle.go（308 行）+ codex_skill_roots.go；支持 personal skill" plugins: "extension_runtime.go（735 行）：为 Hermes 提供 RTK Python 插件机制（命令重写）" mcp: "codex_mcp.go（65 行）—— 注意：MCP 实现挂在 Codex 名下，不是通用层" model_binding: |- 不绑定模型，但**绑定 agent 订阅**：README 明确"用你已有的 Claude / Codex / 其他订阅"。没有订阅的用户可用 Tutti 内置 Agent（Early Access 期免费）。 local_first: true multi_agent: |- Agent Board 统一调度 + Big @ 跨 agent 引用 + 多 agent 实时文件协同编辑 （daemon 落盘与冲突投影）+ 工作流与自动化规则 + Issue/Task/Run 工作流。 会话回放（session-replay）与活动复制（activity-replication）是它的特色。 permission_sandbox: |- tutti_cli_policy.go（140 行）提供 CLI 策略控制；workspace 级权限与 provision 流程。 相较 QwenPaw（内核级沙箱默认开）与 OpenClaw（沙箱默认关）， Tutti 的开源侧没有看到同等强度的执行隔离——它的安全边界更多落在 workspace 与 daemon 层，而非内核沙箱。 observability: |- 这是 Tutti 的强项：Agent Board 看板 + 状态探针（agentstatus + account-usage）+ 会话回放 + 活动复制 + goal review / plan feedback。执行过程可追溯性 在七个样本里仅次于 Maka。 ecosystem: metrics: stars: 3660 forks: 371 open_issues: 185 subscribers: 115 created_at: 2026-06-12 pushed_at: 2026-09-01 size_kb: 248635 languages: {TypeScript: 48.8, Go: 45.4, JavaScript: 4.2, CSS: 0.9, Kotlin: 0.3, Shell: 0.1} latest_release: stable release_cadence: 约 3 天/版本 data_date: 2026-09-01 stale: false community: |- 3.6k star、371 fork、185 issue，规模是七个里最小的，但**发布纪律是七个里最好的**： 最近 8 个 release 全部 prerelease=False（v0.2.25 → v0.2.31，约 3 天一版）。 另维护一个名为 `stable` 的**滚动 tag**（始终指向最新稳定版，会随发版移动）—— 方便用户固定引用，代价是该 tag 的历史不可追溯。 对比：OpenClaw 版本号倒挂（9.1-beta 早于 8.1 正式）、QwenPaw 全是 beta， star 数最少的 Tutti 反而是唯一持续发正式版的。 standards: - "ACP（Agent Client Protocol）——363 个文件引用，深度采纳" notable_events: - "2026-06-12：建仓" - "2026-07-23：docs/specs/2026-07-23-hermes-agent-extension-acceptance.md（Hermes 以扩展方式接入的验收规格）" - "2026-09-01：v0.2.31 与滚动 tag stable 同日发布" risk: license_risk: |- Apache-2.0 本身无风险，但**NOTICE 必须完整保留**：它记录了 5 处第三方代码， 且其中 VS Code Codicons 的 inspect 图标用的是 **CC-BY-4.0**（署名要求 比 Apache-2.0 更严），再分发时漏掉署名即构成侵权。 vendor_lockin: |- **锁定在"协作"而非"代码"**：开源版能跑，但 Group chat / 多人协作 / 同时编辑 / 跨设备 / agent 借用 / 免部署分享这六项功能全在闭源 VM 侧， 且创建 Room 需要邀请码（waitlist）。一旦团队依赖上协作能力，就上了商业版的船。 这是七个样本里 open-core 切分最干脆的一个。 claim_vs_reality: - claim: "（README）Currently Claude Code, Codex, and Hermes；OpenClaw is in development" actual: |- **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 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。 source: "本地源码实测：runtimeprep 目录文件清单 + daemon/runtime/acp_provider_*.go 行数 + grep hermes 引用" - claim: "多引擎中立" actual: |- 协议层中立（都走 ACP），**深度层远不中立**。Codex 2170 行 vs Kimi 127 行， 17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。 而且测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高）， Kimi / ComputerUse / BrowserUse 测试为零。 所谓"中立"是**接入方式的中立**，不是**投入与保障的中立**。 source: "本地源码 wc -l 实测（实现文件与测试文件分别统计）" - claim: "Where people and agents build in tune（多人 × 多 Agent）" actual: |- 开源版里只有 "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 版。 source: "README 'Two Versions of Tutti' 与 'Tutti vs Tutti · VM' 两张对照表原文" - claim: "Apache-2.0 开源" actual: |- 许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、 上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。 但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半， 核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码， 不保证你能用到它宣传的完整体验。 source: "本地源码 NOTICE 全文 + README 版本对照表" - claim: "（隐含）体量小 = 成熟度低" actual: |- 反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的， 但**发布纪律最好**：8 个 release 全是正式版，且维护 `stable` 滚动 tag。 工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程） 明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。 **star 数与工程成熟度在本体系的七个样本里呈负相关。** source: "GitHub releases API + 本地源码 NOTICE 与测试文件实测" maturity: |- 建仓仅 2.5 个月，处在快速成长期。发布纪律是七个样本里最好的（全部正式版 + stable 滚动 tag），工程规范度高（NOTICE 精确到 revision hash、通用测试 7851 行、 Go 守护进程），但引擎接入深度严重向 Codex 倾斜、开源版功能完整度约一半。 适合自用与"多 agent 接力"场景，不适合指望开源版承担团队协同。 maturity_level: "快速成长期" chart: form_depth: 8 # Electron + Workbench 节点 + 内置 Apps，形态最完整之一 engine_neutral: 8 # ACP 协议层真统一（363 文件），但深度极不对等（见 depth_notes） local_first_score: 7 # 开源版本地跑，但协作能力全在云端 VM 侧 deliverable_depth: 7 # 内置 Apps 出设计稿 / 文档 / PPT，不止代码 chart_note: "引擎中立项给的是协议层统一；若按投入对等度重评，该项应下调至 4 左右" verdict: one_liner: |- 把「多 agent 共享上下文、接力干活」做成了产品，且是七个里发布纪律最好的—— 但接入深度严重偏袒 Codex（17 倍差距），而宣传的「多人协作」全在闭源 VM 版。 who_should_use: |- 手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者； 想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人； 看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人。 who_should_not: |- 指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）； 主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）； Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）。 mirror: gitea_repo: "gitinbox/tutti" visibility: public upstream: "https://github.com/tutti-os/tutti" last_sync: "" mode: "pending" sync_note: |- 243 MB。本地已有浅克隆（/Users/figmarlite/.../tutti_repo，8291 文件）， 技术维度分析即基于此，可直接复用做快照，无需重新下载。 仍需 unshallow 补全历史后走 source-only 降级（超 Gitea 50 MB 上限）。尚未执行。 article: emlog_id: 0 # emlog 文章 ID，发布后回写 published_at: "" url: ""