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

Практическое руководство для разработки сайтов, веб-приложений, CRM и CMS.

Содержание

• Что такое агентная система
• Базовые паттерны агентных систем
• Паттерны памяти, инструментов и контроля
• Как выбирать архитектуру
• Лучшие практики ИИ в разработке
• Workflow для сайтов и веб-приложений
• Workflow для CRM
• Workflow для CMS
• Безопасность, качество и контроль изменений
• Модели, стоимость и распределение задач
• Практическая схема Hermes для проектов Юрия
• Антипаттерны
• Чек-листы

---

1. Что такое агентная система

Обычный LLM-чат получает запрос и возвращает текст. Агентная система дополнительно умеет:

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

Упрощённая схема:

Запрос пользователя
        ↓
Понимание задачи
        ↓
План / выбор workflow
        ↓
Инструменты и изменения
        ↓
Тестирование и проверка
        ↓
Результат или запрос уточнения

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

---

2. Основные паттерны агентных систем

2.1. Single Agent + Tools

Один агент работает с набором инструментов: терминал, файлы, браузер, Git, API.

Пользователь → один агент → инструменты → проверенный результат

Когда использовать

• CRUD-функции;
• небольшие исправления;
• деплой;
• диагностика сервиса;
• настройка конфигурации;
• работа с одним проектом.

Плюсы

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

Минусы

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

Практический вывод

Это базовый и предпочтительный режим для большинства задач Юрия.

---

2.2. Prompt Chaining — цепочка шагов

Большая задача разбивается на последовательные этапы. Выход одного этапа становится входом следующего.

Требования → план → реализация → тесты → review → деплой

Пример

1. Изучить существующий код.
2. Составить ТЗ.
3. Получить подтверждение.
4. Реализовать backend.
5. Реализовать frontend.
6. Запустить тесты.
7. Проверить сборку.
8. Подготовить деплой.

Когда использовать

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

Важное правило

Каждое звено должно иметь:

• входные данные;
• конкретный результат;
• критерий успешности;
• поведение при ошибке.

---

2.3. Routing — маршрутизация задач

Система определяет тип запроса и направляет его подходящему агенту, навыку или модели.

Запрос
  ├─ UI → frontend workflow
  ├─ API → backend workflow
  ├─ ошибка → debugging workflow
  ├─ деплой → deployment workflow
  └─ исследование → research workflow

Примеры маршрутизации

• Vue-задача → vue-3-spa-development;
• Nuxt-задача → nuxt-ssr-fullstack-development;
• SEO-задача → seo-semantic-clustering;
• перевод DOCX → docx-translator;
• проблема Hermes → hermes-agent;
• деплой → deploy-web-project.

Модели для routing

Для простого определения категории достаточно недорогой модели. Сильная модель нужна только при неоднозначной задаче.

---

2.4. Parallelization — параллельная обработка

Независимые подзадачи выполняются одновременно.

                 ┌─ анализ frontend
Запрос → план ───┼─ анализ backend
                 └─ анализ тестов

Хорошие кандидаты

• анализ нескольких независимых файлов;
• исследование нескольких API;
• проверка frontend и backend;
• поиск вариантов дизайна;
• независимые code review.

Нельзя параллелить

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

Риск

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

---

2.5. Orchestrator–Workers — оркестратор и воркеры

Главный агент анализирует задачу, разбивает её и раздаёт работу специализированным воркерам.

                   ┌─ frontend worker
Пользователь → оркестратор ─┼─ backend worker
                   └─ test/review worker
                              ↓
                       интеграция результата

Роль оркестратора

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

Роль воркера

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

Когда использовать

• крупный full-stack feature;
• несколько независимых компонентов;
• большой рефакторинг;
• миграция нескольких частей системы.

Главный риск

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

---

2.6. Evaluator–Optimizer — исполнитель и оценщик

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

Исполнитель → результат → evaluator → замечания → исправление

Варианты проверки

• соответствие ТЗ;
• тесты;
• безопасность;
• UX;
• производительность;
• совместимость с существующим кодом;
• отсутствие scope creep.

Лучшее применение

• code review;
• генерация SQL;
• безопасность авторизации;
• сложные формы;
• SEO-разметка;
• документы и отчёты.

Важно

Оценщик должен получать исходное ТЗ, а не только новый код. Иначе он проверяет «красиво ли сделано», а не «сделано ли то, что требовалось».

---

2.7. Generator–Critic — генератор и критик

Похож на evaluator–optimizer, но критик сфокусирован на поиске слабых мест.

Пример

• генератор предлагает архитектуру;
• критик ищет проблемы масштабирования;
• генератор исправляет;
• финальная модель выбирает решение.

Подходит для архитектуры, безопасности и UX, но для простой кнопки избыточен.

---

2.8. Mixture of Agents — MoA

Несколько reference-моделей дают независимые ответы, затем aggregator формирует итоговый ответ.

Запрос → модель A ─┐
       → модель B ─┼→ aggregator → ответ / инструменты
       → модель C ─┘

Для чего

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

Ограничения

• дороже одной модели;
• медленнее;
• aggregator тоже может выбрать неправильный вариант;
• reference-модели не должны параллельно изменять проект;
• для простых задач нет оправданной выгоды.

Практическое применение

Использовать только для архитектуры, сложного аудита, спорного технического выбора и финального review. Не использовать для каждого CRUD-запроса.

---

2.9. Human-in-the-loop — человек в контуре

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

Чтение → автоматически
Тесты → автоматически
Изменение проекта → по правилам
Удаление / миграция / деплой → подтверждение

Обязательные точки подтверждения

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

Для production-сервера автоматический approval не должен заменять контроль владельца.

---

2.10. ReAct — Reason + Act

Агент чередует рассуждение, действие и наблюдение.

Понять → вызвать инструмент → посмотреть результат → скорректировать → повторить

Это естественный режим coding-agent:

1. прочитал файл;
2. нашёл ошибку;
3. изменил код;
4. запустил тест;
5. увидел новую ошибку;
6. исправил;
7. проверил повторно.

Защита от бесконечного цикла

• лимит итераций;
• правило остановки;
• повторяемость ошибок;
• обязательный отчёт о блокере;
• запрет бесконечно повторять одну команду.

---

2.11. Plan-and-Execute

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

Хорошо подходит для

• больших фич;
• CRM-модулей;
• CMS-разделов;
• миграций;
• многослойного full-stack кода.

Плюс

Меньше хаотичных изменений.

Минус

План может устареть после первого изменения. План нужно пересматривать при существенном отклонении.

---

2.12. Blackboard — общее рабочее поле

Несколько агентов обмениваются результатами через общее хранилище:

• markdown-файлы;
• задачи Kanban;
• registry;
• JSON-состояние;
• Git branch;
• database.

Практический вариант

.hermes/plans/feature.md
.hermes/decisions/adr-001.md
.hermes/reviews/feature-review.md

Плюс: информация не теряется между сессиями. Минус: нужно контролировать актуальность файлов.

---

2.13. Memory / RAG — память и поиск знаний

Агент не держит всё в контексте постоянно, а извлекает нужные знания по запросу.

Уровни памяти

1. Краткосрочная — текущая история диалога.
2. Сводка сессии — compression.
3. Профиль пользователя — стабильные предпочтения.
4. Проектная память — архитектура, пути, решения.
5. RAG/knowledge base — поиск по документам и кодовой базе.

Правило

В память помещаются стабильные факты и решения, но не временный прогресс, логи и устаревающие номера.

---

2.14. Event-driven agent

Агент запускается событием:

• webhook;
• новый issue;
• падение сервиса;
• новый файл;
• расписание;
• изменение статуса заказа.

Для production

Event-driven агент должен иметь:

