资讯日报生成器实战：从Prompt到Agent工作流编排与落地

做资讯日报这个需求，看起来是 AI 最容易解决的场景之一：把一堆新闻链接丢给模型，让它整理成一份有摘要、有分类、有推荐的日报，听起来就是几分钟的事。但真正上手之后你会发现，模型并不知道“今天有哪些重要新闻”——除非你先告诉它。而“把新闻抓下来、清洗干净、筛出重点、再稳定输出成日报”这条链路，一旦要求它每天自动跑、不重复、不遗漏、不出错，它就不再是一个 prompt 能解决的问题，而是一个需要 Agent 架构参与设计的工作流问题。

这个判断我想放在最前面：资讯日报生成器，本质不是一个“模型调用任务”，而是一个“工作流编排任务”。模型在里头很重要，但只承担了其中一小段。真正决定这个项目能不能从“演示版”走到“每天稳定运行版”的，是你怎么设计采集、清洗、筛选、生成、审核和分发之间的连接关系，以及当某个环节失败时，整个系统能不能优雅降级。

下面我会围绕这个实战项目，把模型参与的复杂工作流拆开讲清楚。内容会偏工程向，也会给一些可实际落地的步骤和排查思路。

1. 资讯日报生成器的真正难点，不是写 prompt，而是编排多环节流程

1.1 为什么“让 AI 写日报”听起来容易，做起来却总是翻车

很多人在第一次尝试时，会直接把问题抛给模型：

“帮我整理一份今天的人工智能行业日报。”

模型会给你一份格式工整、分门别类的日报。但仔细一看，你会发现三个问题：

1. 它不知道“今天”发生了什么。模型的知识有截止时间，也无法自动获取实时信息。它只能根据自己的训练记忆，生成一份“看起来像那么回事”的日报。
2. 它编造细节。在没有数据支撑的情况下，模型会“脑补”新闻标题、来源甚至原文内容。这在大模型术语里叫幻觉。
3. 它无法追溯。就算模型给出的信息是真实的，你也拿不到原始链接，无法验证，也无法让读者点击跳转。

也就是说，只靠“一个 prompt + 一个模型”，做出来的是“日报的壳”，不是“日报的里子”。

那接下来很自然的想法是：我把抓取到的新闻标题和链接喂给模型，让它帮我整理。这一步确实可行，但依然不够。因为原始素材里经常有重复、广告、短内容、无关内容、格式混乱的文本，直接丢给模型，它会在“脏数据”上做判断，导致输出质量不稳定。

1.2 从一次模型调用到一个 Agent 工作流，差距到底在哪

一次模型调用的输入输出非常简洁：文本进，文本出。但一个资讯日报生成器，需要的是连续完成多个任务：

1. 从多个数据源采集当天的新内容
2. 清洗内容，去掉重复和噪音
3. 筛选出值得进入日报的条目
4. 让模型对条目做摘要、分类或评分
5. 整理成结构化日报
6. 交给人工审核或直接发布

这个多任务链条，就是工作流。而 Agent 架构在这条链路里要做的事情，不是“调用一次模型”，而是编排一次复杂任务：决定每一步做什么、用什么工具、要不要调模型、调完模型之后下一步做什么、出错怎么办。

用一句话概括：“单次模型调用是‘问一个问题得到一个答案’，Agent 工作流是‘拆掉一个目标，逐步执行，并且在执行中兜底’。日报生成器是后者。”

1.3 规则和模型各管一段，才是稳定的起点

这是我做了几个类似项目之后最深的体会：不要指望模型包办所有环节。

• 数据采集：用代码按固定频率抓取，这是规则任务，不用模型。
• 去重和清洗：用字符串匹配、规则过滤、发布时间判断，这是确定性任务，更适合代码。
• 摘要、改写、分类、排序理由：这些是开放性任务，适合模型。
• 最终审核和发布：应该由人来兜底，至少保留在“建议模式”。

