Agent工作流实战：拆解资讯日报生成器与模型调用节点

资讯日报生成器这个实战课，核心不是让你写一个把新闻拼在一起的脚本，而是要把整个信息流拆成多个节点，让模型在每个节点上真正参与判断和生成，再组合成一份能直接阅读的日报。这一课之所以叫复杂工作流，是因为它和单次模型调用完全不一样：单次调用只是把一段文字交给模型返回结果，而日报生成器要处理多来源、多格式、多批次的内容，还要把模型输出整理成固定结构。如果你正在学 Agent 开发，或者想把一个真实业务场景做成自动化流程，这一课的思路可以直接复用。

我建议先不要急着写代码，先把这条工作流的边界和节点搞清楚。否则很容易出现“单条能跑，数据一多就乱”“模型偶尔抽风，整条任务就失败”的问题。下面按实际落地顺序拆一遍。

1. 先把“模型参与的复杂工作流”翻译成具体问题

1.1 资讯日报生成器到底在解决什么

资讯日报生成器解决的核心问题是信息过载和人工整理成本高。每天可能有几十条甚至上百条资讯散落在不同源头，人工一条条读完再归纳成一份日报，耗时而且容易遗漏。日报生成器把采集、清洗、摘要、汇总、格式化串成一条流水线，最终输出一份结构清晰、可以直接阅读或发布的报告。

这个场景很适合用来学 Agent 工作流，因为它不是单一技能，而是把数据获取、文本处理、模型调用、任务调度、错误处理全串在一起。做完这一课，你掌握的其实不是某个模型功能，而是怎么把一个端到端任务拆成可维护的节点。

1.2 为什么不是一次模型调用就能完成

很多人会误以为日报生成器就是“把一堆新闻丢给模型，让它总结一下”。实际跑一遍就发现，模型根本没法直接处理原始数据源。

单次模型调用的流程是：用户给一段文本，模型返回一段文本，结束。资讯日报生成器的流程比这长很多：

• 数据源可能是 RSS、网页、公开接口、本地文件，类型不统一。
• 内容可能带 HTML 标签、重复标题、无效字符、超长正文。
• 模型输出是自由文本，不一定符合固定格式。
• 任务要每天定时跑，不允许每次手工修改。
• 某个数据源失败时，不能导致整个任务挂掉。

也就是说，单次调用只需要考虑“提示词写得好不好”，而复杂工作流要考虑更多：输入清洗、调用策略、输出校验、失败恢复、调度运行。下面用一张对比表表达更直观：

1.3 复杂工作流的关键特征

复杂工作流不是简单堆功能，它有几个明显特征。

第一，节点可拆。采集是一个节点，清洗是一个节点，模型摘要是另一个节点，格式化输出又是一个节点。每个节点都能单独运行、单独测试。这样出了问题能很快定位是哪个环节。

第二，状态可追踪。每个节点处理了多少条数据、成功多少、失败多少、耗时多少，都要记录。没有日志的工作流，出了问题只能靠猜。

第三，模型不是唯一依赖。工作流里要混入规则、缓存、重试、校验这些工程手段。模型负责语义理解，规则负责保证格式和兜底。

第四，错误可恢复。模型会失败，接口会超时，数据源会变化，这都很正常。关键是失败后能重试、能跳过、能留下记录，而不是让整个任务卡死。

如果只是临时用一次，写一个简单脚本问题不大。但想稳定跑下去，就必须按工作流的方式设计。

2. 先搭运行环境和任务边界

2.1 环境准备：接口、密钥、运行时

资讯日报生成器不一定要本地 GPU，重点看模型部署方式。如果调用已有模型服务，普通开发机就能跑；如果使用本地模型，就要根据模型体积关注显存、内存和推理框架的支持情况。

在常见环境下，可以按这套基础准备：

