Безопасный агент на Claude Agent SDK

Зачем нужен

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

Где применяется

• диагностика сервисов и инфраструктуры;
• исследование репозиториев и технической документации;
• подготовка runbook и плана устранения инцидента;
• автоматизация read-only операций с контролируемым набором tools.

Задача

Довести выданный lab-starter до полностью проходящих тестов.

Проверяемые сценарии

• агент запускается и отдаёт поток событий;
• PreToolUse запрещает деструктивную команду;
• read-only интеграция вызывает get_pod без изменения кластера;
• сбойный tool возвращает is_error и не уничтожает агентный цикл;
• полный цикл выполняет диагностику, проверяет гипотезу и формирует runbook.

Уровни сложности

• Minimum: read-only агент и блокировка деструктивных команд hook-ом.
• Medium: structured output через Pydantic и LiteLLM proxy.
• Hard: fallback chain моделей и учёт стоимости через proxy-логи (/spend/logs или аналогичный механизм).

Ожидаемый результат

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

Архитектура моего решения

Решение построено как управляемый agent loop вокруг локальной Ollama. Модель выбирает следующий tool, но не обращается к Kubernetes напрямую: каждый вызов проходит через ToolRegistry, валидацию аргументов и policy-проверку.

Как проходит запрос

1. Client передаёт задачу в Agent runtime.
2. Agent отправляет модели историю и JSON-схемы доступных tools.
3. Ollama предлагает tool call, но не исполняет его самостоятельно.
4. ToolRegistry проверяет имя, Pydantic-схему аргументов и уровень риска.
5. Разрешённый read-only tool получает данные из Minikube и возвращает наблюдение в agent loop.
6. Перед финальным ответом validate_diagnosis детерминированно подтверждает гипотезу.

Граница безопасности

• get_pod, get_pod_yaml и validate_diagnosis относятся к read-only tools.
• delete_pod объявлен destructive и блокируется до вызова handler.
• Прямой запрос на удаление завершается типизированным Refusal, а не Python traceback.
• Решение о доступе принимает обычный код в ToolRegistry, а не prompt и не LLM.

Сейчас практически подключён Kubernetes tool. RAG и notifications на схеме показывают следующие возможные интеграции: поиск runbook и отправку уведомлений через отдельные policy-controlled tools.