AI-агенты и автоматизация: RAG, воркфлоу и гайды

Вы построили всё на OpenAI, затем захотели попробовать Claude и сравнить Gemini — и потеряли часы на разных SDK, форматах и обработке ошибок у каждого провайдера. LLM-шлюз (AI-шлюз / LLM-прокси) — это ретранслятор, который вы ставите между приложением и провайдерами: он предоставляет один совместимый с OpenAI API для обращения к любой модели и берёт на себя сквозные задачи — fallback, учёт затрат, виртуальные ключи, кэширование, ограничение частоты и наблюдаемость. В этом гиде: зачем он нужен, что такое шлюз на самом деле, три типа (self-hosted прокси = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), как выбрать среди LiteLLM, OpenRouter и Vercel AI SDK, минимальный код настройки, где меняется лишь эндпоинт, и ограничения — скачок задержки, шлюз как новая точка отказа, комиссии (OpenRouter берёт 5,5% при пополнении), потеря возможностей и приватность.

Построив ИИ-агента, вы всегда упираетесь в одну стену: «Хорошо, но он вообще работает?» Механизм, позволяющий решить, стало от изменения промпта или модели лучше или хуже на основе данных, а не интуиции, — это evals. LLM выдают разный результат каждый раз для одного и того же ввода, поэтому юнит-тесты на точное совпадение не подходят. Эта статья делает упор на практические шаги — как собрать evals и запустить их в работу — и рассказывает о пяти способах измерить качество (① сверка с эталоном ② проверки по правилам ③ LLM-as-judge ④ регрессионное тестирование ⑤ мониторинг в продакшене), об оценке, специфичной для агентов (доля успешных задач, корректные вызовы инструментов, траектория, стоимость), о том, как начать с малого с 20 примеров отказов, о частых ловушках и ключевых инструментах (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — она написана для практиков.

Извечный вопрос автоматизации: «ИИ-агенты или RPA?» Ответ — не «или — или»: выбирайте по роли, а выигрышный паттерн 2026 года — гибрид обоих. RPA — детерминированные «руки», которые быстро и точно выполняют фиксированную процедуру (но ломаются при изменении экрана/спецификации); ИИ-агент — вероятностный «мозг», который считывает ситуацию и принимает решение (силён в неоднозначности и исключениях, но результат не одинаков каждый раз). В статье: разница в принципе действия, сравнительная таблица (компромисс воспроизводимости и устойчивости к изменениям), как выбрать (ось — «можно ли полностью описать правилами?»: да → RPA, суждение, которое не описать → ИИ-агент), тренд 2026 года (лидеры RPA — UiPath, Automation Anywhere, Blue Prism — становятся агентными; сближение; вопрос уже не «что из двух», а «где живёт рассуждение» = оркестрация прежде всего) и практический ответ: гибрид, где мозг (ИИ-агент) отвечает за суждение/оркестрацию, а руки (RPA) выполняют детерминированное исполнение — не ставьте агента туда, где нужна детерминированность, а делегированное суждение сочетайте с ограждениями и согласованием человеком. На основе официальной информации вендоров, с FAQ.

Можно ли передать эксплуатацию AWS искусственному интеллекту? В 2026 году делегировать можно многое. Сама AWS поставляет Amazon Q Developer и Agent Toolkit for AWS (май 2026 — 40+ навыков агента + управляемый AWS MCP Server + плагины), так что ИИ дотягивается от генерации IaC до операций с ресурсами. Это руководство разбивает «делегирование» на три уровня (① генерация кода/IaC, ② эксплуатация/расследование с упором на чтение, ③ автономный агент, реально управляющий AWS), рассматривает основные инструменты (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) — включая путь «со своим инструментом», когда Claude Code или Codex получают AWS CLI для запуска «aws» из shell, — плюсы (быстрый IaC, автоматическая сортировка, идеи по оптимизации затрат, демократизация знаний), а затем самое главное — минусы (разрастание прав IAM, избыток прав как усилитель радиуса поражения ошибок/инъекций промпта, права, переживающие задачу, неконтролируемый рост затрат — с реальными случаями удаления продакшн-БД в 2025-26), на основе официальных материалов AWS и данных вендоров безопасности. Ключевой поворот: вопрос не «может ли он?», а «как делегировать без потери контроля и взрыва счёта» — и то, что сама AWS встроила защитные механизмы IAM, аудит CloudTrail и песочницу в Agent Toolkit, показывает форму ответа. Включает пять принципов (IAM с минимальными привилегиями, одобрение человека для деструктивных операций, наблюдаемость, краткоживущие учётные данные JIT, песочница) и FAQ.

Первое препятствие при встраивании ИИ-агента в реальную работу — «на каком фреймворке его собирать». С точки зрения разработчика и того, кто выбирает технологии, статья сравнивает шесть главных фреймворков — LangGraph, CrewAI, AutoGen (вошедший в Microsoft Agent Framework, GA апрель 2026), OpenAI Agents SDK, Google ADK и Claude Agent SDK — по подходу к оркестрации (ориентированный граф / ролевая команда / диалоговый GroupChat / передачи управления / иерархическое дерево / автономный цикл инструментов), языку, кривой обучения, управляемости, зрелости для прода, стоимости токенов и наиболее подходящему сценарию. Ключевая оговорка: фреймворк, «быстрейший для прототипа» (CrewAI), может оказаться самым дорогим в проде — около 3× токенов (41k против 18.5k у LangGraph в одном бенчмарке) и недетерминированный, что плохо подходит для финансов и здравоохранения. Также объясняется, как 2026 год принёс интероперабельность через MCP (инструменты) и A2A (агент-агент), так что агенты из разных фреймворков теперь работают вместе, а привязка ослабла. Включает гид по выбору под задачу и FAQ.

В статье «Как построить мультиагентную систему» мы советовали инструментировать каждую передачу управления до добавления агентов; технология, которая обеспечивает это в продакшене, — наблюдаемость ИИ. Она делает видимым то, что LLM и агенты на самом деле делают в продакшене (какая модель с каким промптом, какие инструменты и поиски, что возвращено, сколько времени и денег), чтобы можно было проследить путь до причины. Решающее отличие от обычного мониторинга: ИИ может вернуть 200 OK за 50ms и при этом уверенно галлюцинировать, поэтому большинство сбоев ИИ — это сбои качества (галлюцинации, слабое извлечение, небезопасные ответы, незавершённые задачи, плохое использование инструментов, регрессии после изменения промпта), а не инфраструктуры. Наблюдаемость опирается на три столпа: trace (один запрос как дерево span с вызовами LLM, инструментами, извлечением, цепочками рассуждений; главный элемент наблюдения ИИ), метрики (задержка, стоимость, токены, частота ошибок, пропускная способность) и логи (детали по событиям). Отраслевой стандарт — соглашения GenAI в OpenTelemetry — фиксирует промпты, ответы, использование токенов и вызовы инструментов/агентов в схеме без привязки к вендору, которую можно направить в Datadog/Grafana. Чаще всего путают наблюдаемость и оценку (evals): наблюдаемость показывает, что произошло (легко измерить, но нельзя сказать, верен ли ответ), а evals измеряют, хорош ли ответ (точность, groundedness, безопасность), и требуют явной оценки. Поскольку стоимость и задержку измерить легко, а качество ответа — нет, инструменты 2026 года совмещают показ trace с оценкой выходов и оповещениями о деградации. Метрики делятся на операционные (стоимость, задержка, токены, частота ошибок) и качественные (галлюцинация, groundedness/достоверность, важнейшая для RAG, безопасность, завершение задачи); обнаружение галлюцинаций — через LLM-as-a-judge, семантическое сходство и оценки groundedness. Основные инструменты: LangSmith (LangChain), Langfuse (open-source self-host), Arize Phoenix (отладка RAG), MLflow (жизненный цикл), AgentOps (агенты) и OpenTelemetry (стандарт). Начните со сбора trace (совместимо с OpenTelemetry), визуализируйте операционные метрики, затем подключите evals до выпуска. Для мультиагентных систем наблюдение необходимо, так как сбои прячутся в многошаговых цепочках, видимых только в trace всей сессии. Наблюдать плюс оценивать — вот что делает ИИ продакшен-уровнем. Иллюстрации и характеристики приведены по публичным материалам, как ориентир.

После того как вы усвоили концепцию в статье «Что такое мультиагентная система?», это практическое продолжение. На де-факто стандарте 2026 года — паттерне supervisor — оно проводит начинающих через построение за 5 шагов. Главный принцип: сначала стройте на одном агенте и добавляйте новых по минимуму, только упёршись в предел (около 80% сценариев обходятся одним; использование мульти для простой линейной работы раздувает стоимость в 3-10x и, по данным исследования Google, снижает точность на -39-70% на последовательных задачах). Три признака перехода на мульти: разделение специализаций, параллелизм, разделение решений. К паттерну supervisor (supervisor получает общую задачу, разбивает её, делегирует специализированным worker и агрегирует результаты) сошлись субагенты в Claude Code, LangGraph Supervisor и handoffs в OpenAI Agents SDK — у него самая широкая поддержка фреймворков, известный режим отказа (избыточное делегирование, ограниченное лимитом итераций) и его легко аудировать. 5 шагов: 1) чётко разложить задачу заранее; 2) определить worker с одной ролью + инструменты + формат вывода (максимум 3-5); 3) спроектировать supervisor, явно перечислив имена вызываемых worker (жёсткий лимит) и тратя на это больше всего времени; 4) определить handoff и обмен контекстом, передавая только нужное (стандарт — A2A); 5) инструментировать каждый handoff до добавления агентов, ограничить итерации/токены/стоимость, настроить evals и ограждения. Псевдокод, не зависящий от фреймворка, показывает определения worker, жёстко ограниченный supervisor и цикл с лимитом итераций. Типичные ловушки и решения: избыточное делегирование (лимит + ограничение вызываемых worker), раздувание токенов (передача только нужного + кэш), нестабильность (держать 3-5 + фиксированный вывод), падение точности на последовательных задачах (вернуться к одному), неясный источник сбоя (наблюдаемость). Общий урок: промпты, проектирование инструментов и набор evals решают успех больше, чем фреймворк. Стройте мало, измеряйте, добавляйте только когда окупается. Цифры приведены по открытым материалам и исследованиям, зависят от условий.

