企业官网建设流程全解析

1. 这个智能体到底解决什么问题

1.1 一个真实的痛点：信息过载

我在实际做这个项目之前，每天早上的固定动作是这样的：先打开十几个新闻客户端和公众号，快速扫一遍标题，点开三五篇觉得相关的，然后发现已经过去了四十分钟，真正值得读的内容却没过几篇。更要命的是，很多信息是重复的，同一条新闻换个标题换个平台，会以七八种姿态出现在你面前。那种感觉就像每天早上站在一个堆满报纸的房间里，明明只是想看一眼天气预报，却被迫把整摞报纸都翻开。

这就是“每日AI简报”智能体最原始的出发点：把每天早上刷信息的四十分钟，压缩成“两分钟读一份简报”。我需要的不是一个能聊天的机器人，而是一个能自动完成“找信息、筛信息、整理信息、按时投递”的助手。而这件事，用手工或传统脚本都能做，但接手之后你会发现，最麻烦的不是采集，也不是定时，而是“怎么判断哪些内容值得看”和“怎么把内容组织成人话”。

这个需求特别适合做成智能体，因为它的核心不是“跑流程”，而是“做判断”。在过去的自动化方案里，判断逻辑得靠人写死，规则改一次就折腾一次；而换成以LLM为大脑的智能体之后，判断逻辑可以用自然语言描述，改起来快，适应能力也强得多。

文章后面会带你完整走一遍搭建过程，从画流程图开始，到手把手配置每一个节点，再到发布上线，最后分享一批我在实际运行中踩过的坑。无论你是想入门智能体开发，还是已经在平台上做了几个简单机器人，想试试“定时任务+内容处理”这类真实场景，这篇都能给你一套可以直接抄作业的路径。

1.2 为什么选智能体而不是传统脚本

很多人第一反应是：这个需求用Python脚本不也能做吗？定时请求RSS、用正则或规则筛关键词、拼一个文本文件、再用消息接口推给自己，听起来完全可行。

确实可行，但有个很实际的问题：内容筛选和摘要整理这件事，规则很难写得好。举个例子，你想筛“AI行业值得关注的新闻”，如果用关键词匹配，你可能会写上“AI、大模型、智能体、万卡、DPI”这些词，但结果要么漏掉某些没有命中关键词但确实重要的资讯，要么混进来一堆蹭概念的营销稿。你每天都要维护这套规则，今天加了新词，明天又要排除旧词，规则越攒越复杂，最终变成一个谁也改不动的大泥球。

智能体的思路完全不同。它把“理解内容”这件事交给了LLM，用一段Prompt就能描述什么叫“值得关注”：比如“与AI大模型落地应用相关、有具体产品或数据支撑、不是软文”。模型会基于语义去筛选，而不是机械地匹配字符。最核心的变化是：从“穷举规则”变成了“描述意图”。前者需要你预判一切可能性，后者只需要你说清楚自己要什么。

所以这个项目里，智能体并不只是一个营销概念，它是真正解决“传统脚本无法优雅处理语义判断”这个问题的载体。

1.3 为什么选Coze这类智能体开发平台

做智能体，你可以选开源框架自己搭，也可以选现成的智能体开发平台。对于绝大多数场景，我的建议是先上平台。原因是：搭工作流、配模型、调试、发布、定时调度、消息推送这些脏活累活，平台都帮你封装好了，你只需要把精力花在业务逻辑上。

这篇文章选用Coze（扣子）做演示，主要基于几个很实在的理由：

• 可视化的工作流画布，节点拖一拖就能连起来，新手不用写代码就能做出第一版。
• 内置了大量插件和工具，信息采集、发送消息等常用能力开箱即用。
• 定时触发做得完整，能直接挂在具体时间或Cron表达式上，不用自己写调度服务。
• 发布渠道覆盖了主流IM和邮件，做好之后能很方便地推送到日常使用的工具里。
• 免费额度对个人项目足够友好，前期跑通原型基本不用纠结成本。

