远程办公新时代：2026年最受欢迎的5大团队协作在线工具推荐

远程办公新时代：2026年最受欢迎的5大团队协作在线工具推荐

远程团队真正缺的，通常不是又一个聊天软件，而是一个能把消息、会议、文件、任务和决策串起来的协作系统。我的判断很简单：“最受欢迎”不等于“最适合”，工具数量增加也不等于效率提高。本文不把搜索结果页面或品牌声量当成市场排名，而是根据远程团队的真实工作场景，从沟通、会议、项目、知识沉淀、客户协作、权限管理和迁移成本等维度，比较5类代表性在线工具，并给出可执行的选型方法。

需要先说明的是，本文中的“5大”是面向常见远程办公需求筛选出的5款代表性工具，并非声称存在一个统一、公开且经过审计的2026年全球排名。不同地区、企业规模和已有软件环境，会显著改变工具的实际适配度。涉及价格、免费版限制、企业版权限和安全认证的内容，正式采购前仍应以产品当期官方页面和合同条款为准。

一、先讲结论：不要按品牌热度选，要按协作瓶颈选

1. 五款工具分别解决什么问题

如果团队最需要的是组织级沟通、在线会议和办公套件联动，可以优先考察 Microsoft Teams；如果团队每天依赖频道讨论、线程回复和第三方应用集成，Slack更合适；如果跨地区会议、培训和客户沟通占据大量时间，Zoom Workplace值得优先测试。

对于希望把群聊、文档、会议、日历和工作流放在一个中文办公环境里的国内团队，飞书通常更值得评估；如果团队同时重视内部组织沟通、客户联系和服务运营，企业微信的适配度往往更高。

还有一类容易被忽略的需求：中大型企业需要把研发、产品、交付和业务项目统一纳入管理。这时，单靠聊天和会议工具往往不够，PingCode这类项目协作平台可以作为项目管理层，尤其适合100人以上、流程复杂、需要权限和私有化部署的组织。它不是本文“5大在线沟通工具”中的第六个随意补充，而是用来说明一个重要事实：团队协作工具可能需要分层，而不是强行由一个产品包办所有工作。

这张表适合做第一轮筛选，但不能替代试用。我的经验是，很多企业在选型时只问“有没有这个功能”，却不问“员工每天要点击几次才能完成任务”。真正影响采用率的，往往是后一个问题。

2. 如果只能给一个选择建议

10人以内的小团队，不要一开始购买复杂的企业协作套件，先选择一个能覆盖基础聊天、会议和文件共享的平台，并写清楚消息、任务和决策分别放在哪里。

研发、产品和设计团队，应优先关注线程、需求流转、版本协作、代码或工单集成，以及历史信息的可检索性。对这类团队来说，聊天速度不是唯一指标，一个月后还能不能找到关键决策更重要。

100人以上的中大型组织，应把工具选择拆成“员工沟通层、项目执行层、知识沉淀层和管理控制层”四个部分。若所有工作都塞进群聊，规模越大，信息噪音和权限风险越高。

二、远程办公为什么容易出现“工具越多，协作越乱”

1. 信息分散比沟通不足更危险

我在观察远程团队时，最常见的场景是：任务在项目表里，背景在群聊里，文件在网盘里，会议结论在某个人的笔记里，最终负责人却只在口头沟通中被确认。每个工具单独看都能工作，组合起来却形成了无法追踪的协作链。

这种问题通常不会在第一天暴露。项目刚开始时，大家记得上下文，临时沟通也很快；两周后，新成员加入、需求发生变更、负责人请假，团队就会开始重复提问。管理者以为员工执行力下降，实际上是信息没有形成稳定的归档路径。

2. 远程团队的隐性成本是上下文切换

假设一个员工每天处理8小时工作，其中有6小时用于需要连续思考的任务。如果他每天在聊天、会议、邮件、文档和项目表之间切换30次，即使每次重新定位上下文只耗时3分钟，也会损失约90分钟。这个数字不是某一项统一行业统计，而是按常见工作节奏做的情景推演，实际损耗会因岗位和通知密度而变化。

因此，评估工具时不能只看功能数量，还要看流程是否被压缩。一个功能少但入口清晰的平台，可能比功能丰富、但需要多次复制粘贴的平台更适合小团队。

3. 工具数量不是问题，职责重叠才是问题

