Оригинальный заголовок: Что учить, строить и пропускать в AI-агентах (2026)
Автор оригинала: Rohit
Перевод: Peggy, BlockBeats

Редакторский комментарий: Область AI-агентов входит в этап взрыва инструментов и недостатка консенсуса.

Каждую неделю появляются новые фреймворки, новые модели, новые benchmark и новые продукты с «10-кратной эффективностью», но действительно важные вопросы уже не в том, «как успевать за всеми изменениями», а в том, «какие изменения действительно стоят вложений».

Автор считает, что в условиях постоянного переписывания технологического стека, долгосрочный эффект не дают гонки за новейшими фреймворками, а более фундаментальные навыки: инженерия контекста, дизайн инструментов, системы оценки, модель-оркестратор-субагент, sandbox и мышление в стиле harness. Эти навыки не быстро устаревают с обновлением моделей, а скорее станут основой для построения надежных AI-агентов.

В статье также отмечается, что AI-агенты меняют понимание «квалификации». Раньше диплом, должность и стаж были пропуском в индустрию; но в области, где даже гиганты публично экспериментируют и ошибаются, резюме уже не является единственным подтверждением. Важнее то, что ты сделал и что поставил на поток.

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

Ниже — оригинальный текст:

Каждый день появляется новый фреймворк, новый benchmark, новый продукт с «10-кратной эффективностью». Вопрос уже не в том, «как не отставать», а в том, что из этого действительно сигнал, а что — шум, маскирующийся под срочность.

Каждая дорожная карта через месяц устаревает. Тот фреймворк, который вы освоили в прошлом квартале, уже стал устаревшим. Benchmark, который вы оптимизировали, был пробит и быстро заменен новым. Раньше мы шли по традиционной траектории: один технологический стек — одна тема и уровень; один опыт работы — стаж и должность; медленно поднимаясь по лестнице. Но AI переписал эту картину. Сегодня, если правильно сформулировать подсказки и иметь хороший вкус, один человек может выполнить работу, на которую у инженера с двухлетним опытом уходит один спринт.

Профессиональные навыки по-прежнему важны. Ничего не заменит личного опыта: видеть, как система падает, исправлять утечки памяти в два часа ночи, или принимать трудные решения и быть правым. Такие суждения растут в стоимости и эффекте. Но то, что уже не растет так быстро — это уровень знакомства с «поверхностным API» новых фреймворков. Через полгода оно снова изменится. Через два года победителями станут те, кто заранее выбрал устойчивые базовые навыки и умеет пропускать шум.

За последние два года я создавал продукты в этой области, получал предложения с зарплатой выше 250 тысяч долларов в год, сейчас работаю в скрытой компании, отвечая за технологии. Если кто спросит меня: «Что сейчас важно учить?» — я отправлю ему именно это.

Это не дорожная карта. В области AI-агентов еще нет четкой цели. Лаборатории крупных компаний тоже экспериментируют публично, возвращая проблему к миллионам пользователей, делая обзоры и исправляя ошибки онлайн. Если команда Claude Code выпускает версию, вызывающую 47% падение производительности, и только после этого пользователи замечают проблему, то идея «под ним есть стабильная карта» — фикция. Все еще ищут. Стартапы имеют шанс, потому что гиганты тоже не знают ответов. Люди, не умеющие писать код, работают с агентами, доставляя по пятницам то, что еще два дня назад казалось невозможным для магистров машинного обучения.

Самое интересное в этот момент — изменение понимания «квалификации». Традиционный путь — это диплом, начальная позиция, старшие роли, опыт и медленное продвижение. Это оправдано, когда в базовых областях не происходит резких изменений. Но сейчас, когда земля под ногами у всех движется так же быстро, разрыв между 22-летним, выпустившим демонстрацию агента, и 35-летним инженером — не только в опыте владения стеком. Они работают на одной и той же чистой доске. Для них важнее желание постоянно поставлять и базовые навыки, которые не устареют за квартал.

Это — основная идея всей статьи. Далее я предложу способ оценки: какие базовые навыки стоит развивать, а какие можно пропускать. То, что подходит — берите, что не подходит — отпускайте.

