Год назад, в мае 2025, инженеры Anthropic вышли на Code w/ Claude с докладом «Prompting for Agents». Семь принципов промптинга, публичный workbench в браузере, пара примеров системных инструкций — этого было достаточно, чтобы собрать рабочего агента. Сейчас, в мае 2026, эта картина перестала работать. Через месяц, 15 июня, Anthropic выводит из эксплуатации модели claude-sonnet-4-0 и claude-opus-4-0 — те самые, на которых строился публичный workbench из того доклада.

За год вокруг агентов выросла отдельная дисциплина — context engineering. Anthropic зафиксировала переход в сентябре 2025: вопрос больше не «как сформулировать инструкцию», а «какую конфигурацию контекста положить в окно, чтобы получить нужное поведение». Появились Agent Skills как открытый стандарт, harness engineering для долгих задач, advisor strategy с инверсией оркестратор‑воркер.

Тело агента стало другим. И самый простой способ понять, насколько другим — открыть два опубликованных Anthropic промпта из их же research‑системы и пройтись по ним сверху вниз. research_lead_agent.md и research_subagent.md из репозитория anthropics/claude-cookbooks — это production‑код, на котором работает фича Claude Research. 22 КБ и 9 КБ. Семь основных секций в одном, шесть в другом. Каждая — про то, что должно быть в теле твоего агента в 2026 году, если ты хочешь, чтобы он работал предсказуемо.

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

Что такое context engineering

Внимание — конечный ресурс

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

С большими языковыми моделями история похожая. У них есть то, что Anthropic называет attention budget — буквально «бюджет внимания», расходуемый запас, который тратится на обработку каждого токена в контекстном окне. Чем больше токенов, тем тоньше «размазана» способность модели держать в фокусе важное. В сентябре 2025 в инженерном блоге появилось определение, на которое теперь все ссылаются:

Context engineering: стратегии для отбора и поддержания оптимального набора токенов в процессе вывода LLM.

То есть context engineering — это не «как написать системный промпт». Это про то, какую конфигурацию контекста ты собираешь в окне модели на каждом шаге генерации. Системный промпт — лишь одна из его частей.

Почему это работает именно так (математика)

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

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

Что это значит для агента

Если ты строишь агента — у тебя нет вопроса «вместится ли всё в окно». У тебя есть вопрос «что положить в окно, чтобы внимание не размазалось». Anthropic формулирует главный принцип так:

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

Минимальный достаточный набор. Не «всё что может пригодиться», а «всё, без чего агент точно не справится». Это и есть та смена дисциплины, про которую был разговор во введении. Prompt engineering был про слова в одной инструкции. Context engineering — про то, как из системного промпта, инструментов, описаний, истории сообщений, файлов и результатов работы инструментов собирается то, что модель видит в момент генерации каждого следующего токена.

Дальше — конкретно: как это выглядит на двух production‑промптах, которые Anthropic положила в открытый доступ.

Что мы открываем

Где это лежит

Anthropic держит в открытом репозитории anthropics/claude-cookbooks папку patterns/agents/prompts/. Внутри — три файла, на которых работает фича Claude Research: research_lead_agent.md (22.6 КБ, 155 строк), research_subagent.md (8.9 КБ, 48 строк) и citations_agent.md. Это не игрушка для туториала. Это production‑код.

Я разбираю первые два. Версия зафиксирована на коммите 46f21f95 — на случай, если Anthropic обновит файлы, ты сможешь открыть ровно ту же редакцию, которую читаешь здесь.

https://github.com/anthropics/claude-cookbooks/tree/46f21f95/patterns/agents/prompts

Про третий файл — citations_agent.md

Это специализированный агент, который запускается после lead‑а: берёт готовый отчёт и расставляет в нём ссылки на источники, собранные суб‑агентами. Главное правило в его инструкции — не менять содержание текста, только мапить утверждения на документы. Один агент = одна узкая задача.

Не разбираю его здесь, потому что фокус статьи — на теле одного агента, а citations_agent про архитектуру цепочки.

Что это за система

Claude Research — фича, в которой ты задаёшь сложный вопрос («сравни системы налогообложения скандинавских стран», «найди топ-50 fortune 500 CEO с местами рождения»), а Claude вместо одного длинного ответа разворачивает целую команду агентов. Один — ведущий, lead. Он не ищет информацию сам, его задача — спланировать процесс, разбить вопрос на куски, запустить параллельно несколько суб‑агентов, дождаться их отчётов, синтезировать финальный ответ.

