1. PanWatch 项目定位与核心思路拆解1.1 这个项目到底在解决什么问题PanWatch 这个名字拆开看Pan 指向的是全景、全局的视角Watch 则是持续盯盘、监控的意思。合在一起它要做的就是一个面向多市场、多资产的统一行情监控与智能分析面板。你可以把它理解成一个自建的个人行情驾驶舱——把股票、加密货币、外汇、大宗商品这些分散在不同平台的数据通过 TradingAgents 这类多智能体框架做聚合分析最后在一个 PWA 应用里统一呈现。为什么我要自己折腾这么一套东西市面上现成的行情软件其实不少但痛点也很明显第一数据源割裂看 A 股用一个软件看币圈用另一个看外汇再换一个来回切换极其消耗注意力第二大部分软件只给你原始数据不给分析结论K 线、成交量、MACD 摆在那里但现在该关注什么这件事得你自己判断第三定制化程度低你想加一个自己定义的指标或者预警逻辑基本没戏。PanWatch 的核心价值就在于把这三点一次性解决掉。它用 TradingAgents 的思路——也就是让多个各司其职的 Agent 分别负责数据采集、技术指标计算、情绪分析、风险预警——把看盘这件事从被动接收变成主动推送。你不需要一直盯着屏幕系统会在关键信号出现时通过 PWA 的推送能力通知你。适合谁来参考这个项目我认为有三类人一是有一点编程基础、想搭建自己监控体系的个人投资者二是对 Agent 框架和 Docker 部署感兴趣、想找一个完整落地案例来练手的开发者三是做量化或者金融数据相关工作的朋友想看看多智能体在行情分析场景下怎么编排。哪怕你只是想学 Docker 部署和 PWA 开发这个项目也是一个结构足够完整的实战样本。1.2 为什么选 TradingAgents 这套多智能体架构传统行情监控系统的做法是一个主程序 一堆定时任务所有逻辑耦合在一起加一个新指标就要改主流程维护起来很痛苦。PanWatch 选择 TradingAgents 这种多智能体架构本质上是把关注点分离这件事做到了极致。具体来说每个 Agent 只干一件事。数据采集 Agent 负责从各个数据源拉取原始行情它不关心这些数据后面怎么用技术分析 Agent 拿到数据后只负责计算指标、识别形态情绪分析 Agent 专门处理新闻、公告、社交媒体的文本输出情绪打分风险预警 Agent 则综合前面几个 Agent 的输出判断是否触发预警条件。这种设计的好处是任何一个环节出问题都不会拖垮整个系统而且你想替换某个数据源或者加一个新指标只需要动对应的那个 Agent其他部分完全不受影响。从工程角度看这种架构还有一个隐性优势它天然适合容器化部署。每个 Agent 可以独立打包成一个容器通过 Docker Compose 编排在一起彼此之间通过网络通信。这比把所有逻辑塞进一个进程要清晰得多也方便你按需扩容——比如行情高峰期给数据采集 Agent 多开几个实例。提示多智能体架构不是银弹。如果你的需求只是监控三五个标的、每天看一次那用不着上这么重的方案一个 Python 脚本加定时任务就够了。PanWatch 这套架构的价值在于多市场、多标的、高频次、要分析这四个条件同时成立的时候。1.3 技术选型背后的取舍逻辑PanWatch 的技术栈可以概括为Docker 做部署底座TradingAgents 做分析内核PWA 做前端呈现。这三者不是随便凑的每一个选择都有明确的理由。选 Docker 是因为行情监控系统对环境的依赖很重——Python 版本、各种金融数据库的客户端库、时区配置、定时任务调度这些东西在裸机上装一遍能踩一整天坑。Docker 把这些依赖全部封进镜像换一台机器只要docker compose up就能跑起来环境一致性有保障。而且 Docker 的网络隔离特性让你可以放心地把数据采集 Agent 暴露在公网侧分析 Agent 放在内网侧安全性更好控制。选 PWA 而不是原生 App是因为 PWA 的开发成本低、跨平台能力强而且它支持离线缓存和后台推送。对于行情监控这种平时不用、关键时刻要立刻看到的场景PWA 的推送能力刚好匹配。你不需要去应用商店上架一个链接发到手机上就能用更新也是即时的。TradingAgents 作为分析内核看中的是它的可扩展性。你可以用现成的 Agent 模板快速搭起来也可以自己写新的 Agent 接进去。它本质上是一个编排框架把谁在什么时候做什么这件事用代码描述清楚剩下的交给运行时去调度。2. 核心模块拆解与关键细节解析2.1 数据采集 Agent 的设计要点数据采集是整个系统的入口也是最容易出问题的地方。PanWatch 的数据采集 Agent 需要处理三类数据源交易所 API、公开数据接口、以及网页抓取。这三类的稳定性和频率限制完全不同必须区别对待。交易所 API 通常有严格的频率限制比如每分钟最多 1200 次请求。如果你有 50 个标的要监控每个标的要拉 K 线、盘口、成交明细很容易就超限。我的做法是在采集 Agent 里内置一个令牌桶限流器把请求速率控制在限制的 80% 左右留出余量。同时用 Redis 做一层缓存相同标的的相同周期数据在 5 秒内不重复请求。公开数据接口的稳定性差一些经常出现超时或者返回格式变化。针对这种情况采集 Agent 需要实现重试机制和降级策略。重试不是简单地重试三次就完事而是要用指数退避——第一次等 1 秒第二次等 2 秒第三次等 4 秒避免在对方服务已经过载的时候继续加压。降级策略则是当某个数据源连续失败超过阈值时自动切换到备用数据源同时发一条告警通知。网页抓取是最脆弱的一环因为页面结构随时可能变。我的经验是尽量不用网页抓取能用 API 就用 API。如果实在没有 API那就把抓取逻辑单独封装成一个 Agent并且加上结构校验——每次抓取后检查关键字段是否存在如果连续几次校验失败就自动停掉这个 Agent 并告警避免它一直返回脏数据污染下游分析。# 采集 Agent 的限流与重试核心逻辑示意 import time from functools import wraps def rate_limit(calls_per_minute1000): min_interval 60.0 / calls_per_minute last_called [0.0] def decorator(func): wraps(func) def wrapper(*args, **kwargs): elapsed time.time() - last_called[0] wait min_interval - elapsed if wait 0: time.sleep(wait) result func(*args, **kwargs) last_called[0] time.time() return result return wrapper return decorator def retry_with_backoff(max_retries3, base_delay1): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt max_retries - 1: raise time.sleep(base_delay * (2 ** attempt)) return wrapper return decorator2.2 技术分析 Agent 的指标计算与信号生成技术分析 Agent 拿到原始 K 线数据后要做的事情是计算指标并生成可读的信号。这里有个关键设计决策指标计算是放在 Agent 内部做还是单独抽一个计算服务我的选择是放在 Agent 内部但把计算逻辑写成纯函数方便测试和复用。为什么不做成独立服务因为指标计算是 CPU 密集型但数据量不大的操作单独拆一个服务反而增加了网络开销和部署复杂度。写成纯函数的好处是你可以用历史数据回测验证指标逻辑是否正确而不需要启动整个系统。PanWatch 里我实现了几个核心指标均线系统MA5/MA10/MA20/MA60、MACD、RSI、布林带、成交量异动检测。每个指标的计算都要注意数据对齐问题——不同周期的 K 线时间戳可能不一致必须先做时间对齐再计算。比如日线数据是每天 0 点小时线是整点你要算日线级别的 MACD 就必须先把小时线聚合上去。信号生成是技术分析 Agent 的输出环节。我的做法是定义一个信号优先级趋势信号均线金叉死叉优先级最高其次是超买超卖信号RSI 极值最后是形态信号头肩顶、双底等。当多个信号同时出现时按优先级排序输出避免信息过载。注意技术指标不是越多越好。我一开始加了十几个指标结果每天收到几十条信号根本看不过来。后来精简到五个核心指标信号数量降到每天三到五条反而更有参考价值。指标的价值在于少而准不在于多而全。2.3 情绪分析 Agent 的文本处理链路情绪分析 Agent 处理的是非结构化文本包括新闻标题、公司公告、社交媒体帖子。这条链路的难点在于文本来源杂、格式乱、噪音大而且金融领域的文本有大量专业术语和反讽表达通用情感分析模型经常判断错误。我的处理链路分四步清洗、分词、打分、聚合。清洗阶段去掉 HTML 标签、广告文本、重复内容分词阶段用金融领域词典做分词把利好利空涨停跌停这些词单独标记打分阶段用一个轻量级的分类模型给每段文本打 -1 到 1 的情绪分聚合阶段按时间窗口把多段文本的分数加权平均时间越近的权重越高。这里有个实操心得不要迷信大模型。我试过用大模型做情绪分析效果确实好但成本和延迟都太高不适合高频监控场景。后来换成一个微调过的小模型准确率只降了不到 5 个百分点但速度快了十倍成本几乎可以忽略。对于行情监控这种场景响应速度比绝对准确率更重要。2.4 风险预警 Agent 的触发逻辑风险预警 Agent 是整个系统的决策者它综合技术分析和情绪分析的输出判断是否触发预警。这里的核心设计是多条件与和多条件或的组合。举个例子一个强烈看空预警的触发条件是——技术面出现死叉条件 A且 RSI 高于 70条件 B且情绪分低于 -0.5条件 C。这三个条件必须同时满足才触发这叫多条件与。而一个关注级别的预警可能只需要条件 A 或条件 B 满足即可这叫多条件或。为什么要这样设计因为不同级别的预警对准确率的要求不同。高级别预警宁可漏报不可误报所以用与逻辑收紧条件低级别预警宁可误报不可漏报所以用或逻辑放宽条件。这样用户可以根据自己的风险偏好选择接收哪个级别的预警。预警触发后Agent 会生成一条结构化消息包含触发原因、相关标的、当前价格、建议关注点然后通过 PWA 的推送通道发给用户。消息格式要尽量简洁因为手机通知栏能显示的字数有限详细信息放在点开后的页面里。3. Docker 部署全流程与实操记录3.1 环境准备与 Docker 安装避坑PanWatch 的部署底座是 Docker所以第一步是把 Docker 环境搭好。这里我踩过的坑比较多逐个说。Windows 用户最容易遇到的问题是 Virtualization support not detected 和 Docker Desktop failed to start。这两个报错的根源是一样的BIOS 里的虚拟化支持没开。解决办法是重启进 BIOS找到 Intel VT-x 或者 AMD-V 选项设为 Enabled。注意有些主板把这个选项藏在 Advanced CPU Configuration 或者 Security 菜单下面不在显眼位置。开完之后还要确认 Windows 的 Hyper-V 和 WSL2 功能已经启用这两个是 Docker Desktop 在 Windows 上运行的前提。另一个高频报错是 failed to connect to the Docker API at npipe:////./pipe/dockerDesktopLinuxEngine。这个通常是 Docker Desktop 的后台服务没起来或者 WSL2 的集成没配好。我的排查顺序是先看 Docker Desktop 托盘图标是不是绿色的如果是黄色或者红色点开看具体报错然后检查 WSL2 是否正常在 PowerShell 里跑wsl --status最后确认 Docker Desktop 的设置里 Resources WSL Integration 已经勾选了你用的发行版。Linux 用户相对简单但也要注意权限问题。安装完 Docker 后默认只有 root 能操作普通用户要加进 docker 组sudo usermod -aG docker $USER然后重新登录生效。另外国内环境拉镜像可能慢建议配置镜像加速器在/etc/docker/daemon.json里加上 registry-mirrors 配置。Ubuntu 上安装 Docker 的完整命令如下# 卸载旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install ca-certificates curl gnupg lsb-release # 添加官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加仓库 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin # 验证 sudo docker run hello-world3.2 Docker Compose 编排文件详解PanWatch 的各个 Agent 通过 Docker Compose 编排在一起。下面是我实际使用的 compose 文件结构做了脱敏处理但保留了核心逻辑。version: 3.8 services: redis: image: redis:7-alpine container_name: panwatch-redis restart: unless-stopped ports: - 6379:6379 volumes: - redis-data:/data command: redis-server --appendonly yes networks: - panwatch-net postgres: image: postgres:15-alpine container_name: panwatch-db restart: unless-stopped environment: POSTGRES_USER: panwatch POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: panwatch volumes: - pg-data:/var/lib/postgresql/data networks: - panwatch-net collector: build: ./agents/collector container_name: panwatch-collector restart: unless-stopped depends_on: - redis - postgres environment: REDIS_URL: redis://redis:6379 DB_URL: postgresql://panwatch:${DB_PASSWORD}postgres:5432/panwatch networks: - panwatch-net analyzer: build: ./agents/analyzer container_name: panwatch-analyzer restart: unless-stopped depends_on: - redis - postgres environment: REDIS_URL: redis://redis:6379 DB_URL: postgresql://panwatch:${DB_PASSWORD}postgres:5432/panwatch networks: - panwatch-net web: build: ./web container_name: panwatch-web restart: unless-stopped ports: - 8080:80 depends_on: - analyzer networks: - panwatch-net volumes: redis-data: pg-data: networks: panwatch-net: driver: bridge这个编排文件有几个设计要点值得说明。第一Redis 和 Postgres 都用了restart: unless-stopped保证容器异常退出后自动重启这是生产环境的基本要求。第二所有 Agent 都通过内部网络panwatch-net通信只有 web 服务暴露了 8080 端口给外部访问其他服务都不对外暴露安全性更好。第三数据库密码通过环境变量注入不写在文件里避免泄露。提示depends_on只保证启动顺序不保证服务就绪。也就是说 collector 容器启动了不代表 Redis 已经能接受连接。稳妥的做法是在 Agent 代码里实现连接重试或者在 compose 里加 healthcheck。3.3 数据持久化与备份策略行情数据是持续增长的如果不做清理和归档数据库很快就会撑爆。我的策略是分层存储最近 7 天的原始数据放在 Postgres 里方便快速查询7 天到 90 天的数据做降采样后归档90 天以上的数据只保留日线级别其他全部删除。降采样的逻辑是小时线数据按天聚合取开盘价、最高价、最低价、收盘价、成交量总和分钟线数据按小时聚合同样取 OHLCV。这样数据量能压缩到原来的十分之一左右但保留了主要信息。备份方面我用一个独立的定时任务容器每天凌晨把 Postgres 的数据 dump 出来压缩后存到本地磁盘同时保留最近 30 天的备份。备份文件命名带上日期方便回滚。恢复的时候直接用pg_restore导入即可。# 备份脚本核心逻辑 #!/bin/bash DATE$(date %Y%m%d) BACKUP_DIR/backups docker exec panwatch-db pg_dump -U panwatch panwatch | gzip ${BACKUP_DIR}/panwatch_${DATE}.sql.gz # 删除 30 天前的备份 find ${BACKUP_DIR} -name panwatch_*.sql.gz -mtime 30 -delete3.4 PWA 前端的部署与推送配置PWA 前端的部署相对简单用 Nginx 做静态文件服务即可。关键是要配置好 Service Worker 和 manifest.json这两个文件决定了 PWA 能不能被安装到桌面、能不能接收推送。Service Worker 的核心作用是缓存静态资源和拦截网络请求。我的策略是HTML 文件用 network-first保证每次都能拿到最新版本CSS、JS、图片用 cache-first减少加载时间API 请求不缓存直接走网络。这样既保证了更新及时又保证了加载速度。推送配置需要生成 VAPID 密钥对公钥放在前端私钥放在后端。用户第一次访问时会弹出通知授权请求同意后前端把订阅信息发给后端保存。后端在触发预警时用私钥签名后向推送服务发送消息推送服务再转发给用户的浏览器。// 前端注册 Service Worker 和推送订阅 if (serviceWorker in navigator PushManager in window) { const registration await navigator.serviceWorker.register(/sw.js); const subscription await registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); await fetch(/api/subscribe, { method: POST, body: JSON.stringify(subscription), headers: { Content-Type: application/json } }); }4. 常见问题排查与实战避坑指南4.1 Docker 网络不通的排查思路Docker 网络问题是部署阶段最高频的故障。表现通常是容器启动了但容器之间互相 ping 不通或者容器访问不了外网。排查要按层次来从下往上逐层确认。第一层确认容器是否在同一个网络里。用docker network inspect panwatch-net看有哪些容器接入了。如果某个容器不在列表里说明 compose 文件里没给它指定网络或者指定了不同的网络。第二层确认 DNS 解析是否正常。Docker 内置的 DNS 服务会把容器名解析成 IP如果解析失败说明容器名写错了或者网络配置有问题。可以在容器里跑nslookup redis测试。第三层确认防火墙规则。宿主机上的 iptables 或者 firewalld 可能会拦截 Docker 的流量。特别是 CentOS 系统默认的 firewalld 规则经常和 Docker 冲突。临时关闭防火墙测试一下如果通了就说明是防火墙问题需要加放行规则。第四层确认端口映射是否正确。容器内部端口和宿主机端口是两回事ports: 8080:80表示宿主机 8080 映射到容器 80。如果你在容器里服务监听的是 3000那映射就要写8080:3000写错了就访问不到。4.2 Agent 执行中断的常见原因Agent execution terminated due to error 这个报错在 Agent 开发中很常见但原因可能五花八门。我整理了一个排查表按出现频率排序。报错现象可能原因排查方法解决方案启动后立即退出环境变量缺失docker logs看报错补全 compose 里的 environment运行一段时间后退出内存溢出docker stats看内存曲线加内存限制或优化代码间歇性退出网络超时未处理看日志里的异常堆栈加 try-catch 和重试特定操作后退出数据格式异常复现操作看输入数据加数据校验和容错无规律退出宿主机资源不足看系统日志扩容或限制并发我的经验是Agent 代码里一定要有全局异常捕获任何未处理的异常都要记录详细日志再退出而不是直接崩掉。日志里要包含时间戳、Agent 名称、当前处理的数据、异常堆栈这样排查起来才有线索。4.3 数据源限流与反爬应对数据源限流是采集 Agent 必须面对的问题。除了前面说的令牌桶限流还有几个技巧。一是错峰采集。不要所有标的都在同一秒去拉数据把请求分散到整个采集周期里。比如 60 秒采集一轮50 个标的那就每 1.2 秒拉一个而不是第 1 秒全部拉完。二是分级采集。核心标的用高频采集非核心标的用低频采集。比如你重点关注 10 个标的那就每分钟拉一次其他 40 个标的每 5 分钟拉一次。这样总请求量能降下来不少。三是缓存复用。同一份数据在多个 Agent 之间共享不要每个 Agent 都去拉一遍。采集 Agent 拉完数据后写入 Redis其他 Agent 从 Redis 读这样数据源那边只看到一份请求。注意不要试图绕过数据源的频率限制。一旦被识别为异常流量轻则临时封禁重则永久拉黑。合规使用 API 是长期稳定运行的前提。4.4 PWA 推送不生效的排查PWA 推送不生效通常卡在三个环节授权、订阅、发送。授权环节用户必须明确点击允许才能收到推送。如果用户点了拒绝或者浏览器设置里禁用了通知那推送就发不出去。前端要检测授权状态如果被拒绝要引导用户去浏览器设置里重新开启。订阅环节授权通过后前端要调用pushManager.subscribe()获取订阅对象并把这个对象发给后端保存。如果这一步失败通常是 VAPID 公钥格式不对或者 Service Worker 没注册成功。发送环节后端发送推送时要用 VAPID 私钥签名并且 payload 要加密。如果签名不对或者加密方式不匹配推送服务会拒绝。建议用成熟的库来处理签名和加密不要自己手写。还有一个容易忽略的点PWA 推送在 iOS 上的支持比较晚需要 iOS 16.4 以上而且用户必须先把 PWA 添加到主屏幕才能收到推送。Android 和桌面 Chrome 的支持则好很多。4.5 性能优化与资源控制PanWatch 跑起来之后资源占用是需要持续关注的。我实测下来四个 Agent 加两个数据库在 2 核 4G 的机器上跑得比较吃力建议至少 4 核 8G。优化的方向有几个。第一给每个容器设置资源限制避免某个 Agent 失控拖垮整机。在 compose 里加deploy.resources.limits限制 CPU 和内存上限。第二数据库加索引特别是时间戳字段和标的代码字段查询性能能提升一个数量级。第三Redis 设置过期策略缓存数据不要永久保存设个 TTL 自动清理。第四日志轮转Docker 默认的日志驱动会把所有日志存下来时间长了占满磁盘要配置max-size和max-file。# 资源限制和日志轮转配置 services: collector: deploy: resources: limits: cpus: 1.0 memory: 1G logging: driver: json-file options: max-size: 10m max-file: 35. 从 PanWatch 延伸出的 Agent 开发经验5.1 Agent 框架选型的几个判断维度做 PanWatch 的过程中我对比过几种 Agent 框架的选型思路。这里说的不是具体某个产品而是选型时应该看哪些维度。第一个维度是编排能力。你的 Agent 之间是简单的线性调用还是有分支、循环、并行如果只是线性调用那用最简单的方案就行如果有复杂编排就需要一个支持 DAG 或者状态机的框架。第二个维度是状态管理。Agent 执行过程中产生的中间状态存在哪里是内存、Redis 还是数据库状态管理做得好不好直接决定了系统能不能水平扩展、能不能断点续跑。第三个维度是可观测性。Agent 执行到哪一步了、耗时多少、有没有报错这些信息能不能方便地看到没有可观测性的 Agent 系统出了问题就是黑盒排查起来极其痛苦。第四个维度是生态和社区。遇到问题能不能找到答案有没有现成的工具链这些都会影响开发效率。我的建议是不要一上来就追求最复杂的框架。先用最简单的方案把核心流程跑通等遇到瓶颈了再考虑升级。PanWatch 一开始就是几个 Python 脚本加 Redis 队列后来才逐步演进成多 Agent 架构的。5.2 Agent 记忆机制的设计取舍Agent 记忆是让系统越用越聪明的关键。PanWatch 里的记忆分两层短期记忆和长期记忆。短期记忆存在 Redis 里保存最近几轮的分析结果和用户反馈用于上下文关联。比如技术分析 Agent 这次判断看空它会去查短期记忆里上一次的判断是什么如果连续三次都是看空那信号强度就升级。长期记忆存在 Postgres 里保存历史信号和实际走势的对应关系。每次预警触发后系统会记录当时的市场状态等过一段时间再回看这个预警准不准把结果写回长期记忆。这样积累下来就能统计出不同信号的历史准确率用于动态调整预警阈值。这里有个取舍记忆越多分析越准但查询越慢、存储成本越高。我的做法是给记忆设一个衰减因子时间越久的记忆权重越低超过一定时间的记忆直接归档不参与实时分析。这样既保留了历史经验又控制了实时查询的开销。5.3 Agent 安全与权限隔离Agent 系统跑起来之后安全是不能忽视的。PanWatch 里的安全设计主要有三点。第一最小权限原则。每个 Agent 只给它完成工作必需的权限。数据采集 Agent 只能读数据源不能写数据库分析 Agent 只能读数据库不能访问外部网络预警 Agent 只能发推送不能改数据。这样即使某个 Agent 被攻破影响范围也有限。第二输入校验。所有从外部进来的数据都要校验包括数据源返回的行情数据、用户提交的配置、推送服务的回调。校验内容包括格式、范围、类型任何不符合预期的输入都直接拒绝并记录。第三密钥管理。API key、数据库密码、VAPID 私钥这些敏感信息绝对不能硬编码在代码里也不能提交到代码仓库。用环境变量或者密钥管理服务来注入并且定期轮换。提示Docker 容器的隔离性不是绝对安全的。如果 Agent 要执行用户提交的代码或者访问不可信的数据源建议再加一层沙箱比如用 gVisor 或者 Firecracker 做更强的隔离。5.4 后续可扩展的方向PanWatch 目前实现的是基础的监控和预警后续还有不少可以扩展的方向。一是回测能力。把历史信号和实际走势做对比统计每个信号策略的胜率、盈亏比、最大回撤用数据来验证策略有效性。这个功能对量化交易特别有价值。二是多用户支持。目前是单用户设计如果要给多人用需要加用户体系、权限控制、数据隔离。每个用户有自己的关注列表和预警配置互不干扰。三是策略市场。让用户把自己写的分析策略分享出来其他人可以订阅使用。这需要一套策略的标准化接口和沙箱执行环境复杂度不低但想象空间很大。四是接入更多数据源。目前主要是行情数据后续可以接入财报数据、宏观经济数据、产业链数据让分析维度更丰富。这些扩展方向不是都要做而是根据实际需求选择性推进。我的原则是先把核心链路做稳定再考虑锦上添花的功能。一个稳定运行的基础系统比一个功能花哨但经常出问题的系统有价值得多。我在实际运维 PanWatch 的过程中最大的体会是监控系统本身也需要被监控。Agent 有没有在跑、数据有没有在更新、推送有没有发出去这些都要有独立的健康检查。我吃过一次亏采集 Agent 悄无声息地挂了三天我还以为市场没波动所以没预警结果错过了好几个信号。后来加了一个心跳检测每个 Agent 每分钟往 Redis 写一个时间戳另有一个 watchdog 进程检查这些时间戳超过两分钟没更新就告警。这个机制加上之后再也没出现过系统挂了但我不知道的情况。 基于TradingAgents与Docker的PWA行情监控系统实战
1. PanWatch 项目定位与核心思路拆解1.1 这个项目到底在解决什么问题PanWatch 这个名字拆开看Pan 指向的是全景、全局的视角Watch 则是持续盯盘、监控的意思。合在一起它要做的就是一个面向多市场、多资产的统一行情监控与智能分析面板。你可以把它理解成一个自建的个人行情驾驶舱——把股票、加密货币、外汇、大宗商品这些分散在不同平台的数据通过 TradingAgents 这类多智能体框架做聚合分析最后在一个 PWA 应用里统一呈现。为什么我要自己折腾这么一套东西市面上现成的行情软件其实不少但痛点也很明显第一数据源割裂看 A 股用一个软件看币圈用另一个看外汇再换一个来回切换极其消耗注意力第二大部分软件只给你原始数据不给分析结论K 线、成交量、MACD 摆在那里但现在该关注什么这件事得你自己判断第三定制化程度低你想加一个自己定义的指标或者预警逻辑基本没戏。PanWatch 的核心价值就在于把这三点一次性解决掉。它用 TradingAgents 的思路——也就是让多个各司其职的 Agent 分别负责数据采集、技术指标计算、情绪分析、风险预警——把看盘这件事从被动接收变成主动推送。你不需要一直盯着屏幕系统会在关键信号出现时通过 PWA 的推送能力通知你。适合谁来参考这个项目我认为有三类人一是有一点编程基础、想搭建自己监控体系的个人投资者二是对 Agent 框架和 Docker 部署感兴趣、想找一个完整落地案例来练手的开发者三是做量化或者金融数据相关工作的朋友想看看多智能体在行情分析场景下怎么编排。哪怕你只是想学 Docker 部署和 PWA 开发这个项目也是一个结构足够完整的实战样本。1.2 为什么选 TradingAgents 这套多智能体架构传统行情监控系统的做法是一个主程序 一堆定时任务所有逻辑耦合在一起加一个新指标就要改主流程维护起来很痛苦。PanWatch 选择 TradingAgents 这种多智能体架构本质上是把关注点分离这件事做到了极致。具体来说每个 Agent 只干一件事。数据采集 Agent 负责从各个数据源拉取原始行情它不关心这些数据后面怎么用技术分析 Agent 拿到数据后只负责计算指标、识别形态情绪分析 Agent 专门处理新闻、公告、社交媒体的文本输出情绪打分风险预警 Agent 则综合前面几个 Agent 的输出判断是否触发预警条件。这种设计的好处是任何一个环节出问题都不会拖垮整个系统而且你想替换某个数据源或者加一个新指标只需要动对应的那个 Agent其他部分完全不受影响。从工程角度看这种架构还有一个隐性优势它天然适合容器化部署。每个 Agent 可以独立打包成一个容器通过 Docker Compose 编排在一起彼此之间通过网络通信。这比把所有逻辑塞进一个进程要清晰得多也方便你按需扩容——比如行情高峰期给数据采集 Agent 多开几个实例。提示多智能体架构不是银弹。如果你的需求只是监控三五个标的、每天看一次那用不着上这么重的方案一个 Python 脚本加定时任务就够了。PanWatch 这套架构的价值在于多市场、多标的、高频次、要分析这四个条件同时成立的时候。1.3 技术选型背后的取舍逻辑PanWatch 的技术栈可以概括为Docker 做部署底座TradingAgents 做分析内核PWA 做前端呈现。这三者不是随便凑的每一个选择都有明确的理由。选 Docker 是因为行情监控系统对环境的依赖很重——Python 版本、各种金融数据库的客户端库、时区配置、定时任务调度这些东西在裸机上装一遍能踩一整天坑。Docker 把这些依赖全部封进镜像换一台机器只要docker compose up就能跑起来环境一致性有保障。而且 Docker 的网络隔离特性让你可以放心地把数据采集 Agent 暴露在公网侧分析 Agent 放在内网侧安全性更好控制。选 PWA 而不是原生 App是因为 PWA 的开发成本低、跨平台能力强而且它支持离线缓存和后台推送。对于行情监控这种平时不用、关键时刻要立刻看到的场景PWA 的推送能力刚好匹配。你不需要去应用商店上架一个链接发到手机上就能用更新也是即时的。TradingAgents 作为分析内核看中的是它的可扩展性。你可以用现成的 Agent 模板快速搭起来也可以自己写新的 Agent 接进去。它本质上是一个编排框架把谁在什么时候做什么这件事用代码描述清楚剩下的交给运行时去调度。2. 核心模块拆解与关键细节解析2.1 数据采集 Agent 的设计要点数据采集是整个系统的入口也是最容易出问题的地方。PanWatch 的数据采集 Agent 需要处理三类数据源交易所 API、公开数据接口、以及网页抓取。这三类的稳定性和频率限制完全不同必须区别对待。交易所 API 通常有严格的频率限制比如每分钟最多 1200 次请求。如果你有 50 个标的要监控每个标的要拉 K 线、盘口、成交明细很容易就超限。我的做法是在采集 Agent 里内置一个令牌桶限流器把请求速率控制在限制的 80% 左右留出余量。同时用 Redis 做一层缓存相同标的的相同周期数据在 5 秒内不重复请求。公开数据接口的稳定性差一些经常出现超时或者返回格式变化。针对这种情况采集 Agent 需要实现重试机制和降级策略。重试不是简单地重试三次就完事而是要用指数退避——第一次等 1 秒第二次等 2 秒第三次等 4 秒避免在对方服务已经过载的时候继续加压。降级策略则是当某个数据源连续失败超过阈值时自动切换到备用数据源同时发一条告警通知。网页抓取是最脆弱的一环因为页面结构随时可能变。我的经验是尽量不用网页抓取能用 API 就用 API。如果实在没有 API那就把抓取逻辑单独封装成一个 Agent并且加上结构校验——每次抓取后检查关键字段是否存在如果连续几次校验失败就自动停掉这个 Agent 并告警避免它一直返回脏数据污染下游分析。# 采集 Agent 的限流与重试核心逻辑示意 import time from functools import wraps def rate_limit(calls_per_minute1000): min_interval 60.0 / calls_per_minute last_called [0.0] def decorator(func): wraps(func) def wrapper(*args, **kwargs): elapsed time.time() - last_called[0] wait min_interval - elapsed if wait 0: time.sleep(wait) result func(*args, **kwargs) last_called[0] time.time() return result return wrapper return decorator def retry_with_backoff(max_retries3, base_delay1): def decorator(func): wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: if attempt max_retries - 1: raise time.sleep(base_delay * (2 ** attempt)) return wrapper return decorator2.2 技术分析 Agent 的指标计算与信号生成技术分析 Agent 拿到原始 K 线数据后要做的事情是计算指标并生成可读的信号。这里有个关键设计决策指标计算是放在 Agent 内部做还是单独抽一个计算服务我的选择是放在 Agent 内部但把计算逻辑写成纯函数方便测试和复用。为什么不做成独立服务因为指标计算是 CPU 密集型但数据量不大的操作单独拆一个服务反而增加了网络开销和部署复杂度。写成纯函数的好处是你可以用历史数据回测验证指标逻辑是否正确而不需要启动整个系统。PanWatch 里我实现了几个核心指标均线系统MA5/MA10/MA20/MA60、MACD、RSI、布林带、成交量异动检测。每个指标的计算都要注意数据对齐问题——不同周期的 K 线时间戳可能不一致必须先做时间对齐再计算。比如日线数据是每天 0 点小时线是整点你要算日线级别的 MACD 就必须先把小时线聚合上去。信号生成是技术分析 Agent 的输出环节。我的做法是定义一个信号优先级趋势信号均线金叉死叉优先级最高其次是超买超卖信号RSI 极值最后是形态信号头肩顶、双底等。当多个信号同时出现时按优先级排序输出避免信息过载。注意技术指标不是越多越好。我一开始加了十几个指标结果每天收到几十条信号根本看不过来。后来精简到五个核心指标信号数量降到每天三到五条反而更有参考价值。指标的价值在于少而准不在于多而全。2.3 情绪分析 Agent 的文本处理链路情绪分析 Agent 处理的是非结构化文本包括新闻标题、公司公告、社交媒体帖子。这条链路的难点在于文本来源杂、格式乱、噪音大而且金融领域的文本有大量专业术语和反讽表达通用情感分析模型经常判断错误。我的处理链路分四步清洗、分词、打分、聚合。清洗阶段去掉 HTML 标签、广告文本、重复内容分词阶段用金融领域词典做分词把利好利空涨停跌停这些词单独标记打分阶段用一个轻量级的分类模型给每段文本打 -1 到 1 的情绪分聚合阶段按时间窗口把多段文本的分数加权平均时间越近的权重越高。这里有个实操心得不要迷信大模型。我试过用大模型做情绪分析效果确实好但成本和延迟都太高不适合高频监控场景。后来换成一个微调过的小模型准确率只降了不到 5 个百分点但速度快了十倍成本几乎可以忽略。对于行情监控这种场景响应速度比绝对准确率更重要。2.4 风险预警 Agent 的触发逻辑风险预警 Agent 是整个系统的决策者它综合技术分析和情绪分析的输出判断是否触发预警。这里的核心设计是多条件与和多条件或的组合。举个例子一个强烈看空预警的触发条件是——技术面出现死叉条件 A且 RSI 高于 70条件 B且情绪分低于 -0.5条件 C。这三个条件必须同时满足才触发这叫多条件与。而一个关注级别的预警可能只需要条件 A 或条件 B 满足即可这叫多条件或。为什么要这样设计因为不同级别的预警对准确率的要求不同。高级别预警宁可漏报不可误报所以用与逻辑收紧条件低级别预警宁可误报不可漏报所以用或逻辑放宽条件。这样用户可以根据自己的风险偏好选择接收哪个级别的预警。预警触发后Agent 会生成一条结构化消息包含触发原因、相关标的、当前价格、建议关注点然后通过 PWA 的推送通道发给用户。消息格式要尽量简洁因为手机通知栏能显示的字数有限详细信息放在点开后的页面里。3. Docker 部署全流程与实操记录3.1 环境准备与 Docker 安装避坑PanWatch 的部署底座是 Docker所以第一步是把 Docker 环境搭好。这里我踩过的坑比较多逐个说。Windows 用户最容易遇到的问题是 Virtualization support not detected 和 Docker Desktop failed to start。这两个报错的根源是一样的BIOS 里的虚拟化支持没开。解决办法是重启进 BIOS找到 Intel VT-x 或者 AMD-V 选项设为 Enabled。注意有些主板把这个选项藏在 Advanced CPU Configuration 或者 Security 菜单下面不在显眼位置。开完之后还要确认 Windows 的 Hyper-V 和 WSL2 功能已经启用这两个是 Docker Desktop 在 Windows 上运行的前提。另一个高频报错是 failed to connect to the Docker API at npipe:////./pipe/dockerDesktopLinuxEngine。这个通常是 Docker Desktop 的后台服务没起来或者 WSL2 的集成没配好。我的排查顺序是先看 Docker Desktop 托盘图标是不是绿色的如果是黄色或者红色点开看具体报错然后检查 WSL2 是否正常在 PowerShell 里跑wsl --status最后确认 Docker Desktop 的设置里 Resources WSL Integration 已经勾选了你用的发行版。Linux 用户相对简单但也要注意权限问题。安装完 Docker 后默认只有 root 能操作普通用户要加进 docker 组sudo usermod -aG docker $USER然后重新登录生效。另外国内环境拉镜像可能慢建议配置镜像加速器在/etc/docker/daemon.json里加上 registry-mirrors 配置。Ubuntu 上安装 Docker 的完整命令如下# 卸载旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt-get update sudo apt-get install ca-certificates curl gnupg lsb-release # 添加官方 GPG 密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加仓库 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin # 验证 sudo docker run hello-world3.2 Docker Compose 编排文件详解PanWatch 的各个 Agent 通过 Docker Compose 编排在一起。下面是我实际使用的 compose 文件结构做了脱敏处理但保留了核心逻辑。version: 3.8 services: redis: image: redis:7-alpine container_name: panwatch-redis restart: unless-stopped ports: - 6379:6379 volumes: - redis-data:/data command: redis-server --appendonly yes networks: - panwatch-net postgres: image: postgres:15-alpine container_name: panwatch-db restart: unless-stopped environment: POSTGRES_USER: panwatch POSTGRES_PASSWORD: ${DB_PASSWORD} POSTGRES_DB: panwatch volumes: - pg-data:/var/lib/postgresql/data networks: - panwatch-net collector: build: ./agents/collector container_name: panwatch-collector restart: unless-stopped depends_on: - redis - postgres environment: REDIS_URL: redis://redis:6379 DB_URL: postgresql://panwatch:${DB_PASSWORD}postgres:5432/panwatch networks: - panwatch-net analyzer: build: ./agents/analyzer container_name: panwatch-analyzer restart: unless-stopped depends_on: - redis - postgres environment: REDIS_URL: redis://redis:6379 DB_URL: postgresql://panwatch:${DB_PASSWORD}postgres:5432/panwatch networks: - panwatch-net web: build: ./web container_name: panwatch-web restart: unless-stopped ports: - 8080:80 depends_on: - analyzer networks: - panwatch-net volumes: redis-data: pg-data: networks: panwatch-net: driver: bridge这个编排文件有几个设计要点值得说明。第一Redis 和 Postgres 都用了restart: unless-stopped保证容器异常退出后自动重启这是生产环境的基本要求。第二所有 Agent 都通过内部网络panwatch-net通信只有 web 服务暴露了 8080 端口给外部访问其他服务都不对外暴露安全性更好。第三数据库密码通过环境变量注入不写在文件里避免泄露。提示depends_on只保证启动顺序不保证服务就绪。也就是说 collector 容器启动了不代表 Redis 已经能接受连接。稳妥的做法是在 Agent 代码里实现连接重试或者在 compose 里加 healthcheck。3.3 数据持久化与备份策略行情数据是持续增长的如果不做清理和归档数据库很快就会撑爆。我的策略是分层存储最近 7 天的原始数据放在 Postgres 里方便快速查询7 天到 90 天的数据做降采样后归档90 天以上的数据只保留日线级别其他全部删除。降采样的逻辑是小时线数据按天聚合取开盘价、最高价、最低价、收盘价、成交量总和分钟线数据按小时聚合同样取 OHLCV。这样数据量能压缩到原来的十分之一左右但保留了主要信息。备份方面我用一个独立的定时任务容器每天凌晨把 Postgres 的数据 dump 出来压缩后存到本地磁盘同时保留最近 30 天的备份。备份文件命名带上日期方便回滚。恢复的时候直接用pg_restore导入即可。# 备份脚本核心逻辑 #!/bin/bash DATE$(date %Y%m%d) BACKUP_DIR/backups docker exec panwatch-db pg_dump -U panwatch panwatch | gzip ${BACKUP_DIR}/panwatch_${DATE}.sql.gz # 删除 30 天前的备份 find ${BACKUP_DIR} -name panwatch_*.sql.gz -mtime 30 -delete3.4 PWA 前端的部署与推送配置PWA 前端的部署相对简单用 Nginx 做静态文件服务即可。关键是要配置好 Service Worker 和 manifest.json这两个文件决定了 PWA 能不能被安装到桌面、能不能接收推送。Service Worker 的核心作用是缓存静态资源和拦截网络请求。我的策略是HTML 文件用 network-first保证每次都能拿到最新版本CSS、JS、图片用 cache-first减少加载时间API 请求不缓存直接走网络。这样既保证了更新及时又保证了加载速度。推送配置需要生成 VAPID 密钥对公钥放在前端私钥放在后端。用户第一次访问时会弹出通知授权请求同意后前端把订阅信息发给后端保存。后端在触发预警时用私钥签名后向推送服务发送消息推送服务再转发给用户的浏览器。// 前端注册 Service Worker 和推送订阅 if (serviceWorker in navigator PushManager in window) { const registration await navigator.serviceWorker.register(/sw.js); const subscription await registration.pushManager.subscribe({ userVisibleOnly: true, applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY) }); await fetch(/api/subscribe, { method: POST, body: JSON.stringify(subscription), headers: { Content-Type: application/json } }); }4. 常见问题排查与实战避坑指南4.1 Docker 网络不通的排查思路Docker 网络问题是部署阶段最高频的故障。表现通常是容器启动了但容器之间互相 ping 不通或者容器访问不了外网。排查要按层次来从下往上逐层确认。第一层确认容器是否在同一个网络里。用docker network inspect panwatch-net看有哪些容器接入了。如果某个容器不在列表里说明 compose 文件里没给它指定网络或者指定了不同的网络。第二层确认 DNS 解析是否正常。Docker 内置的 DNS 服务会把容器名解析成 IP如果解析失败说明容器名写错了或者网络配置有问题。可以在容器里跑nslookup redis测试。第三层确认防火墙规则。宿主机上的 iptables 或者 firewalld 可能会拦截 Docker 的流量。特别是 CentOS 系统默认的 firewalld 规则经常和 Docker 冲突。临时关闭防火墙测试一下如果通了就说明是防火墙问题需要加放行规则。第四层确认端口映射是否正确。容器内部端口和宿主机端口是两回事ports: 8080:80表示宿主机 8080 映射到容器 80。如果你在容器里服务监听的是 3000那映射就要写8080:3000写错了就访问不到。4.2 Agent 执行中断的常见原因Agent execution terminated due to error 这个报错在 Agent 开发中很常见但原因可能五花八门。我整理了一个排查表按出现频率排序。报错现象可能原因排查方法解决方案启动后立即退出环境变量缺失docker logs看报错补全 compose 里的 environment运行一段时间后退出内存溢出docker stats看内存曲线加内存限制或优化代码间歇性退出网络超时未处理看日志里的异常堆栈加 try-catch 和重试特定操作后退出数据格式异常复现操作看输入数据加数据校验和容错无规律退出宿主机资源不足看系统日志扩容或限制并发我的经验是Agent 代码里一定要有全局异常捕获任何未处理的异常都要记录详细日志再退出而不是直接崩掉。日志里要包含时间戳、Agent 名称、当前处理的数据、异常堆栈这样排查起来才有线索。4.3 数据源限流与反爬应对数据源限流是采集 Agent 必须面对的问题。除了前面说的令牌桶限流还有几个技巧。一是错峰采集。不要所有标的都在同一秒去拉数据把请求分散到整个采集周期里。比如 60 秒采集一轮50 个标的那就每 1.2 秒拉一个而不是第 1 秒全部拉完。二是分级采集。核心标的用高频采集非核心标的用低频采集。比如你重点关注 10 个标的那就每分钟拉一次其他 40 个标的每 5 分钟拉一次。这样总请求量能降下来不少。三是缓存复用。同一份数据在多个 Agent 之间共享不要每个 Agent 都去拉一遍。采集 Agent 拉完数据后写入 Redis其他 Agent 从 Redis 读这样数据源那边只看到一份请求。注意不要试图绕过数据源的频率限制。一旦被识别为异常流量轻则临时封禁重则永久拉黑。合规使用 API 是长期稳定运行的前提。4.4 PWA 推送不生效的排查PWA 推送不生效通常卡在三个环节授权、订阅、发送。授权环节用户必须明确点击允许才能收到推送。如果用户点了拒绝或者浏览器设置里禁用了通知那推送就发不出去。前端要检测授权状态如果被拒绝要引导用户去浏览器设置里重新开启。订阅环节授权通过后前端要调用pushManager.subscribe()获取订阅对象并把这个对象发给后端保存。如果这一步失败通常是 VAPID 公钥格式不对或者 Service Worker 没注册成功。发送环节后端发送推送时要用 VAPID 私钥签名并且 payload 要加密。如果签名不对或者加密方式不匹配推送服务会拒绝。建议用成熟的库来处理签名和加密不要自己手写。还有一个容易忽略的点PWA 推送在 iOS 上的支持比较晚需要 iOS 16.4 以上而且用户必须先把 PWA 添加到主屏幕才能收到推送。Android 和桌面 Chrome 的支持则好很多。4.5 性能优化与资源控制PanWatch 跑起来之后资源占用是需要持续关注的。我实测下来四个 Agent 加两个数据库在 2 核 4G 的机器上跑得比较吃力建议至少 4 核 8G。优化的方向有几个。第一给每个容器设置资源限制避免某个 Agent 失控拖垮整机。在 compose 里加deploy.resources.limits限制 CPU 和内存上限。第二数据库加索引特别是时间戳字段和标的代码字段查询性能能提升一个数量级。第三Redis 设置过期策略缓存数据不要永久保存设个 TTL 自动清理。第四日志轮转Docker 默认的日志驱动会把所有日志存下来时间长了占满磁盘要配置max-size和max-file。# 资源限制和日志轮转配置 services: collector: deploy: resources: limits: cpus: 1.0 memory: 1G logging: driver: json-file options: max-size: 10m max-file: 35. 从 PanWatch 延伸出的 Agent 开发经验5.1 Agent 框架选型的几个判断维度做 PanWatch 的过程中我对比过几种 Agent 框架的选型思路。这里说的不是具体某个产品而是选型时应该看哪些维度。第一个维度是编排能力。你的 Agent 之间是简单的线性调用还是有分支、循环、并行如果只是线性调用那用最简单的方案就行如果有复杂编排就需要一个支持 DAG 或者状态机的框架。第二个维度是状态管理。Agent 执行过程中产生的中间状态存在哪里是内存、Redis 还是数据库状态管理做得好不好直接决定了系统能不能水平扩展、能不能断点续跑。第三个维度是可观测性。Agent 执行到哪一步了、耗时多少、有没有报错这些信息能不能方便地看到没有可观测性的 Agent 系统出了问题就是黑盒排查起来极其痛苦。第四个维度是生态和社区。遇到问题能不能找到答案有没有现成的工具链这些都会影响开发效率。我的建议是不要一上来就追求最复杂的框架。先用最简单的方案把核心流程跑通等遇到瓶颈了再考虑升级。PanWatch 一开始就是几个 Python 脚本加 Redis 队列后来才逐步演进成多 Agent 架构的。5.2 Agent 记忆机制的设计取舍Agent 记忆是让系统越用越聪明的关键。PanWatch 里的记忆分两层短期记忆和长期记忆。短期记忆存在 Redis 里保存最近几轮的分析结果和用户反馈用于上下文关联。比如技术分析 Agent 这次判断看空它会去查短期记忆里上一次的判断是什么如果连续三次都是看空那信号强度就升级。长期记忆存在 Postgres 里保存历史信号和实际走势的对应关系。每次预警触发后系统会记录当时的市场状态等过一段时间再回看这个预警准不准把结果写回长期记忆。这样积累下来就能统计出不同信号的历史准确率用于动态调整预警阈值。这里有个取舍记忆越多分析越准但查询越慢、存储成本越高。我的做法是给记忆设一个衰减因子时间越久的记忆权重越低超过一定时间的记忆直接归档不参与实时分析。这样既保留了历史经验又控制了实时查询的开销。5.3 Agent 安全与权限隔离Agent 系统跑起来之后安全是不能忽视的。PanWatch 里的安全设计主要有三点。第一最小权限原则。每个 Agent 只给它完成工作必需的权限。数据采集 Agent 只能读数据源不能写数据库分析 Agent 只能读数据库不能访问外部网络预警 Agent 只能发推送不能改数据。这样即使某个 Agent 被攻破影响范围也有限。第二输入校验。所有从外部进来的数据都要校验包括数据源返回的行情数据、用户提交的配置、推送服务的回调。校验内容包括格式、范围、类型任何不符合预期的输入都直接拒绝并记录。第三密钥管理。API key、数据库密码、VAPID 私钥这些敏感信息绝对不能硬编码在代码里也不能提交到代码仓库。用环境变量或者密钥管理服务来注入并且定期轮换。提示Docker 容器的隔离性不是绝对安全的。如果 Agent 要执行用户提交的代码或者访问不可信的数据源建议再加一层沙箱比如用 gVisor 或者 Firecracker 做更强的隔离。5.4 后续可扩展的方向PanWatch 目前实现的是基础的监控和预警后续还有不少可以扩展的方向。一是回测能力。把历史信号和实际走势做对比统计每个信号策略的胜率、盈亏比、最大回撤用数据来验证策略有效性。这个功能对量化交易特别有价值。二是多用户支持。目前是单用户设计如果要给多人用需要加用户体系、权限控制、数据隔离。每个用户有自己的关注列表和预警配置互不干扰。三是策略市场。让用户把自己写的分析策略分享出来其他人可以订阅使用。这需要一套策略的标准化接口和沙箱执行环境复杂度不低但想象空间很大。四是接入更多数据源。目前主要是行情数据后续可以接入财报数据、宏观经济数据、产业链数据让分析维度更丰富。这些扩展方向不是都要做而是根据实际需求选择性推进。我的原则是先把核心链路做稳定再考虑锦上添花的功能。一个稳定运行的基础系统比一个功能花哨但经常出问题的系统有价值得多。我在实际运维 PanWatch 的过程中最大的体会是监控系统本身也需要被监控。Agent 有没有在跑、数据有没有在更新、推送有没有发出去这些都要有独立的健康检查。我吃过一次亏采集 Agent 悄无声息地挂了三天我还以为市场没波动所以没预警结果错过了好几个信号。后来加了一个心跳检测每个 Agent 每分钟往 Redis 写一个时间戳另有一个 watchdog 进程检查这些时间戳超过两分钟没更新就告警。这个机制加上之后再也没出现过系统挂了但我不知道的情况。