이것이 왜 중요할까요?
루프에서 실행되는 에이전트는 빠르게 누적되는 두 가지 비용이 발생합니다. 할당량 비용: 모든 MCP 도구 호출은 주간 허용치에서 차감됩니다. 토큰 비용: 컨텍스트 창에 있는 모든 데이터 조각은 처리 비용을 증가시키고 추론 품질을 저하시킵니다.
얇은 컨텍스트 블록은 이 두 가지 모두를 해결합니다. 짧은 티커 스윕을 몇 줄로 요약하여 대화 시작 시 한 번 주입합니다. 에이전트는 도구 호출 폭풍이나 토큰 인플레이션 없이 상황 인식을 갖게 됩니다.
사전 요건
설정 단계
블록에 포함될 내용 정의
4~6줄, 모두 티커에서 파생 — 약 100 토큰. 일반적인 블록은 다음과 같은 내용을 포함합니다: 기준 통화 티커의 가격 및 24시간 변동, 스윕 범위 내 최고 상승 및 최저 하락, 비정상적인 거래량을 보이는 모든 페어, 그리고 한 단어로 된 시장 체제 라벨.
BTC 66,120 (+1.1%, vol normal)
ETH 3,240 (+2.8%, vol elevated)
SOL 148.50 (+1.9%, vol normal)
Top gainer: ARB +8.2% (vol 2.4x)
Top loser: DOGE -3.5% (vol normal)
Unusual volume: LINK (flat price, vol 3.1x)
Market regime: risk-on, moderate breadth심볼별 루프를 사용하여 블록 생성
벌크 티커 도구는 없습니다 — 각 티커는 단일 MCP 호출입니다. 아래 함수는 심볼마다 한 번씩 호출합니다. 3개의 기준 + 10개의 심볼 스윕은 실행당 13번의 호출이 필요합니다.
def build_thin_context() -> str:
exchange = "binance"
# 고정 기준 티커 — 각각 한 번씩 호출
anchors = ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
anchor_tickers = [mcp.get_ticker(exchange, pair) for pair in anchors]
# 스윕 범위 — 심볼마다 한 번씩 호출
sweep_pairs = [
"ARB/USDT", "OP/USDT", "AVAX/USDT", "LINK/USDT", "AAVE/USDT",
"UNI/USDT", "DOGE/USDT", "MATIC/USDT", "SEI/USDT", "TIA/USDT",
]
sweep_tickers = [mcp.get_ticker(exchange, pair) for pair in sweep_pairs]
# 요약 필드 도출
all_tickers = anchor_tickers + sweep_tickers
top_gainer = max(all_tickers, key=lambda t: t.change_24h_pct)
top_loser = min(all_tickers, key=lambda t: t.change_24h_pct)
unusual = [t for t in all_tickers if t.volume_ratio_vs_baseline > 2.5]
return format_as_context(anchor_tickers, top_gainer, top_loser, unusual)
# 총 호출 횟수 = len(anchors) + len(sweep_pairs) = 실행당 13번에이전트의 첫 메시지 상단에 블록 삽입
타임스탬프와 함께 작업 지침 앞에 블록을 배치하세요. 에이전트는 컨텍스트를 먼저 읽어야 하며 이미 나열된 내용은 다시 가져오지 않아야 합니다.
[CONTEXT AS OF 2026-04-24 08:00 UTC]
BTC 66,120 (+1.1%, vol normal)
ETH 3,240 (+2.8%, vol elevated)
SOL 148.50 (+1.9%, vol normal)
Top gainer: ARB +8.2% (vol 2.4x)
Top loser: DOGE -3.5% (vol normal)
Unusual volume: LINK (flat price, vol 3.1x)
Market regime: risk-on, moderate breadth
Your task: [the actual thing you want the agent to do]더 많은 정보가 필요할 때 에이전트가 얇은 블록에서 에스컬레이션하도록 허용
이 블록은 요약입니다. 흥미로운 점이 발견되면 에이전트는 해당 특정 페어에 대한 캔들 또는 오더북 심도를 얻기 위해 MCP를 호출합니다. 대부분의 실행은 에스컬레이션 없이 종료됩니다 — 이것이 올바른 동작입니다.
워크플로우에 맞는 빈도로 새로고침
시간별 에이전트 → 매시간 시작 시 재생성.
일일 요약 → 하루에 한 번.
요청 시 보조 — 세션당 한 번.
빈도 경계를 넘어서 블록을 재사용하지 마세요 — 오래된 컨텍스트는 컨텍스트가 없는 것보다 나쁩니다.
수학
시간당, 하루 16시간, 주 5일, 13개 심볼 스윕으로 실행되는 에이전트:
접근 방식 | 실행당 호출 횟수 | 주간 호출 횟수 |
단순 (에이전트가 처음부터 가져옴) | 20–100 (매우 다양함) | 1,600–8,000 |
얇은 컨텍스트 + 선택적 에스컬레이션 | 13 기본 + 에스컬레이션 시 ~10–30 | 1,840–5,040 (안정적) |
얇은 컨텍스트가 전체적으로 항상 저렴한 것은 아닙니다 — 이것이 제공하는 것은 예측 가능성입니다. 최악의 주간 상황을 알 수 있습니다. Pioneer의 주간 6,000 호출에서 무료 등급으로 가벼운 시간별 에이전트를 실행 가능하게 유지합니다.
이 패턴을 사용하지 않을 때
상황 | 얇은 컨텍스트가 도움이 되지 않는 이유 |
단기 대화형 연구 | 그냥 질문하세요 — 어시스턴트가 처리합니다 |
항상 깊은 데이터가 필요한 워크플로우 | 그리드 봇 매개변수 생성기는 이미 캔들 기록이 필요합니다. 얇은 컨텍스트는 중복됩니다. |
슬리피지 민감 실행 흐름 | 이러한 흐름은 캐시된 컨텍스트에서 추론해서는 안 됩니다 — 항상 최신 데이터를 가져와야 합니다 |
반복적이고 예측 가능하며 대부분 인식 기반인 워크플로우에는 얇은 컨텍스트를 사용하십시오. 절감 효과는 누적됩니다. 이러한 속성이 없는 경우 오버헤드가 가치가 없습니다.
문제 해결
에이전트가 얇은 컨텍스트를 무시하고 동일한 데이터를 다시 가져옴
명시적으로 프롬프트하세요:"위 컨텍스트 블록이 현재 상태입니다 — BTC, ETH, SOL 또는 나열된 다른 항목에 대한 티커를 다시 가져오지 마세요. 블록에 없는 것이 필요한 경우에만 새 데이터를 가져오세요." 제약 조건으로 프레임되면 에이전트는 이를 준수합니다.
에이전트가 사용할 때쯤 블록이 오래됨
짧은 빈도의 워크플로우(분 단위)의 경우 블록이 빠르게 오래됩니다. 더 자주 새로고침하거나, 오래된 숫자를 기반으로 의사 결정을 내리기 전에 에이전트가 다시 확인하도록 블록 타임스탬프를 명확하게 표시하십시오.
실행 간 블록 형식이 일관되지 않음
템플릿으로 형식을 수정하고 값을 채우세요 — 모델이 블록을 작성하지 않도록 하세요. 결정론적 생성기는 일관된 출력을 생성합니다.
블록에 더 많은 데이터를 원함
충동을 참으십시오. 모든 줄은 모든 실행에서 토큰을 소모합니다. 데이터 포인트가 대부분의 실행에서 참조되지 않으면 온디맨드 호출에 포함되어야 하지 블록에는 포함되면 안 됩니다.
블록에 포함된 숫자를 에이전트가 무시함
그것들을 잘라내세요. 100% 사용되는 블록이 60% 사용되는 블록보다 낫습니다.
여러 거래소의 컨텍스트로 인해 블록이 너무 커짐
블록에는 하나의 주 거래소(일반적으로 Binance)를 사용하세요. 일반적인 경우에 대한 다중 거래소 컨텍스트를 미리 채우지 말고, 비교가 필요할 때만 에이전트가 다른 거래소에서 가져오도록 하세요.
여러 시간 프레임을 포함하는 얇은 컨텍스트를 원함
단일화하려고 시도하는 대신 에이전트 목적별로 하나의 블록을 사용하세요. TA 중심 에이전트는 4시간 추세가 포함된 블록을 얻고, 스캔 중심 에이전트는 24시간 델타가 포함된 블록을 얻습니다.