熟悉我的朋友可能知道，我有个系列叫《养虾实战教程》。名字听着像水产号，实际我养的不是虾，是我的仓位。之所以叫养虾，是因为投资和养虾实在太像：你没法让虾快点长，只能把水养好、料喂好、病防好，然后等。盯盘就是巡塘，复盘就是看料台。我用AI agent有一阵子了，今年一直在用OpenClaw搭一套属于自己的投资agent，目的不是让它替我预测涨跌，而是让它帮我做两件事：盯盘和复盘。这篇文章把从0到1的完整过程写下来，包括OpenClaw部署、channel选择、千问模型接入、复盘skill设计，以及实际遇到的六个坑。如果你也在折腾agent开发，或者被行情搞得心力交瘁，这篇应该对你有用。
1. 先说清楚：为什么投资盯盘像养虾，又为什么需要agent
1.1 盯盘是反人性的，大部分盯盘时间都在制造噪音
做投资的人最容易陷入一个幻觉：盯得越紧，越能抓住机会。但真实情况是，盘中盯着分时图看两小时，最后往往只记住了一根大阴线，然后把原本定好的计划全忘了。这和养虾人一直盯着水面一个道理——水色正常的时候你什么也看不出来，等你看出来不对劲，虾可能已经浮头了。
所以盯盘这件事，真正需要的不是“更多注意力”，而是“规则化触发”。价格到了关键位、成交量异常放大、持仓偏离预设比例，这些才值得通知。其他时间，系统保持静默就好。
这正是agent比人和普通脚本强的地方。传统脚本只能执行写死的if price < 1500: send_msg()，它不理解上下文，也无法应对你临时提出的“如果今天已经涨了5%就别提醒我”这种模糊指令。而agent能听懂自然语言、能调用工具、能根据规则自己判断要不要打扰你。
1.2 复盘的价值被严重低估，难的是坚持
盯盘是即时反馈，复盘是延迟反馈。延迟反馈的事情，人脑天然不擅长坚持。我自己手工复盘过一段时间，最大的问题不是不知道怎么写，而是三天打鱼两天晒网。今天亏了不想写，明天赚了觉得不用写，一周下来记录断断续续，根本形成不了有效样本。
后来我想明白一个道理：复盘的核心不是“总结今天”，而是“让明天的自己遵守今天定的规矩”。如果没有稳定的记录，这个目标完全做不到。
所以我要的agent，必须能每天固定时间自动复盘，并且把结论存下来。不是让它写小作文，而是让它按照固定框架输出：今天执行了什么计划、偏离了什么规则、情绪状态如何、明天怎么做。有框架，才有对比；有对比，才有改进。
1.3 为什么选OpenClaw，而不是自己写定时脚本或直接调API
在决定用OpenClaw之前，我其实先试过两条路：
一是用cron+Python脚本。这条路的问题是：每改一个需求都要改代码，而且脚本没有“理解能力”。比如我写“如果白酒板块整体走弱，看一下茅台是否跌破月线支撑”这种话，脚本根本没法处理。
二是直接调大模型API。这条路能理解自然语言了，但缺少工具调用、消息渠道、长期记忆这些外围能力。我需要自己处理飞书机器人、自己维护会话历史、自己写工具调用循环，等于把agent框架重新造一遍。
OpenClaw这类开源agent框架解决的就是这个“最后一公里”问题。它把大模型、工具、渠道、记忆、权限都装进了一个可运行的壳子里，也就是社区里常说的harness。你只需要关注：接入什么模型、开放哪些工具、让它通过什么channel和你对话。
我用下来的感受是：OpenClaw更适合已经有一定开发基础、但不想从零造轮子的人。它不是无代码平台，但你也不需要精通分布式系统。如果你懂一点Python、会看日志、愿意读官方文档，这套东西完全能自己跑起来。
2. 部署OpenClaw并跑通第一个agent：WSL2环境、channel和千问模型
2.1 Windows下部署：WSL2环境验证失败的排查
我的主力电脑是Windows，所以第一步就是装WSL2。OpenClaw官方文档推荐在Linux环境跑，Windows用户最顺的路就是WSL2 Ubuntu。
第一次部署时我卡了最久的地方，就是启动时报了这么一句：
openclaw could not safely verify the wsl2 environment.字面意思是“无法安全验证WSL2环境”，但这个报错非常误导人。我一开始以为是WSL2没装好，重装了两遍还是同样的错。后来才发现问题是：WSL2默认版本没设对，内核版本太老，而且我的项目目录放在了一个带中文名的路径下。
排查步骤其实不复杂：
wsl --status wsl -l -v如果看到某个发行版的VERSION显示1，说明它还在用WSL1内核，需要手动切换：
wsl --set-version Ubuntu-22.04 2 wsl --set-default-version 2如果版本没问题但还是验证失败，建议检查Windows功能里有没有开启“虚拟机平台”。另外一个容易被忽略的点：项目路径尽量不要有中文和空格。OpenClaw做环境校验的时候会执行一些路径拼接，特殊字符很容易误判。
我的最终环境是这样的：
- Windows 11 + WSL2
- Ubuntu 22.04
- Python 3.11
- 本地二进制方式部署OpenClaw，没用Docker
Docker方式好处是干净，但网络和端口映射在WSL2里偶尔会有诡异问题。本地二进制方式更直接，日志也更好查。
安装命令大致如下，具体以你拿到的官方仓库为准：
git clone <openclaw官方仓库地址> cd openclaw make install openclaw --version装完之后先别急着配channel，先跑一下自检命令，确认harness能正常起来。
2.2 怎么选择channel：飞书、微信还是终端
channel是OpenClaw里的一个核心概念，可以理解成agent和外界对话的入口。支持终端、飞书、微信、Telegram等，不同channel的接入复杂度差别很大。
我第一次配的时候贪方便，直接配了微信。理由是“反正我天天用微信”，结果踩了大坑——这个问题后面专门讲。如果你也想搭投资agent，我现在的建议非常明确：优先用飞书。
原因有三个：
- 飞书机器人API稳定，事件订阅机制清晰，长文本可以通过消息卡片或云文档处理。
- 飞书群的“话题”“快捷指令”这些能力，天然适合做提醒分类。
- 个人微信机器人有风控风险，而且很多实现只支持发消息、不支持收消息，双向通讯很难配。
终端channel适合调试，但不适合日常用。因为你不可能一直开着电脑终端等agent叫你。所以我的组合是：开发调试时用终端channel，正式使用时用飞书channel。
在OpenClaw里加一个channel大致是这样的：
openclaw channel add feishu \ --app-id <飞书应用App ID> \ --app-secret <飞书应用App Secret>然后在飞书开放平台创建企业自建应用，开启机器人能力，配置事件订阅地址。事件订阅地址要填你的公网回调地址，这一步最容易出问题——如果你本机没有公网IP，回调地址可以从ngrok这类内网穿透工具临时拿一个，或者直接把agent部署在一台有公网IP的服务器上。
我自己最后是把agent跑在了一台轻量云服务器上，省掉了内网穿透的各种麻烦。
2.3 配置千问模型：OpenClaw对接Qwen
OpenClaw本身不绑定模型，它通过LLM provider对接各家大模型API。我选的是通义千问的qwen-plus，理由很现实：国内访问稳定、API兼容OpenAI格式、价格便宜，而且工具调用能力在开源模型里是第一梯队。
配置文件里大致是这样一个结构：
model: provider: dashscope model: qwen-plus api_key: ${DASHSCOPE_API_KEY}配好之后重启OpenClaw，在飞书群里拉机器人进群，然后发一句：
你好，介绍一下你自己，以及你现在能用哪些工具。如果agent正常回复，说明模型接入、channel、harness三层都通了。
这里有个小建议：不要把api_key直接写在配置文件里，用环境变量引用。因为配置文件可能要提交到Git仓库，暴露key的代价很大。
3. 盯盘agent是怎么搭的：工具函数、定时任务和消息路由
3.1 把行情接口封装成tool
OpenClaw里的agent本身不会知道实时股价，它需要通过tool去拿数据。所以第一步是把行情接口封装成agent可以调用的工具函数。
我写了一个最简单的报价工具，输入股票代码，输出当前价格和涨跌幅：
import requests def get_quote(symbol: str) -> dict: # 伪代码，实际数据源可换为akshare、baostock或其他行情API url = f"https://api.example.com/quote/{symbol}" data = requests.get(url, timeout=10).json() return { "symbol": symbol, "price": data["price"], "change_pct": data["change_pct"], "time": data["time"] }在OpenClaw里注册工具时，关键是写好描述。描述越清晰，agent越知道什么时候该调用它。比如我写的描述是：
获取A股或港股的实时报价。输入为股票代码，输出为当前价格、涨跌幅和更新时间。 当用户询问“某只股票现在多少钱”“今天涨了还是跌了”时，调用此工具。这一步很多人不重视，但恰恰是agent能不能用好的分水岭。工具描述写得模糊，agent就会在不需要的时候乱调用，或者该调用的时候不调用。
3.2 定时任务与阈值触发：别让agent频繁轮询
盯盘agent的第二种触发方式，是定时任务。OpenClaw支持在harness里定义定时调度，也可以直接用crontab调用CLI命令触发agent执行。
我实际用的方式更简单：
*/5 * * * * cd /path/to/openclaw && openclaw run "检查我的自选股列表，如果有股票触发了我设置的价格提醒条件，就在飞书群里发一条提醒。"这条cron每5分钟跑一次，agent收到任务后会自己去查工具函数、做阈值判断、决定要不要发提醒。
为什么要让agent做判断，而不是直接在Python脚本里写if-else？因为判断条件本身也会变。比如我经常加一些临时规则：“如果白酒板块整体大跌，但茅台没跌破月线，那就等到收盘再提醒我”“今天上午有会，所有提醒改成只发给你，不要@我”。这些临时规则如果都用代码实现，我每天要改十次脚本。用agent，我只要在群里说一句就行。
触发逻辑的设计原则是：宁可漏掉一些小波动，也不要频繁轰炸。提醒的价值在于“少而准”。
3.3 路由识别节点：多channel、多agent的消息该怎么分
用得久了，我的agent不再只有一个，而是拆成了两三个。这时候就涉及到热词里说的“路由识别节点”。说白了，就是入口处需要有一个机制，判断消息应该交给哪个agent处理。
我的路由规则很简单：
- 涉及实时行情、价格提醒、持仓查询的，走watcher-agent
- 涉及“复盘”“总结”“我今天为什么亏了”这类问题的，走review-agent
- 剩下不确定的，由chief-agent统一接管，再由它决定是否分发子任务
具体到OpenClaw里的配置，可以通过prompt层面的路由定义来实现。我给chief-agent的system prompt里写了：
你是总控agent，负责判断用户意图。如果用户询问实时行情、价格、持仓，转给watcher-agent处理。 如果用户要求复盘、总结、分析交易日志，转给review-agent处理。 如果消息无法明确分类，由你直接回答。路由识别节点听起来很高大上，其实核心就是“意图分类+任务分发”。在小规模场景里，一份清晰的路由规则足够用了。等agent数量多了以后，才可以考虑引入独立的路由模型。
3.4 飞书输出容易被截断：长文本分段是真的有必要
跑通之后很快遇到一个经典问题：OpenClaw在飞书里输出长文本时，经常被截断。尤其在让agent输出复盘报告、长复盘表格的时候，内容发到一半就断了。
原因其实不复杂：飞书机器人文本消息有长度上限，富文本卡片也有单条消息大小限制。agent一次性生成几千字，飞书根本收不下。
我一开始以为是OpenClaw的问题，还去查了很久日志。后来才意识到，这属于“内容生产和渠道限制的矛盾”，需要在agent侧解决。
解决方法是我写了一个send_long_text的skill，专门负责把超长文本分块发送。核心逻辑是按Markdown标题分段：
def split_by_heading(text: str, max_len: int = 3500) -> list[str]: parts = [] current = "" for line in text.splitlines(): if line.startswith("## ") and len(current) > max_len: parts.append(current) current = "" current += line + "\n" if current.strip(): parts.append(current) return parts分段之后，让agent逐条调用飞书发送接口。如果内容实在太长，比如超过了10段，就改为生成一个Markdown文件，传到飞书云文档，再把链接发到群里。
这个处理方式后来也被我用在了复盘报告上，效果很好。
4. 深度复盘agent：从agent记忆到skill化的复盘能力
4.1 交易日志与agent记忆：它凭什么记住你上周的判断
盯盘agent解决的是“当下”，复盘agent解决的是“过去”。但“过去”不会凭空出现，这就要说到agent记忆。
OpenClaw里的记忆分两层：短期上下文和长期记忆。短期上下文就是当前会话里能看到的对话历史；长期记忆则是跨会话持久化的信息。
我第一版复盘agent最大的问题，就是它每次都是“失忆”的。你让它复盘今天的交易，它只能看到今天的行情，完全不知道我三天前说过“跌破这个位置我就止损”。这种复盘毫无意义。
后来我设计了一个极简的记忆方案：每天收盘后，让agent把当天的重要信息写入一个本地Markdown文件，作为“交易日志”。字段很简单：
| 字段 | 说明 | 示例 |
|---|---|---|
| 日期 | 交易日 | 2025-01-15 |
| 操作 | 买/卖/持有 | 卖出半仓某标的 |
| 价格 | 成交价格 | 12.35 |
| 原因 | 当时决策依据 | 跌破20日均线，执行止损计划 |
| 情绪 | 主观感受 | 焦虑，但遵守纪律 |
| 明日计划 | 明确的下一步 | 不追涨，等待回踩企稳 |
每次复盘前，先让agent读取这个日志，再结合当天行情做分析。这样它就有了“记忆”，而且这种基于文件的记忆完全透明，出问题了能手动改。
4.2 复盘skill：把复盘能力从“自由发挥”变成“固定框架”
复盘这种任务，如果完全交给agent自由发挥，它每次的格式都可能不一样。今天输出一堆感慨，明天输出一张表，后天又开始写诗了。这会直接导致记录无法横向对比。
所以我把复盘做成了一个标准的skill。skill是什么？可以理解成“给agent预先定义好的一套行为模板”，里面包含目标、步骤、输入输出格式、注意事项。
我的复盘skill长这样：
你是投资复盘助手。在每日复盘时，严格按照以下步骤执行： 1. 读取最近的交易日志文件，整理当日实际操作。 2. 调用行情工具，获取持仓和自选股的当日收盘数据。 3. 按评分卡逐项打分：计划执行度、盈亏归因、情绪状态、规则遵守度。 4. 输出固定格式复盘报告，包含：今日回顾、偏差分析、情绪记录、明日计划。 5. 将复盘结果追加写入交易日志，供后续复盘参考。这样设计的好处是：复盘结果变得非常结构化，一周下来我只需要看七天的评分卡，就能很直观地看出哪个环节持续出问题。
4.3 harness和agent的区别：运行壳和决策脑
很多刚开始接触OpenClaw的人会混淆这两个概念：harness和agent。
我的理解是：
- harness是运行壳。它负责管理工具调用循环、上下文窗口、权限控制、channel输入输出、错误恢复这些和“模型无关”的事情。
- agent是决策脑。它由具体的模型、system prompt、skills、记忆组成。
类比养虾的话，harness是整个虾塘的供氧、水循环、温度控制系统；agent是那个巡塘的人。没有好的水循环系统，巡塘的人经验再丰富，虾也养不好。反过来，水系统再好，没人巡塘判断，也不行。
为什么要区分这两层？因为实际开发中，你可能想在同一个harness里跑多个agent。比如我的watcher-agent用qwen-turbo，因为便宜快速；review-agent用qwen-plus甚至qwen-max，因为需要更强的推理能力。同一个框架、不同的agent配置，这就是分层带来的灵活性。
4.4 skill和agent的区别：能力包和决策主体
skill和agent也是一对容易混淆的概念，区别其实更简单：
- skill是能力包，是agent可以调用的一组“技能”。它本身没有自主决策能力。
- agent是决策主体，它决定“什么时候用skill、用哪个skill、用完skill之后怎么处理结果”。
回到我的场景：我写了一个“获取交易记录”的skill，一个“发送分段长文本”的skill，一个“生成复盘评分卡”的skill。这些skill可以被不同的agent复用。
所以多agent协作的时候，正确的做法不是把每个能力都做成一个agent，而是把公共能力做成skill，把不同职责做成agent。我在实际项目里拆了三个agent：
| Agent | 职责 | 使用模型 |
|---|---|---|
| watcher-agent | 盯盘、价格提醒、持仓查询 | qwen-turbo |
| review-agent | 复盘、日志分析、报告生成 | qwen-plus |
| chief-agent | 路由分发、日常闲聊、复杂任务编排 | qwen-plus |
上下文隔离是最重要的好处。盯盘agent的上下文里充斥着各种行情数据，如果它和复盘agent混在一起，复盘agent的长上下文很快就会被噪音污染，而且token成本翻倍。
4.5 对接魔塔与千问：模型选择的成本经验
热词里有人提到“openclaw对接魔塔”，我理解是想问能不能用魔塔社区的本地模型。魔塔（ModelScope）上确实有很多开源模型，比如Qwen系列的开源版本，理论上都能接进OpenClaw。
但我个人的建议是：如果只是为了做投资盯盘和复盘，别折腾本地模型。本地模型最大的问题是工具调用稳定性。你让qwen-plus在飞书上回个消息、调个工具，问题不大；你让一个7B本地模型在40条对话之后还准确按格式调用工具，难度立刻上来了。
我的成本分配方案是：
- 消息量最大的盯盘agent，用qwen-turbo，价格便宜，响应快。
- 复盘agent用qwen-plus，输出质量高，工具调用稳。
- 如果要做月度总结这种复杂分析，手动切到qwen-max。
这套组合跑下来，每月的模型费用基本可以忽略。对于个人投资者来说，完全在可接受范围内。
5. 真实使用中踩过的坑：六次故障的完整排查链路
5.1 报错“could not safely verify the wsl2 environment”
这个坑在2.1节已经展开过，这里补充一个我当时漏掉的细节：OpenClaw做WSL2环境验证时，其实是在检查WSL内核版本。如果你Windows里的WSL内核太老，即使发行版是VERSION 2，也会报这个错。
解决方法是去Windows Update里更新WSL内核，或者用管理员权限执行：
wsl --update更新之后重新打开终端，再跑一次openclaw --version就不会报这个错了。这个坑因为没有GUI提示，纯靠日志排查，所以特别容易被卡住。
5.2 微信只能发消息、收不到用户回复
这是我最开始选微信channel时遇到的最大问题。现象是：agent能往微信里发消息，但我在微信里发给它消息，它完全没有反应。
查了很久之后定位到原因：个人微信机器人走的是web/ipad协议，很多三方库对“接收消息回调”的支持并不完整。它能把消息推出去，但收消息的通道没有真正建立起来，导致agent根本没有收到用户输入。
这个问题的最终解法就是换channel，换成飞书。飞书支持标准的events回调，收消息、发消息都是正经API，双向通讯非常稳定。如果你一定要用微信，建议研究企业微信或微信客服API，而不是碰个人微信协议。
5.3 报错“agent execution terminated due to error”
这个报错出现的场景很典型：盯盘agent跑定时任务时，偶尔会突然终止，日志里只有一句“execution terminated due to error”，再没有更多信息。
我整理出来的常见原因有三个：
- 工具返回的数据太大，把上下文窗口撑爆了。
- agent循环调用工具次数超过上限。
- 模型返回内容不是合法JSON或格式不符合工具调用规范。
排查思路是：先看日志里最后一次工具调用记录，确认是哪个环节出了问题。然后对症下药。如果是工具输出太大，就在工具函数内部做摘要，比如只返回最高价、最低价和涨跌幅，不要把完整K线数组塞进去。如果是循环次数超限，就调大max_iterations配置。如果是格式问题，换一个更稳定的模型。
5.4 飞书长文本截断
这个已经在3.4节讲过了，这里只补充一个细节：飞书的富文本卡片和普通文本消息限制不一样，富文本卡片单条限制更小。如果你发现agent用卡片发长文经常被截断，试试切回普通文本格式。普通文本还不行，再走分段方案。
5.5 安全边界：别让agent拥有交易权限
我第一次搭好agent之后，脑海里闪过的第一个念头是：能不能让agent直接帮我下单？
冷静下来之后，我决定绝对不做这件事。原因不是技术问题，而是安全边界。agent的prompt注入风险是真实存在的，尤其在飞书群里，如果有人往群里发一条精心构造的消息，可能诱导agent执行恶意指令。如果这个agent还绑定了交易API，后果不堪设想。
我的设置是：
- 行情数据、交易记录，agent有只读权限。
- 所有涉及“买入”“卖出”“撤单”的操作，agent一律只能生成“交易建议”，由我人工执行。
- 在system prompt里明确写了“未经用户明确确认，禁止执行任何交易指令”。
agent可以做很多事，但不代表它应该做所有事。尤其涉及真金白银的时候，留一道人工关卡，是对自己负责。
5.6 上下文被撑爆：不是每次都要“从头聊起”
盯盘agent跑了一个星期之后，我发现一个问题：它的响应越来越慢，费用越来越高。原因是会话历史太长，每天都在累积。
这个问题在OpenClaw这类框架里很常见。解法有两个：要么定期重置会话，要么把“历史记忆”从上下文里剥离出去。我采用的是后者：每天收盘后，让agent把当天对话中的重要信息总结成几条结构化笔记，写入交易日志，然后主动开启一个新会话。新会话的上下文里只加载笔记，不加载原始对话。
这样就做到了“既记得住，又不被历史拖垮”。对于投资场景来说，这个模式比无限堆对话历史高效得多。
6. 用了一个月之后，这套agent到底帮我省了什么
目前这套系统已经稳定跑了四个星期。最大的变化不是赚了多少钱，而是我明显减少了盘中打开行情软件刷手机的次数。
盯盘agent每天按crontab检查自选股，触发条件才会在飞书提醒我一句。午休的时候我扫一眼群消息，就知道上午哪些目标价被触碰了。复盘agent每天收盘后自动跑，晚上我打开飞书，就能看到今天的评分卡和偏差分析。
最有价值的一次提醒，发生在我执行止损计划那天。当天某个标的大跌，我本来想说“再拿一天看看”，结果复盘agent直接把我三天前写的交易日志翻出来，提醒我“你当时明确说，跌破12.35就无条件止损”。看到这条消息，我犹豫了几分钟，最后还是按计划执行了。第二天股价继续跌了6%。
这个时候我才真正意识到，agent对普通投资者最大的价值，不是预测行情，而是帮你守纪律。盯盘是为了减少无效关注，复盘是为了让明天的自己遵守今天定下的规矩。
社区里还有pi agent、hermes agent这类项目，核心思路也是做通用或垂直场景的agent，你可以都去玩玩。但我最后留在OpenClaw，主要是因为它把channel、skill、harness这套东西集成得比较完整，比较适合我这种“既想要灵活性、又不想造轮子”的人。
如果要说后续计划，我有两个方向：一是给复盘agent加一个“按周聚合”的skill，自动生成周度交易报告；二是尝试把评估（eval）流程加进去，用历史数据检验不同prompt哪个更稳定。这些都是增量优化，核心架构不会大改了。
最后再分享一个经验：agent的项目，难点从来不是模型，也不是框架，而是你对自己要解决的问题有没有清晰的定义。你想让它盯盘，先想清楚什么值得提醒；你想让它复盘，先想清楚复盘要输出什么格式。想清楚了，OpenClaw只是一个执行工具。想不清楚，换什么框架都白搭。
