Как превратить ИИ-помощника в инструмент, которым сможет пользоваться команда

Пока помощника запускает один человек, многое держится у него в голове: какой запрос сработал, какие файлы выбрать и когда перепроверить результат. Командному инструменту нужен другой уровень определённости. Он должен понятно запускаться, выполнять ограниченную работу и оставлять след, по которому можно разобрать ошибку.

20 октября Cursor представил Agent SDK — набор средств для создания, проверки и запуска таких помощников. Вместо отдельного диалога получается проект, который можно подключить к рабочим событиям: например, появлению задачи или сообщению в Slack.

Представим небольшую продуктовую команду. В неё приходят сообщения об ошибках: у кого-то не сохраняется форма, у кого-то не открывается страница. Сейчас разработчик читает сообщения вручную, уточняет подробности и выбирает, куда передать задачу.

Для первой версии ИИ-помощника можно ограничиться подготовкой: собрать описание, отметить недостающие сведения и предложить ответственное направление. Самостоятельно исправлять код, назначать приоритет и закрывать обращения он пока не будет.

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

В проекте отдельно задают инструкции, доступные действия и каналы сообщений. Работу можно проверить локально, а затем развернуть. Для обсуждения в задаче или треде сохраняется сессия: следующий вопрос продолжает тот же разговор.

Проверки в SDK могут следить не только за текстом ответа, но и за тем, какие операции помощник вызвал и с какими данными. Это позволяет заметить, например, что вместо подготовки предложения он уже изменил задачу.

Для нашей команды это означает, что новое сообщение запускает разбор, а уточнение к существующему обращению продолжает его. Сотруднику не нужно заново копировать переписку в личный чат с моделью.

Но SDK не выбирает за команду ни полезную функцию, ни допустимые действия. Это средство реализации. Если поручить помощнику неопределённое «разбирай все проблемы», неопределённость не исчезнет от появления папки проекта.

Для сообщения об ошибке можно задать небольшой состав результата: что пытался сделать пользователь, что произошло, каких сведений не хватает и кому предложено передать вопрос.

Например, фраза «ничего не работает» должна приводить к запросу уточнений, а не к уверенно назначенной задаче серверной команде. Сообщение «кнопка сохранения в профиле не реагирует после изменения телефона» уже позволяет подготовить более содержательную карточку.

Это разные случаи, и их стоит сохранить как отдельные пробные задания. Важно проверять не только текст ответа, но и действия: не создал ли помощник повторную задачу, не назначил ли исполнителя без разрешения, не отправил ли личные данные в общий канал.

Поэтому пробные задания стоит сформулировать через наблюдаемые действия: карточка подготовлена, лишних изменений нет, недостающие сведения запрошены. Так возможности SDK связываются с задачей команды.

Сервис может повторно доставить сообщение, сотрудник — нажать кнопку ещё раз, а сеть — оборваться после создания карточки. Для командного инструмента это обычные условия работы.

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

Нужен и журнал: входящее событие, выполненные операции, итог. Тогда на вопрос сотрудника «куда пропала моя задача?» можно ответить по записи, а не запускать помощника ещё раз наугад.

Сохранённые примеры обращений пригодятся и при выборе модели. Их можно использовать для отдельного сравнения API-моделей из provod.ai. Возможность подключить выбранную модель именно к этому проекту на Agent SDK нужно проверить отдельно.

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

Для нашего разбора входящих ошибок достаточно начать с ясных ответов:

Переход от личного помощника к командному начинается с этих договорённостей. Удачный запрос помогает один раз получить хороший ответ. Работающий инструмент должен предсказуемо обрабатывать и следующий запрос — в том числе неудачный.