Anthropic just released 5 workshops showing latest capabilities of Fable 5

Спикер Дайан присоединилась к Anthropic в 2023 году и участвовала в создании каждой версии Claude начиная с Claude 2. Если считать количественно, это охватывает 21 версию, включая модели Haiku, Sonnet, Opus, A сейчас — Fable и Mythos, предназначенные для конечных пользователей и разработчиков.

Буквально несколько часов назад состоялся релиз Claude Fable 5 и Claude Mythos 5 — первого поколения пятых моделей. Fable 5 — это самая мощная модель, когда-либо выпущенная компанией Anthropic и ставшая общедоступной. Она базируется на тех же фундаментальных принципах, что и Mythos 5. Эти модели уже ускоряют работу внутри самой компании Anthropic. Для разработчиков же появление Claude Fable 5 означает, что модель станет мощнее, а отправная точка для реализации проектов сместится вперед.

В Anthropic часто говорят об экспоненциальном росте, но что это означает на практике? По мнению компании, по мере роста интеллектуальности моделей ценность вариантов их использования растет экспоненциально. Например, agentic coding (агентное программирование), которым многие пользуются сегодня, значительно ценнее, чем простое автодополнение кода, которое было доступно всего несколько лет назад.

Компания Anthropic уже наблюдает этот прогресс с моделью Fable 5. С точки зрения программирования, где пользователи, скорее всего, первыми ощутят «магию» этой модели, Fable 5 демонстрирует наилучшие результаты на бенчмарке SweetBench Pro. Однако сам бенчмарк не полностью отражает реальную картину: чем сложнее, длиннее и изощреннее задача, тем больше становится разрыв между возможностями Fable 5 и любой другой моделью на рынке.

Этот разрыв обусловлен двумя ключевыми факторами:

Во-первых, это single-shot correctness (корректность выполнения с первой попытки). Если дать Fable 5 сложную, четко сформулированную задачу, модель справится с ней с первого прохода. Первые тестировщики отмечают, что с помощью единичных промптов им удается создавать результат, на который у группы команд ушли бы дни или даже недели работы.

Во-вторых, это long horizon autonomy (автономия на длинной дистанции). Fable 5 способна работать в течение нескольких дней над одной целью, сохраняя при этом последовательность действий на протяжении всего процесса. Она помнит технические требования пользователя даже в задачах, охватывающих миллионы токенов. Кроме того, модель может распределять подзадачи между «субагентами», поддерживать их выполнение, и делать это значительно надежнее, экономнее и с большей осознанностью, чем любая другая модель, выпущенная компанией ранее.

Дополнительным преимуществом является то, что Fable 5 не просто хорошо пишет код; она еще лучше справляется с задачами чтения и анализа. Она эффективнее диагностирует сбои (outages), лучше «разбирается» в истории репозитория, чтобы понять, что и когда сломалось, а также способна проактивно предлагать рекомендации по улучшению кодовой базы.

Fable 5 представляет собой серьезный шаг за пределы исключительно кодинга. Начинать работу следует с тех задач, на которых строятся процессы в организациях и компаниях: будь то финансовый анализ, работа с документами, презентациями или электронными таблицами. Fable 5 управляет этой работой от начала и до конца. Модель следует инструкциям, придерживается поставленных рамок, а итоговый результат будет профессионального уровня (professional grade), так как это модель, созданная специально для рабочих процессов масштабируемых систем.

Новая версия также эффективнее работает с задачами, где исходные запросы сформулированы нечетко. Когда вы даете Fable 5 запутанную, многопоточную задачу и просите разобраться, что делать дальше, модель способна выполнить эту работу и превзойти другие версии Claude. Кроме того, данная версия Fable 5 является лучшей в индустрии по уровню восприятия визуальной информации: модель способна считывать плотные технические изображения, веб-приложения, графики, диаграммы и таблицы гораздо точнее, чем любая другая версия Claude, выпускавшаяся ранее.

Все вышесказанное относится к положительным сторонам модели такой мощности. Однако интеллект подобного масштаба является палкой о два конца. Два месяца назад был запущен проект Project Glasswing, а Mythos Preview стал доступен небольшой группе партнеров, так как возможности этой модели в области кибербезопасности были достаточно сильны, чтобы потенциально привести к злоупотреблениям. С тех пор была создана новая система безопасности (safeguard system), которая позволяет использовать этот интеллект всем пользователям Fable 5.

Принцип работы этой системы заключается в следующем: когда запрос пользователя касается тем кибербезопасности, биологии или химии, Fable 5 перенаправляет его на следующую по мощности модель — Opus 4.8. Ответ в таком случае будет четко обозначен, и тарификация будет производиться по ценам Opus.

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

Клиенты уже активно используют модель Fable 5 и получают от неё ощутимую пользу. Например, компания Rakuten обнаружила, что Fable 5 эффективно справляется с задачами высокого уровня сложности, подтверждая и валидируя выполняемую работу. Для них это означает возможность реализации автономных автоматизированных операций в масштабе.

Компания Cognition протестировала Fable 5 на своем внутреннем бенчмарке для программирования FrontierBench, предназначенном для оценки передовых моделей, и она показала самый высокий результат среди всех протестированных моделей. Они отметили способность модели к long horizon reasoning (рассуждению на длинных временных горизонтах), а также то, как «из коробки» она обобщает знания при работе с незнакомыми инструментами и в сложных контекстах.

Кроме того, команда GenSpark сообщила, что Fable 5 заняла первое место в их внутренних оценках, победив в прямом сравнении каждую версию модели, которую они ранее тестировали. Она показывает наилучшие результаты в наиболее сложных задачах, таких как дизайн пользовательских интерфейсов (UI design) и написание кода для игр (game coding).

Относительно модели Mythos 5: она базируется на той же фундаментальной модели, что и Fable 5, однако в ней сняты ограничения (safeguards) в сферах кибербезопасности и биологии. В рамках Mythos Preview была продемонстрирована базовая функциональность этого класса моделей, а Mythos 5 делает еще один шаг вперед. На данный момент она доступна партнерам в рамках проекта Project Glasswing. Позднее в этом месяце планируется расширить доступ к Mythos 5 для исследователей в области биологических наук, поскольку те же самые возможности, которые делают биологические исследования рискованными, одновременно обладают и наибольшим потенциалом для создания реальной пользы с помощью ИИ.

Рассуждая о том, что разработчики могут делать с Fable 5, полезно опираться на метрику time horizon (временной горизонт). Она определяет, как долго модель может работать автономно, прежде чем потеряет логическую связность в отношении того, что делать дальше.

Благодаря Fable 5 появились proactive agents (проактивные агенты) — агенты, которые знают, что нужно делать, без дополнительных указаний. Они могут брать на себя ответственность за цели более высокого уровня, требующие суждения (judgment), сотрудничества (collaboration) и «проактивного вкуса» (proactive taste). Например, вместо того чтобы просить Claude написать обновление по проекту, теперь можно попросить Fable обеспечить выполнение плана проекта в течение всей недели. Вместо того чтобы просить Claude создать финансовый прогноз, можно поручить Fable взять его на себя, обновлять, итерировать и улучшать прогноз для поддержания его точности.

