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

Размерность

Цепочка рассуждений (Chain of Thought)

Выполнимый план (Executable Plan)

Базовые единицы

Текстовые шаги мышления

Вызываемые инструменты или API

Цель

Генерация окончательного ответа или объяснения

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

Структура

Линейный, неструктурированный текст

Структурированный (например, последовательность, диаграмма, дерево), поддающийся машинному анализу

Способы проверки

Логическая согласованность, ручная оценка

Автоматическая проверка после выполнения каждого шага с помощью контрольных точек

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

Сложно определить местоположение; ошибки передаются и усиливаются

Четкие алгоритмы обработки исключений (повторная попытка, переключение на альтернативный вариант, отчет о сбое)

Динамическая адаптивность

Статическая, генерируется однократно

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

Это сравнение ясно показывает, что суть планирования заключается в «организации действий», а не в «отчете о мыслях». Вернёмся к примеру «Insight No. 1» от Chen Si, чтобы посмотреть, как выглядят плохой и хороший планы.

Плохой план, основанный на «цепочке умозаключений», может выглядеть следующим образом: «Чтобы проанализировать динамику в социальных сетях бренда „Light Food Style“, мне сначала нужно зайти на их официальные аккаунты в Weibo и Douyin. Затем мне нужно просмотреть контент, опубликованный за последний месяц, и выявить те материалы, которые набрали наибольшее количество взаимодействий (лайки, комментарии, репосты). Далее мне нужно собрать комментарии к этим постам с высокой активностью и проанализировать, является ли настроение пользователей положительным, отрицательным или нейтральным. Наконец, я обобщу эти выводы и составлю отчет, в котором выделю их популярные маркетинговые кампании и основные отзывы пользователей».

Этот текст отличается четкой логикой и безупречен, но для машины он совершенно невыполним. Что значит «зайти»? Через браузер или через API? Каковы критерии «просмотра»? Каков конкретный порог для «выявления материалов с наибольшим количеством взаимодействий»? Какие модели и стандарты используются для «анализа настроения»? За каждым неопределенным глаголом скрывается бесчисленное количество ловушек при выполнении.

А «выполнимый план» выглядит совсем иначе — он больше похож на фрагмент компьютерной программы или определение рабочего процесса:

1. Шаг 1: Получение источников данных

Действие: вызвать внутренний инструмент get_social_media_sources, введя параметр brand_name="".

Контрольная точка: проверить, содержит ли возвращённый результат действительные URL-адреса главных страниц в Weibo и Douyin. В случае неудачи отметить ошибку и сообщить о «отсутствии настроек источников данных».

2. Шаг 2: Сбор списка контента

Действие: для каждого URL-адреса, полученного на предыдущем шаге, вызвать инструмент scrape_post_list, установив параметр time_range="last_30_days".

Контрольная точка: проверьте, не пуст ли возвращённый список контента. Если список не пуст, проверьте, содержит ли каждая запись ключевые поля post_id, publish_time, like_count, comment_count, share_count и т. д. Если список пуст или поля отсутствуют, запустите механизм повторных попыток (не более 3 раз). После 3 неудачных попыток отправьте сообщение «Сбой при сборе контента».

3. Шаг 3: Отбор контента с высоким уровнем взаимодействия

Действие: вызвать встроенную функцию filter_high_interaction_posts, передать список контента, собранного на предыдущем шаге, и установить параметр top_n=10.

Контрольная точка: проверьте, удалось ли отфильтровать 10 или менее (если общее количество меньше) записей. Проверьте, являются ли post_id отфильтрованных записей действительными.

4. Шаг 4: Анализ тональности комментариев

Действие: для каждого поста с высоким уровнем взаимодействия вызовите инструмент fetch_comments для получения комментариев, а затем вызовите analyze_sentiment_api для анализа тональности комментариев.

