Архитектура программного обеспечения: Agent-Friendly Architecture

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

Встатье рассмотрены применение старых и новых вдов архитектур для использования с ИИ агентами

Применение старых архитектур для использования с ИИ агентами

Для разработки с участием ИИ-агентов появляются не столько полностью новые “классические архитектуры”, сколько архитектурные стили и практики, которые делают проект понятным, изменяемым и безопасным для агента.

Главная идея: ИИ-агенту нужна архитектура с явными границами, маленькими модулями, хорошими контрактами и быстрыми тестами.

Применение новых видов архитектур для использования с ИИ агентами

Лучшие архитектуры именно для AI-assisted development

три наиболее удобных варианта.

1. Модульный монолит + Clean/Hexagonal в контексте ИИ агентов

Это, пожалуй, самый практичный вариант.

app/
  modules/
    orders/
      domain/
      application/
      infrastructure/
      api/
    payments/
      domain/
      application/
      infrastructure/
      api/
    users/
      domain/
      application/
      infrastructure/
      api/

Почему хорошо для ИИ:

Задача: "добавь отмену заказа"

Агент понимает:
- идти в modules/orders
- бизнес-правила искать в domain
- сценарий отмены писать в application
- endpoint добавить в api
- работу с БД положить в infrastructure

Это снижает шанс, что агент начнет менять все подряд.

То есть бизнес-логика не зависит напрямую от базы данных, API, очередей или LLM. Она общается с ними через интерфейсы — порты и адаптеры.

Пример:

OrderService
 ├─ использует PaymentPort
 ├─ использует NotificationPort
 └─ не знает, Stripe там, PayPal или mock

Для ИИ-агента это важно, потому что он может:

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

Таком образом:: модульный монолит дает агенту понятные границы, а Clean/Hexagonal дает безопасные точки изменения.

2. Vertical Slice Architecture в контексте ИИ агентов

Очень удобна для фичевой разработки с агентами.

features/
  orders/
    create-order/
      command.ts
      handler.ts
      validator.ts
      tests.ts
    cancel-order/
      command.ts
      handler.ts
      validator.ts
      tests.ts
  payments/
    pay-invoice/
      command.ts
      handler.ts
      tests.ts

Главная особенность: код лежит по пользовательским сценариям, а не только по техническим слоям.

Это удобно для промптов типа:

Добавь фичу "cancel order"

Агенту проще создать новую папку фичи и не трогать лишнее.

Недостаток: общую бизнес-модель все равно нужно держать аккуратно, иначе будет дублирование правил.

Главная идея:

одна бизнес-возможность = один вертикальный срез кода.

Это помогает агентам:

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

Таком образом:: Vertical Slice Architecture делает кодовую базу похожей на набор понятных задач, а не на лабиринт слоев.

3. Plugin / Extension Architecture в контексте ИИ агентов

Хорошо подходит, когда ИИ-агент должен часто добавлять новые возможности.

core/
  plugin-api.ts
  plugin-loader.ts

plugins/
  export-to-pdf/
  telegram-notifications/
  stripe-payments/
  ai-summary/

Почему удобно:

Новая возможность = новый плагин
Меньше риска сломать ядро системы

Это особенно полезно для IDE, CMS, внутренних платформ, automation-систем, SaaS с расширениями.

В контексте ИИ-агентов это особенно удобно: агент может не переписывать всю систему, а подключать новую функцию как отдельный модуль.

Что делает архитектуру “дружественной к ИИ-агентам”

Плохие варианты архитектур для ИИ-агентов

Практическая рекомендация

Для большинства проектов, которые будут активно разрабатываться с ИИ-агентами, я бы выбрал:

Модульный монолит
+ Vertical Slice для фич
+ Hexagonal/Clean внутри сложных модулей
+ DDD для сложной бизнес-логики
+ строгая типизация
+ тесты рядом с кодом

Пример:

src/
  modules/
    orders/
      domain/
        order.entity.ts
        order-status.ts
        order-policy.ts

      features/
        create-order/
          create-order.command.ts
          create-order.handler.ts
          create-order.test.ts

        cancel-order/
          cancel-order.command.ts
          cancel-order.handler.ts
          cancel-order.test.ts

      ports/
        order-repository.ts
        payment-gateway.ts

      adapters/
        postgres-order-repository.ts
        stripe-payment-gateway.ts

      api/
        order.controller.ts

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

agent-friendly architecture / AI-Native Development Architecture