Поскольку прогресс в ИИ демонстрирует экспоненциальный рост, необходимо строить системы с расчетом на формирующиеся возможности (emerging capabilities), а не только на текущие модели. Ожидается, что будущие версии Claude будут еще более функциональными, чем те, которые выпускаются сегодня. Fable 5 и Mythos 5 — это лишь краткий взгляд в такое будущее.

Для того чтобы успешно использовать грядущие изменения, разработчикам следует проектировать свои решения с прицелом на следующую версию Claude, а не только на текущую. Опыт показывает, что выигрывают те разработчики, чьи архитектуры, harnesses (обвязки) и продуктовые решения уже готовы к следующему скачку в интеллекте модели.

По мере того как модели становятся умнее, они могут выполнять более сложные задачи, используя более базовые примитивы — такие как файловая система или изолированные среды вычислений (sandbox computing environments). Это означает, что потребность в сложных и громоздких «обвязках» (harnesses) со временем снижается.

По мере роста интеллектуальных возможностей моделей вам также необходимо начинать проводить более сложные evals (оценки) и создавать прототипы продуктов для тех задач, которые, возможно, еще не работают должным образом. Это единственный способ почувствовать, что экспоненциальный прогресс происходит прямо под вами. Когда задача, прототип или продуктовый опыт, который раньше работал плохо, внезапно начинает работать эффективно — это сигнал к тому, что пора выпускать в свет нечто по-настоящему «магическое», что было невозможно реализовать ранее.

Команды, которые достигают успеха в условиях постоянно ускоряющегося темпа развития технологий, рассматривают обновления моделей как новые бизнес-возможности и стремятся извлечь из них максимум. Вам следует сделать процесс перехода на новые версии моделей максимально легким. Для этого важно внедрять автоматизированные evals, отлаживать процессы тестирования и сохранять практический подход: продолжать тестировать, «продавливать» границы возможностей и создавать новые продукты с помощью новых версий Claude. Именно так вы поймете, когда новые возможности модели станут достаточными для предоставления клиентам уникального пользовательского опыта.

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

Мы начинаем с обзора инфраструктуры Cloud Managed Agents. С момента запуска этого направления мы видим значительный органический рост использования агентов и то, как они существенно ускоряют рабочие процессы разработчиков. Наш опыт охватывает широкий спектр пользователей: от небольших стартапов до крупнейших предприятий. Сегодня мы обсудим экспоненциальный рост возможностей искусственного интеллекта и его влияние на разработку агентов, рассмотрим паттерны агентной разработки, которые привели нас к созданию Cloud Managed Agents, изучим архитектурные блоки для построения агентов и разберем некоторые из наших последних функций.

Как мы все наблюдаем, модели становятся экспоненциально более мощными, и вместе с этим растут наши ожидания. Чем сложнее возможности модели, тем более изощренные задачи мы делегируем. Сейчас мы видим, что «узким местом» все чаще становится инфраструктура, а не сам интеллект. Рассмотрим это на примерах: два года назад, когда был анонсирован Opus 3, вы могли использовать его для написания и тестирования одного компонента, что занимало минуты сфокусированной работы. В прошлом году, с выходом моделей Claude 4, мы вышли на уровень выше — агент мог отлаживать целый набор файлов. Это занимало час или около того, но требовало активного управления с вашей стороны. С нашими текущими моделями этого года агенты запускаются на всю ночь, работают в командах, просматривают ваш бэклог и выполняют всё запланированное до того, как вы проснетесь. В ближайшем будущем мы ожидаем появления моделей, способных выполнять задачи, на которые целым командам людей раньше требовались месяцы, причем агенты будут делать это полностью автономно. Например, мультиагентные системы смогут координировать и проводить целый процесс слияний и поглощений (M&A) от начала до конца за долю времени, которое потребовалось бы нам.

По мере того как задачи перешли от простых пошаговых инструкций к описанию конечных результатов, нам потребовалось больше, чем просто промпты и циклы инструментов. Нам нужна надежная и масштабируемая агентная инфраструктура. Для эффективной работы таких мощных моделей, как Fable, им необходим глубокий доступ к ресурсам. Невозможно запустить эффективного агента, не предоставив ему доступ к вашим учетным данным, внутренним базам знаний или базам данных. Если вы хотите, чтобы агенты писали для вас код, им нужен доступ к кодовым базам для отправки Pull Requests (PR) и деплоя в продакшн. Наконец, им необходимы возможности идентификации и аутентификации. Агенты все чаще действуют не просто как безликие системы, а от нашего имени, используя наши электронные письма и Slack.

По мере предоставления агентам человекоподобных возможностей, мы ожидаем более человекоподобного взаимодействия. Форматы взаимодействия не меняются, меняется лишь длительность. Некоторые агенты очень разговорчивы: вы направляете их и даете советы по пути, возможно, даже прерываете их, если считаете, что они отклоняются от маршрута. Другие агенты, работающие на таких моделях, как Fable, ориентированы исключительно на результат. Если у вас есть четкий сигнал или рубрикатор того, что должно быть сделано, вы можете предоставить это агенту, и он будет итерировать до тех пор, пока не будут выполнены критерии выхода. Кроме того, иногда вы можете запустить задачу несколько дней назад и захотеть вернуться к ней позже. Надежная агентная платформа должна поддерживать все эти сценарии и паттерны взаимодействия. Предоставляемые нами инфраструктура и примитивы должны обеспечивать это «из коробки», оставаясь при этом гибкими, чтобы вы могли настроить их под свои нужды.

Исторически сложилось так, что нагрузка по созданию такой среды ложилась на плечи разработчика. В ходе наших исследований перед запуском Cloud Managed Agents мы выяснили, что разработчики стремятся к использованию возможностей ИИ, но сталкиваются с рядом проблем. Во-первых, это управление контекстом: настройка правильного контекста в нужное время — сложная задача, но критически важная. Предоставление контекста не вовремя может стать огромным отвлекающим фактором для агентов. Во-вторых, половина наших разработчиков называет инфраструктурные проблемы своим главным блокировщиком в продакшене. Агенты создают «взрывные» нагрузки и непредсказуемые паттерны вычислений, поэтому сложно масштабироваться безопасно, соблюдая при этом целевые показатели задержки (latency). В-третьих, наблюдаемость (observability) крайне затруднена: трудно понять, когда агент выдает качественные результаты, поскольку модели недетерминированы и производят огромные объемы неструктурированных данных.

Таким образом, мы пришли к Cloud Managed Agents. Мы проделали всю тяжелую работу по созданию платформы, чтобы вам не пришлось делать это самостоятельно. Cloud Managed Agents объединяет инфраструктуру, агентные примитивы и встроенную наблюдаемость в единый пакет на нашей облачной платформе.

Базовые строительные блоки