Контрольная точка: Проверить, возвращает ли интерфейс анализа эмоций для каждого комментария один из действительных тегов («positive», «negative» или «neutral») и оценку достоверности. Если вызов интерфейса завершился неудачей или был возвращен неверный формат, зафиксируйте ID этого комментария и перейдите к обработке следующего, указав в итоговом отчете: «Анализ части комментариев не удался».

5. Шаг 5: Создание отчета

Действие: передать все обработанные данные и результаты анализа инструменту generate_report_template для формирования структурированного текста отчета.

Контрольная точка: Проверить, превышает ли размер сгенерированного файла отчета ноль и содержит ли он в тексте заданные заголовки разделов, такие как «Источники данных», «Анализ контента с высокой вовлеченностью» и «Анализ эмоционального настроя пользователей».

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

В последние годы в академических кругах и промышленности было предложено множество передовых рамок планирования для поддержки этой способности, например, классический цикл «планирование-выполнение-мониторинг-перепланирование» (Plan-Execute-Monitor-Replan), а также более передовые рамки, более тесно объединяющие рассуждения и действия, такие как рамка ReAct, совместно предложенная Стэнфордским университетом (Stanford University) и Google(Yao et al., 2022). Основная идея всех этих моделей одинакова: заставить интеллектуальный агент «думать» на каждом этапе действия и динамически корректировать последующие «мысли» и «действия» в зависимости от результатов предыдущих действий.

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

3. Инструменты — это не просто список плагинов, а контролируемые границы действий

Если план — это «мозг» интеллектуального агента, то инструменты — его «руки и ноги». Без инструментов даже самый совершенный план останется лишь воздушным замком. В сфере ИИ под инструментами (Tool) обычно понимаются любые функции, API или сервисы, которые интеллектуальный агент может вызывать для взаимодействия с внешним миром. Это может быть интерфейс SQL для запросов к базе данных, API для отправки электронной почты, автоматизированный скрипт для бронирования конференц-залов на веб-сайте или даже мультимодальная модель для генерации изображений.

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

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

Мы можем сравнить плохой дизайн инструментов в стиле «списка плагинов» с отличным дизайном в стиле «контролируемых границ действий».

Измерение

Список плагинов (Plugin List)

Контролируемое пространство действий (Controlled Action Space)

Философия проектирования

«Чем больше, тем лучше» — предоставлять как можно больше вариантов

«В меру» — предоставлять только минимальный набор, необходимый для выполнения задачи

Определение инструментов

Широкие, универсальные (например, «выполнить код», «посетить веб-страницу»)

Точные, атомарные (например, «проверить статус заказа», «получить адрес электронной почты пользователя»)

Параметры и права доступа

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

Строгие, чётко определённые типы параметров, минимальные права доступа

Надежность

Низкая, зависит от нечеткого понимания естественного языка моделью

Высокая, чёткие входные и выходные данные, предсказуемое поведение

Безопасность

Низкая, возможно выполнение опасных операций (например, удаление файлов, изменение паролей)

Хорошая, действия ограничены безопасным, заранее заданным диапазоном

Комбинируемость

Слабая, инструменты с трудом взаимодействуют между собой, легко возникают конфликты

Сильная, может быть точно скомпонована движком планирования, как кубики «Лего»

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

Рассмотрим более конкретный пример. Допустим, нам нужно создать интеллектуальный агент для обработки запросов клиентов на возврат средств. При подходе, основанном на «списке плагинов», интеллектуальному агенту, возможно, предоставили бы универсальный инструмент с именем execute_sql и сказали бы: «Ты можешь использовать этот инструмент для работы с базой данных и обработки возвратов». Затем, когда поступает запрос на возврат средств, интеллектуальный объект может попытаться самостоятельно «написать» SQL-запрос, например: UPDATE orders SET status = 'refunded' WHERE order_id = '...'. Этот процесс сопряжён с множеством рисков:

Риски безопасности: если интеллектуальный агент не проведёт тщательную очистку и проверку введённого пользователем order_id, это может привести к атаке типа «SQL-инъекция».

Логические ошибки: ИИ может забыть восстановить запасы после возврата или не записать его в журнал, что приведёт к несогласованности данных.