Настоящий фильтр эффективности

Невозможно следить за всеми новинками каждую неделю, и не нужно. Вам нужен не поток информации, а фильтр.

За последние 18 месяцев пять вопросов оставались актуальными. Перед тем, как включить что-то новое в стек, задайте себе эти пять вопросов.

Останется ли это важным через два года?
Если это просто оболочка передового модели, CLI-параметр или «версия Devin», ответ почти всегда — нет. Если это базовая операция, например, протокол, режим памяти или sandbox, — скорее да. Оболочки быстро устаревают, а базовые операции — могут жить годами.

Есть ли у вас уважаемый человек, который уже создал реальный продукт на базе этого и честно делился опытом?
Мнения в маркетинговых статьях не считаются, важны обзоры и разборы. Блог «мы протестировали X в продакшене, и тут возникла проблема» ценнее, чем десять объявлений. Истинные сигналы приходят от тех, кто потратил на это выходные.

Использование этого означает, что вы должны отказаться от существующих систем трассировки, повторных попыток, конфигураций, аутентификации?
Если да, то это — попытка сделать фреймворк платформой. А фреймворки-платформы имеют около 90% вероятности провала. Хорошие базовые операции должны легко интегрироваться в существующую систему, не требуя полной миграции.

Что будет, если пропустить это на шесть месяцев?
Для большинства релизов — ничего. Через шесть месяцев вы узнаете больше, и версия станет лучше. Этот вопрос помогает пропускать 90% релизов без страха. Многие отказываются, потому что боятся отстать. Но это — иллюзия.

Можете ли вы измерить, действительно ли это улучшает вашего агента?
Если нет — вы просто предполагаете. Без системы оценки команда рискует запустить проблему на продакшн. С eval команда может дать объективный ответ: лучше GPT-5.5 или Opus 4.7 в конкретной задаче.

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

За этим стоят более сложные навыки, чем любой тест. Это — способность «не гнаться за модой». Фреймворки, которые сейчас популярны на Hacker News, через две недели потеряют актуальность, и их поддержка исчезнет. Те, кто не участвует, — сэкономят время и сосредоточатся на вещах, которые выдержат «становление скучными». Удерживаться, наблюдать и говорить «через шесть месяцев я узнаю» — это настоящая профессиональная способность. Все читают объявления, но мало кто умеет не реагировать на них.

Что учить

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

Инженерия контекста

За последние два года самое важное изменение — это переименование «Prompt Engineering» в «Context Engineering». Это не просто смена названия, а реальное изменение подхода.

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

Важно понять: контекст — это состояние. Каждый лишний токен снижает качество рассуждения. Загрязнение контекста — настоящая производственная проблема. На восьмом шаге задачи, исходная цель может быть «захоронена» выводами инструментов. Команды, способные обеспечить надежного агента, активно резюмируют, сжимают и обрезают контекст. Они управляют версиями описаний инструментов, кешируют статические части и исключают меняющиеся. Они рассматривают окно контекста как опытный инженер — как память.

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

Если прочитаете только одну статью — рекомендуем «Effective Context Engineering for AI Agents» от Anthropic. А также их обзор системы мультиагентов — там цифрами показано, насколько важна изоляция контекста при масштабировании системы.

Дизайн инструментов

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

Пять-десять хорошо названных инструментов лучше двадцати посредственных. Названия должны быть как глаголы в английском. Описания — четко указывать, когда использовать, а когда — нет. Ошибки должны быть обратной связью для модели: «Превышен лимит 500 токенов, сначала подытожьте». Это гораздо эффективнее, чем «Error: 400 Bad Request». Исследовательская команда Anthropic сообщила, что просто переписав сообщения об ошибках, они снизили цикл повторных попыток на 40%.

«Writing tools for agents» от Anthropic — хороший старт. После прочтения добавьте наблюдения по своим инструментам, посмотрите, как они вызываются в реальности. Надежность агента почти всегда улучшается именно на стороне инструментов. Многие меняют подсказки, игнорируя ключевое — работу инструментов.

Модель-оркестратор и субагенты

