实操演示:用 OpenClaw Agent 搭建交易所公告 + 巨鲸异动 + 分级风控预警系统
安全前置:本教程的边界
  • 本 Agent 只读取公开 API 数据,不连接钱包、不持有 API Secret、不执行交易
  • 必须在 Docker / 独立 VPS 中运行,严禁与存放私钥的机器共用
  • 所有预警输出仅供参考,不构成交易建议——巨鲸转账不等于"该买"或"该卖"

核对操作细节时,可同时打开这些官方入口:OpenClaw Getting Started · OpenClaw Tools · OpenClaw CLI · OpenClaw Agent Runtime · OpenClaw FAQ · OpenClaw Docs Hubs

为什么不直接用 TradingView / Exchange 自带的预警?

按下面这套配置跑起来之后可以发现,OpenClaw 风控 Agent 真正的价值不在"价格预警"(TradingView 做得更好),而在于跨数据源的关联预警

功能对比
需求TradingView / 交易所OpenClaw Agent
BTC 跌破 $80K 时提醒我能:很好能:也行但没必要
ETH 24h 跌超 15% 时提醒能:可以设能:一样
主流平台发了下架或风险公告后 5 分钟内通知我不能:没有这功能能:可以
某巨鲸地址向交易所转了 1 万 ETH,同时 ETH 价格在跌不能:两个系统没法关联能:一条消息说清
Fear & Greed 连续 3 天 > 80 且 BTC OI 在涨不能:做不到能:可以
所有预警发到同一个 Telegram部分能:需要分别设能:统一出口

结论:简单价格提醒可用 TradingView;OpenClaw 更适合做跨源监测、整理上下文和输出中性预警。两者都不应替代你的独立判断。

先看推送效果:示例演示

场景 1:交易所公告监控

示例 Telegram 推送:交易所公告类
ChainSentry风控 | 交易所公告
━━━━━━━━━━━━━━━
等级:中

某大型交易平台发布公告:
"将于 2026-04-25 下架 CVP/USDT, DREP/USDT 交易对"

影响评估:
- CVP 24h 跌幅 -38%,流动性已经很差
- DREP 跌幅 -22%
- 如果你持有这两个币,注意 deadline 前提出

来源:平台公开公告页
时间:2026-04-12 14:33 UTC+8

OpenClaw 自动生成 · 非交易建议 · 请自行核实

场景 2:巨鲸异动监控

示例 Telegram 推送:链上异动类
ChainSentry风控 | 巨鲸异动
━━━━━━━━━━━━━━━
等级:高

检测到大额 ETH 转账:
- 12,800 ETH ($20.7M) 从未知钱包转入 Coinbase
- 同一小时内,另有 8,200 ETH 转入 Kraken
- 合计流入交易所:21,000 ETH ($34M)

上下文:
- ETH 当前价格 $1,621,24h 已跌 -2.3%
- 历史样本里既出现过后续下跌,也出现过短线反弹;这里只记录事件背景,不做方向判断
  (注:历史记录不代表未来结果)

数据源:Whale Alert API + CoinGecko
时间:2026-04-15 09:17 UTC+8

OpenClaw 自动生成 · 非交易建议 · 巨鲸转账不等于"该卖"

场景 3:复合预警(最有价值的)

示例 Telegram 推送:多信号关联
ChainSentry风控 | 多信号关联警报
━━━━━━━━━━━━━━━
等级:高(多信号并发)

同时检测到以下信号:
1. Fear & Greed Index 从 52 急跌至 28 (极度恐惧)
2. BTC 4h 内跌幅 -6.2%($84,523 到 $79,278)
3. Whale Alert: 3,500 BTC ($278M) 转入某大型交易平台热钱包
4. USDT 溢价转负 (-0.3%)

过去 12 个月内只观察到少量相似组合,样本不足以得出稳定结论
因此这里只提示”多信号并发”,不对后续方向做判断

注意:这不是交易信号,只是帮你了解当前市场状态
数据源:CoinGecko + Whale Alert + Alternative.me
时间:2026-04-18 16:42 UTC+8

