Агентът каза, че всичко е готово. Базата данни не се съгласи.

Microsoft ThinkingBox оценява AI агентите по записите, които оставят след себе си, а не по изреченията, които генерират, и след това проверява дали могат да го направят двадесет пъти подред. Вече е достъпен чрез Hugging Face.

Фигура 1: ThinkingBox изпълнява агент в изолирани MCP инструментални сесии, след което оценява крайното състояние на терминалния бекенд и страничните ефекти, които агентът е оставил. От нашата статия за ThinkingBox.

Това е съвместна публикация на Microsoft и Hugging Face. Специални благодарности на Tommy Guy (основател на Enderis AI, преди това в Microsoft), Sergio Paniego от Hugging Face и бившите ни стажанти Zhuochun Li (University of Pittsburgh), Ali Keramati (UC Irvine), Youngmin Ko (Northwestern) за съавторството и рецензирането.

Клиентка пише до отдела за обслужване. Кухненският ѝ уред на стойност 745 долара е блокиран като „изключение“ в дистрибуционен център в Нешвил, петнадесет дни след очакваната дата за доставка.

AI агентът работи внимателно. Девет извиквания на инструменти: извлича поръчката, проверява проследяването, намира клиентския ѝ профил, два пъти търси политиката за възстановяване на суми, потвърждава, че няма съществуващ тикет, отваря такъв, документира хронологията и прочита правилно политиката; сегментът на профила ѝ действително не отговаря на условията за компенсация при закъсняла доставка.

След това затваря тикета като разрешен и отговаря: „ Тъй като запитването ви е разрешено, има ли нещо, с което мога да ви помогна? “

Има два проблема. Изключението при превозвача все още е отворено, така че изискваното крайно състояние е задържано до разрешаването му. А клиентката така и не е получила истински отговор на въпроса си.

Оценяващ AI, който проверява извикванията на инструментите, би видял девет добре оформени извиквания. Оценяващият, който проверява дали агентът е записал данни в базата, също би видял това. Но базата данни не е съгласна.

Именно тази разлика измерва ThinkingBox. В 507 работни процеса със състояние, като всяко изпълнение се повтаря 20 пъти с различни LLM модели, той оценява агентите по крайното състояние на бекенда и страничните ефекти. В тази публикация разглеждаме какво открихме, каква е цената на последователността и как сами да стартирате бенчмарка чрез OpenEnv.

Можете сами да стартирате този пример: примерът по-горе е адаптиран от задача в бенчмарка sandbox_external_retail_group1.py:test_case_ST003_006, а неуспешната изпълнима проверка е само едно поле: статусът на тикета е „решен“, докато изискваното крайно състояние е „задържан“. Пълната следа е в Приложение D.4, случай 3 от нашата статия.

Съдържание

1. Извикването на инструмент не е резултат
2. Един успех не е надеждност
3. Можете ли да разчитате на модела зад агента си?
4. Каква е цената на последователността
5. Сигнатури на неуспехите
6. Как работи
7. Стартирайте го сами
8. Какво следва

Искате да го изпробвате, преди да прочетете резултатите? Преминете към раздела „Стартирайте го сами“.

Извикването на инструмент не е резултат

Крайните отговори и валидните извиквания на инструменти са само косвени показатели. Агентът може да звучи правилно, но да остави грешна стойност, да промени грешен запис или да създаде допълнителен страничен ефект. Единствено записите, които оставя след себе си, дават окончателния отговор.

Разликата е значителна. В аблационно изследване върху общ набор, обхващащо 121 680 валидни изпитвания с 12 LLM модела, 79 853 опита не са преминали изпълнимите проверки. От тези неуспехи 67,24% все пак са приключили нормално, извикали са инструмент, променящ състоянието, и не са отчели крайна грешка на инструмент. Изпълнимите проверки въпреки това са открили грешни стойности на полета в 77,61% от тях, непреднамерени допълнителни ефекти в 43,30% и липсващи изисквани ефекти в 25,36%. Тези констатации за състоянието се припокриват.

Една траектория е твърдение. Състоянието на базата данни е доказателството. Повторението е тестът за доверие.

Един успех не е надеждност

Агент, който веднъж обработва правилно възстановяване на сума, а през следващите четири пъти допуска грешки, не е работещ агент за възстановяване на суми. Затова всяка задача се изпълнява 20 независими пъти, всеки път от еднакъв чист бекенд, и отчитаме три различни показателя:

