你有没有算过每天早上为了整理行业动态要花多少时间我以前雷打不动地刷十多个信息源再把觉得重要的链接手工粘进共享文档折腾下来大半个早上就没了。后来我用 FastGPT 搭了个自动化流程系统定时任务每天早上触发 AI 工作流自动采集新闻、生成日报再推到企业微信和邮箱实测跑了小半年累计稳定发送 180 多份日报几乎没有断档。这篇文章就把整套方案的架构、配置、踩坑过程完整写出来给想用 FastGPT 做定时任务自动化、又不想把时间耗在重复手工操作上的人做个参考。1. 先想清楚再动手日报自动化的整体架构怎么搭很多人一听说用 AI 生成日报第一反应是打开大模型网页版把链接粘贴进去让它总结。这条路单独用几次没问题但要一天不落、每天 8 点准时产出纯手动一定坚持不了两周。所以核心不是AI 能不能生成日报而是定时触发和主动推送这两个环节谁来管。1.1 为什么选 FastGPT 而不是裸 API 调用我最早是用 Python 脚本直接调大模型 API 来生成日报。优点是最少依赖一个脚本加一个 crontab 就能跑缺点是每次调整提示词都要改代码日报里如果要用自己积累的行业知识还得自己在脚本里拼上下文越往后越难维护。后来我把 FastGPT 接进去相当于把AI 应用和调度脚本拆开了改日报模板只需要在 FastGPT 工作台里改工作流和提示词调度脚本完全不动。维度裸 API 自研脚本FastGPT 工作流提示词维护改代码重发脚本可视化编辑即时生效知识库接入自己写检索逻辑内置知识库节点直接关联会话/上下文管理自己维护状态工作流节点自动管理团队协作代码仓库团队空间/应用市场失败处理完全自己写多节点组合实现我个人的建议是如果只是给自己用、日报内容也不需要知识库直接用脚本调用 API 更轻量但如果你想做成团队基础设施、让非技术人员也能调整 AI 行为FastGPT 这类平台是更划算的投入。1.2 日报流程的四个环节日报自动化表面上是一个定时任务实际拆开是四个环节定时触发、数据采集、内容生成、结果推送。任何一个环节断掉日报都不会按时出现。定时触发器系统 Cron ↓ 调用 FastGPT 应用 API FastGPT 工作流数据采集 → 知识库检索 → LLM 生成日报 → 输出文本 ↓ POST / SMTP 企业微信 / 钉钉 / 邮件在定时触发环节我用的就是系统 crontab因为它是所有方案里最不容易出问题、也最容易排查的。数据采集环节放在 FastGPT 工作流内部用 HTTP 请求节点去抓 RSS 和公开信息源如果你想要的数据有反爬或者需要复杂登录我建议写一个独立采集脚本把结果写进知识库或数据库再由工作流节点读取不要把所有压力都压在工作流里。内容生成是 FastGPT 的强项用 AI 对话节点配合提示词模板完成。最后的推送环节可以完全放在工作流里用 HTTP 节点实现也可以在外部脚本里推。我的经验是一开始先把推送放在工作流里一条链路从触发到交付全部打通确认每天都稳定出报之后再把重试、多通道推送这类复杂逻辑挪到外部脚本。2. FastGPT 部署与日报工作流核心配置要跑通整个流程第一件事是把 FastGPT 环境准备好。2.1 本地化部署Docker 一键启动与模型接入FastGPT 官方推荐用 Docker Compose 跑一套完整环境。我自己的服务器是 4C8G 的 Linux 机器单机部署 FastGPT 主服务、MongoDB、向量数据库这些组件跑一个个人日报应用绰绰有余如果团队并发量高再把数据库单独拆出去。本地化部署的好处一是数据完全在自己的服务器上涉及内部知识库时更放心二是可以自由接入各种模型渠道不受某个 SaaS 平台的绑定。部署的常规步骤是从 GitHub 拉取 FastGPT 项目复制一份 .env 环境变量文件在环境变量里填写大模型 API 的 Key 和地址然后用 Docker Compose 一键拉起。等容器日志显示服务启动完成后访问 3000 端口进入控制台创建应用。这里有一个新手的常见误区FastGPT 本身不内置大模型它只是一个AI 应用编排器模型能力需要你提前配置好某个模型供应商的 API。日报场景对模型要求不高只要上下文长度够、中文输出稳定就行不需要一上来就追最强最大的模型。2.2 工作流里的核心节点怎么编排进入 FastGPT 控制台新建应用时选择工作流模式你会看到画布上有多种节点。做日报我实际用到的是这几种数据采集节点一般用 HTTP 请求节点定时去抓取 RSS 或信息源接口把返回内容作为后续节点的输入。知识库检索节点连接已经建好的知识库检索和你行业相关的背景资料。这一步决定了日报是纯新闻复读还是有观点的分析。AI 对话节点核心节点把采集到的数据和检索结果一起放进提示词让模型按模板输出日报。文本拼接/代码执行节点对生成内容做二次格式化比如把 Markdown 标题补全、去掉多余空行。HTTP 请求节点把最终日报 POST 到企业微信或钉钉的 Webhook。文本输出节点把结果返回给 API 调用方。整个工作流的顺序大体是HTTP 请求节点拿原始信息 → 知识库检索节点拿长期知识 → 拼进 AI 对话节点 → 输出到文本拼接节点 → 再通过 HTTP 请求节点推送。我第一次搭建时总想把所有事情放在一个节点里完成这是不对的每个节点只做一件事后续排查和修改才能精准定位。另外FastGPT 工作流支持逐步调试。我习惯先把每个节点手动跑一遍确认返回结构符合预期再串联整条流。尤其是 HTTP 请求节点返回的字段名差一个字母后面拼提示词时就可能整段空白这种低级错误在工作流里很常见。3. 定时触发Cron 表达式与三种调度方案日报要求每天早上 8 点落到调度系统里就一句话cron 表达式。3.1 每天 8 点的 Cron 表达式拆开给你看Cron 表达式有五个字段顺序是分、时、日、月、周。每天 8 点整的表达式写出来是0 8 * * *拆开看分是 0小时是 8日、月、周都是通配符*含义就是时钟走到 8 点 0 分、无论日期星期几都执行。工作中常用到的还有这么几个变体表达式含义0 8 * * 1-5工作日周一至周五早晨 8 点30 8 * * *每天 8:300 9 * * MON每周一 9 点*/10 * * * *每 10 分钟一次0 2 * * *每天凌晨 2 点适合做数据备份如果你用 Linux 的 crontab内容可以直接写0 8 * * * /usr/bin/python3 /opt/daily-report/run.py /var/log/daily-report.log 21注意脚本路径最好用绝对路径日志也要单独存一份后面排查问题时没有日志寸步难行。3.2 Linux Cron、Windows 计划任务、云函数定时触发器怎么选定时调用 FastGPT 的方式我实际用下来有三类可选Linux 系统 crontab最直接一个文件搞定谁都能查只要服务器不宕机执行很可靠。云函数定时触发器不用维护服务器但调试不如本地方便冷启动偶尔会造成几十秒延迟。Jenkins 等 CI/CD 工具的定时构建适合已经上了 Jenkins 的团队可以把生成日报当成一个流水线任务来管还顺带保留历史构建记录。如果没有特殊原因我个人推荐第一类也就是单纯在服务器上配 crontab。原因很简单定时任务这种场景稳比炫重要。crontab 已经存在几十年语法简单、行为明确所有服务器运维人员都能接管。你是在给自己搭一个每天都依赖的基础设施选最朴素可靠的方案别引入没必要的外部依赖。3.3 最容易出错的时区与错峰问题这是我实际踩过的坑专门拿出来说。第一次配置时我在 crontab 里写了0 8 * * *结果日报中午 12 点才到。排查半天发现是服务器的系统时区是 UTC它执行的 8 点其实是北京时间下午 4 点而我中午看到的那封其实是凌晨跑的另一个测试任务。解决办法是先统一时区timedatectl set-timezone Asia/Shanghai同时给 crontab 带上环境变量也可以但直接改系统时区是一劳永逸的做法。另一个经验是错峰如果你的 FastGPT 是多人共用的或者模型 API 有并发限制没必要把时间钉死在 8:00:00。我把定时任务设在 8:05也就是5 8 * * *这样既满足早上到公司能看见又避免和整点报时类任务挤在同一个时间窗口。4. 让日报可读而不是流水账提示词与数据源设计定时触发解决了准时的问题但真正决定日报价值的是 AI 生成内容的质量。很多人的 AI 日报不好看问题不出在模型而出在提示词和数据源。4.1 一套可以直接抄的提示词模板行业日报最常见的死法是生成结果像新闻标题列表。为了避免这个我给日报设定了三个结构块今日要闻、值得关注的数据、我的看法。同时明确要求只使用给定信息源禁止编造。模板如下你是我的行业情报分析师。下面是今天采集到的原始信息 {{rss_results}} 请在严格依据上述信息的前提下按以下格式生成日报 ## 今日要闻3-5 条 每条包含 - 标题 - 来源 - 一句话摘要 - 影响点评不超过 30 字 ## 值得关注的数据 列出你发现的关键数据并说明其隐含趋势。 ## 我的看法 用 100 字总结今天值得重点跟进的一件事。 要求 1. 禁止编造内容、来源和数据 2. 语言直接、口语化避免标题党 3. 全文字数控制在 800 字以内。这个模板的核心逻辑是把摘要影响分析拆成两个动作避免 AI 只输出标题复读。你在 FastGPT 工作流里把{{rss_results}}替换成上一个节点传来的实际数据就行。如果日报是给团队看的我会建议增加一条对团队的影响字段让日报从新闻汇编变成工作指引。提示词的迭代也要像代码一样有版本感。我一般先在 FastGPT 应用页手动跑几次看输出有没有幻觉、结构是否稳定改提示词时不要推翻重写而是逐条增加约束因为一次性改动太多你很难判断是哪条规则真正起了作用。4.2 数据源接入与知识库的配合采集环节决定日报的天花板。如果你喂给模型的信息只有三五个过时链接提示词写得再漂亮也出不了好内容。我目前的做法是两条腿走路RSS 直接抓 知识库补背景。RSS 抓取用工作流里的 HTTP 请求节点就能实现请求返回的 XML 先经过代码节点解析成纯文本再把纯文本塞给 AI 对话节点。一个需要注意的细节是RSS 源要定期维护很多小网站写着写着就断更了。建议在采集节点后加一个判断如果返回内容为空直接跳过这个源不要让它把空数据喂给模型。知识库在日报场景里容易被忽略。日报不只是今天有什么新闻更要紧的是这条新闻对谁有什么影响。我把过去半年的行业报告、政策解读、竞品动态都整理进了 FastGPT 知识库工作流里用检索节点取得相关段落再和当天新闻一起交给大模型。这样生成的日报就有了记忆它能写出这条政策和上个月那次调整一脉相承这种话而不是孤立地复述新闻。当然知识库检索也有坑检索结果太杂会把日报带偏。我的实践经验是限制检索返回条数只取 3-5 条最相关的内容并且在提示词中明确知识库内容只作为背景参考不作为当日信息主体。5. 推送落地企业微信/钉钉 Webhook 与邮件发送日报生成出来最后一步是把它送到该出现的地方。5.1 Webhook 推送的通用套路企业微信群机器人、钉钉群机器人、飞书自定义机器人它们的 Webhook 推送方式大同小异往一个 URL 发 POST 请求body 是固定格式的 JSON。比如企业微信机器人curl https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key这里填机器人的Key \ -H Content-Type: application/json \ -d { msgtype: markdown, markdown: { content: # 7月12日 行业日报\n\n**今日要闻**\n\n 1. 某某公司发布新政策 } }钉钉机器人也是类似的 POSTbody 里把msgtype换成markdown即可不过钉钉自定义机器人有个安全限制消息里必须包含你设置的关键词否则会被拒绝。我第一次对接钉钉时就因为日报文本里没有触发关键词推送一直失败后来把日报标题固定加了一个行业日报关键词才算解决。如果想把推送放到 FastGPT 工作流内部只需要在 HTTP 请求节点里配置同样的 URL、请求头和请求体把日报变量拼到 content 字段里。工作流内置推送的好处是触发、生成、发送全在一个应用里管理少一个外部脚本就少一个故障点。5.2 邮件推送与多通道并行有些场景不适合群机器人比如日报要发给外部顾问、或者你想自己在邮箱里归档。邮件推送我通常用 Python 的 smtplib 实现外层还是 cron 调用。关键代码很短import smtplib from email.mime.text import MIMEText msg MIMEText(report, html, utf-8) msg[Subject] 今日行业日报 msg[From] sender msg[To] receiver with smtplib.SMTP_SSL(smtp.qq.com, 465) as server: server.login(sender, auth_code) server.sendmail(sender, [receiver], msg.as_string())有一点容易踩坑这里的 password 不是邮箱登录密码而是邮箱服务商生成的授权码。QQ 邮箱、163 邮箱都在设置里能找到生成入口我第一次用真实密码登录直接被拒。多通道并行也是常见需求团队看企业微信、自己收邮件、领导可能在飞书。最省事的做法是在外部脚本里推多个 Webhook或者在工作流里并列两个 HTTP 请求节点。我现在的配置是 FastGPT 工作流先把日报生成好再通过两个 HTTP 请求节点分别推企业微信和邮件邮件走的是自定义邮件服务封装好的接口整体稳定后基本不用管。6. 运行半年踩过的坑完整排查链路自动化流程最怕的不是搭建而是某天它突然不干活了你还不知道它死在哪一步。下面这几个排查场景是我这半年真实遇到过的。6.1 任务没触发先查这三层日报某天没按时出现我的排查顺序永远是三层先看定时任务有没有执行再看脚本有没有报错最后看 API 调用是否被拒绝。第一层用grep CRON /var/log/syslog看 crontab 是否真的发起了任务。我曾经遇到过服务器在凌晨因为系统更新自动重启重启后 cron 服务没有正常拉起导致任务静默失败。这属于基础设施级故障日志里能看到 cron 进程异常重启服务就能恢复。第二层看脚本日志。我的 crontab 里始终挂着 /var/log/daily-report.log 21排查时tail -n 100看一眼如果是 Python 语法错误、依赖缺失日志会直接给出堆栈。没有日志的定时任务等于裸奔强烈建议从一开始就把日志留好。第三层看 FastGPT 侧的应用日志。如果外部脚本请求返回 401 或者 4xx多半是应用 Token 失效如果是 5xx大概率是大模型服务超时或工作流内部报错。FastGPT 的管理后台可以看到对话记录把对应时间点的记录点开能直接看到是哪一步节点出了问题。6.2 日报内容重复、过时和编造内容问题的排查往往比任务不触发更隐蔽。有段时间日报连续一周都在复述同一条旧消息我一开始怀疑是 RSS 源坏了后来发现是采集节点做了缓存旧的 XML 一直没清理。解决办法是在代码节点里给每条新闻加时间戳过滤超过 24 小时的内容直接丢弃。编造问题也遇到过。模型在信息不足时喜欢脑补尤其是让它总结值得关注的数据时它可能会编出根本不存在的百分比。我的对策是双管齐下提示词里把禁止编造数据这条规则放到最前面同时在知识库检索节点后面加一个校验节点没有命中数据就不允许输出具体数字。6.3 频率限制、失败重试与告警调度脚本本身写得再健康也扛不住上游限流。企业微信机器人对单个机器人每分钟的消息频率有限制虽然日报一天一次不会触发但如果你后续做了日报 午间摘要 晚间复盘一日三推就要考虑错开发送时间。大模型 API 侧也会有并发和速率限制。我在外部脚本里给请求加了重试机制捕获异常后等待 5 秒重试最多 3 次间隔逐步拉长到 10 秒、20 秒。实测这个策略能把绝大多数瞬时故障稀释掉但重试次数也不能太多否则故障时期反而会堆积请求。另外建议增加失败告警万一日报真的没发出去至少要在运维群或者个人邮箱收到一条今日日报发送失败的通知。我的做法是在脚本末尾判断发送结果失败时再调用一次企业微信机器人发一条单独的告警消息。这样即使日报断了人还醒着。最后再分享一个小技巧日报跑得越久价值越体现在历史沉淀上。我现在除了每天早上推给团队还会把每天生成的日报按日期存档到一个数据库表里月底用脚本汇总成月度回顾。定时任务加 AI 工作流这套框架一旦跑通你很容易往里面加新东西比如晚间版、只看重点版、针对某个客户的定制版。建议你先从每天 8 点一份日报这个最小闭环开始跑稳了再一步步加复杂度。这个自动化的复利比你想的要大得多。