Сабагенты на практике: роли, бюджеты, запреты и тихие сбои

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

Проблема знаний связана с навыками. Проблема ролей — с субагентами, и именно это рассматривается в данной статье.

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

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

Роль подагента

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

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

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

Постоянный ввод текста — это триггер, о котором упоминают все руководства. Однако именно он не стал причиной появления двух агентов, которые существуют до сих пор; они возникли под воздействием двух других факторов.

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

Рецензент представляет собой приятного первого субагента. Эти два типа различаются: именно они превращают ту или иную функцию из удобства в способ фактического выполнения проекта.

Навыки против субагентов: знание против действий

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

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

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

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

Знания должны входить в состав навыка. Методология — в состав подагента.

Что такое подагент в Claude Code

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

Внутри Claude Code сабагент на самом деле представляет собой всего лишь Markdown-документ, начинающийся с небольшого блока YAML. Его могут хранить два каталога:

• ~/.claude/agents/ — это личная библиотека, доступная в каждом проекте на компьютере. Рассматривайте её как песочницу.
• .claude/agents/ внутри репозитория применяется только к этому проекту и передаётся вместе с репозиторием после его коммита.

Фронтматер короткий. Вот полный рабочий пример:

---
name: migration-risk-reviewer
description: Reviews database migration plans and schema changes for rollback risk, lock contention, and data integrity problems. Use before running any migration against real data.
tools: Read, Grep, Glob
model: sonnet
---

You are a senior database engineer reviewing a migration for production risk.

## What you look at first

- Can this be rolled back without losing data?
- Does it hold locks on a busy table during deploy?
- Is the ordering safe for a multi-step change?
- Will existing data violate any new constraint?

## Output shape

Findings in order of severity:

1. Blockers — deploy will fail or data will be lost
2. High risk — real production risk, needs a mitigation
3. Medium risk — should fix, won't necessarily block
4. Notes — worth tracking

For each finding: what it is, why it matters, what to do about it.

Есть несколько важных моментов, связанных с тем, как Claude Code обрабатывает подобные файлы, которые стоит знать.

• Основная часть текста — это системное указание. Всё, что находится под метаданными, становится инструкциями для подагента при его запуске. Это не документация, которую модель читает, а затем действует на её основе. Модель читает её и принимает её в качестве своей идентичности.
• description имеет большое значение. Claude Code обращается к нему, чтобы решить, когда автоматически передавать задачу другому агенту, поэтому его следует писать так, чтобы кто-то другой мог понять его смысл из контекста. Фраза вроде «Использовать перед запуском любой миграции» будет понятна, а фраза «помогает с работой с базой данных» — нет. Также необходимо указать негативные аспекты: оба рассматриваемых здесь агента описывают, для чего они не предназначены, поскольку система с радостью передаст им задачу, которая им не подходит.

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

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

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

Вам не нужно вручную писать файлы. Опишите роль для Claude Code, и он создаст файл в нужном месте. Команда /agents также используется для управления ими.

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

Слово «агент» выполняет слишком много функций

Этот термин применяется к четырем разным вещам, и их путаница вызывает постоянные недопонимания. Разделим их:

• Подагент (файл в папке .claude/agents/ или файл .agent.md в режиме Copilot) — это повторно используемый файл, определяющий специализированную роль. Именно об этом идет речь в статье.
• Режим агента или автономная работа — это переключатель функций. Вы позволяете инструменту выполнять команды и редактировать файлы без необходимости утверждения каждой строки. Это настройка прав доступа и не имеет никакого отношения к специалистам.
• Агент для кодирования в фоновом режиме или в облаке — это сервис, который берёт задачу, выполняет её незаметно и возвращает ветку или запрос на слияние. Это также не является специализированным файлом.
• Файл инструкций на уровне репозитория — это постоянно действующее руководство, правила, которым должен следовать каждый агент в данном кодовом базисе. Можно считать его руководством для сотрудников, а не коллегой, по имени к которому обращаются.

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

Создание первого подагента

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

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

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

Что входит в описание

После определения роли полезное описание включает пять элементов. В первый день не нужны все пять.

1. Что модель оптимизирует. Одна вещь, которую эта роль стремится сделать как можно лучше. Когда возникает компромисс, именно её модель старается сохранить.
2. Что проверяется в первую очередь. Сигналы высшего приоритета, которые любой настоящий специалист изучает прежде всего.
3. Варианты сбоев. Конкретные способы, каким образом эта категория задач может пойти не так. Именно здесь заключается настоящий профессионализм, и большая часть его проявляется только при наблюдении за тем, как агент ошибается при выполнении реальных задач.

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

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

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