当然，这套设计思路并不绑定特定平台。就算你用的是其他智能体开发工具，核心的节点拆分、Prompt设计、token成本控制、兜底逻辑这些方法论都是通用的。这也是我写这篇文章时的原则：不是教你怎么点按钮，而是讲清楚每一步背后的思考，让你迁移到任何平台都心里有底。

2. 整体设计：把一个需求拆成一张流程图

2.1 先画流程图再动手

我见过太多人第一次做智能体，打开画布就开始拖节点，拖到一半发现逻辑乱了，再全部删掉重来。白白浪费很多时间。

正确做法是先别打开平台，拿张纸或者随便一个绘图工具，把“数据怎么流动”画出来。哪怕画得很粗糙，只要能表达清楚“从哪儿来、经过谁处理、到哪儿去”就行。

我这个“每日AI简报”的需求，拆开之后非常规整：

• 先从信息源拉取内容。
• 然后把内容做一次预筛选，去掉明显无关的。
• 再对剩下的内容做摘要和整理。
• 最后格式化成一遍清爽的简报，推送给自己。

这个流程画成图就是一条直线：触发 → 采集 → 筛选 → 总结 → 格式化 → 推送。你觉得它像不像一条流水线？每往前一步，数据量都会缩小，数据质量都会提升。最开始的100条资讯，筛选完可能剩15条，总结完变成15段话，格式化后变成一页能看完的简报。

在设计阶段，你唯一要关心的就是这条线能不能走通。至于某个节点的细节怎么处理、某个字段叫什么，那是后面的事情。先把骨架立起来，再填血肉。

2.2 节点选型与输入输出接口设计

当把流程图落成平台上的工作流时，每个环节都要选一种节点类型。我建议不要一开始就贪多，先用一套最简单的组合跑通全流程，再逐步替换成更复杂的方案。

我第一版用的节点组合是这样的：

这里有个非常关键的设计原则：每个节点的输入和输出边界要尽量清晰。不要把筛选和总结塞进同一个LLM节点里，这会让后续调试变得很痛苦。为什么？因为一旦输出结果不符合预期，你就得去改一个特别长的Prompt。如果目标不明确，是筛选做错了还是总结做错了？你根本分不清。拆成独立节点之后，单独测试“筛选”节点，再单独测试“总结”节点，问题立刻定位。

另外还要注意节点之间的数据传递。平台里上游节点的输出会被当成下游节点的输入变量，变量名如果不统一，下游引用就会报错。我的习惯是给每个节点起一个能表达含义的名字，比如“筛选节点”“生成摘要节点”，这样找变量名时一眼就能对应上。

2.3 一个关键的设计决策：筛选先于总结

在设计流程时，你会遇到一个选择：是先让LLM筛选出值得看的条目，再对筛选结果做摘要，还是先把所有内容都做摘要，再筛选？

我的答案是：筛选必须先于总结，而且优先级非常高。

原因有两个。第一个是成本问题。一个RSS源一天可能有三五十条内容，每条摘要可能两三百字，如果全部送进LLM做摘要，消耗的token会大得多。先筛选就能把送入总结环节的内容控制在10条以内，成本能省下一个数量级。第二个是质量问题。先总结再筛选的话，“不值得看”的内容也会被认真整理一遍，相当于花钱把垃圾加工成了看起来还不错的垃圾，后面的筛选环节反而更难看清楚哪些是真正重要的。

这里可以用一个生活里的类比来解释：筛选相当于HR筛简历，总结相当于安排面试。你总不会把每个投简历的人都拉来面试一遍，然后再决定要不要淘汰吧？一定是先筛掉最不匹配的，再安排精力和最好的候选人深聊。

所以，“先筛后总结”这个顺序，既是成本决策，也是质量决策。内容经过这一步设计，整个工作流的效率和输出质量就有了基本保障。

3. 实操：从创建智能体到跑通第一版

3.1 创建智能体前的准备工作

实操之前，有几项准备工作做得好，后面会省很多事。

第一，想清楚你的简报要覆盖什么主题。我建议第一个版本先收窄范围，比如“AI行业动态”或“科技圈重要新闻”，越具体越好。范围窄，筛选Prompt就好写，输出质量也更容易保证。不要一上来就做“每日全网热点”，那不叫简报，那叫信息轰炸。

