Компания, в которой работает ИИ. Агенты, автоматизация и новые правила управления

3. Отслеживание на основе этапов рецензирования и тестирования: дефекты являются одним из основных источников переделок. Поэтому отслеживание количества и серьезности дефектов, обнаруженных на этапах рецензирования кода (Code Review) и тестирования в рамках обеспечения качества (QA), также позволяет косвенно оценить масштаб переделок. Затраты на доработку логической ошибки, обнаруженной и исправленной на этапе рецензирования, намного ниже, чем затраты на исправление ошибки (бага), обнаруженной пользователями уже после выпуска продукта в производственную среду. Таким образом, можно ввести показатель «коэффициента ускользания дефектов» (Defect Escape Rate) — долю дефектов, «ускользнувших» из одного этапа в следующий. Например, количество дефектов, «проскочивших» из этапа разработки на этап тестирования, или количество дефектов, «проскочивших» из этапа тестирования в производственную среду. Чем выше коэффициент ускользания, тем выше затраты на доработку и тем серьезнее последствия.

Методы отслеживания

Основные инструменты/платформы

Преимущества

Недостатки

Ключевые моменты внедрения

На основе коммитов кода

Git, Harness, Minware

Объективные данные, высокая степень автоматизации, возможность выявления нестабильности на уровне кода

Сложность в различении оптимизации и переделки, для анализа требуется специализированная платформа

Разработка четких правил коммитов кода, определение количественных критериев для «переделки кода»

На основе управления проектами

Jira, Zenhub, Asana

Учитывают бизнес-контекст, имеют чёткие определения, легко понятны и реализуемы для команды

Зависит от ручной маркировки, что приводит к пропускам; требует строгой процессуальной дисциплины

Унифицировать определение и методы маркировки переделок, регулярно проводить аудит точности данных

На основе рецензирования и тестирования

Инструменты статического анализа кода, платформы управления тестированием

Позволяет выявлять проблемы на ранних этапах, снижать затраты на доработку, тесно интегрируется с системой контроля качества

Невозможно охватить все типы доработок (например, изменения требований), показатели являются относительно косвенными

Создание стандартизированного процесса управления дефектами, количественная оценка коэффициента пропуска дефектов на разных этапах

Независимо от выбранного метода, ключевым моментом является создание непрерывного цикла обратной связи. Цель измерения показателя доработок заключается не в том, чтобы наказать инженеров, допустивших ошибки, а в том, чтобы, подобно врачу, диагностировать «очаги заболевания» в системных процессах и принять целенаправленные «лечебные» меры. Причина в том, что документация по требованиям составлена недостаточно четко? Или в недостаточном охвате модульных тестов? Или, возможно, в отсутствии единого понимания системной архитектуры в команде? Благодаря анализу первопричин (Root Cause Analysis) задач, требующих доработки, организации, ориентированные на ИИ, могут выявить слабые звенья в процессах и систематически сократить объем доработок путем внедрения инструментов автоматизации, усиления обучения и оптимизации процессов сотрудничества. Таким образом, они смогут направить больше усилий на подлинную инновационную деятельность, сделав поток создания ценности более чистым и плавным.

Способность к восстановлению после сбоев: построение непоколебимой «цифровой иммунной системы»

Если циклическое время и коэффициент переделок являются «копьем», измеряющим «наступательную» способность организации, то «устойчивость к сбоям» (Resilience) — это «щит», измеряющий её «оборонительную» способность. В всё более сложном и полном неопределённости цифровом мире сбои уже не являются вопросом «произойдут ли они», а вопросом «когда они произойдут» и «как на них реагировать». Серверы могут выйти из строя, сеть может прерваться, API сторонних разработчиков могут перестать работать, и даже недавно запущенный интеллектуальный агент (Agent) может вызвать непредвиденный «эффект бабочки». Способность к восстановлению после сбоев означает способность системы выдерживать, адаптироваться и быстро восстанавливать основные функции при столкновении с такими непредвиденными воздействиями (как известными, так и неизвестными). Это «цифровая иммунная система» организации, которая определяет, рухнет ли она под натиском бури, останется ли непоколебимой или даже станет ещё сильнее.