Чрезмерные полномочия: инструмент `execute_sql` обладает слишком широкими полномочиями — он не только может обновлять статус заказа, но и теоретически способен удалить всю базу данных. Если модель начнёт «галлюцинировать» или подвергнется злонамеренному манипулированию, последствия будут непредсказуемыми.

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

get_order_details(order_id: str) → Order: запрашивает детали заказа по ID заказа и возвращает структурированный объект заказа. Этот инструмент предназначен только для чтения и не имеет никаких прав на изменение.

check_refund_policy(order: Order, reason: str) → bool: проверяет, соответствует ли данный заказ правилам возврата. Например, не прошло ли с момента покупки более 30 дней и не относится ли товар к категории, не подлежащей возврату.

process_refund(order_id: str, amount: float, reason: str) -> bool: выполняет операцию возврата средств. Эта функция внутренне объединяет все необходимые шаги: обновление статуса заказа, пополнение запасов, запись в финансовый журнал, отправку уведомляющего письма. Внешне она предоставляет только необходимые параметры, а вся сложная внутренняя логика скрыта.

notify_customer(customer_id: str, message: str): отправка уведомления клиенту.

В данной архитектуре «пространство действий» интеллектуального модуля строго ограничено. Он не может произвольно выполнять операции с базой данных, а может только вызывать эти заранее определенные и безопасные инструменты в соответствии с планом, как при использовании строительных блоков. Его задача из «написания кода» превратилась в «заполнение пробелов»: в слоты параметров order_id, amount и reason инструмента process_refund необходимо ввести правильную информацию, полученную от вышестоящего инструмента. Таким образом, надёжность и безопасность всего процесса повышаются в геометрической прогрессии.

Эта концепция проектирования является продолжением идеи «API-First», которая в последние годы пользуется большой популярностью в области программной инженерии, в сфере интеллектуальных систем. Мы должны проектировать набор инструментов для интеллектуальных систем так же, как проектируем отличный набор средств разработки программного обеспечения (SDK). Каждый инструмент должен иметь чёткое название и описание, строго типизированные параметры, подробную документацию и примеры, а также чёткий механизм обработки ошибок.

Создание такого набора инструментов требует межфункционального сотрудничества внутри организации. Бизнес-эксперты должны определить «что делать» (например, бизнес-правила возврата средств), а технические специалисты — реализовать «как делать» (например, инкапсулировать правила в надежный API). Сам по себе этот процесс представляет собой преобразование неявных знаний организации в явные и структурированные, и его ценность выходит далеко за рамки простого обеспечения возможностей для интеллектуального агента на базе ИИ.

Когда интеллектуальная система обретает четкие цели, выполнимый план и управляемые инструменты, колесо действия уже может начать вращаться. Но для того, чтобы оно вращалось непрерывно, стабильно и все лучше, не хватает последнего, но крайне важного звена: обратной связи.

4. Обратная связь — это не «лайк», а поддающийся количественной оценке механизм исправления ошибок

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

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

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

Мгновенная обратная связь от выполнения инструментов. Это самая прямая и базовая обратная связь. Когда интеллектуальный агент вызывает инструмент, возвращаемое значение инструмента, статус успеха или неудачи, а также конкретная информация об ошибке являются ценными сигналами обратной связи. Например, когда инструмент scrape_post_list терпит неудачу из-за механизмов защиты целевого сайта от сканирования, он не должен возвращать простое значение False, а должен возвращать структурированное сообщение об ошибке, например: {status: 'failed', error_code: 'SCRAPE_BLOCKED', message: 'Access denied due to anti-scraping measures.'}.Получив эту обратную связь, «умный» модуль может обработать её в соответствии с заданной стратегией, например, переключиться на резервный узел сканирования или увеличить интервал между запросами, а не слепо повторять попытки.