В самом ядре системы находится агент, который вы определяете. Это включает системный промпт, выбранную модель, навыки (skills), загруженные в агента, а также инструменты и разрешения для них. Это формирует «идентичность» агента. Следующим блоком является конфигурация окружения (environment) — это шаблон, где вы определяете сетевые разрешения («allow list») и любые предустановленные пакеты. Это «мир», в котором будет жить агент. На основе агента и окружения запускается сессия: для вас подготавливается «песочница» (sandbox), настраивается окружение, а запрашиваемые вами ресурсы и учетные данные монтируются внутрь. Последним компонентом являются события (events) — все, что агент производит в процессе выполнения действий, или события, которые вы предоставляете для управления агентом. Именно события и состояние (stateful awareness) позволяют нам предоставлять платформу, на которой вы можете строить собственные продукты, используя такие примитивы, как память.

События как основа

События — это основа агентной интеграции. В Cloud Managed Agents все основано на событиях, которые представляют собой структурированные, устойчивые транскрипты, помогающие отслеживать прогресс агента:

• User events: то, что вы отправляете агенту для его направления.
• Agent events: то, что агент делает на самом деле (обмен сообщениями, выполнение инструментов, компактизация контекста, делегирование другим агентам).
• Session events: прогресс единицы работы, которую вы делегировали (общий жизненный цикл, переходы состояний, ошибки, результаты).
• Span events: инструменты для группировки связанных событий, позволяющие видеть все в агрегированном, инструментированном виде.

Пример использования: Pascal

Для демонстрации приведем пример Pascal — гипотетического сервиса доставки продуктов, который использует данные о заказах для их анализа и предоставления инсайтов команде. Агент выполняет аналитику за считанные минуты, опираясь на предустановленный набор данных и Python-пакеты, загруженные в контейнер. Вы можете видеть каждое событие в консоли и даже общаться с отладочным агентом для оптимизации интеграции. В режиме реального времени в консоли разработчика мы видим события, конфигурацию агента и настройки окружения (сетевые разрешения, пакеты). Мы можем получить инсайты, например, о популярности товаров или предпочтениях клиентов по времени заказов. Также доступна функциональность «симулятора предсказаний» для анализа вероятности повторных заказов. Панель отладки позволяет проанализировать саму сессию, где агент изучает все события и дает советы по оптимизации интеграции (например, какой Python-код выполняется слишком медленно).

Начать работу с Cloud Managed Agents можно несколькими способами: через Claude API в Cloud Code, через CLI (полезно для CI/CD пайплайнов) или воспользовавшись нашей документацией с практическими примерами («кулинарными книгами»).

Продвинутые возможности

Мы недавно внедрили несколько новых функций:

• Мультиагентная оркестрация: Claude может делегировать задачи другим агентам с независимыми окнами контекста, что позволяет распараллеливать сложные задачи.
• Outcomes: Claude итерирует над заранее определенными критериями выхода или рубрикаторами, пока не достигнет цели.
• Memory: Claude может читать и писать в хранилища памяти. По умолчанию агент начинает сессию «с чистого листа», но с памятью он обладает осознанием предыдущих запусков.
• Dreaming: функция, построенная на базе памяти, где Claude размышляет, кодирует полученные знания, превращая их в новые, более оптимизированные «воспоминания» для следующих сессий.

Мы также работаем над модульностью инфраструктуры:

• Self-hosted sandboxes: вы можете запустить цикл агента и выполнение инструментов внутри вашей инфраструктуры, чтобы файлы и пакеты не покидали ваш периметр.
• MCP tunneling: Claude может получать доступ к закрытым серверам MCP, которые вы не хотите выставлять в открытый интернет.
• Scheduled deployments: позволяют настроить повторяющееся расписание для запуска сессий для регулярных задач.
• Environment variables inside Vaults: позволяют безопасно предоставлять учетные данные для API или CLI, к которым Claude должен обращаться, без риска прямого отображения секретных токенов. При использовании этой функции внутри контейнера размещается непрозрачный токен-заполнитель, к которому Claude имеет доступ. Когда Claude пытается обратиться к API или CLI, он использует эту переменную среды, а система подставляет реальный секрет, который остается скрытым от самого агента.

Вслед за демонстрацией создания производственных агентов на платформе Claude, Claude Code переносит те же возможности и на работу разработчика. Речь идет не об агентах, которые вы поставляете клиентам, а об агентах, которые пишут код для вас.

Миссия Claude Code состоит в том, чтобы преодолеть разрыв между идеей и готовым продуктом. Инструменты, которые мы создаем, позволяют использовать «интеллект передового уровня» (frontier intelligence) наших моделей и делают эти возможности доступными для каждого разработчика. У компании нет готовой, полностью расписанной «дорожной карты» развития; разработчики продукта описывают себя как альпинистов, которые поднимаются вместе с пользователями по еще не до конца изученному ландшафту, в процессе выясняя, что работает лучше всего. Мы растем вместе с пользователями, наращивая возможности ИИ и помогая справляться с новыми возникающими задачами.

За последний год характер взаимодействия с Claude Code кардинально изменился. Раньше разработчик давал задание Claude Code, а затем просматривал каждое сделанное им редактирование, давая подробные инструкции, что именно нужно сделать, прорабатывая каждую мелкую деталь простых задач. Сегодня многие используют auto mode, делегируя полномочия Claude, и проверяют результат только после того, как Claude Code уже протестировал изменения и создал Pull Request (PR), готовый к ревью.

Эволюция интерфейсов Claude Code

Claude Code начинался как инструмент командной строки (CLI), и это остается основным местом для продвинутых пользователей, которым нужен минималистичный текстовый интерфейс, максимальный контроль и возможности настройки. Затем была добавлена поддержка IDE для тех, кому нужны те же мощные агенты, но они хотят следить за всеми изменениями кода в процессе.

От пользователей поступил запрос на возможность запуска нескольких процессов Claude Code параллельно. Это явление они ласково назвали multi-clotting. Чтобы упростить этот процесс, были добавлены два новых интерфейса:

1. Claude Code на Claude Desktop: предназначен для тех, кому нужен полноэкранный графический интерфейс со встроенными предварительными просмотрами, боковой панелью управления, а также возможностью отображать изображения и развернутые результаты вывода. Claude Desktop создан как единое представление для всех локальных и облачных сессий, с визуальными индикаторами, показывающими, какие агенты работают, а какие требуют ввода от пользователя.
2. Claude Agents View в CLI: новейший интерфейс для тех, кто хочет иметь панель управления, не покидая терминал. Он позволяет видеть, какие задачи ждут подтверждения, что выполняется прямо сейчас, а что уже завершено. В этом режиме можно отвечать на запросы в строке (inline), чтобы разблокировать процесс, или переключаться между сессиями, не теряя контекста.

VS Code IDE extension и приложение Claude Code на Claude Desktop построены на базе Claude Agent SDK — того же инструмента, на основе которого многие разработчики сегодня создают собственные решения.

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

