Agents / Context / Урок 02

Инструменты и разрешения

Описываем контракты инструментов и ограничиваем опасные действия.

Видео · 1:02Материалы · 13 минутРусскийОбновлён 02 августа 2026
Для кого
Разработчики агентов, которые читают данные, изменяют файлы или вызывают внешние API.
Перед началом
Рабочий agent loop и список потенциальных действий.
01:02 Озвучка · встроенный текст

Моё обучение

Прогресс и заметка

Войдите, чтобы сохранять прогресс, закладки и личные заметки.

Войти

Материалы / 13 минут

Спроектировать инструменты агента как строгие контракты с минимальными разрешениями и аудитом действий.

01

Инструмент должен быть узким

Вместо универсальной команды shell создайте действие с конкретной целью, типизированным входом и ограниченным выходом. Чем меньше пространство параметров, тем проще проверка.

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

02

Разрешение зависит от контекста

Policy проверяет пользователя, ресурс, среду и риск операции. Чтение, создание черновика и необратимое удаление не должны иметь одинаковый режим подтверждения.

Опасные действия проходят preview или dry-run, затем явное одобрение. Идентификатор одобрения связывается с точными параметрами.

  • Allowlist ресурсов и операций.
  • Ограничение размера, количества и времени.
  • Idempotency key для повторяемых запросов.
  • Полный audit event без секретов.
03

Результат тоже валидируется

Успешный HTTP-код не всегда означает выполненную задачу. Проверяйте ожидаемое изменение и возвращайте агенту нормализованный статус.

Prompt injection из документа или веб-страницы остаётся недоверенным входом и не может расширять разрешения инструмента.

Контракт безопасного действия json
{
  "tool": "create_support_draft",
  "input": { "ticket_id": "T-42", "body": "..." },
  "permissions": ["ticket:read", "draft:create"],
  "side_effect": "reversible",
  "requires_approval": false
}

Практика

Разделите один опасный инструмент

Возьмите широкое действие и превратите его в два-три узких контракта.

  1. 01

    Опишите входную схему и максимальные размеры.

  2. 02

    Добавьте allowlist ресурсов и отдельную policy-функцию.

  3. 03

    Создайте preview для необратимого действия.

  4. 04

    Запишите audit event и проверьте фактический результат.

Критерии готовности

  • Модель не может менять policy.
  • Опасные действия требуют связанного подтверждения.
  • Повтор запроса не создаёт двойной эффект.
  • Audit log позволяет восстановить ход операции.