自托管AI盯盘助手PanWatch：从零部署到调优全攻略

PanWatch这类自托管AI盯盘助手，最近在我关注的圈子里讨论度很高。我自己的使用场景其实很明确：白天要上班，行情却常常在关键时段突变，那些SaaS预警工具要么规则写得太死，要么要把自选列表甚至部分持仓快照传到别人服务器上，怎么想都不太对劲。后来我把盯盘这件事彻底搬回了自己机器上，用AI Agent来做分析判断，PanWatch就是这套思路的典型代表。

这个方案说穿了并不复杂：自托管把软件跑在自己能控制的服务器上，数据、配置、通知渠道全部归自己；AI盯盘则是把过去“价格大于某个数就提醒”的死规则，升级成“结合K线、成交量、资金费率、新闻标题做综合判断”的智能体。适合谁来参考？我觉得有两类人最值：一类是有Linux或Docker基础的个人投资者，想摆脱云端工具的种种限制；另一类是技术爱好者，想把AI Agent、调度任务、多源数据采集串成一个真实可用的工程项目。

下面文章里，我把从零部署、调优、踩坑的整个过程整理出来，包括架构选型、数据源接入、模型部署、规则设计、常见故障排查。内容偏实操，不搞空谈。

1. 整体设计思路：为什么是“自托管+AI”而不是“SaaS+App”

1.1 自托管的真正价值不是省钱，而是可控

很多人一听到自托管，第一反应是“可以省掉订阅费”。我的体会是，省钱只是顺带的，真正的好处是控制权。

先说隐私。行情数据本身不算敏感，但你的自选列表、关注的标的、持仓信息、盯盘策略，这些拼在一起会暴露出你的交易偏好和资金体量。放到云端的SaaS产品里，等于把这些信息交给了第三方。自托管以后，所有数据都留在你自己的机器上，AI分析时该读什么、该输出什么，完全由你的配置说了算。

再说规则自由。SaaS工具通常只提供固定预警模板，比如突破、跌破、涨跌幅超过N%。但真实盯盘里需求千奇百怪：我想让AI在“成交量是过去20日均值的3倍以上”且“价格刚好接近前高”的时候才开始关注，还要附带一段中文解读。这种复合逻辑在SaaS里要么需要复杂的公式脚本，要么根本做不了。自托管之后，这就只是改几行配置的事。

最后是可扩展性。自托管服务可以随便对接自己的数据库、报表系统、企业微信机器人，甚至把AI分析结果再喂给下一个自动化流程。用一句生活类比：SaaS是住酒店，设施齐全但家具不能动；自托管是买自己的房子，装修拆墙都随你。代价是水电煤都要自己管，项目跑挂了只能自己扛。

1.2 AI盯盘与传统条件盯盘的本质区别

传统条件盯盘的逻辑是：当“A指标满足”时，“执行B动作”。比如价格突破70000就发通知。这种规则简单直接，但问题也很明显：没有上下文，不知道这个突破发生在凌晨三点低流动性时段还是放量突破关键位，误报率很高。

AI盯盘的本质区别在于，它把“判断”也交给模型。同样是突破，AI会结合几类信息一起看：当前价格与均线距离、过去24小时成交量变化、资金费率是否偏高、相关新闻情绪如何，然后输出类似“当前突破伴随放量和舆情升温，但流动性偏低，建议提高警惕”这样的结论。

我并不是说传统规则不好，恰恰相反，硬性条件规则是AI盯盘的“门槛”。正确做法是让规则先把明显异常筛出来，再由AI做二次判断，这能显著降低模型幻觉带来的噪声。表格对比会更直观：

1.3 PanWatch在整套架构里的位置

PanWatch这类工具在设计上很像一个“会看盘的小管家”。它不是行情终端，也不是交易机器人，而是处在数据和你的注意力之间的一层代理。典型的模块划分是四层：

• 输入层：对接行情API、K线历史、新闻资讯源，把原始数据收进来；
• 分析层：按调度周期执行规则引擎，筛选出需要AI复核的标的；
• 决策层：调用LLM生成判断结论，按格式输出风险等级和摘要；
• 输出层：通过ntfy、邮件、Webhook把结果推给你。

这样分层的价值是各模块可以独立替换。今天觉得A数据源不好换B，模型效果不佳换另一个模型，通知渠道从邮件换成企业微信，都不用动其他层。我见过不少项目一上来就把所有逻辑塞在一个脚本里，短期跑得通，一旦要加数据源或改模型就直接推倒重来。分层设计虽然前期麻烦一点，后期会轻松非常多。

2. 核心细节解析与实操要点

2.1 数据源接入：别把鸡蛋放在一个API里

数据源是整个盯盘系统的基础，这一层不稳定，AI分析再强也是白搭。我踩过最大的坑，就是只接了一个公开行情接口，结果凌晨行情一波动，接口限频或者超时，一条预警都没发出去。

