Teamwork：让多 Agent 协同完成一次任务

Teamwork 当前是预览版（preview）。基本机制已稳定，最终形态可能调整，欢迎在使用中给我们反馈。

Neutree Agent Platform（NAP）上的多 Agent 协作能力一直都有：在任意 Workspace 里 @agent/slug 就能调另一个 Agent；要传文件就用 AFS 建一个共享目录。但这两件事都是 Workspace 级 的配置——一个 Agent 要么对别人可见、要么不可见，共享目录要么挂着、要么不挂。

而很多协作其实是任务级的：

“这次我想让我的私有 Agent 临时帮我做一份调研，做完就回到不可见。”

“几个 Agent 共同往一个目录里写东西，做完归档；下次任务换一组成员、换一个目录。”

Teamwork 就是为这种场景准备的——你在「应用」里创建一个 team task，把成员拉进来，平台自动管好可见性、共享目录、协作时间线。任务结束，全部收回。

多 Agent 协作的价值

要理解 Teamwork 的设计，先要理解多 Agent 协作究竟解决什么问题。

我们的看法是：多 Agent 的本质是把 context 管好，让任务做得更稳——不是为了在画布上画一堆五颜六色的 CEO/CTO 角色，那种把 Agent 拖成节点连线的玩法对最终任务的完成度没有真正帮助。

单 Agent 的 context 里通常塞着这些东西：

• 系统 prompt、加载的 skills、可用工具（静态部分——代表职责和知识）
• 用户消息、模型回复、工具调用的请求和结果（动态部分——本次对话累积下来的内容）

会撞到两个瓶颈：

1. 静态部分会膨胀——一个 Agent 要既会做 PPT 又会改 Excel 又会查数据库，每多一项能力，系统 prompt 和 skills 就长一截。但任何一次对话其实只用得到其中一小部分，其余都是浪费。
2. 动态部分会变脏——Agent 完成任务前往往要探索一番（列目录、读文件、试错），找到答案后那些过程内容就是”非必要”了，但它们已经以碎片形式占据了 context 空间，分散后续推理的注意力，而且很难剔除。

Sub-agent 是怎么缓解这两点的：

• 职责分离——主 Agent 只负责拆分和调度，PPT 能力放在一个 sub-agent 里、Excel 在另一个 sub-agent 里。当前任务用得上谁就唤醒谁，用不上的能力不进主 Agent 的 context。
• 探索过程隔离——sub-agent 在自己的 session 里探索、试错、读文件，那些 token 都待在 sub-session 里。主 Agent 只通过工具调用拿到 sub-agent 的最终 result（一段精炼的总结），sub-session 结束后探索过程就自然丢弃，不会污染主 context。

这是 Teamwork 想要利用的核心机制。所有的协作 UI、可见性配置、共享目录管理，都是为了让这件事在用户和 Agent 两个视角下都更顺畅。

已有的多 Agent 基础

Teamwork 不是从零起的。它建立在两个已有的能力之上：

Agent 调用工具：call_agent / get_agent_result

主 Agent 通过这两个内置工具去调另一个 Agent：

• call_agent——发起调用。参数是目标 Agent 的 slug 和这次要交给它的任务描述（这段描述就是 sub-session 的第一条 user message——主 Agent 会从自己的上下文里提炼出与本次调用相关的部分作为参数）。支持同步和异步两种模式：同步会等 sub-agent 完成；异步可主动让长任务转入后台。无论同步异步，工具都会返回 sub-session 的 ID
• get_agent_result——用 sub-session ID 查询结果。可用于轮询异步任务，也可用于回看历史协作

call_agent 还支持新开会话或继续之前的会话——两个 Agent 之间也可以有多轮、多线程的对话，跟人和人协作类似。

文件级上下文：AFS 共享目录

对话能传文本，但传不了 PPT 二进制、PDF、几百行 CSV 这类东西。两个 Agent 默认的文件系统是隔离的——sub-agent 在自己容器里写好的文件，主 Agent 是读不到的。

AFS 解决了这个问题：可以创建一个共享目录，挂载给多个 Agent；权限是只读还是读写都能控制，随时可以撤回。Agent 自己也能通过 MCP 工具发起共享。