Суб‑агенты — исполнители. У каждого свой узкий вопрос, свой контекст, свой потолок на 20 вызовов инструментов и 100 источников. После завершения каждый возвращает lead‑агенту сжатый отчёт на 1000–2000 токенов. Lead собирает из них итог.

Это паттерн orchestrator‑worker в чистом виде. По собственным данным Anthropic, такая архитектура даёт +90.2% к качеству на research‑задачах по сравнению с одним агентом — за счёт того, что каждый суб‑агент работает в чистом контекстном окне и не тратит attention budget на чужие куски задачи.

Почему именно эти промпты

Я выбрал их по четырём причинам.

Первая — это production. Они работают прямо сейчас в Claude Research, а не написаны под демо‑доклад. Видно следы реальной отладки: жёсткие потолки на количество суб‑агентов, явные запреты типа «никогда не создавай суб‑агента для написания финального отчёта», исправление известных ошибок («не используй этот инструмент, он сломан»).

Вторая — открытый код. Anthropic положила эти файлы в публичный репозиторий с лицензией. Я могу разбирать их по строчкам без обхода NDA или копирайта.

Третья — актуальность. Эти промпты собраны уже в новой парадигме context engineering. В них есть всё, чему Anthropic учит с сентября 2025: research budget, OODA loop, structured tool use, parallel calls, subagent compression. На них видно, как теоретические концепции из инженерного блога превращаются в реальные строчки в .md‑файле.

Четвёртая — нетривиальность. Это не «hello world», это многоагентная система с делегированием, синтезом и параллелизмом. Достаточно сложная, чтобы в ней проявились все 13 блоков, которые мы пройдём в следующем разделе.

Как читать дальше

Дальше я иду блок за блоком: что это, зачем оно нужно в твоём агенте, как Anthropic решила это у себя. Где‑то блоки общие для lead и subagent — буду показывать оба варианта. Где‑то они есть только в одном — буду оговаривать. По итогу получится чек‑лист и скелет SKILL.md, на которые ты сможешь опереться, когда будешь собирать своего агента.

Анатомия body агента

Мы идём по структуре обоих промптов. На каждый блок — что это, зачем оно нужно агенту, цитата из исходника и общая рекомендация: что это даёт, если ты добавишь это себе. Цитаты в основном перевожу — это раздел для понимания принципов, а не для копирования. Где английский остаётся — там либо термины самой Anthropic, либо имена инструментов, либо живая запись об отладке. Везде, где переведено, в репозитории anthropics/claude-cookbooks на коммите 46f21f95 лежит оригинал — можно сверить.

Фаза 1. Роль и контекст

Блок 1. Роль и цель агента

Самая первая строка в каждом промпте — кто этот агент и зачем он существует. Не «ты помощник, который помогает с задачами», а конкретная роль с конкретной целью.

В research_lead_agent.md:

Ты эксперт‑руководитель исследования, сфокусирован на стратегии исследования высокого уровня, планировании, эффективном делегировании суб‑агентам и написании итогового отчёта.

В research_subagent.md:

Ты суб‑агент исследования, работающий как часть команды.

Видишь разницу? Lead — «эксперт по стратегии», sub — «работаешь в команде». Это не украшение. От роли зависит, что агент считает своей зоной ответственности. Lead в этой системе не ищет информацию сам — он координирует. Sub не пишет итоговый отчёт — он сжимает результат для lead‑а. Если ты не зафиксируешь роль в первой строке, агент начнёт делать всё подряд.

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

Блок 2. Текущая дата

Дата инжектится в оба промпта через переменную шаблона:

Текущая дата: {{.CurrentDate}}.

Зачем это нужно. Модель обучена до какой‑то даты, после неё в её картине мира ничего не произошло. Когда задаёшь вопрос «найди свежие отчёты» — без даты в контексте «свежие» означает «свежие до cutoff». С датой — «свежие на сегодня». Это особенно критично в research‑агенте: оценка того, что считать current, привязана к дате в системном промпте.

Что это даёт у тебя: агент перестаёт галлюцинировать события и даты. Если задача длинная и идёт несколько часов — дата держит привязку к реальному времени. Для long‑running агентов это обязательный блок.