Пример: охотник на баги, игнорирующий последние изменения

Вот пример, возникший из-за постоянных проблем. Что-то ломается, ошибка копируется в Claude Code, и его первым порывом становится просмотр файла, который был изменен последним. Иногда это правильно. Но часто последняя правка с этим совершенно не связана.

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

---
name: bug-investigator
description: Investigates a bug or failure starting from evidence, not from recent code changes. Produces ranked hypotheses with the next diagnostic step for each. Use for "why is this broken" before touching the source.
tools: Read, Grep, Glob, Bash
---

You are a senior engineer investigating a failure. Your job is to find the most
likely cause, rule out the alternatives, and say what to check next.

## Investigation order

1. Start from the symptom — what is actually failing, and how does it show up?
2. Get the error output and any logs from around the time it broke — ask the caller for them if they weren't provided.
3. Only then look at recent changes, and only if the evidence points there.
4. Read source last, once there's a symptom-to-cause hypothesis worth testing.

## Output shape

**Symptoms:** what's failing and how it manifests.
**Likely causes (ranked):** for each — the hypothesis, the evidence for it, the next diagnostic step.
**Ruled out:** what you checked and why it isn't the cause.
**Next steps:** in priority order.
**Open questions:** what you still can't confirm.

## Failure modes to avoid

- Don't assume the last change is the cause without evidence.
- Don't propose a fix before you can name the mechanism.

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

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

Противоположность ожидаемому: сабагент начинает работу с нуля

Все считают изолированное окно контекста полным успехом. Однако это имеет и обратную сторону.

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

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

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

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

В такой конфигурации объектом передачи является файл TASKS.md в корне репозитория, создаваемый навыком планирования. Активная задача содержит именно эти разделы и ничего больше:

• Цель. Что будет истинным после завершения работы.
• Причина (указатель). Ссылка на решение, записанное в PLAN.md, а не новый аргумент в пользу него. Это указатель, а не проза.
• Статус выполнения. Агент постоянно обновляет этот раздел. Более подробно об этом ниже, поскольку именно этот раздел спасает вас.

Дизайн в виде пронумерованных элементов. Последовательная очередь, где [ ] означает «не начато», [x] — «завершено», а [!] — «заблокировано»; зависимости указываются непосредственно рядом, например зависит от #2.

Файлы. Место, где выполняется работа.

Тесты. Проверки, заменяющие собой процедуру рецензирования.

Вне объема. Самый ценный раздел во всем документе.

Отчет. Что обязательно должно быть в итоговом сообщении.

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

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

Состояние выполнения, поскольку сессии прерываются

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

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

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

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

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

Кто оплачивает тот или иной тип мышления

Здесь поле model играет ключевую роль, и экономика всей системы зависит от него.

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

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

Такое разделение также позволяет использовать два разных ритма работы одного и того же механизма.

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

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

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

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

Без бюджета он тратит всё

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

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

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

Предложите возможность выбора степени глубины вместо фиксированного лимита. Любое единственное настройка в большинстве случаев бывает неверной: слишком строгая для сложного вопроса, слишком щедрая для быстрого получения факта. Благодаря трём определённым уровням и указанному по умолчанию значению запрос на deep становится осознанным выбором, а не случайностью. Также указан порядок приоритетов: преимущество имеют значения, заданные пользователем, затем уровень, указанный в запросе, затем настройки проекта, и наконец standard.

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

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

Подсчитайте элементы, которые что-то стоят. Бюджет на запросы включает в себя каждый сетевой запрос, от стандартных запросов до каждой попытки получения заблокированных страниц, а также каждый HTTP-запрос во вспомогательном скрипте; каждая попытка повторного запроса с кодом 429 в таком скрипте учитывается отдельно. В ранней версии учитывались только «запросы к серверу», и агент непреднамеренно обходил это ограничение. Это не считалось обманом — он просто верно следовал плохо написанному правилу.

Настройте возможность отчета о расходах. После каждого этапа агент сообщает строку вида [deep: 3/20 поисков, 5/30 запросов]. Без этого невозможно отличить тщательный процесс поиска от неуправляемого до его завершения. Если бюджет исчерпывается, а вопросы остаются без ответа, агент останавливается и указывает, что именно осталось неизвестным, какой URL с наибольшей вероятностью даст ответ, а также что возможен вариант повторного более глубокого поиска. Единственным запрещенным действием является продолжение работы за пределами установленного лимита без указания на это, поскольку уровень сложности был выбран пользователем, и превышение бюджета отменяет этот выбор.

Ограничения составляют основу зрелого агента

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

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