第二，准备两个信息源。一个主源，一个备用源。RSS源仍然是效率很高的选择，很多科技博客和新闻站还提供RSS订阅。你可以准备两到三个站点，作为后续测试和调优的固定输入。不用贪多，质量好的少而精，比一大堆低频更新的源强得多。

第三，确定简报的输出格式。我强烈建议先用“纯文本结构化模板”，而不是富文本或卡片。原因很简单：纯文本在调试阶段最容易看清问题，也最容易在代码节点里做字符串处理。等逻辑完全跑通了，你再升级成更美观的消息卡片也不迟。

第四，创建一个专门的测试渠道。不要一开始就把简报推送给你日常重度使用的渠道，否则调试过程中产生的错误消息和测试垃圾，会把你自己的工作环境搞得一团糟。单独拉一个测试群或测试会话，跑通之后再改到正式渠道。

3.2 搭建第一个简单工作流

接下来就是正题了，我把第一版从建智能体到跑通的步骤写一遍，你可以照着做。因为平台界面会不停地更新，按钮的位置可能有变化，但核心逻辑不会变。

第一步，创建智能体。进入Coze（扣子）平台，新建一个智能体，填一个名字，比如“每日AI简报”，描述里说明它的用途，保存之后会进入智能体的编排页面。这个时候不要急着加人设和知识库，先切到“工作流”标签页。

第二步，添加定时触发节点。在这个节点里，你可以配置触发时间。第一版测试时我建议不要设每天1次，而是先设为“每15分钟执行一次”，这样你改动完配置，不用等第二天就能看到效果。等全部调试完毕，再改回每天固定时间。定时触发节点一般支持两种配置方式：直接选择固定时间和分钟间隔，或者写Cron表达式。如果你需要每天早8点执行，Cron表达式可以写成0 8 * * *。

第三步，添加“获取RSS”节点。第一版我建议直接用平台内置的RSS解析插件来拉取，这样能把XML解析成结构化的列表，省去自己写的麻烦。配置时把你准备的RSS地址填进去，设置一个拉取条数上限，比如15条。为什么是15条而不是所有？一是控制token成本，二是真正值得看的往往就这么几条，把前15条先拉下来足够用了。

第四步，添加“筛选”LLM节点。这是整个工作流的大脑。节点的输入接收上一步的内容列表，然后执行你写的筛选Prompt。为了不让模型输出太飘，我会把筛选的任务限制成“只输出一个JSON数组”。具体Prompt我放在下一节详细讲。

第五步，添加“生成摘要”LLM节点。把筛选出来的结果喂给它，让它逐条生成摘要。摘要要控制字数，每条50字以内，目标是“看完一句话就知道这条新闻值不值得点开”。如果源是英文，就在摘要节点里同时加一个“翻译”要求，让它直接输出中文摘要。这样能省一个独立的翻译节点。

第六步，添加“格式化”代码节点。前面几个节点输出的都是JSON之类的结构化数据，到了这一步要拼接成人类真正会读的简报文本。不要小看这一步，如果直接把LLM的输出扔给用户看，排版会非常糟糕。我会写一个简短的脚本，把标题、摘要、来源、链接整理成带编号的文本。具体脚本代码可以自己写，核心逻辑就是遍历摘要列表，拼字符串，加上日期和分隔线。

第七步，添加“发送消息”节点。把格式化节点输出的文本发送到你的测试渠道。配置时要填Webhook地址或Token，平台一般会有引导。

第八步，点击“试运行”或“测试”，手工触发一次流程，观察各节点输出。如果从“生成摘要”节点开始就发现数据不对，那就是筛选Prompt或上游数据解析出了问题。建议逐个节点检查输出，直到整个链路全通。

这里有一个很重要的心态：第一版不要追求完美。你可能发现筛选漏了几条好内容，也可能发现摘要质量不够高，这些都非常正常。第一版的目标只是“跑通”，先把数据从源头送到你的消息渠道里，看到一条完整的简报出现在手机里，就已经成功一半了。