В 2024–2025 годах дискуссии о мультиагентах пришли к единому решению — стандартной схеме. Наивные системы с несколькими агентами, которые параллельно пишут в общий статус, — обречены на провал, потому что ошибки накапливаются. Одноагентный цикл — это гораздо больше, чем кажется. Единственная рабочая модель в продакшене — это один оркестратор, делегирующий узкоспециализированным субагентам, и объединяющий их результаты.

Исследовательская система Anthropic, Claude Code и большинство современных фреймворков используют именно такую схему. У субагентов — узкий фокус, они не могут менять общий статус. Запись — за оркестратором.

Статьи «Don’t Build Multi-Agents» от Cognition и «How we built our multi-agent research system» от Anthropic кажутся противоположными, но на самом деле говорят об одном и том же — разными словами. Обе заслуживают внимания.

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

Evals и золотые датасеты

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

Эффективная практика — собирать трассировки из продакшена, отмечать неудачи и включать их в регресс. При каждом новом сбое — добавлять его. Использовать LLM как судью для субъективных случаев, точное сравнение или автоматические проверки — для остальных. Перед любым обновлением — запускать тесты. Исследовательский блог Spotify сообщает, что их система оценки предотвращает около 25% плохих результатов до попадания в продакшн. Без нее — каждое четвертое плохое решение достигает пользователя.

Главная идея — eval — это как юнит-тест: он гарантирует, что агент не отклонился от своей роли, несмотря на постоянные изменения. Новые версии моделей, крупные обновления фреймворков, устаревшие эндпоинты — eval помогает отслеживать стабильность. Без eval — система, где правильность зависит от случайных факторов.

Фреймворки evals, такие как Braintrust, Langfuse, LangSmith — хороши, но не являются узким местом. Главное — иметь размеченные данные. Начинайте сразу, как только есть возможность. 50 образцов — за полдня. Нет оправданий.

Используйте файловую систему как состояние и цикл «Думай-Действуй-Наблюдай»

Для любого агента, выполняющего многошаговые задачи, важна архитектура: размышление, действия, наблюдение, повтор. Файловая система или структурированное хранилище — источник фактов. Каждое действие фиксируется и может быть воспроизведено. Claude Code, Cursor, Devin, Aider, OpenHands, goose — все используют именно такой подход.

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

Глубже — в любой продакшн-агент, зарабатывающий деньги, работа harness важнее модели. Модель выбирает действие, harness проверяет, запускает в песочнице, фиксирует результат, решает, что возвращать, когда останавливать, когда делать чекпоинт, когда создавать субагента. Замена модели — заменяет и harness, и весь продукт. Но плохой harness — даже лучший модельный агент будет работать хаотично и забывать, что делал.

Если ваш продукт сложнее однократного вызова инструмента — сосредоточьтесь на harness. Модель — лишь часть системы.

Понимание MCP

Не просто учитесь вызывать MCP-сервер. Учитесь его модели. Он обеспечивает четкое разделение возможностей агента, инструментов и ресурсов, а также расширяемую аутентификацию и передачу данных. Освоив это, вы увидите, что все остальные «агентские интеграционные фреймворки» — это упрощенные версии MCP, и тратить время на их оценку не нужно.

Linux Foundation сейчас управляет MCP. Все крупные поставщики моделей его поддерживают. Его можно сравнить с «USB-C для AI» — и это уже не ирония.

Sandbox — базовая операция

Каждый продакшн-агент работает в песочнице. Каждый браузерный агент сталкивался с косвенным prompt injection. Каждый мультиарендный агент — с ошибками в области прав доступа. Не стоит ждать, пока заказчик потребует — делайте sandbox как базовую инфраструктуру.

Учите основы: изоляцию процессов, контроль выхода в сеть, управление ключами, границы аутентификации между агентом и инструментами. Те, кто добавляют sandbox только после требований безопасности, рискуют потерять сделки. Те, кто внедряют с первого дня — проходят в корпоративных закупках легко.

Что использовать для построения

Вот конкретные рекомендации на апрель 2026. Они могут меняться, но не слишком быстро. В этой области лучше выбирать «скучные, но надежные» решения.

