Кратко

  • pai-auth-ws-client 1.6.0 добавляет вызов определения конфигурации для сценария ИИ и отдельный вызов чата; оба типа результата содержат провайдера и модель.
  • В публичных Java-классах нет общей метки разрешения или версии конфигурации, поэтому увиденное перед чатом состояние нельзя однозначно связать с полученным текстом.

Новую реализацию прежде всего стоит оценить по её сильным сторонам. README тега 1.6.0 требует Bearer-токен PAI с ролью portal-ai-gateway, а IP вызывающей стороны должен входить в AI_LLM_WS_IP_WHITELIST. Клиент использует стандартную проверку TLS и имени узла, кодирует use как один сегмент пути, отводит пять секунд на соединение и 90 секунд на ответ. Истечение времени превращается в gateway_timeout со статусом 504. Результат чата содержит сценарий, провайдера, модель и задержку. Это не бесконтрольная обёртка над генератором текста.

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

Граница заметна в другом: библиотека делает два момента самостоятельными. resolve(token, use) запрашивает конфигурацию для указанного сценария. chat(token, use, messages) заново передаёт сценарий и сообщения. В README прямо сказано, что значение use задаёт вызывающее приложение, а клиент лишь пересылает его шлюзу.

Класс AiResolveData хранит сценарий, провайдера, ID и подпись модели, признак включения, тайм-аут и имя учётной записи, а также результат, HTTP-статус и ошибку. AiChatData возвращает текст, сценарий, провайдера, модель и задержку. Сохранённый ответ, таким образом, несёт важную описательную информацию о своём происхождении.

Но у самой операции разрешения нет сохраняемой личности. В двух классах отсутствуют resolutionId, configurationId, версия конфигурации, общий ID запроса, трассы или корреляции. Метод чата не принимает объект первого ответа или созданный им непрозрачный билет. Он повторно отправляет use и массив сообщений.

Совпадение провайдера и модели полезно, но не тождественно совпадению состояния. Сам DTO разрешения показывает, что конфигурация шире названия модели: у неё есть включение, лимит времени и ссылка на учётные данные. Две редакции могут выбрать одного провайдера и одну модель, изменив иное правило. Привязка use может обновиться между запросами. Источники не утверждают, что это произошло. Они лишь показывают, что при таком изменении одинаковые строки не укажут, какая редакция реально исполнялась.

Допустим, приложение в 09:00 проверило сценарий и увидело провайдера A, модель B и лимит 60 секунд. В 09:01 чат вернул A и B. Это весомое совпадение атрибутов. Однако если редакция 17 была заменена редакцией 18 с теми же A и B, публичный клиент не отличит их. У приложения останутся два согласующихся описания, но не единая квитанция.

Это не обвинение в состоянии гонки или уязвимости. Шлюз может атомарно разрешать и выполнять запрос внутри чата и сохранять безупречную внутреннюю трассу. Приложение может проставлять собственный ID. Закрытая документация может гарантировать больше. Правильный вывод двусторонний: невидимое нельзя объявлять отсутствующим, но его нельзя и подставлять вместо проверяемого публичного контракта.

Вопрос возник не из-за старого заброшенного кода. GitHub датирует релиз 1.6.0 12 сентября 2026 года. В описании сказано, что полный набор из 59 Maven-тестов прошёл на Java 17, а структурная проверка завершилась успешно. Сравнение с 1.5.1 показывает восемь новых коммитов; предпоследний добавляет ИИ-клиент, последний укрепляет вызовы. Сейчас как раз определяется публичная форма нового интерфейса.

Тесты PortalAiClient фиксируют Bearer-заголовок, разбор каталожной привязки, кодирование специальных знаков в use, сериализацию ролей, отказ при пустом сценарии, преобразование тайм-аута в 504 и делегирование через PortalWSClient. Это разумный набор интеграционных свойств. Сквозного теста идентичности разрешения нет, поскольку интерфейс не даёт значения, которое можно было бы провести через обе операции.

Минимальное дополнение — не раскрытие внутренностей, а непрозрачная квитанция. resolve мог бы возвращать resolutionId или версию конфигурации. В строгом режиме чат принимал бы её и явно отказывался от просроченного состояния. В гибком режиме шлюз мог бы сменить маршрут ради доступности, но возвращал бы ID фактически исполненной версии. Оба режима разумны, если приложение знает, какой из них выбрало.

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

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

Для LACNIC это также способ сузить ответственность. Без общей метки странный результат легко приписать скрытой смене маршрута даже тогда, когда ничего не менялось. Квитанция подтвердит непрерывность или покажет конкретное расхождение. Чем точнее доказательство, тем меньше места для общего подозрения.

Предыдущая публикация Theo March о том же репозитории касалась другой границы: README обещал Java 8, а свежая сборка и байткод требовали Java 17. Там проверялась возможность запустить клиент. Здесь она предполагается; проверяется возможность восстановить решение шлюза. Совпадает объект исследования, но не механизм статьи.

Источники