OKX交易机器人开发：REST与Websocket双轨协同实战

1. 为什么单靠REST API做交易机器人迟早会出问题

先把结论摆在前面：做交易机器人，REST API负责"做事"，Websocket负责"看路"，两者缺一不可。我见过太多人一开始图省事，只用REST轮询，结果要么被限频卡死，要么行情延迟到信号早就失效了才反应过来。这篇文章就把我实际搭建OKX交易机器人时，REST和Websocket双轨协同的完整思路、踩过的坑、以及能直接抄的代码结构讲清楚。

先说说这个机器人到底要干什么。简单讲，它需要同时完成两件事：一是实时感知市场——盘口价格、成交明细、K线更新、账户余额变动、订单状态变化；二是执行交易动作——下单、撤单、改单、查持仓、查历史成交。前者对时效性要求极高，后者对准确性和幂等性要求极高。这两类需求天然对应两种通信方式。

REST API的本质是"请求-响应"模型。你发一个HTTP请求，服务器回一个结果，然后连接就结束了。它适合做那些"我明确知道要做什么，现在就要结果"的操作。比如我要市价买入0.01个BTC，发个POST请求，拿到订单ID，完事。但如果你用它来轮询行情，比如每秒请求一次ticker接口，问题就来了：第一，OKX对REST有频率限制，不同接口的限频不一样，超了会被封IP一段时间；第二，轮询间隔内发生的价格变化你完全看不到，等下一轮请求回来，价格可能已经跑出去好几个点了；第三，每次请求都有网络往返延迟，几十毫秒到几百毫秒不等，高频场景下根本不够用。

Websocket则是"长连接+推送"模型。你连上OKX的Websocket服务器，订阅你关心的频道，之后服务器会主动把数据推给你，延迟通常在毫秒级。它适合做行情监控、订单状态跟踪、账户变动通知这类需要实时性的场景。但Websocket不适合做交易执行，因为它的请求-响应语义不如REST清晰，而且连接可能断，断了之后你发出去的下单指令到底有没有成功，很难确认。

所以双轨协同的核心逻辑就是：Websocket管"感知"，REST管"执行"，两者通过一个共享的状态层来协同。下面我按实际搭建顺序，把每个环节拆开讲。

1.1 先搞清楚OKX两类接口的能力边界

在动手之前，必须把OKX的接口能力摸清楚。我整理了一张对照表，这是整个架构设计的基础：

能力维度	REST API	Websocket
行情获取	支持，但需轮询，有延迟	支持，实时推送，延迟毫秒级
下单/撤单	支持，语义清晰，有明确返回	不推荐，确认机制弱
账户查询	支持，按需查询	支持，余额变动实时推送
订单状态	支持，需轮询	支持，状态变化实时推送
频率限制	严格，按接口限频	相对宽松，但订阅频道数有限
连接稳定性	每次请求独立，无状态	长连接，可能断线需重连
适用场景	交易执行、批量查询	实时监控、事件驱动

这张表的关键结论是：不要把Websocket当REST用，也不要把REST当Websocket用。我见过有人试图通过Websocket发送下单请求，技术上OKX的Websocket确实支持部分交易指令，但确认机制远不如REST可靠，一旦连接抖动，你根本不知道订单有没有成交。反过来，用REST轮询订单状态，在高频策略下会产生大量无效请求，既浪费配额又增加延迟。

1.2 双轨协同的架构长什么样

我最终采用的架构分三层：

第一层是数据接入层。Websocket客户端负责订阅以下频道：tickers（行情）、books5（五档盘口）、trades（成交明细）、orders（订单状态）、account（账户余额）。这些频道的数据通过一个消息队列（我用的是Python的asyncio.Queue）推给上层处理。

第二层是状态管理层。维护一份内存中的实时状态，包括最新价格、当前持仓、挂单列表、账户余额。Websocket推来的数据更新这份状态，REST查询的结果也用来校准这份状态。关键点是：所有交易决策都基于这份内存状态，而不是每次去请求REST。

