Anthropic Engineering: context engineering и мультиагентная исследовательская система — конспект

Две статьи Engineering at Anthropic о том, как агенту хватить «памяти». Первая — общая теория: что класть в окно контекста и как жить, когда задача больше окна. Вторая — разбор настоящей системы: функции Research в Claude, где ведущий агент запускает параллельных субагентов-исследователей. Статьи защищены авторским правом — здесь конспект своими словами; оригиналы: Effective context engineering for AI agents и How we built our multi-agent research system.

Коротко

• Контекст — конечный ресурс с убывающей отдачей. Чем больше токенов в окне, тем хуже модель их «помнит» (context rot); хороший контекст — наименьший набор токенов с высоким сигналом, дающий нужный результат.
• Context engineering шире промпт-инжиниринга: это постоянный отбор всего, что попадает в окно, — системного промпта, инструментов, примеров, истории, результатов инструментов, внешних данных — на каждом шаге агента.
• Три приёма для длинных задач: сжатие истории (compaction), структурированные заметки вне окна (agentic memory) и субагенты с чистым контекстом.
• Мультиагентность окупается на широких задачах. Ведущий Claude Opus 4 с субагентами Claude Sonnet 4 обошёл одиночного Opus 4 на 90,2 % во внутреннем эвале исследований — но тратит примерно в 15 раз больше токенов, чем обычный чат.
• Промпт — главный рычаг управления агентами, а эвал начинают с 20 примеров: эффекты в начале разработки огромны, большой набор не нужен, чтобы их увидеть.

Как читать вместе с курсом

• Когда. Обе статьи — к уроку 8.3.3 «Планирование, память и мультиагентность». Перед этим прочитайте конспект «Building effective agents»: паттерн «оркестратор и исполнители» оттуда — основа исследовательской системы. Части об эвалах и продакшене — к урокам 8.4.2 и 8.4.3.
• Что нужно знать. Почему внимание стоит $O(n^2)$ и как его растягивают на длинный контекст — уроки ступени 4 и 7 (позиционные кодировки, KV-кэш).
• Код. Промпты ведущего агента, субагента и агента цитирования опубликованы в Claude Cookbooks (patterns/agents/prompts/); стратегии управления контекстом сравнивает рецепт context_engineering_tools (см. путеводитель по кукбуку).

---

Часть 1. Effective context engineering for AI agents (сентябрь 2025)

От промпта к контексту

Несколько лет главным навыком прикладного ИИ считался промпт-инжиниринг — подбор слов и формулировок. Авторы (команда Applied AI) предлагают смотреть шире: какая конфигурация контекста вероятнее всего даст нужное поведение модели? Контекст — это все токены, которые модель видит при генерации; инженерная задача — извлечь из них максимум пользы с учётом ограничений модели. Надо «думать контекстом»: какое целостное состояние видит модель прямо сейчас и к какому поведению оно может привести.

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

Почему контекст конечен

Модели, как и люди, в какой-то момент теряют фокус. Тесты в духе «иголки в стоге сена» показали эффект, который называют context rot («гниение контекста»): чем больше токенов в окне, тем хуже модель точно вспоминает информацию из него. У одних моделей деградация мягче, у других резче, но есть она у всех. Авторы говорят о «бюджете внимания»: каждый новый токен немного его расходует.

Причины — в архитектуре:

• в трансформере каждый токен может обращать внимание на каждый, то есть для $n$ токенов есть $n^2$ попарных связей: при $n = 1000$ это миллион пар, при $n = 100\,000$ — уже десять миллиардов; удерживать их все модели всё труднее;
• в обучающих данных короткие последовательности встречаются чаще длинных, поэтому у модели меньше опыта и «специализированных параметров» для зависимостей через весь контекст;
• приёмы вроде интерполяции позиционных кодировок позволяют работать с последовательностями длиннее обучающих, но ценой некоторой потери понимания позиций.

Итог — не обрыв, а градиент: на длинном контексте модель остаётся сильной, но точность извлечения фактов и рассуждений на большом расстоянии снижается. (Курс AI Fluency, напротив, описывает переполнение окна как «обрыв» — см. путеводитель по Claude Academy; это разные вещи: обрыв — когда окно кончилось, градиент — пока оно не кончилось.)

