n8n+AI Agent+Grist：构建Hacker News信息流自动化工作流

1. 先把需求讲清楚：为什么要把 Hacker News 和 Grist 交给一个智能体管

最近在折腾信息流自动化，发现每天花大量时间刷 Hacker News 找技术选题、看热门讨论，效率实在太低了。后来把 n8n、Grist 和 AI Agent 串在一起，做了一个能自动盯 HN 热点、用智能体过滤噪声、最后把结果落到 Grist 表格里的小系统，实测跑了几周，稳定度和可维护性都超出预期。这篇文章就把整个搭建过程、踩坑点和能直接抄走的配置方案完整写出来。

先说清楚这套东西解决什么问题：Hacker News 是技术圈最活跃的信息源之一，但信息噪声也大，帖子质量参差不齐；Grist 是一个“电子表格外壳 + 数据库内核”的存储工具，比传统表格更适合承载结构化数据；n8n 则是把这一切串起来的自动化引擎。三者组合之后，你每天只需要打开一张 Grist 表，就能看到智能体帮你筛选好的 HN 热门内容、带上摘要和分类标签，甚至自动生成一封早报邮件。适合谁参考？正在做内容运营、技术情报收集、或者想用低代码方式搭 AI Agent 工作流的开发者都适用。就算之前没用过 n8n，跟着这篇文章把节点逻辑搞明白，也能在自己的项目里复刻出一套链路。

为什么我不建议直接用脚本定时抓 HN API 然后丢进数据库？因为脚本方案有两个痛点：一是接口返回的原始数据虽然干净，但“哪些内容值得关注”这个判断逻辑每星期都在变，每改一次规则就要动代码；二是人工判断通常没时间逐条做分类和摘要，就算做一次，后面也会断更。n8n 加智能体的方式恰好把这两件事解耦：抓取、过滤、存储、通知每一步都是一个可视化节点，改逻辑不用动代码；AI Agent 负责最花时间的分类、摘要和打分，人只需要在 Grist 里对结果做 final review。这个思路本身，才是这套方案的核心价值。

2. 整体设计：把“数据入口—智能处理—存储落库”三段拆开

2.1 三段式流程：抓取、分析、存储各司其职

我习惯把这套系统拆成三个清晰阶段：Hacker News 节点负责拉原始数据，AI Agent 节点负责阅读理解与判断，Grist 节点负责结构化落地。每两个阶段之间用一个轻量的数据变换节点（比如 Code 节点或 JSON 转换节点）做字段整理，避免上游原始字段太野冲击下游节点。整体结构就是一个链式工作流，没有复杂的并行分支，非常适合第一次上手的人理解。

这么拆的好处很多。首先，每个阶段都能单独测试。比如你怀疑 Hacker News 节点拿到的字段是空的，可以直接在它后面拖一个只看结果的节点运行一次，不需要跑完整链路。其次，智能体节点在整个链路里处于正中间，它的输入是已经清洗过的字段数组，输出是你约定好的 JSON 格式，相当于一个“人肉标注员”的角色，把非结构化的英文帖子标题、链接、分数变成带分类、带摘要、带推荐评分的中文结构化内容。存储节点只认结构化数据，所以整个流程的风险点被天然隔开了——抓取失败不会影响存储，存储失败不会污染智能体缓存。

为了后面排查方便，我还会在每一个大节点之间加上一个仅 log 的 Set 节点，把传入数据的长度打出来。n8n 的执行日志在 Debug 视图里能看到每个节点的输入输出，所以这个 log 不一定非得存库，但加一个不坏事——尤其当你面对几百条帖子数据批量过智能体时，知道“在哪一步丢了数据”远比猜重要得多。

2.2 为什么选 Grist：不是电子表格，也不是重型数据库

Grist 这个选型可能有人不太熟。它从外观上看像 Airtable 或者 Excel 的某种升级版，但内部模型更接近 SQL 数据库：每一列都有严格的类型约束，表与表之间可以用引用列做关联，官方 API 对开发者非常友好。对于 n8n 来说，Grist 节点操作成本远低于直接写 SQL 查询，也远低于在 Google Sheets 里处理字段类型混乱的问题。

