用OpenClaw智能体解析机构群聊：把卖方段子结构化，自动生成投研信号

如果你也常年在各种机构交流群里潜水，大概率见过这种名场面：卖方刚发完一份八十页深度报告，群里鸦雀无声，转头有人甩了个“段子”，一会儿功夫刷出两百条消息。这种“报告没人看、段子刷屏”的现象，本身就是很值得琢磨的信号——它说明大家真正关心的、愿意私下讨论的东西，往往藏在那些看起来不正经的只言片语里。我持续观察了挺久，决定把这件事做成一套工具：用微信API接上机构群的聊天消息，让 OpenClaw 智能体做分类、清洗和打分，把群里的“卖方段子”和碎片点评，自动变成带时间戳、带置信度、带关键词关联的投研信号。

这套东西做出来之后，我最大的感受是：不是段子更有信息量，而是段子代表了“情绪共识”和“第一手消息”，它的时效性碾压研报，只是以前没人把它当结构化数据看。如果你也在做投研支持、量化因子挖掘、或者单纯想减少刷群的时间，这篇内容应该能帮到你。下面我按“采集清洗-智能体分析-信号落地-踩坑复盘”的顺序，把整套方案完整拆开讲清楚。

1. 项目概述：机构交流群里的“信息熵”到底被谁埋没了

1.1 卖方段子为什么能成为投研信号

“卖方段子”不是一个严谨概念，但在机构群里混久了，你一眼就能认出来：它可能是一段两行的点评，可能是一个“听某大佬说”的传闻，可能是一张带有调侃色彩的图片配文，也可能是研究员深夜转发的行业八卦。共同点是：话不多、情绪足、时效性强、指向性明确。

它到底有没有投研价值？我的判断是，它至少包含三类有效信号。第一是“情绪侧写”，一个板块或者一家公司被反复调侃，说明市场关注度已经聚集，这本身就是热度的直接度量；第二是“消息线索”，很多段子背后都有真实调研访或者内部交流的影子，比如“某公司董秘今天很乐观”这类措辞，本质上是一条未被验证的信息；第三是“群体记忆点”，卖方段子的传播依赖圈内共识，能被刷屏的东西，往往已经过了很多人的脑内交叉验证。

传统做法是让研究员每天手动爬群、记小本本，但这非常浪费人力，而且人眼在看群聊时天然会有“幸存者偏差”——你只会记得那些让你印象深刻的段子，却会漏掉大量低频但同样重要的信号。所以我需要一套自动流程，先把所有消息无差别收下来，再让程序做客观的筛选、分类和打分。

1.2 系统的四层架构是什么思路

整个系统我设计成了四个逻辑层：消息接入层、数据清洗层、智能体分析层、信号输出层。接入层解决“消息从哪里来”，清洗层解决“消息乱不乱”，分析层解决“消息该怎么理解”，输出层解决“理解之后怎么办”。

为什么要用 OpenClaw 智能体而不是自己写一堆调度脚本？因为这里的“分析”不是简单跑一下正则就能完成的，它需要做多步骤的决策：先看这条消息属于哪一类，再看它是不是有信号价值的“段子”，然后判断强度、提取关键词，最后决定要不要推送。这本质上是一个任务编排问题，智能体能自动帮我拆解步骤、调用工具、记录上下文，省掉了大量“if else”胶水代码。

另外我刻意没有把系统的重心放在“自动交易决策”上，而是放在“投研信号”上。这个定位非常关键：信号是给人看的，最终的验证和决策必须留给人来把关。

2. 消息采集与底层清洗：先把“群聊噪声”压到最低

2.1 三种合规采集方式与选择

聊到微信API采集群消息，首先要过的一道坎是合规和权限。这里我梳理下来，主流有三种方式，亲测风险和成本差别非常大。

