🫐 Cyberries

Эволюция AI-систем — проектирование адаптивных решений через призму EnMaTeS и фреймворка «3C»

время чтения ~9 мин.

Автор: Рустам Кунафин

Введение: от хаоса агентов к системной эволюции

В потоке противоречивых новостей об искусственном интеллекте предпринимателю легко потерять ориентиры. Заголовки пестрят противоречиями. Команда Cognition AI, создавшая нашумевшего AI-инженера Devin, публикует манифест: «Не создавайте мультиагентные системы». Их главный аргумент — такие системы хрупки и порождают хаос из-за невозможности поддерживать единый контекст. Практически одновременно Anthropic, один из ведущих AI-исследовательских центров, выпускает детальный технический отчет «Как мы создали нашу мультиагентную исследовательскую систему», где доказывает, что именно такой подход позволил им добиться прорыва в решении сложных задач.

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

В этой статье я покажу, как моя методология EnMaTeS служит «несущей конструкцией» для целостного взгляда на бизнес, а инструментальный фреймворк «3C», который я синтезировал из наблюдений за всей индустрией, становится той «живой тканью», которая позволяет проектировать по-настоящему адаптивные AI-решения.

Фундамент «3C»: мой интерфейс к мировым AI-трендам

Чтобы ориентироваться в сложном ландшафте, нам нужен надежный компас. Проанализировав множество подходов и идей, циркулирующих в отрасли (подробный разбор я представил здесь «Агентная революция 2025 — стратегический анализ архитектур и лидеров рынка»), я выделил три универсальных, взаимосвязанных принципа. Вместе они образуют фреймворк «3C», который позволяет перевести глобальный AI-дискурс на язык практических бизнес-решений. Приведенные ниже примеры — это не первопричины этих принципов, а их ярчайшие проявления в стратегиях лидеров рынка.

Принцип 1: Context (Контекст)

Этот принцип утверждает, что надежность и предсказуемость любой интеллектуальной системы напрямую зависят от целостности и доступности ее операционной информации. Ярким проявлением этого фундаментального принципа служит позиция Cognition AI, изложенная в их резонансной статье «Не создавайте мультиагентные системы» [1]. Они доказывают, что основная причина хрупкости сложных систем заключается во фрагментации контекста. Когда отдельные компоненты системы действуют на основе неполной или разной информации, их усилия не складываются в единое целое. Эта идея эволюционирует в дисциплину, которую можно назвать «инженерией контекста» (Context Engineering) — осознанное проектирование информационных потоков для обеспечения надежности.

Принцип 2: Concept (Концепция)

Этот принцип смещает фокус с технологии как таковой на ее стратегическое применение. Он гласит, что определяющим фактором ценности AI-решения является не мощность базовой большой языковой модели, а сам замысел его работы — архитектурный паттерн, который мы теперь называем «агентным рабочим процессом» (agentic workflow). Этот взгляд активно продвигает Эндрю Ын, призывая бизнес-лидеров сосредоточиться на проектировании ценных приложений, а не на гонке за новейшими LLM [2]. Агентский рабочий процесс, где система способна самостоятельно планировать, использовать инструменты и итерировать для достижения сложной цели, и есть та самая концепция, которая превращает технологию в бизнес-решение.

Принцип 3: Collaboration (Коллаборация)

Этот принцип рассматривает взаимодействие множества компонентов — будь то AI-агенты, люди или внешние инструменты — как мощный, но тактический выбор, а не как самоцель. Практическое воплощение этого принципа можно увидеть в работе Anthropic [3]. В своем отчете они показывают, что мультиагентная архитектура была выбрана ими как тактика для решения конкретной проблемы: сложного и «широкого» исследования. Однако для этапа синтеза («записи») они намеренно возвращаются к одному координирующему агенту. Это различие между задачами «чтения» (где коллаборация эффективна) и «записи» (где она может быть вредна) является ключевым инженерным компромиссом.

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

Несущая конструкция: EnMaTeS (AI Layer) как инженерная дисциплина

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

Важно понимать, что у EnMaTeS есть два уровня.

