异地第187天，我用n8n把区块链监控接进了FastGPT

去年十月底，我面了一家做Web3基础设施的公司。面试官问：“如果让你监控某个合约的异常大额转账，你会怎么设计？”我说了一堆监听事件、写脚本轮询、存数据库、发告警。面试官又补了一句：“如果数据量很大，需要自动分类、自动生成可读的分析报告呢？”我卡住了。

回家路上我一直在想这件事。其实问题拆开看并不复杂：数据获取 → 数据处理 → 知识加工 → 分发。每个环节都有现成工具可以拼，只是大多数人没想过拼起来。于是从去年十一月开始，我花了大概三个周末加若干个晚上，把这套东西搭了出来。

架构：三个关键词怎么串起来

技术栈：

• 后端：Node.js + TypeScript，负责链上数据抓取和基础处理，加Redis做队列缓存。
• n8n：开源工作流编排工具，负责把“数据来了之后干什么”这条链路自动化。
• 区块链：以太坊JSON-RPC接口，监控USDT合约的Transfer事件，后来扩展到几个DeFi协议的关键合约。
• FastGPT：知识库问答平台，把历史异常交易案例、链上分析报告、合约白皮书塞进去，让它对新数据做语义层面的分析和总结。

整体流程：

链上新区块 → 后端抓取Transfer事件 → 规则过滤（金额阈值、地址黑名单）
→ 推送原始数据到n8n webhook → n8n执行工作流：
   1. 调用后端API做地址归因（交易所？混币器？巨鲸地址？）
   2. 调用FastGPT接口，把交易上下文作为query，获取语义分析
   3. 汇总结果，生成markdown报告
   4. 推送到Telegram bot和邮件

第一坑：n8n不是你想的那样

很多人以为n8n是“高级版IFTTT”，拖拖拽拽就完事。实际上处理真实业务逻辑时，它的局限性会迅速暴露。

第一个问题是调试体验。一旦工作流里出现异步调用链、条件分支嵌套，调试就很痛苦。经常某个节点报错“Unknown error occurred”，只能一个节点一个节点手动重新执行。有次凌晨一点，我卡在一个HTTP Request节点上，返回的JSON结构和预期不一样，n8n的表达式{{ $json.data[0].address }}一直返回undefined。最后发现上游节点的数据被包了一层data字段，而我测试时用的是手动输入的模拟数据，结构不同。

教训是：在n8n里，永远用真实数据做端到端测试，不要相信手动mock的结构。

第二个问题是版本管理。n8n的工作流导出是JSON文件，直接在UI上改再导出导入到另一个环境，容易出现节点ID冲突或凭据丢失。我的做法是把工作流JSON放进Git仓库，用n8n的API做部署，凭据用环境变量注入。这套流程花了我整整一个周末才理顺。

第三个问题是性能。n8n默认单进程，工作流里等待或轮询操作多，并发一上来就卡。有次我手动触发200个webhook请求，n8n直接OOM了。后来加了队列模式和并发限制才解决。

第二坑：区块链数据比你想象的脏

链上数据虽然不可篡改，但极其混乱。

USDT的Transfer事件，from和to地址是固定的，但很多合约会批量转账，一个交易里包含几十甚至上百个Transfer事件。如果按事件条数统计“大额转账”，会被批量操作刷屏。我一开始没做去重，结果一天收到300多条告警，全是同一个合约地址发出的批量转账，单笔金额只有几十美元，但加起来超过阈值。

后来改成按交易hash聚合，统计单笔交易的总转账金额，同时过滤掉已知的合约地址（交易所热钱包、DeFi协议路由合约等）。这需要维护一个地址标签库，我手动整理了大概50个地址后发现根本不够，又接入了公开的地址标签数据集。

还有个更坑的：代币精度。USDT在以太坊上是6位小数，但有些代币是18位，有些是8位。不处理精度，金额会差好几个数量级。我测试时就把一笔10万美元的转账显示成了0.1美元，差点以为过滤器写错了。

FastGPT的接入：从“能用”到“好用”

FastGPT本质是一个基于大模型的知识库问答平台，上传文档做向量化，然后基于检索增强生成（RAG）来回答问题。

我的用法是：把过去几个月的链上异常交易分析报告、常见攻击手法说明（闪电贷攻击、重入攻击等）、几个主流DeFi协议的文档，全部导入FastGPT作为知识库。当n8n检测到可疑交易时，把交易详情（金额、地址、时间、涉及协议）作为query发给FastGPT，让它结合知识库生成分析。

关键细节：FastGPT的回答质量高度依赖知识库的质量和切分方式。一开始直接把PDF丢进去，回答效果很差，经常答非所问。后来把文档按“攻击类型”“协议名称”“案例编号”做结构化整理，每个文档只讲一件事，控制在500字以内，效果立刻好了很多。

还有一个坑：FastGPT的API调用需要处理上下文长度限制。把整笔交易的原始日志全部塞进去，token消耗巨大且回答啰嗦。我做了个预处理，在后端把交易数据压缩成简洁的JSON摘要，只保留关键字段，再发给FastGPT。

一个真实案例

今年三月的一个周二凌晨两点多，Telegram响了。系统推送一条告警：某个DeFi借贷协议的可疑合约交互，金额异常。

FastGPT生成的分析说：这笔交易的模式和知识库里记录的一起“预言机操纵攻击”高度相似，建议关注该协议的价格预言机更新机制。我把报告转发给一个做链上安全的朋友，他说：“你这个分析方向是对的，这个协议确实在价格源上存在单点故障风险。”

那一刻的感觉很难形容。这套系统真的能把链上的原始噪音，变成一条有上下文、有分析、有建议的信息。 后来我把这个案例整理进简历和作品集。秋招面试时，面试官问起这个项目，我讲了大概十五分钟。面试官最后说：“你对n8n的理解比我们团队里用过它的人还深。”

一些不成熟的小建议

第一，技术探索不要为了用而用。 找一个你真实遇到的问题，然后看这些工具能不能解决它。我当初就是因为面试被问懵了，才有了做这个项目的动力。

第二，side project的完成度比广度重要。 我一开始想加前端面板、支持多链、做移动端推送。后来发现光是把以太坊一条链的数据处理稳定就花了好几个周末。与其做一个半成品的大系统，不如把一个垂直场景做深做透。

第三，先动手，别想太多。 哪怕一开始做得很烂，也比什么都不做强。我那个项目的第一版，现在看代码写得跟屎一样，但如果没有那个版本，就没有后来面试时那个能聊十五分钟的故事。