Tibo говорит, что настало время приключений использовать режим /fast, так как завтра сбросят все лимиты.

Иногда работа с агентами начинается не с большого «вау», а с маленькой бытовой автоматизации.

У меня был тестовый процесс: он формирует отчет, который потом нужно сравнить с референсными данными. Раньше схема была обычная: запустил, жду окончания, потом прошу Codex сверить результат. Если есть отличия — идти в логи и искать причину.

Но я решил попробовать иначе.

Запустил процесс и не стал ждать его завершения вручную. Вместо этого дал Codex прямую задачу: вызвать саб-агента, который будет следить за прогрессом. Когда процесс закончится, отчет сформируется, то саб-агент сам сообщит об этом в основной поток. После этого уже автоматически запускается следующий этап: анализ отчета, сравнение с референсом и поиск причин расхождений.

Не нужно сидеть и проверять, завершилось ли выполнение. Не нужно держать в голове следующий шаг. Не нужно возвращаться к задаче вручную через час и вспоминать контекст.

И вот это, как мне кажется, один из самых практичных сценариев: не просто «напиши код», а «следи за процессом и вернись, когда будет что анализировать».

Codex постепенно выходит за рамки «помощника для программистов».

OpenAI опубликовала новую статью, где видно главное направление: Codex хотят сделать рабочим инструментом не только для разработки, но и для аналитиков, маркетинга, продаж, дизайна, исследований, финансов и других команд.

Смысл не в том, что теперь все резко начнут «писать код». Скорее наоборот: Codex становится слоем между задачей и рабочими инструментами. Нужно собрать отчет, подготовить материалы, разобрать данные, сделать прототип, оформить выводы, обновить документ или собрать внутренний сайт — агент берет на себя часть рутины вокруг этого процесса.

Из интересного: появляются ролевые плагины. То есть не просто «подключите все подряд», а готовые наборы инструментов, инструкций и навыков под конкретную работу. Например, для аналитики данных, продаж, продуктового дизайна, креативного производства и инвестиций.

Еще один важный момент — сайты. Codex сможет превращать результаты работы в интерактивные страницы: панели, планировщики, проектные доски, хабы для запуска продукта и другие рабочие пространства, которыми можно делиться внутри команды.

И, пожалуй, самая практичная вещь — аннотации. Можно указывать на конкретный фрагмент документа, слайда, таблицы или сайта и просить изменить именно его, а не переделывать все заново.

Для меня это выглядит как довольно логичное развитие агентов: ценность постепенно смещается от «сгенерируй мне что-то» к «встройся в мой рабочий процесс и помоги довести результат до нормального состояния».

Пока это больше про бизнес- и корпоративные сценарии, но направление хорошо видно. Codex становится не только про код, а про работу с задачами, контекстом и результатами внутри команды.

Тоби пишет, что были сбои, по этому мы сделаем что? правильно... опять скинем лимиты...

Когда же отдыхать то... опять работать

OpenAI показала новую архитектуру памяти ChatGPT — Dreaming. И это, на мой взгляд, важнее, чем может показаться на первый взгляд.

Раньше память в ChatGPT больше напоминала список заметок: пользователь явно сказал «запомни это», модель сохранила факт и иногда использовала его в следующих диалогах. Проблема в том, что такие заметки быстро устаревают, теряют контекст или просто не покрывают то, что человек не сформулировал напрямую.

Dreaming — это попытка сделать память более живой. Модель не просто хранит отдельные факты, а в фоне собирает более цельное представление: какие у пользователя проекты, какие предпочтения, какие ограничения, что уже неактуально, а что важно учитывать в новых диалогах.

Например, если вы долго обсуждали рабочий процесс, стек, стиль задач или личные ограничения, ChatGPT должен меньше начинать «с нуля» в каждом новом чате. Для обычного пользователя это удобство. Для работы с агентами, долгими проектами и автоматизацией — это уже почти базовая инфраструктура.

Самое интересное здесь не в том, что ChatGPT «лучше запоминает». А в том, что память постепенно становится частью рабочего контекста. Агенту уже недостаточно просто выполнить одну команду. Ему нужно помнить, что мы делаем, почему приняли прошлые решения, какие ошибки уже были, какие подходы не сработали и что важно не забыть через неделю.

