가격·사이트 모니터링

상품 가격, 재고 문구, 공지사항처럼 가끔만 바뀌는 페이지를 사람이 매번 새로고침할 수는 없습니다. 이 레시피는 에이전트가 정해진 간격으로 페이지를 살펴보고, 직전에 본 내용과 다를 때에만 알림을 보내도록 구성합니다.

이렇게 동작합니다

• 지정한 주기마다 페이지를 한 번씩 확인합니다.
• 핵심 값(가격, 재고 문구, 특정 문장 등)을 추출해 직전에 저장해 둔 값과 비교합니다.
• 변화가 있으면 사용자 알림으로 메시지를 보냅니다(자율 실행 중에는 푸시 알림도 함께 갑니다).
• 변화가 없으면 조용히 아무것도 하지 않고 다음 주기를 기다립니다.

핵심은 “조용히 다음 주기로 넘어가는” 동작입니다. 매번 보고하면 알림이 노이즈가 돼서 진짜 변화를 놓치게 됩니다.

켜야 할 도구

설정 탭 → 활성화된 도구에서 아래를 켭니다.

💡 HTTP 요청으로 읽을 수 있는 페이지는 그쪽이 빠르고 가볍습니다. 로그인이 필요하거나 자바스크립트로 렌더링되는 페이지에서만 웹 브라우저를 켜세요.

시스템 프롬프트 예시

에이전트 설정 → 시스템 프롬프트에 다음과 같은 행동 지침을 넣어두면 일관되게 동작합니다. (지시는 자신의 상황에 맞게 다듬으세요.)

역할: 가격·사이트 모니터링 에이전트.

확인 대상:
- https://example.com/product/123  (관심 상품 가격과 "재고 있음" 문구)

매 실행마다 할 일:
1. 위 URL의 페이지를 가져온다.
2. 가격 숫자와 재고 문구를 뽑아낸다.
3. monitoring/last_seen.md 를 읽어 직전 값을 가져온다.
   - 파일이 없으면 이번 값을 baseline으로 저장하고 종료.
4. 직전 값과 비교한다.
   - 가격이 다르거나 재고 문구가 변했으면 사용자에게 알린다.
     - 어떤 값이 어떻게 바뀌었는지(전 → 후) 한 문장으로 요약한다.
   - 변화가 없으면 아무 메시지도 보내지 않는다.
5. 이번에 본 값으로 monitoring/last_seen.md 를 덮어쓴다.

알림은 변화가 있을 때만. 같은 값이면 조용히 마친다.

이 지시에서 중요한 부분은 두 가지입니다.

• 직전 값이 없으면 baseline만 저장하고 끝내기 — 첫 실행에서 잘못된 알림을 보내지 않습니다.
• 변화 없을 때 메시지 금지 — 매번 “변화 없음”을 보내면 푸시가 의미를 잃습니다.

스케줄 등록하기

에이전트에게 “이 페이지를 1시간마다 확인해줘”라고 말하면, 에이전트가 스케줄 생성 도구로 직접 자기 스케줄을 등록합니다. 등록된 스케줄은 에이전트 상세 페이지 → 스케줄 서브페이지에서 확인·수정·삭제할 수 있습니다.

스케줄 등록은 앞으로 크레딧을 쓰는 자동 실행을 예약하는 동작이라, 기본적으로 등록 전에 한 번 승인을 묻습니다. 매번 확인 없이 바로 등록되게 하려면 도구별 승인 설정에서 스케줄 생성을 자동 승인으로 바꿔두면 됩니다.

반복 주기 예시:

• “매 시간마다” → 1시간 간격 반복
• “평일 오전 9시에” → 월~금 오전 9시 실행
• “3시간마다” → 3시간 간격 반복

처음에는 1시간처럼 넉넉한 주기로 시작하고, 페이지 특성에 맞게 조정하세요. 너무 자주 확인하면 페이지가 차단하거나 크레딧이 빨리 줄어듭니다.

첫 실행 — baseline 잡기

새로 만든 모니터링 에이전트는 첫 실행에서 직전 값을 모릅니다. 시스템 프롬프트에 위처럼 “파일이 없으면 baseline으로 저장하고 종료” 규칙을 적어두면, 첫 실행은 알림 없이 조용히 기준값만 만들고 끝납니다. 두 번째 실행부터 비교가 시작됩니다.

기준값을 처음부터 수동으로 잡고 싶다면, 채팅에서 “지금 본 가격을 baseline으로 저장해줘”라고 한 번 시켜 두면 됩니다.

다듬기 — 노이즈 줄이기

페이지가 작은 변화로도 흔들리면 알림이 너무 자주 옵니다. 시스템 프롬프트에 임계치를 추가하세요.