На основе отзывов пользователей в сообществе был разработан ряд новых функций и инструментов, направленных на решение конкретных задач разработчиков.

Так как пользователи выражали желание тратить меньше времени на code review, был выпущен продукт, который использует команду агентов для обнаружения критических ошибок в PR. Этот инструмент ежедневно используют тысячи компаний, включая все внутренние команды Anthropic.

Для обеспечения возможности работать в любом месте была запущена поддержка удаленного управления и Code на iOS и Android. Это позволяет не быть привязанным к ноутбуку или рабочему месту и выполнять задачи по написанию кода в любое время.

Для автоматизации запуска Code по новым тикетам были созданы routines (рутины). Их можно настроить один раз, после чего они будут запускаться по расписанию, через webhook или API call, инициируя работу Code над нужной задачей. Это автоматизирует работу, которая раньше требовала ручного запуска человеком.

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

Для выполнения масштабных и амбициозных задач, таких как крупные рефакторинги и миграции, были запущены dynamic workflows (динамические рабочие процессы). Они позволяют запускать Code параллельно — с использованием десятков или сотен агентов в детерминированной структуре — для решения наиболее сложных задач. Все эти примитивы могут комбинироваться друг с другом, что позволяет легче адаптироваться к будущему инженерного дела.

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

Например, компания Spotify использует Cloud для миграции тысяч репозиториев. Их команда создала фонового агента на Cloud agent SDK, который считывает план миграции на простом английском языке, а затем запускает парк агентов, создающих PR. Благодаря этому они объединяют в продакшн более 1000 PR в месяц и сократили время на миграцию на 90%.

Другим примером является Mercari — японский маркетплейс формата «потребитель для потребителя». Вся инженерная команда Mercari работает с использованием Code, и они измерили, что производительность инженеров выросла на 90% год к году благодаря этому инструменту. Подобные тенденции наблюдаются по всей индустрии: миллионы разработчиков выполняют больше работы и с более высоким качеством, чем раньше.

Для демонстрации возможностей Dynamic Workflows представим, что мы работаем в компании Kaizen Operations, занимающейся созданием приложений для инженерных команд. Наш текущий маркетинговый веб-сайт существует только на английском языке, но мы планируем вывести его на 13 дополнительных рынков, поэтому перед запуском необходимо провести локализацию.

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

Вместо этого мы используем Dynamic Workflows, что позволяет Claude создать воспроизводимый процесс и выполнять каждый из новых переводов одновременно, в параллельном режиме. Мы просим Claude применить рабочий процесс (workflow) для перевода на эти 12 новых языков. После того как Claude создает рабочий процесс, его можно открыть на боковой панели и наблюдать за его выполнением. Это мощная функция десктопного приложения Claude Code, в котором можно увидеть, как все 12 агентов перевода работают одновременно.

После завершения работы агентов перевода система создает еще 12 агентов для проверки качества перевода на всех новых языках. Эта задача, которая ранее потребовала бы выполнения 12 отдельных операций, теперь может быть завершена с помощью всего одного промпта. Кроме того, такой рабочий процесс можно сохранить в виде JavaScript-кода и использовать повторно для будущих переводов. В результате Claude создает 12 новых версий веб-сайта, полностью локализованных с помощью одного действия. Мы можем просмотреть их все в выпадающем меню и проверить качество работы на разных языках.

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

Все, что было показано, доступно уже сегодня, включая Dynamic Workflows и возможности десктопного приложения Claude Code. Новейшая модель, Claude 3.5, также доступна всем пользователям Claude Code, что позволяет использовать её интеллект везде, где вы применяете Claude Code. Мы надеемся, что эти функции помогут вам сократить разрыв между идеей и готовым продуктом.

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

Я призываю вас провести остаток дня, исследуя эти уровни. Посещайте исследовательские доклады (research talks), если хотите узнать больше о новейших возможностях моделей. Присоединяйтесь к сессиям по платформе Cloud (Cloud Platform Sessions), если вы создаете собственных агентов для конечных пользователей. Или приходите на воркшопы Cloud Code, если хотите узнать больше способов внедрения Cloud Code в вашу повседневную работу по разработке.

Всё это работает на Cloud Fable 5 — лучшей модели, которую мы когда-либо выпускали для агентной работы (agentic work), и она доступна уже сегодня. Спасибо всем, и наслаждайтесь Code with Cloud.

Theo, являющийся research product manager в компании Anthropic, работает над возможностями долгосрочного планирования (long horizon capabilities), такими как длинный контекст и память, интегрированные в модели. Он присоединился к компании примерно два года назад, как раз в момент запуска модели Sonnet 3.5.

На тот момент термин «агенты» (agents) практически не использовался. Модели демонстрировали лишь первые, зачаточные признаки жизни в плане возможностей написания кода. Основное внимание индустрии все еще было сосредоточено на чат-комплитах (chat completions), в то время как автономность и концепция агентной автономии считались чем-то совершенно новым. Если вернуться к этому же времени в прошлом году, когда проходило мероприятие «Code with Claude», можно заметить, что Opus 4 только что был запущен. Claude Code тогда не был даже общедоступен (GA — General Availability); это было довольно зарождающееся направление. В то время было неизвестно, получит ли эта технология развитие, так как использование моделей для автономного кодинга было новой концепцией. Сейчас ситуация изменилась: у нас есть Fable, есть Mythos, и недавно был запущен Opus 4.8.

Сравнивая текущую ситуацию с прошлым годом, можно увидеть значительный рост осведомленности. Еще год назад, во время мероприятия «Code with Claude», люди спрашивали базовые вещи: что такое большие языковые модели (large language models), для чего они нужны и как их лучше использовать. Сейчас ситуация радикально иная: наблюдается гораздо больше осведомленности об ИИ, гораздо больше людей используют его в повседневной жизни и, что важно, наблюдают реальный рост собственной продуктивности и эффективности.

Объективные показатели подтверждают этот прогресс: с каждым годом Claude пишет все больше кода. Недавно в блоге была опубликована информация о рекурсивном самосовершенствовании (recursive self-improvement): более 80% кода внутри компании Anthropic проходит стадию объединения (merged) именно благодаря работе Claude. Таким образом, по мере того как модели совершенствуются, мы ожидаем, что возможности и «потолок» этих способностей будут только расти. Данное выступление посвящено тому, как адаптироваться к этому новому миру и как разработчикам начать мыслить категориями создания решений для будущего, а не для прошлого.

На слайде представлены результаты производительности ряда моделей на тесте SWE-bench Verified. Это доверенный тест по программированию (coding eval), который используется внутри компании для оценки прогресса Claude в написании кода. SWE-bench Verified состоит из серии GitHub issues, которые модель должна успешно решить, после чего готовое решение запускается на тестах, чтобы проверить, успешно ли выполнена задача. Если рассмотреть показатели Sonnet 3.7, то модель набрала чуть больше 60%. В случае с Opus 4.8 показатель достиг 88%. Кроме того, при использовании моделей Mythos и Fable стало очевидно, что данный бенчмарк фактически насыщен (saturated).

