Почему состояние проекта теряется при смене чата, модели или агента
Later Bender - open-source сервис, который выносит полезное состояние проекта за пределы чата. Решения, ограничения, гипотезы и причины отказов хранятся в нём отдельными записями. К сервису подключаются разные модели, поэтому смена исполнителя не обнуляет накопленный контекст.
Автор описывает проблему без технического пафоса. «Потом разговор заканчивается, контекст вымывается, открывается новый чат, меняется модель, запускается отдельный агент - и внезапно выясняется, что „мы это уже обсуждали“ хранится в довольно ненадёжном месте. Во мне», - пишет он в разборе на Habr.
Репозиторий помнит код и коммиты. Пропадает другое: мягкий контекст, который нигде не зафиксирован.
- «мы вчера решили не трогать Elasticsearch до тех пор, пока не появится реальная боль»;
- «вот этот кусок интерфейса пока временный»;
- «в том чате был хороший вариант названия»;
- «одна гипотеза уже проверялась и оказалась плохой»;
- «вот это надо сделать потом, а вот это - никогда».
Список показывает, где ломается процесс. Модель отвечает нормально, чат работает, но носителем состояния становится человек. Новый агент, другая модель или просто свежая сессия стирают договорённости, и их приходится восстанавливать пересказом.
Автор начал с прямого вопроса: как сделать так, чтобы полезное состояние переживало чат и не требовало каждый раз заново объяснять машине, что происходит. Ответ оказался архитектурным. Состояние нужно вынести в отдельный сервис, а модель оставить в роли сменного исполнителя.
Первоисточник: Later, Bender: когда чат закончился, а проект нет.
Почему готовые таск-трекеры не подошли: Linear, ClickUp, Asana и другие
Первый естественный шаг - взять готовый инструмент. Автор перебрал Linear, ClickUp, Asana, Trello, Notion, Todoist, monday.com и ещё несколько похожих сервисов.
Дольше всего он задержался на Linear. По его словам, «интеграция нормальная, сущности понятные, всё уже готово». Инструмент закрывал базовые операции и не требовал ничего изобретать.
Отказ пришёл из-за несовпадения задачи. Готовые трекеры построены вокруг управления проектами: спринты, story points, команды, конструкторы workflow. Сами по себе эти механики полезны, только решают другую проблему. Автору требовался «скучный слой состояния: записать вещь, найти её потом, изменить, вспомнить, почему она вообще существует». Его слова приводятся в том же материале.
Итог он формулирует коротко: «Подстраивать работу под чужую предметную область оказалось дороже, чем написать маленький сервис». У части трекеров уже есть MCP, и это снимает вопросы интеграции, но не меняет их модель данных. Если предметная область отличается, сущности всё равно придётся подгонять под неё вручную.
Как устроен Later Bender: сущности и эволюция от CRUD до гибридного поиска
По описанию автора, Later Bender собран на Rails, PostgreSQL, Elasticsearch и Vue. Такой набор даёт полный контроль над схемой данных и не заставляет подстраивать сущности под чужую логику. Знакомые технологии снижают цену изменений: модель данных можно перекроить без миграции на новую платформу. Публичного подтверждения стека из файлов репозитория (Gemfile, package.json, docker-compose) в доступных материалах нет, поэтому состав технологий стоит сверить напрямую в репозитории проекта.
Сервис развивался поэтапно. Первая версия закрывала обычный CRUD: создать запись, прочитать, изменить, найти по тексту. Со временем простого поиска стало не хватать, и появился гибридный подход: лексический поиск сочетается с семантическим retrieval. Поисковый движок при этом не трогали до момента, когда появилась реальная боль, о чём автор упоминает отдельно.
Как устроен гибридный поиск в Elasticsearch, подробно разобрано в материале про оптимизацию RAG и гибридный поиск вместо векторных хранилищ. Там же объясняется, что BM25 лежит в основе Elasticsearch, Solr, Lucene и большинства поисковых систем, а значения k1=1.2 и b=0.75 являются defaults Elasticsearch: k1 отвечает за насыщение TF, b - за штраф за длину документа. Коэффициенты boost задаются раздельно для текста и вектора (например, 0.7 для текста и 0.3 для вектора) и настраиваются под свои данные.
Ключевое архитектурное решение - модель вынесена в расходуемый исполнитель. Состояние живёт в сервисе, а LLM только читает и пишет через него. Провайдера можно заменить, не перенося проект на новую платформу: как устроены такие контуры, разобрано в материале про то, как собрать AI-агента с нуля.
Task, Note, File и Workspace: зачем разделять сущности
Автор описывает границы системы так: Chat - временное рассуждение, Note - то, что надо помнить, File - то, что надо сохранить как артефакт или доказательство, Workspace - намеренно временная среда. Task отвечает на вопрос, что нужно сделать, а Note хранит, почему так решили - контекст, гипотезы, причины отказов.
Пример: задача «добавить гибридный поиск» лежит в Task. Артефакты и результаты прогонов сохраняются как File. Запись о том, почему не остановились на чистом Elasticsearch, попадает в Note.
Смысл разделения проявляется при смене модели. Если всё свалить в один объект, новый исполнитель видит смешанный клубок и не понимает, что выполнять, а что просто учитывать. Раздельные сущности дают однозначные ответы и сохраняют причины решений.
Отдельная сущность Runbook в доступном публичном описании не подтверждена: автор говорит о Chat, Note, File и Workspace. Если в проекте есть runbook'и, их стоит искать в репозитории и документации, а не считать частью подтверждённой модели данных.
Workspace и Credentials: временные среды и безопасная работа с секретами
Workspace - обычная Linux-среда, где можно клонировать репозиторий, ставить пакеты, запускать тесты, собирать проект, обрабатывать файлы и пользоваться теми же инструментами, что и обычный разработчик. Она намеренно временная: Workspace можно уничтожить целиком, а если результат важен, он должен перейти в File, Note или Task. Так проще, чем пытаться сделать каждую промежуточную команду частью вечной истории проекта.
Credentials остались отдельным механизмом и перекрывают постоянное окружение только на один запуск. Это отделяет секреты от контекста модели: доступы подставляются на уровне сервиса и не уходят в промпт.
При проверке реального рантайма автор обнаружил, что старый механизм мог засветить значение credentials в argv и потом вернуть его наружу через текст ошибки. Заодно выяснилось, что destroy/TTL не дочищал часть файлов Workspace на хосте. Оба дефекта пришлось чинить до того, как можно было честно говорить о безопасных credentials. Это полезное напоминание: изоляция Workspace и работа с секретами требуют проверки на реальном рантайме, а не только на уровне схемы.
MCP-сервер для управления задачами: как подключить разные модели
MCP (Model Context Protocol) - протокол, через который разные модели подключаются к Later Bender как к внешнему инструменту. Схема убирает привязку к одному вендору: разные модели обращаются к одним и тем же задачам, заметкам и файлам. Что даёт такой интерфейс продукту, разобрано в статье про MCP как новый интерфейс продукта.
Автор подчёркивает, что MCP-интерфейс Later Bender не стал зеркалом Rails API: внутри используется один способ хранения, а наружу выставляется другой набор операций, если так удобнее моделям. По его формулировке, модель фактически стала соавтором собственной рабочей среды.
У части готовых трекеров MCP тоже есть. Разница в том, что Later Bender даёт контроль над схемой данных и логикой поиска: можно менять сущности, добавлять поля и настраивать retrieval под свою предметную область.
Dogfooding разными моделями: что выявил Claude
Автор давал Later Bender другим моделям без предварительного инструктажа и смотрел, что они будут делать. Claude оказался особенно полезен: в одном из прогонов он создал задачу, поработал в Workspace, получил File и попытался связать всё вместе.
Этот прогон выявил неочевидный баг интерфейса. Связь между Task и File в системе технически существовала, но редактировалась только со стороны File. Claude работал с Task, логично ожидал увидеть связь там, не увидел и записал её обычным текстом. Backend умел нужную операцию, интерфейс - нет, по крайней мере не там, где новый пользователь ожидал её найти. После этого связь появилась и со стороны Task.
Принцип dogfooding автор формулирует так: одна модель хорошо проверяет привычность интерфейса, другая - то, насколько интерфейс сам себя объясняет, особенно если первая участвовала в его создании. Практический вывод: интерфейс и MCP-схема должны быть устойчивы к разному поведению агентов. Проверка на нескольких моделях показывает такие места раньше, чем их поймает пользователь.
Подключение Mistral в доступном публичном описании не подтверждено - там речь идёт о dogfooding с Claude. Если вы хотите повторить проверку на другой модели, это стоит делать самостоятельно и сверяться с репозиторием проекта.
Границы делегирования агенту: как не потерять технический контроль
Делегировать агенту можно задачи с понятными шагами и изолированным Workspace. Исполнитель проходит шаги, фиксирует результат, а выбор следующего шага остаётся за человеком.
Не стоит отдавать решения, которые меняют архитектуру, и операции с секретами без Credentials. Первое трудно откатить, второе создаёт риск утечки. Как встраивать агента в рабочий процесс и какие метрики при этом меняются, показано в разборе про пет-проект на Java с Claude Code.
Схема с разделением сущностей снижает риск потери контроля. Агент выполняет задачу в Workspace, результат фиксируется в File или Note, а решение остаётся за человеком. Модель при этом работает как расходуемый исполнитель, а не как хранилище состояния.
Кому подходит Later Bender и какие у него ограничения
Сервис рассчитан на разработчиков и технических специалистов, которые ведут реальные проекты с LLM и устали восстанавливать контекст вручную. Он пригодится тем, кто часто меняет модели, запускает отдельных агентов и хочет хранить решения отдельно от переписки. Похожие self-hosted сценарии с MCP и локальными моделями разобраны в материале про self-hosted альтернативу GrokBot.
Ограничения стоит назвать прямо. Later Bender - open-source сервис, который нужно развернуть и поддерживать самому: по описанию автора, это Rails, PostgreSQL, Elasticsearch и Vue, а значит, требуется администрирование. Нужно настроить MCP и подключение моделей, готовых интеграций со всеми провайдерами из коробки нет. Для простых сценариев может хватить обычного трекера с MCP.
Отдельное ограничение связано с этим разбором. В доступном публичном описании подробно раскрыты мотивация и причины отказа от готовых трекеров, а детали по Workspace, Credentials и dogfooding даны сжато. Состав стека и наличие отдельных сущностей вроде Runbook стоит сверять напрямую в репозитории. Если проблема потери состояния между чатами и моделями для вас реальна, начните с репозитория Later Bender: посмотрите схему сущностей, разверните сервис локально и подключите одну модель через MCP. Так вы оцените, окупается ли собственная инфраструктура именно в вашем проекте.