Привет, Хабр! Я Игорь Морозов, архитектор в Platformeco. Мы более семи лет развиваем методологию композитных предприятий (Composable Enterprise), изначально разработанную с Google и Gartner, а также делаем продукты iPaaS, API-management и Workflow automation. На True Tech Arch #7, конференции для IT-архитекторов я рассказывал, как ИИ меняет интеграцию и автоматизацию. В этом материале по мотивам моего доклада я покажу, при каких обстоятельствах создание ИТ-продуктов уйдет доменным экспертам, появится возможность автоматизации недоступных ранее процессов и с какими вызовами это столкнется.

Немного теории

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

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

Первый — «M + C» (Microservices и Cloud-native). Несмотря на название, речь не про Kubernetes. Под «микросервисами» здесь понимается упакованная бизнес-капабилити — модуль, который может включать несколько сервисов, базу данных и обязательно контракты интеграции. То есть это часть enterprise-архитектуры, а не просто кусок кода. Cloud-native в их трактовке тоже шире — это не «все в контейнеры», а скорее «переиспользуй готовые SaaS-решения в облаке».

Второй блок «A + H» (API-first и Headless). Первое очевидно — всегда нужно начинать с продуманного API-контракта и делать API частью продукта. Headless объяснить чуть сложнее, есть несколько разных интерпретаций. Мне нравится здесь взгляд Карсона Гросса — разделение на human API и machine API. Для потребителей с агентностью должны быть иные интерфейсы, нежели для потребителей без. Кроме того, Headless является де-факто архитектурным стандратом для реализации омниканальности.

Composable Enterprise и MACH сильно перекликаются с другим подходом Gartner — pace-layered архитектурой. В ней все модули делятся на три уровня:

• Systems of record (медленные и стабильные) — стандартные и есть почти у каждой компании, например HR, WMS в ритейле и т. д. Они меняются редко, требуют стабильности и комплаенса.

• Systems of differentiation (гибкие) — те, что дают конкурентное преимущество. Они развиваются быстрее, но им все еще нужна стабильность и четкие процессы.

• Systems of innovation (быстрые и изменчивые) — это зона экспериментов, например, внедрение ИИ, BFF, клиентские приложения. Здесь можно позволить себе гибкость и риск.

К чему это приводит на практике? 

Если каждая система оформлена как бизнес-капабилити с Headless API-контрактами, мы можем собрать каталог сервисов. А дальше использовать его как конструктор Lego: комбинировать, получать новые капабилити, а затем заносить их обратно в каталог.

Отсюда вытекает идея демократизации технологий. В компании всегда есть технологические эксперты, хорошо понимающие инструменты, и доменные эксперты, которые знают бизнес. Но объединить их усилия не так просто. Демократизация как раз про то, чтобы дать доменным экспертам инструменты, позволяющие собирать решения самостоятельно, без постоянного участия разработчиков. 

Дополнительно можно вспомнить BPMN и похожие подходы: формально там тоже есть разделение труда, но в итоге BPMN-диаграммы все равно нужно реализовывать, так что они скорее служат языком общения, а не инструментом. Здесь же речь о более самостоятельных инструментах для бизнеса.

Давайте теперь рассмотрим какой-то практический пример.

Где и что автоматизируем? 

Возьмем вымышленный максимально утрированный в целях демонстрации пример. Представьте классическую японскую корпорацию с 25-летней историей — Pikachu Inc. С одной стороны, она опирается на традиции и стремится обеспечить клиентам максимально стабильный сервис. С другой — руководство понимает, что для дальнейшего роста необходимо меняться и улучшать внутренние процессы. Точкой приложения усилий выбрали обработку заказов.

Сейчас клиенты оформляют заказ на покемонов через электронную почту. Sales-менеджер практически круглосуточно мониторит ее, вычитывает письма, определяет, что именно хочет клиент и на каком языке написан текст. После этого он вручную заводит карточку в CRM, заполняет все поля и отправляет ответ с подтверждением.

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

Вариант 1. Классическая автоматизация на LCNC

