Как научить AI Agent профессиональной области

Официальный чек-лист оценки AI Agent указывает на реалистичный ориентир прохождения тестов в диапазоне 80–90% в зависимости от бизнес-требований. Это означает, что «подключить документы» недостаточно: чтобы AI Agent действительно освоил профессиональную область, вам нужны четыре согласованных слоя — Knowledge Base отвечает за знания, Agent Skills за процедуру, инструменты за действия, а оценочный набор за проверку надёжности. Только RAG или только набор инструкций дают неполную систему.

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

Сначала разделите четыре типа ответственности

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

Разделите систему так:

• Knowledge Base — проверяемые сведения, документы, версии, источники, даты действия и права доступа.
• Agent Skills — устойчивые процедуры, условия выбора, последовательность операций, формат ответа и контрольные пункты.
• Инструменты — интерфейсы для чтения данных, изменения состояния, запуска команд или передачи задачи на согласование.
• Оценочный набор — фиксированные тесты, по которым вы сравниваете версии Agent до и после изменений.

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

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

Первый шаг: создайте Knowledge Base, которую можно проверить

Knowledge Base должна быть не папкой с PDF-файлами, а каталогом утверждённых источников. Для каждого материала зафиксируйте как минимум:

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

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

Для каждого фрагмента полезно хранить не только текст, но и метаданные: тип документа, продукт, окружение, регион, команду-владельца и дату проверки. Поиск тогда можно ограничивать не только семантическим сходством, но и условиями применимости.

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

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

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

Где проходит граница между RAG и Skill

В RAG помещайте то, что должно часто меняться или требует ссылки на первоисточник:

• политики и регламенты;
• API-документацию;
• матрицы совместимости;
• тарифные и лицензионные условия;
• справочники;
• инструкции, зависящие от версии;
• внутренние решения и записи об инцидентах.

В Skill помещайте то, что описывает способ работы:

• последовательность шагов;
• критерии выбора;
• обязательные проверки;
• условия остановки;
• формат результата;
• правила эскалации;
• требования к журналированию.

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

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

Второй шаг: оформите SOP как Agent Skills

Хороший Skill начинается не с длинного описания предметной области, а с чёткой границы задачи. Укажите:

1. когда Skill следует активировать;
2. какие входные данные обязательны;
3. какие источники нужно найти;
4. какие шаги выполняются строго по порядку;
5. какие условия меняют маршрут;
6. какой результат считается успешным;
7. когда Agent обязан остановиться и передать задачу человеку.

Вместо расплывчатой инструкции «проверь конфигурацию и исправь проблему» задайте процедуру:

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

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

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

Обычно удобно разделять Skill по операциям, а не по отделам. Например, «разбор инцидента», «подготовка релиза» и «проверка макета» — более полезные границы, чем общий Skill «для команды разработки». Узкий Skill проще активировать, ограничить и сопоставить с оценочным набором.

Третий шаг: спроектируйте инструментный вызов до подключения API

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

Разделите инструменты минимум на четыре класса:

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

Для каждого инструмента задайте:

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

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

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

Если Agent работает с удалённой средой, изоляция также становится частью доменной компетенции. Для команд разработки это может означать отдельную рабочую машину или среду, где можно безопасно проверять Skill, состояние файловой системы, SSH-доступ, журналы и сценарии восстановления. Перед арендой среды в ZavCloud полезно изучить варианты аренды Mac для удалённой разработки, но не смешивайте наличие вычислительного окружения с доказательством надёжности самого Agent.

Четвёртый шаг: соберите оценочный набор до запуска

Оценочный набор не должен состоять только из вопросов с правильным текстовым ответом. Для профессионального Agent добавьте несколько классов тестов:

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

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

Отдельно измеряйте четыре показателя:

• точность извлечения знаний;
• соблюдение процедуры;
• корректность выбора инструмента;
• безопасность отказа.

Не объединяйте их в одну оценку слишком рано. Agent может хорошо отвечать на вопросы и одновременно опасно выполнять операции. Поэтому итоговая приёмка должна содержать отдельные пороги для каждого класса поведения.

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

