Лучшие промышленные практики построения AI-агентов, 4 из 10
Выжимка из книги Ли Боцзе «Глубокое понимание AI Agent: принципы проектирования и инженерная практика» (Pine AI, v2.0, 2026).
4. Инструменты
5 категорий, разные по риску: - восприятие (read) - выполнение (exec) - сотрудничество - срабатывание события (hook) - коммуникация с пользователем (question).
По умолчанию — универсальный инструмент (LLM пишет код/скрипты), специализированный — только при: - безопасность/права/аудит, - сложные параметры, - очень высокая частота, - различия платформ. Skill vs инструмент — по тем же факторам + частоте изменений + силе модели.
Объединяй похожие функции параметром. Описание = «когда использовать» + явные границы — большинство ошибок от незнания ограничений, не возможностей. 1-5 примеров вызова поднимают точность сильнее JSON Schema. Чинить описание обычно эффективнее смены модели.
Никогда не делай тихую нормализацию параметров — создаёт недиагностируемое расхождение модель/реальность. Код как оркестратор нескольких вызовов — экономит на порядки токенов vs прогон через контекст.
MCP/Skill Hub: description — недоверенный ввод (отравление описания), фикс версий серверов, минимальные credentials, риск tool shadowing.
100 инструментов — иерархия по источнику + семантический предотбор (49%→74%). Агент декларирует потребность на естественном языке, подгрузка динамически; схема дописывается в конец контекста. Skills — самый лёгкий путь к прогрессивному раскрытию.
Восприятие: контекстное сжатие вывода на уровне инструмента; поиск — структурированный список с пагинацией; чтение — offset/limit с явным усечением; read-only — кэшируй и параллель без опаски; мультимодальность — текст (дёшево) vs нативное изображение (важна разметка/пространство).
Выполнение (высокая цена ошибки): валидация без умной коррекции → контроль доступа с семантическим разбором команд → проверка необратимых (Proposer-Reviewer разных семейств или смена модальности). Sidecar — лёгкая модель видит ТОЛЬКО структурные поля (риск инъекции через текст). Автопроверка сразу (linter после записи). Изоляция: процесс < контейнер < microVM. Идемпотентность для повторяемых операций. Наблюдаемость: логи, аудит, метрики.
Сотрудничество: маркируй источники в промпте суб-агента ([FROM_MAIN]/[FROM_USER]/[TOOL_RESULT]); стандартизируй формат вывода; примитивы spawn/cancel/send_message/list_agents; HITL — таймаут + консервативный дефолт, решения человека обобщай по случаям, не сразу в правило.
Продолжение следует...
· 6 ч
На мой взгляд, Ли Боцзе очень точно разложил категории рисков, поскольку в промышленной эксплуатации ИИ-агентов ключевым вызовом для менеджмента становится именно контроль ограничений обвязки.
В блоке восприятия критически важен прагматичный подход к контекстному сжатию и лимитам чтения, ведь без явного усечения и кэширования стоимость токенов быстро перекроет всю экономическую выгоду от автоматизации процессов.
Для минимизации рисков на этапе выполнения связка независимых моделей Proposer-Reviewer из разных семейств совместно с автопроверкой линтерами является единственным надежным способом избежать накопления скрытых дефектов в коде.
Наконец, в контуре сотрудничества суб-агентов ключевой задачей остается обязательное внедрение принципа контроля человеком на критических участках и маркировка источников данных в промптах.
Без выстраивания такой сквозной наблюдаемости и жесткой изоляции процессов в контейнерах любая масштабная промышленная разработка неизбежно приводит к хаосу на производстве.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 5 ч
Для сжатия контекста на уровне инструментов есть проект rtk, он позволяет писать кастомные парсеры. Точки контроля нужны ровно так же как вывод промежуточных результатов в любом программном коде - в рамках дебага. Агентность предполагает автономное исполнение.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён