В прошлом уроке инструменты были «руками» агента. Теперь — главный секрет, который меняет отношение к ним: для агента инструмент — это не код, а текст. Модель не «нажимает кнопки». Ей дают список инструментов с описаниями, она читает их и пишет в ответ: «вызываю search_orders с параметром email=такой-то». Платформа исполняет вызов настоящим кодом и возвращает результат — то самое «наблюдение» из цикла «цель → план → действие → наблюдение». Модель снова думает, снова выбирает. И так виток за витком.

Из этого следует вывод, который экономит недели: качество агента упирается в качество описаний. Писать описания инструментов — это промпт-инжиниринг, а не программирование. Именно поэтому ты можешь собирать сильных агентов без единой строчки кода.

Инструмент = описание

Вот полный шаблон описания — все пять полей:

Оцени это описание инструмента для ИИ-агента по трём критериям:
хватит ли его, чтобы агент понял КОГДА звать инструмент, ЧТО передать
и ЧТО получит назад. Укажи самое слабое поле и предложи улучшение.

Название: search_orders
Что делает: ищет заказы клиента по email или номеру.
Параметры: email (строка) ИЛИ order_id (число).
Возвращает: список заказов со статусами.
Когда использовать: клиент спрашивает о своём заказе.

Агент выбирает инструмент, сравнивая текущую подзадачу с полями «что делает» и «когда использовать». Размытое описание = неправильный выбор, и никакая сильная модель это не спасёт: она честно исполняет то, что написано. Три правила хорошего описания: глагол в названии (search_orders, а не orders), точное «когда использовать», пример вызова для сложных инструментов.

Почему два инструмента с похожими описаниями хуже, чем один инструмент? Подумай с позиции модели, которая видит только текст описаний.

Чтение vs действие

Все инструменты делятся на два сорта, и граница между ними — граница риска:

Чтение (поиск, просмотр заказа, чтение файла) — безопасно. Худшее, что случится, — бесполезный ответ. Ошибку ты просто выбросишь.
Действие (отправить, записать, оформить, удалить) — меняет мир. Отправленное письмо не вернёшь, оформленный возврат — тоже.

Отсюда правило безопасного старта: сначала только чтение. Запусти агента с читающими инструментами, посмотри на его решения, и лишь когда они стабильно разумны — выдавай действия. А действиям вшивай ограничители прямо в описание: «refund_order: оформляет возврат ДО 50 €. Суммы больше — эскалация человеку». Граница, записанная в описании инструмента, работает надёжнее, чем надежда на здравый смысл модели.

Типичные ошибки описаний

Два похожих инструмента. check_delivery («проверяет доставку») и track_package («отслеживает посылку») — для модели это почти один текст, выбор превращается в монетку. Объедини их или разведи формулировки: «сроки и стоимость доставки ДО заказа» против «где сейчас посылка ПО номеру заказа».
Описание «на программистском». «Выполняет GET-запрос к эндпоинту /orders» — модель поймёт, но выбирать будет хуже, чем по фразе «ищет заказы клиента». Пиши человеческим языком: описание читает языковая модель, а не компилятор.
Нет «когда НЕ использовать» у опасных. Для действий отрицательное правило важнее положительного: «не вызывай для сумм больше лимита», «не вызывай, если клиент не подтвердил». Модель, не знающая границы, границу не увидит.

Честно про пределы

Идеальные описания не делают агента безошибочным. Модель может позвать правильный инструмент с неправильными параметрами, неверно понять результат, застрять в цикле «поискал — не нашёл — поискал так же». Помнишь перемножение ошибок из прошлого урока? Хорошие описания поднимают верность каждого отдельного выбора — но не до ста процентов. Поэтому предохранители из анатомии никуда не деваются: описания снижают число ошибок, лимиты ограничивают цену каждой.

Проверь в песочнице

Пара «до/после» — почувствуй, как описания управляют выбором:

Ты — агент поддержки магазина. У тебя два инструмента:
(вариант ДО) tool_a: «работает с доставкой», tool_b: «информация о посылках».
Вот 5 запросов клиентов: «сколько идёт доставка в Берлин?», «где мой
заказ 4412?», «посылка не пришла, что делать?», «доставляете ли в
субботу?», «какой трек-номер у заказа 8103?».
Для каждого запроса скажи, какой инструмент вызовешь и почему.
Затем повтори то же с описаниями ПОСЛЕ: tool_a: «сроки и стоимость
доставки ДО оформления заказа», tool_b: «где сейчас посылка — по номеру
уже оформленного заказа». Сравни: в каком случае выбор увереннее?

Ревизия опасного инструмента:

Ты ревизор инструментов ИИ-агента. Вот описание:
«Название: refund_order. Что делает: возвращает деньги клиенту.
Параметры: order_id». Найди всё, чего не хватает, по чек-листу:
глагол в названии? точное «когда использовать»? «когда НЕ
использовать»? граница суммы? что возвращает? Перепиши описание
так, чтобы агент не мог оформить возврат на 5000 € без человека.

Сделай сейчас

Опиши по шаблону из этого урока три инструмента для агента поддержки интернет-магазина: посмотреть заказ (чтение), проверить статус доставки (чтение), оформить возврат до лимита (действие с границей). Потом вставь свои описания во второй промпт песочницы вместо refund_order — пусть ИИ-ревизор найдёт, что ты упустил.

Tools: how an agent acts in the world