简介：太平洋证券《AI投研应用系列之四：OpenClaw投研实践——从部署到应用》是一份面向金融投研人员与AI应用开发者的实战报告，解决开源框架OpenClaw从环境搭建到投研场景落地的关键问题。报告对比纯本地、WSL2+云端模型、纯云端三种部署方案的适用场景与优劣，并以WSL2+云端模型为例演示完整配置流程；数据源部分详解Tushare、AkShare等金融数据Skill的接入方法。应用实践涵盖持仓监控报告推送、量化策略回测与行业动量+拥挤度轮动测试、前沿因子挖掘三大场景，也提示了大模型生成脚本可能存在的偏差与数据安全风险。整份资料为1个PDF文件，大小约2MB，便于移动端或桌面端阅读，目前已有100人学习下载。阅读后可获得OpenClaw部署选型思路、飞书集成与常用指令、金融数据源配置及因子挖掘Agent构建方法，适合希望将AI智能体引入日常投研工作流的技术型研究员。
1. 从「研报标题」到「能跑的链路」：OpenClaw投研实践在解决什么
券商研究所的日常工作里，公告解读、纪要整理、数据交叉验证这三件事吃掉了一半以上的人工工时。OpenClaw投研实践想解决的，正是这三件事的自动化：把开源Agent框架OpenClaw部署到本地，把投研规则拆成可复用的技能，再让它按固定流程产出纪要。这个标题挂在「AI投研应用系列」下面，指向的不是又一个聊天机器人，而是一条从部署到应用的完整链路。
这套实践适合三类人：被公告淹没的基本面研究员、想把AI接入内部系统的金融科技工程师，以及所有受够了「大模型只会聊天」的团队负责人。读完你会知道，OpenClaw落地的最短路径是什么，参数在哪里调，以及哪些坑值得在动手前先避开。
2. 部署 OpenClaw 前的选型：本地模型还是 API，为什么我从 Ollama 起步
2.1 投研场景下先定推理后端：数据边界决定模型放哪
部署 OpenClaw 的第一步不是装框架，而是定推理后端。投研材料里有大量未公开信息、内部纪要、尚未发布的评级草稿，这些内容不适合逐条送到外部 API 去跑。所以我建议的默认组合是：OpenClaw 本体跑在 Docker 里，推理后端用 Ollama 拉起一个本地大语言模型，API 只留给那些确实不敏感、且本地模型搞不定的场景。
| 推理后端 | 适合场景 | 主要代价 | 投研推荐度 |
|---|---|---|---|
| Ollama 本地模型 | 内部纪要、未公开公告、离线环境 | 7B 模型能力有限，需要 16GB 以上内存 | 高 |
| OpenAI 兼容 API | 公开研报摘要、英文财报翻译 | 数据出域，有合规争议，按量计费 | 中 |
| 内部托管的模型服务 | 已有 GPU 集群或公司统一模型平台 | 需要运维，接口标准不一 | 高（有条件时） |
这里要说明白：OpenClaw 本身不绑定某个模型，它只负责把任务路由给后端。常见做法是在配置文件里维护一个模型列表，把「读公告」路由到本地 14B 模型，把「润色标题」路由到更小更快的模型。部署阶段不用一次配齐，先把本地链路打通，后面随时可以加。
2.2 环境检查与 Docker Compose 最小部署
我一般会在干净目录下建openclaw-deploy/，先跑一遍环境检查，避免后面排错排到想砸电脑。
# 1. 检查基础环境：Python、Docker、以及 Ollama 是否已就绪 python3 --version # 需要 3.10 或更高，部分 Agent 组件依赖新语法 docker version # 需要 20.10+，Compose V2 已集成在 docker 命令里 ollama list # 如果还没装 ollama，先到官网装，或者用容器跑 # 2. 拉取并启动 Ollama 服务容器（如果本机没装） docker run -d --name ollama \ -v ollama_data:/root/.ollama \ -p 11434:11434 \ ollama/ollama:latest # 3. 拉一个适合中文公告解析的模型，推荐 qwen2.5:14b-instruct-q8_0 ollama pull qwen2.5:14b-instruct-q8_0参数说明：11434是 Ollama 的默认 API 端口，OpenClaw 接的就是这个地址；q8_0是量化精度，比默认的 Q4 保留了更多数值能力，投研场景里经常要从公告里抠出数字，Q8 的幻觉率明显低一些。如果你的机器只有 16GB 内存，可以退到 7B 模型，但后面避坑章节会提到，长公告会被截断。
接着写docker-compose.yml，把 OpenClaw 和 Ollama 放到同一个网络里，这样服务名可以直接当主机名用。
services: openclaw: image: <你的OpenClaw镜像名>:latest # 从项目仓库拉取，不同发行渠道镜像名不同 container_name: openclaw ports: - "8080:8080" # 管理面板 / API 入口 volumes: - ./data:/app/data # 保存会话记忆、任务状态 - ./skills:/app/skills # 挂载技能目录，改代码不用重启容器 environment: - OPENCLAW_MODEL_ROUTER=local # 先只走本地模型，避免误调外部 API - OPENCLAW_OLLAMA_BASE_URL=http://ollama:11434 depends_on: - ollama restart: unless-stopped ollama: image: ollama/ollama:latest container_name: ollama volumes: - ollama_data:/root/.ollama ports: - "11434:11434" restart: unless-stopped volumes: ollama_data:这个 Compose 文件的关键点有两个：一是depends_on保证 OpenClaw 启动时 Ollama 已经在跑，但要注意它只保证容器启动了，不保证模型加载完成；二是我把./skills单独挂出来，因为投研实践的日常就是改技能脚本，挂载目录能省掉频繁 docker restart 的麻烦。镜像名我特意写成占位符，因为 OpenClaw 在不同时期、不同渠道发布的镜像仓库不统一，以你实际拉取的为准。
2.3 启动后先做连通性验证，不要急着配技能
部署最忌讳一上来就配一堆技能，结果模型都没通。我先用一条 curl 验证 Ollama 能响应，再用一个最简对话验证 OpenClaw 能把请求转发出去。
# 进入部署目录，后台拉起整套服务 docker compose up -d # 等 10 秒后检查所有容器状态 docker compose ps # 验证 Ollama 本体是否可对话 curl http://localhost:11434/api/chat \ -d '{"model":"qwen2.5:14b-instruct-q8_0","messages":[{"role":"user","content":"只回复两个字：正常"}],"stream":false}' # 验证 OpenClaw 管理端口是否开了 curl http://localhost:8080/health如果 Ollama 容器起来了但 curl 超时，多半是模型还在加载。14B 的 Q8 权重首次加载要几十秒，不是故障。/health端点如果返回 200，说明 OpenClaw 主服务正常，部署闭环就完成了——到这一步，你已经有了一个「本地模型 + Agent 框架」的最小可运行底座，接下来才进入真正花时间的部分：把投研能力装进去。
3. 把投研能力拆成 Skill 体系：从目录结构到提示词模板
3.1 Skill 的标准结构：声明文件加执行脚本，一个技能一个目录
OpenClaw 这类 Agent 框架的可扩展点几乎都落在 Skill 上。我把它理解成「给 Agent 装插件」：每个技能一个目录，目录里放一个声明文件描述什么条件下触发、一个脚本写具体执行逻辑、一段提示词告诉模型怎么干。这个结构的好处是，投研团队的工程师可以写脚本，研究员可以专心改提示词，互不干扰。
skills/ └── announcement_extract/ # 公告要点提取技能 ├── manifest.yaml # 触发条件和参数声明 ├── run.py # 执行入口：读 PDF、调模型、出 JSON └── prompt.md # 系统提示词模板，研究员主要改这里这个目录挂在 OpenClaw 的skills/挂载点下。放进去之后在管理端重载技能列表，新技能就能被对话触发了。我踩过的第一个坑就是改完run.py忘记重载，导致怎么调都不生效——后面避坑章节会细说。实际落地时，一个投研团队一般会维护 8 到 15 个这样的技能目录，从「新股招股书速读」到「年报异常项检查」都独立成技能，而不是堆在一个大脚本里。
3.2 一个「公告要点提取」Skill 的完整配置与参数
manifest.yaml负责告诉 OpenClaw：这个技能在什么时候被触发，以及调用时用哪些参数。
name: announcement_extract version: "1.0" description: 从上市公司公告 PDF 中提取关键要素，输出结构化结果。 trigger: type: file_watch # 监听指定目录下新出现的 PDF 文件 watched_dir: /app/data/inbox/announcements patterns: ["*.pdf"] model: provider: ollama name: qwen2.5:14b-instruct-q8_0 temperature: 0.1 # 投研场景尽量低，减少创造性发挥 top_p: 0.9 max_tokens: 2048 output: format: json schema_file: schema/announcement_schema.json参数说明里最值得较真的是temperature。写公告要点提取不是写作文，0.1已经算高了，有些团队直接设为 0。一旦设成 0.7 以上，模型会开始「润色」原文，把公告里没写的意思补进去，这在投研场景属于重大翻车。max_tokens设 2048 是因为公告摘要的输出一般不会超过这个长度，设太大反而让模型啰嗦。
run.py是实际干活的部分。它的任务链是：定位新 PDF → 提取文本 → 按块送入模型 → 把结果写回指定目录。核心代码如下。
#!/usr/bin/env python3 import json import re from pathlib import Path import urllib.request OLLAMA_URL = "http://localhost:11434/api/chat" MODEL_NAME = "qwen2.5:14b-instruct-q8_0" def extract_text_from_pdf(path: Path) -> str: """从 PDF 提取文本。 普通文本型 PDF 直接用 pdftotext 类工具； 扫描件先走 OCR，否则后面模型看到的是一堆乱码。""" # 省略具体 PDF 解析库调用，项目里按实际依赖引入 return raw_text def chat_once(prompt: str, system: str, temperature: float) -> str: payload = { "model": MODEL_NAME, "stream": False, "temperature": temperature, "messages": [ {"role": "system", "content": system}, {"role": "user", "content": prompt}, ], } req = urllib.request.Request( OLLAMA_URL, data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"}, ) with urllib.request.urlopen(req, timeout=120) as resp: return json.loads(resp.read().decode("utf-8"))["message"]["content"] def main(): inbox = Path("/app/data/inbox/announcements") out_dir = Path("/app/data/out/announcements") out_dir.mkdir(parents=True, exist_ok=True) for pdf_file in sorted(inbox.glob("*.pdf")): text = extract_text_from_pdf(pdf_file) system_prompt = Path("/app/skills/announcement_extract/prompt.md").read_text() result = chat_once(text[:3000], system_prompt, temperature=0.1) out_path = out_dir / f"{pdf_file.stem}.json" out_path.write_text(result, encoding="utf-8") pdf_file.rename(pdf_file.with_suffix(".pdf.done")) # 处理完改名，避免重复消费 if __name__ == "__main__": main()这段脚本的边界我特意写得保守：只取text[:3000]个字符。原因是本地 14B 模型的上下文窗口有限，把整份 30 页年报塞进去，前面的内容会被截断，模型会把后文的内容张冠李戴到前面的字段上。更稳的做法是分章节抽取再汇总，但那是进阶话题。.done后缀是个小技巧，防止同一份文件在下次运行时被重复解析。
这里敲个黑板：timeout=120不是玄学。本地模型在解析长文本时经常要跑 30 秒以上，如果设成默认的 10 秒，OpenClaw 会报超时，这个技能的调用会一败涂地。在投研场景，宁可单次调用慢一点，也要把超时给足。
3.3 提示词模板里藏着投研领域知识
研究员最该关注的文件其实是prompt.md，因为投研知识都沉淀在提示词里。一个合格的公告提取提示词至少包含四段：角色定义、任务步骤、输出字段约束、反例警告。
你是一名券商研究所的公告分析助理。 对给定公告原文，按以下步骤处理： 1. 先判断公告类型：业绩预告、对外投资、股权变动、诉讼仲裁、其他。 2. 提取字段：公司名称、公告日期、涉及金额、交易对方、对当期利润的影响。 3. 标注风险点：是否涉及关联交易、是否需股东大会审议、是否存在不确定性表述。 4. 所有数值必须来自原文，禁止估算；找不到的字段填 null，不要编。 输出严格按如下 JSON 结构： {"announce_type": "", "company": "", "amount": "", "counterparty": "", "risk_points": [], "source_sentences": []}为什么要把「找不到就填 null」写进提示词？因为模型在自由发挥时倾向于「补全」缺失信息，这是它在对话任务里养成的坏习惯，但在投研任务里会直接导致数据污染。source_sentences字段是交叉验证用的，后面工作流章节会讲到。
技能配好之后，OpenClaw 就不再是个聊天框了——你往inbox/announcements丢一份 PDF，它自动吐出一个 JSON。这就是从部署到应用的关键跃迁。
4. 投研工作流落地：把公告、纪要和交叉验证串成一条线
4.1 三个高频场景的工作流设计
技能只是零件，工作流才是产线。我建议投研团队第一个月只盯三个场景：公告解读、纪要整理、指标交叉验证。每个场景定义清楚输入、处理和输出，不要一上来就想做自动写深度研报——那是半年后的事。
| 场景 | 输入 | 处理方式 | 输出产物 |
|---|---|---|---|
| 公告解读 | 交易所公告 PDF | 公告要点提取 → 风险点标注 | 结构化 JSON + 摘要 Markdown |
| 纪要整理 | 会议录音转写文本 | 角色分离 → 观点提取 → 待办识别 | 纪要 MD + 待办清单 |
| 交叉验证 | 模型初版输出 | 再次送模型，逐句核对原文引用 | 带置信度标记的复核报告 |
这三个场景的共同特征是：结果必须可复核。投研输出的每条结论都要能回溯到原文，否则模型再聪明也不敢用。这就是为什么我在提示词里强制要求source_sentences字段——它让每一轮输出都能被快速验证。
这里顺便说一个我对「多AI协作」的理解：协作不是多个模型同时回答一个问题，而是把任务拆给不同角色的 Skill。OpenClaw 里一个「角色」就是一套独立的 Skill 加提示词，读公告的、写纪要的、查数据的各管一段，通过文件目录传递结果。多AI协作的价值是让每个环节都足够简单，简单到不容易出错。
4.2 串起「抓取到纪要」的完整脚本
下面这段代码演示的是把多个技能串成一条流水线：监听公告目录 → 运行提取 Skill → 生成摘要 Markdown → 触发复核 Skill。这是投研实践中最常见的链路骨架。
#!/usr/bin/env python3 from pathlib import Path import json, time import subprocess DATA_DIR = Path("/app/data") INBOX = DATA_DIR / "inbox/announcements" OUT_DIR = DATA_DIR / "out/announcements" REVIEW_DIR = DATA_DIR / "out/reviewed" def watch_and_process(): processed = set() while True: for pdf in INBOX.glob("*.pdf"): if pdf.name in processed: continue # 步骤 1：调用公告提取技能（调 run.py 或直接 import） subprocess.run(["python3", "/app/skills/announcement_extract/run.py"], check=True) # 步骤 2：读取提取结果，组织成纪要片段 json_file = OUT_DIR / f"{pdf.stem}.json" if json_file.exists(): data = json.loads(json_file.read_text(encoding="utf-8")) md = f"## {data['company']}公告摘要\n\n类型：{data['announce_type']}\n金额：{data['amount']}\n风险点：{'; '.join(data['risk_points'])}\n引用：{data['source_sentences']}" (OUT_DIR / f"{pdf.stem}.md").write_text(md, encoding="utf-8") # 步骤 3：触发复核，检查上面的纪要是否有原文支持 subprocess.run(["python3", "/app/skills/review/run.py", pdf.stem], check=True) processed.add(pdf.name) time.sleep(30) # 轮询间隔 30 秒，避免高频扫目录 if __name__ == "__main__": watch_and_process()这段代码展示了两个必要的工程习惯：一是用processed集合记住已处理文件名，重启进程后重新遍历也不会重复执行；二是步骤 2 里直接拼的是「结构化摘要」，不让模型自由发挥写长文。投研纪要的定位是准确而非华丽，一句话把金额、主体、风险点说清楚，比三段落修辞有用得多。
time.sleep(30)这个参数值得说两句。投研公告一般不会密集到秒级到达，30 秒轮询足够，而且给模型留出了处理上一份文件的时间。如果你把轮询改到 3 秒，很可能会因为上一轮还没跑完、下一轮又开始而重复处理同一批文件。
4.3 交叉验证：让模型给自己挑错
只跑一轮就出结果的应用，在投研场景基本都会翻车。我采用的折中方案是「二次复核」：第一轮正常抽取，第二轮把第一轮输出的每条结论连同原文片段一起送模型，问它「这句话有没有原文依据，数值和原文是否一致」。这一招能把幻觉率压下来一大截，代价只是耗时翻倍。
复核 Skill 的提示词里我会写一层硬约束：凡是没有原文直接支持的结论，必须标记为low_confidence，不允许模型「推断」出结论。这一步做好之后，投研团队拿到 Agent 输出时能一眼看到哪些可以直接用、哪些需要人工确认，而不是拿着整份报告重新读一遍——那样自动化就失去意义了。
5. OpenClaw 投研部署常见问题排查：现象、原因、解决
5.1 Windows Companion 连不上 OpenClaw 主服务
现象：在 Windows 机器上启动 Companion 客户端，界面一直显示连接失败，但 Docker 里的 OpenClaw 明明在跑，浏览器访问localhost:8080也是通的。
原因有三个层次：最常见的是防火墙拦了 8080 端口；其次是 Companion 和服务端用的鉴权 token 不一致；还有一种容易被忽略的情况是 Windows 的「智能应用控制」拦截了未签名的 Companion 安装包，导致程序根本没完整启动。热词里能搜到大量这类求助，基本都逃不开这三个原因。
解决：先到 Windows 防火墙里放行 8080 入站规则，再把 OpenClaw 管理端生成的访问 token 复制到 Companion 配置里。第三类问题直接改用 Docker Desktop 跑一份 Companion 服务端，绕开智能应用控制的拦截。如果你发现 Companion 进程没起来，打开事件查看器看一眼应用日志，通常会有「已阻止可能不安全的应用」之类记录，那就确认是第三个原因。
5.2 本地模型答非所问：长公告被截断和量化精度
现象：用 7B 模型跑业绩预告提取，输出的公司名称是对的，但金额经常变成公告里的另一个数字，甚至出现原文不存在的数字。
原因：第一个是上下文窗口——整份公告塞进去后被截断，模型只看到后半段，自然只能从后半段找数字；第二个是量化精度，Q4 量化下的小模型对数字敏感度下降，可能把 3.2 亿看成 1.2 亿。
解决：先把输入从「全文塞入」改成「分章节抽取」，这是最有效的；第二把量化等级提到 Q8，或者直接换 14B 模型；第三把temperature调到 0.1 以下。我的经验是：这三步按顺序做，做完第一步能解决一半问题，三步全做完，报告里的数字级错误基本绝迹。
5.3 扫描版公告 PDF 解析乱码
现象：模型输出的 JSONcompany字段全是乱码，或者提取出来的「涉诉金额」和原文对不上。
原因：扫描版 PDF 没有文本层，直接用pdftotext提取出来的是空壳甚至乱码。金融公告里大量历史文件是扫描件，这条踩坑率极高。
解决：在 Skill 的extract_text_from_pdf里加 OCR 步骤。常见做法是调用 OCR 服务识别之后再送模型。注意 OCR 后文本会带识别错误，所以在提示词里要写「遇到明显不合理的数值必须标注存疑」。这里稍微啰嗦一句：OCR 不是万能的，表格类公告的识别经常串行，我一般要求在输出 JSON 里再加一个ocr_warning字段，提醒下游人工确认。
5.4 多任务并发时上下文串扰
现象：同时跑「公告提取」和「纪要整理」两个任务，纪要里突然出现了公告里的公司名，两边任务的结果混在一起。
原因：两个任务共享了同一份会话历史目录，后启动的任务读到了前面的上下文。这不是模型问题，是状态管理问题。
解决：每个任务建独立的工作目录，任务结束后归档。具体做法是在调用脚本时传入任务 ID，把临时目录、输出目录、会话记忆目录全部按任务 ID 隔离。这个改动很小，但能根治串扰。我见过有团队在 Compose 文件里给每个任务起一个容器，那是把问题复杂化了——目录隔离就够了。
6. 进阶：给投研 Agent 建一套评测集，把玄学变成可回归的指标
6.1 从真实纪要里攒 20 到 50 条评测样本
调模型、调提示词最怕的就是凭感觉。我今天改了一下 Prompt，感觉输出好了一点，但好多少、是否在其他样本上更好，根本说不清。我的做法是从过去三个月的公告里挑 30 条典型样本，每一条手工标注标准答案：公告类型、公司名称、关键金额、风险点。这个工作看起来枯燥，但它是整个投研 Agent 落地中最值得投入的一步。
评测集建好之后，每改一次prompt.md，每换一个模型，都可以跑一遍全量评测。跑完看三个硬指标：字段抽取准确率、原文引用一致率、JSON 格式合法率。字段准确率回答「有没有抽对」，引用一致率回答「有没有编造」，格式合法率回答「下游流程能不能跑通」。其中最容易翻车的是引用一致率——模型经常能给出漂亮的结果，但引用原文时张冠李戴，这是投研场景最危险的错误。
6.2 用脚本批量回归，盯住三个硬指标
评测脚本不复杂，核心就是把每条样本输入 Agent，拿到输出后和标准答案比对。我的工作目录里放一个eval.py，每次改完都跑一遍，用数字说话。
# 跑评测集，自动汇总三个指标 python3 eval/eval.py \ --samples eval/samples.json \ --model qwen2.5:14b-instruct-q8_0 \ --out eval/report.md脚本内部做的事很简单：逐条调用 OpenClaw 的技能接口，把输出的 JSON 字段和标注答案做精确比对，数值字段要求完全一致。一开始准确率可能只有 60% 上下，不要慌，这是正常起点。把失败的样本列出来，你会发现基本都是两类：提示词没约束住的格式问题，和抽取字段定义不清晰的问题。修提示词，再跑，反复迭代到 90% 以上，这之后投入产出的性价比就会明显下降，适可而止。
最后说一个我的习惯：所有实验都固定一个「基准配置」当对照组，改参数永远只动一个变量。OpenClaw 这类 Agent 框架的可调点太多，模型、量化、温度、提示词、上下文长度、技能目录结构，每个都能改变输出。我以前吃过亏，一次改了三个变量，结果输出变坏了，也不知道是谁干的，只能全部回滚重来——那是时间的大出血，也是我后来坚持评测集回归的直接原因。把流程钉死再动参数，这句话值得印在团队墙上。希望帮到你。
本文还有配套的精品资源，点击获取
