Как построить команду ИИ-агентов, которая работает без вас
Как построить команду ИИ-агентов, которая работает без вас
Команда OM-Digital
Москва, 2026
Глава 1. От инструмента к компании — что такое мультиагентная система
Глава 2. Разделение ответственности — принцип «один агент, одна роль»
Глава 3. Что такое агент простыми словами
Глава 4. Как агенты вообще могут «договариваться»
Глава 5. Секретарь — зачем нужна такая роль в системе
Глава 6. Производство и контроль качества — идея разделения труда
Глава 7. Организационная структура — как это выглядит на примере OM-Digital
Глава 8. Несколько ИИ-«сотрудников» одновременно
Глава 9. Может ли агент работать с браузером сам
Глава 10. Что дальше, если хочется построить своё
Что дальше: практика в Telegram-боте @om_ai_teacher_bot
Есть момент, который у большинства предпринимателей, начавших работать с ИИ, происходит одинаково. Сначала — восторг: нейросеть пишет текст за минуту, отвечает клиенту, считает таблицу. Потом — привычка: вы уже не удивляетесь, просто открываете чат каждое утро, как раньше открывали почту. А потом наступает третий момент, о котором в этой книге, собственно, и пойдёт речь: вы упираетесь в потолок одного помощника.
Потолок выглядит примерно так. У вас уже есть ИИ, который пишет вам тексты, отвечает на вопросы, может даже открыть файл и что-то в нём поправить. Но всё это по-прежнему держится на вас: вы формулируете задачу, вы решаете, что делать с результатом, вы же и следите, чтобы ничего не потерялось между «написал» и «отправил клиенту». Один помощник, каким бы умным он ни был, — это всё ещё вы за клавиатурой, просто печатаете вы меньше.
Дальше есть два пути. Первый — смириться с потолком: он не так уж и низок, многим бизнесам его хватает годами. Второй — понять, что помощника можно не просто сделать умнее, а перестроить саму схему работы: не один ИИ на все руки, а несколько ИИ-ролей, каждая из которых отвечает за свой участок и передаёт результат дальше — так же, как в обычной компании один сотрудник не пытается быть одновременно бухгалтером, менеджером по продажам и контролёром качества.
Именно об этом втором пути — эта книга. Не про то, как заставить один чат работать быстрее, а про то, как из нескольких ИИ-ролей собирается что-то похожее на настоящую компанию: с разделением труда, с внутренней перепиской между ролями, с проверкой качества, с руководителем, который не делает всю работу сам, а координирует тех, кто делает.
Чтобы разговор не был абстрактным, мы будем постоянно возвращаться к одному реальному примеру — компании OM-Digital. Это небольшая цифровая компания, которой мы управляем вместе с командой ИИ-агентов: секретарь принимает заявки, маркетинг пишет тексты, отдельный агент следит за качеством, финансовый директор считает деньги, ещё несколько агентов ищут заказы на биржах фриланса и анализируют рынок. Люди в этой схеме — учредители — не сидят за клавиатурой весь день, разбирая заявки одну за другой. Они видят результат и принимают решения там, где решение действительно нужно человеку.
Мы не будем в этой книге разбирать, как именно устроен файл настройки каждого агента, или показывать код, который заставляет их обмениваться задачами. Это сознательно: подробная механика — материал для отдельного, куда более практического курса, где мы действительно собираем такую систему шаг за шагом, с шаблонами и обратной связью. Здесь наша задача другая — дать вам верную карту местности: что вообще такое агент, чем несколько агентов отличаются от одного, какие роли обязательно нужны в такой системе, а какие можно добавить позже, и, самое важное, — стоит ли вам вообще идти в эту сторону.
Если вы уже пробовали автоматизацию — настраивали одного ИИ-помощника, поручали ему рутину, может быть, даже читали нашу предыдущую книгу об этом, — то дальше как раз ваш следующий шаг. Если ещё не пробовали — тоже нормально, просто держите в голове, что всё, о чём пойдёт речь дальше, не про фантастику и не про «искусственный интеллект, который заменит всех сотрудников». Это про вполне конкретную, работающую сегодня схему организации труда, где часть ролей выполняют люди, а часть — ИИ, и где граница между ними — это ваш осознанный выбор, а не случайность.
Честности ради стоит сразу обозначить, кому эта книга адресована, а кому — нет, потому что от этого зависит, получите ли вы от неё пользу или просто прочитаете любопытный текст без применения. Если вы ни разу не пробовали работать с ИИ дальше разового вопроса в чате — вам сначала нужна не эта книга, а более базовый разговор о том, как вообще начать разговаривать с нейросетью и получать пользу с первого дня; это отдельная тема, которую я разбираю в первой книге серии. Если вы уже освоили простую автоматизацию — поручаете ИИ рутинные задачи, работаете с документами и таблицами через него, но всё ещё в формате «один помощник — я сам всем управляю», — это как раз ваш следующий шаг, и вторая книга серии как раз про эту стадию.
Эта, третья книга — для тех, кто уже прошёл обе предыдущие стадии, хотя бы своим опытом, а не обязательно чтением этих книг: у вас уже есть привычка поручать ИИ конкретные задачи, вы видите, что задач становится больше, чем может унести один диалог, и вы всё чаще замечаете, что именно вы — то самое узкое место, через которое обязана пройти каждая мелочь. Если это про вас — читайте дальше, дальше будет по делу. Если нет — ничего страшного, вернётесь к этой книге, когда до неё дозреете; лишним это чтение точно не будет, но пользы принесёт больше именно на своей стадии.
Десять глав книги идут не хаотично, а по нарастающей — от самого общего вопроса к самому конкретному. Сначала мы разберёмся, чем компания на нескольких агентах вообще отличается от одного мощного помощника, и почему разделение труда между узкими ролями работает лучше, чем один универсальный исполнитель. Дальше — что такое агент на самом базовом уровне и как несколько агентов вообще умудряются «сотрудничать», не разговаривая друг с другом напрямую. Потом — две ключевые роли, без которых система не держится: секретарь как единственный голос компании наружу и разделение производства от контроля качества. Ещё через две главы поднимемся на уровень выше — к организационной структуре целой компании — и посмотрим, что даёт параллельная работа нескольких ролей одновременно и может ли агент сам действовать в браузере, а не только отвечать текстом. Последняя глава — честный разговор о том, кому стоит идти строить такую систему прямо сейчас, а кому имеет смысл повременить.
Каждая глава закончена сама по себе — вы можете читать книгу подряд, а можете вернуться к отдельной главе позже, когда конкретный вопрос станет актуальным именно для вас. И в конце каждой главы, и в конце всей книги мы будем показывать, куда идти дальше, если конкретная тема отозвалась и вам захотелось не просто понять принцип, а разобрать его на практике, с шаблонами и обратной связью, — это отдельный, куда более глубокий разговор, который просто не помещается в формат книги.
Прежде чем идти дальше, стоит договориться о значении слова, которое вынесено в заголовок, — «компания». Мы используем его не в юридическом смысле — не как форму регистрации бизнеса или размер штата, — а в смысле рабочей организации: устойчивой, повторяющейся структуры, в которой разные роли выполняют разную работу и передают результат друг другу по понятному порядку. По этому определению небольшой интернет-магазин, которым управляет один человек с парой ИИ-ролей, вполне может быть «компанией» в том смысле, который важен для этой книги, — а крупная организация с десятками сотрудников, где все процессы держатся на одной перегруженной голове руководителя, компанией в этом смысле может и не быть, несмотря на юридический статус и штатное расписание.
Это разграничение важно держать в голове весь оставшийся текст: когда мы говорим «управляемая ИИ компания», мы не имеем в виду фантастический сценарий, где искусственный интеллект заменяет собой владельца или принимает стратегические решения без его участия. Мы имеем в виду вполне приземлённую вещь — организацию труда, где часть повторяющихся ролей выполняет ИИ, а решения, требующие суждения и ответственности, по-прежнему принимает человек. Ничего фантастического, зато вполне достижимого уже сегодня, даже для очень небольшого бизнеса.
Мы могли бы построить эту книгу вокруг придуманного, абстрактного примера — «представим себе компанию Х», — так часто делают в бизнес-литературе, чтобы не привязываться к реальным деталям и не выглядеть уязвимым перед вопросом «а точно ли у вас самих так работает». Мы сознательно выбрали другой путь: рассказывать на примере реально работающей сегодня OM-Digital, со всеми её настоящими ролями, настоящей структурой и настоящими, не всегда идеальными компромиссами.
Причина простая: придуманный пример всегда звучит более гладко, чем реальный, — в нём легко нарисовать идеальную схему, которая на бумаге выглядит убедительно, а на практике никогда не проверялась. Реальный пример честнее, даже если местами выглядит менее эффектно: в нём видно, где решения принимались не потому, что «так красиво по теории», а потому что именно так пришлось поступить, столкнувшись с конкретной проблемой. Именно эта прикладная, слегка неидеальная честность и должна, как нам кажется, убедить вас сильнее, чем любая отполированная гипотетическая схема.
Начнём с самого главного вопроса: чем компания, устроенная из нескольких агентов, вообще отличается от одного очень старательного помощника.
Представьте день с одним ИИ-помощником. Утром вы открываете чат и пишете: «напиши пост про новую услугу». ИИ пишет пост. Вы его читаете, что-то правите, копируете в соцсеть. Через час пишет клиент — вы копируете его сообщение в тот же чат: «ответь вежливо, уточни бюджет». ИИ отвечает, вы копируете обратно клиенту. Вечером вы просите посчитать, сколько денег пришло за неделю, — открываете таблицу, пересказываете цифры чату, получаете сводку.
Во всех трёх случаях помощник отработал прекрасно. Но обратите внимание, кто на самом деле держит всю систему в голове: вы. Именно вы решаете, какую задачу дать сейчас, именно вы переносите результат из одного места в другое, именно вы помните, что пост нужно было согласовать до обеда, а ответ клиенту — отправить сразу. Помощник экономит вам время на формулировку и написание. Он не экономит время на управление процессом — потому что процессом по-прежнему управляете вы, вручную, в голове.
Это не недостаток инструмента. Один чат и не должен уметь больше — он создан как собеседник, а не как система. Проблема появляется тогда, когда задач становится много, а роли, которые нужны бизнесу, — разные: кто-то должен писать тексты, кто-то — отвечать клиентам, кто-то — считать деньги, кто-то — проверять качество перед отправкой. Пытаться впихнуть всё это в один диалог — то же самое, что нанять одного сотрудника и просить его быть одновременно копирайтером, продавцом, бухгалтером и корректором. Технически возможно. Практически — рано или поздно что-то теряется.
Мультиагентная система — это не «ИИ, но помощнее». Это другой принцип организации: вместо одного универсального собеседника — несколько ИИ-ролей, каждая из которых занимается своим участком и общается с остальными не как с абстрактным чатом, а как с коллегой, у которого есть своя зона ответственности.
Разница похожа на разницу между фрилансером-универсалом и небольшой командой. Фрилансер сделает всё сам — от идеи до финального файла. Команда распределит: один придумывает, другой пишет, третий проверяет. Фрилансер быстрее там, где задача маленькая и predictable. Команда выигрывает там, где задач много, они разные, а качество каждого этапа имеет значение.
Ключевое слово здесь — «система». Не набор отдельных чатов с разными именами, а связанные роли, между которыми есть понятный порядок передачи работы: кто-то принимает задачу первым, кто-то её выполняет, кто-то проверяет, кто-то докладывает о результате. Как только этот порядок появляется — у вас уже не «несколько ИИ», а мультиагентная система, пусть даже маленькая, из трёх-четырёх ролей.
Полезно на секунду забыть про ИИ и вспомнить, как устроена любая работающая компания — даже самая маленькая, из двух-трёх человек. Она никогда не описывается просто списком того, что умеет делать: «умеет писать тексты, умеет отвечать клиентам, умеет считать деньги». Она описывается тем, как эти умения связаны друг с другом: кто первым видит заявку клиента, кто решает, кому её передать, что происходит, если результат не устроил клиента, кто в итоге отвечает за то, чтобы деньги дошли до счёта.
Мультиагентная система — это попытка перенести именно эту связность, а не просто набор способностей, на команду из ИИ-ролей. Важно не то, что у вас есть агент, который умеет писать тексты. Важно то, что у вас выстроен путь: заявка → распределение → выполнение → проверка → сдача → учёт. Каждый шаг этого пути может выполнять отдельная роль — человек или ИИ, не имеет значения. Значение имеет то, что путь целиком продуман и работает без ежедневного ручного склеивания кусков вами лично.
Когда мы только начинали выстраивать OM-Digital, всё действительно происходило в одном чате: мы формулировали задачу, получали текст, сами решали, куда его отправить. Первым звоночком, что так дальше не поедет, стало банальное совпадение по времени — заявка от клиента на сайт и заявка на карточки товара пришли почти одновременно, а мы физически не могли одинаково внимательно вести оба диалога сразу, постоянно переключаясь между контекстами и теряя нить то в одном, то в другом.
Решение оказалось не «работать быстрее», а разделить ответственность. Сегодня в компании есть отдельная роль-секретарь, которая первой видит любую входящую заявку и решает, какому направлению она принадлежит. Есть производственные роли — маркетинг, направление AI Studio, бизнес-аналитика, автоматизация — каждая отвечает только за свой тип работы и не пытается закрывать чужую. Есть отдельная роль контроля качества, которая проверяет результат до того, как он уйдёт клиенту, а не после жалобы. Есть финансовый директор, который считает деньги по каждому заказу и не занимается ничем, кроме учёта. И есть координирующая роль — по сути, руководитель этой маленькой системы, — которая не пишет тексты и не отвечает клиентам напрямую, а следит, чтобы все остальные роли работали слаженно, и докладывает о результатах учредителям компании.
Ни одна из этих ролей по отдельности не сложнее того первого единого чата. Сложность не в том, что каждая роль стала «умнее». Сложность — и, честно говоря, главная ценность — в том, что появилась структура, которая сама разводит задачи по нужным рукам, вместо того чтобы всё держалось на моей голове.
Важно сразу закрыть один соблазнительный, но опасный вывод. Мультиагентная система — это не «поставил и забыл», не автопилот, который сам ведёт бизнес без вашего участия. Это, скорее, хорошо спроектированный офис, где каждый знает свою работу, — но офис по-прежнему нуждается в собственнике, который задаёт направление, разбирает нестандартные ситуации и принимает решения там, где цена ошибки высока: деньги, репутация, необратимые действия.
Разница с ручным режимом не в том, что вы перестаёте участвовать в бизнесе. Разница в том, что вы перестаёте быть узким местом, через которое обязана пройти каждая мелкая операция. Вы переключаетесь из режима «я делаю всё сам» в режим «я вижу, как работает система, и вмешиваюсь там, где это действительно нужно». Это не про меньше работы вообще — это про то, чтобы ваша работа была работой владельца компании, а не оператора одного чата.
Идея разделить работу на роли и передавать задачи по цепочке не нова — так устроена практически любая компания уже сотни лет, задолго до всякого ИИ. Что изменилось за последние год-два — это то, что роли в такой цепочке впервые можно заполнить не только людьми, но и ИИ, причём достаточно надёжным, чтобы доверить ему не разовую подсказку, а постоянный участок работы.
Раньше «автоматизация» бизнеса означала жёсткие скрипты и формы: если клиент написал ровно так, как предусмотрено, — сработает; если чуть иначе — сломается или ответит невпопад. Такую хрупкую автоматизацию невозможно было выстроить в полноценную цепочку ролей, потому что один сбой на любом из этапов останавливал всё дальше по цепочке. Современные модели ИИ ведут себя иначе: они не требуют от собеседника точной формулировки, разбираются в контексте, могут гибко реагировать на нестандартную ситуацию — а значит, впервые действительно можно поручить им не узкую механическую функцию, а полноценную роль с элементом суждения, как это было бы у живого сотрудника. Именно это техническое взросление и сделало мультиагентные системы практичными для малого бизнеса, а не только темой исследовательских лабораторий.
Полезно иметь для себя простой ориентир, а не абстрактную теорию, чтобы понять, дозрели вы до идей этой книги или нет. Сигнал обычно один и тот же, в разных формулировках: вы ловите себя на том, что открываете один и тот же чат с ИИ по нескольким совершенно разным поводам за один день, и каждый раз заново приходится «переключать» его — то вы просите написать текст, то посчитать деньги, то ответить клиенту, — и в какой-то момент начинаете путать, какой контекст вы уже объяснили, а какой ещё нет.
Другой похожий сигнал — ощущение, что задачи начинают конкурировать за ваше внимание не потому что их физически много, а потому что каждая требует, чтобы именно вы лично держали в голове весь путь от начала до конца: кто уже видел эту заявку, что с ней сделано, куда её передать дальше. Если оба этих ощущения вам знакомы — не разово, а как повторяющийся паттерн недели, — это довольно надёжный признак, что дело не в том, что вам нужен ИИ помощнее, а в том, что пришло время перестроить саму схему работы, о которой и пойдёт речь в оставшихся главах.
Часто слово «компания» ошибочно ассоциируют с размером: якобы, чтобы называться компанией, а не просто предпринимателем с помощником, нужны офис, штат, обороты. Для целей этой книги важнее другое измерение — не размер, а разнообразие ролей, которые реально задействованы в работе. Один человек, который сам пишет тексты, сам считает деньги, сам ищет клиентов и сам проверяет качество, — формально «компания из одного человека», но по сути это тот же единственный универсальный исполнитель, просто без вывески. А небольшая структура из нескольких по-настоящему разделённых ролей — пусть даже совсем скромная по деньгам и оборотам — уже устроена как компания в том смысле, который важен для этой книги: с разделением труда и понятным путём задачи от начала до конца.
Именно поэтому уместно говорить о «компании, которой управляет ИИ», применительно даже к очень небольшому бизнесу: дело не в количестве сотрудников или размере выручки, а в том, что появилась настоящая внутренняя структура ролей вместо одного человека, разрывающегося между всем сразу.
Прежде чем двигаться дальше, честно скажу про типичное разочарование первых недель, чтобы вы не решили, что что-то пошло не так именно у вас, если однажды окажетесь на этом пути. Почти всегда первая версия разделения ролей получается неидеальной: где-то роли всё ещё пересекаются, где-то забыли важный переход между этапами, где-то одна роль оказывается перегружена, а другая почти не задействована. Это нормальная часть процесса, а не признак того, что сама идея не работает.
Разница между рабочей и нерабочей системой — не в том, что она с первого раза спроектирована безупречно, а в том, есть ли у вас способ заметить, где именно она сбоит, и скорректировать это без необходимости переделывать всё с нуля. Именно поэтому в следующих главах мы будем возвращаться не только к тому, как выглядит хорошая роль, но и к тому, как система в целом устроена так, чтобы проблемы становились видны, а не тихо накапливались где-то в стороне от вашего внимания.
Глядя на готовую структуру OM-Digital — секретарь, несколько производственных ролей, контроль качества, финансовый учёт, отдел развития, отдел рекламы, — легко подумать, что построить такую систему можно только сразу целиком, большим и сложным проектом. На практике всё было ровно наоборот: система росла ролью за ролью, и каждая следующая появлялась только тогда, когда предыдущая уже устойчиво работала и стало ясно видно, чего именно не хватает.
Это важно держать в голове, потому что самая частая причина, по которой люди вообще не начинают двигаться в эту сторону, — ощущение, что задача слишком большая, чтобы подступиться. На деле она никогда не решается одним прыжком: сначала выделяется одна узкая роль на месте самого болезненного узкого места, потом, когда стало легче и видно следующее узкое место, — вторая, и так далее. Мы ещё вернёмся к этому пошаговому взгляду в последней главе книги.
В следующей главе разберём первый и самый важный принцип, на котором держится вся эта структура: почему один агент должен уметь только одно, и что случается, когда эту границу размывают.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Соблазн очевиден: раз современный ИИ умеет и писать тексты, и отвечать клиентам, и анализировать таблицы, зачем плодить несколько ролей — не проще ли один мощный агент с длинной инструкцией «делай всё это»?
Проблема не в возможностях модели. Проблема в том, что происходит с качеством и предсказуемостью, когда одна роль отвечает сразу за всё. Универсальный агент с инструкцией на десять страниц рано или поздно начинает путать контексты: тон, уместный в переписке с клиентом, просачивается в финансовый отчёт; строгость, нужная при проверке качества, теряется, когда та же роль минуту назад «была» дружелюбным продавцом. Человеку тоже сложно быть одинаково хорошим продавцом и одинаково строгим контролёром одновременно — не потому что не хватает ума, а потому что это разные режимы работы, разные приоритеты, иногда прямо противоположные: продавец хочет сказать клиенту «да, сделаем», контролёр обязан быть готовым сказать «нет, это не готово».
Разделение на узкие роли решает эту проблему не за счёт того, что каждая роль становится умнее, а за счёт того, что у каждой роли — одна чёткая задача и один режим мышления. Агенту, который отвечает только за проверку текста на ошибки, незачем думать о цене услуги. Агенту, который считает деньги, незачем формулировать вежливый ответ клиенту. Каждый занят своим — и именно поэтому делает это стабильнее.
Легко ошибиться и решить, что «роль» — это просто красивое название вроде «агент-маркетолог» или «агент-бухгалтер». На деле роль — это, по сути, контракт: что именно эта роль обязана делать, что ей категорически не разрешено делать, и что она обязана передать дальше, когда её часть работы закончена.
Хорошая роль отвечает на три простых вопроса. Что входит в мою зону ответственности? Что точно не входит — даже если я технически мог бы это сделать? И кому я передаю результат, когда моя часть готова? Если хотя бы на один из этих вопросов роль не может дать чёткий ответ — значит, граница размыта, и рано или поздно эта роль начнёт либо брать на себя чужую работу, либо, наоборот, упускать то, что должна была сделать.
Например, роль «контроль качества» имеет смысл только тогда, когда ей запрещено самой же и создавать финальный результат — иначе она проверяет собственную работу, а это в лучшем случае формальность, в худшем — источник систематических ошибок, которые никто не замечает, потому что «проверяющий» и «автор» — один и тот же взгляд.
Самая частая ошибка в самодельных многоагентных схемах — это не отсутствие ролей, а их дублирование и размытость. Два агента одновременно считают, что имеют право отвечать клиенту напрямую. Или роль, которая должна была только писать тексты, по пути начинает сама решать, стоит ли вообще брать этот заказ, — хотя это решение принадлежит совершенно другой части системы.
Итог предсказуем: клиент получает два разных ответа на один вопрос, потому что откликнулись сразу два агента. Или задача выполняется дважды, потому что непонятно было, кто именно за неё отвечает. Или, наоборот, задача не выполняется вовсе, потому что каждая роль думала, что этим займётся кто-то другой.
Лечится это не усложнением инструкций — «давайте распишем подробнее» обычно только добавляет путаницы, — а обратным движением: сужением. Чем уже и однозначнее очерчена роль, тем меньше шансов, что две роли наступят друг другу на ноги. Хорошая мультиагентная система — это система с минимальным пересечением обязанностей, а не с максимальным покрытием возможностей.
В OM-Digital за тексты в широком смысле отвечают сразу несколько ролей, и на первый взгляд может показаться, что они соперничают за одни и те же задачи. Это не так, и граница между ними — хороший пример того, как работает принцип «одна роль — одна ответственность».
Маркетинговая роль отвечает за тексты, которые продают или информируют напрямую: карточки товаров, посты в соцсетях, письма, коммерческие предложения. Роль AI Studio отвечает за принципиально другой тип работы — она не пишет продающий текст для человека-читателя, а собирает логику для другого ИИ: сценарии чат-ботов, структуру базы вопросов и ответов, инструкции, по которым потом будет работать какой-нибудь другой автоматический помощник у клиента. Тексты в обоих случаях, но назначение — разное, и поэтому это разные роли, а не одна раздутая.
Точно так же бизнес-аналитика — это не маркетинг с более длинными предложениями, а отдельная зона: техническое задание, разбор рынка, регламент работы отдела. И automation-роль, которая занимается кодом и техническими настройками, никогда не лезет писать рекламный пост — даже если технически способна сформулировать текст. Граница проведена не по способностям, а по назначению результата. Именно поэтому, когда приходит новая заявка, секретарь-роль может быстро и без колебаний решить, кому её передать: у каждой роли есть чёткий периметр, а не расплывчатое «ну, в целом, тоже умеет».
Может показаться, что жёстко очерченная роль — это недостаток: агент как будто «глупее», чем мог бы быть. На практике всё наоборот. Узкая роль защищает результат от типичной болезни универсальных инструментов — расфокусировки. Роль, которая знает ровно одну задачу, может выполнять её глубже и точнее, потому что не тратит внимание на то, что к делу не относится.
Это же правило хорошо ложится и на людей: маленькая команда, где каждый чётко понимает свою зону, работает предсказуемее большой группы, где границы размыты и в критический момент никто не уверен, кто именно должен был это сделать. Мультиагентная система в этом смысле не изобретает ничего нового — она просто переносит давно известный принцип разделения труда на команду, часть которой — искусственный интеллект.
Есть простой практический тест, который помогает понять, не слишком ли широко очерчена роль, ещё до того, как система вообще заработала. Попробуйте описать задачу роли одним коротким предложением, без союза «и». «Пишет тексты для клиентов» — нормально, одна задача. «Пишет тексты для клиентов и отвечает на вопросы по оплате» — уже подозрительно, потому что здесь фактически две разные задачи, склеенные вместе просто потому, что обе показались «не очень большими» по отдельности.
Если описание роли не получается сформулировать без соединительного «и» — скорее всего, перед вами не одна роль, а две, которые по недосмотру объединили в одну. Это не значит, что маленькие по объёму роли обязательно нужно разносить по разным агентам физически — иногда экономически разумнее, чтобы формально одна роль выполняла две смежные маленькие функции. Но даже в этом случае полезно осознавать, что внутри одной роли на самом деле живут два разных контракта, и рано или поздно, когда объём работы вырастет, их придётся разделить по-настоящему.
Стоит отдельно проговорить частое заблуждение: разделение ответственности на узкие роли — это не то же самое, что физически нанять больше людей или запустить больше отдельных программ. Роль — это прежде всего логическая единица ответственности, а не обязательно отдельная технологическая единица. На ранней стадии небольшой компании вполне нормально, что одна и та же технологическая настройка выполняет две-три узкие, но по-прежнему разграниченные роли последовательно, просто переключаясь между ними как между разными «шляпами».
Важно, чтобы граница ответственности при этом оставалась чёткой: когда роль работает «в шляпе автора», она не имеет права одновременно судить о собственном качестве; когда та же настройка переключается «в шляпу контролёра», она обязана временно забыть, что только что сама написала этот текст, и посмотреть на него заново, как посторонний. Это сложнее реализовать честно, чем кажется, — соблазн «одобрить самого себя» силён даже при формальном разделении шляп, — и именно поэтому по мере роста компании имеет смысл всё же разносить критически важные проверки на действительно отдельные, независимые роли, а не полагаться на переключение шляп внутри одной.
Разделение ответственности касается не только действий, но и доступа к информации, и об этом легко забыть, сосредоточившись только на том, «кто что делает». Роль, которая пишет продающие тексты, не обязана видеть внутреннюю финансовую картину компании — ей это попросту не нужно для работы, а лишний доступ к чувствительным данным — это лишний риск без всякой пользы. Роль финансового учёта, наоборот, не обязана вникать в переписку с конкретным клиентом по поводу тона текста — ей нужны только цифры.
Здесь работает простое правило, знакомое из обычного менеджмента: доступ должен соответствовать задаче, а не должности вообще. Не «эта роль важная, пусть видит всё», а «этой роли для её конкретной работы нужно вот это, и ничего сверх того». Из этого правила рождается приятный побочный эффект: если однажды какая-то роль поведёт себя неожиданно или её настройки придётся полностью пересобрать заново, ограниченный доступ означает ограниченные последствия — она физически не могла бы натворить того, до чего у неё просто не было доступа.
Представим ситуацию, будто бы возникшую при поспешном проектировании: одной роли поручили одновременно писать ответы клиентам и вести подсчёт того, сколько денег компания заработала за неделю, — потому что «всё равно один и тот же агент под рукой, зачем плодить лишнее». Первое время это может даже работать без видимых проблем. Но постепенно начинают проявляться трещины: роль, привыкшая быть вежливой и уступчивой с клиентами, незаметно начинает так же мягко трактовать финансовые цифры — например, округлять не в ту сторону, куда следовало бы для честного учёта, просто потому что тот же самый «характер» роли, полезный в переписке, неуместен в бухгалтерии.
Заметить это удаётся не сразу — именно потому что каждый отдельный ответ клиенту выглядит нормально, и каждая отдельная цифра в отчёте выглядит правдоподобно. Проблема всплывает только тогда, когда кто-то сопоставляет отчёты за несколько недель подряд и видит непоследовательность. Хороший практический сигнал, что пора разделять слитые роли, — именно такая непоследовательность результата день ото дня, даже если по отдельности каждый результат кажется приемлемым. Она означает, что роль внутри себя разрывается между двумя разными режимами мышления, и рано или поздно один из них начинает незаметно просачиваться в другой.
Полезно закончить эту главу мыслью, которая на первый взгляд звучит парадоксально: чем более узко очерчена роль, тем свободнее она себя чувствует внутри своей задачи. Это похоже на то, как хороший специалист, глубоко знающий одну область, действует внутри неё увереннее и смелее, чем универсал, вынужденный постоянно оглядываться на соседние области, в которых разбирается поверхностно. Узость — это не клетка, а, скорее, ясно очерченная площадка, на которой можно позволить себе быть по-настоящему хорошим, а не средним сразу во всём.
Это стоит держать в голове, когда в следующий раз возникнет соблазн «на всякий случай» расширить роль ещё немного: расширение почти никогда не делает роль сильнее — оно делает её более расплывчатой, и то, что раньше выполнялось уверенно и глубоко, начинает выполняться средне и осторожно, потому что внимание теперь распределено на большее количество разных задач.
В следующей главе разберём, что вообще стоит за словом «агент» — и почему это не то же самое, что обычный чат с ИИ, даже если снаружи выглядит похоже.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Слово «агент» в последний год стало модным настолько, что успело потерять смысл — им называют и простого чат-бота с готовыми кнопками, и сложную автоматизацию, и вообще любую программу, если она хоть немного связана с ИИ. Полезно договориться о более честном определении, прежде чем двигаться дальше.
Бот с кнопками — это заранее прописанный сценарий: нажал «1» — получил ответ А, нажал «2» — ответ Б. Он не думает, он выполняет ветвление, которое кто-то заранее нарисовал. Скрипт — это программа, которая делает ровно то, что в ней написано, шаг за шагом, без права на интерпретацию.
Агент — это нечто среднее между сотрудником и инструкцией для него. У агента есть модель ИИ, которая действительно рассуждает и принимает решения по ситуации, а не просто выбирает заранее готовую ветку. И у этой модели есть роль — описание того, что именно она должна делать, в каких границах, и на что имеет право, а на что нет. Разница с ботом принципиальная: если клиент сформулирует вопрос непривычным образом, агент разберётся, о чём речь, и ответит по существу, а не упрётся в «не понимаю команду, введите 1, 2 или 3».
Не вдаваясь в техническую механику — она за пределами этой книги, — можно сказать, что у любого рабочего агента есть три составляющие, и полезно их различать, даже если вы никогда не будете настраивать это сами.
Первое — контекст: что агент знает о ситуации, в которой работает. Не «всё на свете», а именно то, что относится к его роли: например, агент, который отвечает клиентам компании, знает, чем компания занимается и как обычно строится диалог с заказчиком, — но ему не нужно и не должно быть известно всё содержимое финансовой отчётности.
Второе — инструкция роли: описание задачи, границ и стиля работы. Это не «программный код» в привычном смысле — это, скорее, письменное объяснение того, как хороший сотрудник на этой должности вёл бы себя, оформленное так, чтобы ИИ мог этим руководствоваться. Я сознательно не показываю здесь, как именно выглядит такой документ изнутри и по какой структуре его составляют, — это уже прикладной навык, а не общее понимание, и он относится к материалу практического курса.
Третье — полномочия: что агенту разрешено делать самому, а что требует решения человека. Хороший агент умеет отличать обратимое действие («написать черновик ответа») от необратимого («списать деньги», «удалить файл», «отправить финальный вариант клиенту без проверки») и по умолчанию не берёт на себя то, что относится ко второй категории.
Есть и отдельный, более сильный режим работы, о котором стоит упомянуть уже здесь: агента можно запустить так, что он вообще перестаёт останавливаться и спрашивать подтверждение перед каждым шагом, а выполняет всю цепочку действий подряд, самостоятельно. Это ускоряет работу в разы, но убирает последний барьер перед ошибкой — поэтому включать такой режим имеет смысл только для тех ролей, которым вы уже осознанно готовы доверять, и никогда для всего сразу. И здесь стоит сразу проговорить главное правило, которое касается вообще всего в этой книге: какие именно полномочия и какой доступ к информации получает агент — работает ли он в таком самостоятельном режиме, на какие сайты ему можно заходить, какие данные ему доверять, — решение всегда принимает человек, который строит систему, а не сам агент и не какая-то настройка «по умолчанию».
Если вы уже пользовались чатом с ИИ — спрашивали что-то и получали ответ, — легко подумать, что агент — это тот же самый чат, просто под другим названием. Разница в двух вещах.
Во-первых, устойчивость роли. В обычном чате вы каждый раз заново объясняете, кто вы, что вам нужно и в каком стиле отвечать, — а если забыли, помощник может ответить не так, как вы рассчитывали. У агента роль закреплена: она не «вспоминается» заново каждый раз, а является постоянной частью того, как он работает, — вне зависимости от того, кто и как сформулировал конкретный запрос.
Во-вторых, встроенность в процесс, а не в разговор. Обычный чат существует, пока вы с ним разговариваете, и заканчивается, когда вы закрываете окно. Агент — это часть более крупной системы: он получает задачу не от вас лично в моменте, а из общего потока работы (об этом подробно — в следующей главе), выполняет её и передаёт результат дальше, даже если в этот момент никто не сидит и не наблюдает за диалогом.
Проще говоря: чат — это разговор с ИИ. Агент — это сотрудник на базе ИИ, у которого есть постоянная должность в вашей системе.
Чтобы идея не осталась абстрактной, разберём самый простой из возможных агентов — без реальной структуры настройки, просто на уровне идеи.
Представьте роль, единственная задача которой — проверять готовый текст на ошибки и опечатки перед тем, как он уйдёт клиенту. У этой роли узкий контекст: ей не нужно знать историю переговоров с клиентом или цену услуги, ей нужен только сам текст. У неё простая инструкция: найти ошибки, предложить исправления, не менять смысл и стиль автора без необходимости. И у неё скромные полномочия: она не отправляет ничего сама, а возвращает исправленный вариант тому, кто попросил проверку, — обычно другой роли, которая как раз и отвечает за отправку.
Обратите внимание, насколько это отличается от «попросить тот же чат, который писал текст, самому же его перечитать». Тот же автор, проверяющий сам себя, склонен не замечать собственных ошибок — это верно и для человека, и для ИИ. Отдельная роль с узкой единственной задачей «свежим взглядом» ловит то, что автор физически не видит в собственном тексте. Это крошечный пример, но он показывает главный принцип всей мультиагентной идеи: разделение задачи между разными ролями работает лучше, чем попытка сделать всё в одном месте, даже если технически это мог бы один и тот же ИИ.
Последнее, что важно проговорить в этой главе: агент — не волшебная кнопка «сделай хорошо». Качество его работы напрямую зависит от того, насколько чётко продумана его роль — что ему разрешено, а что нет, откуда он берёт информацию, кому передаёт результат. Плохо продуманная роль даст нестабильный результат, даже если модель ИИ внутри самая мощная на рынке. Хорошо продуманная роль даёт стабильный результат даже на скромных задачах.
Это, кстати, и есть основная причина, почему проектирование ролей — отдельный навык, которому стоит учиться целенаправленно, а не собирать по кусочкам из разрозненных статей. Мы к этому ещё вернёмся ближе к концу книги.
Полезно провести и другое сравнение — не с чатом, а с настоящим наймом человека, потому что здесь тоже есть важная разница, о которой редко задумываются. Когда вы нанимаете человека на роль, вы полагаетесь на то, что он сам, своим опытом и здравым смыслом, заполнит пробелы в инструкции — доработает то, что вы не успели явно прописать, ориентируясь на общее понимание, «как это обычно делается».
С агентом это работает иначе и требует больше сознательности с вашей стороны. Агент действительно опирается на широкие общие знания о мире, но не обладает вашим личным опытом именно этого бизнеса и именно этих клиентов — если что-то важное не заложено в его роль явно, он не «дотянет» это интуицией так, как дотянул бы опытный человек, проработавший у вас полгода. Это не недостаток, а особенность, которую нужно учитывать: чем более конкретно и полно описана роль, тем стабильнее агент работает, — в отличие от человека, где иногда достаточно общей идеи должности, а детали доучиваются на практике сами собой.
Из этого следует и практический вывод для будущего: не стоит ждать от свежесозданной роли, что она «сама разберётся» в нюансах вашего бизнеса так же, как разобрался бы человек за несколько недель работы. Роль настолько хороша, насколько хорошо продумана и явно прописана её задача, — и это ответственность того, кто её создаёт, а не то, что можно списать на «недостаточно умный ИИ».
Раз агент действует по роли, а не спрашивает разрешения на каждый чих, разумный вопрос — а можно ли ему вообще доверять? Ответ здесь такой же, как с любым сотрудником: доверие выдаётся постепенно и пропорционально цене ошибки. Роли с низкой ценой ошибки — черновик текста, который в любом случае кто-то ещё прочитает и поправит, — можно смело отдавать агенту целиком. Роли с высокой ценой ошибки — отправка денег, необратимые действия, финальное решение по спорной ситуации с клиентом — по умолчанию остаются либо у человека, либо требуют его подтверждения, даже если агент технически способен справиться сам. Мы будем возвращаться к этому принципу ещё не раз, потому что именно он, а не мощность модели, определяет, насколько безопасно расширять систему.
Здесь стоит снять ещё одну возможную путаницу. Слово «агент» иногда используют для обозначения конкретной технологической настройки, а иногда — для обозначения роли, которую эта настройка выполняет прямо сейчас. Это разные вещи, и различие важно понимать, если вы когда-нибудь будете вникать в устройство подобной системы глубже. Одна и та же технологическая база — модель ИИ определённого типа — вполне может в разное время исполнять разные роли, точно так же как один и тот же человек может днём быть родителем, а вечером — тренером детской спортивной секции: он один, но ведёт себя и мыслит по-разному в зависимости от того, в какой роли находится в данный момент.
Что делает роль ролью — не «личность» технологической настройки, а именно набор из контекста, инструкции и полномочий, о которых шла речь выше. Поэтому, говоря «агент секретаря» и «агент маркетинга», мы говорим не обязательно о двух совершенно разных технологических сущностях, а о двух разных наборах правил поведения, которые в конкретной системе могут быть реализованы как угодно технически — это уже вопрос прикладной архитектуры, а не той общей картины, которую важно понимать на уровне этой книги.
Последний штрих к портрету хорошо спроектированного агента, который часто упускают: способность честно признать границу своей компетенции. Плохо продуманная роль в неясной ситуации склонна либо выдумывать правдоподобный, но неверный ответ, либо, наоборот, пытаться взять на себя решение, которое ей не принадлежит, — просто потому что «кто-то же должен ответить прямо сейчас».
Хорошо продуманная роль устроена иначе: если вопрос выходит за пределы того, что ей поручено, она не изображает уверенность, а честно передаёт вопрос дальше — человеку или другой, более подходящей роли. Это качество — умение вовремя остановиться и передать вопрос дальше — не менее важно, чем умение хорошо выполнять свою прямую задачу, и именно оно чаще всего отличает систему, которой действительно можно доверять, от системы, которая просто выглядит уверенно, но время от времени выдаёт результат там, где стоило бы промолчать и спросить.
Полезно на секунду вернуться к мини-агенту «Проверка орфографии» из этой главы и посмотреть на него ещё раз, уже глазами всех трёх составляющих, которые мы разобрали. Контекст этой роли — минимален и сознательно ограничен: только сам текст, ничего больше. Инструкция — предельно узкая: искать ошибки, не трогать смысл. Полномочия — скромные: вернуть исправленный вариант, не отправлять ничего самостоятельно.
Обратите внимание, что именно эта скромность по всем трём параметрам и делает роль надёжной. Если бы у неё был доступ к истории переговоров с клиентом, инструкция звучала как «сделай текст лучше в целом», а полномочия позволяли отправлять результат напрямую — это была бы уже совсем другая, куда менее предсказуемая роль, при том же самом «навыке» находить ошибки в тексте. Хороший агент — это не тот, у кого максимум возможностей, а тот, у кого возможности точно соответствуют задаче, ни больше, ни меньше.
В следующей главе — про то, как несколько таких ролей вообще узнают, что им пора браться за работу, если не сидеть и не передавать задачи друг другу вручную.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Допустим, у вас уже есть несколько ролей: одна принимает заявки, другая пишет тексты, третья проверяет качество. Возникает практический вопрос, который в теории звучит просто, а на практике оказывается ключевым для всей системы: как роль «принимает заявки» вообще сообщает роли «пишет тексты», что появилась новая задача? Они же не сидят в одном окне чата и не могут просто повернуться друг к другу и сказать «слушай, тут новый заказ».
Первая интуитивная идея — заставить агентов «разговаривать» друг с другом напрямую, как два человека по телефону. На небольшом масштабе это может даже сработать. Но у прямого разговора между агентами есть слабое место: если один агент занят или временно недоступен, второй не может просто передать задачу и заняться своими делами — он вынужден ждать ответа здесь и сейчас, как в телефонном звонке. А если ролей не две, а семь, и заявки идут не по одной, а десятками в час, — прямой разговор каждой роли с каждой быстро превращается в хаос: непонятно, кто кому что уже сказал и что из этого потерялось.
Более устойчивое решение — которое, кстати, задолго до ИИ придумали для обычных заводов и офисов, — это общее место, куда задачи складываются, и откуда их забирают те, кому они предназначены. Не прямой разговор «агент A агенту Б», а разговор через общий ящик: A кладёт задачу в ящик с пометкой, что это касается направления Б, а Б — когда освобождается — заглядывает в ящик, видит задачи по своему направлению и берёт их в работу.
Это снимает сразу две проблемы. Первая — не нужно, чтобы обе роли работали одновременно: A может положить задачу поздно вечером, а Б заберёт её утром, ничего не потеряется. Вторая — не нужно вручную помнить, кому что передавали: ящик — это единый список, по которому в любой момент видно, что сделано, что ещё ждёт, а что зависло без ответа дольше, чем следовало бы.
Мы намеренно не будем описывать здесь, как именно технически устроен такой ящик в реальных системах — какой формат у записей, какие поля в них обязательны. Это уже вопрос прикладной реализации, а не принципа. Принцип же прост и универсален: должно быть общее, понятное всем ролям место, где задача существует независимо от того, кто именно сейчас смотрит в этот момент в экран.
В такой схеме у каждой роли есть свой, довольно простой алгоритм поведения по отношению к общему ящику задач. Одни роли в основном кладут задачи — например, роль, которая первой встречает клиента, кладёт в ящик заявку с пометкой, какому направлению она принадлежит. Другие роли в основном забирают — например, производственная роль периодически проверяет, не появилось ли для неё новой работы, и если появилась — берёт её в обработку. Третьи делают и то, и другое: например, роль контроля качества забирает готовый черновик у одной роли и кладёт обратно в ящик исправленный вариант — уже с пометкой «готово к отправке», — откуда его заберёт совсем другая роль.
Важная деталь: задача в таком ящике всегда имеет статус — она не просто «лежит», а находится на определённом этапе своего пути: новая, взята в работу, ожидает проверки, готова к сдаче, завершена. Именно эти статусы и позволяют системе не терять задачи и не путать, кто сейчас за что отвечает — без единого живого координатора, который бы вручную раздавал работу каждому по очереди.
В OM-Digital именно так устроен путь любой входящей заявки — будь то сообщение с биржи фриланса, письмо на почту или обращение через Telegram. Заявка сначала попадает в общий поток входящих задач. Секретарь-роль просматривает этот поток, определяет, к какому направлению относится обращение — маркетинг, AI Studio, бизнес-аналитика или автоматизация, — и помечает задачу соответствующим образом, оставляя её в общем потоке уже с этой пометкой.
Производственная роль нужного направления, работая по своему расписанию, видит в потоке задачи со своей пометкой и берёт их в работу одну за другой. Закончив, она не отправляет результат клиенту напрямую — это сознательное ограничение, отдельно закреплённое как правило компании: результат возвращается в общий поток с пометкой «готово к проверке», откуда его забирает роль контроля качества. И только после этой проверки задача переходит в статус «готова к сдаче», а отправляет её клиенту снова секретарь — та же роль, что и приняла заявку изначально, замыкая цикл.
Ни на одном из этих шагов роли не списываются друг с другом напрямую в духе «я сейчас тебе лично сообщу». Каждая роль просто честно делает свою часть и оставляет результат там, где его найдёт следующий по цепочке. Такая система устойчива именно потому, что не требует, чтобы все участники работали синхронно, — а в компании, где часть работы делают люди, а часть роли работают в разное время суток, асинхронность — это не недостаток, а обязательное условие, чтобы система вообще не разваливалась при первой же задержке.
Может показаться, что общий ящик задач — техническая деталь, малоинтересная для владельца бизнеса. На деле это как раз то место, где решается, будет ли ваша мультиагентная система хрупкой или устойчивой. Система, где роли зависят друг от друга напрямую и должны отвечать друг другу мгновенно, ломается при первой же задержке одной из ролей — вся цепочка встаёт. Система, построенная вокруг общего потока задач со статусами, продолжает работать, даже если одна из ролей временно недоступна: задачи просто ждут своей очереди, ничего не теряя и не блокируя остальных.
Именно поэтому, если вы когда-нибудь будете проектировать подобную систему для себя, главный вопрос не «какого ИИ выбрать», а «как задачи будут передаваться между ролями, чтобы ничего не потерялось, даже если кто-то из участников недоступен прямо сейчас». Это вопрос архитектуры, а не мощности модели, — и именно поэтому его стоит продумывать заранее, а не постфактум, когда первая потерянная заявка уже обошлась вам в недовольного клиента.
Отдельного разговора заслуживает ситуация, которая рано или поздно случается в любой системе с общим потоком задач: что-то встряло на полпути. Роль забрала задачу в работу, но по какой-то причине не довела до конца — например, ждала уточнения, которое так и не пришло, или просто оказалась перегружена другими задачами дольше обычного. Если система устроена честно, зависшая задача не исчезает бесследно — она продолжает лежать в общем потоке с прежним статусом «взято в работу», и рано или поздно на неё обращает внимание либо сама роль, вернувшись к ней, либо координирующий уровень системы, который время от времени просматривает поток целиком и замечает то, что задерживается дольше, чем следовало бы.
Это принципиально отличается от систем без общего потока, где задача, которую «забыли» передать дальше, просто теряется — и о ней узнают только тогда, когда клиент сам напоминает о себе, обычно уже раздражённо. Наличие видимого статуса каждой задачи — это, по сути, страховка от главного риска ручного управления: забытой, потерянной где-то между людьми и чатами заявки.
Полезно сразу закрыть и обратную крайность: не каждое взаимодействие между ролями обязательно проходит именно через общий поток задач. Есть вещи, которые логичнее держать как разделяемое общее знание, доступное сразу всем ролям, а не как отдельную задачу, которую кто-то кладёт и кто-то забирает, — например, общее понимание того, чем занимается компания, какие у неё правила работы с клиентами, какие направления она берёт, а какие принципиально нет. Это не поток задач, а скорее общая база знаний, к которой обращается любая роль по мере необходимости, без того чтобы кто-то специально «передавал» это знание от одной роли к другой каждый раз заново.
Разница между «поток задач» и «общее знание» простая: поток задач — это то, что движется и меняет статус по мере выполнения. Общее знание — это то, что стабильно и одинаково доступно всем ролям одновременно, без движения от одной к другой. Хорошо спроектированная система использует оба механизма там, где они уместны, а не пытается впихнуть всё в один универсальный способ передачи информации.
Есть ещё одна практическая польза от общего потока задач, о которой редко думают заранее, — он делает видимым то, что при ручном управлении легко остаётся незамеченным: где именно в вашей системе накапливается затор. Если задачи одного определённого типа регулярно дожидаются своей очереди дольше остальных — это не абстрактное ощущение «кажется, мы не успеваем», а конкретный, наблюдаемый факт: вот здесь, на этом узком месте, скапливается работа быстрее, чем её успевают разбирать.
При ручном управлении, когда всё держится в голове у одного человека, подобные заторы часто ощущаются смутно — «в последнее время что-то как будто медленнее» — без понимания, где именно происходит затор и почему. Общий поток задач со статусами превращает это смутное ощущение в конкретную, видимую картину: можно прямо увидеть, что именно роль контроля качества, а не производство, стала тем местом, где сейчас копится больше всего незавершённой работы, — и это уже конкретная информация, с которой можно что-то сделать, а не абстрактное чувство перегрузки.
Ещё одна деталь, которая на практике оказывается важнее, чем кажется на первый взгляд, — не каждая задача в общем потоке одинаково срочна. Заявка от клиента, который уже нервничает из-за задержки, и рутинная внутренняя проверка, которая может подождать день, не должны стоять в очереди на равных правах просто потому, что обе технически «лежат в потоке задач».
Хорошо спроектированная система учитывает это различие — у задач есть не только статус, но и своего рода приоритет, который влияет на то, в каком порядке их забирают в работу. Это не обязательно сложная система баллов и весов — иногда достаточно простого разделения на «срочное» и «может подождать». Но само наличие этого разделения принципиально важно: без него система рискует обрабатывать задачи строго в порядке поступления, вне зависимости от их реальной важности, — а это редко совпадает с тем, что на самом деле нужно бизнесу и его клиентам.
Стоит проговорить прямую практическую пользу от всего описанного в этой главе — не для системы абстрактно, а для вас лично. Если задачи проходят через общий поток со статусами, а не живут исключительно у вас в переписке и в голове, вы в любой момент можете задать системе честный вопрос — что сейчас происходит, что готово, что задерживается — и получить конкретный ответ, а не пытаться вспомнить, кому вы что поручали три дня назад.
Это меняет саму природу вашего участия в бизнесе: вместо того чтобы быть единственным хранилищем информации о состоянии всех дел одновременно, вы становитесь тем, кто в любой момент может заглянуть в понятную картину и увидеть её целиком. Разница между «я должен помнить всё сам» и «я могу в любой момент посмотреть и увидеть всё» — это, пожалуй, одна из самых недооценённых практических выгод перехода от ручного управления к системе с общим потоком задач.
В следующей главе — про роль, без которой ни одна такая система работать не будет: секретарь, тот самый интерфейс между вашими агентами и живыми людьми снаружи.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Если посмотреть на компанию со стороны клиента, он никогда не думает про «мультиагентную систему», «общий поток задач» или «разделение ответственности». Он просто пишет сообщение и ждёт ответа — человеческого, тёплого, по существу. Ему не интересно, что за кулисами это сообщение сейчас будет разобрано, классифицировано, передано нужной производственной роли и потом ещё пройдёт проверку качества. Всё, что он видит, — это первый ответ и то, каким тоном с ним разговаривают.
Именно поэтому в любой мультиагентной системе, где есть внешние клиенты, обязательно должна быть роль, которая берёт на себя весь этот внешний фасад, — секретарь. Не потому что остальные роли «не умеют» вежливо разговаривать, а потому что смешивать функцию «производить результат» и функцию «общаться с человеком снаружи» — плохая идея по тем же причинам, что мы разбирали во второй главе: это разные режимы работы, и хорошо получается либо одно, либо другое, редко оба сразу в одной и той же роли.
У секретаря в такой системе две главные функции, и обе легко недооценить.
Первая — фильтр. Не каждое входящее сообщение — это реальная рабочая задача. Часть — вопросы «сколько стоит», часть — уточнения по уже идущему заказу, часть — вообще не по адресу. Секретарь разбирает этот поток и решает: это новая заявка, которую нужно завести и передать в производство? Это вопрос, на который можно ответить сразу, не привлекая никого другого? Или это тревожный сигнал — например, что-то похожее на мошенничество или конфликтную ситуацию, — который требует особого внимания, а не автоматического ответа по шаблону?
Вторая функция — перевод. Клиент формулирует задачу по-своему, часто расплывчато: «нужен текст, чтобы цепляло», «сделайте что-нибудь для продвижения». Производственной роли нужна куда более конкретная формулировка, чтобы результат вообще можно было сделать хорошо. Секретарь — та роль, которая превращает расплывчатое пожелание в чёткую постановку задачи: что именно нужно, для кого, в каком объёме, к какому сроку. Без этого перевода производственные роли либо будут постоянно уточнять напрямую у клиента — теряя тот самый единый фасад общения, — либо будут гадать, что имелось в виду, и результат окажется не тем, что ждали.
Полезно представить систему без этой роли, чтобы понять её цену. Заявка приходит напрямую в производство. Производственная роль, не привыкшая разговаривать с клиентами напрямую, либо отвечает сухо и по-деловому — что клиента может оттолкнуть, — либо, что хуже, начинает сама додумывать детали задачи, которые на самом деле нужно было уточнить. Если заявок несколько, а направлений тоже несколько, никто не следит за тем, чтобы одному и тому же клиенту не пришло два разных ответа от двух разных ролей, которые не в курсе друг о друге.
А ещё без единой точки входа теряется целостность истории общения с клиентом: сегодня ему ответила одна роль, завтра — другая, и оба раза «с чистого листа», не помня, что клиент уже писал раньше и о чём именно. Секретарь как раз и обеспечивает эту целостность — он единственная роль, которая ведёт полную историю по каждому клиенту от первого сообщения до сдачи готовой работы, не теряя контекст между этапами.
Важно не путать роль секретаря с функцией автоответчика. Автоответчик отвечает шаблонно, вне зависимости от того, что именно написал человек. Секретарь принимает решения: заводить ли заявку, куда её направить, достаточно ли информации, чтобы передать в работу, или нужно сначала уточнить. Это управленческая функция, пусть и небольшая, — не просто вежливая переписка.
Именно поэтому хорошая роль секретаря устроена так, чтобы быть быстрой в реакции — клиент не должен ждать часами простого подтверждения, что его сообщение получено и обрабатывается, — но при этом не торопиться там, где решение требует внимания: если ситуация нестандартная, если что-то выглядит подозрительно, если запрос выходит за рамки того, что компания вообще берётся делать, — секретарь должен уметь остановиться и передать это на решение человеку, а не пытаться закрыть вопрос любой ценой.
В OM-Digital роль секретаря устроена именно так — и её описывают внутри компании не как «первую линию поддержки», а как операционного директора: именно эта роль первой видит любое обращение с любой площадки — будь то биржа фриланса, почта или мессенджер, — заводит по нему учётную запись во внутренней системе учёта клиентов, определяет нужное направление и держит контроль над всем циклом до самой сдачи работы.
Показательный пример — то, как в компании закреплено правило: клиентам от лица компании имеет право писать только секретарь. Даже если производственная роль полностью закончила работу и результат прекрасен, отправляет его клиенту не она — а секретарь, после того как результат прошёл проверку качества. Это осознанное ограничение, а не бюрократическая формальность: оно гарантирует, что у клиента всегда один голос компании, а не несколько разных ролей, каждая из которых что-то ему пишет напрямую и невпопад.
Ещё одна деталь, которая многое говорит о том, зачем нужна эта роль: именно секретарь первым замечает нестандартные, рискованные ситуации — например, подозрительные предложения оплаты через незнакомые ссылки, — и вместо того чтобы автоматически на них реагировать, эскалирует такие случаи наверх, к человеку. Секретарь не пытается закрыть собой любую входящую ситуацию — он умеет отличать «обычная заявка, справлюсь сам» от «здесь нужно решение человека», и в этом, пожалуй, главная ценность роли, а вовсе не в скорости ответа.
Последнее важное уточнение: даже самый хорошо выстроенный секретарь не снимает с владельца бизнеса необходимость периодически смотреть, что происходит, — особенно в нестандартных, денежных или репутационно значимых ситуациях. Роль секретаря — забрать с вас рутинную часть общения: вежливое подтверждение получения заявки, уточнение стандартных деталей, распределение по направлениям. Роль владельца — оставаться тем, к кому в конечном счёте стекается всё действительно важное, потому что именно владелец несёт ответственность за решения, которые нельзя откатить назад.
Легко недооценить, насколько сильно на доверие клиента влияет простая последовательность: если он получает ответы от одного и того же «лица» компании на всех этапах — от первого сообщения до сдачи готовой работы, — у него складывается ощущение, что с ним работает организованная команда, которая помнит, о чём шла речь раньше. Если же на разных этапах отвечают разные, никак не связанные между собой голоса — сегодня один тон, завтра другой, — возникает ровно обратное ощущение: разрозненности и неаккуратности, даже если по существу каждый отдельный ответ был безупречен.
Именно поэтому единый голос компании — не эстетическое пожелание, а вполне практический инструмент удержания доверия. Клиент не обязан знать и не должен даже подозревать, что за кулисами его заявку успели передать между несколькими разными ролями, — снаружи всё должно выглядеть так, будто с ним с самого начала и до конца разговаривает одна и та же внимательная сторона.
Отдельно стоит сказать про скорость — потому что для клиента, особенно на конкурентных площадках вроде бирж фриланса, часто важнее не идеальность первого ответа, а сам факт того, что ответ пришёл быстро. Роль секретаря особенно ценна именно здесь: она способна отреагировать на входящее сообщение практически сразу, не дожидаясь, пока освободится производственная роль, — подтвердить, что заявка получена, задать уточняющий вопрос, обозначить примерные сроки, — и уже после этого спокойно передать дальше по цепочке то, что требует более вдумчивой работы.
Это разделение — «быстро отреагировать» и «вдумчиво выполнить» — ещё одно проявление всё того же принципа узких ролей: секретарь не пытается сходу выполнить саму работу вместо производства, но и производство не пытается взять на себя мгновенную реакцию на входящий поток, потому что для качественного выполнения задачи нужна сосредоточенность, а не постоянные переключения на новые входящие сообщения.
Отдельная практическая сложность, с которой сталкивается растущий бизнес, — общение с клиентами редко идёт через один канал. Кто-то пишет на бирже фриланса, кто-то — в мессенджер, кто-то присылает письмо на почту. Без единой роли, которая держит в поле зрения все эти каналы сразу, легко упустить обращение просто потому, что оно пришло не туда, куда вы в этот момент смотрели.
Роль секретаря решает и эту проблему — не потому что физически «сидит» сразу на всех площадках одновременно, а потому что для неё не имеет значения, откуда пришло обращение: логика обработки одна и та же вне зависимости от канала. Заявка с биржи фриланса, сообщение в мессенджере и письмо на почту в итоге проходят через одну и ту же точку принятия решения — заводится ли новая запись, к какому направлению относится, что делать дальше, — и именно поэтому у клиента не возникает ощущения, что на разных площадках с ним работают разные, слабо связанные друг с другом части компании.
Отдельно стоит сказать про ситуацию, которую любая работающая роль секретаря обязана уметь распознавать особо внимательно, — недовольство клиента результатом или процессом. Здесь особенно ярко проявляется разница между автоответчиком и настоящей ролью с полномочиями суждения: шаблонная реакция на недовольство — извиниться и предложить стандартное решение — работает в простых случаях, но именно в сложных, эмоционально окрашенных ситуациях клиент особенно остро чувствует, разговаривает ли с ним живая, внимательная сторона или бездушный скрипт.
Хорошая роль секретаря умеет отличить рутинное недовольство, которое можно закрыть стандартным путём — например, доработкой в рамках уже оговорённых условий, — от ситуации, которая требует реального человеческого решения: спорный вопрос об оплате, недопонимание в объёме работы, репутационно значимая жалоба. Во втором случае секретарь не пытается закрыть вопрос сам, а эскалирует его человеку, ровно по той же логике, что уже обсуждалась выше применительно к подозрительным ситуациям: способность вовремя остановиться и передать решение выше — не слабость роли, а признак того, что она спроектирована правильно.
Есть ещё одна причина, по которой роль секретаря заслуживает особого внимания владельца бизнеса: именно через неё проходит весь входящий поток, а значит, именно она первой чувствует, если что-то в системе работает не так. Если производственная роль перегружена и задачи начинают задерживаться дольше обычного, это в первую очередь ощущается как растущее число клиентов, которым секретарь вынужден писать «пока ожидаем, скоро будет готово» вместо конкретного ответа по существу.
Именно поэтому в зрелой системе полезно периодически смотреть не только на то, что говорит секретарь клиентам, но и на то, как часто ему приходится извиняться за задержки или откладывать содержательный ответ, — это простой и честный индикатор того, где именно в системе сейчас накапливается нагрузка, даже раньше, чем это станет заметно по любым другим признакам.
В следующей главе — про то, что происходит после того, как секретарь передал задачу в работу: как устроено разделение труда между теми, кто делает, и теми, кто проверяет, прежде чем результат уйдёт клиенту.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Есть простое наблюдение, знакомое любому, кто хоть раз перечитывал собственный текст перед отправкой: чем дольше вы сами писали текст, тем хуже вы замечаете в нём ошибки. Не потому что вы невнимательны, а потому что мозг — что человеческий, что искусственный — при повторном чтении собственной работы видит то, что «должно» там быть, а не то, что там есть на самом деле. Это не лечится просьбой «перечитай ещё раз повнимательнее» — усталый глаз автора и внимательный взгляд постороннего человека физически работают по-разному.
Из этого наблюдения вырастает второй важный принцип мультиагентных систем, после «одна роль — одна ответственность»: роль, которая создаёт результат, и роль, которая его проверяет, должны быть разными ролями. Не формально разными — по-настоящему независимыми, с разными задачами и разным взглядом на одну и ту же работу.
Производственная роль настроена на созидание: написать текст, собрать структуру, предложить решение. Её задача — сделать что-то, чего раньше не было, и сделать это как можно лучше в первом приближении.
Контролирующая роль настроена на противоположное: искать, что не так. Не улучшать, не переписывать заново, не привносить свою версию — а честно и придирчиво находить слабые места в том, что уже создано: ошибки, нестыковки, несоответствие исходной задаче, недостаточно убедительный аргумент, забытую деталь. Это неблагодарная, но критически важная работа, и именно поэтому её нельзя поручать той же роли, что уже сделала первый вариант, — слишком велик соблазн одобрить собственную работу.
Разделение этих двух режимов — не бюрократическая надстройка «для галочки», а способ действительно поймать то, что иначе прошло бы незамеченным. Хорошая система устроена так, что ни одна работа не считается готовой, пока её не увидел кто-то, кроме автора.
В зрелой мультиагентной системе контроль качества редко устроен как одна проверка «хорошо или плохо». Чаще это несколько последовательных фильтров, каждый из которых смотрит на свою грань результата, — и текст или продукт проходит их один за другим, прежде чем считается по-настоящему готовым.
Один фильтр может смотреть на то, насколько убедительно и по-человечески звучит текст — не сухо, не шаблонно, а так, будто его писал живой человек, а не программа. Другой фильтр — на грамотность и стилистическую чистоту: опечатки, согласование, пунктуация. Третий — соответствует ли результат тому, что изначально просил клиент, ничего ли не упущено. Идея не в том, чтобы усложнить процесс ради самого процесса, а в том, что каждая из этих проверок требует своего фокуса внимания, и объединять их в одну «общую проверку на всё сразу» — значит рисковать тем, что каждая грань будет проверена поверхностно.
Мы не будем здесь разбирать, как именно устроен конкретный набор таких фильтров и в каком порядке они выстроены технически, — это уже вопрос практической настройки конкретной системы. Важен сам принцип: качество — это не одна финальная галочка, а последовательность разных, независимых взглядов на результат, каждый из которых ловит своё.
В OM-Digital любой текст, который в итоге уходит клиенту, — будь то отклик на заявку, статья, коммерческое предложение или пост в соцсети — проходит именно через такую последовательность, а не отправляется сразу после первого варианта.
Сначала производственная роль — например, маркетинг или AI Studio, в зависимости от типа задачи, — создаёт первый вариант, отталкиваясь от того, что передал секретарь. Дальше этот вариант проходит через отдельный фильтр, который делает текст более живым и убедительным, — задача этого этапа не переписать содержание, а усилить то, как оно воспринимается читателем. После этого — ещё один фильтр, задача которого убрать из текста характерные штампы и обороты, которые сразу выдают, что текст писала машина, а не человек, — потому что клиенты компании ценят именно живой, человеческий тон, а не формально правильный, но безликий. И только в конце — финальная вычитка на грамотность, орфографию и пунктуацию, отдельная от смысловой правки, потому что смешивать проверку смысла и проверку орфографии в одном проходе означает рисковать пропустить и то, и другое наполовину.
Только после того как текст прошёл весь этот путь, он получает статус «готов к отправке» — и, как мы обсуждали в предыдущей главе, именно тогда секретарь забирает его и передаёт клиенту. Ни на одном из промежуточных шагов текст не может «перепрыгнуть» проверку, даже если производственная роль уверена, что и так справилась хорошо.
Разделение труда между «сделать» и «проверить» в OM-Digital не ограничивается только текстами. Отдельная роль — финансовый директор — занимается исключительно учётом: сколько денег пришло по каждому заказу, какие расходы понесла компания, какова итоговая прибыль. Эта роль ничего не производит и ничего не проверяет по содержанию работы — она проверяет цифры, и делает это независимо от производственных ролей, ровно по той же логике: тот, кто сделал работу и назвал цену, не должен быть единственным, кто считает, сколько на самом деле заработала компания.
Похожим образом устроен и контроль качества результата не только текстов, но и, например, кода или технических настроек, — отдельная роль тестирования смотрит на готовый результат чужим, придирчивым взглядом, прежде чем он будет признан готовым к сдаче, вне зависимости от того, насколько уверена в себе была роль, которая этот результат создала.
Стоит подчеркнуть: разделение на «производство» и «контроль» — не про то, что производственные роли якобы «плохо работают» и нуждаются в постоянной перепроверке. Это про то, как устроена надёжность любой сложной системы, будь то завод, издательство или компания на ИИ-агентах: независимая проверка ловит то, что не может поймать сам создатель, просто в силу того, как устроено внимание при повторном взгляде на собственную работу. Чем выше цена ошибки — деньги клиента, репутация компании, — тем важнее, чтобы между «сделал» и «отправил» стоял кто-то ещё, кроме автора.
Полезно заранее продумать не только сам факт проверки, но и то, что происходит, когда контролирующая роль находит недостаток. Худший вариант — если результат проверки никак не возвращается автору, а просто где-то фиксируется «плохо» без объяснений: в этом случае ошибка, может, и не уйдёт клиенту в этот раз, но с высокой вероятностью повторится снова, потому что никто не понял, в чём именно она была.
Работающая схема устроена иначе: контролирующая роль не просто ставит отметку «не готово», а возвращает результат туда же, откуда он пришёл, с конкретным указанием, что именно нужно поправить, — и только после исправления результат заново проходит тот же путь проверки. Это возвратное движение — не признак того, что производственная роль «плохо справилась», а нормальная, ожидаемая часть процесса, точно так же, как редактор в издательстве возвращает автору рукопись с правками не один раз, а иногда несколько, прежде чем текст готов к печати. Система, где допускается и предусмотрено такое возвратное движение, работает надёжнее системы, где предполагается, что результат обязан быть идеальным с первой попытки.
Стоит проговорить прямо то, что иногда стесняются сказать: разделение на производство и контроль всегда добавляет время к общему циклу — задача не может считаться готовой мгновенно после первого варианта, ей нужно пройти ещё один или несколько шагов. Это осознанная цена, а не побочный неприятный эффект, который стоит стремиться свести к нулю.
Правильный вопрос — не «как убрать эту задержку», а «какую задержку компания готова принять ради того, чтобы результат был надёжным». Для одних типов работы — например, черновой внутренний документ, который в любом случае ещё не раз обсудят, — можно позволить себе упрощённую, быструю проверку. Для других — например, текст, который сразу увидит клиент и по которому сложится его мнение о компании, — оправдана более медленная, но более тщательная многоступенчатая проверка. Хорошая система не проверяет всё одинаково строго, а соотносит глубину контроля с ценой возможной ошибки, — и это тоже решение, которое стоит принимать осознанно, а не автоматически применять максимальную строгость ко всему подряд.
Стоит развеять ещё одно тихое заблуждение: контроль качества — не разовая настройка, которую один раз выстроили и дальше можно забыть. То, что считалось хорошим результатом полгода назад, может перестать устраивать клиентов сегодня — вкусы, ожидания, конкурентная среда меняются, и то, что раньше воспринималось как «нормальный, рабочий текст», сегодня может выглядеть слишком обыденно на фоне того, что делают конкуренты.
Поэтому зрелая система контроля качества периодически пересматривает не только сам результат, но и критерии, по которым его оценивают. Не в смысле постоянных изменений ради изменений, а в смысле честного вопроса, который стоит время от времени себе задавать: действительно ли то, что мы считаем «хорошо сделанной работой» сегодня, всё ещё соответствует тому, что клиенты по-настоящему ценят, — или планка незаметно застыла на уровне прошлого года.
Может показаться, что вся идея независимой проверки построена на недоверии — как будто система изначально предполагает, что производственная роль обязательно что-то напортачит. На деле логика ровно обратная: независимая проверка существует не потому, что производственной роли не доверяют, а потому, что доверие к системе в целом строится именно на том, что каждый этап проверен кем-то ещё, а не на честном слове.
Это тонкое, но важное различие. Клиент, который знает, что результат прошёл несколько независимых проверок перед тем, как попасть к нему, доверяет компании больше — не потому что подозревает, что производственная роль плохо работает, а потому что видит: система устроена так, что ошибка с высокой вероятностью будет поймана прежде, чем дойдёт до него. Доверие клиента к компании в целом строится именно на этой видимой добросовестности процесса, а не на обещании, что «у нас всё всегда получается с первого раза».
Стоит предостеречь и от противоположной крайности, в которую иногда впадают, вдохновившись идеей многоступенчатого контроля, — не превращать проверку в самоцель, добавляя всё новые и новые фильтры просто потому, что «чем больше проверок, тем надёжнее». На практике каждый лишний, не оправданный реальной пользой уровень проверки добавляет только время и сложность, не давая взамен ощутимого прироста качества, — а иногда даже вредит: слишком длинная цепочка правок постепенно размывает изначальный голос и характер текста, превращая его в компромисс между слишком многими разными взглядами.
Здоровый ориентир — каждый уровень проверки должен ловить то, что не ловит никакой другой уровень. Если два фильтра на практике находят одни и те же типы ошибок, один из них, скорее всего, избыточен, и его стоит либо убрать, либо переформулировать так, чтобы он проверял что-то своё, не пересекающееся с остальными.
Важная практическая оговорка напоследок: количество уровней проверки, которое подходит зрелой компании с десятком ролей, необязательно подходит бизнесу, который только начинает выстраивать первую пару ролей. На старте вполне разумно ограничиться одним уровнем контроля — например, простой проверкой на соответствие исходному запросу клиента, — и добавлять новые уровни постепенно, по мере того как становится понятно, какие именно ошибки на практике проскакивают через существующую проверку.
Это тот же принцип, что мы уже видели применительно к организационной структуре в целом: система контроля качества должна расти из реальной, наблюдаемой потребности, а не выстраиваться заранее во всей возможной полноте. Начать с малого и добавлять уровни проверки по факту обнаруженных проблем — куда более здоровая стратегия, чем пытаться с первого дня выстроить идеальный, многоступенчатый конвейер контроля, который в итоге будет непропорционально сложен для объёма реальной работы.
В следующей главе поднимемся на уровень выше — от отдельных ролей к тому, как всё это складывается в организационную структуру целой компании, на примере того, как устроена сама OM-Digital.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Пока ролей мало — три, четыре, — их можно держать в голове просто списком: секретарь, маркетинг, контроль качества, финансы. Но по мере того как компания растёт, а вместе с ней растёт и число ролей, плоский список перестаёт работать по той же причине, по которой он перестаёт работать в обычной компании из живых людей: непонятно, кто кому докладывает, кто с кем должен согласовывать пересекающиеся вопросы, и кто в конечном счёте отвечает за то, что вся система в целом работает слаженно, а не просто как набор независимых исполнителей.
Решение то же самое, что и в обычном бизнесе, — группировка ролей в отделы по общей цели, и появление координирующего уровня над отделами. Не потому что это красиво выглядит на схеме, а потому что при определённом масштабе без этого начинают теряться задачи и размываться ответственность — ровно то, от чего мы уходили, когда вводили узкие роли в третьей главе.
Прежде чем перейти к принципам группировки, стоит подчеркнуть одну деталь структуры, которую легко принять за формальность, хотя это не так. То, что учредители находятся на вершине схемы, — не дань традиции корпоративных иерархий и не красивая картинка для документа. Это отражает реальное распределение ответственности: именно учредители несут итоговый риск за решения компании, именно к ним возвращаются деньги и репутация, и именно поэтому именно они, а не координирующая роль и уж тем более не любая производственная роль, сохраняют последнее слово в необратимых вопросах.
Координирующая роль управляет потоком повседневной работы, но не подменяет собой волю владельцев бизнеса. Это различие стоит держать в голове весь оставшийся разбор структуры: чем выше по схеме — тем больше речь идёт не о том, «кто выполняет больше операций», а о том, «кто несёт больше ответственности за последствия».
Ключевая ошибка при построении структуры — группировать роли по внешнему сходству задач, а не по цели. Например, может показаться логичным объединить в один отдел «всё, что связано с текстами» — и маркетинг, и AI Studio, и бизнес-аналитику. Но у этих ролей разные цели: маркетинг продаёт и информирует напрямую, AI Studio строит логику для других ИИ-систем, бизнес-аналитика создаёт документы для внутреннего и внешнего использования. Объединение по формальному сходству «все работают с текстом» скрывает то, что на деле это разные направления работы компании.
Правильная группировка — по цели, ради которой роль существует. Если несколько ролей существуют ради того, чтобы компания находила новых клиентов и новые возможности для роста, — это одна цель, и вокруг неё может сложиться отдел, даже если конкретные задачи внутри разные: одна роль анализирует рынок, другая ищет новые каналы продаж, третья синтезирует это в конкретный план. Общая цель — рост компании — делает их одним отделом, даже несмотря на разные повседневные задачи.
В OM-Digital на сегодняшний день структура выглядит примерно так. На самом верху — учредители, к которым в конечном счёте стекается всё важное и кто принимает решения по необратимым, денежным и репутационно значимым вопросам. Прямо под ними — координирующая роль, которая выступает единственной точкой входа между учредителями и всей остальной системой: именно через неё проходят все сообщения от учредителей вниз и все отчёты снизу вверх, что исключает ситуацию, когда учредителям приходится самим разбираться, к какой из множества ролей обратиться с тем или иным вопросом.
Под координирующей ролью — несколько отделов, каждый со своей целью. Производственный отдел объединяет роли, которые непосредственно выполняют заказы клиентов, — маркетинг, направление AI Studio, бизнес-аналитику, автоматизацию, а также отдельную роль контроля качества, которая проверяет результат перед сдачей. Отдел поиска заказов объединяет роли, которые мониторят биржи фриланса и другие источники клиентов, — их цель не выполнить работу, а найти того, для кого её нужно выполнить. Отдел развития — это роли, чья цель не сиюминутные заказы, а долгосрочный рост: анализ рынка, поиск новых ниш и возможностей, синтез всего этого в конкретный план для учредителей. И отдел рекламы, чья цель — продвижение самой компании, а не выполнение заказов для клиентов: работа над видимостью компании там, где её могут найти будущие клиенты.
Отдельно от этой основной структуры существует финансовый учёт, который скорее пронизывает все отделы, чем является одним из них, — потому что каждая завершённая работа так или иначе должна быть отражена в деньгах, вне зависимости от того, какой отдел её выполнил.
Важное уточнение, которое легко упустить: координирующая роль над отделами — не супер-агент, который умеет делать работу всех отделов лучше них самих. Её задача принципиально другая — видеть систему целиком, получать отчёты от каждого отдела, замечать, где что-то пошло не так или зависло дольше обычного, принимать решения по спорным вопросам, которые выходят за рамки полномочий отдельного отдела, и доносить общую картину до учредителей — без того, чтобы учредители сами разбирались в деталях работы каждой отдельной роли.
Это тот же принцип «одна роль — одна ответственность», применённый на уровень выше: как отдельный агент не должен пытаться быть одновременно и автором, и проверяющим, так и координатор не должен пытаться быть одновременно и стратегом, и исполнителем каждой отдельной задачи. Его сила — в широте обзора, а не в глубине погружения в каждую операцию.
У структуры OM-Digital есть ещё одна практическая особенность, которая заслуживает упоминания: разные группы ролей физически работают в разных, независимых друг от друга технических сессиях — условно говоря, в разных «терминалах». Один поток занимается производством заказов, другой — мостом для связи с учредителями через мессенджер, третий — мониторингом бирж фриланса и работой в браузере, четвёртый — координацией и административными вопросами. Это не отдельные компании и не дублирующие друг друга системы — это просто способ дать разным направлениям работать одновременно, не мешая друг другу и не деля одно и то же рабочее пространство. Подробнее о том, зачем нужна именно такая параллельность и что она даёт, — в следующей главе.
Соблазн, характерный для растущих систем, — создавать отделы заранее, «на будущее», под задачи, которых пока не существует. Это плохая идея по той же причине, по которой плохо нанимать сотрудников под работу, которой пока нет: структура без реальной нагрузки быстро превращается в формальность, за которой никто по-настоящему не следит.
Более здоровое правило — реагировать на факт, а не на прогноз: если у вас накопилось несколько ролей с одной общей целью, которую сложно уместить в уже существующие отделы, — вот тогда стоит выделить для них отдельный отдел. Не раньше. Структура должна вырастать из реальной сложности работы, а не предвосхищать её, — иначе вы рискуете построить красивую, но пустую организационную схему, за которой не стоит настоящая работа.
Организационная структура — это не документ, который один раз нарисовали и забыли. По мере того как компания растёт, находит новые направления работы или, наоборот, сворачивает то, что не показало результата, структуру нужно пересматривать — не хаотично, при каждом удобном случае, а регулярно, в заранее оговорённые моменты, чтобы это стало предсказуемой частью управления, а не поводом для паники всякий раз, когда что-то меняется.
В OM-Digital, например, заведено регулярно, в начале и в середине каждого месяца, заново проходить цикл поиска новых направлений и площадок для работы: искать новые возможности, проверять их, согласовывать с учредителями и только после этого включать в постоянную работу компании. Это не значит, что структура меняется каждый раз кардинально, — чаще всего пересмотр подтверждает, что всё работает так, как нужно. Но сам факт регулярной проверки не даёт структуре незаметно устареть и продолжать существовать по инерции, когда реальная работа компании давно ушла в сторону.
Последнее уточнение, о котором легко забыть, увлёкшись красотой самой схемы: организационная структура — это средство, а не цель. Она существует, чтобы заявки клиентов доходили до нужных рук быстро и без потерь, чтобы учредители получали внятную картину происходящего, не разбираясь в деталях работы каждой роли, и чтобы сама система могла расти, не разваливаясь при увеличении нагрузки.
Если в какой-то момент структура начинает мешать этому — усложняет путь простой задачи, создаёт лишние промежуточные звенья, требует согласований там, где раньше вопрос решался за минуту, — это сигнал, что структуру пора упростить, а не повод гордиться количеством отделов и уровней иерархии. Хорошая структура всегда служит скорости и надёжности работы, а не наоборот.
Хороший пример того, почему группировка по цели, а не по внешнему сходству задачи, действительно важна на практике, — сравнение отдела поиска заказов и отдела развития в OM-Digital. На первый взгляд оба «ищут возможности» и легко было бы объединить их в один отдел просто по этому внешнему признаку. Но цели у них принципиально разные: отдел поиска заказов ищет конкретных клиентов прямо сейчас, под существующие услуги компании, — его горизонт планирования это дни и недели. Отдел развития ищет не клиентов, а направления — новые рынки, новые форматы работы, новые каналы, которые могут окупиться месяцами позже, — его горизонт совсем другой, и он может позволить себе гораздо более медленное, вдумчивое исследование, не обязанное давать результат сегодня же.
Если бы эти две цели смешали в одном отделе, скорее всего, быстрая, сиюминутная работа по поиску заказов постоянно вытесняла бы медленную, стратегическую работу по поиску направлений, — просто потому что у первой есть немедленная отдача, а у второй отдача отложенная, и в условиях конкуренции за внимание срочное почти всегда побеждает важное. Разделение на два отдела с разными целями защищает именно стратегическую, долгосрочную работу от того, чтобы её постоянно откладывали ради сиюминутной.
Похожая логика объясняет и существование отдельного отдела рекламы в OM-Digital, который легко было бы спутать с отделом поиска заказов, — оба, казалось бы, работают на приток клиентов. Но цель у них разная: отдел поиска заказов реагирует на уже существующий спрос — ищет конкретные заявки там, где они уже появились. Отдел рекламы работает на то, чтобы спрос вообще возникал в новых местах, — размещает материалы о компании там, где потенциальные клиенты могут её обнаружить, даже если формально прямо сейчас ничего не ищут.
Это разница между «ловить рыбу там, где она уже есть» и «расширять пруд, в котором рыба вообще может появиться». Обе задачи важны, но требуют разного мышления, разного темпа и разных критериев успеха, и именно поэтому в зрелой структуре они разведены по разным отделам, а не свалены в одну общую корзину «продвижение бизнеса».
Хороший практический критерий того, насколько удачно выстроена организационная структура, — представить, что новый человек (или новый читатель этой книги) должен понять её за несколько минут, глядя на простую схему, без долгих пояснений. Если для понимания того, кто чем занимается и кто кому докладывает, требуется отдельная лекция с оговорками и исключениями, — вероятно, структура успела стать сложнее, чем того требует реальный объём работы.
Простая, понятная с первого взгляда структура — не признак примитивности компании, а признак того, что она честно устроена вокруг реальных ролей и реальных целей, а не обросла историческими наслоениями, которые давно никто не пересматривал. Это тот же принцип, что мы уже видели применительно к отдельным ролям в предыдущих главах, — только на этот раз применённый к организации в целом: ясность важнее видимой сложности.
В следующей главе — про то, что означает работать «одновременно», а не «по очереди», и почему это не только про скорость.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Вернёмся к образу из первой главы — одному помощнику в одном чате. Даже если у вас уже есть несколько ролей, легко незаметно для себя выстроить их так, что фактически они всё равно работают по очереди: сначала вы обращаетесь к одной роли, дожидаетесь результата, потом к другой, потом к третьей. Формально ролей несколько, но по факту система работает не быстрее одного помощника — просто вы переключаетесь между несколькими чатами вместо одного.
Настоящая ценность нескольких ролей раскрывается тогда, когда они действительно работают параллельно — не дожидаясь друг друга, а занимаясь каждая своей задачей в одно и то же время. Пока одна роль отвечает клиенту, другая параллельно проверяет качество уже готовой работы, третья в этот же момент мониторит биржи фриланса в поисках новых заказов. Не потому что кто-то специально это оркеструет вручную, а потому что каждая роль работает в своём собственном темпе, независимо от остальных, и просто складывает результат в общий поток задач, о котором шла речь в четвёртой главе.
Первое, очевидное преимущество — время. Если раньше на путь «клиент написал → секретарь ответил → производство сделало → проверка прошла → клиент получил результат» уходил целый день, потому что каждый шаг ждал, пока вы лично переключитесь к следующему участнику процесса, то при настоящем параллелизме разные части этого пути могут двигаться одновременно с другими похожими заявками: пока по одному заказу идёт проверка качества, по другому уже стартовало производство, а по третьему секретарь ещё уточняет детали.
Но есть и второе, менее очевидное преимущество — устойчивость. Если одна роль временно перегружена или недоступна — например, обрабатывает длинную задачу, — остальные роли не останавливаются в ожидании. Работа продолжает двигаться там, где это возможно, а не замирает целиком из-за одного узкого места. Это прямое следствие того, что мы обсуждали в четвёртой главе: связь через общий поток задач со статусами, а не через прямую зависимость друг от друга в реальном времени.
У параллельной работы есть обратная сторона, и честно о ней сказать важнее, чем красиво рассказать только о плюсах. Когда несколько ролей действуют одновременно, а не по очереди, появляется риск дублирования и конфликтов: два процесса могут независимо друг от друга взяться за одну и ту же задачу, если границы ответственности прописаны недостаточно чётко — а это прямая отсылка ко второй главе про размытые роли. Или один процесс может изменить что-то, от чего в этот момент зависит другой, создавая рассинхронизацию.
Именно поэтому параллелизм — это не просто «запустить несколько ИИ одновременно и надеяться, что получится быстрее». Это требует заранее продуманной структуры: чёткого разделения зон ответственности, понятных статусов задач и правил, кто первым берёт задачу в работу, если формально она могла бы подойти нескольким ролям сразу. Без этой подготовки параллельная работа не ускоряет систему, а вносит в неё хаос — задачи начинают теряться или дублироваться быстрее, чем при последовательной, медленной, но предсказуемой работе.
В OM-Digital параллелизм реализован буквально — несколько независимых технических сессий работают в одно и то же время, каждая занимаясь своим направлением, не дожидаясь остальных. Пока один поток занят обработкой производственных задач — тем, что реально нужно сделать и сдать клиентам, — другой параллельно ведёт мониторинг бирж фриланса в браузере, ищет новые заявки, откликается на подходящие. Третий держит связь с учредителями через мессенджер, обрабатывая входящие сообщения и передавая задачи туда, где их нужно выполнить. Четвёртый занимается координацией и административными вопросами всей системы в целом.
Ни один из этих потоков не ждёт, пока освободится другой. Заявка, которую нашёл поток мониторинга бирж, попадает в общий список задач и там дожидается своей очереди у производственного потока, который в это время может быть занят чем-то другим, — и ничего не теряется, просто задача подождёт немного дольше, если поток сейчас загружен. При этом строго разграничено, кто и что имеет право делать: например, отправлять сообщения клиентам от лица компании имеет право только секретарь — даже если технически поток, который нашёл заказ на бирже, мог бы написать клиенту сам. Это разграничение существует именно для того, чтобы параллельная работа нескольких потоков не превратилась в ситуацию, когда клиент получает противоречивые сообщения от разных частей системы.
Стоит на всякий случай уточнить: не каждую задачу стоит распараллеливать. Есть решения, которые по своей природе должны приниматься последовательно и осознанно, одним человеком, а не разными ролями одновременно, — прежде всего это касается денег, необратимых действий и всего, что мы в компании называем «красной зоной»: перевод реальных средств, удаление данных, любое решение, которое нельзя откатить назад. Такие вещи сознательно выведены из-под параллельной автоматической обработки и остаются на решение учредителей, даже если формально какая-то роль технически могла бы справиться быстрее.
Параллелизм — это инструмент для увеличения пропускной способности рутинной, повторяющейся работы. Он не предназначен для того, чтобы ускорить принятие решений, которые по природе своей требуют вдумчивости и права окончательного голоса у человека.
Есть неожиданная польза от того, чтобы попробовать запустить несколько ролей действительно одновременно, а не по очереди: это отличный практический тест на то, насколько на самом деле чётко продуманы границы этих ролей. Пока роли работают строго по очереди, под контролем человека, размытая граница между ними может годами оставаться незамеченной — вы просто вручную, интуитивно, разруливаете пересечения, даже не осознавая, что делаете это.
Как только те же роли начинают работать параллельно и без постоянного присмотра, любая нечёткость в разделении ответственности проявляется быстро и заметно: либо задача повисает, потому что обе роли думали, что её возьмёт другая, либо, наоборот, обрабатывается дважды. В этом смысле переход к параллельной работе — не просто следующий шаг в развитии системы, а своего рода проверка на прочность всего, что было спроектировано раньше. Если структура ролей выдерживает параллельную нагрузку без путаницы — значит, она была продумана достаточно хорошо. Если нет — параллелизм безжалостно это покажет, и лучше увидеть это на практике, чем полагаться на то, что «в теории всё должно быть в порядке».
Отдельно стоит отделить параллельную работу нескольких ролей от ситуации, когда несколько людей или процессов одновременно пытаются менять одно и то же — например, один и тот же документ или одну и ту же запись о клиенте. Это разные вещи, и путать их опасно. Хорошо спроектированный параллелизм — это когда разные роли занимаются разными участками работы одновременно, не претендуя на один и тот же ресурс в один и тот же момент. Если же две роли одновременно пытаются изменить одну и ту же запись — это уже не параллельная эффективность, а гонка, в которой один из результатов почти гарантированно потеряется или будет незаметно перезаписан другим.
Именно поэтому в зрелых системах у каждой сущности — заявки клиента, конкретного заказа, финансовой записи — всегда есть понятная «текущая стадия» и понятно, какая именно роль имеет право менять её прямо сейчас. Это не отменяет параллелизма в целом — просто параллелизм должен быть организован вокруг разных участков работы, а не вокруг попытки нескольких ролей одновременно вцепиться в один и тот же кусок.
Стоит отдельно отметить практическую тонкость, характерную именно для систем, где часть ролей — люди, а часть — ИИ: у них принципиально разная скорость и разный ритм работы, и хорошая система не пытается искусственно их выровнять. Учредители компании читают отчёты и принимают решения в своём темпе — когда у них есть на это время и внимание, а не по расписанию, продиктованному скоростью работы автоматических ролей. ИИ-роли, напротив, могут откликаться на новые задачи практически мгновенно, без пауз на отдых или переключение внимания.
Хорошо спроектированная система не заставляет более медленную сторону — людей — подстраиваться под темп более быстрой, и не тормозит быструю сторону ожиданием медленной там, где это не обязательно. Задачи, которые требуют решения человека, спокойно ждут своей очереди в общем потоке, пока человек не найдёт время их рассмотреть, — и в это время всё остальное в системе продолжает работать в своём темпе, не замирая в ожидании. Именно эта терпимость к разной скорости разных участников — а не попытка всех ускорить до одного темпа — и есть настоящий секрет того, почему параллельная система с людьми и ИИ внутри неё вообще может работать устойчиво.
Легко увлечься самой идеей параллелизма и не заметить момент, когда стоит остановиться и проверить, действительно ли он даёт эффект, а не просто выглядит внушительно на схеме. Практичный ориентир простой: сравнить, сколько задач в среднем проходит полный путь от заявки до сдачи за неделю сейчас — при параллельной работе нескольких ролей — с тем, сколько проходило раньше, при последовательной, ручной модели. Если цифра ощутимо выросла, а количество ошибок и путаницы не выросло вместе с ней, — параллелизм работает так, как задумывался. Если объём вырос, но вместе с ним выросло и число накладок, дублирований, потерянных задач — это сигнал, что распараллелили раньше, чем роли были готовы к этому, и стоит на время вернуться к более последовательной, контролируемой модели, доработать границы ответственности и только потом пробовать снова.
Важно, что это не разовая проверка, а что-то вроде периодического взгляда со стороны: система, которая сегодня работает параллельно без сбоев, вполне может начать давать сбои через несколько месяцев — просто потому что выросла нагрузка, появились новые роли, изменились внешние условия. Здоровая привычка — не считать однажды достигнутую устойчивость постоянным свойством системы, а периодически перепроверять её на практике.
Если у вас пока всего одна-две роли, идея параллельной работы может показаться преждевременной — и в этом есть здравое зерно. Разумная последовательность — сначала выстроить каждую роль по отдельности так, чтобы она надёжно работала сама по себе, и только потом задумываться о том, чтобы запускать несколько ролей одновременно, без постоянного присмотра.
Попытка сразу построить параллельную систему из ролей, ни одна из которых ещё толком не проверена в одиночной работе, — верный способ получить хаос, в котором невозможно разобрать, где проблема в самой роли, а где — в том, как несколько ролей взаимодействуют друг с другом. Параллелизм — это надстройка над уже работающими по отдельности ролями, а не способ ускорить их проектирование с самого начала.
В следующей главе — про ещё одну способность, которая сильно расширяет возможности такой системы: может ли агент не просто отвечать текстом, а сам открыть браузер и что-то в нём сделать.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Всё, о чём мы говорили до сих пор, легко представить как обмен текстом: агент получает задачу текстом, возвращает результат текстом. Но реальный бизнес не ограничивается текстом — иногда результат нужно получить не в виде ответа в чате, а в виде конкретного действия во внешнем мире: заполнить форму на сайте, отправить сообщение на бирже фриланса, проверить, появились ли новые заявки на внешней площадке, куда нет прямого программного доступа, только обычный сайт с кнопками, как у любого пользователя.
Здесь возникает естественный вопрос: может ли агент делать это сам — открывать страницу, читать, что на ней написано, нажимать нужные кнопки, — а не только советовать вам, что нажать? Короткий ответ — да, современные системы это умеют. Агент может «видеть» содержимое страницы, интерпретировать его так же, как это делал бы человек, глядя на экран, и выполнять действия — клик, ввод текста, прокрутку — практически так же, как это делал бы живой пользователь за компьютером. При необходимости агент способен и сам зарегистрироваться на новом сайте, создать профиль или завести аккаунт от вашего имени — если именно это нужно для вашей задачи.
Здесь же стоит закрепить пометку, важную для всей этой главы: заходить ли агенту на конкретный сайт, регистрироваться ли на нём, какие данные и пароли для этого использовать, — решение всегда принимаете вы, а не агент. Способность что-то сделать самостоятельно — это не то же самое, что разрешение это делать; разрешение выдаёте только вы, осознанно и для конкретной ситуации.
Причина, по которой это важно, а не просто эффектная техническая деталь, — это то, что огромная часть повседневных задач малого бизнеса устроена именно так: через интерфейсы, рассчитанные на человека, а не на программу. Биржи фриланса, куда нужно заходить и проверять новые заказы. Формы обратной связи на сторонних сайтах. Личные кабинеты сервисов, где нужно время от времени что-то проверять или обновлять. Всё это — не про обмен структурированными данными между программами, а про обычные веб-страницы, с которыми раньше мог взаимодействовать только человек, кликающий мышкой.
Возможность поручить агенту такую работу — это возможность автоматизировать не только «подумать и написать текст», но и рутинный обход множества сайтов и интерфейсов, которые иначе требовали бы вашего личного внимания каждый день: зайти, проверить, отреагировать, и так по кругу для каждой отдельной площадки.
Прежде чем воодушевиться, важно честно проговорить и обратную сторону. Работа агента с браузером — не безотказная магия. Сайты нередко специально защищаются от автоматических действий: капчи, проверки на «настоящего» пользователя, временные блокировки при подозрительной активности. Это означает, что не каждую площадку получится автоматизировать полностью — иногда агент упирается в проверку, которую может пройти только живой человек, и в этом месте автоматизация честно останавливается, передавая шаг человеку, а не пытается его обойти любой ценой.
Кроме того, здесь особенно важна ответственность за то, что именно агенту разрешено делать самостоятельно, а что требует подтверждения человека, — та же логика полномочий, о которой шла речь в третьей главе, но с повышенной ставкой: если агент, отвечающий текстом, в худшем случае напишет неудачную фразу, то агент, который совершает реальные действия на сайтах — отправляет сообщения, заполняет формы, — может совершить действие, которое трудно или невозможно отменить. Именно поэтому здравая практика — оставлять окончательное решение об отправке чего-либо вовне за человеком или за отдельной проверяющей ролью, даже если техническая возможность нажать кнопку «отправить» у агента уже есть.
В OM-Digital именно так устроена часть отдела поиска заказов: отдельный технический поток занимается тем, что заходит на биржи фриланса, читает список свежих заказов и заявок так, как это делал бы человек, просматривающий страницу, оценивает, подходит ли заявка под профиль компании, и, если да, — доводит информацию до секретаря, а не решает самостоятельно, отправлять ли отклик от лица компании.
Показательно и то, где именно в компании специально остановили автоматизацию, а не довели её «до полного цикла». По внутреннему правилу компании, отправлять что-либо клиентам от лица компании — на любой площадке, в любом виде — имеет право только секретарь, и никакая другая роль, включая ту, что нашла заказ на бирже, не отправляет сообщение напрямую. Браузерный поток в этом смысле выполняет роль глаз и рук для рутинного просмотра и сбора информации, а не роль, которая самостоятельно принимает решение об отправке чего-либо от имени компании. Это осознанное разделение — та же логика, что мы разбирали в шестой главе про производство и контроль: тот, кто выполняет техническое действие, не обязательно тот, кто принимает решение об этом действии.
Полезное практическое правило, которое стоит запомнить, даже не вдаваясь в техническую реализацию: чем ближе действие к необратимому — отправка сообщения клиенту, оплата, публикация чего-либо от имени компании, — тем больше оснований оставить финальное подтверждение за человеком или за отдельной ролью, специально предназначенной для этого решения, а не за той ролью, что физически совершает клик. И, наоборот, чем более рутинно и обратимо действие — просмотр страницы, сбор информации, черновая подготовка данных, — тем спокойнее можно доверить его полностью автоматическому потоку.
Эта граница — не техническое ограничение возможностей ИИ, а осознанный выбор владельца системы: где заканчивается зона «пусть работает само» и начинается зона «здесь нужен взгляд человека». Настройка этой границы — тонкая работа, требующая понимания конкретно вашего бизнеса, и именно поэтому в этой книге мы показываем лишь принцип, а не готовую настройку — тем более что настройка подобной автоматизации требует специфических технических инструментов, разбор которых выходит за рамки книги и относится уже к практической части обучения.
Если вы уже сталкивались с автоматизацией через готовые интеграции между сервисами — когда один сервис умеет напрямую передавать данные другому по заранее оговорённому техническому каналу, — важно понимать разницу с тем, о чём эта глава. Прямая интеграция быстрее и надёжнее там, где она доступна, потому что не зависит от интерфейса, рассчитанного на человека, — но она в принципе не существует для огромного количества сайтов и сервисов, которые никогда не открывали такой технический доступ для сторонних программ.
Способность агента работать через обычный, «человеческий» интерфейс сайта — это как раз способ достучаться туда, где прямой технической интеграции никогда не будет, потому что сервис её просто не предоставляет. Это не замена интеграциям там, где они есть, а способ расширить автоматизацию на то огромное пространство сайтов и площадок, которые интеграций не предлагают в принципе и, скорее всего, никогда не предложат, потому что не для этого создавались.
Стоит отдельно подчеркнуть, что даже без единого совершённого «активного» действия — без единого клика или отправленной формы — сама способность агента регулярно и внимательно просматривать множество внешних источников уже представляет собой самостоятельную ценность. Пропущенная новая заявка, появившаяся ночью на одной из десятка площадок, где работает компания, — это упущенная возможность, которую человек физически не может отследить, если не проверяет каждую площадку вручную по несколько раз в день.
Регулярный, терпеливый просмотр множества источников — это именно та рутина, где параллельная и постоянная работа агента даёт эффект, несоразмерный простоте задачи: не нужно сложное «умное» решение, нужно просто постоянное, ничего не упускающее внимание, а это ровно то, в чём автоматический процесс объективно превосходит человека, у которого неизбежно заканчиваются силы и концентрация к концу дня.
Как и в случае с любой другой ролью, разумно не выдавать агенту, работающему с браузером, полное доверие сразу же. Практичный путь — начать с наименее рискованных задач: просмотр и сбор информации, где ошибка ничего не стоит, кроме упущенной секунды внимания. По мере того как становится видно, что роль ведёт себя предсказуемо и разбирается именно с теми площадками, для которых её настроили, можно постепенно расширять то, что ей разрешено, — но каждый следующий шаг в сторону более рискованных действий должен быть осознанным решением владельца системы, а не автоматическим продолжением уже выданных полномочий.
Это, по сути, тот же принцип постепенного доверия, о котором шла речь в третьей главе применительно к любому агенту вообще, — просто применённый к самой чувствительной по последствиям категории действий: тем, что происходят не в переписке, а во внешнем, реальном для компании и её репутации пространстве.
В материалах про автоматизацию часто мелькают эффектные цифры — «экономит 70% времени», «освобождает целый рабочий день», — и к таким обещаниям стоит относиться настороженно, если они не привязаны к конкретной задаче. Честная оценка выглядит скромнее и зависит от того, сколько площадок вы вообще мониторите вручную и как часто. Если раньше вы или кто-то из ваших сотрудников тратил, скажем, по пятнадцать-двадцать минут несколько раз в день на обход десятка сайтов в поисках новых заявок — это уже час-полтора рабочего времени ежедневно, которое уходило не на содержательную работу, а на механический просмотр одних и тех же страниц в надежде, что там появится что-то новое.
Именно эта механическая, но требующая постоянного внимания часть работы — то, что реалистично забирает у вас браузерный агент, а не какая-то абстрактная и труднопроверяемая доля «всего рабочего времени». Честная рамка ожиданий здесь звучит так: не «ИИ теперь ведёт весь бизнес вместо меня», а «конкретная, измеримая рутина конкретного типа больше не требует моего личного внимания каждый день», — и именно вторая, куда более скромная формулировка на практике оказывается устойчивой и не разочаровывает при столкновении с реальностью.
Стоит закрыть эту главу без иллюзий, к которым легко скатиться: способность агента работать с браузером — это не полная и окончательная замена человека, сидящего за компьютером. Это расширение зоны, где рутинные, повторяющиеся, хорошо описываемые действия можно делегировать, освобождая внимание человека для того, что действительно требует его суждения, — оценки нестандартной ситуации, решения по спорному вопросу, творческой части работы.
Граница между «это можно поручить агенту» и «здесь всё ещё нужен человек за экраном» будет неизбежно сдвигаться дальше по мере того, как технологии становятся надёжнее. Но сегодня разумная позиция — не пытаться заранее угадать, где эта граница окажется через год, а честно смотреть на то, что работает уже сейчас, и постепенно расширять автоматизацию именно оттуда, где она подтвердила свою надёжность на практике, а не там, где кажется, что «наверное, тоже должно сработать».
В последней главе — подведём итог всему, о чём говорили в этой книге, и поговорим честно о том, кому действительно стоит идти строить такую систему для себя, а кому пока рано или не нужно вовсе.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Прежде чем подвести итог, полезно быстро вспомнить, как именно мы сюда пришли — не для того, чтобы пересказать содержание, а чтобы увидеть его как единую логическую цепочку, а не десять разрозненных тем. Мы начали с наблюдения, что один помощник экономит время на исполнение, но не на управление процессом, — и что настоящий следующий шаг это не более мощный помощник, а другая схема организации труда. Дальше мы разобрали, почему эта схема строится на узких, а не универсальных ролях, и что происходит, когда границы между ролями размываются. Мы заглянули внутрь понятия «агент» и увидели, чем он отличается и от чата, и от жёсткого скрипта, и даже от найма живого человека. Мы разобрались, как роли передают друг другу работу без необходимости говорить друг с другом напрямую и синхронно. Мы отдельно остановились на двух ролях, без которых система не держится, — секретаре как едином голосе компании наружу и независимом контроле качества. Поднялись на уровень выше — к организационной структуре в целом — и увидели, как отдельные роли группируются в отделы вокруг общей цели, а не общего типа задачи. И закончили двумя более техническими, но не менее важными темами — параллельной работой нескольких ролей одновременно и способностью агента действовать за пределами текста, в браузере.
Если вы дошли до этой главы, у вас в голове уже должна была сложиться довольно цельная картина — не рецепт, а именно картина того, как устроена компания, которой управляет команда ИИ-агентов, а не один универсальный помощник. Вы знаете, чем несколько узких ролей отличаются от одной широкой, — и почему узость на самом деле сила, а не ограничение. Вы знаете, что агент — это не бот и не скрипт, а роль с контекстом, инструкцией и границами полномочий. Вы понимаете идею общего потока задач, через который роли передают друг другу работу, не завися от того, работают ли они синхронно. Вы видели, зачем нужна роль секретаря как единственного голоса компании наружу, и почему производство и контроль качества должны быть разными ролями. Вы представляете, как отдельные роли складываются в отделы, а отделы — в целую структуру. И вы понимаете, что параллельная работа нескольких ролей и способность агента действовать в браузере — это не фантастика, а реально работающие сегодня возможности, у которых, впрочем, есть свои границы и свои риски.
Это уже немало. Большинство людей, которые говорят «у меня в компании работает ИИ», на деле имеют в виду один чат, который иногда что-то пишет за них. Вы теперь понимаете разницу между этим и настоящей системой — а понимание разницы часто важнее, чем кажется, потому что именно оно позволяет честно оценить, куда двигаться дальше.
Здесь стоит остановиться и сказать прямо то, что редко говорят в книгах, которые продают следующий шаг: мультиагентная система — это не универсальное благо для любого бизнеса на любой стадии. Если у вас один-два повторяющихся типа задач и один помощник с ними прекрасно справляется — усложнять систему до нескольких ролей, отделов и общего потока задач может быть избыточным. Сложность имеет свою цену: это время на проектирование, дисциплина в том, чтобы держать роли узкими и не размывать границы, и постоянное внимание к тому, как система работает в целом, а не просто к тому, что говорит очередной чат.
Идти в сторону мультиагентной системы имеет смысл тогда, когда вы уже упёрлись в реальный, а не воображаемый потолок: задач стало действительно много и они действительно разного типа, вы физически не успеваете держать в голове весь процесс от заявки до сдачи, и вы уже пробовали простую автоматизацию с одним помощником — и она перестала справляться с объёмом или разнообразием работы. Если это ваша ситуация — тогда да, следующий шаг именно такой, каким он описан в этой книге.
Второе, что стоит сказать прямо: то, что описано в этой книге, — не «нажал кнопку и получил компанию на автопилоте». Мультиагентная система требует спроектированных ролей, продуманных границ ответственности, работающего механизма передачи задач и — что особенно легко недооценить — постоянного присмотра за тем, как система ведёт себя на практике, а не только в теории. Это ближе к тому, чтобы построить и настроить небольшой, но настоящий офис, чем к тому, чтобы установить приложение.
Хорошая новость в том, что этот офис, в отличие от офиса с живыми людьми, не требует зарплат, отпусков и больничных, работает практически без перерывов и масштабируется без пропорционального роста затрат. Но требует он того же, что требует любой работающий офис от своего владельца: ясности в том, кто за что отвечает, и внимания к тому, что происходит на самом деле, а не только к тому, что написано в плане.
Прежде чем перейти к практическому первому шагу, стоит честно взвесить и обратную сторону — цену того, чтобы не менять ничего вообще. Она редко ощущается как разовый удар, скорее как медленная, почти незаметная утечка: чуть больше времени уходит на рутину каждую неделю, чуть чаще что-то теряется между задачами, чуть медленнее вы реагируете на новые возможности, потому что физически не успеваете параллельно вести всё, что могли бы вести. По отдельности каждая из этих потерь невелика. Накопленные за месяцы, они превращаются в вполне ощутимую разницу между тем, сколько бизнес мог бы делать, и тем, сколько он делает на практике, упираясь в возможности одного человека и одного помощника.
Это не означает, что нужно бросаться перестраивать всё немедленно и любой ценой — мы уже проговорили, что мультиагентная система нужна не каждому и не на любой стадии. Но честная картина требует держать в голове и эту сторону весов, а не только цену усложнения системы, — иначе решение «пока оставить всё как есть» принимается не потому, что это действительно лучший вариант для вашего бизнеса, а просто по инерции, из-за того что перемены требуют усилия, а бездействие не требует ничего.
Если, прочитав всю книгу, вы понимаете, что это ваш случай, — полезно начать не с технической настройки, а с довольно простого упражнения: честно выписать, какие роли реально нужны именно в вашей работе. Не абстрактный список «маркетинг, продажи, поддержка», а то, что действительно повторяется у вас каждую неделю и отнимает время: кто у вас сейчас отвечает клиентам, кто готовит материалы, кто проверяет результат перед тем, как он уйдёт наружу, кто считает деньги. Скорее всего, окажется, что часть этих ролей вы уже выполняете сами, просто не называя их так, — и именно это первое честное описание становится основой для того, чтобы начать разносить обязанности по отдельным ИИ-ролям, а не пытаться удержать всё в одной голове и дальше.
Дальше начинается уже прикладная часть — как именно описать роль так, чтобы ИИ реально ей следовал, как организовать общий поток задач технически, как выстроить проверку качества так, чтобы она не превратилась в формальность. Это ровно то, что не входит в задачу этой книги, — не потому что нам жалко поделиться, а потому что честная практическая настройка требует куда большего объёма, разбора конкретных примеров и обратной связи по вашей собственной ситуации, чем может уместиться в главы книги.
Даже до того, как вы примете решение, строить систему или нет, есть один шаг, который стоит сделать прямо после прочтения этой книги, — он не требует никакой технической настройки и не рискует ничем. Возьмите лист бумаги или пустой документ и честно, без прикрас опишите один рабочий день — не идеальный, а типичный, со всеми переключениями между задачами, которые вы обычно даже не замечаете, потому что давно к ним привыкли.
Отметьте на этом описании моменты, где вы лично выступали передаточным звеном между двумя частями процесса, ничего по сути не решая, — просто перенося информацию из одного места в другое, напоминая себе, что нужно сделать дальше, или дожидаясь, пока освободится время заняться следующим шагом. Это упражнение занимает двадцать минут, но даёт то, чего не даст никакая теория, — конкретную, вашу собственную картину того, где именно у вас в работе спрятан тот самый «один помощник за клавиатурой», о котором шла речь в первой главе. Это самое надёжное основание для решения, идти ли дальше в сторону мультиагентной системы, — куда надёжнее, чем абстрактное «звучит интересно» или «наверное, нам бы это подошло».
Если вы читаете эту книгу — скорее всего, вы уже прошли путь от «попробовал ИИ-чат один раз» до «хочу выстроить систему», возможно, через простую автоматизацию с одним помощником, о которой шла речь в предыдущей книге этой серии. Это значит, что вы именно та аудитория, для которой имеет смысл идти в самую глубокую, практическую часть обучения — туда, где мы разбираем не принципы, а конкретную настройку: как выглядит структура роли на практике, как реально устроен обмен задачами между агентами, как шаг за шагом выстроить контроль качества, который действительно работает, а не просто существует на бумаге.
Полная практика — с разбором реальных примеров, шаблонами и обратной связью по вашей ситуации — ждёт вас в Telegram-боте @om_ai_teacher_bot, на Продвинутом уровне курса. Дальше в книге — расширенный рассказ о том, что именно входит в каждый уровень обучения и как выбрать подходящий именно вам.
Мы начали эту книгу с образа одного помощника, который экономит время на написание, но не на управление процессом. Заканчиваем мы её похожим, но зеркальным образом: мультиагентная система не экономит вам всю работу целиком и не превращает бизнес в нечто, что крутится само по себе без вашего участия. Она меняет то, какую именно работу вы делаете лично, — убирая рутинную склейку процессов вручную и оставляя вам то, что действительно требует владельца: направление, нестандартные решения, ответственность за необратимое.
Если это звучит не как волшебная кнопка, а как честный, пусть и не самый простой, следующий шаг в развитии вашего дела — значит, книга донесла именно то, что должна была донести. Дальше — дело практики, и туда мы вас с удовольствием ждём.
👉 Хотите разобрать эту тему пошагово, с практикой и обратной связью? Полный курс — в Telegram-боте @om_ai_teacher_bot
Эта книга сознательно останавливалась на границе между пониманием и практикой. Вы получили карту — что такое агент, зачем нужны узкие роли, как они передают друг другу задачи, зачем в системе отдельный секретарь и отдельный контроль качества, как всё это складывается в структуру и что значит работать по-настоящему параллельно и действовать в браузере. Но карта — это ещё не сама дорога. Дальше начинается практика: как на самом деле спроектировать роль под вашу задачу, как реально организовать передачу задач между агентами, как выстроить рабочий конвейер так, чтобы он не разваливался при нагрузке, — а это уже разбор именно вашей ситуации, с обратной связью, а не общий текст, одинаковый для всех читателей.
Какой именно формат обучения и что конкретно в него входит — проще увидеть внутри диалога с ботом, чем в печатном тексте книги: откройте в Telegram @om_ai_teacher_bot, и он поможет разобраться, что подойдёт именно вашей ситуации.
Почитать про саму компанию OM-Digital, на примере которой строилась вся эта книга, — увидеть, как всё это выглядит не в теории, а в работающем виде, — можно на сайте https://om-digital.ru.
Спасибо, что дочитали до конца. Если из десяти глав хотя бы одна идея заставила вас взглянуть на свою рутину иначе — книга уже сделала свою работу.
Хотите освоить Claude и AI-агентов на практике — с разбором реальных кейсов и поддержкой?
Перейти в @om_ai_teacher_botChatGPT для бизнеса и ChatGPT для текстов — два разных сценария, и путать их дорого. В книге разобрано, где модель заменяет исполнителя, а где остаётся черновиком, который всё равно придётся править человеку.
ИИ для маркетинга разобран подробнее остальных направлений: как выглядит рабочий процесс, если сделать нейросеть для текстов частью редакции, и почему без правки живым редактором такие тексты узнаются с первого абзаца.