最近在折腾情报收集的老哥应该都有同感——每天打开十几个资讯源挨个翻文章、看更新、手动转发到群里这套流程看着简单真正跑起来又耗时又容易漏。我一开始也想偷懒用现成工具凑合后来发现要么只能盯一两个平台要么推送格式丑得没法看。折腾几轮之后干脆自己动手搭了一套飞书 × 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: fBearer {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或直接在环境变量里指定TZAsia/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 都是在快速演进的项目文档不一定跟得上实际进度遇到问题时多翻接口文档、多打日志往往比搜教程更直接。