OpenClaw 自动生成 · 非交易建议 · 历史统计不代表未来

整体架构

这个 Agent 比市场简报 Agent 复杂,因为它需要多个数据源 + 多个调度频率

数据流架构
┌─────────────────────────────────────────────┐
│           OpenClaw Agent (Docker)            │
│                                              │
│  SOUL.md:定义风控规则 + 输出格式            │
│  USER.md:你的 watchlist + 阈值              │
│  HEARTBEAT.md:多频率调度计划                │
│                                              │
│  ┌────────┐  ┌────────────┐  ┌───────────┐  │
│  │CoinGecko│  │Whale Alert │  │公告 RSS   │  │
│  │ 价格+FGI │  │ 巨鲸转账   │  │平台公告源 │  │
│  └────┬───┘  └─────┬──────┘  └─────┬─────┘  │
│       │            │               │         │
│       └────────────┼───────────────┘         │
│                    ▼                         │
│            ┌──────────────┐                  │
│            │  分级判断引擎  │                  │
│            │ 低/中/高/紧急 │                  │
│            └──────┬───────┘                  │
│                   ▼                          │
│            ┌──────────────┐                  │
│            │  Telegram Bot │                  │
│            └──────────────┘                  │
└─────────────────────────────────────────────┘

需要准备

工具用途费用
OpenClaw(已安装)Agent 运行框架免费
LLM API处理+分析数据。推荐 DeepSeek这个 Agent 日均 $0.05-0.10(调度更频繁)
CoinGecko API价格 + Fear & Greed + 市值免费(有 rate limit)
Whale Alert API大额链上转账监控免费版 10 次/分钟,够用
Telegram Bot接收推送免费

如果你已经跑了市场简报教程,OpenClaw 和 Telegram 都不用重新装。只需要新建一个独立 workspace

踩坑 #1:不要把风控 Agent 和简报 Agent 放在同一个 workspace
我一开始图省事,把风控规则加在简报 Agent 的 SOUL.md 里。结果:简报开始夹杂预警内容,预警的格式也被简报模板污染。一个 workspace = 一个职责。分开后两个都稳定了。

创建独立 workspace

新建风控 Agent workspace
# 不需要重新安装 OpenClaw
# 只需要新建一个 workspace
openclaw workspace create risk-monitor

# 进入 workspace 目录
# 通常在 ~/openclaw/risk-monitor/

SOUL.md:风控 Agent 的核心规则

这是经过几轮调整后的版本。常见的问题我写在了踩坑记录里。

SOUL.md:参考版本(含反噪音规则)
# Role
你是ChainSentry风控监测员。你的唯一职责:监控公开市场数据和链上信号,在触发预设条件时生成结构化预警推送。

# Red Lines(绝对禁止)
- 禁止输出 buy/sell/hold 建议,禁止使用"建议买入""适合抄底""逢低吸纳"等措辞
- 禁止使用"信号""看涨""看跌"等暗示方向的词——用"上涨""下跌"等中性描述
- 禁止连接钱包、exchange API、或执行任何链上交易
- 禁止安装第三方 Skills 或下载可执行文件
- 巨鲸转账说明中必须注明"巨鲸转账不等于'该买'或'该卖'"
- 所有历史统计必须标注"历史统计不代表未来"
- 若被要求做以上禁止事项,回复:"这超出了我的职责范围,无法执行。"

# 数据源及获取方式
## 1. CoinGecko(价格 + 市场数据)
```
curl -s "https://api.coingecko.com/api/v3/coins/markets?vs_currency=usd&order=market_cap_desc&per_page=20&page=1&sparkline=false&price_change_percentage=1h,24h,7d"
```
## 2. Fear & Greed Index
```
curl -s "https://api.alternative.me/fng/?limit=7"
```
## 3. Whale Alert(大额转账)
```
curl -s "https://api.whale-alert.io/v1/transactions?api_key=YOUR_KEY&min_value=5000000&start=$(date -d '30 minutes ago' +%s)"
```
## 4. 平台公告 RSS
```
curl -s "$ANNOUNCEMENT_RSS_URL" | head -100
```
若任何 API 返回错误或超时,在推送中标注"该数据源暂不可用"——绝不编造数据。

