AI-агенты: harness, loop и память — как это работает
Мы в ZUB-AI редко бросаемся на хайп-темы, но AI-агенты — это не хайп, а рабочий инструмент. Особенно если вы автоматизируете рутину вокруг трейдинга: сбор новостей, разбор скринов сделок, генерацию отчётов по журналу. Команда изучила три свежих технологических разбора об архитектуре агентов и собрала из них практическую выжимку. Один материал — чистая визуальная схема устройства агента. Второй — демонстрация готового open-source фреймворка, живущего локально на машине. Третий — пошаговая сборка агента внутри Claude без единой строки кода.
Кому это полезно. Если вы трейдер уровня intermediate и выше, который хочет не просто «спросить нейросеть», а собрать помощника, который сам выполняет цепочку задач — этот текст для вас. Мы не будем учить писать промпты для чата. Мы разберём, чем настоящий агент отличается от «умного автодополнения» и что нужно, чтобы он работал предсказуемо.
Главный вывод одним предложением: ценность агента живёт не в модели и не в наборе инструментов, а в том, насколько чётко вы описали ему процесс и память.
Что такое агент и почему это не просто чат
Начнём с определения, которое проходит красной нитью через все три разбора. В свежих материалах прослеживается общая модель — три уровня взаимодействия с ИИ.
Уровень первый — обычный чат. Вы задаёте вопрос, получаете ответ, копируете, задаёте следующий. Большинство людей застряли именно здесь и используют мощную LLM как «продвинутый поисковик». Для трейдера это выглядит так: «объясни, что такое order block» — прочитал — закрыл вкладку.
Уровень второй — режим строителя (builder mode). Вы уже не спрашиваете, а просите создать: написать скрипт для парсинга котировок, набросать структуру журнала сделок, проанализировать выгрузку. Результат реальный. Но вы вручную ведёте каждый шаг, проверяете каждый вывод, сами толкаете проект вперёд.
Уровень третий — агентная работа. Вы задаёте цель — конечный результат — а система сама разбивает задачу на этапы, задаёт уточняющие вопросы, выполняет фазы последовательно, проверяет собственную работу и выдаёт готовое. Образ из разборов простой: вы указываете пункт назначения, а агент ведёт машину. Вы не участвуете в каждом микрорешении.
Так вот, суть простая. Настоящий агент отличается от «навороченного промпта» тремя признаками:
- Следование процессу. Он проходит стадии — собирает контекст, строит план, выполняет пошагово, проверяет результат, корректируется при сбое.
- Решения в неопределённости. Он умеет рассуждать в двусмысленной ситуации, а не подбирать самый вероятный шаблонный ответ. Столкнулся с неясностью — остановился, а не выдумал.
- Уточнение до выполнения. Спрашивает про аудиторию, формат, масштаб и тон — до того, как начал работать.
Последний пункт мы бы выделили жирным для себя лично. По нашим наблюдениям за роликами в нише, именно пропущенные уточнения дают львиную долю мусорных результатов. Модель неправильно поняла задачу — и честно выполнила не то.
Harness: упряжь, которая держит модель в узде
Термин harness (обвязка, упряжь) — центральный для темы. В свежих разборах он объясняется через простой образ: harness — это набор инструментов, который управляет мощной LLM, как упряжь управляет лошадью. Модель сильная, но склонна «уходить в случайные стороны». Обвязка держит курс.
Что входит в harness на практике:
- Узел ввода — точка, куда поступает запрос пользователя.
- Обращение к LLM — центральный вычислительный элемент, «мозг» агента.
- Набор инструментов — терминал, браузер, работа с файлами, вызов суб-агентов.
- Блок генерации вывода — этап, где формируется финальный ответ.
- Память — отдельная подсистема, о ней ниже большой раздел.
- Операционный слой — трассировка, логи, мониторинг запусков.
Один из материалов — это буквально одна подробная блок-схема, нарисованная от руки в браузерном инструменте виртуальной доски (Excalidraw). Схема разбита на логические зоны и описывает базовый цикл — обозначенный как AI Agent Run, то есть один прогон обработки запроса. Отдельно на ней выделена крупная зона операций (LLM Ops) с элементом трассировки (Trace).
Нам этот подход к проектированию понравился именно бытовой доступностью. Чтобы объяснить команде, как устроен ваш будущий агент для трейдинга, не нужен тяжёлый специализированный софт. Открыл доску в браузере, накидал блоки от руки — ввод, модель, память, вывод, логи — и всем всё понятно. Дёшево и наглядно.
Loop engineering: как агент решает сам
Loop engineering (инженерия рабочего цикла) — это механизм, при котором агент сам решает, какие инструменты вызывать, выполняет задачу и завершает цикл, отправив ответ. Без постоянных подсказок от человека на каждом шаге.
Разберём цикл по пунктам, как он собирается из разборов:
- Пользователь отправляет промпт.
- Промпт вместе с историей чата и системным промптом попадает в рабочую память (working memory).
- Агент обрабатывает запрос, применяя loop engineering — сам выбирает и вызывает нужные инструменты.
- По завершении задачи агент прекращает цикл (end loop) и отправляет ответ.
А вот тут важная деталь про порядок работы над агентом. Логика подачи в материалах выстроена так: сначала цикл, потом наблюдаемость. То есть сперва вы выстраиваете рабочий loop — чтобы агент вообще выполнял задачу от начала до конца — и только потом навешиваете трассировку и мониторинг для эксплуатации. Не наоборот. Мы считаем это правильной методологией. Нет смысла строить систему логирования вокруг агента, который ещё не умеет доводить задачу до конца.
Какие инструменты агент обычно держит в руках (по демонстрации живого фреймворка):
- Терминал — выполнять команды прямо на машине.
- Браузер — искать и собирать информацию в вебе.
- Делегирование задач — порождать суб-агентов, в том числе вызывать отдельный кодовый CLI для написания скриптов.
- Cron job — планировать повторяющиеся задачи без участия человека.
- Управление навыками и подключение к внешним источникам через MCP.
Для трейдера это уже почти конструктор. Cron — утренний сбор макро-новостей. Браузер — парсинг экономического календаря. Терминал — запуск вашего скрипта проверки открытых позиций. Делегирование — отдельный суб-агент, который пишет и правит код индикатора.
Память агента: три типа, и почему это главное
Здесь начинается самое интересное. Память — это то, что превращает разового отвечателя в персонального помощника, который вас помнит. В разборах память чётко делится на три типа.
Процедурная память — навыки
Отвечает за то, как действовать. Хранится в файлах навыков (формат вроде skill.md). Каждый навык — это пошаговая инструкция: как сделать конкретную вещь. Например, навык делегирования кода описывает: установить нужный CLI, авторизоваться, запустить.
Пример из живой демонстрации: пользователь попросил создать навык подготовки видео — как он форматирует сценарии (разговорный язык, пояснение жаргона по ходу текста, без длинных тире, с фирменной завершающей фразой). Агент создал соответствующий файл навыка и теперь применяет его автоматически.
Переведите это на трейдинг. Навык «разбор сделки»: открыть скрин, определить сетап по концепции SMC, проверить наличие зоны ликвидности, зафиксировать вход/стоп/тейк в журнал в заданном формате. Один раз описали — агент повторяет по шаблону.
Семантическая память — факты о вас
Хранится в файле памяти (вроде memory.md). Содержит устойчивые факты, привычки, ваш профиль. Любопытная деталь, которую мы отметили: в одном из фреймворков вместо эмбеддингов и RAG-системы используется простой текст с ключевыми словами. Никакой векторной базы — обычный markdown-файл. Автор демонстрации сам признался, что не до конца понимает причину такого выбора. Мы тоже удивились: это идёт вразрез с «канонической» архитектурой, где под память принято городить RAG.
Пример явного сохранения: пользователь попросил запомнить любимый фреймворк для тестирования — и это легло отдельным блоком в файл. Пример самостоятельного: во время задачи агент допустил ошибку со сбором данных и сам обновил память, записав особенность-quirk. То есть система итерируется и учится на собственных косяках.
Для трейдера семантическая память — это ваши правила риска. «Максимум 1% на сделку», «не торгую во время выхода NFP», «предпочитаю лондонскую сессию». Агент держит это в голове и не предлагает вам сетапы, нарушающие вашу же систему.
Эпизодическая память — история
Хранится в базе данных (вроде state.db). Это история чатов и события. Со временем старые чаты консолидируются с помощью вспомогательных, более дешёвых моделей — они суммируют переписку и извлекают факты в семантическую память. Экономно и умно: дорогая модель не перечитывает всю историю каждый раз.
Пример: пользователь спросил, что он написал агенту самым первым — и агент через поисковый инструмент нашёл в базе исходный вопрос.
Память — это то, что формирует привязанность к системе. Агент запоминает вас, со временем становится точнее, и переезжать на другой инструмент уже не хочется. В разборах это прямо называют lock-in — эффект удержания через накопленный контекст.
Локально или в облаке: вопрос приватности
Отдельная линия, которая нас зацепила. Один из фреймворков — самообучающийся агент, живущий прямо на локальной машине пользователя. Все данные — навыки, память, история — хранятся на вашем компьютере, а не в облаке. Это ключевое отличие и потенциальное преимущество для приватности.
Способы запуска гибкие: локальная командная строка, Docker, SSH или виртуальный сервер (VPS). Взаимодействовать можно двумя путями — через десктопное приложение или через привычный мессенджер, который работает как шлюз (gateway). В демонстрации использовался WhatsApp: настроил шлюз одной командой — и общаешься с агентом с телефона, а он выполняет задачи на твоей машине.
Была озвучена и логичная идея: разместить систему на виртуальной машине, чтобы работала постоянно, и рулить ею удалённо через мессенджер. Для трейдера это почти готовая схема автономного помощника — VPS не спит, cron собирает данные к открытию сессии, а вы получаете сводку в мессенджер.
Честно про ограничения. В этом локальном фреймворке нет встроенной системы LLM Ops и оценки качества (eval). Хотите отслеживать вызовы модели, число обращений, работу с памятью — стройте это сами или подключайте сторонние инструменты. Трассировка при этом есть: логи ошибок, логи запусков агента, логи шлюза. И обнаружился баг — запланированные через cron задачи не отправляли результаты автоматически, пока их явно не запросишь. Так что «поставил и забыл» пока работает не идеально.
Сборка агента без кода: файл процесса решает всё
Третий подход самый практичный для тех, кто не хочет возиться с Docker и VPS. Агенты собираются внутри десктопного приложения Claude, во встроенном рабочем пространстве (code workspace), без написания кода.
И вот главный тезис, который мы бы вытатуировали на видном месте: интеллект живёт в инструкциях, а не в технологическом стеке. Продуманный процесс с базовыми инструментами всегда обходит плохо продуманный процесс со сложными интеграциями.
Архитектура такой системы — три компонента:
- Файл рабочего процесса (workflow file) — markdown-документ, описывающий процесс: цель, шаги, правила, ожидаемый формат вывода и что делать при сбое. По сути — стандартная операционная процедура на простом человеческом языке.
- Сам агент — читает файл процесса, понимает цель и работает как проект-менеджер: решает, что делать на каждом шаге, когда спросить, когда продолжить, когда остановиться.
- Набор инструментов — чтение и создание файлов, организация папок, поиск по документам, редактирование текста. Для задач начального и среднего уровня встроенного хватает — внешние API не нужны.
Отдельно выделяется файл claude.md — его называют «онбординг-документом для вашего ИИ». Большинство проблем с агентами возникает именно потому, что этот файл пропускают. Без него агент стартует каждую сессию с нуля, качество скачет, и на исправления уходит больше времени, чем экономит агент.
Что кладут в claude.md:
- Раздел «обо мне» — кто вы, ваша аудитория, предпочитаемый тон.
- Раздел правил — например: задавать минимум три уточняющих вопроса перед сложной задачей; всегда показывать план до выполнения; не раздувать вывод сверх запрошенного; файлы называть строчными буквами через дефис.
- Структура папок — отдельно для файлов процессов, отдельно для готовых результатов, отдельно для справочных материалов.
И ещё одна вещь, которую мы считаем недооценённой — режим планирования. Правило простое: никогда не давать агенту выполнять задачу немедленно. Сначала он показывает план — как понял цель, какие шаги планирует, какие файлы создаст, какие вопросы остались. Вы одобряете — он работает. Формула из разбора: 10 минут проверки плана экономят 10 минут исправлений в конце. По факту экономит больше, потому что чинить наполовину готовый многоэтапный результат тяжелее, чем поправить план на старте.
Практика: что делать прямо сейчас
Хватит теории. Вот пошаговый план для трейдера, который хочет собрать первого рабочего агента за неделю. Мы разложили по этапам от простого к сложному.
Шаг 1. Выберите ОДИН процесс. Не пять. Один. Люди срываются, пытаясь построить исследователя, планировщик, CRM и почтового ассистента за неделю — получают пять полурабочих систем. Начните с одного и доведите до надёжности.
Хороший первый кандидат для трейдера — утренний брифинг: агент собирает экономический календарь на день, ключевые новости по вашим инструментам и выдаёт краткую сводку.
Шаг 2. Заведите рабочее пространство и файл claude.md. Опишите себя: трейдер, торгую по ICT/SMC, интересуют крипта и форекс, тон — сжатый и по делу, без воды. Пропишите правила: задавать уточнения перед сложной задачей, показывать план, не раздувать вывод.
Шаг 3. Опишите процесс простым языком. Для брифинга это выглядит так:
Роль: аналитик-ассистент трейдера
Вход: список инструментов из memory.md
Шаги:
1. Собрать события экономкалендаря на сегодня
2. Найти 3-5 ключевых новостей по инструментам
3. Отметить события высокой волатильности (красные)
4. Проверить: не совпадает ли событие с моей торговой сессией
Выход: сводка markdown, максимум 300 слов, в папку output
При сбое: остановиться и сообщить, что не удалось собрать
Шаг 4. Настройте память. В файл семантической памяти внесите свои правила риска и предпочтения: размер риска на сделку, любимые сессии, инструменты-исключения. Агент будет учитывать это в каждой задаче.
Шаг 5. Всегда через режим планирования. Первые запуски — только с показом плана и вашим одобрением. Дайте агенту раза три отработать под контролем, прежде чем отпускать в автоном.
Шаг 6. Добавьте наблюдаемость последней. Когда loop стабильно работает — подключайте трассировку и логи. Сначала цикл, потом мониторинг. Не наоборот.
Чек-лист готовности агента:
- [ ] Есть один чётко описанный процесс
- [ ] Заполнен claude.md с разделами «обо мне» и «правила»
- [ ] Прописан режим планирования
- [ ] Настроена память с вашими правилами риска
- [ ] Процесс отработал под контролем минимум 3 раза
- [ ] Добавлены логи и трассировка
Что мы заметили: где подходы сходятся, а где расходятся
Мы изучили около часа контента по теме и выделили точки согласия и расхождения.
Где все сходятся. Три момента повторяются во всех разборах без исключений:
-
Ценность в процессе, а не в стеке. Хоть визуальная схема, хоть готовый фреймворк, хоть no-code сборка — везде интеллект системы задаётся описанием процесса, а не мощью инструментов. Продуманная инструкция с базовыми возможностями бьёт навороченный стек с плохой логикой.
-
Память — сердце агента. Разделение на процедурную (навыки), семантическую (факты) и эпизодическую (история) встречается последовательно. И везде подчёркивается: именно память превращает разового отвечателя в помощника, который вас знает.
-
Порядок «сначала loop, потом наблюдаемость». Сперва рабочий цикл, потом трассировка и логи. Это методологический консенсус.
Где подходы расходятся. А вот тут интереснее.
Подход А — локальный автономный фреймворк. Ставка на приватность и самообучение. Всё крутится на вашей машине, агент сам создаёт навыки и обновляет память, учится на ошибках. Плюсы: данные никуда не утекают, работает автономно на VPS, персонализация растёт сама. Минусы: нет встроенного eval, обнаружены баги (тот же cron), требует технической возни с установкой. И честное наблюдение из самого разбора: несмотря на модные термины, по сути это добротная стандартная реализация harness, во многом дублирующая уже известные кодовые ассистенты. Уникальное отличие — локальное самообновление.
Подход Б — no-code сборка в десктопном приложении. Ставка на доступность. Никакого кода, никакого Docker — открыл приложение, написал файл процесса на человеческом языке. Плюсы: порог входа минимальный, накопительный эффект от постоянного рабочего пространства, быстрый результат. Минусы: вы работаете внутри одной экосистемы, память и автономность скромнее, чем у полноценного локального фреймворка.
Расхождение в реализации памяти. Отдельно отметим техническую развилку. Один подход использует простой текст с ключевыми словами вместо векторной базы и RAG — сознательно отказавшись от «канонической» архитектуры. Это спорное решение, и даже в самом разборе прозвучало недоумение по поводу такого выбора. Более консервативный взгляд предполагает RAG для семантической памяти. Практика показывает: для небольших личных агентов простой текст может работать не хуже, а поддерживать его проще. Для больших объёмов знаний — вопрос открытый.
Наш вывод по развилке. Если вы техничны и цените приватность — смотрите в сторону локального автономного подхода, но будьте готовы допиливать eval и ловить баги. Если хотите быстрый результат без возни — начинайте с no-code сборки, соберите один надёжный процесс, а масштабирование придёт позже.
Куда это ведёт и с чего начать завтра
Способность агентов не открывается сразу — её выстраивают постепенно, по одному надёжному процессу за раз. Сначала один рабочий процесс. Потом итеративные, где агент делает черновик и дорабатывает его за несколько раундов. Затем — мультипроцессные системы, где один агент запускает другой: аналитик собрал сводку по рынку, а второй агент читает её и готовит идеи сетапов. Это уже конвейер, и строить его не так страшно, как кажется, если отдельные звенья отлажены.
Прозвучала мысль, которая нам близка: если вы соберёте хотя бы одного рабочего агента за неделю — вы уже опередите большинство людей, которые про агентов только говорят. Так вот, наш совет предельно конкретный. Не читайте ещё десять статей про AI-агентов. Откройте рабочее пространство сегодня вечером, опишите один процесс — тот самый утренний брифинг — заполните claude.md со своими правилами риска и запустите его в режиме планирования. Один процесс, доведённый до надёжности, стоит больше, чем сто закладок «прочитать потом». А когда он заработает — возвращайтесь, будем разбирать связку агентов в конвейер под задачи трейдинга.