Разработката на AI агенти минава тест на runtime средата
Изследователи от ByteDance Seed, Singapore University of Technology and Design, Georgia Tech, M-A-P и TokenWave.AI представиха на 2026-09-11 HarnessDev — бенчмарк, който оценява изпълнимата система, която един LLM изгражда около агента, а не само отговора, който връща. Това е важно за разработката на AI агенти, защото проучването показва, че дизайнът на runtime средата може да променя способностите, разхода и преносимостта на резултатите също толкова силно, колкото и изборът на модел. Според обобщението на MarkTechPost за публикацията, само 34 от 64 съседни еволюционни промени са се обобщили към скрити задачи.
HarnessDev променя какво всъщност се оценява при разработката на AI агенти
Повечето публични бенчмаркове фиксират runtime средата на агента и оценяват отговора на модела. HarnessDev измества фокуса. Тук обектът на тест е изпълнимата система, която моделът изгражда: логика на цикъла, инструменти, работа с контекст, състояние, възстановяване, правила за спиране и верификация.
Това звучи силно технически, но затваря празнина, която много екипи, изграждащи custom AI агенти, вече виждат на практика. Модел, който изглежда силен в една среда или toolchain, може да се представи по-слабо в друга, дори при идентични weights. Публикацията започва с конкретен пример, цитиран и в източника: GPT-5 решава 35.2% от задачите в Terminus 2, но 49.6% в Codex CLI при същите weights.
Бенчмаркът използва два етапа. В Creation всеки модел получава една и съща слаба начална версия с file, search и process primitives, но без planner, verifier, retry logic или stopping rule. В Evolution моделът редактира собствения си замразен код на базата на обратна връзка от изпълнението върху фиксирани бенчмарк набори, след което се оценява по скрити SWE-bench Pro задачи, които не е виждал.
Това е важно за AI API интеграция и по-широката архитектура на AI интеграцията, защото изолира частта от стека, която предприятията често третират като glue code. HarnessDev подсказва, че именно този glue code често решава крайния резултат.
Как етапът Creation показва разликите в качеството на runtime средата
Конфигурацията на creation етапа обхваща 2,207 инстанции в SWE-bench Pro, Terminal-Bench 2.1, MLE-bench, EQ-Bench3 и BrowseComp, като шест creator модела работят в Claude Code 2.1.177. Резултатите са отчетени както при self-evaluation, така и при unified evaluation, където Gemini 3.1 Pro служи като общ executor.
При self-eval Opus 4.8 постига най-висок среден резултат — 67.8, под референтната човешки инженерна система с 86.2. Но разпределението по домейни е по-показателно от средната стойност:
- Code: Opus 4.8 достига 69.3 на SWE-Pro спрямо референтни 80.0.
- Terminal tasks: Gemini 3.1 Pro води с 68.8 спрямо референтни 88.8.
- Search: GPT-5.5 води в BrowseComp с 52.6 срещу 92.2 за референтната система.
- Writing: Opus 4.8 записва 84.6 на EQ-Bench3, над референтните 83.7.
- ML experimentation: Opus 4.8 с 32.9 и Gemini с 32.4 изпреварват референтните 24.0.
Пазарният извод е, че AI automation agents не се провалят равномерно. Те се провалят според типа натоварване. Писането и ML експериментирането търпят по-голяма вариация в runtime средата. Кодът и търсенето изглеждат значително по-чувствителни към качеството на planner-а, retry правилата и дисциплината при работа с инструменти.
Източникът подчертава и една от по-показателните констатации: обемът код не е бил предиктор за качество. В 18 генерирани системи моделите са добавили нетно 17,111 реда, но Gemini е добавил най-малко редове и въпреки това е водил в Terminal-Bench. Много функции просто не са се активирали. От 108 инстанции на кодови компоненти, 18 никога не са се изпълнили по време на runtime, като всички са били в state и memory. При writing 124 от 587 функции са били мъртъв код.
| Approach | Typical runtime pattern | Strength | Risk | Best fit |
|---|---|---|---|---|
| Benchmark-first agent builds | Optimize for one fixed executor and task set | Fast iteration | Poor transfer to unseen environments | Labs and short-lived prototypes |
| Prompt-led workflow automation | Strong prompts over thin orchestration | Lower build effort | Brittle stopping, retries, and verification | Narrow internal copilots |
| Implementation-led AI workflow automation | Runtime, tools, and monitoring engineered together | Better transfer, observability, and cost control | More upfront systems work | Production AI business automation |
Защо прехвърлянето между executors е истинският стрес тест
Най-полезният в оперативен план резултат в публикацията е смяната на executor-а. Когато системи, създадени от един модел, са пуснати под Gemini 3.1 Pro, класиранията се променят рязко. Qwen печели 17.6 точки при BrowseComp и 12.9 при MLE-bench. Резултатът на Opus 4.8 за SWE-Pro спада от 69.3 до 33.0.
Подобен спад не е просто любопитен бенчмарк ефект. Това е предупреждение за enterprise AI интеграции, при които един екип разработва с един модел, а друг внедрява на различна runtime среда поради разходи, latency или procurement изисквания. Ако една система предполага конкретен step limit, message format или tool cadence, преносимостта се превръща в скрит режим на отказ.
Според източника една система на Opus на практика е закодирала твърдо лимит от 120 стъпки около оригиналния си executor. Поведението ѝ при търсене също се е влошило след смяната, като делът на дублирани заявки е скочил от 10.1% до 88.2%. Точно такива implementation details рядко присъстват в полирани демота, но определят резултатите в production.
Полезно сравнение идва от работата на Anthropic върху agentic coding systems и benchmark отчетите на OpenAI, които неведнъж показаха, че инструментите, дизайнът на средата и retry структурата могат съществено да променят крайните резултати. HarnessDev развива този урок, като прави самата runtime среда обект на оценка.
Какво казва етапът Evolution за самоусъвършенстването на моделите
Историята за самоусъвършенстване е по-умерена, отколкото мнозина вероятно очакват. В девет lineages изследователите създават 73 официални версии и 64 съседни смени. И петте self-runtime creator модела подобряват резултатите си върху скрити задачи, но само с +1.43 до +4.44 точки средно. При фиксиран Gemini само Opus се подобрява, докато GPT-5.5 регресира с 10.32 точки.
По-важният модел е шумът. От 64-те смени, 8 регресират и в двата бенчмарка, 16 регресират в единия, 27 се подобряват само в рамките на шумовия диапазон, а едва 2 показват ясни положителни доказателства. Обратната връзка и резултатите на скрити задачи се движат в една и съща посока само 34 пъти, или 53.1%.
Това не е аргумент срещу AI workflow automation. Това е аргумент да не се вярва твърде бързо на локални победи в бенчмаркове. За екипите, които изграждат AI business automation, изводът е ясен: ако цикълът за валидация е твърде близо до цикъла за разработка, системата може да научава навици за конкретния бенчмарк, а не устойчиво работно поведение.
Най-ясният успешен случай идва от Opus 4.8. Както е перифразирано в източника, моделът е забелязал, че 99 от 100 изпълнения отчитат успех, докато реално преминават само 48, проследил е разликата до преждевременно завършване и е добавил completion gate. Това е полезен сигнал: моделите понякога могат да диагностицират грешки в control-flow логиката на собствената си runtime среда. Но публикацията също така отчита, че специализираният trajectory интерфейс за диагностика на откази е бил извикан само два пъти, което подсказва, че диагностиката все още изостава спрямо генерирането на код.
За по-широк пазарен ориентир скорошното изследване на McKinsey за внедряването на AI стига до сходен извод на езика на предприятията: бариерата вече не е само достъпът до модели, а способността на организациите да operationalize системи надеждно в различни работни процеси.
Какво трябва да вземат екипите от HarnessDev преди да пуснат агенти
Проучването насочва към три практични промени в разработката на AI агенти.
Първо, третирайте дизайна на runtime средата като продуктово инженерство, а не като второстепенна middleware задача. Custom AI агентите имат нужда от ясна логика за спиране, верификация, retries и fallback обработка. Качеството на prompt-а остава важно, но вече не обяснява изцяло качеството на runtime средата.
Второ, тествайте преноса преди rollout. Ако системата ще се мести между доставчици, shell среди или orchestration слоеве, оценявайте я в тези среди рано. Това е особено важно при enterprise AI интеграции, където ограниченията на procurement или latency често налагат късни смени на модела.
Трето, проверявайте неактивната сложност. Публикацията открива неизползвани state, memory и helper компоненти в много от генерираните системи. Мъртвият код не е само неефективност; той може да създаде фалшива увереност. Runtime среда, която изглежда сложна при преглед, може въпреки това да не изпълнява контролите, които твърди, че има.
Следващото, което си струва да се следи, е дали бъдещите бенчмаркове за агенти ще приемат скритата смяна на executor като стандартно изискване, а не като страничен експеримент. Ако това се случи, разработката на AI агенти ще се оценява по-малко по успеха в единично изпълнение и повече по това дали системите издържат на реална оперативна вариативност.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation