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

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

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

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

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

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

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

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

Мне нужно поехать в дорогу, за рулем на трассе, нашел сайт с музыкой, попросил кодекс написать быстро скрипт и скачать пару сборников, что бы не по 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 часто сохраняет качество при меньшем расходе токенов.

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

Внезапно OpenAi разошлись. Снова скинули лимиты.

А еще предложили написать твит и первым 10к твитнутых могут получить подарок

Кто смелый и активный, налетайте!

Нашёл интересный репозиторий про Loop Engineering — подход к работе с ИИ-агентами, где вместо постоянного написания новых промтов мы проектируем цикл, который сам понимает, что и когда нужно делать.

Типовой процесс выглядит так: событие или расписание запускает агента → агент читает текущее состояние проекта → выбирает задачу → выполняет её в отдельном worktree → другой агент проверяет результат → система либо создаёт PR, либо передаёт проблему человеку → состояние обновляется, и цикл начинается заново.

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

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

Поддерживается и Codex: репозиторий может создать начальную структуру со skills, verifier-агентом, состоянием и ограничениями.

При этом это не готовая автономная платформа. Большая часть проекта — методика, документация, шаблоны и небольшие CLI-утилиты. Связать запуск агентов, хранилище состояния, проверку и внешние сервисы всё равно придётся самостоятельно. Но как набор правил для построения собственной агентной системы репозиторий очень полезный.

Особенно мне близка основная идея: следующий этап работы с coding-агентами — не поиск идеального промта, а проектирование управляемого цикла с памятью, границами, проверкой результата и понятным условием остановки.

Оказывается у меня есть 4 недельных сброса лимита.

Я забыл совсем! Теперь кодекс надо гонять без остановки до завтра вечера, что бы потом активировать истекающий сброс.

Уффф... OpenAI и так уже раз в пару дней скидывают лимиты, так еще и самому можно...

Когда у тебя есть сбросы лимитов, можно и себя чуть побаловать.

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

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

В итоге я создал MCP помощник , который согласно законам литературы, работает с базой данных сюжетных событий, таймлайнами, персонажами и так далее.

Пару дней я накидывал концепт вместе с агентам, мы прописывали основные сюжетные арки и так далее. Т.е. я создал структуру.

А потом дал указания - согласно структуре, напиши черновик.

6 томов, 62 главы, 283 869 слов.
Цель достигнута за 20h 37m 56s

Я специально не трогал агента, т.е. практически за сутки он написал полноценный черновик.

В целом, самая история нормально, местами не нравится стилистика или сюжетные действия персонажей, НО! Как база, как начало это очень удобно.

Мой совет: не только кодом мы живем, если в вас есть творческие нотки, не теряйте их, развивайте вместе с агентом!

https://www.youtube.com/@KodeKloud/videos

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