用 OpenClaw 搭建个人金融助手：从联网查询到双模型协同

我希望有一个能持续整理金融资料、阅读公告、跟踪研究观点的助手：平时可以通过聊天更新资料，在固定时段收到摘要，重要问题再展开研究。交易仍由人决定，助手不登录交易账户，也不自动下单。

真正搭起来后发现，接通模型和飞书只是开始。更难的问题是：搜索结果能不能支撑结论？模型算出来的金额有没有统一口径？任务究竟还在运行，还是已经无声结束？

这篇文章记录一套已经跑通模型委派链路的实现思路，以及目前仍需验证的环节。它不是投资策略，也不包含任何真实持仓、资金规模、个人风险阈值或收益记录。文中的目录和示例均为通用示意。

1. 先把助手的职责定清楚

我把金融助手的工作分成三层：

助手可以提出建议，但不能修改用户已经确认的投资政策，更不能把自己生成的阈值当成用户的真实偏好。

“不操作”可以是合理结论，不过也需要理由。反过来，不能为了每天交一份报告，就每天制造一条交易建议。

2. 架构：让模型做研究，让程序负责计算

系统由五部分组成：Docker 中的 OpenClaw Gateway、飞书聊天入口、持久化文件区、数据采集与计算工具，以及按任务分工的模型。

基本流程是：

1. 用户通过聊天提交问题或脱敏截图。
2. 助手读取已确认资料，调用搜索和数据工具。
3. 普通整理任务由 Flash 完成，正式研究委派 Pro。
4. 程序计算金额、比例和压力情景，模型解释结果。
5. 结果保存为研究底稿，主会话主动发送摘要。

这里没有把每一步都做成一个独立智能体。初期保持一个对外助手、一个受控研究子任务，排错和追踪成本更低。

Docker 部署的重点是状态，不只是容器

容器能启动，不代表系统已经可长期使用。部署时应分别确认：

• OpenClaw 配置、会话及状态文件是否持久化。

• 智能体 workspace 和研究资料是否持久化。

• 额外 CLI 的配置、加密凭证及其配套密钥是否也已持久化。

• Python 依赖是否有可复现的安装清单。

下面只是建议的业务目录，不是 OpenClaw 的官方目录规范，也不是现成部署结果：

1
2
3
4
5
6
7
8
/srv/fin-assistant/  app/              # 采集和计算程序  config/           # 来源配置、产品映射  data/raw/         # 原始响应  data/normalized/  # 清洗后的数据  research/         # 研究底稿  runs/             # 执行记录  logs/             # 日志

需要把宿主机目录与容器内路径明确映射。目录叫 /data，或者文件已经提交到 Git，都不能单独证明它能在容器重建后保留。

如果使用 Python 工具，不要复制 Windows 的虚拟环境到 Linux。应在目标环境按依赖清单安装；长期运行时，可以构建固定依赖的镜像或独立数据服务。持久化 venv 也不能免除 Python 和系统版本兼容性检查。

3. 接通飞书前，先分清通道、CLI和技能

“安装了飞书相关工具”不等于“飞书消息通道已接通”。至少需要区分：

• 消息通道插件： 让 OpenClaw 收发消息。

• 独立 CLI： 访问具体服务接口。

• 技能文件： 告诉模型如何使用工具完成工作。

排查时分别检查插件加载、通道连接、访问控制和真实消息往返。某个 CLI 授权正常，不能证明消息通道一定正常。

网页端还要分清两个聊天入口：普通智能体聊天用于业务任务；Ask OpenClaw 用于系统设置与修复。右侧 Home 可以打开所选智能体的主会话，不能只凭窗口在左边还是右边判断角色。

配置助手看不到某个参数，也不必立刻解释为整个版本不支持。它可能只是在当前工具或权限范围内无法操作，应通过本机 schema、工具参数和实际调用验证。

4. 联网搜索：配置完成不等于业务会话可用

模型 API 和搜索 API 是两条独立能力。选了某个聊天模型，不代表它在 OpenClaw 中自动拥有网页搜索。

