Опубликовано: 17.09.2026 | Источник: TechCrunch

Автономные LLM-агенты в дипломе: проектируем guardrails на примере Claude Code

Поддомен: AI/ML (агентные системы и безопасность LLM) · Роль эксперта: Data/ML-инженер

24 марта 2026 года Anthropic включила для Claude Code новый режим auto: агент выполняет цепочки задач с заметно меньшим числом подтверждений от разработчика, но остаётся под встроенными предохранителями — песочницей, политиками на инструменты и точками эскалации к человеку. Это не «ИИ получил свободу», а инженерный компромисс: скорость исполнения против контролируемости риска. Для выпускника ИТ это готовый полигон для ВКР. Тема лежит на стыке прикладного ML, DevTools и информационной безопасности — значит, работа получается современной, защищаемой и с внятной практической частью. Ниже — как превратить этот кейс в структуру диплома, какие метрики считать и где чаще всего валятся студенты.

Частые вопросы до старта

Нужен ли платный доступ к API Claude, чтобы защитить такую ВКР?

Нет. Достаточно воспроизвести архитектурный паттерн: policy engine, sandbox, аудит-лог. Можно взять открытые модели (Qwen, Llama через Ollama) или вообще заглушку-эмулятор агента с заранее записанными действиями. Комиссия оценивает методологию и измеримость, а не счёт за токены.

Где брать данные для оценки агента, если нет продакшн-логов?

Три источника: (1) синтетический набор задач (SWE-bench-подобные мини-кейсы на 40–60 репозиториев), (2) собственные сценарии по 5–10 типовым операциям — чтение файла, правка, запуск тестов, git-коммит, (3) публичные датасеты инцидентов агентов. Один прогон = одна траектория с действиями; этого хватает на статистику по метрикам автономности.

Как считать эффективность, если нет эталонной разметки «правильно/неправильно»?

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

Подойдёт ли тема для направлений 09.03.01, 09.04.01, 02.03.03?

Да, с уточнением акцента. Для программной инженерии — реализация policy engine, для ИБ — модель угроз по OWASP Top 10 for LLM Applications, для ИИ — оценка надёжности агента. Главное, чтобы объект и предмет исследования были сформулированы, а не «я написал бота».

Темы ВКР, которые реально защищаются

• Подсистема guardrails для автономного LLM-агента в CI/CD-конвейере.
  Актуальность: режим auto у Claude Code показывает, что индустрия двигается к меньшему числу подтверждений — а значит, нужен формальный слой политик.
  Цель: разработать компонент авторизации действий агента с настраиваемыми правилами риска.
  Задачи: классифицировать инструменты по уровню риска; спроектировать policy engine; реализовать аудит-лог; провести нагрузочный эксперимент.
  Структура: Гл.1 — анализ агентных инструментов и моделей угроз; Гл.2 — проектирование и реализация; Гл.3 — эксперименты и оценка.
• Оценка влияния степени автономности на производительность и риск LLM-агента.
  Актуальность: Anthropic прямо артикулирует trade-off скорость/безопасность — это гипотеза, которую можно проверить количественно.
  Цель: построить методику сравнения режимов manual / semi-auto / auto.
  Задачи: определить метрики; собрать датасет траекторий; реализовать харнесс прогонов; статистически обработать результаты.
  Структура: Гл.1 — теория агентных архитектур; Гл.2 — стенд и инструментарий измерений; Гл.3 — результаты и интерпретация.
• Human-in-the-loop подтверждения в агентных инструментах разработки.
  Актуальность: «поводок» из заголовка статьи — это ровно про проектирование точек эскалации к человеку.
  Цель: оптимизировать баланс между числом запросов подтверждения и числом пропущенных инцидентов.
  Задачи: описать модель пользовательского внимания; предложить эвристику эскалации; реализовать прототип; замерить Human Intervention Rate.
  Структура: Гл.1 — обзор подходов; Гл.2 — алгоритм и прототип; Гл.3 — оценка на сценариях.
