Saltar a contenido

Arquitectura multi-agent para trading

Patrón 4-agent consolidado de OpenClaw y otras implementaciones: separar responsabilidades entre Data, Strategy, Risk y Execution, conectados por un bus de mensajes loggeable.

Los 4 agentes

1. Data Agent

  • Pull market data: precios, earnings calendar, options chains, news.
  • Fuentes: broker APIs (Alpaca, IBKR), data providers (Polygon, Alpha Vantage, CBOE).
  • Output: stream/snapshot de datos normalizados para los otros agentes.

2. Strategy Agent

  • Evalúa data contra reglas/modelos definidos.
  • Output: señales {ticker, action: buy|sell|hold|skip, confidence, rationale}.
  • Formato típico: condition/action rules.
  • Complemento o reemplazo: LLM que hace análisis fundamental sobre fillings, news, macro.

3. Risk Agent

  • Gatekeeper: cada orden propuesta por Strategy pasa por aquí antes de ejecutarse.
  • Checks estándar:
  • max_position_size por ticker (sugerido 2–5%).
  • portfolio_concentration total por sector/factor.
  • daily_loss_limit (sugerido 2%).
  • market_hours_only.
  • no_trade_pre_earnings_48h.
  • circuit_breaker — halt on drawdown.
  • Para opciones: liquidez mínima (OI >500, bid-ask <5%, vol >100).
  • Output: aprobar / rechazar / modificar orden.

4. Execution Agent

  • Coloca la orden en el broker.
  • Maneja retries, partial fills, slippage.
  • Persiste en trade log.
  • Output: confirmación de ejecución (qty, price, ts) o failure.

Message bus

Los 4 se comunican vía shared bus (pub/sub interno). Cada handoff se logga — auditabilidad total. Ver concepts/file-based-agent-memory para cómo persistir los logs.

Cómo aplica al user (RACIONAL sin API)

Modificación principal: el Execution Agent NO hace submit automático vía API — en su lugar:

  • Fase 1 (HITL): emite "orden candidata" al user vía notificación; user ejecuta manual en UI de RACIONAL.
  • Fase 2 (semi-auto): usa Chrome automation para rellenar el form de orden, el user confirma con un click.
  • Fase 3 (full-auto): si todo lo anterior estable, Chrome automation con submit automático (ver analysis/adapting-broker-without-api para riesgos).

Los otros 3 agentes (Data, Strategy, Risk) pueden ser idénticos al patrón puro.

Variantes

  • 1 agente monolítico: todo en un LLM call. Simpler, but mezcla responsabilidades → harder to audit, fallas compuestas.
  • Agents con modelos distintos: Data puede ser llamada determinista; Strategy puede ser LLM; Risk puede ser script puro. Mix and match.
  • N sub-agents por rol: ej. Strategy tiene sub-agents por factor (momentum, value, macro).

Por qué separar en 4

  1. Single responsibility: cada agente con un contrato claro.
  2. Risk siempre independiente: el Risk Agent NO puede ser "convencido" por Strategy de bypassearlo — es un script aparte con reglas duras.
  3. Auditabilidad: cada decisión queda en logs separados.
  4. Substituibilidad: cambiar el Strategy Agent (nuevo modelo, nueva estrategia) sin tocar Data/Risk/Execution.
  5. Cost optimization: Strategy Agent (caro, LLM) solo corre cuando Data marca cambio relevante; Risk (barato, script) corre siempre.

Anti-pattern a evitar

  • Agente "full-stack": un solo LLM que busca data, decide, valida riesgo y ejecuta. El LLM racionaliza violar guardrails ("esta vez es diferente").
  • Risk como recomendación: el Risk Agent debe poder bloquear, no solo "sugerir".

Relaciones