如果非让模型承担所有环节，你会遇到两类问题：一是模型输出不稳定，二是模型输入太长、成本太高、延迟太长。资讯日报这个场景不算极端复杂，但如果你把垃圾数据、重复数据、超长内容都塞给模型，模型既浪费 token，又会把噪音当成重点，输出自然不专业。

2. 一个最小可运行的日报工作流，应该怎么拆

2.1 信息采集：先解决“模型不知道今天发生了什么”

这一步是整个工作流的前提。模型的训练数据是滞后的，而日报要求的是“当天发生的事”，所以必须为模型提供实时上下文。

采集层要确定三件事：

• 数据源列表：比如行业媒体 RSS、特定网站栏目页、开发者社区、关键词搜索接口。建议先维护一个白名单，不要贪多。
• 采集频率：日报场景通常每天固定一次，一般放在早上或晚间。可以先用定时任务触发，不需要做得太重。
• 采集方式：优先使用已有的 RSS 或 API 接口，没有接口的页面再做 HTML 解析。HTML 解析容易受页面改版影响，要额外做容错。

常见写法类似这样：

# 示例结构 def fetch_sources(source_list): results = [] for source in source_list: try: items = source.fetch() # 每个数据源有自己的抓取逻辑 results.extend(items) except Exception as exc: log.warning(f"source {source.name} failed: {exc}") return results

这一层的核心产出是结构化条目：标题、来源、链接、发布时间、摘要（如果有的话）。不要在这里就合并成一大段文本丢给模型，后面还需要筛选和清洗。

2.2 清洗与去重：别让模型在脏数据上做判断

采集到的数据往往是混合体：有重复新闻、有纯广告、有只有标题没有正文的碎片、有发布时间缺失的记录。

在这个阶段，我更建议用“硬规则”做清洗，而不是让模型判断。原因很简单：清洗逻辑需要稳定、可解释、成本低。模型判断有概率性，有些时候还慢。

要处理的典型问题：

• 去掉正文为空或过短的条目
• 去掉标题和正文里明显是广告、推广的内容
• 按标题做归一化去重；如果标题不同但链接相同，也要去重
• 过滤时间超出范围的内容，比如“昨天之前”的新闻默认不进当天日报

清洗之后，我们可以给每条数据计算一个“基础质量分”，用于下一阶段排序。

这里提醒一句：不要在这一步就丢掉原始链接。后面模型生成日报时，需要把完整链接带出来。很多日报项目做到一半发现“没有链接”，就是因为中间环节没有保留来源信息。

2.3 筛选与排序：用评分机制代替“凭感觉选新闻”

经过清洗的条目可能仍然有不少。让模型逐一判断每条是否值得进日报，成本高，而且不好调。我建议先用一个“评分公式”做粗筛，再让模型对高分内容做细加工。

评分可以综合多个维度：

这个公式不是死的，可以结合自己的领域调整。比如做技术日报，关键词匹配的权重就很重要；做综合资讯，来源权重和时效性要拉高。

粗筛的结果通常控制在一个数量范围内，比如候选 20 到 30 条，最终日报只保留 10 到 15 条。这一步把模型要处理的内容控制在一个相对稳定的体量里，既能控制成本，也更容易保持输出质量。

2.4 生成与格式化：模型最擅长也最容易被滥用的环节

到这一步，我们已经把“喂给模型的内容”从原始嘈杂数据，变成了结构化、筛选后的候选条目。现在才轮到模型真正参与：

• 为每条新闻生成一句摘要
• 按主题分组，比如“大模型进展”“开源项目”“行业事件”
• 为每个分组写一句简短的“主编观察”
• 把日报整理成 Markdown 文本

模型在这步的核心价值是“把结构化的信息加工成人话”，而不是“发明信息”。为此，prompt 里要明确：

1. 只基于提供的条目内容输出，不要添加额外细节。
2. 不编造链接、日期、来源。
3. 输出格式固定，比如每个分组下的条目列表。
4. 如果某组没有内容，就留空或标注“暂无更新”。

实际开发里，还可以让模型输出 JSON 中间结果，再由后端代码渲染成日报。这样在格式校验上更稳。

