企业官网建设流程全解析

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 的部署对机器有一定要求，不是随便一台旧笔记本就能跑得顺的。以下是我实测下来比较稳妥的配置：

操作系统方面，Linux 是首选，Ubuntu 22.04 或 Debian 12 都比较稳。如果你用 macOS，Docker 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: 30

• interval决定了数据粒度。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.5

• weight是权重，协调层汇总时用。如果你更信任技术面，可以把 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: 60

• max_concurrent_agents控制并发上限。设太高机器扛不住，设太低分析延迟大。4 核 8G 的机器建议设 3。
• cooldown_seconds是同一个 Agent 两次调用之间的最小间隔。这个参数很重要，能防止行情剧烈波动时 Agent 被反复唤醒导致资源耗尽。

3.3 启动流程与首次验证

配置写好后，启动流程大致是：

1. 拉取镜像：docker compose pull
2. 启动服务：docker compose up -d
3. 查看日志：docker compose logs -f panwatch
4. 验证数据流：确认行情数据正常写入数据库
5. 触发一次手动分析：看 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.7
• volume_anomaly：中性，置信度 0.5
• sentiment：看空，置信度 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 关于成本和维护的现实考量

自托管不是零成本。除了机器和电费，还有几块隐性成本：

• 时间成本：部署、调参、排错、升级，这些都要花时间。如果你完全不懂技术，学习曲线会比较陡。
• 模型调用成本：如果用云端 API，Agent 调用频繁的话费用不低。建议设置预算上限和告警。
• 维护成本：数据源接口可能会变，模型 API 可能会升级，这些都需要跟进。

我的建议是：先用最低配置跑起来，验证它对你是否真的有价值，再决定要不要加大投入。不要一上来就买高配机器、充大量 API 额度，万一用不惯就浪费了。

6.3 后续可以怎么扩展

PanWatch 的架构是开放的，后续可以往几个方向扩展：

• 接入更多数据源：除了行情数据，还可以接入链上数据、社交情绪数据等，让 Agent 的分析维度更丰富。
• 自定义 Agent：如果你有特定的分析逻辑，可以写自己的 Agent 插件，挂到调度层里。
• 回测框架：把历史信号和实际走势做对比，量化评估每个 Agent 的表现，据此动态调整权重。

我现在正在做的是第二项，写了一个基于特定形态识别的 Agent，还在调优阶段。等跑稳定了再单独写一篇分享。

最后分享一个小技巧：新 Agent 上线前，先让它"影子运行"一段时间。也就是让它正常分析、正常输出，但不接入最终信号，只记录它的判断。跑一两周后对比它的判断和实际走势，确认靠谱了再正式启用。这样能避免一个不成熟的 Agent 直接污染你的信号系统。