title: 你给 AI Agent 装了5个，但每次切换都在从零开始——有人造了个共享大脑 description: 多Agent协作的真正瓶颈不是模型能力，而是上下文断裂。Tutti用共享工作空间打通Agent间的记忆孤岛，但多Agent范式本身的风险不容忽视。 tags: [AI Agent, 多Agent协作, Tutti, Claude Code, Codex, 上下文共享]
你见过交响乐团只有一个乐手吗？
一把小提琴拉完，放下琴，走到大提琴位坐下，重新看谱，从头练起——再换到定音鼓后面，又是从零开始。
这不是荒诞剧，这是大多数人用 AI Agent 的日常。
Claude Code 写完代码，切到 Codex 接手，先花十分钟交代背景；Codex 改完，想用 AI 生张配图，又得把需求重新描述一遍。每个 Agent 都很强，但每次切换，你都变成了它们之间的翻译官。
问题不在 Agent 的能力，在于它们彼此是瞎子。
从"信使"到"指挥家"
GitHub 上 6 月 12 日刚开源的 Tutti（Apache 2.0 协议），243 star、16 位贡献者、版本号还在 v0.1.12——但它试图干掉的这个"信使"角色，确实是痛点。
它不是又一个 Agent 框架，不是再做一个聊天机器人——它做的是环境层：一个让多个 Agent 共享上下文、文件、任务和应用的实时工作空间。
接入 Claude Code 和 Codex 后，你在 Claude Code 里的对话、代码改动、需求文档，Codex 全都能看到。不需要你手动复制粘贴，不需要重新解释"我之前让它做了什么"。
操作方式极其简单：**@ 一下就行。**
在 Codex 的输入框里 @Claude Code 的历史会话，完整的上下文——需求、回复、diff、所有改动——直接引用过来。Codex 接手时，它自己就知道项目做到哪一步了。
不只是共享记忆，是共享产出
Tutti 更有意思的一点：它内置了应用中心——产品原型设计、AI 文档、PPT、生图、Canvas 等。
这些应用不是独立的工具，而是工作空间的一部分。你在 Claude Code 里梳理完需求，@ 产品原型设计应用，它基于 PRD 直接出设计稿。设计稿确认后，Claude Code 直接读取，开始搭项目——省掉了以前下载截图、发给 Agent、再补一句"按这张图做"的繁琐流程。
需要配图？在 Claude Code 对话框里 @Codex 或 @AI Canvas，用 GPT-Image 生成，图片自动进入工作空间，顺手把代码改了。
全程零重复交代，全在一个空间里通过 @ 调度完成。
而且，这些应用跑在你已有的 Agent 订阅上——用你自己的 Claude 或 Codex，不额外收费。
架构拆解：Tutti 到底做了什么
把 Tutti 的核心能力拆开看，三层结构：
第一层：共享上下文引擎
- Big @：跨 Agent 引用历史对话、文件、应用输出、任务
- Reference "+"：引用本地文件或 App 产出
- 所有 Agent 看到的是同一个项目状态
第二层：人机共用的 App 生态
- 内置应用中心，用户和 Agent 都能调用
- App 产出留在工作空间，下一步可直接引用
- 不额外收费，复用已有 Agent 订阅
第三层：任务编排与控制
- 目标自动拆解为子任务
- Control Center 统一管理所有 Agent 对话和待审批操作
- GUI 界面，无需命令行
技术栈：TypeScript 65% + Go 30%，代码库 2300 万+字节。Apache 2.0 开源协议，24 fork，发布节奏极快——7 月 6 日一天连发 v0.1.9、v0.1.10、v0.1.12 三个正式版。目前支持 Claude Code 和 Codex，Gemini、OpenClaw（DeepSeek）、Hermes 即将支持。
两个版本：Tutti（开源版）单人多 Agent，本地运行；Tutti · VM（即将推出）云端 Room，多人多设备跨 Agent 协作。
代价清醒：多 Agent 的暗面
Tutti 解决了上下文断裂的问题，但多 Agent 协作本身的风险，它解决不了。
Token 成本倍增。 学术研究显示，AI Agent 的 token 消耗是普通聊天的 1000 倍。同一任务，不同 Agent 的 token 用量可差 30 倍。10 个并行 Agent，配额消耗速度就是 10 倍。Uber 曾在 4 个月内烧完全年 AI 编码预算，人均月费 $500-2000。
协调失败率惊人。 NeurIPS 2025 的 MAST 分类研究显示，多 Agent 系统生产失败率 **41%-86.7%**，79% 的故障源于规格歧义和协调崩溃。4 个 Agent 创造 6 个潜在故障点，10 个 Agent 创造 45 个。
社区的反方声音很大。 Reddit 高赞帖直言："I build multi-agent systems and I keep telling people to just use one agent instead。" 另一位从业者说得更直白："Multi agent systems are a total nightmare in production——到第 4 个 Agent 时基本在编造信息。"
项目本身还在早期。 243 star、24 fork、88 个 open issues，6 月 12 日创建至今不到一个月。核心贡献者仅 16 人，Top 1 贡献者 devRickyyy 独占 742 次提交——项目高度依赖少数人。启动台上 Gemini、OpenClaw、Hermes 还是置灰状态，尚未支持。
什么时候不该用？ 如果你的任务一个 Agent 就能搞定，别上多 Agent。如果团队没有精力处理 Agent 间的协调异常，别上多 Agent。如果 token 预算有限，更别上——Tutti 不收费，但底层 Agent 的 API 费用是实打实的。
趋势判断：从"谁更强"到"谁更会协调"
Tutti 的价值不在于它接了几个 Agent，而在于它补上了 AI 工具链里被忽略的一层——环境层。
过去我们比的是谁的模型参数多、谁的 benchmark 高。但实际干活时，瓶颈从来不是单个 Agent 的能力，而是 Agent 之间的协作成本。
这跟软件工程的历史一模一样：早期比谁写代码快，后来发现瓶颈在协作——于是有了 Git、有了 CI/CD、有了代码审查。Agent 协作正在走同一条路。
Tutti 不是唯一的选择。同类工具已经挤了一排：CrewAI 做角色协作，crystal 做 Codex+Claude 并行，cmux 做多 Agent 平台，GitHub Agent HQ 做企业级方案。但 Tutti 的差异化在于：它不是编排框架，而是工作空间——Agent 在里面不是被调度，而是共享同一个"办公室"。
也许往后，比的不再是谁手里的 Agent 更强，而是谁能更低成本地让一堆 Agent 协同完成一件事。
Tutti 开源地址：https://github.com/tutti-os/tutti
你用多 Agent 协作时，最头疼的是什么？评论区聊聊。
暂无评论。