Teamwork 用到的就是这套底层，只是把”建目录、挂载、回收”这件事自动化了。

Teamwork 的三项增强

Teamwork 不是替代上面这两个能力，而是在它们之上加一层”任务”语义。打开「应用」找到 Teamwork 入口（标记为预览版），创建一个 team task，设定一个 协调员（coordinator）Agent，再把成员加进来。从这一刻起，下面三件事就自动生效。

1. 任务级的 Agent 可见性

平时 Workspace 的 Visibility 是三档：Private / User / Public。这是个 Workspace 级别的常态配置——一个 Agent 要么对协作方可见、要么不可见。

但如果你想要的是”这一次任务让某个私有 Agent 帮我做事，做完它继续不可见”——常态配置就太重了，得反复调来调去。

在 team task 里加成员时，候选列表包含：

• 所有 Public 可见的 Agent
• 所有 User 级可见的 Agent（你自己的）
• 你自己的 Private Agent——加进来时如果还没配 slug 可以在这里现配一个

把一个 Private Agent 加进 task 后，它只在这个 task 里可见，不影响其他场景。task 优先级高于 Workspace 的全局可见性配置。所以你不必为了一次任务把 Agent 暴露到 user/public 级别。

2. 自动管理的共享目录

每个 team task 创建时都会自动创建一个共享目录（用任务 ID 命名，类似 team-<uid>），平台负责把它挂载给所有当前成员。

• 成员加入 → 自动挂上
• 成员退出 → 自动卸下
• 任务结束 → 共享目录回收

成员之间无须再走”建目录 → 授权”这两步——只要在 task 里，就有一个互通的工作目录可用。需要更细粒度控制（比如某两个 Agent 之间单独走一个临时目录）时，仍然可以手动用 AFS API 做，自动管理只是覆盖了绝大多数情况。

3. 协作时间线

前面说过，复杂的多 Agent 调度画布对最终效果没有真正帮助——但有一个观测视图是真正有用的：能看到 Agent 之间到底交换了什么 context。

team task 的详情页提供一个协作时间线：

• 每个成员的 session 是一条时间线（协调员在最上，sub-agent 依次往下）
• 每次 call_agent 在时间线上落一个点，标明：主→次发出的 sub-message、次→主返回的 result、调用是同步还是异步

不喜欢可以折叠掉。但在 debug 多 Agent 协作时这是最直接的工具——你能立刻看到主 Agent 究竟把什么传给了 sub-agent、sub-agent 又总结回来了什么，不必逐条翻对话记录。

典型场景

分头调研 + 主 Agent 合并

主 Agent 把任务拆给两个 sub-agent：一个调研竞品 ACME，一个调研竞品 Beta，分别把报告写到共享目录里。完成后主 Agent 读这两份文件，合并出一份总报告。

完整流程都在协作时间线里看得到：两次 call_agent 并行发出 → 两个 sub-agent 各自把 markdown 写到 team-<uid>/ACME.md 和 team-<uid>/Beta.md → 主 Agent 读两份后写出 report.md。

同一个 Agent 的多 session 并行

team task 里不一定要有多种 Agent。同一个 Agent 也可以开多个并行 session 各做一件事——前面说过，多 Agent 的本质是把 context 管好，单 Agent 的多 session 同样吃得到这个好处。

例：让一个 code-review Agent 开三个 session 并行检查同一段代码——一个看命名规范、一个看 SQL 安全、一个看前端错误处理。每个 session 都只装载这一个方向的 context，命中率比”一个 session 看所有方面”要高得多。

适用与不适用场景

用 Teamwork：

• 这次任务要拉临时成员（包括你的私有 Agent），完事就解散
• 成员之间需要共享文件，但不想手动管 AFS 目录
• 想观察 Agent 之间的 context 交换、debug 多 Agent 流程

继续用普通 @agent 调用：

• 长期固定的协作关系（比如 reviewer Agent 一直在被各个 dev Agent 调用）——配好 Visibility 和 Slug 就够，没必要每次开 task
• 简单一次性调用、不涉及文件交换

接下来

• 想知道 Agent 之间到底怎么互调、Visibility 怎么配 → 指南 6：多 Agent 协作
• 想懂跨 Agent 文件共享底层 → AFS：跨 Agent 文件共享