Оркестровка

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

Если используете TypeScript — Mastra. Это наиболее понятное решение в экосистеме.

Если предпочитаете Pydantic и цените типовую безопасность — Pydantic AI. Вышел в конце 2025, есть перспективы.

Для провайдер-специфичных задач — компьютерное использование, голос, реальное взаимодействие — используйте SDK Claude или OpenAI в рамках LangGraph. Не пытайтесь делать их универсальными оркестраторами.

Протокол

MCP — это всё.

Интегрируйте инструменты через MCP-сервер. Внешние интеграции — тоже через него. Уже большинство поставщиков моделей поддерживают его. В 2026 году писать собственный plumbing — неэффективно.

Память

Выбирайте систему памяти по степени автономии агента, а не по популярности.

Mem0 — для чат-персонализации: предпочтения, легкая история. Zep — для продакшн-диалогов, где состояние меняется, нужно отслеживать объекты. Letta — для агентов, которым важна стабильность в течение дней или недель. Большинство команд этого не требуют, но те, кому нужно — знают, что это важно.

Ошибки — это: сначала добавьте память, когда есть проблема. Начинайте с контекста и векторной базы. Только когда ясно, какие сценарии не работают — добавляйте память.

Об observability и evals

Langfuse — open source по умолчанию. Можно хостить самостоятельно, лицензия MIT, покрывает трассировку, управление версиями подсказок и базовые evals. Если используете LangChain — интеграция с LangSmith. Braintrust — для научных экспериментов и сравнений. Traceloop / OpenLLMetry — для многоязычных систем с нейтральной телеметрией.

Нужно иметь и трассировку, и evals. Трассировка показывает, что агент делал. Eval — помогает понять, стал ли он лучше или хуже. Без них — нельзя запускать в продакшн. Лучше подготовить их сразу — это дешевле, чем исправлять ошибки потом.

Режим выполнения и sandbox

E2B — универсальный для выполнения кода в песочнице. Browserbase + Stagehand — для автоматизации браузеров. Anthropic Computer Use — для реальных системных задач. Modal — для краткосрочных задач.

Никогда не запускайте непесоченные скрипты. Агент, уязвимый к prompt injection, в продакшене — это катастрофа.

Модели

Гонка за benchmark — утомительна и часто бесполезна. По состоянию на апрель 2026:

• Claude Opus 4.7 и Sonnet 4.6 — для надежных вызовов инструментов, многошаговой согласованности и аккуратных ошибок. Для большинства задач — Sonnet лучше по соотношению цена/качество.

• GPT-5.4 и GPT-5.5 — для мощных CLI и терминальных рассуждений, если вы уже работаете на инфраструктуре OpenAI.

• Gemini 2.5 и 3 — для задач с длинным контекстом и мультимодальных сценариев.

• Когда важна цена — DeepSeek-V3.2 или Qwen 3.6, особенно при узкоспециализированных задачах.

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

Что пропускать

Часто советуют учить и использовать эти вещи, но на самом деле — можно пропускать. Стоимость пропуска — минимальна, а сэкономленное время — велико.

AutoGen и AG2 — не для продакшена.
Этот фреймворк от Microsoft уже перешел в сообщество, обновляется медленно, и его архитектура не подходит для реальных команд. Можно использовать для исследований, но не для продуктов.

CrewAI — не для новых продакшн-проектов.
Он популярен для демонстраций, но профессиональные инженеры уже уходят от него. Можно делать прототипы, но не связывайте себя надолго.

Microsoft Semantic Kernel — только если вы глубоко интегрированы в Microsoft и ваши заказчики ценят это.
Это не направление развития экосистемы.

DSPy — только если вы оптимизируете prompt-программы на большом масштабе.
Идея ценна, но аудитория узкая. Не стоит выбирать его как универсальный фреймворк.

Использование отдельного code-writing агента как архитектурный выбор.
Это интересное направление, но не — стандарт в продакшене. Вызовы безопасности и инструментарий — ваши проблемы, а конкуренты могут их не решать.

