1. 项目概述一个连接Google Chat与Pub/Sub的智能插件最近在折腾自动化消息流转的时候发现了一个挺有意思的开源项目teyou/openclaw-googlechatpubsub-plugin。简单来说这是一个为OpenClaw平台设计的插件核心功能是打通Google Chat谷歌聊天和Google Cloud Pub/Sub谷歌云发布/订阅服务之间的双向通道。你可以把它想象成一个“翻译官”兼“邮差”它能让Google Chat里的消息自动发布到Pub/Sub的主题Topic里也能把来自Pub/Sub订阅Subscription的消息精准地推送到指定的Google Chat空间Space或私聊中。这玩意儿解决了一个什么痛点呢在云原生和DevOps的日常里我们经常需要把各种系统事件、监控告警、CI/CD流水线状态、日志摘要等实时地通知到团队协作工具里比如Google Chat。传统做法可能是写个脚本调用Chat的Webhook API但这样每个需要通知的地方都得单独维护一套逻辑散乱且难以管理。而Pub/Sub作为谷歌云上强大的异步消息服务本身就是处理事件流、解耦系统组件的最佳实践。这个插件恰恰是把这两大“神器”优雅地结合在了一起。它让事件驱动架构Event-Driven Architecture的“事件”能够以一种更友好、更互动的方式直接触达最终的用户和团队。对于运维工程师、SRE、后端开发者或者任何在GCPGoogle Cloud Platform生态里构建应用、需要强化团队信息同步效率的人来说这个插件提供了一个开箱即用的、可扩展的解决方案。你不用再从零开始造轮子去处理认证、重试、消息格式转换这些繁琐的细节而是可以专注于业务逻辑本身。接下来我就结合自己的部署和调试经验把这个插件的里里外外、怎么用、怎么避坑给大家拆解清楚。2. 核心架构与设计思路解析2.1 为什么是OpenClaw插件首先得理解OpenClaw是什么。OpenClaw本身是一个开源的、插件化的机器人框架它设计初衷就是为了统一管理和对接各种聊天平台如Slack, Discord, 当然也包括Google Chat与后端服务。它提供了一个核心的运行时和插件规范让开发者可以专注于编写特定功能的插件而不用操心消息接收、分发、生命周期管理这些底层通用逻辑。teyou/openclaw-googlechatpubsub-plugin就是基于这个框架开发的一个功能插件。这种设计带来了几个显著优势解耦与复用插件只关心“Google Chat”和“Pub/Sub”之间怎么通信而用户认证、插件加载、健康检查等都由OpenClaw核心负责。这使得插件本身非常轻量和专注。标准化配置OpenClaw通常使用统一的配置文件如YAML来管理所有插件的设置。这意味着这个插件的配置方式会和你的其他OpenClaw插件保持一致降低了学习和维护成本。生态集成你可以轻松地将这个插件与你部署的其他OpenClaw插件比如连接数据库的、调用外部API的组合使用构建出更复杂的自动化工作流。所以选择这个插件本质上你是选择了一个标准化、可集成的方案而不是一个孤立的脚本。2.2 双向消息流设计剖析这个插件的核心价值在于实现了双向、异步的消息流。我们来拆解一下这两个方向方向一从Google Chat到Pub/Sub (Chat - Pub/Sub)这是插件作为“消息生产者”的角色。当用户在配置好的Google Chat空间里发送一条消息时插件会捕获到这条消息事件。但它不是简单转发而是会做一系列处理事件格式化将Google Chat特有的消息结构包含发送者、消息内容、线程ID、空间ID等元数据转换成一个更通用、结构化的格式通常是JSON。属性提取插件允许你通过配置提取消息中的关键信息作为Pub/Sub消息的“属性”Attributes。例如你可以把发送者的邮箱、消息类型文本、卡片作为属性这样Pub/Sub的订阅者就可以根据这些属性进行过滤和路由。发布到指定主题将格式化后的消息体作为数据Data连同提取的属性一起发布到你在GCP项目中预先创建好的一个Pub/Sub主题。这个方向典型的使用场景是将团队在Chat中的操作指令或讨论关键点作为事件触发后端流程。比如在运维频道发送“/deploy service-a v1.2.3”插件将其发布到Pub/Sub然后由订阅了这个主题的云函数Cloud Function自动触发部署流程。方向二从Pub/Sub到Google Chat (Pub/Sub - Chat)这是插件作为“消息消费者”的角色。插件会监听一个或多个你指定的Pub/Sub订阅。主动拉取或推送插件会以配置好的间隔主动从Pub/Sub订阅中“拉取”Pull消息。这是一种可靠的方式确保消息不会丢失。消息转换与渲染拉取到的Pub/Sub消息其数据字段可能是一段JSON文本、一个日志字符串或者是一个已结构化的通知对象。插件需要将这些数据转换成Google Chat API能够识别的消息格式。这里通常是插件最需要定制化的地方。简单的文本可以直接转发复杂的可能需要渲染成Google Chat的“卡片消息”Card Message包含按钮、图片、表格等富交互元素。投递到指定空间转换后的消息会被发送到配置中指定的Google Chat空间或私聊。插件需要处理Chat API的限流、重试机制。这个方向是最常用的用于实现各种系统通知监控告警来自Cloud Monitoring、代码合并请求来自Cloud Build、预算预警来自Billing API等都可以通过Pub/Sub中转然后由这个插件推送到团队群聊实现信息的集中化和实时化。注意这种双向设计意味着插件需要同时具备Google Chat API和Google Cloud Pub/Sub API的调用权限且两者的配置如主题名、订阅名、空间Webhook地址必须准确无误这是后续部署的关键。2.3 配置驱动的灵活性从项目文档和代码结构看这个插件高度依赖外部配置。主要配置项通常包括GCP项目与认证指定GCP项目ID以及服务账号密钥文件路径用于API调用。Pub/Sub设置pubsub_topic_id用于接收Chat消息的Pub/Sub主题ID。pubsub_subscription_id插件监听并从中消费消息的Pub/Sub订阅ID。pubsub_subscription_project_id订阅所属的GCP项目ID可能与插件运行项目不同。Google Chat设置google_chat_webhook_url用于发送消息到Chat的Incoming Webhook URL。这是最常用的方式无需复杂的OAuth。google_chat_space_name插件需要监听的Chat空间名称用于Chat-Pub/Sub方向。可能还有service_account_json如果使用服务账号模拟用户来调用Chat API则需要此项。这种配置驱动的方式使得同一个插件二进制文件可以通过不同的配置文件轻松服务于不同的环境开发、测试、生产或者同时连接多个不同的Chat空间和Pub/Sub主题组合。3. 部署与配置实操全指南理论讲完了我们来点硬的。假设你已经在某个服务器或容器环境里运行了一个OpenClaw实例现在要把这个插件加进去。以下是我从零部署的一次实录。3.1 前期准备权限与资源创建在配置插件之前必须在Google Cloud Console上把“路”铺好。这是最容易出错的一步。3.1.1 在GCP上创建服务账号并授权插件需要一个身份来调用Google Chat和Pub/Sub的API。最佳实践是使用服务账号Service Account。进入IAM与管理 服务账号点击“创建服务账号”。给它起个名字例如openclaw-chat-pubsub-bot。授予这个服务账号以下最小必要角色Pub/Sub发布者(roles/pubsub.publisher)用于向主题发布消息。Pub/Sub订阅者(roles/pubsub.subscriber)用于从订阅拉取消息。Chat API调用者这个角色比较特殊。如果使用Webhook方式发送消息则不需要Chat API权限。但如果插件需要读取Chat消息Chat-Pub/Sub方向则必须启用Google Chat API并为服务账号授权。通常需要将服务账号的邮箱地址手动添加到目标Google Chat空间的成员中并赋予“可以发布”的权限。因为Chat API目前对服务账号的支持有限读取消息可能需要借助“域范围委托”或使用用户OAuth2.0凭证这增加了复杂度。因此很多实践会仅启用Pub/Sub - Chat的单向流程这更简单稳定。我们这里先按单向流程准备。创建完服务账号后为其生成一个JSON格式的密钥。下载并妥善保存为service-account-key.json。切记不要将此文件提交到任何版本控制系统3.1.2 创建Pub/Sub主题和订阅进入Pub/Sub 主题点击“创建主题”。主题ID可以命名为openclaw-chat-events。主题创建后进入该主题点击“创建订阅”。订阅ID例如openclaw-chat-notifier。传递类型选择“拉取”。其他设置如消息保留期、确认期限可以先用默认值。现在你有了一个主题 (openclaw-chat-events)用于接收来自其他系统如Cloud Functions, Cloud Build的消息。一个订阅 (openclaw-chat-notifier)插件将监听这个订阅把消息推到Chat。一个拥有发布/订阅权限的服务账号密钥。3.1.3 在Google Chat中配置Webhook这是实现Pub/Sub - Chat推送的关键。进入你需要接收通知的Google Chat空间。点击空间名称旁边的下拉箭头选择“管理Webhook”。点击“添加Webhook”输入一个名称如“运维告警机器人”然后点击“保存”。系统会生成一个长长的URL格式类似https://chat.googleapis.com/v1/spaces/XXXX/messages?keyYYYYtokenZZZZ。复制并保存好这个URL这就是你的google_chat_webhook_url。3.2 插件安装与配置假设你的OpenClaw是基于Docker Compose部署的。3.2.1 获取插件通常OpenClaw插件可以以二进制文件或容器镜像的形式提供。你需要查看teyou/openclaw-googlechatpubsub-plugin项目的Release页面获取最新的可执行文件或镜像名。 例如如果提供Docker镜像# 在Dockerfile中或直接拉取 docker pull ghcr.io/teyou/openclaw-googlechatpubsub-plugin:latest3.2.2 编写插件配置文件在OpenClaw的配置目录下例如./plugins/config/为这个插件创建一个YAML配置文件比如googlechat-pubsub.yaml。# googlechat-pubsub.yaml plugin: googlechat-pubsub # 插件名称需与OpenClaw识别的名称一致 enabled: true config: # GCP 配置 gcp_project_id: your-gcp-project-123 # 服务账号密钥可以是文件路径或base64编码的内容。这里用路径密钥文件需挂载到容器内。 google_application_credentials: /run/secrets/service_account_key.json # Pub/Sub 消费者配置 (Pub/Sub - Chat) pubsub: subscription_id: openclaw-chat-notifier # 如果订阅在另一个项目取消注释并修改 # subscription_project_id: another-gcp-project # Google Chat 配置 (用于发送消息) google_chat: # 使用Webhook方式最简单 webhook_url: https://chat.googleapis.com/v1/spaces/XXXX/messages?keyYYYYtokenZZZZ # 可选消息格式模板。插件可能支持简单的Go模板用于定制消息样式。 # message_template: 【告警】来自系统: {{.source}}\n内容: {{.message}} # 可选Chat到Pub/Sub的生产者配置 (Chat - Pub/Sub)如果启用则需配置Chat API # chat_to_pubsub: # enabled: false # 默认关闭因为配置较复杂 # space_name: projects/your-project-id/spaces/your-space-id # pubsub_topic_id: openclaw-chat-events关键点说明google_application_credentials这里指向容器内的路径。你需要通过Docker的Secrets或卷挂载volumes的方式将之前下载的service-account-key.json文件放到容器内的这个位置。webhook_url务必使用你在Chat中创建的Webhook URL这是单向推送的核心。chat_to_pubsub部分被我注释掉了。强烈建议初次部署只开启单向Pub/Sub - Chat这能避免Chat API复杂的认证和权限问题让系统先跑起来。3.2.3 修改OpenClaw主配置你需要修改OpenClaw的主配置文件如openclaw.yaml或config.yaml告诉它加载这个新插件。# openclaw.yaml 片段 plugins: - name: googlechat-pubsub config_path: ./plugins/config/googlechat-pubsub.yaml # 如果插件是独立容器可能还需要指定镜像或命令 # type: docker # image: ghcr.io/teyou/openclaw-googlechatpubsub-plugin:latest3.2.4 使用Docker Compose部署如果你的OpenClaw使用Docker Compose更新你的docker-compose.yml文件。version: 3.8 services: openclaw: image: your-openclaw-core-image:latest volumes: # 挂载插件配置目录 - ./plugins/config:/etc/openclaw/plugins/config:ro # 挂载服务账号密钥作为只读文件 - ./secrets/service-account-key.json:/run/secrets/service_account_key.json:ro # ... 其他OpenClaw配置 # 如果插件是作为独立sidecar容器运行取决于OpenClaw架构 googlechat-pubsub-plugin: image: ghcr.io/teyou/openclaw-googlechatpubsub-plugin:latest volumes: - ./plugins/config/googlechat-pubsub.yaml:/config.yaml:ro - ./secrets/service-account-key.json:/run/secrets/service_account_key.json:ro environment: - CONFIG_PATH/config.yaml depends_on: - openclaw restart: unless-stopped具体方式取决于OpenClaw的插件运行模式是作为核心进程的模块还是独立的sidecar容器。你需要查阅OpenClaw和该插件的具体文档来确定。3.3 验证与测试配置完成后启动或重启你的OpenClaw服务。检查日志首先查看OpenClaw和插件容器的日志确认没有报错特别是关于GCP认证和Pub/Sub订阅连接的错误。docker-compose logs -f openclaw googlechat-pubsub-plugin你应该能看到类似“Plugin loaded successfully”、“Connected to Pub/Sub subscriptionopenclaw-chat-notifier”的信息。发送测试消息到Pub/Sub这是验证整个链路是否通畅的最佳方式。 你可以使用gcloud命令行工具gcloud pubsub topics publish openclaw-chat-events \ --message{\text\: \Hello from Pub/Sub! This is a test message.\} \ --attributesourcetest,typenotification这条命令会向openclaw-chat-events主题发布一条JSON格式的消息并附带两个属性。查看Google Chat几秒钟内你应该在配置了Webhook的Google Chat空间里看到这条测试消息。如果消息成功送达恭喜你基础链路通了测试更复杂的消息格式尝试发布一个符合Google Chat卡片消息结构的JSON看看插件是否能正确渲染。这需要你查阅Google Chat Card API文档和插件对消息格式的支持情况。4. 核心功能深度使用与定制基础链路通了只是第一步要让这个插件真正发挥威力还得深入它的核心功能。4.1 消息格式的转换与模板化插件最核心的价值在于“转换”。原始的Pub/Sub消息数据通常是一个字符串或JSON需要被转换成Google Chat能展示的格式。4.1.1 理解输入与输出输入Pub/Sub Message Data可以是任意字符串。但在实践中为了结构化我们通常发布JSON。例如一个来自Cloud Monitoring的告警消息{ incident: { condition_name: CPU usage 80%, resource_name: my-compute-instance, state: open, url: https://console.cloud.google.com/monitoring/alerting/incidents/... } }输出Google Chat MessageGoogle Chat API支持两种主要格式简单文本{“text”: “Alert: CPU usage is high on my-compute-instance”}。卡片消息功能强大支持标题、段落、图片、按钮、键值对列表等。例如可以把上面的告警信息渲染成一个漂亮的卡片包含“查看详情”按钮直接链接到Console。4.1.2 利用插件模板功能高级的插件会支持模板引擎如Gotext/template或sprig。你可以在配置文件中定义一个message_template。当插件收到Pub/Sub消息后会解析消息数据如果是JSON会反序列化为对象然后将其作为上下文Context传入模板进行渲染生成最终的Chat消息文本或卡片JSON。假设插件支持模板你的配置可以这样写google_chat: webhook_url: your-webhook-url message_template: | { cards: [{ header: {title: 监控告警, subtitle: {{.incident.condition_name}}}, sections: [{ widgets: [ {keyValue: {topLabel: 资源, content: {{.incident.resource_name}}}}, {keyValue: {topLabel: 状态, content: {{.incident.state}}}}, {buttons: [{textButton: {text: 查看详情, onClick: {openLink: {url: {{.incident.url}}}}}}]} ] }] }] }这样当收到上面的告警JSON时插件就会生成一个完整的卡片消息并发送到Chat。你需要仔细阅读插件的文档确认其支持的模板语法和输入数据结构。4.1.3 备选方案前置消息格式化如果插件本身不支持复杂模板一个更灵活的做法是在消息发布到Pub/Sub之前就将其格式化为Google Chat API能直接接受的最终消息格式。 例如你可以写一个Cloud Function专门处理原始告警事件将其转换成Chat卡片JSON然后发布到openclaw-chat-events主题。这样插件就只需要做一个简单的“搬运工”直接转发消息体即可。这种方式将转换逻辑前移让插件更轻量也让你能使用更熟悉的编程语言如Python、Node.js来处理复杂的转换逻辑。4.2 利用Pub/Sub属性进行消息路由和过滤Pub/Sub消息除了data字段还有一个attributes属性字段这是一个键值对集合。这个特性在这个插件场景下非常有用。4.2.1 属性过滤你可以在创建Pub/Sub订阅时设置过滤条件。例如你只有一个Chat空间但想接收来自不同系统的消息。你可以在发布消息时设置属性# 发布部署消息 gcloud pubsub topics publish openclaw-chat-events \ --messageDeployment succeeded for service-frontend \ --attributesystemcloud-build,envproduction,typedeployment # 发布预算告警 gcloud pubsub topics publish openclaw-chat-events \ --messageProject budget exceeded 90% \ --attributesystembilling,severitywarning,typealert然后你可以为插件创建多个订阅每个订阅使用不同的过滤条件。例如订阅A (sub-chat-build) 过滤条件systemcloud-build订阅B (sub-chat-billing) 过滤条件systembilling AND severitywarning然后你可以运行两个插件实例分别监听这两个订阅并配置不同的webhook_url将消息发送到不同的Chat空间如“部署频道”和“财务频道”。这样实现了消息的精细化路由。4.2.2 插件利用属性即使只有一个订阅插件也可以在配置中读取消息的属性并将其用于模板渲染或逻辑判断。例如在模板中可以使用{{.attributes.system}}来获取属性值从而在Chat消息中动态显示消息来源。4.3 错误处理与重试机制在生产环境中网络抖动、服务暂时不可用是常态。一个健壮的插件必须具备良好的错误处理和重试能力。Pub/Sub侧确认机制插件在成功处理一条消息即成功发送到Google Chat后必须向Pub/Sub发送“确认”Ack。如果处理失败如Chat API返回5xx错误则应发送“否定确认”Nack这样Pub/Sub会在稍后重新投递这条消息。你需要确认插件是否正确实现了这一逻辑。Chat API限流与退避Google Chat API有速率限制。插件在发送消息时如果遇到429Too Many Requests错误应该实现指数退避Exponential Backoff重试而不是立即失败。插件健康检查与监控将插件本身纳入监控。OpenClaw框架通常提供健康检查端点。你可以配置探针并设置告警当插件进程异常退出时能及时通知当然不能通过它自己来告警需要另一个通道。5. 生产环境部署的注意事项与排坑实录在实际部署和运维这个插件的过程中我踩过几个坑这里分享出来希望能帮你绕过去。5.1 权限配置的深水区问题1服务账号无法读取Google Chat消息这是启用Chat-Pub/Sub方向时最常见的障碍。Google Chat API对服务账号的支持并不像其他GCP API那样直接。即使你给服务账号赋予了chat.messages.readonly等角色它也无法直接读取一个普通群聊空间的消息因为它不是“用户”。解决方案与取舍方案A推荐简单放弃Chat-Pub/Sub方向仅使用Pub/Sub-Chat的单向通知。对于绝大多数通知场景这已经足够了。如果需要从Chat触发操作可以使用Chat内置的“斜杠命令”/command功能配合Google Cloud Functions的HTTP端点来实现这通常是更标准的方式。方案B复杂需域管理员使用G Suite域内的服务账号并配置“域范围委托”Domain-wide Delegation然后使用OAuth 2.0 JWT授权。这需要域管理员操作且配置繁琐不适合所有环境。方案C使用用户凭证不使用服务账号而是使用一个真实用户的OAuth 2.0凭证。这需要手动完成一次OAuth授权流程获取刷新令牌并将令牌安全地存储起来。这种方式将插件与特定用户绑定存在令牌过期和用户权限变更的问题。我的建议除非有非常强烈的双向交互需求否则优先采用方案A。保持架构简单就是最大的稳定。问题2Webhook URL泄露你的Webhook URL包含了授权令牌token任何人拿到这个URL都可以向你的Chat空间发送消息。这可能导致垃圾信息或安全风险。解决方案定期轮换在Google Chat的Webhook管理界面定期删除旧Webhook并创建新的然后更新插件的配置。限制消息源虽然Webhook本身难以做来源验证但你可以在插件逻辑或前置的Pub/Sub发布者那里进行校验。例如要求所有发布到openclaw-chat-events主题的消息必须携带一个只有内部系统知道的密钥属性插件在转发前先验证这个属性。5.2 消息格式兼容性与调试问题发送了卡片消息JSON但Chat显示为纯文本代码块。这是因为插件发送的消息头Content-Type不正确或者消息结构不符合Chat API要求。排查步骤检查插件日志查看插件发送HTTP请求的日志确认请求体Body是否是你期望的完整卡片JSON。检查HTTP头确认插件发送请求时Content-Type头是application/json; charsetUTF-8。简化测试先在配置中使用最简单的纯文本模板{text: test}确认基础通信正常。使用curl模拟用curl命令直接向你的Webhook URL发送一个已知正确的卡片消息排除插件转换逻辑的问题。curl -X POST -H Content-Type: application/json; charsetUTF-8 \ -d {cards:[{header:{title:Test Card}}]} \ YOUR_WEBHOOK_URL查阅Google Chat API文档确保你构建的卡片JSON结构完全符合官方文档规范。一个常见的错误是嵌套层级不对或者使用了不支持的部件Widget。5.3 性能与可靠性考量问题消息量增大时出现延迟或丢失。Pub/Sub拉取间隔检查插件的配置看是否有控制从Pub/Sub拉取消息频率的参数如pull_interval_seconds。如果设置得太长如30秒会导致消息延迟。对于实时性要求高的告警可以设置为1-5秒。但要注意频繁拉取会增加API调用次数。并发处理插件是单线程顺序处理消息还是支持并发如果处理一条消息尤其是调用Chat API耗时较长就会阻塞后续消息。查看插件文档或代码了解其并发模型。如果性能成为瓶颈可以考虑启动多个插件实例监听同一个订阅Pub/Sub支持这种负载均衡但要注意消息的顺序性可能会被打乱。确认超时插件处理消息后向Pub/Sub发送Ack/Nack的操作应该有超时设置并做好错误处理避免因为一次Ack失败导致消息被重复投递。5.4 监控与可观测性将插件纳入你的监控体系日志聚合确保插件输出的日志INFO, WARN, ERROR级别被收集到像Cloud Logging或ELK这样的集中日志系统。关键要关注消息处理成功/失败计数、API调用错误、认证错误。指标监控如果插件暴露了Prometheus格式的指标如messages_processed_total,message_processing_duration_seconds将其纳入你的PrometheusGrafana监控栈。关注消息处理速率、延迟和错误率。端到端健康检查可以编写一个轻量级的定时任务定期如每5分钟向你的Pub/Sub主题发送一条测试消息并验证它是否能在预期时间内出现在Google Chat中。这是最直接的业务层面健康检查。6. 进阶应用场景与扩展思路当你熟练掌握了这个插件的基本用法后可以尝试将它融入到更复杂的自动化场景中。场景一构建统一的运维告警中心将所有GCP服务的告警Cloud Monitoring、审计日志Cloud Audit Logs中的关键事件、以及自定义应用的错误都通过Pub/Sub汇聚。然后利用这个插件根据事件类型通过属性过滤和严重等级将消息分发到不同的Chat频道如“P0-紧急告警”、“P1-重要通知”、“日常信息”。你可以在插件模板中根据severity属性为消息卡片设置不同的颜色如红色代表CRITICAL黄色代表WARNING让告警一目了然。场景二CI/CD流水线状态实时播报在Cloud Build的构建配置中添加一个最后的步骤将构建状态成功、失败、触发原因、代码变更链接等信息发布到Pub/Sub主题。插件接收到后将其格式化为一个清晰的卡片包含构建编号、状态徽章、跳转到构建日志和代码提交的按钮实时推送到开发团队的Chat空间让所有人第一时间了解构建健康状况。场景三与工作流引擎集成你可以使用Cloud Workflows 或 Terraform Cloud 等工具编排复杂的运维流程。在这些流程的关键节点开始、完成、失败向Pub/Sub发送事件。插件将这些事件通知到Chat形成一个可交互的进度看板。你甚至可以在卡片消息里加入“批准”、“重试”等按钮这些按钮可以关联到另一个HTTP端点触发工作流的后续操作实现简单的ChatOps交互。扩展思路开发自定义插件如果你发现teyou/openclaw-googlechatpubsub-plugin的模板功能不够灵活或者有特殊的格式要求完全可以基于OpenClaw的插件SDK开发一个你自己的定制版本。你可以增加对Jinja2模板的支持集成更强大的渲染引擎或者添加对Microsoft Teams、Slack等其他平台的支持打造一个属于你自己团队的多渠道通知中枢。开源项目的价值就在于它提供了一个坚实的基础让你可以在此基础上构建最适合自己需求的东西。