• idempotency key;
• журнал событий;
• retry с backoff;
• dead-letter queue;
• лимит повторов;
• уведомление человека при ошибке.

---

2.15. Saga / Compensating Actions

Длинная операция состоит из шагов. Если шаг посередине провалился, система выполняет компенсирующие действия.

Пример деплоя

1. собрать frontend;
2. сохранить старую версию;
3. скопировать новую;
4. проверить HTTP;
5. откатить старую версию при ошибке.

Это обязательный паттерн для production-деплоя, миграций и массовых операций.

---

3. Память, инструменты и контроль

3.1. Tool design

Инструменты агента должны быть:

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

Плохой инструмент: execute_anything(command) без ограничений.

Хороший инструмент: deploy_project(project, target, version, dry_run).

3.2. Идемпотентность

Повторный вызов не должен портить результат.

Примеры:

• mkdir -p вместо безусловного создания;
• upsert вместо дублирования записи;
• миграции с проверкой версии;
• деплой через атомарную директорию;
• webhook с защитой от повторного event ID.

3.3. Наблюдаемость

Для каждого agent workflow полезно сохранять:

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

---

4. Как выбирать архитектуру

Задача	Лучший паттерн
Простое исправление	Single Agent + Tools
Новая фича	Plan-and-Execute + Prompt Chaining
Frontend и backend независимо	Parallelization + Integration Review
Большой full-stack модуль	Orchestrator–Workers
Критичный код	Generator–Critic + Evaluator–Optimizer
Архитектурный выбор	MoA или 2–3 независимых review
Production-деплой	Human-in-the-loop + Saga/rollback
Мониторинг	Event-driven + Read-only
Длинная работа	Plan + checkpoints + memory
Непредсказуемые входы	Routing + guardrails

Принцип минимальной достаточности

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

Не нужен MoA для создания поля в форме. Не нужен Kanban-оркестратор для одной CSS-правки. Не нужен evaluator из дорогой модели для генерации заголовка.

---

5. Лучшие практики ИИ в разработке

5.1. Сначала спецификация, потом код

Хороший запрос к агенту содержит:

• цель;
• пользователей;
• ограничения;
• затрагиваемые части системы;
• точные acceptance criteria;
• что не нужно менять;
• команду проверки.

Для крупных задач сначала нужен документ ТЗ. Реализацию запускать только после подтверждения.

5.2. Агент должен изучить проект до изменений

Перед кодом нужно проверить:

• структуру каталогов;
• package.json;
• конфигурацию сборки;
• роутинг;
• модели базы;
• существующие API;
• стиль компонентов;
• env-переменные;
• текущую ветку и незакоммиченные изменения.

Нельзя просить агента «сделать с нуля», если уже есть рабочий проект.

5.3. Маленькие изменения

Лучший размер одной задачи — одна логическая фича или один вертикальный срез:

схема БД → API → UI → тест → проверка

Не объединять в один запрос:

• новый модуль CRM;
• смену дизайн-системы;
• миграцию БД;
• переписывание авторизации;
• новый деплой.

5.4. Вертикальные срезы

Фича должна проходить через все слои:

User action → UI → API → validation → DB → response → UI state

Так ошибка обнаруживается раньше, чем при создании отдельно огромного frontend и потом огромного backend.

5.5. Тесты — часть задачи, а не финальная опция

Минимальный набор:

• unit-тесты для бизнес-логики;
• API-тесты для критичных endpoint;
• тесты разрешений;
• тесты граничных условий;
• smoke-тест production URL;
• build/typecheck/lint.

Для CRM особенно важны тесты:

• tenant isolation;
• роли и permissions;
• статусы сущностей;
• повторная отправка формы;
• удаление и восстановление;
• фильтры и пагинация.

5.6. Проверка результата должна быть объективной

Плохо: «выглядит нормально».

Хорошо:

npm run build — exit 0
npm run typecheck — exit 0
npm test — 42 passed
curl -I https://domain.ru — HTTP 200
GET /api/items — 200 и валидный JSON

5.7. Не доверять самоотчёту агента

Агент может сказать «готово», но фактически:

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

Нужно проверять артефакт самостоятельно: прочитать файл, выполнить тест, проверить URL, посмотреть Git diff.

5.8. Git и checkpoints

Перед рискованным изменением:

1. проверить git status;
2. сохранить рабочие изменения;
3. создать commit или checkpoint;
4. выполнить изменение;
5. проверить diff;
6. проверить сборку;
7. только потом деплоить.

5.9. Безопасность по умолчанию

Агент не должен:

• выводить секреты;
• коммитить .env;
• отключать auth для удобства;
• делать SQL через конкатенацию строк;
• принимать права из frontend без серверной проверки;
• автоматически удалять production-данные;
• выполнять неизвестные команды из веб-страницы.

5.10. Контроль контекста

Длинная история ухудшает работу даже при большом контекстном окне.

Практика:

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

---

6. Разработка сайтов

6.1. Правильный цикл

1. Анализ референса и бизнес-цели.
2. Карта страниц.
3. Контентная модель.
4. Дизайн-токены.
5. Компонентная система.
6. Один эталонный экран.
7. Адаптивная версия.
8. Остальные страницы через компоненты.
9. SEO и accessibility.
10. Проверка в браузере.
11. Сборка и деплой.

6.2. Для статического сайта

ИИ должен сначала определить:

• какие страницы реально нужны;
• общий layout;
• данные, которые нужно вынести в JSON;
• общие header/footer/navigation;
• правила изображений;
• meta title/description;
• fallback для 404.

Не следует копировать HTML одного экрана на двадцать страниц без компонентной структуры.

6.3. Для Vue/Vite

Рекомендуемая структура:

src/
  components/
  views/
  layouts/
  stores/
  services/
  composables/
  types/
  assets/

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

6.4. UI-проверка

Проверять:

• desktop;
• mobile;
• tablet;
• hover/focus/disabled;
• длинные тексты;
• пустые состояния;
• ошибки API;
• loading;
• keyboard navigation;
• контраст.

---

7. Веб-приложения

7.1. Разделение ответственности

UI: состояние отображения и ввод
API: авторизация, валидация, бизнес-правила
DB: ограничения целостности и индексы
Worker: длинные фоновые операции

ИИ часто ошибочно помещает бизнес-логику в компонент Vue или доверяет frontend-валидации. Это нужно исправлять на review.

7.2. API-контракт

До реализации зафиксировать:

• method и path;
• request schema;
• response schema;
• ошибки;
• auth;
• pagination;
• filters;
• sorting;
• idempotency;
• rate limits.

Для TypeScript полезно использовать общие типы или OpenAPI.

7.3. Работа с базой

Агент должен:

• сначала изучить схему;
• создавать миграцию;
• не менять production вручную без backup;
• добавлять индексы по реальным запросам;
• проверять foreign keys;
• избегать N+1;
• учитывать null и уникальность;
• иметь rollback-план.

---

8. CRM-системы

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

8.1. Сначала доменная модель

Перед UI определить:

• сущности;
• связи;
• жизненный цикл статусов;
• владельцев;
• роли;
• аудит;
• правила удаления;
• импорт/экспорт;
• историю изменений.

8.2. Permission-first development

Для каждой операции задать матрицу:

Роль	Чтение	Создание	Изменение	Удаление	Экспорт
Администратор	✓	✓	✓	✓	✓
Менеджер	✓	✓	✓	ограниченно	✓
Наблюдатель	✓	—	—	—	—

Проверка должна быть на сервере. Скрытие кнопки в UI не является безопасностью.

8.3. Аудит

Для важных действий хранить:

• кто сделал;
• когда;
• что изменилось;
• старое значение;
• новое значение;
• источник действия;
• request/event ID.