第一种，企业微信会话存档接口。这是最稳妥的路子，需要企业管理员开通会话存档权限，然后配置回调地址来接收群聊消息。优点是接口稳定、消息字段完整，包含群ID、发送人、消息类型、消息原文、时间戳；缺点是开通审批流程比较麻烦，有些公司IT部门会卡权限。第二种，自建内部群机器人转发。如果你自己拥有一个企微群的机器人权限，可以让群成员手动把感兴趣的消息转发到“收集群”，系统通过机器人webhook接收。这种方式工作量小、侵入性低，但依赖成员配合，而且只能拿到转发过来的内容。第三种，个人号自动化方案。市面上一些框架能直接控制个人微信收消息，但风险很高，容易被封号，而且涉及非官方协议，我不推荐把它放在生产环境里。

我自己最终采用的是“会话存档接口为主、群机器人webhook为辅”的组合方案：重要核心群走存档接口，外围讨论群靠成员自愿转发。这样既保证了核心数据完整，又避免了对全量群做过高权限申请。

注意：无论选哪种方案，都要先跟公司合规部门确认使用边界。尽量走官方接口，不要碰非官方协议，否则后面出了安全问题整个项目都得推倒重来。

2.2 文本清洗与去重：防止“刷屏消息”污染信号库

机构群的消息有个天然特点：同一份纪要、同一个段子，会被不同的人反复转发。如果不做去重，后面的词频统计完全没法看，一个热门段子会被重复20次，系统误以为全世界都在讨论这个标的。

我的清洗管道分成了三步。第一步是按消息ID去重，这条最简单，企微每条消息自带MsgId，直接查数据库去重；但问题在于群机器人转发过来的消息，MsgId可能会变化，所以还需要第二步，内容哈希去重：对消息正文做MD5，再结合时间窗口判断，如果同一段文本在24小时内出现过两次以上，就标记为重复。第三步是相似度去重，这一步用来处理“同一条公告被不同人转述，措辞略有差异”的场景，我用了simhash算法，计算两个文本之间的汉明距离，低于一个阈值就认为是近似重复。这三步跑下来，重复消息的过滤率能到80%以上。

文本规范化也很重要，尤其是从聊天软件里拿到的文本，经常存在全角半角混杂、换行多、繁体简体不一致的问题。我会做几个固定操作：全角字符转半角、把所有空白字符统一成空格、繁体转简体、去掉无意义的表情符号和回复类“收到”“赞”“+1”等噪声词。

2.3 非文本消息怎么办：OCR和语音转写

机构群里至少有三分之一的消息是图片和文档，比如卖方PPT截图、调研现场照片、聊天记录截图、会议纪要PDF。如果只处理文本，等于放弃了一大块信息源。我的做法是用OpenClaw智能体编排一层“视觉理解管道”：图片消息先走OCR识别文字，再进入后级分析；PDF和PPT转成图片后抽帧OCR；语音消息则走ASR转写。

这里有个成本控制的小技巧：不要对所有图片都做OCR，先用图片分辨率、发送人、文字量做预筛选，只有包含足够多文字或由研究员账号发出的图片，才走完整OCR流程。我实测下来，这样能把OCR成本压缩到原来的四分之一。

还要强调一个细节：OCR出来的文字往往没有标点、没有分段，直接喂给后续模型会降低分类效果。所以我会在OCR后加一段“标点恢复+句段切分”的处理，用LLM做轻量级重排版，而不是原样保存。

3. 智能体如何把“段子”拆成“信号”：分类、识别与打分

3.1 消息分类：先规则后模型，双保险降低成本

消息进来到分析层之后，第一步是分类。我定义了这些类别：宏观政策、行业点评、个股推荐、路演纪要、调研纪要、行业数据、传闻段子。再加上一个“其他”兜底，一共八类。

分类策略我用的是“规则先行，模型后置”的级联方式。规则层写了一批关键词和正则，比如出现“央行”“降准”“LPR”就直接标记宏观；出现“调研”“反路演”就标记调研纪要。规则层处理掉大约50%的消息，剩下的模糊消息才交给LLM来判断。这不仅是准确率问题，更是成本问题——给每条消息都调一次LLM，按机构群的日活消息量算，费用不低。规则层能接住的绝不动用模型。

