1. 盯盘这件事为什么我最后选择了自托管方案做交易的人都有一个共同的痛点行情不等人。白天上班、晚上带娃、半夜睡觉行情该走还是走该砸还是砸。我最早用的是手机端的价格提醒设几个关键价位到点响一声。用了一段时间发现两个问题一是提醒太死板只认价格不认形态二是数据全在别人服务器上我连自己设了多少条提醒、触发逻辑是什么都查不清楚。后来试过一些在线的智能盯盘工具功能确实花哨但要么按年收费不便宜要么数据流向不透明心里总是不踏实。PanWatch 这个项目就是在这个背景下进入我视野的。它的定位很明确自托管、AI 驱动、盯盘助手。关键词里出现的 TradingAgents 和 EasyClaw 也印证了它的技术路线——用多智能体协作的方式来做行情分析和信号判断而不是简单的阈值触发。说白了它想做的事情是把盯盘这件事从设个价格提醒升级成让几个 AI 角色帮你从不同角度分析当前行情然后告诉你现在值不值得关注。这篇文章适合几类人看一是对自托管工具感兴趣、想自己掌控数据的技术型交易者二是想了解 AI Agent 在金融场景怎么落地、怎么扛住实时数据流的开发者三是单纯好奇AI 盯盘到底靠不靠谱、值不值得折腾的普通用户。我会从架构设计、核心机制、部署实操、踩坑经验几个维度把 PanWatch 拆开讲清楚尽量做到看完就能自己动手跑起来。需要提前说明的是PanWatch 本身是一个开源项目我基于公开信息和实际部署经验来写涉及具体策略的部分大家自行判断本文不构成任何投资建议。工具是工具决策是决策这个边界要分清楚。2. PanWatch 的架构骨架多智能体协作到底怎么跑起来的2.1 从 TradingAgents 说起为什么不是单模型一把梭很多人第一次听到AI 盯盘脑子里浮现的是一个模型盯着 K 线图然后吐出一个买或卖。这种单模型方案的问题在于一个模型很难同时兼顾技术面、基本面、情绪面而且它的判断过程是个黑盒你没法知道它为什么得出这个结论。TradingAgents 的思路不一样。它把分析任务拆给多个角色每个角色有自己的职责和视角。PanWatch 借鉴了这个思路在架构上做了几个关键设计角色分离不同的 Agent 负责不同的分析维度比如有的看价格行为有的看成交量异动有的看新闻情绪。每个 Agent 的输出是结构化的不是一段模糊的自然语言。协作决策多个 Agent 的结论汇总到一个协调层由协调层做加权或投票最终输出一个综合信号。这样做的好处是单一 Agent 的误判不会直接变成最终决策。可追溯每个 Agent 的判断依据都会被记录下来你事后可以复盘当时为什么给了这个信号。这个设计思路其实和现实中的交易团队很像分析师各看各的最后基金经理拍板。PanWatch 把这个流程自动化了而且跑在你自己的机器上。2.2 EasyClaw 在链路里扮演什么角色关键词里的 EasyClaw 值得单独说一下。从命名和常见实践来看它大概率是 PanWatch 用来做任务调度和 Agent 编排的组件。你可以把它理解成一个工头它不负责具体分析但负责决定什么时候唤醒哪个 Agent、数据从哪来、结果往哪送。为什么需要这么一层因为盯盘是个持续运行的任务不是跑一次就完事。行情数据是流式的Agent 的调用是有成本的不管是算力成本还是时间成本如果每个数据点都触发全量分析系统很快就扛不住了。EasyClaw 这层的价值在于按需触发只有满足特定条件比如价格突破关键位、成交量突然放大才唤醒对应的 Agent避免无效计算。并发控制多个 Agent 可以并行跑但要有上限否则本地机器资源会被吃满。失败重试某个 Agent 调用失败了调度层负责重试或降级不让整个链路断掉。我在实际部署时观察到如果没有这层调度直接把数据流怼给模型响应延迟会非常高而且费用不可控。加上调度层之后系统的有效分析密度明显提升——同样的算力能覆盖更多有价值的行情节点。2.3 自托管带来的数据主权自托管这个词听起来有点技术宅但它的核心价值很实在数据在你自己的机器上逻辑你可以自己改服务不会因为别人关停而消失。具体到 PanWatch你的自选列表、提醒规则、历史信号记录都存在本地数据库里不经过第三方服务器。Agent 的提示词和判断逻辑是开源的你可以根据自己的交易风格调整。比如你觉得某个 Agent 太保守可以改它的权重你觉得某个维度没用可以直接关掉。没有订阅费。电费和机器折旧是你唯一的持续成本。当然自托管也有代价你得自己维护服务器、自己处理数据源的稳定性、自己承担机器故障的风险。这个取舍后面会详细讲。3. 部署实操从零把 PanWatch 跑起来3.1 环境准备与依赖清单PanWatch 的部署对机器有一定要求不是随便一台旧笔记本就能跑得顺的。以下是我实测下来比较稳妥的配置项目最低配置推荐配置说明CPU2 核4 核以上Agent 并发调用时 CPU 会吃紧内存4 GB8 GB 以上多 Agent 并行时内存占用明显磁盘20 GB50 GB SSD历史行情和信号记录会持续增长网络稳定宽带低延迟宽带行情数据对延迟敏感运行环境DockerDocker Docker Compose官方推荐容器化部署操作系统方面Linux 是首选Ubuntu 22.04 或 Debian 12 都比较稳。如果你用 macOSDocker Desktop 也能跑但长时间运行的稳定性不如 Linux。Windows 的话建议走 WSL2直接跑 Docker 会有一些路径和权限的坑。依赖方面核心是这几样Docker 和 Docker Compose容器化部署的基础版本不要太老Compose 建议 v2 以上。数据库PanWatch 通常用 PostgreSQL 或 SQLite 存数据。SQLite 适合单机轻量场景PostgreSQL 适合数据量大、需要并发读写的场景。行情数据源这是最关键的外部依赖。你需要自己准备数据接口具体用哪家这里不展开原则是选稳定、延迟低、覆盖你关注市场的源。模型接口Agent 的推理需要调用大模型。你可以用云端 API也可以在本地跑小模型。云端 API 省事但按量计费本地模型省钱但需要 GPU。提示如果你打算长期跑建议把数据库和主程序分开部署至少用 Docker volume 把数据持久化出来。我见过有人容器一删数据全没的历史信号记录丢了很麻烦。3.2 配置文件的关键字段拆解PanWatch 的配置通常集中在一个 YAML 或环境变量文件里。以下是我认为最需要关注的几类字段以及它们背后的逻辑数据源配置datasource: provider: your_provider api_key: your_key symbols: - BTC/USDT - ETH/USDT interval: 1m history_days: 30interval决定了数据粒度。1 分钟适合短线盯盘但数据量和计算量都大5 分钟或 15 分钟适合中长线资源消耗小很多。这个要根据你的交易周期来定不要盲目追求高频。history_days是启动时拉取的历史数据天数。Agent 做分析时需要上下文太短了判断不准太长了启动慢。30 天是个比较平衡的值。Agent 配置agents: - name: price_action enabled: true weight: 1.0 trigger: price_change_pct: 2.0 - name: volume_anomaly enabled: true weight: 0.8 trigger: volume_ratio: 3.0 - name: sentiment enabled: false weight: 0.5weight是权重协调层汇总时用。如果你更信任技术面可以把 price_action 的权重调高。trigger是触发条件。price_change_pct: 2.0意思是价格波动超过 2% 才唤醒这个 Agent。这个值设太小会导致频繁调用设太大又会漏掉机会。我的经验是先从 2% 开始跑一周看触发频率再调。enabled可以单独关掉某个 Agent。比如你不想用情绪分析直接设 false省算力。调度配置scheduler: max_concurrent_agents: 3 retry_times: 2 retry_delay_seconds: 5 cooldown_seconds: 60max_concurrent_agents控制并发上限。设太高机器扛不住设太低分析延迟大。4 核 8G 的机器建议设 3。cooldown_seconds是同一个 Agent 两次调用之间的最小间隔。这个参数很重要能防止行情剧烈波动时 Agent 被反复唤醒导致资源耗尽。3.3 启动流程与首次验证配置写好后启动流程大致是拉取镜像docker compose pull启动服务docker compose up -d查看日志docker compose logs -f panwatch验证数据流确认行情数据正常写入数据库触发一次手动分析看 Agent 是否能正常返回结果首次启动最容易出问题的地方是数据源连接。日志里如果出现datasource connection failed或api key invalid先检查 key 有没有过期、IP 有没有被限制、symbol 格式对不对。不同数据源对 symbol 的写法要求不一样有的要BTCUSDT有的要BTC/USDT这个要对着文档确认。另一个常见问题是模型接口超时。如果你用的是云端 API首次调用可能会有冷启动延迟。建议在配置里把超时时间设长一点比如 30 秒避免因为偶发延迟导致 Agent 调用失败。验证通过后你可以观察一段时间日志看看 Agent 的触发频率是否合理。如果发现某个 Agent 几乎没被触发过说明 trigger 条件设太严了如果频繁触发说明设太松了。这个调参过程是必须的没有一套参数能适合所有人。4. 盯盘逻辑的核心信号是怎么产生的4.1 从原始数据到 Agent 输入的数据管道行情数据从数据源进来的时候是一堆带时间戳的 OHLCV 记录。这些原始数据不能直接丢给 Agent中间需要经过一层处理清洗去掉重复记录、补全缺失的时间点、处理异常值比如明显错误的插针。特征计算算出 Agent 需要的衍生指标比如移动平均线、波动率、成交量比率等。窗口切片把连续数据切成固定长度的窗口每个窗口作为一个分析单元。这层管道的设计直接影响 Agent 的分析质量。我踩过的一个坑是早期为了省事直接把原始 tick 数据丢给 Agent结果模型被大量噪声干扰输出的信号质量很差。后来加了清洗和特征计算信号的可解释性明显提升。另一个经验是窗口长度要和 Agent 的分析目标匹配。看短期波动的 Agent 用短窗口比如 60 个数据点看趋势的 Agent 用长窗口比如 240 个数据点。如果所有 Agent 都用同一个窗口要么短视要么迟钝。4.2 多 Agent 结论的汇总机制多个 Agent 各自给出判断后怎么汇总成一个最终信号PanWatch 的做法通常是加权投票或评分制。假设三个 Agent 分别给出price_action看多置信度 0.7volume_anomaly中性置信度 0.5sentiment看空置信度 0.6协调层会根据配置的权重计算一个综合分。如果 price_action 权重 1.0、volume_anomaly 权重 0.8、sentiment 权重 0.5那么综合分大致是score (0.7 * 1.0) (0.5 * 0.8) (-0.6 * 0.5) 0.7 0.4 - 0.3 0.8正分偏多负分偏空。具体阈值怎么定要看你的风险偏好。保守的话可以把阈值设高一点只有综合分超过某个值才发信号。这里有个细节值得注意置信度的校准。模型给出的置信度不一定准有的模型天生过度自信。我建议在实盘使用前先用历史数据回测一下看看不同置信度区间的实际准确率然后据此调整权重或阈值。4.3 信号输出与提醒通道信号产生后需要推送到你能看到的地方。PanWatch 通常支持多种提醒通道Web 界面最直观能看到信号详情和 Agent 的分析依据。Webhook可以对接各种消息平台实现手机推送。邮件适合不追求实时性、但需要留档的场景。我的建议是重要信号走实时通道普通信号走汇总通道。如果所有信号都实时推送很快你就会对提醒麻木反而漏掉真正重要的。可以在配置里设一个信号等级只有高等级信号才触发即时推送低等级信号攒着定期汇总。注意提醒通道的稳定性很关键。我遇到过 webhook 服务挂掉导致信号丢失的情况后来加了一个本地日志兜底所有信号先写本地推送失败可以事后补看。5. 实际运行中踩过的坑与调优经验5.1 资源占用失控的排查过程系统跑起来第一周我发现机器负载越来越高最后直接卡死。排查过程大致是这样的第一步看容器资源占用docker stats发现 panwatch 容器的 CPU 占用长期在 90% 以上内存也在持续增长。第二步看日志找异常日志里出现大量重复的 Agent 调用记录同一个 Agent 在几分钟内被触发了十几次。原因是行情波动剧烈时价格变化频繁超过 trigger 阈值导致 Agent 被反复唤醒。第三步定位配置问题检查配置发现cooldown_seconds设的是 10 秒太短了。而且max_concurrent_agents设的是 5超过了机器实际能承受的量。第四步修复与验证把cooldown_seconds调到 60 秒max_concurrent_agents降到 3同时给 trigger 加了一个最小间隔条件。重启后观察一天CPU 占用稳定在 40% 左右内存也不再持续增长。这个坑的教训是默认配置不一定适合你的机器和行情环境。上线前一定要压测观察高峰时段的资源表现。5.2 Agent 输出质量不稳定的应对跑了一段时间后我发现 Agent 的输出质量波动很大。有时候分析得很到位有时候明显在胡说。排查下来有几个原因上下文不足某些 Agent 拿到的数据窗口太短信息量不够模型只能瞎猜。解决办法是给这类 Agent 单独配置更长的窗口。提示词歧义Agent 的提示词如果写得模糊模型的理解会不稳定。我把提示词改得更结构化明确要求输出格式和判断依据稳定性好了很多。数据源延迟行情数据有延迟时Agent 分析的是过时的数据结论自然不准。这个需要在数据管道层加时间戳校验延迟超过阈值的数据直接丢弃。还有一个经验不要迷信单一 Agent 的判断。多 Agent 协作的价值就在于互相制衡。如果某个 Agent 经常给出极端结论要么调低它的权重要么检查它的输入数据是不是有问题。5.3 数据持久化与备份策略自托管最大的风险是数据丢失。我现在的做法是数据库定期备份每天凌晨自动 dump 一次保留最近 30 天。配置文件版本管理所有配置用 Git 管理每次改动都有记录出问题可以快速回滚。信号记录双写重要信号同时写数据库和本地文件防止数据库故障导致记录丢失。这些措施看起来麻烦但真出问题的时候能救命。我有一次数据库文件损坏靠备份恢复了大部分数据只丢了几小时的记录。6. 自托管 AI 盯盘的边界与我的使用体会6.1 它擅长什么不擅长什么用了一段时间后我对 PanWatch 这类工具的能力边界有了比较清晰的认识。它擅长的持续、不知疲倦地监控多个标的不会因为疲劳或情绪漏看行情。从多个维度同时分析避免单一视角的盲区。记录完整的分析过程方便事后复盘和学习。它不擅长的预测突发事件。黑天鹅来了历史数据里没有的模式Agent 也给不出有效判断。替代人的最终决策。工具给的是参考信号仓位管理、风险控制这些还是得自己来。处理极端行情。流动性枯竭或剧烈波动时数据质量和模型表现都会下降。我的使用方式是把 PanWatch 当作一个永不休息的助理它负责筛选和提示我负责决策和执行。这个定位比较务实也不会对工具有不切实际的期待。6.2 关于成本和维护的现实考量自托管不是零成本。除了机器和电费还有几块隐性成本时间成本部署、调参、排错、升级这些都要花时间。如果你完全不懂技术学习曲线会比较陡。模型调用成本如果用云端 APIAgent 调用频繁的话费用不低。建议设置预算上限和告警。维护成本数据源接口可能会变模型 API 可能会升级这些都需要跟进。我的建议是先用最低配置跑起来验证它对你是否真的有价值再决定要不要加大投入。不要一上来就买高配机器、充大量 API 额度万一用不惯就浪费了。6.3 后续可以怎么扩展PanWatch 的架构是开放的后续可以往几个方向扩展接入更多数据源除了行情数据还可以接入链上数据、社交情绪数据等让 Agent 的分析维度更丰富。自定义 Agent如果你有特定的分析逻辑可以写自己的 Agent 插件挂到调度层里。回测框架把历史信号和实际走势做对比量化评估每个 Agent 的表现据此动态调整权重。我现在正在做的是第二项写了一个基于特定形态识别的 Agent还在调优阶段。等跑稳定了再单独写一篇分享。最后分享一个小技巧新 Agent 上线前先让它影子运行一段时间。也就是让它正常分析、正常输出但不接入最终信号只记录它的判断。跑一两周后对比它的判断和实际走势确认靠谱了再正式启用。这样能避免一个不成熟的 Agent 直接污染你的信号系统。