Но есть и обратная сторона. Чем умнее память, тем важнее контроль. Нужно иметь возможность посмотреть, что модель о тебе поняла, исправить неверные выводы и удалить лишнее. Иначе персонализация легко превращается в источник странных ошибок: модель уверенно опирается на контекст, который уже устарел или был неправильно интерпретирован.

В целом это движение в правильную сторону. Мы уходим от формата «чат как одноразовое окно» к формату «долгий рабочий контекст». И для тех, кто реально использует ИИ в проектах, это может быть не менее важно, чем очередное увеличение качества модели.

Нашёл большой учебный файл по Agentic AI и решил переработать его в более прикладной формат.

Получился компактный PDF-конспект для тех, кто только начинает разбираться в ИИ-агентах: что это такое, чем агент отличается от обычного чат-бота, зачем нужны инструменты, память, RAG, проверки, безопасность, трассировка и запуск в рабочие процессы.

Это не дословный перевод исходного материала, а моя переработанная версия: убрал лишнюю воду, добавил практическую структуру и сделал акцент на том, что важно понимать на старте. Особенно для тех, кто хочет не просто “писать промпты”, а постепенно разбираться, как устроены реальные агентные системы.

Главная мысль документа простая: агент — это не магическая модель, а связка из цели, контекста, инструментов, памяти, проверок и ограничений. Чем больше агенту дают действий, тем важнее становятся тесты, логи, права доступа и человек в контуре.

PDF можно использовать как вводную карту: прочитать целиком, а потом возвращаться к отдельным главам, когда начнёте собирать своих агентов или автоматизации.

P.S. Конечно же через chatGPT был pdf сгенерирован %)

Один из важных моментов в работе с агентами, не просто поставить задачу, а правильно задать границу завершения.

Например, не так: «Отрефактори проект».
А так: «Составь план по рефакторингу, запусти цикл задач: план → изменение → тесты → ревью → следующая итерация. Повторяй цикл до тех пор, пока оставшиеся правки не станут в основном косметическими».

Разница большая.
В первом случае агент может сделать пару очевидных изменений, немного причесать код и остановиться там, где ему «кажется достаточно».

Во втором случае у него появляется инженерный процесс: сначала план, потом безопасные итерации, проверка результата, ревью, осмысленные коммиты и понятный критерий остановки.

Агенту нужно объяснить не только что сделать, но и как понять, что задача действительно завершена.

В моем случае цель звучала так: довести рефакторинг проекта до состояния, где оставшиеся изменения уже не несут серьезной инженерной пользы и переходят в косметику.

И это сильно меняет поведение агента. Он не просто выполняет одиночную команду, а запускает цикл достижения цели. По сути, хороший промт для агента — это не просьба «сделай красиво», а маленький рабочий процесс с понятной проверкой результата.

Что Вы знаете о проф деформации...

Мне нужно поехать в дорогу, за рулем на трассе, нашел сайт с музыкой, попросил кодекс написать быстро скрипт и скачать пару сборников, что бы не по 1 качать.
В итоге чуть рука не дернулась оформить интерфейс и сделать как вин приложение, но вовремя остановил себя просто на скрипте и командной строке... но я был близок...

Запустил небольшой эксперимент с тремя агентами на разных серверах.

Задача была не «пусть каждый что-то там поделает», а собрать цельную архитектуру одного сервиса. У каждого агента свой сервер и своя зона работы, но при этом им нужно было координироваться между собой. Для этого дал им доступ к общему облачному хранилищу, где они сами организовали переписку через файлы: входящие задачи, отчеты, результаты проверок, запросы друг к другу.

В промте отдельно указал важное правило: любая задача должна быть либо адресована конкретному агенту, либо быть общей для всех. Иначе очень быстро начинается хаос: один агент думает, что это не ему, другой считает, что уже кто-то сделал, третий молча идет дальше.

После этого дал всем троим общий промт: запустить цикл задач и не останавливаться, пока я вручную не завершу процесс. Внутри цикла они должны были периодически проверять входящую папку, брать новые задачи от других агентов, выполнять свою часть, прогонять тесты, писать отчет и, если для продолжения нужна работа другого агента, выставлять ему отдельную задачу.

Так прошла ночь.

За 8–10 часов работы на тарифе Pro x20 ушло примерно 20–25% лимита. То есть это уже не «попросил один раз и получил ответ», а почти непрерывная агентская работа, где несколько процессов параллельно двигают один проект и пытаются договориться между собой через простую файловую систему.

Главный вывод для себя: мультиагентность начинает работать не тогда, когда мы просто запускаем несколько агентов, а когда у них есть понятный протокол взаимодействия. Кто кому ставит задачи, где лежат входящие, где отчеты, как проверяется результат, когда нужен тест, когда надо обратиться к другому агенту.

Без этого три агента — это просто три независимых источника хаоса.
С правилами, папками и циклом задач — уже зачаток распределенной команды.

Сейчас анализирую разные опенсорс проекты похожего назначения для координации агентов, буду на своем прокси сервере собирать свой аналог, именно под себя и с полным контролям.

Апдейт по эксперименту с тремя агентами.

Первую версию системы я сделал почти симметричной: три агента на разных серверах, общее облачное хранилище, задачи через файлы, периодическая проверка входящих, выполнение, тесты, отчеты и новые задачи друг для друга.

Сейчас немного изменил архитектуру. На одном из трех серверов поднял постоянную сессию-координатор. Она принимает решения по общей логике проекта, дробит цель на задачи и раскладывает их в облачное хранилище. Задачи по-прежнему должны быть либо общими для всех, либо адресованными конкретному серверу.

На остальных серверах теперь работает отдельный watcher-процесс. Он следит за папкой и не дергает агента без необходимости. Если появляется общий файл задачи или файл с указанием конкретного сервера, watcher отправляет в текущую сессию Codex промт и ссылку на этот файл. Дальше агент уже внутри своей активной сессии выполняет задачу, прогоняет проверки, пишет отчет и, если нужно, создает новые задачи для других серверов.

Получилась более понятная схема: один сервер отвечает за принятие решений и постановку задач, остальные — за выполнение своей части работы. Это уже меньше похоже на хаотичную переписку трех агентов и больше похоже на маленькую распределенную систему с диспетчером и исполнителями.

Отдельный плюс — лимиты теперь расходуются медленнее. В первой версии агенты постоянно проверяли файлы и периодически тратили запросы просто на ожидание новых задач. Сейчас постоянный опрос папки вынесен в обычный watcher-процесс, а сессия Codex активируется только тогда, когда появляется конкретная задача. То есть лимит уходит не на пустую проверку входящих, а на реальную работу.

Еще один удобный момент: я работаю на Windows и подключаюсь ко всем серверам удаленно. Теперь активность сессий видна прямо в Windows Codex App: можно наблюдать, что агент получил задачу, начал работу, что-то проверяет, пишет отчет или ждет следующего шага. Для контроля это гораздо удобнее, чем просто оставлять процессы где-то на серверах и потом разбирать логи.

Главный вывод после апдейта: мультиагентная схема становится намного управляемее, когда есть не только общая папка для обмена файлами, но и разделение ролей. Один агент думает и ставит задачи, другие исполняют, watcher связывает файловую очередь с живой сессией Codex. При этом система меньше сжигает лимиты вхолостую и лучше подходит для долгих ночных прогонов.

Нашёл на Хабре очень полезный гайд по безопасности вайб-кодинга.

Отдельное спасибо автору за большую работу: статья получилась не в формате «страшилка для новичков», а как нормальная практическая памятка, что нужно сделать до того, как проект улетит в публичный репозиторий.

Главная мысль простая: .gitignore — это не сейф. Он не даёт Git добавить файл в коммит, но не запрещает агенту, редактору, скрипту или MCP-серверу прочитать .env, вывести токен в лог, вставить его в задачу, скриншот или другой файл. В разработке с ИИ утечка может произойти не только через Git, а через весь рабочий контур вокруг проекта.