• 가격 임계치 예시: “가격 변화가 5% 미만이면 알리지 말 것. 5% 이상이거나 재고 문구가 바뀐 경우에만 알림.”
• 시점 임계치 예시: “같은 변화 알림을 12시간 안에 두 번 보내지 말 것 (메모리에 마지막 알림 시각을 기록해 비교).”

알림 톤도 따로 지시할 수 있습니다. “급격한 가격 인하면 긴급한 톤으로, 단순 문구 변경이면 조용한 톤으로.” 같은 식입니다.

다음 단계

• 도구 부여하기 — 이 레시피에 쓰인 도구들의 자세한 설명
• 매일 아침 뉴스 브리핑 — 같은 “스케줄 + 사용자 알림” 패턴이지만 변화 비교 없이 매번 보고하는 버전
• 리서치 비서 — 모니터링 중 큰 변화가 잡혔을 때 뒤를 캐내는 후속 에이전트로 연결할 수 있습니다

고급 (Advanced)

아래 내용은 일반 사용자에게 필요하지 않습니다. 비교 로직을 더 다듬거나, 로그인 페이지를 모니터링하는 등 한 단계 더 들어갈 때만 참고하세요.

직전 값은 어디에 저장되나요

파일 쓰기에서 monitoring/last_seen.md처럼 상대 경로로 저장한 파일은 에이전트의 개인 메모리 영역에 보관됩니다. 같은 에이전트의 다음 실행에서 파일 읽기로 같은 상대 경로를 부르면 그대로 다시 읽을 수 있습니다.

• 이 저장 공간은 해당 에이전트 전용입니다 — 같은 팀의 다른 에이전트는 볼 수 없습니다.
• 팀 전체가 공유해야 하는 값이라면 대신 팀 상태 설정(team_state_set)을 사용하세요.
• 저장하는 파일은 마크다운 형식이 다루기 쉽습니다. 단순한 키-값 몇 개라면 그냥 한두 줄로 적어두는 것으로 충분합니다.

메모리 인덱스 파일에는 길이 제한이 있으므로, 본격적인 데이터는 monitoring/처럼 하위 경로에 분리해서 저장하는 것이 안전합니다.

노이즈가 심한 페이지

페이지 본문이 자주 흔들리는데도 같은 알림이 반복되면 다음을 시도해보세요.

1. 추출 범위 좁히기 — 페이지 전체가 아니라 “가격 숫자”처럼 명시적 키워드만 추출하도록 시스템 프롬프트에 적습니다.
2. 임계치 추가 — 본문에 5% 이상, 12시간 내 1회 등 한도 규칙을 추가합니다.
3. 확인 주기 늘리기 — 5분 → 1시간으로 늘리면 자잘한 변동은 자연히 합쳐집니다.
4. 확인 시간대 좁히기 — 24시간 내내가 아니라 평일 9~18시처럼 의미 있는 시간대만 잡습니다. 스케줄을 그에 맞게 등록하면 됩니다. 에이전트 설정 → Heartbeat → 활성 시간대 밴드로 미리 허용 범위를 정해두면, 그 바깥 시각으로 스케줄을 등록하려 할 때 에이전트가 한 번 더 확인을 요구합니다.

로그인이 필요한 페이지

로그인 후에만 보이는 페이지(회원 전용 가격, 대시보드 등)는 HTTP 요청으로는 가져올 수 없습니다. 이 경우:

• 웹 브라우저 도구를 켜고, 시스템 프롬프트에 “로그인 화면이 나타나면 화면을 사용자에게 넘겨 직접 로그인하도록 요청”처럼 적어두세요. 실제로 화면을 넘기는 동작은 사용자 질문 도구의 데스크톱 모드가 담당합니다(사용자 질문 도구는 기본으로 켜져 있어 따로 켤 필요가 없습니다). 에이전트가 로그인이 필요한 시점에 화면 제어권을 잠시 사용자에게 돌려주고, 사용자가 직접 로그인을 완료하고 “완료” 버튼을 누르면 이어서 진행합니다. 이 방식은 에이전트가 비밀번호를 직접 다루지 않아 더 안전합니다.
• 자주 쓰는 외부 서비스라면 설정 → 외부 서비스 연결에서 미리 연결해 두는 편이 안전합니다 (지원되는 서비스에 한함).
• 에이전트가 페이지 내용을 마음대로 다른 곳에 보내지 않도록 시스템 프롬프트에 작업 범위를 명시해 두는 것을 권장합니다.

비용 메모

• 페이지 확인 주기를 짧게 잡을수록 LLM 호출 횟수가 늘어 크레딧 사용량이 비례해 증가합니다.
• 웹 브라우저 도구는 HTTP 요청보다 호출 단위 비용이 큽니다 — 둘 다 쓸 수 있다면 가벼운 쪽을 우선하세요.
• 변화가 없을 때 알림 메시지를 보내지 않도록 시스템 프롬프트에 명시하면, 매 주기마다 응답 생성 비용도 줄어듭니다.