Надёжные AI-агенты: контекст, инструменты и оценка

Агенту нужны явные правила исполнения

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

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

Сначала ограничьте процесс, затем увеличивайте автономность

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

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

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

Отделите сохраняемое состояние от текущего контекстного окна

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

Архитектура Managed Agents, представленная Anthropic в апреле 2026 года, разделяет сессию, управляющую обвязку агента и среду исполнения. Полезное следствие: агент может извлекать нужные события из постоянного журнала, не полагаясь на единственную растущую переписку.

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

Подбирайте контекст под каждое решение

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

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

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

Делайте инструменты узкими, типизированными и учитывающими права

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

inspect_release(commit, repository) → evidence
run_checks(commit, check_profile) → test_results
prepare_release(commit, evidence_ids) → proposal
execute_release(proposal_id, approval_id, idempotency_key) → execution_record

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

MCP может стандартизировать обнаружение и вызов инструментов, но подключение по протоколу не заменяет проектирование безопасности приложения. Рекомендации MCP по безопасности рассматривают, среди прочего, угрозу confused deputy и неконтролируемую передачу токенов доступа. Особенности черновой документации нужно сверять с используемой версией протокола.

Не доверяйте инструкциям из внешних источников

Файлы репозитория, веб-страницы и ответы инструментов могут содержать инструкции, направляющие агента к чужой цели. Модель способна ошибочно принять такое содержимое за источник полномочий. В результате prompt injection может перевести операцию чтения в попытку изменения данных или их раскрытия.

Рекомендации OWASP по prompt injection предлагают многоуровневые меры: минимальные привилегии, детерминированные проверки и контроль привилегированных операций. Пометка внешнего текста полезна, но не обеспечивает полной защиты.

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

Проектируйте повторы с учётом побочных эффектов

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

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

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

Оценивайте результат и изучайте трассу исполнения

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

Начальная матрица оценки релизного ассистента может включать:

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

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

Определите, что можно безопасно менять после запуска

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

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

О поисковой архитектуре и разрешениях читайте в статье RAG или fine-tuning. О стоимости контекста и генерации — в статье об инференсе LLM.