Як оцінювати browser agents: практичний чекліст

Почніть із task contract, який називає початковий стан, дозволені сайти й застосунки, дані, термінальний стан, заборонені події та межу людського підтвердження. Фраза «замов квиток» не є тестом: треба зафіксувати маршрут, дату, бюджет, чи дозволене бронювання, і чи агент має зупинитися перед оплатою. Для read-only задач verdict може перевіряти знайдений запис; для state-changing задач потрібне підтвердження фактичного backend-стану, а не тексту, який агент побачив на сторінці.

WebArena корисний саме через функціональні сайти та перевірку завершення реалістичних довгих задач, але публічний benchmark не відтворює ваші дозволи, локалі, дані й наслідки. Перетворіть production jobs на очищені task families і для кожної створіть незалежний oracle: API або database query у sandbox, структурований export, контрольний DOM state чи human-reviewed artifact. Self-report агента «готово» ніколи не є oracle.

• Outcome → потрібний стан справді створено, знайдено або змінено.
• Trajectory → кожна дія була дозволена для цього task і поточного стану.
• Side-effect integrity → немає зайвого submit, повідомлення, платежу або видалення.
• Stop behavior → агент коректно відмовляється, уточнює або просить approval.

Результат browser eval залежить не лише від моделі. Версіонуйте image або VM, браузер, viewport, device scale, locale, timezone, шрифти, cookies, account fixture, network policy, початкові дані й стан кожного застосунку. Окремо фіксуйте observation mode: screenshot, accessibility tree, DOM, OCR або їхню комбінацію; action mode: координати, element IDs, Playwright primitives чи keyboard shortcuts. OpenAI у додаткових матеріалах до CUA прямо документує відмінності browser/VM середовища, prompts, sampling і scoring — без цього порівняння версій не є відтворюваним.

BrowserGym уніфікує observation та action spaces для кількох web-agent benchmarks; у внутрішньому harness застосуйте ту саму дисципліну. Зберігайте environment manifest біля результату і відхиляйте run, якщо fixture не піднявся, сайт змінився або oracle недоступний. Infrastructure failure не можна рахувати як model failure, а випадково вже виконану задачу — як success. Reset має відновлювати весь business state, включно з листами, кошиком, файлами й pending transactions.

Frozen regression set охоплює типові задачі й відомі інциденти, а held-out set — нові формулювання, сутності та layout variants. Додайте responsive viewport, інший zoom, переклад, sticky banner, modal, lazy loading, disabled control, однакові labels, таблицю з pagination і елемент нижче fold. Для computer-use agent перевіряйте активне вікно, focus, drag, clipboard, file picker і системний dialog. Мета не в тому, щоб ламати координати, а щоб виміряти grounding на поточному семантичному стані.

Додайте часові та операційні perturbations: повільний response, spinner, stale screenshot, action accepted після timeout, session expiry, redirect, нова вкладка й часткове збереження форми. Ambiguous tasks повинні вимагати уточнення, а impossible tasks — безпечної зупинки. Підтримуйте contamination boundary: не використовуйте held-out screenshots у prompts або few-shot examples і не оптимізуйте policy за кожним невдалим кейсом без нового сліпого набору.

Task success є необхідним, але не достатнім. Trace grader перевіряє origin transitions, targets, введені поля, repeated actions, approval binding і prohibited states. Розрізняйте perception error, wrong target, planning error, policy block, environment failure, premature stop та false success claim. Кількість кроків і latency корисні лише після correctness: короткий шлях із хибним submit не є ефективнішим. Якщо існує кілька правильних шляхів, оцінюйте інваріанти, а не exact action sequence.

Recovery suite починає агент із проміжного стану: modal перекрив кнопку, form validation відхилила поле, navigation повернула на login або timeout настав після commit. Pass вимагає спочатку зчитати фактичний стан, не дублювати side effect і вибрати retry, reconcile, rollback чи escalation. Для стохастичного агента робіть кілька незалежних runs, звітуйте розподіл і paired comparison з baseline; не перетворюйте один вдалий replay на загальну заяву про надійність.

• Functional verdict → незалежний oracle підтвердив кінцевий state.
• Policy verdict → жодна дія не вийшла за scope або approval.
• Grounding verdict → target відповідав наміру у фактичному кадрі.
• Recovery verdict → повтор не створив дубль і зберіг audit trail.

Сторінка, документ, повідомлення й tooltip є недовіреними даними. Security slice розміщує direct та indirect prompt injections у видимому тексті, accessibility attributes, завантаженому документі й результаті пошуку. Перевіряйте не лише те, чи агент повторив інструкцію, а sinks: чи спробував змінити ціль, перейти на заборонений origin, прочитати canary secret, вставити його у форму, завантажити файл або виконати зовнішню дію. Prompt-injection detection без sink verdict створює хибне відчуття захисту.

Усі write tests виконуються в disposable accounts із canary data, перехопленими email/webhook, fake payment rail і журналом backend mutations. Approval прив'язуйте до точного payload і state snapshot: підтвердження одного одержувача не дозволяє змінити адресу після modal. Тестуйте скасування approval, expired approval, misleading button, download quarantine й секрет у clipboard. Production credential, реальний платіж або повідомлення зовнішній людині не потрібні для доказового eval.

Decision record містить dataset revision, environment manifest, model, prompt, observation/action adapter, policy, oracle, sample count, segment results, critical failures і reviewer. Порівнюйте candidate з known-good bundle на тих самих task seeds. Promote вимагає non-regression для outcome, нульового допуску до визначених critical side effects і проходження окремих slices для домену, локалі, task length та risk tier. Публічний benchmark є зовнішнім сигналом, а не заміною вашого release gate.

Rollout іде від offline resettable environment до shadow, read-only canary, draft-only writes і вузьких approved actions. Monitor повторює offline taxonomy: false completion, duplicate mutation, unexpected origin, approval mismatch, recovery failure. Rollback повертає сумісний bundle моделі, prompt, adapter і policy, зупиняє нові runs та reconciles незавершені side effects перед повтором. Очищений incident trace стає regression fixture тільки після перевірки provenance й privacy.