Ещё один пример исходит от разработчика из репозитория research-agent, где именно этот механизм является основной причиной того, что все соблюдают правило. Он никогда не должен создавать файлы в папках agents/ или skills/, поскольку agents/ содержит готовый пакет данных, а менеджер пакетов при установке преобразует все файлы формата .md, находящиеся внутри него, в отдельных агентов верхнего уровня. Любой случайный файл, оказавшийся там, попадёт во все проекты-потребители.

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

Со временем эти ограничения могут принимать еще несколько форм:

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

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

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

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

Они терпят неудачу бесшумно и уверенно

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

Произошло следующее: запрос WebSearch с ограничением site:reddit.com вернул десять чистых, правдоподобных результатов с других доменов, среди которых был форум сообщества рынка ремесел, сайт правительства, посвящённый малому бизнесу, и сайт для обмена слайдами, причём не было никаких ошибок. Ни ошибки 403, ни пустого набора результатов, ни предупреждений. Фильтр доменов был молча проигнорирован, и в результатах поиска об этом не говорилось. У агента появился аккуратный список пригодных к использованию страниц с неправильных источников, и он поступил так, как поступил бы любой разумный сотрудник с таким списком: он использовал эти страницы и сообщил о успехе.

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

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

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

Проведите механический тест. Ошибок не обнаружено, поэтому агент не увидел причин для проверки чего-либо. Решение заключается в одном предложении, не требующем дополнительных суждений: когда поиск ограничен определенным доменом, а ни один из полученных URL не принадлежит ему, следует считать это нулевым количеством результатов, а не набором результатов. Для этого не требуются дополнительные инструменты, запросы или разрешения, поскольку URL уже имеются. Фраза «Будьте насторожны по отношению к источникам» не даёт агенту никаких действий, тогда как фраза «Проверьте хост-имя на соответствие тому, по которому вы проводили фильтрацию» даёт четкие указания.

Рассматривайте источник данных как обязательный канал вывода с определенной структурой. Именно здесь форма вывода перестает быть просто набором заголовков разделов и начинает вести себя как конкретный тип. Два массива привязываются к своим именам ключей.

• unreachable[] содержит по одной записи на каждую стену; ключи в ней — именно source, url и reason. Она охватывает как ситуации с полным провалом загрузки, так и случаи бесшумной замены.
• sources[] содержит по одной записи на каждый источник, который действительно смог предоставить ответ; ключи здесь — именно source, url и fields. Страницы, которые были открыты, но не передали никакой информации, не фиксируются. Если источник предоставил ответ для четырех полей, создается одна запись с четырьмя именами, а не четыре отдельные записи.

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

Каждая неудача несёт с собой урок, который стоит усвоить. В первой версии этого агента было указано в четырёх отдельных местах записывать информацию как «недоступную», однако так и не было указано ни поле, ни массив, ни место для сохранения результата. Такая инструкция ни к чему не привела. Агенту приходилось записывать что-то, куда это поместить было невозможно, поэтому он ничего не записывал, и никто на это не жаловался. Каждый раз, когда вы пишете инструкцию для подагента, убедитесь, что действие, которое она описывает, имеет конкретное место назначения. Инструкция «Сообщить X», в которой не указано, куда именно записывать X, ничего не делает, но при этом считается корректной.

Проверяйте работу агента извне. То, соблюдал ли агент свои обязательства по выводу данных, определяется скриптом, запускаемым позже, а не утверждениями самого агента. Примерно 180 строк кода на Python проверяют структуру JSON на соответствие заявленным полям, и это имеет большее значение, чем любые подчёркивания в самом запросе.

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

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

Одна задача на агента и факторы, приводящие к увеличению размера файла

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

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

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

Два агента, которые выжили

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

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

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

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

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

Тогда пропустите схему организации. Обратите внимание на ту работу, которую хотели бы выполнить в другом месте, и сохраните именно её.

Сначала шаблон, затем специализация

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

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

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

Копия другого проекта получила указание изучать те решения из файла PLAN.md, на которые указывает задача, перед написанием кода, а также поле для отчета о всем, что требует вмешательства Opus или человека. Протокол остается прежним, но риски отличаются.

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

Направьте агента к знаниям, а не вставляйте их вручную

Именно здесь встречаются навыки и подагенты, и идея стала гораздо более конкретной, когда от неё стала зависеть реальная работа системы.

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

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

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

Два аспекта механики оказались важнее, чем ожидалось.

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

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

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

Где находятся файлы: личные, проектные, упакованные

Существует три уровня, и именно на третьем проживают все настоящие агенты.

