Отсутствующий инженерный уровень между вызовом инструментов и готовыми к использованию ИИ-агентами. Вот сценарий, который должен обеспокоить любого, кто занимается созданием агентов ИИ. Вы предоставляете агенту доступ к CRM, почтовому сервису и внутренней базе данных. Агент может повторно...
Отсутствующий инженерный уровень между вызовом инструментов и готовыми к использованию ИИ-агентами.
Вот сценарий, который должен обеспокоить любого, кто занимается созданием агентов ИИ.
Вы предоставляете агенту доступ к CRM, почтовому сервису и внутренней базе данных.
Агент может получать данные о клиентах, обновлять записи и отправлять электронные письма.
Система работает прекрасно.
Затем агент решает отправить отчет о клиенте не тому получателю.
API электронной почты возвращает 200 ОК.
Ваша система журналирования фиксирует успешное действие.
Обновления панели мониторинга.
Технически все работало.
За исключением того, что агент просто поделился информацией, которой у него не должно было быть.
Вот почему управление агентами не может полагаться только на наблюдение за исполнением.
Разница между доступом к инструменту и разрешением действовать
Когда разработчики создают агентов ИИ с поддержкой инструментов, архитектура часто выглядит примерно так:
Запрос пользователя → Обоснование LLM → Выбор инструмента → Выполнение API → Ответ
Этот подход полезен для прототипов.
Но возникает серьезный вопрос:
Кто определяет, разрешен ли предлагаемый вызов инструмента?
Агент?
Система подскажет?
Разрешения API приложения?
Подсказка может сказать агенту не выполнять определенные операции, но естественным образом