Чому це важливо
Агенти, що працюють у петлях, мають дві витрати, які швидко накопичуються. Вартість квоти: кожен виклик інструменту MCP враховується у вашому тижневому ліміті. Вартість токенів: кожна частина даних у вікні контексту збільшує витрати на обробку та знижує якість міркувань.
Тонкий блок контексту вирішує обидві проблеми: один короткий прогін по тикерах, резюмований у кількох рядках, вставляється один раз на початку розмови. Агент має ситуаційну обізнаність без шторму викликів інструментів або інфляції токенів.
Передумови
Cryptohopper MCP налаштований у клієнті MCP — див. огляд налаштування.
Робочий процес агента, який запускається періодично або безперервно. Одноразові запити не отримують вигоди від цієї техніки.
Достатньо рівня Pioneer — виклики тикерів дешеві на всіх рівнях. Див. рівні підписки.
Етапи налаштування
Визначте, що буде в блоці
Чотири-шість рядків, усі отримані з тикерів — близько 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"
# Fixed anchor tickers — one call each
anchors = ["BTC/USDT", "ETH/USDT", "SOL/USDT"]
anchor_tickers = [mcp.get_ticker(exchange, pair) for pair in anchors]
# Sweep universe — one call per symbol
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]
# Derive summary fields
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)
# Total calls = len(anchors) + len(sweep_pairs) = 13 per runВставте блок на початку першого повідомлення агента
Розмістіть блок перед інструкцією щодо завдання з позначкою часу. Агент спочатку читає контекст і не повинен повторно отримувати будь-які вже перелічені дані.
[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 для отримання свічок або глибини ордербуку для цього конкретного pasangan. Більшість запусків закінчуються без ескалації — це правильна поведінка.
Оновлюйте з періодичністю, що відповідає робочому процесу
Агент, що працює щогодини → відбудовувати на початку кожної години.
Щоденний дайджест → раз на день.
Помічник на вимогу → раз за сесію.
Не використовуйте один блок повторно між межами періодичності — застарілий контекст гірший за його відсутність.
Математика
Агент, що працює щогодини, 16 годин/день, 5 буднів/тиждень, з розгоном 13 символів:
Підхід | Виклики на запуск | Тижневі виклики |
Наївний (агент отримує дані з нуля) | 20–100 (сильно варіюється) | 1,600–8,000 |
Тонкий контекст + вибіркова ескалація | 13 базових + ~10–30 при ескалації | 1,840–5,040 (стабільно) |
Тонкий контекст не завжди дешевший в сумі — він купує передбачуваність. Ви знаєте, як виглядає тиждень з найгіршим сценарієм. На рівні Pioneer з 6000 викликів/тиждень він дозволяє працювати легкому погодинному агенту на безкоштовному рівні.
Коли не слід використовувати цей шаблон
Ситуація | Чому тонкий контекст не допомагає |
Одноразові розмовні дослідження | Просто поставте запитання — помічник впорається |
Робочі процеси, які завжди потребують глибоких даних | Генератор параметрів сіткового бота вже потребує історії свічок; тонкий контекст є зайвим |
Робочі процеси, чутливі до прослизання | Вони ніколи не повинні міркувати на основі кешованого контексту — завжди отримуйте свіжі дані |
Використовуйте тонкий контекст, коли робочий процес повторюється, передбачуваний і в основному базується на обізнаності. Економія накопичується; без цих властивостей накладні витрати не варті того.
Усунення несправностей
Агент ігнорує тонкий контекст і повторно отримує ті ж дані
Пропишіть йому явно: "Блок контексту вище — це поточний стан, не отримуйте повторно тикери для BTC, ETH, SOL або будь-чого з переліченого. Отримуйте нові дані тільки якщо вам потрібно щось, чого немає в блоці." Як тільки це сформульовано як обмеження, агент його дотримується.
Блок застаріває до того часу, як його використовує агент
Для робочих процесів з коротким періодом (хвилинний рівень) блок швидко застаріває. Або оновлюйте частіше, або чітко позначте часову мітку блоку, щоб агент знав, що потрібно перевірити перед прийняттям рішень на основі старих чисел.
Формат блоку непослідовний від запуску до запуску
Виправте формат як шаблон і заповнюйте значення — не дозволяйте моделі писати блок. Детермінований генератор виробляє послідовний вивід.
Ви хочете більше даних у блоці
Чиніть опір бажанню. Кожен рядок коштує токенів при кожному запуску. Якщо точка даних не згадується більшістю запусків, вона повинна бути у виклику на вимогу, а не в блоці.
Блок містить числа, які агент ігнорує
Видаліть їх. Блок, який використовується на 100%, кращий за той, що використовується на 60%.
Контекст з кількох бірж робить блок занадто великим
Використовуйте одну основну біржу (зазвичай Binance) для блоку. Нехай агент отримує дані з інших майданчиків тільки тоді, коли потрібне порівняння — не попередньо заповнюйте контекст з кількох майданчиків для загального випадку.
Ви хочете тонкий контекст, що охоплює кілька таймфреймів
Використовуйте один блок на кожну мету агента замість того, щоб намагатися їх об'єднати. Агент, орієнтований на ТА, отримує блок з 4-годинним трендом; агент, орієнтований на сканування, отримує блок з 24-годинними дельтами.