Transcription
Сегодня в AI Daily Brief — девять советов от команды Codex для работы с Codex. Перед этим, в новостях, да, мы получили вердикт по делу Илона Маска против OpenAI, но это гораздо менее интересно, чем Composer 2.5. AI Daily Brief — это ежедневный подкаст и видео о самых важных новостях и дискуссиях в области ИИ. Итак, друзья. Короткие объявления перед тем, как мы начнем. Вы можете подать заявку на нашу новую вакансию инженера по росту. Я скоро закрою прием заявок, так что, если вы заинтересованы, подавайте свою заявку. А также вы можете найти ссылку для регистрации на третий поток Enterprise Cloud, который скоро начнется. По сути, если вы воодушевлены сегодняшним разговором о Codex и хотите привнести этот дух создания агентов в свою компанию, то Enterprise Cloud именно для этого и пригодится. Но, отложив это в сторону, давайте поговорим о Composer 2.5 и о том, что это говорит о Cursor в гонке ИИ. Одним из вопросов, возникших в этом году, было то, смогут ли так называемые "лаборатории агентов" Swyx, а теперь, возможно, "лаборатории harness first", — компании вроде Cursor, Cognition и т. д. — конкурировать на фронте моделей. Беспокойство этих компаний, конечно, заключалось в том, что если они полностью зависят от моделей от больших лабораторий, и если эти лаборатории начнут двигаться в направлении создания собственных "harness" (оболочек), это может вытеснить пространство для таких компаний, как Cursor и Cognition. И в то же время, у компаний вроде Cursor и Cognition было нечто ценное в виде данных, генерируемых при использовании их платформ, что теоретически давало им представление о том, как люди на самом деле взаимодействуют с этими моделями, и что могло бы стать ценным активом для обучения их собственных моделей. Смогли бы они это сделать или нет, было ясно, что это направление, в котором они начнут двигаться, и что разрыв между так называемыми "лабораториями агентов" и "лабораториями моделей" обречен сократиться. Лаборатории моделей будут двигаться в пространство "harness". Лаборатории агентов или "harness" будут двигаться в пространство моделей. В январе генеральный директор Майкл Труэл сообщил сотрудникам, что это, цитата, "военное время", признавая, что бизнес-модель Cursor eroding с обеих сторон. Claude Code наступал им на пятки со стороны "harness", но они также не могли продолжать нести расходы на обслуживание моделей Anthropic со скидкой. Имея это в виду, он сказал, что приоритетом номер один для компании является создание лучшей модели кодирования в этом году. Выпуск Composer 2 в марте был достойным первым шагом, но он в основном касался снижения затрат. Там, где пользователи приняли дешевую внутреннюю модель, это было в основном для простых задач. Однако это не привлекло новых пользователей на платформу. Только что выпущенный Composer 2.5 может изменить ситуацию. Модель выглядит конкурентоспособной по ключевым бенчмаркам. Она набрала 69,3% на Terminal Bench 2.0, что всего лишь на 0,1% отстает от Opus 4.7 (69,4%). На SweBench multilingual она набрала 79,8%, что сравнимо как с Opus 4.7 (80,5%), так и с GPT-5.5 (77,8%). На собственном бенчмарке Cursor, который тестирует более сложные задачи кодирования, Composer 2.5 набрал 63,2%, всего на один пункт отставая от 4.7 и 5.5. Теперь производительность кодирования выводит Composer 2.5 в диапазон применимости для серьезных кодеров, но большая часть истории — это стоимость. Cursor обслуживает эту модель всего за 50 центов за миллион входных токенов и 250 за миллион выходных токенов, что вдвое дешевле Opus 4.7 или GPT-5.5. Они также, похоже, добились значительного повышения эффективности использования токенов. Их бенчмарк на SweBench обошелся менее чем в доллар за задачу по сравнению с примерно 5 долларами за задачу для GPT-5.5 на сверхвысоких настройках или 11 долларами за задачу для Opus 4.7 на максимальных настройках. Это позволило Cursor заявить, что их модель в 10 раз эффективнее по сравнению с аналогичными по возможностям моделями. Теперь Composer 2.5 по-прежнему построен на той же базовой модели, что и Composer 2, — Moonshots Kimi 2.5. Это означает, что весь прирост производительности обусловлен лучшими методами обучения с подкреплением, и предполагает, что даже если люди не перейдут массово с Opus и GPT на Composer, существует огромный потенциал для дообучения ведущих open-source моделей, чтобы конкурировать на передовой, особенно в отношении этих дискретных задач. Cursor также объявил, что они находятся в процессе обучения новой модели с нуля, используя вычислительный кластер XAI Colossus 2. Они написали: "С миллионом эквивалентов H100 в Colossus 2 и нашими объединенными данными и методами обучения мы ожидаем, что это будет значительный скачок в возможностях модели". Леон Лин подытожил публикацию о выпуске модели: "Итак, по сути, мы получили модель уровня Opus 4.7, которая стоит в 10 раз дешевле. Мне нужно это протестировать". Позже в тот же день он вернулся с результатами, написав: "Довольно быстрая и эффективная модель, отлично справляется. Я бы сказал, что она почти так же сильна, как Opus 4.7, а в некоторых случаях даже на том же уровне. Дешевая модель, хороша во фронтенде, все еще немного общий дизайн при использовании без навыков". Аналитик Макс Вайнбах согласился, написав: "Composer 2.5 очень хорош. Он хорош не только для быстрых итераций фронтенда. Я, вероятно, буду использовать его вместо Claude и Cursor". Отвечая на вопрос о том, что изменилось по сравнению с Composer 2, он добавил: "Composer 2 был хорош для некоторых быстрых исправлений, но я не доверял ему достаточно, чтобы делать больше. Я гораздо больше доверяю 2.5". Али из Prime Intellect отметил, что после сделки с XAI, которая, как вы, возможно, помните, дает XAI возможность выкупить их за 60 миллиардов долларов, Али сказал, что Cursor теперь конкурентоспособен с передовыми лабораториями как по производительности моделей, так и по вычислительным мощностям для обучения. Безусловно, Илон, кажется, воодушевлен, спамя ретвиты всех восторженных постов о модели. И чтобы дать вам представление о типе возможностей, которые могут появиться у Cursor, особенно если вы сидите и думаете: "Разве компании сейчас не подписываются только с OpenAI или Anthropic?" Чамат Палихапития написал: "Если вы управляете консалтинговым бизнесом и внедряете Anthropic или OpenAI напрямую в свою организацию, я смотрю на вас, PwC и Accenture, вы пускаете лису в курятник. OpenAI и Anthropic открыто финансируют и запускают конкурентов вам, одновременно используя ваше использование для достижения большего успеха для себя. Это не их провал, а ваш провал. Консалтинговые компании, которые это понимают, принимают план контроля, который позволяет им определять, куда идут токены и кто их генерирует. Контроль над токенами — это контроль над специями". По сути, ведется гораздо больше разговоров о том, насколько сильно вы хотите быть привязаны как предприятие к этим моделям, что создает интересную открытую нишу для компаний, ориентированных на "harness", которые, да, могут иметь собственные модели, но в конечном итоге являются модель-агностиками. Далее, Cloudflare опубликовал свои выводы после работы с Mythos в течение последних нескольких месяцев, что может быть одним из самых полезных обзоров секретной новой модели Anthropic. Переходя прямо к сути, они пишут: "Предварительная версия Mythos — это настоящий шаг вперед, и стоит сказать это прямо, прежде чем переходить к чему-либо еще. Мы уже некоторое время тестируем модели на нашем коде, и скачок от того, что было возможно с предыдущими универсальными передовыми моделями, к тому, что делает Mythos preview сегодня, — это не просто усовершенствование того, что было раньше. Это другой тип инструмента, выполняющий другую работу, и это затрудняет прямое сравнение с ранними моделями". Cloudflare далее объясняет два больших отличия. В отличие от предыдущих моделей, Mythos способен создавать цепочку эксплойтов, а не просто обнаруживать отдельные ошибки. Это означает, что он может синтезировать несколько атакующих примитивов в функциональный эксплойт. Cloudflare написал, что использование рассуждений для создания сложных эксплойтов делает работу модели больше похожей на работу старшего исследователя, чем на автоматический сканер ошибок. Другое большое изменение — это возможность генерировать доказательства. Предыдущие модели были довольно хороши в обнаружении потенциальных уязвимостей, но редко демонстрировали эксплойт. Mythos может генерировать функциональные эксплойты, что делает его гораздо более полезным в качестве инструмента отладки, который не просто генерирует список ложных срабатываний. Более того, Mythos способен тестировать и дорабатывать свои эксплойты, если они не работают с первого раза, предоставляя дополнительные доказательства для исправления уязвимости. Cloudflare заявил, что некоторые другие модели смогли найти те же основные ошибки, но редко шли дальше. Все это добавляет огромный контекст к тому, почему Mythos важен. В недели после выпуска предварительной версии многие отмечали, что другие модели могут найти многие из тех же ошибок, что и Mythos, но, как отмечает Cloudflare, есть большая разница между указанием на потенциальные ошибки и предоставлением полного кода для функционального эксплойта, демонстрирующего, что именно нужно исправить. Автор Дэниел Джеффрис утверждает, что это тот тип анализа, который нам нужен в отношении этих инструментов, говоря: "Это тот разговор, который нам нужен, а не идиотские разговоры о конце всего программного обеспечения. Нам нужен правильный ответ, потому что эти модели появляются и будут становиться лучше. Итак, как мы можем объединить усилия и создать лучшее и более безопасное программное обеспечение по всему миру. И это не может быть просто исправление около 100 проектов, получивших доступ к Project Glasswing. Это не поможет миру". Наконец, сегодня одна небольшая драма в области ИИ подходит к концу, по крайней мере, в этой версии. Илон Маск проиграл свой иск против OpenAI и Сэма Альтмана. После трех недель показаний присяжным потребовалось всего 2 часа, чтобы вынести единогласный вердикт, который будет крайне неудовлетворительным для многих и оставит многие вопросы неразрешенными эмоционально, даже если они разрешены юридически. Присяжные установили, что иск о нарушении благотворительного траста был отклонен по сроку давности, что означает, что Илон слишком долго затягивал с подачей иска. Вместе с этим отпал и иск о том, что Microsoft способствовала этому нарушению. Иск Маска о возмещении ущерба также был отклонен по сроку давности, и с этим этот большой, массивный, привлекающий заголовки судебный процесс по делу о технологиях сдулся до ничего. Теперь, честно говоря, судебный процесс был странным еще до вынесения вердикта. За недели до начала судебного процесса Илон отказался от своих более амбициозных претензий о мошенничестве, сосредоточившись исключительно на нарушении благотворительного траста. Он подал иск, добиваясь двух результатов: отстранения Сэма Альтмана и Грега Брокмана от должностей руководителей и скромных 134 миллиардов долларов в качестве возмещения ущерба. Но даже при сокращенном объеме присяжным не пришлось рассматривать суть дела, просто приняв решение исключительно на основе технических недостатков самого иска. Этот фатальный недостаток сам по себе был интересным микрокосмом того, как развивалось дело. Маск утверждал, что Альтман и Брокман вступили в сговор, чтобы, цитата, "украсть благотворительность", связывая эти претензии с инвестициями Microsoft в размере 10 миллиардов долларов в 2023 году. Однако OpenAI убедила присяжных, что Маск знал о планах создания коммерческой компании еще в 2018 году, получив проект соглашения, описывающий предложенную структуру. Судебный процесс также выявил собственные мысли Илона по этому поводу, а именно предложение 2017 года объединить OpenAI с Tesla для привлечения коммерческих средств. Присяжные установили, что эти события положили начало 3-летнему сроку для Илона, чтобы подать этот иск. На прошлой неделе The Verge проделала довольно хорошую работу, обобщив дело, утверждая, что, по их словам, оно не достигло ничего, кроме вынесения грязного белья. Мы, безусловно, получили много новой информации о том, что происходило за закрытыми дверями в OpenAI за последнее десятилетие. Это включает в себя борьбу за власть между Илоном и другими соучредителями, роковую неделю, когда Сэм Альтман был смещен, а затем вернулся в качестве генерального директора, что, по-видимому, внутренне называлось "блипом". Но помимо этого, реальных ответов не было. Все, что мы получили, — это трехнедельное дознание о характерах Илона, Сэма Альтмана и других лидеров, которое, если использовать фразу из текстового сообщения Амиры Морати, раскрытого во время судебного процесса, было "направленно очень плохим". Теперь хорошая новость для индустрии ИИ заключается в том, что, каким бы бурным ни было все это здесь, я не думаю, что большинство людей в мире за пределами ИИ вообще обращали на это внимание. К сожалению для нас, широкое общественное мнение уже считает, что ИИ — это просто еще один инструмент для богатых, чтобы стать богаче, а не что-то, что действительно поможет их жизни каким-либо значимым образом, по крайней мере, по цене, которую они готовы заплатить. И поэтому больше свидетельств того, как миллиардеры бросают друг в друга свое золото, действительно не меняет этой перспективы. Думаю ли я, что для ИИ было бы лучше, если бы все эти лидеры объявили мораторий на публичные выступления об индустрии? Да, да, думаю. Но рад ли я также тому, что, по крайней мере, эта конкретная драка закончилась? Да, да, рад. С этим я очень рад завершить освещение этой конкретной саги и перейти к основному эпизоду. Добро пожаловать обратно в AI Daily Brief. У нас было два довольно больших "мыслительных" эпизода подряд, и прямо сейчас, когда я записываю, мы с нетерпением ждем всех новых вкусностей, которые получим на Google I/O. И поэтому, учитывая это, я подумал, что это будет хороший день для более практического, ориентированного на действия основного эпизода. Конечно, это год урожая, когда люди понимают, что раскрытие истинной силы агентов включает в себя умение хорошо использовать программное обеспечение, через которое вы запускаете и управляете этими агентами, будь то что-то open-source, как Open Claw, или что-то от одной из больших лабораторий, как Claude Code или Codex. Codex в этом году демонстрирует невероятный рост, перейдя от почти полного отсутствия пользователей в начале года к средним однозначным цифрам прямо сейчас. И поскольку Anthropic пришлось принять некоторые трудные решения относительно своей модели ценообразования и сократить определенные категории использования, которые ранее субсидировались, особенно за пределами их собственных "harness", OpenAI воспользовалась этим, чтобы привлечь больше таких продвинутых пользователей кодирования в экосистему GPT и Codex. В результате у нас много людей, которые серьезно изучают Codex впервые и выясняют все способы, как сделать его полезным для себя. Я планировал эпизод-введение по Codex, но на выходных я увидел пост Джейсона Лу из команды Codex о советах, которые сделали его использование Codex еще более эффективным. Пост называется "Maxing Codex". Он был опубликован на GitHub Джейсона. И поэтому сегодня мы извлечем самые важные идеи из этого поста в качестве небольшого введения, чтобы увидеть лучшие практики использования Codex от некоторых из тех, кто его создал. Моя презентационная версия поста Джейсона, конечно, была создана с помощью Codex. В качестве предыстории Джейсон сказал, что некоторое время он использовал Codex для задач, связанных с кодированием, но за последние несколько месяцев он действительно стал для него целым рабочим пространством. И часть того, что делает его ценным, заключается в том, что он заменяет однократный интерфейс "дай промпт — получи ответ" в стиле ChatGPT на более широкий, полный опыт, который может сохранять контекст во времени и выполнять гораздо более обширные типы работ. Основа советов Джейсона — девять практик, которые сводятся к одному большому сдвигу. Первое — использование долгосрочных, устойчивых потоков. Вы, возможно, помните, как несколько недель назад одно из последних обновлений Codex получило новую систему для сжатия контекста. Это, по сути, способ, которым "harness" на бэкенде сворачивает и сжимает контекст из долгосрочного разговора в ключевые элементы, которые ему нужно знать, освобождая место в окне контекста, чтобы чат продолжался. Часть того, что отмечали инсайдеры OpenAI в связи с этим обновлением, заключалась в том, что система сжатия стала настолько лучше, что они могли поддерживать набор постоянных потоков, которые никогда не теряли общий контекст потока и могли постоянно его дополнять. Опыт Джейсона по созданию потока "главного помощника" был на самом деле одним из примеров, на который я ссылался, говоря о том, как вы можете использовать эту новую версию по-другому. И чтобы немного углубиться в то, почему такой устойчивый поток может быть ценным. Многие функции в приложениях, таких как ChatGPT, по сути, являются лишь прокси для памяти и контекста. Когда вы используете проект и добавляете в него кучу файлов, это, по сути, дает каждому новому разговору в этом проекте возможность черпать из всего этого контекста. Но ему все равно приходится черпать из этого контекста. Он не обязательно обновляется, если вы специально его не поддерживаете. И процесс извлечения контекста из этих файлов не всегда идеален. Не говоря уже о проблемах пользовательского интерфейса и опыта, когда у вас есть куча разных потоков и чатов, которые вам приходится сортировать и выяснять, в каком из них вы на самом деле ведете релевантный разговор. Идея паттерна "монопотока" заключается в том, чтобы собрать ключевые разговоры по определенной теме в один лог-поток, полагаясь на сжатие Codex, чтобы этот поток был устойчивым и сохранялся во времени. Совет Джейсона не только использовать этот паттерн "монопотока", но и иметь отдельный поток для каждого из его ключевых рабочих потоков. Это не значит, что каждая вещь, над которой вы работаете, заслуживает такого типа "монопотока", но для ключевых постоянных рабочих потоков они часто заслуживают. Совет номер два — о голосе. Это то, о чем, если вы постоянный слушатель, вы слышали, как я бесконечно кричал. Я на самом деле настоятельно рекомендую всем, кто взаимодействует с агентами или, по сути, выполняет любую работу на компьютерах в данный момент, скачать что-то вроде WhisperFlow как улучшенную версию встроенного распознавания голоса вашего компьютера. Но с Codex вам даже не нужно этого делать, потому что его внутренняя система преобразования речи в текст — это, по сути, золотой стандарт. Для Джейсона голос — это не просто способ быстрее передать сообщение. Он открывает совершенно другой тип отношений с самим Codex. Искусство болтовни дает вам возможность предоставить гораздо больше предыстории. Оно позволяет вам предоставлять более богатую информацию о областях неопределенности по сравнению с определенностью. Поскольку оно позволяет вам объяснить, что вы знаете, чего не знаете, что, по вашему мнению, вы знаете, чего, по вашему мнению, не знаете, назвать компромиссы и позволить самому ИИ помочь вам превратить беспорядочные мысли во что-то ясное, вместо того, чтобы делать это самостоятельно. Как говорит Джейсон: "Многие планы становятся лучше, когда модель имеет доступ к беспорядочной версии моих мыслей, а не только к отполированной". Это 100% мой опыт. Не могу сильнее согласиться с этим конкретным советом. Совет третий — интересный, который использует ключевую функцию Codex, чтобы немного нарушить шаблон нашего взаимодействия с ИИ. Если вы активный пользователь ИИ, вы, вероятно, привыкли к паттерну взаимодействия, который выглядит примерно так: запросить конкретный результат, то есть задать промпт, подождать, пока он сделает свою работу, а затем, когда он сделает свою работу и доставит результаты, вы определяете, какие исправления и изменения вы хотите внести, и затем вся эта система повторяется. Но функция "steer" (направление) в Codex позволяет делать вещи немного иначе, особенно после того, как вы получили первый артефакт для проверки. Вы можете начать формировать обратную связь, пока инструмент работает. Steer — это функция в Codex, которая позволяет добавлять или обновлять промпт, не останавливая общий поток. Среди прочего, это означает, что вам не обязательно доводить промпт до совершенства с самого начала. Вместо такого хрупкого предварительного планирования вы можете начать более широко с общих целей и ограничений, а затем, по мере поступления прогресса, фактически направлять разговор, так что вы и агент работаете параллельно, и вы не просто сидите и тратите время в Twitter, ожидая, пока ИИ сделает свою работу. Кстати, голос — идеальное средство для такого направления, потому что, опять же, наблюдая за тем, как агент работает, вы можете просто болтать. Вам не нужно каждый раз набирать идеально сконструированное предложение. Совет номер четыре от Джейсона — о памяти. И одна из интересных вещей заключается в том, что, хотя Codex начал вводить нативные функции памяти, вы можете перейти в настройки, затем в персонализацию, затем в память, аргумент Джейсона заключается в том, что, хотя эти вещи полезны для стабильных предпочтений, повторяющихся рабочих процессов, соглашений по проектам и известных подводных камней, они не являются, как он выражается, заменой для проверенных инструкций или явного хранилища. Основной аргумент Джейсона заключается в том, что работа должна оставлять после себя структурированную память, а не просто более длинный чат. И поэтому он создал целую файловую систему в Obsidian, которая, если вы ею не пользовались, является простой файловой системой заметок, которая взаимодействует с вашей локальной средой, чтобы структурированно превратить его потоки в структурированный набор контекстов, к которым можно обращаться позже. Говоря о своих устойчивых потоках, Джейсон пишет: "Длинный поток может многое запомнить, но эта память заперта внутри потока, если полезные части не будут сериализованы где-то надежно. Цель системы памяти — превратить то, что узнает поток, в артефакт, который я могу просматривать, редактировать и повторно использовать". Джейсон также делится конкретной структурой хранилища, которое он собирает, с файлом markdown верхнего уровня agents.md, содержащим инструкции, такие как: "По мере того, как вы узнаете больше о людях, добиваетесь прогресса в проектах или закрываете открытые петли, обновляйте соответствующие страницы в хранилище". Хранилище, по его словам, содержит текущий контекст моей работы, людей, решений, открытых петель, ежедневных заметок, состояния проекта и фрагментов понимания, которые иначе потерялись бы между потоками. Так что для тех из вас, кто использует конструктор портфолио личного контекста, которым я поделился около полутора месяцев назад, хотя этот конструктор личного контекста был о сборе широкого контекста, который вы бы взяли с собой в любой новый опыт работы с агентом, Джейсон, по сути, возвращает это на уровень проекта таким образом, что существует прямой поток от больших потоков, где он работает над вещами, в это хранилище, которое автоматически обновляется. Он также отмечает, что он хранит хранилище как репозиторий GitHub, что позволяет ему работать и в облаке. Этот раздел памяти является одним из самых насыщенных инсайтами, поэтому я придерживаюсь того, что написал Джейсон. Например, он говорит о том, почему этап проверки того, что агент решил поместить в хранилище, то есть что он посчитал достаточно важным для запоминания, является ценным этапом. Он продолжает: "Я не хочу, чтобы вечные потоки тихо накапливали вибрации и историю разговоров. Я хочу, чтобы они записывали, что изменилось. Этот человек предпочитает это, этот проект ждет того, это решение было принято, эта петля закрыта". Это также, говорит он, почему мне нравится память в виде файлов. Файлы заставляют агента сжимать опыт в форму, которая может пережить поток. Если поток умирает, плохо сжимается или становится слишком дорогим для поддержания, полезное знание все еще остается. В этот момент закрепленные потоки начинают ощущаться меньше как чаты, а больше как разные работники, читающие из одной и той же записной книжки. Итак, некоторые другие идеи для того, что можно поместить в эту память, включают правила, вкус, то есть что означает "хорошо" для задач, включающих дизайн, написание или анализ, список релевантных источников, антипаттерны или что не делать, ссылки на ключевые артефакты и многое другое. Совет номер пять касается использования компьютера и браузера. Хотя я думаю, что то, как моя интерпретация Codex суммировала это как "инструменты", является довольно хорошим сокращением. Инструменты позволяют Codex превратиться в сборщика доказательств. Когда вы даете Codex возможность использовать ваш компьютер и браузер, он может делать такие вещи, как читать файлы, открывать страницы, запускать тесты, редактировать артефакты, проверять визуальные элементы и многое другое. И понимание того, какой инструмент или какая среда важна для каждого типа работы, является ключевым навыком. Так что, если правда и доказательства, которые имеют значение, живут в коде, документах, логах, CSV-файлах, слайдах, PDF-файлах или других типах артефактов на вашем компьютере, именно там вам понадобится использование компьютера. Когда артефакт требует визуального осмотра, или ему нужно проверить живые документы или источники, которые находятся где-то еще, именно там имеет значение использование браузера. А затем, конечно, когда релевантная информация находится в других системах, таких как Slack, Gmail, GitHub, Notion или Vercel, именно тогда вы будете использовать коннекторы. С одной стороны, такое использование инструментов довольно очевидно ценно, но оно все еще требует некоторой настройки, которая может показаться вам задержкой, когда вы просто пытаетесь что-то сделать. Однако, если и когда вы перейдете от рассмотрения Codex как просто другого интерфейса для того же, что вы использовали бы для ChatGPT ранее, и вместо этого будете рассматривать его как основу для совершенно новой рабочей системы, доступ к инструментам к любой среде, которую Codex должен иметь полный контекст и выполнять всю необходимую работу, становится существенным. И говоря о Codex как о новой рабочей системе, одно из самых больших изменений, которое только начинает появляться, — это идея возможности отделить вашу работу от физического сидения перед ноутбуком или настольным компьютером. Codex активно продвигается в этой области. Сначала у него был удаленный контроль, а теперь, конечно, Codex фактически доступен как полнофункциональная функция в приложении ChatGPT. И для большинства людей это не будет означать, что они теперь будут делать все со своего телефона, а просто то, что вы можете работать более гибко. Благодаря этим функциям удаленного управления вы можете улавливать намерения, пока идеи свежи, вы можете помочь перенаправить или направить поток, не открывая заново весь проект. Точно так же, как совет Джейсона заключался в том, что направление может использоваться для сокращения времени ожидания, удаленное управление фактически делает то же самое, но для гораздо более длительной работы. Если все больше и больше проектов занимают часы, а не минуты, возможность управлять ими на ходу — это огромное повышение производительности, и поэтому стоит потратить время на то, чтобы понять взаимосвязь между полнофункциональным опытом настольного компьютера и удаленными средствами управления, которые вы можете использовать для взаимодействия с мобильного устройства. Совет седьмой касается "heartbeats" (пульса), и любой, кто создавал Open Claw, будет хорошо знаком с этим паттерном. "Heartbeats" — это повторяющиеся или запланированные проверки, которые позволяют потоку, над которым вы работаете, снова "проснуться". "Heartbeats" могут быть запланированы по определенному времени, например, каждые полчаса, каждый час, или они могут быть привязаны к конкретным триггерам. Джейсон приводит несколько примеров, включая его поток "главного помощника". У него есть "heartbeat", который каждые 30 минут проверяет Slack и Gmail на наличие неотвеченных сообщений, чтобы помочь ему расставить приоритеты того, что важнее всего. Это именно тот тип функции, который был очень распространен для первых встроенных экспериментов в Open Claw. Джейсон также приводит пример, который показывает, как настройка экосистемы, с которой может взаимодействовать Codex, может сделать такой "heartbeat" еще более мощным. Говоря об анимационном проекте, Джейсон пишет: "Я опубликовал видео в Slack и попросил Codex проверять поток каждые 15 минут на предмет обратной связи, перерендерить новую версию при поступлении комментариев и ответить обратно в поток, пометив рецензента. Сервер Slack MCP не мог загружать файлы, поэтому агент использовал компьютер, чтобы нажать кнопку добавления файла и все равно отправить переработанный рендер". Другими словами, то, что говорит Джейсон, заключается в том, что инструменты, специфичные для Slack, не имели функции загрузки, поэтому он просто использовал компьютер для ручного выполнения этой задачи. "Интересная часть", — пишет Джейсон, — "не только в том, что он проверял Slack каждые 15 минут. Петля пересекала границы инструментов. Slack для обратной связи, Remotion для рендеринга, компьютер для загрузки. Именно тогда "heartbeats", коннекторы и использование компьютера перестают ощущаться как отдельные функции. Вместе они становятся циклом обратной связи, который продолжает работать без моего присутствия". Восьмой совет и поведенческий паттерн Джейсона связаны с целями, хотя он полностью признает, что все еще работает над их пониманием прямо сейчас. TLDR функции /goal, которая, кстати, теперь есть не только в Codex, но и в Cloud Code, заключается в том, что когда у вас есть проект с очень конкретными, известными и проверяемыми критериями успеха, вы можете использовать функцию целей, чтобы агент продолжал работать над этой целью, от которой обычный промпт мог бы просто отказаться. Я собираюсь пропустить цели здесь, потому что позже на неделе, либо как основной эпизод, либо как бонусный эпизод оператора, у меня будет полное руководство по целям, также основанное на недавних советах от самой команды Codex, но достаточно сказать, что цели достаточно велики для отдельного эпизода, поскольку люди действительно понимают, как это меняет поведенческий паттерн взаимодействия с агентами. Последний совет Джейсона — о боковой панели. И это одна из областей, где, я думаю, Джейсон думает иначе, чем многие другие. Он пишет: "Часть Codex, которая меня больше всего волнует, — это боковая панель. Легко думать о ней как о месте, где происходят предварительные просмотры, но это недооценивает ее. Боковая панель — это место, где Codex перестает быть просто приложением для чата и начинает становиться местом, где происходит работа". Для него, говорит он, она выполняет три задачи: инспекция артефактов, управление веб-сервисами и проверка изменений. И причина, по которой это так важно, заключается в том, что это пространство позволяет ему параллельно обрабатывать информацию и работать, даже когда другой агент работает. Важно, пишет он, не просто то, что Codex может генерировать артефакты, а то, что я могу их проверять и аннотировать, не нарушая цикл. И я думаю, здесь стоит сделать шаг назад, чтобы признать, что TLDR всего этого набора советов именно об этом — не нарушать цикл. Как, другими словами, вы позволяете агентам внутри Codex продолжать работать параллельно с их человеческим партнером, а не бесконечной серией ходов между ними? Я думаю, часть ценности советов Джейсона заключается даже просто в рассмотрении этого как желаемого поведенческого сдвига, что, конечно, не означает, что вы никогда не будете иметь такого пошагового взаимодействия с ИИ, когда вы даете ему промпт, позволяете ему что-то сделать, а затем проверяете его, когда он закончен. И это не значит, что я не верю, что если у вас не работает агент 24/7, вы каким-то образом не максимизируете ценность системы. Но для всех, кто обнаружил, что отвлекается на переключение контекста, пока ждет, пока эти все более мощные инструменты будут выполнять все более крупные задачи, такой сдвиг в мышлении имеет большой потенциал для реинтеграции этого рабочего опыта. Итак, на этом мы завершаем наши девять советов от команды Codex о том, как максимально использовать Codex. Конечно, в примечаниях к выпуску будет ссылка на оригинальный пост Джейсона. Надеюсь, это поможет вам получить больше от одного из самых мощных "harness", которые вы можете использовать. А пока на сегодня это все в AI Daily Brief. Спасибо за прослушивание или просмотр, как всегда, и до следующего раза, мир.