1. 从一条每日资讯说起为什么要用智能体工作流来做内容自动化每天早上八点我手机里会准时收到一条推送——一份排版整齐的AI行业资讯包含标题、摘要、来源链接和一段简短的点评。这份资讯不是我手动整理的也不是某个编辑团队在后台加班赶出来的而是一个跑在Coze上的AI智能体工作流在每天凌晨自动完成抓取、筛选、摘要、排版、发布的全流程。这个项目就是「每日AI资讯」自动生成发布系统核心关键词是Coze、AI智能体、工作流。说白了这件事解决的是一个很朴素的问题AI领域的信息更新速度太快了每天有大量的新模型发布、新工具上线、新论文挂出、新融资消息传出。靠人工去刷各种信息源、筛选有价值的内容、写成简报不仅耗时而且很容易漏掉重要信息。我试过纯手动整理坚持了不到两周就放弃了——不是不想做是实在扛不住每天两三个小时的投入。这个工作流适合几类人参考一是想做内容自动化但不知道从哪下手的朋友二是已经在用Coze或类似平台搭智能体、想看看完整工作流怎么设计的开发者三是需要做行业信息聚合的产品或运营同学。哪怕你完全没接触过Coze只要跟着思路走一遍也能理解一个自动化内容流水线是怎么从零搭起来的。我搭建这个工作流的整体周期大概花了三个周末中间踩了不少坑也推翻过两版方案。下面我把整个设计思路、核心节点配置、实操过程和排查经验完整地拆开讲一遍尽量做到你照着就能复现。2. 整体架构设计与方案选型为什么是Coze而不是别的2.1 需求拆解一条资讯从哪来到哪去在动手之前我先把「每日AI资讯」这个需求拆成了几个明确的环节。第一个环节是信息采集需要从多个渠道获取当天的AI相关资讯包括新闻站点、社区热帖、产品更新日志等。第二个环节是内容筛选不是所有信息都值得放进日报需要按关键词、来源权重、热度等维度做过滤。第三个环节是摘要生成把筛选后的内容压缩成一段可读的摘要最好带一点点评。第四个环节是排版组装把标题、摘要、来源、日期等信息拼成一份结构化的文档。第五个环节是发布把成品推送到目标渠道。这五个环节串起来就是一条完整的工作流。如果纯靠写代码实现用Python加定时任务也能做但维护成本不低——信息源的页面结构一变抓取脚本就得改摘要模型换个接口代码又得调。我需要的是一个可视化、可调试、改起来不费劲的方案。2.2 为什么选Coze工作流而不是纯代码或Dify市面上做工作流的平台不少Coze、Dify、ComfyUI各有各的定位。ComfyUI我主要用来跑图像生成的工作流做文本类资讯处理不太顺手。Dify在AI智能体开发上确实强尤其是RAG和Agent编排但它的工作流更偏向对话式应用做这种定时触发的批处理任务配置起来反而绕。Coze吸引我的点在于第一它的工作流节点类型足够覆盖我的需求有代码节点、大模型节点、插件节点、条件判断节点、循环节点基本不用写太多底层代码第二它的插件生态里有现成的网页抓取、搜索、文档处理能力省去了自己封装接口的功夫第三调试体验比较直观每个节点的输入输出都能单独跑、单独看出问题容易定位。提示选平台的时候不要只看功能列表一定要看它的调试能力和错误处理机制。工作流跑一次成功不难难的是连续跑三十天不出问题出问题能快速修好。2.3 工作流的整体拓扑结构我的工作流大致分成三段。第一段是「采集段」由一个定时触发器启动依次调用搜索插件和网页抓取插件把多个来源的原始内容拉回来存到一个数组变量里。第二段是「处理段」用一个循环节点遍历原始内容每个条目先过一遍关键词过滤命中的再送进大模型节点做摘要和点评输出结构化结果。第三段是「组装发布段」把所有处理好的条目按模板拼成Markdown文档再通过发布插件推送到目标渠道。这三段之间用变量传递数据采集段的输出是处理段的输入处理段的输出是组装段的输入。整个链路是线性的没有太复杂的嵌套这样设计的好处是每一段都可以独立测试改一段不会影响其他段。2.4 关键设计取舍批处理还是逐条处理这里有一个我纠结过的点是把所有原始内容一次性丢给大模型做批量摘要还是逐条处理。批量处理的好处是省调用次数、速度快但坏处是模型容易在长上下文里丢失细节而且一条内容出错会影响整批。逐条处理虽然调用次数多但每条独立出错可控而且可以针对不同来源用不同的提示词。最后我选了逐条处理配合循环节点。实测下来虽然调用次数上去了但整体稳定性好很多而且单条失败可以单独重试不会拖垮整个流程。如果你的资讯量特别大比如每天几百条那可以考虑分批处理每批十到二十条在效率和稳定性之间取平衡。3. 核心节点配置与实操要点每个环节到底怎么设3.1 定时触发器与信息采集节点的配置定时触发器是整个工作流的起点。Coze里可以设置每天固定时间触发我设的是凌晨三点这个时间点网络相对空闲抓取成功率会高一些。触发器的时区要确认清楚默认可能是UTC需要改成你所在的时区否则会出现「明明设了早上八点结果下午才跑」的情况。信息采集我用的是搜索插件加网页抓取插件的组合。搜索插件负责按关键词拉取当天的资讯列表关键词我设了一组包括「AI」「大模型」「智能体」「工作流」等每个关键词取前若干条结果。网页抓取插件负责把搜索结果里的链接打开提取正文内容。这里有个细节要注意搜索插件返回的结果里标题和链接是结构化的但正文需要另外抓。抓取的时候要设置超时时间和重试次数我设的是超时十秒、重试两次。有些站点响应慢不设重试的话会直接丢掉那条内容。{ trigger: { type: schedule, cron: 0 3 * * *, timezone: Asia/Shanghai }, search: { keywords: [AI, 大模型, 智能体, 工作流], limit_per_keyword: 10 }, fetch: { timeout: 10, retry: 2 } }3.2 关键词过滤与去重逻辑的实现采集回来的原始内容里有相当一部分是噪音——广告、旧闻、不相关的技术帖。我用一个代码节点做过滤逻辑分三层。第一层是关键词白名单标题或正文里必须包含至少一个AI相关的核心词。第二层是黑名单包含某些明显不相关的词就直接丢掉。第三层是去重用标题的相似度做判断相似度超过阈值的只保留一条。去重这块我一开始用的是完全匹配结果发现同一件事不同媒体的标题措辞不一样完全匹配根本去不掉。后来改成基于标题的分词加余弦相似度阈值设在0.8左右效果好了很多。代码节点里可以直接写Python用jieba分词加sklearn算相似度跑起来不慢。注意去重阈值不要设太低否则会把不同角度的报道误判为重复也不要设太高否则去重等于没做。0.75到0.85之间是比较稳妥的区间具体值要根据你的信息源特点调。3.3 大模型摘要节点的提示词设计摘要节点是整个工作流里最影响成品质量的一环。我用的提示词经过了好几轮迭代核心思路是让模型做三件事用一句话概括这条资讯的核心事实用两到三句话补充关键细节最后给一句简短的点评或影响分析。提示词里我明确约束了输出格式要求返回JSON包含title、summary、comment三个字段。这样后续组装的时候可以直接取字段不用再做文本解析。另外我加了「如果内容与AI无关返回空」的兜底逻辑防止过滤环节漏掉的噪音进入成品。prompt 你是一名AI行业资讯编辑。请阅读以下内容完成三件事 1. 用一句话概括核心事实不超过50字。 2. 用两到三句话补充关键细节不超过150字。 3. 给出一句简短的点评或影响分析不超过80字。 如果内容与AI行业无关三个字段都返回空字符串。 以JSON格式返回字段为title、summary、comment。 内容 {content} 实测下来这个提示词在多个模型上都能稳定输出结构化结果。如果你的模型对JSON格式支持不好可以在提示词里加一个示例或者用Coze自带的结构化输出功能做约束。3.4 组装发布节点的模板与推送配置组装节点负责把处理好的条目拼成最终的Markdown文档。模板我设计得比较简单开头是一行日期和标题然后是分隔线接着每条资讯用二级标题加摘要加点评的格式排列最后附上来源链接。发布环节我试过几种方式最后选的是推送到一个文档渠道同时保留一份本地存档。推送的时候要注意内容长度限制有些渠道对单条消息的字符数有上限超过会被截断。我的做法是在组装节点里判断总长度超过阈值就自动拆成多条推送。# 每日AI资讯 | {date} --- ## {title} {summary} 点评{comment} 来源[链接]({url}) ---4. 完整实操过程从零跑通第一条资讯4.1 环境准备与工作流创建先在Coze上创建一个新的工作流命名随意我起的是「daily-ai-news」。创建完之后先别急着加节点把工作流的输入输出变量定义好。输入我设了一个date变量默认取当天日期输出设了一个markdown变量用来承接最终成品。然后按顺序添加节点定时触发器、搜索插件、网页抓取插件、代码过滤节点、循环节点、大模型节点、组装节点、发布插件。节点之间的连线要按数据流向连好每个节点的输入要正确引用上游节点的输出。这一步最容易出的问题是变量引用错误。Coze里引用上游输出要用特定的语法写错了节点会报「变量未定义」。我的经验是每加完一个节点就先单独跑一次确认输出正常再往下接不要一口气全连完再调。4.2 单节点调试与联调过程单节点调试是省时间的关键。搜索插件单独跑看返回的结果结构对不对抓取插件单独跑看能不能拿到正文代码节点单独跑喂几条测试数据看过滤逻辑对不对大模型节点单独跑看输出格式稳不稳定。全部单节点跑通之后再做联调。联调的时候先把定时触发器关掉手动触发这样能控制节奏。第一次联调大概率会在某个节点报错看错误信息定位是哪个节点的问题回到单节点模式复现修好再联调。我联调的时候遇到过一个坑循环节点里的变量作用域问题。循环内部的大模型节点引用循环外的变量时有时候会拿不到值。解决办法是把需要的变量通过循环节点的输入参数传进去而不是直接引用外部变量。4.3 参数计算与阈值选择过程工作流里有几个关键参数需要根据实际情况调。第一个是搜索关键词的数量和每个关键词的结果条数。关键词太少会漏信息太多会引入噪音。我最后用了八个关键词每个取十条总共八十条原始结果过滤后大概剩十五到二十条。第二个是去重相似度阈值。我拿一周的历史数据做了测试分别用0.7、0.75、0.8、0.85跑了一遍看保留的条目数和人工判断的重复率。最后定在0.8这个值下重复率低于5%同时没有明显误删。第三个是大模型调用的超时和重试。模型响应时间波动比较大我设的超时是三十秒重试一次。如果两次都失败这条就跳过记录到日志里不影响其他条目。参数取值选择依据关键词数量8个覆盖主要AI子领域噪音可控每词结果数10条总量约80条过滤后15-20条去重阈值0.8重复率低于5%无误删模型超时30秒覆盖95%的响应时间模型重试1次平衡成功率和耗时4.4 发布效果与成品展示第一次完整跑通的时候成品出来我挺意外的——排版比我想象的整齐摘要质量也过得去。当然也有问题比如有几条资讯的点评写得比较空还有一条因为抓取失败导致摘要为空。但整体上一个能用的自动化资讯流水线算是搭起来了。后面我又迭代了几版主要是优化提示词和增加错误处理。现在这个工作流已经连续跑了几个月每天稳定产出十五到二十条资讯偶尔有单条失败但不影响整体。我每天早上花五分钟扫一遍有需要深挖的就点进去看原文效率比手动整理高太多了。5. 常见问题与排查技巧实录5.1 抓取失败与内容为空的排查抓取失败是最常见的问题表现是某条资讯的正文为空导致摘要节点输出空字符串。原因通常有三种目标站点反爬、页面结构变化、网络超时。排查的时候先看抓取节点的日志确认是请求失败还是解析失败。请求失败就检查超时和重试配置解析失败就检查选择器是不是还匹配当前的页面结构。我的应对策略是加一个兜底如果正文抓取为空就用搜索插件返回的摘要字段代替虽然信息量少一些但至少不会开天窗。另外我会定期检查抓取成功率如果某个来源连续失败就把它从采集列表里暂时移除。5.2 大模型输出格式不稳定的处理模型有时候不按JSON格式返回或者在JSON外面包了一层说明文字。这种情况在换模型或者调整提示词之后容易出现。解决办法有两个一是在提示词里加强格式约束明确说「只返回JSON不要任何其他文字」二是在代码节点里加一个解析容错先用正则提取JSON部分提取失败再走兜底逻辑。我还遇到过一次模型把点评写成了摘要的重复内容原因是提示词里对两个字段的区分不够明确。后来我在提示词里加了示例明确摘要讲事实、点评讲影响问题就解决了。5.3 工作流超时与并发限制的应对Coze的工作流有执行时长限制如果节点太多或者某个节点太慢整个工作流会超时中断。我的工作流节点数不算多但循环节点里每条都要调一次模型二十条就是二十次调用累计时间不短。为了控制总时长我把循环改成了并行执行同时限制并发数避免触发平台的频率限制。提示并行执行能显著缩短总时长但并发数不要设太高一般三到五比较稳妥。设太高容易触发限流反而导致更多失败。5.4 常见问题速查表问题现象可能原因排查方向解决办法正文为空抓取失败看抓取日志加兜底、换来源摘要格式乱模型未按格式返回看模型原始输出强化提示词、加解析容错工作流超时节点太多或太慢看各节点耗时改并行、减节点重复内容多去重阈值太低看去重前后对比调高阈值定时不触发时区设置错误看触发器配置改成正确时区5.5 几个我踩过的坑和独家技巧第一个坑是变量命名混乱。工作流一复杂变量名如果不起得清楚过两天自己都看不懂。我的做法是给变量加前缀比如raw_表示原始数据filtered_表示过滤后数据final_表示成品数据一眼就能看出数据处在哪个阶段。第二个坑是忽略日志。Coze的工作流有执行日志但很多人不看。我养成的习惯是每天扫一眼日志看看有没有失败节点、有没有异常输出。很多问题在变成大问题之前日志里已经有苗头了。第三个技巧是保留历史版本。每次大改之前先复制一份工作流改坏了可以回滚。我有一次改提示词把整个流程改崩了幸好有备份五分钟就恢复了。第四个技巧是用小样本测试。改完工作流不要直接跑全量先用三五条测试数据跑一遍确认没问题再放开。这样能省很多等待时间也能更快定位问题。6. 工作流的扩展方向与个人体会这个工作流跑顺之后我陆续加了一些扩展。比如增加了一个「热度评分」节点根据来源权重和关键词命中数给每条资讯打分成品里按分数排序重要的排前面。还加了一个「历史存档」节点把每天的成品存到文档里方便回溯和搜索。另一个扩展方向是做成多平台分发。同一份成品可以适配不同的发布渠道比如文档、邮件、即时通讯工具。每个渠道的格式要求不一样但核心内容是一样的只需要在组装节点里加分支逻辑。我还试过把这个工作流的思路迁移到其他场景比如技术博客的选题聚合、竞品动态监控、行业报告素材收集。核心逻辑是一样的采集、过滤、摘要、组装、发布。换的只是信息源和提示词。说实话搭这个工作流最大的收获不是省了多少时间而是让我对「自动化」这件事有了更实际的理解。自动化不是一键搞定而是把重复劳动拆成可管理的环节每个环节做到足够稳整体才能稳。中间那些调试、报错、重试的过程才是真正长经验的地方。如果你也想搭一个类似的工作流我的建议是从最小的闭环开始——先跑通一条资讯的采集到发布再逐步加来源、加过滤、加摘要。不要一上来就追求大而全那样很容易在调试阶段就放弃。先把一条跑通后面的扩展都是水到渠成的事。