Таблица 1: Трите числа, които отчитаме, и въпросът, на който отговаря всяко от тях.

В тази публикация използваме наблюдавано 20/20 като буквалния брой от 507 задачи, преминали 20 от 20 опита. Без оценител, без изглаждане.

Нека започнем с познатата гледна точка. Таблицата по-долу отчита pass@1 — оценката за резултата при един опит — по области. Това е числото, което публикуват повечето класации, и само по себе си изглежда като обикновено класиране на способностите.

Таблица 2: ThinkingBox-Bench pass@1 (%) по области. Всеки модел се оценява върху всяка задача в 20 повтарящи се изпитвания. Получерният шрифт обозначава лидера в групата, а подчертаването — втория. Стандартните грешки за оценките на резултата при един опит са дадени в Таблица 4 от нашата статия за ThinkingBox.

Модел	Търговия на дребно (98)	Автомобилно застраховане (100)	Пътувания (104)	Необанка (104)	Консултантски услуги (101)	Общо, претеглено по задачи (507)
Собствени модели
Claude Opus 5.5	80.97	68.40	54.28	71.25	61.58	67.16
Claude Opus 5	80.71	65.80	49.95	70.62	66.19	66.50
GPT-5.4	76.33	62.65	68.12	65.34	54.60	65.36
GPT-5.6 Sol	67.65	65.30	60.34	59.09	57.52	61.91
Claude Sonnet 4.6	72.35	54.40	58.94	56.39	54.31	59.19
GPT-6 Astra	71.73	46.55	55.87	60.87	56.83	58.31
GPT-5.2	70.20	22.40	53.70	51.15	34.06	46.28
Claude Opus 4.6	68.62	8.30	21.11	35.67	27.82	32.09
o3-pro	37.70	2.95	17.31	24.28	14.60	19.31
Grok-4.3	43.93	2.60	15.14	1.78	9.55	14.38
Модели с отворени тегла
Kimi-K3	82.24	50.80	61.83	41.35	51.63	57.37
Qwen3.8-27B	64.03	47.85	53.41	47.88	45.69	51.70
DeepSeek-V4-Pro	68.21	29.65	43.13	44.86	31.04	43.26
Kimi-K2.6	53.72	24.50	39.52	33.65	37.33	37.66
GLM-5.1	58.67	25.70	35.43	13.27	34.06	33.19
Qwen3.6-27B	43.11	29.00	46.39	27.84	18.37	32.94
Qwen3.5-9B	19.90	0.70	4.71	1.15	2.33	5.65
Mistral-Large-3	11.28	1.30	8.99	1.15	0.74	4.66

Claude Opus 5.5 води в общото класиране с 67,16% — с две трети от процентния пункт пред Claude Opus 5. Kimi-K3 е най-силният модел с отворени тегла, на по-малко от един пункт от GPT-6-Astra. Областта е също толкова важна: Claude Opus 4.6 постига 68,62% при търговията на дребно, но 8,30% при автомобилното застраховане.

Един добър опит показва, че моделът може да свърши работата. Не показва дали ще я свърши отново. Затова изпълнете всяка задача 20 пъти и проверете каква част от резултата се запазва.

Фигура 2: Каква част от резултата на всеки модел при един опит се запазва след 20 повторения.

Само три модела запазват по-голямата част от резултатите си при pass@1: GPT-6 Astra запазва 78% от честотата си при един опит, а Claude Opus 5.5 и Claude Opus 5 запазват по 71%. В другия край GLM-5.1, Kimi-K2.6 и DeepSeek-V4-Pro запазват приблизително 8%.

Разликата между това, което един модел може да направи веднъж, и това, което прави всеки път, е същината на историята.

Можете ли да разчитате на модела зад агента си?

Фигура 3: Обхватът и последователността се раздалечават. Показани са дванадесет от осемнадесетте модела; шестте с pass@1 под 33% са пропуснати за по-добра четливост.

Kimi-K3 има най-широкото покритие от всички тествани модели. Той решава 93,89% от бенчмарка поне веднъж: 476 от 507 задачи. Само 31 задачи го побеждават напълно — най-ниският брой в изследването. При работните процеси в търговията на дребно той безусловно води с 82,24% pass@1, пред всеки собствен модел.

Kimi-K3 е и сред най-малко последователните модели. Само 68 от 507 задачи, или 13,41%, са успешни във всичките 20 опита.