Это невероятное достижение, масштаб которого даже не полностью передает график. Переход с 62% до 88% всего за 12 месяцев означает, что модель Sonnet 3.7 в этих задачах ошибалась в три раза чаще. Стоит задуматься об этом на секунду. Таковы темпы совершенствования моделей за последний год, и скорость этого прогресса только растет. Далее демонстрируется одна и та же задача, выполненная разными моделями с разницей в 12 месяцев: пересборка веб-сайта Claude.ai за один подход.

Сначала демонстрируется работа Sonnet 4 на данной задаче. Видно, что модель пишет очень большое количество строк кода, вызывает множество инструментов и переходит к действиям сразу, не планируя их предварительно. При попытке запуска полученного интерфейса выясняется, что он не работает: выглядит вроде бы сносно, но функционально не пригоден.

Модель Opus 4.8 построила бы абсолютно такой же интерфейс, но уже с верными цветами, соответствующими сайту Claude.ai. В нем была бы видна боковая панель и интерфейс чата, можно было бы отправлять сообщения, которые корректно обрабатывались бы. Эта модель планирует действия до того, как переходит к их выполнению. Умение планировать перед действием приводит к значительно меньшему количеству вызовов инструментов и меньшему объему написанного кода. В итоге Opus 4.8 справляется с задачей более успешно, выполняя её быстрее и экономичнее.

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

Старые модели работали подобно человеку, собирающему мебель из IKEA: они сразу приступали к делу, не заглядывая в инструкцию, начинали строить, терпели неудачу, а затем осознавали, что им необходимо вернуться назад и все-таки прочитать инструкцию. Они действовали, не задумываясь о планировании. Современные модели, напротив, сначала планируют: они продумывают спецификацию задачи до того, как приступят к её выполнению.

Благодаря предварительному планированию спецификации модели становятся эффективнее. В процессе такого препланирования модель способна заметить и исправить ошибки. В результате можно увидеть, как модель использует фразы вроде «actually» (на самом деле) или «never mind» (неважно, забудь), пересматривая свои выводы. Исправляя ошибки на этапе планирования, модель способна более эффективно выполнить задачу с первого раза.

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

Вторая область, где мы наблюдаем значительный прирост интеллекта, — это восстановление после ошибок (error recovery) и самокоррекция.

Старые модели были склонны к тому, что называется doom looping (бесконечный цикл ошибок). Doom looping — это ситуация, при которой модели дают задание, она приступает к его выполнению, но терпит неудачу. Когда вы сообщаете модели: «Я думаю, тебе стоило сделать иначе», — или когда среда (внешние условия) дает обратную связь о неверном действии, модель отвечает: «Отлично, давай попробую еще раз». Однако при повторной попытке она продолжает выполнять ровно то же решение, которое провалилось, и не меняет своего подхода.

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

Для вас это означает необходимость проектировать среду взаимодействия так, чтобы вы могли предоставлять модели обратную связь по ходу дела. Это позволит ей успешно восстанавливаться после любых ошибок, с которыми она сталкивается в процессе. Кроме того, это изменение подхода предотвращает бессмысленную трату токенов на «doom looping» — модели становятся способны выполнять задачи, используя в конечном итоге меньшее количество токенов.

Современные модели демонстрируют значительные улучшения в работе с всё более длинными временными горизонтами. Это означает, что модели способны поддерживать внимание и сохранять согласованность контекста на протяжении объема до миллиона токенов и иногда даже больше. В прошлом модели могли «потерять нить» повествования на полпути и забыть поставленную задачу. Часто говорят, что модель «lose the plot» (теряет сюжет) — это состояние, когда модель забывает задачу или исходные инструкции в процессе выполнения, из-за чего начинает отклоняться от ожидаемого пути. Сейчас мы наблюдаем, что эта проблема значительно решена, хотя, конечно, есть возможности для совершенствования по мере увеличения длины контекста.

Возможность работы с полным миллионом токенов означает, что пользователю не нужно выполнять такой объем работ по управлению контекстом, как раньше: нет необходимости разбивать окно контекста на части («chunk up») столь активно, как требовалось до этого. Тем не менее, если необходимо работать с объемами данных, значительно превышающими миллион токенов, определенные манипуляции всё же могут потребоваться. Следует стремиться к более амбициозным задачам: теперь можно передавать модели не один файл, а полноценную кодовую базу целиком, поскольку модели стали значительно лучше справляться с планированием.

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

Типичный процесс работы таких агентов выглядит следующим образом: сначала агент составляет план, затем выполняет его. Далее агенту предоставляется возможность верификации (проверки) выполненного плана. Это может быть реализовано через обратную связь от человека в ходе диалога или путем обращения к специализированному инструментальному агенту (tool agent), который проверяет полученные результаты. На основе этой верификации агент корректирует свой план, и этот цикл повторяется до тех пор, пока модель не придет к итоговому результату, который ее полностью устраивает.

Отзывы от партнеров подтверждают эти качественные сдвиги. В компании Shopify отметили, что модель Claude Opus 4.8 демонстрирует заметно лучшие результаты в исправлении ошибок и планировании перед выполнением действий. В компании Cursor увидели, что в моделях значительно улучшилась эффективность работы с токенами и вызов инструментов (tool calling), и что Opus 4.8 превосходит все остальные модели Opus, которые они тестировали. Аналогично, в компании Cognition заметили, что Opus 4.8 является «более автономной», способна работать с гораздо более длинными временными горизонтами и при этом является более эффективной с точки зрения потребления токенов.

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

Переход к разработке с учётом развития моделей будущего требует изменения мышления. Это касается не только актуальных моделей, доступных сегодня, но и понимания того, как разработчику действовать по мере улучшения моделей, чтобы пользователи получали все преимущества растущего интеллектуального потенциала технологий.

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

Первый шаг к такой готовности — это создание evals (систем оценки). Если они у вас уже есть, их нужно обновлять, но зачастую для многих это первый шаг к пониманию того, что в принципе возможно в современных моделях. Если у вас ещё нет систем оценки, воспринимайте их как unit tests для ИИ.

Некоторые из этих тестов могут быть основаны на регрессии — это задачи, которые модели уже способны выполнять сегодня. Они нужны для проверки того, справляются ли текущая конфигурация или будущие модели с теми же задачами, что и раньше. Однако зачастую вам нужно создавать такие evals, которые не «насыщаются» текущими моделями. Это означает, что нужно смотреть не только на текущий пользовательский опыт, который вы обеспечиваете, но и на тот опыт, который вы хотите предоставить пользователям в долгосрочной перспективе, а также на направление, в котором вы хотите развивать своё приложение. Необходимо внедрять соответствующие тестовые сценарии в свои системы оценки. Также это включает в себя поиск «моделей отказа» (failure modes), о которых сообщают пользователи: добавляйте их в свои evals и проверяйте, смогут ли новые модели «из коробки» исправить эти ошибки.