• Python 3.9 或更高版本。
• 安装 requests、json、dataclasses 这类基础库。
• 准备模型接口地址、密钥、模型名称，不要写死在代码里。
• 准备输入数据源目录和输出目录。
• 准备好日志目录，方便排查问题。

配置最好放在独立文件或环境变量里。原因是日报生成器会同时接触数据源和模型服务，配置集中管理后，换环境、换模型、换密钥都不需要改代码。另外，密钥写死在代码里很容易泄漏，一旦提交到代码仓库就很麻烦。

如果原始项目里没有明确依赖版本，落地时先确认 Python 和依赖库的版本兼容性，不要凭印象装。

2.2 输入源和输出格式先定下来

日报生成器最怕的就是“输入都是活的，输出也是活的”。开始写代码前，先把输入源和输出格式固定下来。

输入源可以是 RSS、公开接口、本地文本文件、数据库记录。比如：

{ "sources": [ {"name": "ai_news", "url": "https://example.com/rss", "type": "rss"}, {"name": "local_notes", "path": "./inputs/today.txt", "type": "file"} ] }

输出格式可以是 Markdown、HTML、Word、纯文本。这里更建议先用 Markdown 跑通，因为 Markdown 结构清晰、方便阅读，后面要转 Word 或 HTML 再加一个转换节点。

# 2025-06-15 资讯日报 ## 大模型领域 - 标题：某模型发布新版本 来源：example.com 摘要：该模型在推理速度上做了优化，并增加了长文本支持。

不要一开始就纠结“怎么把 Markdown 转成 Word”这种问题。格式转换是最后一步，跟日报内容生成不是同一个问题。先把内容生成链路跑通，最后再处理格式转换。

2.3 资源条件与判断标准

日报生成器对资源的要求不算高，但不同运行方式差异很大。

还要特别提醒一个判断标准：不要把“能启动”当成“能上生产”。能启动只是第一步，还要看连续跑 3 到 5 天是否稳定。日报生成器这类任务，真正考验的是稳定性和可重复性，不是第一次能不能跑通。

3. 工作流拆解：从信息采集到日报成稿

3.1 信息采集节点

采集节点的任务是按时从各个数据源拿到原始内容。这里面最容易犯的错误，是看到什么就抓什么，完全没有边界。

更稳妥的做法是优先使用对方提供的公开接口或 RSS，减少解析成本，也降低对目标服务的压力。如果确实需要抓取页面，一定要控制频率和数量，不要用高频请求去打别人的服务器。这在资讯场景里既是工程问题，也是使用规范问题。

采集节点还要考虑单点失败：某个数据源暂时不可用，不应该让整个任务失败。正确做法是跳过这个源，记录日志，继续处理其他源。

3.2 过滤与预处理节点

采集到的原始数据通常不能直接丢给模型。RSS 条目里可能带 HTML 标签，多个源可能重复报道同一条新闻，有的条目可能只有标题没有正文，时间格式也可能五花八门。

这个节点做几件事：

• 去掉 HTML 标签和无效字符。
• 按标题或链接去重。
• 过滤过短、过长、无正文的条目。
• 统一时间格式。
• 截断超长正文，控制模型输入长度。

为什么过滤很重要？因为模型对干净输入更稳定。如果输入里有一堆标签和重复内容，模型输出的摘要质量会明显下降，而且重复内容会浪费模型调用的 token 成本。

3.3 模型摘要与编排节点

这个节点是模型参与最深的地方。模型在这里要做标题改写、摘要生成、领域分类、重要程度排序等工作。

这里要做一个关键设计：要不要把摘要、分类、排序合并成一次模型调用？

如果输入条目少，合并一次调用省时间。但条目多、格式杂的时候，我建议拆分。原因是拆分后更容易定位问题：摘要内容不对，看摘要调用；分类不对，看分类调用；如果全合在一起，模型输出一乱，很难判断是提示词问题还是模型能力问题。

实际落地时，可以先按批次做摘要，再汇总排序。把长文本先截断到合适长度，再交给模型，避免超出上下文限制。

