Solución de generación de humo manual de operaciones simuladas en vivo (live_grid_multi)

Estimado usuario, este capítulo es una lista de verificación manual: en un día de negociación real (o en un momento conveniente para usted), ejecute una sesión de negociación en vivo simulada usando el ejemplo del repositorio ``examples/live_grid_multi.py`, marque cada elemento y confirme que el comportamiento de qteasy es consistente con la documentación.

¿Qué es la prueba de humo? Al igual que las pruebas en el mar antes del lanzamiento de un nuevo barco, no es necesario cubrir todas las estrategias, sino que utiliza ejemplos fijos + comprobaciones fijas para determinar rápidamente «si funciona y si los registros son legibles». Este manual se centra en real `qt.run` + verificación humana; Durante las horas no comerciales, los scripts sin cabeza en el repositorio también se pueden usar para la regresión de la arquitectura (ver más abajo).

Línea base de la estrategia: examples/live_grid_multi.py (5-minute VS + multi-mark grid). Maintainers who need to refer to the internal roadmap can refer to the repository .cursor/plans/trader architecture upgrade roadmap_0650f0d5.plan.md (opcional, no es necesario leerlo).

Relación con los guiones sin cabeza

  • tests/notebook_trader_headless_script.py proporciona humo sin cabeza en fases (incluido 5-A/5-B, 5-C, etc.), que se puede llamar en celdas de Notebook.

  • Este manual se centra en: usted personalmente iniciando en vivo, viendo la CLI/registros y marcando las casillas.

  • Horario recomendado: En días hábiles seguir este manual; Durante los cierres de mercado utilice un script sin cabeza para realizar análisis de regresión.

I. Entorno y requisitos previos

  1. Python: se recomienda /opt/anaconda3/envs/py39/bin/python. Si instaló qteasy mediante pip, el directorio de trabajo puede ser cualquier ruta que contenga examples/live_grid_multi.py (no necesita clonar todo el repositorio, pero debe poder acceder al script de ejemplo).

  2. Cuenta nueva, sin posiciones abiertas (para evitar interferencias de órdenes antiguas):

    • -n/–new_account <username> crea una nueva cuenta; o

    • Si ya existe un account_id y –restart borra el registro, reinicie solo después de confirmar que no hay posiciones abiertas.

  3. Datos: Las estrategias basadas en minutos requieren tablas locales como stock_1min; la recarga inicial puede tardar más, lo cual es normal.

  4. **Los registros: sys_log_file_path y trade_log_file_path se pueden escribir (verifique con artifacts).

II. Plantilla de comando de inicio

Ejecute en el directorio que contiene el ejemplo (ajuste según su cuenta):

/opt/anaconda3/envs/py39/bin/python examples/live_grid_multi.py \\
    -a <ACCOUNT_ID> -n <NEW_USER_NAME_OR_OMIT> \\
    --ui cli \\
    [--debug] [--restart]

Nota:

  • Arranque en frío: cree un nuevo -n o –restart y confirme que la posición esté vacía.

  • No amplíe trade_batch en un entorno desconocido para evitar presiones financieras.

  • CLI relacionada con 5-C Se recomienda agregar –debug para que se pueda ejecutar run –task diagnose_pending_orders.

III. Aceptación por fases (marque cada elemento)

Las siguientes etapas corresponden a las hojas de ruta internas 0-5-C / Etapa 11; cada ítem incluye lo que se verifica en esta etapa, operación y aceptación.

Fase 0: línea de base, máquina de estados y observabilidad

Qué verificar: Trader puede iniciarse normalmente, las transiciones de estado son razonables y los registros pueden restaurar el orden de «Inicio → Programación → Tareas críticas».

  • Operación: Observe el estado (detenido → inactivo/en ejecución, etc.) en CLI/registro y la tarea en cola.

  • Prueba de Aceptación: No hay puntos muertos inexplicables; capaz de reconstruir una línea de tiempo de inicio completa.

Fase 1: Salida estandarizada

Qué verificar: Los recursos se liberan después de una parada/salida normal y no hay truncamientos anormales en los puntos de interrupción y los registros.

  • Operación: Salga normalmente usando Shell; No mate por la fuerza el proceso.

  • Prueba de aceptación: No hay hilos de zombies; registros completos.

Fase 2: programación y omisión de tareas

Qué verificar: Los aumentos de precios asincrónicos y las tareas estratégicas tienen límites claros; cuando se omite una tarea, el registro contiene skip_reason legible.

  • Operación: Observe los horarios como acquire_live_price y run_strategy.

  • Aceptación: Las anomalías/saltos son explicables y estadísticamente significativos.

Fase 3: programación y puesta al día

Qué verificar: El horario se puede reproducir bajo la misma configuración; el comportamiento de «volver a ejecutar» cuando se inicia desde el disco es coherente con la documentación.

  • Operación: Compare los dos momentos clave del mismo día o inicie uno durante la negociación.

  • Aceptación: La salida del cronograma es reproducible.

Fase 3.5: Coherencia entre el registro de transacciones y el pago

Qué se está verificando: El efectivo/posición/orden debe coincidir después de la transacción, sin deducciones duplicadas.

  • Operación: Verifique el libro mayor después de al menos una transacción simulada.

  • Aceptación: No hay contradicción con la «presentación parcial».

Fase 4-A: Ruta de devolución de la transacción

Lo que se está verificando: Las transacciones se consumen a través de rutas públicas como poll_fills y la SIM puede funcionar de manera estable todo el día.

  • Operación: Funciona durante medio día de negociación o un día completo.

  • Prueba de aceptación: No se encontró ninguna pila de errores de clase de cola interna.

Fase 4-B: omitir la agrupación basada en causas

Qué verificar: El skip_reason= en los registros se puede categorizar manualmente (por ejemplo, gate_failed, snapshot_stale).

  • Operación: Recuperar skip_reason=.

  • Aceptación: Todos los campos están completos y sus significados son comprensibles.

Fase 5-A: Panorama de la estrategia

Qué verificar: Cuando la división está habilitada, prepárese antes de ejecutar; omita instantáneas que caduquen y tengan registros.

  • Operación: Primero, configure live_trade_split_strategy_prepare=False para establecer una línea de base; luego establezca True y configure live_trade_prepare_lead_seconds y live_trade_strategy_snapshot_max_age_seconds (debe configurarse antes de qt.run).

  • Aceptación: consulte prepararse para el cronograma/registro; snapshot_stale es explicativo.

Fase 5-B: Activar control de acceso

Qué verificar: warn solo emite una advertencia; block impide que la política se ponga en cola en caso de una falla grave.

  • Operaciones: Pruebe warn / block en diferentes niveles; Shell ejecuta gate.

  • Prueba de aceptación: block no debe bloquear por error transacciones en días comerciales normales (primero use warn para pruebas en escala de grises).

Fase 11/5-C: Mapeo, Rotación, Diagnóstico, Conciliación

Qué se está verificando: Cancelación de cuentas de corretaje, rotación de registros de riesgos, diagnóstico de órdenes en tránsito y conciliación de cierre JSON.

  1. Mapeo de pedidos: los pedidos exitosos tienen broker_order_id; los contrarechazos tienen rejected y el corredor está vacío; los rechazos de control de riesgos no tienen nuevas líneas de pedido, pero risk_log tiene ``.<RISK REJECTED> ``

  2. Productos y rotación — artifacts writable with four keys; rotatelogs --days 30 cleans up expired *.risk.log.

  3. Diagnóstico de Órdenes Pendientes — DEBUG: run --task diagnose_pending_orders, todos los campos están completos.

  4. post_close — reconcile JSON que contiene is_ok, failures, etc.

IV. Información complementaria relacionada con live_grid_multi

  • Objetivo múltiple VS + multi_pars: los parámetros de la cuadrícula para cada objetivo se inicializan razonablemente el primer día.

  • Frecuencia de recarga subdiaria: Para los días con humo, la tabla de recarga se puede reducir solo al conjunto más pequeño, como stock_1min.

  • Aceptación: El comportamiento el primer día sin posiciones abiertas fue consistente con la lógica del ejemplo; no hubo errores de precios de NaN.

5. Cuaderno que emite humo sin cabezal (opcional)

Durante el cierre del mercado, las funciones stage* en tests/notebook_trader_headless_script.py se pueden llamar dentro del Notebook; consulte los comentarios del guión para obtener más detalles. Esto se puede utilizar junto con el modo en vivo manual.

VI. Hoja de resumen del trabajo diario

Cuando finalice la prueba de humo manual, puede marcar rápidamente «Qué paso de la prueba de hoy se completó» usando la siguiente tabla. Cada fila corresponde al número de etapa en la Parte 3 anterior; Se debe completar un resumen de sus acciones como realmente se realizaron, y los criterios de verificación provienen de las especificaciones de aceptación para esa etapa. Esta tabla cubre la hoja de ruta 0 a 5-C/etapa 11, excluyendo la integración de Broker/QMT (ver Capa de adaptación e integración de corretaje).

Significados de las columnas: Etapa es el número de la hoja de ruta; Usted registra un resumen de sus acciones; Criterios de marca de verificación es el requisito mínimo para pasar esta etapa.

Cómo utilizar: Después de completar una determinada etapa durante el proceso de humo, escriba una oración en la columna «Resumen de acción» (por ejemplo, «Puerta pasada en modo de advertencia»). Si se logra el objetivo, marque la casilla en su mente o en la copia; si no se logra el objetivo, regístrelo en la columna «Conclusión» de la Plantilla de registro §7.

escenario

Resumen de acción

Criterios de marca de verificación

0

Ver estado/registros

El enlace de arranque se puede restaurar.

1

Salida estandarizada

Liberación normal de recursos.

2～4-B

Programar y omitir

skip_reason, ¿entiendes?

5-A/B

Instantáneas y control de acceso

obsoleto/puerta es interpretable

11/5-C

Mapeo/Rotación/Diagnóstico/Reconciliación

Consulte las cuatro secciones anteriores.

VII. Plantilla de registro (recomendado)

Después de cada señal de humo, registre: número de versión, configuración principal live_trade_*, resultado gate, muestreo de pedido rechazado, resumen reconcile y conclusión (aprobada/pendiente/bloqueada). Esto es para comparar el siguiente día de negociación.

Documentos relacionados