How Claude Code Works - Jared Zoneraich, PromptLayer

[музыка] Итак, добро пожаловать на последний семинар. У вас получилось. Поздравляю. Из примерно 800 человек вы — последние выжившие, очень-очень преданные инженеры. Да, так вот, этот — странный. Я получил неприятности с Entropic из-за этого. Очевидно, из-за названия. Я сам дал ему название и спросил: «Хочешь изменить?» Он ответил: «Нет, я просто с этим смирюсь. Это довольно забавно». Так что, да, это официально не одобрено Copic, но мы же хакеры, верно? А Джаред очень предан. Он... И еще мне очень нравится представлять заметных людей из мира ИИ из Нью-Йорка, верно? Так что не думайте, что это единственное, чем занимается Джаред. У него есть целый стартап, о котором вы обязательно должны его спросить. Но, знаете, я очень рад представлять больше контента для местных жителей. Итак, Джаред, тебе слово. >> Большое спасибо. Большое спасибо. И какая потрясающая конференция. Очень жаль, что мы заканчиваем, но надеюсь, это будет хорошее завершение. И да, меня зовут Джаред. Это будет доклад о том, как работает Claude Code. Опять же, я не связан с Anthropic. Они мне не платят. Я бы взял деньги, но они не платят. Но мы также поговорим о нескольких других кодирующих агентах. И главная цель, о которой я расскажу, — это то, что я лично, я — большой пользователь всех кодирующих агентов, как и все здесь. И они в последнее время взорвались, и как разработчик, мне было интересно, что изменилось, что сделало кодирующих агентов наконец хорошими. Итак, начнем. Я начну с себя. Я Джаред. Вы можете найти меня, я Джаред Z в X, в Твиттере, где угодно. Я строю рабочее место для инженеров ИИ. Так что моя компания называется Prompt Layer. Мы находимся в Нью-Йорке. Вы можете увидеть наш офис здесь. Это такое маленькое здание. Оно загорожено несколькими другими зданиями. Так что мы — небольшая команда. Мы запустили продукт 3 года назад. Так что долго для ИИ, но мало для всего остального. И да, наша основная идея заключается в том, что мы верим в строгий инжиниринг промптов, строгую разработку агентов, и мы верим, что команда продукта должна быть вовлечена, команда инженеров должна быть вовлечена. Мы считаем, что если вы строите ИИ-юристов, в этом должны участвовать юристы, а также инженеры. Так что вот чем мы занимаемся. Обрабатываем миллионы запросов LM в день. И многие выводы в этом докладе основаны на разговорах с нашими клиентами о том, как создавать кодирующих агентов и тому подобное. И также не стесняйтесь, в ходе доклада мы можем сделать его неформальным. Так что, если я что-то скажу, и у вас возникнет вопрос, не стесняйтесь задать его. И я провожу много времени, «употребляя» свой продукт. Это своего рода странная работа основателя в наши дни, потому что это наполовину запуск агентов, а наполовину использование моего собственного продукта для создания агентов, и это кажется странным, но это своего рода весело. И да, последнее, что я добавлю, — я большой энтузиаст. Мы буквально перестроили нашу инженерную организацию вокруг облачного кода. Я думаю, что самое сложное в создании платформы — это то, что вам приходится иметь дело со всеми этими крайними случаями, и о, мы загружаем наборы данных сюда, это не работает, и вы можете умереть от тысячи порезов. Поэтому мы установили правило для нашей инженерной организации: если вы можете что-то завершить менее чем за час, используя облачный код, просто сделайте это. Не приоритизируйте это. И мы намеренно небольшая команда, но это нам очень помогло, и я думаю, это действительно вывело нас на новый уровень. Так что я большой поклонник, и давайте углубимся в то, как это работает. Итак, это то, что, как я уже говорил, является целью этого доклада. Во-первых, почему это взорвалось? В чем заключалась инновация? Изобретение, которое сделало кодирующих агентов наконец рабочими? Если вы немного разбираетесь в этой области, вы знаете, что в начале многие из этих автономных кодирующих агентов были ужасны, и мы все пытались их использовать. Но это день и ночь. Мы углубимся во внутренние детали, и, наконец, все в этом докладе ориентировано на то, как создавать собственных агентов и как использовать это для самостоятельного инжиниринга ИИ. Итак, давайте немного поговорим об истории. Как мы сюда попали? Все знают, что все началось с рабочего процесса, когда вы просто копировали и вставляли свой код из ChatGPT туда и обратно, и это было здорово, и это было своего рода революционно, когда это произошло. Шаг второй, когда появился Cursor, если мы все помним, это было не очень хорошее программное обеспечение в начале. Это был просто форк VS Code с командой K, и мы все это любили. Но теперь мы больше не будем использовать команду K. Затем у нас появился помощник Cursor. Так что этот маленький агент туда и обратно, а затем облачный код. И честно говоря, за последние несколько дней с момента создания этого слайда, возможно, появилась новая версия, о которой мы могли бы поговорить. И в конце я расскажу о том, что дальше. Но вот как мы сюда попали. И это действительно, я думаю, облачный код — это своего рода безголовый, даже не этот новый рабочий процесс, когда вы даже не касаетесь кода. И он должен быть действительно хорошим. Так почему же он так хорош? В чем был большой прорыв? Давайте попробуем выяснить. И еще раз, это все мое мнение, и то, что я считаю прорывом. Возможно, есть и другие вещи, но простая архитектура. Я думаю, многое было упрощено в дизайне агента, а затем лучшие модели, лучшие модели и лучшие модели. Я думаю, что большая часть прорыва скучна, потому что Anthropic просто выпускает лучшую модель, которая лучше работает для таких вызовов инструментов и подобных вещей. Но простая архитектура связана с этим. Так что мы можем углубиться в это. Архитектура, и это наш маленький, вы увидите, наш маленький талисман для нашей компании — это наш «жонглер промптов». Так что мы сделали много графики для этих слайдов, но, по сути, дайте ему инструменты, а затем отойдите в сторону — это однострочное описание архитектуры сегодня. Я думаю, если вы немного занимались разработкой на основе LM, это не всегда было так. Очевидно, вызовы инструментов существовали не всегда, и вызовы инструментов — это своего рода новое абстрагирование для форматирования JSON, и если вы помните библиотеки GitHub, такие как JSON former и тому подобное в старые времена, но дайте ему инструменты, отойдите в сторону. Модели созданы для этого и обучаются быть лучше в вызовах инструментов и в этом. Так что чем больше вы хотите оптимизировать, а каждый инженер, включая меня, особенно я, любит оптимизировать, и когда у вас впервые появляется идея, как создать агента, вы садитесь и говорите: «О, а затем я предотвращу эту галлюцинацию, сделав этот промпт, а затем этот промпт, а затем этот промпт». Не делайте этого, просто простой цикл, отойдите в сторону и просто удалите каркас, и меньше каркаса, больше модели — это своего рода девиз здесь, и, знаете, это таблица лидеров с этой недели. Очевидно, эти модели становятся все лучше и лучше. Мы могли бы провести целый разговор, и я уверен, что было много разговоров о том, замедляется ли это, плато ли это. Для этого доклада это не имеет значения. Мы знаем, что это становится лучше, и они становятся лучше в вызовах инструментов, и они становятся лучше оптимизированными для автономной работы. И не делайте этого, я думаю, Anthropic называет это «пилюлей AGI». Способ мышления — не пытайтесь переинженерить недостатки модели сегодня, потому что многое просто улучшится, и вы будете тратить время впустую. Итак, вот философия, как я вижу облачный код, игнорируя вложения, игнорируя классификаторы, игнорируя сопоставление пар. У нас была вся эта RAG-штука, на самом деле Cursor немного возвращает RAG, и как они это делают, и они смешивают и сопоставляют. Но я думаю, гениальность облачного кода в том, что они отбросили все это и сказали: «Нам не нужны все эти модные парадигмы, чтобы обойти то, что модель плоха». Давайте просто сделаем лучшую модель, а затем дадим ей «готовить» и просто опираться на эти вызовы инструментов и упрощать вызовы инструментов, что является очень важной частью. Вместо рабочего процесса, где мастер-промпт может разбиться на три разных ветви, а затем перейти в четыре разных ветви, на самом деле есть всего несколько простых вызовов инструментов, включая GP вместо RAG, и да, и на этом он обучен. Так что это очень оптимизированные модели для вызова инструментов. Итак, это «Дзен Python», если вы знакомы, если вы импортируете это в Python. Мне очень нравится эта философия, когда дело доходит до создания систем, и я думаю, что она очень подходит для того, как был создан облачный код. Так что действительно, простое лучше, чем сложное, сложное лучше, чем запутанное, плоское лучше, чем вложенное. Это все, что вам нужно, это весь доклад. Это все, что вам нужно знать о том, как работает облачный код и почему он работает, особенно то, что мы возвращаемся к инженерным принципам, таким образом, простой дизайн — лучший дизайн. Я думаю, это верно, независимо от того, создаете ли вы схему базы данных, но это также верно при создании этих автономных кодирующих агентов. Итак, я сейчас разберу все конкретные части этого кодирующего агента и почему я считаю их интересными. Первое — это конституция. Теперь многое из этого мы принимаем как должное, хотя они начали делать это месяц или два назад, или, может быть, три или четыре месяца назад. Так что это облачный MD CodeX или другие используют агентов MD. Интересно то, что я предполагаю, большинство из вас знает, что это такое. Опять же, это там, где вы помещаете инструкции для вашей библиотеки. Но интересно то, что это, по сути, команда, говорящая, что нам не нужно переинженерить систему, где модель сначала исследует репозиторий, а Cursor, как Cursor 1.0, как вы знаете, создает локальную векторную базу данных для понимания репозитория и проводит все эти исследования. Они просто говорят: «А, просто поместите файл Markdown. Пусть пользователь меняет вещи, когда ему нужно. Пусть агент меняет вещи, когда ему нужно. Очень просто, и это возвращается к инжинирингу промптов, к которому я немного предвзят, потому что Prompt Layer — это платформа для инжиниринга промптов, но в конечном итоге все — это инжиниринг промптов или инжиниринг контекста. Все сводится к тому, как вы адаптируете эти универсальные модели для своего использования. И самый простой ответ здесь, я думаю, лучший. Так что это ядро системы. Это просто простой главный цикл. И это на самом деле своего рода революционно, учитывая, как мы раньше строили агентов. Все в облачном коде и во всех кодирующих агентах сегодня, CodeX и новый Cursor, и AMP, и все остальное, это просто один цикл while с вызовами инструментов, просто запускающий главный цикл while, вызывающий инструменты и возвращающийся к главному циклу while. Это, по сути, четыре строки того, что называется. Я думаю, они называют это N0 внутри, по крайней мере, на основе моих исследований, но пока есть вызовы инструментов, запускайте инструмент, передавайте результаты инструмента модели и повторяйте, пока нет вызовов инструментов, а затем спрашивайте пользователя, что делать. В первый раз, когда я сделал это, в первый раз, когда я использовал вызовы инструментов, я был очень шокирован тем, что модели так хорошо знают, когда продолжать вызывать инструмент и когда исправлять свою ошибку. И я думаю, что это одна из самых интересных вещей в LM — они действительно хороши в исправлении ошибок и гибкости. И чем больше вы опираетесь на модель для исследования и выяснения, тем лучше и надежнее будет ваша система при работе с лучшими моделями. Итак, это основные инструменты, которые у нас есть в облачном коде сегодня. И, честно говоря, они меняются каждый день, вы знаете, они выпускают новые версии каждые несколько дней, но это основные, которые я нашел наиболее интересными для обсуждения. Завтра их может быть 15, завтра их может быть 5, но это то, что я считаю интересным. Итак, во-первых, чтение. Да, они могут просто сделать cat. Но интересно то, что при чтении у нас есть ограничения по токенам. Так что, если вы много использовали облачный код, вы видели, что иногда он говорит, что этот файл слишком большой или что-то в этом роде. Вот почему стоит создать этот инструмент чтения. Grep glob. Это тоже очень интересно, потому что это противоречит многим советам того времени по использованию RAG и векторов. И я не говорю, что RAG не имеет места, кстати. Но в этих универсальных агентах GP хорош, и GP — это то, как пользователи бы это делали. И я думаю, что это на самом деле важный момент. Когда я говорю об этих инструментах, помните, что это все человеческие задачи. Мы не создаем совершенно новый инструмент для использования моделью. Мы просто имитируем действия человека и то, что вы и я бы сделали, если бы были за терминалом и пытались решить проблему. Редактирование. Редактирование имеет смысл. Я думаю, интересно отметить, что при редактировании используются diffы, и файлы не переписываются большую часть времени. Гораздо быстрее, гораздо меньше контекста используется, но также гораздо меньше проблем. Если бы я попросил вас, если бы я дал вам эти слайды и попросил вас просмотреть слайды, и вы прочитали бы их и должны были бы записать все слайды для меня в своих новых редакциях, по сравнению с тем, если бы вы могли просто вычеркивать вещи на бумаге, вычеркивать гораздо проще. Diff — это естественный способ предотвратить ошибки. Bash. Bash — это основная вещь. Я думаю, вы могли бы избавиться от всех этих инструментов и оставить только bash. И в первый раз, когда я увидел это, когда вы запускаете что-то в облачном коде, и облачный код создает файл Python, а затем запускает файл Python, а затем удаляет файл Python, в этом красота того, почему это работает. Так что bash — самое важное. Я бы сказал, веб-поиск, веб-запрос. Интересно то, что они перемещают это на более дешевую и быструю модель. Так, например, если вы создаете какой-то агент на своей платформе, и вы создаете агента, и ему нужно подключиться к некоторым конечным точкам, к списку конечных точек, возможно, стоит перенести это на своего рода более низкий уровень, а не на этот главный цикл while. Вот почему это отдельный инструмент. To-dos. Мы все видели to-dos. Поговорим об этом немного позже, но удержание модели на правильном пути, управляемость, а затем задачи. Задачи — это очень интересно. Это управление контекстом. Как мы запускаем этот долгий процесс, читаем весь файл, не загромождая контекст? Потому что главный враг здесь — когда ваш контекст заполнен, модель становится глупой, если можно так выразиться. Так что, по сути, bash — это все, что вам нужно. Я думаю, это единственное, на чем я хочу сосредоточиться. Удивительно в bash для кодирующих агентов две вещи. Первая — это простота, и он делает все. Он очень надежен. Но вторая, столь же важная вещь, заключается в том, что на нем так много обучающих данных, потому что именно это мы используем. Это причина, по которой модели не так хороши в Rust или менее распространенных языках программирования, просто потому, что меньше людей этим занимаются. Так что это действительно универсальный адаптер. Вы, тысячи инструментов, вы можете сделать что угодно. Это тот пример с Python, который я привел. Я всегда нахожу это очень крутым, когда он делает скрипт Python или создает тесты, и я всегда должен просить его не делать этого. Но все эти оболочечные инструменты в нем. И это, я имею в виду, я сам использую облачный код для запуска локальных сред, где обычно у меня было бы пять команд, написанных в каком-то файле, а затем они устаревают. Он действительно хорошо справляется с выяснением этих вещей и запуском того, что вы хотели бы сделать. И он специально позволяет модели пробовать вещи. Так что да, другие предложения здесь и использование инструментов. Я думаю, есть небольшой системный промпт, который говорит ему, какой инструмент использовать и когда использовать какой инструмент вместо другого, и это часто меняется, но это своего рода крайние случаи и углы, в которых модель застревает. Чтение перед редактированием. Они на самом деле заставляют вас делать это, используя инструмент GP, а не bash. Так что, если вы посмотрите на список инструментов здесь, есть специальный инструмент GP. Может быть много причин для этого. Я думаю, безопасность — одна из главных, и песочница, а затем также просто ограничение по токенам, выполнение независимых операций параллельно. Так что своего рода подталкивание модели к этому большему. А также такие тривиальные вещи, как кавычки путей с пробелами. Это просто обычные, обычные вещи. Я уверен, что они просто «употребляют» много в Anthropic, и они находят это, и они говорят: «Хорошо, мы добавим это в системный промпт». Хорошо, давайте поговорим о списках дел. Опять же, очень распространенная вещь, но раньше ее не было. Так что это на самом деле, я думаю, список дел из моего исследования для этой презентации. Но действительно интересная вещь в списках дел заключается в том, что они структурированы, но не структурно принудительны. Итак, вот правила. Одна задача за раз. Отмечайте их как выполненные. Это то, что вы бы ожидали. Продолжайте работать над тем, что в процессе, если есть блокировки или ошибки, и разбивайте задачи на разные инструкции. Но самое интересное для меня — это то, что это не принуждается детерминированно. Это чисто на основе промпта. Это чисто в системном промпте. Это чисто потому, что наши модели теперь хорошо следуют инструкциям. И это не сработало бы год назад. Это не сработало бы два года назад. В системном промпте есть описания инструментов наверху. Мы как бы внедряем списки дел в системный промпт. Их нет, но это не принуждается в реальном коде, и опять же, возможно, есть другие агенты, которые идут противоположным путем. Мне просто показалось это довольно интересным, что это, по крайней мере, как для пользователя, имеет большое значение, и кажется, что это было очень просто реализовать, почти как проект на выходные, который кто-то сделал, и кажется, что это сработало. Могу ошибаться насчет этого, но... Так что да, это буквально вызов функции. Это первый раз, когда вы что-то спрашиваете, рассуждение экспортирует этот блок дел, и я покажу вам структуру на следующем слайде. Там есть идентификаторы. Есть какая-то структурированная схема и детерминизм, но это просто вставлено туда. Вот пример того, как это может выглядеть. Вы получаете версию, вы получаете свой идентификатор, заголовок задачи, и тогда она может фактически вставлять доказательства. Это, казалось бы, произвольные блоки данных, которые она может использовать. И идентификаторы — это хеши, на которые она может ссылаться, заголовок — что-то, что человек может прочитать, но это просто еще один способ структурировать данные. И точно так же, как вы организуете свой стол, когда работаете, мы пытаемся организовать модель. Так что я думаю, что есть, это своего рода четыре преимущества, которые мы получаем. Мы заставляем ее планировать. Мы можем возобновить работу после сбоев. Облачный код терпит неудачу. Я думаю, UX — большая часть этого. Как пользователь, вы знаете, как это происходит. Это не просто работает в цикле 40 минут без каких-либо сигналов для вас. Так что UX не является незначительным. Хотя UX может не сделать его лучшим кодирующим агентом, он может сделать его лучше для всех нас в использовании. И управляемость. Итак, вот еще две части, которые были «под капотом». Асинхронный буфер, они назвали его H2A. Это своего рода процесс ввода-вывода и как отделить его от рассуждений и как управлять контекстом таким образом, чтобы вы не просто запихивали все, что видите в терминале, и все обратно в модель, что опять же, контекст — наш главный враг здесь. Это сделает модель глупее. Так что нам нужно быть немного умными в этом и в том, как мы сжимаем и как мы суммируем. Так что здесь вы видите, когда он достигает емкости, он как бы отбрасывает середину, суммирует начало и конец. Затем у нас есть этот компрессор контекста. Итак, каков предел? 92% кажется чем-то вроде этого. И как он сохраняет долгосрочное хранение? Это на самом деле еще одно преимущество bash, на мой взгляд, и наличие песочницы. Я бы даже сделал прогноз, что все ваши окна чата GPT, все окна Claude в ближайшем будущем будут поставляться с песочницей. Это просто намного лучше, потому что вы можете хранить эту долгосрочную память. И я делаю это все время. У меня есть навыки облачного кода для глубоких исследований и тому подобного. И я всегда инструктирую его сохранять файлы Markdown, потому что чем короче контекст, тем быстрее он и тем умнее он. Так что это то, что меня больше всего волнует. Нам не нужны DAG-и, как эти. Я дам вам реальный пример. Некоторые пользователи Prompt Layer, разные агенты, такие как агент поддержки клиентов, в основном все строили DAG-и, подобные этому, последние два-два с половиной года. И это было безумие. Сотни узлов: «Хорошо, если этот пользователь хочет вернуть деньги, направьте его к этому промпту, если он хочет этого» и много классифицирующих промптов. Преимущество этого в том, что вы можете гарантировать, что не будет галлюцинаций, или гарантировать, что не будет возвратов тем, кто не должен их получать, или своего рода решение проблемы инъекции промптов, потому что если вы находитесь в промпте, который чисто классифицирует его как X или Y, инъекция не имеет значения, особенно если вы отбрасываете контекст. Теперь мы как бы возвращаем этот вектор атаки, но главное преимущество в том, что нам не приходится иметь дело с этой паутиной инженерного безумия, и это просто в 10 раз проще разрабатывать эти вещи, в 10 раз более поддерживаемо, и это действительно работает намного лучше, потому что наши модели теперь просто хороши. Так что это, это своего рода вывод: полагайтесь на модель. В случае сомнений, не пытайтесь продумать каждый крайний случай и продумать каждое условие. Просто полагайтесь на модель, чтобы исследовать и выяснить. И я на самом деле два дня назад, думаю, или вчера, на этой неделе, я проводил эксперимент на нашей панели, чтобы добавить, пытаясь использовать эти браузерные агенты. И я хотел посмотреть, могу ли я добавить небольшие заголовки ко всем нашим кнопкам, и поможет ли это агенту автоматически ориентироваться на нашем веб-сайте. И это на самом деле ухудшило ситуацию, как ни странно. И, возможно, я могу запустить его снова, и, возможно, я что-то сделал неправильно с этим тестом, но это сделало навигацию по Prompt Layer для агента хуже, потому что он отвлекался, потому что я говорил ему: «Ты должен нажать эту кнопку, потом ты должен нажать эту кнопку», а потом он не знал, что делать. Так что лучше полагаться на исследование. У вас есть вопрос? >> Да, я немного возражу. >> Пожалуйста. Я признаю, что любой каркас, который мы создаем сегодня для решения особенностей ограничений, будет устаревшим через 3-6 месяцев, даже если это так, они немного помогают сегодня. Как вы балансируете это, как потраченное впустую инженерное время для решения проблемы, которая у нас есть только три месяца? >> Это отличный вопрос. Итак, чтобы повторить вопрос: каков компромисс между решением реальных проблем, которые у нас есть сегодня, и тем, что вы полагаетесь на модель, которая еще не может этого сделать, но сможет через три месяца, верно? Это зависит от случая. Зависит от того, что вы строите. Если вы строите чат-бот для банка, вы, вероятно, хотите быть немного более осторожным. Для меня золотая середина — использовать эту парадигму агента главного цикла while и вызовов инструментов, но сделать ваши вызовы инструментов очень строгими. Так что, я думаю, нормально иметь вызов инструмента, который выглядит так или выглядит как половина этого, так же, как облачный код использует чтение в качестве вызова инструмента или GP в качестве вызова инструмента. Так что для крайних случаев поместите это в структурированный инструмент, который вы затем можете оценить и версионировать и тому подобное. И я могу поговорить, я немного больше об этом позже, но поместите это в этот структурированный инструмент. Но для всего остального, для фазы исследования, оставьте это модели или добавьте системный промпт. Так что это компромисс, и он очень зависит от конкретного случая использования, но я думаю, это хороший вопрос. Спасибо. Итак, да, возвращаясь к облачному коду. Мы избавляемся от всего этого. Мы говорим, что нам не нужен обнаружение намерений на основе машинного обучения. Нам не нужны реаксы. Нам не нужны, я имею в виду, он немного использует реаксы, но нам не нужны реаксы, встроенные в него. Нам не нужны классификаторы. И долгое время мы на самом деле создавали продукт для Prompt Layer. Мы никогда его не выпускали, потому что существует только прототип использования классификатора на основе машинного обучения, а не LM, в вашем конвейере промптов. Многие люди добиваются большого успеха с этим, но все больше и больше кажется, что это не будет очень полезно, если только стоимость не является для вас огромной проблемой. И даже тогда стоимость — это меньшие модели, которые становятся все меньше и меньше, поскольку финансовый инжиниринг между всеми этими компаниями оплачивает наши токены. Так что Claude также делает эту умную вещь, я думаю, с триггерными фазами. Вы знаете, у вас есть «думай», «думай усердно», «думай еще усерднее», а «ультра-думай» — мой любимый. И это позволяет нам использовать бюджет рассуждений, бюджет токенов рассуждений как еще один параметр, который модель может регулировать. И это на самом деле модель может регулировать это, но именно так мы заставляем ее регулировать. И вместо этого вы могли бы сделать вызов инструмента для сложного планирования. И на самом деле, некоторые кодирующие агенты делают это. Или вы можете позволить пользователю указать это, а затем просто изменить это на лету. Итак, это одна из самых больших тем здесь. Песочница и разрешения. Я буду совершенно честен, это самая скучная часть для меня, потому что я половину времени запускаю ее в режиме YOLO. Некоторые люди в нашей команде фактически отказались от всех своих локальных баз данных. Так что вам действительно нужно быть осторожным. Так что мы не используем режим YOLO с нашими корпоративными клиентами, очевидно, но я думаю, что эти вещи, кажется, будут решены, но нам нужно немного знать, как это работает. Итак, есть большая проблема с инъекцией промптов из Интернета. Если вы подключаете этого агента, у которого есть доступ к оболочке, и вы выполняете веб-запрос, это довольно большой вектор атаки. Так что есть некоторая контейнеризация этого. Есть блокировка URL-адресов. Вы можете видеть, что облачный код довольно раздражает по поводу «Могу ли я получить данные с этого URL?», «Могу ли я сделать это?», и он как бы помещает это в под-агента. И да, большая часть сложного кода находится в этом наборе песочницы и разрешений. Я думаю, есть целый конвейер для ограничения команд bash. Так что в зависимости от префикса он проходит через среду песочницы, и многие другие модели работают здесь по-другому. Но именно так работает облачный код. Я объясню другие позже в конце. Следующая тема, имеющая отношение к делу, — это под-агенты. Итак, это возвращение к управлению контекстом и этой проблеме, к которой мы постоянно возвращаемся: чем длиннее контекст, тем глупее наш агент. Это ответ на нее. Так что используйте под-агентов для конкретных задач, и ключ к под-агенту — у него есть свой собственный контекст, и он возвращает только результаты, и именно так вы не загромождаете его. Итак, у нас есть исследователь, читатель документации, тестировщик, рецензент кода. В примере, о котором я говорил ранее, когда я добавил все теги на наш веб-сайт, чтобы агент мог сделать это лучше, я, очевидно, использовал кодирующего агента для этого, и я сказал: «Сначала прочитай нашу документацию, а затем сделай это», и он сделает это в под-агенте. Он вернет информацию, и главное здесь — это форки агента и то, как мы агрегируем их обратно в наш основной контекст. Вот пример. Я думаю, это очень интересно. Я хочу выделить пару вещей. Итак, задача — это то, чем является под-агент. Мы даем задаче две вещи: описание и промпт. Описание — это то, что увидит пользователь. Так что вы скажете: «Задача: найти стандартную инстанциацию контекста чата» или что-то в этом роде. А затем в промпте вы дадите длинную строку, что очень интересно, потому что теперь у нас есть кодирующий агент, который сам промптирует своих агентов. И я на самом деле использовал эту парадигму в агентах, которые я создал для нашего продукта. Если вы можете, вы можете просто заставить агента запихнуть столько информации, сколько он хочет, в эту строку. И если мы возвращаемся к опоре на модель, если эта задача возвращает ошибку, теперь запихните еще больше информации и позвольте ей решать проблемы. Лучше быть гибким, чем жестким. Если бы я строил это, я бы рассмотрел возможность замены строки на объект, возможно, в зависимости от того, что вы строите, и, возможно, позволил бы ей фактически давать более структурированные данные. Да. Так что я вижу, что этот промпт содержит довольно несколько предложений. Это в основном агенте? Он использует контекст основного агента, или есть какой-то промежуточный шаг, где под-агент дважды читает то, что делает основной агент, а затем генерирует? >> Правильно. Так вопрос в том, получает ли задача только промпт здесь, или она также получает вашу историю чата? Это вопрос? Вопрос в том, является ли все это системным промптом основного агента, чтобы информировать, как он промптирует под-агента? >> Нет. Нет. Как это не в системе. Это во всем контексте. Является ли весь этот контекст основного агента, который вызывает задачу, или вы говорите о структуре для задачи? >> Весь этот JSON, верно? Или >> Да. Так что это вызов инструмента. Так что структура вызова инструмента того, что такое задача, находится в основном агенте. А затем они генерируются на лету. Так что, когда вы хотите выполнить задачу, она генерирует описание и промпт. Задача — это вызов инструмента. Они могут выполняться параллельно, а затем возвращают результаты. Надеюсь, это поможет. Итак, мы можем вернуться к системному промпту. Так что есть некоторые утечки системного промпта облачного кода. Так что именно на этом я основываюсь. Вы можете найти его онлайн. Вот некоторые вещи, которые я отметил в нем. Краткие выводы. Очевидно, не давайте ничего слишком длинного. Нет, я просто сделаю задачу, которую хочет пользователь. Скорее подталкивает его к использованию инструментов больше, чем текстовых объяснений. Очевидно, я думаю, когда мы, мы все создавали кодирующих агентов, и когда мы это делаем, обычно говорится: «Эй, я хочу запустить этот SQL». Нет, подтолкните его к использованию инструмента. Соответствие существующему коду, а не добавление комментариев. Это у меня не работает, но интенсивное выполнение команд параллельно, а затем списки дел и тому подобное. Есть много вещей, которые вы можете подтолкнуть его делать с помощью системных промптов. Но, как вы видите, я думаю, есть действительно интересный момент в вашем предыдущем вопросе о том, где, каков компромисс между DAG и циклами. Многие из этих вещей, как вы видите, кажутся пришедшими от кого-то, кто использовал облачный код и сказал: «О, если бы только он делал это немного меньше, или если бы он делал это немного больше». Вот где приходит промптинг, потому что так легко итерировать, и это не жесткое требование, но если бы только он сказал: «Вот немного больше». Иногда можно сказать, но хорошо, навыки. Навыки — это здорово. Это немного новее. Я, честно говоря, убедился в этом только недавно. Так что хорошо. Я построил эти слайды с навыками. Это, по сути, я думаю, в контексте этого доклада об архитектуре, давайте думать об этом как о расширяемом системном промпте. Так же, как мы не хотим загромождать контекст, есть много разных типов задач, которые вам нужно будет выполнять, где вы хотите гораздо больше контекста. Так что вот как мы даем облачному коду несколько вариантов того, как он может получить доступ к большей информации. Вот несколько примеров. Я использую это для обновлений документации, чтобы сообщить ему мой стиль письма и мой продукт. Так что, если я хочу обновить документацию, я говорю: «Используй этот навык». Загрузи этот навык. Редактирование Microsoft Office, Microsoft Word и Excel. Я не использую это, но я видел, как многие люди это используют. Это своего рода декомпилирует f, это очень круто. Но это позволяет облачному коду делать это, руководство по стилю дизайна. Это распространенный случай. Глубокое исследование. Я на днях вставил статью или репозиторий GitHub о том, как работает глубокое исследование, и сказал: «Перестрой это как навык облачного кода». Это работает так хорошо, это потрясающе. Так что унифицированное дифференцирование, я думаю, это заслуживает отдельного слайда. Это очень очевидно, вероятно, не так много, о чем нам нужно говорить здесь, но это делает это намного лучше, и это делает ограничение по токенам короче. Это делает его быстрее и менее подверженным ошибкам, как я привел пример с переписыванием эссе вместо того, чтобы отмечать его красной линией. Это просто лучше. Я настоятельно рекомендую использовать дифференцирование в любых агентах, которые вы создаете. Унифицированное дифференцирование — это стандарт. Когда я смотрел на многие из этих кодирующих агентов, некоторые фактически создали свой собственный стандарт, и как бы с небольшими вариациями унифицированного дифференцирования, потому что вам не всегда нужны номера строк, но унифицированное дифференцирование работает. У вас был вопрос? >> Чтобы вернуться к навыкам. Я, я не знаю, видел ли кто-нибудь предупреждение облачного кода, и желтым текстом, если ваш облачный код имеет более 40 тысяч символов. Так что я подумал: «Хорошо, я наверху. Давайте разберем это на навыки». Так что я потратил некоторое время, а затем Claude проигнорировал все мои навыки, и я поместил их в некоторые. Так что я? Я не знаю. Навыки [кашляет] кажутся глобально неправильно понятыми или как будто я не знаю, что-то упускаю. Помогите мне понять. [смех] >> Да. Так что вопрос был о том, хорошо, системный облачный MD код предупреждает вас, когда он слишком длинный. Так что вы переместили его в навыки, а затем он не распознает навыки и не подбирает их, когда они нужны. >> Да, обратитесь к команде Anthropic, я бы сказал. Но это также хороший пример того, что, возможно, системный промпт >> это было намерение, как навыки, вам нужно их вызывать, и как бы агент сам не должен их вызывать все время, >> правильно? Он дает описание каждого навыка модели, или должен, говорит ему, вот однострочное описание каждого навыка. Так что теоретически в идеальном мире он подбирал бы все навыки все время. Но вы правы, я обычно должен вызывать навык сам вручную. Но я думаю, что это хорошая связь с тем, когда промптинг является правильным решением, или когда DAG является правильным решением, или, возможно, это проблема обучения модели. Возможно, им нужно немного больше сделать после обучения, чтобы модель вызывала навыки, почти как вызов инструмента. Вы должны знать, когда его вызывать. Так что, возможно, это просто функциональность, которая еще не очень хороша, но я думаю, что парадигма очень интересна, но она не идеальна, как мы узнаем. Так что дифференцирование, мы только что говорили о том, что дальше. Так что это больше основано на мнении, но куда, по моему мнению, движутся эти вещи и где, вероятно, будут следующие инновации. Я думаю, здесь есть две школы мысли. Многие люди думают, что у нас будет один главный цикл с сотнями вызовов инструментов, и просто вызовы инструментов станут намного лучше. Это очень вероятно. Я придерживаюсь альтернативной точки зрения, что, по моему мнению, нам нужно максимально сократить вызовы инструментов и просто вернуться к bash, и, возможно, даже поместить скрипты в локальный каталог. Я думаю, я сторонник одного мега-вызова инструмента вместо множества вызовов инструментов. Возможно, не на самом деле один. Я на самом деле думаю, что слайд, который я показал вам раньше, вероятно, является хорошим списком, но многие люди думают, что нам нужны сотни вызовов инструментов. Я просто не думаю, что это туда идет. Адаптивные бюджеты, корректировка рассуждений, мы делаем это немного, «думай» и «ультра-думай» и тому подобное, но я думаю, что модели рассуждений как инструмент имеют большой смысл как парадигма. Можете ли вы использовать, я думаю, многие из нас пойдут на компромисс с моделью в 20 раз быстрее с немного более глупыми результатами и смогут вызвать вызов инструмента для очень хорошей модели. Я думаю, это компромисс, на который мы пойдем во многих случаях. Возможно, не наш планировщик. Возможно, мы сначала пойдем к планировщику с GPD 51 CodeX или Opus, или что бы там ни было, когда выйдет новый Opus. Но я думаю, я думаю, есть много смешивания и сопоставления, которое мы можем сделать, и это, я думаю, следующая граница, и я думаю, последняя граница. Я думаю, есть многому, чему мы можем научиться из списков дел и новых первоклассных парадигм, которые мы можем построить. Навыки — это еще один пример первоклассной парадигмы, которую мы можем попытаться построить, возможно, она не работает идеально, но я думаю, что есть много новых открытий, которые можно сделать там, на мой взгляд. Есть ли они у меня? Я не знаю. Итак, теперь я хочу, для последней части этого доклада, поговорить о другой границе агентов и других философиях, которые они разработали, философиях, которые они выбрали, и у нас всех есть преимущество, мы можем смешивать и сопоставлять, когда мы строили нашего агента, мы могли делать все, что хотели, и учиться у лучших, а лабораторные границы очень хороши в этом. Итак, что-то, к чему я люблю возвращаться, я называю это проблемой «терапевта ИИ», возможно, есть лучшее название, но я считаю, что есть много проблем, самые интересные проблемы ИИ вокруг. Нет глобального максимума. То есть, мы в Нью-Йорке. Если мне нужен терапевт, их шесть на каждом квартале здесь. Нет глобального ответа на то, какой терапевт лучший. Есть разные стратегии. Есть терапевт, который занимается медитацией или КПТ, или, возможно, тот, кто дает вам аяваску. И это просто своего рода разные стратегии для одной и той же цели, так же, как если вы строите терапевта ИИ, нет глобального максимума. Это своего рода мой анти-AGI подход, но это также подход, который говорит, что при создании этих приложений вкус играет большую роль, и архитектура дизайна имеет большое значение. У вас может быть пять разных кодирующих агентов, которые все потрясающие. Никто не знает, какой сегодня. Никто не знает, какой лучший, честно говоря. Я не думаю, что Anthropic знает. Я не думаю, что OpenAI знает. Я не думаю, что Sourcegraph знает. Никто не знает, чей лучший, но некоторые лучше в одних вещах. Лично мне нравится Claude Code для, я сказал, запуска моей локальной среды или использования Git или использования этих человеческих действий, требующих обратной связи, но я иду к CodeX для сложных проблем или к Composer от Cursor, потому что он быстрее. И есть много, по сути, все это означает, что есть ценность в разных философиях. И я не думаю, что будет один победитель. Я думаю, будут разные победители для разных случаев использования. И это не только кодирующие агенты, кстати. Это все продукты ИИ. Это, это своего рода причина, по которой вся наша компания фокусируется на доменных экспертах и привлечении PM и эксперта-предметника, потому что именно так вы создаете защищенность. Итак, вот перспективы. Как я это вижу, это не полный список кодирующих агентов, но это те, которые я считаю наиболее интересными. Claude Code, я думаю, для меня он выигрывает в удобстве использования и простоте. Как я уже сказал, если я делаю что-то, что требует много приложений, Git — лучший пример. Если я хочу сделать PR, я иду к Claude CodeX. Контекст, он действительно хорош в управлении контекстом. Он кажется мощным. Есть ли у меня доказательства, чтобы показать вам, что он мощнее? Вероятно, нет. Но мне так кажется, и рынок, есть целый другой разговор, чтобы сказать, что рынок знает лучше, и то, о чем говорят люди, знает лучше, но я не знаю, знают ли они. Cursor IDE — это своего рода модель-агностик. Он быстрее. Factory делает Droid, отличная команда. Они тоже были здесь. У них есть несколько, они действительно специализируются на этих Droid под-агентах. Так что это своего рода их преимущество, и это, возможно, разговор о DAG, или, возможно, обучение модели, когнитивные способности. Devon — своего рода сквозная автономия, саморефлексия. AMP, о котором я расскажу подробнее через минуту. У них много интересных перспектив, и на самом деле я нахожу их очень захватывающими в эти дни. Free — модель-агностик, и есть много UX-сахара для пользователей, и на самом деле я люблю их дизайн, их доклады на этой конференции, у них очень-очень уникальные перспективы. Итак, начнем с CodeX, потому что это популярный. Он довольно похож на облачный код. Тот же главный цикл while, большинство из них делают это, потому что это просто выигрышная архитектура. Интересно, что ядро на Rust. Круто то, что он с открытым исходным кодом, так что вы можете фактически использовать CodeX для понимания того, как работает CodeX, что я, по сути, и сделал. Он немного более событийно-ориентированный, немного больше работы было вложено в многопоточность, своего рода очереди отправки, выходные события, своего рода то, о чем я говорил с буфером ввода-вывода в облачном коде. Я думаю, они делают это немного по-другому. Песочница очень отличается. Так что их больше, я имею в виду, вы можете видеть здесь macOS Seatbelt и Linux land, их больше на уровне ядра, а затем состояние, своего рода, все это под многопоточностью и разрешениями, как я бы сказал, это в основном отличается. А затем настоящее отличие — это модель, честно говоря. Это на самом деле я, использующий облачный код для понимания того, как работает CodeX. Так что вы видите, у нас есть несколько исследующих. Я не говорил об исследовании, но это еще один тип под-агента, как я уже упоминал, они входят и выходят. Но да, это исследование CodeX с помощью облачного кода. Это всегда весело делать. Итак, давайте поговорим об AMP. Это кодирующий агент Sourcegraph. У него есть бесплатный уровень. Это просто крутая перспектива, на мой взгляд. Они используют своего рода избыточные токены от провайдеров и дают рекламу. Так что у нас на самом деле есть реклама на них. Я думаю, это круто, я за рекламу. Многие люди против рекламы. Я думаю, это одна из моих горячих тем.