Для начала посмотрим, как эту задачу можно решить привычными средствами:

1. Начнем с интеграции с почтой. Мы должны читать входящие письма и отправлять ответы клиенту. Технически это делается через SMTP, IMAP или REST API (например, у Gmail). Протоколы не самые удобные, местами раздражающие, но, по крайней мере, понятные и стабильные.

2. После подключаем мессенджер. В примере возьмем Telegram, но на деле это может быть любая система. Задача простая: уведомить sales-менеджера о том, что заказ оформлен, чтобы он был в курсе и мог при необходимости вмешаться.

3. И наконец, нам понадобится сама система, куда мы заносим заказы. Название здесь не принципиально: CRM, ERP или OMS. 

У нашей компании длинная история, поэтому в примере речь пойдет о какой-нибудь легаси-системе с серверным рендерингом или, того хуже, с толстым клиентом. Здесь мы, скорее всего, получим проблемы.

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

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

Мы рассчитываем, что письмо будет четко написано на английском языке: I want one Pikachu, но в реальности так не бывает. Текст будет с вариациями, опечатками и разными форматами. Классическая схема автоматизации начинает сыпаться.

Вариант 2. AI Workflow для того же процесса

Здесь фактически все сводится к замене одного «кубика». Контракт мы оставляем тем же: на вход поступает письмо, на выходе — заказ, но внутри этого блока теперь работает LLM. Мы пишем промпт: «Тебе приходит письмо от клиента. Определи, является ли оно заказом. Если да — извлеки наименование позиции».

В результате такой автоматизации письмо, отправленное на японском языке, корректно было занесено в CRM как заказ, а в Telegram пришло уведомление, что клиент заказал пять Pikachu.

Что из этого следует? 

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

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

Есть еще один важный момент. В этом примере мы получили доступ к понятию agency, и именно оно напрямую ведет нас к разговору об AI-агентах, поэтому останавливается на этом варианте.

Что такое AI-агент и как запустить цикл? 

Следующий шаг автоматизации после AI workflow — это ИИ-агенты. Чтобы объяснить, что именно стоит за этим термином, обратимся к понятию «субъектность» (agency). В философии оно означает способность действующего актора воспринимать среду, иметь цель и адаптироваться, чтобы ее достичь. В определении ИИ-исследователей эта идея сохраняется почти без изменений.

Итак, если мы посмотрим на простейшего агента (ReACT), то увидим примитивный цикл: модель ловит задачу, анализирует ее, принимает решение, выполняет действие во внешней системе, получает результат и снова оценивает ситуацию. Этот процесс повторяется до тех пор, пока цель не достигнута.

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

Интеграция агента 

Вернемся к теме демократизации технологий. Кажется, что это довольно простая задача, когда есть ИИ-агенты. Но на практике сложно представить интерфейс, который позволит экспертам создавать новые бизнес-процессы, при этом ничего технически не ломая.

Ключевая же проблема тут — в ограниченности инструментов. Если агенту заранее «зашить» фиксированный набор функций, он теряет главное свойство — адаптивность. Поэтому на первый план выходит интеграция и протокол MCP (Model Context Protocol) от Anthropic. Суть в том, что он позволяет динамически подключиться к серверу и от него получить список тулов, доступных для агента:

В итоге можно, например, авторизовать агента по токену и отдать ему только разрешенные инструменты. Или, наоборот, вернуть полный список тулов организации — хотя здесь сразу появляются риски безопасности и галлюцинаций. А можно подключить LLM, которая на лету будет определять, какие именно тулы нужны для выполнения задачи. Вариаций действительно много. 

Самая интересная идея, на мой взгляд, в том, что динамическая выдача тулов позволяет агенту автоматически получать список всех API. Так, MCP-сервер можно связать с API Management решением, выгрузить все API-спецификации и превратить каждую операцию в отдельный тул для агента.

В итоге получается следование принципам композитной архитектуры и API-first: достаточно одной строки кода, чтобы подключить агента к любой системе внутри организации. На практике мы указываем URL, создаем объект MCP-сервера и получаем готовую интеграцию.

