GitHub опубликовал еженедельный апдейт по проекту agentic workflows: сразу три pre-release и больше сотни изменений. В центре — защита от «лавины» запусков, более умные ограничения времени/условий выполнения и улучшения для команд, которые подключают свои инструменты к ИИ‑агентам.
GitHub выпустил еженедельный отчёт по проекту github/gh-aw — экспериментальной площадке для агентных workflow. За неделю команда отгрузила сразу три pre-release (v0.87.5, v0.87.8 и v0.87.9) и влила «сильно больше сотни» pull request’ов. Обновления нацелены на предсказуемость запусков, стабильность движка и удобство отладки интеграций.
Что именно изменилось в v0.87.9
- Окно «охлаждения» для триггеров (on.cooldown). Теперь workflow может объявить паузу, чтобы повторные события не выстраивались в очередь и не били в один и тот же «таргет» подряд. Это особенно полезно, когда внешняя система (или окружение для тестов) не любит параллельные перезапуски.
- Более гибкая остановка прогонов (typed on.stop-after). Параметр stop-after научился принимать не только фиксированное значение, но и выражения GitHub Actions. По сути, появляется удобный способ ограничивать продолжительность/условия выполнения без «костылей» вокруг.
- Понятные ошибки по схемам инструментов в Codex harness. Если модель не поддерживает tool-schema, вместо размытых сообщений провайдера теперь появляется отдельная, читаемая диагностика. Это экономит время на разбор «почему не завелось», особенно когда агент вызывает инструменты автоматически.
- Рутинные, но важные обновления зависимостей: по умолчанию подняли MCP Gateway до v0.4.14, а Agentic Workflow Firewall — до v0.28.10. Такие апдейты обычно незаметны, пока не спасают от очередной несовместимости или сетевой странности.
Почему это важно на практике
У агентных workflow есть характерная проблема: они реагируют на события слишком «охотно». Один и тот же репозиторий может получить серию почти одинаковых триггеров (например, когда кто-то несколько раз подряд пушит правки или обновляет PR). Без механики «торможения» система начинает тратить ресурсы на повторы и мешает самой себе.
on.cooldown закрывает именно этот класс болей: вы ограничиваете частоту запусков и снижаете риск того, что агент будет параллельно «чинить одно и то же» в нескольких ветках. А on.stop-after с выражениями позволяет аккуратнее выставлять границы: например, останавливать прогоны по условию окружения, типу события или параметрам запуска (сценарий зависит от того, как вы устроили Actions).
Заметные изменения вокруг документации и экосистемы
- Подход «сначала намерение, потом шаги»: появилось руководство по intent-driven дизайну — когда вы формулируете цель workflow понятным «намерением», а не расписываете инструкцию в стиле «нажми сюда, потом туда».
- Новый паттерн Feature Farmer: шаблон для workflow, который выращивает функциональность маленькими порциями, регулярно добавляя к проекту небольшие улучшения.
- Защита от слишком больших запросов в MCP: добавили поведение, при котором чрезмерно объёмные payload’ы не ломают вызовы молча, а завершаются контролируемо.
- Установка плагинов с авторизацией из приватных репозиториев: полезно для команд, которые держат инструменты и расширения внутри корпоративного контура.
- Bash на Windows‑раннерах: ещё один шаг к более «нормальному» Windows‑опыту в агентных сценариях.
«Агент недели»: AI Moderator — спокойный фильтр для шума
В отчёте отдельно выделили AI Moderator — агента, который следит за новыми issue, комментариями и pull request’ами, вылавливая спам, «мусорные» AI‑комментарии и link‑spam. По описанию, он работает в read-only режиме и задуман как безопасный «вахтёр»: минимальный риск, максимум пользы для репозиториев с большим потоком входящих событий.
Интересная деталь: его прогоны иногда попадали в наблюдаемости в категорию «сбоев», и команда отдельно отмечает, что такие сигналы важно правильно классифицировать, прежде чем делать вывод «всё сломалось».
Что можно попробовать у себя
- Обновиться до v0.87.9 и включить on.cooldown там, где у вас часто возникают повторные события.
- Пересмотреть ограничения выполнения и перевести часть логики на on.stop-after с выражениями Actions, если вам нужно тонко контролировать «сколько и когда работать».
- Если вы подключаете инструменты к агенту и ловили странные ошибки, проверить улучшенную диагностику по tool-schema: она должна быстрее приводить к причине, а не к догадкам.