我之前用过 Google Sheets 当存储端，遇到最大的坑是列类型太“自动”了。你好不容易通过 n8n 把一个 score 数字写进去，Sheets 有可能把它变成浮点数，而且因为连接方式用的是 Sheets 节点，它对每一列的类型控制非常弱。反过来，如果上 PostgreSQL，存储能力没问题，但每次都要维护连接串、处理 JSON 字段类型，对只是想存一批帖子清单的轻量场景来说有点过度。Grist 正好卡在中间：它有数据库级别的结构约束，但交互是表格式的，操作界面一目了然，n8n 的 Grist 节点直接支持创建记录、更新记录、删除记录和查询记录，把鼠标点一点就能完成 CRUD。

另外一点是权限控制。Grist 可以给不同的用户分配查看者、编辑者、所有者权限，这意味着你可以把这张表直接分享给团队成员，让他们在浏览器里看每日 HN 精选，而设备端不用部署任何东西。和我合作的一个内容团队就是这样：我负责通过 n8n 自动化写数据，他们只读 Grist 的“精选视图”，用 Grist 自带的分组功能按分类浏览，全程没有经过我手动导出任何文件。

2.3 工具选型的心得：不要把 Agent 用成“瑞士军刀”

虽然标题里写了“智能体开发”，但我严格限制了 AI Agent 的职责范围。有不少人一开始会想：既然有 Agent 了，干脆让它直接去抓网页、调用 HN API、自己决定存哪里。这是最容易翻车的思路。AI Agent 的本质是推理和生成，不是稳定执行引擎；如果你让它自己决定如何抓取数据，一次模型输出的 API 参数格式变了，整个工作流就断了。我的原则是一一“确定性的活交给节点，不确定性的活交给 Agent”。

所以实际链路里，Hacker News 节点和 Grist 节点都是确定性的，AI Agent 只做三件事：从批量数据里提炼主题、给每条内容打标签、输出推荐理由和评分。这样即使 Agent 偶尔犯错，也不会影响数据源和存储端，最多就是某个分类标签不够准确，手动在表里改一下就行。把不可控范围压到最小，这算是自动化项目里最重要的经验之一。

3. Hacker News 节点：数据入口的每一种参数都要摸透

3.1 节点能拿到的数据范围

n8n 的 Hacker News 节点（完整名称是 Hacker News，官方集成里自带）并不是在 n8n 里面内置一个抓包器，而是封装了 HN 的官方 API，通过后台请求 JSON 接口再在节点内部把数据整理成统一结构。所以它能够获取的内容边界，就是 HN API 提供的能力边界。简单说，它支持拉取几个主流的时间流：最新帖子、热门帖子、最佳帖子、Ask HN 和 Show HN，同时也支持根据单个帖子 ID 获取帖子的详情和评论。

这里需要提一个常见的误区：很多人第一次看到 Hacker News 节点，以为它能像抓取器一样输入一个关键词搜索所有文章。其实它本质上是一个“时间流拉取器”，并没有提供全文搜索参数。如果你真的想按关键词过滤，建议在节点后面加一个 Code 节点做本地过滤，或者把标题、摘要数据交给 AI Agent 让它来决定是否保留。我自己的做法是：先用节点把最近 90 条热门帖子拉下来，然后在后置 Code 节点里按几个硬性关键词（比如 AI、LLM、database、langchain 等）做第一轮粗略过滤，把候选集压缩到 20 到 30 条，再交给 Agent 处理。这一步能显著降低 Agent 的 token 消耗，每天的运行成本低到可以忽略。

3.2 参数设置的实操建议

Hacker News 节点支持的操作类型（Resource 和 Operation）非常直观，我把常用组合列在下面，方便你对照配置：

• Operation 选 Get All Posts，可以拉时间流内的帖子列表；
• Operation 选 Get Post，需要输入单个帖子 ID，用于获取特定条目；
• Operation 选 Get Comments，输入帖子 ID 后拿评论，适合想做舆情分析或深度讨论挖掘的场景。

在 Get All Posts 模式下，有一个大分类参数叫 Category：可选 best、new、top、ask、show 和 job。我建议根据自己的业务场景选。做技术热点监控选 top 或者 best 最合适，因为这两个类别代表当前关注度高、分值高的内容；做创业观察可以叠加 show；做问答社区跟踪就选 ask。注意一个小坑：job 类别是招聘帖，语义分析场景下会污染数据，除非你专门做招聘信息聚合，否则别选它。