LLM分类时我会在提示词里要求它输出一个严格的JSON结构，包含类别、关键词列表、消息可信度、是否值得深挖四个字段。还有一个细节：分类需要结合群特征。不同群的语境不一样，同一个词在“固收群”和“股票群”里的含义完全不同，所以我会把群ID作为一个额外字段传给模型，让它在分类时做对照。

3.2 段子识别：看结构特征，看风险提示缺失

区分一段话是“正经报告”还是“段子”,对模型来说比想象中难。因为很多卖方言辞本身就很夸张，而有些段子反而用最平淡的口吻讲出来。我总结下来，段子通常有三个特征：结构上有人物和动作，比如“某基金经理今早买完就开始慌了”，这是一种叙事结构，而正经研报一般不会这样写；第二是没有风险提示，卖方正式材料结尾都会有标准风险提示，但段子不会；第三是高频使用“调侃式限定词”，比如“纯属瞎猜”“故事纯属虚构”“如果打脸别怪我”“这波叫信仰充值”。

我的识别逻辑是先把这些特征做成规则特征库，快速筛出候选段子。凡是命中规则库的，直接进入“待打分”状态；没命中但被LLM判断为“疑似段子”的，再追加一轮人工语义校验。

这里要特别小心一类“洋葱段子”：它看起来是段子，实际上是一个严肃的产业动向，只是用了一个幽默的壳。反过来也有看着像真消息，实际上是开开玩笑的。我解决这个问题的方式是“交叉验证”：如果某条被判定为段子的消息里出现了某个实体名词，并且该实体在当天其他正常消息里也出现了，我就会把它单独标记为“有共识潜质的信号”，而不仅仅扔进段子库。这个交叉验证字段，是我觉得整个项目里最有价值的一个设计。

3.3 打分模型：三个维度加权，输出可排序信号

分类和识别都只是过程，最后的产出是一个带分值的信号。我设计了一个三轴打分模型，分别是“强度分”、“置信度分”和“情绪分”。

强度分衡量的是“这条信息值不值得被看到”。我的计分规则包括：如果某关键词或实体在过去7天内第一次出现，加20分，初始热度低而突然出现，往往代表新逻辑要发酵了；如果同一个实体在半小时内被3个不同群聊同时提到，加30分，这代表多群共识；如果消息来自高频发核心观点的研究员账号，加10分。置信度分衡量的是“这条信息靠不靠谱”，判断维度包括消息里有没有明确信息来源、有没有具体时间地点、有没有引用数据。情绪分则用模型判断极性，给出-1到1之间的分数，同时记录情绪波动方向。

最后输出时会做一个加权，比如总分 = 强度分 * 0.4 + 置信度分 * 0.4 + 情绪分 * 0.2。总分超过阈值才会进入推送队列。我给一个实际例子让你感受一下。某条段子内容是：“午后跟某龙头公司交流了下，管理层话里话外语气特别自信，问了下排产，下半年基本满的，大家自己品。”这条的强度分给到85，因为“龙头公司”在当天是首次提到且半小时内被三个群转发；置信度给到70，因为有人物动作、交流方式但没有具体数据；情绪分是0.75，明显偏正面。最终加权之后，它成为当天最高级别的信号之一。

{ "signal_id": "S20250114132001", "source_chat": "某电源设备产业群", "category": "传闻段子", "entities": ["某龙头公司"], "score": { "strength": 85, "confidence": 70, "sentiment": 0.75, "final": 77 }, "trigger_rules": ["首次出现", "多群共现"], "raw_message": "午后跟某龙头公司交流了下..." }

这个JSON结构会进入输出层，作为后续推送和记录的基础。

4. 信号落地的样子：推送、周报和命中率闭环

4.1 输出格式：机器可读与人类可读双轨