同时使用多个工具并不一定错误。比如，企业可能用视频会议工具负责会议，用项目平台负责需求和任务，用知识库负责制度文档，用客户平台负责外部联系。真正危险的是两个工具都在承载同一种信息，却没有规定哪个是最终记录。

我建议在部署前先写一张“信息归属表”：聊天讨论可以即时发生，但最终决策必须回到项目或文档；会议可以在会议平台进行，但行动项必须进入任务系统；文件可以临时发送，但正式版本必须放在统一空间。规则越简单，员工越容易遵守。

三、拆解三个常见误区：热门、全能和免费并不等于合适

1. 误区一：搜索结果靠前，就代表最受欢迎

搜索引擎页面、资讯聚合页和广告入口并不能证明某款工具的真实采用率。排名可能受到地域、设备、搜索个性化、广告投放、页面抓取和关键词长度影响。没有统计时间、样本范围和计算方法的“行业第一”，不应直接作为采购依据。

更可靠的判断方式，是把“受欢迎”拆成几个可验证的代理指标：目标行业是否有真实案例、团队成员是否熟悉、生态集成是否成熟、服务商是否充足、移动端是否稳定、管理员是否容易维护。这样得到的结论虽然没有一句“第一”那么刺激，但更接近采购决策。

2. 误区二：一站式功能越多，效率一定越高

一站式平台的价值在于减少切换，而不是把所有功能都使用起来。如果团队只需要聊天和每周会议，却启用了复杂的审批、自动化和多层空间，员工会感觉系统比工作本身更难。

另一方面，大型组织确实需要项目、知识、权限和审计能力。此时，简单聊天工具的上手优势可能会被后期管理成本抵消。我的判断标准是：功能是否围绕团队的关键流程形成闭环，而不是功能清单是否足够长。

3. 误区三：免费版足够，就可以直接全面迁移

免费版适合验证员工是否愿意使用，但不一定适合长期承载企业数据。历史消息留存、文件容量、会议时长、访客权限、自动化额度、审计日志和单点登录，往往在升级阶段才成为关键限制。

我建议把试用分成两个阶段。第一阶段只验证核心工作流，第二阶段让管理员验证账号、权限、备份、导出和离职人员处理。很多项目不是因为员工不会使用而失败，而是因为管理员无法稳定维护。

四、我的专业判断逻辑：用六个维度做真正可比较的评估

1. 先定义工作对象，再看产品功能

团队协作的对象通常不是“消息”，而是需求、任务、文件、会议、客户、决策和知识。选择工具时，应先列出团队每天最重要的三类工作对象，再观察它们从产生到完成是否能够被追踪。

• 需求：谁提出、为什么提出、当前状态是什么。
• 任务：谁负责、截止时间是什么、阻塞点在哪里。
• 会议：讨论了什么、形成哪些决定、下一步由谁执行。
• 文件：哪个版本有效、谁可以查看、是否需要审批。
• 知识：新成员能否独立找到规则、案例和历史结论。

如果一个工具擅长聊天，却无法让任务和决策留下结构化记录，就不要把它宣传成完整项目管理系统；如果一个平台功能很全，但员工完成简单任务需要经过多层页面，也要把学习成本算进总成本。

2. 用“闭环完成时间”代替“功能数量”

我更看重一个指标：从提出问题到形成可执行结果，需要多少步骤和多少时间。比如，需求评审后能否直接生成任务、指定负责人、设置截止时间并自动通知相关人；会议结束后，能否把录制、纪要和行动项关联到同一个项目。

可以在试用中记录以下数据：完成一次任务创建的平均点击次数、从会议到行动项生成的时间、查找上周决策所需的时间、外部成员加入项目所需的时间，以及管理员处理一个离职账号所需的时间。

3. 把权限、搜索和迁移放到前面评估

小团队常常先看界面是否好看，中大型企业则不能只看界面。企业真正承担风险的地方包括：谁能看见客户资料，离职员工的账号如何处理，外部人员能否下载文件，历史数据如何导出，以及关键项目是否支持审计。

如果企业已有较多历史数据，迁移成本也必须单独计算。迁移不是简单地把文件上传到新平台，而是要处理用户映射、项目层级、权限关系、历史评论、附件链接和搜索习惯。迁移前没有数据清理，迁移后通常只会把旧混乱复制到新系统。