还有一个参数容易被忽略，就是这个节点内部其实没有直接的“返回条数”字段，而是在其他参数（Limit）里控制返回数量。我第一次用的时候只看到有“数量限制”藏在参数折叠区，没展开就默认跑了，结果一次性拿回了 90 条，反而让后面 Agent 的压力变大。现在我的配置是这样：Category 选 top，Limit 设 30，然后节点返回的每条记录都包含 title、url、points、author、time、commentCount 等字段，基本够用。如果你需要更多数据，可以对这个节点做分页处理，n8n 内建支持翻页选项，或者你用 Loop 节点循环翻页，把多次请求的结果汇一处再往下传。

3.3 字段清洗与去重

HN 接口返回的字段相对稳定，但有几个问题必须提前处理。第一个是 time 字段是 Unix 时间戳，你写入 Grist 时要用日期类型，n8n 的转换表达式可以直接用{{ $fromUnix($json.time) }}这种写法转成标准日期。我习惯直接转成带时区的 ISO 字符串，这样在 Grist 里排序时才不会十点八点乱跳。第二个是 url 字段，部分帖子没有外链（比如纯 Ask HN 文本帖），url 字段会缺失，后面智能体判断“原文链接”时可能收到空值，我在清洗节点里会统一补一个默认值https://news.ycombinator.com/item?id=xxx作为回退。第三个是去重。HN 的 top 榜单每一天的更新范围其实高度重合，如果你定时每天跑一次，昨天的 20 条里有 15 条会再次出现。

去重逻辑放哪里最合理？在 Entry 阶段做结构去重意义不大，因为你还要去 Grist 查历史库。我处理方式是：Grist 表里给hn_id这一列设置成唯一标识，n8n 在写入新记录前先用 Grist 节点查一下这个 ID 是否已存在，不存在才追加。Grist 节点支持“根据条件查询记录”，把过滤条件写成hn_id = 具体ID，再根据查询结果走分支。这样就算抓取任务每天重跑，重复数据也进不了表。关于这个分支写法，后面第 5.3 节专门讲。

4. Grist 节点：把“表格”用成“数据库”

4.1 Grist 的几个关键概念

第一次用 Grist 的人建议先花十分钟理解三个概念：文档（Document）、表（Table）和列（Column）。一个 Grist 文档里可以有多张表，表与表之间可以用引用列关联，比如我建一张hn_posts表存放帖子主体信息，另一张hn_analysis表存放智能体的分析结果，两张表之间通过post_id做关联。这个设计和你建 MySQL 数据库时的思路几乎一样，区别在于 Grist 的界面更友好，你可以直接用表格方式编辑数据，还可以在表格里添加公式列，比如用RECODE公式，根据已有关键词给记录打分类。

在 n8n 里接入 Grist 并不复杂。官方集成提供了 Grist 节点，连接方式只需要填 Grist 的 API 地址和 API Key。Grist 的 API Key 在个人设置页面生成，注意密钥只显示一次，生成之后要立刻复制保存。有人会把 API Key 直接写在节点配置里，这对本地测试没问题，但如果你想跑正式环境，建议用 n8n 的 Credentials 变量去引用，不要硬编码在 workflow JSON 里，避免分享时泄露密钥。

4.2 n8n 的 Grist 节点支持哪些操作

Grist 节点在 n8n 里封装的操作有：Create（创建记录）、Update（更新记录）、Delete（删除记录）、Get All（查询记录）、Get Row（按 ID 获取单条）等。最常用的是 Create 和 Get All。

• 在 Create 模式下，你要在“Columns”里把列名和值一一映射。比如我的hn_posts表有这些列：hn_id、title、url、points、author、time、comment_count。在节点里添加 Column 字段，Value 就填表达式引用上游字段，比如{{ $json.hn_id }}。
• 在 Get All 模式下，你可以填过滤条件，格式是“列名 操作符 值”。比如判断 hn_id 是否等于某个字符串，写法就是hn_id = abc123。这个查询功能在去重场景里是主力。
• 还有一个特别有用的参数是“Return Table”，如果设为 Table，节点返回的数据格式是数组，方便后续 Loop 节点逐条处理；如果设为 Single Row，则只返回匹配的第一条，适合判断存在性。

