用GPT-6 Astra+Dify+LangBot搭建飞书GitHub更新简报机器人

刚开始做这个项目的时候我的状态是每天至少刷十遍 GitHub生怕漏掉关注仓库的关键 commit 和 release。后来实在刷不动了干脆把这件事交给了机器人在飞书群里发一句话它就把指定仓库的更新动态、变更要点整理成一份简报发回来。底层用到的组合是 GPT-6 Astra Dify LangBot整体跑通之后我最大的感受是这套工作流的价值远不止“监控仓库更新”它其实是一个可以反复复用的“对话式数据服务”范式——你在飞书里问一句背后自动完成 API 请求、数据清洗、模型总结和格式化推送。这篇文章就把我的完整搭建过程和踩坑经历写出来从方案选型到运行维护尽量说得细一点希望对想自己做飞书机器人的朋友有参考价值。1. 需求拆解与整体方案设计1.1 核心需求在飞书里问一句就拿到 GitHub 更新简报先把自己当时的真实场景描述一下。我主要在 GitHub 上维护几个开源项目同时也在跟踪一些活跃的上游仓库比如某个流行框架的官方仓库、某个工具链的 release 页面。过去我每天要手动做三件事看 watch 到的通知邮件、去看 commit 历史、去 release 页面看新版本说明。时间一长就发现这个流程有几个痛处。第一GitHub 的通知邮件太多了star、issue 评论、pr 提醒全混在一起真正重要的 commit 和 release 很容易被淹没第二很多仓库的 commit message 写得比较随意光看标题根本不知道到底改了什么第三团队里不止我一个人有这种需求大家都在各自重复刷页面。所以我想做的这个项目核心需求其实一句话就能说清楚用户用自然语言在飞书里问“最近三天 xxx 仓库有什么更新”机器人返回一份有摘要、有分类、可读性强的更新简报。要实现这个需求必须拆成四个动作理解用户的提问意图、确定要拉取哪个仓库和时间范围、访问 GitHub API 拿到原始数据、把一堆 commit 和 release 内容总结成一段人话。这个需求看起来不复杂但真正做的时候难点全在细节上。GitHub API 返回的数据是 JSON 结构字段很多直接丢给大模型会浪费 token而且效果不一定好commit 信息量差异很大有的仓库一天几十条提交有的仓库一周也没几个 release飞书机器人回复还有交互时长的限制如果数据拉取和模型生成太慢飞书会出现超时重试。这些都是在设计阶段就要想清楚的。1.2 为什么选 GPT-6 Astra Dify LangBot 这套组合“用什么工具实现”这件事我前前后后对比过好几条路线。最简单的方案是自己写一个 Python 脚本用 flask 起一个 webhook 服务收到飞书回调之后自己调 GitHub API再用 OpenAI SDK 调用 GPT-6 Astra 做总结最后用飞书的自定义机器人 webhook 发消息。这套方案的好处是代码全部在自己手里灵活度最高坏处也很明显飞书的加密校验、事件重试、消息卡片格式处理、多轮对话上下文管理这些都要自己写。而且一旦以后想接入钉钉、Slack 或者微信公众号又得重新改一遍。对比下来我选了”LangBot 做消息接入Dify 做应用逻辑GPT-6 Astra 做内容生成“的分层方案。LangBot 本身是开源的消息机器人框架它内置了飞书、企业微信、钉钉、微信公众号等多个渠道的适配器飞书那边的长连接和事件订阅只要配置好就能通省掉了我维护长连接和回调服务的成本。Dify 则是一个低代码的 LLM 应用平台我可以在里面用可视化方式编排工作流把 GitHub API 请求、数据提取、模型调用这些节点串起来调试也更直观。GPT-6 Astra 在这个项目里的定位是内容生成引擎。我选择它的原因有两个。第一它在长上下文理解和指令遵循上表现不错面对一堆杂乱的 commit 信息它能按照我给的模板把内容归类和提炼生成的中文简报比较自然第二通过 Dify 接入之后我可以在不同工作流里复用同一套模型配置以后想换更强的模型或者切换供应商只需要改一个地方。当然如果你手上没有 GPT-6 Astra 的 API也可以换成你实际可用的任意大模型整个工作流的骨架并不会变。这层拆法还有一个隐性优点可观测性好。Dify 的日志系统能看到每个节点的输入输出GitHub API 返回了什么、模型最终怎么总结的、哪个环节报错了都一目了然。LangBot 那边也有独立日志可以对比消息链路是否完整。对于这种跨系统集成项目可观测性比代码简洁更重要。1.3 整体数据流转设计整个工作流的数据走向是这样的用户在飞书群里或单聊中发出一条消息例如“看下 xx 仓库这三天的更新”LangBot 接收消息之后会按照预设的工具调用规则把这条消息转给 Dify 的应用 API。Dify 应用里的工作流开始运行第一个节点解析用户意图提取出仓库名和时间范围然后调用 HTTP 请求节点访问 GitHub API。GitHub API 返回的 JSON 数据会经过一个代码节点做字段筛选和格式整理把 commit 标题、作者、提交时间、release 版本号等关键字段提取出来。整理后的结构化数据会拼到提示词里发送给 GPT-6 Astra。模型生成总结文本之后再经过一个输出节点把结果返回给 LangBot。LangBot 拿到文本后通过飞书开放平台的消息接口推送给用户。这里有一个细节要注意GitHub API 这个环节既可以是工作流主动触发的也可以由 Chatflow 的 Agent 节点动态调用。我采用的方案是在 Dify 里建立一个比较轻量的工作流通过 HTTP 请求节点直接访问 GitHub API这样做的好处是流程透明、依赖简单。后面我会详细说明每一步的具体配置。2. 环境准备Dify、LangBot 与飞书应用搭建2.1 Dify 社区版部署及初始配置Dify 我建议直接用社区版功能对个人和中小团队已经完全够用。部署方式用的是 Docker Compose参考官方文档做即可。这里分享几个我实际踩过坑之后认为值得注意的点。第一个是镜像拉取问题。如果你所在的服务器网络访问 Docker Hub 不稳定docker compose up -d很容易在langgenius/dify-api这个镜像上卡很久。我的做法是配置好 Docker daemon 的镜像加速源然后重新加载守护进程再执行拉取。如果还是失败就先手动docker pull一次需要的基础镜像成功之后再执行 compose 启动。启动完成之后访问服务器的 HTTP 服务端口默认是 80 或者 443这个取决于你的 compose 文件首次进入需要设置管理员账号。第二个是版本选择。如果你只需要稳定直接用官方 docker-compose 最新 tag 即可如果想先在测试环境里体验新版本再用 develop tag。生产环境我倾向于固定一个已知稳定的版本避免哪天docker compose pull把组件升级到不兼容版本导致工作流报错。第三个是模型供应商配置。Dify 部署好之后第一件事是进入“设置 - 模型供应商”把 GPT-6 Astra 的 API Base 和 API Key 填进去。需要注意Dify 对模型供应商的配置路径是按供应商类型区分的如果你用的是 OpenAI 兼容接口就在 OpenAI 类型的供应商里填自定义 Base URLDify 1.17.1 之后对自定义模型供应商的支持更完善可以直接配置模型名称、上下文长度等参数。这里最容易犯的错是只填了 API Key没填模型类型和模型名称导致后面工作流里选模型时找不到选项。2.2 LangBot 部署与飞书接入LangBot 这个框架安装起来不算复杂官方推荐用 pip 安装或者 Docker 部署。我自己用的是 pip 方式因为它方便预览配置文件和直接看日志。安装好之后需要先修改langbot.json配置文件把飞书相关的配置项填进去。在飞书开放平台那边你需要先创建一个企业自建应用。创建完成之后要开启“机器人”能力拿到 App ID 和 App Secret。LangBot 连接飞书有两种方式一种是使用 WebSocket 长连接模式这种方式不需要暴露公网回调地址对本地开发和内网服务器比较友好另一种是使用 Webhook 事件订阅模式需要在飞书开放平台上配置回调地址。强烈建议先用 WebSocket 模式跑通整条链路因为不需要折腾反向代理和 HTTPS 证书等确实需要多实例部署或者更稳定的生产方案时再迁移到 Webhook 模式也不迟。配置短连接模式时LangBot 里要填三个信息App ID、App Secret以及飞书应用的加密校验 keyEncrypt Key可以不填。把这三项填到langbot.json的飞书渠道配置里重启进程如果日志显示连接成功说明飞书和 LangBot 已经打通。这时在飞书里直接给应用机器人发一条普通消息LangBot 会有一个默认的回复这就说明消息能进来。2.3 为机器人申请必要的权限与事件这一步最容易漏。飞书开放平台的应用默认权限非常少机器人能收到的消息类型也有限。如果你直接照搬网上的配置很容易出现“机器人收不到消息”的问题。需要重点配置的有两块。第一块是权限必须在“权限管理”页面申请im:message相关权限至少要包括读取用户发给机器人的单聊消息、读取群消息、发送消息等。权限申请之后还要在“版本管理与发布”里创建一个版本并发布权限才会真正生效。第二块是事件订阅在“事件与回调”页面添加im.message.receive_v1事件。如果使用的是 WebSocket 长连接方式飞书事件订阅那里选择“使用长连接接收事件”不需要填写请求地址如果是 Webhook 方式就要把 HTTPS 回调地址填进去并且启用加密模式。我开发时犯过的错就是只申请了发消息权限没申请接收消息权限结果机器人在群里像哑巴一样消息根本进不来 LangBot。另外提醒一句飞书的权限和事件配置修改后通常要等一两分钟才生效测试的时候别太心急。3. Dify 工作流从接收提问到 GitHub 数据获取3.1 创建“GitHub 更新简报”工作流登录 Dify 后台之后在“工作流”页面创建一个空白工作流。我给它取名为“GitHub 更新简报”。工作流的输入变量我设计成两个一个是query表示用户发来的自然语言提问一个是conversation_history用来保存飞书对话历史便于模型在上下文中理解多轮对话中的指代关系。如果你只做单轮问答第二个变量可以不要但做多轮场景时这个变量能让用户直接说“那再看看 Issues”机器人也能知道“那”指的是上一个仓库。工作流的开始节点里我通过 LangBot 调用 Dify API 时传入query和可选的conversation_history。接着是一个 LLM 节点用来做“意图识别和参数抽取”。为什么要先做一个 LLM 节点而不是直接写死 JSON因为用户可能说“看看 langgenius/dify 这两天有没有新版本”也可能说“查一下我关注的那个 xxxx 前端项目最近的提交”仓库名、时间范围、关注类型都在变必须用模型抽取出结构化参数。为了让抽取结果更可靠我在提示词里明确要求模型只输出 JSON格式是“repository, since, event_type”三个字段。这里 event_type 可以是 commit、release、issue 或者其他。抽取出的 JSON 结果会传给一个代码节点做解析因为后续 HTTP 请求节点需要直接引用repository这个变量。代码节点里写几行 Python把 JSON 字符串转成字典再return出去。Dify 的变量引用模式是{{#node_id.output#}}你在节点配置面板里能看到所有上游节点的输出字段直接点选就行。3.2 HTTP 请求节点调用 GitHub API 获取更新工作流的下一步是 HTTP 请求节点。这是整个链路中比较关键的一步也是很多第一次做的人容易配置错的地方。GitHub REST API 的 endpoint 是https://api.github.com/repos/{owner}/{repo}/commits和https://api.github.com/repos/{owner}/{repo}/releases。我通常会根据用户在提问中关注的类型决定只调其中一个或者在两个都调之后再合并。先说 commit 接口。GET /repos/{owner}/{repo}/commits支持since和until参数格式是 ISO 8601例如2025-01-01T00:00:00Z。since参数可以单独使用意思就是“返回这个时间点之后的提交”。在 Dify 的 HTTP 请求节点里我把请求方法设为 GETURL 里填https://api.github.com/repos/{{#node_id.output#: repository}}/commitsQuery String 里填一个 key 为sincevalue 为{{#node_id.output#: since}}的变量。再讲 release 接口。GET /repos/{owner}/{repo}/releases返回最近发布的版本列表默认一页 30 条。它不像 commit 接口那样支持since参数所以我在 HTTP 请求节点之后会加一个代码节点根据发布时间的字段对结果做过滤只保留用户要求时间范围内的版本。关于认证问题公开仓库的接口不认证也能调但有很明确的速率限制比如未认证的请求 IP 限制是 60 次每小时很容易触发rate limit exceeded。所以务必加上认证头在 HTTP 请求节点的 Header 里设置Authorization值为Bearer {your_github_token}同时加上Accept: application/vnd.githubjson和X-GitHub-Api-Version: 2022-11-28。认证后速率限制会提高到 5000 次每小时短期高强度测试也不用担心。3.3 数据清洗把 JSON 变成模型爱看的文本GitHub API 返回的 commit 对象结构比较复杂直接全部传给大模型有两个问题。第一是 token 消耗大一个 commit 对象里包含 files、url、comments_url 等很多字段真正对总结有用的就是 commit.message、commit.author.name、commit.author.date 和 html_url。第二是噪音多很多 commit 是“Merge branch”“Update dependency”“chore: release”全塞进上下文会影响模型对重点变更的识别。所以我在 HTTP 请求节点之后加了一个 Python 代码节点。逻辑很简单遍历 JSON 列表取出需要的字段拼接成三行以内的文本。比如每条 commit 最终渲染成一行- [2025-01-12] 张三: feat: add user profile page (https://github.com/xxx/yyy/commit/abc123)同样release 信息渲染成- [v1.4.2] 2025-01-12: 新增强大的日志检索功能, 修复若干稳定性问题 (https://github.com/xxx/yyy/releases/tag/v1.4.2)做完这个清洗步骤之后数据量已经从数千 token 降到了几百 token模型生成的速度和准确率都明显提升。这一步的做法其实很通用不管上游接的是 GitHub API、Jira API 还是数据库查询都应该先做数据投影和汇总再做模型生成。4. 接入 GPT-6 Astra让模型输出结构化简报4.1 在 Dify 中配置 GPT-6 Astra 模型供应商模型接入这块刚说了一点这里再展开。Dify 的模型供应商页面里如果 GPT-6 Astra 是以 OpenAI 兼容接口形式提供的那么就在 OpenAI 供应商类型下添加一个自定义模型。需要填写的核心参数有模型名称、模型上下文长度、最大 token 上限以及 API 的 Base URL。如果填对了Dify 会要求先输入 API Key 做一次连通性测试。测试通过之后这个模型就会出现在所有 LLM 节点可选模型的下拉列表里。有个配置细节容易被忽略Temperature 参数。对于信息抽取场景我会把 Temperature 调低到 0.2 左右让模型尽量忠实于输入内容减少自由发挥对于最终的简报生成会稍微调到 0.4保留一点表达的灵活性。既然 Dify 允许你为每次节点调用单独设置参数那就不要整个应用统一一个参数分场景设置效果好很多。4.2 设计高质量的总结提示词模型输出简报的质量百分之八十取决于提示词设计。我一开始的提示词写的是“请总结以下 GitHub 更新内容”结果模型输出五花八门。有的只报 commit 数量有的一股脑列出所有原始信息完全没有摘要和分类。后来我把提示词改成了模板化结构效果马上不一样了。我的做法是在 LLM 节点里用系统消息加用户消息的组合。系统消息里写明角色和职责你是一个专业的 GitHub 更新简报生成助手。你的任务是根据给定的仓库更新数据生成一份简洁准确的简报。简报面向有经验的开发者要求信息密度高、分类明确、去除无意义噪音。只使用输入数据提供的信息不要编造任何内容。用户消息则包含三部分用户原始提问、仓库更新时间范围、清洗后的结构化数据。同时示例了输出格式。我直接在提示词里写死了输出模板【仓库】xxx 【时间范围】xxx 【最近提交】 - commit 标题一句话概括变更目的 【Release/版本更新】 - 版本号、发布时间、核心变化 【值得注意】 - 需要人工关注的重大变更、破坏性更新或迁移指南用这个模板之后模型输出的稳定度提升很快。原因在于给模型一个明确的结构框架它就不太会跑偏给模型节制的输入数据它就能把注意力放在真正重要的内容上。4.3 格式化输出与飞书卡片适配GPT-6 Astra 生成的报告默认是纯文本含 Markdown 标记。LangBot 把它发给飞书之后飞书客户端对 Markdown 的支持是有限制的不是所有 Markdown 语法都能渲染。尤其是有时模型输出会带表格或很复杂的列表飞书消息里展示效果很糟糕。我的处理方法是在 Dify 工作流的最后加一个代码节点把模型输出里的表格语法转换成飞书消息更友好的纯文本格式。具体包括把##标题改成全角括号或方括号包裹的小标题把-项目符号统一成中划线加空格把**加粗**去掉或者改成普通文本。如果你希望消息展示更漂亮也可以让 LangBot 发送飞书富文本卡片但那需要在 LangBot 的响应里额外定义消息卡片结构我目前还是以纯文本为主够用且稳定。还有一个控制逻辑值得说如果清洗后的数据内容为空也就是“这段时间仓库没有任何更新”那就不必调用模型直接在代码节点里返回“该仓库在指定时间范围内没有检测到新的 commit 或 release”。这个分支设计可以节省大量 token也避免模型在没有数据时胡编乱造。5. LangBot 与 Dify 的联动飞书消息闭环5.1 LangBot 工具调用与 Dify API 对接LangBot 接入 Dify 主要有两种方式。第一种是内置的 Dify 工具直接在 LangBot 的工具配置里填 Dify API Base 和 API Key然后在机器人设置里指定默认使用这个工具。第二种是把 Dify 工作流封装成一个自定义工具在 LangBot 的工具列表里新增一个 OpenAPI 工具指向 Dify 的 Chatflow API endpoint。我使用的是第二种方式因为它更灵活。Dify 针对已发布的工作流应用会提供一个类似https://your-dify-server/v1/chat-messages的 API endpoint。调用时在 Header 里带Authorization: Bearer {dify_api_key}请求体里传inputs对应工作流的输入变量、query用户查询内容、user和response_mode。response_mode如果设为blockingDify 会等整个工作流跑完再一次性返回结果适合当前这种“问一句等一下拿报告”的场景如果设为streaming就可以实现打字机效果但 LangBot 对接流式响应要额外处理我建议先做 blocking。把 Dify 封装成自定义工具之后还需要配置 LangBot 的工具触发规则。LangBot 本身自带 Agent 能力它会基于大模型判断用户消息是否应该调用某个工具。我在 LangBot 的提示词里加入了工具描述“当用户询问 GitHub 仓库更新、commit、release、版本动态等问题时必须调用 github_update_brief 工具。”这样模型在多数情况下会自动选择正确的工具。5.2 端到端联调问一句拿到简报配置到这里就可以做一次完整的端到端测试了。我在飞书里给机器人发消息看看 langgenius/dify 这两天有没有新版本。预期结果是机器人返回一份简报包含最近两天的提交和发版信息。实际跑的时候会有几种可能的情况。第一种情况是 LangBot 没有调用 Dify 工具而是自己用内置语言模型硬答了。原因通常是 LangBot 的模型配置里没开“函数调用”能力或者工具描述信息不明确。解决方法是在 LangBot 的后台配置里明确启用工具调用并检查其调用的模型是否支持 function call 或 tool use 格式。第二种情况是 Dify 工作流执行了但返回结果为空这通常是因为since时间参数格式错误或者 GitHub API 返回的 422 错误。解决办法是打开 Dify 运行日志查看 HTTP 请求节点的输出确认请求 URL 和参数拼接是否正确。第三种情况是消息链路中断Dify 正常返回了但飞书没收到消息。这时候要去 LangBot 的日志里看是否有“send message success”之类的记录同时去飞书开放平台的事件订阅记录里看是否有发送失败的日志。飞书这边如果频繁触发重试多半是响应超时可以通过缩短 Dify 工作流耗时或者把response_mode改为 streaming 来解决。5.3 定时推送与手动提问的取舍这个项目做到后面会出现一个新的需求除了“问一句拿简报”用户还想每天早上九点自动收到一份“重点关注仓库”的汇总简报。实现起来有两种方式。第一种是在 LangBot 里加定时任务在指定时间调用 Dify 工作流 API然后把结果推送到指定的飞书群。第二种是在 Dify 外部写一个 cron 脚本直接调工作流 API。我目前用的是第二种方式。原因很简单保持 Dify 工作流本身无状态外部脚本只管定时触发和群机器人推送。脚本我用的是 Python requests在服务器上写了一个 systemd timer每天 09:30 执行。脚本里预置了几个仓库名列表依次调用同一个 Dify 工作流 API把模型生成的简报通过飞书群机器人的 webhook 发到群里。这里要注意飞书群机器人 webhook 和自定义应用机器人消息 API 是两套完全不同的发送通道前者简单粗暴、不需要申请复杂权限适合内部告警和定时推送后者适合交互式对话。定时任务还有一个隐含问题GitHub API 限流。如果你一天要查几十个仓库建议只查 commit 和 release 两个核心接口并且加上自己的 token。如果仓库很多可以考虑用 GitHub 的 GraphQL API 做批量化查询一次请求拿多个仓库的数据效率会更高但配置复杂度也上去了。6. 常见问题与排查实录6.1 GitHub API 限流与认证失效GitHub API 的限流是第一个会遇到的问题。没加 token 之前本地测试还好一旦部署到服务器上服务器公网 IP 的所有未认证请求共享同一个 60 次每小时的配额一个工作流只要跑几个仓库就会触发限流。报错信息一般是403或者rate limit exceeded。解决方式很直接在 GitHub 账号下创建一个 Personal Access Token关键词是“classic”或者“fine-grained”类型都可以。Fine-grained token 可以限制只访问 public repositories安全性更好。在 Dify 的 HTTP 请求节点 Header 里配好Authorization: Bearer your_token之后限流配额会提升到 5000 次每小时日常使用足够了。还有一个容易踩的坑是 token 过期。GitHub 的 fine-grained token 有默认过期时间设置时尽量选 90 天以上并在日历里标记到期提醒避免某天工作流突然全部报 401。6.2 Dify 拉取镜像失败与版本升级Dify 部署时最容易卡住的是镜像拉取。langgenius/dify-api和langgenius/dify-web这两个镜像体积都不小网络不稳定时很容易超时。我的建议是分两步走先单独docker pull这些镜像确认成功后再运行 Docker Compose。另外dify 1.17.1 更新之后改动了一些配置项老项目升级时会遇到环境变量不匹配的问题。保险的做法是升级前备份docker-compose.yaml和.env文件执行docker compose down之后再用新的 compose 文件启动。工作流的定义是存在数据库里的升级容器镜像不会丢工作流但升级前仍然建议用 Dify 后台的“备份”功能导出一份 DSL 文件这样可以做到任意回滚。6.3 飞书机器人收不到消息或回复超时这个问题我遇到得最多原因也最多样。最常见的是权限没配好具体表现是机器人发不出消息或者 LangBot 日志显示收到了消息但飞书侧没有任何记录。解决方向是去飞书开放平台检查im:message权限是否已开通以及事件订阅是否选择了正确的版本并发布。另一种是回复超时。飞书对机器人响应时间是有限制的如果机器人 3 秒或更短内没有返回响应飞书会认为发送失败并在一定时间后重试。我们这种工作流因为要调 GitHub API 再调大模型整体耗时大概率超过这个阈值。解决办法有两种。第一种是在 LangBot 收到消息后立即先回复一句“正在生成简报请稍候”然后再异步调用 Dify 工作流最终把结果推送出去。这样用户感知到的等待时间会好很多。第二种是缩短工作流耗时比如把 GitHub 请求并发化、限制拉取的提交条数、模型生成的 max_tokens 别设太大。6.4 LangBot 命中断言失败与工具选择异常LangBot 内部使用大模型做工具选择判断偶尔会出现判断不准的情况明明用户问的是 GitHub 更新它却走了默认闲聊逻辑。这个问题的根源不是 LangBot 本身而是它的工具选择提示词不够明确或者基础模型对工具描述的理解有限。我建议在 LangBot 的工具描述里加上足够的触发关键词并且在每条描述里给出正反面示例。例如“当用户消息中出现更新、commit、release、仓库、版本、动态、最新等关键词时优先调用该工具如果是一般问候、闲聊、数学运算则不调用”。另外如果 LangBot 本身用于工具调用和对话生成的是同一个模型这个模型还需要支持 function calling 特性。如果模型不支持那就只能走“手动规则匹配”来处理虽然少了一些智能感但可行性也很高。7. 一套可以复用的扩展思路这个工作流跑通之后我越用越觉得它本质上不只是“GitHub 更新简报器”。它背后的架构模式是飞书当作统一交互入口LangBot 当作消息总线和渠道适配器Dify 当作工作流编排器大模型当作自然语言理解和生成核心再配上各种外部 API 作为数据源。换一个数据源这套骨架就变成了另一个工具。我后面已经做过几个延伸。第一个是“竞品动态监控”把 GitHub API 换成几个指定竞品官网的 RSS 源每天定时拉取让模型总结出新增功能、价格调整、活动公告。第二个是“内部知识库问答”把 GitHub 数据源换成了我们内部的飞书云文档和知识库 API机器人可以直接回答“线上文档里怎么配置 xx”这类问题。第三个是“数据库查询助手”用户在飞书里问一句“昨天新增用户多少”LangBot 调 Dify 工作流工作流里先用代码节点生成 SQL再查数据库最后把结果返回给用户。这几个场景用的都是同一套飞书 LangBot Dify 的组合只是换了数据获取节点和提示词。如果你也想做类似的事情我的建议是先从最简版本开始。不要一上来就追求复杂的 Agent 规划、多轮对话、知识库 RAG先跑通“消息进、API 调、模型出、消息回”这个最小闭环。最小闭环跑通了后面加节点、加数据源、加权限控制都是水到渠成的事。我当初第一次联调成功的那一刻说实话比看十篇技术文章都有用。很多问题只有真正把消息从飞书发到 LangBot、再进入 Dify、再打回飞书才能暴露出来纸上谈兵没有意义。照着这个项目做一次你收获的不仅是一个能用的机器人还会对消息机器人、低代码 LLM 应用编排、云 API 调用和结构化数据清洗有更深入的理解。