Традиционные подходы к аварийному восстановлению (Disaster Recovery) и высокой доступности (High Availability) сосредоточены на том, как реагировать на известные и предсказуемые сбои, такие как повреждение оборудования. В то же время «инженерия устойчивости» (Resilience Engineering), к которой стремятся организации, изначально построенные на ИИ, представляет собой более проактивную и системную парадигму мышления. Она признает, что «непредвиденное» — это норма, и переносит акцент с «предотвращения сбоев» на «элегантное преодоление сбоев». Как сказал бывший архитектор облачных систем Netflix Эдриан Кокрофт (Adrian Cockcroft), цель Netflix заключается не в создании системы, которая никогда не выходит из строя, а в создании системы, сбои в которой пользователи практически не замечают даже при частичном выходе из строя. Их знаменитая практика «хаос-инжиниринга» (Chaos Engineering), заключающаяся в активном внедрении сбоев в производственную среду с целью постоянной проверки и укрепления отказоустойчивости системы, является ярким воплощением этой философии.

Для оценки и построения такой «неуязвимой» цифровой иммунной системы нам необходима системная оценочная структура. Опираясь на соответствующие исследования в области сложных инженерных систем (Hoseyni & Cordiner, 2024), мы можем построить эту структуру по двум измерениям и четырём этапам, охватывающим весь процесс от «пассивной защиты» до «активной эволюции»:

1. Абсорбционная способность (Absorptive Capacity): способность системы выдерживать удары без снижения функциональности. Это похоже на амортизаторы в автомобиле. Для оценки этой способности необходимо ответить на вопрос: обладает ли наша система достаточным запасом прочности и буфером, чтобы противостоять типичным колебаниям? Например, способен ли наш кластер серверов справиться с внезапными пиками трафика? Способен ли наш механизм кэширования обеспечить нормальное выполнение основных операций чтения в случае кратковременной недоступности базы данных?

2. Адаптивная способность (Adaptive Capacity): когда нагрузка выходит за пределы поглощающей способности, способна ли система адаптироваться к новым условиям путем корректировки своей структуры или поведения и при этом поддерживать работу ключевых функций? Это похоже на то, как организм человека в условиях высокогорья постепенно увеличивает количество эритроцитов. Для оценки этой способности необходимо ответить на вопрос: обладает ли наша система механизмом «плавного перехода на пониженный уровень»? Например, в случае сбоя платежного шлюза сможет ли система автоматически переключиться на резервный канал или временно отключить второстепенные транзакционные функции, чтобы гарантировать, что основной бизнес не пострадает?

3. Восстановительная способность (Restorative Capacity): насколько быстро система способна восстановить нормальное состояние после сбоя. Это похоже на скорость заживления раны после травмы. Для оценки этой способности необходимо ответить на вопрос: каково наше среднее время восстановления (Mean Time To Repair, MTTR)? Имеем ли мы автоматизированные механизмы обнаружения сбоев и восстановления? Например, когда экземпляр службы выходит из строя, может ли наша платформа оркестрации контейнеров (такая как Kubernetes) автоматически запустить новый экземпляр в течение нескольких секунд?

4. Способность к обучению и адаптации: способна ли система извлекать уроки из прошлых сбоев и постоянно развиваться, чтобы лучше справляться с неизвестными вызовами будущего. Это высший уровень восстановительной способности, ключ к построению «антихрупких» (Antifragile) систем. Для оценки этой способности необходимо ответить на следующие вопросы: имеем ли мы отлаженный механизм анализа причин сбоев (Post-mortem)? Превращаем ли мы опыт, извлечённый из сбоев, в конкретные усовершенствования архитектуры, оптимизацию процессов или стратегии автоматизации?

Аспекты устойчивости

Основные цели

Примеры вопросов для оценки

Ключевые технологии/практики

Примеры показателей

Способность к адаптации

Устойчивость к нагрузкам и поддержание стабильности

Способна ли система справляться с внезапными всплесками трафика? Способен ли буфер противостоять сбоям в бэкэнде?

Равномерное распределение нагрузки, резервирование, эластичное масштабирование ресурсов

Запас пропускной способности системы, коэффициент попадания в кэш

Адаптивность

Регулируемое поведение, плавный переход на резервные ресурсы

Возможно ли автоматическое переключение при сбое оплаты? Можно ли изолировать второстепенные функции?

Понижение уровня обслуживания, механизм «предохранителя», включение/выключение функций (Feature Flag)

Доступность ключевых функций в случае сбоя

Восстановительная способность

Быстрое устранение неисправностей и восстановление нормальной работы

Автоматизированы ли обнаружение сбоев и восстановление? Каково среднее время устранения неисправностей?

Автоматизация эксплуатации и обслуживания, оркестрация контейнеров (Kubernetes) Развертывание по принципу «синий-зеленый»

Среднее время устранения неисправности (MTTR), время обнаружения неисправности

Обучение и развитие

Обучение на ошибках, постоянное совершенствование

Существует ли механизм анализа неисправностей? Превращается ли опыт в конкретные действия?

Хаотическая инженерия, тестирование с имитацией сбоев, анализ первопричин (RCA)

Частота повторяющихся сбоев, доля выполненных улучшений архитектуры

Эта концепция предоставляет организациям, ориентированным на ИИ, дорожную карту для оценки и повышения собственного «иммунитета». Она больше не ограничивается отдельными техническими показателями, а рассматривает состояние системы с целостной и динамичной точки зрения. Только следуя рекомендациям этой концепции и постоянно проводя нагрузочные тесты, хаотические эксперименты и симуляции сбоев, организация сможет по-настоящему создать мощную цифровую иммунную систему, спокойно реагировать на будущую неопределённость и становиться всё более устойчивой и сильной после каждого удара.

Часть 2. Направление 1: Интеллектуальные агенты становятся «новыми коллегами в организации»

Глава 5.

Минимальный замкнутый цикл интеллектуального агента: цели, планы, инструменты, обратная связь

В одну из сред ноября 2025 года в Шанхае небо было пасмурным, словно промокший до нитки серый войлок. Настроение Чэнь Си (Chen Si), директора по маркетингу перспективного потребительского бренда «Benwei Life», было таким же. Она только что завершила двухчасовое квартальное совещание по итогам работы, и в конференц-зале царила удушающая атмосфера. Генеральный директор (CEO) на встрече безжалостно указал, что их «система прогнозирования хитов», которой они так гордились — проект в области искусственного интеллекта (ИИ), стоивший миллионы и на который возлагались большие надежды, — в этом квартале полностью провалилась. Три «потенциальных хита», предсказанных системой, в итоге показали на рынке посредственные результаты, а настоящий хит оказался произведением, созданным на ходу малоизвестным дизайнером из компании-конкурента.

«Нам нужна более быстрая реакция на рынок и более глубокое понимание конкурентов!» — слова генерального директора, сопровождавшиеся ударом по столу, всё ещё звучали в ушах. «Чем вообще занимается наш ИИ? Он кажется всезнающим, но почему всегда упускает самое главное?»

С этим тяжёлым вопросом Чэнь Си вернулась в свой кабинет. Она вспомнила о другой системе «интеллектуального сотрудника», которую компания с большим размахом внедрила в начале года. Во время демонстрации поставщика плавный диалог и способность быстро генерировать отчёты воодушевили всех. Вице-президент по продажам тут же принял решение, назвав систему «Ноевым ковчегом, который приведёт нас в эпоху искусственного интеллекта». Чэнь Си тогда была не менее воодушевлена: первая команда, которую она отдала этому интеллектуальному агенту под названием «Insight No. 1», звучала так: «Непрерывно отслеживай и анализируй активность основного конкурента — «Light Food Style» — в социальных сетях, еженедельно составляй отчет об огласке и анализе настроений пользователей».

В первые две недели работа «Insight No. 1» была просто безупречной. Каждый понедельник в девять утра в почтовый ящик Чэнь Си своевременно поступал отчет, отличавшийся изысканным оформлением и насыщенный иллюстрациями. Однако начиная с третьей недели возникли проблемы. Данные в отчетах стали нечеткими, некоторые ключевые случаи негативных отзывов были пропущены, а однажды в отчете даже были смешаны два совершенно не связанных между собой бренда. Техническая команда Чэнь Си несколько раз связывалась с поставщиком, но в ответ всегда слышала: «Модель находится в процессе обучения» или «Мы уже оптимизировали промпты», однако качество отчетов продолжало ухудшаться. Самый серьезный случай произошел на одном из ключевых совещаний по принятию решений о продукте: Чэнь Си процитировала выводы из отчета «Insight No. 1» об эффективности маркетинговой кампании конкурента, но один из стажеров тут же указал на то, что данные полностью неверны — так называемая «вирусная кампания» на самом деле была досрочно прекращена из-за проблем с бюджетом. Чэнь Си до сих пор ясно помнит ту неловкость, которую испытала в тот момент.

Она без сил опустилась на стул и, глядя на мчащийся за окном поток машин, почувствовала огромное чувство беспомощности. Почему эти, казалось бы, такие умные ИИ, попадая в реальную, сложную и динамичную бизнес-среду, становятся такими уязвимыми? Они могут цитировать авторитетные источники, имитировать любой стиль письма, за секунду генерировать казалось бы профессиональную аналитическую структуру, но почему они не могут надежно «сделать хоть что-то»? Это похоже на то, как если бы вы наняли сотрудника с блестящим резюме и красноречивым языком, но как только он приступает к работе, в его действиях появляется масса ошибок, и он не может предоставить надежный результат. Эта проблема беспокоит не только Чэнь Си, но и десятки тысяч компаний по всему миру, которые амбициозно стремятся к трансформации, основанной на ИИ.

1. Почему многие интеллектуальные системы «выглядят так, будто умеют говорить, но не умеют действовать»

Проблема, с которой столкнулся Чэнь Си, является одной из самых распространенных и ключевых проблем в сфере применения ИИ на сегодняшний день. Согласно прогнозам известной консалтинговой компании Gartner, к концу 2027 года более 40 % проектов по внедрению интеллектуальных систем на базе ИИ будут отменены (Gartner, 2025). За этой поразительной цифрой стоит не потеря доверия компаний к ИИ, а то, что они обнаружили: между «болтливым чат-ботом» и «умным сотрудником», способным самостоятельно выполнять сложные задачи, лежит огромная пропасть. Эта пропасть — разрыв между «словами» и «делами».

Корень проблемы заключается в том, что в настоящее время основным движущим механизмом подавляющего большинства систем, называемых «интеллектуальными системами», по-прежнему являются крупные языковые модели (Large Language Model, LLM). По сути, LLM — это основанный на вероятностях генератор текста, который, изучая огромные объемы текстовых данных, осваивает законы языка, фактические знания и определенные способности к логическому мышлению. Это позволяет ей понимать человеческие команды и генерировать логически связные и содержательные ответы. Именно поэтому, когда мы общаемся с ChatGPT, Wenxin Yiyan или любым другим подобным ИИ, мы восхищаемся их эрудицией и беглостью речи. Они — превосходные «ораторы».

Однако «выполнять» задачу и «описывать» задачу — это два совершенно разных навыка. Настоящему действующему субъекту требуются не только знания и языковые навыки, но и замкнутая система, способная разбивать цели на действия и надежно взаимодействовать с физическим или цифровым миром. Интеллектуальное существо, умеющее только говорить, подобно военному стратегу, разбирающемуся только в теории: на песочной карте он может просчитывать движения тысяч войск, но на реальном поле боя, возможно, не сможет сделать и шага. Ведь реальный мир полон неопределённости, динамичных изменений и деталей реализации.

Мы можем понять фундаментальное различие между «словами» и «действиями» с помощью простого сравнения.

Измерение

Говорящий (LLM)

Действующий субъект (интеллектуальный агент)

Основные способности

Генерация текста на основе вероятности

Выполнение задач на основе целей

Режим диалога

Диалог, вопросы и ответы, генерация контента

Взаимодействие с окружающей средой (API, базы данных, веб-страницы)

Критерии успеха

Релевантные, плавные и логичные ответы

Успешное выполнение задачи, проверка результатов

Предположения о среде

Статичность, полнота информации

Динамическая, неполная информация, задержки

Обработка ошибок

Генерирование «иллюзий» или ошибочной информации

Выявление ошибок, попытка исправления, обращение за помощью

Реализация ценности

Получение информации, систематизация знаний, стимулирование творчества

Автоматизация процессов, достижение измеримых бизнес-результатов

Эта таблица наглядно демонстрирует пропасть между ними. Успех LLM заключается в том, насколько он способен «говорить как» эксперт; а успех подлинного интеллектуального агента — в том, может ли он постоянно и надежно «делать все правильно». Когда «Insight No. 1» от ChenSi не может точно собрать информацию о конкурентах, он обнажает свои ограничения как «говорителя». Он, возможно, знает, какие шаги включает в себя задача «анализа динамики конкурентов», и даже может сгенерировать план, выглядящий вполне прилично, но при выполнении каждого шага — например, при посещении нужных социальных сетей, вызове соответствующих API, фильтрации и проверке достоверности информации — ему не хватает прочной и надёжной рамки действий. На уровне «говора» он демонстрирует отличные результаты, но на уровне «действия» оказывается беспомощным.

Это явление «умеет говорить, но не умеет делать» в основном обусловлено следующими глубинными причинами:

Отсутствие «приземлённого» понимания реального мира. Знания LLM происходят из статичных наборов данных прошлого. Он знает, что такое «курс акций», но не может в режиме реального времени запросить и понять, что означают текущие колебания цены той или иной акции. Он знает, что такое «бронирование авиабилетов», но не способен справиться с реальным сайтом бронирования, включающим в себя ввод проверочного кода, многоэтапное подтверждение и этап оплаты. Его понимание мира носит «теоретический», а не «практический» характер. Действия требуют взаимодействия с интерфейсами реального мира (API, инструменты), а сложность и динамичность такого взаимодействия далеко не всегда могут быть полностью описаны статическим текстом.

Уязвимость способности к логическому мышлению. Хотя LLM демонстрируют определенные способности к логическому мышлению, такое мышление зачастую носит «одношаговый» или «цепочечный» характер и не предполагает долгосрочного планирования и динамической корректировки. Сложная задача, такая как «организация онлайн-презентации для компании», требует разбиения на десятки, а то и сотни подзадач, включающих утверждение бюджета, приглашение гостей, подготовку контента, технические испытания, рекламную кампанию и многое другое. Между этими этапами существуют сложные взаимозависимости и временные ограничения.LLM, возможно, сможет перечислить эти этапы, но ему будет сложно в процессе выполнения динамически корректировать весь план с учетом непредвиденных обстоятельств (таких как внезапное отсутствие гостя или сбой сервера). Если в цепочке его рассуждений произойдет ошибка на каком-либо этапе, это может привести к провалу всей задачи, причем самому LLM будет сложно понять, в чем именно заключается ошибка.