Фаза 2А. Как агент думает

Блок 3. Тип задачи

Только в lead. Перед тем как разворачивать команду, lead классифицирует запрос пользователя в один из трёх типов:

- Depth-first query- Breadth-first query- Straightforward query

Depth‑first — когда вопрос один, но требует разных углов («что вызывает ожирение» — генетика, среда, психология, экономика).

Breadth‑first — когда вопрос разбивается на параллельные потоки («сравни 3 облачных провайдера»).

Straightforward — когда хватит одного источника («какое сейчас население Токио»).

Зачем это нужно. От типа зависит стратегия делегирования. Для depth‑first ты запускаешь суб‑агентов с разными методологиями. Для breadth‑first — на разные подзадачи. Для straightforward — одного агента на всё.

Anthropic заставляет lead‑а явно проговаривать тип в своём reasoning перед тем, как идти дальше:

Явно проговори, к какому из этих типов относится запрос.

Что это даёт у тебя: классификация типов до выполнения. Если твой агент работает с разными типами задач — добавь типизацию первым шагом. Это не overhead, это экономия. Неправильная стратегия делегирования стоит дороже, чем 200 токенов на классификацию.

Блок 4. Research process

Пошаговая процедура. В lead — четыре фазы: Assessment and breakdown → Query type determination → Detailed research plan → Methodical plan execution. В sub — три: Planning → Tool selection → Research loop.

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

Думай о задаче пользователя тщательно и в деталях, чтобы понять её хорошо.

Зачем такая жёсткость. Без процесса агент сваливается в стратегию «искать сразу». Это плохо работает: первый поисковый запрос редко оптимален, и без плана агент его уточняет в процессе, вместо того чтобы потратить 30 секунд на план и потом сделать три точных запроса параллельно.

Что это даёт у тебя: скелет процесса в системном промпте, по которому агент идёт. Не один абзац «думай и делай», а пронумерованные фазы с описанием, что нужно сделать в каждой. Это самая большая разница между «промпт» и «production‑агент»: production знает, в какой фазе он сейчас находится.

Блок 5. OODA loop

OODA — observe, orient, decide, act. После каждого вызова инструмента агент должен остановиться и провести цикл:

(a) наблюдай, что уже собрано, (b) ориентируйся, какие инструменты и запросы лучше использовать, © принимай обоснованное решение, (d) действуй — вызови инструмент.

Это явная инструкция на рефлексию. Без неё агент склонен делать вызовы инструментов «по инерции»: получил снипет от web_search → сразу следующий поиск с похожим запросом → ещё один. Anthropic отдельно подчёркивает: одинаковые запросы — пустая трата ресурсов:

НИКОГДА не используй одни и те же запросы с одними и теми же инструментами повторно.

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

Фаза 2Б. Как агент работает

Блок 6. Research budget

Этот блок прямо влияет на стоимость работы агента в долларах. В sub‑агенте Anthropic явно прописывает потолок вызовов инструментов в зависимости от сложности. Если бы пришлось выбирать самый ценный блок — я бы остановился на этом.

Простые задачи: меньше 5 вызовов. Средние: 5 вызовов. Сложные: около 10. Очень сложные: до 15.

В lead — аналогично, но в терминах суб‑агентов: 1 субагент для простого / 2–3 для стандартного / 3–5 для среднего / 5–10 для сложного / максимум 20.

Зачем. Без потолка агент входит в бесконечный цикл уточнений.

Что это даёт у тебя: явный лимит в системном промпте. Не «работай эффективно», а «потолок такой‑то». Если задача сложнее — пусть агент явно скажет об этом в финальном отчёте, но не лезет за лимит. Это твой основной рычаг управления стоимостью.

Блок 7. Параллельные вызовы

В обоих промптах есть отдельный блок про параллелизм, и тон там жёсткий:

Для максимальной эффективности вызывай инструменты одновременно, а не последовательно.

В lead это даже сильнее: «ОБЯЗАТЕЛЬНО используй параллельные вызовы инструментов при создании суб‑агентов». Параллелизм — обязателен.

Зачем. Многоагентная система без параллелизма теряет своё главное преимущество. Если lead запускает суб‑агентов последовательно, ты получаешь обычный chain‑of‑thought ценой 15-кратной стоимости. Если параллельно — три суб‑агента работают одновременно, и общее время близко ко времени самого медленного из них.

