Несколько лет настройка нейросети почти полностью сводилась к промпту: нужно было подобрать формулировку, передать контекст и описать желаемый ответ. Для разовой задачи этого по-прежнему достаточно. Но рабочие ИИ-системы теперь читают документы, вызывают внешние сервисы, выполняют код и продолжают работу после первого ответа. Поэтому настраивать приходится не только текст запроса, но и среду, в которой модель действует.
Эту среду часто называют harness. В данном контексте слово означает техническую обвязку модели: код и правила, которые подают ей нужный контекст, открывают разрешённые инструменты, сохраняют состояние, ограничивают действия и проверяют результат. Harness engineering — проектирование и настройка такой обвязки.
Три уровня настройки
| Уровень | Что настраиваем | Для чего подходит | Где возникает проблема |
|---|---|---|---|
| Промпт-инжиниринг | Инструкцию для одного запроса | Черновик письма, анализ фрагмента, разовая классификация | Процесс приходится заново объяснять в следующей задаче |
| Skill engineering | Повторяемый способ работы, шаблоны и справочные материалы | Регулярный отчёт, редактура по правилам компании, сборка типового документа | Навык сам по себе не даёт доступ к данным и не управляет исполнением |
| Harness engineering | Инструменты, контекст, права, память, проверки и цикл выполнения | Агент, который получает задачу и доводит её до проверяемого результата | Плохо собранная обвязка делает даже сильную модель нестабильной или опасной |
Эти уровни не отменяют предыдущие. В рабочей системе по-прежнему нужны ясные инструкции. Просто теперь промпт находится внутри более крупного процесса.
Промпт-инжиниринг: точная инструкция на текущий ход
Промпт — сообщение с задачей для модели. В нём указывают цель, исходные данные, ограничения и формат результата. Например: «Собери протокол встречи. Не добавляй решений, которых нет в расшифровке. Для каждого поручения укажи ответственного и срок».
Качество формулировки заметно влияет на ответ. Модель должна понимать, что считать результатом и где нельзя додумывать. Однако длинный промпт плохо заменяет рабочий процесс. Если в него начинают добавлять правила бренда, порядок проверки, десятки исключений и инструкции по использованию сервисов, его трудно обновлять и ещё труднее тестировать.
Skill engineering: способ работы, который не нужно объяснять заново
Skill, или навык агента, — сохранённый сценарий выполнения повторяемой задачи. Он может включать инструкцию, шаблон результата, примеры, справочные файлы и небольшие скрипты. Агент подключает нужный skill, когда распознаёт соответствующую задачу.
Для протокола встречи skill может хранить структуру документа, правила оформления решений, список обязательных полей и проверку дат. Для еженедельного отчёта — порядок получения данных, формулы показателей и шаблон таблицы. Команда меняет правило в одном месте, после чего оно применяется в следующих запусках.
Skill engineering — работа над такими навыками: границами задачи, инструкциями, примерами, ресурсами и проверкой результата. Хороший skill описывает конкретную операцию. Файл на несколько сотен правил обо всём сразу будет занимать контекст и мешать модели выбирать нужное действие.
В Aiklava инструкции, документы и результаты можно держать в одном проекте, чтобы рабочий контекст не приходилось собирать перед каждым запросом. Попробовать ИИ в действии →
Harness engineering: что происходит вокруг модели
Модель получает текст и предлагает следующее действие. Harness превращает это предложение в управляемый процесс. Он решает, какие данные положить в контекст, какие инструменты показать модели, можно ли выполнить выбранное действие, что сохранить после него и когда работа действительно завершена.
В обвязку обычно входят оркестратор, хранилище состояния, подключения к сервисам, разграничение прав, журнал действий, обработка ошибок и проверки результата. Оркестратор — программа, которая ведёт цикл работы агента: передаёт задачу модели, исполняет разрешённый вызов инструмента, возвращает результат модели и останавливает процесс по заданным условиям.
Здесь решаются практические вопросы. Что делать при таймауте? Можно ли повторить платный запрос? Как не отправить одно сообщение пять раз? Кто подтвердит перевод денег или удаление записи? Как ограничить объём контекста? Какая проверка должна пройти до публикации? Ответы находятся в коде и конфигурации системы, а не в пожелании «работай внимательно».
Как работает MCP
MCP, Model Context Protocol — открытый протокол для подключения ИИ-приложений к внешним данным и инструментам по общим правилам. Его можно сравнить со стандартным разъёмом: приложение понимает, какие возможности предоставляет подключённый сервер и как их вызвать, без отдельной интеграции для каждого сочетания модели и сервиса.
В архитектуре MCP есть три основные роли. Host — ИИ-приложение, в котором работает пользователь и агент. Client поддерживает соединение с конкретным MCP-сервером. Server предоставляет ограниченный набор возможностей. Это могут быть инструменты для действий, ресурсы для чтения данных и готовые шаблоны запросов.
Например, MCP-сервер CRM может дать агенту инструменты «найти клиента» и «создать задачу». Сервер файлового хранилища — доступ к выбранной папке с договорами. Агент видит описание возможностей и вызывает нужную. Сам протокол не решает, следует ли разрешить изменение сделки конкретному сотруднику. Авторизация, подтверждение опасных действий, фильтрация данных и журналирование остаются частью harness.
Один пример: подготовка протокола встречи
На уровне промпта пользователь загружает расшифровку и просит выделить решения. Результат зависит от полноты команды и каждый раз требует ручного оформления.
Skill добавляет утверждённую структуру: участники, решения, поручения, сроки и открытые вопросы. В него же входит правило ссылаться на фрагмент расшифровки и не назначать ответственного по догадке.
Harness принимает аудиофайл, запускает распознавание речи, передаёт текст и skill модели, проверяет наличие обязательных полей, создаёт документ и сохраняет его в проекте. Через MCP он может получить список сотрудников из корпоративного каталога и положить готовый файл в разрешённую папку. Отправка документа коллегам выполняется только после подтверждения пользователя.
Так становится видно, где искать ошибку. Пропущено решение — проверяем инструкцию и качество расшифровки. Файл не сохранился — смотрим интеграцию и журнал вызовов. Документ ушёл не тем людям — исправляем права и этап подтверждения.
Что проверять при создании обвязки
Начать стоит с одного измеримого рабочего маршрута. Для него фиксируют допустимые источники данных, список действий, условия ручного подтверждения и признаки готового результата. Затем собирают несколько реальных примеров и проверяют весь путь целиком, включая ошибки сервисов и повторный запуск.
Отдельное внимание нужно доступам. Агенту не следует выдавать больше прав, чем требуется для задачи. Внешняя страница, письмо или документ могут содержать prompt injection — текст, который пытается выдать себя за новую инструкцию для модели. Поэтому данные из внешних источников нельзя автоматически считать доверенными командами, а значимые действия должны проходить проверку.
Что изменилось для команд
Умение писать хороший запрос осталось полезным, но качество рабочего ИИ теперь сильнее зависит от устройства всей системы. Команда описывает повторяемые операции в skills, подключает данные и действия через контролируемые интерфейсы, а в harness задаёт права, проверки, память и обработку сбоев.
Поэтому при выборе ИИ-платформы имеет смысл смотреть не только на список моделей. Важно понять, как она хранит контекст, подключает корпоративные источники, ограничивает инструменты, показывает историю действий и восстанавливается после ошибки. Именно эти детали определяют, сможет ли удачная демонстрация стать повседневным процессом.
Источники и определения
Определения и архитектура сверены с материалами OpenAI о harness engineering и skills, а описание MCP — с официальной документацией протокола. Практика разграничения доступа и проверок соответствует рекомендациям по построению агентов.