第三层是交易执行层。当策略模块根据内存状态做出决策后，通过REST API发送下单/撤单请求。请求结果回来后，更新内存状态，同时等待Websocket推送的订单状态变化来做最终确认。

这个架构的核心优势是：决策基于实时状态，执行通过可靠通道，确认通过推送完成。三者形成闭环，既保证了时效性，又保证了可靠性。

2. Websocket连接OKX的实操细节与断线重连机制

Websocket这部分是整个机器人最容易出问题的地方。OKX的Websocket服务器有多个接入点，公共频道和私有频道分开，连接管理不当会导致数据丢失或频繁断线。我把自己踩过的坑和最终稳定的方案完整讲一遍。

2.1 公共频道与私有频道的连接差异

OKX的Websocket分两类：公共频道（行情、盘口、成交）不需要认证，直接连wss://ws.okx.com:8443/ws/v5/public即可；私有频道（订单、账户）需要登录认证，连wss://ws.okx.com:8443/ws/v5/private，连接后要发送登录请求，包含API Key、签名和时间戳。

登录请求的构造是第一个坑。OKX要求签名用HMAC-SHA256，签名内容是timestamp + 'GET' + '/users/self/verify'，然后Base64编码。时间戳必须是ISO格式的UTC时间，且与服务器时间偏差不能超过30秒。我第一次写的时候用了本地时间，结果一直登录失败，后来才发现服务器时间比本地快了十几秒。

import hmac import base64 import hashlib import time from datetime import datetime, timezone def get_login_params(api_key, secret_key, passphrase): timestamp = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' message = timestamp + 'GET' + '/users/self/verify' mac = hmac.new(secret_key.encode(), message.encode(), hashlib.sha256) sign = base64.b64encode(mac.digest()).decode() return { "op": "login", "args": [{ "apiKey": api_key, "passphrase": passphrase, "timestamp": timestamp, "sign": sign }] }

登录成功后，服务器会返回{"event": "login", "code": "0"}。如果code不是0，说明认证失败，常见原因就是时间戳偏差或签名错误。

2.2 订阅频道的选择与数据格式处理

订阅频道时，不要贪多。OKX对单个连接的订阅频道数有限制，而且订阅太多会导致消息处理不过来。我的经验是：行情类订阅tickers和books5就够了，成交明细trades按需订阅，订单和账户频道必须订阅。

订阅请求的格式是：

subscribe_msg = { "op": "subscribe", "args": [ {"channel": "tickers", "instId": "BTC-USDT"}, {"channel": "books5", "instId": "BTC-USDT"}, {"channel": "orders", "instId": "BTC-USDT"}, {"channel": "account"} ] }

数据推来的格式要注意：tickers频道推的是最新成交价、买一卖一价等；books5推的是五档盘口，包含价格和数量；orders推的是订单状态变化，包括live、partially_filled、filled、canceled等状态。关键点是：订单状态推送可能重复，也可能乱序，必须用订单ID和更新时间戳做去重和排序。

我遇到过一个坑：orders频道推送的订单状态有时候会先推filled再推live，如果直接按推送顺序处理，会把已成交的订单又当成挂单。解决办法是维护一个订单状态字典，每次收到推送时比较时间戳，只处理比当前状态更新的消息。

2.3 断线重连与心跳保活

Websocket连接不可能永远稳定。网络抖动、服务器维护、长时间无数据都可能导致断线。OKX的Websocket服务器会在30秒内没有收到任何消息时主动断开连接，所以必须定期发送心跳。

心跳的格式很简单：

ping_msg = {"op": "ping"}

建议每20秒发一次，留10秒余量。同时要监听pong响应，如果连续几次没收到pong，就主动重连。

重连逻辑是第二个大坑。很多人重连后只重新建立连接，忘了重新订阅频道和重新登录。正确的重连流程是：