Во-вторых, обновляйте те evals, которые могли достигнуть точки насыщения. Часто при запуске новых моделей мы слышим от пользователей: «Я прогнал тест, и качество улучшилось всего на 1% — не думаю, что эта модель стала намного лучше». Но со временем, начав больше экспериментировать с моделью, они осознают, что она значительно продуктивнее, просто в тех аспектах, которые их система оценки вообще не тестировала. Это подтверждение того, что если вы видите, что показатели вашего теста практически не меняются, вам следует проверить, являются ли оставшиеся нерешёнными задачи в этом тесте честными и решаемыми. Если нет, значит, ваш eval насыщен, и пора его обновлять, подбирая более сложные задачи.

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

An important operational change is to shrink your scaffolding. Scaffolding is defined as the prompts, tools, and code that surround the model; this architecture is sometimes referred to as the harness. Users and developers often add new components to this harness over time as a reaction to various failure modes encountered by previous model iterations.

The lecturer provides an example from their experience with the Claude AI system prompt. At one point, the prompt contained a line specifying a particular citation format that eventually became obsolete. Because their new models exhibited significantly better instruction following, the models began to strictly adhere to that outdated system prompt instruction. The team initially believed that the citation functionality in the new model was broken, until they examined the system prompt and realized the model was simply succeeding at following the legacy instruction added some time ago. The necessary solution was to remove that line from the system prompt entirely.

This case study demonstrates that shrinking scaffolding and allowing the model more autonomy helps reveal the model's actual capabilities in practice. The recommended approach is to write prompts focused on intent and the intended final outcome, rather than crafting prompts specifically to address every past failure encountered with previous models.

Models must also be given room to work. This involves adaptive thinking, which provides the model the ability to decide both when it needs to think and the depth of thought required. Furthermore, there is an effort dial that allows developers to manually adjust the intensity of the work the model dedicates to solving specific problems.

It is also necessary to allow agents greater access to the environment to facilitate taking actions, provided this access is controlled. As models become more intelligent and autonomous, their potential remains untapped unless they are given the capability to act. The lecturer notes that internal teams launched AutoMode within Claude Code; this functions as a classifier that identifies which actions are safe for the model to perform. While a model should not be allowed to run wild or perform destructive operations like deleting files in its environment, using a classifier approach enables the right balance between necessary safety controls and granting the model sufficient freedom.

Finally, you must close the agent loop. While models currently exhibit strong error recovery, the model needs to know when an error has occurred to fix it. To achieve this, you must give the model a way to verify its outputs. For instance, when building an agent for application development, one might provide a computer use tool. This tool allows the agent to perform Quality Assurance (QA) on the front end, click around the interface, and see if it functions as expected. Receiving this feedback from the environment allows the model to understand if it should proceed or if it needs to go back and update the code.

Данная сессия стоит ваших усилий, потому что мы будем говорить не просто о создании агентов, а о том, как осуществлять deploy (развертывание) агентов. Речь пойдет о том, как сделать их secure (безопасными), reliable (надежными), performant (производительными) и — что наиболее важно — cost-effective (экономически эффективными). Это необходимо, чтобы вы могли действительно работать в масштабе.

Я знаю, что многие из вас уже начали создавать агентов. Некоторые, возможно, уже имеют агентов в production (в промышленной эксплуатации), но лишь немногие из вас действительно довольны производительностью, надежностью и ценовой эффективностью своих агентов. Именно поэтому данная лекция углубляется в эти вопросы, и это сделает её полезной для вас. Перейдем к детальному рассмотрению.

Прежде чем переходить к обсуждению других техник и инструментов, необходимо поговорить о Prompt Caching (кэшировании промптов). Это самый важный вывод из всей лекции.

В длительных агентных приложениях происходит множество вызовов инструментов и множество итераций взаимодействия с пользователем, из-за чего транскрипты становятся очень длинными. Каждый запрос к API в таком случае повторяет эти длинные сегменты промпта. Если пересчитывать эти сегменты каждый раз заново, это становится дорогим и медленным процессом.

Prompt Caching решает эту проблему, позволяя предварительно вычислять общую часть контекста. Мы сохраняем эти предварительно вычисленные части промпта на своих серверах в виде промежуточных значений, которые мы называем KV values (Key-Value values). Таким образом, когда приходит следующий запрос, нам нужно вычислить только небольшую дельту (разницу) по сравнению с предыдущим запросом. Это экономит значительный объем вычислительных ресурсов, и мы передаем эту экономию пользователям.

Самым важным преимуществом Prompt Caching является скидка 90% — вы платите всего 10% от стоимости при использовании технологии кэширования. Кроме того, вы получаете более быстрое время отклика, а кэшированные токены не влияют на ваши лимиты (rate limits): токены, которые были кэшированы, не учитываются при расчете лимитов в API.

Некоторые наши клиенты проделали отличную работу по внедрению Prompt Caching. Если посмотреть на такие сервисы, как Perplexity, Cursor, Replit, то все эти клиенты потратили значительные инженерные усилия, чтобы поднять свой коэффициент попадания в кэш (cache hit rate) на очень высокий уровень. На самом деле, если бы у этих клиентов не было такого высокого cache hit rate, мы бы даже не смогли обслуживать их рабочие нагрузки, так как без Prompt Caching просто не хватает вычислительных мощностей. Поэтому данная технология очень важна.

Существует возможность достичь высокой частоты попаданий в кэш (cache hit rate) с гораздо меньшими усилиями. Для этого существует два основных метода. Первый способ заключается в использовании консоли разработчика, или облачной консоли (cloud console). Здесь доступна новая информационная панель (dashboard), которая предоставляет отчёты по вашему cache hit rate. Например, агент, который мы сейчас рассматриваем, имеет показатель всего 56%, что говорит о наличии пространства для улучшения. Я приглашаю вас, как только вы окажетесь дома, зайти и проверить, какой cache hit rate установлен у вашего агента. Если этот показатель не достигает 80%, я настоятельно рекомендую сделать оптимизацию этого параметра первым делом в списке задач, так как многие долгоживущие агенты вполне способны поддерживать высокий уровень попаданий в кэш.

Вторым важным советом для повышения cache hit rate является использование навыка Cloud API. Это новый инструмент, который по умолчанию устанавливается вместе с Cloud Code. Если у вас есть доступ к Cloud Code или к любому другому средству разработки, вы можете использовать этот навык, так как он отлично понимает принципы кэширования промптов (prompt caching). Если вы просто откроете свой проект в Cloud Code и дадите команду «улучши мой cache hit rate», система начнет работу по модификации промпта: она добавит заголовки управления кэшем (cache control headers) и выполнит другие необходимые действия, чтобы поднять ваш cache hit rate до требуемого высокого уровня.

