半个多月前团队里提了一个听起来很简单的需求把带写作能力的 AI 助手直接拉进日常工作的 QQ 群、微信群和飞书群让它帮我们写公众号初稿、周报、文案还要能结合团队自己的知识库回答写作相关的问题。真正上手之后才发现这个需求需要同时处理平台接入、模型调度、上下文隔离、知识库召回和提示词工程远不是把模型换个壳子扔进群聊那么简单。整套链路我最终是用 Dify LangBot 这套组合跑通的模型以 GPT-6 Astra 的 API 服务为示例。在开始拆解之前先说明一点这篇文章里所有涉及 GPT-6 Astra 的配置你可以原样换成任何你实际有调用权限的模型服务只要它提供 OpenAI 兼容接口或者能被 Dify/LangBot 接入就行。核心思路是通用的我踩过的坑对各类模型方案也有参考价值。1. 项目背景与整体方案选型1.1 需求拆解群聊里的写作助手到底需要什么能力表面需求是把 AI 拉进群但拆开看会发现这里面有几个完全不同的子问题。第一是平台接入。QQ 群、微信群、飞书群三个平台的开放能力完全不同接入方式、回调机制、消息格式也不一样。你要的不是能发消息而是能够稳定接收群消息、知道是谁在什么时间说的、能主动回复、能正确处理 触发。如果每个平台都从零写一套监听程序前期工作量还好说后续维护才是噩梦。第二是写作能力。这不是一个聊天机器人它是一个写作助手。也就是说它要能根据用户给的粗略主题生成完整文章要能把一段口语描述改写成正式文案要能把群里的讨论总结成周报。这些任务需要分步骤执行需要风格控制需要输出格式约束。单纯靠一个带聊天上下文的 LLM 接口很难稳定做到。第三是知识库和团队风格。我们团队有历史公众号文章、宣传手册、产品文档还有一些内部写作规范。如果助手不懂这些写出来的东西会非常通用和团队风格完全脱节。所以还必须有 RAG检索增强生成能力。第四是运维和管理。团队里不可能每次都让工程师去改配置、重启服务。我需要的是一个可视化的流程编辑器让不懂代码的运营同学也能调整写作模板和知识库内容。同时群聊场景还涉及权限问题至少要能控制哪些群能用哪些人能用。把这些需求摆出来之后选型思路就清晰了一个负责大脑做工作流、知识库和模型调度一个负责五官做多平台消息收发、群权限和会话隔离。1.2 为什么是 Dify LangBot而不是其他组合选型阶段我评估过三套方案各有取舍最终选了 Dify LangBot。方案一只用 LangBot 直连模型 API。LangBot 确实支持配置各种模型提供商部署起来非常快改一下 provider.json 就能跑。但问题是LangBot 本质上还是一个消息转发框架它本身没有知识库管理体系没有可视化工作流也没有精细的日志审计。如果你想加一个先检索团队知识库、再生成文章的流程得自己在 LangBot 的外部请求钩子里写代码维护成本不低。方案二只用 Dify自己开发平台适配器。Dify 的工作流、知识库、模型管理、Prompt 编排都非常成熟但它不做群消息接入不会自己监听 QQ 群消息。你需要自己写监听服务把各平台消息 POST 给 Dify 应用 API再把返回结果发回群里。这意味着三个平台就要写三套适配代码而且消息回调地址、重试机制、图片文件处理都要自己兜底工作量比想象中高很多。方案三也是我最终采用的Dify 做大脑LangBot 做五官。LangBot 负责连接 QQ、微信、飞书把群聊消息统一封装成标准消息格式Dify 负责所有的业务逻辑——意图识别、知识库检索、工作流编排、模型调用。LangBot 收到消息后直接把消息内容转发给 Dify 的应用 API然后把 Dify 返回的结果发回群里。两个系统的分工非常清晰一个管通信一个管智能。我还对比过其他一些支持多平台接入的机器人框架各有特点但 LangBot 在三点上比较突出平台适配器齐全、接入方式灵活支持 WebSocket、Webhook、反向连接、管理面板能直接看到各平台状态而且它的配置结构不复杂适合团队协作时做版本管理。2. 环境准备Dify 与 LangBot 的本地部署2.1 部署前的硬性条件和网络规划先交代一下环境。我用的是一台 4 核 8G 内存的云服务器系统是 Ubuntu 22.04装了 Docker 20.10 和 Docker Compose v2。如果条件达不到8G 内存是跑 Dify 全家桶比较舒服的底线因为 Dify 同时会带起 PostgreSQL、Redis、Weaviate 三个基础设施服务加上 API 服务和 Worker 进程内存占用轻松超过 4G别用 2G 内存的机器硬扛后面构建知识库索引的时候极容易 OOM。另外需要提前规划网络。QQ 和微信的接入方式对公网要求不高如果是反向连接模式服务器只需要能主动外联。但飞书的回调模式要求你的服务端能被公网访问到建议准备一个域名或者至少在服务器安全组里放行对应端口并提前规划好回调地址别等部署完了再去折腾网络配置。2.2 Dify 部署步骤以 1.17.1 为例Dify 部署走 Docker Compose非常成熟。我实际操作时的命令路径如下。git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env打开 .env 后重点确认几个变量。EXPOSE_NGINX_PORTDify 对外服务端口默认 80如果机器上已经有其他 Nginx建议改成 8080 之类避免端口冲突。SECRET_KEY生产环境必须改成随机长字符串这个是用来做数据加密和 Cookie 签名的别用默认值。POSTGRES_PASSWORD、REDIS_PASSWORD如果你要长期使用也建议改掉。确认无误后执行docker compose up -d第一次启动会拉取一堆镜像耗时取决于网络大概 5 到 15 分钟。拉取完成后用docker compose ps查看状态确保api、worker、web、weaviate、db、redis、nginx这些关键容器都是 Up 状态。浏览器访问http://服务器IP:端口Dify 会引导你创建管理员账号。这里有个容易忽略的点初始化管理员是全局唯一的管理员后续团队其他账号都由这个管理员账号创建密码务必记牢。我部署的时候 Dify 正好是大版本迭代期Web 端界面和旧版相比改了不少。但核心逻辑没变左边是应用、知识库、工具、工作流右边是模型供应商和 API 访问设置。后来的 1.17.1 版本在工作流节点上做了不少优化比如节点复制粘贴、并行分支预览对做写作项目非常实用。2.3 LangBot 部署方式与基础配置LangBot 的部署方式也挺多Docker、源码运行、二进制包都有。为了和生产环境保持一致我选择了 Docker Compose 方式。先创建一个工作目录比如/data/langbot然后把 LangBot 的配置文件模板放进去。核心需要关心的两个配置是langbot.json和provider.json。langbot.json主要管平台接入定义每个平台渠道的 enabled/disabled 状态、触发方式是否必须 、消息前缀、群白名单等。provider.json主要管模型接入定义请求哪个模型服务、用什么 API 地址、用什么 Key。我用 Docker 方式启动 LangBot 后管理面板默认跑在 8000 端口登录面板能看到各个平台渠道的状态也能在线修改一些配置。需要提醒的是LangBot 的配置修改后通常需要重载进程才生效别改了发现没生效就以为是 bug先在面板里点一下重新加载配置。关于 LangBot 和 Dify 的部署顺序我建议先把 Dify 跑起来并配置好模型再去接 LangBot。因为 LangBot 的很多测试需要后端真正能返回结果Dify 就绪后再接 LangBot链路调起来会顺畅很多否则两头都是黑的排查问题容易抓瞎。3. 模型接入让 GPT-6 Astra 在两条链路上跑起来3.1 在 Dify 里配置模型供应商Dify 的模型接入在左侧菜单模型供应商里。GPT-6 Astra 如果提供的是 OpenAI 兼容接口在 Dify 里走OpenAI-API-compatible这类自定义模型配置最省事。需要准备三个信息Base API URL模型服务商给你的接口地址一般是https://xxx/api/v1这种形式。API Key你的密钥通常以sk-开头。模型名称服务商定义的模型 ID比如gpt-6-astra或者别的什么必须完全一致大小写也要对。配置完成后Dify 会有一个点击测试的按钮会实际发起一次模型调用验证连通性。这一步千万别跳过先在这里把连通性搞定再往下走。实测中很多机器人不回复的问题最后都追溯到模型压根没配通。如果你使用的是 GPT-6 Astra 直连并且走 Dify 的工作流那这一步配置完Dify 的模型下拉框里就能选中它了。我在实际项目里用的是类似于gpt-6-astra的一个模型 ID具体以你拿到的参数为准。3.2 在 LangBot 里配置模型直连还是走 DifyLangBot 的 provider.json 配置有两种思路这个选择会直接影响整个系统架构。第一种思路是 LangBot 直连 GPT-6 Astra 的 API配置简单请求路径短响应速度快。但问题是 LangBot 侧没有 Dify 的工作流和知识库所有智能逻辑都要靠 LangBot 的提示词和外部请求插件来实现对复杂写作任务支持不足。第二种思路是 LangBot 把请求转发给 Dify 的应用 API这也是我采用的方式。实现方法如下。在 Dify 中创建一个应用比如叫群聊写作助手编排好工作流和知识库后进入访问 API页面复制 API Key形如app-xxx和 API 地址形如http://dify-host/v1。然后在 LangBot 的 provider.json 里配置一个指向 Dify API 的服务{ type: openai_compatible, base_url: http://dify-host/v1, api_key: app-xxxxx, model: gpt-6-astra }这里有一个关键细节当你把 LangBot 指向 Dify API 时LangBot 本身只是透明转发真正调用哪个模型、走哪些工作流节点完全由 Dify 应用决定。所以你在 LangBot 里填的model字段其实不那么重要重要的是 API Key 对应的 Dify 应用是谁。这也意味着你可以在 Dify 端灵活更换底层模型LangBot 这边几乎不用改配置。两种链路我整理了对比如下。链路模式优点缺点适用场景LangBot 直连模型 API部署最轻延迟低少一层转发无法使用工作流、知识库、多分支节点纯闲聊、简单问答LangBot 请求 Dify 应用 API工作流、RAG、变量、审计全都能用修改即时生效多一层网络开销启动链路依赖 Dify 在线写作助手、复杂业务机器人我的建议是只要你的目标不是随手聊天级别的需求就尽量走 Dify。因为写作这个场景太依赖流程控制了这篇稿子的风格、结构、知识库引用逻辑放在 Dify 工作流里调整比塞在 LangBot 的提示词里清晰太多。3.3 用多个 API Key 实现多群路由这里分享一个我后来发现的技巧。Dify 允许同一个应用生成多个 API KeyLangBot 可以给不同群配置不同的 provider 或渠道。也就是说你可以在 Dify 里创建两个应用一个负责自媒体写作一个负责周报总结分别生成两个 API Key然后在 LangBot 里给 QQ 群路由到自媒体写作应用给飞书群路由到周报总结应用。这样一来一个 Dify 后端就拖动了多个群机器人业务而且各群之间互不干扰。后续如果某个群的工作流要单独调整也不影响其他群。听起来只是配置层面的小技巧实际用起来非常顺手。4. 群聊接入实操把三端全都接进来4.1 QQ 群接入利用 OneBot 协议与 NapCatQQ 群机器人接入社区里最成熟的方案是走 OneBot 协议。LangBot 自带 OneBot 适配器只需要一个实现了 OneBot 协议的服务端和 QQ 建立连接即可。我使用的是 NapCat一个轻量级的 OneBot 实现。操作路径大致如下。第一下载并运行 NapCat。不同版本安装方式略有差异但整体逻辑是运行后它会展示一个二维码用 QQ 扫码完成登录登录成功后本地会开放一个 WebSocket 端口。第二在 LangBot 管理面板中新增渠道类型选择 OneBot把 WebSocket 地址填成ws://127.0.0.1:端口。如果你的 LangBot 和 NapCat 不在同一台机器上就需要填完整的外网或内网地址注意端口放行。第三在 QQ 群里把机器人拉进来并在 LangBot 的群配置里启用该群。默认触发方式通常设置为必须 机器人这样群里闲聊时机器人不会乱入。这里必须说一句风险提示使用个人 QQ 账号做自动化机器人本质上是在利用非官方接口账号存在被限制登录的风险。我建议只在测试小号上做验证不要拿主号直接挂生产。如果团队预算允许可以考虑 QQ 开放平台的官方机器人接口合规性更好但接入流程会复杂不少。4.2 微信接入优先选择企业微信个人微信有风险微信是三个平台里最复杂、最需要注意合规的。我明确不建议用非官方的个人微信 hook 协议来生产环境封号风险和稳定性风险都很高。团队如果一定要接微信群我更推荐走企业微信的官方能力。在 IWeCom企业微信侧有两个常用姿势企业微信群机器人Webhook在群里添加一个自定义机器人拿到 webhook 地址。优点是配置极快几十秒就能推送消息到群。缺点是只能主动推送不能直接接收群里的 消息。企业微信自建应用创建企业微信应用配置可信 IP 和接收消息回调 URL使用官方 API 接收消息与回复。这种方式双向都能通支持 触发LangBot 也支持对应渠道是比较稳的正路。实操时需要注意企业微信回调要求你的服务端 IP 在应用的可信 IP 列表里而且回调地址必须公网可访问。我在最开始接入时卡了很久最后发现企业微信后台要求填 URL 后先通过配置验证LangBot 侧需要把消息解密和签名验证配置好两边配齐才能通。如果团队用的就是个人微信群且没有企业微信环境那这个需求在合规层面其实是受限的。这种情况下我建议换一个思路把机器人做成一个网页版小助手群里投一个链接入口用户点开之后跳转到 Dify 的 WebApp 页面去提问效果虽然不如直接在群里 但至少是安全可控的。4.3 飞书接入开发体验最好的一个飞书的开放平台在三者里做得很规范全程走官方开放平台 API 即可没有那么多灰色地带的问题。步骤大概如下。第一步在飞书开放平台创建企业自建应用启用机器人能力。第二步在应用的事件订阅里添加事件选择im.message.receive_v1接收消息并配置请求地址格式类似https://你的域名/lark/callback。飞书会向这个地址发送验证请求需要服务端正确响应一个加密 challenge。第三步添加权限重点是im:message、im:message:send_as_bot这类消息读写权限还要发布应用版本并确保企业管理员审核通过。第四步拿到应用的 App ID 和 App Secret填到 LangBot 的飞书渠道配置里。第五步在群里添加这个机器人为成员然后在群里 它测试。飞书的回调对开发者很友好因为它所有消息都带open_id和chat_id上下文隔离很好做。LangBot 对飞书的适配也比较成熟我接入过程里几乎没有踩坑唯一要提醒的是回调地址必须是 HTTPS或者飞书开发者后台允许配置的 HTTP 测试地址新版本有收紧趋势所以最好在服务器上挂一个 Nginx 反代并配置证书。4.4 统一管理用一个面板管三个平台三个平台都接好之后LangBot 的价值就体现出来了。以前三个平台三套系统现在在一个管理面板里能看到所有平台渠道的状态QQ 在线、飞书在线、企业微信在线哪个断了日志里直接能看出来。LangBot 还支持对每个平台分别设置是否启用该渠道群白名单 / 黑名单触发方式是否必须 单条消息最大长度上下文会话隔离策略我在实际配置中把 QQ 群设成了必须 把飞书评审群设成了随便说话就绪这样两个群的使用体验完全不同但底层共用同一个 Dify 应用非常灵活。5. 让写作助手真正好用工作流、知识库和上下文管理5.1 写作工作流设计把写一篇文章拆成节点平台接入只是骨架真正决定体验好坏的是 Dify 里的工作流设计。我给自己定了一个原则能在工作流里编排的绝不丢给模型自由发挥。以一个写公众号推文初稿的流为例我设计的节点顺序如下。开始节点接收用户输入。意图识别节点判断用户要的是写新文章改写现有内容还是总结材料。这里用一个 LLM 节点输入限定分类输出结构化 JSON。参数提取节点把用户输入中的主题、目标读者、字数、语气等关键信息抽取出来。知识库检索节点根据主题到团队知识库召回 3 到 5 条相关内容。文章生成节点把用户原始输入、参数提取结果、知识库召回内容合并成 Prompt调用 GPT-6 Astra 生成初稿。结束节点返回最终文本。这个流程在 Dify 里搭建很快而且最爽的是每个节点都能单独测试和调参。比如知识库召回效果不好可以单独调检索策略不需要动其他节点。有一次运营同事想改文章风格只改了文章生成节点里的提示词全流程不用动这个体验很打动人。5.2 知识库与 RAG让团队风格真正长进输出里群聊写作助手如果只有模型能力写出来的东西会非常通用。我们团队有历史文章、产品手册、品牌语料这些必须沉淀到 Dify 知识库里。Dify 知识库支持导入文本、PDF、Markdown、网页等格式。我建议先把团队历史公众号文章分行分段导入配置分段长度在 300 到 500 字符重叠 50 字符左右。分段太短检索时语义不完整太长检索命中后塞进 Prompt 的内容太多浪费 token 而且容易偏题。索引方式建议选择高质量模式也就是走向量化索引。Dify 会自动调用配置好的 Embedding 模型来生成向量。注意Embedding 模型也需要在模型供应商里单独配置别以为配置了 GPT-6 Astra 就能自动出向量这两个是独立的能力。RAG 检索策略上我建议在群聊这种短消息场景里限制召回数量。Dify 的知识库检索节点可以设置召回条数我一般设 3 条上限绝不超过 5 条。因为在群聊里用户没有耐心看大段引用你只需要把关键知识揉进生成结果就好召回太多反而容易导致模型回答跑偏.经验是运营团队经常临时想改风格我鼓励他们把品牌手册、Slogan 清单、历史爆款标题不断更新到知识库而不是反复改提示词。知识库负责事实和风格素材提示词负责如何组织表达两者职责切分开后期的维护压力小很多。5.3 上下文管理避免群聊消息相互污染在群聊场景里上下文管理是最容易被忽视也最影响体验的问题。想象一个场景运营群里上午聊了一堆双十一活动策略下午有人 机器人问帮我写个竞品分析报告开头机器人如果直接把上午的聊天记录当上下文生成结果里大概率充斥着毫无关联的活动信息。LangBot 提供了会话隔离机制我建议根据你的实际场景按群用户双维度隔离。简单说每个用户的每次提问只带上下文的最近 N 轮记录而不是整个群的全部消息。N 我一般设置为 6 到 10 轮既能保证多轮对话的连贯性又不会引入过多噪声。如果你用的是 LangBot 走 Dify API 的模式上下文的传递方式取决于你在 Dify 工作流里怎么设计。我们平时建议把 LangBot 的消息历史组装成 messages 数组传给 DifyDify 的 LLM 节点会自动识别。要注意的是Dify 应用有两种对话模式聊天助手和工作流。如果你需要比较强的多轮记忆可以在 Dify 里使用对话开局变量或者外部会话 ID 功能按群会话维度持久化记忆。系统提示词也同样重要。我在 Dify 的 LLM 节点里写了一个固定的群聊写作助手角色设定内容包括你是团队的写作助手擅长公众号文章、周报、文案改写与总结回答精炼、有理有据输出格式清晰如果信息不足直接说明不要编造数据需要引用知识库内容时自然融入表达不要逐条罗列据知识库显示写清这些限定之后模型在群聊里的表现稳定很多不会因为某条嘈杂消息就突然切换成闲聊模式。5.4 三个真实场景的演示场景一QQ 运营群。运营同学发了开发布会倒计时宣传文案要求有紧迫感、突出新功能群里的机器人 触发后先通过意图识别进入写文案分支知识库里召回了以往新品发布的文案风格最终输出了三条 30 字以内、带不同情绪的备选文案。整个过程从 到回复不到 15 秒。场景二企业微信工作群。产品技术群里就一个方案讨论了很多轮最后有人 机器人帮我把刚才讨论的结论总结成周报给我的领导。这里靠 LangBot 回传的多轮上下文Dify 工作流把大段讨论压缩成了包含结论、待办事项、风险点的结构化周报并把待办事项输出成清单格式直接复制就能用。场景三飞书评审群。有人贴了一段很潦草的需求描述机器人改写成正式的 PRD 需求描述。因为没有对应知识库内容工作流走了改写分支模型输出了规范化的需求背景、目标、范围、验收标准四段式内容。整个过程一气呵成没有出现刷新页面、重试调用等尴尬情况。这三个场景其实同一套后端只是入参和分支不同。这也说明把流程拆成节点而不是堆一个巨大的 Prompt是群聊写作助手能够灵活应变的主要原因。6. 常见问题与排查技巧实录这个项目从搭建到稳定使用我记录了不少问题。列一个速查表给后来人省点时间。现象可能原因排查思路与处理方式Dify 里模型测试失败模型名称或者 Base URL 填错Key 无效模型供应商限流先用 curl 直连模型 API 测试排除 Dify 配置问题再回 Dify 里核对三个参数LangBot 收到消息但无回复LangBot 的 provider 指向 Dify 失败Dify 应用未发布看 LangBot 日志确认请求是否到达 DifyDify 应用必须发布后才能通过 API 访问QQ 群不收消息NapCat 未正常登录WebSocket 连接断开群未启用先确认 NapCat 的登录状态和端口连通性再到 LangBot 面板查看该渠道是否在线飞书回调验证失败回调地址无法公网访问加密配置错误应用未被审核通过先用飞书开放平台的调试工具发送验证请求看你的接口能否正确响应 challenge企业微信群只能推送不能接收消息用的是普通群机器人 Webhook而不是自建应用需要升级为企业微信自建应用模式配置消息回调 URL 并校验可信 IP生成结果和知识库内容无关检索策略不佳知识库分段过短或过长召回条数太少在 Dify 知识库节点单独测试检索结果调整分段大小与召回数量必要时换更好的 Embedding 模型群聊上下文串味多个用户共享同一个会话 ID上下文窗口过大在 LangBot 中开启按用户隔离的会话策略限制上下文条数多群之间相互干扰多个群共用一个 Dify 应用且共用会话维度使用多个 API Key 或为不同群分配不同的 Dify 应用按会话 ID 隔离消息响应太慢工作流分支太多且串联执行模型推理时间长知识库检索慢用 Dify 的并行执行节点对非关键步骤可以缩短提示词给模型换更快的推理配置Dify 服务器内存不足大量并发检索与推理导致 Worker 耗尽内存监控 Docker 内存必要时给 Worker 单独加大内存限制也可以考虑拆分出独立的向量数据库实例再补充一个排查问题的通用技巧。当你不知道问题出在 LangBot 还是 Dify 时先在 Dify 的调试预览里手动模拟一条群聊消息看能不能得到正确结果。如果能说明 Dify 侧没问题问题大概率出在 LangBot 的平台接入或消息格式转换上如果不能那就回 Dify 工作流里细查节点。这种由内向外的排查顺序能帮我快速圈定故障范围比到处看日志高效得多。关于日志Dify 和 LangBot 都建议打开详细日志。Dify 的 API 日志里能看到每次请求的入参和出参LangBot 的日志里能看到各平台消息的接收和发送状态。两边的日志时间戳对一下基本能定位到消息是在哪一环丢的。还有一个非常容易踩的坑LangBot 默认配置里触发方式可能限制了必须包含特定的前缀词比如AI或者机器人。如果你在群里 机器人它没反应先别急着怀疑模型看看 LangBot 的触发规则确认是不是漏了前缀要求。我一开始就是因为默认前缀没配好导致它在群里装死了半个小时。最后说一点我个人在实际操作中的体会。这套 Dify LangBot 组合最大的价值不在于某个单一功能有多强而在于它把智能层和通信层彻底解耦了。Dify 让我不用写代码就能调整写作流程和知识库LangBot 让我不用关心三个平台的协议差异。后续如果想让机器人每天自动生成行业晨报推到飞书群只需要在 Dify 里加一个定时触发的工作流节点然后把结果推送到群里如果想增加钉钉支持也只需要在 LangBot 里加一个渠道。这种扩展性才是当初选这套方案时最看重的东西。如果让我给后来者一个建议先跑通一条最小链路再逐步加复杂度。先把 QQ 群的 触发跑通生成一条普通回复再接入知识库让回复具备团队风格最后构建完整工作流和引入飞书、企业微信。不要试图第一天就把所有平台和工作流全部配好饭要一口一口吃链路要一层一层搭。踩过几次坑之后回过头看这套系统已经成了我们团队日常运营里离不开的一个在线同事了。