企业协同办公的关键基座：如何打造融合通信架构

作者 | 何鹏飞，建信⾦科解决⽅案架构师  

⼀ 、引⾔

1.1 协同办公的演进

随着企业数字化转型提速，传统办公模式已⽆法满⾜现代企业对⾼效、灵活和智能化办公的需求。企业亟需⼀个整合多种功能的平台来实现业务流程的⾃动化和优化。近年来，科技企业纷纷推崇"All in One"的协同办公理念，致⼒于打造⼀站式协同办公平台。

⼀站式协同办公平台整合了项⽬管理、即时通信、⽂件共享和任务分配等核⼼功能，⽀持 PC、⼿机、平板等多种终端设备。这不仅减少了员⼯在不同⼯具间切换的时间，还让员⼯能够随时随地办公，显著提升⼯作效率。通过整合多种⼯具和服务 ，企业可以降低对独⽴软件的依赖，从⽽减少采购和维护成本。"All in One"协同办公理念已成为企业数字化转型的重要⽅向，⽽⼀站式办公平台正是实现这⼀⽬标的关键⼯具。

1.2 企业需求的多样性

虽然"All in One"的协同办公概念备受瞩⽬，但企业的实际经营情况远⽐这复杂——各类沟通⼯具林⽴，单⼀⼯具难以满⾜企业所有业务场景的需求。举例来说，企业内部沟通通常依赖于钉钉、飞书等协同办公软件，这些⼯具提供了丰富的协作功能 ，如即时通讯、⽂件共享、任务管理、组织管理等。⽽与客户的沟通往往需要借助微信、旺旺等社交或电商⼯具 ，因为这些平台是客户更熟悉和常⽤的。此外，与产业上下游或合作伙伴的沟通⼜可能需要使⽤其⾃建的办公 App，以满⾜企业⾃⾝组织管理和信息安全的需要。

这导致员⼯在不同⼯具之间频繁切换，不仅增加了时间成本，还可能导致沟通不畅和信息的碎⽚化。员⼯可能需要在钉钉上处理企业内部的待办任务，同时在微信上跟踪客户项⽬的进度，还要在合作伙伴的⾃建 App 上提交数据，这种多⼯具并⽤的模式使得⼯作流程变得复杂且难以管理。不同沟通⼯具之间的数据难以整合，形成信息孤岛。此外，数据分散在多个平台，也增加了数据泄露的风险，尤其是在涉及客⼾隐私和商业机密的情况下。

二、All in One 的定位解析

随着经济持续承压，企业越来越重视降本增效。然⽽，"构建⼀体化企业应⽤ "与"企业业务多样性"之间存在着天然冲突。过去讨论效率时，⼈们往往局限于具体场景的效率提升——⽐如在办公场景中，如何提⾼沟通效率，更快地获取信息、处理事务，以及与他⼈或系统建⽴连接。但从更宏观的视⻆来看，我认为更关键的问题是"如何进⼀步提升整体组织效率"。这是⼀个需要融合企业多个业务场景的效率提升⽅案，⽬标是实现组织效率的最⼤化。只有这样，才能真正为企业整体带来最⼤价值。

这对今天的平台型产品，尤其是规模达到了⼀定体量后的成熟产品⽽⾔，充满了挑战。产品的护城河更多地应该是系统性的，⽽不应是⼀种排他性的。这种系统性构成的差异化，才能给客⼾更深度的价值满⾜。如果只考虑办公场景的“All in Oneˮ ，⽽忽略企业经营整体的效能提升，实际价值要⼤打折扣。所以，“Oneˮ 到底是什么？引发了我的深思。

2.1 不同层级的“Oneˮ

我认为根据所处层级不同，“Oneˮ的含义是⼤相径庭的，按软件研发领域常说的软件 即服务（SaaS）、 平台即服务（ PaaS）、基础设施即服务（ IaaS）看 ，分别对应着基 于端侧的“Oneˮ , 基于技术组件的“Oneˮ和基于基础设施的“Oneˮ。

Cloud Service Models

• 端侧的 One：应当搭建业务联系的桥梁，向⽤⼾提供⼀站式、⼀⽹通服务。

• 技术组件的 One：侧重构建可扩展、 可复⽤的技术核⼼，确保其能在任⼀块业务 （应⽤） ⼟壤上，都能扎根并茁壮成⻓。