Нечеткое определение понятия «завершение». Для LLM задача считается «завершенной», как только он сгенерирует текст. Однако для интеллектуального агента определение «завершения» гораздо более строгое. Отчет не считается завершенным после того, как он написан; необходимо убедиться, что все данные в нём точны, а каждый вывод подкреплён фактами. Заказ не считается выполненным после его отправки; необходимо подтвердить успешную оплату, списание товара со склада и формирование логистической информации. При отсутствии чёткого и измеримого «критерия завершения» интеллектуальный агент легко попадает в ловушку, когда он «сделал», но «сделал неверно» или «не до конца».

Поэтому, чтобы интеллектуальная система эволюционировала от «умного собеседника» до «надежного цифрового сотрудника», мы должны построить для нее минимальный замкнутый цикл действий. Этот цикл не зависит от абстрактного «интеллекта» самой модели, а через структурированную рамку наделяет ее способностью надежно воспринимать, планировать, действовать и учиться. Эта структура включает четыре неотъемлемых компонента: цель (Goal), план (Plan), инструмент (Tool) и обратную связь (Feedback). Эти четыре компонента вместе составляют минимальную единицу, создающую ценность для организации, и являются основным двигателем, отличающим организации, построенные на ИИ, от традиционных цифровых предприятий.

2. План — это не длительное рассуждение, а выполнимые шаги и контрольные точки

Если осознание разницы между «умением говорить» и «умением действовать» является первым шагом к созданию надежного интеллектуального агента, то разработка действительно выполнимого плана — это ключ к воплощению действия «делать» в жизнь. Суть многих провальных проектов по созданию интеллектуальных систем заключается в смешении двух понятий: «рассуждение» и «план». Их авторы пытаются заставить крупные языковые модели вести длинные рассуждения, генерировать грандиозную программу действий, а затем ожидают, что эта программа будет успешно реализована. Но это ничем не отличается от использования стихотворения в прозе в качестве строительного чертежа — провал в таком случае практически предрешен.

Крупные языковые модели специализируются на «цепочке мысли» (Chain of Thought): они имитируют процесс человеческого мышления, генерируя серию промежуточных шагов, чтобы в итоге вывести окончательный ответ. Это очень эффективно при решении логических головоломок, выполнении математических вычислений или ответе на сложные вопросы. Например, вы спрашиваете: «Если у команды есть 5 проектов, каждый из которых требует участия 3 разработчиков в течение 4 недель, а затраты на каждого разработчика составляют 2000 долларов в неделю, то какова общая стоимость?» Модель сгенерирует цепочку рассуждений примерно такого вида: «Сначала рассчитаем стоимость каждого проекта.3 разработчика умножить на 4 недели умножить на 2000 долларов в неделю равняется 24 000 долларов. Затем рассчитаем общую стоимость. 5 проектов умножить на 24 000 долларов за каждый проект равняется 120 000 долларов. Таким образом, общая стоимость составляет 120 000 долларов».

Этот процесс выглядит как план, но им не является. Это «объяснение», логическая дедукция, проводимая для вывода заключения. По сути, это по-прежнему генерация текста, и ни один из её шагов не является проверяемым действием, позволяющим взаимодействовать с внешним миром. Она предполагает замкнутый, статичный мир, в котором вся информация известна. Однако задачи в реальном мире кардинально отличаются. Когда вы поручаете интеллектуальному агенту «проанализировать динамику конкурентов», он сталкивается с открытой, динамичной средой: сайты конкурентов могут быть обновлены, API-интерфейсы могут измениться, информация в социальных сетях может оказаться ложной, а интернет-соединение — прерваться. В таких условиях план, напоминающий «прозаическую поэму», бесполезен; интеллектуальному агенту нужна «боевая карта», точная до каждого шага.

Основной особенностью выполнимого плана является не длительность или сложность рассуждений, а то, что он состоит из ряда «выполнимых шагов» и «четких контрольных точек». Он разбивает грандиозные цели на конкретные, атомарные и проверяемые единицы действий.