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

За год правила производства агентов пересобрались. Появилось семь отдельных дисциплин. Это первая из двух частей: здесь — четыре дисциплины‑фундамента, на которых держится рабочий агент, а не демка. И три из этих четырёх — не про то, что добавить, а про то, что убрать лишнее и довериться модели. Во второй части будут три frontier‑дисциплины и полная карта.

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

Кто такой человек рядом с агентом

«Человек больше не пишет код — он оркестрирует агентов». Это в 2026 повторяют все, включая Anthropic в Founder's Playbook (гайд для основателей, документ маркетинговый, не инженерный). Сама по себе фраза пустая: и так ясно, что при работе с агентами руками работает агент.

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

Рамка: ты компенсируешь то, чего у модели нет — но ровно столько, сколько нужно

У этой карты есть сквозной принцип, и без него семь дисциплин выглядят просто списком модных слов.

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

Но есть обратная сторона, и её часто пропускают. Anthropic в посте «Scaling Managed Agents» формулирует это прямо:

«harnesses encode assumptions about what Claude can't do on its own» — обвязка кодирует допущения о том, чего модель не умеет сама

А допущения устаревают. Их собственный пример. Модель поколения Sonnet 4.5 имела привычку сворачивать задачу раньше времени, чувствуя приближение лимита контекста, — это назвали «context anxiety». В обвязку добавили сброс контекста, чтобы лечить. Перешли на Opus 4.5 — поведение исчезло само, и сброс превратился в мёртвый груз.

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

Дисциплина 1. Context engineering: меньше контекста, а не больше

Самая базовая дисциплина и прямое продолжение разговора про тело агента. Anthropic называет context engineering естественным продолжением промпт‑инжиниринга: вопрос сместился с «как сформулировать инструкцию» на «какой набор токенов должен видеть модель в момент вывода».

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

Было: напихать в системный промпт всё, что может пригодиться, на всякий случай. Огромные инструкции, вся история, все возможные примеры.

Стало: держать в контексте минимально достаточный набор и подтягивать остальное по требованию. Внешняя память вместо раздутого промпта — агент пишет заметки в файл (тот же claude-progress.txt, что в harness ниже) и перечитывает их, а не тащит всё в окне.

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

Что проверить у себя: чистится ли контекст между фазами длинной задачи и вынесена ли при этом рабочая память во внешний файл вроде claude-progress.txt, чтобы сброс её не стёр; лежит ли постоянный контекст проекта в CLAUDE.md, чтобы каждая сессия не выводила структуру заново; нет ли в системном промпте инструкций «на всякий случай», которые ни разу не сработали.

Дисциплина 2. Tool design: инструменты под модель, а не под человека

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

Отсюда правила, которые на первый взгляд странные для бэкендера:

• Не делай по инструменту на каждый эндпойнт API. Обернёшь каждый — у агента окажется десяток почти одинаковых инструментов (get_user, find_user, list_users, search_users), и на каждом шаге он тратит контекст на выбор, какой взять, а часто берёт не тот. Лучше меньше инструментов, каждый под реальную задачу агента, а не под строчку в твоём API.

• Возвращай осмысленный контекст, а не голые ID. user_42931 для модели — пустая метка: по ней не понять, кто это и что с ним делать, и чтобы разобраться, агенту придётся делать ещё один вызов. А Анна Петрова, заказ #18, оплачен модель уже может сравнивать и принимать решение прямо в рассуждении. ID оставляй рядом, если он нужен для следующего вызова, но не делай его единственным, что видит модель.

• Думай про токены ответа. Пагинация, фильтрация, усечение — чтобы один вызов не утопил контекст (привет, дисциплина 1).

• Описание инструмента — это промпт. Каждое слово в имени и описании влияет на то, выберет ли модель этот инструмент правильно.

И здесь снова заголовок. Чем сильнее модель, тем дальше она уходит на общих примитивах — файловая система, выполнение кода, bash — вместо россыпи узких функций под каждый шаг. Сильной модели не нужно диктовать пошагово; ей нужно дать общий инструмент и цель.

Было: спроектировать REST‑style API, по эндпойнту на операцию, и отдать агенту как есть.

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

Что проверить: можешь ли ты сам, как человек, однозначно сказать, какой инструмент применить в конкретной ситуации, — если нет, модель тоже не сможет; не дублируют ли инструменты друг друга; не возвращают ли они сырые простыни, которые жрут контекст.

Дисциплина 3. Agent Skills: подтягивать навык, а не держать его в голове

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