Claude Opus 5 показва обратната картина. Той решава по-малко задачи поне веднъж (79,09%; 106 го побеждават напълно), но завършва 47,53% от бенчмарка при всеки един опит.

По-новият модел не решава този проблем. Claude Opus 5.5 постига по-висока средна стойност при всеки опит от Claude Opus 5 — 67,16% срещу 66,50% — и решава повече задачи поне веднъж. Но преминава точно същия брой задачи във всичките 20 опита: 241. Половин пункт по-висока водеща точност не донесе никаква допълнителна надеждност.

• Kimi-K3 решава 75 повече задачи поне веднъж от Opus 5.
• Opus 5 решава 173 повече задачи последователно от Kimi-K3.

Ако избирате модел за работа, която засяга реални записи, pass@20 е грешната колона, към която да се обърнете.

Каква е цената на последователността

Сравненията на способностите обикновено приключват с резултата. За всеки, който внедрява система, важният въпрос е колко струва една успешна единица работа. Измерваме това като цена за успешен опит на задача. Казваме „опит на задача“, защото всяка задача в бенчмарка се изпълнява многократно и разходът възниква за всеки опит, така че pass@1 е съответният знаменател за качеството.

Взехме отчетеното използване на токени от всяка кампания на модела с 507 × 20 изпълнения и го оценихме по неподлежащите на отстъпка публични тарифи, налични в OpenRouter⁺, като обърнахме промоционалните отстъпки и изключихме крайните точки, които декларират квантизация. Тарифите за вход, изход и кеширане са взети от една крайна точка на доставчик за всеки модел.

След това разделихме цената на едно изпълнение на броя опити, които са били успешни:

Цена за успешен опит на задача = изчислена цена за 507 опита, по един за всяка задача ÷ (507 × pass@1)

Това е сравнителен индекс за ефективност, а не фактура и не цената за обслужване на една производствена заявка. Освен това оценява отделни успехи, а не последователност. След това оценяваме и последователността.

Пример: GPT-5.4 струва 43,49 долара за 507 опита (по един опит за задача) и има 65,36% pass@1, така че 43,49 ÷ (507 × 0,6536) = 0,131 долара за успешен опит на задача.

Граница на разходите по Парето

Модел е на границата, ако няма друг модел, който да е едновременно не по-скъп и поне толкова точен. Три модела отговарят на това условие; всеки друг е доминиран по поне една от осите.

Фигура 4: Цена за успешен опит на задача спрямо pass@1. Окръжените точки са моделите на границата на разходите по Парето.

Границата има три стъпала. GPT-5.6 Sol има най-ниската цена за успех — 0,127 долара; GPT-5.4 повишава pass@1 с 3,45 процентни пункта срещу 0,004 долара повече за успех; Claude Opus 5.5 добавя още 1,80 пункта при 0,276 долара за успех. Всеки от трите остава на линията на границата на разходите, тъй като нито един по-евтин модел не достига неговия pass@1.

Claude Opus 5 е най-ясният пример: при 0,475 долара за успешен опит и 66,50% pass@1 той е едновременно по-скъп и по-неточен от Claude Opus 5.5 при 0,276 долара и 67,16%.

Сега да оценим последователността

Цената за успех възнаграждава модел, който е евтин и често е прав. Тя не възнаграждава модел, който е прав всеки път. Затова изчисляваме и цена за надеждна задача: цената на пълната кампания от 20 изпълнения, разделена на броя задачи, които моделът е преминал във всичките 20 опита.

Цена за надеждна задача = изчислена цена за 20 изпълнения на 507 опита ÷ задачите, преминали 20/20

Пример: GPT-6-Astra струва 20 × 86,03 = 1720,60 долара за кампанията и преминава 231 задачи при всеки опит, така че 1720,60 ÷ 231 = 7,45 долара за надеждна задача.

Таблица 3: Деветте най-ниски цени за надеждна задача сред моделите с поне една наблюдавана задача 20/20, подредени от ниска към висока. Изчислени долари, а не действителни облачни сметки.

Сега класираме по последователност. GPT-5.4 е най-евтиният — 6,80 долара, макар че само 128 задачи покриват критерия. GPT-6 Astra достига 231 при 7,45 долара, а Claude Opus 5.5 — най-високите заедно 241 при 7,80 долара.