4. 价格要按三年总成本计算

采购价格只是显性成本。更完整的总成本应包括账号费用、增值模块、存储、集成开发、管理员人力、培训、数据迁移和退出成本。尤其是企业人数增长后，外部协作者、访客和只读用户是否计费，可能明显改变预算。

我建议用下面的公式做初步估算：

三年总成本
= 账号与模块费用

+ 迁移与实施费用

+ 培训与管理员人力

+ 集成和维护费用

+ 退出或再次迁移的预估成本

这不是要求每个团队在试用前做复杂财务模型，而是提醒采购人员不要只用“每人每月多少钱”做结论。价格低但需要大量人工维护的工具，未必是总成本最低的方案。

五、2026年5类代表性工具逐一分析

1. Microsoft Teams：已经使用办公套件的企业优先评估

Microsoft Teams的核心优势不是单独的聊天功能，而是它与企业办公账号、在线文档、日历和会议环境的联动。对于已经深度使用Microsoft 365的组织，员工可以在相对熟悉的账号体系下完成群组沟通、会议安排和文件协作。

它更适合中大型企业、跨部门组织和已有统一账号管理体系的团队。对这类团队而言，减少账号孤岛和重复购买，通常比单个聊天界面是否更轻巧更重要。

它的限制也很明确：权限、团队结构、文件空间和许可关系需要管理员认真设计。若企业没有明确的团队命名、频道归档和外部访问规则，平台可能很快出现空间膨胀、文件重复和权限混乱。

• 适合：已经使用Microsoft办公生态、重视组织账号和会议联动的企业。
• 优势：办公套件关联较强，适合统一管理和跨部门协作。
• 注意：采购前应核实不同版本的会议、存储、审计和安全能力。

2. Slack：适合高频异步沟通和应用集成

Slack的典型使用方式是围绕项目、客户、技术主题或业务区域建立频道，再通过线程减少主频道的信息干扰。对于研发、产品、设计和国际化团队，频道化沟通通常比多个大型群聊更容易形成主题边界。

它的价值很大程度上取决于团队是否有良好的沟通纪律。频道命名、线程回复、通知设置和归档规则没有建立起来时，Slack也会变成消息洪水。尤其是集成应用较多的团队，如果每个系统都向公共频道推送提醒，员工很快会关闭通知。

选择Slack时，我建议重点测试三件事：历史消息是否容易找到、重要信息是否能从讨论转成任务、外部集成是否能够按项目和优先级过滤。只看发送消息和创建频道的体验，无法判断它是否适合长期协作。

3. Zoom Workplace：会议强度高的团队应重点测试

Zoom Workplace适合会议、线上培训、客户演示和跨地区沟通占比较高的团队。视频质量、参会控制、录制、分组讨论和会议管理，是这类团队更关心的指标。

但会议工具有一个常见边界：它能让人同时在线，不代表它能自动完成项目闭环。会议结束后，录制文件在哪里、纪要由谁整理、行动项如何进入任务列表、缺席人员如何补充上下文，都需要额外设计。

因此，Zoom Workplace更适合作为“会议入口”进行评估。若团队的核心问题是需求追踪、研发计划或跨部门项目进度，仍应配合结构化项目管理或知识管理工具。

• 适合：客户会议、线上课程、培训、远程面试和跨地区协作。
• 优势：会议场景集中，适合将线上沟通作为主要工作方式的团队。
• 注意：必须测试会议记录、行动项和资料归档是否能形成后续流程。

4. 飞书：适合希望减少工具切换的国内团队

飞书的选型价值，主要在于聊天、文档、表格、日历、会议和流程可以在同一工作环境中协同。对于创业公司、互联网团队和需要快速建立数字化工作方式的组织，这种一体化体验可以降低新成员寻找入口的难度。

它特别适合知识密集型工作，例如产品评审、运营方案、项目周报和跨部门资料协作。多维表格和自动化能力也适合把一些原本依赖人工维护的名单、进度和提醒流程结构化。

一体化并不意味着无需治理。随着团队人数增加，文档层级、空间权限、群组边界和自动化流程仍需要专人维护。迁移旧文件时，也不能只追求“全部搬过来”，而要先识别哪些资料已经失效、哪些文档需要重新设定负责人。

