Вне зависимости от того, какую агентную систему вы строите, инструменты (tools) наверняка станут её важной частью. С их помощью
Claude (или другая LLM) может взаимодействовать с внешними сервисами и API, передавая при этом чётко заданную структуру и определения в рамках нашего API. Если Claude решит вызвать инструмент, он добавит
«tool use block» в ответе API. Стоит вложить столько же сил в продумывание инструментария, сколько в основные промпты. Ниже кратко описано, как к этому подойти.
Зачастую одно и то же действие можно реализовать по-разному. Например, редактирование файла можно описывать через формат diff или же предложить модели переписать весь файл целиком. Код может возвращаться внутри Markdown или внутри JSON. С точки зрения классического программирования это неважно — мы можем потом как угодно преобразовать результат. Но для LLM разница существенна. Например, делать diff сложнее, так как придётся указывать правильное число изменяемых строк перед самим кодом. А при написании кода внутри JSON нужны дополнительные экранирования.
Рекомендации:
1. Давайте модели достаточно «места на размышление» (токенов), чтобы она не «загоняла себя в угол».
2. Старайтесь использовать знакомые модели форматы, как в текстах из интернета.
3. Избегайте сложных «служебных» требований к формату (например, точного подсчёта строк в diff или экранирования каждого символа).
Подумайте о том, сколько усилий мы обычно вкладываем в создание удобных человеко-машинных интерфейсов (HCI). Стоит быть столь же внимательными при проектировании интерфейса «агент-компьютер» (ACI). Несколько идей:
• Представьте себя на месте модели. Ясно ли из описания, как использовать этот инструмент? Или нужно поломать голову? Если второе — модель тоже будет ошибаться. Хорошая спецификация содержит примеры, крайние случаи, информацию о форматах входа и чёткие различия от других инструментов.
• Переименуйте параметры и дополните описания так, чтобы всё было максимально очевидно. Представьте, что пишете docstring для младшего разработчика. Важно, когда много инструментов или они похожи.
• Обязательно тестируйте использование ваших инструментов. Гоняйте разные примеры, смотрите, какие ошибки модель делает, и дорабатывайте.
• Внедряйте
«poka-yoke» (защиту от дурака).Меняйте аргументы и формат так, чтобы модель сложнее делала ошибки.
Во время работы над нашим агентом для
SWE-bench мы больше всего времени потратили именно на тонкую настройку инструментов, а не на общий промпт. Например, мы столкнулись с ситуацией, когда модель делала ошибки, используя относительные пути после смены директории. Решение — запретить относительные пути и требовать абсолютные. Модель тут же перестала ошибаться.