3.3 写Prompt的四个要点

智能体的质量，很大程度取决于Prompt的质量。我写筛选节点和摘要节点Prompt时，会遵循下面这四个原则，你可以直接复用。

第一个原则：给模型一个明确的角色。不要只说“帮我筛新闻”，而是让模型进入一个角色。比如：“你是一位资深科技编辑，负责为一位关注AI行业的读者筛选每日必读资讯。”角色设定看起来是虚的，但它会显著影响模型的输出风格和判断尺度。角色越具体，输出越稳。

第二个原则：把输入格式描述清楚。RSS解析出来的内容不是纯文本，而是包含标题、链接、描述等字段的结构化数据。模型如果不认识这个结构，就容易瞎猜。所以我会在Prompt里写：“以下是今日资讯列表，每条包含title、link、description字段。请基于title和description判断该条内容是否值得收录。”

第三个原则：严格定义输出格式。这是最容易被忽略，也最容易出问题的一点。LLM如果没有被强制约束输出格式，它会自由发挥，插入各种解释和客套话。为了后续处理方便，我会要求输出纯JSON数组，并且给一个格式示例。与此同时还要加一句“只输出JSON，不要输出任何解释文字”。

第四个原则：一个节点只干一件事。筛选节点就只做筛选，摘要节点就只做摘要。不要在筛选Prompt里写“顺便给个摘要”，也不要在摘要Prompt里写“顺便判断一下这个新闻重不重要”。混在一起，一旦输出有偏差，你根本定位不了是哪一步的问题。

下面是我“筛选”节点用的一段Prompt，你可以参考：

你是一位资深科技编辑，负责为关注AI行业的读者筛选每日必读资讯。 以下是今日资讯列表，每条包含title、link、description字段。 请判断每条资讯是否满足以下收录标准： 1. 内容与人工智能、大模型、智能体等主题直接相关。 2. 涉及具体产品、公司动态、研究成果或行业数据，而非空泛的观点文。 3. 内容不是广告、活动推广或明显的营销软文。 只输出JSON数组，数组中的每个对象包含： {"index": 序号, "title": 原标题, "reason": "收录原因，20字以内"} 如果没有符合条件的内容，输出空数组 []。 不要输出任何JSON以外的文字。

下面是我“摘要”节点用的Prompt：

你是简报编辑。下面是一条科技新闻的标题和描述。 请用中文生成一段不超过50字的摘要，要求： 1. 先说最核心的信息（谁做了什么，或发生了什么）。 2. 再说为什么这件事值得关注。 3. 语气客观，不要发表个人观点。 输出格式： 【摘要】摘要内容 标题：{TITLE} 描述：{DESCRIPTION}

这些Prompt不需要一次写对。实测中你会发现，第一次生成的输出可能不符合预期，这不奇怪。我的做法是调完Prompt后反复测试同一个节点，直到输出的格式和内容都稳定，再继续往下走。

3.4 token用量与成本估算

很多人用智能体开发平台，一开始最关心的不是效果，而是“会不会很费钱”。这个想法非常实际。我帮你算一笔账，心里就有谱了。

以我的“每日AI简报”为例，假设一个RSS源每次拉取15条资讯，每条description平均150字。那就是大概2250字的中文输入。我们按每个汉字约1.5个token估算，大概是3400个token。筛选节点的输出是一个较短JSON数组，假设收录了8条，大约500个token。筛选节点每次运行的总token构成是：3400的输入加上500的输出，也就是3900个token左右。

接下来是摘要节点。它只接收筛选出来的8条，每条输入按200字算，1600字，约2400个token。输出8条摘要，每条按60字算，480字，约720个token。合计约3120个token。

两个节点的总和是7000个token上下。如果每天执行1次，一个月就是21万个token。在平台的免费额度里，这个量级对个人项目来说是完全够用的。即使考虑偶尔的异常重试、多几个源，把量翻一倍，一个月也就40万到50万token，依然处在非常可控的范围内。