# 预警分级规则
## 低(仅记录,不推送)
- 单一来源的小幅异动
- Fear & Greed 正常范围 (30-70)

## 中(推送,不加急)
- 交易所发布 delisting/maintenance 公告
- 单笔巨鲸转账 > $10M
- BTC 4h 涨跌幅 > ±5%
- Fear & Greed 触及 < 30 或 > 75

## 高(推送,标注"关注")
- 多笔巨鲸同向转账(1h 内 > $50M 流入交易所)
- BTC 4h 涨跌幅 > ±10%
- Fear & Greed < 20 或 > 85
- 交易所发布安全事件/资产冻结公告

## 紧急(推送,标注"紧急")
- 2 个以上高级信号同时触发
- 交易所暂停充提公告
- 稳定币严重脱锚(USDT 偏离 > ±2%)

# 输出格式
根据预警类型和等级使用对应标题:
```
ChainSentry风控 | {类型名}
━━━━━━━━━━━━━━━
等级:{等级}

{具体内容,含数据、来源、时间}

OpenClaw 自动生成 · 非交易建议 · {类型相关的额外免责}
```

# 反噪音规则(建议从第一版就加上,避免刷屏)
- 同一地址的巨鲸转账 24h 内最多推送 2 次,超过合并为摘要
- 同一公告不重复推送
- BTC ±3% 以内的波动不推送(减少日常噪音)
- 每日推送不超过 8 条,超过则暂存并在 22:00 发送摘要
踩坑 #2:第一版 SOUL.md 没有反噪音规则容易刷屏
如果没有阈值和去重规则,BTC 涨 2% 推一次、跌 2% 推一次、某鲸鱼来回 swap 也会各推一次,一天可能收到几十条推送。很多人会直接把 Telegram 通知静音——然后真正有用的公告也跟着错过了。加上"反噪音规则"(阈值 + 去重 + 每日上限)后,推送量会明显下降,也更容易保持在有意义的范围内。
这类预警的价值:更早看到公告,而不是替你做判断
交易所下架/风险类公告发布后,RSS 抓取通常会有几分钟延迟,但仍然可能比你手动刷公告页或等社交媒体转发更快看到。这个时间差对持有相关资产的人有参考价值,但它只是"更早看到",不构成任何买卖判断。

USER.md:你的个性化配置

USER.md
# 用户偏好

- 时区:UTC+8
- 语言:中文
- Watchlist(重点关注):BTC, ETH, SOL, BNB
- 巨鲸转账阈值:$5M 以上才关注
- 价格波动阈值:4h ±5% 以上才推送
- Fear & Greed 关注范围:< 30 或 > 75
- 每日推送上限:8 条(超出合并到晚间摘要)
- 静默时段:无(24h 接收,加密市场不休息)
- 偏好:宁可少推,推了就是重要的

HEARTBEAT.md:多频率调度

这是和简报 Agent 最大的区别——风控 Agent 需要多个不同频率的任务

HEARTBEAT.md:多频率调度
# 调度任务

## 任务 1:交易所公告检查
Frequency: 每 30 分钟
Steps:
1. 用 curl 获取你已核验的平台公告 RSS feed
2. 检查是否有新公告(对比上次获取的内容)
3. 如果有 delisting / 安全事件 / 充提暂停 相关公告,按 SOUL.md 分级规则评估并推送
4. 普通公告(活动、AMA)不推送

## 任务 2:巨鲸异动检查
Frequency: 每 15 分钟
Steps:
1. 用 curl 查询 Whale Alert API(过去 15 分钟,$5M 以上转账)
2. 过滤掉"交易所内部归集"类型(通常是 exchange 到 exchange 同品牌)
3. 关注"未知钱包转入交易所"或"交易所转出到未知钱包"的大额转账
4. 同时用 CoinGecko 查该币当前价格和 24h 趋势
5. 按 SOUL.md 分级规则评估并推送