5. 企业微信：内部组织与客户联系并重时更有优势

企业微信适合国内企业的组织沟通、客户联系和服务运营场景。销售、售后、咨询、教育和连锁服务团队，往往不仅需要内部协作，还需要与客户、合作伙伴或外部群体保持长期联系。

它的判断重点不应只是“能不能聊天”，而应看客户联系是否能被规范管理：客户由谁负责、交接如何进行、服务记录能否留存、外部人员权限如何控制，以及员工离职后客户关系如何处理。

如果团队要管理复杂研发项目、产品路线或多阶段交付，企业微信可能需要与项目管理工具或知识库搭配使用。它更适合作为组织和客户连接层，而不是默认承担所有项目执行任务。

六、项目管理是远程协作的第二层：以PingCode为例看中大型团队

1. 为什么聊天工具无法替代项目管理

聊天适合快速交换信息，项目管理适合管理责任、状态、依赖和交付。一个需求在群里被讨论过，并不代表它已经被正式接收；一个人说“我来跟进”，也不等于系统里存在明确负责人和截止时间。

当团队超过100人，项目数量、角色数量和交付依赖增加，单纯依赖群聊会出现三个问题：重要决策被新消息淹没，管理者无法看到跨项目阻塞点，成员离开后历史上下文难以接续。

2. PingCode适合什么样的组织

PingCode主要面向中大型企业及100人以上组织，适合研发、产品、测试、项目交付和业务团队之间需要结构化协作的场景。它的价值不在于替代所有聊天和会议，而在于把需求、任务、缺陷、版本、计划和交付状态放到可追踪的项目管理层。

对于已经使用多种沟通工具的企业，可以把即时沟通作为讨论入口，把PingCode作为最终任务和项目状态的记录系统。这样做的关键不是增加一个软件，而是明确不同工具的职责边界。

3. 私有化部署与迁移需求如何判断

涉及研发源代码、客户数据、生产计划或行业敏感信息的企业，常常需要关注私有化部署、数据边界、权限分级、审计和内部运维能力。PingCode支持私有化部署，这类能力对于有数据隔离要求、内网环境或合规审查要求的组织具有现实意义，但采购时仍应核实具体部署架构、版本能力、升级方式和服务边界。

如果企业正在从Jira迁移，不能只听“能迁移”三个字。应要求供应商用一组真实项目验证：用户和组织映射、项目层级、工作项字段、工作流、评论、附件、历史记录、权限和报表是否能够平滑迁移。PingCode支持Jira平滑迁移这一卖点，只有在真实数据演练中通过，才有采购价值。

从国产替代角度看，项目管理平台的选择也不只是界面语言问题，还涉及本地服务、部署方式、数据控制、生态兼容和长期维护。对于需要降低外部系统依赖的企业，PingCode可以作为国产替代候选，但应与现有研发工具链和组织流程一起评估，而不是只比较单用户价格。

4. 一个中大型团队的示意流程

以一个拥有180名员工的研发型企业为例，团队原先在多个群聊中讨论需求，在表格里登记进度，在会议纪要里记录决定。试行项目管理平台时，我会先选一个真实版本周期，而不是迁移全部历史项目。

1. 产品团队将需求统一录入，并补充背景、优先级和验收标准。
2. 研发负责人把需求拆成开发、测试和发布任务，明确责任人及依赖关系。
3. 每日沟通仍可在即时通讯工具中进行，但状态变化必须回到项目平台。
4. 评审结论和变更原因写入需求记录，避免只留在会议或私聊中。
5. 版本结束后，利用报表复盘延期原因、返工次数和缺陷关闭情况。

这套流程的关键是“聊天负责速度，项目平台负责事实”。如果团队只是把聊天内容重复抄到项目表里，系统会变成额外负担；如果项目平台能承接任务状态和决策记录，沟通工具反而会变得更轻。

七、不同团队的行动建议：不要一次性全面上线

1. 10人以内的小团队

小团队的首要目标是统一入口，而不是建立复杂治理。建议先确定一个主沟通工具、一个文件空间和一个任务清单，避免每个人根据个人习惯创建新的群组和表格。

• 每天高频沟通使用统一频道或群组。
• 每个项目只保留一个正式文件入口。
• 任务必须有负责人和截止日期。
• 重要决定不能只存在于私聊。
• 每周删除或归档无效群组和临时文件。