In order to demonstrate what this looks like, I would like to invite Rod out. Rod has worked on a demo for us. Rod is actually one of the lead engineers on the API, so if you have built something and you are using the API, you are probably running his code. Let’s switch over to the demo and see what Rod has for us. What we are building is a dashboard for a CEO. A CEO has a set of objectives, and what we have done is written an agent that goes out to track them. However, when looking at the screen, I have to ask: is this the right user interface? We are coding with Claude, and you bring up this 90s-looking SharePoint user interface. I do not know; I think we can do better.

Rod is going to make a superhero theme demo, as I think that is much more appropriate. Again, we are using Claude Code, modifying the source of our demo locally, and then we are going to flip back over. It looks much better now. We are no longer the CEO of some boring corporation; this is now the dashboard for the CEO of HeroCorp.

HeroCorp utilizes a business model where it rents out superheroes to defend your city, defeat villains, and show up at kids' birthday parties, or whatever is necessary. Despite this unique business model, we still have a set of objectives, and we are reporting on the status of those objectives by scouring all the data that this corporation has. We have a bunch of tools that bring in that data. In fact, just to get a sense for what this site looks like, Rod put in a nice developer console. Let's see the developer view of this site. This is our developer view. You can see we have a couple of tools there, such as the Outlook search, which we will get into later. You can also see how Rod is invested in prompt caching.

После того как Род внедряет prompt caching в Cloud Code, показатели системы меняются. При перезагрузке сайта мы видим, что cache hit rate (коэффициент попадания в кэш) начинает расти. Изначально система выполнила несколько операций записи в кэш (cache writes), а затем перешла к успешным попаданиям (cache hits). В результате этого изменения удалось достичь 58% показателей cache hit rate. Лектор предлагает наблюдать за этой метрикой на протяжении всей демонстрации, отмечая, что по мере добавления новой функциональности коэффициент попадания в кэш будет увеличиваться еще сильнее.

