Tan Zeng

Founder @tutti_global — multi-user, multi-agent, real-time
collaboration space | Previously 0→1 engineering lead for Tencent Docs, CapCut Web, Dreamina (即梦)

[Tan Zeng @TanZeng1021]

@jiangkoumo_ 呃，那还挺麻烦的，就是一个纯云端的东西吧

[Tan Zeng @TanZeng1021]

Why today’s agent collaboration often falls short of real collaboration:
Agents typically run inside sandboxes, keeping the agent loop, filesystem, and subprocesses in one environment. This supports deeper work, longer tasks, and specialized workflows. For asynchronous work—“one task, one environment, one PR”—it’s an efficient, pragmatic architecture.

But it also tightly couples each agent to a single sandbox. That creates three problems:

1. Agents are trapped inside their sandboxes
Each task gets a fresh sandbox, so the agent has to initialize from scratch every time.
Beyond the cold-start cost, there’s the memory it develops while working: where to start debugging, what the user cares about, how to reflect on its own work afterward.
Those lessons disappear when the task ends. They don’t automatically carry over or stay synchronized across sandboxes.

2. Parallel execution doesn’t deliver real collaboration
Running more tasks in parallel works well when the work has clear boundaries. But complex work involves dependencies between collaborators.
Real collaboration requires effective division of labor, shared state, conflict resolution, and a way to bring results together.
The agent group chats and agent teams we’ve seen mostly increase the number of agents executing concurrently. They don’t make it safe for multiple people and agents to work simultaneously in the same project or workspace.
When each agent is tied to its own sandbox, it lives in a separate universe. It can’t see what others are actually doing as they work. Collaboration and sharing still happen after the fact, through Git or shared-drive synchronization.
This architecture gives us more parallel tasks, but it doesn’t give us real parallel collaboration.

3. Performance pressure and difficult engineering problems
What if we solve this by putting all the collaborating agents into the same sandbox?
It’s theoretically possible, but difficult to make practical.
Every agent brings its own session management, network requests, skills, and CLI tools. All the CPU usage, memory consumption, and filesystem I/O concentrate on a single node. That’s an expensive tradeoff in both performance and compute cost.
Forcing an environment designed for one agent to support many also introduces difficult engineering problems:

How do you enforce identity boundaries between tenants?
How do you separate private and shared areas?
How do you commit agents’ writes in a controlled order?
How do you trace file changes back to the agent that made them?
How do you prevent conflicting commands and deduplicate execution?
How do you define and coordinate each agent’s lifecycle?

23:33

[Tan Zeng @TanZeng1021]

Forcing an environment designed for one agent to support many also introduces difficult engineering problems:
How do you enforce identity boundaries between tenants?
How do you separate private and shared areas?
How do you commit agents’ writes in a controlled order?
How do you trace file changes back to the agent that made them?
How do you prevent conflicting commands and deduplicate execution?
How do you define and coordinate each agent’s lifecycle?

[Tan Zeng @TanZeng1021]

Why today’s agent collaboration often falls short of real collaboration:
Agents typically run inside sandboxes, keeping the agent loop, filesystem, and subprocesses in one environment. This supports deeper work, longer tasks, and specialized workflows. For asynchronous work—“one task, one environment, one PR”—it’s an efficient, pragmatic architecture.
But it also tightly couples each agent to a single sandbox. That creates three problems:

[Tan Zeng @TanZeng1021]

3. Performance pressure and difficult engineering problems
What if we solve this by putting all the collaborating agents into the same sandbox?
It’s theoretically possible, but difficult to make practical.
Every agent brings its own session management, network requests, skills, and CLI tools. All the CPU usage, memory consumption, and filesystem I/O concentrate on a single node. That’s an expensive tradeoff in both performance and compute cost.

[Tan Zeng @TanZeng1021]

传统互联网时代已经被验证过的冲突解决方案，无论在线文档还是figma，都是基于应用层的协同，用户操作和产物类型在他们各自的场景下是固定和可以穷举的，所以可以基于ot或者crdt等算法给他们设计冲突处理逻辑。

但agent之间的命令调用，文件操作如何发生冲突，涉及到的情况多到无法穷举。举几个具体的例子，协作者同时安装npm依赖，损坏了node_modules怎么办，有的agent正在写入文件内容，另一个agent正在移走这个文件时到底以谁为准，POSIX下的全量写入，如何避免覆盖其他人的变更等等。

agent时代实时协同的唯一解法，是把冲突处理收敛在系统层，给文件系统设计一套更底层和通用的协同引擎。

[Tan Zeng @TanZeng1021]

如何解决潜在的Agent之间的协作冲突

并行工作的前提是解决潜在的协作冲突问题，即便我们主观上没有一起协作的需求，客观上很多时候团队成员和agent必须串行工作，在群里确认结果，用git合并，都是因为担心在同一个工作区工作时，可能存在潜在的多人冲突风险。

