最近在折腾情报收集的老哥应该都有同感——每天打开十几个资讯源，挨个翻文章、看更新、手动转发到群里，这套流程看着简单，真正跑起来又耗时又容易漏。我一开始也想偷懒，用现成工具凑合，后来发现要么只能盯一两个平台，要么推送格式丑得没法看。折腾几轮之后，干脆自己动手搭了一套飞书 × OpenClaw 的自动化情报站。这个系列前面几篇讲了基础架构、Agent 调度、工具注册和定时任务的玩法，这一篇继续往后走，重点解决两件事：一是怎么让 OpenClaw 真正理解"什么值得推"，二是怎么把飞书机器人当成合格的收发终端来用。
如果你手上也有一堆 RPA 或脚本在跑，但总感觉"自动化了但又没完全自动化"——情报确实抓回来了，可还要人工筛选、人工排版、人工转发，那这篇内容大概率能帮上忙。这篇涉及的核心关键词有：飞书机器人、多维表格、OpenClaw 部署、消息推送、Agent 调度、自动化测试框架，适合正在做信息聚合、舆情监控、竞品跟踪或者团队通知体系的开发者来参考。
1. 情报站的整体设计思路：先想清楚信息管道再动手
在把任何一行代码写进 OpenClaw 之前，我建议先把整条链路拆成三段来看：采集、加工、触达。所有情报站类项目，本质上就是在解决这三段里各自的效率问题。
第一段是采集。传统做法是写一堆爬虫或者订阅 RSS，往数据库里灌原始内容。这个阶段最大的坑不是"抓不到"，而是抓得太杂：今天抓了几百条正文，真正值得看的可能只有十分之一。OpenClaw 这类 Agent 框架在这个环节的价值，不是替你把抓取脚本重写一遍，而是它能把"抓取哪些源、按什么频率抓、过滤掉什么"这一整套判断逻辑沉淀成技能（Skill），下次遇到类似需求直接复用。
第二段是加工。这是整个系统里最容易被低估的一环。很多人以为情报站的核心是抓数据，其实真正值钱的是"筛选+摘要+关联"。同样一条新闻，普通读者看一眼标题就划走了，但你关心的可能是它对某个行业板块的连锁反应。加工这层，我倾向于让 OpenClaw 调用大模型做粗筛和摘要，再配合一组规则做精筛。
第三段是触达。内容再好，送不到对的人手里也是白搭。触达环节要解决的是"用什么样的姿势把情报发出去"：是推送到群里，还是通过机器人私聊？是直接甩链接，还是附带一段 AI 摘要？是实时推，还是攒成日报定时发？这一步做得好不好，直接决定了团队成员愿不愿意看这个情报站。
这三段不是固定的流水线顺序，实际搭建时可以先从触达层起步，先把飞书机器人调通，能发消息了，再回去完善采集和加工。这样做的好处是每一轮迭代都有可感知的产出，不至于埋头写了两周爬虫最后发现机器人根本连不上。我这一篇就是从中间往外写的：先打通飞书，再回头优化 OpenClaw 的筛选策略。
1.1 为什么选飞书而不是其他 IM
飞书在高频消息推送场景下有一个其他 IM 比不了的优势：消息卡片。你可以把一条情报渲染成结构化卡片，标题、摘要、来源、时间、相关链接各占一块，视觉层级非常清晰。微信群机器人只能发纯文本和简易图文，钉钉虽然有卡片但模板定义偏死板，飞书卡片支持自定义 JSON 结构，能动态拼装，非常适合像"每日情报汇总"这种内容。
另一个实用角度是飞书的多维表格。情报站跑起来之后，你会发现"推完了就完事"是个特别大的浪费。推出去的消息如果能顺手落库，后续就能做数据回溯、按周复盘、统计信息来源质量，这些操作在飞书多维表格里几乎不需要开发成本。OpenClaw 可以直接调用飞书开放平台的 API 写多维表格，这就等于给情报站加了一个免费的内存。
1.2 OpenClaw 在情报站里承担的角色
OpenClaw 不是 RPA，它是一套 Agent 运行时，核心是把大模型、工具调用和任务编排揉在一起。在情报站这个项目里，我用它做三件事：
- 意图理解：收到飞书消息后，判断你这是让我搜情报、整理日报还是查看某个源的状态。
- 拆解任务：把"整理一份今日 AI 行业动态"拆成"抓取这几个网站 + 过滤重复 + 按主题聚类 + 生成摘要 + 推送到群"这样的子任务序列。
- 调用工具：通过内置的工具注册机制，把飞书、HTTP请求、脚本执行、数据库操作都暴露成可调用单元。
实际体验下来，OpenClaw 的定位和写死流程的脚本有一个本质区别：后者是"定时跑一遍固定代码"，前者是"根据当前触发条件动态决定跑什么"。比如同样收到一条飞书消息，如果内容是"今天有什么值得关注的"，它会走检索流程；如果内容是"把上周提到的那个项目进展整理发我"，它会先查表再组织语言再推送。这个灵活性是脚本给不了的。
2. 部署与初始化：把运行环境一次搞定
OpenClaw 的部署方式在不同的平台差距很大，官网也一直在更新。最省事的方式是用 Docker 跑服务端，Windows 上用 Companion 做配套交互。如果你的机器是 Linux，直接用 Docker 镜像即可；如果主力是 Windows，建议先装好 WSL2 再走 Docker 路线，Windows 原生跑 OpenClaw 目前还有部分系统调用兼容问题。
初始化阶段有一个必须要做的动作：配置大模型接入。OpenClaw 本身不携带模型，它的推理和规划全部依赖外部大模型 API。这一步在配置里指定 API 地址和模型名称就行，填好之后可以通过内置的对话命令验证是否连通。我在部署时报错最多的地方就是网络代理和 API 地址写错，这两个问题排查时优先看日志里的请求记录。
部署完成之后，把飞书应用也顺手建好。你需要一个企业自建应用，在飞书开放平台创建，拿到 App ID 和 App Secret。这两个凭据是后续所有 API 调用的钥匙。部署 OpenClaw 时准备一个目录专门放配置文件和技能定义，我自己的习惯是：
openclaw/ ├── config.yaml ├── skills/ │ ├── fetch_rss/ │ ├── fetch_web/ │ └── feishu_push/ └── logs/这个结构方便后续加技能。技能（Skill）是 OpenClaw 的插件机制，每个技能可以定义自己可以处理哪些输入、执行哪些命令。配置正确之后，启动服务会看到类似"已注册 N 个技能"的日志输出，到这里基础设施基本就位了。
2.1 Docker 部署的正确姿势与避坑
如果机器上已经装了 Docker，拉取镜像其实没什么难度，真正的坑在启动参数。OpenClaw 需要获取宿主机网络能力来做 HTTP 请求，所以启动时不能只映射 API 端口，还要给它配置好网络模式。我自己用的是 host 模式，这样所有出网请求都走宿主机网络，不容易出现容器内 DNS 解析不了的问题。
另外要注意配置目录的挂载。OpenClaw 的配置和行为日志最好落到宿主机上，不然容器一删配置全没了。挂载的时候，把刚才那个 openclaw 目录整体映射进去，之后改配置、加技能都不用进容器操作，宿主机的编辑器改完重启服务即可生效。
这里吐个槽：OpenClaw 的 Windows 原生版确实还有不少小毛病，日志里经常出现检测不到 WSL 状态的提示，但实际功能不受影响，如果你在 Windows 下部署遇到类似提示，不要慌，优先检查你的 Docker Desktop 是否正常。
2.2 飞书企业自建应用创建流程
创建飞书应用不需要写代码，在开放平台上按引导填名称、描述、图标就能建出来,但有几个细节容易被忽略：
- 权限开通：发送消息需要的权限是
im:message:send_as_bot，读取多维表格要开通bitable:app:readwrite，这些权限不是创建应用时自动带的，需要手动添加并发布版本。 - 应用发布：企业自建应用需要"创建版本并发布"，发布后企业内成员才能看到这个应用。如果只有你一个人用，发布范围选最小即可。
- 机器人启用：应用创建成功后，需要进入"添加应用能力"里启用机器人，否则后面发消息会报"bot disabled"。
我遇到过最尴尬的一次是权限全部开通了，但忘了发布版本，结果机器人能收到事件回调，发消息却一直声称没有权限。检查的顺序是：应用是否发布 → 机器人是否启用 → 具体权限是否授予。
3. 情报采集与清洗：OpenClaw 技能的实战设计
采集层是整个情报站的入口，也是工作量最大的一块。前面说了，OpenClaw 通过技能来抽象采集能力，实际落地时我会把采集动作拆成几类技能：RSS 抓取、网页正文解析、关键词过滤。
RSS 抓取技能是我最先实现的。它的逻辑很简单，读一个 URL 列表，逐个抓取 RSS feed，解析出标题、链接、发布时间，丢给下一步处理。OpenClaw 里跑这样的技能不一定非要写复杂工具，一段 Python 脚本就够，关键是注册成技能后能让 Agent 在需要时自动调用。
网页正文解析技能处理的是没有 RRS 的站点。这类站点需要用 HTTP 请求把 HTML 拉回来，再用正文提取算法扒出核心段落。实现时不要用正则硬抠，正文结构一改你的正则就废了。推荐用 readabilipy 或类似库，它们基于文本密度和标签特征做正文提取，准确率高得多。
关键词过滤技能是保证情报质量的关键。我的做法是维护一个白名单和黑名单：白名单决定哪类词命中后保留，黑名单决定哪类词命中后丢弃。这个技能不是简单判断"标题里有没有包含"就完事，它会综合标题、摘要、正文三类信号，给每条内容打一个 0-100 的分数，低于阈值直接丢。这样的策略比单一关键词判断要稳，也更容易根据反馈去调。
3.1 技能注册机制与调用原理
在 OpenClaw 里新增技能的套路很统一：写一个目录，里面放描述文件和实现脚本。描述文件记录技能的名称、可处理的任务类型、参数 schema,实现脚本是实际执行的代码。Agent 在接到任务后，会先读所有技能的描述，选出能处理当前任务的技能，然后按参数 schema 生成调用参数执行。
这里有个原则想提醒一下：技能粒度不宜太粗。别想硬塞一个"全能采集"技能进去，让它同时管抓取、解析、过滤，这样每次运行都容易失控。拆成单一职责的小技能，Agent 的规划可解释性强，出问题时也更容易定位是哪个环节坏了。
3.2 清洗规则的落地细节
实现清洗规则时，我强烈建议把规则外置成独立配置文件，别写在代码里。比如：
rules: - name: "drop_ads" type: "regex" pattern: "广告|推广|软文" action: "drop" - name: "boost_core_word" type: "contains" keywords: ["智能体", "Agent", "大模型"] score: 20外置的好处是你调整规则时不用改代码、不用重启服务，改完配置刷新技能参数就行。OpenClaw 的技能设计支持读取外部配置，充分利用这个机制能让后期的维护成本降一大截。
清洗这块还要注意时间处理。RSS 里的时间格式五花八门，解析时需要统一转成时间戳。如果不做这一步，后面按时间排序、按天聚拢都会出问题。我最初踩过这个坑，所有文章混在一起，根本没法做"每日热点"。
4. 飞书机器人接入：从发送消息到卡片模板
飞书机器人是情报站的"最后一公里"。接入的核心是调用飞书开放平台 API 发送消息，其中最关键的是im/v1/messages这个接口。以一个最简单的文本消息为例，请求格式大致如下：
POST https://open.feishu.cn/open-apis/im/v1/messages Authorization: Bearer {tenant_access_token} Content-Type: application/json请求体里需要指定receive_id（接收方 ID）和msg_type（消息类型），如果是文本消息，content 字段传 JSON 序列化后的字符串。如果你只是发一段文字，到这里就够了。
但情报站不应该只发文本。前面我强烈推荐了消息卡片，这里就展开说一下它的价值。
4.1 代码示例：OpenClaw 调用飞书 API 发送文本消息
在 OpenClaw 的技能脚本里，调用飞书 API 的核心是拿到tenant_access_token。这个 token 用 App ID + App Secret 换，有效期一般是两小时，建议缓存下来避免频繁请求。
以 Python 为例：
import requests def get_tenant_token(app_id, app_secret): resp = requests.post( "https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal", json={"app_id": app_id, "app_secret": app_secret} ) return resp.json()["tenant_access_token"] def send_text(open_id, text, token): resp = requests.post( "https://open.feishu.cn/open-apis/im/v1/messages", headers={"Authorization": f"Bearer {token}"}, json={ "receive_id": open_id, "msg_type": "text", "content": json.dumps({"text": text}) } ) print(resp.status_code, resp.json())注意receive_id是接收者的 open_id，不是手机号也不是邮箱。open_id 可以通过飞书后台的管理员接口查询，也可以在机器人收到事件时从事件体里取。自建应用默认的接收方类型是 open_id，刚开始调试时不要搞混。
4.2 消息卡片模板：让情报一目了然
一张好的情报卡片大概长这样：顶部是标题和来源站点，中间是 AI 生成的摘要，下方是发布时间和一个"查看原文"的链接按钮。这些在飞书卡片里都能实现。
卡片的 JSON 结构我简化一下给你看：
{ "config": {"wide_screen_mode": true}, "header": { "template": "blue", "title": {"tag": "plain_text", "content": "AI 行业动态 · 2025-01-14"} }, "elements": [ { "tag": "div", "text": { "tag": "lark_md", "content": "**关键词：** 大模型、智能体\n智能体编排框架本周迎来多项更新，多家厂商发布新版本..." } }, { "tag": "div", "text": { "tag": "lark_md", "content": "**来源：** 36氪 | **时间：** 08:23" } }, { "tag": "action", "actions": [ { "tag": "button", "text": {"tag": "plain_text", "content": "查看原文"}, "type": "primary", "url": "https://example.com/article/123" } ] } ] }headers 里的 template 可以控制颜色，情报类的消息建议用蓝色，日报用绿色，紧急用红色，团队里扫一眼颜色就能判断优先级。卡片里的文本区域支持lark_md标记，部分 Markdown 语法能用，足够满足日常需要。
把这段 JSON 放进msg_type为interactive的消息里发送，就能在飞书里看到一张完整的情报卡片。OpenClaw 里实现卡片推送时，我习惯把卡片模板也外置成配置，不同情报类型对应不同模板，这样加新栏目时只加一个 JSON 文件就行。
5. 定时任务与主动触达：把情报站从玩具变成工具
机器人调通了、卡片也会发了，但如果每次都要手动在飞书里发消息触发，那还算不上自动化。真正让情报站"活了"的关键是定时任务。
OpenClaw 支持配置定时任务，我最常用的是 cron 表达式。比如每天早上 9 点自动执行"昨晚今晨重要新闻整理并推送"这个任务，cron 配置大概是：
0 9 * * * /run_daily_digest配置的位置在 OpenClaw 的配置文件里，每个定时任务指向一个技能名称或一组会话模板。执行时它会按顺序调用采集、清洗、摘要、推送几个技能，全部完成后在日志里留一行"任务执行完毕"。
定时任务真正跑起来之后，你需要关注两件事：执行耗时和失败重试。如果一次执行涉及十多个站点的抓取，耗时可能超过两分钟，cron 任务的超时阈值要留足。失败重试方面，OpenClaw 支持给任务配置重试次数，我建议至少设置 2 次重试，间隔 30 秒。另外，定时任务执行完的日志一定要保留，不然出问题时根本不知道是哪一步断了。
5.1 设定定时任务注意事项
如果要让定时任务长期稳定跑，务必要关注宿主机的睡眠设置。电脑若是合盖休眠，cron 任务直接不执行，第二天早上群里空空如也。我一开始踩过这个坑，后来把 Windows 的电源计划改成了"从不睡眠"，Docker 服务也设置为开机自启，才算彻底稳住。
还有一点是时间源问题。OpenClaw 容器里的默认时区是 UTC，如果你直接写0 9 * * *，它会在 UTC 9 点执行，也就是北京时间的下午 5 点。血泪教训：配置 cron 前一定先确认时区，最好是容器启动时挂载/etc/localtime，或直接在环境变量里指定TZ=Asia/Shanghai。
5.2 手动触发与被动响应场景
定时任务之外，情报站还可以响应飞书群里的指令。OpenClaw 接入飞书事件回调以后，用户在群里 @ 机器人并发送"今天有什么重要信息"，机器人会触发一次检索任务，把结果直接回复到群里。这个机制让情报站不只是一个闹钟型的定时推送工具，它还能实时响应群里的提问。
这个被动响应能力的实现路径是：飞书把消息事件推送给公网可达的回调地址 → OpenClaw 解析消息文本 → 匹配到对应技能 → 执行并发送结果。如果回调地址不好搞定公网穿透，也可以用飞书的 Webhook 模式，定时从某个接口拉取待处理消息，虽然没有实时性限制但架构上省事很多。
6. 三个常见故障排查与优化实录
情报站上线之后，最花时间的往往不是写新功能，而是排查各种偶发问题。这里把我踩过的几个典型故障整理成速查表，供你对照。
| 现象 | 核心原因 | 解决方式 |
|---|---|---|
| 机器人能收不能发 | 权限未发布或 token 过期 | 检查应用版本状态，确认权限已发布 |
| 定时任务没执行 | 时区不对或电脑休眠 | 设置 TZ 环境变量，调整电源计划 |
| 卡片显示为纯文本 | content 未正确序列化 | 确保 content 字段是 JSON 字符串 |
| 抓取到的文章大量重复 | 没有做去重 | 引入 URL 哈希 + 标题相似度判断 |
| OpenClaw 启动时提示 WSL 状态异常 | Windows 环境检测误报 | 检查 Docker Desktop 是否正常 |
6.1 最难排查的消息丢失问题
有一类问题比报错更让人崩溃：日志显示任务执行成功，推送接口返回了 200，但飞书群里就是看不到消息。我排查了将近两个小时才发现，是因为消息卡片里某个字段内容超长，触发了飞书服务端的 IM 风控，消息被静默拦截了。
遇到这种问题，最有效的排查方式是在推送代码里打印完整的响应体，而不是只看 HTTP 状态码。飞书接口即使返回 200，响应体里可能有code != 0的错误码，那才是真正的失败原因。另外一个经验是：第一次测试推送时，先发一条极短的文本消息验证链路通断，再上完整卡片模板，可以减少很多干扰因素。
6.2 去重机制：防止情报噪音
情报站跑了一周后，你会发现大量重复内容。同一个新闻，可能五个源都发了，RSS 抓回来五条标题几乎一样的条目。去重不能只靠标题精确匹配，因为有些源会改标题党风格。我的方案是两层：第一层对 URL 计算哈希，重复 URL 直接丢弃；第二层对标题做归一化处理——去掉空格、统一简体、截取前 20 个字——再计算文本相似度，超过阈值就视为重复。
这个能力我同样放在一个技能里，清洗管道最后一步会调用它。实现用的是 Python 的hashlib和difflib，几十行代码就够，不需要引入重型的向量数据库。
6.3 推送频率与内容质量平衡
最后聊一个产品层面的问题：推送频率定多少合适。想清楚这个问题之前，我先定了默认策略——每日一推，时间在早上 9 点。但跑了半个月后，团队反馈早上的信息密度太低，大家上午往往在开会，根本没时间细看。于是我把推送时间调整为早 8 点和下午 2 点两次：早上给的是昨日夜间到今晨的速览，下午给的是上午的市场变化。
调整策略的时候只要在定时任务配置里把 cron 表达式改一下就行，完全不用动采集和推送代码。OpenClaw 的定时任务配置虽然简单，但配合技能后能覆盖非常灵活的场景。这一点我体验下来感觉是它相比传统脚本最有价值的地方：策略调整成本极低，试错成本几乎为零。
7. 更进一步：把情报站扩展成团队知识中枢
情报站跑稳之后，自然会产生一个想法：这些收集到的内容不能只活在会话里，它得积累成团队可复用、可检索的知识资产。这里我用了飞书多维表格做落库，打通了 OpenClaw 到多维表格的写入链路。
多维表格的使用逻辑很简单：建一个数据表，字段包括标题、链接、摘要、来源、标签、抓取时间，OpenClaw 每次完成推送后顺手调一次 API，把数据写入。对飞书开放平台而言，写多维表格走的是bitable系列接口，核心请求也是在 token 基础上加数据表 ID，复杂度不高。
这一步扩展的价值在于，情报站从"发生了什么"进化成"曾经发生什么、趋势如何变化"。比如你两周后想评估"最近智能体话题的热度是不是起来了"，直接查多维表格统计条目数和标签变化就行，不用再懊悔当初没存数据。
如果把 OpenClaw 的定时任务能力再加进来，每晚可以让它自动对当天的数据做一次汇总统计，生成日报卡片，同步到群里。这套体系叠完，情报站的定位就从工具变成了有记忆的团队助手，这可能是这个项目最有意思的地方——它解决的不只是"今天的消息没漏掉"，还有"三个月前那个线索到底埋在哪"。
根据我做这几期系列的经验，自动化项目尽量不要一上来就追求大而全。先把一条最简单的链路跑通——比如每天定时抓一个源、推一条文本消息——然后逐步做厚。每一步改进都有明确反馈，系统稳定性和团队接受度都会更好。飞书和 OpenClaw 都是在快速演进的项目，文档不一定跟得上实际进度，遇到问题时多翻接口文档、多打日志，往往比搜教程更直接。