光有JSON结构还不够，投研岗的人不可能天天开着监控看数据流。所以我做了一套“双轨输出”：结构化的JSON写进数据库，用于回测和统计；可读性强的文本推送到微信工作群，用于人工快速浏览。

推送到群里的文本，我会尽量模仿一个有经验的研究助理口吻来写，格式类似这样：“10:35 信号提醒 | 某光伏辅材概念热度突增，触发首次出现+多群共识。情绪偏正面，置信度中等。原始来源：三群交叉链接。建议关注后续排产数据更新。”开头带上时间，中间写明触发原因，结尾指明讨论方向。这样做的好处是，研究员一眼就能决定要不要点开详情，不需要帮消化原始消息。

机器可读的部分也不只是存JSON，我会额外建一张宽表，把关键字段全部展平，方便后面直接写SQL查询。字段包括消息日期、信号类别、实体名、原始消息、所属群、触发的规则、最终分数、验证状态。这一步看似简单，但如果你一开始只存嵌套JSON，后面做周报统计时会非常痛苦，SQL没法直接聚合。我从一开始就做了展平，省了很多后续功夫。

4.2 推送策略：别让信号变成新的噪声

信号系统最怕什么？最怕变成又一个刷屏的群。所以推送策略必须比消息本身更克制。

我设计了三个控制规则。第一是时间段限制，只在早盘前、午间休市和收盘后三个时段推送，盘中紧急信号走单独的“高频通道”，数量严格限制在每天最多5条以内。第二是分组推送，普通信号只推给“信号接收组”，高置信度信号才会同步给核心研究员和投资经理，避免每人每天看到几十条消息产生麻木。第三是自动静默，如果某条信号在2小时内被系统判定为“已过时”，比如已经有官方公告发布，就自动撤回之前的推送。

关于“撤回”有一个技术细节：企业微信群机器人的推送消息不支持直接撤回，所以我用“补充推送”而非“删除推送”来处理。系统会追加一条“上一条信号已由官方信息佐证，请以官方数据为准”的提示。虽然不如撤回干净，但至少避免了错误信息被一直晾在那里的尴尬。

4.3 信号池与命中率记录：让系统自己进化

好信号系统必须能自证价值。所以我在输出层之外加了一个“信号池”机制：所有超过阈值的信号都会进入池子，每一条都带一个验证状态，未验证、待验证、已生效、已证伪。

在每个交易日收盘之后，系统会拿当天池子里的信号和实际行情做对照。如果某条信号提到的实体收盘涨幅显著、或者盘中异动，就把状态更新为“已生效”，否则标记“待观察”。每周五系统会把这一周的信号清单、命中率、时效分布做成一张周报图，推送给核心用户。我用这套机制跑了大概一个月，发现两个有意思的结论：第一，命中率最高的不是情绪最强烈的段子，而是那些“置信度中等但多群共识很强”的信号，这种信号出现后往往在3到5天内有行情反映；第二，宏观类段子虽然传播量最大，但实际交易价值反而最低。这个结论直接让我在后面调整了加权公式，把宏观类信号的权重下调了10个百分点。

5. 部署过程中的坑和取舍（实操复盘）

5.1 接入层的三个坑：权限、签名、回调重放

第一个坑就是会话存档的权限申请。我在某企业内部申请会话存档开通的时候，被要求提交“消息使用边界说明文档”，要写清楚存什么、谁能看、多长时间销毁。这一关特别容易被忽视，大量技术人以为拿到API就万事大吉，结果卡在审批流程上一两周。我的建议是，申请材料里一定要写清楚“仅用于内部投研辅助，消息明水不落地超30天”，审批会顺利很多。

第二个坑是回调接口的签名校验。企微会话存档的JSON回调需要对消息体做SHA256签名校验，我一开始忘了校验签名，结果安全扫描直接被扣分。实现的时候务必把Token和EncodingAESKey的解析逻辑单独建一个模块，别跟业务代码混在一起，后面排查问题能省很多时间。