我的做法是先检查当前搜索列表，再选一个可用服务跑通链路。免费服务适合试用，但需要接受额度、访问性和服务限制；付费前先测试自己关心的中文资料覆盖，而不是只比较每千次请求的价格。

搜索验收至少做两次：

1. 在设置页执行提供商测试。
2. 在助手正常会话中，要求实际调用 web_search，返回标题、原文链接和发布日期。

这两个测试检查的路径不同。设置页测试通过后，业务会话仍可能因为工具发现、插件运行状态或会话上下文而不可用。

遇到类似错误，应按错误区分原因：

1
2
3
unknown web_search providerweb_search provider is not availableweb_search is disabled or no provider is available

它们不能都归结为“Key填错了”。应检查当前版本、插件是否安装启用、运行时能否发现提供商，以及会话实际获得了什么工具。

在线文档也不一定与已安装包完全一致。不能因为文档出现某个提供商，就强行向当前配置写入该名称。校验不通过时，应核查兼容版本，而不是手改文件绕过校验。

最后，搜索只负责发现资料。政策、公告和新闻可以搜索；基金净值、指数估值及财务序列，最好由固定数据工具取得并保存。

5. 数据接入：公开来源优先，字段逐项验收

我没有把“必须先购买专业终端”作为启动条件。第一版研究可以主要依靠公开资料，完整历史估值和一致预期则保留为后续选项。

常用入口包括：

• 巨潮资讯：https://www.cninfo.com.cn/

• 上海证券交易所：https://www.sse.com.cn/

• 深圳证券交易所：https://www.szse.cn/

• 中证指数：https://www.csindex.com.cn/

• 国证指数：https://www.cnindex.com.cn/

• 中国人民银行：https://www.pbc.gov.cn/

• 国家统计局：https://www.stats.gov.cn/

• 中债收益率曲线：https://yield.chinabond.com.cn/

• FRED：https://fred.stlouisfed.org/

这些是来源入口，不保证都存在无需授权、长期稳定的 API。AKShare 等库可以减少采集工作，但它们仍依赖上游；库安装成功不代表接口可用，更不代表数据正确。

每条数据都需要带上来源信息

我要求采集器至少记录：

1
2
来源机构、URL、发布日期、数据所属期、采集时间、单位、字段定义、原始文件、清洗方法、错误状态

错误也需要分类：成功获取、来源未披露、访问失败、解析失败、等待发布、需要授权。

HTTP 200 不等于有效数据，退出码为0也不等于业务验收通过。空数据可能来自产品尚未成立、接口参数错误、页面结构改变或真实没有记录，不能直接补成零。

6. 研究方法：先确定问题，再选择指标

早期最容易陷入的误区，是规定“长期估值分位、资金流、盈利修正全部齐全，才允许给建议”。这会让助手长期停留在补数据阶段。

更实用的方式是按资产和问题选证据：权益研究经营、盈利、估值与预期；利率类资产研究收益率和久期；主动基金研究经理、策略与实际持仓。某项指标不适用，就写不适用。

但降低统一门槛，不代表降低证据要求。研究中有几条特别需要固定下来。

公司增长，不等于主题行业增长

一家指数成份公司的收入可能来自多个业务。公司总收入增加，不能直接证明主题业务需求增强。地区与产品分类也会重叠：海外收入可能同时属于主题业务，不能把两者相加。

财务指标要读原因，不只读数值

经营现金流下降，可能来自收款变化，也可能来自付款加快、备货或季节性。需要同时读管理层解释和报表科目。

累计数据可以在口径一致时相减得到单季度数值；同比增速、毛利率等比例不能简单相减。

压力测试不是市场预测

假设某资产下跌一定幅度，可以计算组合损失，但不能把任意选择的跌幅直接包装成最优交易金额。

必须先定义本金、现金流、累计损失或回撤的口径，再说明其他资产与卖出款的处理。已有浮亏转为已实现亏损，也不应重复计作新增经济损失。

有限结论比补齐所有指标更重要

没有长期估值历史，就不声称历史便宜或昂贵；没有一致预期，就不声称超预期。仍然可以分析现有经营证据、提出条件性判断，并说明哪些新事实会改变结论。