行情接口通常分两类：REST接口适合低频拉取快照，比如每5分钟拿一次最新价；WebSocket适合实时流推送，但需要在连接断开时自动重连。PanWatch这类自托管工具，大部分场景用REST轮询就够，真正要毫秒级响应的场景不多。如果要做高频监控，建议用WebSocket加断线重连，而不是盲目缩短REST轮询间隔。

数据源接入的几个实操要点：

• 至少配置两个源：主源负责日常抓取，备用源在主源连续失败时快速切换；
• 做好限频：公开API通常有每分钟请求上限，轮询间隔要留足余量，比如名义限制30次/分钟，实际只跑10次；
• 设置错误退避：接口返回429或5xx时，不要立刻重试，按指数退避等待，否则很容易被临时封IP；
• 时间同步很关键：不同源返回的时间戳格式可能不同，统一转成UTC时间存储，分析时才不会对不上。

我习惯在采集层加一个小函数做故障转移，伪代码大概是这样的：

def fetch_ticker(symbol): for source in (primary_source, backup_source): try: data = source.fetch(symbol) if is_valid(data): return data except SourceUnavailable: continue raise AllSourcesFailedError(symbol)

别小看这个“不行就换源”的逻辑，它救过我很多次。还有一个容易忽略的点：新闻资讯源也要单独接，而且要做去重。同一件事被多个网站报道，AI如果每次只看到一条标题，判断就会偏。按事件指纹去重后再丢给模型，分析质量会明显提升。

2.2 AI模型选型与部署：7B参数和70B参数怎么选

自托管AI盯盘有个绕不开的选择：模型到底跑在哪。如果机器性能允许，推荐用Ollama这类工具在本地跑开源模型；如果机器只有4G内存，那就老老实实接云端模型API，把数据外发这件事接受下来。

就我的经验，盯盘分析不一定需要超大模型。7B到14B参数量的量化模型，配合设计良好的提示词，已经能完成大部分数据整理和异常判断工作。更关键的是速度和成本：本地小模型跑一次分析只要一两秒，云端大模型虽然聪明一些，但遇到轮询间隔只有几分钟的场景，调用开销和延迟都会放大。

模型部署时几个参数要特别注意：

• temperature：也就是随机性，盯盘任务不要超过0.2，建议直接设0.1；
• seed：固定随机种子，让同一输入尽量产生同一输出；
• max_tokens：给模型设置合理的输出长度上限，比如512，防止它长篇大论；
• context：上下文长度不要贪大，给太多历史数据反而会增加延迟和注意力分散。

选模型时有个实用建议：结构化的JSON输出尽量做到格式化。现在不少开源模型已经能用比较严格的格式约束输出JSON，这比让模型自由发挥稳定得多。

2.3 规则引擎与任务调度：让AI每隔几分钟看一眼

有了数据和模型，还要解决“什么时候看”的问题。我建议把规则和调度拆开来设计，规则管“看什么”，调度管“多久看一次”。

调度频率要看标的流动性。主流币和股票5分钟轮询一次是比较平衡的选择；波动大的合约市场，可以缩短到1分钟；冷门标的一天看几次都行。不建议所有标统一用一个频率，否则系统负载不均匀。

规则设计建议拆成三层：

• 第一层是硬阈值：价格越界、涨跌幅超过设定值，这类规则直接触发通知，不需要AI介入；
• 第二层是统计异常：比如成交量突然放大到20日均值的3倍，波动率飙升到历史95分位，这里先不通知，丢进AI队列；
• 第三层是AI复核：LLM结合快照、指标摘要、新闻标题输出风险等级和原因，再由通知模块按等级发送。

为什么硬阈值要优先？因为AI存在幻觉和延迟，关键时刻宁可让一条简单的规则先响，也别等模型慢慢思考。反过来，统计异常交给AI复核能过滤掉大量“放量但无意义”的噪声。

冷却机制也必不可少。同一个信号如果在半小时内反复触发，应该合并成一条消息。实现起来不复杂：给每类信号生成一个指纹，比如“BTCUSDT-突破-20240101_0900”，在冷却时间窗口内再次触发只更新摘要，不重复推送。

2.4 通知渠道：该喊的时候一定要喊得响

盯盘工具最后一步是通知，很多项目前期做得热闹，结果卡在“消息没送达”上。通知渠道我推荐三条腿走路：ntfy做轻量推送，邮件做备份，Webhook对接企业微信或钉钉。

ntfy是现在个人项目里很流行的自托管通知方案，部署简单，App端推送及时，还支持按主题订阅。邮件适合发日报和汇总，不适合发紧急预警，因为时效性不够。Webhook则适合接入已有的群机器人，让团队或小群组能同时收到消息。