Что это даёт у тебя: инструкция «вызывай инструменты параллельно, когда они независимы». Это не очевидно для модели самой по себе — она склонна к последовательной работе. Один абзац в промпте — заметная экономия времени и контекста на длинных задачах.

Фаза 3. Инструменты и качество данных

Блок 8. Tool selection

В sub‑агенте есть отдельная инструкция, какой инструмент когда использовать:

google_drive_search (internal docs),gmail tools (emails), gcal tools (schedules),repl (calculations), web_search, web_fetch.

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

Anthropic особо подчёркивает связку web_search и web_fetch:

ВСЕГДА используй web_fetch, чтобы получить полное содержимое страниц.

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

Что это даёт у тебя: в системном промпте — явный список инструментов с описаниями. Не «у тебя есть инструменты, используй их», а «вот этот для того, вот этот для этого, и в таких‑то случаях вызывай их в паре».

Блок 9. Internal tools priority

Отдельный блок про приоритет внутренних инструментов. Если у агента есть доступ к Google Drive, Gmail, Slack, Asana — Anthropic пишет максимально жёстко:

ВСЕГДА используй внутренние инструменты для задач, требующих личных или рабочих данных пользователя.

Зачем это выделено отдельно. Модель по умолчанию идёт в web_search — это её привычка из тренировки. Если у тебя в системе есть MCP‑сервер с реальными данными пользователя, без этого блока агент будет искать в интернете то, что лежит в первом приложенном документе.

Что это даёт у тебя: отдельная инструкция приоритета. Если у твоего агента есть доступ к чему‑то непубличному — корпоративные документы, личная база знаний, MCP к internal‑сервису — этот блок гарантирует, что агент идёт сначала туда.

Блок 10. Source quality

Один из самых длинных блоков в sub‑агенте. Anthropic учит модель распознавать признаки манипуляции и слабых источников:

Обращай внимание на признаки слабых источников: новостные агрегаторы вместо оригиналов, ложные авторитеты, анонимные источники, маркетинговый язык.

Дальше — флаги для содержания: глаголы в будущем времени, цитированные превосходные степени, financial projections, «может», «возможно», «по слухам».

Зачем. Модели легко скармливать аналитические заметки за факты. Без явной инструкции «сомневайся» агент берёт результат поиска на веру и тащит его в финальный отчёт. С этим блоком — оценивает источник до того, как использовать.

Anthropic честно пишет про сломанный встроенный инструмент:

DO NOT use the evaluate_source_quality tool ever- ignore this tool. It is broken.

Видишь? Это live‑документ. Они не переписывают промпт под красоту, они правят его под производство. Эту цитату оставляю на английском — её ценность не в смысле инструкции, а в том, что это «след правки» живого продукта. Перевод тут разрушает эффект.

Что это даёт у тебя: блок с критериями оценки источников и явными «красными флагами». Что вы считаете надёжным, что — нет. Особенно важно, если агент работает с открытым вебом, где половина результатов — пересказы пересказов.

Блок 11. Maximum tool call limit

Жёсткий потолок. В sub:

Не превышай лимит в 20 вызовов инструментов и около 100 источников. Это абсолютный верхний потолок.

В lead:

Никогда не создавай больше 20 суб‑агентов, если это не строго необходимо.

Это второй уровень защиты, после research budget. Research budget говорит «обычно столько‑то», maximum limit говорит «никогда больше столько‑то, иначе тебя терминируют». Anthropic явно угрожает агенту терминацией — и это работает, потому что в инструкции дальше:

Когда доходишь до 15 вызовов — прекращай собирать источники.

То есть агент знает: если он не остановится сам, его выключат принудительно. Это создаёт у модели мотивацию начинать сворачиваться заранее, а не упереться в стену.

Что это даёт у тебя: двухуровневая защита — мягкий бюджет и жёсткий потолок. Без жёсткого потолка агент может перебрать research budget, объясняя это «задача оказалась сложнее». С потолком — есть точка, где он обязан остановиться.

Фаза 4. Итог работы

Блок 12. Output formatting

Как агент завершает работу. У sub есть отдельный инструмент complete_task, у lead — он тоже есть, но с другой ролью. У sub complete_task сжимает результат для передачи lead‑у:

Как только задача выполнена, сразу вызови complete_task и передай подробный, сжатый, точный отчёт.

То есть результат суб‑агента — не просто «всё, что я нашёл», а сжатый отчёт. По данным Anthropic, типичный subagent сжимает 10K токенов работы в 1–2K возврата. Это структурное решение: суб‑агент работает с большим контекстом, lead получает только концентрат.

Lead использует complete_task для финального отчёта пользователю. И отдельно:

Не включай в отчёт никаких Markdown‑цитат — этим занимается отдельный агент.

В их системе цитаты пишет третий агент — citations_agent.md. Lead не лезет в чужую зону.

Что это даёт у тебя: явный формат завершения. Не «выдай результат», а «вызови такой‑то инструмент с такой‑то структурой». И — отдельная инструкция, чем агент НЕ занимается. Это важно: чёткие границы между ролями в многоагентной системе.

Блок 13. Synthesis responsibility

Самый важный запрет во всём lead‑промпте. Он повторяется несколько раз, и оба раза капсом:

НИКОГДА не создавай суб‑агента для написания финального отчёта — ТЫ пишешь итоговый отчёт по исследованию сам.

Зачем это так жёстко. Lead, у которого есть инструмент «запустить суб‑агента», склонен использовать его для всего, включая написание финального ответа. Это logical fallacy: суб‑агент работает в чистом контексте, без всех результатов исследования, поэтому он физически не может написать качественный финальный отчёт. Финал должен писать тот, у кого в контексте все материалы — то есть lead.

И ещё одна формулировка про роль координатора:

твоя главная роль — координировать, направлять и синтезировать, А НЕ проводить исследование самому.

Lead не исследует. Lead координирует и синтезирует. Это полная инверсия привычной для одноагентной системы логики «делай всё сам».

Что это даёт у тебя: явное распределение ролей. Если у тебя multi‑agent система — lead не должен лезть в исследование, sub не должен писать финальный ответ. Каждый агент знает свою зону и явно знает, чем он НЕ занимается. Это даёт системе предсказуемость и сильно облегчает отладку.

Чек‑лист: 13 блоков production‑агента

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

Роль и контекст

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

2. Текущая дата. {{.CurrentDate}} или эквивалент. Без неё агент галлюцинирует «свежие» события до cutoff модели.

Как агент думает

3. Тип задачи. Классификация запроса до выполнения. Для research‑агента — depth‑first / breadth‑first / straightforward. Стратегия зависит от типа.

4. Research process. Явные пронумерованные фазы процесса. Не «думай и делай», а «сначала разбери задачу, потом классифицируй, потом составь план, потом исполняй».

5. OODA loop. Инструкция остановиться и проверить себя после каждого вызова инструмента. Что узнал, что осталось, что делать дальше.

Как агент работает

6. Research budget. Мягкий бюджет вызовов инструментов в зависимости от сложности задачи. У Anthropic в sub: меньше 5 для простой, до 15 для сложной.

7. Параллельные вызовы. Явная инструкция вызывать инструменты параллельно, когда они независимы. Без этого модель работает последовательно.

Инструменты и качество данных

8. Tool selection. Явный список инструментов с описаниями «когда что использовать». Особенно связки вроде web_search + web_fetch.

9. Internal tools priority. Если есть MCP/private‑tools — приоритет им. Без этого блока агент по привычке идёт в web_search.

10. Source quality. Критерии оценки источников и красные флаги: спекуляции, news aggregators, marketing language, nameless sources.

11. Maximum tool call limit. Жёсткий потолок ресурсов. Второй уровень защиты после research budget — точка, где агент обязан остановиться.

Итог работы

12. Output formatting. Явный формат завершения и инструмент завершения. Что агент возвращает, и явно — чего он НЕ делает (например, не пишет цитаты, если для этого есть отдельный агент).

13. Synthesis responsibility. В multi‑agent системе — кто пишет финальный отчёт. У Anthropic это lead, никогда не суб‑агент. И lead не лезет в primary research.

Как пользоваться

Пройдись по списку и поставь галочку напротив пунктов, которые у тебя уже есть в системном промпте агента. Скорее всего, первые 1–2 блока будут — а вот к 6, 11, 13 у большинства самописных агентов вопросы. Это нормально. Это и есть та дельта между «промптом» и «production‑агентом».