Agent Skills — это способ упаковать навык (инструкцию плюс опциональные скрипты и файлы) в папку с одним файлом SKILL.md. В октябре 2025 Anthropic выпустила это как фичу, в декабре 2025 — как открытый стандарт (спецификация живёт на agentskills.io). За три месяца его прочитали больше тридцати инструментов от конкурирующих компаний — Claude Code, Codex CLI от OpenAI, Cursor, Copilot, Gemini CLI. Один и тот же SKILL.md работает везде, без переделки.

Но почему это дисциплина, а не просто формат файла, и почему она в одном ряду с заголовком «тем меньше ей нужно». Потому что в основе Skills лежит progressive disclosure — постепенная подгрузка в три уровня:

• Discovery. В контекст всегда грузится только имя и описание каждого навыка — порядка 30–80 токенов. Это оглавление: модель знает, что навык существует, но не тратит контекст на детали.

• Activation. Когда задача совпала с описанием, агент читает полное тело SKILL.md — в среднем около двух тысяч токенов.

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

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

Было: один гигантский системный промпт, в который зашиты все процедуры и все правила команды, и он всегда целиком в контексте.

Стало: библиотека навыков, из которой агент держит в контексте только оглавление и разворачивает нужное по ходу.

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

Дисциплина 4. Harness engineering: леса вокруг долгой задачи

Четвёртая дисциплина — про то, что происходит, когда задача не влезает в одно окно контекста. Часовая или многодневная работа: миграция кодовой базы, сборка приложения с нуля, длинный research.

Сначала термин. Scaffolding (обвязка, «леса») — это всё, что вокруг модели, но не сама модель: циклы, инструкции, набор инструментов, файлы состояния. Harness — частный случай: обвязка, в которой агент работает долго и автономно. Модель — мозг, harness — строительные леса вокруг стройки.

Главная проблема долгих задач, как описывает Anthropic: агент работает дискретными сессиями, и каждая новая начинается с чистого листа, без памяти о предыдущей. Представь стройку, где каждую смену приходит новый рабочий, ничего не знающий о прошлой смене. Решение Anthropic — два агента: инициализатор, который на первом запуске разворачивает структуру (список фич в JSON, git‑репозиторий, файл прогресса claude-progress.txt), и кодящий агент, который каждую сессию делает инкремент и оставляет артефакты для следующей. Это и есть компенсация архитектурной дыры из рамки: у модели нет памяти между сессиями — память строят снаружи.

Но именно в harness виден и второй край принципа — где леса превращаются в клетку. На Code with Claude 2026 это сформулировали так:

«as models get smarter, the scaffolding that used to help can hold Claude back» — чем умнее модель, тем больше прежняя обвязка может её сдерживать

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

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

Было: плотные леса под каждый шаг, потому что слабую модель без них клинило.

Стало: минимально достаточный harness — структура, чекпоинты, верификация — и доверие модели там, где она уже справляется. Проектируй под следующую версию модели, не под текущую.

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

Что со всем этим делать

Четыре дисциплины — это фундамент. Context engineering решает, что модель видит. Tool design — чем она действует. Agent Skills — как подтягивает знание по требованию. Harness — как держит длинную задачу, не теряя нить. Сквозь все четыре проходит одна мысль: ты компенсируешь то, чего у модели нет, но снимаешь подпорки там, где она уже выросла.

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

Продолжение — во второй части. Там три frontier‑дисциплины: оркестрация нескольких агентов под одним ведущим, граница безопасности (и почему prompt injection идёт не через запрос, а через данные) и evaluation. Плюс полная карта семи дисциплин одной страницей и сверка с индустриальной рамкой — насколько моя карта совпадает с тем, как те же дисциплины раскладывают в сертификации от GitHub и Microsoft.

Источники

Статья опирается на инженерные посты Anthropic (все на английском):

• Effective context engineering for AI agents — бюджет внимания, context rot, внешняя память, минимальный промпт (Дисциплина 1).

• Writing tools for agents — инструмент как контракт с моделью, осмысленный контекст вместо ID (Дисциплина 2).

• Equipping agents for the real world with Agent Skills — формат SKILL.md и progressive disclosure (Дисциплина 3).

• Effective harnesses for long‑running agents — обвязка для долгих задач, инициализатор и кодящий агент (Дисциплина 4).

• Scaling Managed Agents — обвязка кодирует устаревающие допущения, пример с context anxiety (рамка статьи).

• The Founder's Playbook — основатель как оркестратор (вступление; документ маркетинговый, не инженерный).

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

Разбираю эту серию и смежное в телеграм‑канале «Я и мой друг робот».