• Трассировка и аудит действий LLM-агента средствами OpenTelemetry.
  Актуальность: без воспроизводимого журнала действий ни один автономный режим не пройдёт приёмку в корпоративной среде.
  Цель: спроектировать схему телеметрии агентной сессии.
  Задачи: определить span-модель; реализовать инструментацию; визуализировать трассы; показать разбор инцидента.
  Структура: Гл.1 — observability и стандарты; Гл.2 — реализация экспортёра; Гл.3 — сценарий расследования.

Куда встроить кейс статьи в главы ВКР

Глава 1: анализ тренда без «воды»

Не пересказывайте новость — стройте сопоставительную рамку. Введите две оси: степень автономности и объём требуемых гарантий. Сравните режимы работы агента по числу подтверждений, типу разрешённых инструментов и наличию песочницы. Увяжите это с ISO/IEC 25010 (функциональная пригодность, безопасность, удобство использования) — так вы покажете, что оцениваете систему по стандарту, а не по ощущениям.

Глава 2: архитектура и код

Основной артефакт главы — C4-диаграмма контейнеров: планировщик, исполнитель инструментов, policy engine, песочница, журнал аудита. Отдельно опишите контракт между исполнителем и policy engine: он должен быть синхронным и дешёвым, иначе автономность теряет смысл. Ниже — рабочий псевдокод решения, который можно адаптировать под конкретный стек.

ALLOWLIST = {"read_file", "run_tests", "git_status", "apply_patch"}
ESCALATE_THRESHOLD = 0.65

def authorize(action, ctx):
    # 1. Жёсткие запреты — вне обсуждения
    if action.tool in DENY_TOOLS:
        return Decision.DENY, "hard_denied"

    # 2. Инъекция промпта в контенте — эскалация к человеку
    if ctx.contains_untrusted_instruction(action.payload):
        return Decision.ESCALATE, "possible_prompt_injection"

    # 3. Выход за пределы рабочей области
    if not ctx.in_workspace(action.path):
        return Decision.DENY, "path_outside_sandbox"

    # 4. Оценка риска по контексту
    score = ctx.risk_score(action)   # изменяет ли prod, сеть, секреты
    if score >= ESCALATE_THRESHOLD:
        return Decision.ESCALATE, f"risk={score:.2f}"

    return Decision.ALLOW, "auto_mode_ok"

Рядом дайте конфигурацию автономности в YAML — это удобно защищать, потому что видно параметризацию политики:

autonomy:
  mode: auto
  max_actions_per_task: 25
  escalate_on:
    - tool: shell
      pattern: "rm -rf|git push --force"
    - risk_score: ">= 0.65"
  sandbox:
    root: "./workspace"
    network: false
  audit:
    exporter: otlp
    endpoint: "http://collector:4317"

Глава 3: метрики, которые считаются из журнала

Комиссия любит числа, которые можно перепроверить. Возьмите четыре:

• Autonomy Success Rate (ASR) = задачи, завершённые без вмешательства человека / все задачи. Отражает выгоду от режима auto.
• Human Intervention Rate (HIR) = число эскалаций / число действий. Показывает цену контроля.
• Unsafe Action Rate (UAR) = небезопасные действия, прошедшие политику / все действия × 100%. Целевое значение — ноль, но измеряйте честно.
• Cost per Task = токены + время CPU песочницы + время ревью.

Эксперимент строится на 40–60 задачах, по три прогона на режим. Разницу между режимами проверяйте не «на глаз», а критерием Манна — Уитни: данных мало, распределения ненормальные, t-тест здесь неуместен. Это отдельный плюс на защите.

Нормоконтроль и оформление

Техническое задание — по ГОСТ 34.602, схемы алгоритмов и данных — по ГОСТ 19.701 (иначе классические «блок-схемы» завернут на кафедре). Листинги policy engine уносите в приложение, в текст — только ключевые фрагменты. Диаграмму классов делайте в UML, диаграмму развёртывания — в C4. Ссылку на первоисточник оформляйте как электронный ресурс с датой обращения.

Источник: Anthropic hands Claude Code more control, but keeps it on a leash (опубликовано 2026-03-24)