熟悉我的朋友可能知道我有个系列叫《养虾实战教程》。名字听着像水产号实际我养的不是虾是我的仓位。之所以叫养虾是因为投资和养虾实在太像你没法让虾快点长只能把水养好、料喂好、病防好然后等。盯盘就是巡塘复盘就是看料台。我用AI agent有一阵子了今年一直在用OpenClaw搭一套属于自己的投资agent目的不是让它替我预测涨跌而是让它帮我做两件事盯盘和复盘。这篇文章把从0到1的完整过程写下来包括OpenClaw部署、channel选择、千问模型接入、复盘skill设计以及实际遇到的六个坑。如果你也在折腾agent开发或者被行情搞得心力交瘁这篇应该对你有用。1. 先说清楚为什么投资盯盘像养虾又为什么需要agent1.1 盯盘是反人性的大部分盯盘时间都在制造噪音做投资的人最容易陷入一个幻觉盯得越紧越能抓住机会。但真实情况是盘中盯着分时图看两小时最后往往只记住了一根大阴线然后把原本定好的计划全忘了。这和养虾人一直盯着水面一个道理——水色正常的时候你什么也看不出来等你看出来不对劲虾可能已经浮头了。所以盯盘这件事真正需要的不是“更多注意力”而是“规则化触发”。价格到了关键位、成交量异常放大、持仓偏离预设比例这些才值得通知。其他时间系统保持静默就好。这正是agent比人和普通脚本强的地方。传统脚本只能执行写死的if price 1500: send_msg()它不理解上下文也无法应对你临时提出的“如果今天已经涨了5%就别提醒我”这种模糊指令。而agent能听懂自然语言、能调用工具、能根据规则自己判断要不要打扰你。1.2 复盘的价值被严重低估难的是坚持盯盘是即时反馈复盘是延迟反馈。延迟反馈的事情人脑天然不擅长坚持。我自己手工复盘过一段时间最大的问题不是不知道怎么写而是三天打鱼两天晒网。今天亏了不想写明天赚了觉得不用写一周下来记录断断续续根本形成不了有效样本。后来我想明白一个道理复盘的核心不是“总结今天”而是“让明天的自己遵守今天定的规矩”。如果没有稳定的记录这个目标完全做不到。所以我要的agent必须能每天固定时间自动复盘并且把结论存下来。不是让它写小作文而是让它按照固定框架输出今天执行了什么计划、偏离了什么规则、情绪状态如何、明天怎么做。有框架才有对比有对比才有改进。1.3 为什么选OpenClaw而不是自己写定时脚本或直接调API在决定用OpenClaw之前我其实先试过两条路一是用cronPython脚本。这条路的问题是每改一个需求都要改代码而且脚本没有“理解能力”。比如我写“如果白酒板块整体走弱看一下茅台是否跌破月线支撑”这种话脚本根本没法处理。二是直接调大模型API。这条路能理解自然语言了但缺少工具调用、消息渠道、长期记忆这些外围能力。我需要自己处理飞书机器人、自己维护会话历史、自己写工具调用循环等于把agent框架重新造一遍。OpenClaw这类开源agent框架解决的就是这个“最后一公里”问题。它把大模型、工具、渠道、记忆、权限都装进了一个可运行的壳子里也就是社区里常说的harness。你只需要关注接入什么模型、开放哪些工具、让它通过什么channel和你对话。我用下来的感受是OpenClaw更适合已经有一定开发基础、但不想从零造轮子的人。它不是无代码平台但你也不需要精通分布式系统。如果你懂一点Python、会看日志、愿意读官方文档这套东西完全能自己跑起来。2. 部署OpenClaw并跑通第一个agentWSL2环境、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 WSL2Ubuntu 22.04Python 3.11本地二进制方式部署OpenClaw没用DockerDocker方式好处是干净但网络和端口映射在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对接QwenOpenClaw本身不绑定模型它通过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 把行情接口封装成toolOpenClaw里的agent本身不会知道实时股价它需要通过tool去拿数据。所以第一步是把行情接口封装成agent可以调用的工具函数。我写了一个最简单的报价工具输入股票代码输出当前价格和涨跌幅import requests def get_quote(symbol: str) - dict: # 伪代码实际数据源可换为akshare、baostock或其他行情API url fhttps://api.example.com/quote/{symbol} data requests.get(url, timeout10).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。我在实际项目里拆了三个agentAgent职责使用模型watcher-agent盯盘、价格提醒、持仓查询qwen-turboreview-agent复盘、日志分析、报告生成qwen-pluschief-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只是一个执行工具。想不清楚换什么框架都白搭。
