AI 주식 관심 목록 리서치 에이전트

의미 있는 업데이트의 조건을 정의하세요

관심 목록 에이전트는 마지막으로 검토한 리서치 패킷 이후 무엇이 바뀌었는지 답해야 합니다. 새로운 제출 자료, 수정된 공시, 실적 발표, 열린 리서치 질문에 영향을 주는 근거처럼 중요한 이벤트를 정의하세요. 각 발행인의 리서치 질문과 소스 커버리지를 식별자와 함께 저장합니다. 그러면 모델에는 범위가 정해진 작업이 주어지고 검토자에게는 업데이트를 받는 이유가 생깁니다. 타이머가 울렸다는 이유만으로 제한 없는 기업 분석을 예약하지 마세요. 변하지 않은 입력은 일반적으로 또 다른 긴 보고서가 아니라 변하지 않은 상태를 만들어야 합니다.

수집과 리서치 생성을 분리하세요

먼저 소스 피드 또는 허용된 폴링으로 메타데이터를 수집한 뒤 새 자료가 모델 작업을 할 만한지 결정하세요. SEC 개발자 리소스는 미국 제출 기업 수집을 지원할 수 있는 제출 피드와 색인을 설명하며 다른 시장에는 자체 권위 있는 출처가 필요합니다. 게시 시간, 검색 시간, 소스 리비전을 독립적으로 저장하세요. 변경된 웹페이지 래퍼를 새로운 기업 공시로 오해해서는 안 됩니다. 관련 문서 또는 이벤트에서 콘텐츠 식별자를 만들고 아무것도 바뀌지 않았다는 판단과 소스 오류를 별도로 보존합니다.

하나의 전역 시계가 아니라 시장과 소스에 맞춰 예약하세요

각 증권에 거래소 시간대와 휴일 캘린더를 함께 보존하세요. 정보 가용성에는 공시 타임스탬프를 사용하고 검토자가 요약을 원하는 시점에는 별도의 일정을 사용합니다. 발행인이 장외 시간에 공개하거나 여러 시장에 상장할 수 있습니다. 모든 이벤트를 하나의 달력 날짜로 옮겨 순서를 잃지 마세요. 반복 작업에서는 예정된 시간 창과 실제 실행 시간을 기록합니다. 누락된 실행은 전체 이력을 조용히 건너뛰거나 다시 재생하지 말고 마지막으로 완료된 수집 워터마크에서 재개해야 합니다.

명시적인 작업 및 알림 상태를 사용하세요

작은 상태 머신이 반복 작업을 운영하기 쉽게 합니다. 변하지 않음, 새 근거, 소스 이용 불가, 리서치 대기, 검토 필요를 구분하세요. 아래 예시 기록은 애플리케이션 설계이지 스케줄러 제품 구성은 아닙니다. 안정적인 이벤트 키와 소스 매니페스트 해시를 유지해 같은 작업을 재시도해도 중복 작업이나 중복 알림이 만들어지지 않게 하세요. 이벤트를 완료로 표시하기 전에 산출물을 저장합니다. 성공적인 보고서 생성에서 추론하지 말고 알림 전달은 자체 확인 상태를 가져야 합니다.

{
  "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"
}

현재 및 이전 패킷에서 변경 노트를 생성하세요

새 소스, 이전에 검토된 노트, 열린 질문을 모델에 제공하세요. 소스 위치와 어떤 이전 문장을 업데이트해야 하는지 명확한 설명이 있는 짧은 변경 로그를 요청합니다. 원래 노트를 덮어쓰지 말고 리비전으로 보존하세요. 새로운 공시는 해석을 강화하거나 약화하거나 그대로 둘 수 있으므로 모든 이벤트를 방향성 있는 주식 신호로 만들지 마세요. 이전 패킷이 없다면 과거 비교를 지어내지 말고 초기 리서치 상태를 만드세요.

반복 예산과 재시도 정책에 상한을 두세요

예약하기 전에 실행별 발행인 수, 소스 양, 모델 시도, 벽시계 작업 시간에 제한을 설정하세요. 계획에는 현재 모델 계약을 사용하고 이벤트 및 작업별 실제 사용량을 보존합니다. 소스 재시도와 모델 재시도를 분리해 일시적인 제출 자료 장애가 오래된 데이터에 대한 분석을 반복하게 만들지 마세요. 문서 및 파서 버전으로 추출을 캐시하세요. 예산을 다 쓰면 새 작업 생성을 중지하고 대기 이벤트를 보존하며 미해결 상태를 드러냅니다. 불필요한 검토 부하를 줄이도록 알림 빈도와 수집 빈도를 분리하세요.

작은 운영 미니플로를 실행하세요

반복 전달을 활성화하기 전에 변하지 않은 문서, 새 리비전, 일시적으로 이용할 수 없는 소스, 재시도된 알림을 테스트하세요. 안정적인 이벤트 식별자, 올바른 리서치 상태, 같은 완료 이벤트에 대해 의도한 알림이 정확히 하나인지 확인합니다. 그런 다음 원래 근거와 대조해 완전한 변경 노트 하나를 검사하세요. 수집기와 리서치 도구는 읽기 전용으로 유지하고 외부 메시지 대상에는 명시적인 승인을 사용합니다. 리서치 승인은 주문 승인이 아닙니다. 관심 목록 워크플로가 감시 없이 실행된다는 이유만으로 브로커 권한을 얻어서는 안 됩니다.

근거와 한계

이 가이드는 공식 제출 자료 리소스와 소스 검토된 리서치 애플리케이션의 영향을 받은 워크플로 설계입니다. 이 페이지를 위해 반복 관심 목록 작업, 알림 전달, 측정된 사용량 사례를 실행하지 않았습니다. 반복 워크플로가 운영 중이라고 주장하기 전에 배포 기록에는 실제 스케줄러, 소스 커버리지, 모델, 저장된 이벤트 상태, 알림 테스트가 식별되어야 합니다.

자주 묻는 질문