通知也要分级。我的习惯是：

• info级：日常摘要，比如“今日关注列表暂无异常”，只在固定时间发；
• warn级：AI报告有值得关注的情况，推送摘要链接；
• alert级：硬阈值触发或AI高置信度异常，立即推送并可能升级到电话报警。

无论用哪种渠道，上线前一定要做一次“测试通知”。先发一条固定消息确认链路通，再把真实分析结果推过来。千万别等行情真出现异常才发现群里没收到任何消息。

3. 实操过程：从零部署一套PanWatch

3.1 部署前的准备工作

PanWatch这类系统的部署门槛并不高，准备好基础环境就能开始。一台2核4G的Linux服务器是底线，如果要用本地AI模型，建议内存加到8G以上，量化后的7B模型大约占4~6G内存。

部署前先想清楚几个问题：机器上是否装了Docker和Docker Compose；是否规划好数据目录，避免配置、日志、数据库混在一起；是否决定好模型方案——本地Ollama还是云端API。我习惯建一个panwatch目录，下面分成config、data、logs三个子目录，所有数据都落在同一棵目录树里，备份和迁移都很方便。

要提醒的是，Docker Compose文件里挂载卷一定要写好路径，否则容器重启后数据全部丢失。很多新手第一次部署时把配置写在容器内部，结果docker compose down再up之后，配置回到初始状态，所有改动全部白费。

3.2 docker-compose编排：一个文件跑起核心服务

假设你的PanWatch发行版提供了core镜像，同时需要本地模型服务，编排文件可以这样写：

version: "3.8" services: panwatch-core: image: panwatch/core:latest container_name: panwatch-core restart: unless-stopped volumes: - ./config:/app/config - ./data:/app/data - ./logs:/app/logs environment: - TZ=Asia/Shanghai - CONFIG_PATH=/app/config/config.yaml depends_on: - ollama logging: driver: json-file options: max-size: "10m" max-file: "3" ollama: image: ollama/ollama:latest container_name: panwatch-ollama restart: unless-stopped volumes: - ./models:/root/.ollama ports: - "11434:11434" deploy: resources: limits: memory: 6G

这段编排里有几个细节值得讲一下。restart设为unless-stopped，机器重启后服务自动拉起，减少人工介入。日志要配置轮转，否则长时间跑下来一个日志文件可能吃掉几个G磁盘。ollama服务把模型目录挂到宿主机的models目录，想换模型或备份模型都方便。

如果发行版没有现成镜像，结构也是照抄：core服务负责调度和分析，ollama服务提供推理能力，中间通过HTTP通信。我见过有人把模型推理也塞进core容器里，结果一升级core版本模型还得重新拉，非常痛苦。

3.3 核心配置解读：盯什么、多久看、谁来分析

配置是整个系统的主心骨。PanWatch的配置一般集中在YAML文件里，核心是watchlist、scheduler、llm、notify四段。下面是一个可参考的模板，具体数值请按自己需求改：

watchlist: - symbol: "BTCUSDT" market: "spot" hard_alerts: price_above: 70000 price_below: 50000 ai_review: true cooldown_minutes: 30 scheduler: interval_seconds: 300 run_on_start: true llm: provider: ollama base_url: "http://ollama:11434" model: "qwen2.5:7b-instruct" temperature: 0.1 seed: 42 max_tokens: 512 timeout_seconds: 30 notify: ntfy: enabled: true topic: "panwatch-alerts" mail: enabled: false webhook: enabled: true url: "https://example.com/hook/alarm"

watchlist里每个标的就是一个监控项。hard_alerts是硬性告警条件，AI不在这一层介入；ai_review表示这个标的要不要经过AI复核。cooldown_minutes是冷却时间，建议所有标的都配一个，避免半夜连续轰炸。

scheduler的interval_seconds决定轮询频率，300就是5分钟一次。llm段如果你用的是云端API，把provider改成对应厂商，base_url换成API地址即可。notify段先开ntfy和webhook，邮件等跑顺了再加。

3.4 启动与验证：先让系统“喊一嗓子”

配置文件写好之后，先别急着把所有标的都放进去，我建议用一个测试标的验证全链路。启动命令和检查步骤大概是：

docker compose up -d docker compose logs -f panwatch-core

看到日志里出现“collector running”“scheduler started”之类的内容后，再用命令确认模型服务可达：

curl http://localhost:11434/api/tags

如果返回模型列表，说明模型服务正常。接着向ntfy主题发一条测试消息，确认通知链路通。这一条消息发出去后，整个系统最关键的输入、分析、输出三个环节就都打通了。

我第一次跑通时没做测试消息，直接在watchlist里配了十几个标的，结果第二天起来发现消息推送用的主题少打了一个字母，所有预警全进了空气。所以验证步骤真的不能省。

3.5 提示词模板：AI分析质量的关键一步

