Transcription
Это полное руководство по созданию агентских циклов и автономных систем ИИ. Вы, возможно, слышали много шума вокруг термина "инженерия циклов", но очень немногие люди показывают, как на самом деле применять эти идеи на практике. Большинство из нас мечтают о том, чтобы автономные агенты работали на нас 24/7, выполняли работу, зарабатывали деньги и экономили нам время. Но на самом деле создание агентских систем требует настоящего дизайнерского мышления. Я покажу вам, как я использую комбинацию Claude Code и Codex для автоматизации значительной части моего процесса разработки. К концу вы будете знать, как работают автономные агентские циклы и как создавать их самостоятельно. Все ресурсы, подсказки и все, что вам нужно, будет бесплатно доступно по ссылке в описании ниже. Итак, приступим к [музыка] этому. Если вы новичок на канале, меня зовут Оуэн. Я был инженером-программистом, менеджером по инжинирингу и директором по инжинирингу в течение последних 20 лет, и я создаю автономные системы ИИ каждый день в своем собственном бизнесе. Хорошо, это твит от Питера Зейнбергера, который как бы вызвал всю эту дискуссию. Итак, эта идея, что ваш ежемесячный напоминание, вы больше не должны кодировать агентов по подсказкам. Вы должны проектировать циклы, которые дают подсказки вашим агентам. Это довольно абстрактная концепция. Всякий раз, когда вы используете субагента, например, вы уже делаете это. >> [музыка] >> Итак, субагент будет запущен с помощью подсказки, написанной родительским агентом. Так что всякий раз, когда вы запускаете субагента, у вас уже есть агенты, которые пишут подсказки. >> [музыка] >> Но я думаю, что Питер здесь говорит больше о системном дизайне. Борис также говорит о другой концепции. Итак, Борис говорит об этой идее, что я больше не даю подсказки Claude Code. Я пишу циклы, и циклы делают работу. Моя работа — писать циклы. Опять же, это очень расплывчатая и очень абстрактная идея. Одна из причин, по которой мне в целом не нравится термин "инженерия циклов", заключается в том, что он очень абстрактен и очень неясно, что он означает. Я думаю, что лучший термин — это создание систем с агентами. Я думаю, что это более понятный способ мыслить об этом. Другой термин, который мне очень не нравится, — это "инженерия упряжи" по тем же причинам. Это очень непрозрачно и очень неясно, что это на самом деле означает на практике. Итак, цикл — это очень простая концепция. Обычно это просто повторение действий снова и снова. Циклы всегда существовали в кодировании. Это фундаментальная часть создания кода, очевидно. И поэтому идея цикла здесь в этом контексте заключается в том, что мы запускаем агента в цикле. Вот что здесь отличается. Итак, по расписанию или при возникновении события агент будет читать состояние мира. Это может быть чтение очереди задач GitHub. Он выполнит некоторую работу, а затем обновит состояние мира. Он снова уснет, а затем повторит цикл. Это самый базовый цикл, который вы могли бы построить. Итак, у агента есть очень конкретная задача. Он работает по расписанию и может обновлять состояние мира. Итак, важная вещь, о которой следует подумать при создании автономных агентских систем, — это всегда думать о плоскости управления или состоянии мира. И поэтому, когда эти агенты работают автономно, вам нужен способ проверять, что они делают. Как человеку, вам не хочется, чтобы агенты работали без присмотра, без видимости того, что на самом деле происходит. Это было бы очень опасно. Итак, плоскость управления может быть чем-то вроде линейной или задач GitHub, где агенты могут обновлять задачи или задания, над которыми они работают. Вы можете видеть, как задачи перемещаются по очереди статусов, переходя от "в работе" к "на проверке" к "выполнено". И каждая задача может содержать комментарий от агента. Вы можете видеть всю выполняемую работу. Агенты могут комментировать вещи. Они могут обновлять состояние задач. Итак, в этом видео мы рассмотрим простую систему, которая имеет два цикла. Итак, первый цикл — это то, что я называю циклом менеджера. Это цикл, в котором агент ИИ просматривает бэклог проекта, просматривает все рабочие элементы и классифицирует все задачи как низкорискованные или высокорискованные, а также подходит ли задача для агента, чтобы работать над ней. Итак, у вас есть автономный агент, классифицирующий работу. И это позволяет вам иметь второй агентский цикл, который я называю рабочим циклом. Здесь у нас есть агент, опрашивающий очередь задач GitHub или плоскость управления, ищущий работу. Когда агент находит работу, агент затем пройдет через свой собственный рабочий процесс. Итак, он возьмет задачу и, по сути, запустит конвейер. В этом случае у меня есть внутренний цикл, где агент сначала прочитает задачу. Затем он напишет код. Он запустит субагента для проверки кода. Затем он выполнит некоторые дополнительные проверки, и, наконец, он откроет pull request в конце. Итак, это действительно важно. У вас есть агент, дающий подсказки самому себе на протяжении всего этого цикла. Итак, агент дает подсказки субагенту для проверки кода, и агенты просто работают в цикле здесь. Итак, довольно простая настройка, но она очень, очень мощная, как мы увидим. Итак, первый цикл, который мы рассмотрим, — это цикл менеджера. Итак, как бывший менеджер по инжинирингу и бывший технический лидер, одной из моих обязанностей или одной из обязанностей менеджера по инжинирингу в целом является поддержание бэклога в порядке. Это потому, что люди в вашей команде или инженеры будут работать над этими задачами, и вам нужно убедиться, что все правильно упорядочено, у всего правильный приоритет, все на доске находится в правильном состоянии. Одним из самых больших разочарований, если вы работаете в инженерной команде, является то, когда вы смотрите на доску, как эта, вещи отмечены как "в работе", хотя они уже завершены, вещи отмечены как "на проверке", хотя вы знаете, что это не так, или над ними все еще работают. Итак, эта проблема несоответствия очень расстраивает в реальном мире. Итак, мы будем использовать агентов для маркировки и классификации всех наших задач автономно, и агенты также будут проверять, что все находится в правильном состоянии. Агенты также будут проверять нашу кодовую базу, и всякий раз, когда они найдут ошибку, несоответствие в документации или что-то не так с нашим кодом, агенты также смогут создать задачу. Итак, у нас есть этот автономный агент-менеджер, который следит за всем в нашем проекте. Итак, вот код для этой автоматизации. Это довольно просто. Вы можете попросить Claude Code, по сути, написать эти вещи для вас сейчас. К счастью, вам больше не нужно писать их вручную. Но, по сути, это будет работать, это будет запускать Claude Code в цикле, и он говорит: "Используйте навык менеджера бэклога для триажа репозитория, по сути. Итак, пройдитесь по всем задачам, запустите навык и убедитесь, что все в порядке". Это, по сути, все, что мы здесь делаем в рамках автоматизации. Вы можете установить cron здесь, например, если вы хотите запланировать это на каждый день. Хорошо, теперь мы запустим эту автоматизацию. Итак, это агентский цикл. Действие GitHub будет выполняться в цикле. Мы используем Claude Code в качестве агента для управления нашим бэклогом. Мы переведем это в режим применения. Это позволит Claude Code вносить изменения в наш бэклог. Итак, мы просто запустим это сейчас и посмотрим, что получится. Итак, теоретически, по мере выполнения этого, вы должны увидеть, как Claude Code фактически обдумывает проблему, а затем мы должны увидеть, как эти задачи обновляются по мере того, как Claude проходит через бэклог. Итак, еще одно, что стоит сказать, это то, что при создании этих агентских циклов вы также хотите учитывать ограничения. Например, когда этот цикл автоматизации агента запускается, агент не может отправлять код или выполнять какие-либо деструктивные операции. И поэтому всякий раз, когда вы создаете агентский цикл, вам нужно очень тщательно подумать о дизайне ограничений. Например, единственное, что может делать эта автоматизация агента или Claude в этой ситуации, — это обновлять и управлять нашими задачами. Это все, что он может делать. Вы можете заблокировать это. Это позволяет вам создавать такие агентские циклы очень, очень безопасно. И это ключ к созданию этих автономных систем. Вам нужно установить ограничения для защиты всего. Хорошо, теперь вы можете видеть, что агент обновляет вещи. Итак, похоже, что этот агент теперь жив и работает. Итак, агентский цикл классифицировал эту задачу, поэтому он отметил ее как "готов к агенту", "риск низкий", "тип — функция". Это идеально. Теперь агент читает задачи, обновляет все метки. Надеюсь, теперь мы увидим остальные. Вы можете видеть, что некоторые другие дополнительные метки теперь классифицируются. Итак, эта задача здесь, эта требует человеческого вмешательства. Вы можете видеть, что теперь агент добавляет все метки. Итак, это функция с высоким риском. Она также требует человеческого вмешательства, поскольку это исследование. Так что, очевидно, нам нужно какое-то человеческое вмешательство в эти задачи, и нам просто нужно подождать, пока он пройдет через остальные, классифицирует остальные. Итак, это агентский цикл, выполняющий действие. Агент классифицирует все задачи. Мы ничего не делаем. Это будет выполняться каждый день, независимо от того, когда вы это запланируете. Итак, всякий раз, когда вы добавляете новую задачу или каждый день, вы заставляете цикл агента ИИ проходить, классифицировать и управлять всем вашим проектным бэклогом. Это работа, которая раньше занимала у человека много времени. Итак, у нас есть пара задач, которые, похоже, мы можем выполнить. Итак, эта задача, похоже, мы можем назначить ее агенту. Итак, она готова для агента, потому что она низкорискованная и не требует человеческого вмешательства. Вы можете настроить это. Очевидно, вы можете сделать любую из этих задач готовой для агента. Чем больше вы доверяете системе, тем больше вы можете делегировать агентам. Я бы начал с того, что поручал агентам самые простые задачи, такие как исправление ошибок, обновление документации. А затем, по мере того, как вы будете набирать уверенность в этих автономных агентских циклах, вы сможете начать делегировать агентам все более крупные задачи. Я, вероятно, был бы вполне доволен тем, что делегировал бы некоторые из этих средних задач агентам, честно говоря. Хорошо, если вы вернетесь к нашей диаграмме, вы увидите здесь, что мы завершили цикл менеджера. Итак, этот автономный агентский цикл теперь может выполняться каждый день или каждый раз, когда вы добавляете задачу, вы можете запускать этот цикл менеджера, классифицировать все ваши задачи, чтобы убедиться, что они готовы для агента, решать, над чем агенты могут работать, классифицировать уровень риска, убедиться, что все находится в правильном статусе и т. д. Итак, теперь нам нужно перейти к созданию второго цикла, который я называю рабочим циклом. Хорошо, это действительно захватывающая и интересная часть цикла. Итак, по сути, задача инженера циклов — фактически написать весь код. Итак, у нас есть агент, который работает в цикле каждый день. Он будет искать любые открытые задачи с меткой "готов к агенту" и "риск = низкий". Итак, любые задачи, подходящие для автономного ИИ-агента, будут загружены, работа начнется, и будет запущен внутренний рабочий процесс. Здесь агенты дают подсказки агентам. Итак, первое, что мы делаем, это убеждаемся, что мы находимся в правильной ветке. Итак, мы убеждаемся, что мы не находимся в грязной ветке, у нас нет незафиксированных изменений, убеждаемся, что все в среде чисто. Это снова полезная мера предосторожности, чтобы защитить вас от того, чтобы агенты не испортили вашу работу или не вызвали проблем. Вы хотите убедиться, что он прервется, если что-то будет нечисто. А затем мы будем работать последовательно. Это действительно важно. Вы могли бы запускать эти задачи параллельно, если бы хотели. Итак, вы могли бы запускать несколько разных агентов, работающих над несколькими разными задачами одновременно. Я обычно этого не делаю, потому что это может вызвать много проблем. Вероятно, вы обнаружите, что агенты конфликтуют друг с другом. Часто эти задачи все равно имеют зависимости. Так что есть своего рода логический порядок, но вы можете попросить координатора запускать их параллельно, если хотите. Этот основной агент действует как координатор для остальной части системы. Итак, что мы собираемся сделать, это фактически запустить новый поток Codex. Итак, прочитайте автоматизацию. Создайте новый поток Codex. Это уникально для Codex. Вы не можете сделать это в Claude Code, но это создает совершенно новую сессию или разговор или экземпляр агента, который затем сам может запускать субагентов, и вы можете заходить и проверять любой из этих, по сути, этих потоков в любое время. Итак, что мы собираемся сделать, это прочитать задачу, написать код, обеспечить хорошее покрытие тестами, запустить соответствующие тесты, использовать субагента для проверки различий. Итак, здесь мы используем агентов для подсказок другим агентам, а затем мы исправим любые найденные проблемы, откроем pull request, а затем переместим задачу в состояние "готов к проверке", прокомментируем исходную проблему. Это действительно важно при работе с автономными агентскими системами. Вы всегда хотите, чтобы агенты предоставляли доказательства в задачах того, что они сделали. Это позволяет вам видеть проделанную ими работу. Это позволяет вам убедиться, что они запустили тесты, потому что они могут предоставить доказательства внутри задачи. Когда вы работаете с людьми-инженерами, вы обычно делаете то же самое. Это очень хорошая практика — добавлять скриншоты, доказательства вывода тестов в ваши задачи, потому что это подтверждает рецензенту, что тесты действительно были запущены. Так что это просто очень хорошая практика в целом. Только после открытия pull request вы можете перейти к следующей задаче. Итак, это своего рода выполнение всего цикла. У нас также есть максимальное количество задач — три на один запуск автоматизации. Это важно, потому что опять же, это просто еще одно ограничение. Поскольку эти агенты работают автономно, может возникнуть ошибка, когда у вас есть, скажем, 50 задач, и агент, работающий над 50 задачами, сожжет много токенов. Поэтому вы хотите быть немного консервативны и снова просто установить ограничения внутри ваших автоматизаций. Вы, очевидно, можете изменить это число по мере того, как вы набираете уверенность в системе. Итак, что мы собираемся сделать сейчас, это просто запустить эту автоматизацию. Мы запустим ее, а затем мы можем нажать здесь, чтобы увидеть, что автоматизация теперь запущена. Итак, это то, что будет запускаться каждый день. Что действительно полезно, так это то, что при запуске этих автоматизаций, хотя вы можете видеть, что я жестко закодировал много инструкций здесь. Итак, я вложил много деталей в этот набор инструкций. Что я бы рекомендовал сделать в качестве лучшей практики, так это не делать этого. Что я рекомендую, так это иметь навык, который будет запускать рабочий процесс. Итак, по сути, эта автоматизация должна быть относительно простой. Она должна говорить: "Загрузите задачи, делегируйте их работникам, а затем запустите навык, по сути". Это позволяет вам иметь меньше шума в этой автоматизации. Ее гораздо проще поддерживать. Так что это просто то, что я бы рекомендовал. Итак, теперь вы можете видеть, что агент запрашивает GitHub. Итак, он запускает запрос GitHub сейчас. Итак, у нас есть четыре потенциальные задачи. Итак, у нас есть задача номер 18, задача 63, 110 и 129. Итак, агент может работать над любой из них. Он может работать только над тремя одновременно. Итак, теперь агент должен использовать свой собственный интеллект или суждение о том, над чем он будет работать. Опять же, вот почему такие системы так мощны. У вас есть агенты, использующие свой интеллект для принятия решений о том, что делать. Вот почему это намного мощнее, чем, возможно, традиционная автоматизация. Итак, ваш подход здесь, если вы используете Codex, ваш подход к такому роду вещей будет немного отличаться от Claude Code. Но принцип тот же. В Claude Code теперь могут быть вложенные субагенты. Итак, что я, вероятно, сделаю в Claude Code, так это то, что основной агент будет координатором, который затем запустит субагента. Субагент будет выполнять всю работу, а затем отчитываться координатору. Субагенты в Claude Code теперь могут быть вложенными, так что у вас может быть оркестратор, у вас может быть работник, а затем у вас может быть субагент от суб-работника. Так что это своего рода мощный шаблон, который вы теперь можете делать в Claude Code. Что вы можете видеть здесь, так это то, что это агент, который выполняет работу. Итак, это идея агента, дающего подсказки агенту. Итак, очевидно, мы не писали эту подсказку. Итак, она говорит: "Ты работник один для этого репозитория. Работай только над этой задачей GitHub". Итак, опять же, агент пишет эту подсказку. Это пример того, что говорил Питер. Агенты дают подсказки самим себе. Мы не пишем подсказку. Система пишет свои собственные подсказки. Если вас интересуют навыки, я оставлю ссылку в описании ниже. Но это мой навык менеджера бэклога. И вы можете видеть здесь, что он говорит: "Управляйте инженерным бэклогом для людей и ИИ-агентов". Так что довольно просто. Цель этого навыка — по сути, классифицировать задачи. Мы используем фреймворк "Jobs to be Done" для определения ролей в рамках навыка. Итак, у агента есть три задачи. Итак, триаж бэклога, убедитесь, что все правильно помечено, все находится в правильном состоянии, подготовьте очередь, то есть классифицируйте задачи по типу риска, а затем поддерживайте и отчитывайтесь. По сути, просто приведите все в порядок и убедитесь, что все в хорошем состоянии. А затем вы также можете видеть, что мы используем этот набор меток. Итак, у нас есть метка риска, у нас есть метка типа и метка маршрутизации. Итак, первая классификация риска будет указывать, является ли задача высокорискованной или низкорискованной. Вы не хотите, чтобы агенты работали над задачами с высоким риском или изменениями. Вы не хотите, чтобы они развертывали ваше программное обеспечение автономно. Вы, вероятно, не хотите, чтобы они сами принимали очень рискованные продуктовые решения. И у вас также есть тип задачи, так что вы можете видеть, является ли это ошибкой, изменением документации или рефакторингом. А затем вы также можете видеть эти две метки, которые являются критическими. Итак, готова ли эта задача для агента или требует ли эта задача человеческого вмешательства? Это позволяет вам вернуться к системе, дать свой отзыв, и тогда в следующий раз, когда агентский цикл запустится, он, очевидно, сможет перевести ее в состояние "готов к агенту". Итак, это своего рода уровень координации между вами как человеком и вашими ИИ-агентами, управляющими системой. Опять же, здесь требуется человеческое вмешательство. Это не заменяет человеческое суждение или человеческое мышление, но это позволяет вам иметь агентов, работающих над низкорискованными или простыми задачами, что просто массово увеличит вашу производительность и качество вашей кодовой базы, потому что агенты будут искать ошибки. Затем они будут проактивно исправлять вещи в вашей кодовой базе. Так что это довольно мощная концепция. Опять же, вам придется адаптировать это к вашему уровню риска. В некоторых компаниях и ситуациях вы, возможно, не захотите, чтобы агенты запускали этот цикл, но я думаю, что это довольно безопасно, потому что вы всегда проверяете pull request в конце. Итак, давайте посмотрим, что сделал агент. Итак, вы можете видеть здесь, что открыт pull request. Итак, какой именно? Итак, этот был открыт 2 минуты назад. Итак, это наш агент пишет pull request. Итак, что действительно мощно здесь, так это то, что вы будете просыпаться утром с кучей pull request. Надеюсь, с качественной работой, выполненной вашими агентами. По мере того, как вы правильно строите систему, эта работа будет пригодна для слияния. Вы запускаете проверки, вы проводите проверку кода, вы запускаете тесты, вы убеждаетесь, что ваша система делает все правильно. Вы можете видеть здесь файлы, измененные агентом. Итак, мы добавили этот тест в нашу систему. Это довольно простой пример. Мы просто добавляем дополнительный тест. Это тот тип вещей, где очень, очень просто, нет реального риска для слияния. Это очень низкий риск. Так что это идеальный тип задачи для агента. Простое улучшение вашей кодовой базы. Улучшение вещей, происходящее автономно 24/7. Вы заметите, что у меня есть дополнительные проверки. Итак, возвращаясь к этому пункту об ограничениях, когда вы создаете автономные системы ИИ, вам нужно много ограничений. Итак, ограничение, которое у нас есть здесь, заключается в том, что Codex будет выполнять какую-то автоматическую проверку кода. Так что даже когда агент отправляет PR, даже если агент проверил свою работу, у нас затем есть вторичная проверка кода. Вы могли бы встроить сюда другой инструментарий, такой как Greptile или Code Rabbit или любую другую автоматизацию для проверки качества кода. Вы могли бы запустить кучу автоматизированных тестов, все, что вам нужно. Но суть в том, что у агента есть второй рецензент, который является автоматизацией, проверяющей его работу практически каждый раз. Итак, это то, что позволяет нам запускать эти автономные системы. Если вас интересует эта тема, я дам вам ссылку на репозиторий навыков, который у меня называется Blueprint. И внутри вы найдете руководство по инженерии циклов в целом и моему мышлению по этому поводу. Вы можете видеть здесь, что у нас есть три фазы. У вас есть идеи. Итак, вы думаете о том, что хотите построить. Затем вы, по сути, создаете задачи. Вы создаете всю работу, которую нужно выполнить. Вы заставляете агента выполнять работу, а затем у вас есть своего рода проверка или обратная связь. Это действительно важно. И главное, о чем вы хотите думать при создании этих агентских систем сейчас, — это проверки качества. Вы не хотите, чтобы агенты сливали низкокачественную работу. Вам нужен этот цикл обратной связи, слой верификации. Это действительно, действительно важно. Если вас это интересует, у меня есть куча навыков здесь, а также куча руководств и документации по созданию автономных агентских систем и тому, как я это делаю сам. И вы можете видеть здесь, что у нас есть куча разных навыков. И поэтому то, что мы делаем, — это кодируем процесс, а не знания. Эти навыки очень легкие. Они в основном полагаются на интеллект агентов. Нам не нужно говорить агентам, как выполнять разработку на основе тестов. Они уже знают. Итак, в этом репозитории вы найдете кучу навыков, связанных с циклами. Итак, у нас есть различные типы циклов. У нас есть внутренний цикл, где мы берем задачу, а затем открываем pull request. Итак, если вы думаете о системах, если вы системный мыслитель, вход — это задача, а выход — pull request. Это уровень абстракции, на котором вы хотите думать, когда создаете автономного агента, вы хотите думать как системный мыслитель. Каков вход? Каков выход? А затем какова проверка качества? Многозадачность позволяет вам запускать несколько задач одновременно. Итак, вы можете видеть здесь, что у нас есть этот координатор многозадачности. Опять же, это просто шаблоны проектирования, которые вы можете принять. Итак, у нас есть список задач. У вас есть один основной агент, который действует как координатор, который затем запускает параллельные задачи или выполняет их последовательно. Суть в том, что основной агент, будь то Claude Code или Codex, основной агент координирует всю работу, а затем делегирует ее либо потокам Codex, либо субагентам Claude Code. Итак, у вас есть координатор, у вас есть эти работники, выполняющие всю работу, а затем вы, очевидно, открываете pull request и выполняете свой слой верификации. Итак, это действительно мощный рабочий процесс с замкнутым циклом, который позволяет вам масштабировать вашу агентскую инженерию. Что вы заметите, так это то, что эти циклы могут занимать много времени. Итак, по мере того, как агенты работают над этими задачами и становятся умнее и мощнее, эти агентские циклы будут работать все дольше и дольше. Итак, это может занять от часа до двух часов. Вы не хотите нянчиться с такими циклами. Они могут работать много-много часов. И поэтому мы всегда хотим иметь такие системы агентских циклов, и поэтому мы отходим от простого предоставления подсказок агентам в нашем терминале к тому, чтобы позволить агентам просто выполнять рабочий процесс, а затем мы можем просто просматривать работу. Это то, о чем говорили Борис и Питер. Агенты дают подсказки агентам, создают системы, создают циклы и выходят из цикла. Итак, последнее, о чем вы хотите подумать, когда создаете эти системы, — это действительно ограничения. Итак, вы можете видеть, насколько они мощны. Теперь у нас есть агенты, работающие над нашей кодовой базой 24/7. Они фактически выполняют работу для нас. У нас есть агентский цикл, который классифицирует все наши задачи. Это работает непрерывно, обеспечивая хорошее состояние нашего бэклога и проекта. Это своего рода выполнение работы менеджера по инжинирингу или технического лидера, триажирующего бэклог. А затем у вас есть другой агентский цикл, который фактически выполняет работу. Но ключевое, что нужно помнить, — это то, что вам нужны эти ограничения. У нас не было агентов, работающих над всем. У нас были агенты, работающие над небольшой частью работы. Это ключевой момент. Вы не хотите полностью выходить из процесса в определенных вещах. Вы всегда хотите проверять и принимать окончательное решение. Но чем больше ограничений вы установите и чем более тщательно вы будете проектировать системы, тем больше вы сможете позволить себе выйти из процесса. Итак, это действительно проблема системного дизайна. Итак, вы также хотите подумать об оценках. Итак, как вы узнаете, хорошо ли справляется эта система? Вы подумаете, сколько задач потребовалось переделать? Закрыли ли агенты задачу с первого раза? Правильно ли они написали код? [музыка] Или вам пришлось вернуться и дать много-много обратной связи? Итак, при проектировании этих систем вы хотите думать об оценках и ограничениях. Они, вероятно, являются критически важными частями для создания этих автономных систем, которые могут работать без присмотра. Без ограничений и без способа оценки работы агентов, >> [музыка] >> вы не сможете масштабировать этот шаблон. Но если вы сможете разобраться с этими вещами, то вы определенно сможете построить эти невероятные системы, способные автономно выполнять значительную часть вашего рабочего процесса с помощью ИИ-агентов. Итак, я надеюсь, вы найдете это полезным. Если у вас есть какие-либо комментарии или мысли по этому поводу, дайте мне знать в комментариях ниже. И увидимся в следующем.