• 基础设施的 One：提供安全、稳定的软硬件⽀撑，包括但不限于云化服务器、 ⽹络通信、 资产管理等，对上隐藏晦涩难懂的硬件交互，对下降低配置、运维成本。

2.2 案例印证

字节跳动新成⽴的 AI 部⻔正是上述观点的⽣动体现。2023 年 4 ⽉11⽇，在阿⾥云峰会上 ，阿⾥张勇提出：“所有⾏业、所有应⽤ 、所有软件、所有服务都值得基于新型⼈⼯智能技术、基于 AIGC 各⽅⾯技术⽀撑、⼤模型⽀撑重做⼀遍。ˮ这⼀战略布局呼应了⾏业对技术更新和效率提升的⾼度需求，⽽字节跳动及时组建了 AI 部⻔，以加速该⽅向的业务布局。

⾖包桌⾯版客户端

• Flow（端侧）：聚焦于产品应⽤开发，提供⼀站式 AIGC 服务 ，整合常见的问答、 ⽂⽣图、⽂档总结、辅助编程等功能 ，助⼒业务场景⾼效融合。

• Seed（技术组件）：专注于⼤模型研发，提供统⼀的技术组件，⽀持不同业务应 ⽤的落地和迭代。⽬标是构建可扩展的技术核⼼，确保技术的可复⽤性和适应性。

• Stone（基础设施）：承担系统底层⽀撑职能，提供安全、稳定、 可扩展的技术框架 ，确保硬件与软件层⾯的稳定运⾏ ，降低企业运维成本 ，提升系统可靠性。

通过这种分层次的技术布局，字节跳动在“端侧ˮ、 “技术组件ˮ和“基础设施ˮ构建了⼀个完整的技术体系。确保从顶端的应⽤层到底层的硬件基础，每个层级都能独⽴⾼效运⾏ ，⼜能协同提升整体组织效率。这种多层级的“⼀体化ˮ设计不仅能满⾜当下对企业数字化转型的迫切需求 ，还能为未来的可持续发展提供有⼒⽀持。

三、为何即时通信无法满足企业级协同需求？

在前文中，我们探讨了企业级协同办公系统的“融合”概念，并分析了不同层次的“ONE”架构。其中，即时通信（IM）作为办公沟通的基础设施，确实提升了个体间的信息传递效率。但在企业级协同场景下，IM 仍然存在一些局限。以下即时通信和融合通信的对比：

3.1 定义对⽐

• 即时通信（IM）：是⼀种通过⽹络进⾏实时通信的系统，允许两⼈或多⼈使⽤⽹络 即时传递⽂字、⽂件、语⾳等内容。通常以⽹站、 电脑软件或移动应⽤程序个⽅式提供服务。

• 融合通信（UC）：是⼀种将多种通信⽅式和技术整合到⼀个统⼀平台上的通信模式，旨在打破不同通信⼿段之间的壁垒，实现⽆缝切换和协同⼯作，从⽽提⾼通信效率和⽤⼾体验。

3.2 本质区别

简单来说 IM 是企业协同办公中的⼀种重要⼯具，适合⽤于快速沟通和信息传递。⽽ UC 则是⼀种更全⾯的通信解决⽅案，能够整合多种通信⽅式，提升企业协同办公的整体效率和灵活性，强调业务流程整合和跨系统协同。

四、融合通信的建设⽅法论

4.1 核⼼价值

确切来说，建设融合通信系统应深⼊到技术组件层进⾏全⾯考量。回顾第⼆节的内容，企业协同产品的规划应从服务企业整体经营的角度出发，⽬标是提升组织效率的最⼤化，⽽不仅仅局限于单⼀办公场景的沟通效率。由于业务的多样性，⽆法依赖单⼀的“超级应⽤ˮ来覆盖所有业务活动，排他性地引⼊或⾃建⼀款全能型平台是⾏不通的。

规划者应聚焦于系统化的统⼀与连接，构建技术组件层级，⽽⾮只为某个端⼝或单⼀业务场景提供解决⽅案。真正的重点是通过技术架构的整合和互联，提升各业务模块的协同效能，⽽⾮单纯构建⼀个排他性的应⽤平台。下⾯，我将从业务侧和技术侧两个⽅⾯，详细阐述企业级融合通信技术组建的建设⽅法论。