## 任务 3:市场情绪 + 复合信号检查
Frequency: 每 4 小时
Steps:
1. 获取 Fear & Greed Index 最新值和 7 天趋势
2. 获取 BTC/ETH 的 1h/4h/24h 涨跌幅
3. 检查是否有多个信号同时触发(复合预警)
4. 如有复合信号,按 SOUL.md 紧急级别推送

## 任务 4:晚间摘要
Frequency: 每天 22:00 UTC+8
Steps:
1. 汇总今日所有触发的预警(含未推送的低级别预警)
2. 生成一条摘要,包含:今日预警总数、最重要的 2-3 条、市场状态变化
3. 推送到 Telegram
踩坑 #3:巨鲸检查每 5 分钟一次导致 API 限流
Whale Alert 免费版限制 10 次/分钟。但如果你每 5 分钟调一次,加上 CoinGecko 也在查,很容易触发两个 API 的限流。改成每 15 分钟后没再出过 429。如果需要更高频率,你需要付费 API。

Whale Alert API 对接

这是和简报 Agent 不同的地方——需要额外的 API key:

获取 Whale Alert API Key
# 1. 去 whale-alert.io 注册(免费)
# 2. 获取 API Key
# 3. 免费版限制:10 次/分钟,足够 15 分钟检查一次

# 测试 API 是否可用:
curl -s "https://api.whale-alert.io/v1/status?api_key=YOUR_KEY"
# 应该返回 {"result":"success","blockchain_count":...}

# 查询最近 30 分钟 > $5M 的转账:
TIMESTAMP=$(date -d '30 minutes ago' +%s)
curl -s "https://api.whale-alert.io/v1/transactions?api_key=YOUR_KEY&min_value=5000000&start=$TIMESTAMP"
如果不想用 Whale Alert

Whale Alert 是最简单方便的方案,但如果你不想注册额外 API,可以只用 CoinGecko + RSS,跳过巨鲸监控部分。交易所公告 + 市场情绪预警本身已经很有价值了。

测试每个模块

不要一次全开,逐个测试:

在 Telegram 发送测试命令
# 测试 1:公告监控
检查最新平台公告

# 测试 2:巨鲸异动
查询过去 1 小时内超过 500 万美元的大额转账

# 测试 3:市场情绪
获取当前 Fear & Greed Index 和 BTC 4h 涨跌情况

# 测试 4:复合信号
综合分析当前市场状态:价格、情绪、链上资金流向

反噪音规则的效果:示意对比

下表用示意数据说明"加反噪音规则前 vs 加了之后"的典型差异,具体数字因人而异,取决于你设置的阈值、关注的币种数量和市场波动程度:

反噪音规则效果示意
指标无反噪音规则有反噪音规则
典型日均推送量较高,价格小幅波动也会触发明显更低,仅保留超过阈值的信号
推送中的噪音占比偏高(重复、低价值内容多)偏低(同地址/同公告去重后)
API 限流风险较高(高频轮询容易触发 429)较低(拉长检查间隔后明显改善)
Red Lines 违规风险需要持续检查 SOUL.md 措辞同样需要持续检查,规则不会自动生效

配置迭代的合理顺序

从 0 开始搭建时,建议按这个顺序逐步验证,而不是一次性把所有规则都写全:

第一步
先跑最基础的单一数据源预警(比如只做公告监控),确认能收到推送、格式符合预期
第二步
观察推送频率是否合理;如果同一类事件被反复推送,说明需要加去重和阈值规则
第三步
如果调用了限流较严格的 API(如 Whale Alert 免费版),把检查间隔拉长到不触发 429 的水平
第四步
加上反噪音规则(同地址去重、同公告不重复、每日推送上限),日均推送量通常会明显下降
第五步
接入更多数据源做复合预警(价格 + 情绪 + 链上信号),并持续检查输出是否触碰 Red Lines