принимает, но мне это нравится. У них нет селектора моделей. Это тоже очень интересно. Это их собственная перспектива. Э, на самом деле это помогает им двигаться быстрее, потому что у вас меньше точных ожиданий от того, каким будет результат, потому что, знаете ли, они могут менять модели здесь и там. Так что это меняет то, как они разрабатывают. И затем, э, я думаю, их видение довольно интересно. э, их видение заключается в том, как построить не просто лучшего агента, а как построить агента, который работает с наиболее дружественными к агентам средами, и на самом деле Factory также выступал с докладом, похожим на этот, но как построить герметично закрытый э, как бы, репозиторий для кодирования, на котором агент может запускать тесты, как построить цикл обратной связи, потому что это своего рода Святой Грааль, так мы строим автономного агента, и как бы, я хотел бы увидеть фронтенд-версию этого, как бы, позволить ему взглянуть на свой собственный дизайн и сделать его лучше, и ходить туда-сюда, и это своего рода их руководящая философия, и вы можете свести это к перспективе агента, как я ее называл. Я думаю, они делают интересные вещи с контекстом. Итак, мы все знакомы с компакт. Это ужасно. Приходится ждать 10. Я не знаю, почему это занимает так много времени. Э, и если вы не знакомы, это резюмирование вашего окна чата, когда контекст становится слишком большим, и предоставление резюме. Так что у них есть что-то под названием handoff, что напоминает мне, если кто-то играл в Call of Duty в свое время, переключение оружия. Это быстрее, чем перезарядка. И э, вот что такое handoff. Вы просто начинаете новую ветку и передаете ей информацию, необходимую для новой ветки. Мне кажется, это выигрышная стратегия. Могу ошибаться, но, возможно, вам нужно и то, и другое. Вот куда они движутся. И мне это нравится. Они дают очень свежий взгляд. Итак, второе — выбор модели. Это ручки для рассуждений, э, и их взгляд на это. У них есть быстрые, умные и оракул. Так что они еще сильнее склоняются к тому, что у нас есть разные модели. Мы не говорим вам, что такое оракул. Они говорят, но мы готовы менять то, что такое оракул, но мы будем использовать оракул, когда у нас очень сложная проблема. Так что, да. Так что это AMP. Перейдем к агенту Cursor. Я думаю, у агента Cursor здесь очень интересная перспектива. Во-первых, очевидно, это UI. э, в первую очередь UI, а не CLI. Я думаю, у них может быть CLI, не совсем уверен, но UI — это интересная часть. Он просто очень быстрый. Их новый композитор моделей, он дистиллированный. У них есть данные. Они фактически сделали, по моему мнению, людей снова заинтересованными в тонкой настройке. тонкая настройка. Мы почти никогда не рекомендовали это нашим клиентам, но композитор показывает вам, что вы можете фактически построить защиту, основанную на ваших данных снова, что удивительно, но э, да, композитор агента Cursor, я почти полностью перешел на него, потому что он просто очень быстрый. Он почти слишком быстрый. Случайно отправил в master один из моих личных проектов. Э, так что вы не всегда этого хотите. Э, но Cursor был просто фаворитом публики, и я хочу отдать должное их команде. Они строили итеративно. Первая версия Cursor была ужасной, и мы все использовали, я использовал ее, потому что это форк VS Code. Мне нечего терять, и она стала такой хорошей. Это такое хорошее программное обеспечение, и это отличная команда, и э, но я скажу, что то же самое можно сказать и о моделях CodeX от OpenAI. Они не такие быстрые, но они оптимизированы для этих кодирующих агентов, и они дистиллированы. И я могу представить, что OpenAI выпустит действительно быструю модель здесь, потому что у них также есть данные. Так что вот картинка. Э, я думаю, вы можете, это картинка, которую они разместили в своем блоге, и вы можете увидеть их перспективу на кодирующих агентов здесь, просто исходя из того, что они показывают вам три модели, которые они запускают. Так что они предлагают композитор, но они позволяют вам использовать передовые технологии, потому что они знают, что, возможно, GPT 5.1 лучше планирует, или здесь это 5, но теперь у нас есть 5.1. Так что здесь возникает большой вопрос: какой из них нам всем следует использовать? Какая архитектура лучше всего? Что нам делать? И э, мое мнение здесь в том, что бенчмарки довольно бесполезны. Бенчмарки стали маркетингом для многих этих поставщиков моделей. каждая модель превосходит бенчмарки. Я не знаю, как это происходит, но я думаю, что есть мир, где оценки имеют значение здесь. И вопрос в том, что вы можете оценить. Вопрос в том, как эта простая архитектура с простым циклом, которую я пытаюсь продвигать, исходя из моего понимания, на самом деле затрудняет оценку, потому что если мы больше полагаемся на гибкость модели, как ее протестировать? Вы можете запустить интеграционный тест, своего рода сквозной тест, и просто сказать: "Исправляет ли это проблему?" Это один из способов. Вы можете разбить его. Вы можете сделать снимки в определенный момент времени и сказать: "Эй, я дам контекст моему чат-боту из наполовину законченного разговора, где я знаю, что он должен вызывать определенный инструмент". Я могу их запустить. Э, или я могу просто запустить бэктест и сказать: "Как часто он меняет инструменты?" Я думаю, здесь также есть другая концепция, которая начинает разрабатываться, называемая "запах агента" или, по крайней мере, я называю ее "запах агента". Так что запустите агента и посмотрите, сколько раз он вызывает инструмент. Сколько раз он повторяет попытку. Сколько времени это занимает. И это все поверхностные метрики, но это очень хорошо для проверки здравого смысла. И эти вещи трудно оценить. В этом много чего есть. Я покажу вам пример того, что я сделал, э, чтобы просто углубиться в это. Но, но на эту тему, возможно, я просто скажу еще кое-что. Я бы разбил это, моя ментальная модель такова: вы можете провести сквозной тест, вы можете провести тест в определенный момент времени, или то, что я чаще всего рекомендую, — это просто провести бэктест. Начните с бэктеста, начните собирать исторические данные и просто запустите его снова. Так что, да, позвольте мне дать вам этот пример. Так что, в основном, что у меня здесь есть, так это скриншот Prompt Layer. Это наш продукт для оценки, он также просто пакетный обработчик. Так что вы можете просто прогнать кучу столбцов через промпт. Но в данном случае я прогоняю его не через промпт, а через облачный код. Так что у меня есть просто безголовый облачный код, и я беру всех этих поставщиков, и я просто, у меня это на следующем слайде. Ищите в Интернете поставщика модели. Он дан вам в файле переменных. Найдите самую последнюю и самую большую выпущенную модель и верните ее имя. Так что я не знаю, что он делает. Он ищет в Интернете. Меня это даже не волнует. Это сквозной тест. Вот как мы пытались делать облачный код. И я на самом деле думаю, что есть много чего в том, чтобы поместить облачный код в ваши рабочие процессы, и эти типы безголовых SDK. Я расскажу об этом, думаю, на следующем слайде. Но главное, что здесь можно выделить, это то, что вы можете начать проводить сквозные тесты. Вы можете взглянуть на это с высоты птичьего полета, провести "запах модели" и затем заглянуть в статистику по каждой строке и увидеть, сколько раз она вызывала инструмент. И возвращаясь, и мы много говорили об этом в этом докладе. строгие инструменты. Инструменты могут быть строго протестированы. Вы можете. Вот как вы разгружаете детерминизм. Вот как вы разгружаете детерминизм в разные части вашей модели. Вы тестируете инструменты. Вы тестируете выходные данные ваших инструментов. Смотрите на них как на функции. Это вход и выход. Если ваш инструмент — это под-агент, который работает, то мы находимся в своего рода рекурсии, потому что тогда вам придется вернуться и протестировать сквозное решение. Но для ваших инструментов, я дам вам этот пример. Если я, так, в моих кодирующих агентах или моих агентах в целом, моих автономных агентах, если есть что-то очень специфическое, что я хочу вывести. Так, в данном случае, если у меня есть очень специфический тип формата электронной почты или тип сообщения в блоге, которое я хочу написать, и я действительно хочу, чтобы он правильно передал мой голос, я не хочу полагаться на исследование модели. Я хочу фактически создать инструмент, который я могу строго протестировать. Так, в данном случае, это также скриншот Prompt Layer, но это рабочий процесс, который я построил. Он имеет утверждение LM, где говорится: проверьте, хороша ли электронная почта по моим стандартам. Если она хороша, она ее пересматривает. Если она не хороша, она добавляет части. Так, например, заголовок, который он пропустил, и он пересматривает его с тем же шагом. Это, очевидно, очень простой пример, но у нас есть другая версия для некоторых наших SEO-блогов, которая имеет около 20 различных узлов и пишет план на основе глубокого исследования, а затем исправляет заключение и добавляет ссылки. для вещей, у которых у вас есть очень конкретное видение, тогда тестирование становится намного проще, потому что, как вы можете видеть, очевидно, тестирование такого рабочего процесса имеет меньше шагов и меньше гибкости. Так что это оценка, которую я сделал. Я начинаю с простого набора образцов электронных писем. Я запускаю промпт, на самом деле я запускаю агентский рабочий процесс здесь, и я просто добавляю кучу эвристик. Так что это очень простой судья LM: включает ли он три части? Так, вот что я тестировал для электронного письма "Привет, Джаред", основной текст и подпись. Вы можете сделать гораздо более сложные вещи. Вы можете выполнить выполнение кода. Вы можете сделать, я не знаю, судья LM обычно самый простой. Но теперь, очевидно, вы можете видеть, я могу продолжать запускать это, пока оно не станет правильным для всех, и как бы видеть мою оценку с течением времени. Это просто из этого примера. Я получил 100. Так что это было весело. Э, и затем я хочу добавить еще одну перспективную вещь. Следите за безголовыми SDK облачного кода. Я знаю, что сегодня утром был доклад об этом. Э, так что я не хочу, я не буду тратить на это слишком много времени, но это потрясающе. Вы просто даете простой промпт, и это просто еще одна часть вашего конвейера. Я использую его для, я думаю, у меня это на следующем слайде. У меня есть действие GitHub, которое обновляет мои документы каждый день и просто читает все коммиты, которые мы отправили в наши другие репозитории. И у нас много коммитов, и он просто запускает облачный код. Облачный код загружает все репозитории, проверяет, что обновлено, читает наш облачный MD, чтобы узнать, следует ли вообще обновлять документы, затем создает PR. Так что я думаю, это открывает много возможностей, и есть вероятность, что мы начнем строить агентов на более высоком уровне абстракции и просто полагаться на облачный код и эти другие агенты для выполнения многих задач по обеспечению безопасности и оркестрации. >> Вы их просматриваете? Да, [смех] он создает PR. Он не сливает PR. Так что вот мои выводы. Номер один, доверяйте модели. Э, в случае сомнений, полагайтесь на модель при создании агентов. Номер два, простой дизайн побеждает. Номер один и номер два здесь как бы идут вместе. Номер три, bash — это все, что вам нужно. Будьте просты с вашими инструментами. Не имейте 40 инструментов, имейте 10 или 5 инструментов. Для управления контекстом имеет значение, это пугало, от которого мы постоянно бежим в агентах на данный момент. Возможно, в будущем появятся новые модели, которые будут намного лучше работать с контекстом. Но всегда будет предел, потому что, ах, вы разговариваете с человеком. Я забываю имена людей, если встречаю слишком много за один день. Это управление контекстом или моя глупость. Я не знаю. И номер пять, разные точки зрения имеют значение в агентах. Я думаю, что инженерный мозг не всегда это понимает так, как должен, особенно в, и я инженер, так что я говорю и о себе, но разные точки зрения имеют значение, такие что есть разные способы решения проблемы, где нет одного лучшего, чем другой, и вы как бы, вы, вероятно, хотите смесь экспертов-агентов. Я бы хотел, чтобы мой запускал облачный код и CodeX, и это, и давал мне результат, и считал это командой, и, возможно, пусть они разговаривают друг с другом в канале сообщений на основе Slack. Я жду, когда кто-нибудь это построит. Это было бы здорово. Но это мои выводы. Э, мой бонус, который я вам покажу, это как я построил эту презентацию с помощью облачного кода. Так что, э, я построил навык разработки слайдов. Так что я, по сути, сказал облачному коду исследовать, как работает разработка слайдов, и как он может, и это своего рода библиотека, в которой я это сделал. Я построил навык глубокого исследования, чтобы исследовать всех этих агентов и то, как они работают. Я построил навык дизайна, потому что я знаю, что половина вещей выглядит ужасно или выглядит хорошо, но я не хороший дизайнер, чтобы разобраться в этом. Так что эти коробки, даже я просто сказал: "О, сделай коробку немного лучше. Придай ей акцентный цвет". Э, так что, да, вот как я это построил. Но опять же, спасибо за внимание. Э, буду рад ответить на любые вопросы. Я Джаред, основатель Prompt Layer. Найдите меня там. [аплодисменты] >> Да. >> Спасибо. Отличный доклад. Э, так вы упомянули, что касается DAG, по сути, давайте избавимся от них, верно, но DAG как бы обеспечивают это последовательное выполнение, э, прохождение, я не знаю, обслуживание клиентов, как агент спрашивает имя, электронную почту, э, в какой-то последовательности, э, так вы говорите, просто запишите это, э, как это теперь, это должно быть, э, просто записано как план для агента для выполнения, и просто доверять, что модель будет вызывать эти инструменты в этой последовательности, как мы обеспечиваем порядок? >> Правильно. Так вопрос был, почему я продолжаю говорить об избавлении от DAG? Как еще вы должны обеспечить определенный порядок для решения проблемы? Так что я думаю, что есть разные типы проблем. Так, проблема создания универсального кодирующего агента, который мы все можем использовать для нашей работы, и даже нетехнические люди могут использовать, нет конкретного шага для решения этой проблемы, поэтому лучше полагаться на модель. Если бы ваша проблема заключалась в создании, скажем, туристического маршрута, это более конкретный шаг, потому что у вас есть результат, который всегда одинаков. Так что здесь может иметь значение небольшой DAG, но на этапе исследования путешествий вы, вероятно, не хотите DAG, потому что каждый город будет разным. Так что это действительно зависит от проблемы, которую вы решаете. Я бы, если бы я хотел создать агента для туристического маршрута, я бы, вероятно, имел вызов инструмента, одним из моих вызовов инструмента был бы DAG создания выходного файла, потому что я хочу, чтобы выходные данные выглядели одинаково, или создания плана. А затем в системной проблеме я мог бы сказать: всегда заканчивай выводом, например. Но вам нужно смешивать и сочетать. Каждый вариант использования отличается, но если вы хотите создать что-то универсальное, мой подход заключается в том, чтобы больше полагаться на модель в простых циклах и меньше на DAG. >> Круто. Есть еще вопросы? Да. >> Да. Продолжая этот пункт, как вы думаете, мы движемся к миру, где большинство из вас не будет фактически вызывать API через код, и большинство вызовов LM будут путем запуска облачного кода и просто написания файлов вместо этого? Так что вопрос в том, уйдем ли мы от прямого вызова моделей и просто будем вызывать, как бы, безголовый облачный код, верно? >> Да. Например, если у меня есть, у меня есть конвейер, который делает один вызов LM на документ, суммирует его в конце. Вы можете сделать облачный код в виде цикла, который сохраняет файл каждый раз. Вы никогда не вызываете API, кроме как используя облачный код в цикле. >> Потенциально. Э, я дам вам плюс и минус. >> Да. >> Плюс в том, что его легче разрабатывать, и мы можем полагаться на передовые технологии. Я имею в виду, если вы подумаете об этом, модель рассуждений — это просто это. Моделей рассуждений не всегда существовало. У нас просто была обычная модель LM, а затем, о, теперь у нас есть 01 и модели рассуждений. Все, что это такое, это, я имею в виду, немного сложнее, чем это, но это, по сути, просто цикл на серверах OpenAI, который продолжает запускать контекст и затем в конечном итоге дает вам результат. в том же смысле, что облачный код SDK — это цикл с кучей других вещей. Так что я вполне могу представить, что многие разработчики будут касаться только этих агентских конечных точек. Возможно, даже увидим, как поставщик модели выпустит модель как агентскую конечную точку. Но для многих задач вам понадобится немного больше контроля. И они плюс, и, вероятно, вы все равно захотите приблизиться к металлу. Имея это в виду, было много людей, которые все еще хотели модели завершения, и этого никогда не случалось, и никто больше об этом не говорит. Так что очень вероятно, что все просто станет этим SDK, но у меня нет хрустального шара, но вот как я бы об этом думал. >> Да. >> Спасибо за доклад. Э, я знаю, вы сказали, что чем проще, тем лучше, но каковы ваши мысли о тестировании во время разработки, спецификации во время разработки в ИИ? Вы пробовали? Что насчет >> для создания агентов или для выполнения работы? >> Для кодирования. >> Хорошо. Так что вопрос о разработке, управляемой спецификациями, разработке, управляемой тестами, для кодирования с агентами. [кашель и смех] В случае сомнений, возвращайтесь к хорошим инженерным практикам, вот что я бы сказал. Так что, если вы, и есть целые инженерные дебаты о том, является ли разработка, управляемая тестами, правильным путем, и некоторые люди клянутся этим, а некоторые нет. Так что я не думаю, что есть ответ. Я думаю, что кодирующие агенты явно делают разработку, управляемую тестами, проще. Я думаю, как я вам показывал, это вся философия Sourcegraph AMP, что если вы можете построить хорошие тесты, и Factory, я думаю, тоже так думает. Если вы можете построить хорошие тесты, ваш кодирующий агент может работать намного лучше. Так что это имеет смысл для меня, когда я работаю лично, я довольно сильно полагаюсь на фазу планирования и фазу разработки, управляемой спецификациями, и я думаю, что более простые задачи довольно легки для модели, но если я делаю очень простой редактирование, я пропускаю этот шаг. Так что нет универсального решения, но возвращайтесь к инженерным принципам, в которые вы верите, в случае сомнений, я бы сказал, да. >> Так раньше вы говорили о системных утечках, возможно ли просто посмотреть на загрузки пакетов или у них есть специальная конечная точка, которая имеет промпты за конечной точкой. >> Да. Э, я думаю, я думаю, они скрывают это. Я думаю, они скрывают это. Был на самом деле интересный рассказ, кто-то, потому что CodeX с открытым исходным кодом, до того, как OpenAI выпустила модель CodeX, которую она использовала, они смогли взломать CodeX с открытым исходным кодом, чтобы дать пользовательский промпт модели и использовать модель без нее. Так что да, вы можете углубиться в это, но в целом это пытались скрыть, а также лень кого-то, кто это опубликовал. Так что вот, это работа, но кто-то должен был это найти, верно? Как будто эта проблема где-то на вашей машине? >> Я на самом деле не знаю ответа. [смех] >> Вы знаете ответ? >> Да. >> Да. >> Это на вашей машине. Нико говорит, что это на вашей машине. Так что вот. Так что, возможно, промпт, на который я смотрел, немного устарел, и мне нужно его обновить. Но вопрос был, скрыт ли промпт на их серверах, или вы можете найти его, если вы так решительны? И ответ, кажется, да. Есть еще вопросы? >> Да. >> Это последний? >> Это последний вопрос? >> Может быть. >> Можете ли вы рассказать о Prompt Layer и как люди могут вам помочь? >> Да, это хороший вопрос. Я забыл об этом. Спасибо. Э, так что, да, я ищу сотрудников. Э, так что, если вы ищете работу в сфере кодирования в очень веселой и быстро развивающейся команде в Нью-Йорке, вы можете связаться со мной в X или по электронной почте jaredprompter.com. Мы находимся в Нью-Йорке. Мы, э, да, мы платформа для создания и тестирования продуктов ИИ для управления промптами, аудита, управления, всего этого веселья, а также логирования и оценок. И те скриншоты, которые я вам показывал, взяты из Prompt Layer. Если вы создаете приложение ИИ и создаете его с командой, вам, вероятно, стоит попробовать Problem Layer. Это облегчит вам жизнь. Э, особенно чем больше ваша команда, тем больше вы хотите сотрудничать, тем больше вы хотите сотрудничать с PM и нетехническими пользователями, или если вы просто технические пользователи, это отличный инструмент. Это сделает вашу жизнь лучше. Настоятельно рекомендую. promptlayer.com, и это легко сделать. И это было мое выступление. Спасибо за внимание. [аплодисменты] [музыка] >> [музыка] [музыка] >> Жара.