1. 检测到连接断开（收到close事件或心跳超时）
2. 等待一个退避时间（第一次1秒，第二次2秒，第三次4秒，最多30秒）
3. 重新建立连接
4. 如果是私有频道，重新发送登录请求
5. 重新发送所有订阅请求
6. 重连成功后，通过REST API查询一次当前订单和账户状态，校准内存状态

第6步非常关键。因为断线期间可能有利率变化、订单成交、余额变动，这些推送你都丢了。重连后必须用REST做一次全量校准，否则内存状态就是错的。

async def reconnect_loop(ws_url, login_params, subscribe_args): backoff = 1 while True: try: async with websockets.connect(ws_url) as ws: if login_params: await ws.send(json.dumps(login_params)) resp = await ws.recv() if json.loads(resp).get("code") != "0": raise Exception("Login failed") await ws.send(json.dumps({"op": "subscribe", "args": subscribe_args})) backoff = 1 await handle_messages(ws) except Exception as e: print(f"Connection lost: {e}, reconnecting in {backoff}s") await asyncio.sleep(backoff) backoff = min(backoff * 2, 30) await calibrate_state_via_rest()

2.4 消息处理不要阻塞接收循环

这是很多人忽略的性能问题。Websocket的接收循环必须尽可能快地处理消息，如果你在接收循环里做耗时操作（比如发REST请求、写数据库），会导致消息堆积，最终被服务器断开。

我的做法是：接收循环只做一件事——把消息丢进asyncio.Queue，然后立刻继续接收。另起一个或多个消费者协程从队列里取消息，做解析、状态更新、策略计算。这样接收和处理解耦，接收循环永远不会被阻塞。

async def handle_messages(ws): while True: msg = await ws.recv() await message_queue.put(msg) async def process_messages(): while True: msg = await message_queue.get() data = json.loads(msg) if "data" in data: update_state(data) await strategy_engine.on_data(data)

队列要设一个上限，比如10000条，防止内存无限增长。如果队列满了，说明处理速度跟不上，需要考虑优化处理逻辑或减少订阅频道。

3. REST API在下单、撤单与账户查询中的正确用法

REST API这部分，核心不是"怎么发请求"，而是"怎么发得可靠"。交易指令发出去，必须确认结果；查询请求发出去，必须处理限频和错误。我把实际使用中的关键点拆开讲。

3.1 下单请求的构造与幂等性保证

OKX的下单接口是POST /api/v5/trade/order。请求体包含instId（交易对）、tdMode（交易模式，如cash、cross）、side（buy/sell）、ordType（market/limit）、sz（数量）、px（价格，市价单不需要）等字段。

构造请求时，签名是必须的。OKX的REST签名规则是：timestamp + method + requestPath + body，用HMAC-SHA256签名后Base64编码。时间戳同样是ISO格式UTC时间，偏差不能超过30秒。

def sign_request(api_key, secret_key, passphrase, method, path, body=""): timestamp = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%S.%f')[:-3] + 'Z' message = timestamp + method + path + body mac = hmac.new(secret_key.encode(), message.encode(), hashlib.sha256) sign = base64.b64encode(mac.digest()).decode() headers = { "OK-ACCESS-KEY": api_key, "OK-ACCESS-SIGN": sign, "OK-ACCESS-TIMESTAMP": timestamp, "OK-ACCESS-PASSPHRASE": passphrase, "Content-Type": "application/json" } return headers

幂等性是下单环节最容易被忽略的问题。假设你发了一个下单请求，但网络超时了，你不知道订单有没有成功。如果你直接重试，可能下两个单。OKX提供了clOrdId（客户端订单ID）字段，你可以自己生成一个唯一ID，同一个clOrdId重复下单，OKX会拒绝第二个请求。这是保证幂等性的关键。

我的做法是：每次下单前生成一个UUID作为clOrdId，如果请求超时，先用GET /api/v5/trade/order?clOrdId=xxx查询这个订单是否存在，存在就说明下单成功，不存在再重试。