Оптимизация LLM

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

Важно понять, что: 

• LLM, которую мы сейчас все привыкли видеть, это не «чистая» модель, это набор весов с архитектурой слоев. Провайдеры типа OpenAI или Anthropic предоставляют нам комплексную систему: модель в ядре, API для вызова инструментов, преднастроенные методы сэмплинга, оптимизации и т. д. 

• Саму «сердцевину» модели мы почти не контролируем. Можно сделать fine-tuning или слегка изменить параметры вроде температуры, но радикально влиять на поведение облачных провайдеров LLM невозможно.

Зато мы можем сколько угодно играться с промптами, и здесь как раз-таки получается выстраивать когнитивные архитектуры. Это сложные цепочки, где мы получаем промт, передаем его в LLM, получаем результат, потом еще раз перестраиваем промт и снова отправляем модели. К таким архитектурам относятся few-shot (в промпт включаются примеры) и RAG (модель извлекает информацию из внешних источников).

В этом контексте стоит упомянуть несколько фреймворков. Самый известный и популярный сегодня — DSPy. Он появился первым и до сих пор активно развивается. Работает он просто: агент получает задачу, а оптимизатор переписывает запрос, добавляет few-shot примеры, делает fine-tuning или формулирует промпт заново через LLM.

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

Второй — OptoTrace, формально проект Microsoft, но разработан он также выходцем из Стэнфорда. По сути, это развитие тех же идей, но с упором на генерацию кода и оптимизацию рабочих процессов.

И третий тоже стэнфордский фреймворк — TextGrad. Его идея навеяна классическим ML-подходом: обратным распространением ошибки и стохастическим градиентным спуском. Но ее можно использовать только с числами, то есть мы вычисляем производные для каждого узла, получаем градиент и применяем его для оптимизации весов модели.

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

В результате агент перестает быть «черным ящиком», который действует непредсказуемо. Мы можем построить архитектуру, где часть шагов выполняется детерминированно. Например, планировщик генерирует код на Python, который затем выполняется как обычный поток работ. Так, с одной стороны, задача описывается текстом (демократизация), с другой — выполняется предсказуемо.

PLANNER_SYSTEM_PROMPT = '''
You are a smart language model that evaluates code snippets
that written to automate business processes described "task" using
functions provided in "environment".
You do not solve problems or propose new code snippets,
only evaluate existing solutions critically
and give very concise feedback. Pay special attention to provided
"hints" that can contain existing "code" execution exception
or feedback provided by a human.
'''
PLANNER_SYSTEM_PROMPT = tg.Variable(PLANNER_SYSTEM_PROMPT,
  requires_grad=False,
  role_description='System prompt for workflow planner',
)

PLANNER_INSTRUCT_TEMPLATE = '''
Think about the automation task described below.
Then review the Code snippet that implements the `workflow`
function that should implement the described task
potentially using functions from the Environment.
Implementation should assume that
global exception handling implemented by workflow function caller
(e.g. workflow function should omit exception handling).
Implementation should also assume that configuration, logging, tracing,
metrics, scaling, circuit breakers and retries etc
also already implemented by the host (the caller) or Environment functions
implementation and must not re-implement them.

Does the code solve the described task?
Does it follow all instructions carefully?
Does it use only Python 3 standard library and functions described in Environment?
Is the order of steps correct?
Does it use the best possible function from `env` for every step?
Are there any syntax errors or wrong parameters usage?

### Task

{task}

### Code

```py
{code}
```

### Environment

```py
{environment}
```

### Hints

{hints}
'''


review_process_plan_code = FormattedLLMCall(
  engine=backward_engine,
  format_string=PLANNER_INSTRUCT_TEMPLATE,
  fields={"code": (), "task": (), "environment": (), "hints": ()},
  system_prompt=PLANNER_SYSTEM_PROMPT,
)


def loss_fn(
  task: tg.Variable,
  code: tg.Variable,
  environment: tg.Variable,
  hints = tg.Variable('-', requires_grad=False, role_description='No hints provided'),
) -> tg.Variable:
  return review_process_plan_code(
    inputs={"code": code, "task": task, "environment": environment, "hints": hints},
    response_role_description="Evaluation of code that solves the described automation task",
  )