• Личные (~/.claude/agents/) предназначены для общих специалистов, нужных в любом проекте. Считайте их рабочей мастерской, где допускается ломать что-то.
• Проектные (.claude/agents/, сохранённые в коммите) — для специалистов, которые имеют смысл только в одном кодовом репозитории, например, для реализатора, который знает, что в проекте отсутствуют тесты. Сохраните их в коммите, и они будут ждать вас при возвращении, даже через четыре месяца, если проект забылся.
• Упакованные (установленные с помощью менеджера пакетов и привязанные к конкретному коммиту) превращают агента в зависимость. Это тот уровень, о существовании которого никто не догадывается, пока тот же агент не окажется в дюжине репозиториев, и тринадцать копий не начнут развиваться независимо друг от друга.

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

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

Узнайте, что делает ваш установщик с файлами. Этот пакет устанавливается через APM от Microsoft, который преобразует каждый файл формата .md, находящийся в каталоге agents/, в отдельного агента верхнего уровня. Такой стандартный подход кажется разумным, но приносит проблемы. Если поместить туда данных файл, каждый проект-потребитель получит ложного зарегистрированного агента. Если же записать туда агента, специфичного для проекта, он установится в репозиториях всех пользователей. Именно по этой причине модули стратегии поиска находятся в каталоге skills/, а не в папке agents/, куда они, казалось бы, должны быть помещены: в agents/ они потеряют свою структуру при установке и приведут к созданию пяти фиктивных агентов в каждом проекте-потребителе.

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

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

Та же идея в других инструментах

Claude Code — не единственный инструмент для этого. Если вы переходите с одного инструмента на другой, эти принципы сохраняются даже там, где форматы файлов отличаются.

GitHub Copilot и VS Code называют их пользовательскими агентами, которые хранятся в виде файлов .agent.md, обычно в папке .github/agents/, при этом существует возможность создания личной библиотеки в пользовательском каталоге. В структуре frontmatter больше полей, чем у Claude: помимо предыдущих полей name, description и tools, здесь присутствуют argument-hint, model, user-invocable, disable-model-invocation, а также, что самое ценное, handoffs. Готовый агент может отображать кнопку, которая передаёт задачу другому агенту с уже заполненным следующим запросом, тем самым позволяя планировать, выполнять и проверять действия последовательно, без слияния их в один запутанный агент. Это ловушка, если читать более старые примеры: ранее существовавшее поле infer было разделено на два отдельных поля — user-invocable и disable-model-invocation; с точки зрения прошлого это выглядит упорядоченно, но изначально создаёт путаницу.

Ещё одно утверждение, с которым вы можете столкнуться, заключается в том, что VS Code распознаёт файлы .claude/agents/ и переводит названия инструментов, благодаря чему один агент может обслуживать оба инструмента бесплатно. Это действительно так, но это вводит в заблуждение. Словари терминов инструментов не совпадают, и запрос, запрещающий использование инструментов по их названию, как это делает каждый зрелый агент, не сохраняется в неизменном виде при автоматическом переводе.

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

---
name: Web Research Writer
description: "Use for bounded web research that must read a local schema, search and fetch current sources, write one designated result file, and validate it with a local command."
tools: [read, search, web, edit, execute]
user-invocable: false
disable-model-invocation: false
---

Load the installed canonical research prompt from the first existing candidate:

1. `.github/agents/web-search-agent.agent.md`
2. `.claude/agents/web-search-agent.md`

Follow its search budgets, module routing, source standards, tool discipline, output, and validation rules. Ignore that file's incompatible `tools` frontmatter; this wrapper's Copilot-native tool categories govern this session.

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

В документации проекта указан один недостаток. Если направить загрузчик на папку .github/agents/, канонический промпт регистрируется как самостоятельный агент, из-за чего Copilot может показывать дублирующиеся названия: имитатор «Web Research Writer» и канонический файл. Выберите одно место хранения для каждого инструмента или оставьте канонический файл в папке .claude/agents/, где автоматическое обнаружение Copilot его игнорирует.

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

Как на самом деле создаются качественные решения

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

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

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

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

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

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

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

Связанные материалы

• Практические заметки: пошаговое руководство по созданию собственного агента — Подробное руководство с примерами использования: контракты, проверки и готовые блоки кода для команд, внедряющих эту модель.
• Практические заметки: Qwen3.8–27B как новый предпочтительный инструмент для программирования с SGLang/vLLM и — Подробное руководство с примерами использования: контракты, проверки и готовые блоки кода для команд, внедряющих эту модель.

«The Harness Is the Product: Практическое руководство по харнесам в агентных ИИ» — Узнайте, что такое харнес агента и каковы его семь компонентов: от инструментов и контекста до ограничений и механизмов оценки, а также субагентов, способов сбоев и полезных фреймворков.