Агент сломал прод не из-за «галлюцинаций», а потому что не видел интерфейс: почему runtime-perception для web/desktop становится обязательным

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany; в DennisCraft AI Studio я запускаю AI-системы для DACH B2B на стеке Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самый неприятный класс инцидентов, который я вижу в проде, выглядит не как «модель придумала ерунду», а как «агент нажал не ту кнопку, потому что кнопка изменилась, модальное окно перекрыло экран, а DOM уже не соответствовал реальному состоянию интерфейса».

Когда команда говорит «у нас hallucination problem», я обычно сначала смотрю не на промпт, а на то, как агент наблюдает среду во время выполнения. Если агент работает с web или desktop UI и опирается только на заранее известные селекторы, текстовые команды или устаревший снимок DOM, это не интеллект, а хрупкая автоматизация. В regulated среде это особенно заметно: интерфейсы меняются, feature flags включаются выборочно, CAPTCHA и SSO встраивают промежуточные шаги, а audit trail потом фиксирует действие, которое агент выполнил формально корректно, но в неверном контексте.

Проблема не в «галлюцинации», а в отсутствии runtime state

У слова hallucination есть плохой побочный эффект: оно позволяет списать системную ошибку на модель. На практике во многих production-инцидентах модель не выдумывала мир, а действовала в условиях плохой наблюдаемости. Агенту сказали «открой счет клиента и нажми Approve», но во время выполнения UI показал баннер с новым обязательным полем, вкладка перерендерилась, а нужная кнопка стала disabled до заполнения причины. Если у агента нет runtime-perception, он продолжает действовать по старой карте.

Что я называю runtime-perception

Это не магия и не отдельный бренд. Это паттерн, в котором агент перед критическим действием получает актуальное наблюдение среды: screenshot, accessibility tree, DOM snapshot, текстовое OCR-представление или комбинацию этих каналов. Затем он сопоставляет намерение с фактическим состоянием интерфейса и только после этого делает шаг. После шага цикл повторяется.

Anthropic в документации по computer use прямо исходит из того, что модель работает по циклу «observe → reason → act» и нуждается в текущем визуальном состоянии интерфейса, а не только в текстовой инструкции. Это не маркетинг, а инженерная необходимость для UI-задач: Anthropic Docs, 2024–2025. Если агент не видит среду в момент действия, он не управляет системой, а угадывает.

Почему web и desktop стали опаснее для агентов

5 лет назад многие B2B-процессы можно было автоматизировать через стабильные формы и предсказуемые экраны. Сейчас почти в каждом enterprise-потоке есть динамика: React-компоненты, role-based rendering, A/B-тесты, consent-баннеры, iframe-платежи, SSO-переадресации, условные поля, локализация по рынку. Для desktop добавьте VDI, Citrix, legacy ERP и окна, которые нельзя надежно описать API-вызовом.

Подход Что видит агент Типовой сбой Где применимо
Только API Структурированные данные Не покрывает действия, живущие в UI Лучший вариант, если API полное
Только DOM/селекторы HTML-структуру Overlay, hidden state, re-render, iframe Ограниченно для стабильных web-app
Runtime-perception Текущий экран + состояние UI Выше стоимость шага, ниже риск ложного клика Web и desktop с меняющимся интерфейсом

Я не утверждаю, что perception должен заменить API. Наоборот: сначала API, потом event-driven интеграции, и только там, где бизнес-процесс реально заперт в интерфейсе, добавляется perception layer. Но если UI уже в контуре, делать вид, что агенту достаточно текста и селекторов, больше не получается.

Как выглядит production-паттерн

В проде я закладываю не «умного агента», а контролируемый цикл действий с проверками. Минимальный набор: актуальный снимок UI, явная цель шага, ограничение допустимых действий, post-action verification и fallback на человека при неопределенности. Агент не должен «смело продолжать», если confidence падает после появления незнакомого элемента.

Пример оркестрации шага через n8n и Python

from anthropic import Anthropic
import base64
import os

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

with open("screen.png", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode("utf-8")

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=400,
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "Find the approval control. If the form is incomplete, say BLOCKED and explain why."},
            {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_b64}}
        ]
    }]
)

print(response.content[0].text)

Здесь важен не сам SDK, а дисциплина: агенту нельзя сразу кликать. Сначала он должен классифицировать состояние экрана. Если ответ содержит BLOCKED, workflow в n8n переводит кейс в другую ветку: запросить недостающее поле, сделать новый screenshot, эскалировать оператору.

Верификация перед записью в БД

type UiDecision = {
  action: "click" | "type" | "blocked";
  target?: string;
  reason: string;
};