有一个容易出问题的地方：Grist 的列名如果包含空格或特殊字符，在 n8n 表达式里引用时要用['列名']而不是.列名。比如列名是comment count，那么写入表达式要写成$json['comment count']。这一点我第一次用的时候没注意，节点直接报错，后来排查才知道是字段名里的空格导致的。

4.3 记录唯一性和幂等写入

用 Grist 做存储端，我最看重它的“列唯一性”设置。在 Grist 的表结构设计里，你把hn_id那一列的类型设为 Text，然后在列选项里开启“唯一”约束，表示同一张表内不允许出现两个一样的值。这个约束在 Grist 数据库层生效，比你在 n8n 里写半天的判断逻辑可靠得多。不过要注意：Grist 的约束触发在实际写入的那一刻，如果写入重复会直接报错，错误信息会从节点传递到 n8n，导致整个工作流失败。所以如果你的写入逻辑已经先做了一次查询判断，其实也可以不开唯一约束，自己控制逻辑，还能省去一部分异常处理。

我个人更推荐查重 + 幂等更新的组合方式：在写入前查一遍 Grist，如果记录已存在就把它更新为最新分数和最新分析结果；如果不存在就新建。为什么要做“更新”而不是“跳过”？因为 HN 的帖子分数（points）会随时间变化，一条昨天还是 20 分的帖子今天可能已经变成 300 分了，如果你直接跳过，表格里的数据就永远不会刷新，这条帖子也成为“死数据”。所以我的链路里，Grist 的操作不是简单的 Create，而是用一个 If 节点判断“记录是否存在”，存在走 Update 分支，不存在走 Create 分支。这种模式也叫“upsert 幂等写入”，在自动化 pipeline 里是非常标准的做法。

4.4 Grist 公式列：让智能体的输出更规整

Grist 最让我喜欢的一点，是支持公式列。什么意思呢？假设智能体返回的每条记录里有一个叫ai_score的评分，范围是 0 到 100，你想把它转成 High / Medium / Low 三档显示。这个转换当然可以在 n8n 的 Code 节点里做，但如果你直接把原始数字写进 Grist，然后通过 Grist 的公式列自动生成档位，逻辑就变得极其清晰：原始数据是数据，展示逻辑是公式，两者分离，将来改展示规则不用动自动化流程。

我实际建了一个视图，用类似这样的公式：IF(score >= 70, "High", IF(score >= 40, "Medium", "Low"))。Grist 的公式语法和 Excel 类似，上手很容易。还有一个常用场景是统计最长标题的字符数、评论数排名等，这些都可以用公式视图完成，不需要额外写代码。团队里的人看到的就是一张会自己算的“智能表”，他们不需要理解 n8n 的任何概念。

5. AI Agent 节点的设计与实践

5.1 n8n 智能体节点的工作原理

n8n 的 Agent 节点本质上是一个大模型对话应用，它在 n8n 工作流内部模拟了一个类似 ChatGPT 的循环：接收系统提示词、工具列表和用户输入，然后调用大模型生成内容。比较关键的是 Agent 节点能够挂载工具（Tool），比如挂一个 HTTP Request 工具去查 Grist 的数据，挂一个 Code 工具做计算。但回到我前文的原则——我强烈建议不要让 Agent 直接去挂 Grist 工具，它只需要处理“分析”判断即可。

那么 Agent 节点该如何配置？首先要选择一个模型。n8n 支持通过 LangChain 兼容的方式接入 OpenAI、Anthropic、Google 等模型，也支持本地的 Ollama。日常验证阶段，我推荐用 Ollama 跑本地模型，成本为零但速度慢一点；生产环境则看你对中文质量和结构化输出有多苛刻，用 OpenAI 的gpt-4o-mini级别模型足够，性价比高。配置时把 API Key 放进 Credentials，然后在 Agent 节点里连接模型即可。

5.2 系统提示词的写法：要具体、要限死输出格式