4.2 业务侧

业务侧主要是从业务需求出发，⾸先要确保组件功能可以充分满⾜业务要求。在此基础上，还能与现有业务建⽴连接，提供统⼀的、灵活的服务，以及有效的成本控制⽅案。

4.2.1 功能完整

核心⽬标：确保融合通信组件能够满⾜企业核⼼需求 ，同时避免功能冗余，提升⽤户体验。

在融合通信的构建过程中，功能的完整性⾄关重要。然⽽，并不表示功能越多越好，⽽是要聚焦于企业的实际需求，确保最关键的 5% 功能可以被 95% 的⽤户⾼效使⽤。这就要求：

• 重点打磨核心功能，如消息收发、会话管理、消息存储与检索等，使其易⽤、高效。

• 遵循“简洁⽽不简单ˮ的设计原则，避免功能堆砌。例如微信的订阅号从最开始的仅⽀持订阅号列表展示，到后来能基于信息流展示；从最开始的在顶部展示订阅号名称，功能栏全部隐藏在右上角“...ˮ⾥，到现在基础信息和常⽤功能放在底部。

这些⽤户常⽤功能的持续迭代，优化改进，令⼈印象深刻。

Notion 的创始⼈ Ivan Zhao 曾发推⽂：“这个世界上最好的系统都是由⼏个模块和⼏个简单的规则组成的，这些规则产⽣了最⼤的⾃由度、可能性和复杂性，同时使事情尽可能直观和明显，设计软件也不例外。ˮ

4.2.2 连接业务

核⼼⽬标：使通信组件与企业的各个业务流程⽆缝衔接，提⾼信息流转效率。

融合通信组件不仅仅是⼀个独⽴的沟通⼯具，更应该成为企业业务链条中的重要⼀环：

• 业务系统集成：需要⽀持与 OA、CRM、ERP、财务、销售、客服、项⽬管理等系 统的深度集成。例如 ，在客户关系管理场景下，客户沟通记录能够⾃动由融合通   信系统归档⾄CRM 系统。销售团队也可以直接在 IM 中查看历史对话 ，并快速响应客户需求。

• 系统间消息推送：如⾃动同步邮件、任务通知、审批提醒等，当有新邮件、任务、 审批时，能及时地借助统⼀的在线 / 离线消息推送触达⽤户 ，使企业内部协同更流畅。

• 智能辅助机器⼈：⼀⽅⾯ ，借助 AIGC 和流式输出等技术 ，创建定制会话或群机器⼈并对接企业⼤模型和知识库，实现常见问题的 Q&A、⽂档编写 / 归纳 / 总结、辅助 设计 / 编码等⼯作；另⼀⽅⾯ ，通过 webhook 等技术，能从会话消息中获取数据 ， 透传给后⽅系统 ，业务处理后异步响应⽤户，后提升⾃动化能⼒ 。例如 ，⽤户在会话内发起了⼯单申请，机器⼈识别到并调⽤⼯单系统 API 创建⼯单，后续再通过消息推送服务，推送问题处理进度⾄⽤户。

• 平台间消息互通：上⾯提到，现实的情况要复杂得多，沟通场合多样，单⼀⼯具难以覆盖企业所有的业务场景。要从业务系统的连续性，真正地延展到业务的连续性。针对难以融合的产品，如两家企业⾃建的 A 和 B 两款即时通信应⽤，可以通过⼀些⼿段实现消息互通：

  消息双发⽹关：部署协议转换⽹关，将各⾃产品的私有协议（如基于 HTTP/JSON 的 API）转换为公⽹协议（如 XML 或特定⼆进制格式）。发出⽅在 发送消息时进⾏私转公 ，经由消息队列（ Kafka、 RabbitMQ 等）发给接收⽅ ，接收⽅消费队列中的内容，通过⽹关公转私，实现 A 的消息能在 B 中呈现。

  虚拟会话：被接⼊⽅提供功能闭环的 SDK ，可选择性地提供交互界⾯ ，接⼊⽅在客户端对接此 SDK，并在会话列表中提供独⽴的⼊⼝，⽤户通过访问此会话进⼊被接⼊⽅的会话列表，查看或回复消息。

4.2.3 统⼀服务