但是，如果你犯了一个典型的错误，成本就会快速上升。什么错误？把全部15条甚至50条原始内容一股脑塞进摘要节点，而不是先做筛选。假设50条都去生成摘要，一个月的token消耗直接奔着百万级去了。这就是为什么我反复强调筛选前置的原因——它不是锦上添花，而是成本控制的关键。

控制成本的另外两个小技巧：一是在采集节点设置条数上限，不要无脑拉取全部；二是在LLM节点的设置里加上输出token上限，限制单次回复长度。这样就算模型出现异常，单次消耗也不会失控。

3.5 发布与定时调度的细节

工作流跑通之后，接下来就是把智能体发布出去，让它真正每天自动运行。

发布的第一步，是确认推送渠道。你在工作流里配置的“发送消息”节点，会有一个对应的Webhook地址或者消息接口，这个通常是发布动作的前提。平台里发布智能体和发布工作流通常是绑定的，你只需要跟着引导走，选择发布成“Bot”或者“应用”，然后选择目标渠道里的测试会话。

这里有一个我踩过的坑：有些渠道的机器人需要先“添加”到目标会话或群里，否则即使发布成功，消息也推不过去。我第一版搭建时，发布完成后怎么等都不见消息，最后发现是根本没有把机器人添加到接收消息的那个群里。这个步骤在平台引导里可能被弱化，实操时务必检查一遍。

再说定时调度。前面测试时你可能把触发间隔设成了15分钟，跑通了要改成真正的计划。如果不想用Cron表达式，平台一般也支持直接选“每天几点执行”。我建议用Cron，因为将来你想改成“周一到周五”“早上8点加下午6点”这种复杂计划，Cron都覆盖得了。以每天早8点为例，Cron是0 8 * * *；如果只要工作日执行，就是0 8 * * 1-5。

还要留意时区问题。如果你在一个时区配置了定时任务，但平台服务器用的默认时区不一致，执行时间就很可能不是你预想的8点。建议在配置界面找到时区设置，确认是东八区，再修改执行时间。

最后，发布成功之后，一定要做一次“真实环境验证”：直接等下一个定时节点触发，确认消息真的从“定时任务”而不是“手动测试”到达了你的手机。只有这一步验证通过，才能算真正落地。

4. 进阶：让简报“更像人做的”

4.1 让筛选更有品味：多源输入与黑名单

第一版能跑起来之后，你会很快发现一个问题：内容来源太单一了，看几天就腻了。这时候就需要做“多源输入”。

多源输入不是简单地把好几个RSS源塞进采集节点，而是要考虑去重和合并。同一个热点事件常常会出现在多个源里，如果不去重，简报里就会出现三篇高度相似的新闻，看起来非常蠢。去重逻辑可以放在代码节点里：按标题去重，或者按标题相似度去重。简单一点的做法是，先把所有条目合并到一个列表，然后让LLM筛选节点顺带去重，在Prompt里加一句“如果两条内容主题高度重复，只保留信息更完整的一条”。

另一个能显著提升质量的小机制是“黑名单”。有些源定期会混入一些推广文、软文、标题党，明明和主题无关却靠蹭词混进了收录范围。与其不断修改筛选Prompt里的标准，不如维护一个简单的黑名单列表，放到代码节点里做硬过滤。黑名单可以包含两类名单：一类是关键词黑名单，比如“免费领取”“限时秒杀”“点击购买”；另一类是来源黑名单，比如某些广告频发的站点，直接整个过滤掉。代码节点里一句简单的includes判断，就能挡掉一大批垃圾内容。

我还推荐一个进阶玩法：“置信度评分”。让筛选节点不只是返回“收录/不收”，而是给每条内容按0到10打分，并输出打分理由。你在代码节点里设定一个阈值，比如7分以上必须收录，5到7分先放行，5分以下直接丢弃。这样做的最大好处是，生成摘要节点永远只会收到质量相对高的内容，简报的整体品味会稳定很多。

4.2 让摘要更像人写的：结构化模板与独立观点

机器生成的摘要最大的问题不是“不准”，而是“无趣”。它会把每个新闻都写成“某公司发布了某产品，这一举措标志着……”这种标准句式，读起来像说明书。要解决这个问题，光靠改Prompt还不够，我后来是给摘要定义了一个“模板结构”，这才让简报有了自己的味道。