«Автономные агенты» — маркетинговый трюк.
AutoGPT и BabyAGI — устарели. Сейчас говорят о «agentic engineering»: с контролем, границами и оценкой. Продажа «не нужно ничего делать после запуска» — устаревшая идея 2023 года.

Магазины и маркетплейсы агентов

Обещания их появления с 2023 — не реализовались. Компании не покупают универсальных преднастроенных агентов. Они либо создают свои, либо покупают узкоспециализированные. Не стоит строить бизнес вокруг идеи app store.

Клиенты осторожно выбирают платформы «build any agent».
Например, Google Agentspace, AWS Bedrock, Microsoft Copilot Studio — могут пригодиться, но сейчас — хаос и медленная релизная политика. Обычно выбирают узкоспециализированный агент или делают свой. Salesforce Agentforce и ServiceNow Now Assist — исключения, потому что встроены в рабочие системы.

Не стоит гоняться за рейтингами SWE-bench и OSWorld.
Исследователи Berkeley в 2025 году отметили, что большинство публичных benchmark — легко «обойти» без решения реальных задач. Сейчас лучше ориентироваться на внутренние evals и реальные кейсы.

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

Новые продукты с агентами — не должны иметь ценовую модель per-seat.
Рынок движется к outcome- и usage-based моделям. Оплата за место — уменьшит прибыль и даст клиенту сигнал, что вы не уверены в результате.

Следующий фреймворк, который увидите на Hacker News — подождите шесть месяцев.
Если он останется актуальным — вы узнаете. Если нет — сэкономите время на миграцию.

Как действовать

Если вы не просто хотите «следить за агентами», а реально внедрять их — следуйте этому порядку. Он скучен, но эффективен.

Начинайте с конкретного результата. Не стройте «агентскую платформу» с нуля. Выберите измеримый бизнес-цель: снижение обращений в поддержку, подготовка юридического заключения, фильтрация лидов, подготовка отчета. Успех агента — в улучшении этого результата. Он — ваша цель оценки.

Эта цель — самая важная, потому что она ограничит все последующие решения. Есть конкретный результат — выбор фреймворка не философский вопрос, а быстрый путь к его доставке. Выбор модели — не спор о benchmark, а оценка через evals. Не нужны memory, subagents или кастомный harness — только при конкретных ошибках.

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

Перед запуском — настройте трассировку и evals. Подключите Langfuse или LangSmith. Сделайте небольшой золотой датасет — 50 образцов. Без измерений — невозможно улучшать. В будущем — это будет в 10 раз дороже.

Начинайте с одного цикла «Думай-Действуй-Наблюдай». Выберите LangGraph или Pydantic AI. Модель — Claude, Sonnet 4.6 или GPT-5. Дайте агенту 3–7 инструментов. Используйте файловую систему или базу данных для состояния. Запустите на небольшой группе пользователей, наблюдайте трассировки.

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

Когда достигнете уровня, позволяющего расширять — добавляйте subагентов. Когда окно контекста станет узким — внедряйте memory. Когда API станет недостаточным — используйте computer или browser. Не проектируйте заранее — пусть ошибки покажут, что нужно.

Выбирайте простую инфраструктуру: MCP для инструментов, E2B или Browserbase для sandbox, Postgres или существующие хранилища. Аутентификацию и мониторинг — по текущим системам. Не усложняйте инфраструктуру — дисциплина важнее.

С первого дня следите за метриками: стоимость действий, кеширование, повторные попытки, вызовы моделей. В начале — кажется дешевым, но без контроля — быстро станет дорого. Например, один запуск за 0,50$ — при масштабировании может стать 50 тысячами долларов в месяц. Не заметить — значит попасть на CFO.

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

Как понять, что что-то работает

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

Признаки шума: через 30 дней — только демо, без реальных кейсов; benchmark — слишком хорош, чтобы быть правдой; в презентации — «автономный», «агентская ОС», «build any agent» без ограничений; документация — предполагает отказ от существующих систем трассировки, авторизации; рост звезд — быстрый, а коммиты и релизы — нет; активность на GitHub — слабая по сравнению с ростом звезд; Twitter — активность высокая, а GitHub — нет.

Полезная привычка — по пятницам выделять 30 минут на обзор области. Читать три источника: блог Anthropic, заметки Simon Willison, Latent Space. Если есть разбор ошибок — добавить пару статей. Остальное — пропускайте. Главное — не пропустить важное.

Что дальше наблюдать

В ближайшие два квартала — не обязательно, что это точно выигрыш, а скорее — вопрос, «сигнал ли это».

Replit Agent 4 — модель параллельных fork-ов.
Это один из первых серьезных экспериментов с «несколькими агентами в параллели» без ошибок из-за общего состояния. Если он покажет масштабируемость — модель оркестратора и субагентов может измениться.

Готовность outcome-based pricing.
Sierra и Harvey уже подтвердили эффективность в узких нишах. Вопрос — сможет ли эта модель распространиться на другие области.

Навыки как слой инкапсуляции.
Рост количества файлов AGENTS.md и skills — знак появления новой формы инкапсуляции. Будет ли она стандартом — вопрос открытый.

Качество Claude Code в апреле 2026 и его разбор.
Лидирующий агент выпустил версию с 47% падением производительности, и это заметили пользователи и мониторинг. Это показывает, что даже у лидеров практика оценки в продакшене еще несовершенна. Если это подтолкнет индустрию к более серьезным онлайн-оценкам — хорошо.

Голосовые интерфейсы — стандарт поддержки клиентов.
К концу 2025 Sierra уже превзошла текстовые каналы. Если тренд сохранится — задержки, прерывания, вызовы инструментов — станут первоочередными задачами, и многие системы придется переделывать.

Открытые модели и возможности агентов — сокращение разрыва.
DeepSeek-V3.2 с нативной поддержкой thinking-into-tool-use, Qwen 3.6 и другие — перспективные направления. Стоимость и эффективность узкоспециализированных задач меняются. Закрытые модели — не навсегда.

Каждая из этих тем — ясный вопрос: «Через шесть месяцев я должен увидеть, чтобы поверить, что это важно». Это — тест. Следите за ответами, а не за объявлениями.

Контр-интуитивные ставки

Каждая неиспользуемая вами рамка — это возможность избежать миграции в будущем. Каждый пропущенный benchmark — это квартал фокусировки. Компании, которые сейчас выигрывают — Sierra, Harvey, Cursor — выбирают узкие цели, создают дисциплину и пропускают шум.

Традиционный путь — выбрать стек, годами его изучать, и подниматься по лестнице. Это работает, когда стек стабилен 10 лет. Но сейчас стек меняется каждый квартал. Побеждают те, кто не гонится за «знанием стеков», а за вкусом, базовыми операциями и скоростью доставки. Они строят маленькие продукты, учатся на практике. Их опыт — их квалификация.

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

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

Настоящий навык — не «агенты», а способность судить, что в этом быстро меняющемся мире даст эффект в долгосрочной перспективе. Engineering контекста, дизайн инструментов, модель-оркестратор-субагент, eval-процессы, мышление в стиле harness — все это растет в цене. А новые фреймворки, API и релизы — нет. Когда вы научитесь отличать важное от шума, новые релизы перестанут быть стрессом, а станут шумом, который можно игнорировать.

Вам не нужно учить все. Нужно — те навыки, что дают эффект в долгосрочной перспективе, и пропускать остальное. Выберите результат, настройте трассировку и evals перед запуском. Используйте LangGraph или аналогичные инструменты. MCP — как стандарт. Внедряйте sandbox. Начинайте с одного агента. Когда сложность растет — добавляйте subагентов, память, API. Пересматривайте модели раз в квартал, а не каждую неделю. По пятницам — три источника для чтения.

Это — ваш план. Остальное — вкус, скорость и терпение, чтобы не гоняться за пустым.

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

[ссылка на оригинал]

Кликните, чтобы узнать о вакансиях в BlockBeats

Присоединяйтесь к официальному сообществу BlockBeats:
Telegram подписка: https://t.me/theblockbeats
Telegram чат: https://t.me/BlockBeats_App
Twitter: https://twitter.com/BlockBeatsAsia