源码级核验：agent_catalog.py + requirements.txt + SECURITY.md

PanWatch 运行成本与运维：钱花在哪、数据放哪、风险落在谁身上

PanWatch 开源不等于零成本，自托管也不等于自动安全。本页分三块回答：月度账单由什么构成（以及项目内置的熔断机制）、数据与升级怎么管（备份对象是数据卷）、责任边界在哪（官方安全政策明确排除了哪些部分）。本站不给价格数字——价格以各厂商官网为准。

看成本三层结构看安全边界

成本三层：模型 + 服务器/存储 + 数据源与通知内置熔断：月度预算 10 美元 / 超预算拒绝执行备份对象：数据卷（不是容器）依据：agent_catalog.py + requirements.txt + SECURITY.md（固定 commit）

模型调用

服务器与存储

数据源与通知

预算与缓存控制

依据项目默认配置整理的运行成本构成示意图（不含任何报价数字，价格以各厂商官网为准）；非官方架构图。

Cost structure

PanWatch 月度成本由哪些部分构成？先分清哪一层最容易失控

PanWatch 的「开源免费」指的是代码。运行成本分三层，可控性差别很大——最贵也最难预估的是模型调用。

成本层	由什么决定	可控性	控制手段
模型调用	分析频率 × 标的数 × 单次用量 × 模型单价	最低：按量计费，且与你的使用习惯强相关	月度预算 + 超预算拒绝执行；结果缓存 12 小时；盘中只对有事件的情况分析；贵/便宜模型分档
服务器与存储	主机规格 + 常驻时长 + 数据保留量	高：可以选低配、可长期稳定	单容器部署；数据落本地卷；历史 K 线与日志按需清理
数据源与通知	是否使用付费源 / 是否使用收费渠道	高：默认走免 key 公开源即为 0	默认源全部免费；雪球 cookie、YFinance、Yahoo 默认关闭
人力与时间	首次配置、排错、升级频率	中：项目发布节奏较快	固定版本、备份数据卷、升级前读 Release Notes

为什么模型调用这一层最危险：服务器成本是固定的，而模型成本随「你加了多少只标的、把频率调成多密」线性增长。官方把深度分析的默认月度预算设成 10 美元并让超预算直接拒绝执行——也就是说最坏情况是「分析不跑了」，而不是「月底看到一张意外账单」。把这个机制保留着，比自己盯着用量更可靠。

Cost controls

PanWatch 项目内置的六个省钱机制（都是默认值，不是技巧）

下面这些不是「优化建议」，而是官方默认配置里已经写好的控制项；知道它们，就能预判账单形状。

机制	默认设置	省在哪	副作用
月度预算熔断	预算 10 美元，超预算 `reject`	账单有硬上限	超出后分析直接不执行，需要你手动提额
结果缓存	同标的 12 小时内复用	反复看同一只标的时几乎不花钱	12 小时内的结论可能是旧的，看时间戳确认
盘中只对有事件的情况分析	`event_only=True`	避开「每 5 分钟都叫模型」的烧钱模式	没达到阈值就没有输出
同标的抑制窗口	`throttle_minutes=30`	异动频繁时不会连续触发	30 分钟内的后续异动不重复分析
模型分档	`deep_model` / `quick_model`（默认留空）	把贵模型留给决策、便宜模型做采集	需要你自己按模型能力挑，配错会降低质量
不重试失败分析	`llm_max_retries=0`	失败不会反复烧钱	失败就是失败，要重跑需手动触发

如果你想要……	建议方向	要付出的代价
最低成本先跑起来	保持默认：只开收盘复盘 + 便宜模型 + 关掉深度分析	没有盘中提醒，也没有多 Agent 研究
日常盯盘够用	开盘中监测，阈值放宽，深度分析按需手动触发	盘中开销随标的数与波动率变化
愿意为研究质量付费	开深度分析、贵模型做决策、预算提到自己可接受的上限	月度账单上限随预算设定而上升
完全不想按量计费	本地 Ollama 跑模型	硬件与电费成本、推理速度与效果差异需要自己评估