模型部署好，提示词就成了影响分析质量最大的变量。好的提示词要做三件事：交代身份和上下文、限制只使用提供的数据、固定输出格式。下面这套模板我用下来效果比较稳定：

你是一名盯盘助手。当前时间：{time} 以下是最近一次行情快照： {snapshot} 以下是该标的近期K线特征和指标摘要： {indicators} 以下是相关新闻标题： {news} 请完成三项任务： 1. 判断是否存在值得关注的异常； 2. 说明理由，只能引用上面提供的信息，禁止猜测盘外消息； 3. 给出风险等级：watch / warn / alert。 必须输出JSON格式： {"level":"...","summary":"...","reasons":["...","..."]}

为什么强制输出JSON？因为后面要接通知模块和可能的自动化流程，结构化输出才能稳定解析。同时“只能引用上面提供的信息”这句话，能明显减少模型编造不存在的新闻或数据的概率。温度调到0.1，固定seed，模型输出就会比较稳定。

4. 常见问题与排查技巧实录

4.1 行情接口断连、限流，系统静默了

现象是日志里出现大量timeout和429错误，或者干脆某一段时间没有任何采集记录。这种问题通常不是程序逻辑错了，而是对数据源的依赖太单一。

排查先看日志记录的错误类型：如果是429，是请求过频，需要拉长轮询间隔或降低请求头频率；如果是timeout或连接重置，大概率是源不稳定，先把备用源切上来。处理办法是在采集层做故障转移，并且每年给主源设置容量警报，连续失败超过5次就通知你人工介入。

经验之谈：行情源不要只挂一家，尤其是免费公开接口，高峰期延迟和限流特别明显。谁也不希望自己的盯盘助手在关键行情到来前先“失明”。

4.2 AI误报与漏报，一个很考验耐心的问题

误报比漏报更容易消磨耐性。模型把一段正常波动描述成“异常”，连续几条后就会想关掉AI功能。我处理误报的原则是：AI只做二次判断，必须先用规则筛出候选，模型不能直接从原始数据全量自由判断。

漏报则通常是提示词或上下文的问题。如果模型漏掉某个细节，可以检查是不是历史K线摘要太简略，或者新闻标题被截断。给模型的上下文要有针对性地预处理，而不是把所有原始数据一股脑塞进去。做了这个调整以后，我的AI告警准确率提升非常明显。

4.3 资源占用偏高与日志膨胀

小型服务器最怕什么？磁盘被日志塞满，内存被模型吃光。对策分别是：Docker日志配置max-size和max-file，限制单文件大小和数量；模型镜像单独分配内存上限，避免和其他服务抢资源。

数据存储也要定期清理。K线数据和历史指标如果长期堆积，数据库会越来越大，建议保留90天或180天滚动清理。这些运维细节不起眼，但自托管玩久了你会发现，稳定性往往就体现在这些地方。

4.4 通知收不到，问题大多出在配置细节

通知是用户感知系统是否正常的唯一窗口，所以“有没有收到”比“分析好不好”更重要。排查顺序是：先检查服务日志里有没有发送记录；再确认通知渠道的配置项，比如网络地址是否可达、Webhook地址是否有效；最后用测试消息验证。

如果用的自建ntfy，要确认客户端设备能访问你暴露的订阅地址，反向代理也要配好。Webhook场景则先确认签名或Token有没有变动。很多时候线上改了一个密钥忘了同步到配置里，就变成了“日志显示已发送，群里什么都没收到”。

4.5 模型输出不稳定，同一样本两次分析结果不同

如果模型对同一份行情快照输出了不同的结论，大概率是温度设置过高或没有固定随机种子。把temperature降到0.1，设置一个固定seed，输出稳定性会立刻改善。

如果仍然不稳定，再看是不是上下文里有时间戳、数字格式这类微小变化影响了推理。建议在喂给模型前做一次数据归一化，比如价格统一保留两位小数，时间戳统一格式化，减少模型对格式差异的敏感度。这个细节对开源小模型尤其重要。

最后说点个人体会

自托管AI盯盘助手跑通以后，最大的收获其实不是“AI能预测涨跌”，而是帮你把注意力放到真正值得看的东西上。AI分析会有误判，规则也可能漏报，但在“硬阈值优先、AI复核兜底、冷却合并消息”这套机制下，系统已经能像一个不怎么打扰人的副驾驶，只在需要的时候拉一下你的袖子。

如果你准备上手，我的建议是：先用一个标的、一条规则、一个通知渠道跑通，稳定运行一周后再逐步加复杂逻辑。提示词要当代码来维护，每次误报都记录下来，慢慢你会发现模型对常见模式的判断越来越准。自托管的路确实多了一些运维上的活，但那种“所有环节都由自己掌控”的感觉，是SaaS替代不了的。