Agente de investigación de listas de seguimiento de acciones con IA

Define qué cuenta como actualización relevante

Un agente de lista de seguimiento debe responder qué cambió desde el último paquete de investigación revisado. Define los eventos importantes: un informe nuevo, una divulgación corregida, una llamada de resultados o evidencia que afecte a una pregunta de investigación abierta. Guarda las preguntas de investigación y la cobertura de fuentes de cada emisor junto a su identificador. Esto da al modelo un trabajo acotado y al revisor un motivo para recibir una actualización. Evita programar análisis de empresas sin restricciones solo porque se active un temporizador; las entradas sin cambios normalmente deben producir un estado sin cambios en lugar de otro informe largo.

Separa la recopilación de la generación de investigación

Usa feeds de fuentes o polling permitido para recopilar primero los metadatos y decide después si el material nuevo justifica trabajo del modelo. Los recursos para desarrolladores de la SEC describen feeds e índices de informes que pueden apoyar la recopilación de emisores estadounidenses; otros mercados necesitan sus propias fuentes autoritativas. Almacena por separado la hora de publicación, la hora de recuperación y la revisión de la fuente. Un wrapper de página cambiado no debe confundirse con una nueva divulgación de la empresa. Construye la identidad del contenido a partir del documento o evento pertinente y conserva los errores de fuente separados de la determinación de que no cambió nada.

Programa por mercado y fuente, no con un único reloj global

Mantén la zona horaria de la bolsa y el calendario de festivos junto a cada valor. Usa las marcas de tiempo de divulgación para la disponibilidad de información y un calendario separado para el momento en que los revisores quieren el resumen. Un emisor puede publicar fuera del horario de mercado o cotizar en varios mercados. No desplaces cada evento a una sola fecha natural y pierdas el orden. Para trabajos recurrentes, registra la ventana prevista y la hora real de ejecución. Una ejecución perdida debe reanudarse desde el último watermark de recopilación completado, en lugar de omitir silenciosamente un intervalo o reproducir todo el historial.

Usa estados explícitos de trabajo y notificación

Una máquina de estados pequeña facilita la operación del trabajo recurrente. Distingue sin cambios, evidencia nueva, fuente no disponible, investigación pendiente y revisión requerida. El registro ilustrativo de abajo es un diseño de aplicación, no una configuración de producto de programación. Mantén una clave de evento estable y un hash del manifiesto de fuentes para que reintentar el mismo trabajo no genere trabajo ni notificaciones duplicadas. Persiste el artefacto antes de marcar el evento como completado. La entrega de notificaciones debe tener su propio estado de acuse, en lugar de inferirse de una generación de informe correcta.

{
  "issuer_id": "REQUIRED",
  "event_key": "REQUIRED_STABLE_KEY",
  "source_manifest_hash": "REQUIRED",
  "collection_status": "pending",
  "research_status": "not_started",
  "review_status": "pending",
  "notification_status": "not_sent"
}

Genera una nota de cambios a partir del paquete actual y el anterior

Proporciona al modelo la fuente nueva, la nota anterior revisada y las preguntas abiertas. Pide un registro breve de cambios con localizadores de fuentes y una explicación clara de qué afirmaciones anteriores necesitan actualización. Conserva la nota original como una revisión en lugar de sobrescribirla. Una divulgación nueva puede reforzar, debilitar o dejar sin cambios una interpretación; no fuerces cada evento a convertirse en una señal direccional de acciones. Si falta el paquete anterior, produce un estado inicial de investigación en lugar de inventar una comparación histórica.

Acota el presupuesto recurrente y la política de reintentos

Establece antes de programar límites por ejecución para emisores, volumen de fuentes, intentos del modelo y trabajo de pared. Usa el contrato actual del modelo para planificar y conserva el uso real por evento y trabajo. Separa los reintentos de fuentes de los reintentos del modelo para que una interrupción temporal de informes no active análisis repetidos de datos obsoletos. Guarda la extracción en caché usando versiones del documento y del parser. Detén la generación de trabajo nuevo cuando se agote el presupuesto, conserva los eventos en cola y muestra el estado sin resolver. Mantén independiente la frecuencia de notificación de la frecuencia de recopilación para reducir la carga de revisión innecesaria.

Ejercita un miniflujo operativo pequeño

Antes de activar la entrega recurrente, prueba un documento sin cambios, una revisión nueva, una fuente temporalmente no disponible y una notificación reintentada. Verifica la identidad estable del evento, el estado correcto de investigación y exactamente una notificación prevista para el mismo evento completado. Después inspecciona una nota de cambios completa frente a la evidencia original. Mantén el recopilador y las herramientas de investigación en solo lectura y usa autorización explícita para los destinos de mensajería externos. La aprobación de investigación no es aprobación de órdenes; el flujo de lista de seguimiento no debe obtener permisos de bróker solo porque se ejecute sin supervisión.

Evidencia y limitaciones

Esta guía es un diseño de flujo informado por recursos oficiales de informes y aplicaciones de investigación revisadas con fuentes. Para esta página no se ejecutaron un trabajo recurrente de lista de seguimiento, una entrega de notificaciones ni un caso de uso medido. Un registro de despliegue debe identificar el programador real, la cobertura de fuentes, el modelo, los estados de eventos persistidos y la prueba de notificación antes de afirmar que el flujo recurrente es operativo.

Preguntas frecuentes