function requireSafeDecision(decision: UiDecision) {
  if (decision.action === "blocked") throw new Error(decision.reason);
  if (!decision.target || decision.target.length < 3) {
    throw new Error("Missing verified UI target");
  }
  return decision;
}

const decision = requireSafeDecision({
  action: "click",
  target: "button[aria-label='Approve payment']",
  reason: "Button visible and enabled"
});

Такая верификация не спасет от всех ошибок, но она делает сбой наблюдаемым. Вместо тихого неверного действия вы получаете явный stop condition.

Безопасность и аудит: что ломается без perception

Когда агент работает в regulated процессе, вопрос уже не только в UX-ошибке. Ошибка интерфейса может превратиться в инцидент доступа, ошибочное подтверждение операции или запись данных не в тот контекст клиента. OWASP в LLM-памятках 2025 года отдельно подчеркивает риск недостаточного контроля агентных действий и необходимость ограничений на инструменты и верификацию контекста: OWASP Top 10 for LLM Applications.

Из моего опыта, самые частые поломки выглядят так:

  • агент кликает по визуально похожему элементу после изменения layout;
  • модальное окно блокирует основной экран, но DOM старой страницы еще доступен;
  • desktop-сессия теряет фокус, и ввод уходит не в то окно;
  • SSO или MFA добавляют неожиданный шаг, который не был в сценарии;
  • локализация меняет подписи кнопок, и текстовый матчинг дает ложное совпадение.

Именно поэтому я считаю runtime-perception обязательным слоем для UI-агентов в проде. Не потому, что модели «стали хуже», а потому, что среда стала более подвижной, а цена ошибки выросла.

Что делать команде прямо сейчас

Если у вас уже есть агент, который ходит в web или desktop, задайте 5 практических вопросов. 1) Что именно агент видит перед критическим действием? 2) Есть ли post-action verification? 3) Что происходит при неизвестном состоянии экрана? 4) Можете ли вы воспроизвести шаг по audit log и screenshot? 5) Где в цепочке оператор может безопасно перехватить управление?

Если хотя бы на 2 вопроса ответ расплывчатый, проблема, скорее всего, не в prompt engineering. Проблема в том, что агент работает вслепую. И это исправляется архитектурой, а не очередной правкой system prompt.

FAQ

Разве API не всегда лучше UI-автоматизации?

Да, если API действительно покрывает нужный процесс. Но в enterprise-среде критические действия часто остаются только в UI, особенно в legacy-системах, партнерских кабинетах и desktop-приложениях.

Достаточно ли DOM snapshot без screenshot?

Не всегда. DOM не показывает фактическую видимость, overlay, disabled state после рендера и фокус окна. Для важных шагов я предпочитаю комбинировать DOM и визуальное наблюдение.

Это слишком дорого по токенам и времени?

Дороже, чем слепой клик, но дешевле, чем инцидент в проде. Обычно perception включается только на критических точках процесса, а не на каждом элементарном действии.

Подходит ли это для desktop и VDI?

Да, и там это еще нужнее. В desktop-среде API часто нет, а состояние окна, фокус и разрешение сессии напрямую влияют на корректность действий агента.

Можно ли обойтись без человека в контуре?

Иногда да, если шаги хорошо ограничены и верифицируемы. Но для операций с деньгами, доступами и персональными данными я обычно оставляю явный путь эскалации.

Где в вашем LLM-контуре чаще всего всплывают ошибки в проде — на этапе планирования, при вызове инструментов или в момент фактического взаимодействия с UI? Я правда хочу это сравнить с тем, что вижу у DACH B2B-команд.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.

Read more

Computer-Use-Agenten scheitern an Pixeln: wie Sie auf stabile UI-Referenzen über Accessibility Trees umstellen und fehleranfällige Desktop-Automatisierung nicht mehr ständig reparieren

von Denis Shokhirev, Enterprise AI Architect aus Freiburg im Breisgau Ich bin Denis Shokhirev, Agentic AI Systems Architect in Freiburg im Breisgau, Germany, und bei DennisCraft AI Studio setze ich produktive KI-Systeme für DACH-B2B-Kunden auf Basis von Claude, Supabase, n8n, Doppler und selbst betriebenem Postgres um. Die teuersten Fehler in

By Denis Shokhirev

Компьютерные агенты ломаются на пикселях: как перейти на stable UI refs через accessibility tree и перестать чинить flaky desktop automation

Я Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я собираю production AI-системы для DACH B2B на Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самая дорогая поломка в desktop automation, которую я вижу у клиентов, почти никогда не связана с моделью: агент

By Denis Shokhirev