Результат инструмента и ответ агента: как не перепутать статусы
Фраза агента «заявка создана» не доказывает запись в системе. Источником подтверждения должен быть результат инструмента с явным статусом и идентификатором объекта. Текстовый ответ помогает человеку понять результат, но не заменяет техническую проверку.
Разберите ложный успех
Учебный инструмент создания заявки вернул {"ok":false,"error":"service_unavailable"}. Агент продолжил разговор и по привычному шаблону написал, что заявка создана. Если интерфейс считает успехом наличие слова «создана», отчёт о конверсии тоже окажется неверным.
Задайте контракт: успех записи содержит стабильный ID и статус, ошибка содержит безопасный код и допустимый следующий шаг. Не прячьте ошибку в обычный текст, который по форме похож на удачный результат.
| Сигнал | Что он подтверждает |
|---|---|
| Модель предложила вызов | Только намерение вызвать инструмент |
| Инструмент получил команду | Начало обработки |
| Сервис вернул подтверждённый ID | Результат согласно контракту сервиса |
| Агент пересказал результат | Коммуникацию с пользователем |
Откуда строить интерфейс и метрики
Состояние карточки операции формируйте из проверенного backend-результата. Пояснение модели можно показать рядом, но оно не должно менять статус. Если операция ещё выполняется, обозначьте ожидание. Если результат неизвестен после обрыва, предусмотрите восстановление по ID операции.
Успех пользовательской задачи может быть шире успеха одного инструмента. Создать пустую заявку технически возможно, но задача не решена, если обязательные поля неверны. Для такой оценки нужна отдельная проверка полноты результата.
Тест без реального сервиса
Используйте заглушки с тремя ответами: успешный ID, явная ошибка и неопределённый результат после таймаута. Проверьте, что интерфейс показывает разные состояния и не сообщает о завершённой записи в последних двух случаях.
Затем намеренно дайте модели неудачное словесное объяснение успешного результата. Backend-статус должен остаться корректным, а проблема коммуникации фиксироваться отдельно. Это помогает понять, что нужно исправлять: интеграцию, правила ответа или интерфейс.
LangChain описывает передачу результатов инструментов обратно в диалог. Их бизнес-семантику определяет ваш контракт. Уточняйте, какие поля считаются доказательством выполнения и что делать при частичном успехе.
Этот разбор подготовлен Latorn. Если вы уже знаете основы Python и API и хотите практиковать такие решения системно, сравните программу платного курса LangChain 1.0.x со своей задачей. Открытый пример выше можно проверить самостоятельно; он не заменяет полный проект.
Технические источники: LangChain tools. Учебные ситуации и числа в статье придуманы для объяснения механизма.
Следующий шаг: LangChain: практические разборы формата, памяти и потоков. По смежным вопросам: Отсутствующее поле и null в ответе LLM: как не стереть данные, Обрезка истории LangChain: как сохранить договорённости.