我的摘要模板包含三个字段：核心信息、为什么值得关注、一句话点评。前两个字段负责事实部分，第三个字段是关键——它是给LLM留出的“观点空间”。你在Prompt里改成：输出格式为“核心信息：…；为什么值得关注：…；编辑点评：…”，点评要求“站在读者角度，用一句话指出这条信息对普通人的影响”。

加上点评之后，简报读起来就有了立场和温度，像一个真的读过这些新闻的人在给你翻译和划重点，而不是冷冰冰的消息汇总。这一步改造完成后，我自己阅读简报的意愿大大提升了——以前点开是扫一眼，现在真的会认真读完。

如果信息源是英文，摘要节点里还需要处理“本地化”。不要简单地在Prompt里写“翻译成中文”，这样输出的语言容易生硬。更好的说法是：“请用中文转述这条新闻，不要逐句翻译，要把关键术语和背景用中文读者能理解的方式表达出来。”转述和翻译的区别很大，转述要求理解后重写，输出质量会高一大截。

4.3 扩展：多渠道推送与“速读/深度”双模式

等单渠道跑稳了，你可以把工作流复制一份，改一下发送节点，推送到自己的另一个常用渠道。也可以不复制，直接在推送节点里配置多个目标地址，一次性群发。不过我更推荐后者，理由很简单：只维护一份工作流，后续修改逻辑时不用同步多个副本，省心很多。

另一个很值得做的扩展是“速读/深度”双模式。思路是：同一个采集和筛选流程生成的摘要，分成两种输出格式。速读版只保留核心信息和一句话点评，每条不超过两行，适合早上刷牙时快速扫；深度版则增加原始链接、完整描述和编辑点评，适合午休时间点开细读。这个可以在格式化节点里做一个“模式”参数，在运行时控制输出哪种版本。

我自己用下来最舒服的模式是：速读版每天早晨推送，深度版只在周末推送一次，做个“本周值得关注”。这个模式也适合那些不想天天被打扰的用户——每周只读一次深度总结，既有密度又没负担。

最后提醒一句：你的RSS源不会永远稳定。网站改版、RSS地址失效、内容质量下滑，这些都是常态。我一度三个月没管，突然发现好几天没收到简报，一查才发现其中一个源已经在某次改版后失效了。所以每个季度腾出半小时，检查一下所有源是否正常，该换的换，该删的删。这个维护成本很低，但对简报的长期稳定性来说价值极大。

5. 常见问题与排错实录

5.1 触发成功了但没收到消息

这种情况在第一次搭建时非常常见。工作流显示执行成功，但手机就是没收到简报，排查思路如下。

第一步，确认发送节点真的执行了。在工作流的执行日志里，找到发送节点，看它的运行状态和返回信息。如果返回信息里有“ok”或“success”字样，说明消息已经推给了目标渠道，问题大概率出在“目标渠道没把消息展示给你”。

第二步，确认机器人是否被添加到了你的会话里。很多IM需要先执行“添加机器人”或“邀请入群”操作，才允许机器人发消息。这是新手最容易漏掉的一步。

第三步，如果发送节点返回错误信息，那就把错误信息复制出来，多看几个关键词。有些是Webhook地址失效，有些是消息体格式不对。直接根据报错词去查，比乱猜高效得多。

5.2 LLM输出不是合法JSON

LLM输出格式不稳定，是做智能体时最经典的坑。你明明在Prompt里说了“只输出JSON”，它也回复了JSON，但JSON里可能夹了解释文字、缺少逗号、或者一个字符串里的引号没转义。一旦下游代码节点用JSON.parse（或json.loads）解析，直接就报错。

我的处理方案有三层：

第一层，在Prompt里提供格式示例并明确禁止多余输出，这个前面已经讲过，能解决八成问题。

第二层，在代码节点里做“宽容解析”。不要直接用严格模式，先尝试反序列化，如果失败，就从返回文本中裁出第一对“[]”或“{}”再试，因为LLM即使夹杂了废话，结构化部分通常也是完整存在的。