Структурированная обратная связь от контрольных точек плана. В исполняемом плане каждая контрольная точка представляет собой возможность сбора обратной связи. Роль контрольной точки заключается в разбиении конечной цели задачи на ряд «ожидаемых значений» промежуточных состояний. Когда результат действия интеллектуального агента не соответствует ожидаемому значению, возникает четкий сигнал «отклонения». Например, план требует «отбор 10 статей с наибольшим количеством взаимодействий», но в результате фактического выполнения было найдено только 5 статей. Разница между «5» и «10» представляет собой количественную обратную связь. Она может побудить интеллектуальный агент к самоанализу: проблема в источниках данных или в том, что критерии отбора слишком строгие?

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

Только такая детализированная и привязанная к конкретным действиям обратная связь может по-настоящему сформировать мощный замкнутый цикл обучения. Она предоставляет чёткие и практические инструкции для тонкой настройки модели, итеративной доработки инструментов и оптимизации планов.

Измерение

Обратная связь «типа лайка»

Количественно измеримый механизм исправления ошибок

Информационная насыщенность

Низкий, двоичный сигнал (хорошо/плохо)

Высокая, включает тип ошибки, местоположение, правильное значение, рекомендации по улучшению

Адресат обратной связи

Конечный результат

Весь процесс выполнения (план, инструменты, промежуточные результаты)

Роль ИИ

Нечеткие сигналы усиления, низкая эффективность обучения

Точные сигналы контроля, которые можно использовать для эффективной настройки и оптимизации правил

Степень автоматизации

Сложность автоматизации, зависимость от большого объема ручной маркировки

Возможна частичная автоматизация (например, обратная связь от инструментов, обратная связь от контрольных точек)

Конечный результат

Улучшения происходят медленно, трудно решить коренные проблемы

Стимулирует быстрое и непрерывное совершенствование интеллектуальных систем, обеспечивая повышение надежности

Объединив эти четыре составляющие — цель, план, инструменты и обратную связь — мы получаем минимальный замкнутый цикл, обеспечивающий надежное действие интеллектуальной системы. Этот цикл функционирует следующим образом:

1. Начинается с цели (Goal): человек с помощью намерения определяет чёткую и измеримую бизнес-цель.

2. Разбивается на план (Plan): механизм планирования разбивает цель на ряд структурированных, выполнимых шагов, включающих контрольные точки.

3. Применение инструментов (Tool): на каждом этапе интеллектуальная система задействует один или несколько инструментов с чётко очерченными границами и надёжными функциями для взаимодействия с окружающим миром и изменения состояния окружающей среды.

4. Сбор обратной связи (Feedback): на каждом этапе выполнения система непрерывно собирает количественную обратную связь от инструментов, контрольных точек и человека.

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

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

Для таких компаний, как «Benwei Life», выход из ситуации, когда «много говорят, но мало делают», заключается не в замене модели на более «умную», а в систематическом построении замкнутого цикла действий. Им необходимо преобразовать расплывчатые ожидания в отношении «Insight No. 1» в чёткую цель; детализировать инструкцию «проанализировать динамику» до уровня выполнимого плана; сузить общие полномочия по «доступу к веб-сайтам» до набора надёжных инструментов для сбора данных; а также создать механизм, позволяющий директору по маркетингу Чэнь Си легко предоставлять точную обратную связь.

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

Глава 6.

От отдельного интеллектуального агента к команде агентов: источником ценности является сотрудничество

12 ноября 2025 года, в три часа ночи, сверхмощный тайфун «Посейдон» обрушился на один из ключевых портов Южной Азии. Для Ли Цзин, руководителя отдела цепочки поставок глобального гиганта потребительской электроники «Globlex», начался настоящий кошмар. Этот порт являлся центром распределения ключевых компонентов для их новейшего флагманского смартфона «Стардаст X», а до «золотого» периода подготовки к глобальному рождественскому сезону продаж оставалось всего три недели. Если перебои в грузоперевозках продлятся более 48 часов, по меньшей мере 30 % мирового рынка столкнется с дефицитом товаров, а убытки, по оценкам, достигнут 500 миллионов долларов США.