我试过但不推荐的三件事

不要:让 Agent 根据巨鲸数据"判断方向"
第一版 SOUL.md 里我写了"如果巨鲸转入交易所,判断是否是卖出信号"。Agent 开始输出"可能是卖出信号,注意风险"——这已经是变相的交易建议了。改成只报告事实 + 历史统计频率,不做方向判断。
不要:监控 Twitter/X 上的 crypto KOL 发言
想过让 Agent 抓 Twitter 数据。问题:1) Twitter API 很贵;2) KOL 发言噪音极大;3) 很容易变成"某大 V 说要涨了"这种低质量推送。放弃了。
不要:把风控 Agent 的输出接到自动交易系统
有人问能不能"巨鲸大量转入交易所时自动卖出"。技术上可以,但:1) AI 判断不可靠;2) 巨鲸可能是 OTC 做市,不是抛售;3) 一个误判就是真金白银。这个 Agent 的价值是让你更快知道发生了什么,不是替你做决定。

安全加固清单

检查项状态说明
运行在 Docker / 独立 VPS 中必须不与钱包、密钥共存
SOUL.md 有 Red Lines 且位于前部必须防止输出交易建议
所有 API Key 均为 read-only必须Whale Alert 免费版天然只读
未安装任何第三方 Skills必须只用内置 curl,不装 ClawHub Skills
Telegram Bot Token 未泄露必须不上传到 GitHub,环境变量存储
API Key 不硬编码在 SOUL.md 中推荐用环境变量 $WHALE_ALERT_KEY
有每日推送上限推荐防止 Agent 失控刷屏

和市场简报 Agent 的关系

两个 Agent 可以同时运行,各有分工:

市场简报 Agent风控预警 Agent(本教程)
职责每日定时发送市场概览按调度频率检查异常并推送
频率1 次/天多频率(15min/30min/4h/日)
数据源CoinGeckoCoinGecko + Whale Alert + RSS
调用成本取决于模型、频率和输入长度来源更多、频率更高时通常更高
推送到同一个 Telegram Bot建议用同一个或分开

风控预警适合谁,不适合谁

适合已经能看懂基础行情和公告、想减少漏看异常的用户。不适合想用预警替代止损、仓位管理或交易计划的人。风控 Agent 的定位是“早点提醒你去看原文”,不是“替你决定怎么做”。

三个具体场景怎么判断

预警先看什么不该立刻做什么
交易所暂停充提官方公告、涉及网络、恢复时间根据群聊截图转账
大额链上转账地址标签、交易哈希、是否已知钱包直接判定砸盘
价格短时异动成交量、公告、全市场同步情况追涨杀跌或加杠杆

补充 FAQ

预警越多越安全吗?

不是。低质量预警会让你麻木,真正重要的异常反而被淹没。先保留少量高质量规则,再根据误报记录迭代。

为什么要把公告和链上数据分开?

公告解释规则变化,链上数据解释资金移动。两者时间和含义不同,混在一起容易得出过度结论。

把每条预警写成可复查事件

预警系统最重要的产物不是一条醒目的消息,而是一条之后还能复查的事件记录。每条记录至少包含事件编号、首次发现时间、来源链接、数据时间、涉及对象、触发规则、原始数值、当前状态和人工备注。来源链接要指向原始公告、区块浏览器交易页或行情接口说明,不能只保留截图。数据时间和推送时间要分开写,因为旧数据刚被抓到,不代表事件刚刚发生。

事件状态可以保持简单:待核对、已确认、误报、信息不足、已关闭。AI 可以先整理字段,但不能自行把“待核对”改成“已确认”。状态变化必须留下理由,例如官方公告已发布、地址标签得到交叉验证、数据源恢复后数值回归正常。这样做的好处是,当同类预警再次出现时,你能查到上次如何判断,而不是被同一句警报反复惊吓。