Agent 节点有一个 System Message 栏位，这里填系统提示词。很多人随便写一句“你是一个数据分析助手”，结果输出的字段五花八门，解析时直接头大。我的经验是：系统提示词必须包含三段内容。第一段定义角色和任务边界；第二段定义输入数据的字段含义；第三段硬性规定输出 JSON 的格式。

这里给出一个可以直接复制微调的示例（我用的是中文提示词，因为后面希望处理结果保持中文，方便团队阅读）：

你是一个技术内容分析助手。你会收到一批来自Hacker News的帖子标题、URL、作者、分数和评论数。你的任务是对每一条帖子做三项工作： 1. 用不超过20个字概括它讨论的核心技术主题； 2. 对帖子做分类，分类范围只能是：AI/ML、数据库、前端、后端、工具链、安全、创业、其他； 3. 对你的概括给出一个可信度分数，分数是0到100的整数。 输出必须是一个JSON数组，数组中每一项的格式如下： {"id": "原始帖子ID", "summary": "中文概括", "category": "分类", "confidence": 分数} 请不要输出任何除JSON数组以外的文本，不要使用Markdown代码块包裹。

实测下来，这样写基本能保证输出是干净的 JSON。如果模型偶尔还是输出了一堆夹杂说明文字的文本，我会在 Code 节点里用正则从内容里把 JSON 片段抓出来再JSON.parse。这是最古老的稳妥兜底方案，但足够用了。有一点要提醒：如果你用的是本地量化小模型，可能无法严格遵守 JSON 输出格式，这种情况下建议在 n8n 里加一个“如果 JSON.parse 失败就重试一次”的循环，或者干脆在生产环境换更稳定的云端模型。

5.3 批量数据如何喂给 Agent，又不打爆上下文

HN 节点一次返回 30 条记录，如果你把 30 条原始记录一次性全部塞给 Agent，上下文窗口虽然不至于爆，但 token 开销会明显增大。而且模型对超长列表的注意力会分散，后面的条目分析质量下降。我第一次测试时直接把 90 条全塞进去，结果后面的条目摘要质量明显变差，有些甚至被直接忽略。

更合理的方式是：用 n8n 的 Split Out 节点（或 Item Lists 节点）把数组分割成单独条目，然后每次只让 Agent 处理一条，最后再用 Aggregate 节点把结果拼接回数组。但这种方式的缺点是调用次数增多，如果你的环境不支持并发，性能会比较感人。另一个折中方案是，每 5 到 8 条作为一批批次处理，每个批次生成一个 JSON 数组，既能压 token，又能提升一致性。我现在用的是后者：先用 Code 节点把 30 条原始记录切分成 5 个 chunk，每个 chunk 6 条，循环交给 Agent，最后合并输出。整个执行时间大约 1 到 2 分钟，完全可接受。

5.4 工具挂载：该让智能体查什么

虽然我说了不要让 Agent 直接操作数据库，但在某些场景下，给它一个只读查询工具是有益的。举个例子：如果你的智能体要做“今日 HN 与前 7 日热点对比”，它需要知道之前存了哪些内容。这时候可以让 Agent 挂一个 HTTP Request 工具，请求 Grist 的 API 查询近 7 天的数据。工具描述要写清楚“如果想知道历史数据，就调用这个工具，输入日期参数，返回的是 JSON 数组”。然后 Agent 自己决定什么时候调用。

不过这类工具调用依赖模型自身的 function calling 能力，稳定性不如固定流程。如果是给团队做生产工具，我的建议还是不要依赖这种动态调用，而是固定用 n8n 节点先查好历史数据，放到工作流的上下文里，再交给 Agent 综合分析。动态工具适合那种探索性、不确定要不要查的“研究模式”，不适合“每天固定产出日报”的场景。这两者的边界你要先想清楚。

6. 完整工作流搭建实录：从空白画布到第一张日报表

6.1 前置准备：账号、接口和凭据

开始搭之前，先准备四样东西。第一，一个 n8n 实例。这个网上教程很多，可以用官方托管，也可以自托管，我建议开发者至少先用官方 Docker 镜像在本地跑通，调试方便。第二，Hacker News 的公网 API，不需要 key，直接用节点内置能力即可。第三，一个 Grist 实例。如果你没有现成的，可以用官方文档里的远程托管，也可以在本地用 Docker 快速启动一个 Grist，它有开箱即用的 Web 界面。第四，一个 LLM 的 API Key，比如 OpenAI 的。准备好这四项，再开始画工作流。

