Biblioteca de módulos integrada

Braidrun incluye más de 120 módulos integrados. Cada módulo es un workflow encapsulado con un contrato de entrada / salida tipado; otros workflows lo referencian con un step sub_workflow, sin necesidad de preocuparse por su implementación interna.

Herramientas generales (unas 80)

utility-module-* prefijo, cubre los pasos generales ajenos al negocio, como procesamiento de datos, solicitudes HTTP, búsqueda y scraping, IA de texto y comprobaciones de monitoreo. Módulos representativos:

Entrega y notificación

Salida de notificación estable al final del workflow, implementada en su mayoría con pasos de puro código, sin depender del LLM, para evitar que la falta de credenciales del modelo rompa la cadena de notificación. Módulos representativos:

Los demás módulos de notificación cubren bots de grupo de Discord, Feishu, WeCom, Microsoft Teams, Mattermost y Rocket.Chat; correo de Mailgun / SendGrid; y notificaciones de Bark, Pushover y ServerChan. También hay un módulo de entrega de archivos por Telegram que envía informes .md / .xlsx / .pdf / .csv, junto con un texto explicativo, directamente a la conversación indicada. La opción dedupe_key evita envíos duplicados al volver a ejecutar.

Análisis financiero (unos 10)

module-* cadena de herramientas cuantitativas con el prefijo: cotizaciones → indicadores técnicos → análisis de cartera → backtesting. Los módulos de cotizaciones no requieren API key (fuentes de datos Tencent Finance / Yahoo Finance / CoinGecko), y los módulos de indicadores y backtesting están implementados con la biblioteca estándar pura.

La misma serie incluye además módulos de noticias de acciones, selección condicional de valores, valoración de opciones, indicadores de riesgo y visión general de mercado, que se pueden encadenar en un flujo completo desde la cotización hasta el informe.

Publicidad y crecimiento (unos 40)

Este conjunto de módulos proviene de las operaciones reales de campañas de un equipo de una app de suscripción, y cubre Apple Search Ads, Google Ads y datos de ingresos de App. Los principales tipos, por finalidad:

• Extracción de informes de ASA：Cuatro dimensiones campaigns / keywords / adgroups / searchterms, con nivelado automático de las diferencias de nomenclatura de los campos de la interfaz.
• Lista de entidades de ASA：Extracción por lotes de campañas, grupos de anuncios, palabras clave y palabras clave negativas.
• Herramientas de Google Ads：Ejecuta consultas GAQL y las devuelve estructuradas; incluye además informes de rendimiento de campañas y descubrimiento de cuentas accesibles.
• Extracción de ingresos de App：Obtiene datos de ingresos y suscripciones por ventana de tiempo.
• Resolución de ventana de tiempo：Convierte los días de retrospección más la zona horaria en fechas de inicio y fin normalizadas, garantizando que la semántica de «ayer / la semana pasada» sea idéntica en un lote de informes.
• Ensamblaje de informes：Construcción de Excel de varias hojas y renderizado de plantillas de informe en Markdown.
• Procesamiento por lotes de varias Apps：El mismo subflujo se ejecuta una vez por cada App de un lote y combina los resultados.
• Bucle de revisión de calidad：Puerta de calidad estandarizada de generar → puntuar → reintentar si no cumple → salir al cumplir.

Contrato de módulo

Cada módulo declara un contrato: la entrada es tipada (string / number / boolean / enum / path / json), se puede marcar required, un valor por defecto, los valores del enum y un rango numérico; la salida declara nombre, tipo y variable de origen; el contrato tiene una contract_version independiente de la versión de implementación del workflow.

module:
  enabled: true
  display_name: Web Search
  contract_version: 1.0.0
  inputs:
    - {name: query, type: string, required: true}
    - {name: provider, type: enum, default: duckduckgo,
       allowed_values: [duckduckgo, serper]}
    - {name: max_results, type: number, default: "10", min: 1, max: 100}
  outputs:
    - {name: results_json, type: string, source: "{{var:results_json}}"}
    - {name: result_count, type: number, source: "{{var:result_count}}"}

Al modificar el contrato, la plataforma compara el nuevo con el antiguo: los cambios no disruptivos (por ejemplo, añadir una entrada opcional) pasan directamente; los cambios disruptivos (que afectan a los consumidores existentes) se rechazan por defecto al guardar, requieren confirmación explícita y se sugiere un nuevo número de versión del contrato. El contrato también admite la marca deprecated con notas de migración, que avisa a los consumidores para que cambien a un módulo sustituto.

Referenciarlo en un workflow

Referéncielo por id de módulo con un step sub_workflow. Los valores de inputs son todos cadenas (los números también se escriben como "10"), admiten plantillas de variable; outputs mapea las salidas del módulo de vuelta a variables del workflow padre, y los pasos posteriores las usan directamente.

workflow:
  - step: fetch_metrics
    sub_workflow:
      name: utility-module-http-request
      version_strategy: latest
      inputs:
        url: "https://api.example.com/v1/metrics"
        method: GET
      outputs:
        status_code: fetch_status
        response_body: metrics_json

  - step: notify
    sub_workflow:
      name: utility-module-slack-webhook
      inputs:
        webhook_url: "{{var:slack_webhook_url}}"
        text: "Metrics updated: {{var:metrics_json}}"
      outputs:
        send_status: notify_status
    depends_on:
      - fetch_metrics
    retry:
      max_attempts: 2
      backoff: exponential

• version_strategy Por defecto latest; también puede fijar una versión concreta, y las actualizaciones del módulo no afectarán a los workflows padre ya en producción.
• Una referencia que apunta a un módulo funciona en modo contrato: inputs / outputs se validan según el contrato; si el módulo se degrada de nuevo a un workflow normal, la referencia pasa a modo laxo y deja de validarse automáticamente.
• Los modificadores de paso retry, condition, depends_on, etc., están disponibles con normalidad para los steps sub_workflow.

Módulo personalizado

Cualquier workflow se puede promocionar a módulo: en el panel de configuración del workflow del editor, busque la sección «Contrato de módulo», rellene el nombre visible, la descripción, las entradas / salidas y la versión del contrato, y pulse «Guardar contrato de módulo». Después aparecerá en la biblioteca de módulos y otros workflows podrán referenciarlo con sub_workflow.

Al retirar la condición de módulo (degradar), la plataforma hace primero una comprobación de dependencias inversas: si todavía hay workflows padre que referencian este módulo, enumera las ubicaciones concretas de la referencia y bloquea la operación, para evitar romper en silencio el flujo de otros.

Los módulos, igual que las plantillas, se pueden publicar en el marketplace, con número de versión, y al instalarlos las dependencias se resuelven automáticamente.