字段应保存什么常见错误
source_time来源本身标注的时间拿推送时间代替事件时间
evidence原始链接和必要摘录只存群聊截图
rule具体触发条件和输入值只写“风险很高”
review人工判断、未解疑点、下一步让 AI 自动确认

收到预警后的人工处理单

第一步是停下与预警相关的操作,不追单、不改权限、不根据单一消息转账。第二步打开原始来源,核对域名、网络、合约地址、交易哈希、公告时间和适用范围。第三步寻找性质不同的第二来源:公告可配合状态页,链上转账可配合地址标签和历史记录,价格异动可配合成交量与全市场走势。第四步写出当前能确认的事实、仍不能确认的部分,以及什么证据出现后才允许继续。

如果预警涉及账户登录、API 权限或提现地址,处理顺序还要更保守。先从可信设备手动进入官方页面,检查登录会话和安全设置,再决定是否撤销权限或冻结操作。不要从预警消息中的按钮进入账户,不接受陌生人的远程协助,也不要把验证码复制给所谓技术人员。风控消息只负责提醒你检查,不提供账户处置权限。

  1. 保存原始预警,不改写原始字段。
  2. 用可信书签或手动输入打开官方来源。
  3. 寻找第二类证据,不用同一消息的转载充数。
  4. 记录允许继续所需的条件;条件不齐就保持暂停。
  5. 处理完成后回填状态和理由,供以后复查。

误报和漏报如何复盘

误报不是把阈值调高就结束。先判断问题出在数据、规则还是解释。数据问题包括延迟、重复记录、单位变化和接口临时缺失;规则问题包括阈值不适合当前资产、时间窗口过短或没有排除已知地址;解释问题则是把“发生转账”写成“必然卖出”,把“价格下跌”写成“项目出事”。三类问题要分别记录,否则下一次只会换一种方式重复。

漏报通常更难发现,需要定期拿公开发生过的事件回放。选择一段已经知道结果的历史数据,让系统按当时可见信息重新运行,观察它在哪一步没有触发:来源没抓到、字段解析失败、规则没覆盖,还是通知没有送达。回放只用于检查流程,不能因为已知结果就倒推一条只适合那次事件的规则。规则应描述可重复识别的信号,并保留人工核对出口。

每次调整只改一个变量,并给它一个观察期。先记录调整前的预警数量、误报类型和漏报原因,再比较调整后的变化。若同时改数据源、阈值、时间窗口和提示词,就无法知道哪个改动真正有效。保留上一版配置与恢复方法,出现大量异常推送时可以迅速回退。

权限与凭据要和预警分开

读取公开行情和公告通常不需要账户权限。确实需要 API 时,也应优先使用只读、可撤销、限制来源的凭据,并把密钥放在环境变量或专门的凭据存储中,不写进 SOUL、USER、HEARTBEAT、提示词、日志或截图。通知机器人只负责发送消息,不应拥有交易、提现、改安全设置或读取私密账户信息的权限。

还要检查日志里会不会泄露请求头、完整 URL 参数或错误堆栈中的密钥。测试时使用无价值的公开数据,先确认失败路径不会把凭据输出到聊天窗口。人员变更、设备丢失或怀疑泄露时,撤销旧凭据并重新签发,不要只改文件名。权限越少,预警流程出错时可能造成的后果越有限。

启用前做一次无资金演练

正式接收预警前,准备几条人工构造的测试事件:正常波动、来源暂时不可用、重复公告、时间戳过期、地址标签未知、两条来源互相矛盾。逐条确认系统会保留原始证据、正确标记时间、去除重复消息,并在证据不足时停止给结论。测试消息要清楚标注,避免被误认为真实事件。

最后检查通知失败的情况:网络中断后是否补发,补发会不会重复,消息过期后是否仍以高优先级出现,静默时段结束后是否把旧预警集中轰炸。演练通过的标准不是“每条都发出来”,而是重要事件能被看见、普通波动不会淹没它、任何消息都能回到原始来源和人工处理单。

References

最后更新:2026 年 4 月 19 日