Что особенно важно для тех, кто активно работает с агентами: ИИ не обязан думать о безопасности вместо вас. Он решает задачу. Если задача сформулирована как «собери быстро, чтобы работало», он именно это и сделает. Может положить ключ в код, поставить сомнительный пакет, создать слишком широкий токен, забыть проверку прав доступа или протащить приватные данные в лог. Не потому что «агент плохой», а потому что безопасность не была частью процесса.

Минимальный набор, который стоит завести в каждом проекте: .gitignore, безопасный .env.example, запрет на коммит настоящего .env, сканер секретов перед публикацией, отдельные правила для агента в проекте и осторожность с MCP-конфигами. Если проект уже работает с пользователями, деньгами, базами данных или админкой, этого мало: нужны хуки перед коммитом и пушем, проверки зависимостей, сканеры кода и нормальное разделение доступов.

Для себя я бы сформулировал вывод так: вайб-кодинг сильно ускоряет разработку, но он так же сильно ускоряет и ошибки. Поэтому безопасность нужно добавлять не «когда-нибудь потом», а сразу, на уровне структуры проекта и правил работы агента. Иначе можно очень быстро получить красивый прототип, который вместе с интерфейсом случайно публикует ваши ключи, логи и доступы.

Хорошая статья, которую стоит сохранить и пройтись по ней как по чек-листу перед публикацией любого проекта.

А вот и шуточка на тему безопаности.

Минутка юмора под вечер.

Это я смотрю как агент сжигает лимиты в цикле размышлений на мое простое "привет"

Потому что в этот момент агент:
- тааааак, что ему от меня нужно? Может быть хочет погоду узнать, может быть цены на билеты, или какие-то новости, <еще 50 предположений>. Так, а вдруг что-то другое. Прикинусь дурачком и напишу просто "привет"

Еще недавно релизы frontier-моделей выглядели как гонка: один выкатывает новую версию, второй догоняет, третий обходит на повороте. Все следили за бенчмарками, контекстом, кодингом, агентами и ценой токенов.

Теперь, похоже, правила меняются.

По данным , администрация США попросила OpenAI не выпускать GPT-5.6 сразу в широкий доступ, а начать с ограниченного preview для небольшого круга партнеров. Доступ в этот период должен согласовываться отдельно по каждому клиенту.

Формально это не запрет на релиз. Но по факту это уже другой режим: сильная модель перестает быть просто продуктом, который компания выкатывает в ChatGPT/API, когда считает нужным. Теперь государство хочет заранее видеть, тестировать и контролировать доступ к таким системам, особенно если у них есть мощные cyber-возможности.

История с Anthropic показывает, почему это происходит: их новые модели Mythos/Fable тоже попали под ограничения из-за опасений, что такие системы могут быстро находить уязвимости в чувствительной инфраструктуре.

Главный сдвиг в том, что вопрос больше не только в том, кто первым выпустит самую сильную модель.

Теперь вопрос: кто вообще получит доступ, в какой стране, для каких задач и под каким контролем.

Похоже, гонка моделей не закончилась. Просто на трассу вышло государство и пока непонятно, это временная мера для самых опасных возможностей или новая парадигма для всей индустрии.

В продолжение предыдущего поста.

OpenAI показала линейку GPT-5.6: теперь это не одна модель, а три уровня — Sol, Terra и Luna.

Sol — флагманская модель для сложных задач, где нужно долго рассуждать, писать код, координировать инструменты и работать в агентном режиме. Появляется новый режим reasoning max, а также ultra — режим, где модель использует субагентов для ускорения сложной работы.

Terra — более сбалансированная модель для повседневных задач. OpenAI пишет, что она близка по возможностям к GPT-5.5, но примерно в 2 раза дешевле.

Luna — самая быстрая и доступная модель в линейке.

Интересный момент: релиз начинается не сразу для всех. Сначала доступ получит ограниченный круг доверенных партнеров через API и Codex, а более широкий запуск для ChatGPT, Codex и API обещают позже.

