Для устранения узкого места в виде людей создаются автономные агенты с инструментами и контекстом

Для устранения узкого места в виде людей создаются автономные агенты с инструментами и контекстом

Связка 1

Начальное состояние: Узким местом в разработке стали люди, которые вручную предоставляют моделям инструменты и контекст, ограничивая производительность и масштабирование работы агентов
Преобразование: Создание автономных облачных агентов с инструментами (AnyDev CLI), контекстом (упрощенная документация, онбординг-агент), зрением (доступ к приложениям и чатам) и возможностью запускать сервисы, что позволило им самостоятельно исследовать кодовую базу и выполнять задачи
Конечное состояние: Узкое место устранено: разработчики могут безопасно запускать множество автономных агентов в облаке, агенты самостоятельно справляются с задачами от A до D, а разработчики тратят время на создание систем, решающих задачи от A до Z

---

Speaker 0: Привет. Хорошо. Итак, модели становятся действительно хорошими. Для всё большего объёма работы узким местом больше не является интеллект модели. Узкое место — это люди, которые дают моделям инструменты и контекст, а также всё более амбициозные задачи и цели, чтобы они могли раскрыть свой потенциал.

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

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

Это приводит вас к третьему этапу — созданию системы, которая создаёт систему. То есть вместо того, чтобы тратить свой день на сопровождение агентов от задачи A до D, вы тратите это время на создание системы, которая может решать задачи от A до Z.

Итак, мы начали думать о том, как сделать наших агентов более способными.

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

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

Я знаю, что если бы мне пришлось работать таким образом, и я бы просто читал код с листа и не мог протестировать приложение, я бы, вероятно, тоже раздражал и бесил людей, которым приходилось тестировать за меня. Поэтому мы решили создать онбординг-агента. И мы создали облачного онбординг-агента. Любой может зайти на kurzu.com/onboard. Вы можете настроить свой репозиторий, и облачный онбординг-агент приступает к работе.

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

Итак, после того как агенты прошли онбординг, мы поняли, что работы еще немало, потому что у нас есть множество разработчиков, ежедневно запускающих множество облачных агентов, и любые проблемы умножаются на все эти запуски. Каждый раз, когда агенты запускаются, им приходится инициализировать среду разработки с нуля. При локальной разработке вы, вероятно, оставляете все работающим. Для облачных агентов это не так. Поэтому мы хотели оптимизировать их опыт разработки (dev x).

Они тратили много времени на ожидание запуска сервисов. У них не было хороших способов ожидания, поэтому мы создали инструмент AnyDev CLI. Теперь они могли запускать сервисы, ждать их запуска, проверять статусы. У них появился швейцарский нож для таких задач, как создание тестовых аккаунтов и вход в сервисы, сторонние сервисы и тому подобное. Мы заметили, что по мере улучшения сред разработки все больше разработчиков запускали больше облачных агентов и получали от этого больше пользы.

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

Итак, в ходе этого процесса мы выводим основные принципы автономии.

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

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

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

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

Сложность здесь не в том, чтобы кликнуть в нужное место. Сложность лучше объяснить так: если программирование — это как шахматы, где вы видите все фигуры на доске, то навигация по этим графическим интерфейсам больше похожа на видеоигру, где вы видите лишь небольшой фрагмент за раз. Есть необратимые решения. Есть состояния «конца игры», в которые можно попасть. Поэтому нужна метапознание более высокого уровня, умение возвращаться назад и навыки общего интеллекта, в которых семейство Claude действительно сильны.

Итак, Claude 4.7 — наша модель для использования компьютера. Вот пример: ей было поручено разработать функцию частного маркетплейса. Она записывает демо, где реализует все мелкие детали. У нас есть ввод URL, и нужно добавить CSP. И замечательно то, что она использует это не только для собственного сквозного тестирования, чтобы убедиться, что изменения работают. Вы, как разработчик, получаете возможность очень эффективно проверять работу агента, прежде чем углубляться в код. И это становится особенно ценным, когда вы запускаете множество таких агентов одновременно в облаке и переключаетесь между ними.

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

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

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

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

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

Но верно и обратное: когда вы вкладываетесь в них и заставляете их работать лучше, все хотят использовать их больше. Люди строят доверие к агентам. Они обнаруживают, что могут с одного раза решать всё более крупные задачи. И тогда они хотят вкладывать в это больше.

Так что это действительно важное изменение в том, как вы думаете о своей работе, когда вы как бы программируете систему. Вы онбордили своих агентов, дали им инструменты, чтобы сделать их действительно мощными, начали учиться использовать их и масштабировать, и увидели, где они дают сбой. Вы начали работать над этим циклом того, как научить их работать лучше. И мы поняли, что это снова начинает ощущаться как программирование. Итак, конечно, мы подумали: «Что ж, агенты должны делать это». У нас есть несколько способов, которыми мы пытаемся заставить агентов делать это. Это самый важный, и о нём я сегодня расскажу: агенты итеративно улучшают свои собственные рабочие процессы.

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

Все эти отчеты накапливаются в системе учета. Опять же, это очень похоже на то, как работают человеческие системы. Менеджеры просматривают все проблемы, классифицируют их, удаляют дубликаты и группируют в категории: технические проблемы, которые можно решить. Затем есть проблемы с разрешениями — у агентов просто нет доступа к чему-то, и им нужно получить разрешение. Есть проблемы незнания — агенты не знают, что делать, и им нужны люди, которые придут и скажут, как правильно решить проблему. И на последнем этапе, конечно, эти проблемы исправляются как агентами, так и людьми.

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

Итак, я приведу пару примеров.

Это наш самый важный навык. Навык WTF, что, конечно, расшифровывается как «Работа над фабрикой». И вы видите, что каждый облачный агент получает этот навык. И это почти тот же самый промпт, который я показывал на предыдущем слайде.

Работа над фабрикой — это идея о том, что когда что-то раздражает, сломано или сбивает с толку, вы уделяете время, чтобы сообщить об этом, чтобы мы могли улучшить инструменты и рабочие процессы, а не просто пробиваться сквозь трудности. Модели некоторое время назад не очень хорошо справлялись с этим, но сегодня они раздражаются, находят сломанные вещи, путаются, осознают это и сообщают об этом. Так мы получаем систему учёта, куда они отправляют все эти проблемы. Конечно, затем нужно решать проблемы, и это само по себе очень важная задача, если вы хотите, чтобы вся эта система была самоулучшающейся. И мы обнаружили, что при таких проблемах с опытом разработки агентов, попытки заставить агента просто решить их с одного раза были не очень эффективны, потому что в этих проблемах много нестабильности.

То есть что-то происходит лишь время от времени. И поэтому мы научили облачного агента, который решает проблему, запускать ещё несколько облачных агентов с изменением в опыте разработки и убеждаться, что во всём этом наборе для оценки есть надёжное решение. И тогда, когда проблема, когда решение, PR возвращается на проверку человеку, есть высокая степень уверенности, что это хорошо проверенное, хорошо проверенное решение. Это немного преждевременно. Да, я думаю, что это оба очень хороших примера того, как такие навыки могут работать как фоновые процессы сборки мусора или процессы очистки в операционной системе.

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

Ладно. А теперь слайд с благодарностями.

Если вы хотите узнать больше о самоулучшающихся системах идентификации, пожалуйста, поговорите со мной. Вы можете найти меня в X по моему имени. А если вы хотите дать свободу своим агентам, переходите на cursor.com/onboard и позвольте Claude познакомиться с вашей кодовой базой — возможно, вы выпустите свою следующую амбициозную функцию.

Большое спасибо.