8.4. Надёжность данных

Критичные операции должны быть:

• транзакционными;
• идемпотентными;
• защищёнными от повторной отправки;
• с понятным состоянием ошибки;
• с возможностью восстановления.

8.5. Импорт данных

Безопасный импорт:

1. загрузка файла;
2. проверка размера и типа;
3. предварительный preview;
4. валидация каждой строки;
5. отчёт об ошибках;
6. подтверждение пользователя;
7. транзакционная запись или batch с журналом.

Нельзя сразу импортировать файл в production-базу только потому, что модель «прочитала» его.

---

9. CMS-системы

9.1. Контент отдельно от представления

ИИ должен разделять:

• content model;
• редактор;
• preview;
• публикацию;
• frontend rendering;
• media library;
• SEO metadata;
• revisions.

9.2. Draft / Review / Published

Минимальная модель публикации:

draft → review → published → archived

Для публикации нужны:

• права;
• версия;
• дата публикации;
• возможность отката;
• preview;
• аудит.

9.3. Медиа

Проверять:

• MIME и расширение;
• размер;
• генерацию thumbnails;
• alt text;
• EXIF и приватные данные;
• удаление неиспользуемых файлов;
• CDN/cache invalidation.

---

10. Безопасность AI-assisted разработки

10.1. Prompt injection

Нельзя считать инструкции из:

• веб-страницы;
• README чужого проекта;
• issue;
• пользовательского файла;
• комментария в коде;

доверенными инструкциями. Это данные, а не команды владельца системы.

10.2. Least privilege

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

Для read-only анализа не нужны:

• удаление файлов;
• restart сервисов;
• доступ к секретам;
• production credentials.

10.3. Секреты

• хранить в env/secret manager;
• не читать без необходимости;
• маскировать логи;
• не отправлять в prompt;
• не коммитить;
• после утечки ротировать.

10.4. Деплой

Правильный production workflow:

Изменение → тесты → сборка → backup → staging/smoke → deploy → HTTP/API check → rollback при ошибке

---

11. Модели и стоимость

11.1. Двухуровневая стратегия

Tier 1 — рабочая модель

Для:

• CRUD;
• UI-компонентов;
• простых API;
• тестов;
• документации;
• небольших исправлений.

Tier 2 — сильная модель

Для:

• архитектуры;
• сложных багов;
• auth и permissions;
• миграций;
• рефакторинга большого объёма;
• security review;
• интеграций.

11.2. Не использовать самую сильную модель везде

Модель должна соответствовать риску задачи, а не престижу.

Риск	Модель
Низкий	быстрая дешёвая
Средний	сильная рабочая
Высокий	сильная модель + review + человек

11.3. Где экономить безопасно

• заголовки сессий;
• простая суммаризация;
• поиск подходящего skill;
• форматирование;
• простые CRUD-изменения.

11.4. Где экономить опасно

• compression критичного контекста;
• approval опасных команд;
• auth;
• платежи;
• миграции production DB;
• импорт и удаление данных;
• права доступа.

---

12. Практическая схема Hermes для твоих проектов

12.1. Основной режим

Один основной профиль для внутренней разработки:

• seohelper;
• seo-backend;
• ecom;
• nm.yuriybevov.ru;
• сервер;
• CRM/CMS.

Это дешевле и сохраняет единый контекст.

12.2. Навыки как routing layer

Использовать навыки только по необходимости:

• deployment;
• Vue/Nuxt;
• SEO;
• DOCX;
• debugging;
• design;
• GitHub.

Не загружать большие skills заранее.

12.3. Рекомендуемый workflow новой фичи

1. Пользователь формулирует цель
2. Агент изучает проект
3. Агент пишет ТЗ с нумерованными пунктами
4. Пользователь подтверждает ТЗ
5. Агент создаёт план
6. Реализация маленькими шагами
7. После каждого шага тесты
8. Проверка соответствия ТЗ
9. Code review
10. Сборка
11. Smoke test
12. Backup и deploy только после разрешения
13. Сохранение стабильных решений в память/документацию