Глобальный уровень — это целостная архитектура для мышления о бизнесе как о едином организме: Entrepreneurial, Managerial, and Technological System (Предпринимательская, Управленческая и Технологическая Система).

Прикладной AI-слой — это набор конкретных фреймворков и практик для проектирования AI-решений, который работает поверх глобальной архитектуры. Ядром этого слоя является формальная дисциплина «Инженерии Управляемого Контекста» (Supervised Contextual Engineering).

Она переводит абстрактные идеи о «контексте» на язык конкретных инженерных артефактов:

  • Семантические Графы (SG): «Мозг» AI-агента, моделирующий бизнес-домен.
  • Системные Инструкции (SI): «Операционная система» агента, собранная из модульных компонентов (SMF, FPM, FPS, PIC), определяющая его поведение.
  • Пакеты Инициализации (IP): «Первоначальные знания» агента, включающие SG, исходные документы (SDA), стартовые промпты (SP) и руководства (UM).
  • Исходные Документы (SDA): «Библиотека» или «долговременная память» агента.

Эта инженерная дисциплина позволяет нам управлять поведением LLM на фундаментальном уровне.

Ядро подхода: системный синтез EnMaTeS и «3C»

Настоящая синергия возникает, когда мы используем «3C» как набор диагностических вопросов на каждом из трех уровней EnMaTeS.

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

  • (Context): В какой рыночной среде мы действуем?
  • (Concept): Какова стратегическая концепция нашего AI-решения?
  • (Collaboration): Какая модель взаимодействия с рынком закладывается в основу?

На управленческом уровне

  • (Context): Каков контекст наших операционных процессов и имеющихся данных в системах вроде Planfix, Fibery, Битрикс24 или условный Notion?
  • (Concept): Каков замысел AI-системы для оптимизации управления?
  • (Collaboration): Как эта система будет взаимодействовать с командой?

На технологическом уровне

  • (Context): Каков контекст нашего текущего технологического стека?
  • (Concept): Какова оптимальная техническая концепция AI?
  • (Collaboration): Как будет технически реализовано взаимодействие компонентов?

Практический пример: проектирование «AI-ассистента PjM»

Давайте пройдем по универсальному кейсу: проектирование AI-ассистента для управления сложными клиентскими проектами.

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

Идет набор в Киберлодку №1

Cоздание системы ИИ-агентов под свой бизнес-домен — это основная цель путешествия, на данный момент.

Участие бесплатное, как всегда всё в формате «open-source/mind».

Ссылка-приглашение в закрытую группу: https://t.me/+_J2jkUrhXHIyODYy — осталось 8 мест.

Этап I: Проектирование в режиме Dev

Прежде чем мы получим работающего ИИ-агента для менеджера проектов (PjM), нам нужно создать “мастерскую” для его производства и обслуживания. Этот процесс я веду в специальном Dev-чате.

  1. Инициализация среды разработки. Я запускаю ИИ-ассистента с полной Системной Инструкцией (SI) для разработчика (FPM-Dev). Его роль (FPS) — AgentDeveloper, а цель (PIC) — PIC_Dev_PjMCopilot.md, где четко сказано: “Мы создаем компоненты для AI-ассистента по управлению проектами”.

  2. Инженерия контекста. В диалоге с этим AI-Разработчиком мы инициируем создание или доработку Семантического Графа (SG). Этот процесс может начаться с готового шаблонного графа для данного домена, который AI-Разработчик затем итеративно наполняет и уточняет, анализируя предоставленные Исходные Данные (SDA) — наши лучшие шаблоны планов проектов, регламенты и т.д. Благодаря командам из FPM-Dev, AI может сам предлагать оптимальную структуру графа на основе анализа документов.

  3. Проектирование компонентов для Use-режима. Все еще находясь в Dev-чате, мы создаем артефакты для будущего “пользовательского” агента:

    • Роль (FPS): FPS_PjMCopilot.md — “Ты — AI-копилот для PM, твоя задача — проактивно выявлять риски в проектах”.
    • Цель (PIC): PIC_Use_PjMCopilot.md — “Используй SG_PjM.md и связанные SDA для анализа данных из Planfix API”.
    • Стартовый Промпт (SP) и Руководство (UM) для будущего пользователя.