Нито един от трите не доминира над останалите: всяка допълнителна надеждна задача струва повече. Claude Opus 5 също преминава 241 задачи, но при 13,30 долара, така че Opus 5.5 го доминира напълно. GPT-5.6 Sol, най-евтиният за един успех при 0,127 долара, струва 9,76 долара за надеждна задача. Най-евтиният начин да получите правилен отговор не е най-евтиният начин да получите надежден отговор.

Сигнатури на неуспехите

Присвояваме на всяка неуспешна следа една детерминистична диагностична сигнатура, а водещият извод е приложим: приблизително четири от всеки пет неуспеха са свързани с обработката на инструменти, а не с разсъждението. В рамките на аблационно изследване в Таблица 5 от нашата статия:

Това са непретеглени средни стойности на дяловете по модели и наблюдаемите етикети, а не уникални причинно-следствени обяснения.

Практическият модел е прост: агентите обикновено стигат достатъчно далеч, за да опитат работния процес, след което не успяват да се възстановят от грешки на инструментите, неизпълнени предварителни условия или празни справки. Преди всичко това е проблем с повторните опити и възстановяването от грешки, а не с модела.

Трудността също се променя според областта: сред моделите, изброени в Таблица 2 по-горе, търговията на дребно има средно 59,52% pass@1, докато автомобилното застраховане има средно 33,83%.

Какво да направите. Приемете процента 20/20 като вход за проектирането, а не като присъда. Същият сигнал, по който бенчмаркът оценява, е наличен и в производствена среда: проверявайте крайното състояние, преди да потвърдите промяната, а не обобщението на модела за него.

Класифицирайте грешките на инструментите и системата, така че повторните опити да са насочени към възстановимите случаи. Ограничете набора от инструменти до необходимото за работния процес. И изисквайте човешко одобрение за промените, които не можете евтино да отмените. Не сме измервали повишаването на резултата от нито една от тези мерки в този бенчмарк — именно това е от типа неща, които средата вече позволява да бъдат тествани.

Как работи

ThinkingBox е пясъчникът за агенти, а ThinkingBox-Bench е набор от данни за оценяване на агенти. Диаграмата в началото на тази публикация показва цикъла; ето какво прави всяка част.

Фигура 5: Цикълът на пясъчника от панел A на Фигура 1 по-горе: изолирана инструментална сесия, крайно състояние на базата данни, странични ефекти, изпълними оценители.

Всяка задача определя начално състояние на бекенда, цел на потребителя, наличните MCP инструменти, политиката на областта и изпълними проверки върху крайното състояние. Симулиран потребител пази частен контекст (референция за резервация, предпочитание или дата на раждане) и го предоставя само когато бъде попитан.

Всеки опит получава изолирана MCP сесия с току-що инициализирано състояние. Два опита на една и съща задача никога не споделят ред в базата данни или кеширано състояние на инструмента, което прави сравнението от 20 изпитвания смислено.

В края екстрактор на странични ефекти извлича какво действително се е променило, а детерминистични оценители го сравняват с изискваното крайно състояние, като приемат всяка траектория, която води до правилния резултат, и отхвърлят грешните, липсващите или допълнителните ефекти. За изисквания без чиста стойност в базата данни („агентът разкрил ли е, че това не е гарантирано?“) тесен двоичен въпрос от рубрика обработва семантиката. 477 от 507 задачи се оценяват само по състоянието; 30 добавят рубрики за отговора.

Границата на доверие: моделът вижда задачите, диалога и схемите на инструментите. Златното състояние, твърденията, вътрешните механизми за оценяване и идентификационните данни остават от страната на оценяващия.

Стартирайте го сами

ThinkingBox вече е в Hugging Face — както инструментариумът, така и наборът от данни. ThinkingBox-Bench вече използва интерфейса OpenEnv, а всеки завършен епизод връща двоична награда за успех/неуспех. Публикуваният адаптер е предназначен за оценяване; отделни сценарии извън бенчмарка могат да използват същия интерфейс в работни процеси за обучение.

Преди да започнете

Тествано е на Linux и WSL с Python 3.11+, uv и Docker. Необходим е и клониран репозиторий thinkingbox-data на фиксираното издание, както и крайни точки за моделите на агента, симулирания потребител и оценителя. Една крайна точка може да обслужва и трите роли — това е най-лесният начин да започнете. Образът на OpenEnv стартира само API на OpenEnv; всичко останало стартирате сами.

Инсталиране

git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

Стартирайте Typesense

В втори терминал стартирайте Typesense 30.1 и изчакайте проверката за изправност:

mkdir -p .typesense-data
docker run --rm -d --name thinkingbox-typesense \
  -p 8108:8108 \
  -v "$PWD/.typesense-data:/data" \
  typesense/typesense:30.1 \
  --data-dir /data --api-key=Fake --enable-cors
until curl -fsS http://127.0.0.1:8108/health; do sleep 1; done

Стартирайте MCP сървърите

В трети терминал стартирайте проксито на сесиите и MCP сървърите.

cd OpenEnv
tb mcp-start --host 127.0.0.1 --port 7111 \
  --servers "$PWD/thinkingbox-data/servers/servers.yaml"
curl -fsS http://127.0.0.1:7111/health

Стартирайте сървъра на OpenEnv

Върнете се в първия терминал и стартирайте сървъра на OpenEnv спрямо YAML конфигурация на ThinkingBox, в която са посочени трите ви модела (ръководство за конфигурацията):

OPENENV_TB_CONFIG="$PWD/thinkingbox.yaml" \
uv run --project envs/thinkingbox_env --frozen server

Проверете готовността

Проверете готовността, преди да стартирате каквото и да е. Сървърът връща 503, докато не преминат проверките за наблюдаемите данни, конфигурацията и проксито на сесиите. Той не може да наблюдава Typesense или да тества в реално време всяка крайна точка на модел, затова потвърдете тези неща отделно:

curl -sS http://127.0.0.1:8000/ready

Оценете епизод

Сега оценете реален епизод. example_usage.py само нулира и показва инструментите; за действията на агента, ефектите и твърденията използвайте включения оценител:

echo "- sandbox_external_retail_group1.py:test_case_ST002_001" > one_task.yaml
uv run --project envs/thinkingbox_env thinkingbox-eval \
  one_task.yaml \
  --config "$PWD/thinkingbox.yaml" \
  --output results.jsonl \
  --errors-output errors.jsonl \
  --repeat 1 --message-timeout 1800

Адаптерът на OpenEnv записва оперативните неуспехи в страничен файл с грешки, за да могат да бъдат изпълнени отново, вместо тихо да се смесват с резултатите на модела. Каноничният резултат трябва да разреши или изрично да отчете тези опити; ние преброихме системните грешки като неуспешни изпитвания.

Изпълненията се ограничават до фиксиран комит на рамката, фиксирано издание на данните и хеш на пакета, така че каноничният резултат да може да бъде проверен, а не просто заявен.

Какво следва

Полезната част от тази работа не е нашата класация по pass@1. Това е средата.

Ако оценявате агент, който работи с реални записи:

1. Проверете неуспех. Намерете изпълнение, което е приключило нормално, но все пак е неуспешно, и вижте какво действително се е променило в базата данни. Това променя гледната точка към онова, което измерват собствените ви оценки.
2. Възпроизведете една задача чрез OpenEnv със собствен модел.
3. Отчитайте показател за повторяемост и го дефинирайте. Каквото и k да оправдава вашият случай на употреба, посочете дали отчитате най-доброто от k или всеки от k опита и как сте го изчислили.

Допълнителни подробности можете да намерите на следните връзки:

• Среда: envs/thinkingbox_env
• OpenEnv: https://huggingface.co/docs/openenv/environments/thinkingbox
• Рамка: microsoft/thinkingbox · урок
• Бенчмарк: microsoft/thinkingbox-data · издание v1.0
• Преглед на набора от данни: microsoft/ThinkingBox-Bench
• Статия: arXiv:2608.19741 или HF
• RL обучение (предстои): microsoft/thinkingbox-training

Кодът на ThinkingBox е с лиценз MIT; данните от бенчмарка са с лиценз CDLA-Permissive-2.0; средата OpenEnv се предоставя под лиценза BSD-3-Clause на OpenEnv.

Отказ от отговорност: всяка задача в публичния бенчмарк е синтетична реконструкция. Работните процеси и политиките са моделирани по реални корпоративни модели за използване на AI агенти; клиентите не са реални.

ThinkingBox и ThinkingBox-Bench са създадени от екипа на Microsoft Copilot Studio в партньорство с Toloka, със сътрудници от University of Pittsburgh, Northwestern University, Columbia University и UC Irvine, които са били стажанти в Microsoft.

⁺ Снимката на цените в OpenRouter е направена на 20 септември 2026 г.; цената на Opus 5.5 е според сайта на Anthropic.

Набори от данни, споменати в тази статия 1

Статии, споменати в тази статия 1

Още от този автор