早上打开手机企业微信里已经躺着今天的行业日报昨天有哪些值得关注的产品发布、开源社区有什么新项目、竞对又做了哪些动作。这不是某个资讯App推送的是我自己搭的一套自动化系统干的。核心引擎就是 FastGPT配合定时任务每天 8 点雷打不动把日报送到我跟前。这套方案我已经跑了两个多月中间踩过不少坑也优化过好几轮。今天把整个落地过程完整写出来从 FastGPT 本地化部署、行业日报工作流搭建到 Cron 定时触发、常见问题排查一条线讲透。文章偏实操适合手里有服务器、想给团队或自己做自动化信息服务的开发者参考哪怕你之前没碰过 FastGPT照着走也能跑起来。1. 先说结论这是一套什么样的方案1.1 要解决的问题做技术的人每天都有信息焦虑要看竞品动态、看新框架、看行业报告、看大厂技术博客。光靠手动刷网页不但费时间而且容易被信息流算法牵着走真正重要的东西反而漏掉。我想要的是这样一种能力每天早上固定时间系统自动把过去 24 小时相关渠道的新内容抓回来让 AI 按照我关心的维度做筛选、去重、摘要和结构化输出最后推送到手机上。人可以晚起日报不能缺席。这里有两个硬性要求。第一是数据可控行业信息里很大一部分是内部资料、付费内容、私有知识库我不希望这些内容经过第三方平台中转所以必须本地化部署。第二是可编排日报不只是把内容丢给大模型总结这么简单还要过滤低质信息、控制输出格式、按固定模板渲染这需要一套能可视化编排的工作流引擎。两个需求叠在一起FastGPT 几乎是现阶段最顺手的选择。1.2 为什么不用别的方式有人会问直接写 Python 脚本调大模型 API再用 crontab 不也能实现确实能但区别在于维护成本和可扩展性。脚本方案里提示词、数据源、输出格式全都硬编码在代码里改一次要动代码、重启服务而 FastGPT 的工作流界面里改提示词、换模型、调参数都是点几下鼠标的事非开发人员也能看懂。还有一种方案是用现成的自动化平台比如各类 RPA 工具或者商业 AI 工作流平台。这类工具胜在省事但定制能力受限尤其是知识库问答、私有数据检索、复杂分支逻辑这些场景往往要额外收费或者根本不支持。FastGPT 开源版本没有这些限制。从技术架构上看我的方案可以拆成三个部分。最底层是 FastGPT 平台负责模型管理、知识库和工作流引擎中间层是行业数据源通过 RSS、公开接口或者自建的定时采集脚本把内容喂给 FastGPT最上层是调度器负责每天早上 8 点触发工作流再把生成结果推送到企业微信。三个部分松耦合任何一个环节掉了都不会影响其他部分排查起来也很清晰。2. FastGPT 本地化部署实战2.1 Docker Compose 一把梭FastGPT 官方提供了一键部署脚本本质上是 Docker Compose 编排把前端、后端、FastGPT 依赖的 MongoDB、PostgreSQL 等组件打包在一起。我建议你在干净的系统上部署我用的是 4 核 8G 的云主机存储给了 100G实际跑下来 CPU 和内存都很宽裕模型推理还是另外接到其他服务上的。部署前确认机器上有 Docker 和 Docker Compose 插件。然后拉取项目代码官方仓库里有 docker-compose.yml 和 config.json 配置文件。直接执行 docker compose pull 拉镜像再 docker compose up -d 启动。第一次启动会因为初始化数据库稍微慢一点等 2 到 3 分钟后访问服务器 IP 的 3000 端口就能看到登录页。这里有两个坑提前说。一个是 MongoDB 初始化需要时间如果打开页面报数据库连接失败别急着删掉容器重来先等两分钟再看。另一个是 config.json 里的模型配置必须提前填好否则即使前端起来了创建应用的时候也会提示没有可用模型。2.2 模型接入本地模型和商业 API 怎么选FastGPT 本身不产生模型能力它是个编排和业务层必须对接大模型。接入方式有两种主流选择。第一种是接本地模型。用 Ollama 或者 vLLM 部署 Qwen 系列、Llama 系列这类开源模型FastGPT 通过 OpenAI 兼容接口对接本地模型服务。优点是数据完全不出内网也不按 token 计费适合日报内容量大、经常跑批量任务的场景。缺点是对机器性能有要求模型越大推理越慢需要至少一块好显卡纯 CPU 跑 7B 模型做每日摘要会比较吃力。第二种是接商业模型 API。在 config.json 里填好模型服务商的 BaseURL 和 API Key再配置一下模型名称映射就行。这种方式效果最好、速度最快但费用会随着日报的调用量线性增长。我个人的建议是如果有 GPU 资源用本地模型做基础摘要和格式化把最关键的判断环节路由到商业模型质量和成本能取得一个折中。FastGPT 支持一个应用里配置多个模型工作流的不同节点可以分别选择使用哪个模型这种路由能力很实用。2.3 部署完成后的自检清单服务起来以后先别急着搭工作流花 5 分钟做个连通性测试。检查思路如下浏览器打开 FastGPT 管理界面确认前端加载正常。进入模型提供商页面确认模型状态显示可用不是红色失败。创建一个最简单的应用输入一句话测试模型能否正常回复。确认 API 端口正常在服务器本地用 curl 调用应用的 HTTP 接口看能否拿到 200 响应。这个自检清单能帮你尽早暴露问题。我遇到过的情况是模型 Provider 配置了但鉴权没通过导致工作流里第一个节点就报错排查到半夜才发现是 API Key 多了一个空格。诸如此类的低级问题在自检阶段就能全部拦下来。3. 搭一条日报生成工作流3.1 数据源是日报的地基日报的质量高低一半取决于数据源。FastGPT 工作流里可以直接用HTTP 请求节点抓取外部接口数据但更通用的是先把数据准备好再用定时或手动方式导入到知识库。我的数据源分三类你可以参考技术社区和博客的 RSS 输出这类数据用 RSSHub 之类的开源项目做统一聚合输出成标准 RSS 格式脚本每天抓取一次即可。竞品产品的公开动态包括官网公告、版本发布说明可以通过定时爬虫抓取页面内容或者直接用公开 API。行业报告和热点话题这类内容在公众号、新闻站分布比较散人工每周补充一次到知识库让 AI 做周维度的回顾。抓取到的数据需要做文字提取和清洗。我在数据采集脚本里做三步处理去除 HTML 标签和样式、去除导航栏和广告等噪音、把发布时间统一格式化为标准时间。清洗后的内容按日期和来源分类存到文本文件或者导入 FastGPT 知识库。从这三个月经验看数据源宁可精不要多。刚开始我图全接了 30 多个源的 RSS结果日报里全是无关紧要的水文。后来砍到 10 个左右的高质量源日报的信息密度反而上来很多。3.2 提示词决定日报质量工作流的核心是一个AI 对话或者AI 结构化输出节点提示词写得好不好直接影响日报能不能用。我建议不要在提示词里堆砌太多规则而是给 AI 一个明确角色、一组具体任务和一个输出模板让它照着做。我的日报提示词核心逻辑是这样的先说明我是谁、日报给谁看再告诉 AI 这次输入的是哪些渠道的信息接下来要求它按重要度从高到低筛选出不超过 8 条内容每条内容必须包含信息标题、来源、一句话摘要、为什么这条对读者重要这四个要素。最后强制要求输出为固定的 Markdown 格式不允许添加额外寒暄。这里的关键是为什么这条对读者重要如果只让 AI 做摘要输出会非常平淡纯粹是新闻复读机。加上这个维度以后AI 会自动带入目标读者的视角筛选标准会明显偏向行业相关度高的信息。3.3 从工作流到企业微信群FastGPT 工作流里有很多种节点真正让日报闭环的是 HTTP 请求节点。我用这个节点把最终生成的日报内容 POST 到企业微信机器人的 Webhook 地址上。企业微信机器人的用法很简单在目标群里添加一个自定义机器人会得到一个 Webhook URL向这个 URL 发送特定格式的 JSON 数据即可。工作流里配置一个 HTTP 节点请求方法选 POST请求体写{ msgtype: markdown, markdown: { content: {{aiNode.output}} } }其中{{aiNode.output}}是工作流里上一个 AI 节点的输出变量FastGPT 里的变量引用语法是双大括号加节点名。注意企业微信 markdown 消息有 4096 字节的长度限制如果日报内容太长会被截断我是让 AI 节点输出完以后再加一个字符串处理节点做截断处理。对接钉钉、飞书机器人的原理类似只是消息格式略有不同。如果想让信息发送到邮件可以用 SMTP 节点或者走第三方邮件 API逻辑也是通的。4. 定时任务的正确姿势4.1 先把 Cron 表达式讲透定时触发这块网上有很多资料但我还是要把 Cron 表达式单独拿出来说因为踩坑最多的就是这里。Cron 表达式有不同的位数标准。最常见的 Linux 系统 crontab 使用 5 位格式分 时 日 月 周。而 Java 生态里的 Quartz、Spring Boot 的 Scheduled cron 通常使用 6 位格式多了一个秒字段在开头。以每天早晨 8 点为例在 Linux crontab 里写成0 8 * * *意思是第 0 分、第 8 小时、每个月的任意一天、任意月、任意星期等价于每天 08:00。如果要求周一到周五上班日执行则写成0 8 * * 1-5注意周字段里 0 和 7 都代表周日这在某些文档里容易搞混。如果使用 6 位 Quartz 格式则要写成0 0 8 * * ?多了一个最前面的秒字段而且日和周不能同时指定具体值必须用问号占位。第一次用 Java 定时任务的朋友看到这个问号往往会懵其实它表达的就是该字段不参与匹配。4.2 用系统 Crontab 触发 FastGPT API最简单的定时调度方式就是 Linux 系统自带的 crontab不需要额外安装任何东西。先确认 FastGPT 应用有可调用的 HTTP 接口。在 FastGPT 应用编辑页面可以找到该应用的 API 配置创建 API Key 后就能通过 HTTP 请求调用这个应用等同于在界面上发了一条对话消息。我的 crontab 配置是0 8 * * * curl -s -X POST http://127.0.0.1:3000/api/v1/chat/completions \ -H Authorization: Bearer fastgpt-xxxx \ -H Content-Type: application/json \ -d {chatId: daily-report, messages: [{role: user, content: 请生成今日行业日报}]} /var/log/fastgpt-report.log 21由于 FastGPT 本身部署在本机这里直接用 127.0.0.1 访问不加鉴权网关也能通。请求里带上 chatId 的好处是让多轮对话保持在同一个会话上下文如果日报生成到一半失败了重试时还能沿用一个上下文。crontab 的日志很重要第一次跑通前别省这一步。把所有输出追加到日志文件第二天早上检查日志如果发现 curl 报错能省去很多排查时间。4.3 复杂场景下的分布式定时方案如果你所在的企业已经有 Java 技术栈不想在服务器上额外维护 crontab那可以考虑在现有应用里集成定时任务框架。Spring Boot 项目里用 Scheduled 注解加 Cron 表达式就能实现本质和 crontab 一样每天 8 点触发一个方法方法里用 HTTP Client 调用 FastGPT API拿到结果后再走企业微信推送。优点是可以把定时任务和业务系统放在一起复用公司已经搭好的监控告警体系。如果系统是多实例部署就要注意同一时刻多个实例不能都去触发同一个定时任务否则日报会重复推很多份。这时需要引入分布式锁或者使用 XXL-Job 这类分布式任务调度平台。XXL-Job 里有统一的调度中心可以配置多个执行器通过在调度中心设置 Cron 表达式来触发任务天然解决多实例重复执行的问题。还有一种思路是 FastGPT 工作流自身如果支持定时触发节点那就直接在流程里配 Cron完全不需要外部调度器。不过我实际用下来外部调度更直观可控也方便在触发前后做额外的依赖检查和状态记录。4.4 跑了两个月后总结的调度经验调度这块有几个经验值得分享。第一时区要统一。服务器可能是 UTC 时区也可能是 CST 时区crontab 用的是系统时区判断执行时间但 FastGPT 容器内部可能又是另一套时区。最简单的办法是把宿主机时区、Docker 容器时区、FastGPT 日志时区全部统一为 Asia/Shanghai避免8 点没跑或者7 点就跑了的诡异问题。第二注意夏令时和系统时间同步。云主机默认开启 NTP 时间同步一般不会出问题但如果你把 crontab 部署在某些精简容器里里面根本没有 NTP 服务时间漂移会导致任务执行时间越来越不准确。第三完备的失败告警比任务本身更重要。我一开始只配置了日报推送没有配置失败告警结果有一天数据源源站超时工作流直接报错日报没发出来我早上到公司打开手机才发现。后来我在 crontab 脚本里加了判断逻辑如果 curl 请求返回非 200就立即调用一个独立的告警机器人接口把错误消息推给团队群。这样日报没到告警先到人还没到工位就心里有数了。5. 常见问题与排查记录5.1 高频问题速查表这两个多月里我碰到的问题集中在以下几类整理成表方便你对照排查。现象可能原因排查方法定时任务不触发时区不对、Cron 表达式写错先确认系统时区再手动执行一次脚本验证FastGPT API 调用超时工作流节点逻辑太复杂模型推理太慢检查 FastGPT 日志观察是哪一步耗时最长日报内容为空数据源没有抓到新内容或者解析失败手动触发工作流查看每个节点的输入输出日报内容重复数据源在一天内被多次抓取存在重复内容在清洗脚本中按文章链接去重推送消息被拦截Webhook 地址失效、消息内容超长先在命令行用 curl 单独调用 Webhook 测试模型输出格式混乱提示词约束不严格或者模型版本替换后行为变化把输出格式要求写的更明确增加不允许输出其他内容约束工具类问题基本都能在这个表里找到方向。真正麻烦的是类型数据抓取到了但是内容质量太差这种主观问题这种没有统一解法只能通过调提示词和筛选数据源来慢慢优化。5.2 日报质量与成本优化心得最后聊点体会层面的东西。日报系统的价值不在于把信息搬运一遍而在于看完之后能快速形成判断。我建议你在提示词里加入只保留可能有业务影响的信息这个筛选条件然后把筛选到的内容用影响分析而不是内容摘要来呈现。同样一条某大厂发布新框架的新闻摘要只是告诉你框架发布了影响分析则会告诉你它对现有技术选型是否有冲击、是否值得团队跟进调研。这个差别非常明显。关于成本如果每天跑的日报任务量很大可以调整工作流里各个节点的模型策略清洗和格式化用便宜的小模型判断和影响分析用贵的大模型。FastGPT 工作流的每个 AI 节点都能单独选模型充分利用这个特性费用能节省不少。另外数据源维护不能只靠一次配置。RSS 源可能会失效网站改版可能让爬虫抓不到内容每周抽 10 分钟看一下日报的输出质量及时调整数据源和提示词比花大把时间调模型参数有意义得多。自动化系统的维护不是一劳永逸而是持续优化你投入时间打磨它它才能真正成为你每天离不开的助手。