Dev-чат с его историей и созданным SG остается нашей “мастерской”. Если понадобится обновить логику «AI-ассистента PjM», мы вернемся именно сюда.

Этап II: Сборка и работа агента в режиме Use

Теперь, когда все компоненты готовы, мы “собираем” нашего ИИ-агента для конечного пользователя — PjM.

  1. Сборка ИИ-агента. Создается ChatConfig_Use_PjMCopilot.md, который декларативно описывает, из чего собирается агент:
    • Системная Инструкция (SI): Объединяются FPM-Use, FPS_PjMCopilot и PIC_Use_PjMCopilot. Она определяет, как агент должен себя вести.
    • Пакет Инициализации (IP): Объединяются SG_PjM, связанные SDA, SP_Welcome и UM_UserGuide. Он определяет, что агент знает на старте.
  2. Архитектура и Реализация. На технологическом уровне мы выбираем гибридную архитектуру, реализованную, например, на базе Google Cloud Functions и Gemini API:
    • Агент-Оркестратор (главный агент) постоянно следит за SG.
    • Агент-Наблюдатель периодически “читает” данные из API Planfix/Fibery, обновляя статусы задач в SG.
    • Агент-Аналитик раз в час выполняет Сканирование Векторной Аффинности по графу для выявления рисков (например, “задача с высоким весом просрочена, и от нее зависит 5 других задач”).
    • При обнаружении риска Оркестратор выполняет Ноотропную Инфузию: извлекает детали из SDA (например, “согласно регламенту, этот тип риска требует немедленной эскалации”) и формирует полное, осмысленное уведомление для PjM через нативные возможности Planfix или с помощью интеграционной платформы вроде Latenode.
    • Для проверки гипотезы можно обойтись и одним (для каждого режима Dev/Use) ИИ-агентом.

AI-Creatures

Если углубляться, то в данном кейсе надо разработать не одного ИИ-агента, а нескольких, которые связаны общим бизнес -доменом, -процессом, -задачей, -ролью и работают на основе единого Семантического Графа и общей SDA. Подобные сущности я называю AI-Creatures. Поэтому по факту мы получим AI-Creature «AI-ассистента PjM» состоящий минимум из трех AI-Agents в режиме Use и как минимум одного AI-Agent в режиме Dev, если его будет достаточно для разработки и развития ИИ-агентов (в режиме Use) Оркестратор, Наблюдатель и Аналитик.

Таким образом, мы не просто создали агента, а развернули управляемую, предсказуемую и, что самое главное, эволюционирующую систему. Когда бизнес-процессы изменятся, мы вернемся в нашу Dev-мастерскую, обновим SG или FPS, и “пересоберем” «AI-ассистента PjM» до новой версии, сохранив преемственность и целостность.

Постскриптум: от автоматизации к кибербионике

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

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

Сам процесс вдумчивого проектирования AI-системы по методологии EnMaTeS заставляет нас наводить порядок в наших собственных бизнес-процессах. AI становится не просто продуктом хорошего системного мышления; он становится катализатором, который заставляет нас самих становиться лучшими системными архитекторами. Будущее за теми, кто не просто научится пользоваться готовыми AI-инструментами, а теми, кто научится проектировать уникальные интеллектуальные бизнес-системы. И предложенный здесь подход — неплохая отправная точка на этом пути.

Источники:

[1] Cognition AI. (12-06-2025). Don’t build multi-agent systems. Cognition. https://cognition.ai/blog/dont-build-multi-agents

[2] Ng, A. (25-03-2025). Why agentic AI is the smart bet for most enterprises. Insight Partners. https://www.insightpartners.com/ideas/andrew-ng-why-agentic-ai-is-the-smart-bet-for-most-enterprises/

[3] Anthropic. (13-06-2025). How we built our multi-agent research system. https://www.anthropic.com/engineering/built-multi-agent-research-system

Вид графа