第三个坑是回调重放。企微为了可靠性，可能会在同一事件上重试多次回调，导致端到端的重复消息进入分析管道。去重机制虽然能拦文本内容，但重放导致的重复调用也会引发群机器人webhook重复推送。解决办法是对回调事件里的EventId做全局唯一键，数据库加唯一索引，重复请求直接在入口丢掉。

5.2 消息质量相关的坑：OCR乱码、长文截断、图片尺寸超限

群里图片五花八门，OCR出来的文字质量参差不齐。最典型的问题是白字黑底的小字截图，比如把数据平台的深色模式界面截图发进来，OCR识别率会直线下降。我后来索性对这类图片先做反色和对比度增强，再做OCR，识别率能提高不少。

还有一个非常容易踩的坑是文本长度限制。企业微信机器人webhook推文本消息的单条上限是2048字节，而LLM分析出来的长段子原文经常超过这个量。我一开始没有做截断，导致推送失败。最终的处理方案是“摘要前置，原文链接后置”：推送消息只带200字以内的摘要，需要看原文的人点开详情页，详情页通过后端接口从数据库读取原始消息。

图片尺寸超限的问题多半出现在OBS录用的PPT截图，动不动就5MB，传输到OCR服务时会超时。我的处理方式是先把图片压到最长边1600像素，再转成PNG统一格式。实测下来压缩到200KB左右时，OCR准确率几乎没有下降，速度却快了很多。

5.3 成本与延迟的取舍：LLM调用不是越多越好

这套系统最大的隐性成本是LLM调用费。如果不加控制，每天几千条消息全部跑一遍LLM，账单会让你怀疑人生。

我的控制策略有四个。第一，规则层能判断的消息绝不调用LLM，只有需要分类或者需要打分的信息才走模型。第二，对同一群内同一实体的多条消息做聚合，把半小时内关于同一实体的消息合并成一条摘要，再进模型分析，而不是逐条处理。第三，设置模型缓存的TTL，同一个关键词组合在一小时内命中过结果，直接走缓存。第四，遇到LLM接口超时直接降级：如果分类模型超时，就按规则层的结果继续，如果打分模型超时，就给一个默认中等分，宁可推送范围收窄，也不能让管道卡死。

延迟优化上，我把LLM由同步调用改成了异步队列。消息进来先落库，然后立刻返回“已接收”，分析过程在后台队列里跑。实测一条消息从入库到产生信号，平均延迟大约15秒到40秒，对盘后复盘场景完全够用。真正需要盘中的秒级响应，才会走单独的紧急通道。

6. 常见问题速查表与后续扩展方向

6.1 常见问题速查表：从现象直接定位原因

6.2 可以继续扩展的方向

目前这套系统的数据源还集中在“文字/图片为主的群聊消息”，下一步可以往三个方向延伸。第一个方向是接入会议系统和路演录音，把线上会议的ASR转写文本也丢进智能体分析管道里，这样调研纪要和路演纪要就能自动归类；第二个方向是接入数据库做历史回测，把过去一年的历史信号对应当年的行情数据，量化计算出不同信号类型的累计净值表现，给自动打分模型做特征拟合；第三个方向是做“消息溯源地图”，把同一个信号在不同群、不同时间点的传播路径画出来，看看哪些账号是早期传播节点，这对判断信号真伪很有参考价值。

如果你想先做一个轻量版本，不需要企业微信会话存档权限，完全可以简化成“单群机器人接收 + 脚本处理 + 群推送”的模式。先用一个小群把流程跑通，再慢慢补权限和自动化能力。就是这个思路，从一条段子开始，让它变成你投研路上真正有用的信号。

我个人在搭建这套系统的过程中，最大的体会是：信号系统的难点不在于AI能力的上限，而在于你愿不愿意接受“大量消息是没有用”的默认前提。只有承认噪声是主流，你才舍得在上面花代价做清洗。后来我还把阈值调得更严格了一些，宁可少推几条，也不为凑数量牺牲质量。毕竟在一个信息过载的环境里，能克制地说“这条值得看”，本身就是一种稀缺能力。