办公聊天软件接入 Hermes Agent 实录零为什么做、怎么选、三篇地图本系列基于 Hermes Agentv0.20.0 Dify1.16.1实测三篇文章分别对应企业微信、飞书、钉钉的完整接入实录。为什么做这件事很多企业有这样的需求把企业的 AI 能力变成「聊天窗口里随叫随到的 AI 助手」——员工在钉钉/飞书/企业微信里直接问「产品手册里 XX 怎么配置」「帮我查一下订单状态」「生成这周的工作汇报」机器人秒回、回答还带引用能追溯到来源。这里说的「AI 能力」不只是知识库问答也包括业务流程工作流订单查询、审批、报表生成……——聊天软件只是入口背后接什么业务能力都行。本系列以知识库问答为例演示最直观、最容易上手但同一套链路换成其他工作流应用完全一样。比打开网页查文档自然得多也比自建一套 App 轻得多——办公软件已经在用业务系统已经存在要做的只是把它们接起来。共同架构三篇同一套Dify 编排层Hermes 调度层用户入口层消息推送消息推送消息推送调用 MCP 工具查询触发返回结果返回结果格式化回复回推消息回推消息回推消息企业微信客户端钉钉客户端飞书客户端Hermes GatewayWebSocket 长连接Hermes Agent会话管理/用户身份/权限Dify 知识库RAG 检索Dify 工作流审批/工单/复杂逻辑如图所示我们采用**「Hermes 负责连接与执行Dify 负责知识与编排」的分层解耦架构**Hermes 屏蔽了企业微信、飞书、钉钉三大平台的底层差异长连接/事件订阅/身份映射Dify 提供 RAG 检索和可视化工作流编排能力两者通过 HTTP/MCP 协议无缝对接。前端用哪款聊天软件后端是同一套——三篇的区别只在「前端平台怎么接」后端完全一致。为什么不直连为什么要加 Hermes 这一层有人会问Dify 官方也支持接入飞书/钉钉为什么还要中间加一个 Hermes直接让 Dify 对接多个聊天软件会遇到三个现实问题会话状态不一致——每个平台各自维护会话员工在企微问了一半、切到飞书继续问上下文对不上用户身份割裂——同一个员工在企微/飞书/钉钉是三个不同 ID权限控制、审计追踪都断链无法调用本地能力——Dify 跑在云端调用 Shell、本地文件、内部系统这类「终端执行」能力受限加 Hermes 作为唯一网关后三平台事件订阅统一收口、用户身份统一映射一个大脑认一个人、会话按平台隔离且可跨平台管理Dify 专注它最擅长的知识检索和业务编排。Hermes 管连接与执行Dify 管知识与编排——各干各的互不替代。三篇怎么选篇平台接入路线适合谁一企业微信智能机器人长连接极简想要最少配置快速跑通还想了解「一个机器人调多个 Dify 应用」二飞书权限矩阵 事件订阅 版本发布完整配置用飞书办公想理解聊天软件接入的完整机制三钉钉Stream 模式长连接个人开发者友好用钉钉办公没有企业资质、想用个人账号自建的开发者系列文章列表序号标题主题链接零办公聊天软件接入 Hermes Agent 实录零为什么做、怎么选、三篇地图系列总览本篇本文一办公聊天软件接入 Hermes Agent 实录一企业微信 WebSocket 长连接 Dify 知识库问答v0.20.0 实测极简路线 多 Dify 应用 架构原理发布后贴链接二办公聊天软件接入 Hermes Agent 实录二飞书权限矩阵 长连接事件订阅一次跑通v0.20.0 实测完整配置路线权限/事件订阅/发布三件套发布后贴链接三办公聊天软件接入 Hermes Agent 实录三钉钉 Stream 模式长连接零公网跑通个人开发者也能接v0.20.0 实测个人开发者路线 Stream 长连接发布后贴链接阅读建议第一次接触按一→二→三顺序读——企微篇最易上手飞书篇把配置机制讲透钉钉篇补个人开发者视角只关心某个平台直接读对应篇每篇自成完整闭环想了解原理企微篇的架构节讲得最全Dify 应用即 API、工具化认知、两层质量环境说明Hermes Agent v0.20.0开源 AI Agent 框架支持多聊天软件接入Dify 1.16.1开源 LLM 应用开发平台知识库问答云服务器腾讯云轻量Ubuntu 24.04Docker 部署 Dify三篇全部实测跑通企业微信、飞书、钉钉三平台可同时在线一个 Hermes 大脑、三个聊天软件入口会话按平台天然隔离互不干扰。本文由 AI 协作完成接入、排障、优化均为实测过程数据取自真实运行日志。有问题欢迎评论区交流。