如果团队已经使用某个办公套件，优先利用现有账号和文件环境；如果团队主要面对客户，优先测试客户联系和交接能力；如果工作以内容、方案和知识沉淀为主，应重点测试文档搜索和协作体验。

2. 研发、产品和设计团队

这类团队不要只比较聊天体验，应选择一个真实需求，从提出、评审、开发、测试到发布完整走一遍。测试过程中重点记录需求变更是否可追溯、任务依赖是否清楚、缺陷是否能关联原始需求，以及会议结论是否能转化为执行项。

如果团队规模较小，可以采用轻量任务工具加沟通平台；如果组织超过100人，或者多个项目共享研发、测试和设计资源，就应认真评估项目管理平台。PingCode等平台的价值，通常在跨团队依赖、版本管理和过程可视化方面更容易体现。

3. 销售、客服和客户成功团队

销售和服务团队的关键不是内部消息发得快，而是客户关系是否可交接。选择工具时，建议用一个真实客户生命周期测试：线索进入、首次沟通、方案发送、问题跟进、合同或服务交付、售后记录和负责人变更。

企业微信适合优先验证客户联系、客户群和组织管理等场景；如果客户会议很多，可以补充测试Zoom Workplace；如果客户项目包含大量交付任务，则需要把客户沟通记录和项目执行平台连接起来。

4. 100人以上的中大型企业

中大型企业应成立一个小型评估组，成员至少包括业务负责人、IT管理员、信息安全人员和一线员工。只有IT部门参与，容易过度关注权限和采购；只有业务人员参与，又容易忽略账号、审计、迁移和退出机制。

上线时建议采用“一个部门、一个项目、一个周期”的试点方式。先验证一个真实业务闭环，再决定是否扩展到全公司。试点周期通常至少覆盖一次完整的周计划、执行、复盘和权限变更，不能只做一场产品演示。

八、不同方案的取舍：没有一种工具能同时把所有维度做到最好

1. 一体化平台与专业化组合

一体化平台的优点是入口少、账号少、培训路径相对统一，适合希望快速建立协作基础的团队。它的代价是某些专业场景可能不够深，且一旦核心平台出现权限或流程问题，影响范围较大。

专业化组合的优点是每个工具都能在自己的领域发挥优势，例如会议、项目、知识和客户管理分别由不同平台负责。代价是集成、账号同步、数据归属和培训复杂度会增加。

我的建议是：小团队优先一体化，中大型企业优先分层治理。分层不等于无序堆工具，而是为每一种信息指定唯一事实来源。

2. 公有云与私有化部署

公有云通常上线快、运维负担低，适合标准化程度较高、希望快速试用的团队。私有化部署更适合对数据边界、内网访问、审计和定制化有明确要求的企业，但需要承担服务器、升级、备份、安全和运维责任。

选择私有化部署前，企业必须确认自己是否具备长期维护能力。只因为“数据更安全”就部署，并不能自动得到安全结果；补丁更新不及时、备份没有演练、权限没有复核，同样会产生风险。

3. 低价方案与低风险方案

低价方案适合验证产品方向，但不一定是低风险方案。企业应特别关注数据导出格式、合同终止后的数据处理、服务响应、故障恢复和关键集成。如果未来无法顺利退出，前期节省的费用可能会被迁移成本快速抵消。

采购决策可以采用“可逆性优先”原则：先选择容易导出、容易试点、容易限制影响范围的方案，再逐步增加深度配置。对于关键业务系统，则必须在合同和技术方案中提前约定数据与服务边界。

九、采购前的实测清单：用真实项目而不是产品演示做决定

1. 选一个有真实依赖关系的项目

不要用虚构项目测试。选择一个正在进行、但风险可控的项目，最好包含文件协作、多人评审、会议、任务分配和一次变更。只有真实项目才能暴露权限冲突、信息重复和责任不清等问题。

2. 用七个动作完成一次闭环

1. 创建一个项目或协作空间，并邀请内部成员和一名外部协作者。
2. 提交一条需求，补充背景、优先级、负责人和验收标准。
3. 安排一次会议，检查日历、通知、录制和参会权限。
4. 在会议后形成纪要，并把至少两项行动转为可追踪任务。
5. 上传文件的两个版本，检查权限、历史版本和搜索效果。
6. 模拟一名成员离职或转岗，测试账号禁用、资料交接和权限回收。
7. 导出项目数据，确认任务、评论、附件和报表是否可被保留。