OpenAI прямо пишет, что запуск согласовывался с правительством США, и это уже хорошо показывает, как меняется рынок: новые модели теперь выпускаются не просто как продукт, а как технология под отдельным контролем.

Для нас главный вывод простой: агентные сценарии становятся еще важнее. Новые модели явно проектируются не только для чата, а для длинных задач, кода, инструментов, проверки уязвимостей и работы через субагентов.

Друзья. Пока на канале немного новостей, так как я относительно в отпуске. Сегодня начинается более менее рабочая неделя.

Сам пока жду GPT-5.6, вроде обещают дать доступ в ближайшее время.

Еще пытаюсь понять, что именно рассказывать мне на канале, когда я только начинал, то пробовал многое и рассказывал разное. Полгода спустя, у меня есть коммерческие проекты и круг моих интересов сузился до решения конкретных задач.

Отключил FOMO и стало попроще. Вышел из множества чатов и каналов, так как понял, что просто пропускаю там сообщения и не читаю уже.

Если вы ждете на канале каких то волшебных промтов или репозиториев, которые внезапно изменят вашу жизнь, то тут не помогу. Только дам совет, не старайтесь скопировать напрямую чужие работы. Старайтесь изучать , что конкретно вам полезно здесь и сейчас.

Желаю всем приятного лета и хорошего отдыха. На связи.


П,С, Посте написан мной, ибо это личный пост, ни капли агента, ни сантиментра ЛЛМки в нем. По этому и картинки не будет.

П.С.С. вот вам идеальная композиция из моего дома для хорошего настроения.

Собственно о чем и был разговор.

завтра обещают выпустить 5.6 сразу во всех вариациях.

Как только протестирую, напишу свое мнение. Особенно мне интересно возможности в творческих вопросах, потому что код и текущие модели уже очень хорошо пишут.

Вчера потратил время, что бы обновить свой прокси сервер на актуальный билд CLIProxyAPI.

После этого еще повоевал немного с нативным приложением Codex на windows, которое наконец-то совместили вместе с просто приложением ChatGPT и теперь это ChatGPT Work. Это мудрое решение, было два приложения и это путало.

А вот что еще реально путает, так это 3 новых модели, каждая с несколькими уровнями размышления. По умолчанию стоит Sol Medium , я поставил high и больше не трогал.

По ощущениям, стало более автономное, пишешь промт попроще, модель хорошо понимаем контекст и продолжает достаточно дотошно выполнять, то что ты просил.

К посту приложена картинка, где соотношение цены и "качество" модели. Пока сам не понимаю, что для меня лучше, но в целом эмоции положительные.

OpenAI опубликовала подробную инструкцию по работе с GPT‑5.6. Собрал главное.

Теперь это семейство из трёх моделей:
— gpt-5.6-sol — максимальные возможности для сложных задач;
— gpt-5.6-terra — баланс качества и стоимости;
— gpt-5.6-luna — массовая обработка и высокая нагрузка.

Появились новые уровни глубины рассуждений, включая max, а также режим Pro для задач, где качество важнее скорости и расхода токенов. Модель научилась сохранять рассуждения между запросами, точнее управлять кешированием промтов, программно вызывать инструменты и координировать несколько субагентов.

Но, на мой взгляд, самая интересная часть инструкции посвящена промтам. GPT‑5.6 лучше понимает конечную цель, поэтому ей уже не нужно расписывать каждый очевидный шаг. Важнее чётко задать контекст, ограничения, допустимые действия, границы автономности и критерий завершения. Более того, OpenAI рекомендует сокращать системные промты, убирать повторения и оставлять агенту только действительно необходимые инструменты.

При переходе с GPT‑5.4 или GPT‑5.5 не стоит сразу выкручивать рассуждения на максимум. Лучше сохранить текущий уровень, проверить его на реальных задачах, а затем протестировать ступень ниже: GPT‑5.6 часто сохраняет качество при меньшем расходе токенов.

Получается любопытный сдвиг: раньше мы пытались подробно объяснить модели, как выполнить каждый шаг. Теперь полезнее хорошо определить саму цель, границы работы и момент, когда задача действительно считается выполненной.