[Tan Zeng @TanZeng1021]

@globaltrend_ai 得后面弄一下，技术上很容易

[Tan Zeng @TanZeng1021]

和 AI 聊天很容易，但把一件事真正做完，却没那么简单。
今天让 AI 帮你梳理需求，明天让它改代码；过两天换了同事接手，前面的背景、讨论和踩坑记录，又要重新解释一遍。看似每次都在高效对话，实际上团队一直在重复“找回上下文”。
https://t.co/26eYtOPmAF更像是一个让人、项目和 AI Agent 长期一起工作的共同空间。
在 Tutti 里，项目不该随着聊天窗口关闭而中断。需求、讨论、任务进展、代码改动、验证结果，以及 AI 做过的探索，都可以沉淀在同一个持续存活的工作区里。

团队成员不用反复讲背景，接手工作更顺畅。
已经做过的尝试和决策不会散落在个人聊天记录里。
人负责判断和协作，AI Agent 负责执行、调研、测试和推进。
每一次协作，都能成为下一次工作的基础。
真正高效的 AI 协作，不是写出一句完美提示词，而是让上下文、任务和成果能够持续存在、被团队共享、被不断复用。
Tutti 想做的，就是这样一个持久化共同工作区，每个人带着自己熟悉的agent进来，在这里一起创造。
你觉得未来的团队协作，会从“人用 AI”变成“人和 AI 一起工作”吗？

[Tan Zeng @TanZeng1021]

@jiujianian 企业场景的 Agent，不必属于企业，也可以是属于员工的，企业的上下文和资产属于企业

[Tan Zeng @TanZeng1021]

@Wuji_NFTs 我也很喜欢，看过很多遍，😁国庆刚去广州听了Hans Zimmer现场，有这段音乐～

[Tan Zeng @TanZeng1021]

@shmily7 这个钱咋付。。

[Tan Zeng @TanZeng1021]

@konghayao 有道理

[Tan Zeng @TanZeng1021]

这个事情还是很复杂的，我们有协同编辑的技术背景（19年做了业内第一个文档千人协同引擎），最近也做了一个文件级的协同处理引擎（比文档级的要复杂很多），过阵子来陆续介绍下技术原理。

[Chasen @chasen_liao]

和大家聊一个反直觉的多 agent 并行方案吧

不开分支，不开 worktree，多个 agent 直接挤在同一个分支、同一个工作目录里同时干活

听起来通疯狂的，但这是 Pi 仓库 AGENTS.md 的默认假设：同一目录下可能同时跑着多个 pi 会话，每个会话各自改不同的文件

它的隔离逻辑和我们熟悉的 git 协作完全反过来

传统多人协作靠分支，一人一条线，最后 merge Pi 这套靠文件级分工，只要各会话改的文件不重叠，就天然没有冲突，连分支都不用切
那 git 在里面负责什么 它不负责隔离，反而成了最需要提防的东西，因为工作区和暂存区是所有会话共享的：

git add -A 会把别的会话改的文件一起塞进你的 commit，所以必须写明路径
reset --hard、stash、clean 操作的是整个工作区，一条命令就能清掉别人没提交的活

真有两个会话改到同一个文件，规则要求立刻停下问用户，agent 不许自己处理冲突

对应原文放这：

Multiple pi sessions may be running in this cwd at the same time, each
modifying different files. Git operations that touch unstaged, staged, or
untracked files outside your own changes will stomp on other sessions' work.

Committing:

- Only commit files YOU changed in THIS session.
- Stage explicit paths (`git add <path1> <path2>`); never `git add -A` / `git add .`.
- Before committing, run `git status` and verify you are only staging your files.

Never run (destroys other agents' work or bypasses checks):

- `git reset --hard`, `git checkout .`, `git clean -fd`, `git stash`,
`git add -A`, `git add .`, `git commit --no-verify`.

If rebase conflicts occur:

- Resolve conflicts only in files you modified.
- If a conflict is in a file you did not modify, abort and ask the user.
- Never force push.

我今天拉 Pi 的源码看的时候就看了一眼，这套方案的本质是把「分支级隔离」换成了「文件级分工 + git 操作自律」

好处是轻，省掉切分支和 merge 的成本，会话之间能立刻看到彼此的改动，commit 全在一条线上 代价是成立的前提很明确：任务拆分时就得保证各 agent 碰的文件不重叠

常见的并行方案是给每个 agent 一个独立 worktree，安全但重 Pi 给了另一个方向：只要分工够细、纪律够硬，一个工作区也能并行

但是仅仅靠 prompt 去约束肯定不是 100% 的，这套也只是假设，我看到觉得还蛮有意思的就分享了一下

[Tan Zeng @TanZeng1021]

@chasen_liao 我们最近做了一个文件级的冲突处理引擎，过阵子来介绍下技术原理。

[Tan Zeng @TanZeng1021]

@chasen_liao 光靠文件级分工是挺难的，实操起来有挺多问题的