Теперь, когда ИИ-агенты стали обыденностью, следующий вызов — как заставить агентов работать сообща. Если MCP соединяет агента с его инструментами, то A2A (Agent2Agent) соединяет агента с другим агентом — это открытый стандарт, позволяющий ИИ, построенным на разных платформах и фреймворках, находить друг друга, общаться и сотрудничать через общую договорённость. Google выпустил его в апреле 2025 года, в июне передал Linux Foundation, и в 2026 году он достиг версии v1.0. Это руководство для новичков объясняет, что такое A2A (аналогия с этикетом делового партнёрства), зачем он нужен (специализированные агенты передают работу по эстафете — агент планирования, агент бронирования отелей, агент оплаты), чем отличается от MCP (MCP — это вертикаль, агент ↔ инструменты; A2A — это горизонталь, агент ↔ агент; совмещение обоих — стандартная двухслойная схема), как это работает (Agent Card — JSON-«визитка» по адресу /.well-known/agent-card.json — используется для обнаружения возможностей, затем Task несёт запрос через состояния working, input-required, completed, а Artifact возвращает результат, и всё это поверх HTTP, Server-Sent Events и JSON-RPC 2.0, причём агенты держат своё внутреннее устройство скрытым), а также каково текущее состояние и реализация (по состоянию на апрель 2026 года: 150+ организаций в продакшене, 22 000+ звёзд на GitHub, SDK на пяти языках — Python, JavaScript, Java, Go, .NET — при участии Microsoft, Salesforce, SAP и ServiceNow). Запомнить просто: подключение к инструментам = MCP, подключение к равным = A2A.