本站不提供任何单价数字。模型价格、云主机价格与通知服务价格都会变，复制进来既容易过期也容易误导。要做预算，请用你自己的实际用量乘以各厂商官网的当前价格。

Data and backup

PanWatch 的数据在哪、备份什么、怎么升级回滚

自托管项目的运维动作集中在「数据卷」这一个对象上。先把这件事做对，后面都简单。

数据卷运维六步

确认数据落点：容器内 /app/data，由具名卷 panwatch_data 挂载；本地开发默认 ./data（可用 DATA_DIR 改）。

确认卷挂对了：docker inspect panwatch 看 Mounts；没挂上时容器重建会丢数据。

备份：备份数据卷（例如先停容器再打包卷目录），而不是备份容器本身；代码与数据分离意味着镜像可以随时重建。

升级前读 Release Notes：项目发布节奏较快（0.10.2 到 0.16.1 共 10 个版本），跨版本升级的注意事项以官方说明为准。

升级：本地构建路径用 git pull 加 docker compose up --build -d；直跑镜像则重新拉镜像并重建容器。

回滚：镜像回退到上一个 tag，再把备份的数据卷换回去；因此「备份 + 记录当前镜像 tag」是回滚的两个前提。

官方特别提醒过的一点：整个 data/ 目录不受版本管理，所以不要用「清理未跟踪文件」之类的方式做清理，数据会直接消失。另外 .env 里可能有模型 Key 与通知 Token，它同样不该进版本库——官方贡献指南也明确要求不要提交任何凭据。

Security boundary

PanWatch 的密钥、日志与公网暴露有哪些风险？自托管把责任交回给你

官方有一份安全政策文档，它最有价值的部分不是「报告漏洞的邮箱」，而是范围界定——划清了哪些问题由项目负责、哪些由你负责。

资产	在哪里	风险点	该怎么做
登录凭据	`AUTH_USERNAME`/`AUTH_PASSWORD` 或首次访问设置；会话用 JWT	弱口令 + 公网暴露 = 持仓与配置全暴露	用强口令；不要把 8000 端口直接暴露到公网
模型 API Key	设置 → AI 服务商（或 `.env` 里的 `AI_API_KEY`）	泄露后按量计费被他人消耗	不要提交进版本库；轮换时同步更新容器环境变量
通知 Token / Chat ID	通知渠道配置（如 `NOTIFY_TELEGRAM_BOT_TOKEN`）	泄露后可被用来向你的群发消息	与模型 Key 同等对待
数据源 cookie	数据源配置（如雪球资讯的 `cookies`）	等价于该账号的登录态	默认关闭是正确的默认；开启前确认风险
持仓与交易记录	数据卷内的数据库	是隐私数据，也是最有价值的攻击目标	备份加密保存；对外提供访问前先加认证层
日志	控制台与界面日志板	`DEBUG` 级别会记录调度心跳与采集过程，可能含 URL 与标识	对外分享日志前先脱敏；不要贴完整 `.env`

SECURITY.md（范围界定，原文摘要）范围包括 PanWatch 源码、官方容器镜像、默认配置和项目维护的工作流。
第三方 AI 服务、行情供应商、用户自行管理的反向代理或修改过的本地部署
可能不在直接修复范围内；但只要报告说明 PanWatch 如何导致或放大影响,
我们仍欢迎提交。

（报告方式：邮件私发，主题 [PanWatch Security]；目标 5 个工作日内确认；
 目前不提供漏洞赏金计划。）

三条最容易被忽略的自托管风险。① 端口暴露：服务默认监听 0.0.0.0:8000，仓库里没有附带反向代理与 HTTPS 配置，直接映射到公网等于把登录页交给全网。② 代理成了信任边界：官方明确把用户自建代理排除在修复范围外——如果你用 Nginx/Caddy 暴露服务，认证、证书与访问控制的责任全在你这边。③ 备份里就有密钥：数据卷与 .env 一起决定了「失窃后果」，两者都要按敏感数据处理。

一句话总结：自托管解决的是「数据不出你的机器」，不解决「你的机器是否安全」。

Ops checklist

日常运维要检查哪些项？每月花五分钟做一次