Повторяйте тесты несколько раз, если ответы вероятностны. Даже при одинаковом запросе Agent может выбрать другой маршрут, особенно когда разрешены несколько инструментов или источников. В рекомендациях по оценке также отмечается, что реалистичная частота успешного прохождения зависит от требований бизнеса, а тесты нужно расширять по категориям качества. (learn.microsoft.com)

Пятый шаг: организуйте обновление и разрешение конфликтов

Назначьте владельца для каждой области знаний. Ответственный должен иметь право:

• утвердить новую версию;
• отозвать ошибочный документ;
• указать дату вступления в силу;
• описать заменяемую версию;
• определить, влияет ли изменение на Skill;
• инициировать повторную оценку.

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

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

После изменения Knowledge Base действуйте в таком порядке:

1. зарегистрируйте новую версию источника;
2. пометьте старую версию как заменённую;
3. проверьте метаданные и права;
4. запустите тесты поиска и цитирования;
5. определите влияние на Skill;
6. обновите Skill только при изменении процедуры;
7. повторите оценочный набор;
8. сохраните решение о выпуске.

Это важное различие: обновление знаний не всегда требует изменения Skill, а изменение Skill почти всегда требует повторной проверки поведения Agent.

Шестой шаг: проведите приёмку среды перед развёртыванием

До запуска проверьте не только ответы модели, но и эксплуатационную оболочку:

• изолированы ли тестовая и рабочая среды;
• где хранятся ключи и токены;
• исключаются ли секреты из логов;
• можно ли восстановить состояние после обрыва;
• что происходит при повторной доставке одной задачи;
• есть ли лимиты параллельных операций;
• как фиксируются версии модели, Knowledge Base и Skill;
• кто может просматривать журналы;
• как отключить инструмент без остановки всего Agent;
• куда передаётся задача после отказа или тайм-аута.

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

Используйте условия тарифа ZavCloud, если вам нужно заранее сопоставить требования проекта к удалённой среде с фактическим способом доступа и эксплуатации. Но финальное решение о запуске принимайте по результатам изоляции, журналирования, восстановления и оценочного набора, а не только по доступности нужного устройства.

Чек-лист перед выпуском

• [ ] Для каждого документа указаны версия, источник, владелец и дата действия.
• [ ] Устаревшие материалы исключаются из обычного поиска или явно помечаются.
• [ ] Skill описывает входы, шаги, условия остановки и формат результата.
• [ ] Динамические факты не продублированы в долгоживущих инструкциях.
• [ ] Инструменты разделены на чтение, подготовку, изменение и критические действия.
• [ ] Для каждого инструмента заданы схема аргументов и структурированный ответ.
• [ ] Опасные операции требуют подтверждения или отдельного разрешения.
• [ ] В оценочном наборе есть устаревшие знания, конфликт источников и сбой инструмента.
• [ ] Сохраняется baseline для сравнения версий.
• [ ] После обновления Knowledge Base проверяется влияние на Skill.
• [ ] В рабочей среде настроены изоляция, журналирование и восстановление.
• [ ] Зафиксированы условия, при которых Agent обязан отказаться от действия.

Ответьте на частые вопросы перед внедрением

Чем Knowledge Base отличается от Agent Skills?

Knowledge Base хранит доказуемые сведения, а Agent Skills — способ применения этих сведений. В базе должны оставаться документы, версии, источники, даты и права. В Skill фиксируются шаги, проверки, условия перехода и формат результата. Если смешать эти слои, обновление документа не гарантирует обновление поведения Agent.

Что размещать в RAG, а что — в Skill?

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

Как проверить освоение профессиональной области?

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

Как обновлять устаревшие знания?

Сначала измените источник и метаданные Knowledge Base, затем проверьте, не затронуты ли шаги Skill. После этого повторите тесты на старую версию, конфликт документов и ссылку на актуальное доказательство. Выпуск без повторной оценки создаёт риск, что Agent будет уверенно следовать прежней процедуре.

Вместо того чтобы пытаться решить задачу одним промптом или постоянно расширять RAG, рассматривайте доменного Agent как систему из четырёх управляемых слоёв. Такой подход позволяет отдельно найти причину ошибки и не переписывать весь проект после каждого изменения документа или API.

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