То есть архитектура, специально оптимизированная не только под людей, но и под ИИ-агентов, которые читают код, планируют изменения, запускают тесты, рефакторят и создают pull request’ы.

Важно: это пока не каноническая архитектура с единым названием, а формирующийся стиль. Свежие материалы OpenAI, Martin Fowler и статьи 2025–2026 годов больше говорят о переходе к AI-native engineering, agentic workflows и необходимости архитектуры, где человек больше занимается дизайном и контролем, а агент — реализацией.

Чем она отличается от обычной архитектуры

Обычная архитектура оптимизировалась под:

Главная идея:

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

Agent-Friendly Architecture — это способ проектировать продукт, кодовую базу или систему так, чтобы с ней было удобно работать AI-агентам.

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

Обычно это значит:

• Понятная структура проекта: где лежит логика, тесты, конфиги, документация.
• Хорошая документация для агента: например README, AGENTS.md, инструкции по запуску и стилю кода.
• Автоматические проверки: тесты, линтеры, CI, чтобы агент мог сам проверить изменения.
• Маленькие независимые модули: агенту проще менять одну часть, не ломая все.
• Явные контракты: API, типы, схемы данных, примеры входов и выходов.
• Безопасные операции: staging-среда, dry-run, ограничения на доступ к секретам и продакшену.

Как могла бы выглядеть новая архитектура

Условно ее можно назвать:

Agent-Oriented Modular Architecture

Или короче:

AOMA — Agent-Oriented Modular Architecture

Это не официальный стандарт, а хорошее рабочее название.

Ее суть:

Система делится не только на модули, а на agent-friendly workspaces:

• - каждый модуль имеет явный контракт
• - каждая фича имеет локальный контекст
• - рядом лежат тесты
• - есть README для агента
• - есть machine-readable спецификации
• - архитектурные правила проверяются автоматически

Пример структуры:

src/
  modules/
    orders/
      AGENT.md
      README.md
      module.contract.yaml

      domain/
        order.ts
        order-policy.ts

      features/
        create-order/
          task.md
          create-order.handler.ts
          create-order.test.ts

        cancel-order/
          task.md
          cancel-order.handler.ts
          cancel-order.test.ts

      ports/
        order-repository.ts
        payment-gateway.ts

      adapters/
        postgres-order-repository.ts
        stripe-payment-gateway.ts

      architecture.rules.ts

Главная новая особенность

Не просто “чистые слои”, а кодовая база как навигационная среда для агента.

То есть архитектура отвечает не только на вопрос:

Как системе работать?

но и на вопрос:

Как ИИ-агенту безопасно менять эту систему?

Основные принципы такой архитектуры

Чем это отличается от Clean Architecture

Чем отличается от микросервисов

Микросервисы дают независимый deploy, но не всегда удобны для ИИ-агента: агенту сложнее учитывать сеть, API-версии, distributed transactions, observability и асинхронные эффекты.

В 2026 уже появляются обсуждения и даже бенчмарки, сравнивающие, в каких архитектурах агентам легче работать. Например, материалы о ModulithBench утверждают, что модульный монолит может быть удобнее для reasoning агентов, чем микросервисы, из-за локальности и меньшей распределенной сложности. Это не окончательный научный консенсус, но направление показательное.

Практический вариант “новой” архитектуры

Для реального проекта я бы выбрал такую формулу:

Agent-Oriented Modular Architecture =
  Modular Monolith
  + Vertical Slice Architecture
  + Hexagonal boundaries
  + DDD для сложных доменов
  + AGENT.md в каждом модуле
  + architecture tests
  + typed contracts
  + локальные тесты на каждую фичу

Пример AGENT.md

# Orders Module — Agent Guide

Purpose:
This module manages order lifecycle.

Allowed changes:
- Add new order features inside features/
- Put business rules in domain/
- Use ports/ for external dependencies

Do not:
- Call payment provider directly from domain/
- Import infrastructure from domain/
- Modify payments module without updating contract tests

Common tasks:
- New order action → create folder in features/
- New persistence logic → update adapter + repository port
- New business rule → update order-policy.ts and tests

Это очень полезно: агент не просто “угадывает”, куда писать код, а получает локальную инструкцию.

Итог

Абсолютно новой, официально признанной архитектуры пока нет. Но реально формируется новый стиль:

Agent-Friendly / AI-Native / Agent-Oriented Architecture

Его главная особенность:

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

На практике лучшая база для этого сейчас — модульный монолит + vertical slices + typed contracts + локальная документация для агентов.