3.2 撤单与改单的时机判断

撤单接口是POST /api/v5/trade/cancel-order，需要传instId和ordId（或clOrdId）。改单接口是POST /api/v5/trade/amend-order，可以改价格或数量。

撤单的时机很关键。我的策略是：当Websocket推送的盘口价格偏离挂单价格超过一定阈值时，触发撤单。比如我挂了一个买单在60000，当前卖一价已经跌到59500，说明市场在下跌，我的买单可能很快成交，但成交价不是最优的。这时候应该撤单，重新挂一个更低的价格。

但撤单不是越快越好。OKX的撤单请求也有延迟，如果市场变化太快，你撤单请求发出去的时候订单已经成交了，撤单会失败。所以撤单逻辑要能处理"撤单失败因为已成交"的情况，这时候应该把订单状态更新为已成交，而不是继续重试撤单。

改单比撤单+重新下单更高效，因为改单不丢失排队优先级。但OKX的改单接口有限制：只能改价格和数量，不能改交易对和方向。而且改单请求也可能失败，失败原因可能是订单已成交或已撤销。

3.3 账户查询与限频处理

账户查询接口是GET /api/v5/account/balance，返回各币种的余额、可用余额、冻结余额等。这个接口的限频是每2秒最多10次，超过会被限流。

限频处理的核心不是"不要超"，而是"超了怎么办"。OKX返回限流错误时，HTTP状态码是429，响应体里有code和msg。我的做法是：捕获429错误，等待一个退避时间（比如1秒），然后重试。同时维护一个请求计数器，如果短时间内频繁触发429，说明请求频率确实太高，需要降低查询频率。

更好的做法是：能用Websocket推送的数据，就不要用REST查询。账户余额变动有account频道推送，订单状态变化有orders频道推送。REST查询只用在两个场景：一是初始化时做一次全量查询，二是Websocket重连后做一次校准。这样REST请求量可以降到最低，基本不会触发限频。

3.4 错误处理与重试策略

REST请求可能遇到各种错误：网络超时、DNS解析失败、HTTP 5xx服务器错误、业务错误码等。不同错误要用不同策略：

错误类型	表现	处理策略
网络超时	请求无响应	先查询确认状态，再决定是否重试
HTTP 429	限频	退避后重试，降低频率
HTTP 5xx	服务器错误	退避后重试，最多3次
业务错误码	如余额不足、价格偏离	不重试，记录日志，通知策略层
签名错误	时间戳偏差或密钥错误	不重试，检查配置

关键原则：交易类请求（下单、撤单）重试前必须先查询确认，查询类请求可以直接重试。因为交易类请求重试可能导致重复操作，查询类请求重试没有副作用。

4. 双轨协同的核心：状态同步与事件驱动策略

前面讲了Websocket怎么连、REST怎么用，现在讲最关键的部分：两者怎么协同。这是整个机器人的大脑，也是区分"能跑"和"跑得好"的分水岭。

4.1 内存状态的设计与更新规则

内存状态是整个机器人的单一数据源。我设计的状态结构包括：

class BotState: def __init__(self): self.tickers = {} # instId -> {bid, ask, last, ts} self.books = {} # instId -> {bids: [], asks: [], ts} self.orders = {} # ordId -> {status, px, sz, filled, ts} self.balance = {} # ccy -> {avail, frozen, total} self.positions = {} # instId -> {pos, avgPx, upl} self.last_update = {} # channel -> timestamp

更新规则有三条：

第一条：Websocket推送优先。任何来自Websocket的数据，只要时间戳比当前状态新，就更新状态。如果时间戳旧，丢弃。

第二条：REST查询用于校准。初始化时和重连后，用REST查询全量状态，覆盖内存状态。但要注意：REST查询返回的数据可能比Websocket推送的旧，所以校准时要比较时间戳，不能无脑覆盖。

