PanWatch这类自托管AI盯盘助手最近在我关注的圈子里讨论度很高。我自己的使用场景其实很明确白天要上班行情却常常在关键时段突变那些SaaS预警工具要么规则写得太死要么要把自选列表甚至部分持仓快照传到别人服务器上怎么想都不太对劲。后来我把盯盘这件事彻底搬回了自己机器上用AI Agent来做分析判断PanWatch就是这套思路的典型代表。这个方案说穿了并不复杂自托管把软件跑在自己能控制的服务器上数据、配置、通知渠道全部归自己AI盯盘则是把过去“价格大于某个数就提醒”的死规则升级成“结合K线、成交量、资金费率、新闻标题做综合判断”的智能体。适合谁来参考我觉得有两类人最值一类是有Linux或Docker基础的个人投资者想摆脱云端工具的种种限制另一类是技术爱好者想把AI Agent、调度任务、多源数据采集串成一个真实可用的工程项目。下面文章里我把从零部署、调优、踩坑的整个过程整理出来包括架构选型、数据源接入、模型部署、规则设计、常见故障排查。内容偏实操不搞空谈。1. 整体设计思路为什么是“自托管AI”而不是“SaaSApp”1.1 自托管的真正价值不是省钱而是可控很多人一听到自托管第一反应是“可以省掉订阅费”。我的体会是省钱只是顺带的真正的好处是控制权。先说隐私。行情数据本身不算敏感但你的自选列表、关注的标的、持仓信息、盯盘策略这些拼在一起会暴露出你的交易偏好和资金体量。放到云端的SaaS产品里等于把这些信息交给了第三方。自托管以后所有数据都留在你自己的机器上AI分析时该读什么、该输出什么完全由你的配置说了算。再说规则自由。SaaS工具通常只提供固定预警模板比如突破、跌破、涨跌幅超过N%。但真实盯盘里需求千奇百怪我想让AI在“成交量是过去20日均值的3倍以上”且“价格刚好接近前高”的时候才开始关注还要附带一段中文解读。这种复合逻辑在SaaS里要么需要复杂的公式脚本要么根本做不了。自托管之后这就只是改几行配置的事。最后是可扩展性。自托管服务可以随便对接自己的数据库、报表系统、企业微信机器人甚至把AI分析结果再喂给下一个自动化流程。用一句生活类比SaaS是住酒店设施齐全但家具不能动自托管是买自己的房子装修拆墙都随你。代价是水电煤都要自己管项目跑挂了只能自己扛。1.2 AI盯盘与传统条件盯盘的本质区别传统条件盯盘的逻辑是当“A指标满足”时“执行B动作”。比如价格突破70000就发通知。这种规则简单直接但问题也很明显没有上下文不知道这个突破发生在凌晨三点低流动性时段还是放量突破关键位误报率很高。AI盯盘的本质区别在于它把“判断”也交给模型。同样是突破AI会结合几类信息一起看当前价格与均线距离、过去24小时成交量变化、资金费率是否偏高、相关新闻情绪如何然后输出类似“当前突破伴随放量和舆情升温但流动性偏低建议提高警惕”这样的结论。我并不是说传统规则不好恰恰相反硬性条件规则是AI盯盘的“门槛”。正确做法是让规则先把明显异常筛出来再由AI做二次判断这能显著降低模型幻觉带来的噪声。表格对比会更直观维度传统条件盯盘AI盯盘触发机制单一指标阈值多源数据综合判断输出内容“价格突破73000”“突破放量舆情偏多留意回调”误报率偏高无上下文过滤相对低但存在模型幻觉部署复杂低中高需要模型与调度可解释性完全可解释依赖提示词与输出结构设计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.1seed固定随机种子让同一输入尽量产生同一输出max_tokens给模型设置合理的输出长度上限比如512防止它长篇大论context上下文长度不要贪大给太多历史数据反而会增加延迟和注意力分散。选模型时有个实用建议结构化的JSON输出尽量做到格式化。现在不少开源模型已经能用比较严格的格式约束输出JSON这比让模型自由发挥稳定得多。方案优点缺点适用场景本地7B量化模型延迟低、隐私好、免费推理能力有限自托管主力方案本地14B量化模型效果更好延迟可接受内存和显存要求更高配置较好的服务器云端大模型API能力强、无需硬件数据外发、按量付费个人没有GPU的过渡方案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. 实操过程从零部署一套PanWatch3.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: - TZAsia/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/alarmwatchlist里每个标的就是一个监控项。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替代不了的。