在 n8n 的 Credentials 页面，分别创建 Grist API 凭据和 OpenAI API 凭据。Grist 这里需要填：API Key、URL（你的 Grist 实例地址）、还有 Grist 的文档 ID。文档 ID 在 Grist 页面的 URL 里可以看到，是一串字母数字。如果文档 ID 填错，节点会报 404，这是新手最常踩的坑之一。

6.2 核心节点连线步骤

我按从前往后的顺序整理了一份可直接照着连的清单：

1. Schedule Trigger：先拖一个定时触发器，比如每天早上 7 点执行。如果你只是测试，可以把触发间隔改成每分钟，运行成功后再改回工作流自带的方式。
2. Hacker News 节点：Operation 选 Get All Posts，Category 选 top，Limit 设 30。
3. Code 节点（第一轮过滤）：写一小段 JS，过滤掉标题里不包含任何预设关键词的记录，把 title、url、points、author、time、commentCount、id 打包成新对象数组。
4. Code 节点（分块）：把上一步数组切成 5 块，输出{ "chunks": [[...], [...], ...] }。
5. Loop Over Items 节点：遍历 chunks 数组，循环体里依次接 Agent 节点、JSON 清洗节点。
6. Agent 节点：模型选gpt-4o-mini，System Message 用第 5.2 节的提示词，User Message 传入 chunk 里的 JSON 数组文本。
7. JSON 清洗节点：用 Code 节点把 Agent 输出字符串解析成数组，并补一个hn_id字段。
8. Merge 节点：把所有循环结果合并成一个整体数组。
9. Grist 节点（查重）：把合并后数组拉平，逐条查 Grist 表判断 hn_id 是否存在。
10. If 分支：存在就接 Grist Update 节点，不存在就接 Grist Create 节点。
11. 最后接一个 Email 节点（可选），把当日处理条数和新增条数发到邮箱。

6.3 关键参数与代码参考

这里的 Code 节点值得单独说。第一轮过滤节点的 JS 大概是这样的：

const keywords = ['ai', 'llm', 'database', 'langchain', 'gpt', 'vector', 'model']; const items = $input.all().map(item => item.json); const filtered = items.filter(item => { const title = (item.title || '').toLowerCase(); return keywords.some(keyword => title.includes(keyword.toLowerCase())); }); return filtered.map(item => ({ hn_id: item.id.toString(), title: item.title, url: item.url || `https://news.ycombinator.com/item?id=${item.id}`, points: item.points || 0, author: item.author || '', time: item.time, comment_count: item.commentCount || 0 }));

这里有个小地方要注意：n8n 的 Code 节点里面$input.all()返回的每一项是{ json: {...}, binary: {...} }结构，所以拿到item.json才是真正的数据。有很多初次使用 Code 节点的人会直接写$input.item，然后拿不到字段，一脸懵。这种细节真的只有实际操作踩过坑才会记得牢。

Grist 建表时，我的列设计大概长这样：

6.4 调度与邮件通知

整个工作流跑起来之后，我给 Schedule Trigger 设成了每天 7:30 执行。因为 HN 的 top 榜单更新频率很高，早上跑一次可以抓前一天深夜到凌晨的热门内容。邮件通知我用的是 n8n 的 Email 节点，SMTP 填自己的邮箱服务。内容很简单，用 HTML 模板把当天新增条数和分类占比写进去。为什么要有邮件？因为如果 Grist 写入失败，我想在第一时间知道，而不是隔了几天打开表才发现数据断更。

邮件节点的内容是可以用表达式动态拼接的。我一般会写一个 HTML 片段，插入 Grist 新增记录数的变量，比如“今日新增 23 条记录，分类占比：AI/ML 40%，数据库 20%”。这个不用很复杂，表达清楚即可。如果你的团队用企业通讯软件，n8n 也有对应的通知节点，可以用同样的变量。

7. 常见问题与排查技巧实录

7.1 Hacker News 节点报超时或拿不到数据