class Environment:
  '''Environment namespace describes helper functions (tools) and classes
  available for use in the task solution.'''
  pass

TASK = '''Read emails in small batches and process them until no unread emails left (at most 5 iterations).
Processing an email means the following: first, detect if the email contains
a products order (it contains order if user explicitly mentions intent of ordering
one or multiple of the following products: Pikachu, Slowpoke in any natural language).
If email doesn\'t contains an order then ignore it.
If it contains order then extract customer name and email from sender,
then detect what products in what quantities are requested.
Use LLM to detect if email body contains order and to detect products with their quantities,
do not check email body for words directly because email contents can be written in any natural language.
Then create order in CRM system providing all required details, then notify sales manager
with message "New order has been created:\nid: `id`\nitems: `items`" (`id` is order id,
`items` is comma-separated list of order items with their quantities), then
reply to the order email with confirmation letter with topic "Confirmation"
and text "Your order was accepted, thank you for trusting us!", and finally mark
this email as read.'''
TASK = tg.Variable(TASK,
  requires_grad=False,
  role_description='''Contains original task that must be solved in coded workflow
    potentially using functions provided by Environment''',
)

ENVIRONMENT = tg.Variable(create_abstract_class_contract(Environment),
  requires_grad=False,
  role_description='''Contains abstract declarations (contracts) of functions
    that the workflow can use as auxiliary tools in task implementation.''',
)

CODE = '''
def workflow(env: Environment = Environment()):
  """Workflow implement automation described by the task."""
  pass
'''
CODE = tg.Variable(CODE,
  predecessors=[TASK, ENVIRONMENT],
  role_description='Code that implements some automation described by automation task',
)

HINTS = tg.Variable('-', requires_grad=False, role_description='Hints on how to fix code')

def execute():
  imports = dedent('''
  from typing import Sequence
  from abc import ABC, abstractmethod
  ''')

  interpreter = InteractiveShell.instance()
  interpreter.run_cell(imports)
  interpreter.user_ns['Environment'] = Environment


  try:
    interpreter.run_cell(CODE.value, store_history=False)
    workflow = interpreter.user_ns['workflow']
    workflow(Environment())
  except Exception as e:
    HINTS.value = ''.join(traceback.TracebackException.from_exception(e).format())

optimizer.zero_grad()
HINTS.value = '-'
execute() # try to execute generated code and update HINTS automatically
if HINTS.value =='' or HINTS.value == '-':
  # if code is correct then provide human feedback
  HINTS.value = input('Provide human feedback on code: ')
loss = loss_fn(TASK, CODE, ENVIRONMENT, HINTS)
loss.backward()
optimizer.step()

В ранее упомянутом Microsoft Trace идея очень схожа. Там узлы графа реализованы как питоновские функции. Агент запускает оптимизатор, который прямо во время работы переписывает код внутри себя. Класс можно сохранить (в pickle), позже загрузить, снова дообучить на свежем фидбэке и снова сохранить. Получается цикл бесконечной адаптации.

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

Итог — самооптимизирующиеся ИИ-агенты

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

Попробуем систематизировать где в разработке автоматизации может быть место LLM. У нас есть тот, кто автоматизацию разрабатывает (например, программист), тот кто в логике автоматизации принимает решения об ее исполнении (часто это делает опять же программист на этапе написания кода), тот, кто получившийся код ревьювит, и тот, кто его улучшает на базе ревью.

В этом и кроется концепция самооптимизирующегося агента. Не просто система, которая выполняет инструкции, а та, что корректирует себя в процессе работы.

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

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

Подводя итоги

Если собрать все сказанное воедино, то выводы будут такими:

• Следование модульной композитной архитектуре действительно позволяет быстро внедрять новые процессы. Достаточно заменить один «кубик» или добавить строку с MCP-коннектором, чтобы получить интеграцию со всеми системами.

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

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

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

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