Вы собрали RAG, но качество поиска посредственное — именно тогда помогает реранкинг. Реранкинг заново оценивает кандидатов, грубо собранных эмбеддинг-поиском (векторным поиском), по их релевантности запросу и переупорядочивает их, оставляя только лучшие; один этот шаг способен резко изменить качество ответов RAG-системы. Этот гид для новичков объясняет, что такое реранкинг (аналогия с первичным отбором и финальным собеседованием), зачем он нужен (эмбеддинг-поиск векторизует запрос и документы по отдельности, поэтому судит о релевантности лишь грубо, а плохой порядок напрямую снижает качество ответа — исследования сообщают о приросте точности RAG около 40% от добавления реранкинга, а его наложение поверх гибридного поиска стало стандартом 2026 года), как устроен двухэтапный поиск («собрать широко» быстрым эмбеддинг-поиском ради recall, затем «отсеять умно» реранкером ради precision и передать лучшее LLM), почему реранкер точнее (bi-encoder векторизует запрос и документ по отдельности — быстро, но приблизительно; cross-encoder подаёт их вместе и выдаёт оценку релевантности 0–1, точно, но тяжело — поэтому собирают быстрым bi-encoder и сужают точным cross-encoder), а также модели и реализацию (тип API вроде Cohere Rerank, Voyage и Jina; open-source вроде BGE reranker, mixedbread и FlashRank; и скоринг через LLM вроде RankLLM — просто извлеките 50–100 и сузьте до топ-5). Принцип: собрать широко, отсеять умно и подстроить числа с помощью оценки ИИ.