核心目标：确保企业服务能够被统⼀管理，提⾼数据⼀致性，降低运维成本。

企业在规模化扩展的过程中，往往会⾯临多个机构或⼦公司的 IT 系统割裂的问题，导致信息孤岛。解决⽅案包括：

• 组件统⼀：在企业内部，各应⽤对接同⼀套组件，提供⼀致性服务，降低重复建设。

• 数据统⼀：确保所有的沟通数据能在不同逻辑⼦系统（应⽤）之间同步、查询。

• 功能逻辑统⼀：不同业务线的沟通模式可能不同，但底层的功能逻辑需要⼀致。例如，跨部⻔协作时，应当有统⼀的⾝份认证、权限管理、消息收发交互、消息存储策略等。

• 公共接⼝服务：对外提供标准化的公共接⼝，⽅便不同业务系统接⼊ ，减少开发成本。

4.2.4 配置灵活

核⼼⽬标：提供可定制化的解决⽅案，适应不同企业的业务场景。

界⾯是业务的交互⽅式，不同企业的业务需求千差万别，SDK 侧的灵活性太低 ，会严重限制技术组件的发展。这就要求技术组件不能太侵⼊业务，能做到界⾯可修改、功能可选配，具备⾼度可配置性，⽀持企业按需定制：

• UI 可配置：不同业务对界⾯的需求不同，例如客服部⻔可能更关注与客户的对话，研发团队可能更关注代码或企业架构规范等材料的共享，需要组件具备 UI 灵活调整的能⼒。

• 功能可选配：如⾯向客⼾的客服系统不需要群聊功能，⽽协同办公场景则需要复杂的群组管理能⼒。组件应允许企业按需启⽤或隐藏不同功能。

• 权限灵活管理：允许企业为不同岗位、不同部⻔设置不同的通信权限，如销售团队可以与外部客⼾沟通，⽽内部管理⼈员则仅限于内部交流并不允许将内部⽂件发送⾄互联⽹。

4.2.5 成本可控

核心⽬标：在技术投入的同时，合理控制成本并妥善处理现有系统的历史数据迁移。企业升级融合通信系统时，往往已经有⾃建或者外采的产品在运⾏，势必都存储了⼤量的聊天记录、⽣产资料。这就⾯临两⼤挑战：历史数据处理和成本优化。就像是换房子，不能说新房⼦更⼤、装修的更好、⽔电⽹设施更完备、物业更专业更贴⼼，但是屋⾥⼀件家具没有，还是没法住。也不能说换到新房⼦⾥去，就把⽼房⼦⾥家具、家电等尚有价值的资产统统丢弃。需要提供妥善的解决⽅案：

历史数据迁移策略：

• 强制升级：完成即时通信 IM 服务端数据同步后 ，强制 App 从 1.0 升级为 2.0，此⽅案实施简单 ，升级后⽆需处理新⽼ App 兼容问题。

即时通信 IM 平滑升级—强制升级⽅案

• 新旧系统共存：新⽼ App 可以共存 ，消息双发，在 App 1.0 停⽤之前 ，App 后台需要在新⽼系统之间保持实时双向同步，此⽅案相对复杂，对终端⽤户体验更好。

即时通信 IM 平滑升级—新⽼兼容⽅案

降低运营成本：

• 采⽤混合云架构 ，让企业可以根据需求选择本地部署或云端托管 ，优化基础设施成本。

• 通过智能存储和归档 ，及时清理冗余历史数据 ，节省存储空间。

4.3 技术侧

技术侧则更多地基于稳定性、 安全性、扩展性等因素进⾏考量 ，组建上线后 ，这些因素将直接影响到所服务系统的业务持续性。

4.3.1 安全

核⼼⽬标：确保企业通信数据的安全性 ，防⽌信息泄露。

• 数据加密：包含消息传输和存储加密。对数据安全有更⾼要求的场景可以采⽤端到端加密 ，确保数据在传输和存储过程中不会被窃取。

• 访问控制：采⽤零信任架构（ZTNA）对每个⽤户、设备进⾏严格的⾝份验证，防⽌未经授权的⽤户访问和服务调⽤。

• ⽇志与审计：提供完整的⽇志记录和审计功能 ，确保所有通信⾏为可追溯 ，满⾜ 合规要求（如 GDPR、 ISO 27001）。

4.3.2 稳健