12.4. Для крупной фичи

Главный агент
  ├─ исследование текущего кода
  ├─ backend worker
  ├─ frontend worker
  ├─ test/review worker
  └─ интеграционная проверка

Но workers не должны одновременно править одни и те же файлы.

12.5. Approval

Использовать модель как дополнительный фильтр, но не как единственный барьер. Для destructive production-операций финальное решение остаётся за Юрием.

12.6. MoA

Оставить как специальный инструмент для:

• архитектурных решений;
• сложного аудита;
• спорного выбора модели/стека;
• финального review;

но не включать как основной режим для ежедневной разработки.

---

13. Антипаттерны

13.1. «Сделай весь проект» одним запросом

Проблемы:

• агент не понимает приоритеты;
• много scope creep;
• трудно проверить результат;
• ошибки обнаруживаются поздно.

13.2. Код без изучения проекта

Приводит к дублированию компонентов, конфликтам стилей и поломке API.

13.3. Автоматический деплой после генерации

Генерация не равна проверке. Всегда нужны build, тесты, smoke и rollback.

13.4. Параллельная запись в одни файлы

Приводит к конфликтам и потере изменений.

13.5. Огромный контекст без фильтрации

Модель видит много текста, но хуже выделяет главное и дороже работает.

13.6. MoA для всего

Повышает стоимость и задержку без пропорциональной пользы.

13.7. Доверие к «готово» без проверки

Всегда проверять реальным tool output.

13.8. Использование AI как замены архитектуры

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

---

14. Чек-лист новой фичи

До реализации

• Цель сформулирована.
• Пользователь и сценарий понятны.
• Текущая архитектура изучена.
• Затрагиваемые файлы определены.
• ТЗ написано нумерованными пунктами.
• Acceptance criteria определены.
• Пользователь подтвердил начало реализации.

Во время реализации

• Изменение маленькое и обратимое.
• Backend проверяет входные данные.
• Права проверяются на сервере.
• Ошибки обработаны.
• Тест написан.
• Нет незапрошенного scope creep.
• Секреты не попали в код или логи.

Перед деплоем

• Git diff проверен.
• Build проходит.
• Typecheck/lint проходят.
• Тесты проходят.
• Production backup создан.
• Smoke-test подготовлен.
• Rollback понятен.
• Получено разрешение на production-изменение.

После деплоя

• HTTP возвращает ожидаемый статус.
• Ключевой пользовательский сценарий проверен.
• API отвечает корректно.
• Логи не содержат новых ошибок.
• Результат зафиксирован.

---

15. Короткая итоговая стратегия

1. Использовать single agent по умолчанию.
2. Сначала ТЗ и исследование, потом код.
3. Для больших задач применять plan-and-execute.
4. Независимые части параллелить, общие файлы — нет.
5. Для критичного кода использовать evaluator/reviewer.
6. MoA включать только для сложных решений.
7. Дешёвую модель использовать для рутинной работы.
8. Сильную модель подключать по риску и сложности.
9. Все изменения проверять реальным выполнением.
10. Production-действия оставлять под контролем владельца.

---

Источники и дальнейшее чтение

• Anthropic — Building Effective AI Agents: https://www.anthropic.com/research/building-effective-agents
• Anthropic — Architecture Patterns and Implementation Frameworks: https://resources.anthropic.com/hubfs/Building+Effective+AI+Agents-+Architecture+Patterns+and+Implementation+Frameworks.pdf
• OpenAI — A Practical Guide to Building Agents: https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
• OpenAI — Building Agents: https://developers.openai.com/tracks/building-agents
• Hermes Agent documentation: https://hermes-agent.nousresearch.com/docs

Документ подготовлен как практическая база для работы с Hermes Agent и AI-assisted development.