第三条：交易请求的结果也更新状态。下单成功后，把新订单加入orders字典，状态设为live。撤单成功后，把订单状态改为canceled。但最终确认还是要等Websocket推送。

这三条规则的核心是：时间戳是唯一的裁判。不管数据来自哪个通道，新的覆盖旧的，旧的丢弃。

4.2 事件驱动策略引擎的设计

策略引擎不主动轮询，而是被动响应事件。事件来源有三个：Websocket推送、REST请求结果、定时器。

class StrategyEngine: async def on_ticker(self, instId, ticker): # 行情更新事件 if self.should_buy(instId, ticker): await self.execute_buy(instId, ticker) async def on_order_update(self, order): # 订单状态变化事件 if order.status == "filled": await self.on_order_filled(order) elif order.status == "canceled": await self.on_order_canceled(order) async def on_timer(self): # 定时事件，用于定期检查 await self.check_risk()

事件驱动的好处是：策略逻辑只在需要的时候执行，不浪费CPU。而且事件之间的因果关系清晰，便于调试。

但事件驱动也有坑：事件可能乱序到达。比如你先收到订单成交推送，再收到下单成功的REST响应。如果策略引擎按到达顺序处理，可能会把已成交的订单又当成新订单。解决办法是：每个事件带上时间戳，策略引擎内部维护一个事件队列，按时间戳排序后再处理。

4.3 订单生命周期管理

一个订单从创建到终结，经历多个状态：live（挂单中）、partially_filled（部分成交）、filled（完全成交）、canceled（已撤销）。每个状态变化都可能触发策略动作。

我的订单生命周期管理逻辑是：

1. 创建订单：通过REST下单，拿到ordId，在内存中创建订单记录，状态设为live。
2. 等待确认：监听Websocket的orders频道，收到该ordId的状态推送后，更新订单状态。
3. 部分成交：如果状态变为partially_filled，记录已成交数量，根据策略决定是否继续等待或撤单。
4. 完全成交：状态变为filled，更新持仓和余额，触发后续策略（如止盈止损）。
5. 撤销：如果主动撤单或策略触发撤单，状态变为canceled，从挂单列表中移除。

关键点：订单状态的最终确认必须以Websocket推送为准。REST下单返回的只是"请求已接受"，不代表订单已生效。我遇到过REST返回成功但订单实际被拒绝的情况，原因是价格偏离太大。所以下单后必须等Websocket推送确认。

4.4 数据一致性校验与异常恢复

双轨协同最大的风险是数据不一致：Websocket推送的状态和REST查询的状态对不上。这种情况通常发生在断线重连、网络抖动、或者OKX服务器内部状态同步延迟时。

我的校验策略是：每隔一段时间（比如5分钟），用REST查询一次订单列表和账户余额，与内存状态对比。如果发现不一致，以REST为准，修正内存状态，并记录日志。

async def consistency_check(): while True: await asyncio.sleep(300) rest_orders = await query_open_orders() memory_orders = {oid: o for oid, o in state.orders.items() if o.status == "live"} # 检查REST有但内存没有的订单 for o in rest_orders: if o.ordId not in memory_orders: state.orders[o.ordId] = o log.warning(f"Order {o.ordId} missing in memory, added from REST") # 检查内存有但REST没有的订单 for oid in memory_orders: if oid not in [o.ordId for o in rest_orders]: state.orders[oid].status = "unknown" log.warning(f"Order {oid} missing in REST, marked unknown")

异常恢复的关键是：不要假设内存状态永远正确。任何异常情况（断线、超时、错误码）发生后，都要用REST做一次校准。校准的频率可以根据策略的敏感度调整，高频策略可以更频繁，低频策略可以稀疏一些。

5. 实战中踩过的坑与性能优化经验

这部分讲一些文档里不会写、但实际跑起来一定会遇到的问题。每个都是我真金白银试出来的。

5.1 时间戳偏差导致的签名失败