{ "date": "2025-06-23", "groups": [ { "name": "大模型进展", "items": [ { "title": "某模型发布新版本", "summary": "一句话摘要", "source": "来源名称", "url": "原始链接" } ] } ], "editor_note": "今天值得关注的方向..." }

先拿 JSON，再按模板渲染为 Markdown，比让模型直接生成 Markdown 更可控：能校验字段是否齐全，能单独调整排版，也不会因为模型偶尔加个多余符号就破坏日报格式。

3. 模型参与的边界，决定了工作流能否长期稳定

3.1 哪些环节让模型参与，哪些环节不应该

我见过不少失败案例，问题都不在模型能力上，而在于把模型用错了地方。

可以用一张表来划分职责：

当你把“什么该交给模型”想清楚之后，整个工作流的稳定性会明显提升。模型只处理那些“定义模糊、需要理解、允许多样性”的任务，而把“确定性任务”交给代码。

3.2 上下文窗口与 token 预算：一次日报要花多少钱

很多人做项目时不太会算 token。等到日报跑起来，发现每天要消耗几十万 token，才回头优化，已经有点晚了。

一个基本的预算方式如下：

• 假设候选条目 20 条，每条原文约 800 到 1500 字。
• 如果全量塞给模型让模型读原文做摘要，一次请求可能吃掉 2 万到 3 万 token。
• 如果先用规则抽取“标题 + 首段摘要 + 关键句”，再把文本压缩到每条 200 到 300 字，一次请求可以降到 6000 到 10000 token。

这里有两条经验：

1. 能先让代码缩短文本，就不要让模型读原文。模型token不是无限便宜的，尤其在团队里做成一个长期服务时。
2. 如果数据量太大，可以分批调模型，再做二次合并。比如每 5 条一组生成一个“小组简报”，最后再对小组简报做合并。这个思路在处理长文本时非常常用。

成本控制不是为了省几块钱，而是为了让这个工作流可持续。一天跑一次，感觉差别不大；一旦一天跑十几次、几十次，或者团队多个人同时用，差别立刻就出来了。

3.3 结构化输出与校验：别让自由文本毁掉流程

模型输出不可避免会出现变化。今天给你 Markdown，明天可能多一个代码块标记，后天可能把列表嵌套错。让自由文本直接进入下游流程，是很多日报生成器维护成本上升的原因。

我建议做一层“输出协议”：

• 固定使用 JSON 作为中间格式。
• 定义好每个字段的类型和必填项。
• 在代码中解析 JSON，解析失败就标记为失败任务。
• 校验通过后再进入渲染阶段。

这样，即使模型偶尔抽取错误，也不会让整个日报流程中断。你可以设置一个重试策略：第一次解析失败，重试一次；还是失败，就把对应分组标记为“格式异常”，由人工处理。

这个设计理念不仅适用于资讯日报，也适用于所有涉及模型调用的自动化流程：模型输出是你的“原材料”，必须经过校验和规整，才能变成产品的一部分。

3.4 人工审核节点：放在生成之后还是之前

我的建议是：放在生成之后、发布之前。

为什么不是生成之前？因为人工审核的重点不是“决定要不要生成”，而是“看生成结果是否可用”。模型摘要、分组、点评的质量，只有生成出来之后才能被有效评估。

在 MVP 阶段，日报生成后，直接输出到本地 Markdown 文件或某个内部群人工过一眼，确认无误再对外分发。等运行一段时间、模型输出稳定之后，再考虑让“低风险分组”自动发布，“高风险分组”仍然走审核。

这样的好处是：你保留了对最终产品内容的控制权，同时在逐步建立信任。自动化从来不是一步到位的，先让模型做草稿，再做编辑，最后做审批，是更稳妥的路径。

4. 从“单次跑通”到“每天稳定运行”，还差三块拼图

如果你只是做一次实验，跑到第 2 章结束基本够了。但如果你要把它部署到一个服务器上，让它每天自动跑，那你至少要补上三块拼图：异常处理、日志追踪、幂等与调度。