这个节点依赖外部 API，偶尔会有超时情况，尤其是下午的活跃时段。通常做法是在节点设置里把 Timezone 和 Retry 相关参数配上，n8n 在节点错误时默认可以重试。如果频繁超时，可以先在浏览器里直接访问https://hacker-news.firebaseio.com/v0/topstories.json这类接口，看看是不是网络环境问题。也有一种情况是 Limit 参数设置过大，比如一次性拉取几百条，会导致执行时间很长甚至超时，调到 50 以内比较稳妥。

7.2 Grist 写入时报错“value too long”或类型不匹配

Grist 对类型校验比普通电子表格严格。如果你写入的字段长度超过列定义的长度，或者把一个字符串写进整数列，节点会返回错误。我最常遇到的是把commentCount原样写入的时候，HN 节点返回的可能是字符串0，而 Grist 列定义是 Integer，就会报错。解决办法是在 Code 清洗阶段做一次严格类型转换：parseInt(item.commentCount || '0')。所有写入 Grist 的字段都要提前检查类型，这是建议养成的好习惯。

7.3 Agent 输出不是合法 JSON

这是目前最常出现的问题，尤其是切换模型后。排查步骤有三层：第一步，看 Agent 节点的原始输出，是否被 Markdown 的 ```json 包裹，如果是，清洗代码里要先把包裹去掉；第二步，用正则提取第一个[到最后一个]之间的内容，再尝试 parse；第三步，如果 parse 仍然失败，就让工作流把失败数据写进一个独立的错误表，方便事后分析。这三层都不复杂，但非常有效。

这里给一个兜底的正则提取示例：

const text = $json.output; const match = text.match(/\[[\s\S]*\]/); if (!match) throw new Error('No JSON array found'); const data = JSON.parse(match[0]); return data;

注意[\s\S]*可以匹配换行符，比.更靠谱。

7.4 智能体分析结果和预期严重不符

这种情况大多是提示词问题而不是模型问题。我之前出现过分类“其他”占比过高，后来排查发现是因为预设分类里没有“云计算”这个类别，很多云原生相关帖子只能被塞进“其他”。解决办法是把分类列表调整得更贴合自己的业务，比如加上“云原生 / 基础设施”。另外，如果你希望 Agent 对标题里没有明显信号但实际非常热门的帖子能给出合理判断，建议把标题、评论数、分数同时传给它，而不只是标题文本。评论数高的帖子往往代表讨论热度大，这是非常有价值的信息。

7.5 记录重复：既是节点问题也是表设计问题

如果你没有做查重直接写入，重复几乎是必然的。查重节点本身也会有精度问题：Grist 查询返回结果时，如果存在一条以上，条件查询有可能会报错或者返回多条。最保险的方案是建表时就给hn_id加唯一约束，同时再配合 n8n 的 If 分支做 upsert。两条路都走，才能保证不管是程序漏了还是网络抖动，都不会写进重复记录。

8. 一点经验总结：任何自动化系统都要先想好“失败后怎么办”

有人可能会问：既然这套系统已经能自动抓取、分析、存储，那是不是可以完全不用人工看？以我个人的实操体会来说，不行。它最大的价值是把重复性劳动压缩到几乎为零，把人的精力从“收集信息”解放到“判断信息”上，但判断本身还是需要人做 final review。我每天早晨打开 Grist 的精选视图，花大概十分钟扫一遍智能体的摘要，偶尔纠正几个分类，日子久了，模型在同类型内容上的表现会越来越稳定——因为你其实是在用每天的反馈喂养那个提示词的上下文质量。

另外，所有自动化系统都要提前设计“失败后怎么办”。我的工作流里专门留了一个错误分支：任何关键节点抛错时，n8n 会把错误信息发到企业通讯软件里，同时保留原始数据在临时表里。这样可以防止数据源因为一个夜间 API 波动就整条链路静默失效。建立这个习惯之后，后面做更复杂的智能体流程也会顺手很多。

最后分享一个小技巧：如果你打算长期跑这套系统，尽量把 Agent 节点输出的字段版本化。比如 Grist 表里同时保留summary_v1和summary_v2两列，这样万一某次提示词调整后效果变差，还能快速对比回滚。不要删除旧数据，数据留底的价值永远比节省的一点存储大得多。这套 Hacker News + Grist + n8n 的组合，目前是我最稳定的信息流自动化方案之一，希望对你也能派上用场。