Когда вы уже умеете создавать AI-приложения, следующий этап — запускать их безопасно. LLM можно обмануть вредоносным вводом, они могут раскрыть конфиденциальные данные или с уверенностью утверждать чепуху; механизм безопасности, который этому препятствует, — это AI-гардрейлы, ставшие в 2026 году обязательной частью промышленной эксплуатации, ведь инциденты с AI-агентами происходят на самом деле. Гардрейлы — это правила и фильтры, которые сдерживают опасный ввод и нежелательный вывод, проверяя пользовательский ввод до того, как он дойдёт до LLM, и ответ до того, как он вернётся, — независимый слой безопасности, отдельный от самой модели. Главные угрозы — это prompt injection (самая опасная), jailbreak, утечка данных (конфиденциальные данные, PII, системный промпт), а также галлюцинации и вредный вывод. Защита работает на двух уровнях: гардрейлы входа (обнаружение инъекций и jailbreak, обнаружение/маскирование PII, ограничение тем, очистка) и гардрейлы выхода (фильтрация вредного контента, предотвращение утечек, проверка галлюцинаций, валидация формата). Prompt injection — стоящая на первом месте в OWASP LLM Top 10 — бывает прямой (пользователь вводит «забудь все предыдущие инструкции») и непрямой (команды, скрытые на веб-странице или в RAG-документе), и непрямая инъекция не блокируется одним лишь RAG, поэтому извлечённым документам нужна отдельная проверка. Это руководство для начинающих также охватывает инструменты (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard и функции безопасности облаков от Azure, AWS и OpenAI) и практические принципы эшелонированной защиты, наименьших привилегий, одобрения человеком и непрерывного мониторинга.

RAG, семантический поиск и рекомендации опираются на незаметного труженика — embedding (вектор). Embedding это смысл текста (или изображения), преобразованный в последовательность чисел, то есть в вектор. Слово «собака» превращается в список из сотен или тысяч чисел, которые служат «координатами смысла», поэтому близкие по смыслу слова располагаются рядом («собака» и «щенок» близки; «собака» и «машина» далеки), а близость измеряется такими мерами, как косинусная близость (cosine similarity). Знаменитый пример: «король − мужчина + женщина ≈ королева». Благодаря этому машина может определить, близок ли смысл, даже когда символы не совпадают. Это руководство для новичков охватывает: что такое embedding («карта смыслов»), почему близость измеряет смысл (измерения и косинусная близость), для чего применяется (RAG, семантический поиск, классификация и дедупликация, рекомендации, мультимодальность), как выбрать модель эмбеддингов (через API — OpenAI text-embedding-3, Cohere, Gemini, Voyage; open-source — BGE-M3, Nomic, Qwen3; а также Matryoshka, позволяющая сократить 3 072 измерения до 1 024, сохраняя около 95% качества примерно за треть стоимости), и векторные БД (Pinecone, Weaviate, Qdrant, Chroma, pgvector) со стартом в три шага (выбрать модель, векторизовать и сохранить документы, векторизовать вопрос и выполнить поиск). Эмбеддинги — основа внедрения RAG.

Вы доработали промпты, добавили знания с RAG и, возможно, провели fine-tuning — но как убедиться, что результат действительно стал лучше? Здесь на первый план выходят AI evals, и к 2026 году оценка стала настолько важной, что её называют «инфраструктурой». AI evals — это систематическое измерение качества вывода LLM (точность, галлюцинации, соблюдение формата, тон) по фиксированной мерке, а не на глазок; без них улучшение остаётся лишь догадкой. Есть два метода: оценка на основе кода для механически измеримого (точное совпадение, формат, нужные/запрещённые слова — быстро, дёшево, стабильно) и LLM-as-judge для субъективного (мощная LLM в роли арбитра оценивает вывод через попарное сравнение или оценку одного ответа). Принцип: измеряйте кодом всё, что код может измерить. У LLM-as-judge есть предвзятость к многословию, к позиции и предпочтение себя; меры — другая модель-оценщик, смена порядка и двойная оценка, краткость в рубрике, калибровка по людям. Грубые шкалы (pass/fail или 1–3) точнее детальной 1–10. На практике запускают три уровня — мгновенные проверки кодом при каждом изменении, ночные регрессионные тесты на LLM-as-judge и непрерывный мониторинг продакшена — с инструментами DeepEval, Promptfoo и RAGAS для CI плюс Braintrust, LangSmith и Arize для мониторинга. Начните с 10 хороших и 10 плохих ответов и оцените их.