Руководство для разработчиков по созданию масштабируемого ИИ: рабочие процессы против агентов
Не так давно было время — ладно, месяца три назад, — когда я провалился глубоко в кроличью нору агента.
Я только начал экспериментировать с CrewAI и LangGraph, и мне казалось, что я открыл совершенно новое измерение в строительстве. Внезапно у меня появились не просто инструменты и конвейеры — у меня появились команды. Я мог создавать агентов, которые могли рассуждать, планировать, взаимодействовать с инструментами и друг с другом. Мультиагентные системы! Агенты, вызывающие других агентов! Я практически создавал ИИ-версию команды стартапа.
Каждый вариант использования становился кандидатом в команду. Подготовка к встрече? Экипаж. Создание слайдов? Экипаж. Обзор лабораторного отчета? Экипаж.
Это было захватывающе — пока не перестало быть таковым.
Чем больше я создавал, тем чаще сталкивался с вопросами, о которых не задумывался.: Как мне это контролировать? Как мне отладить цикл, в котором агент просто продолжает “думать”? Что происходит, когда что-то ломается? Может ли кто-нибудь еще поддерживать это вместе со мной?
Вот тогда я понял, что пропустил важный вопрос: Действительно ли это должно быть агентным? Или мне просто не терпелось воспользоваться новой блестящей вещью?
С тех пор я стал намного осторожнее — и намного практичнее. Потому что, согласно Антропологии, существует большая разница между:
- Рабочий процесс: структурированный конвейер LLM с четким потоком управления, где вы определяете шаги — используете инструмент, извлекаете контекст, вызываете модель, обрабатываете выходные данные.
- И агент: автономная система, в которой магистр права решает, что делать дальше, какие инструменты использовать и когда все “готово”.
Рабочие процессы больше похожи на то, что вы отдаете приказы, а магистр права следует вашим указаниям. Агенты больше похожи на блестящего, немного хаотичного стажера, который сам во всем разбирается — иногда красиво, иногда ужасающе дорого.
Эта статья предназначена для всех, кто когда-либо испытывал такое же искушение построить многоагентную империю, прежде чем продумать, что нужно для ее поддержания. Это не предупреждение, это проверка на практике и руководство к действию. Потому что иногда агенты - это именно то, что вам нужно. Но в большинстве случаев? Вам просто нужен четкий рабочий процесс.
Ситуация с ИИ-агентами: Все этим занимаются, но никто не знает почему
Вы, наверное, видели статистику. Согласно опросу Bain, проведенному в 2024 году, 95% компаний в настоящее время используют генеративный ИИ, а 79% внедряют ИИ-агентов специально. Это звучит впечатляюще, пока вы не присмотритесь повнимательнее и не обнаружите, что только 1% из них считают эти внедрения “зрелыми”.
Перевод: большинство команд что-то склеивают и надеются, что это не взорвется в процессе производства.
Я говорю это с любовью — я был одним из них.
Наступает момент, когда вы впервые создаете работающую агентскую систему, даже небольшую, и это кажется волшебством. Магистр права решает, что делать, выбирает инструменты, повторяет шаги и возвращается с ответом, как будто он только что совершил мини-путешествие. Вы думаете: “Зачем мне снова писать жесткие конвейеры, если я могу просто позволить модели разобраться с этим?”
И тогда сложность возрастает.
Вы переходите от простого конвейера к сети юристов, владеющих инструментами, которые рассуждают по кругу. Вы начинаете писать логику, чтобы скорректировать логику агента. Вы создаете агента для контроля за другими агентами. Не успеете оглянуться, как вы уже поддерживаете распределенную систему стажеров, испытывая беспокойство и не ощущая затрат.
Да, есть реальные истории успеха. Агент Klarna обслуживает 700 представителей службы поддержки клиентов. BCG разработала мультиагентную систему проектирования, которая сократила время проектирования судов почти вдвое. Это не демонстрационные материалы — это производственные системы, которые реально экономят время и деньги компаний.
Но эти компании появились там не случайно. За кулисами они инвестировали в инфраструктуру, наблюдаемость, резервные системы, бюджетный контроль и команды, которые могли отлаживать цепочки запросов в 3 часа ночи без слез.
Для большинства из нас? Мы не Klarna. Мы пытаемся создать что-то работающее, что было бы надежным, экономически эффективным и не потребляло бы в 20 раз больше токенов, чем хорошо структурированный конвейер.
Так что да, агенты могут быть замечательными. Но мы должны перестать притворяться, что они используются по умолчанию. То, что модель может решать, что делать дальше, не означает, что так и должно быть. Динамичность потока не означает, что система интеллектуальна. И то, что все так делают, не означает, что вы должны следовать за ними.
Иногда использование агента — это все равно что заменить микроволновую печь на су-шефа: более гибкий подход, но и более дорогой, им сложнее управлять, а иногда он принимает решения, о которых вы не просили.
Давайте разберемся, когда на самом деле имеет смысл идти по этому пути, а когда вам следует просто придерживаться того, что работает.
Техническая проверка на практике: что вы на самом деле выбираете
Прежде чем мы углубимся в экзистенциальный кризис выбора между агентами и рабочими процессами, давайте разберемся с нашими определениями. Потому что в обычной технической среде все используют эти термины для обозначения немного разных вещей.
Рабочие процессы: Надежный друг, который приходит вовремя
Рабочие процессы организованы. Вы пишете логику: возможно, извлекаете контекст из хранилища векторов, вызываете набор инструментов, затем используете LLM для обобщения результатов. Каждый шаг является четким. Это как рецепт. Если что—то сломается, вы точно знаете, где это произошло - и, вероятно, как это исправить.
Это то, чем являются большинство “тряпичных конвейеров” или цепочек подсказок. Контролируемый. Поддается тестированию. Стоимость предсказуема.
В чем прелесть? Вы можете отлаживать их так же, как и любое другое программное обеспечение. Трассировка стека, журналы, резервная логика. Если векторный поиск завершается неудачей, вы перехватываете его. Если ответ модели странный, вы перенаправляете его.
Рабочие процессы - это ваш надежный друг, который приходит вовремя, придерживается плана и не начинает переписывать всю схему базы данных, потому что она кажется “неэффективной”.
В этом примере простой задачи поддержки клиентов этот рабочий процесс всегда выполняется по одному и тому же шаблону "классифицировать" → "маршрут" → "ответить" → "журнал". Он предсказуем, поддается отладке и работает стабильно.
def customer_support_workflow(customer_message, customer_id):
"""Predefined workflow with explicit control flow"""
# Step 1: Classify the message type
classification_prompt = f"Classify this message: {customer_message}\nOptions: billing, technical, general"
message_type = llm_call(classification_prompt)
# Step 2: Route based on classification (explicit paths)
if message_type == "billing":
# Get customer billing info
billing_data = get_customer_billing(customer_id)
response_prompt = f"Answer this billing question: {customer_message}\nBilling data: {billing_data}"
elif message_type == "technical":
# Get product info
product_data = get_product_info(customer_id)
response_prompt = f"Answer this technical question: {customer_message}\nProduct info: {product_data}"
else: # general
response_prompt = f"Provide a helpful general response to: {customer_message}"
# Step 3: Generate response
response = llm_call(response_prompt)
# Step 4: Log interaction (explicit)
log_interaction(customer_id, message_type, response)
return response
Детерминированный подход обеспечивает:
- Предсказуемое выполнение: ввод A всегда приводит к процессу B, а затем к результату C
- Явная обработка ошибок: “Если это сломается, выполните это конкретное действие”.
- Прозрачная отладка: вы можете буквально отследить весь код, чтобы найти проблемы
- Оптимизация ресурсов: вы точно знаете, сколько все это будет стоить
Внедрение рабочих процессов обеспечивает стабильную отдачу для бизнеса: OneUnited Bank добился 89% конверсии по кредитным картам, а Sequoia Financial Group сэкономила 700 часов в год на одного пользователя. Не так сексуально, как “автономный искусственный интеллект”, но ваша оперативная команда полюбит вас.
Агенты: Умный парень, который иногда выходит из-под контроля
Агенты, с другой стороны, строятся по принципу замкнутого цикла. Магистр права ставит перед собой цель и начинает размышлять о том, как ее достичь. Он выбирает инструменты, предпринимает действия, оценивает результаты и решает, что делать дальше — и все это в рамках рекурсивного цикла принятия решений.
Вот тут-то и начинается... веселье.
Архитектура предоставляет поистине впечатляющие возможности:
- Динамический выбор инструмента: “Следует ли мне запросить базу данных или обратиться к API? Дайте мне подумать...”
- Адаптивное мышление: учимся на ошибках в рамках одного диалога
- Самокоррекция: “Это не сработало, давайте я попробую другой подход”
- Комплексное управление состоянием: отслеживание того, что произошло три шага назад.
В том же примере агент может решить сначала выполнить поиск в базе знаний, затем получить платежную информацию, а затем задать уточняющие вопросы — все это основано на его интерпретации потребностей клиента. Путь выполнения может варьироваться в зависимости от того, что агент обнаруживает в процессе анализа:
def customer_support_agent(customer_message, customer_id):
"""Agent with dynamic tool selection and reasoning"""
# Available tools for the agent
tools = {
"get_billing_info": lambda: get_customer_billing(customer_id),
"get_product_info": lambda: get_product_info(customer_id),
"search_knowledge_base": lambda query: search_kb(query),
"escalate_to_human": lambda: create_escalation(customer_id),
}
# Agent prompt with tool descriptions
agent_prompt = f"""
You are a customer support agent. Help with this message: "{customer_message}"
Available tools: {list(tools.keys())}
Think step by step:
1. What type of question is this?
2. What information do I need?
3. Which tools should I use and in what order?
4. How should I respond?
Use tools dynamically based on what you discover.
"""
# Agent decides what to do (dynamic reasoning)
agent_response = llm_agent_call(agent_prompt, tools)
return agent_response
Да, именно автономия делает агентов могущественными. Это также затрудняет их контроль.
Ваш агент может:
- решить попробовать новую стратегию, но на полпути
- забыть, что он уже пробовал
- , или вызвать инструмент 15 раз подряд, пытаясь “разобраться во всем”
Вы не можете просто установить точку останова и проверить стек. “Стек” находится внутри контекстного окна модели, а “переменные” - это нечеткие мысли, сформированные вашими подсказками.
Когда что—то пойдет не так — а это обязательно произойдет - вы не получите красивого красного сообщения об ошибке. Вы получаете счет за токены, который выглядит так, будто кто-то неправильно ввел условие цикла и вызвал OpenAI API 600 раз. (Я знаю, потому что я делал это по крайней мере один раз, когда забыл закрыть цикл, и агент просто продолжал думать... и думать... пока вся система не рухнула с ошибкой “не хватает токена”).
Проще говоря, вы можете представить это так:
Рабочий процесс - это навигатор.
Вы знаете пункт назначения. Вы следуете четким инструкциям. “Поверните налево. Здесь выполните слияние. Вы прибыли”. Он структурирован, предсказуем, и вы почти всегда попадаете туда, куда направляетесь, если только специально не игнорируете его.
С агентом все по-другому. Это все равно, что дать кому-то карту, смартфон, кредитную карточку и сказать:
“Придумайте, как добраться до аэропорта. Вы можете дойти пешком, вызвать такси, сделать крюк, если нужно, — просто сделайте так, чтобы это сработало”.
Они могут прибыть быстрее. Или же они могут в конечном итоге поспорить с приложением для совместного катания, совершить живописный обход и приехать через час со смузи за 18 долларов. (Мы все знаем таких людей).
Оба подхода могут сработать, но главный вопрос в том, что:
Вам действительно нужна автономия или просто надежный набор инструкций?
Дело в том, что агенты — это звучит потрясающе. И теоретически так оно и есть. Вы, наверное, видели заголовки газет:
- “Внедрите агента, который будет управлять всей вашей системой поддержки!”
- “Позвольте ИИ управлять вашими задачами, пока вы спите!”
- “Революционные мультиагентные системы — ваша персональная консалтинговая фирма в облаке!”
Эти примеры можно найти повсюду. И некоторые из них реальны. Но большинство из них?
Они похожи на фотографии из путешествий в Instagram. Вы видите яркий закат, идеальную линию горизонта. Вы не замечаете шестичасовых переездов, опоздания на поезд, сэндвича в аэропорту за 25 долларов или трехдневной желудочной колики от уличных тако.
Вот что часто упускается из виду в историях успеха агентов: сложность работы, трудности с отладкой, растущий счет за токены.
Так что да, агенты могут подвести вас к решению проблем. Но прежде чем передавать ключи, убедитесь, что вас устраивает маршрут, который они могут выбрать. И что вы можете позволить себе платить за проезд.
Скрытые издержки, о которых никто не говорит
На бумаге агенты кажутся волшебными. Вы ставите перед ними цель, и они понимают, как ее достичь. Нет необходимости жестко программировать процесс управления. Просто определите задачу, и пусть система справится с остальным.
В теории это элегантно. На практике это хаос в пальто.
Давайте поговорим о том, во что на самом деле обходится переход на agentic — не только в долларах, но и в плане сложности, возможных сбоев и эмоционального износа вашей команды инженеров.
Стоимость токенов быстро растет
Согласно исследованию Anthropic, агенты потребляют в 4 раза больше токенов, чем при простом взаимодействии в чате. Мультиагентные системы? Попробуйте использовать в 15 раз больше токенов. Это не ошибка — в этом весь смысл. Они зацикливаются, рассуждают, переоценивают и часто разговаривают сами с собой по нескольку раз, прежде чем принять решение.
Вот как выглядит эта математика.:
- Основные рабочие процессы: 500 долларов в месяц за 100 тысяч взаимодействий.
- Одноагентные системы: 2000 долларов в месяц за тот же объем работы
- Многоагентные системы: 7500 долларов в месяц (при условии, что за 1 тыс. токенов приходится 0,005 доллара)
И это при условии, что все работает должным образом.
Если агент застрянет в цикле вызовов инструментов или неправильно истолкует инструкции? Вы увидите всплески, из-за которых ваша панель выставления счетов будет похожа на график криптографической обработки данных.
Отладка похожа на археологию искусственного интеллекта
С рабочими процессами отладка похожа на прогулку по хорошо освещенному дому. Вы можете отследить ввод → функцию → вывод. Легко.
С агентами? Это больше похоже на блуждание по не нанесенному на карту лесу, где деревья иногда меняются местами. Вы не получаете традиционные логические записи. Вы получаете логические цепочки, полные сгенерированных моделью мыслей, таких как:
“Хм, это не сработало. Я попробую другой подход”.
Это не трассировка стека. Это запись в дневнике искусственного интеллекта. Это поэтично, но бесполезно, когда что-то ломается в процессе производства.
По-настоящему “забавная” часть? Распространение ошибок в системах агентов может происходить совершенно непредсказуемым образом. Одно неверное решение на ранней стадии логической цепочки может завести агента в кроличью нору, где все более неверные выводы становятся все более очевидными, как в телефонной игре, где каждый игрок также пытается решить математическую задачу. Традиционные подходы к отладке — установка точек останова, отслеживание путей выполнения, проверка состояний переменных — становятся гораздо менее полезными, когда “ошибка” заключается в том, что ваш искусственный интеллект решил творчески интерпретировать ваши инструкции.
Новые режимы сбоев, о которых вам никогда не приходилось задумываться
Исследование Microsoft выявило совершенно новые режимы сбоев, которых не было до появления агентов. Вот лишь некоторые из них, которые не распространены в традиционных конвейерах:
- Внедрение агента: эксплойты на основе подсказок, которые нарушают логику агента
- Джейлбрейки с несколькими агентами: Агенты вступают в непреднамеренный сговор
- Отравление памяти: Один агент портит общую память галлюцинаторным бредом
Это уже не крайние случаи — они становятся настолько распространенными, что теперь существуют целые подполя “LLMOps”, предназначенные только для их обработки.
Если ваш стек мониторинга не отслеживает дрейф токенов, спам от инструментов или непредвиденное поведение агентов, вы действуете вслепую.
Вам понадобится информация, которой у вас, вероятно, нет
Системы, основанные на агентах, нуждаются не только в вычислениях - им нужны новые уровни инструментария.
Вероятно, в конечном итоге вам придется собрать какое-то сочетание:
- LangFuse, Arize или Phoenix для обеспечения наблюдаемости
- AgentOps для мониторинга затрат и поведения пользователей
- Настраиваемые средства защиты токенов и резервные стратегии для предотвращения зацикливания
Этот набор инструментов необязателен. Он необходим для обеспечения стабильности вашей системы.
А если вы еще этого не делаете? Вы не готовы к использованию агентов в производстве — по крайней мере, тех, которые влияют на реальных пользователей или деньги.
Так что да. Дело не в том, что агенты “плохие”. Просто они намного дороже — в финансовом, техническом и эмоциональном плане, — чем кажется большинству людей, когда они впервые начинают с ними играть.
Сложность в том, что в демоверсии этого нет. В демоверсии все выглядит чисто. Контролируемый. Впечатляющий.
Но в процессе производства происходит утечка информации. Система зацикливается. Контекстные окна переполняются. И вам остается объяснять своему начальнику, почему ваша система искусственного интеллекта потратила 5000 долларов на расчет наилучшего времени для отправки электронного письма.
Когда агенты действительно имеют смысл
[Прежде чем мы углубимся в истории успеха агентов, небольшая проверка на практике: это закономерности, выявленные при анализе текущих реализаций, а не универсальные законы архитектуры программного обеспечения. Ваш опыт может быть разным, и существует множество организаций, успешно использующих рабочие процессы для сценариев, в которых агенты теоретически могут преуспеть. Подумайте об этих обоснованных наблюдениях, а не о божественных заповедях, высеченных на кремнии.]
Вот несколько сценариев, в которых агенты действительно зарабатывают себе на жизнь.
Главное - понять разницу между “Я хочу попробовать агентов, потому что они классные” и “этот вариант использования на самом деле требует автономии”.
Потому что иногда агенты - это именно то, что вам нужно. Они великолепны в том смысле, в каком жесткие рабочие процессы просто невозможны.
Хорошо. До сих пор я распространял множество предупреждений о системах агентов, но я здесь не для того, чтобы отпугивать вас навсегда.
Динамичные разговоры с высокими ставками
Допустим, вы создаете систему поддержки клиентов. Некоторые запросы просты — статус возврата средств, сброс пароля и т.д. Простой рабочий процесс прекрасно справляется с ними.
Но другие разговоры? Они требуют адаптации. Логические рассуждения. Определение приоритетности следующего вопроса в режиме реального времени на основе того, что говорит пользователь.
Вот в чем преимущество агентов.
В таких условиях вы не просто заполняете форму — вы управляете ситуацией. Персонализированное устранение неполадок, рекомендации по продукту, переговоры о заключении контракта — все это вопросы, в которых следующий шаг полностью зависит от того, что произошло.
Компании, внедряющие системы поддержки клиентов на базе агентов, сообщают о высокой рентабельности инвестиций - мы говорим об увеличении эффективности и конверсий на 112-457% в зависимости от отрасли. Потому что, когда все сделано правильно, агентурные системы кажутся более умными. И это приводит к росту доверия.
Принятие решений с высокой отдачей и небольшим объемом работы
Агенты стоят дорого. Но иногда решения, с которыми они помогают, обходятся дороже.
BCG помогла судостроительной фирме сократить на 45% инженерные затраты, используя мультиагентную систему проектирования. Это того стоит, потому что от этих решений зависели многомиллионные результаты.
Если вы оптимизируете прокладку оптоволоконного кабеля по всему континенту или анализируете юридические риски в контракте, который затрагивает всю вашу компанию, проблема не в том, чтобы потратить несколько лишних долларов на вычисления. Неправильное решение - это.
Агенты работают здесь, потому что цена ошибки намного выше, чем стоимость вычислений.
Открытые исследования
Существуют проблемы, когда вы буквально не можете заранее определить блок—схему, потому что не знаете, что такое “правильные шаги”.
Агенты отлично разбираются в неоднозначных задачах, разбивают их на части, повторяют то, что находят, и адаптируются в режиме реального времени.
Подумайте:
- Ассистенты по техническим исследованиям, которые читают, обобщают и сравнивают статьи
- Роботы для анализа продуктов, которые изучают конкурентов и обобщают информацию
- Исследовательские агенты, которые исследуют нестандартные ситуации и выдвигают гипотезы
Это не проблемы, связанные с известными процедурами. Они по своей природе являются замкнутыми циклами, и агенты преуспевают в них.
Многоэтапные, непредсказуемые рабочие процессы
В некоторых задачах слишком много ветвей, чтобы их можно было жестко запрограммировать — например, когда выполнение всех условий “если это, то то” становится работой на полный рабочий день.
Именно здесь циклы агентов могут на самом деле упростить задачу, поскольку LLM обрабатывает поток динамически, основываясь на контексте, а не на заранее написанной логике.
Подумайте о диагностике, инструментах планирования или системах, которые должны учитывать десятки непредсказуемых переменных.
Если ваше логическое дерево начинает походить на диаграмму—спагетти, составленную осьминогом с кофеином, - да, возможно, пришло время позволить модели взять штурвал в свои руки.
Так что нет, я не против агентов (на самом деле, я их люблю!) Я за то, чтобы инструмент соответствовал задаче.
Когда в сценарии использования требуется гибкость, адаптация и автономность, тогда да — привлекайте агентов. Но только после того, как вы будете честны с самим собой относительно того, решаете ли вы действительно сложную задачу ... или просто стремитесь к блестящей абстракции.
Когда рабочие процессы, очевидно, будут Лучше (но менее захватывающими)
[Опять же, это наблюдения, основанные на анализе отрасли, а не на незыблемых правилах. Несомненно, существуют компании, успешно использующие агентов для регламентированных процессов или приложений, требующих больших затрат, - возможно, потому, что у них есть особые требования, исключительный опыт или бизнес—модели, которые меняют экономику. Рассматривайте это как рекомендации для начинающих, а не как ограничения на то, что возможно.]
Давайте на секунду вернемся назад.
Многие разговоры об архитектуре искусственного интеллекта завязли в шумихе: “Будущее за агентами!” “AutoGPT может создавать компании!” — но в реальных производственных средах большинству систем не нужны агенты.
Им нужно что-то, что работает.
Вот тут-то и возникают рабочие процессы. И хотя они могут показаться не такими футуристичными, они невероятно эффективны в тех средах, для которых большинство из нас разрабатывают.
Повторяемые операционные задачи
Если ваш вариант использования включает в себя четко определенные шаги, которые редко меняются, например, отправку дополнительных сообщений, пометку данных, проверку правильности ввода в форму, то рабочий процесс всегда будет превосходить работу агента.
Дело не только в стоимости. Речь идет о стабильности.
Вам не нужны творческие решения в вашей системе расчета заработной платы. Вы хотите каждый раз получать один и тот же результат без каких-либо неожиданностей. Хорошо структурированный конвейер дает вам это.
В “надежности процессов” нет ничего привлекательного — до тех пор, пока ваша агентная система не забудет, какой сейчас год, и не отметит каждого сотрудника как несовершеннолетнего.
Регулируемая среда, поддающаяся аудиту
Рабочие процессы детерминированы. Это означает, что их можно отследить. Это означает, что если что—то пойдет не так, вы можете точно показать, что произошло - шаг за шагом - с помощью журналов, резервных копий и структурированных выходных данных.
Если вы работаете в сфере здравоохранения, финансов, юриспруденции или в правительстве — в тех сферах, где “мы считаем, что ИИ решил попробовать что—то новое” - это неприемлемый ответ, - это важно.
Вы не можете создать безопасную систему ИИ без прозрачности. Рабочие процессы обеспечивают это по умолчанию.
Сценарии с высокой частотой и низкой сложностью
Существуют целые категории задач, для которых стоимость одного запроса имеет большее значение, чем сложность аргументации. Думать:
- Получение информации из базы данных
- Анализ электронных писем
- Ответы на запросы в стиле "Часто задаваемых вопросов"
Рабочий процесс может обрабатывать тысячи таких запросов в минуту при предсказуемых затратах и задержках, с нулевым риском сбоев.
Если вы быстро масштабируетесь и хотите оставаться экономичным, структурированный конвейер лучше, чем умный агент.
Стартапам, MVP и проектам "Простосделай это"
Агентам требуется инфраструктура. Мониторинг. Наблюдаемость. Отслеживание затрат. Оперативная архитектура. Резервное планирование. Проектирование памяти.
Если вы не готовы вкладывать средства во все это — а большинство команд, работающих на ранней стадии, к этому не готовы, - агентов, вероятно, слишком много и слишком рано.
Рабочие процессы позволяют вам быстро продвигаться вперед и изучать поведение LLM, прежде чем приступать к рекурсивному анализу и отладке возникающего поведения.
Подумайте об этом так: рабочие процессы - это то, как вы переходите к производству. Агенты - это то, как вы масштабируете конкретные варианты использования, когда глубоко понимаете свою систему.
Одна из лучших ментальных моделей, которые я видел (ссылка на инженерный блог Anthropic), такова:
Используйте рабочие процессы для создания структуры, основанной на предсказуемом. Используйте агентов, чтобы исследовать непредсказуемое.
Большинство систем искусственного интеллекта в реальном мире представляют собой смесь, и многие из них сильно зависят от рабочих процессов, потому что производство не поощряет сообразительность. Это поощряет устойчивость.
Система принятия решений, которая действительно работает
Вот кое—что, что я усвоил (на собственном горьком опыте, конечно): большинство неудачных архитектурных решений принимаются не из-за недостатка знаний, а из-за того, что все происходит слишком быстро.
Вы действуете синхронно. Кто—то говорит: “Это кажется слишком динамичным для рабочего процесса - может быть, мы просто воспользуемся агентами?”
Все кивают. Звучит разумно. Агенты гибки, не так ли?
Перенесемся на три месяца вперед: система работает с перебоями, логи нечитаемы, затраты растут, и никто не помнит, кто предложил использовать агентов в первую очередь. Вы просто пытаетесь понять, почему магистр права решил удовлетворить запрос на возврат средств, забронировав авиабилет в Перу.
Итак, давайте на секунду притормозим.
Речь идет не о выборе самого модного варианта, а о создании чего—то, что вы можете объяснить, масштабировать и поддерживать на практике.
Приведенный ниже фреймворк разработан для того, чтобы заставить вас задуматься, прежде чем накопятся деньги за токены, и ваш симпатичный прототип превратится в очень дорогую приключенческую историю.
Процесс оценки: Потому что решения, принимаемые одним фактором, приводят к гибели проектов
Это не дерево решений, которое сдается при первом же “звучит заманчиво”. Это структурированная оценка. Вы проходите по пяти параметрам, оцениваете каждый из них и видите, чего на самом деле требует система, а не только то, что звучит забавно.
Вот как это работает:
- Каждое измерение дает +2 балла как рабочему процессу, так и агентам.
- Один вопрос дает +1 балл (надежность).
Суммируйте все это в конце — и вы будете доверять результату больше, чем своим рекламным заявлениям агентов.
Сложность задачи (2 балла)
Оцените, содержит ли ваш вариант использования четко определенные процедуры. Можете ли вы описать шаги, которые позволяют обрабатывать 80% ваших сценариев, не прибегая к маханию руками?
Да → +2 для рабочих процессов
Нет, есть неоднозначность или динамическое ветвление → +2 для агентов
Если в ваших инструкциях содержатся фразы типа “а потом система все выяснит”, то, скорее всего, вы находитесь на территории агента.
Ценность бизнеса в сравнении с Громкость (2 балла)
Оцените холодную и жесткую экономичность вашего варианта использования. Это крупномасштабная, чувствительная к затратам операция или сценарий с малым объемом работ и высокой стоимостью?
- Большой объем и предсказуемость → +2 для рабочих процессов
- Решения с небольшим объемом работ, но с высокой отдачей → +2 для агентов
В принципе, если затраты на вычисления более значительны, чем небольшие ошибки, выигрывают рабочие процессы. Если ошибки обходятся дорого, а медлительность приводит к потере денег, возможно, агенты того стоят.
Требования к надежности (1 балл)
Определите, насколько вы терпимы к вариативности выходных данных, и честно определите, что на самом деле нужно вашему бизнесу, а не то, что кажется гибким и современным. Какую степень вариативности выходных данных может выдержать ваша система?
- Должна быть последовательной и отслеживаемой (аудиты, отчеты, клинические рабочие процессы) → +1 для рабочих процессов
- Может справиться с некоторыми вариациями (творческими задачами, поддержкой клиентов, исследованиями) → +1 для агентов
Этот параметр часто упускается из виду, но он напрямую влияет на то, сколько логики guardrail вам нужно будет написать (и поддерживать).
Техническая готовность (2 балла)
Оцените свои текущие возможности без “розовых очков”: "мы разберемся с этим позже". Каковы ваши текущие технические настройки и уровень комфорта?
- У вас есть ведение журнала, традиционный мониторинг и команда разработчиков, которая еще не создала agentic infra → +2 для рабочих процессов
- У вас уже есть наблюдаемость, резервные планы, отслеживание токенов и команда, которая понимает поведение ИИ в новых условиях → +2 для агентов
Это проверка зрелости вашей системы. Будьте честны с самим собой. Надежда - это не стратегия отладки.
Организационная зрелость (2 балла)
Оцените опыт вашей команды в области искусственного интеллекта с абсолютной честностью — дело не в интеллекте, а в опыте работы с конкретными странностями систем искусственного интеллекта. Насколько ваша команда опытна в оперативном проектировании, оркестровке инструментов и в LLM-странностях?
- Все еще изучаете оперативное проектирование и поведение LLM → +2 для рабочих процессов
- Освоение распределенных систем, циклов LLM и динамического мышления → +2 для агентов
Здесь вы не оцениваете интеллект, а просто имеете опыт работы с определенным классом проблем. Агентам требуется более глубокое знакомство с моделями сбоев, характерными для ИИ.
Суммируйте свои оценки
После завершения всех пяти тестов подсчитайте общее количество баллов.
- Оценка рабочего процесса ≥ 6 → Придерживайтесь рабочих процессов. Вы поблагодарите себя позже.
- Оценка агента ≥ 6 → Агенты могут быть жизнеспособными, если нет критичных для рабочего процесса блокировщиков.
Важно: этот фреймворк не говорит вам, что самое крутое. Он говорит вам, что является устойчивым.
Многие варианты использования будут сильно зависеть от рабочего процесса. Это не потому, что агенты плохие, а потому, что истинная готовность агентов предполагает согласованную работу многих систем: инфраструктуры, зрелости операционного процесса, знаний команды, обработки сбоев и контроля затрат.
И если чего—то из этого не хватает, обычно не стоит рисковать - пока.
Поворот сюжета: Вам не нужно выбирать.
Я жалею, что не осознал этого раньше: вам не нужно выбирать ту или иную сторону. Волшебство часто исходит от гибридных систем, где рабочие процессы обеспечивают стабильность, а агенты — гибкость. Это лучшее из обоих миров.
Давайте рассмотрим, как это работает на самом деле.
Почему гибрид имеет смысл
Представьте его как многоуровневый:
- Реактивный уровень (ваш рабочий процесс): выполняет предсказуемые задачи большого объема
- Совещательный уровень (ваш агент): принимает сложные, неоднозначные решения
Именно так создаются многие реальные системы. Рабочий процесс выполняет 80% предсказуемой работы, в то время как агент выполняет 20%, требующих творческого осмысления или планирования
Создание гибридных систем шаг за шагом
Вот усовершенствованный подход, который я использовал (и позаимствовал из лучших практик в области гибридных технологий).:
Определите основной рабочий процесс.
Наметьте свои предсказуемые задачи — извлечение данных, векторный поиск, вызов инструментов, обобщение ответов.
Определите точки принятия решений.
Где вам может понадобиться агент для принятия динамических решений?
Дополните эти этапы облегченными агентами.
Думайте о них как об узкоспециализированных механизмах принятия решений — они планируют, действуют, размышляют, а затем возвращают ответы в рабочий процесс.
Разумно используйте память и планируйте циклы.
Предоставьте агенту достаточно контекста, чтобы он мог принимать разумные решения, не допуская сбоев.
Отслеживайте и корректно завершайте работу.
Если работа агента выходит из-под контроля или затраты резко возрастают, вернитесь к ветви рабочего процесса по умолчанию. Поддерживайте работу журналов и счетчиков токенов.
Контрольная точка "Человек в цикле".
Особенно в регламентированных потоках или потоках с высокими ставками, сделайте паузу для проверки человеком перед выполнением критически важных действий агента
Когда следует использовать гибридный подход
Это согласуется с тем, как такие системы, как WorkflowGen, n8n и собственный инструментарий Anthropic, рекомендуют создавать стабильные конвейеры с ограниченной автономией.
Реальные примеры: Гибрид в действии
Минимальный пример гибрида
Вот сценарий, который я использовал с LangChain и LangGraph:
- Этап рабочего процесса: получение заявок в службу поддержки, внедрение и поиск
- Ячейка агента: решите, будет ли это вопрос о возврате средств, жалоба или сообщение об ошибке
- Рабочий процесс: запустите правильную ветку на основе тега агента
- Этап проверки: если это жалоба, обобщите ее мнение и предложите следующие шаги
- Рабочий процесс: отформатируйте и отправьте ответ; регистрируйте все
Результат? Большинство заявок оформляется без участия агентов, что снижает затраты и сложность. Но когда возникает неопределенность, агент вмешивается и добавляет реальную ценность. Никаких неоплачиваемых счетов за токены. Четкая прослеживаемость. Автоматическое резервное копирование.
Этот шаблон разделяет логику между структурированным рабочим процессом и агентом с ограниченной областью действия. (Примечание: это демонстрация высокого уровня)
from langchain.chat_models import init_chat_model
from langchain_community.vectorstores.faiss import FAISS
from langchain_openai import OpenAIEmbeddings
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langgraph.prebuilt import create_react_agent
from langchain_community.tools.tavily_search import TavilySearchResults
# 1. Workflow: set up RAG pipeline
embeddings = OpenAIEmbeddings()
vectordb = FAISS.load_local(
"docs_index",
embeddings,
allow_dangerous_deserialization=True
)
retriever = vectordb.as_retriever()
system_prompt = (
"Use the given context to answer the question. "
"If you don't know the answer, say you don't know. "
"Use three sentences maximum and keep the answer concise.\n\n"
"Context: {context}"
)
prompt = ChatPromptTemplate.from_messages([
("system", system_prompt),
("human", "{input}"),
])
llm = init_chat_model("openai:gpt-4.1", temperature=0)
qa_chain = create_retrieval_chain(
retriever,
create_stuff_documents_chain(llm, prompt)
)
# 2. Agent: Set up agent with Tavily search
search = TavilySearchResults(max_results=2)
agent_llm = init_chat_model("anthropic:claude-3-7-sonnet-latest", temperature=0)
agent = create_react_agent(
model=agent_llm,
tools=[search]
)
# Uncertainty heuristic
def is_answer_uncertain(answer: str) -> bool:
keywords = [
"i don't know", "i'm not sure", "unclear",
"unable to answer", "insufficient information",
"no information", "cannot determine"
]
return any(k in answer.lower() for k in keywords)
def hybrid_pipeline(query: str) -> str:
# RAG attempt
rag_out = qa_chain.invoke({"input": query})
rag_answer = rag_out.get("answer", "")
if is_answer_uncertain(rag_answer):
# Fallback to agent search
agent_out = agent.invoke({
"messages": [{"role": "user", "content": query}]
})
return agent_out["messages"][-1].content
return rag_answer
if __name__ == "__main__":
result = hybrid_pipeline("What are the latest developments in AI?")
print(result)
Что здесь происходит:
- Сначала выполняется рабочий процесс.
- Если результат кажется слабым или неопределенным, за дело берется агент.
- Вы оплачиваете услуги агента только тогда, когда это действительно необходимо.
Простой. Контролируемый. Масштабируемый.
Дополнительно: Мультиагентное выполнение, управляемое рабочим процессом
Если ваша задача действительно требует использования нескольких агентов — скажем, в задаче исследования или планирования — структурируйте систему в виде графика, а не набора рекурсивных циклов. (Примечание: это демонстрация высокого уровня)
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langchain.chat_models import init_chat_model
from langgraph.prebuilt import ToolNode
from langchain_core.messages import AnyMessage
# 1. Define your graph's state
class TaskState(TypedDict):
input: str
label: str
output: str
# 2. Build the graph
graph = StateGraph(TaskState)
# 3. Add your classifier node
def classify(state: TaskState) -> TaskState:
# example stub:
state["label"] = "research" if "latest" in state["input"] else "summary"
return state
graph.add_node("classify", classify)
graph.add_edge(START, "classify")
# 4. Define conditional transitions out of the classifier node
graph.add_conditional_edges(
"classify",
lambda s: s["label"],
path_map={"research": "research_agent", "summary": "summarizer_agent"}
)
# 5. Define the agent nodes
research_agent = ToolNode([create_react_agent(...tools...)])
summarizer_agent = ToolNode([create_react_agent(...tools...)])
# 6. Add the agent nodes to the graph
graph.add_node("research_agent", research_agent)
graph.add_node("summarizer_agent", summarizer_agent)
# 7. Add edges. Each agent node leads directly to END, terminating the workflow
graph.add_edge("research_agent", END)
graph.add_edge("summarizer_agent", END)
# 8. Compile and run the graph
app = graph.compile()
final = app.invoke({"input": "What are today's AI headlines?", "label": "", "output": ""})
print(final["output"])
Этот шаблон позволяет вам:
- Управлять маршрутизацией и памятью на уровне рабочего процесса
- При необходимости использовать логику на уровне агента
- Ограниченные циклы вместо бесконечной рекурсии агента
Именно так должны работать такие инструменты, как LangGraph: структурированная автономия, а не произвольные рассуждения.
Производственное внедрение — где теория встречается с реальностью
Все архитектурные схемы, деревья решений и дебаты на доске в мире не спасут вас, если ваша система искусственного интеллекта развалится в тот момент, когда ею начнут пользоваться реальные пользователи.
Потому что именно здесь все становится запутанным — входные данные зашумлены, число крайних случаев бесконечно, а пользователи обладают волшебной способностью ломать все так, как вы и представить себе не могли. Производственный трафик обладает индивидуальностью. Он протестирует вашу систему так, как никогда не смогла бы ваша среда разработки.
И именно на этом спотыкается большинство проектов с использованием искусственного интеллекта.
Демонстрация работает. Прототип впечатляет заинтересованных лиц. Но затем вы выходите в эфир — и внезапно модель начинает галлюцинировать именами клиентов, использование ваших токенов резко возрастает без объяснения причин, и вы по уши погружаетесь в логи, пытаясь понять, почему все оборвалось в 3:17 ночи (правдивая история!).
Это разрыв между классным доказательством концепции и системой, которая на самом деле работает в реальных условиях. Именно здесь разница между рабочими процессами и агентами перестает быть философской и становится очень, очень действенной.
Используете ли вы агентов, рабочие процессы или какой—то промежуточный гибрид - как только вы начинаете работать, это уже другая игра.
Вы больше не пытаетесь доказать, что ИИ может работать.
Вы пытаетесь убедиться, что он работает надежно, доступно и безопасно — каждый раз.
Итак, что же для этого нужно на самом деле?
Давайте разберемся.
Мониторинг (потому что “Это работает на моем компьютере” не масштабируется)
Мониторинг системы агентов — это не просто “приятно иметь”, это инструмент выживания.
Вы не можете относиться к агентам как к обычным приложениям. Традиционные инструменты APM не объяснят вам, почему LLM решил повторить вызов инструмента 14 раз или почему было потрачено 10 000 токенов на подведение итогов к абзацу.
Вам нужны инструменты для обеспечения наблюдаемости, которые говорят на языке агента. Это означает отслеживание:
- схемы использования токенов,
- частота обращений к инструментам,
- распределение задержек ответа,
- результаты выполнения задач
- и стоимость взаимодействия — все это в режиме реального времени.
Вот где пригодятся такие инструменты, как LangFuse, AgentOps и Arize Phoenix. Они позволяют заглянуть в "черный ящик" — увидеть, какие решения принимает агент, как часто он повторяет действия и что выходит из-под контроля до того, как это произойдет с вашим бюджетом.
Потому что, когда что-то ломается, сообщение “ИИ сделал странный выбор” не является полезным сообщением об ошибке. Вам нужны отслеживаемые логические цепочки и журналы использования, а не только вибрации и всплески токенов.
Для сравнения, рабочие процессы намного проще отслеживать.
У вас есть:
- время отклика,
- частота ошибок,
- использование процессора / памяти
- и пропускная способность запросов.
Все обычные функции, которые вы уже отслеживаете с помощью стандартного стека APM — Datadog, Grafana, Prometheus, что угодно. Никаких неожиданностей. Никаких циклов, пытающихся спланировать свой следующий шаг. Только четкие, предсказуемые пути выполнения.
Так что да — оба требуют мониторинга. Но агентные системы требуют совершенно нового уровня наглядности. Если вы к этому не готовы, продакшн убедит вас в этом на собственном горьком опыте.
Управление затратами (до того, как ваш финансовый директор приступит к вмешательству)
Потребление токенов на производстве может выйти из-под контроля быстрее, чем вы успеете сказать “автономное рассуждение”.
Все начинается с малого — несколько дополнительных обращений к инструментам, цикл повторных попыток — и не успеете оглянуться, как вы потратите половину своего месячного бюджета на отладку одного диалога. Особенно в случае с агентскими системами, затраты не просто увеличиваются, они усугубляются.
Вот почему умные команды относятся к управлению затратами как к инфраструктуре, а не как к чему-то второстепенному.
Некоторые распространенные (и необходимые) стратегии:
- Динамическая модель маршрутизации — используйте упрощенные модели для простых задач, приберегая дорогостоящие для тех случаев, когда это действительно важно.
- Кэширование — если один и тот же вопрос возникает сто раз, вам не стоит платить за то, чтобы отвечать на него сто раз.
- Предупреждения о расходах — автоматические флажки, указывающие на странности в использовании, чтобы вы не узнали о проблеме от своего финансового директора.
Для агентов это имеет еще большее значение.
Потому что, как только вы передаете управление логическому циклу, вы теряете представление о том, сколько шагов он предпримет, сколько инструментов вызовет и как долго будет “думать”, прежде чем выдать ответ.
Если у вас нет отслеживания затрат в режиме реального времени, ограничений по бюджету для каждого агента и гибких резервных вариантов, вы всего в нескольких шагах от очень дорогостоящей ошибки.
Агенты умны. Но они недешевы. Планируйте соответственно.
Рабочие процессы также требуют управления затратами.
Если вы обращаетесь к LLM по каждому пользовательскому запросу, особенно по этапам поиска, обобщения и создания цепочки, то цифры суммируются. А если вы используете GPT-4 повсеместно из соображений удобства? Вы почувствуете это в счете-фактуре.
Но рабочие процессы предсказуемы. Вы знаете, сколько вызовов вы совершаете. Вы можете выполнять предварительный расчет, пакетную обработку, кэширование или замену в небольших моделях без нарушения логики. Стоимость линейно и предсказуемо увеличивается.
Безопасность (поскольку автономный ИИ и безопасность - Лучшие друзья).
Безопасность ИИ — это уже не просто защита конечных точек, это подготовка к работе с системами, которые могут принимать собственные решения.
Вот тут—то и возникает концепция "сдвига влево" - более раннего внедрения безопасности в жизненный цикл разработки.
Вместо того чтобы зацикливаться на безопасности после того, как ваше приложение “заработает”, переключение влево означает разработку с учетом требований безопасности с самого первого дня: во время оперативного проектирования, настройки инструментов и конвейера.
С помощью агентных систем вы не просто защищаете предсказуемое приложение. Вы защищаете что—то, что может самостоятельно принимать решение о вызове API, доступе к личным данным или инициировании внешнего действия - часто способами, которые вы явно не программировали. Это совсем другая область угроз.
Это означает, что ваша стратегия безопасности нуждается в доработке. Вам потребуется:
- Управление доступом на основе ролей для каждого инструмента, к которому может получить доступ агент
- Обеспечение минимальных привилегий для внешних вызовов API
- Контрольные записи, позволяющие фиксировать каждый шаг в рассуждениях и поведении агента
- Моделирование угроз для новых атак, таких как быстрое внедрение, олицетворение агента и совместный джейлбрейк (да, сейчас это модно).
Большинство традиционных систем безопасности приложений предполагают, что поведение определяется кодом. Но в случае агентов поведение динамично и определяется подсказками, инструментами и пользовательским вводом. Если вы создаете автономные приложения, вам нужны средства управления безопасностью, рассчитанные на непредсказуемость.
Но как насчет рабочих процессов?
Они проще, но не безопасны.
Рабочие процессы детерминированы. Вы определяете путь, управляете инструментами, и нет цикла принятия решений, который может выйти из-под контроля. Это упрощает безопасность и делает ее более тестируемой, особенно в средах, где важны соответствие требованиям и проверяемость.
Тем не менее, рабочие процессы обрабатывают конфиденциальные данные, интегрируются со сторонними сервисами и выдают результаты, ориентированные на пользователя. Это означает, что:
- Быстрое внедрение по-прежнему вызывает беспокойство
- По-прежнему важна очистка выходных данных
- Ключи API, доступ к базе данных и обработка личных данных по-прежнему нуждаются в защите
Для рабочих процессов “сдвиг влево” означает:
- Заблаговременная проверка форматов ввода/вывода
- Выполнение оперативных тестов на риск внедрения
- Ограничение доступа каждого компонента, даже если это “кажется безопасным”
- Автоматизация повторного объединения и тестирования с учетом пользовательского ввода
Дело не в паранойе, а в защите вашей системы до того, как она заработает и реальные пользователи начнут вводить в нее неожиданные данные.
Независимо от того, создаете ли вы агенты, рабочие процессы или гибриды, правило одно и то же:
Если ваша система может генерировать действия или выходные данные, ее можно использовать.
Поэтому создавайте так, чтобы кто—то попытался это сломать, потому что рано или поздно кто-то, вероятно, это сделает.
Методологии тестирования (потому что принцип “Доверяй, но проверяй” применим и к ИИ)
Тестирование производственных систем ИИ похоже на проверку качества очень умного, но немного непредсказуемого стажера.
Они имеют в виду только хорошее. Обычно они все делают правильно. Но время от времени они удивляют вас — и не всегда в хорошем смысле.
Вот почему вам нужны уровни тестирования, особенно когда вы имеете дело с агентами.
Для агентных систем одна ошибка в рассуждениях может привести к целой цепочке странных решений. Одно неверное суждение на ранней стадии может привести к неправильным вызовам инструментов, ошибочным выводам или даже к утечке данных. А поскольку логика заключается в подсказке, а не в статической блок-схеме, вы не всегда сможете выявить эти проблемы с помощью традиционных тестовых примеров.
Оперативная проверка - потому что некоторые вещи, такие как тональность или нюансы предметной области, по-прежнему требуют оценки со стороны человека
Надежная стратегия тестирования обычно включает:
- Изолированные среды с тщательно разработанными макетными данными для стресс-тестирования крайних случаев
- Поэтапное развертывание с ограниченным количеством реальных данных для мониторинга поведения перед полным развертыванием
- Автоматизированные регрессионные тесты для проверки неожиданных изменений выходных данных между версиями модели
- Для агентов это необязательно. Это единственный способ предотвратить непредсказуемое поведение.
Но как насчет рабочих процессов?
Их проще тестировать — и, честно говоря, это одна из их самых сильных сторон.
Поскольку рабочие процессы подчиняются детерминированному сценарию, вы можете:
- Писать модульные тесты для каждой функции или вызова инструмента
- Аккуратно моделировать внешние службы
- Делайте снимки ожидаемых входных/выходных данных и проверяйте их на согласованность
- Проверяйте крайние случаи, не беспокоясь о рекурсивных рассуждениях или циклах планирования
Вы по—прежнему хотите тестировать подсказки, предотвращать внедрение подсказок и отслеживать выходные данные, но при этом площадь поверхности меньше, а поведение отслеживается. Вы знаете, что происходит, когда на шаге 3 происходит сбой, потому что вы написали шаг 4.
Рабочие процессы не устраняют необходимость в тестировании — они делают его тестируемым.
Это очень важно, когда вы пытаетесь создать что-то, что не развалится в тот момент, когда оно попадет в реальные данные.
Честная рекомендация: Начинайте с простого, намеренно масштабируйте
Если вы зашли так далеко, то, вероятно, вам нужна не реклама, а система, которая действительно работает.
Итак, вот честный, немного несексуальный совет:
Начните с рабочих процессов. Добавляйте агентов только тогда, когда вы можете четко обосновать необходимость.
Рабочие процессы могут показаться не революционными, но они надежны, поддаются тестированию, объяснимы и предсказуемы с точки зрения затрат. Они объясняют, как ваша система ведет себя в рабочей среде. Они предоставляют вам журналы, резервные пути и структуру. И самое главное: они получаются объемными.
Это не ограничение. Это зрелость.
Это как научиться готовить. Вы не начинаете с молекулярной кухни — вы начинаете с изучения того, как не подгорает рис. Рабочие процессы - это ваш рис. Ингредиенты - это пена.
И когда вы столкнетесь с проблемой, которая на самом деле требует динамичного планирования, гибкого мышления или самостоятельного принятия решений, вы узнаете об этом. Это произойдет не потому, что в твиттере вам сказали, что будущее за агентами. Это произойдет потому, что вы наткнетесь на стену, которую рабочие процессы не смогут преодолеть. И в этот момент вы будете готовы к работе с агентами — и ваша инфраструктура тоже будет готова.
Посмотрите на клинику Майо. Они используют 14 алгоритмов для каждой ЭКГ — не потому, что это модно, а потому, что это повышает точность диагностики в масштабе. Или возьмем компанию Kaiser Permanente, которая утверждает, что ее системы клинической поддержки, основанные на искусственном интеллекте, помогают спасать сотни жизней каждый год.
Это не демонстрация технологий, созданная для того, чтобы произвести впечатление на инвесторов. Это реальные производственные системы, которые обрабатывают миллионы случаев — тихо, надежно и с огромным эффектом.
В чем секрет? Дело не в выборе агентов или рабочих процессов.
Речь идет о глубоком понимании проблемы, осознанном выборе правильных инструментов и обеспечении устойчивости, а не внезапности.
