Цикл агента AI SDK: докажите, почему он остановился

Цикл агента AI SDK нельзя считать исправным лишь потому, что он завершился. Возврат доказывает, что один путь потока управления завершился: модель завершилась без вызова другого инструмента, инструмент не смог выполниться, потребовалось одобрение или сработало настроенное условие остановки. Ни один из этих фактов не доказывает, что счет был создан, билет был обновлен или отчет достиг места назначения. Практическое значение по умолчанию — сохранить ограниченный цикл SDK, записать одну явную причину остановки и отдельно проверить предполагаемый внешний результат. Рассматривайте запрос на утверждение как ожидание, ограничение шага или бюджета как ограниченную остановку, а естественное завершение без получения результата как ложное завершение. В этом руководстве поведение привязано к выпущенному пакету [email protected] и Node.js 22.23.1. Сопровождающий повтор без содержания выполнял фактически экспортированные функции условия остановки в одиннадцати рабочих случаях. Все одиннадцать классификаций и четыре прямых утверждения SDK прошли успешно. SDK может остановиться по нескольким законным причинам. AI SDK Руководство по управлению контуром называет четыре маршрута завершения: 1. модель возвращает причину завершения, отличную от tool calls ; 2. вызываемый инструмент не имеет функции execute ; 3. вызов инструмента требует одобрения; 4. настроенное условие остановки возвращает true. Эти маршруты не должны сводиться в одно поле completed: true . Они подразумевают разные действия оператора. Естественная обработка без использования инструментов может быть вполне подходящей для исследовательского ответа, но неполной для рабочего процесса, контракт которого требует наличия файла в объектном хранилище. Инструмент без execute может намеренно действовать как структурированный сигнал done , но сигнал содержит то, что утверждает модель, а не независимое свидетельство того, что побочный эффект оказался успешным. Запрос на одобрение — это намеренная пауза. Ограничение шага означает, что граница безопасности сработала, а не означает, что задача не выполнена или выполнена успешно. В текущей документации указано, что ToolLoopAgent по умолчанию равен isStepCount(20) . Замена его на isLoopFinished() устраняет условие остановки подсчета шагов. Это может быть разумно для жестко контролируемого локального эксперимента, но это также устраняет простое ограничение на вызовы моделей и стоимость. Если приложение не может объяснить свои независимые элементы управления сроком, бюджетом и отменой, сохранение ограничения по умолчанию является более безопасным решением. Три небольшие детали реализации меняют диагноз Версия закреплена источник условия остановки достаточно короток для прямого аудита: isStepCount(n) истинно, когда steps.length === n , а не когда счетчик больше или равен n . hasToolCall(name) проверяет вызовы инструментов на последнем завершенном этапе. isLoopFinished() всегда возвращает false в качестве условия остановки, оставляя естественное завершение, невыполненный инструмент или подтверждение завершения цикла. Эта семантика имеет значение при реконструкции инцидента. Предположим, что приложение сохраняет только окончательный текст и общее количество шагов. Трехшаговый запуск, вызвавший done на втором шаге, не может позже доказать, что hasToolCall("done") вызвал завершение, поскольку соответствующее условие проверяет последний шаг. Аналогично, наблюдение за 21 шагом не показывает, что isStepCount(20) сработал; это свидетельствует о том, что настроенная политика, зарегистрированное количество или граница выполнения отличаются от предположения. Сохраните входные данные условия и выбранную версию политики при выполнении. Не делайте выводов из информационной панели постфактум. Создайте стоп квитанцию, прежде чем выбирать состояние работоспособности Полезный прием небольшой. Ему не нужны подсказки, ответы модели или необработанные полезные данные инструмента: stopCause должен исходить из границы интеграции, а не из догадок, основанных на окончательном варианте. Запишите, достиг ли прогон завершения без использования инструмента, соответствовал ли именованному условию остановки, был ли отправлен запрос на утверждение, вызван ли невыполненный инструмент завершения, был ли прерван, истекло время ожидания или произошел ли сбой при выполнении инструмента. Затем примените правило приоритета: Доказательство Состояние Решение оператора Не удалось выполнить инструмент FAILED Диагностика границы инструмента; не повторяйте вслепую неопределенный побочный эффект. Ожидается утверждение с указанием владельца, срока и токена резюме. WAITING Маршрутизируйте решение и сохраните возможность возобновления. Ожидается одобрение без данных маршрутизации WAITING UNROUTED Добавьте владельца и путь эскалации, прежде чем ожидание станет невидимым. Тайм аут истек без полезного прогресса STUCK Проверьте последний устойчивый прогресс и выберите одно ограниченное восстановление. Сработала привязка шага, токена или прерывания пользователя BOUNDED STOP Сохранить частичную работу; решить, оправдан ли новый ограниченный пробег. Натуральная отделка или явный done плюс получение результата VERIFIED COMPLETE Закрыть пробег. Натуральная отделка или явный done без получения результата FALSE COMPLETE Проверьте место назначения или повторно откройте задачу. Сигналы не совпадают или причина не зафиксирована UNCERTAIN Спросите, прежде чем действовать. Порядок имеет значение. Тайм аут на четвертом шаге по прежнему остается тайм аутом, даже если количество шагов равно четырем. Запрос на утверждение должен оставаться в ожидании, а не переводиться в общее незавершенное состояние. Естественное завершение без какого либо результата должно оставаться ложно завершенным, даже если его текст звучит уверенно. Воспроизведение политики без вызова модели В ходе аудита были импортированы выпущенные функции isStepCount , hasToolCall и isLoopFinished . Он передавал бессодержательные массивы завершенных записей шагов и присоединял их вывод к классификатору квитанций. Никакого вызова модели, подсказки, секрета или воздействия внешнего инструмента не требовалось. Четыре утверждения устанавливают границу SDK: Затем приспособление из одиннадцати корпусов охватывало естественную отделку с результатом и без него, done с результатом и без него, ограничение шага, бюджет токена, маршрутизированное и немаршрутизированное одобрение, ошибку инструмента, тайм аут и пользовательское прерывание. Показательные пары не были экзотическими неудачами. Оба светильника с натуральной отделкой имели одинаковые причины управления потоком; только тот, у которого была квитанция о назначении, стал VERIFIED COMPLETE . Такое же разделение произошло и для инструмента done . Это основной фальсифицируемый результат: если бы завершение цикла само по себе оказалось полезным завершением, эти парные приборы должны были бы получить один и тот же верный вердикт. Они этого не сделали. Проверьте пункт назначения после остановки потока управления. Справочник по ToolLoopAgent отображает завершенные шаги в сгенерированном результате и принимает abortSignal и элементы управления тайм аутом. Эти поля являются полезным свидетельством, но приложению по прежнему принадлежит определение успеха. Выберите самую дешевую детерминированную проверку, отвечающую фактическому запросу пользователя: для файла проверьте ожидаемый путь или ключ объекта, тип контента, минимальный размер и хэш или схему для конкретной задачи; в случае мутации базы данных прочитайте запись назначения и сравните предполагаемые поля; для сообщения сохраните квитанцию ​​поставщика и идентификатор получателя; для развертывания проверьте неизменяемую версию, реакцию общественного здравоохранения и маршрут, ориентированный на пользователя; для анализа проверьте необходимые разделы, охват источника и машиночитаемый результат, прежде чем принимать прозу. Не делайте квитанцию ​​о результатах второй копией утверждения модели. {"status":"done"} , излучаемый тем же циклом, не является независимой проверкой. Квитанция должна исходить от пункта назначения, от детерминированного валидатора или от человеческого решения, если результат не может быть безопасно проверен с помощью кода. Одобрение также требует отдельной границы. В документации SDK показано, что запрос на утверждение можно собрать, добавить к диалогу в качестве ответа на утверждение и передать в последующий вызов. С функциональной точки зрения это означает, что ожидание должно сохранить достаточный контекст для возобновления того же решения. Владелец без токена резюме выполняет работы по реконструкции вручную; токен без владельца создает невидимую очередь. Чего этот повтор не доказывает В эксперименте не вызывалась модель поставщика, не осуществлялась потоковая передача частичного вывода и не выполнялся внешний инструмент. Поэтому он не устанавливает поведение причины завершения, зависящее от поставщика, время отмены сети или идемпотентность побочных эффектов. Они относятся к интеграционным тестам реальной модели, инструментов и назначения. Он также не рекомендует использовать один универсальный шаг или ограничение на токен. Четырехэтапный поиск и сорокашаговая миграция имеют разные конверты. Операционное требование состоит в том, чтобы выбранные границы были явными, записанными и привязанными к безопасным действиям при их достижении. Правило более узкое и долговечное: сохраняйте причину остановки цикла, отличайте законные ожидания от сбоев и требуйте доказательства назначения перед объявлением полезного завершения. Sidewisp — это платформа работоспособности агентов искусственного интеллекта, предназначенная для упрощения проверки доказательств, состояний ожидания, ограниченного восстановления и проверки результатов в существующих средах выполнения. Сбор данных о состоянии производственного агента и мониторинг AI SDK сегодня обычно не поставляются. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Если это уведомление о прекращении соответствует режиму сбоя в ваших собственных агентах, список ожидания частной предварительной версии является подходящим местом для обмена необходимой вам средой выполнения и границей доказательств.