3.4 格式化与校验节点

模型输出通常是自然语言文本，不一定严格符合日报结构。所以格式化节点不能只做“把模型输出写进文件”，还要做校验。

校验内容包括：日期是否存在、标题是否为空、来源是否保留、摘要是否完整、Markdown 结构是否正常。如果模型输出缺项，可以先用规则补默认值，或者重新请求一次，再不行就标记为失败，留到下一轮处理。

各节点关系可以这样看：

4. 最小可运行版本：单次生成怎么跑通

4.1 用示例代码跑通一条日报

先不要写完善的重试、队列和复杂调度。先把最小链路跑通：读取输入、调用模型、写出文件。

下面这段是演示主流程的示例代码，不是可以直接复制到生产环境的完整实现。实际使用时要把模型地址、鉴权、超时和重试换成你自己的。

# 示例代码：单次生成日报的简化流程 import json import requests def fetch_items(): # 演示用，实际要替换成真实数据源读取 return [ {"title": "某模型发布新版本", "source": "example.com", "time": "2025-06-15"}, {"title": "某框架发布更新说明", "source": "example.org", "time": "2025-06-15"} ] def summarize_with_llm(items): # 这里替换为你实际使用的模型接口 prompt = "请根据以下资讯列表生成一份结构化日报，包含日期、标题、来源、摘要：\n" prompt += json.dumps(items, ensure_ascii=False, indent=2) response = requests.post( "https://your-model-endpoint", json={"prompt": prompt, "temperature": 0.2}, timeout=60 ) response.raise_for_status() return response.json()["result"] def main(): items = fetch_items() report = summarize_with_llm(items) with open("daily_report.md", "w", encoding="utf-8") as f: f.write(report) if __name__ == "__main__": main()

这份代码的核心逻辑很清晰：读取条目、拼接提示词、调用模型、写文件。跑通之后，再把数据源、日志、重试逐步加进去。

4.2 核心参数怎么设置

日报生成器不是提示词越长越好，也不是温度越高越有创意。核心参数要按场景调。

这里不要一上来就把并发开满。并发高确实能提升处理速度，但代价是接口限流概率增加、日志变乱、问题定位变难。先把单条任务跑稳，再考虑批量提速。

4.3 验证成功结果

单次生成跑通后，怎么判断算成功？

第一，生成文件存在且非空。第二，日报里有正确日期和领域分组。第三，每条资讯都有标题、来源、摘要。第四，再运行一次，结构保持一致。第五，某个数据源返回空数据时，任务不崩溃，其他内容正常输出。

如果输出有乱码、空段落、标题丢失，先不要急着改模型提示词，应该先看输入编码、输出目录权限、后处理解析逻辑。很多时候问题不在模型，而在数据流转的某一环。

5. 多模型协作和参数调优

5.1 什么场景需要多个模型

不是所有日报都需要多个模型。单一模型如果摘要质量够，先用一个模型跑是最稳定的方案。

但业务复杂后，可以考虑分工：

• 用轻量模型做分类，降低成本和时延。
• 用更强模型做摘要和标题生成。
• 用不同厂商模型做互相备份，一个服务不稳定时切换另一个。

如果你在 Dify、Coze、n8n 这类工作流工具里编排，思路也是一样：把任务拆成多个节点，每个节点绑定一个模型或一个接口，节点之间通过输入输出串联。日报生成器只是把这种思路用代码实现出来。

要注意的是，不要为了“多模型”而多模型。多个模型意味着多个失败点、多份成本、多项参数要调。只有单一模型确实满足不了需求时，才做多模型协作。

5.2 系统提示词和温度怎么调

模型生成日报的稳定性，很大程度由提示词决定。可以给一个比较固定的提示词模板：