4.1 异常与重试：模型调用不可能永远成功

在实际运行中，模型服务的返回可能超时、可能限流、可能突然返回空内容，甚至可能因为依赖服务升级而暂时不可用。这不是小概率事件，而是常态。

一个比较稳的处理策略是：

1. 每个环节都包一层 try-catch。
2. 模型调用设置超时时间，比如 30 到 60 秒。
3. 对临时性错误做有限次重试，比如 2 次，重试之间加退避。
4. 重试仍失败，就把任务标记为失败，并保留原始数据供排查，而不是直接丢弃。

再往下做，可以在失败时发送提醒。对于日报任务，如果我们每天早上 8 点生成日报，7 点失败了，最好在 7 点零几分就有提醒，而不是等到用户 8 点打开订阅发现是空文档。

4.2 日志与追踪：没有日志的 Agent 工作流没法维护

Agent 工作流比普通接口多了更多中间节点，因此排查链路更复杂。你至少要能回答这几个问题：

• 这条日报是哪一批任务生成的？
• 每一环节花了几秒？有没有失败？
• 模型输入输出块保存在哪里？
• 最终日报是哪几个核心条目组成的？

我建议结构化日志至少包含以下字段：

有了这个日志，你就可以快速定位：问题出在采集源挂了，还是模型调用超时，还是解析失败。没有日志，你要靠猜；有日志，你几秒就能找到原因。

4.3 幂等与调度：重复运行和定时触发

日报任务要防止重复执行。比如定时任务因为服务器重启、网络超时等原因重复触发了三次，同一批数据被反复处理，最终日报出现重复内容，这就是幂等性问题。

可以用几个办法控制：

• 给每天的运行批次生成一个唯一键，比如report_20250623。
• 在数据库或缓存里记录该批次的状态：running、success、failed。
• 启动前先检查当天批次是否已经成功生成；成功则直接跳过。
• 每条新闻按链接哈希或标题哈希去重，保证不会因为重复运行而插入多次。

调度层可以选择 simple 的方式：Linux cron、系统定时任务；如果团队里已经有调度平台，也可以接入。这个阶段不需要上复杂的编排引擎，先把“每天按时跑、不重复跑”解决掉。

5. 沉淀一个可复用的 Agent 工作流设计框架

做完资讯日报这个项目，可以把经验抽象成一个通用框架。以后不管你做周报生成器、竞品监控、开源项目动态汇总，还是会议纪要整理，都可以套用这个思路。

5.1 四层拆分法

我比较推荐把 Agent 工作流拆成四层：

1. 数据层：负责接入外部数据源，输出结构化条目。这一层不调用模型，只用代码和接口。
2. 规则层：负责清洗、去重、评分、数量控制。这一层也不调用模型，核心是可配置、可解释。
3. 模型层：负责摘要、分类、点评、格式转换。这一层是唯一调用模型的地方，要控制 token 和延迟。
4. 控制层：负责调度、状态管理、日志、重试、人工审核。这一层是工作流能长期稳定运行的关键。

把这四层分清楚之后，你会发现，很多看起来复杂的 Agent 项目，本质上是在控制层把前三层组合起来。每一层内部都可以独立升级、独立测试、独立替换。

5.2 自研和现成工作流工具怎么选

市面上的工作流工具（比如 Dify、Coze、n8n）可以帮你快速搭出这类日报流程。它们把节点拖拽连接起来，很多基础功能已经内置。

我的建议是：

• 快速验证、个人使用、不需要和内部系统深度集成：优先用现成的工作流工具。它们能省掉大量运维工作，尤其对于不熟悉前后端开发的人来说，非常适合做原型。
• 要长期运行、要处理复杂权限、要接入已有数据系统、要精细控制日志和异常：考虑自研，或者自研工作流引擎的简化版。因为当你需要监控、告警、批量处理、审计时，自研会让每一步都可控。