Демонстрация выглядит успешно для первой поставленной цели. Однако при попытке прокрутить страницу вниз, чтобы показать, что всего существует четыре цели (objectives), выясняется проблема. Первая цель посвящена удержанию талантливых сотрудников (retaining top talent), но при попытке загрузить вторую цель обнаруживается, что система исчерпала доступный объем контекста (we've run out of context), так и не дойдя до второго пункта.

Индикатор окна контекста показывает, что пользователю был выделен контекст размером в один миллион токенов. Несмотря на такой внушительный объем, удалось проработать только одну из четырех целей. Лектор делает вывод, что система может работать эффективнее, и для решения проблемы ограниченности контекста требуется, как он выражается, «контекстный инжиниринг» (context engineering), после чего предлагается вернуться к слайдам.

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

Для управления контекстом в разрабатываемых агентах существуют три ключевых инструмента:

Во-первых, tool search tool (инструмент поиска инструментов), который позволяет исключить множество определений инструментов из контекста.

Во-вторых, programmatic tool calling (программный вызов инструментов), помогающий убрать из контекста объемы данных, получаемые в результате работы этих инструментов.

В-третьих, compaction (сжатие данных).

Ключевая проблема, которую решает Tool Search Tool (Инструмент поиска инструментов), заключается в масштабируемости управления инструментами. Многие агенты требуют использования десяти, двадцати или даже ста инструментов для выполнения своей работы. Разработчики стремятся к тому, чтобы агенты были общего назначения (general purpose) и продуктивны. Поскольку агенты должны рационально декомпозировать задачи с помощью различных инструментов, наличие более ста таких инструментов вполне оправдано. Однако проблема возникает при попытке поместить все эти сто с лишним инструментов непосредственно в контекст.

Если загрузить сотню инструментов в контекст, они займут большую его часть только своими определениями, оставляя крайне мало места для фактической работы агента. Это нерационально, так как в большинстве траекторий или запусков агент использует лишь около 10% от всего набора доступных инструментов. Тем не менее вы всё равно «платите» за загрузку всех этих инструментов — как в денежном эквиваленте, так и в плане задержек (latency).

Tool Search Tool предлагает иное решение. Вместо загрузки всего массива, в контекст добавляется только один инструмент — сам Tool Search Tool. Когда модель решает, что ей нужен какой-либо инструмент, она сначала обращается к Tool Search Tool с вопросом: «Есть ли у тебя инструмент для этой задачи?». После этого Tool Search Tool осуществляет поиск по своему инвентарю инструментов, выбирает наиболее подходящий для конкретного запроса и загружает в контекст только его.

В результате вы получаете значительно больше «агентного пространства» (agentic space). Контекст используется гораздо эффективнее, поскольку загружаются исключительно те инструменты, которые необходимы для выполнения конкретного запуска. Это позволяет иметь в распоряжении большое количество доступных инструментов, используя при этом только те, что требуются в моменте.

Клиенты, например, компания Lovable, уже ощутили преимущества этого подхода. Только за счет данного изменения они сократили потребление токенов на 10%, получив мгновенную экономию. Но что ещё важнее для Lovable, это привело к улучшению производительности и качества ответов модели. Когда модель получает слишком большой объем данных в контекст, её суждения иногда становятся менее точными. Таким образом, за счет сокращения объема информации, поступающей в контекст, сама модель стала работать лучше.

Основная цель программного вызова инструментов (programmatic tool calling) заключается в том, чтобы убрать промежуточные результаты работы инструментов из контекста модели. При проектировании инструментов разработчики часто стремятся к тому, чтобы они возвращали как можно больше данных. Это логично, так как хочется, чтобы у модели был доступ к любому контексту, который может ей понадобиться. Однако возникают ситуации, когда такой подход становится неэффективным.

Представьте ситуацию с инструментом для работы с электронной почтой, который мы рассматривали ранее: если он возвращает 100 писем, это значительно перегружает контекстное окно, хотя на самом деле вам могло потребоваться только заголовок одного конкретного письма. Аналогичная проблема возникает при работе с веб-страницами: вы можете получить всю HTML-страницу целиком, когда для решения задачи требовался лишь маленький div-тег из неё. Все эти лишние данные загружаются в контекст, занимая место.

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

Таким образом, в режиме реального времени модель может написать код, который извлекает только необходимые фрагменты — скажем, 2% или 5% от общего объема данных — и помещает в контекстное окно исключительно тот результат, который действительно нужен. Для инструментов, возвращающих огромные объемы данных, это дает значительное преимущество.

Клиенты, например, компания Cora, ощутили серьезную пользу от применения этого метода. Агенты Cora работают с большими объемами HTML-кода: раньше они загружали полные страницы, хотя им требовалась лишь небольшая их часть. Переход к модели программного вызова инструментов позволил их агентам работать значительно эффективнее.

Даже при качественной работе с инструментами поиска и programmatic tool calling, вы всё равно можете столкнуться с тем, что контекст переполняется, так как он не бесконечен. Если у вас есть агент, который ставит перед собой амбициозные задачи и должен работать часами или даже днями, вам стоит воспользоваться функцией compaction (компактизация).

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

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

Для демонстрации методов оптимизации контекста в приложении HeroCorp мы переходим от теоретического обсуждения к практике, чтобы увидеть, как compaction (сжатие данных) и другие стратегии работают в реальном времени.

Напомним предыдущий контекст: приложение HeroCorp потребляло миллион токенов контекста всего лишь для одной из своих четырех задач. Теперь наша цель — попробовать нагрузить систему иначе, используя оптимизированные методы. Для этого мы заходим в Cloud Code и активируем все стратегии одновременно: tool search tool (инструмент поиска функций), programmatic tool calling (программный вызов функций) и compaction.

После перезагрузки приложения и активации всех стратегий видно, что процессов стало гораздо больше. Объем контекстного окна динамически изменяется, а в потоке активности (activity stream) мы видим множество вызовов инструментов, так как система заполняет каждую из поставленных задач. Благодаря небольшому объему дополнительного инженерного проектирования, мы получаем значительно больше ценности, достигая всех целей, но при этом с гораздо меньшим итоговым объемом контекста.

Разберем каждый метод по порядку.

Tool Search Tool (Инструмент поиска функций)

Первым сработал tool search tool. В самом начале модель решила вызвать этот инструмент, выполнив поиск по запросу «hero retention metrics». Инструмент поиска ответил, что располагает соответствующей функцией, и предоставил её схему, которая называется hero_retention_metrics. Модель сделала вызов этого инструмента и получила результат. Это демонстрирует эффективность метода: нам не пришлось загружать все сто с лишним инструментов заранее, мы могли загружать их по одному, по мере необходимости.

Programmatic Tool Calling (Программный вызов функций)

Этот инструмент интересен при работе с такими вещами, как Gong Customer Digest (сервис для транскрибирования встреч). Gong возвращает полную транскрипцию встречи, которая сама по себе полезна, но в данном случае нам требовалась только информация о тональности (sentiment) встречи.

Вместо того чтобы загружать в контекст всю транскрипцию целиком, система использовала Code Executor для написания кода. Этот код выполняет вызовы всех необходимых методов и инструментов, извлекает результат в формате JSON и выводит только ту малую часть JSON, которая была действительно нужна для выполнения текущей задачи. Это позволяет существенно экономить контекст.

Compaction (Сжатие контекста)

Наконец, мы видим процесс compaction. В данном примере система сбросила 9 тысяч токенов, уменьшив общий объем до 10 тысяч. Процесс сжатия создает краткое резюме (summary) для модели или агента, который будет обрабатывать данные дальше. В этом резюме четко изложено: в чем заключается задача (objective), какие данные мы уже собрали, и что нужно сделать дальше. Это очень лаконичное и сжатое резюме.

Если снова запустить процесс и наблюдать за линией контекстного окна, можно заметить, как оно постепенно растет по мере использования инженерии контекста. Мы установили порог в 400 тысяч токенов: как только объем приближается к этой отметке, срабатывает сжатие, после чего объем контекста резко снижается и процесс накопления данных начинается заново.

To optimize model performance, we use the Advisor strategy. The insight behind this approach will be familiar to anyone who has worked with a development team: you can make a junior engineer significantly more productive simply by providing them access to a senior engineer. If you allow a senior engineer to review code and enable the junior engineer to ask a few questions throughout the day, the junior engineer improves, and it costs the senior engineer very little time.

This principle applies to models as well. You can take a small, inexpensive model and make it significantly better by giving it a tool that allows it to communicate with a bigger, more capable model. For instance, if you have a model like Haiku or Sonnet, you can make those models much smarter by providing them with an Advisor, such as Opus or the newly launched Fable.

Regarding the cost, it has been noted that Fable costs twice as much as Opus. The Advisor strategy is an effective way to access the reasoning capabilities offered by a model like Fable for only a fraction of the cost. The reasoning is that models like Haiku and Sonnet are highly proficient at writing code and performing tool calling; their relative limitation is that they are not as capable at deep, insightful reasoning. It is therefore logical to let Haiku and Sonnet do what they are good at for less money, and only utilize models like Opus and Fable where that differentiated, high-level reasoning is truly necessary. We see customers like Bolt implementing this approach.

In the demonstration, the current setup is in the debug view, utilizing Opus 4.8. When activating Advisor mode, one could theoretically switch the primary model to Sonnet to decrease costs. However, in the context of a dashboard used by a CEO for business decision-making, where the cost of being wrong is significant, both cost-efficiency and accuracy are critical.

In this demo, Sonnet is used to perform tool calling. Throughout the process, Sonnet periodically calls the Advisor running Opus. In the specific example shown, Sonnet evaluated the "Metropolis deal" and marked it as "on track," indicated by a green check. However, when Sonnet called the Advisor running Opus, Opus disagreed with the decision Sonnet had made. Opus reviewed the transcripts—specifically, data buried in a Gong transcript—and caught a problem that Sonnet had missed. The Mayor of Metropolis had stated they specifically wanted "Cryothane" to attend the opening, a request that had been missed by the account team. Consequently, the deal was actually at risk. Because of the Opus Advisor, the status was correctly identified as red.

This process demonstrates that we can save money while simultaneously keeping a high level of superior reasoning. By clicking on the flagged item, the CEO was able to reschedule "Cryothane," ensuring the deal could be closed. Rod’s demonstration shows that with the Advisor strategy, we can use more inexpensive models for general tasks, and only use more expensive models where they are needed.

This strategy relates to three different techniques: context management, context engineering, and prompt caching.

Для завершения обзора мы подвели итог основным рассмотренным возможностям. Мы обсудили Prompt Caching, который обязательно стоит использовать, если вы создаете агента — он позволяет существенно оптимизировать работу. Также мы затронули инструменты, такие как search tool, которые помогают предотвратить переполнение контекста, programmatic tool calling для управления результатами вызовов инструментов и compaction. Наконец, мы обсудили Advisor, использование которого позволяет применять более дешевые модели при сохранении того же уровня рассуждения (reasoning), что и у более мощных аналогов.

Облачная платформа развивается очень быстро, и следить за новыми функциями — отличный способ оставаться в курсе актуальных возможностей. Количество нововведений, запущенных в 2026 году, очень велико.

Мне очень нравится Workload Identity Federation, или WIF. Основная задача WIF — исключить необходимость использования API key. Я знаю, что многие клиенты по ошибке добавляют API-ключи в исходный код или оставляют их в открытом доступе, что создает серьезный риск утечки: если кто-то завладеет вашим API-ключом, он сможет отправлять запросы от вашего имени. WIF полностью устраняет эту проблему.

Второе важное обновление, которое мы запустили сегодня — это модель Fable. Это модель класса Mythos, и поскольку она обладает такими характеристиками, нам пришлось внедрить для нее дополнительные классификаторы безопасности. Из-за этого уровень блокировок (block rate) у данной модели немного выше, чем у других. Чтобы решить эту проблему, мы внедрили функцию fallback. Теперь в messages API можно указать список других моделей. Это значит, что если Fable не может обработать запрос по какой-либо причине (например, из-за срабатывания классификатора), запрос будет автоматически перенаправлен на резервную модель. Это обеспечивает более надежную и устойчивую работу.

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