你是一个资讯编辑。输入是若干条资讯，请生成一份日报。 要求： 1. 按领域分组。 2. 每条资讯给出标题、来源、一句话摘要。 3. 不要编造事实。 4. 使用中文。 5. 输出 Markdown。

提示词里要明确输入格式、输出格式、约束条件。模型是很依赖上下文的，你给的结构越清晰，输出越稳定。温度按摘要场景一般设在 0.2 到 0.4，太高容易生成“可能”“大概”这类不必要表达，太低又容易显得模板化、死板。

5.3 模型失败时的降级策略

模型调用一定会失败，只是早晚问题。日报生成器必须提前设计降级策略。

常见的降级方案：

• 失败后重试 2 到 3 次，每次间隔递增。
• 重试还失败，跳过这条，保留原始标题和链接，摘要标记为“生成失败”。
• 如果配置了多个模型，可以切换到备用模型。
• 把错误信息写入日志，下一轮定时任务再补跑。

这套策略不复杂，但非常重要。没有降级策略的日报生成器，模型服务一抖动，整天的日报就没了。宁可留几条“生成失败”的记录，也不能让整个任务中断。

6. 从单次运行到稳定调度

6.1 定时任务和调度器

单次跑通之后，下一步是让日报每天自动生成。

在 Linux 环境里，最直接的方式是 cron。比如每天早上 8 点执行一次：

0 8 * * * cd /path/to/project && python generate_daily_report.py >> logs/run.log 2>&1

Windows 环境可以用计划任务，容器环境可以用内部调度框架，也可以直接用 Dify、Coze、n8n 这类工具的定时触发能力。

无论用哪种方式，都要注意两点：一是定时任务要能记录上一次运行状态，二是避免重复触发。如果上一次任务还没跑完，下一次任务又启动了，就可能出现重入问题。简单做法是加一个运行锁，正在执行时直接跳过新任务。

6.2 失败重试和幂等设计

定时任务要特别关注幂等性。什么叫幂等？就是同一天的任务重复跑多次，结果不会出现重复日报。

实现方式很简单：给每条资讯生成一个唯一键，比如日期 + 来源 + 标题。生成日报前先检查这条是否已经处理过，处理过就直接跳过。这样即使定时任务意外重跑，也不会产生重复数据。

如果数据源里有重复标题，还要做归一化处理，比如去掉首尾空格、把英文大小写统一，否则同一篇新闻会因为格式差异识别成两条。

6.3 日志、输出目录和任务队列

日报生成器属于周期性任务，日志比功能列表还重要。

建议日志至少包含：执行时间、当前节点、成功数量、失败数量、执行耗时、错误信息。这样每次运行完，一眼就能看出哪个环节有问题。

输出目录按日期分文件夹：

output/2025-06-15/daily_report.md output/2025-06-15/raw_items.json output/2025-06-15/annotated_report.md

如果数据源很多，需要考虑任务队列。不要一次性把所有原始数据都加载到内存，可以按源或者按批次分发。批处理的好处是单个批次失败不会影响全局，也能避免接口短时间被请求太多。

这里不要急着做复杂队列。先小批量验证，确认处理结果没问题，再逐步提高批次大小。

7. 常见问题排查链路

7.1 输出为空或格式错乱

日报生成器最容易踩的坑，就是模型服务跑通了，但最终日报是空的或者格式乱。

遇到这种情况，按这个顺序排查：

1. 输入是否为空。数据源可能没抓到任何条目，模型没有内容可总结。
2. 模型返回内容是否被截断。max_tokens 设小了，输出会在中间断掉。
3. 提示词是否明确要求 Markdown。没有明确要求，模型可能输出普通段落。
4. 后处理解析是否有 bug。比如用正则解析标题时，如果模型输出格式和预期不完全一致，就会丢失字段。

先看输入，再看模型返回，最后再看代码解析。这个顺序能避免很多误判。

7.2 任务卡住或速度变慢

任务卡住通常不是模型能力问题，而是某个环节一直等不到结果。