日报生成器这个项目，两种路径都可以走通。关键看你的真实需求是“一周内跑出一个可用版本”，还是“做一个长期维护的产品模块”。

5.3 适用边界：这个方案适合谁

需要明确的是，这个方案不是万能的。它适合的场景有：

• 个人或团队内部的每日资讯整理
• 基于特定关键词的行业动态监控
• 每周或每月固定形式的简报生成
• 内容平台的草稿预生成

不适合的场景包括：

• 需要严格事实核验的金融、医疗、法律场景
• 需要实时、秒级响应的资讯推送
• 对外内容直接自动发布，没有任何人工审核的场景
• 对数据隐私要求极高、不允许外部模型服务介入的场景

如果你确实要处理这些场景，需要在架构里加入更严格的核验层、更细的权限控制，以及本地模型或专有模型部署方案。那样的话，成本和复杂度都会大幅上升，不是简简单单一个日报工作流能覆盖的。

6. 高频问题与排查链路

最后补充一块实际维护中经常遇到的内容。如果你把日报生成器部署后发现“日报没生成”“日报内容重复”“日报质量变差”，可以按下面的顺序排查。

6.1 按顺序排查：现象、输入、环境、参数、日志

我建议的排查顺序如下：

1. 看现象：是完全没有输出？还是输出了但内容为空？还是内容重复？还是某个分类缺失？先准确定位是哪一种失败。
2. 看数据层：采集环节有没有成功拉回数据？数据源列表有没有变化？RSS 地址是否失效？这是最常见的失败点。
3. 看清洗层：清洗规则是不是过严，把所有数据都过滤掉了？去重逻辑是不是偶发误杀？
4. 看模型层：模型调用有没有超时？返回的 JSON 能不能解析？摘要是不是随机缺失？
5. 看控制层：定时触发有没有成功？日志里有没有异常堆栈？批次状态是 running、success 还是 failed？

这个顺序的逻辑是：先看“有没有数据”，再看“数据有没有被处理”，再看“处理结果有没有问题”，最后看“流程怎么挂了”。如果你一开始就盯着参数改，反而容易漏掉真正的根因。

6.2 几个容易忽略的坑

结合日常维护经验，我列几个坑：

1. 时区问题。服务器时区如果不是北京时间，定时调度会在错误的时间触发。采集时间、批次时间、日报日期全部要统一时区。
2. 日期字段判断。有的新闻源发布时间是“最后更新时间”，不是“首次发布时间”，会导致你看到的“昨日新闻”乱入今日列表。
3. 去重字段选错。只用标题去重不够稳，不同媒体标题可能不同。建议用内容归一化后的签名或者 URL 路径做去重。
4. 模型输出格式漂移。今天 JSON 正常，明天模型升级后，JSON 里多了一个字段，或者缩进变了。解析层要做“宽容解析”，必要时要升级 prompt 并重新验证。
5. 数据源频率限制。如果你用的第三方搜索 API，或者某些网站有反爬限制，一次采集请求太多会被限流。要给采集层加请求间隔和失败退避。
6. 没有保留原始数据。排错时最有用的东西是原始输入。建议每个批次保留一份原始 JSON 存档，方便事后复盘。

这些坑不会在第一次跑通时出现，但会在你跑了一两个月之后陆续冒出来。提前在心里留个印象，能让你排查时光速定位。

回到最开始的问题：资讯日报生成器到底难在哪里？难的不是让模型输出像样的话，而是把一条“需要实时信息、需要确定性判断、需要开放生成、需要长期可靠”的完整链路，设计成一个人工可以检查、代码可以执行、模型可以辅助、系统能够兜底的工作流。

如果你正在做类似项目，我的建议是：先别急着把模型能力拉满。先用代码把数据采集、清洗、排序跑通，让模型只做摘要和分类；然后加上日志、重试和批次记录；最后再考虑是否增加人工审核或自动发布。每一步都先跑出最小闭环，再逐步升级。这样，你得到的才不是一个“能演示的日报生成器”，而是一个“可以每天替你值班的资讯系统”。