О себе Портфолио Кейсы Услуги Блог Контакт 🎙 Поговорить с AI
EN DE RU
🎙 Поговорить с AI
November 3, 2026 · 4 min read

Агент сломал прод не из-за «галлюцинаций», а потому что не видел интерфейс: почему 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 уже не соответствовал реальному состоянию интерфейса». Когда команда говорит «у нас hallu

Denis Shokhirev
Denis Shokhirev
Agentic AI Systems Architect
Telegram LinkedIn

Я — 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.

Для вашего бизнеса

Такие агенты я делаю для бизнеса в Германии и ЕС.

Опишите в двух предложениях, что отнимает у команды время, — отвечу в течение суток.

Разработка ИИ-агентов (страница на немецком) →
Читать дальше
Компьютерные агенты ломаются на пикселях: как перейти на stable UI refs через accessibility tree и перестать чинить flaky desktop automation
Cursor-marketplace скомпрометировали: как не пустить AI-расширение с SSH-бэкдором на ноутбуки разработчиков
AI-агент получил доступ к прод-среде? Как построить replayable security triage и доказуемый audit trail до первого инцидента
Claude Code превращают в команду специалистов: когда skills реально ускоряют разработку, а когда создают ещё один слой хаоса
Все статьи →
Где это применяется
Услуги — что мы делаем
Поговорить с голосовым агентом
Кейсы
Готовы к следующему шагу?

Превратить процесс в систему, которая работает

Продакшн-качество, а не демо.

Обсудить проект → ← Все статьи