Анатомия хорошего контекста

Главный принцип статьи: найти наименьший возможный набор токенов с высоким сигналом, который максимизирует вероятность нужного результата. По частям:

Системный промпт — на «правильной высоте». Авторы описывают два провала. Внизу — жёстко зашитая в промпт логика вида «если А, то сделай Б, иначе В…»: хрупко и тяжело поддерживать. Вверху — расплывчатые общие пожелания, которые не дают модели конкретных сигналов или предполагают общий контекст, которого у неё нет. Нужна середина («зона Златовласки»): достаточно конкретно, чтобы направлять поведение, и достаточно гибко, чтобы дать модели сильные эвристики. Промпт удобно делить на разделы (<background_information>, <instructions>, ## Tool guidance, ## Output description), хотя с ростом моделей точный формат значит всё меньше. «Минимальный» не значит «короткий»: агенту нужно всё, что определяет поведение. Практический совет: начните с минимального промпта на лучшей доступной модели, посмотрите, где она ошибается, и добавляйте инструкции и примеры под эти ошибки.

Пример для нашего курса. Слишком низко: «Если ученик спрашивает про градиент, сначала напиши формулу, потом пример с числами 2 и 3, потом…». Слишком высоко: «Будь хорошим репетитором». Правильная высота: «Ты репетитор для взрослого новичка. Объясняй через числовой пример до формулы; если ученик ошибся, задай наводящий вопрос, а не давай ответ».

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

Примеры (few-shot) по-прежнему очень полезны, но не превращайте промпт в перечень всех пограничных случаев. Лучше подобрать небольшой набор разнообразных «канонических» примеров: для модели примеры — это «картинки, которые стоят тысячи слов».

Поиск «точно в срок» и агентный поиск

Определение агента, к которому пришли авторы: LLM, которая автономно пользуется инструментами в цикле. По мере роста моделей можно давать агентам больше самостоятельности.

Классический подход — заранее, до генерации, найти релевантные фрагменты по эмбеддингам (RAG, урок 8.2). Агентный подход добавляет стратегию «точно в срок» (just in time): агент держит в контексте лёгкие ссылки — пути к файлам, сохранённые запросы, URL — и подгружает данные инструментами, когда они понадобятся. Так работает Claude Code при анализе больших баз: пишет точечные запросы, сохраняет результаты и смотрит на них командами вроде head и tail, никогда не загружая объект целиком. Так же поступают люди: мы не заучиваем всё подряд, а пользуемся папками, почтой, закладками.

У ссылок есть бонус — метаданные как сигнал. Файл test_utils.py в папке tests и файл с тем же именем в src/core_logic/ — явно разные вещи; иерархия папок, соглашения об именах, даты изменения подсказывают, что и когда важно. Это позволяет постепенное раскрытие (progressive disclosure): агент исследует среду слой за слоем, держит в рабочей памяти только нужное, а остальное — в заметках.

Минусы: исследование во время работы медленнее, чем готовый индекс, и требует продуманных инструментов и эвристик — иначе агент тратит контекст на тупики. Поэтому часто лучше гибрид: что-то загрузить заранее (Claude Code сразу кладёт в контекст файлы CLAUDE.md), остальное искать по ходу (glob, grep). Гибрид хорош для областей с относительно стабильным содержимым (юридическая, финансовая работа). Общий совет авторов не меняется: «делайте самое простое, что работает».

Длинные задачи: три приёма

Когда работа длится десятки минут или часы (миграция большой кодовой базы, обширное исследование) и токенов больше, чем помещается в окно, просто ждать моделей с бо́льшим окном бессмысленно: «загрязнение» контекста и проблема релевантности останутся при любом размере. Три приёма:

flowchart TB
subgraph C1["Сжатие (compaction)"]
  h["Длинная история"] --> s["Модель пишет сводку"] --> n["Новое окно: сводка + 5 последних файлов"]
end
subgraph C2["Заметки (agentic memory)"]
  a["Агент"] -->|"пишет"| f[("NOTES.md, список дел")]
  f -->|"читает после сброса"| a
end
subgraph C3["Субагенты"]
  L["Ведущий агент: план"] --> S1["Субагент: десятки тысяч токенов поиска"]
  S1 -->|"сводка 1–2 тыс. токенов"| L
end

Три приёма для задач длиннее окна контекста (наша схема)

1. Сжатие (compaction). Когда разговор подходит к пределу окна, модель пишет его сводку, и работа продолжается в новом окне со сводкой. В Claude Code модель сохраняет архитектурные решения, нерешённые ошибки и детали реализации, а выбрасывает лишние выводы инструментов; агент продолжает со сжатым контекстом и пятью последними открытыми файлами. Искусство — в выборе, что оставить: слишком агрессивное сжатие теряет детали, важность которых проявится позже. Совет: настраивать промпт сжатия на сложных трассах агента — сначала добиться максимальной полноты (ничего важного не потеряно), потом повышать точность (убирать лишнее). Самая безопасная и лёгкая форма сжатия — удалять старые результаты инструментов: зачем агенту снова видеть сырой вывод, который он уже обработал? (Это стало отдельной функцией платформы Claude.)

2. Структурированные заметки (agentic memory). Агент регулярно записывает заметки во внешнюю память и подгружает их позже — как Claude Code ведёт список дел или ваш агент — файл NOTES.md. Яркий пример — Claude, играющий в Pokémon: без всяких подсказок о структуре памяти он ведёт точные счётчики («последние 1234 шага тренирую покемонов на Route 1, Пикачу набрал 8 уровней из 10»), карты исследованных мест, список достижений и заметки о том, какие атаки работают против каких противников; после сброса контекста читает свои заметки и продолжает многочасовые сценарии. Вместе с Claude Sonnet 4.5 Anthropic выпустила инструмент памяти на основе файлов.

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

Как выбрать:

Приём	Когда подходит
Сжатие	задачи с долгим диалогом «вопрос — ответ», где важна непрерывность разговора
Заметки	итеративная разработка с понятными промежуточными вехами
Субагенты	сложные исследования и анализ, где окупается параллельное изучение

Вывод первой статьи

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

---

Часть 2. How we built our multi-agent research system (июнь 2025)

Зачем исследованию много агентов

Функция Research в Claude ищет по интернету, Google Workspace и подключённым интеграциям. Исследование — открытая задача: шаги заранее не предсказать, путь зависит от находок. Значит, нужен агент, а не линейный конвейер.

Ключевая мысль авторов: суть поиска — сжатие, выжимка главного из огромного корпуса. Субагенты сжимают параллельно, каждый в своём окне, изучая разные стороны вопроса, и передают ведущему только самое важное. Заодно они разделяют ответственность: свои инструменты, промпты и траектории — меньше зависимость от одного пути.

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

Числа из статьи:

• система «ведущий Claude Opus 4 + субагенты Claude Sonnet 4» обошла одиночного Claude Opus 4 на 90,2 % во внутреннем эвале исследований. Пример — найти всех членов советов директоров компаний IT-сектора S&P 500: мультиагентная система разбила задачу между субагентами и нашла ответ, одиночный агент не справился медленными последовательными поисками;
• в эвале BrowseComp (поиск труднонаходимой информации в вебе) три фактора объясняют 95 % разброса качества: объём потраченных токенов (сам по себе — 80 %), число вызовов инструментов и выбор модели. Мультиагентная система работает прежде всего потому, что позволяет «потратить достаточно токенов» на задачу. Причём переход на Claude Sonnet 4 дал больше, чем удвоение бюджета токенов на Claude Sonnet 3.7: новые модели — «множитель эффективности»;
• цена: агенты тратят примерно в 4 раза больше токенов, чем чат, мультиагентные системы — примерно в 15 раз. Значит, задача должна быть достаточно ценной.

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

Архитектура

flowchart TD
U["Запрос пользователя"] --> L["LeadResearcher: думает, сохраняет план в память"]
L --> M[("Память: план")]
L --> S1["Субагент 1: поиск + размышления между вызовами"]
L --> S2["Субагент 2"]
L --> S3["Субагент N"]
S1 --> L
S2 --> L
S3 --> L
L -->|"нужно ещё?"| L
L -->|"достаточно"| C["CitationAgent: расставляет ссылки на источники"]
C --> R["Отчёт с цитатами"]

Исследовательская система Anthropic: оркестратор и исполнители (по описанию в статье)

Схема — паттерн «оркестратор и исполнители». Ведущий агент (LeadResearcher) обдумывает подход и сохраняет план в память: если контекст превысит 200 000 токенов, он будет обрезан, а план терять нельзя. Затем он создаёт субагентов с конкретными исследовательскими задачами; каждый сам ищет в вебе, оценивает результаты, размышляя между вызовами инструментов, и возвращает находки. Ведущий сводит их и решает, нужно ли ещё, — может создать новых субагентов или поменять стратегию. Когда сведений хватает, все находки передаются агенту цитирования (CitationAgent), который находит в документах конкретные места для ссылок, — так каждое утверждение отчёта привязано к источнику.

Отличие от классического RAG: там поиск статический (найти чанки, похожие на запрос, и ответить по ним), здесь — многошаговый, адаптирующийся к находкам.

Восемь правил промптинга агентов

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

1. Думайте как ваш агент. Сделайте симуляцию с точными промптами и инструментами системы и смотрите на работу агента шаг за шагом. Сразу видны провалы: агент продолжает, хотя результатов уже хватает; пишет слишком длинные запросы; выбирает не тот инструмент.
2. Научите оркестратор делегировать. Каждому субагенту нужны цель, формат результата, указания по инструментам и источникам и чёткие границы задачи. Короткое «исследуй дефицит полупроводников» приводило к тому, что один субагент изучал автомобильный кризис чипов 2021 года, а двое других дублировали друг друга, исследуя цепочки поставок 2025 года.
3. Соизмеряйте усилия со сложностью. Агенты плохо оценивают, сколько сил нужно, поэтому правила зашили в промпт: простой факт — 1 агент и 3–10 вызовов инструментов; прямое сравнение — 2–4 субагента по 10–15 вызовов; сложное исследование — больше 10 субагентов с чётко разделёнными обязанностями.
4. Проектирование и выбор инструментов критичны. Агент, который ищет в вебе то, что есть только в Slack, обречён. С MCP-серверами проблема усиливается: агент встречает незнакомые инструменты с описаниями очень разного качества. Агентам дали эвристики: сначала осмотреть все доступные инструменты, подбирать инструмент под намерение пользователя, веб — для широкого поиска, специализированные инструменты предпочитать общим.
5. Пусть агенты улучшают себя. Модели Claude 4 оказались хорошими промпт-инженерами: по промпту и описанию провала они ставят диагноз и предлагают исправления. Сделали даже агента-тестировщика инструментов: он десятки раз пробует «сломанный» MCP-инструмент и переписывает его описание. Новые описания сократили время выполнения задач будущими агентами на 40 % — они просто перестали ошибаться.
6. Сначала широко, потом узко. Как эксперт-человек: сначала обзор местности, потом детали. Агенты по умолчанию пишут слишком длинные и узкие запросы, которые почти ничего не находят; их учили начинать с коротких общих запросов и постепенно сужать.
7. Направляйте размышления. Режим размышлений (extended thinking) — управляемый черновик: ведущий агент планирует в нём, какие инструменты подходят, насколько сложен запрос, сколько субагентов нужно и какова роль каждого. Субагенты планируют, а после результатов инструментов размышляют снова (interleaved thinking): оценивают качество, ищут пробелы, уточняют следующий запрос.
8. Параллельные вызовы ускоряют всё. Ведущий запускает 3–5 субагентов одновременно, а каждый субагент — 3 и больше инструментов одновременно. Время исследования сложных запросов сократилось до 90 %.

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

Как оценивать агентов

Обычный эвал предполагает, что на вход X система идёт путём Y к выходу Z. Агенты так не работают: одинаково стартовав, один найдёт ответ за три источника, другой за десять, разными инструментами. Поэтому оценивают результат и разумность процесса, а не совпадение с заранее заданными шагами.

• Начинайте сразу и с малого. В начале разработки правка промпта может поднять успех с 30 % до 80 % — такой эффект виден на нескольких примерах. Авторы начали примерно с 20 запросов, отражающих реальное использование. Ошибка многих команд — откладывать эвалы, считая, что полезны только наборы из сотен кейсов. (Почему 20 примеров хватает для большого эффекта и не хватает для маленького, объясняет урок 7.3.2 про бутстрэп.)
• LLM-судья масштабируется, если сделан хорошо. Отчёты — свободный текст без единственного правильного ответа. Судья оценивал по рубрике: фактическая точность (утверждения соответствуют источникам?), точность цитат (источник подтверждает утверждение?), полнота, качество источников (первоисточники лучше вторичных), эффективность инструментов. Пробовали отдельных судей на каждый критерий, но один вызов с одним промптом, выдающий оценки от 0,0 до 1,0 и итог «прошёл/не прошёл», оказался самым стабильным и лучше всего совпадал с оценками людей.
• Люди находят то, что пропускает автоматика: выдумки на необычных запросах, системные сбои, тонкие перекосы в выборе источников. Тестировщики заметили, что ранние агенты стабильно предпочитали SEO-оптимизированные «контент- фермы» авторитетным, но хуже ранжированным источникам — научным PDF и личным блогам. Помогли эвристики качества источников в промпте.

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

Инженерия продакшена

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

• Агенты хранят состояние, ошибки накапливаются. Перезапускать с нуля дорого и раздражает пользователей, поэтому система умеет продолжать с места сбоя. Помогает и сама модель: если сообщить агенту, что инструмент сломался, он неплохо адаптируется. Это сочетают с детерминированными страховками — повторами запросов и регулярными контрольными точками.
• Отладка требует трассировки. Агенты недетерминированы даже при одинаковых промптах. Жалобу «агент не нашёл очевидное» не разобрать без полной трассировки в продакшене: плохие запросы? плохие источники? сбой инструмента? Следят и за паттернами решений и структурой взаимодействий — не читая содержимого разговоров, ради приватности.
• Выкатка новых версий — «радужная» (rainbow deployment). Агенты работают почти непрерывно и в момент обновления могут быть в любой точке процесса. Нельзя переключить всех разом: трафик постепенно переводят со старой версии на новую, держа обе запущенными.
• Синхронность — узкое место. Сейчас ведущий агент ждёт, пока закончит вся группа субагентов: он не может их направлять, они не могут координироваться, и вся система ждёт самого медленного. Асинхронное исполнение даст больше параллелизма, но усложнит координацию результатов, согласованность состояния и распространение ошибок.

Приложение: ещё три совета

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

Что сделать руками

1. Возьмите своего агента из урока 8.3.1 и добавьте «удаление старых результатов инструментов»: в сообщениях старше трёх шагов заменяйте содержимое tool_result на «[результат удалён, см. заметки]». Сравните число токенов и качество на 10 задачах.
2. Добавьте агенту инструмент write_note/read_notes (файл NOTES.md) и задачу, которая не помещается в окно маленькой локальной модели (например, сводка 20 длинных статей). Помогают ли заметки?
3. Соберите «мини-Research» по паттерну оркестратора: ведущий агент делит вопрос на 3 подвопроса, три субагента отвечают по Википедии (инструмент из курса Tool use), ведущий сводит. Сравните расход токенов с одиночным агентом — ближе к «×4» или к «×15»?
4. Напишите рубрику LLM-судьи для отчётов по образцу из статьи (пять критериев, оценки 0–1 и итог «прошёл/не прошёл») и проверьте её на 5 отчётах из задания 3.

Словарик

EN	RU
context engineering	инженерия контекста
context rot	«гниение» контекста, деградация на длинном контексте
attention budget	бюджет внимания
right altitude (of a prompt)	правильная «высота» промпта (уровень конкретности)
just-in-time retrieval	извлечение «точно в срок»
progressive disclosure	постепенное раскрытие
compaction	сжатие (уплотнение) контекста
tool result clearing	удаление результатов инструментов
structured note-taking, agentic memory	структурированные заметки, агентная память
lead agent, subagent	ведущий агент, субагент
emergent behavior	эмерджентное поведение
end-state evaluation	оценка конечного состояния
rainbow deployment	«радужная» (постепенная) выкатка