第三层，设置LLM的温度参数（temperature）到0.2以下。温度越低，模型输出越保守稳定，虽然创造性降低，但对于输出JSON这种强规则任务，稳定性远重要于创造性。

我建议把这个防御链设计成：宽容解析失败时，走一个“降级分支”。降级分支里不再要求JSON，直接让另一条Prompt返回纯文本摘要，然后整个简报用纯文本发送，保证“有输出总比没输出好”。

5.3 token用量涨得太快

如果你的月用量比预期高很多，先从这几点排查。

一是采集节点是否拉取了过多条目。很多人默认拉50条，但真正会被收录的可能只有8条，你就为另外42条数据白白付了筛选节点的输入token。控制拉取条数是最直接的节流手段。

二是是否在每个LLM节点带上了大段说明文字。Prompt本身也会算入输入token，如果每个节点前面都啰嗦了一大段，累计下来也是不少消耗。Prompt要写得精炼，把约束条件合并成一条分号分隔的句子，而不是铺成长篇。

三是代码节点是否有重复调用LLM的逻辑。某些初学用户会因为“想处理得更细”，在代码节点内又去请求模型接口，这会让每次运行额外增加固定的隐性消耗。务必检查节点日志中的token统计，定位耗量最多的节点。

5.4 下游节点报“字段不存在”

工作流里类似“找不到参数title”“变量is_null”之类的错误，根源几乎都在上下游数据格式不匹配。

最常见的场景是：筛选节点输出的JSON格式，和你预期的不一样。你以为输出的字段名是title，但模型实际返回的是newsTitle。解决这个问题的标准姿势是：把筛选节点先运行一次，把它的真实输出贴到代码节点里，仔细看字段名是什么。然后按照真实输出修改代码，不要靠猜。

其次是大小写问题。字段名是Title还是title，模型输出往往不稳定。如果你用代码节点读取字段，建议做一层容错：按多种大小写形式逐个尝试取值，取的第一个值就作为最终结果。这个技巧能省掉很多不必要的调试时间。

5.5 常见问题速查表

下面把我在实际使用中遇到的典型问题汇总成表，方便你遇到同类问题时快速定位：

5.6 一个调试的小习惯：先测节点再测流程

最后分享一个我调试智能体的小习惯。很多初学者喜欢整个工作流一起试运行，然后看总输出，发现不对了再从头猜问题出在哪。这个方法效率极低，因为任何一个中间节点的偏差都可能造成最终输出异常。

我的做法是：只选某一个节点单独测试。平台基本都支持“运行到当前节点”或“单独运行节点”。先把采集节点跑一遍，看拉回来的数据结构对不对；确认没问题，再单独跑筛选节点，检查输出JSON是否符合预期；再单独跑摘要节点，检查文案质量。只有每个节点都稳了，才把整条工作流串起来做整体测试。

这个习惯听起来很不起眼，但能帮你把调试时间压缩到原来的三分之一。尤其是当LLM节点出现“有时好有时坏”这种诡异问题时，分步测试能让你快速确认问题到底出在“Prompt写得不稳”还是“上游数据格式变化”上。

一个小经验

这个“每日AI简报”智能体，我从搭建到现在跑了大几个月，中间改过好几次。最大的体会是：不要把第一版想得太完美，先让它跑起来，再让它变好。

你甚至可以故意把第一版做得“笨”一点：只用一个信息源、不做去重、不做打分、摘要就是简单的三五句话。就是这样一版简陋的东西，已经能让你每天早上节省二十分钟。然后你再根据自己的真实感受一步步加能力——想要内容更多就加源，想要筛选更准就做打分，想要简报更像人写的就加编辑点评。这个过程里，你是在“使用中改进”，而不是“想象中设计”，改出来的东西会扎实得多。

如果你想让这个智能体走得更远，我建议你上一个工作日定时的工作日简报，周末另做一份周末综合版。这样既有日常的信息密度，又有周复盘的信息深度，周一到周五每天早上看一眼速读版，周末抽十分钟细读深度版，信息摄入结构就健康很多了。