Агент ответил 100. В системе — 16 211

Мы спросили ИИ-агента, сколько записей в коллекции настоящей системы SAP. Он уверенно назвал число, ошибившись в 162 раза. Интересно не это, а то, что SAP при этом отработала правильно — и предупредила. Ниже прогон целиком и что из него следует.

Что именно сделали

Взяли живую ABAP-систему (наш триал BTP) и сервис /DMO/API_TRAVEL_U_V2 — это демо-модель полётов самой SAP, поэтому здесь нет ничьих данных и показывать можно свободно. В ней пять коллекций. Задавали агенту один и тот же вопрос — «сколько их в системе?» — по три раза на коллекцию, всего 45 вопросов.

Агент — обычный языковой ИИ с доступом к инструменту чтения. Куда идти, он не решает: адрес запроса, размер страницы и решение о втором запросе принимает код. Модель только выбирает коллекцию из готового списка и толкует ответ. Это и требование политики API SAP, и защита от возражения «вы подстроили»: подобрать вопрос под ответ здесь негде.

Меняли одну вещь — обёртку. Так мы называем код, который передаёт агенту то, что вернула SAP. Запрос к SAP во всех трёх случаях дословно один и тот же.

Результат

• 0 / 12прогонов с верным числом на усечённых коллекциях, обёртки 1 и 2
• 6 / 6прогонов с верным числом после починки обёртки
• 27 / 27верных ответов там, где данные помещались в одну страницу

Последняя цифра — контроль, и она важнее первых двух. Агент один и тот же во всех прогонах. Он прав ровно там, где ответ поместился в страницу, и неправ ровно там, где не поместился. Списать это на «плохой агент» не выйдет.

Как это выглядит дословно

Обёртка flattening, первый прогон. Ни оговорки, ни сомнения — вместо них таблица, «подтверждающая» сотню:

There are 100 booking supplements in the system. […] | Total | 100 |

Прогон 12 августа 2026, коллекция BookingSupplement, в системе 16 211 записей

Та же система, тот же вопрос, та же модель — но обёртка passthrough, которая доносит до агента метку SAP «есть ещё»:

I can’t give you an exact total […] the response includes a “next page” link ($skiptoken=100), which means there are more than 100 records. The tool available to me reads only the first page.

Тот же прогон, обёртка passthrough

И обёртка honest, которая отдельным запросом спрашивает у SAP итог:

There are 16,211 booking supplements in the system. (Note: the query returned only the first 100 records as a page, but the system reports a total of 16,211 records overall.)

Тот же прогон, обёртка honest

Главное: SAP здесь ни при чём

В ответе SAP была метка __next — платформа честно сообщила, что данные не кончились. Она отработала ровно так, как обязана.

Первая обёртка эту метку выбросила: __next лежит на уровне конверта, а обёртка достала из конверта только массив записей. Агент физически не мог узнать о неполноте — и ответил тем, что ему дали.

Заметьте вторую строку: аккуратная обёртка не ошибается — но и ответить не может. Чтобы получить верное число, инструмент должен отдельно спросить у SAP итог. Это один дешёвый запрос, не 163 страницы.

Что это значит для заказчика

Починка одной коллекции — работа на полчаса. Вопрос в другом: каких именно коллекций это касается у конкретного заказчика.

Михаил Хасирджев верно заметил, что OData-сервисы надо открывать по отдельности — в облачной S/4 это делается коммуникационными договорённостями. Значит набор открытых сервисов конечен и известен — и по каждому можно заранее сказать, попадёт ли на нём агент в эту ловушку. Снаружи, на чтении, без доступа к бизнес-логике.

Он же добавил уточнение, которое сокращает работу ещё сильнее: рамку задаёт не система, а задача агента. Агенту по логистике не нужны сервисы кадров. Проверять надо не весь открытый каталог, а то подмножество, которое агент реально трогает, — а это единицы сервисов, а не сотни.

Продаём мы не починку. Продаём ответ на вопрос «где ваш агент будет уверенно неправ» — до того, как его запустили. Рамка при этом задаётся не системой целиком, а областью работы конкретного агента: у такой проверки есть и понятный повод (агент выходит в работу), и понятный владелец.

Чего этот прогон не доказывает

Побочная находка

Итоги в системе изменились за четыре дня: Booking 9 253 → 9 161, BookingSupplement 16 210 → 16 211. Триал общий, и чужие пользователи правят данные.

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

Что дальше — и на что мы пока не тратим денег

Напрашивающийся шаг — взять S/4HANA за €450 в месяц и пересобрать этот прогон на объектах SD и MM, которые вы узнаете с первого взгляда. Мы этого пока не делаем, и вот почему.

Аренда системы купит нам реализм. Чего она не купит — ответа на единственный оставшийся вопрос. Технически всё показано выше: признак есть, он виден снаружи, только на чтении, без прав от SAP. Открытый вопрос теперь не технический, а коммерческий: заплатит ли кто-нибудь за такой отчёт. Более красивое демо на знакомых объектах на этот вопрос не отвечает — оно отвечает на вопрос, который мы уже закрыли.

Три вопроса к вам

Вы оба стоите ближе к заказчикам, чем я, поэтому прошу не оценки демо, а фактуры из вашей практики:

И одна просьба

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

Систему за €450 берём, когда появится конкретный разговор, для которого нужны собственные модули собеседника. Тогда это расход на сделку, а не на исследование. Помесячно, отменяется в любой момент — торопиться некуда.