Forwarded from Вайб-кодинг
// Обвязка агента через код //
Отчёт на 100+ страниц по всем аспектам, связанным с агентными обвязками: https://arxiv.org/abs/2605.18747
В частности, обзор суммирует методы и применения кода как обвязки для агентов.
В статье приводится сильный аргумент, что такой подход может быть ключом к переходу к более широкой науке инженерии обвязок.
Достаточно ли одного кода? Возможно.
В любом случае, в работе утверждается, что будущие системы должны обладать четырьмя свойствами: исполняемость, инспектируемость, состояние, управляемость.🤑
Отчёт на 100+ страниц по всем аспектам, связанным с агентными обвязками: https://arxiv.org/abs/2605.18747
В частности, обзор суммирует методы и применения кода как обвязки для агентов.
В статье приводится сильный аргумент, что такой подход может быть ключом к переходу к более широкой науке инженерии обвязок.
Достаточно ли одного кода? Возможно.
В любом случае, в работе утверждается, что будущие системы должны обладать четырьмя свойствами: исполняемость, инспектируемость, состояние, управляемость.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
Forwarded from Machinelearning
🔥 AlphaProof Nexus: формальные доказательства начинают превращаться в инженерный пайплайн
Google DeepMind показали AlphaProof Nexus - систему, которая автономно закрыла 9 открытых задач Эрдёша, часть из которых висела десятилетиями. По оценке авторов, стоимость решения одной задачи составила всего несколько сотен долларов.
Кроме этого, система доказала 44 открытые гипотезы из OEIS, закрыла 15-летний вопрос в алгебраической геометрии и нашла новый алгоритмический параметр в оптимизационной теории, который раньше не был описан людьми.
Модель генерирует идеи и фрагменты доказательств, а Lean проверяет каждый логический шаг через компилятор. Если доказательство некорректно, оно просто не проходит проверку. Не нужен рецензент, который вручную ищет дыру в рассуждении.
Базовый агент, который просто чередует генерацию LLM и обратную связь от компилятора, смог повторить все 9 успешных решений задач Эрдёша. Более сложная версия с эволюционным поиском и reinforcement learning дала заметный выигрыш только на самых тяжёлых случаях.
Чем сильнее становятся foundation models, тем чаще простые циклы «сгенерировал - проверил - исправил» начинают догонять специализированные архитектуры.
Отличие от неформального подхода к математическим доказательствам принципиальное. Модель часто придумывала несуществующие леммы, ссылалась на «известные результаты» и пыталась спрятать сложность задачи в вспомогательное утверждение. В обычном текстовом доказательстве такие ошибки легко пропустить. Lean отсекает их сразу.
Ещё один неожиданный эффект: агент находил неточности в формализациях уже существующих математических утверждений. То есть он работал не только как решатель, но и как диагностический инструмент для самой постановки задачи.
Успехи пока сосредоточены там, где библиотека Lean уже достаточно зрелая: комбинаторика, теория чисел, оптимизация. Задачи, где нужно строить большой пласт новой теории, всё ещё далеко не закрыты. И большинство задач Эрдёша система не решила.
Та же схема подходит для кодигша, спецификаций, верификации протоколов, компиляторов, криптографии.
Формальная проверка отсекает галлюцинации.
Модель может придумать лемму или сослаться на несуществующий результат, но Lean это не пропустит.
https://arxiv.org/html/2605.22763v1
@ai_machinelearning_big_data
Google DeepMind показали AlphaProof Nexus - систему, которая автономно закрыла 9 открытых задач Эрдёша, часть из которых висела десятилетиями. По оценке авторов, стоимость решения одной задачи составила всего несколько сотен долларов.
Кроме этого, система доказала 44 открытые гипотезы из OEIS, закрыла 15-летний вопрос в алгебраической геометрии и нашла новый алгоритмический параметр в оптимизационной теории, который раньше не был описан людьми.
Модель генерирует идеи и фрагменты доказательств, а Lean проверяет каждый логический шаг через компилятор. Если доказательство некорректно, оно просто не проходит проверку. Не нужен рецензент, который вручную ищет дыру в рассуждении.
Базовый агент, который просто чередует генерацию LLM и обратную связь от компилятора, смог повторить все 9 успешных решений задач Эрдёша. Более сложная версия с эволюционным поиском и reinforcement learning дала заметный выигрыш только на самых тяжёлых случаях.
Чем сильнее становятся foundation models, тем чаще простые циклы «сгенерировал - проверил - исправил» начинают догонять специализированные архитектуры.
Отличие от неформального подхода к математическим доказательствам принципиальное. Модель часто придумывала несуществующие леммы, ссылалась на «известные результаты» и пыталась спрятать сложность задачи в вспомогательное утверждение. В обычном текстовом доказательстве такие ошибки легко пропустить. Lean отсекает их сразу.
Ещё один неожиданный эффект: агент находил неточности в формализациях уже существующих математических утверждений. То есть он работал не только как решатель, но и как диагностический инструмент для самой постановки задачи.
Успехи пока сосредоточены там, где библиотека Lean уже достаточно зрелая: комбинаторика, теория чисел, оптимизация. Задачи, где нужно строить большой пласт новой теории, всё ещё далеко не закрыты. И большинство задач Эрдёша система не решила.
Та же схема подходит для кодигша, спецификаций, верификации протоколов, компиляторов, криптографии.
Формальная проверка отсекает галлюцинации.
Модель может придумать лемму или сослаться на несуществующий результат, но Lean это не пропустит.
https://arxiv.org/html/2605.22763v1
@ai_machinelearning_big_data
1❤3👍2🔥1
Forwarded from Вайб-кодинг
Microsoft открыла исходный код Webright. Это скилл для ИИ-агентов, позволяющий управлять браузерами.
Фишка в том, что внутри он использует Playwright, генерирует код на лету, а производительность просто бешеная.🧑🍳
Фишка в том, что внутри он использует Playwright, генерирует код на лету, а производительность просто бешеная.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯3
Forwarded from Вайб-кодинг
Антропики выкатили Claude Opus 4.8. Доступна уже сегодня по той же цене 🎉
Из самого интересного – заметно подтянули честность модели. По словам Anthropic, Opus 4.8 примерно в 4 раза реже пропускает баги в коде, который написал сам, и не пытается выдать сломанное решение за рабочее.
Также в Claude Code появилась новая фича: dynamic workflows (research preview) – для самых сложных задач Claude строит план, запускает сотни параллельных subagents и валидирует результаты перед тем, как вернуть отчёт. Например, при миграции, затрагивающей сотни файлов. Подробнее тут
Для Opus 4.8 также доступен Fast mode - это та же модель, но примерно в 2.5 раза быстрее и в три раза дешевле, чем раньше.
Из самого интересного – заметно подтянули честность модели. По словам Anthropic, Opus 4.8 примерно в 4 раза реже пропускает баги в коде, который написал сам, и не пытается выдать сломанное решение за рабочее.
Также в Claude Code появилась новая фича: dynamic workflows (research preview) – для самых сложных задач Claude строит план, запускает сотни параллельных subagents и валидирует результаты перед тем, как вернуть отчёт. Например, при миграции, затрагивающей сотни файлов. Подробнее тут
Для Opus 4.8 также доступен Fast mode - это та же модель, но примерно в 2.5 раза быстрее и в три раза дешевле, чем раньше.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯4❤2
Forwarded from Всеволод Устинов (канал: ai, стартапы, пост-ирония)
Посмотрел выступление Anthropic про то, как они собирают агентов, которые могут работать часами.
Схема такая:
planner → agent → evaluator
Это маленькая продуктовая команда из агентов. У каждого своя роль, свой контекст и своя зона ответственности. Но есть важные нюансы.
1. Planner: верхний план и спринты
Planner получает короткий запрос и превращает его в структуру работы:
— что собираем
— какие большие части нужны
— в какой последовательности идти
— какие спринты должны получиться
Важная деталь: planner не расписывает всю техническую реализацию заранее.
Если в начале придумать подробный план на 200 шагов и ошибиться, ошибка потом поедет каскадом через несколько часов работы.
Поэтому planner держит уровень продукта и спринтов, а технические решения остаются ближе к моменту реализации.
2. Agent: сборка следующего спринта
Agent берёт следующий спринт и собирает фичу.
Но перед началом работы он сначала договаривается с evaluator, что именно будет считаться готовым результатом.
Это главный механизм всей системы.
В обычной агентской работе часто бывает так: дал задачу, агент что-то сделал, сам себя проверил, сказал “готово”, а потом выясняется, что половина сценариев не работает.
Anthropic решает это через contract.
3. Contract: договорённость о готовом результате
Agent пишет: я соберу такую фичу, проверять её надо вот так.
Evaluator отвечает: добавь такой сценарий, такой edge case, такое состояние интерфейса, такую проверку.
Они обмениваются markdown-файлами и уточняют критерии, пока не сходятся на contract.
Contract — это список конкретных проверяемых утверждений.
Дальше evaluator проверяет уже не исходный расплывчатый запрос пользователя, а этот contract.
Например, исходный запрос:
“сделай retro game maker”
А contract превращает его в конкретику:
— можно создать новый проект
— есть sprite editor
— есть play mode
— сохраняется состояние
— canvas работает корректно
— основные сценарии кликаются в браузере
В примере Anthropic для одного приложения получилось 27 contract criteria.
Если критерии расплывчатые, critique тоже будет расплывчатой. Agent получает “ну как-то не очень” и не понимает, что именно чинить.
Если критерии конкретные, он видит точную проблему.
4. Evaluator: жёсткая проверка через браузер
Evaluator — это отдельный агент-критик.
Он открывает приложение через Playwright, кликает по интерфейсу, делает скриншоты, проверяет сценарии, пишет критику и отдаёт её обратно agent.
Отдельного критика проще настроить быть жёстким. У него отдельный контекст, отдельная роль и отдельная инструкция.
Agent собирает.
Evaluator атакует результат.
За счёт этого появляется нормальное давление на качество.
5. Финальный цикл
Итоговый процесс выглядит так:
1. planner разбивает задачу на спринты
2. agent берёт следующий спринт
3. agent и evaluator согласуют contract
4. agent строит
5. evaluator проверяет через браузер
6. agent чинит
7. цикл повторяется
С новыми моделями эту схему можно делать проще. Иногда agent может два часа спокойно собирать продукт, а потом evaluator прогоняет проверку.
Но суть остаётся: качество держится не на “модель умная”, а на архитектуре процесса.
6. Как собрать похожее самому
Нужны понятные примитивы:
— subagents для отдельных ролей
— Playwright / Chrome MCP для проверки интерфейса
— skills / rubrics для критериев качества
— auto mode / permissions для долгой автономной работы
— contract files для договорённости о “готово” до начала реализации
—
Я сам дошёл до части этих принципов: независимое тестирование, контракт (у меня назвался definition of done, dod). Теперь хочу попробовать воспроизвести целиком.
Видео:
https://youtu.be/mR-WAvEPRwE
Схема такая:
planner → agent → evaluator
Это маленькая продуктовая команда из агентов. У каждого своя роль, свой контекст и своя зона ответственности. Но есть важные нюансы.
1. Planner: верхний план и спринты
Planner получает короткий запрос и превращает его в структуру работы:
— что собираем
— какие большие части нужны
— в какой последовательности идти
— какие спринты должны получиться
Важная деталь: planner не расписывает всю техническую реализацию заранее.
Если в начале придумать подробный план на 200 шагов и ошибиться, ошибка потом поедет каскадом через несколько часов работы.
Поэтому planner держит уровень продукта и спринтов, а технические решения остаются ближе к моменту реализации.
2. Agent: сборка следующего спринта
Agent берёт следующий спринт и собирает фичу.
Но перед началом работы он сначала договаривается с evaluator, что именно будет считаться готовым результатом.
Это главный механизм всей системы.
В обычной агентской работе часто бывает так: дал задачу, агент что-то сделал, сам себя проверил, сказал “готово”, а потом выясняется, что половина сценариев не работает.
Anthropic решает это через contract.
3. Contract: договорённость о готовом результате
Agent пишет: я соберу такую фичу, проверять её надо вот так.
Evaluator отвечает: добавь такой сценарий, такой edge case, такое состояние интерфейса, такую проверку.
Они обмениваются markdown-файлами и уточняют критерии, пока не сходятся на contract.
Contract — это список конкретных проверяемых утверждений.
Дальше evaluator проверяет уже не исходный расплывчатый запрос пользователя, а этот contract.
Например, исходный запрос:
“сделай retro game maker”
А contract превращает его в конкретику:
— можно создать новый проект
— есть sprite editor
— есть play mode
— сохраняется состояние
— canvas работает корректно
— основные сценарии кликаются в браузере
В примере Anthropic для одного приложения получилось 27 contract criteria.
Если критерии расплывчатые, critique тоже будет расплывчатой. Agent получает “ну как-то не очень” и не понимает, что именно чинить.
Если критерии конкретные, он видит точную проблему.
4. Evaluator: жёсткая проверка через браузер
Evaluator — это отдельный агент-критик.
Он открывает приложение через Playwright, кликает по интерфейсу, делает скриншоты, проверяет сценарии, пишет критику и отдаёт её обратно agent.
Отдельного критика проще настроить быть жёстким. У него отдельный контекст, отдельная роль и отдельная инструкция.
Agent собирает.
Evaluator атакует результат.
За счёт этого появляется нормальное давление на качество.
5. Финальный цикл
Итоговый процесс выглядит так:
1. planner разбивает задачу на спринты
2. agent берёт следующий спринт
3. agent и evaluator согласуют contract
4. agent строит
5. evaluator проверяет через браузер
6. agent чинит
7. цикл повторяется
С новыми моделями эту схему можно делать проще. Иногда agent может два часа спокойно собирать продукт, а потом evaluator прогоняет проверку.
Но суть остаётся: качество держится не на “модель умная”, а на архитектуре процесса.
6. Как собрать похожее самому
Нужны понятные примитивы:
— subagents для отдельных ролей
— Playwright / Chrome MCP для проверки интерфейса
— skills / rubrics для критериев качества
— auto mode / permissions для долгой автономной работы
— contract files для договорённости о “готово” до начала реализации
—
Я сам дошёл до части этих принципов: независимое тестирование, контракт (у меня назвался definition of done, dod). Теперь хочу попробовать воспроизвести целиком.
Видео:
https://youtu.be/mR-WAvEPRwE
YouTube
Anthropic Workshop: Build Agents That Run for Hours — Ash Prabaker & Andrew Wilson
Why self-evaluation is a trap and adversarial evaluator agents work better; why context compaction doesn't cure coherence drift but structured handoffs do; how to decompose work into testable sprint contracts; how to grade subjective output with rubrics an…
🔥2❤1🤔1
Forwarded from Вайб-кодинг
This media is not supported in your browser
VIEW IN TELEGRAM
Если у вас есть видеокарта с 8 ГБ VRAM, то у меня для вас хорошие новости.
Вчера чувак тестировал Unsloth Gemma 4 12B Q4_K_XL на карте с 8 ГБ VRAM.
Народ был в шоке и сразу спросил: А 25B+ модель на бюджетной карте вообще реально запустить?
Оказалось — да.
Чувак запускает локально огромную MoE-модель на 26 миллиардов параметров на обычном ноутбуке с RTX 4060 8 ГБ и 16 ГБ оперативки.
Что по скорости:
- стабильные 20 токенов/с на декодировании;
- скорость не проседает даже на длинных промптах;
- скормил ей промпт на 60k токенов - всё так же держит около 20 TPS.
По TTFT чудес нет. Огромный контекст нужно сначала обработать. Но при скорости prefill около 200 токенов/с ждать приходится недолго, пользоваться вполне комфортно.
И всё это без MTP. Главная причина — новые QAT-кванты Gemma 4 от Google. Файл весов
Главный секрет — флаг
Флаги запуска:
После запуска достаточно открыть веб-интерфейс на localhost и включить новый значок лампочки режима reasoning в поле ввода, чтобы наблюдать, как модель выполняет многошаговые рассуждения.😒 😒 😒
А интеграция с Hermes Agent заняла буквально пару минут.
Вчера чувак тестировал Unsloth Gemma 4 12B Q4_K_XL на карте с 8 ГБ VRAM.
Народ был в шоке и сразу спросил: А 25B+ модель на бюджетной карте вообще реально запустить?
Оказалось — да.
Чувак запускает локально огромную MoE-модель на 26 миллиардов параметров на обычном ноутбуке с RTX 4060 8 ГБ и 16 ГБ оперативки.
Что по скорости:
- стабильные 20 токенов/с на декодировании;
- скорость не проседает даже на длинных промптах;
- скормил ей промпт на 60k токенов - всё так же держит около 20 TPS.
По TTFT чудес нет. Огромный контекст нужно сначала обработать. Но при скорости prefill около 200 токенов/с ждать приходится недолго, пользоваться вполне комфортно.
И всё это без MTP. Главная причина — новые QAT-кванты Gemma 4 от Google. Файл весов
unsloth gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf весит всего 13.2 ГБ, что для модели такого размера выглядит почти нереально.Главный секрет — флаг
-cmoe в llama.cpp. Он отправляет веса экспертов MoE в оперативную память, а GPU оставляет Attention и KV Cache. В результате VRAM не забивается под завязку, а скорость остаётся стабильной.Флаги запуска:
-m "gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf" -cmoe -c 248000 -v
После запуска достаточно открыть веб-интерфейс на localhost и включить новый значок лампочки режима reasoning в поле ввода, чтобы наблюдать, как модель выполняет многошаговые рассуждения.
А интеграция с Hermes Agent заняла буквально пару минут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯6❤4😁2
Forwarded from Вайб-кодинг
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел Harness-1 — поисковый агент на 20B параметров с довольно необычной идеей.
Вместо того чтобы заставлять модель хранить всю историю поиска в контексте, авторы решили вынести состояние наружу и обучить модель работать через специальный harness.
Получился агент на 20B параметров, который на длинных поисковых задачах конкурирует с гораздо более крупными моделями.
Обычно поисковые агенты работают по схеме:
поиск → чтение → поиск → чтение → всё подряд добавляется в контекст.
В итоге модель одновременно играет роль поисковика, памяти, заметочника, верификатора и библиотекаря.
Harness-1 разделяет эти задачи.
Модель по-прежнему решает, что искать, что читать, какие факты сохранять и что проверять. Но всё состояние поиска хранится во внешнем harness-слое.
Он ведёт рабочую память агента:
• найденные документы
• отобранные доказательства
• историю поиска
• связи между источниками
• результаты проверок
• дедупликацию и сжатие данных
• контроль контекстного бюджета
Интересно и то, что модель обучалась на сравнительно небольшом объёме данных: всего 899 SFT-траекторий и RL на 3453 запросах. Авторы считают, что значительную часть нужного поведения можно вынести в сам harness, а не зашивать в веса модели
Самый любопытный результат - переносимость. На новых бенчмарках, которых модель не видела во время обучения, прирост оказался ещё выше, чем на исходных задачах.
Paper : arxiv.org/abs/2606.02373
Code : https://github.com/pat-jj/harness-1
Model : https://huggingface.co/pat-jj/harness-1
HF Paper: https://huggingface.co/papers/2606.02373
Вместо того чтобы заставлять модель хранить всю историю поиска в контексте, авторы решили вынести состояние наружу и обучить модель работать через специальный harness.
Получился агент на 20B параметров, который на длинных поисковых задачах конкурирует с гораздо более крупными моделями.
Обычно поисковые агенты работают по схеме:
поиск → чтение → поиск → чтение → всё подряд добавляется в контекст.
В итоге модель одновременно играет роль поисковика, памяти, заметочника, верификатора и библиотекаря.
Harness-1 разделяет эти задачи.
Модель по-прежнему решает, что искать, что читать, какие факты сохранять и что проверять. Но всё состояние поиска хранится во внешнем harness-слое.
Он ведёт рабочую память агента:
• найденные документы
• отобранные доказательства
• историю поиска
• связи между источниками
• результаты проверок
• дедупликацию и сжатие данных
• контроль контекстного бюджета
Интересно и то, что модель обучалась на сравнительно небольшом объёме данных: всего 899 SFT-траекторий и RL на 3453 запросах. Авторы считают, что значительную часть нужного поведения можно вынести в сам harness, а не зашивать в веса модели
Самый любопытный результат - переносимость. На новых бенчмарках, которых модель не видела во время обучения, прирост оказался ещё выше, чем на исходных задачах.
Paper : arxiv.org/abs/2606.02373
Code : https://github.com/pat-jj/harness-1
Model : https://huggingface.co/pat-jj/harness-1
HF Paper: https://huggingface.co/papers/2606.02373
❤6👍1
Forwarded from Вайб-кодинг
This media is not supported in your browser
VIEW IN TELEGRAM
Знакомьтесь: Clips. Бесплатная открытая замена Loom, заточенная под агентов. 😋
В отличие от Loom, агент понимает Clips просто по ссылке. Каждый клип содержит API и метаданные, благодаря которым агент может изучить его содержимое. Агенты видят и слышат не только транскрипт, а вообще всё, что происходит на видео в любой момент времени.
Делишься баг-репортом, фидбеком, анализом — и передаёшь это агенту, чтобы он улучшал продукт или отчёт.
Ещё один плюс: софт твой. Никто не поднимет цену в один день, как это сделал Loom.
Clips создан для кастомизации. Встроенный агент умеет править собственный код, просто адаптируешь приложение под себя.
Ещё можно импортировать Loom по ссылке и загружать видео.
Есть бесплатная хостовая версия. Можно форкнуть и хостить самому.
В отличие от Loom, агент понимает Clips просто по ссылке. Каждый клип содержит API и метаданные, благодаря которым агент может изучить его содержимое. Агенты видят и слышат не только транскрипт, а вообще всё, что происходит на видео в любой момент времени.
Делишься баг-репортом, фидбеком, анализом — и передаёшь это агенту, чтобы он улучшал продукт или отчёт.
Ещё один плюс: софт твой. Никто не поднимет цену в один день, как это сделал Loom.
Clips создан для кастомизации. Встроенный агент умеет править собственный код, просто адаптируешь приложение под себя.
Ещё можно импортировать Loom по ссылке и загружать видео.
Есть бесплатная хостовая версия. Можно форкнуть и хостить самому.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Вайб-кодинг
Нашёл отличную книгу — The Hitchhiker’s Guide to Agentic AI, которая охватывает практически весь стек Agentic AI.
Главная ценность книги - это широкий обзор всего направления: архитектура LLM, обучение моделей, методы обучения с подкреплением, системы инференса, оценка моделей, агентные системы и многое другое.
Лучше всего использовать её как карту знаний. Сначала просмотреть оглавление, найти темы, в которых есть пробелы, понять, чего ещё не хватает, а затем углубиться в соответствующие главы. Такой подход помогает выстроить системное понимание Agentic AI.
🐸 🐸 🐸
Главная ценность книги - это широкий обзор всего направления: архитектура LLM, обучение моделей, методы обучения с подкреплением, системы инференса, оценка моделей, агентные системы и многое другое.
Лучше всего использовать её как карту знаний. Сначала просмотреть оглавление, найти темы, в которых есть пробелы, понять, чего ещё не хватает, а затем углубиться в соответствующие главы. Такой подход помогает выстроить системное понимание Agentic AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Вайб-кодинг
Anthropic описала четыре типа циклов, которые можно строить с помощью Claude. Каждый из них передаёт агенту разную часть процесса принятия решений.
Термин loop engineering сейчас используется настолько широко, что стоит чётко понимать, чем именно отличаются эти четыре варианта: что запускает цикл и что определяет момент его завершения.
> Цикл на основе запросов. Вы отправляете запрос, Claude выполняет задачу, самостоятельно проверяет результат и возвращает его вам. Именно этот цикл работает практически при каждом вашем сообщении, независимо от того, называете вы его так или нет.
> Цикл на основе цели (/goal). Вы заранее задаёте измеримый критерий завершения. Каждый раз, когда Claude пытается завершить работу, модель-оценщик проверяет, достигнута ли поставленная цель. Если нет, Claude отправляется продолжать работу.
> Цикл на основе времени (/loop, /schedule). Вместо пользовательского запроса запуск происходит по таймеру. Команда /loop повторно выполняет проверку через заданные интервалы, но прекращает работу, если останавливается ваша машина. Команда /schedule переносит ту же идею в облако, поэтому цикл продолжает работать независимо от вашей текущей сессии.
> Проактивный цикл. Это комбинация /schedule, /goal и рабочего процесса, которая запускается по событию без какого-либо запроса со стороны пользователя в момент выполнения. Каждый элемент доводится до собственной цели, а сам процесс продолжает работать, пока кто-нибудь его не отключит.
НО: циклы на основе цели работают только тогда, когда критерий завершения действительно можно измерить. А проактивные циклы это самый простой способ столкнуться с проблемами при масштабировании, если сначала не проверить их работу хотя бы на нескольких реальных сценариях. Для большинства задач по-прежнему лучше подходит обычный цикл на основе запросов, чем более сложная схема, в которой пока нет необходимости.
Необязательно выбирать самый продвинутый механизм только потому, что он сложнее. Важнее подобрать тип цикла в зависимости от того, имеет ли задача чёткий критерий завершения или действительно должна выполняться непрерывно.
Вот статья, где разобрали все четыре типа циклов, привели примеры и предложили подход к выбору между /goal и /loop.🎉
Термин loop engineering сейчас используется настолько широко, что стоит чётко понимать, чем именно отличаются эти четыре варианта: что запускает цикл и что определяет момент его завершения.
> Цикл на основе запросов. Вы отправляете запрос, Claude выполняет задачу, самостоятельно проверяет результат и возвращает его вам. Именно этот цикл работает практически при каждом вашем сообщении, независимо от того, называете вы его так или нет.
> Цикл на основе цели (/goal). Вы заранее задаёте измеримый критерий завершения. Каждый раз, когда Claude пытается завершить работу, модель-оценщик проверяет, достигнута ли поставленная цель. Если нет, Claude отправляется продолжать работу.
> Цикл на основе времени (/loop, /schedule). Вместо пользовательского запроса запуск происходит по таймеру. Команда /loop повторно выполняет проверку через заданные интервалы, но прекращает работу, если останавливается ваша машина. Команда /schedule переносит ту же идею в облако, поэтому цикл продолжает работать независимо от вашей текущей сессии.
> Проактивный цикл. Это комбинация /schedule, /goal и рабочего процесса, которая запускается по событию без какого-либо запроса со стороны пользователя в момент выполнения. Каждый элемент доводится до собственной цели, а сам процесс продолжает работать, пока кто-нибудь его не отключит.
НО: циклы на основе цели работают только тогда, когда критерий завершения действительно можно измерить. А проактивные циклы это самый простой способ столкнуться с проблемами при масштабировании, если сначала не проверить их работу хотя бы на нескольких реальных сценариях. Для большинства задач по-прежнему лучше подходит обычный цикл на основе запросов, чем более сложная схема, в которой пока нет необходимости.
Необязательно выбирать самый продвинутый механизм только потому, что он сложнее. Важнее подобрать тип цикла в зависимости от того, имеет ли задача чёткий критерий завершения или действительно должна выполняться непрерывно.
Вот статья, где разобрали все четыре типа циклов, привели примеры и предложили подход к выбору между /goal и /loop.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1🥰1