Первый день обучения локальный агент решил задачу Valid Parentheses.
Время выполнения — 15 миллисекунд.
Количество вызовов языковой модели — ноль.
На первый взгляд это выглядит странно. Ведь сегодня практически любая система на базе ИИ отправляет запрос в LLM даже для относительно простых задач. Но в данном случае никакой генерации не происходило.
Это не кэширование готовых ответов и не заранее зашитые шаблоны.
Решение вернула нейро-символьная архитектура, которая постепенно накапливает опыт, выделяет устойчивые паттерны и использует их повторно без обращения к модели.
Самое интересное, что всё это работает локально на обычном компьютере с RTX 5060 (8 ГБ видеопамяти), 16 ГБ оперативной памяти и единственной языковой моделью — qwen2.5-coder:7b.
Пока индустрия соревнуется в количестве параметров и размерах контекстных окон, я решил проверить другую гипотезу: можно ли сделать агента умнее не за счёт новых моделей, а за счёт правильной организации памяти и детерминированной верификации?
Как агент решает задачу без обращения к модели
Ключевой компонент системы называется Symbolic Cache.
Когда агент сталкивается с новой задачей, решение действительно генерируется моделью qwen2.5-coder:7b.
Но после успешного выполнения сохраняется не просто ответ.
Система фиксирует весь путь решения, результаты проверки и связанные паттерны.
Со временем из множества трейсов выделяются устойчивые структуры.
Если аналогичная задача встречается повторно, агент уже не обращается к модели. Он извлекает проверенный паттерн из Symbolic Cache и возвращает результат мгновенно.
Именно поэтому задача Valid Parentheses была решена без единого вызова LLM.
Для системы это уже не задача генерации, а задача извлечения ранее подтверждённого знания.
Почему я отказался от проверки второй моделью
На ранних этапах экспериментов использовалась классическая схема cross-validation через вторую языковую модель.
На бумаге идея выглядит разумно: одна модель генерирует решение, другая проверяет.
На практике возникают проблемы.
Вторая модель тоже может ошибаться.
Она тоже способна галлюцинировать.
А главное — такая схема увеличивает задержки и потребляет дополнительные ресурсы.
Поэтому в системе появился ValidatorNano.
Его задача проста: проверить код не мнением другой модели, а фактическим результатом выполнения.
Каждое решение запускается в изолированной среде и проходит набор тестов.
Если программа завершается успешно и выдаёт ожидаемый результат, решение считается валидным.
Если хотя бы один тест не проходит, навык отклоняется.
Фактически проверка сводится к детерминированному условию:
«Код выполнился без ошибок и выдал правильный результат».
Такой подход исключает спор двух моделей и заменяет его объективной проверкой.
Как опыт превращается в знания
Каждое действие агента сохраняется в журнал трейсов.
Там фиксируются успешные решения, ошибки, выбранные инструменты и результаты верификации.
Со временем объём таких данных становится достаточно большим для анализа.
Периодически запускается процедура консолидации.
Алгоритм анализирует накопленные трейсы и выделяет повторяющиеся паттерны через комбинацию TF-IDF и механизма временного затухания значимости.
Успешные стратегии получают больший вес.
Неэффективные постепенно теряют приоритет.
В результате из нескольких похожих решений формируется единый устойчивый паттерн.
В случае с Valid Parentheses система проанализировала последние трейсы, выделила наиболее стабильный способ решения и сохранила его в Symbolic Cache.
После этого задача начала решаться мгновенно.
Важно понимать: это не fine-tuning.
Модель не переобучается.
Новые веса не создаются.
Вся работа выполняется на уровне символического обобщения накопленного опыта.
Именно поэтому консолидация занимает секунды и практически не требует вычислительных ресурсов.
Почему ошибки ценнее успешных запусков
Обычно журналы ошибок используются только для отладки.
После исправления проблемы о них быстро забывают.
В моей системе ошибки становятся частью памяти агента.
Каждый сбой сохраняется как отдельный Negative Skill.
В него входят:
– исходная задача;
– текст ошибки;
– используемая модель;
– количество RAG-фрагментов;
– контекст выполнения;
– причина отказа.
Таким образом агент запоминает не только успешные стратегии, но и неудачные.
Через некоторое время становится заметно, что система начинает избегать заведомо проблемных решений ещё до запуска генерации.
Ошибка перестаёт быть мусором в логах.
Она превращается в источник знаний.
Что помогает анализировать поведение агента
Когда система становится сложнее, одного просмотра логов уже недостаточно.
Важно понимать не только факт ошибки, но и её причины.
Поэтому трейсы автоматически группируются по типам отказов.
Это позволяет выявлять повторяющиеся проблемы, слабые места промптов и неэффективные стратегии решения.
Подобный подход используется в современных инструментах анализа агентных систем, например в LangSmith, где основное внимание уделяется поиску устойчивых failure patterns и анализу траекторий выполнения.
Дополнительно агент активно использует файловую систему как внешний контекст.
Большие результаты сохраняются в файлы и при необходимости читаются обратно.
Такой механизм позволяет обходить ограничения контекстного окна и сохранять стабильность работы даже при длинных цепочках рассуждений.
Похожий подход применяется и в Deep Agents SDK, где файлы выступают частью долговременного рабочего пространства агента.
Вместо вывода
Этот эксперимент привёл меня к неожиданному выводу.
Чем дальше развивается система, тем меньше роль самой языковой модели.
LLM остаётся важным инструментом генерации, но интеллект всё чаще возникает вокруг неё.
Память.
Верификация.
Консолидация опыта.
Анализ ошибок.
Все эти механизмы работают детерминированно и не требуют миллиардов дополнительных параметров.
Поэтому будущее агентных систем я вижу не только в более крупных моделях.
Не менее важную роль будут играть нейро-символьные архитектуры, которые умеют накапливать опыт, проверять собственные решения и постепенно снижать зависимость от генеративных моделей.
Именно благодаря этому локальный агент на обычном домашнем ПК смог решить задачу за 15 миллисекунд и без единого обращения к LLM.