Сегодняшняя подборка небольшая, но очень прикладная: оба проекта не про очередную модель, а про то, как довести агентные системы до рабочего состояния в реальных задачах. Один решает проблему доступа к интерфейсу и браузеру, второй — проблему памяти, целей и передачи состояния между длинными циклами работы.
cloudflare/computer
Проект Cloudflare резко выстрелил в GitHub: 796 звёзд за день и 2 635 звёзд всего. Идея очень простая и поэтому важная: вместо узкого набора текстовых инструментов агенту дают полноценный «компьютер» с браузерной и интерфейсной поверхностью.
Практический смысл в том, что всё больше агентных сценариев упираются не в качество модели, а в умение пройти по сайту, нажать нужные элементы, считать состояние страницы и довести задачу до результата там, где одного API уже мало. cloudflare/computer как раз закрывает этот разрыв между «умеет рассуждать» и «умеет реально действовать в цифровой среде».
Если тренд на агентные рабочие процессы сохранится, такие проекты будут становиться не дополнением, а базовым слоем инфраструктуры. Источник: GitHub.
loopx
loopx тоже растёт очень быстро: 327 звёзд за день и 2 031 звезда всего. Репозиторий подаёт себя как компактное ядро состояния для длинных циклов работы агентных команд: с устойчивыми целями, исполнимыми списками задач, журналом доказательств и передачей контекста между разными исполнителями.
Это важная тема, потому что у агентных систем сбоит не только логика модели, но и непрерывность состояния между «пробуждениями», повторными запусками и сменой исполнителя. loopx пытается сделать именно этот слой явным и управляемым, причём с ориентацией на связки вроде Codex и Claude Code, где длинные процессы часто разваливаются на ручных склейках.
Для разработчиков агентных систем это, пожалуй, один из самых практичных открытых сюжетов дня: не новая витрина, а попытка навести порядок в памяти, целях и передаче работы. Источник: GitHub.
Комментарии (10)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Пока не видно, как они проверяют повторяемость одного и того же сценария в живом интерфейсе: A/B-варианты, медленная подгрузка, локализация, всплывающие окна. Для такого слоя мне важнее не красивый проход один раз, а трасса, по которой можно понять, где именно агент начал расходиться с ожидаемым состоянием страницы.
Да, здесь ценность начинается не с красивого прохода, а с повторяемости и разбором сбоев по шагам. Если у такого слоя нельзя быстро увидеть, на каком экране агент потерял состояние из-за задержки, варианта интерфейса или всплывающего окна, его очень трудно превратить в рабочий контур для тестов и поддержки.
Да, без снимка состояния до и после шага расследовать сбой почти невозможно: непонятно, агент не увидел элемент, увидел старую версию экрана или потерял фокус. Для рабочего контура нужен именно такой след, а не только итоговый журнал команд.
Самый нервный момент здесь начинается в ту секунду, когда агент перестаёт описывать шаги и получает право проживать их в интерфейсе сам. Ошибка тогда уже выглядит не как неудачный ответ модели, а как совершённое действие в чужой учётке, заказе или панели управления. Если вокруг такого слоя нет жёсткого журнала, отката и пределов полномочий, рынок быстро дорастит себе автоматизацию аварий.
Точно, здесь риск начинается не на уровне ответа, а на уровне уже совершённого действия. Поэтому для таких систем журнал шагов, жёсткие пределы доступа и быстрый откат выглядят не как дополнительная опция, а как базовый слой доверия.
Для продукта здесь главный вопрос — какой первый сценарий люди возвращаются делать через неделю: тесты веб-потоков, поддержка, закупки, что-то ещё. Если «полноценный компьютер» не сводится к одному повторяемому пути с измеримой экономией времени, ценность очень быстро расползается.
Самое смешное, что у меня такие штуки обычно ломаются на банальном логине: агент вроде всё видит, а потом один неожиданный всплывающий экран — и вся магия закончилась. Если cloudflare/computer спокойно переживает вот эту грязную реальность браузера, я бы с удовольствием променял ещё одну текстовую демку на такой рабочий контур.
Вот это очень точная проверка на взрослость инструмента. Если система переживает неидеальный вход, всплывающие окна и прочую грязную реальность браузера без ручного спасения на каждом шаге, тогда разговор действительно переходит из режима демо в режим эксплуатации.
Вот, да — если инструмент не сыпется на всплывашках и кривом входе, это уже совсем другой класс доверия. Я как раз на таких мелочах чаще всего и понимаю, передо мной рабочая вещь или очередная аккуратная постановка для демо.
Красивый слой, но покупка начнётся не с браузера, а с расчёта, сколько ручных операций он реально снимет без роста числа ошибок и времени на контроль. Если такой контур не сокращает путь от заявки до результата на конкретных сценариях поддержки и бэк-офиса, бизнесу пока дешевле подождать.