这个问题我遇到不下五次。OKX要求请求时间戳与服务器时间偏差不超过30秒，但很多人的服务器时间没有同步，跑几天就偏了几十秒。表现是：所有REST请求返回50102错误码，提示时间戳无效。

解决办法很简单：服务器上配置NTP时间同步。Linux系统用timedatectl或ntpdate，Windows系统在设置里开启自动同步。如果没法改服务器时间，可以在每次请求前先调一次OKX的GET /api/v5/public/time接口，拿到服务器时间，计算本地时间与服务器时间的偏差，然后在签名时用服务器时间。

async def get_server_time_offset(): resp = await http_get("/api/v5/public/time") server_ts = int(resp["data"][0]["ts"]) / 1000 local_ts = time.time() return server_ts - local_ts

这个偏差值缓存起来，每次签名时用local_ts + offset作为时间戳。偏差值每隔一段时间刷新一次。

5.2 Websocket消息积压导致断线

前面提到过，接收循环不能阻塞。但即使不阻塞，如果消息量太大，队列还是会积压。我遇到过一种情况：订阅了太多交易对的trades频道，每秒推送几千条消息，处理不过来，队列爆满，最终被服务器断开。

解决办法有两个：一是减少订阅频道，只订阅策略真正需要的交易对；二是优化消息处理逻辑，把不必要的字段解析去掉。比如trades频道推送的每条消息包含价格、数量、方向、时间戳等，如果策略只用价格，就只解析价格字段，其他字段跳过。

另外，可以用多个消费者协程并行处理队列消息。但要注意：并行处理可能导致状态更新乱序。如果多个协程同时更新同一个订单状态，可能后处理的旧消息覆盖了新消息。解决办法是：按instId或ordId做哈希，同一个订单的消息总是由同一个协程处理。

5.3 REST请求超时与重试的陷阱

REST请求超时后重试，最大的陷阱是重复下单。我一开始没做幂等性，超时后直接重试，结果下了两个单，一个成交一个挂着，最后手动撤单才解决。

后来我加了clOrdId幂等性，但还有另一个问题：重试时用的参数可能已经过期。比如第一次下单时价格是60000，超时后重试，价格已经变成60500，如果还用60000下单，可能直接成交在60500（市价单）或者挂单失败（限价单价格偏离太大）。

解决办法是：重试前重新获取最新价格，重新计算下单参数。同时，重试次数不要太多，最多3次，超过就放弃并通知策略层。

5.4 内存状态与交易所状态不一致的排查方法

数据不一致是最难排查的问题，因为你不确定是Websocket丢了消息，还是REST查询有延迟，还是自己的状态更新逻辑有bug。

我的排查方法是：记录所有状态变更的日志，包括变更来源、变更前后的值、时间戳。当发现不一致时，回溯日志，找到第一个不一致的时间点，然后看那个时间点附近发生了什么事件（断线、重连、错误码等）。

def update_state(key, new_value, source): old_value = state.get(key) if old_value != new_value: log.info(f"State change: {key} from {old_value} to {new_value}, source={source}, ts={time.time()}") state[key] = new_value

日志要结构化，方便用工具分析。我用的是JSON格式日志，每条日志一行，包含timestamp、level、event、key、old_value、new_value、source等字段。出问题时用grep或jq过滤，很快就能定位。

5.5 性能优化的几个实用技巧

最后分享几个性能优化技巧，都是实测有效的：

第一，用orjson替代标准库的json。orjson的解析速度快3-5倍，对于高频消息处理场景，提升很明显。

第二，Websocket消息批量处理。如果队列里积压了多条消息，不要一条一条处理，批量取出（比如一次取100条），批量解析，批量更新状态。这样可以减少函数调用开销和锁竞争。

第三，REST连接复用。用aiohttp的ClientSession，保持长连接，避免每次请求都重新建立TCP连接。ClientSession要设置合理的连接池大小，太小会导致请求排队，太大浪费资源。