7. Flash与Pro协同：先验证路由，再讨论质量

我的试运行分工是：

OpenClaw 原生子任务可以承担这条链路。实际验证时，重点不在于模型是否声称“已经调用Pro”，而在于子任务的运行记录。

最小测试只安排一件小事：主会话委派研究任务，子任务核对本地一条数据，再把结果交回主会话。检查实际模型、任务状态及主会话最终回复。

本次试运行已经验证了 Flash 委派 Pro、Pro结束并返回结果、主会话回复这条链路。思考设置虽然随任务提交，但没有取得与模型字段同等独立的生效证据。

还必须区分三种核验：

• 本地一致性核验： 数字是否与本地文件一致。

• 原文核验： 是否与官方文件和字段口径一致。

• 推断复核： 这些事实能否支持研究结论。

本地核验返回 verified: true，不能扩大为“官方数据和投资建议全部正确”。

试用中，Pro能继续拆解问题，也能发现旧报告的问题，但仍会出现跨期比较、分类重叠或过度推断。因此，当前选择它负责研究，是工作分配上的判断，不是已经完成严格的模型可靠性评测。

8. 定时报告与运行状态：输出也是验收的一部分

定时报告的目标是固定时段交付信息，而不是每天重做完整行业研究。更合理的日报内容是：新增事实、旧观点是否改变、是否触发复核，以及仍然缺少什么。

正式接入前，需要逐项确认任务ID、时区、执行模型、投递目标、下次运行时间和失败记录。主会话临时切到Pro，不代表定时任务也会跟着切换。

本次已经验证的是模型协同；固定时段的自动交付仍需要单独做端到端验收，不能写成已经长期稳定运行。

没有回复时，不要立刻重启

网页端可以查看停止生成按钮、任务进度、等待授权、错误通知，以及 Processes 和子任务状态。版本不同，入口可能不同。

需要进一步排查时，可在 Gateway 所在容器检查：

1
2
openclaw statusopenclaw logs --follow

没有进程不一定代表没有模型推理；没有停止按钮，也不能单独证明任务成功完成。页面状态、子任务记录与日志应结合判断。

我实际遇到过一种情况：文件已经保存，聊天却没有最终交付，追问后才补发结果。这种情况应视为交付未闭环，而不是正常完成。

因此，每轮任务的完成标准应该包含：

1. 结果或失败原因已保存。
2. 主会话已收到子任务结果。
3. 用户收到了最终摘要或明确失败通知。

只在提示词里写“结束时必须回复”，不能保证消息链路一定可靠，还需要实际投递记录。

9. 不让助手在研究中不断改变自己的规则

后台技能维护可能从对话中学习并修改技能。这对通用工作流有价值，但金融助手需要避免把临时推断写成永久政策。

我会将内容分开保存：

• 用户确认的政策：独立文件，变更需要用户明确确认。

• 采集与计算技能：描述工具、字段和流程。

• 研究报告：记录当时证据和观点，可以有版本，但不反向修改政策。

技能更新先形成候选和差异，确认后再应用。把这条写进 AGENTS.md 只是表达要求，是否真正约束后台维护，还需要检查对应流程和设置，不能当作强制隔离已经完成。

10. 一段可复用的起步提示词

下面的提示词不包含具体持仓或风险比例。它用于约定工作方式，不能代替真实的工具配置与验收。

这套助手目前更适合作为一个可追溯的研究工作台。它能降低查资料、整理报表和跟踪观点的成本，但是否采取行动，仍需要人理解证据和假设之后作出决定。

官方参考

• OpenClaw Docker 部署

• 飞书通道

• 模型与会话切换

• 网页搜索

• DeepSeek接入

• 子任务与模型覆盖

• 管理定时任务

• Home与Ask OpenClaw

• 聊天、进程与停止操作

• DeepSeek思考模式

本文按2026年11月的文档和试运行过程整理。OpenClaw更新较快，配置路径、命令与插件能力应以实际安装版本为准。

如果对你有启发，欢迎点赞、在看、转发

点赞

在看

转发