自托管项目的故障很少是突然发生的，多数是「小问题攒着」。下表是一份可以直接跟着做的日常检查表。

检查项	看什么	异常时怎么办
数据卷挂载	`docker inspect` 的 Mounts 与启动命令一致	不一致就立刻修正——这是丢数据的头号原因
磁盘占用	数据卷里数据库与日志的增长	清理旧日志；历史行情按需保留，不要无上限积累
数据源健康度	各源的成功率、p50 延迟与最近错误	成功率明显下降时换源或启用备源；先看是不是网络问题
通知渠道	各渠道是否仍为启用状态、能否收到测试消息	Token 失效与 Chat ID 变更都会静默失败，所以要定期测
模型用量与预算	本月花费与预算设置	接近上限时先确认分析频率是否过高，再决定是否提额
版本与备份	当前镜像 tag、备份时间	升级前先备份数据卷并记下旧 tag，否则无法回滚
暴露面	是否有公网入口、代理与证书是否有效	只需内网访问时就不要对公网开放；本地端口暴露是本项风险最高的一项

为什么把「暴露面」放在最后一行而不是开头一行：它平时不出问题，一旦出问题就是最严重的那类。如果你只是自己在家里的一台机器上跑、通过局域网访问，风险可控；一旦映射到公网，登录凭据、模型 Key、通知 Token 与持仓数据都在同一条链路上，此时前六项检查就不再能保护你了。

FAQ

PanWatch 成本与运维常见问题

答案基于固定 commit 的官方配置与文档；价格、主机规格与第三方服务条款请以各自官方信息为准。

相关页面：故障排查手册 · 部署与首次跑通

跑 PanWatch 一个月要花多少钱？

没有统一答案，因为它由三层构成：模型调用（按量，最容易变）、服务器与存储（固定）、数据源与通知（默认免费）。项目内置的控制项是：深度分析默认月度预算 10 美元、超预算拒绝执行、同标的结果缓存 12 小时、盘中只对有事件的情况分析、失败不重试。本站不复制任何单价，请按自己的用量与厂商官网价格估算。

开源免费，为什么还要花钱？

免费的只有代码（MIT）。Agent 与深度分析需要调用模型，模型按量计费；服务器与存储要你自己提供；若使用收费数据源或通知服务另有开销。想避免按量计费可以接本地 Ollama，但硬件与电费会成为另一种成本。

数据存在哪里？升级会不会丢？

数据在挂载卷里（容器内 /app/data，本地开发默认 ./data），代码与数据分离，容器重建不丢数据。但升级前仍应备份数据卷；并且不要用清理未跟踪文件的方式清理 data/——它不受版本管理。

怎么升级？能回滚吗？

本地构建路径：git pull 后 docker compose up --build -d；直跑镜像则重新拉镜像并重建容器。回滚需要两个前提：① 备份的数据卷；② 记住升级前的镜像 tag，以便回退到旧版本。项目发布较密集（0.10.2 到 0.16.1 共 10 个版本），升级前建议先读对应 Release Notes。

把服务放到公网上安全吗？

服务默认监听 0.0.0.0:8000，而仓库里没有附带反向代理与 HTTPS 配置。直接暴露到公网意味着登录页面对全网开放，一旦口令薄弱，持仓数据、模型 Key 与通知 Token 都在同一条链路上。官方安全政策明确把「用户自行管理的反向代理」排除在修复范围外，因此代理层加固是你的责任。

官方对安全问题是什么态度？

官方有一份安全政策：疑似漏洞要求邮件私发（主题带 [PanWatch Security]），不要开公开 issue；目标在 5 个工作日内确认；目前不提供漏洞赏金计划。范围包括源码、官方容器镜像、默认配置与项目维护的工作流；第三方 AI/行情供应商与用户自建代理不在直接修复范围内。

日志里会不会有敏感信息？

在 DEBUG 级别下会记录调度心跳、采集过程等底层信息，可能包含请求 URL 与标识。官方在贡献指南里也要求不要提交含隐私数据的日志。对外分享日志（比如贴到群里求助）前请先脱敏，尤其注意不要连 .env 一起贴出去。