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

做资讯日报这个需求看起来是 AI 最容易解决的场景之一把一堆新闻链接丢给模型让它整理成一份有摘要、有分类、有推荐的日报听起来就是几分钟的事。但真正上手之后你会发现模型并不知道“今天有哪些重要新闻”——除非你先告诉它。而“把新闻抓下来、清洗干净、筛出重点、再稳定输出成日报”这条链路一旦要求它每天自动跑、不重复、不遗漏、不出错它就不再是一个 prompt 能解决的问题而是一个需要 Agent 架构参与设计的工作流问题。这个判断我想放在最前面资讯日报生成器本质不是一个“模型调用任务”而是一个“工作流编排任务”。模型在里头很重要但只承担了其中一小段。真正决定这个项目能不能从“演示版”走到“每天稳定运行版”的是你怎么设计采集、清洗、筛选、生成、审核和分发之间的连接关系以及当某个环节失败时整个系统能不能优雅降级。下面我会围绕这个实战项目把模型参与的复杂工作流拆开讲清楚。内容会偏工程向也会给一些可实际落地的步骤和排查思路。1. 资讯日报生成器的真正难点不是写 prompt而是编排多环节流程1.1 为什么“让 AI 写日报”听起来容易做起来却总是翻车很多人在第一次尝试时会直接把问题抛给模型“帮我整理一份今天的人工智能行业日报。”模型会给你一份格式工整、分门别类的日报。但仔细一看你会发现三个问题它不知道“今天”发生了什么。模型的知识有截止时间也无法自动获取实时信息。它只能根据自己的训练记忆生成一份“看起来像那么回事”的日报。它编造细节。在没有数据支撑的情况下模型会“脑补”新闻标题、来源甚至原文内容。这在大模型术语里叫幻觉。它无法追溯。就算模型给出的信息是真实的你也拿不到原始链接无法验证也无法让读者点击跳转。也就是说只靠“一个 prompt 一个模型”做出来的是“日报的壳”不是“日报的里子”。那接下来很自然的想法是我把抓取到的新闻标题和链接喂给模型让它帮我整理。这一步确实可行但依然不够。因为原始素材里经常有重复、广告、短内容、无关内容、格式混乱的文本直接丢给模型它会在“脏数据”上做判断导致输出质量不稳定。1.2 从一次模型调用到一个 Agent 工作流差距到底在哪一次模型调用的输入输出非常简洁文本进文本出。但一个资讯日报生成器需要的是连续完成多个任务从多个数据源采集当天的新内容清洗内容去掉重复和噪音筛选出值得进入日报的条目让模型对条目做摘要、分类或评分整理成结构化日报交给人工审核或直接发布这个多任务链条就是工作流。而 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(fsource {source.name} failed: {exc}) return results这一层的核心产出是结构化条目标题、来源、链接、发布时间、摘要如果有的话。不要在这里就合并成一大段文本丢给模型后面还需要筛选和清洗。2.2 清洗与去重别让模型在脏数据上做判断采集到的数据往往是混合体有重复新闻、有纯广告、有只有标题没有正文的碎片、有发布时间缺失的记录。在这个阶段我更建议用“硬规则”做清洗而不是让模型判断。原因很简单清洗逻辑需要稳定、可解释、成本低。模型判断有概率性有些时候还慢。要处理的典型问题去掉正文为空或过短的条目去掉标题和正文里明显是广告、推广的内容按标题做归一化去重如果标题不同但链接相同也要去重过滤时间超出范围的内容比如“昨天之前”的新闻默认不进当天日报清洗之后我们可以给每条数据计算一个“基础质量分”用于下一阶段排序。这里提醒一句不要在这一步就丢掉原始链接。后面模型生成日报时需要把完整链接带出来。很多日报项目做到一半发现“没有链接”就是因为中间环节没有保留来源信息。2.3 筛选与排序用评分机制代替“凭感觉选新闻”经过清洗的条目可能仍然有不少。让模型逐一判断每条是否值得进日报成本高而且不好调。我建议先用一个“评分公式”做粗筛再让模型对高分内容做细加工。评分可以综合多个维度评分维度说明权重建议关键词匹配是否命中你关心的主题词高时效性发布距当前时间越近分数越高中来源权重核心媒体/官方源给更高分中文本完整度有正文、有长摘要的加分低重复次数多个源报道同一事件加权重看场景这个公式不是死的可以结合自己的领域调整。比如做技术日报关键词匹配的权重就很重要做综合资讯来源权重和时效性要拉高。粗筛的结果通常控制在一个数量范围内比如候选 20 到 30 条最终日报只保留 10 到 15 条。这一步把模型要处理的内容控制在一个相对稳定的体量里既能控制成本也更容易保持输出质量。2.4 生成与格式化模型最擅长也最容易被滥用的环节到这一步我们已经把“喂给模型的内容”从原始嘈杂数据变成了结构化、筛选后的候选条目。现在才轮到模型真正参与为每条新闻生成一句摘要按主题分组比如“大模型进展”“开源项目”“行业事件”为每个分组写一句简短的“主编观察”把日报整理成 Markdown 文本模型在这步的核心价值是“把结构化的信息加工成人话”而不是“发明信息”。为此prompt 里要明确只基于提供的条目内容输出不要添加额外细节。不编造链接、日期、来源。输出格式固定比如每个分组下的条目列表。如果某组没有内容就留空或标注“暂无更新”。实际开发里还可以让模型输出 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。这里有两条经验能先让代码缩短文本就不要让模型读原文。模型token不是无限便宜的尤其在团队里做成一个长期服务时。如果数据量太大可以分批调模型再做二次合并。比如每 5 条一组生成一个“小组简报”最后再对小组简报做合并。这个思路在处理长文本时非常常用。成本控制不是为了省几块钱而是为了让这个工作流可持续。一天跑一次感觉差别不大一旦一天跑十几次、几十次或者团队多个人同时用差别立刻就出来了。3.3 结构化输出与校验别让自由文本毁掉流程模型输出不可避免会出现变化。今天给你 Markdown明天可能多一个代码块标记后天可能把列表嵌套错。让自由文本直接进入下游流程是很多日报生成器维护成本上升的原因。我建议做一层“输出协议”固定使用 JSON 作为中间格式。定义好每个字段的类型和必填项。在代码中解析 JSON解析失败就标记为失败任务。校验通过后再进入渲染阶段。这样即使模型偶尔抽取错误也不会让整个日报流程中断。你可以设置一个重试策略第一次解析失败重试一次还是失败就把对应分组标记为“格式异常”由人工处理。这个设计理念不仅适用于资讯日报也适用于所有涉及模型调用的自动化流程模型输出是你的“原材料”必须经过校验和规整才能变成产品的一部分。3.4 人工审核节点放在生成之后还是之前我的建议是放在生成之后、发布之前。为什么不是生成之前因为人工审核的重点不是“决定要不要生成”而是“看生成结果是否可用”。模型摘要、分组、点评的质量只有生成出来之后才能被有效评估。在 MVP 阶段日报生成后直接输出到本地 Markdown 文件或某个内部群人工过一眼确认无误再对外分发。等运行一段时间、模型输出稳定之后再考虑让“低风险分组”自动发布“高风险分组”仍然走审核。这样的好处是你保留了对最终产品内容的控制权同时在逐步建立信任。自动化从来不是一步到位的先让模型做草稿再做编辑最后做审批是更稳妥的路径。4. 从“单次跑通”到“每天稳定运行”还差三块拼图如果你只是做一次实验跑到第 2 章结束基本够了。但如果你要把它部署到一个服务器上让它每天自动跑那你至少要补上三块拼图异常处理、日志追踪、幂等与调度。4.1 异常与重试模型调用不可能永远成功在实际运行中模型服务的返回可能超时、可能限流、可能突然返回空内容甚至可能因为依赖服务升级而暂时不可用。这不是小概率事件而是常态。一个比较稳的处理策略是每个环节都包一层 try-catch。模型调用设置超时时间比如 30 到 60 秒。对临时性错误做有限次重试比如 2 次重试之间加退避。重试仍失败就把任务标记为失败并保留原始数据供排查而不是直接丢弃。再往下做可以在失败时发送提醒。对于日报任务如果我们每天早上 8 点生成日报7 点失败了最好在 7 点零几分就有提醒而不是等到用户 8 点打开订阅发现是空文档。4.2 日志与追踪没有日志的 Agent 工作流没法维护Agent 工作流比普通接口多了更多中间节点因此排查链路更复杂。你至少要能回答这几个问题这条日报是哪一批任务生成的每一环节花了几秒有没有失败模型输入输出块保存在哪里最终日报是哪几个核心条目组成的我建议结构化日志至少包含以下字段字段示例用途batch_id20250623对应某一天的运行批次step_namefetch/clean/select/generate当前环节item_idurl_hash对应具体的数据条目statussuccess/failed/skipped状态cost_ms1234耗时errortimeout...错误信息有了这个日志你就可以快速定位问题出在采集源挂了还是模型调用超时还是解析失败。没有日志你要靠猜有日志你几秒就能找到原因。4.3 幂等与调度重复运行和定时触发日报任务要防止重复执行。比如定时任务因为服务器重启、网络超时等原因重复触发了三次同一批数据被反复处理最终日报出现重复内容这就是幂等性问题。可以用几个办法控制给每天的运行批次生成一个唯一键比如report_20250623。在数据库或缓存里记录该批次的状态running、success、failed。启动前先检查当天批次是否已经成功生成成功则直接跳过。每条新闻按链接哈希或标题哈希去重保证不会因为重复运行而插入多次。调度层可以选择 simple 的方式Linux cron、系统定时任务如果团队里已经有调度平台也可以接入。这个阶段不需要上复杂的编排引擎先把“每天按时跑、不重复跑”解决掉。5. 沉淀一个可复用的 Agent 工作流设计框架做完资讯日报这个项目可以把经验抽象成一个通用框架。以后不管你做周报生成器、竞品监控、开源项目动态汇总还是会议纪要整理都可以套用这个思路。5.1 四层拆分法我比较推荐把 Agent 工作流拆成四层数据层负责接入外部数据源输出结构化条目。这一层不调用模型只用代码和接口。规则层负责清洗、去重、评分、数量控制。这一层也不调用模型核心是可配置、可解释。模型层负责摘要、分类、点评、格式转换。这一层是唯一调用模型的地方要控制 token 和延迟。控制层负责调度、状态管理、日志、重试、人工审核。这一层是工作流能长期稳定运行的关键。把这四层分清楚之后你会发现很多看起来复杂的 Agent 项目本质上是在控制层把前三层组合起来。每一层内部都可以独立升级、独立测试、独立替换。5.2 自研和现成工作流工具怎么选市面上的工作流工具比如 Dify、Coze、n8n可以帮你快速搭出这类日报流程。它们把节点拖拽连接起来很多基础功能已经内置。我的建议是快速验证、个人使用、不需要和内部系统深度集成优先用现成的工作流工具。它们能省掉大量运维工作尤其对于不熟悉前后端开发的人来说非常适合做原型。要长期运行、要处理复杂权限、要接入已有数据系统、要精细控制日志和异常考虑自研或者自研工作流引擎的简化版。因为当你需要监控、告警、批量处理、审计时自研会让每一步都可控。日报生成器这个项目两种路径都可以走通。关键看你的真实需求是“一周内跑出一个可用版本”还是“做一个长期维护的产品模块”。5.3 适用边界这个方案适合谁需要明确的是这个方案不是万能的。它适合的场景有个人或团队内部的每日资讯整理基于特定关键词的行业动态监控每周或每月固定形式的简报生成内容平台的草稿预生成不适合的场景包括需要严格事实核验的金融、医疗、法律场景需要实时、秒级响应的资讯推送对外内容直接自动发布没有任何人工审核的场景对数据隐私要求极高、不允许外部模型服务介入的场景如果你确实要处理这些场景需要在架构里加入更严格的核验层、更细的权限控制以及本地模型或专有模型部署方案。那样的话成本和复杂度都会大幅上升不是简简单单一个日报工作流能覆盖的。6. 高频问题与排查链路最后补充一块实际维护中经常遇到的内容。如果你把日报生成器部署后发现“日报没生成”“日报内容重复”“日报质量变差”可以按下面的顺序排查。6.1 按顺序排查现象、输入、环境、参数、日志我建议的排查顺序如下看现象是完全没有输出还是输出了但内容为空还是内容重复还是某个分类缺失先准确定位是哪一种失败。看数据层采集环节有没有成功拉回数据数据源列表有没有变化RSS 地址是否失效这是最常见的失败点。看清洗层清洗规则是不是过严把所有数据都过滤掉了去重逻辑是不是偶发误杀看模型层模型调用有没有超时返回的 JSON 能不能解析摘要是不是随机缺失看控制层定时触发有没有成功日志里有没有异常堆栈批次状态是 running、success 还是 failed这个顺序的逻辑是先看“有没有数据”再看“数据有没有被处理”再看“处理结果有没有问题”最后看“流程怎么挂了”。如果你一开始就盯着参数改反而容易漏掉真正的根因。6.2 几个容易忽略的坑结合日常维护经验我列几个坑时区问题。服务器时区如果不是北京时间定时调度会在错误的时间触发。采集时间、批次时间、日报日期全部要统一时区。日期字段判断。有的新闻源发布时间是“最后更新时间”不是“首次发布时间”会导致你看到的“昨日新闻”乱入今日列表。去重字段选错。只用标题去重不够稳不同媒体标题可能不同。建议用内容归一化后的签名或者 URL 路径做去重。模型输出格式漂移。今天 JSON 正常明天模型升级后JSON 里多了一个字段或者缩进变了。解析层要做“宽容解析”必要时要升级 prompt 并重新验证。数据源频率限制。如果你用的第三方搜索 API或者某些网站有反爬限制一次采集请求太多会被限流。要给采集层加请求间隔和失败退避。没有保留原始数据。排错时最有用的东西是原始输入。建议每个批次保留一份原始 JSON 存档方便事后复盘。这些坑不会在第一次跑通时出现但会在你跑了一两个月之后陆续冒出来。提前在心里留个印象能让你排查时光速定位。回到最开始的问题资讯日报生成器到底难在哪里难的不是让模型输出像样的话而是把一条“需要实时信息、需要确定性判断、需要开放生成、需要长期可靠”的完整链路设计成一个人工可以检查、代码可以执行、模型可以辅助、系统能够兜底的工作流。如果你正在做类似项目我的建议是先别急着把模型能力拉满。先用代码把数据采集、清洗、排序跑通让模型只做摘要和分类然后加上日志、重试和批次记录最后再考虑是否增加人工审核或自动发布。每一步都先跑出最小闭环再逐步升级。这样你得到的才不是一个“能演示的日报生成器”而是一个“可以每天替你值班的资讯系统”。