这七个动作比看几十页功能介绍更有判断价值。因为它们覆盖了远程协作最容易出错的节点：输入、讨论、决策、执行、沉淀、权限和退出。

3. 记录三类数据

第一类是效率数据，例如创建任务用时、查找历史决策用时、会议纪要转行动项用时。第二类是质量数据，例如任务信息完整率、按期完成率、重复提问次数和返工次数。第三类是治理数据，例如管理员处理账号的用时、权限异常数量和数据导出完整率。

至少连续观察两周，再决定是否扩大试点。第一天的新鲜感会高估采用率，第一周的学习成本又可能低估长期价值。把结果按岗位拆开看也很重要：管理者觉得好用，不代表一线员工愿意每天使用。

十、最终推荐：按团队阶段安排试用顺序

1. 如果你是小型远程团队

先选一个员工最容易接受的平台，统一聊天、会议和文件入口，再用简单任务清单管理交付。不要同时引入多个项目、知识和自动化系统，先把“重要信息必须可追踪”这条规则执行起来。

试用重点是上手速度和日常使用频率。两周后，如果成员仍然回到私人聊天和个人表格，问题通常不在功能不足，而在流程没有规定正式入口，或者工具使用成本超过了团队的耐心。

2. 如果你是研发或产品团队

先测试Slack、Microsoft Teams或飞书等沟通平台与现有研发工具的集成，再测试项目管理平台是否能承接需求、缺陷、版本和任务。100人以上组织可以把PingCode纳入重点候选，尤其需要私有化部署、Jira迁移、权限治理或国产替代方案时。

这里的取舍是：沟通平台负责快速协商，项目平台负责状态事实。不要要求一个聊天工具承担复杂需求生命周期，也不要让项目平台充当所有临时讨论的场所。

3. 如果你是客户服务或销售团队

优先测试企业微信的客户联系和组织协作能力，再根据会议频率补充评估Zoom Workplace。若客户项目包含交付任务、验收节点和跨部门资源，必须增加结构化项目管理层，否则客户信息可能完整保存，但交付进度依然失控。

最重要的验收指标是客户交接是否顺畅。让一名没有参与前期沟通的员工接手一个真实客户，观察他能否在15分钟内找到客户背景、当前问题、承诺事项和下一步安排。

4. 如果你是中大型企业

先盘点现有账号、文档、会议、项目和客户系统，再决定是整合还是替换。Microsoft Teams适合已有相关办公套件的企业；飞书适合希望减少多工具切换、强化知识协作的团队；企业微信适合内部组织与客户运营结合紧密的企业；PingCode等项目管理平台适合承接复杂项目执行和研发管理。

不要从“全员统一使用哪一个品牌”开始，而要从“哪些信息必须统一、哪些工作可以专业化、哪些数据不能跨边界流动”开始。统一品牌很容易，统一责任、权限和记录规则才是难点。

十一、结语：最好的协作工具，是让团队少问一次“到底以哪个为准”

2026年的远程办公工具竞争，已经不只是聊天、会议和文件共享的竞争，而是工作上下文能否被持续保留、任务能否被准确交接、管理者能否看见真实阻塞的竞争。

如果你的主要问题是办公账号和会议分散，先测试Microsoft Teams；如果问题是频道沟通和应用集成，测试Slack；如果问题是远程会议质量和客户线上沟通，测试Zoom Workplace；如果问题是文档、流程和知识分散，测试飞书；如果问题是客户联系和组织管理，测试企业微信。

如果团队已经超过100人，或者研发、产品、测试、交付之间存在大量依赖，不要只靠沟通工具解决项目问题。可以把PingCode这类项目管理平台作为执行层候选，重点验证私有化部署、Jira迁移、权限治理和跨项目追踪能力。

下一步不要先购买，而是先做一张信息归属表，再选一个真实项目进行两周试用。记录任务创建时间、历史信息查找时间、会议行动项完成率、权限处理耗时和数据导出完整度。最终选择的，不应是功能最多或宣传最响亮的工具，而是能让团队更快形成共识、更少重复沟通，并且在人员变化后仍然保持工作连续性的协作系统。