核⼼⽬标：保证服务的⾼可靠性，确保通信数据实时、准确、可达

• 消息可靠性：

  消息必达：即使⽤户离线 ，系统也会进⾏重试或离线推送 ，待⽤户恢复在线后⾃ 动推送 ，确保重要信息不会丢失。

  ⼀致性保证：确保所有终端设备上的消息状态（ 已读 / 未读等） 同步⼀致

• 实时性优化：

  采⽤⻓连接 +WebSocket 技术 ，确保消息能够低延迟到达。

  结合 MQTT 等消息推送协议 ，适配不同终端设备 ，保证移动端在弱⽹环境下也能 稳定接收消息。

4.3.3 扩展

核⼼⽬标：确保系统能够⽀持业务增⻓，快速扩容

• 分布式架构：

  采⽤微服务架构，⽀持按需扩展，避免单点瓶颈。

  结合 CDN 加速，优化全球⽤户的通信体验。

• 多租户⽀持：

  确保⼤企业能够在同⼀套融合通信系统上管理不同的⼦公司或业务单元，⽀持⾃定义组织架构、权限分级等功能。

4.3.4 容灾

核⼼⽬标：在突发情况下，确保系统能够快速恢复，减少业务损失。

• 多机房部署：采⽤主备容灾架构，在不同地区部署多个数据中⼼，确保任何⼀个数据中⼼故障时，系统能够⾃动切换到备份机房。

• 智能故障检测：结合 AI 运维， ⾃动检测服务器负载、异常流量，提前预警并执⾏⾃恢复操作。

• 快速恢复机制：采⽤数据库分⽚ + ⽇志回滚机制，确保在数据损坏或丢失时能够快速恢复。

五、本质：业务需求驱动

5.1 业务诉求解析

业务提出的需求是基于角⾊本⾝的需要，关注的是功能更新能否⽀撑业务活动，对实现⽅式往往不会提详细要求。要探索业务的根本诉求，并深⼊思考达成业务诉求的实现⽅式，在业务需求达成和应⽤⻓远规划上取得平衡。例如，企业管理层要求加强公司管理，能⾼效的贯彻落实战略和计划。管理是组织⾏为，是要达成的结果，推导出来就是要强化信息传递的效率，⾯对⾯、打电话、视频会效率还是低，再细化⽅案就是消息在线和组织在线，当组织在线了管理就在线了，管理是顺⽔推⾈的过程。

5.2 产品核⼼原则

对产品和功能设计的要求就是要做到让员⼯都乐意⽤产品 ，本质上还是聚焦服务⽤户，⽽⾮盲⽬迎合趋势。产品经理是应该⾯向⽤户做事情 ，理解⽤户的画像 ，思考⽤户的场景 ，解决⽤户的需求 ，提升使⽤体验 ，⽽⾮堆砌功能。这⼀点亘古不变 ，不是随着时代发展或者某些⼈的意志转移⽽变化的。

六、总结

All in One 不是打造排他性的唯⼀应⽤或服务 ，⽽是实现系统性协同。融合通信作为技术组件，顶层设计应聚焦于通过系统性协同来打破信息孤岛 ，实现各业务的⾼效整合。不仅是对即时通讯的增强，更是连接企业内部、外部及合作伙伴的全场景业务连接器 ，帮助企业打通 OA、 CRM、 ERP 等关键系统 ，提升信息流转效率。

在技术组件实施建设⽅⾯ ，必须兼顾安全性、稳定性、 可扩展性和灵活性：通过全链 路加密和零信任架构保障数据安全，利⽤分布式架构和智能容灾机制确保系统可靠性，同时提供标准化 API 和灵活配置能⼒，满⾜企业的个性化需求。归根结底，融合通信的⽬标不是优化单个功能点，⽽是以提升整体组织效率为核⼼，帮助企业实现全局性的运营效率提升，在数字化竞争中保持优势地位。

作者介绍

何鹏飞，建信⾦科解决⽅案架构师，具有丰富的企业级解决⽅案设计和实施经验。⻓期专注于 ToB 领域，在企业协同办公、零信任⽹络安全架构等产品的规划、设计与建设方面，积累了深厚的技术背景和⾏业实践。擅⻓将前沿技术与企业实 际需求相结合，为客户提供定制化、 高效能的解决方案。