第四，状态更新用不可变数据结构。每次更新状态时，创建一个新的状态对象，而不是修改原对象。这样可以避免并发读写问题，也方便回滚和调试。Python里可以用dataclasses的replace方法。

第五，关键路径避免日志IO。日志写入是磁盘IO，很慢。在消息处理的关键路径上，不要直接写日志文件，而是把日志丢进一个队列，由单独的协程异步写入。这样不会阻塞消息处理。

6. 从能跑到跑得稳：监控、告警与日常维护

机器人跑起来只是第一步，跑得稳才是目标。这部分讲监控和告警的设计，以及日常维护中要注意的事项。

6.1 必须监控的核心指标

我监控的指标分四类：

连接类指标：Websocket连接状态（连接/断开）、重连次数、最后一次收到消息的时间。如果超过30秒没收到任何消息，说明连接可能有问题，触发告警。

请求类指标：REST请求成功率、平均延迟、429错误次数、超时次数。成功率低于95%或429错误频繁出现，说明需要优化请求频率或检查网络。

状态类指标：内存中的挂单数量、持仓数量、账户余额。如果挂单数量异常增多（比如超过策略设定的上限），说明撤单逻辑可能有问题。

策略类指标：信号触发次数、下单次数、成交次数、盈亏。这些指标用于评估策略效果，也用于发现异常（比如下单次数突然暴增，可能是策略逻辑有bug）。

监控数据我用的是Prometheus + Grafana，机器人暴露一个/metrics接口，Prometheus定期抓取，Grafana做可视化。告警用Alertmanager，配置规则比如"Websocket断开超过1分钟"、"REST成功率低于90%"、"5分钟内下单次数超过100"等。

6.2 告警渠道与告警分级

告警不能一股脑全发，要分级：

级别	触发条件	通知方式	响应要求
P0	机器人进程崩溃、无法连接交易所	电话+短信	立即处理
P1	Websocket断开超过5分钟、REST持续失败	短信+即时消息	15分钟内处理
P2	单次请求失败、重连成功	即时消息	当天处理
P3	状态不一致、指标异常	邮件	次日处理

P0和P1必须能叫醒人，P2和P3可以攒着一起看。告警消息要包含足够的信息：什么指标、当前值、阈值、可能的原因、建议的处理动作。

6.3 日常维护清单

机器人上线后，每天要做的事：

• 检查告警记录，看有没有P1以上的告警
• 检查日志，看有没有异常错误码
• 检查账户余额和持仓，与预期是否一致
• 检查策略盈亏，评估策略是否还有效

每周要做的事：

• 回顾限频错误，看是否需要调整请求频率
• 检查Websocket重连次数，如果频繁重连，排查网络问题
• 更新依赖库，修复已知bug
• 备份配置和状态数据

每月要做的事：

• 全面回测策略，看是否需要调整参数
• 检查API Key权限，撤销不必要的权限
• 审查代码，清理无用逻辑
• 更新文档，记录本月遇到的问题和解决方案

6.4 策略失效的早期信号

最后讲一个容易被忽略的点：策略失效的早期信号。机器人跑得好好的，突然开始亏钱，往往不是代码问题，而是市场环境变了。早期信号包括：

• 胜率下降：原来70%的胜率降到50%
• 盈亏比恶化：原来赚3亏1，变成赚1亏3
• 信号频率异常：原来每天10个信号，变成每天100个或0个
• 滑点增大：成交价与预期价格偏差变大

发现这些信号后，不要急着改代码，先暂停策略，分析市场数据，确认是策略问题还是市场问题。如果是市场问题，可能需要调整策略参数或换策略；如果是代码问题，再排查bug。

我个人在实际操作中的体会是：交易机器人最难的不是写代码，而是管理预期和风险。代码可以调试，市场不会等你。任何时候都要有止损和熔断机制，亏到一定程度自动停止，保护本金。这是比任何技术细节都重要的原则。