先看资源占用：CPU、内存、网络连接、磁盘读写。再看是否有其他任务同时运行，把资源占满了。然后检查模型服务和数据源接口的响应时间，很多“卡住”其实是网络请求超时后程序还在等待。

如果代码里设置了无限重试，也很容易造成“卡住”。建议所有重试都设置最大次数，每次重试间隔递增，避免网络抖动时疯狂请求。

7.3 API 报错和配额问题

模型接口返回报错时，先看错误码。常见几类：

• 鉴权失败：密钥错误或已过期，检查配置。
• 限流：请求频率过高，增加延时和重试。
• 配额不足：每天调用次数达到上限，需要评估日报条数和模型调用次数。
• 上下文超限：输入文本太长，截断后再调用。

不要一遇到报错就去改提示词。很多接口报错跟提示词无关，先确认请求本身是否正常。

7.4 排查顺序总结

日报生成器的问题排查，可以固定成一条链路：

1. 看现象：是空输出、卡住、报错，还是速度变慢。
2. 看输入：数据源是否为空，格式是否正确，编码是否正常。
3. 看请求：接口地址、鉴权、参数、超时设置是否正确。
4. 看环境：依赖版本、目录权限、网络是否可达。
5. 看代码：解析逻辑、分支判断、重试逻辑有没有写错。

这条链路看起来通用，但实际排查时报错信息很容易把人带偏。比如模型接口报“超时”，你可能一直在调超时参数，但真正原因是数据源返回了超大正文，接口处理不过来。所以我每次都会提醒：先看输入，再改参数。

8. 边界和进阶建议

8.1 低配环境能不能跑

资讯日报生成器如果使用模型 API，对本地机器要求很宽松，普通办公电脑就能跑。

如果使用本地模型，情况就不一样了。文本摘要任务通常不需要特别大的模型，但你也得根据模型体积观察显存和内存占用。在实际开发中，本地模型最容易遇到的问题是推理框架和模型格式不匹配，导致模型加载失败。这时候不要盲目改代码，先去确认当前推理框架是否支持你要加载的模型类型，以及依赖包是否安装完整。

如果机器配置偏低，正确做法不是换高端卡，而是把任务缩到最小可运行规模：减少并发数、缩短输入文本、降低生成长度、关闭不必要的附加功能。先把链路跑通，再考虑性能优化。

8.2 单机任务和生产任务的区别

单机任务和生产任务完全是两种要求。

单机任务只要能跑通、能输出、能手动排查问题就够了。生产任务需要考虑定时调度、连续运行稳定性、失败告警、幂等处理、并发控制、日志监控、权限隔离。如果你刚学工作流开发，不建议一上来就按生产标准设计，否则只会被无关问题淹没。

更现实的路径是分三步：

1. 先跑通单次生成。
2. 再加上定时调度和失败重试。
3. 最后才追加告警、监控、任务队列和多 Agent 编排。

8.3 后续还能加什么

资讯日报生成器跑稳之后，可以往几个方向扩展。

可以把历史日报存入知识库，支持按日期、关键词检索。可以增加重要度排序，把最值得看的资讯放到日报前面。可以接入企业微信、邮件、钉钉等渠道，自动推送日报。也可以引入人工反馈，对模型生成的摘要做评分，积累数据后持续优化提示词。

更进一步，可以让多个 Agent 协作：一个负责采集，一个负责审核，一个负责排版，一个负责发布。但前提是基础工作流已经稳定。基础链路跑不稳，Agent 越多越混乱。

如果你正准备做同类项目，我比较建议的路径是：先把单次生成跑通，再把调度和重试加上，最后再考虑多模型、多 Agent 的复杂编排。资讯日报生成器看起来环节多，但每个节点都能单独验证，问题也基本能从日志、输入和请求报错里定位。把这条链路打通，后面做知识库摘要、内容审核流程、简历筛选工作流，思路都是可以复用的。