Скелет агента: шаблон SKILL.md

Что такое Agent Skills (минимально, на 30 секунд)

В октябре 2025 Anthropic запустила Agent Skills — формат упаковки инструкций для агента в виде папки. Внутри — файл SKILL.md с YAML‑заголовком и Markdown‑телом, при необходимости — вспомогательные файлы и скрипты. С декабря 2025 это открытый стандарт agentskills.io. К марту 2026 его приняли 32 инструмента, включая Codex CLI, Cursor, Gemini CLI, JetBrains Junie.

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

Главный архитектурный приём — прогрессивное раскрытие. В стартовом контексте агента всегда лежит только метаданные (name + description) всех установленных skills. Когда задача матчится с описанием — агент подгружает SKILL.md целиком. Если в SKILL.md ссылка на дополнительный файл и он нужен — подгружает и его. Контекст не раздувается без необходимости.

Почему шаблон на английском

Короткая ремарка до того, как ты пойдёшь забирать шаблон из репозитория. Он на английском не случайно. Claude обучен на смешанном корпусе, но плотность инструкций по работе агента в нём максимальна на английском. Системные промпты на русском работают, но дают на длинных цепочках reasoning заметно худшие метрики — Anthropic в марте 2026 публиковала бенчмарк SWE‑bench Multilingual, где задачи с инструкциями на не‑английских языках теряли 3–7 процентных пунктов по сравнению с английским.

Все production‑промпты, которые Anthropic выкладывает в открытый доступ, на английском. Их собственные системные промпты для Claude.ai, Claude Code, Claude Research — на английском. Это не случайность, это оптимизация под максимальную метрику.

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

Что в шаблоне

Шаблон лежит на GitHub отдельным файлом — копируй, форкай, адаптируй под свою задачу.

Внутри — все 13 блоков из этой статьи, в правильном порядке, с YAML‑заголовком и комментариями к каждой секции:

• YAML frontmatter: name + description (главный триггер срабатывания)

• Роль агента и текущая дата

• <task_classification> — три типа задач

• <research_process> — пошаговая процедура с OODA loop

• <tool_selection> — какой инструмент когда использовать

• <internal_tools_priority> — приоритет внутренних инструментов

• <source_quality> — критерии и красные флаги

• <parallel_tool_calls> — где параллелизм обязателен

• <maximum_limits> — жёсткий потолок ресурсов

• <output_format> — формат финального ответа

Полная версия шаблона со всеми расшифровками, чек‑листом на 13 пунктов и готовым примером (research‑агент в полностью заполненном виде) — в репозитории:

github.com/inforobotvit/agent‑skeleton

Два места, где надо быть внимательным

Поле description в YAML‑заголовке. Это главный триггер срабатывания. Anthropic в собственной документации советует делать его активным — не описывать, а заставлять модель сработать. Не «как исследовать что‑то», а «используй этот skill, когда пользователь просит исследовать, изучить, сравнить или проверить факты — даже если он не сказал слово „исследование“.»

Подробное описание триггеров поднимает шанс, что агент подгрузит skill в нужный момент.

Поле <tool_selection>. В шаблоне стоит плейсхолдер [your internal tools here] — замени его на реальные инструменты, которые есть у твоего агента. Если есть MCP‑сервер с Notion — добавь его. Если есть свой API — впиши его. Чем точнее агент знает, что у него в руках, тем точнее работает.

Форкай репозиторий, ставь звёздочку, присылай pull request, если найдёшь, что улучшить.

Что дальше в серии

Это первая статья и ещё четыре планирую на тему context engineering.

Параллельно собираю веб‑инструмент Agent Skeleton Builder — анкета с вопросами по 13 блокам, на выходе готовый SKILL.md под твою задачу. Анонс будет в одной из ближайших статей.

Подписаться на серию и обсуждать вживую — в Telegram‑канале «Я и мой друг робот» (https://t.me/mewithrobot).

Заключение

Главное, что я вынес из разбора research_lead_agent.md и research_subagent.md — production‑агент это не «один длинный промпт». Это структурированная система из 13+ блоков, каждый из которых закрывает свой класс проблем: дрейф роли, неконтролируемые расходы, галлюцинации источников, потеря фокуса в долгой задаче, плохое распределение работы между ролями.

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