Агент сломал прод не из-за «галлюцинаций», а потому что не видел интерфейс: почему 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, 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.
Такие агенты я делаю для бизнеса в Германии и ЕС.
Опишите в двух предложениях, что отнимает у команды время, — отвечу в течение суток.
Превратить процесс в систему, которая работает
Продакшн-качество, а не демо.