ITECH · ТЗ · проекты · акты

Контроль изменений ТЗ, проектной документации и актов; согласование с заказчиком. Перенос из Gramax (ITECH_DOCS).

Проект

Коммерческое предложение, PRD и Техническое задание (каноничные документы проекта).

Проект

Коммерческое предложение

LEANTECH

Разработка и внедрение AI-ассистента для отдела продаж ITECH

Grace CRM Assistant

Исполнитель LeanTech (ООО Экобанкинг)
Заказчик ООО «АйТек»
Дата 09.04.2026
Основание PRD v1.0 от 28.03.2026 + дополнения от 01.04.2026

1. Что мы предлагаем

LeanTech работает на стыке трёх дисциплин: бережливые методологии + AI-агенты + развитие людей. Именно эта комбинация даёт результат, который недостижим ни через внедрение одной технологии, ни через классический консалтинг по отдельности.

Для АйТек мы предлагаем мультиагентную AI-систему поверх Grace CRM -- группу специализированных AI-агентов, каждый из которых выполняет конкретную роль в процессе продаж: собирает информацию, анализирует контекст, готовит рекомендацию, напоминает о следующем шаге.

Система решает три практические задачи отдела продаж:

Какую выгоду получает ITECH?

Больше сделок при той же команде. AI-агенты берут на себя рутину: отслеживание статусов по активным проектам, поиск нужной информации, подготовку контекста к звонку. Менеджер тратит время на клиента, а не на CRM. Ожидаемый эффект -- высвобождение 6–10 часов в неделю на каждого менеджера. При 10–15 менеджерах это 60–120 дополнительных часов продаж в неделю без расширения штата.

Скорость ответа клиенту как конкурентное преимущество. Система сигнализирует, когда клиент давно без контакта, когда наступает критический момент для звонка, когда нужно ускорить сделку. Менеджер действует проактивно -- клиенты АйТек получают ответ быстрее, чем от конкурентов, у которых такой системы нет.

Фундамент для цифровизации компании. КРАБ -- корпоративная база знаний -- строится один раз и становится активом компании. По мере роста системы к ней подключаются другие процессы и отделы: производство, закупки, проектирование. Это не точечное решение, а архитектура, которая масштабируется.

Дополнение по результатам обсуждения от 01.04.2026

По запросу усилен блок «Помощь продавцу в выстраивании стратегии по проекту/клиенту». Recommendation Agent дополнен следующими требованиями:

«По проекту "ЖК Северный" для клиента ООО "СтройГрупп" последний контакт был 16 дней назад. В похожей сделке на поставку ВРУ для жилого комплекса решающим оказался звонок с уточнением статуса согласования у главного энергетика. Рекомендуем: связаться с руководителем проекта, уточнить готовность технического задания, предложить провести расчёт в течение одного рабочего дня.»

2. Этапы и состав работ -- Фаза 1 (MVP)

Этап 0. Исследование и архитектура (2 недели)

Самый критичный этап. На нём мы вместе с командой АйТек детально изучаем как устроены процессы продаж, какие данные где живут, и проектируем архитектуру системы. Для каждого будущего агента фиксируем три вещи: роль, вход и выход, правила управления и эскалации. Результат этапа определяет качество всего проекта.

Блок работ Содержание Часы
Исследование Grace CRM API Изучение API, тестирование эндпоинтов, определение лимитов, проверка вебхуков, документирование доступных данных 24
Проектирование КРАБ КРАБ -- Корпоративная Распределённая Адаптивная База знаний. Проектирование структуры векторного хранилища: какие данные индексировать, модель похожести сделок, стратегия наполнения и обогащения 20
Проектирование tech stack Финализация стека, настройка Docker Compose, CI/CD, структура репозитория, выбор LLM-провайдера, оценка стоимости токенов 12
Схема БД и модели данных Проектирование PostgreSQL-схемы: кэш CRM-данных, история рекомендаций, конфигурация агентов и правил 12
Архитектура безопасности Проектирование RBAC-модели, схема JWT + 2FA, политика хранения API-ключей (Vault), audit log 12
Согласование с заказчиком Утверждение ролевой модели доступа, правил работы агентов, политики безопасности, приоритетов наполнения КРАБ 8
Итого Этап 0 88

Результат: Технический проект, утверждённая архитектура агентной системы, задокументированное API Grace, спроектированный КРАБ, работающее dev-окружение.

Этап 1. Интеграция с Grace CRM + синхронизация данных (3 недели)

Блок работ Содержание Часы
Модуль синхронизации Периодический полинг / вебхуки Grace API, синхронизация справочников, проекты, статусы, история активностей 36
Агент контроля качества данных Автоматический мониторинг полноты и актуальности данных по проектам, формирование сигналов о пробелах 28
Очередь и отказоустойчивость Celery + Redis: фоновая синхронизация, ретраи, логирование ошибок 12
Итого Этап 1 76

Результат: Данные Grace CRM синхронизируются в реальном времени, агент контроля качества фиксирует пробелы и формирует сигналы для команды.

Этап 2. Recommendation Agent + Telegram-бот (3 недели)

Блок работ Содержание Часы
Наполнение КРАБ Импорт истории закрытых сделок АйТек, формирование эмбеддингов, настройка pgvector, тестирование релевантности поиска 24
Recommendation Agent (Agno) Разработка агента: подключение к КРАБ, промпт-инжиниринг для стратегических рекомендаций под специфику электрощитового производства, логика эскалации к РОПу 36
Telegram-бот Интеграция python-telegram-bot, форматирование сообщений по ролям, расписание уведомлений 16
Итого Этап 2 76

Результат: Менеджеры получают в Telegram конкретные стратегические рекомендации по проектам, основанные на реальном опыте АйТек.

Этап 3. Тестирование, внедрение и обучение (2 недели)

Блок работ Содержание Часы
Интеграционное тестирование End-to-end тесты всех модулей, стресс-тест синхронизации, проверка корректности расчётов Кк 16
Тестирование безопасности Проверка RBAC на всех эндпоинтах, audit log, сканирование уязвимостей 10
Деплой на production Docker Compose on-premise, миграция, мониторинг (Sentry), настройка TLS/HTTPS 10
Обучение пользователей Обучающие сессии для менеджеров (2–3 группы), для РОП, для зам. ГД. Инструкции и видеогайды 14
Пилотная эксплуатация Сопровождение до конца периода: мониторинг, исправление багов, сбор обратной связи, тюнинг рекомендаций 10
Итого Этап 3 60

Результат: Система работает в production, все пользователи обучены, пилотный период пройден.

3. Сводная оценка трудозатрат и стоимости -- Фаза 1

Распределение часов по ролям

Этап PM / архитектор Разработчик Junior Итого
0. Исследование и архитектура 56 24 8 88
1. Интеграция + синхронизация данных 12 44 20 76
2. Recommendation Agent + TG 16 44 16 76
3. Тестирование и внедрение 24 18 18 60
Итого 108 130 62 300

Расчёт стоимости (все суммы -- с учётом всех налогов и сборов)

Роль Часы Ставка Сумма
PM / архитектор решения 108 4 500 ₽/ч 486 000 ₽
Разработчик (fullstack + AI) 130 3 000 ₽/ч 390 000 ₽
Junior-разработчик 62 1 800 ₽/ч 111 600 ₽
Итого работа команды 300 987 600 ₽

Все суммы указаны с учётом всех налогов и сборов. Дополнительных начислений нет.

Инфраструктурные расходы (~10 недель разработки ≈ 2,5 месяца)

Статья В мес. Период Сумма
LLM API + AI-инструменты разработки ~30 000 ₽ 2,5 мес. ~75 000 ₽
Сервер для разработки (если нет своего) ~5 000 ₽ 2,5 мес. ~12 500 ₽
Прочее (домен, SSL, мониторинг) ~5 000 ₽ 2,5 мес. ~12 500 ₽
Итого инфраструктура ~100 000 ₽

Инфраструктурные расходы оплачиваются заказчиком отдельно. Если у АйТек есть собственный сервер -- статья «Сервер» не включается.

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

Итого Фаза 1

Сумма
Работа команды 987 600 ₽
Инфраструктура (оценка) ~100 000 ₽
ИТОГО ~1 087 600 ₽

4. Почему такая стоимость?

Мы активно используем AI-агентов в собственной разработке (Claude Code, Cursor) -- это позволяет небольшой команде из 3 человек реализовать проект за 2,5 месяца, который в классической разработке потребовал бы 4–6 человек и 4–8 месяцев.

При этом важно понимать, где находится основная ценность проекта:

70% сложности -- это не код. Это работа на стыке процессов, людей и архитектуры:

30% -- написание кода, которое ускоряется за счёт AI-инструментов разработки.

5. Безопасность и защита данных

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

Разграничение доступа (RBAC):

Аутентификация и шифрование:

Аудит и мониторинг:

Защита от уязвимостей:

On-premise развёртывание:

6. Условия оплаты

Все суммы указаны с учётом всех налогов и сборов.

График оплаты работы команды

№ Момент Сумма
1 Предоплата при подписании договора 190 000 ₽
2 По завершении Этапа 0 (исследование и архитектура утверждены) 190 000 ₽
3 По завершении Этапа 1 (интеграция с Grace CRM работает, данные синхронизируются) 240 000 ₽
4 По завершении Этапа 2 (Recommendation Agent + Telegram-бот запущены) 250 000 ₽
5 По завершении Этапа 3 (тестирование, деплой, обучение, пилот пройден) 117 600 ₽
Итого 987 600 ₽

Каждый этап завершается подписанием акта приёмки.

Инфраструктурные расходы (~100 000 ₽) оплачиваются заказчиком отдельно по необходимости и согласованию.

7. Сроки

Этап Длительность Ориентировочные даты
0. Исследование и архитектура 2 недели Апрель 2026 (2–3 неделя)
1. Интеграция + синхронизация данных 3 недели Май 2026 (1–3 неделя)
2. Recommendation Agent + TG 3 недели Май–Июнь 2026
3. Тестирование и внедрение 2 недели Июнь 2026 (3–4 неделя)
Итого Фаза 1 ~10 недель Апрель -- конец Июня 2026

8. О компании LeanTech

LeanTech -- бережливые технологии управления.

Мы работаем на стыке трёх дисциплин: Lean-методология + AI-агенты + развитие людей. Как показывает практика передовых компаний, именно это сочетание даёт конкурентные преимущества, недостижимые ни через «чистый Lean», ни через «чистый AI», ни через классический консалтинг по отдельности.

Наш подход: сначала разобраться как работает бизнес, понять где AI усилит людей, а не заменит их -- и только потом строить систему. Поэтому Этап 0 для нас не формальность, а основа всего проекта.

Релевантный опыт:

9. Следующие шаги

  1. Обсудить и согласовать данное предложение.

  2. Утвердить условия оплаты.

  3. Подписать договор.

  4. Запустить Этап 0 -- исследование API Grace CRM.

Предложение действительно до 30.04.2026.

Контакт: Левицкий А.Е., LeanTech

Проект

Product Requirements Document (PRD)

AI-ассистент для менеджеров продаж ITECH (Grace CRM)

Версия документа: 1.0 Дата: [Текущая дата] Автор: [Имя автора/Команда продукта] Статус: Черновик на согласование

1. Введение и обзор продукта

1.1. Видение продукта

AI-ассистент для менеджеров продаж ITECH (далее -- Grace CRM Assistant) -- это мультиагентная система на базе больших языковых моделей (LLM), внедряемая поверх корпоративной CRM-системы Grace (grace.i-tech.su). В основе архитектуры -- набор специализированных AI агентов, каждый из которых обладает доступом к инструментам (tool calls), долгосрочной памятью и способностью к рассуждению (reasoning). Агенты автономно анализируют состояние проектов, формируют рекомендации, рассчитывают прогнозы и отправляют уведомления -- без ручной настройки правил. Со временем система накапливает паттерны успешных сделок компании и повышает качество рекомендаций.

1.2. Проблема и обоснование

В ООО «АйТек» существуют следующие болевые точки в процессе продаж:

1.3. Цели и задачи

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

Ключевые задачи (OKR):

  1. Повысить дисциплину заполнения CRM: Увеличить средний коэффициент качества (Кк) по отделу на 30% в течение 6 месяцев после запуска.

  2. Снизить потери проектов: Уменьшить количество «спящих» клиентов (нет активности >3 мес.) на 25% за квартал.

  3. Повысить прозрачность и мотивацию: Обеспечить 100% менеджеров доступом к прогнозу премии в реальном времени.

  4. Ускорить онбординг: Сократить среднее время выхода нового менеджера на стандартную продуктивность на 20%.

2. Анализ целевой аудитории

2.1. Пользователи и их роли

Роль Количество Ключевые задачи в системе Ключевые потребности
Менеджер по продажам ~10-15 чел. Ведение проектов, получение напоминаний, просмотр своего дашборда и прогноза премии, прохождение обучения. Четкие подсказки, простота интерфейса, мотивация через прозрачный расчет премии.
Ведущий менеджер Несколько чел. Все функции менеджера + доступ к расширенной аналитике по своим проектам/клиентам. Углубленная аналитика, инструменты для наставничества.
Руководитель отдела продаж (РОП) 1 чел. Мониторинг общей воронки, аналитика по эффективности команды, доступ ко всем данным о премиях (с разграничением). Обзорные дашборды, данные для планирования, выявление узких мест.
Заместитель ГД по развитию 1 чел. Стратегический обзор воронки, прогноз выручки, анализ по ключевым клиентам. Высокоуровневая аналитика, прогнозные модели.

2.2. Контекст использования

3. Детальное описание основных функций (Core Features)

3.1. Мониторинг качества данных CRM

3.2. Умные напоминания и рекомендация «Следующего шага»

3.3. Калькулятор премии в реальном времени

3.4. Аналитический дашборд воронки продаж

3.5. Обучающий модуль

3.6. Интеграция с Grace CRM API

4. Технические и бизнес-ограничения

4.1. Технические ограничения

  1. Интеграция только через API Grace CRM. Прямого доступа к базе данных нет. API самописное, требуется тщательное изучение документации (ее наличие уточняется) и проведение стресс-тестирования.

  2. Миграция на 1С ЕРП. До 01.07.2026 учет производства ведется в ВМС, затем планируется переход. Модули, связанные с производственными сроками (фаза 2), должны проектироваться с учетом будущей миграции (абстрактный слой данных).

  3. Нормы времени в Excel. Интеграция с производственными нормативами отложена на фазу 2. В фазе 1 расчеты ведутся только на данных CRM.

  4. Производительность. Система должна работать с объемом данных: ~1000 клиентов, ~700 активных проектов, ~15 одновременных пользователей без деградации производительности.

4.2. Бизнес-ограничения и политики

  1. Поэтапность разработки:

    • Фаза 1 (MVP): Модуль продаж (пп. 3.1, 3.2, 3.3, 3.6). Запуск в пилот.

    • Фаза 2: Расширенная аналитика (п. 3.4), интеграция с нормативами из Excel, модуль для производства.

    • Фаза 3: Полноценная интеграция с 1С ЕРП, модуль проектирования.

  2. Конфиденциальность данных. Строгое разграничение доступа:

    • Менеджер: Видит только свои проекты, свою аналитику, свой прогноз премии.

    • РОП/Ведущий: Видит данные по своим подчиненным/направлению.

    • Зам. ГД: Имеет доступ ко всей аналитике, но без данных о персональных премиях менеджеров (только агрегаты).

    • Реализуется на уровне API-запросов и логики приложения.

  3. Регламент. Все бизнес-правила (правила проверки, формулы) должны быть вынесены в конфигурационные файлы или админ-панель для оперативного изменения без релизов.

5. Соображения по реализации

5.1. Мультиагентная архитектура

Система построена на фреймворке Agno (Python). Agno реализует концепцию Agent Teams: каждый агент -- объект класса Agent с декларативно заданными инструментами, памятью и базой знаний; команда агентов управляется объектом Team, который маршрутизирует задачи и объединяет результаты.

┌────────────────────────────────────────────────────────┐│              Sales Team  (agno.Team)                   ││    mode=coordinate │ leader: Orchestrator Agent        │└──────┬──────────┬──────────┬──────────┬───────────────┘       │          │          │          │┌──────▼──┐ ┌────▼────┐ ┌───▼───┐ ┌───▼──────────┐│  CRM    │ │ Recom-  │ │ Bonus │ │ Notification ││ Monitor │ │mendation│ │ Calc. │ │    Agent     ││  Agent  │ │  Agent  │ │ Agent │ │(TG / e-mail) │└──────┬──┘ └────┬────┘ └───┬───┘ └──────────────┘       │          │          │┌──────▼──────────▼──────────▼──────────────────────────┐│              Tool Layer  (agno.tools + custom)        ││  Grace CRM API │ PostgreSQL (agno.storage) │ pgvector  ││                │ (agno.knowledge / RAG)               │└───────────────────────────────────────────────────────┘

Агенты системы (agno.Agent):

Агент Роль Инструменты (tools) LLM
Orchestrator Agent Лидер Team: принимает входящую задачу, делегирует агентам, агрегирует результат; при критических ситуациях инициирует эскалацию к РОПу schedule_task, route_to_agent, escalate_to_rop GPT-4o
CRM Monitor Agent Проверяет каждый проект на соответствие регламенту, рассчитывает персональный Кк get_projects, check_required_fields, update_kk_score, flag_project GPT-4o-mini
Recommendation Agent Анализирует контекст проекта, ищет паттерны успешных сделок через agno.knowledge (pgvector RAG), генерирует рекомендацию следующего шага get_project_context, get_activity_history, vector_search_similar_deals, write_recommendation GPT-4o
Bonus Calc Agent Детерминированный расчёт прогноза квартальной премии по формуле П = [Σ((Пр × Ку) − КРр)] × Кк; LLM используется только для форматирования объяснения get_manager_projects, get_kk_score, get_stage_coefficients, calculate_bonus GPT-4o-mini
Notification Agent Форматирует и доставляет сообщения в Telegram / e-mail; адаптирует стиль под роль получателя send_telegram, send_email, format_message_for_role GPT-4o-mini

Ключевые возможности Agno, используемые в проекте:

Типы памяти агентов:

5.2. Высокоуровневая архитектура системы

5.3. Технологический стек

Слой Технология Обоснование
Агентный фреймворк Agno (agno.Agent, agno.Team) Лёгкий, Pythonic API; нативная поддержка Teams, pgvector RAG, PostgreSQL storage; встроенный мониторинг через agno.io
LLM (основной) OpenAI GPT-4o / GPT-4o-mini Function calling, высокое качество reasoning, tool use; нативная интеграция в Agno
LLM (резервный) Google Gemini 1.5 Pro Fallback при недоступности OpenAI; нативная интеграция в Agno
Векторная БД pgvector + agno.knowledge.PgVector2 RAG по истории сделок без отдельного сервиса; управляется через Agno из коробки
Хранилище агентов agno.storage.PostgresStorage Персистентная память сессий агентов в PostgreSQL
Бэкенд Python 3.12 + FastAPI Async, нативная совместимость с Agno
Фронтенд React 18 + TypeScript Компонентность, скорость разработки
UI-библиотека Ant Design Таблицы, дашборды, форм-контролы из коробки
Реляционная БД PostgreSQL 16 Хранение кэша CRM, логов, истории уведомлений
Кеш / очередь Redis 7 + Celery Планировщик запуска агентов, кеш справочников
Интеграция с Grace REST API (HTTP/JSON) Единственный поддерживаемый канал доступа
Уведомления python-telegram-bot Telegram-бот для менеджеров
Наблюдаемость agno.io + Sentry Встроенный трейсинг вызовов агентов; мониторинг ошибок
Деплой Docker Compose Простота развёртывания on-premise

5.4. Безопасность и разграничение доступа

6. Дорожная карта (Roadmap)

Фаза 1 -- MVP (срок: 2–3 месяца после старта)

Цель: Запустить в пилот ключевые модули для отдела продаж.

Спринт Задачи
Спринт 1–2 Изучение API Grace CRM. Разработка схемы БД. Базовая аутентификация. Docker-окружение.
Спринт 3–4 Модуль синхронизации данных с Grace CRM (п. 3.6). Расчёт Кк (п. 3.1).
Спринт 5–6 Калькулятор премии (п. 3.3). Умные напоминания и Telegram-бот (п. 3.2).
Спринт 7–8 Фронтенд: личный дашборд менеджера, виджет Кк, прогноз премии. Тестирование. Пилот.

Критерии готовности MVP: Все менеджеры могут видеть свой Кк и прогноз премии. Telegram-уведомления работают. Синхронизация с Grace без ошибок > 48 часов.

Фаза 2 -- Расширенная аналитика (срок: 2–3 месяца после MVP)

Фаза 3 -- Интеграция с 1С ЕРП (срок: после 01.07.2026)

7. Метрики успеха

7.1. Ключевые показатели эффективности (KPI)

Метрика Базовое значение Целевое значение Срок
Средний Кк по отделу < 0.7 (оценка) ≥ 0.91 +6 мес. после запуска
Доля менеджеров с Кк ≥ 0.85 < 50% ≥ 80% +3 мес.
Количество «спящих» клиентов (>3 мес.) Базовый замер −25% +1 квартал
Время выхода нового менеджера на норму ~3 месяца ≤ 2.5 месяца +6 мес.
Доля менеджеров, использующих систему ежедневно 0% ≥ 85% +2 мес. после запуска
Количество ошибок синхронизации с Grace CRM -- < 0.1% запросов Постоянно

7.2. Метрики качества продукта

8. Риски и митигация

# Риск Вероятность Влияние Митигация
R1 API Grace CRM закрытое / плохо документированное Высокая Критическое Провести spike (2 недели) на изучение API до старта разработки. Предусмотреть прямой SQL-доступ как fallback (согласовать с вендором).
R2 Сопротивление менеджеров внедрению (change management) Средняя Высокое Вовлечь 2–3 «чемпионов» из команды продаж на этапе дизайна. Показать прямую выгоду через прозрачность премии.
R3 Изменение формулы расчёта премии / регламента CRM Средняя Среднее Вынести все бизнес-правила в конфигурационные файлы. Обеспечить возможность изменений без релизов.
R4 Задержка миграции на 1С ЕРП (>01.07.2026) Средняя Низкое Фаза 3 не входит в MVP. Архитектура фазы 1–2 проектируется с абстрактным слоем данных.
R5 Нехватка ресурсов разработки Средняя Высокое Зафиксировать минимальный состав команды (1 бэкенд + 1 фронтенд + 1 PM/аналитик) до старта.
R6 Утечка конфиденциальных данных о премиях Низкая Критическое Строгий RBAC, аудит-лог, тестирование безопасности перед запуском. Принцип минимальных прав.

9. Открытые вопросы и следующие шаги

9.1. Открытые вопросы

  1. API Grace CRM: Существует ли официальная документация? Поддерживаются ли вебхуки? Каков лимит запросов в минуту?

  2. Формула Кк: Финальная формула и веса для каждой проверки -- требует утверждения РОПом и Зам. ГД.

  3. Telegram-бот: Разрешено ли корпоративными политиками использование Telegram для рабочих уведомлений? Альтернатива -- корпоративный мессенджер.

  4. Хостинг: Определить конкретный сервер / инфраструктуру для деплоя (on-premise или корпоративное облако).

  5. Команда: Кто несёт ответственность за разработку -- внутренняя команда ООО «АйТек» или внешний подрядчик?

9.2. Следующие шаги

Документ подготовлен на основе материалов: «Правила заполнения данных CRM-системы. Продажи» (24.06.2024), «Бонусная политика ITECH», внутренних интервью с РОПом и менеджерами.

Проект

Техническое задание

Приложение №1 к Договору 04-002 от 24.04.2026

об оказании услуг между ООО «Экобанкинг» и ООО «АйТек»

Разработка и внедрение мультиагентной AI-системы Grace CRM Assistant

для отдела продаж ООО «АйТек»

г. Москва, 2026 г. · Версия 2.2

Исполнитель: ООО «Экобанкинг»

Заказчик: ООО «АйТек»

Договор: №04-002 от 24.04.2026

1. Общие сведения

Разработка и внедрение мультиагентной AI-системы (Grace CRM Assistant) -- набора специализированных цифровых сотрудников, автоматизирующих ключевые участки процесса продаж ООО «АйТек», а также технической платформы корпоративного управления знаниями.

2. Цель и назначение системы

Система создаётся для повышения эффективности отдела продаж ООО «АйТек» за счёт автоматизации рутинных операций, предоставления менеджерам своевременных рекомендаций и создания корпоративного поискового контура на основе накопленных знаний компании.

Система обеспечивает:

-- AI-ассистирование менеджера по продажам -- анализ контекста проектов и выработка конкретных рекомендаций по следующему шагу

-- Автоматический контроль качества и актуальности данных в Grace CRM

-- Своевременные уведомления для менеджеров, РОПа и руководства через Telegram

-- Аналитические дашборды по данным CRM через OpenSearch Dashboards

-- Поиск и получение отраслевого контекста через корпоративный поисковый контур на базе OpenSearch при формировании рекомендаций

-- Техническую платформу корпоративного управления знаниями: RAGflow + AI-агенты базы знаний

3. Состав системы -- агентная архитектура

Система состоит из двух взаимосвязанных контуров: агенты отдела продаж (Grace CRM Assistant) и агенты базы знаний. Архитектура агентов и правила эскалации утверждаются по результатам Этапа 0.

3.1 Агенты отдела продаж (Grace CRM Assistant)

Агент Вход Выход Управление / эскалация
Sync Agent Данные Grace CRM через MS SQL Актуальный индекс в OpenSearch Автоматически по расписанию / вебхук
Quality Agent Индекс CRM, правила полноты Список проектов с пробелами, сигнал в Telegram Оркестратор -> менеджер / РОП
Recommendation Agent Контекст из OpenSearch (CRM + база знаний) Рекомендация: действие, срок, обоснование Оркестратор -> менеджер; при просрочке -> РОП
Notification Agent События от агентов, роль получателя Telegram-сообщение адресату Оркестратор; при отсутствии реакции -> эскалация
Orchestrator Сигналы от всех агентов Приоритизация, маршрутизация Правила эскалации, утверждённые на Этапе 0

3.2 Агенты базы знаний

Реализуются в соответствии с методологическими требованиями и Схемой КРАБ, предоставляемыми в рамках смежного консалтингового проекта.

Агент Функция Триггер
Ingest Agent Принимает документ -> определяет блок -> создаёт/обновляет wiki-страницы в RAGflow -> обновляет индекс OpenSearch Новый документ / ручной запуск
Query Agent Принимает запрос + фильтр по блоку -> ищет в RAGflow + OpenSearch -> синтезирует ответ с цитатами Запрос от агента продаж или сотрудника
Lint Agent Сканирует базу знаний -> находит противоречия, устаревшие записи, orphaned-страницы -> формирует отчёт Еженедельно по расписанию

4. Корпоративный поисковый контур (OpenSearch)

Экобанкинг разворачивает и настраивает OpenSearch on-premise как единый поисковый и аналитический слой системы, обслуживающий оба контура: агентов продаж и базу знаний.

4.1 Интеграция с текущей БД (MS SQL -> OpenSearch)

Текущие данные АйТек хранятся в MS SQL (Grace CRM). Интеграция выполняется в два шага:

Шаг 1 -- Синхронизация: разработка коннектора MS SQL -> OpenSearch. Sync Agent извлекает данные (проекты, клиенты, статусы, история активностей) и индексирует их в OpenSearch через вебхуки и периодический полинг.

Шаг 2 -- API-слой: разработка унифицированного API поверх OpenSearch для последующего подключения внешних систем (±1С, PDM, ERP и др.) без прямого доступа к MS SQL. API предоставляет стандартизированный интерфейс чтения и записи данных.

4.2 Индексы OpenSearch

Индекс Содержимое Потребители
crm-projects Проекты, статусы, история активностей из Grace CRM Sync Agent, Quality Agent, Recommendation Agent
crm-clients Клиенты, отрасли, контакты Recommendation Agent
kb-documents Wiki-страницы базы знаний (блоки БЗ-1..БЗ-11) Query Agent, Recommendation Agent
kb-log Журнал изменений базы знаний Lint Agent

4.3 OpenSearch Dashboards

Настройка аналитических дашбордов для трёх ролей:

-- Менеджер: свои проекты, рекомендации, просроченные контакты

-- РОП: сводка по команде, динамика статусов, просроченные контакты по команде, эскалации

-- Зам. ГД: агрегированная воронка, прогноз выручки, сигналы по команде

5. Платформа базы знаний (RAGflow + AI-агенты)

5.1 RAGflow

Экобанкинг разворачивает RAGflow on-premise на сервере Заказчика:

-- Установка и настройка RAGflow (Docker, on-premise)

-- Настройка embedding-модели для русского языка (multilingual-e5 или аналог)

-- Подключение LLM-провайдера (GigaChat / YandexGPT / OpenAI -- по согласованию с Заказчиком)

-- Настройка хранилища документов (MinIO или локальная папка)

-- Настройка пайплайна: документ -> парсинг -> чанкинг -> векторизация -> индексация в RAGflow + OpenSearch

5.2 AI-агенты базы знаний

Разработка трёх агентов (Ingest, Query, Lint) в соответствии с функциональными требованиями раздела 3.2. Реализация включает:

-- Разработку скриптов Ingest-цикла: приём документа, определение блока знаний, создание/обновление wiki-страниц, обновление кросс-ссылок

-- Разработку Query-модуля: гибридный поиск (семантический + полнотекстовый) с фильтрацией по блоку, синтез ответа с цитатами

-- Разработку Lint-цикла: еженедельное сканирование, выявление противоречий (LLM-сравнение страниц), формирование отчёта, уведомление ответственного

-- Разработку веб-интерфейса прямого доступа сотрудников к базе знаний (поиск, просмотр страниц, загрузка документов)

-- Настройку RBAC: разграничение доступа к блокам знаний по ролям

Фреймворк реализации агентов определяется Исполнителем на Этапе 0 исходя из технических требований. Функциональные требования и Схема КРАБ (структура блоков, форматы страниц, правила Ingest) предоставляются Заказчиком в рамках смежного консалтингового проекта.

6. Этапы и состав работ

Этап Состав работ Срок
Этап 0 Исследование и архитектура Исследование API Grace CRM и схемы MS SQL; проектирование индексов OpenSearch; архитектура агентов обоих контуров; выбор фреймворка агентов базы знаний; ролевая модель; согласование 2 нед.
Этап 1 Инфраструктура и интеграция данных Развёртывание OpenSearch + Dashboards; коннектор MS SQL -> OpenSearch (Шаг 1); API-слой для внешних систем (Шаг 2); Sync Agent; Quality Agent; базовые дашборды 3 нед.
Этап 2 Agents + RAGflow Развёртывание RAGflow; настройка embedding и LLM; Ingest Agent, Query Agent, Lint Agent; Recommendation Agent с подключением к поисковому контуру; Telegram-бот; Orchestrator 3 нед.
Этап 3 Тестирование, внедрение Интеграционное и нагрузочное тестирование всех модулей; тестирование безопасности; веб-интерфейс базы знаний; деплой on-premise; обучение; пилот 2 нед.
ИТОГО ~10 нед.

Этап 0. Результаты:

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

-- Схема индексов OpenSearch (4 индекса, форматы документов, правила фильтрации)

-- Схема интеграции MS SQL -> OpenSearch (коннектор, периодичность, обработка конфликтов)

-- Спецификация API-слоя для внешних систем

-- Описание ролевой модели (RBAC) -- агенты продаж + база знаний

-- Выбор фреймворка и архитектура агентов базы знаний

-- Работающее окружение для разработки

Этап 1. Критерии приёмки:

-- OpenSearch развёрнут, базовые дашборды доступны по ролям

-- Данные из Grace CRM (MS SQL) корректно синхронизируются в индексы crm-projects и crm-clients

-- API-слой возвращает корректные ответы на тестовые запросы

-- Quality Agent формирует сигналы о пробелах в данных; очередь задач работает без потерь

Этап 2. Критерии приёмки:

-- RAGflow развёрнут, embedding-модель и LLM-провайдер настроены

-- Ingest Agent принимает тестовый документ -> создаёт wiki-страницу -> индексирует в OpenSearch

-- Query Agent возвращает релевантный ответ с цитатой за ≤ 5 сек.

-- Lint Agent формирует тестовый отчёт о состоянии базы знаний

-- Recommendation Agent формирует рекомендации с использованием данных CRM и поискового контура

-- Telegram-бот доставляет уведомления по ролям, эскалация работает корректно

Этап 3. Критерии приёмки:

-- Система развёрнута на production-сервере Заказчика и работает в штатном режиме

-- Веб-интерфейс базы знаний доступен сотрудникам по ролям

-- RBAC корректен на всех эндпоинтах обоих контуров; audit log ведётся

-- Проведено обучение: менеджеры (2–3 группы), РОП, зам. ГД, ответственный за базу знаний

-- Пилотная эксплуатация завершена, критические замечания устранены

7. Требования к безопасности и доступу

Роль Права доступа
Менеджер Свои проекты, аналитика, рекомендации; блоки БЗ-7, БЗ-8, БЗ-9, БЗ-11
РОП Проекты и аналитика по команде, эскалации; те же блоки базы знаний
Зам. ГД Агрегированная аналитика; БЗ-7, БЗ-8
Ответственный за блок Загрузка документов, просмотр и редактирование своего блока базы знаний
Администратор Конфигурация агентов, пользователей, RBAC; доступ к логированию

Технические меры безопасности:

-- JWT-аутентификация + двухфакторная аутентификация для администраторов

-- Весь трафик -- HTTPS (TLS 1.3)

-- API-ключи LLM-провайдеров и Grace CRM хранятся в защищённом хранилище

-- Все действия пользователей фиксируются с указанием времени, роли и действия (audit log)

-- Валидация входных данных; мониторинг аномалий

Развёртывание on-premise: вся система размещается на внутреннем сервере Заказчика. Данные не покидают периметр компании. К LLM-провайдеру передаются только обезличенные контексты. Соответствие 152-ФЗ.

8. Требования к инфраструктуре

Инфраструктурные расходы оплачиваются Заказчиком отдельно. Приведённые цифры носят ориентировочный характер; фактические расходы фиксируются ежемесячно и выставляются отдельными счётами по согласованию сторон.

Статья В месяц
LLM API + AI-инструменты разработки ~30 000 ₽
Сервер для разработки (если нет собственного) ~12 500 ₽

При наличии собственного сервера Заказчика статья «Сервер» не включается в расчёт.

Минимальные требования к production-серверу:

-- OpenSearch: 16 GB RAM, 4 CPU, SSD 200+ GB

-- RAGflow + агентный слой: 8 GB RAM, 4 CPU, SSD 100+ GB (GPU рекомендуется для embedding)

-- ОС: Linux (Ubuntu 22.04+)

10. Обязательства сторон

Исполнитель обязуется:

-- Выполнить работы в соответствии с настоящим ТЗ в установленные сроки

-- По завершении каждого этапа предоставить акт приёмки с описанием выполненных работ

-- Обеспечить конфиденциальность данных Заказчика

-- Провести обучение пользователей и предоставить инструкции в рамках Этапа 3

-- Реализовать агенты базы знаний в соответствии с Функциональными требованиями и Схемой КРАБ, предоставленной Заказчиком

Заказчик обязуется:

-- Предоставить доступ к API Grace CRM, схеме и данным MS SQL

-- Выделить ответственного представителя для участия в согласованиях на Этапе 0

-- Предоставить Схему КРАБ (структура блоков, форматы страниц, правила Ingest) до начала Этапа 2

-- Обеспечить production-сервер, удовлетворяющий требованиям раздела 8

-- Обеспечить доступ к тестовым данным для настройки и тестирования OpenSearch-индексов

-- Производить оплату в соответствии с графиком платежей

11. Порядок приёмки работ

По завершении каждого этапа Исполнитель направляет Заказчику уведомление о готовности и акт приёмки. Заказчик в течение 3 (трёх) рабочих дней проверяет результаты на соответствие критериям приёмки (раздел 6) и подписывает акт либо направляет мотивированный отказ. Исполнитель устраняет замечания в согласованные сроки. Приёмка Этапа 3 завершает выполнение всех работ по настоящему ТЗ.

Приложение №1 к Договору 04-002 · Версия 2.2 · апрель 2026 · Наполнение базы знаний и методология -- в рамках смежного консалтингового проекта.

Акт сдачи-приёмки работ № 1

Акт №1 и приложения: архитектура, API-слой, индексы OpenSearch, RBAC, реестр критических данных, карточки агентов.

Акт сдачи-приёмки работ № 1

Акт сдачи-приёмки работ № 1

Этап 0 «Исследование и архитектура»

Приложение №1 к Договору №04-002 от 24.04.2026 об оказании услуг между ООО «Экобанкинг» и ООО «АйТек»

г. Москва «» _____ 2026 г.

ООО «Экобанкинг» (далее -- Исполнитель) в лице __, действующего на основании __, с одной стороны,

и

ООО «АйТек» (далее -- Заказчик) в лице __, действующего на основании __, с другой стороны,

совместно именуемые «Стороны», составили настоящий Акт о нижеследующем.

1. Предмет акта

В соответствии с Договором №04-002 от 24.04.2026 и Техническим заданием (Приложение №1) Исполнитель выполнил, а Заказчик принимает результаты работ по Этапу 0 «Исследование и архитектура» в рамках проекта «Разработка и внедрение мультиагентной AI-системы Grace CRM Assistant для отдела продаж ООО „АйТек"».

2. Состав выполненных работ

В рамках Этапа 0 Исполнителем выполнены следующие работы и подготовлены соответствующие документы.

2.1 Исследование API Grace CRM и схемы данных

Исполнителем проведено исследование REST API системы Grace CRM (grace.i-tech.su), включая:

Результат: зафиксирована модель данных Grace CRM, достаточная для проектирования агентов и схемы синхронизации.

2.2 Проектирование индексов OpenSearch

Спроектирована и развёрнута структура из 15 индексов OpenSearch, обеспечивающая поисковый и аналитический слой системы.

Документ: 01_opensearch_schema.md

Группа Индексы
Контур продаж (Sales AI) itech_projects, itech_accounts, itech_calculations, itech_orders, itech_order_items, itech_comments, itech_contacts, itech_properties, itech_expected_payments, itech_users
Продуктовый каталог itech_nomenclatures, itech_calc_nomenclatures, itech_bom_components, itech_purchase_items
Управление разработкой itech_digital_requests

Для каждого индекса определены: маппинг полей, типы данных, анализаторы (ru_standard, standard), правила фильтрации, связи между индексами.

Текущее состояние: OpenSearch развёрнут, все 15 индексов наполнены данными (~225 000 документов), OpenSearch Dashboards доступны по адресу http://localhost:5601.

2.3 Архитектура агентов обоих контуров

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

Документ: 00_architecture.md

Контур 1 -- Sales AI (Grace CRM Assistant):

Агент Продукт
Sync Agent Актуальный поисковый образ данных CRM в OpenSearch
Quality Agent Ежедневный реестр проектов с критическими пробелами данных
Recommendation Agent Конкретный следующий шаг по каждому активному проекту
Notification Agent Адресное уведомление через Mattermost (осн.) / Telegram (резерв)
Orchestrator Бесперебойная работа агентной системы как единого целого

Контур 2 -- Knowledge AI (база знаний):

Агент Продукт
Ingest Agent Проиндексированный документ в RAGflow с метаданными
Query Agent Контекстный ответ с цитатой из источника за ≤ 5 секунд
Lint Agent Еженедельный отчёт о противоречиях и устаревших данных

Для каждого агента зафиксированы: входные данные, индексы OpenSearch, формат выходного продукта, критерии качества.

2.4 Схема интеграции Grace CRM -> OpenSearch

Спроектирована схема синхронизации данных из Grace CRM в OpenSearch через Sync Agent.

Документ: 02_integration_schema.md

Схема включает:

2.5 Спецификация API-слоя для внешних систем

Разработана спецификация API-слоя Grace CRM Assistant для интеграции с внешними системами (BI, ERP, 1С).

Документ: 03_api_spec.md

Спецификация включает:

2.6 Ролевая модель (RBAC)

Разработана ролевая модель системы для контуров Sales AI и Knowledge AI.

Документ: 04_rbac.md

Модель включает:

2.7 Выбор фреймворка и архитектура агентов базы знаний

Зафиксирован выбор технологического стека для реализации системы.

Зафиксировано в: 00_architecture.md, раздел 5

Компонент Технология Обоснование
Агентный фреймворк Agno Нативная поддержка Teams, on-premise, совместимость с RAGflow через tool API
LLM основной OpenAI GPT-4o / GPT-4o-mini Function calling, высокое качество рассуждения
LLM резервный GigaChat / YandexGPT Fallback без изменения логики агентов
База знаний RAGflow Self-hosted, гибридный поиск, граф знаний, on-premise
Поисковый слой OpenSearch 2.13 15 индексов CRM, развёрнут и наполнен
Коммуникации Mattermost (осн.) + Telegram (резерв) Adapter pattern, канал per-user
Деплой Docker Compose On-premise, инфраструктура I-TECH

2.8 Работающее окружение для разработки

Развёрнуто и передано Заказчику рабочее окружение для начала Этапа 1:

Компонент Статус Адрес
OpenSearch 2.13 ✅ Работает http://localhost:9200
OpenSearch Dashboards ✅ Работает http://localhost:5601
RAGflow ✅ Развёрнут http://localhost:9380
ETL-скрипт (Grace CRM -> OpenSearch) ✅ Готов scripts/mysql_to_opensearch.py
15 индексов OpenSearch ✅ Наполнены ~225 000 документов

3. Соответствие требованиям ТЗ

Требование Этапа 0 (ТЗ, раздел 6) Выполнено Документ
Исследование API Grace CRM и схемы MS SQL ✅ 00_architecture.md, раздел 3
Проектирование индексов OpenSearch ✅ 01_opensearch_schema.md
Архитектура агентов обоих контуров ✅ 00_architecture.md, раздел 4
Выбор фреймворка агентов базы знаний ✅ 00_architecture.md, раздел 5
Ролевая модель (агенты продаж + база знаний) ✅ 04_rbac.md
Схема интеграции (коннектор, периодичность, конфликты) ✅ 02_integration_schema.md
Спецификация API-слоя для внешних систем ✅ 03_api_spec.md
Работающее окружение для разработки ✅ Артефакт (п. 2.8 настоящего Акта)
Согласование Подписание настоящего Акта --

4. Открытые вопросы, перенесённые на Этап 1

Следующие вопросы выявлены в ходе Этапа 0 и требуют уточнения или реализации в рамках Этапа 1:

# Вопрос Ответственный
1 Поддержка webhooks в API Grace CRM -- уточнить у разработчика Grace Заказчик
2 Лимиты запросов (rate limit) API Grace CRM -- получить от разработчика Grace Заказчик
3 Финальная формула расчёта Кк и веса для каждой проверки -- утвердить у РОПа и Зам. ГД Заказчик
4 Конкретный сервер / инфраструктура для production-деплоя Заказчик
5 Список ответственных по ролям (knowledge_manager, admin) Заказчик

5. Стоимость и оплата

В соответствии с Договором №04-002 от 24.04.2026 стоимость работ по Этапу 0 составляет:

__ рублей __ копеек (__ руб. коп.), в том числе НДС %: ____________ рублей.

Оплата производится в порядке, предусмотренном Договором.

6. Заключение

Стороны подтверждают, что работы по Этапу 0 «Исследование и архитектура» выполнены Исполнителем в полном объёме, в соответствии с требованиями Технического задания и с надлежащим качеством.

Заказчик претензий по объёму, качеству и срокам выполненных работ не имеет.

Настоящий Акт составлен в двух экземплярах, имеющих равную юридическую силу, -- по одному для каждой из Сторон.

7. Подписи сторон
ИСПОЛНИТЕЛЬ ЗАКАЗЧИК
ООО «Экобанкинг» ООО «АйТек»
_____________ _____________
(подпись) (подпись)
_____________ _____________
(ФИО, должность) (ФИО, должность)
М.П. М.П.

Приложения к настоящему Акту

  1. 00_architecture.md -- Техническое описание архитектуры Grace CRM Assistant

  2. 01_opensearch_schema.md -- Схема индексов OpenSearch

  3. 02_integration_schema.md -- Схема интеграции Grace CRM -> OpenSearch

  4. 03_api_spec.md -- Спецификация API-слоя для внешних систем

  5. 04_rbac.md -- Ролевая модель (RBAC)

  6. 05_agent_cards.md -- Карточки агентов (продуктовый подход)

Акт сдачи-приёмки работ № 1

Техническое описание архитектуры — Grace CRM Assistant

Версия: 1.0 Дата: 4 мая 2026

Статус: Этап 0 -- согласование файл 00_architecture.md

Проект: Мультиагентная AI-система для отдела продаж I-TECH

1. Назначение системы

Grace CRM Assistant -- мультиагентная AI-система, развёртываемая поверх корпоративной CRM Grace (grace.i-tech.su). Система выполняет advisory-функцию: анализирует данные CRM, контролирует качество данных, формирует рекомендации менеджерам, обеспечивает управленческий контроль -- не нарушая принципа Grace CRM = source of truth.

Все изменения в CRM производятся только через API Grace. Система не имеет прямого доступа к базе данных MySQL.

2. Состав системы

Система включает два функциональных контура.

Контур 1 -- Sales AI (Grace CRM Assistant)

Агент Наименование Продукт агента
Sync Agent Агент синхронизации Актуальный поисковый образ данных CRM в OpenSearch
Quality Agent Агент контроля качества Реестр проектов с критическими пробелами данных
Recommendation Agent Агент рекомендаций Конкретный следующий шаг по каждому активному проекту
Notification Agent Агент уведомлений Доставленное уведомление с подтверждённой реакцией
Orchestrator Оркестратор Бесперебойная работа агентной системы как единого целого

Контур 2 -- Knowledge AI (база знаний)

Агент Наименование Продукт агента
Ingest Agent Агент загрузки знаний Проиндексированный документ в RAGflow с метаданными
Query Agent Агент поиска знаний Контекстный ответ с цитатой из источника
Lint Agent Агент аудита знаний Отчёт о противоречиях и устаревших данных в базе знаний

3. Архитектура решения

3.1 Общая схема

┌─────────────────────────────────────┐
│         Grace CRM (MySQL)           │
│         source of truth             │
└──────────────┬──────────────────────┘
               │ API (REST)
               │ CLI-синхронизация
               ▼
┌──────────────────────────────────────┐
│           Sync Agent                 │
│         (Agno framework)             │
└──────┬──────────────────┬────────────┘
       │                  │
       ▼                  ▼
┌─────────────┐    ┌──────────────────┐
│  OpenSearch │    │     RAGflow      │
│  (15 индек- │    │  (база знаний,   │
│   сов CRM)  │    │   векторный      │
└──────┬──────┘    │   поиск)         │
       │           └──────┬───────────┘
       └────────┬──────────┘
                ▼
┌───────────────────────────────────────┐
│          Orchestrator (Agno)          │
│     управление, приоритизация, SLA    │
└──────┬───────────────┬────────────────┘
       │               │
       ▼               ▼
┌────────────┐  ┌─────────────────┐
│  Quality   │  │ Recommendation  │
│   Agent    │  │     Agent       │
└─────┬──────┘  └───────┬─────────┘
      │                 │
      └────────┬─────────┘
               ▼
┌──────────────────────────────────────┐
│          Notification Agent          │
│  Mattermost (основной) / Telegram    │
│  adapter pattern, канал per-user     │
└──────────────────────────────────────┘

3.2 Слой данных

Слой Система Роль
Источник Grace CRM (MySQL) Source of truth для операционных данных
Поисковый OpenSearch (15 индексов) Быстрый доступ, аналитика, downstream для агентов
Семантический RAGflow База знаний, векторный поиск, RAG

3.3 Ключевые принципы архитектуры

4. Описание агентов -- продуктовый подход

Каждый агент описывается через продуктовую формулу:

Продукт × Внутренний клиент × Триггер × Критерий выполнения

4.1 Sync Agent -- Агент синхронизации

Продукт: Актуальный поисковый образ данных Grace CRM в OpenSearch -- гарантирующий, что любой запрос от downstream-агентов отражает реальное состояние CRM на момент последнего запуска.

Параметр Содержание
Внутренний клиент Quality Agent, Recommendation Agent
Механизм CLI -> API Grace CRM -> трансформация -> bulk index в OpenSearch
Триггер Cron по расписанию + ручной запуск администратором
Входные данные API Grace CRM: projects, activities, clients, tasks, comments, calculations, orders, users, objects
Выходной продукт Обновлённые индексы OpenSearch (15 индексов)
Критерий выполнения Все индексы обновлены без ошибок; расхождение Grace CRM / OpenSearch = 0 по завершении синхронизации

Режимы работы:

Режим Триггер Что синхронизируется
Инкрементальный Cron каждые N минут Изменения с последнего запуска (параметр updated_since)
Полный Ночной cron / ручной запуск администратором Все сущности, полная пересборка индексов

Входные данные (API endpoints):

GET /api/projects?updated_since=timestamp
GET /api/projects/{id}
GET /api/activities?updated_since=timestamp
GET /api/clients?updated_since=timestamp
GET /api/clients/{id}
GET /api/tasks?updated_since=timestamp
GET /api/comments?entity_type=&entity_id=
GET /api/calculations?updated_since=timestamp
GET /api/orders?updated_since=timestamp
GET /api/users
GET /api/objects?updated_since=timestamp

Красный флаг: ошибка синхронизации -> downstream-агенты работают на устаревших данных -> все рекомендации невалидны.

4.2 Quality Agent -- Агент контроля качества данных

Продукт: Ежедневный реестр проектов с критическими пробелами данных -- для менеджеров и РОПа -- с указанием конкретного поля, ответственного и срока устранения.

Параметр Содержание
Внутренний клиент 1 Менеджер -- задача на заполнение по своим проектам
Внутренний клиент 2 РОП -- сводка по команде, эскалация при просрочке
Триггер Ежедневно в 09:00 + при изменении статуса проекта
Входные данные OpenSearch: itech_projects, itech_calculations, itech_activities; правила проверки из конфига
Выходной продукт Структурированный реестр: проект -> пробел -> ответственный -> срок; сигнал в Notification Agent
Критерий выполнения Доля проектов с полными данными ≥ 85%; каждый пробел имеет назначенного ответственного

Правила проверки (настраиваются в конфиге):

Проверка Поле Условие
Обязательные поля account_id, property_id, project_status_id, probability_new, forecast_date Не пусто
Следующий шаг next_action, next_action_date Заполнено и дата не в прошлом
Логика статусов calculation_status При статусе «КП выставлено» -- существует расчёт
Активность last_activity_at Не более 30 дней назад для активных проектов

4.3 Recommendation Agent -- Агент рекомендаций

Продукт: Конкретный следующий шаг по каждому активному проекту -- для менеджера -- сформулированный на основе истории CRM и базы знаний RAGflow, доставляемый не позднее 2 часов после изменения статуса или по запросу.

Параметр Содержание
Внутренний клиент Менеджер (первично); РОП (при просрочке реакции)
Триггер Изменение статуса проекта / запрос менеджера / просрочка контакта
Входные данные OpenSearch (itech_projects, itech_calculations, itech_comments, itech_accounts); RAGflow (кейсы, скрипты, возражения)
Выходной продукт Рекомендация: действие + срок + обоснование + ссылка на кейс из базы знаний
Критерий выполнения Менеджер знает следующий шаг по каждому активному проекту; нет проектов без зафиксированного следующего действия

Формат рекомендации:

Проект: [название] | Клиент: [название] | Стадия: [статус]Последний контакт: N дней назад​Рекомендация: [конкретное действие]Срок: [дата]Обоснование: [краткое обоснование]Похожий кейс: [ссылка из базы знаний]

4.4 Notification Agent -- Агент уведомлений

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

Параметр Содержание
Внутренний клиент Менеджер / РОП / Зам. ГД -- в зависимости от типа события
Триггер Сигнал от любого агента системы
Входные данные Сигнал от агента + профиль получателя (предпочтительный канал)
Выходной продукт Доставленное уведомление с подтверждённой реакцией
Механизм доставки Adapter pattern: Mattermost (основной) / Telegram (резерв), канал настраивается per-user
Критерий выполнения Реакция в течение N часов; при отсутствии реакции -- эскалация в Orchestrator

Матрица маршрутизации уведомлений:

Событие Получатель Приоритет
Пробел в данных по своему проекту Менеджер Нормальный
Просрочка реакции менеджера > SLA РОП Высокий
Рекомендация по проекту Менеджер Нормальный
Критическое событие (крупная сделка, риск ухода) РОП, Зам. ГД Высокий
Сводка по команде РОП Ежедневный

4.5 Orchestrator -- Оркестратор

Продукт: Бесперебойная работа агентной системы как единого целого -- обеспечивающая, что ни одно критическое событие не теряется и каждый сигнал доходит до нужного человека в нужное время.

Параметр Содержание
Внутренний клиент РОП, Зам. ГД
Триггер Постоянно -- реагирует на сигналы всех агентов
Входные данные Сигналы от всех агентов; SLA-параметры из конфига
Выходной продукт Гарантия непрерывности потока сигналов; каждое событие имеет назначенного ответственного
Критерий выполнения Отсутствие потерянных эскалаций; система работает без ручного вмешательства

4.6 Ingest Agent -- Агент загрузки знаний

Продукт: Проиндексированный документ в RAGflow с корректными метаданными -- готовый к поиску Query Agent.

Параметр Содержание
Внутренний клиент Query Agent, Recommendation Agent
Триггер Загрузка нового документа ответственным за базу знаний
Входные данные Документ (PDF, DOCX, MD) + метаданные: отрасль, тип клиента, стадия сделки, продукт, теги
Выходной продукт Проиндексированная запись в RAGflow; обновлённый граф связей
Критерий выполнения Документ доступен для поиска; метаданные заполнены полностью

4.7 Query Agent -- Агент поиска знаний

Продукт: Контекстный ответ с цитатой из источника -- для менеджера -- за ≤ 5 секунд.

Параметр Содержание
Внутренний клиент Менеджер, Recommendation Agent
Триггер Запрос менеджера / вызов от Recommendation Agent
Входные данные Текстовый запрос + контекст проекта
Выходной продукт Ответ + цитата + ссылка на источник
Критерий выполнения Релевантный ответ ≤ 5 сек; источник всегда указан

4.8 Lint Agent -- Агент аудита знаний

Продукт: Еженедельный отчёт о противоречиях, устаревших данных и логических разрывах в базе знаний.

Параметр Содержание
Внутренний клиент Ответственный за базу знаний
Триггер Еженедельно
Входные данные Все документы в RAGflow
Выходной продукт Отчёт: список противоречий, устаревших фактов, незаполненных разделов
Критерий выполнения Выявлены все документы старше 6 месяцев и документы с конфликтующими утверждениями

5. Технологический стек

Слой Технология Роль
Агентный фреймворк Agno Агенты, Teams, оркестрация
LLM (основной) OpenAI GPT-4o / GPT-4o-mini Рассуждение, генерация рекомендаций
LLM (резерв) GigaChat / YandexGPT Fallback при недоступности OpenAI
Поисковый слой OpenSearch 2.13 15 индексов CRM, аналитика
База знаний RAGflow Семантический поиск, RAG, граф знаний
Коммуникации Mattermost (основной) + Telegram (резерв) Доставка уведомлений, adapter pattern
Синхронизация CLI + Agno Agent Grace CRM API -> OpenSearch
Планировщик Cron / systemd timer Расписание синхронизации и агентов
Деплой Docker Compose On-premise, I-TECH инфраструктура

Выбор фреймворка агентов базы знаний

Для контура Knowledge AI выбран RAGflow как платформа базы знаний по следующим основаниям:

Критерий RAGflow
Развёртывание Self-hosted, on-premise -- соответствует требованиям I-TECH
Поиск Гибридный: semantic + full-text
Граф знаний Поддерживается нативно
Интеграция с Agno Через REST API -- Agno вызывает RAGflow как tool
Мультиформатность PDF, DOCX, MD, TXT

Агенты контура Knowledge AI реализованы на Agno и взаимодействуют с RAGflow через его REST API как с внешним инструментом (tool call). Прямой встройки RAGflow в агентный фреймворк не требуется.

6. Цепочка данных (основной сценарий)

Grace CRM (MySQL)    ↓  CLI → APISync Agent    ↓  bulk indexOpenSearch (15 индексов)    ↓  запрос агентовQuality Agent → реестр пробелов → Notification Agent → Mattermost/Telegram → МенеджерRecommendation Agent → рекомендация → Notification Agent → Mattermost/Telegram → Менеджер    ↑RAGflow (база знаний) — контекст для рекомендаций

7. Что остаётся за рамками Этапа 0

Тема Этап
Калькулятор премии (Кк) Этап 1
Telegram-бот (UI) Этап 2
Полная интеграция RAGflow + Ingest/Query/Lint агентов Этап 2
Интеграция с 1С ЕРП Этап 3

8. Программа и методика приёмо-сдаточных испытаний (ПМИ)

8.1 Общие принципы

ПМИ фиксирует проверку каждого функционального блока системы на соответствие требованиям Этапа 0.

Формат тест-кейса:

8.2 ПМИ -- Sync Agent

TC-SA-01 -- Инкрементальная синхронизация

TC-SA-02 -- Полная синхронизация

8.3 ПМИ -- Quality Agent

TC-QA-01 -- Обнаружение пробелов

TC-QA-02 -- SLA-эскалация

8.4 ПМИ -- Recommendation Agent

TC-RA-01 -- Генерация рекомендации

8.5 ПМИ -- Notification Agent

TC-NA-01 -- Доставка уведомления

8.6 ПМИ -- API

TC-API-01 -- Получение проектов

8.7 ПМИ -- Knowledge AI

TC-KB-01 -- Поиск

9. Прототипы дашбордов OpenSearch Dashboards

9.1 Общие требования

9.2 Дашборд «Менеджер»

Фильтры: период, стадия, тип клиента

Виджеты:

9.3 Дашборд «РОП»

Фильтры: менеджер, период, стадия, тип клиента

Виджеты:

9.4 Дашборд «Зам. ГД»

Виджеты:

Дополнительно:

10. Развёртывание и инфраструктура

10.1 Сервер

10.2 Размещение компонентов

Компонент Размещение
OpenSearch Docker container
RAGflow Docker container
Agno Agents Docker container
API Layer Docker container
Mattermost Внешний / контейнер

10.3 Требования к ресурсам

10.4 Сеть и доступ

10.5 Запуск (базовый)

docker-compose up -d

10.6 Резервное копирование

10.7 Мониторинг

Акт сдачи-приёмки работ № 1

Спецификация API-слоя — Grace CRM Assistant

Версия: 1.0 Дата: 4 мая 2026

Статус: Этап 0 -- согласование файл 03_api_spec.md

1. Назначение

API-слой Grace CRM Assistant предоставляет интерфейс для:

Все эндпоинты доступны только на внутренней сети. Публичного доступа нет.

2. Базовые параметры

Параметр Значение
Base URL http://grace-ai.i-tech.local/api/v1
Протокол HTTP/HTTPS (TLS 1.3 внутри периметра)
Формат JSON
Аутентификация Bearer Token (JWT)
Версионирование URI (/v1/, /v2/)

Заголовки запроса

Authorization: Bearer {token}Content-Type: application/jsonAccept: application/json

Стандартный формат ответа

{  "success": true,  "data": { ... },  "meta": {    "total": 100,    "page": 1,    "per_page": 20  }}

Стандартный формат ошибки

{  "success": false,  "error": {    "code": "UNAUTHORIZED",    "message": "Токен недействителен или истёк"  }}

3. Аутентификация и авторизация

3.1 Получение токена

POST /api/v1/auth/tokenContent-Type: application/json​{  "client_id": "erp-system",  "client_secret": "***"}

Ответ:

{  "access_token": "eyJ...",  "expires_in": 3600,  "token_type": "Bearer"}

3.2 Матрица доступа по ролям

Группа эндпоинтов manager rop deputy_gd admin system
/projects -- свои проекты ✅ ✅ ✅ ✅ ✅
/projects -- все проекты ❌ ✅ ✅ ✅ ✅
/recommendations ✅ ✅ ❌ ✅ ✅
/analytics/team ❌ ✅ ✅ ✅ ✅
/analytics/aggregate ❌ ❌ ✅ ✅ ✅
/sync/* ❌ ❌ ❌ ✅ ✅
/admin/* ❌ ❌ ❌ ✅ ❌

4. Эндпоинты -- данные CRM

4.1 Проекты / Сделки

GET /api/v1/projects

Параметры фильтрации:

Параметр Тип Описание
manager_id integer Фильтр по менеджеру
status string Статус проекта
probability_min integer Минимальная вероятность, %
updated_since ISO8601 Изменено после даты
page integer Страница (default: 1)
per_page integer Записей на странице (max: 100)

Ответ:

{  "success": true,  "data": [    {      "id": 15714,      "name": "ЖК Дмитровское небо",      "account_name": "КР ЭНЕРГО ООО",      "manager_name": "Пересунько Павел",      "project_status": "Отправлено КП",      "probability_percent": 65,      "amount": 91769410,      "forecast_date": "2026-06-30"    }  ],  "meta": { "total": 247, "page": 1, "per_page": 20 }}

GET /api/v1/projects/{id}

Возвращает полную карточку проекта включая историю комментариев и список расчётов.

4.2 Рекомендации

GET /api/v1/recommendations

Параметры:

Параметр Тип Описание
manager_id integer Рекомендации для менеджера
project_id integer Рекомендации по проекту
status string pending / acknowledged / done

Ответ:

{  "success": true,  "data": [    {      "id": "rec_001",      "project_id": 15714,      "project_name": "ЖК Дмитровское небо",      "account_name": "КР ЭНЕРГО ООО",      "action": "Позвонить клиенту и уточнить статус решения по КП",      "deadline": "2026-05-07",      "rationale": "Последний контакт 18 дней назад, КП на согласовании",      "knowledge_ref": "kb://cases/energo-jk-pattern",      "created_at": "2026-05-04T09:00:00",      "status": "pending"    }  ]}

POST /api/v1/recommendations/{id}/acknowledge

Менеджер подтверждает получение рекомендации.

POST /api/v1/recommendations/{id}/done

Менеджер отмечает рекомендацию выполненной.

4.3 Аналитика

GET /api/v1/analytics/funnel

Воронка продаж с разбивкой по статусам и менеджерам.

Параметры: manager_id, date_from, date_to, group_by (manager / status / month)

GET /api/v1/analytics/data-quality

Коэффициент качества данных (Кк) по менеджерам и отделу.

Ответ:

{  "success": true,  "data": {    "team_kk": 0.82,    "managers": [      {        "manager_id": 12,        "manager_name": "Стегнина Мария",        "kk": 0.91,        "projects_total": 249,        "projects_with_gaps": 22      }    ]  }}

GET /api/v1/analytics/backlog

Сводка по backlog-позициям (незавершённые отгрузки).

5. Эндпоинты -- управление системой

5.1 Синхронизация (только role: admin, system)

POST /api/v1/sync/runContent-Type: application/json​{  "mode": "incremental",  "entities": ["projects", "orders"]}

Ответ:

{  "success": true,  "data": {    "run_id": "sync_2026_05_04_090000",    "status": "started",    "estimated_duration_sec": 25  }}

GET /api/v1/sync/status/{run_id}

Статус текущего или последнего запуска синхронизации.

GET /api/v1/sync/history

История запусков синхронизации (последние 30).

5.2 Состояние системы

GET /api/v1/health

Доступен без авторизации. Возвращает статус всех компонентов.

{  "status": "healthy",  "components": {    "opensearch": "healthy",    "ragflow": "healthy",    "grace_api": "healthy",    "sync_agent": "healthy",    "last_sync": "2026-05-04T08:45:00"  }}

GET /api/v1/metrics

Метрики системы для мониторинга (только admin).

6. Эндпоинты -- база знаний

GET /api/v1/knowledge/search

Поиск по базе знаний (через RAGflow).

Параметры: q (текст запроса), industry, deal_stage, product_type

Ответ:

{  "success": true,  "data": {    "answer": "По данному типу клиента рекомендуется...",    "sources": [      {        "id": "kb_case_001",        "title": "Кейс: ЦОД-проект, застройщик",        "excerpt": "...",        "relevance": 0.92      }    ]  }}

POST /api/v1/knowledge/documents

Загрузка нового документа в базу знаний (только role: knowledge_manager, admin).

7. Коды ошибок

Код HTTP Описание
UNAUTHORIZED 401 Токен отсутствует или недействителен
FORBIDDEN 403 Недостаточно прав для операции
NOT_FOUND 404 Ресурс не найден
VALIDATION_ERROR 422 Ошибка валидации параметров
RATE_LIMITED 429 Превышен лимит запросов
INTERNAL_ERROR 500 Внутренняя ошибка сервера
SERVICE_UNAVAILABLE 503 Компонент системы недоступен

8. Лимиты

Параметр Значение
Rate limit 100 запросов / минуту на токен
Максимум записей в ответе 100 (per_page)
Максимальный размер тела запроса 10 МБ
Таймаут 30 секунд
Акт сдачи-приёмки работ № 1

Схема индексов OpenSearch — Grace CRM Assistant

Версия: 2.0 Дата: 22 июля 2026 (актуализация по проду)

Источник: OpenSearch http://localhost:9200 файл 01_opensearch_schema.md

Всего индексов: 31

1. Назначение слоя OpenSearch

OpenSearch является поисковым и аналитическим слоем системы. Данные поступают из Grace CRM через Sync Agent и хранятся в виде денормализованных витрин, оптимизированных под сценарии работы AI-агентов.

Ключевые принципы:

2. Индексы контура Sales AI

2.1 itech_projects -- Сделки (Opportunities)

Центральный индекс воронки продаж. Используется Quality Agent и Recommendation Agent.

Поле Тип Описание
id integer PK
number keyword Номер сделки
name text + .keyword ru_standard
account_id integer -> itech_accounts.id
account_name text + .keyword ru_standard
manager_id integer
manager_name text + .keyword standard
engineer_user_id integer
engineer_name text + .keyword standard
property_id integer -> itech_properties.id
property_name text + .keyword ru_standard
project_status_id integer
project_status text + .keyword standard
probability_new keyword Вероятность (категория)
probability_percent integer Вероятность, %
amount double Сумма сделки
type_of_calculation keyword Тип тендера
forecast_date date Прогнозная дата закрытия
refusal_reason text Причина отказа, ru_standard
created_at date
created_year integer

Правила фильтрации для агентов:

2.2 itech_accounts -- Контрагенты

Поле Тип Описание
id integer PK
name text + .keyword ru_standard
inn keyword ИНН
reliability keyword red / yellow / green / black / blue
manager_id integer
manager_name text + .keyword standard
assistant_user_id integer
is_prepayment_only boolean Только предоплата
order_count integer Кол-во заказов
project_count integer Кол-во сделок
revenue_mln float Выручка, млн руб.
paid_mln float Оплачено, млн руб.
debt_mln float Долг, млн руб.
last_order_at date Дата последнего заказа
sectors keyword Отраслевые сектора
top_properties keyword Топ объекты
created_at date

2.3 itech_calculations -- КП / Расчёты

Поле Тип Описание
id integer PK
project_id integer -> itech_projects.id
project_name text + .keyword ru_standard
account_id integer
account_name text + .keyword ru_standard
manager_id integer
manager_name text + .keyword standard
engineer_user_id integer
engineer_name text + .keyword standard
calculation_status_id integer
calculation_status text + .keyword standard
amount double Сумма КП
type keyword Тип расчёта
quality keyword Точный / Бюджетная оценка
is_urgent boolean Срочный
due_date date Срок выполнения
kp_exposed_at date Дата выставления КП
completed_at date
created_at date

2.4 itech_orders -- Заказы (шапки)

Поле Тип Описание
id integer PK
order_number keyword Номер заказа
account_id integer
account_name text + .keyword ru_standard
manager_id integer
manager_name text + .keyword standard
project_id integer -> itech_projects.id
total_cost double Итоговая стоимость
general_purchase double Себестоимость
is_shipped boolean Отгружен
bill_type keyword Тип счёта
run_date date Дата запуска в производство
shipping_date_plan date Плановая дата отгрузки
shipping_date_fact date Фактическая дата отгрузки
created_at date

2.5 itech_order_items -- Позиции заказов

Поле Тип Описание
id integer PK
order_id integer -> itech_orders.id
order_number keyword
name text + .keyword standard
article keyword Артикул
amount double Сумма с НДС
amount_wo_vat double Сумма без НДС
purchase_plan double Плановая себестоимость
profit_amount double Прибыль
hours_plan double Плановые часы
is_shipped boolean
shipping_date_plan date
shipping_date_fact date NULL = позиция в backlog
created_at date

2.6 itech_comments -- Комментарии

Поле Тип Описание
id long PK
commentable_type keyword Тип объекта (Project / Calculation / ...)
commentable_id integer ID объекта
author_id integer
author_name text + .keyword standard
project_id integer -> itech_projects.id
project_name text + .keyword ru_standard
project_status keyword Статус на момент комментария
account_name text + .keyword standard
manager_name text + .keyword standard
comment text + .keyword Текст, ru_standard
created_at date

2.7 itech_contacts -- Контактные лица

Поле Тип Описание
id integer PK
full_name text + .keyword ru_standard
job_title text + .keyword Должность
phones keyword Массив телефонов
emails keyword Массив email
is_priority boolean
accounts nested Связанные контрагенты
└ account_id integer
└ account_name text + .keyword
created_at date

⚠️ accounts -- nested-тип. Обязательно использовать nested query при фильтрации.

2.8 itech_properties -- Строительные объекты

Поле Тип Описание
id integer PK
name text + .keyword ru_standard
address_full text + .keyword ru_standard
city keyword
region keyword
property_type keyword Тип объекта
sector keyword Отрасль
account_count integer Кол-во контрагентов
project_count integer Кол-во сделок
top_account keyword Основной контрагент
created_at date

2.9 itech_expected_payments -- Ожидаемые платежи

Поле Тип Описание
id text + .keyword PK
order_id integer -> itech_orders.id
order_number keyword
exp_payment_status keyword Статус платежа
pay_amount double Ожидаемая сумма
paid_amount double Оплаченная сумма
pay_date date Ожидаемая дата
paid_date date Фактическая дата
created_at date

2.10 itech_users -- Пользователи системы

Поле Тип Описание
id integer PK
full_name text + .keyword ru_standard
email keyword
title keyword Должность
department text + .keyword standard
roles keyword Массив ролей
is_active boolean
created_at date

3. Индексы продуктового каталога

3.1 itech_nomenclatures -- Мастер-каталог

Поле Тип Описание
id integer PK
name text + .keyword ru_standard
article keyword Артикул
brand text + .keyword Бренд
created_at date

3.2 itech_calc_nomenclatures -- Расчётная номенклатура

Поле Тип Описание
article keyword PK
name text + .keyword ru_standard
price float Нормативная цена
assembly_time float Норма времени сборки, ч
weight float Масса, кг
body_type keyword Тип корпуса
body_width / body_height / body_depth integer Габариты, мм
body_ip integer Степень защиты IP
rated_in float Номинальный ток, А
icu float Ток отключения, кА

3.3 itech_bom_components -- BOM-спецификации

Поле Тип Описание
id integer PK
calculation_id integer -> itech_calculations.id
project_id integer -> itech_projects.id
article keyword Артикул компонента
quantity double Количество
cost double Стоимость
currency keyword Валюта

3.4 itech_purchase_items -- Позиции закупок

Поле Тип Описание
id integer PK
nomenclature_id integer -> itech_nomenclatures.id
nomenclature_name text + .keyword ru_standard
article keyword
quantity integer Запрошено
received_quantity integer Получено
desired_delivery_date date
created_at date

3.5 itech_digital_requests -- ИТ-задачи

Поле Тип Описание
id integer PK
name text + .keyword ru_standard
status keyword Статус
importance keyword Важность
department_name text + .keyword Отдел-заказчик
plan_date_end_development date Плановая дата завершения
fact_date_end_development date Фактическая дата
created_at date

4. Схема связей между индексами

itech_projects ──── account_id ────► itech_accountsitech_projects ──── property_id ───► itech_propertiesitech_projects ──── manager_id ────► itech_users​itech_calculations ── project_id ──► itech_projectsitech_orders ──────── project_id ──► itech_projectsitech_order_items ─── order_id ────► itech_ordersitech_expected_payments ─ order_id ► itech_orders​itech_comments ──── project_id ────► itech_projectsitech_contacts ──── accounts[] ────► itech_accounts (nested)​itech_bom_components ── calculation_id ► itech_calculationsitech_purchase_items ─── nomenclature_id ► itech_nomenclatures

5. Правила использования агентами

Агент Индексы Операции
Sync Agent Все 15 Запись (bulk index)
Quality Agent itech_projects, itech_calculations, itech_accounts Чтение, агрегации
Recommendation Agent itech_projects, itech_accounts, itech_comments, itech_calculations, itech_contacts Чтение, fulltext
Orchestrator itech_projects, itech_users Чтение

6. Индексы, добавленные после v1.0

Снято с живого OpenSearch (прод, сервер 147) 22 июля 2026. Схемы полей — из фактического _mapping индексов. Служебные поля _sync_source / _synced_at в таблицах опущены.

6.1 Операционный контур — новые itech_* (синк из Grace)

itech_contracts — Договоры с контрагентами (шапки)

Документов: 1 980

Поле Тип
account_id integer
approval_status keyword
approval_status_id integer
assistant_name keyword
assistant_user_id integer
contact_id integer
contract_end_date date
contract_start_date date
deadline date
id integer
manager_name keyword
manager_user_id integer
number keyword
project_id integer
signing_date date
status_id integer
type keyword

itech_contract_annexes — Приложения/спецификации к договорам

Документов: 2 986

Поле Тип
amount double
approval_status keyword
contract_id integer
currency_code keyword
id integer
number keyword
order_number keyword
project_id integer
signing_date date
start_date date
status_id integer
type keyword

itech_calculation_requests — Заявки на расчёт — входящая очередь инженерам

Документов: 22 745

Поле Тип
account_id integer
calculation_complexity integer
created_at date
description text + .keyword
end_desired date
end_plan date
engineer_name keyword
engineer_user_id integer
estimated_time float
id integer
is_priority integer
is_question integer
manager_id integer
manager_name keyword
probability_percent float
project_id integer
project_path keyword
property_id integer
start_plan date
status_id integer
type_of_calc_id integer
updated_at date

itech_calculation_remarks — Замечания к расчётам

Документов: 41

Поле Тип
author_name keyword
author_user_id integer
calculation_engineer_user_id integer
calculation_id integer
created_at date
engineer_name keyword
id integer
project_id integer
remark text + .keyword

itech_services_requests — Сервисные заявки (внутренние закупки/услуги)

Документов: 4 503

Поле Тип
account_id integer
approval_status_id integer
category text + .keyword
cost long
created_at date
department_id integer
department_name text + .keyword
executor_name text + .keyword
expenditure_item_id integer
id integer
order_number keyword
purpose text + .keyword
recipient_name text + .keyword
status_id integer

itech_object_registrations — Регистрации объектов за контрагентом (защита проекта)

Документов: 467

Поле Тип
account_id integer
contact_id integer
controller_name keyword
controller_user_id integer
created_at date
id integer
property_id integer

itech_quality_managers — Снимки коэффициента качества Кк по менеджерам (витрина Quality Agent)

Документов: 41

Поле Тип
clean integer
gap_count integer
kk float
manager keyword
snapshot_date date
stale_count long
total integer
with_gaps integer

itech_activity_log — Журнал изменений сущностей (аудит воронки)

Документов: 15 868

Поле Тип
account_id integer
account_name text + .keyword
action keyword
amount double
causer_name text + .keyword
causer_user_id integer
changed_fields keyword
changes_text text
created_at date
created_year integer
engineer_name text + .keyword
engineer_user_id integer
entity_id integer
entity_type keyword
forecast_date date
id long
manager_name text + .keyword
manager_user_id integer
probability_percent float
project_id integer
status_id integer
status_name keyword

itech_reminders — Напоминания менеджерам (индекс создан, данных пока нет)

Документов: 0

Поле Тип
by_email boolean
by_grace boolean
by_telegram boolean
created_at date
entity_id integer
entity_type keyword
id integer
is_expired boolean
manager_id integer
manager_name text + .keyword
pre_notifications keyword
remind_date date
result text + .keyword
status keyword
text text + .keyword

6.2 Продуктовый каталог — itech_vendor_price_lists

Прайс-листы вендоров по артикулам — крупнейший индекс каталога.
Документов: 658 642

Поле Тип
article keyword
brand_id keyword
currency keyword
effective_date date
family text + .keyword
name text
price double
price_list_id keyword
source keyword
unit keyword
vendor keyword

6.3 Аналитический слой — витрины *_v1 (в v1.0 отсутствовал)

Считаются у нас (не синк из Grace): модель конверсии сделок (агент Quality) и поиск похожих проектов (агент Recommendation).

deal_conversion_training_v1 — Обучающая выборка модели конверсии сделок (признаки + метка converted)

Документов: 8 648

Поле Тип
account_id keyword
amount double
comment_avg_gap_days double
comment_count double
comment_distinct_authors double
comment_max_gap_days double
comment_span_days double
comments_before_forecast double
comments_per_week double
company_id keyword
complexity double
converted boolean
created_at date
created_year double
days_created_to_forecast double
days_forecast_to_first_order double
days_since_last_comment double
first_order_created_at date
first_order_id long
forecast_date date
important keyword
is_sales_plan keyword
label integer
manager_id keyword
manager_name keyword
probability_source keyword
probability_value double
project_age_days double
project_id long
project_name keyword
project_status keyword
project_status_id keyword
property_id keyword
sector keyword
type_of_calculation keyword

deal_conversion_predictions_v1 — Предсказания вероятности конверсии (модель против оценки менеджера)

Документов: 1 255

Поле Тип
as_of_date date
created_at date
features object
forecast_date date
manager_id keyword
manager_name keyword
manager_probability double
model_name keyword
predicted_probability double
probability_delta double
project_id long
project_name keyword
project_status keyword

project_similarity_embeddings_v1 — Эмбеддинги проектов (knn_vector: content + structured) для поиска похожих

Документов: 20 371

Поле Тип
account_id keyword
account_name text + .keyword
amount double
amount_log float
comment_count integer
comment_count_log float
comment_span_days float
comments_per_week double
content_embedding knn_vector
content_hash keyword
content_text text
created_at date
created_year integer
days_since_last_comment float
embedding_dimensions integer
embedding_model keyword
embedding_provider keyword
execution_days double
first_order_created_at date
first_order_id long
forecast_date date
forecast_horizon_days double
has_order boolean
has_order_value double
manager_id keyword
manager_name keyword
order_item_count integer
order_item_count_log float
probability double
project_age_days double
project_id long
project_name text + .keyword
project_status keyword
project_status_id keyword
property_id keyword
property_name text + .keyword
sector keyword
structured_vector knn_vector
type_of_calculation keyword

project_similarity_vectors_v1 — Векторы сходства проектов (knn_vector)

Документов: 20 356

Поле Тип
account_id keyword
account_name text + .keyword
amount double
amount_log float
comment_count integer
comment_count_log float
comment_span_days float
comments_per_week double
content_hash keyword
content_text text
content_vector knn_vector
created_at date
created_year integer
days_since_last_comment float
execution_days double
first_order_created_at date
first_order_id long
forecast_date date
forecast_horizon_days double
has_order boolean
has_order_value double
manager_id keyword
manager_name keyword
order_item_count integer
order_item_count_log float
probability double
project_age_days double
project_id long
project_name text + .keyword
project_status keyword
project_status_id keyword
property_id keyword
property_name text + .keyword
sector keyword
structured_vector knn_vector
type_of_calculation keyword

project_similarity_cards_v1 — Карточки проектов для выдачи похожих (токенизированные)

Документов: 20 353

Поле Тип
account_id keyword
account_name text + .keyword
amount double
amount_log double
created_at date
created_year integer
execution_days double
first_order_created_at date
first_order_id long
forecast_date date
forecast_horizon_days double
has_order boolean
manager_id keyword
manager_name keyword
order_item_count integer
probability double
project_age_days double
project_id long
project_name text + .keyword
project_status keyword
project_status_id keyword
property_id keyword
property_name text + .keyword
sector keyword
token_text text
tokens keyword
type_of_calculation keyword

project_similarity_comment_drafts_v1 — Черновики рекомендательных комментариев (nested similar_projects)

Документов: 426

Поле Тип
comment_text text
created_at date
draft_id keyword
send_result object
sent_at date
similar_projects nested
source keyword
status keyword
target_project_id long
target_project_name keyword
Акт сдачи-приёмки работ № 1

Схема интеграции Grace CRM → OpenSearch

Версия: 1.0 Дата: 4 мая 2026

Статус: Этап 0 -- согласование файл 02_integration_schema.md

1. Архитектура интеграции

Grace CRM (MySQL) не подключается к OpenSearch напрямую. Синхронизация осуществляется через Sync Agent -- Agno-агент, запускаемый по расписанию или вручную.

Grace CRM (MySQL)    │    │  REST API (GET-запросы)    ▼CLI-команда → Sync Agent (Agno)    │    │  Трансформация данных    │  (нормализация, денормализация, обогащение)    ▼OpenSearch (bulk index)    │    ├── itech_projects    ├── itech_accounts    ├── itech_calculations    ├── itech_orders    ├── itech_order_items    ├── itech_comments    ├── itech_contacts    ├── itech_properties    ├── itech_expected_payments    └── ... (15 индексов)

Важно: прямого доступа к MySQL Grace CRM у Sync Agent нет. Все данные получаются только через REST API Grace CRM.

2. Механизм запуска

2.1 CLI-команда

# Инкрементальная синхронизация (основной режим)grace-sync run --mode incremental​# Полная синхронизация (ночная / восстановление)grace-sync run --mode full​# Синхронизация конкретной сущностиgrace-sync run --entity projects --mode incremental​# Ручной запуск с указанием временного окнаgrace-sync run --mode incremental --since 2026-05-01T00:00:00

2.2 Расписание (cron)

Режим Расписание Описание
Инкрементальный Каждые 15 минут Основной рабочий режим
Полный Ежедневно в 02:00 Восстановление консистентности
Ручной По требованию администратора После миграций, исправлений

3. Сущности и endpoints API

Сущность Endpoint Индекс OpenSearch Частота
Сделки GET /api/projects?updated_since= itech_projects 15 мин
Контрагенты GET /api/clients?updated_since= itech_accounts 15 мин
Расчёты (КП) GET /api/calculations?updated_since= itech_calculations 15 мин
Заказы GET /api/orders?updated_since= itech_orders 15 мин
Позиции заказов GET /api/order_items?updated_since= itech_order_items 15 мин
Активности GET /api/activities?updated_since= itech_comments 15 мин
Задачи GET /api/tasks?updated_since= (в itech_projects) 15 мин
Контактные лица GET /api/contacts?updated_since= itech_contacts 1 час
Объекты GET /api/objects?updated_since= itech_properties 1 час
Платежи GET /api/expected_payments?updated_since= itech_expected_payments 1 час
Пользователи GET /api/users itech_users 1 раз/день

4. Режимы синхронизации

4.1 Инкрементальный режим

Принцип: запрашиваются только записи, изменённые с момента последней синхронизации.

1. Читаем last_sync_timestamp из хранилища состояния2. GET /api/{entity}?updated_since={last_sync_timestamp}3. Трансформируем полученные записи4. Bulk upsert в OpenSearch (upsert по id)5. Обновляем last_sync_timestamp = текущее время

Хранение состояния: файл sync_state.json или переменная окружения. Формат:

{  "projects": "2026-05-04T08:45:00",  "clients": "2026-05-04T08:45:00",  "orders": "2026-05-04T08:45:00"}

4.2 Полный режим

Принцип: полная выгрузка всех сущностей с пагинацией, полная пересборка индексов.

1. Создаём новый индекс с суффиксом _tmp2. Загружаем все данные через API с пагинацией (batch по 500 записей)3. После успешной загрузки — переключаем алиас4. Удаляем старый индекс

Применяется при: первоначальном развёртывании, восстановлении после сбоя, изменении маппинга.

5. Трансформация данных

5.1 Денормализация

При индексации данные обогащаются связанными сущностями во избежание JOIN-запросов в OpenSearch:

projects → добавляем account_name, manager_name, property_name, project_status (название)orders   → добавляем account_name, manager_name, company_namecomments → добавляем project_name, project_status, account_name, manager_name

5.2 Вычисляемые поля

Поле Индекс Формула
is_shipped itech_orders, itech_order_items shipping_date_fact IS NOT NULL
revenue_mln itech_accounts SUM(order_items.amount) / 1 000 000
debt_mln itech_accounts SUM(expected_payments где paid_amount < pay_amount) / 1 000 000
order_count itech_accounts COUNT(orders.id)
top_account itech_properties Контрагент с наибольшим числом проектов на объекте

5.3 Нормализация данных

6. Обработка конфликтов и ошибок

6.1 Стратегия при конфликте версий

Правило: последнее изменение по updated_at побеждает.

# При upsert в OpenSearch{  "doc": { ...новые поля... },  "doc_as_upsert": True}

Если updated_at в новой записи меньше, чем в существующей -- запись не обновляется (idempotent операция).

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

Ситуация Поведение
HTTP 429 (rate limit) Пауза 60 сек, повтор
HTTP 5xx (ошибка сервера) Retry 3 раза с экспоненциальной задержкой
HTTP 404 (запись удалена) Удаление из OpenSearch
Таймаут соединения Retry 3 раза, затем запись в лог ошибок
Частичный сбой батча Повтор только ошибочных записей

6.3 Логирование

Каждый запуск синхронизации фиксирует:

{  "run_id": "uuid",  "mode": "incremental",  "started_at": "2026-05-04T09:00:00",  "finished_at": "2026-05-04T09:00:23",  "entities": {    "projects": { "fetched": 42, "indexed": 42, "errors": 0 },    "orders": { "fetched": 7, "indexed": 7, "errors": 0 }  },  "status": "success"}

7. Мониторинг и алерты

Метрика Пороговое значение Действие
Время последней синхронизации > 30 минут назад Алерт администратору
Количество ошибок за запуск > 5% от batch Алерт + запись в лог
Расхождение счётчиков Индекс < 90% от MySQL Запуск полной синхронизации
Недоступность API Grace > 3 неудачных попытки Алерт + пауза 10 минут

8. Требования к API Grace CRM

Для корректной работы интеграции API Grace CRM должен поддерживать:

Требование Параметр Обязательно
Фильтрация по дате изменения ?updated_since=ISO8601 Да
Пагинация ?page=N&per_page=500 Да
Получение записи по ID GET /{entity}/{id} Да
Аутентификация API-ключ в заголовке Да
Rate limit Информация о лимитах Да (для настройки задержек)

Открытый вопрос: наличие webhooks в API Grace CRM уточняется на Этапе 0. При наличии webhooks -- добавить режим event-driven синхронизации в дополнение к cron-polling.

Акт сдачи-приёмки работ № 1

Ролевая модель (RBAC) — Grace CRM Assistant

Версия: 1.0 Дата: 4 мая 2026

Статус: Этап 0 -- согласование файл 04_rbac.md

1. Принципы ролевой модели

2. Роли системы

2.1 Контур Sales AI

Роль ID Назначение
Менеджер по продажам manager Работа со своими проектами, рекомендации, уведомления
Руководитель отдела продаж rop Мониторинг команды, эскалации, аналитика по отделу
Заместитель ГД deputy_gd Стратегическая аналитика, агрегированные данные
Администратор системы admin Управление системой, конфиг, синхронизация

2.2 Контур Knowledge AI

Роль ID Назначение
Ответственный за базу знаний knowledge_manager Загрузка документов, управление базой знаний
Читатель базы знаний knowledge_reader Поиск и просмотр документов

2.3 Системные роли

Роль ID Назначение
Системный интегратор system Межсистемное взаимодействие (API-to-API)

3. Матрица прав доступа

3.1 Данные CRM

Объект manager rop deputy_gd admin
Свои проекты (просмотр) ✅ ✅ ✅ ✅
Все проекты команды (просмотр) ❌ ✅ ✅ ✅
Все проекты компании (просмотр) ❌ ❌ ✅ ✅
Свои клиенты (просмотр) ✅ ✅ ✅ ✅
Все клиенты (просмотр) ❌ ✅ ✅ ✅
Комментарии по своим проектам ✅ ✅ ✅ ✅
Комментарии по всем проектам ❌ ✅ ✅ ✅

3.2 Рекомендации

Действие manager rop deputy_gd admin
Получать рекомендации по своим проектам ✅ ✅ ❌ ✅
Просматривать рекомендации по команде ❌ ✅ ❌ ✅
Подтверждать выполнение рекомендации ✅ ✅ ❌ ✅
Запрашивать рекомендацию вручную ✅ ✅ ❌ ✅

3.3 Аналитика

Объект manager rop deputy_gd admin
Своя воронка продаж ✅ ✅ ✅ ✅
Воронка по команде ❌ ✅ ✅ ✅
Агрегированная аналитика компании ❌ ❌ ✅ ✅
Свой коэффициент качества (Кк) ✅ ✅ ❌ ✅
Кк по команде ❌ ✅ ❌ ✅
Кк агрегированно по отделу ❌ ❌ ✅ ✅
Свой прогноз премии ✅ ✅ ❌ ✅
Прогноз премии по команде ❌ ✅ ❌ ✅
Прогноз премии по всему отделу ❌ ❌ ❌ ✅

Примечание: Зам. ГД видит только агрегированные данные по отделу, без персональных показателей менеджеров.

3.4 База знаний

Действие manager rop deputy_gd knowledge_manager admin
Поиск по базе знаний ✅ ✅ ✅ ✅ ✅
Просмотр документов ✅ ✅ ✅ ✅ ✅
Загрузка документов ❌ ❌ ❌ ✅ ✅
Редактирование документов ❌ ❌ ❌ ✅ ✅
Удаление документов ❌ ❌ ❌ ✅ ✅
Запуск Lint Agent (аудит) ❌ ❌ ❌ ✅ ✅

3.5 Управление системой

Действие manager rop deputy_gd knowledge_manager admin
Запуск синхронизации ❌ ❌ ❌ ❌ ✅
Просмотр статуса синхронизации ❌ ❌ ❌ ❌ ✅
Изменение правил проверки Quality Agent ❌ ❌ ❌ ❌ ✅
Изменение SLA-параметров ❌ ❌ ❌ ❌ ✅
Просмотр audit log ❌ ❌ ❌ ❌ ✅
Управление пользователями и ролями ❌ ❌ ❌ ❌ ✅

3.6 Уведомления

Действие manager rop deputy_gd admin
Получать уведомления о своих проектах ✅ ✅ ❌ ✅
Получать сводку по команде ❌ ✅ ✅ ✅
Получать эскалации ❌ ✅ ✅ ✅
Настраивать предпочтительный канал (Mattermost/Telegram) ✅ ✅ ✅ ✅

4. Изоляция данных: правила фильтрации

Менеджер (role: manager)

projects WHERE manager_id = {current_user_id}
accounts WHERE manager_id = {current_user_id}
  OR assistant_user_id = {current_user_id}
recommendations WHERE manager_id = {current_user_id}
kk_score WHERE manager_id = {current_user_id}
bonus_forecast WHERE manager_id = {current_user_id}

РОП (role: rop)

projects WHERE manager_id IN (
  SELECT id FROM users WHERE department_id = {rop_department_id}
)
-- или конфигурируемый список подчинённых менеджеров

Зам. ГД (role: deputy_gd)

-- Только агрегированные данные, без персональных показателей
SELECT COUNT(*), SUM(amount), AVG(probability_percent)
FROM projects
-- без разбивки по конкретным менеджерам в разделе премий

5. Назначение ролей

5.1 Текущее назначение (I-TECH)

Пользователь Роль в Grace CRM Роль в AI-системе
Менеджеры отдела продаж Продажи manager
Руководитель отдела продаж РОП rop
Заместитель ГД по развитию Зам. ГД deputy_gd
Дмитрий Калдарбеков Руководитель отдела цифровизации admin
Ответственный за базу знаний -- knowledge_manager

5.2 Правила назначения

6. Аутентификация

6.1 Режимы

Режим Применение
SSO через Grace CRM Основной режим для сотрудников I-TECH
JWT Bearer Token Межсистемные интеграции (1С, BI, ERP)
API Key Системные интеграторы (role: system)

6.2 Параметры JWT

Параметр Значение
Алгоритм RS256
Срок действия 8 часов (рабочая смена)
Refresh token 30 дней
Payload user_id, roles[], department_id, exp

7. Audit Log

Все действия пользователей фиксируются со следующими полями:

Поле Описание
timestamp Дата и время события
user_id ID пользователя
user_role Роль на момент действия
action Тип действия (READ / WRITE / DELETE / SYNC / LOGIN)
resource_type Тип объекта (project / recommendation / document / ...)
resource_id ID объекта
ip_address IP-адрес запроса
result success / forbidden / error

Обязательно логируются:

Хранение: audit log хранится 12 месяцев, доступен только admin.

Акт сдачи-приёмки работ № 1

Реестр критических данных и правила контроля качества

файл 05_critical_data.md

1. Назначение

Данный документ определяет перечень критических данных в Grace CRM, подлежащих обязательной проверке Quality Agent, а также правила контроля качества:

Цель: обеспечить достоверность аналитики и корректную работу Recommendation Agent.

2. Принципы контроля качества

3. Реестр объектов и полей

3.1 Проекты (itech_projects)

Поле Тип Обязательность Формат Правило проверки Критичность
account_id integer Обязательно >0 Не NULL Critical
project_status_id integer Обязательно >0 Не NULL Critical
probability_percent integer Обязательно 0–100 Не NULL Critical
forecast_date date Обязательно YYYY-MM-DD Не NULL, ≥ today Critical
next_action text Обязательно строка Не пусто Critical
next_action_date date Обязательно YYYY-MM-DD ≥ today Critical
last_activity_at date Обязательно дата ≤ 30 дней Warning

3.2 Контрагенты (itech_accounts)

Поле Тип Обязательность Формат Правило проверки Критичность
name text Обязательно строка Не пусто Critical
inn keyword Обязательно 10/12 цифр regex Critical
manager_id integer Обязательно >0 Не NULL Critical
reliability keyword Желательно enum red/yellow/green Warning

3.3 Активности / комментарии (itech_comments)

Поле Тип Обязательность Формат Правило проверки Критичность
comment text Обязательно строка длина > 10 Warning
created_at date Обязательно дата не NULL Critical

3.4 Расчёты (itech_calculations)

Поле Тип Обязательность Формат Правило проверки Критичность
project_id integer Обязательно >0 Не NULL Critical
calculation_status keyword Обязательно enum Не NULL Critical
amount double Обязательно >0 >0 Warning

4. Логика выявления пробелов

4.1 Отсутствие обязательных полей

IF field IS NULL → ошибка

4.2 Нарушение бизнес-логики

Примеры:

IF status = "КП отправлено" AND calculations = 0 → ошибка

4.3 Просроченные действия

IF next_action_date < today → ошибка

4.4 Отсутствие активности

IF last_activity_at > 30 дней → warning

5. Расчёт Кк (коэффициента качества данных)

Кк=1−(проектысошибками/общееколичествопроектов)

Где:

6. Выход Quality Agent

Формируется реестр:

Проект

Поле

Ошибка

Ответственный

Срок

7. Эскалации

Условие Действие
Ошибка Critical уведомление менеджеру
Нет реакции > SLA эскалация РОП
Повторная ошибка эскалация Зам. ГД

8. Расширение реестра

Акт сдачи-приёмки работ № 1

Карточки агентов — продуктовый подход

Приложение 6. Карточки агентов -- продуктовый подход

к Акту сдачи-приёмки работ по Этапу 0

Проект: Grace CRM Assistant Договор: №04-002 от 24.04.2026 Исполнитель: ООО «Экобанкинг» Заказчик: ООО «АйТек»

О методе описания

Каждый агент описан через продуктовую формулу:

Продукт -- что конкретно производит агент Внутренний клиент -- кто получает этот продукт (роль или другой агент) Триггер -- при каком условии агент запускается Критерий выполнения -- как проверить, что агент выполнил свою функцию

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

Контур 1 -- Sales AI (Grace CRM Assistant)

Агент 1. Sync Agent -- Агент синхронизации

Продукт:

Актуальный поисковый образ данных Grace CRM в OpenSearch -- гарантирующий, что любой запрос от downstream-агентов отражает реальное состояние CRM на момент последнего запуска.

Элемент Содержание
Внутренний клиент Quality Agent, Recommendation Agent
Механизм CLI -> API Grace CRM -> трансформация -> bulk index в OpenSearch
Триггер Cron по расписанию + ручной запуск администратором
Входные данные API Grace CRM: projects, activities, clients, tasks, comments, calculations, orders, users, objects
Выходной продукт Обновлённые индексы OpenSearch (15 индексов)
Критерий выполнения Все индексы обновлены без ошибок; расхождение Grace CRM / OpenSearch = 0 по завершении синхронизации
Красный флаг Ошибка синхронизации -> downstream-агенты работают на устаревших данных -> все рекомендации невалидны

Режимы работы:

Режим Триггер Что синхронизируется
Инкрементальный Cron каждые 15 минут Изменения с последнего запуска (updated_since)
Полный Ежедневно в 02:00 / ручной запуск Все сущности, полная пересборка индексов

Цепочка ответственности:

Grace CRM (source of truth)    ↓ APISync Agent    ↓ bulk indexOpenSearch (15 индексов) → Quality Agent, Recommendation Agent

Агент 2. Quality Agent -- Агент контроля качества данных

Продукт:

Ежедневный реестр проектов с критическими пробелами данных -- для менеджеров и РОПа -- с указанием конкретного поля, ответственного и срока устранения.

Элемент Содержание
Внутренний клиент 1 Менеджер -- получает задачу на заполнение по своим проектам
Внутренний клиент 2 РОП -- получает сводку по команде и эскалацию при просрочке
Триггер Ежедневно в 09:00 + при изменении статуса проекта
Входные данные OpenSearch: itech_projects, itech_calculations; правила проверки из конфига
Выходной продукт Структурированный реестр: проект -> пробел -> ответственный -> срок; сигнал в Notification Agent
Критерий выполнения Доля проектов с полными данными ≥ 85% (вектор роста); каждый пробел имеет назначенного ответственного

Правила проверки (настраиваются в конфиге без релиза):

Проверка Поле Условие нарушения
Обязательные поля account_id, property_id, project_status_id, probability_new, forecast_date Пусто
Следующий шаг next_action_date Пусто или дата в прошлом
Логика статусов calculation_status При статусе «КП выставлено» -- расчёт отсутствует
Активность last_activity_at Более 30 дней назад для активного проекта

Агент 3. Recommendation Agent -- Агент рекомендаций

Продукт:

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

Элемент Содержание
Внутренний клиент Менеджер (первично); РОП (при просрочке реакции менеджера)
Триггер Изменение статуса проекта / запрос менеджера / просрочка контакта
Входные данные OpenSearch: история проекта, активности, комментарии; RAGflow: кейсы, скрипты, возражения
Выходной продукт Рекомендация: действие + срок + обоснование + ссылка на кейс из базы знаний
Критерий выполнения Менеджер знает следующий шаг по каждому активному проекту; нет проектов без зафиксированного следующего действия
Вектор роста Снижение доли проектов без следующего шага; рост конверсии КП -> заказ

Формат рекомендации:

Проект: [название] | Клиент: [название] | Стадия: [статус]
Последний контакт: N дней назад

Рекомендация: [конкретное действие]
Срок: [дата]
Обоснование: [краткое обоснование на основе истории]
Похожий кейс: [ссылка из базы знаний RAGflow]

Агент 4. Notification Agent -- Агент уведомлений

Продукт:

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

Элемент Содержание
Внутренний клиент Менеджер / РОП / Зам. ГД -- в зависимости от типа события
Триггер Сигнал от любого агента системы
Входные данные Сигнал от агента + профиль получателя (предпочтительный канал)
Выходной продукт Доставленное уведомление с подтверждённой реакцией
Механизм доставки Adapter pattern: Mattermost (основной) / Telegram (резерв), канал настраивается per-user
Критерий выполнения Реакция (действие или подтверждение) в течение N часов; при отсутствии реакции -- эскалация в Orchestrator
Красный флаг Уведомление без реакции сверх SLA -> передаётся Orchestrator для эскалации

Матрица маршрутизации:

Событие Получатель Приоритет
Пробел в данных по своему проекту Менеджер Нормальный
Рекомендация по проекту Менеджер Нормальный
Просрочка реакции менеджера > SLA РОП Высокий
Критическое событие (крупная сделка, риск ухода клиента) РОП, Зам. ГД Высокий
Ежедневная сводка по команде РОП Плановый

Агент 5. Orchestrator -- Оркестратор

Продукт:

Бесперебойная работа агентной системы как единого целого -- для РОПа и Зам. ГД -- обеспечивающая, что ни одно критическое событие не теряется и каждый сигнал доходит до нужного человека в нужное время.

Элемент Содержание
Внутренний клиент РОП, Зам. ГД
Триггер Постоянно -- реагирует на сигналы всех агентов
Входные данные Сигналы от всех агентов; SLA-параметры из конфига
Выходной продукт Гарантия непрерывности потока сигналов и эскалаций; каждое событие имеет назначенного ответственного
Критерий выполнения Отсутствие потерянных эскалаций; система работает без ручного вмешательства

Примечание: Orchestrator не имеет одного артефактного продукта -- его продукт это состояние системы. Это принципиальное отличие от остальных агентов.

Контур 2 -- Knowledge AI (база знаний)

Агент 6. Ingest Agent -- Агент загрузки знаний

Продукт:

Проиндексированный документ в RAGflow с корректными метаданными -- готовый к поиску Query Agent и использованию Recommendation Agent.

Элемент Содержание
Внутренний клиент Query Agent, Recommendation Agent
Триггер Загрузка нового документа ответственным за базу знаний
Входные данные Документ (PDF, DOCX, MD) + метаданные: отрасль, тип клиента, стадия сделки, продукт, теги
Выходной продукт Проиндексированная запись в RAGflow; обновлённый граф связей
Критерий выполнения Документ доступен для поиска Query Agent; все метаданные заполнены

Обязательные метаданные документа:

Поле Описание Пример
industry Отрасль клиента Энергетика, Строительство
client_type Тип клиента Генподрядчик, Интегратор
deal_stage Стадия сделки Расчёт КП, Переговоры
product Продукт НКУ, ВРУ, БКТП
doc_type Тип документа Кейс, Скрипт, Возражение, Регламент
tags Теги конкуренция, срок, цена

Агент 7. Query Agent -- Агент поиска знаний

Продукт:

Контекстный ответ с цитатой и ссылкой на источник -- для менеджера или Recommendation Agent -- за ≤ 5 секунд.

Элемент Содержание
Внутренний клиент Менеджер (прямой запрос); Recommendation Agent (инструментальный вызов)
Триггер Текстовый запрос менеджера / вызов от Recommendation Agent
Входные данные Текстовый запрос + контекст проекта (отрасль, стадия, тип клиента)
Выходной продукт Ответ + цитата из источника + ссылка на документ
Критерий выполнения Релевантный ответ ≤ 5 секунд; источник указан всегда

Агент 8. Lint Agent -- Агент аудита знаний

Продукт:

Еженедельный отчёт о противоречиях, устаревших данных и логических разрывах в базе знаний -- для ответственного за базу знаний.

Элемент Содержание
Внутренний клиент Ответственный за базу знаний (роль knowledge_manager)
Триггер Еженедельно
Входные данные Все документы в RAGflow
Выходной продукт Отчёт: противоречия, документы старше 6 месяцев, незаполненные разделы
Критерий выполнения Выявлены все документы старше 6 месяцев и документы с конфликтующими утверждениями

Схема взаимодействия агентов

Grace CRM
    ↓ API
[1] Sync Agent ──────────────────────────────────────────────►  OpenSearch
                                                                     │
                                     ┌───────────────────────────────┘
                                     │
                              [5] Orchestrator
                             (управление, SLA)
                                     │
                    ┌────────────────┴────────────────┐
                    ▼                                 ▼
             [2] Quality Agent              [3] Recommendation Agent
             (пробелы в данных)             (следующий шаг) ◄── RAGflow
                    │                                 │        [6] Ingest Agent
                    └────────────────┬────────────────┘        [7] Query Agent
                                     ▼                         [8] Lint Agent
                             [4] Notification Agent
                              (Mattermost / Telegram)
                                     │
                    ┌────────────────┼────────────────┐
                    ▼                ▼                 ▼
                Менеджер            РОП            Зам. ГД

Промежуточные варианты (Ожерельев)

Ранние черновики архитектуры и ТЗ Sync Agent. Не каноничны — сохранены для истории согласования.

Промежуточные варианты (Ожерельев)

Техническое описание архитектуры продукта

Технической описание архитектуры продукта

Версия: 1.0 Дата: 3 мая 2026

Источник: Ожерельев В.А. файл Техническое_описание_архитектуры.md

1. Обзор продукта

1.1 Назначение системы

Мультиагентная AI-система Grace CRM Assistant предназначена для автоматизации процессов продаж и повышения эффективности работы отдела продаж компании.

Система реализует цифровых AI-ассистентов (агентов), которые анализируют данные CRM, контролируют качество данных, формируют рекомендации менеджерам и обеспечивают управленческий контроль.

Система интегрируется с Grace CRM (Laravel BAP) через API и webhooks и функционирует как надстройка (advisory layer) над CRM, не нарушая принцип CRM = source of truth

1.2 Цели внедрения

Основные бизнес-цели системы:

1.3 Функциональные возможности

Система обеспечивает:

1.3.1 AI-ассистирование продаж

1.3.2 Контроль качества данных

1.3.3 Уведомления и эскалации

1.3.4 Корпоративный поисковый контур

1.3.5 Управление знаниями

1.4 Состав системы

Система включает два функциональных контура: контур продаж и контур базы знаний.

Контур 1 -- Sales AI (Grace CRM Assistant)

Агент Наименование Назначение
Sync Agent Агент синхронизации Получает данные из Grace CRM через API/webhooks, обновляет PostgreSQL и инициирует индексацию в OpenSearch
Quality Agent Агент контроля качества данных Проверяет полноту и корректность данных CRM, выявляет пробелы, формирует задачи и сигналы
Recommendation Agent Агент рекомендаций Анализирует данные CRM и базы знаний, формирует конкретные рекомендации менеджерам (действие, срок, обоснование)
Notification Agent Агент уведомлений Доставляет сообщения пользователям (корпоративный мессенджер / CRM), отслеживает статус реакции
Orchestrator Оркестратор (LLM-слой) Управляет агентами, приоритизацией задач, SLA, маршрутизацией и эскалациями

Контур 2 -- Knowledge AI (база знаний)

Агент Наименование Назначение
Ingest Agent Агент загрузки знаний Принимает документы, структурирует их, создает/обновляет сущности базы знаний и инициирует индексацию
Query Agent Агент поиска знаний Выполняет поиск (семантический + полнотекстовый) и формирует ответы с ссылками на источники
Lint Agent Агент аудита знаний Анализирует базу знаний, выявляет противоречия, устаревшие данные и логические разрывы

1.5 Ключевые принципы

Дополнительно:

Требования к LLM-слою

Коммуникационный слой

2. Архитектура решения

2.1 Общая архитектурная модель

Система построена по принципу мультиагентной архитектуры с централизованной оркестрацией:

2.2 Основные компоненты

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

Источники данных

Слой данных

AI-слой

Интеграционный слой

2.3 Схема взаимодействия систем

Логическая схема взаимодействия:

               ┌────────────────────┐
                │   Grace CRM        │
                │ (Laravel BAP API)  │
                └─────────┬──────────┘
                          │
                (API / Webhooks)
                          │
          ┌───────────────▼────────────────┐
          │         Sync Agent             │
          └───────────────┬────────────────┘
                          │
        ┌─────────────────┼──────────────────┐
        │                 │                  │
        ▼                 ▼                  ▼
┌──────────────┐  ┌──────────────┐  ┌────────────────┐
│ PostgreSQL   │  │ OpenSearch   │  │ RAGFlow        │
│ (операционка)│  │ (индексы)    │  │ (КРАБ / Vector DB)│
└──────┬───────┘  └──────┬───────┘  └──────┬─────────┘
       │                 │                  │
       └─────────┬───────┴──────────┬───────┘
                 ▼                  ▼
        ┌──────────────────────────────────┐
        │         Orchestrator (LLM)       │
        └───────────┬───────────────┬──────┘
                    │               │
     ┌──────────────▼───────┐   ┌───▼───────────────┐
     │ Recommendation Agent │   │ Quality Agent     │
     └──────────────┬───────┘   └───┬───────────────┘
                    │               │
                    ▼               ▼
             ┌──────────────┐   ┌──────────────┐
             │ Notification │   │ Tasks / CRM  │
             │ Agent        │   │ updates      │
             └──────┬───────┘   └──────┬───────┘
                    │                  │
                    ▼                  ▼
             ┌──────────────┐   ┌──────────────┐
             │ Telegram     │   │ Grace CRM     │
             │ / Messenger  │   │ (обратная запись)
             └──────────────┘   └──────────────┘

Схема взаимодействия систем (Mermaid)**

(диаграмма tekhnicheskoy-opisanie-arkhitektury-produkta.mermaid отсутствовала в исходнике Gramax — восстановить)

2.4 Потоки данных (основной сценарий)

1. Синхронизация

2. Анализ

3. Оркестрация

4. Доставка

5. Обратная запись

2.5 Архитектурные особенности

3. Описание компонентов решения

--

3.1 PostgreSQL -- операционный слой (OLTP)

PostgreSQL используется как основное операционное хранилище AI-системы, обеспечивающее консистентность и управление внутренним состоянием.

Назначение:

Типы данных:

Почему PostgreSQL:

Роль в архитектуре:

➡️ System of record для AI-слоя (но не для бизнес-данных CRM)

3.2 OpenSearch -- поисковый и аналитический слой

OpenSearch используется как унифицированный слой быстрого доступа к данным CRM и аналитики.

Назначение:

Типы данных:

Особенности:

Почему OpenSearch:

Роль в архитектуре:

➡️ Search & Analytics Layer (read-heavy слой)

3.3 RAGFlow -- база знаний (Knowledge Layer)

Назначение:

Дополнительно:

➡️ Semantic Knowledge Layer

3.4 Итоговое разделение ответственности слоя данных

Слой Система Роль
Операционный PostgreSQL Состояние системы и агентов
Поисковый OpenSearch Быстрый доступ и аналитика CRM
Семантический RAGFlow Знания и контекст для AI

4. База знаний (компактное описание)

4.1 Какие документы входят в базу знаний

База знаний -- это:

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

База знаний должна содержать строго структурированные типы контента:

  1. Продуктовые материалы Описания продуктов, УТП, ограничения, сценарии применения

  2. Кейсы продаж (ключевой блок) Реальные сделки: контекст, действия менеджера, результат

  3. Скрипты и best practices Шаблоны коммуникаций, стратегии ведения сделки

  4. Возражения и ответы Типовые возражения клиентов и эффективные способы их обработки

  5. Отраслевые материалы Боли, особенности и контекст различных отраслей

  6. Конкурентный анализ Сравнение с конкурентами, аргументация

  7. Регламенты и процессы Правила работы, этапы воронки, SLA

  8. Ошибки и анти-паттерны Причины провалов сделок и нежелательные сценарии

  9. FAQ / быстрые ответы Короткие стандартизированные формулировки

4.2 Что ищут менеджеры

Поисковые сценарии делятся на 4 типа:

Ситуационные

Контекстные

Поведенческие

Тактические

4.3 Структура базы знаний

1. Иерархия

2. Метаданные (обязательные)

Каждый документ должен содержать:

3. Граф связей (knowledge graph)

В рамках данной архитектуры база знаний дополнительно структурируется с использованием графовой модели (граф БД / knowledge graph) для этого используется логическая графовая модель внутри RAGFlow:

Пример связей между сущностями:

4.4 Как это использует AI

Recommendation Agent:

Quality Agent:

Orchestrator:

Промежуточные варианты (Ожерельев)

ТЗ: Разработка агента синхронизации данных (Sync Agent)

ТЗ: Разработка агента синхронизации данных (Sync Agent)

Источник файл Ожерельев В.А. ТЗ: Разработка агента синхронизации.md

Дата: 03.05.2026

1. Назначение

Агент синхронизации обеспечивает загрузку и актуализацию данных из Grace CRM в:

Система должна поддерживать:

2. Состав синхронизируемых сущностей

Обязательные сущности:

Сущность Описание
Projects Сделки
Clients Клиенты
Objects Объекты клиента (ключевая связь клиент -> актив)
Activities Активности
Tasks Задачи
Comments Комментарии
Calculations Расчёты / КП
Orders Заказы
Users Пользователи

3. API интеграция с CRM

Основные endpoints

GET /api/projects
GET /api/projects/{id}
GET /api/projects?updated_since=timestamp

GET /api/activities
GET /api/activities?project_id=
GET /api/activities?updated_since=timestamp

GET /api/clients
GET /api/clients/{id}

GET /api/tasks
GET /api/tasks?project_id=

GET /api/comments
GET /api/comments?entity_type=&entity_id=

GET /api/calculations
GET /api/calculations?project_id=

GET /api/orders
GET /api/orders?project_id=

GET /api/users

3.1 Объекты (обязательное расширение CRM)

⚠️ В рамках проекта требуется наличие сущности:

Objects (объекты клиента)

Если отсутствует -- требуется добавить API:

GET /api/objects
GET /api/objects/{id}
GET /api/objects?client_id=
GET /api/objects?updated_since=timestamp

Назначение:

Пример:

4. Архитектура Sync Agent

Компоненты:

5. Mapping схемы OpenSearch (JSON)

5.1 crm-projects

{
  "mappings": {
    "properties": {
      "project_id": {"type": "keyword"},
      "client_id": {"type": "keyword"},
      "object_id": {"type": "keyword"},
      "name": {"type": "text"},
      "status": {"type": "keyword"},
      "stage": {"type": "keyword"},
      "amount": {"type": "double"},
      "manager_id": {"type": "keyword"},
      "created_at": {"type": "date"},
      "updated_at": {"type": "date"},
      "last_activity_at": {"type": "date"},
      "activities_count": {"type": "integer"}
    }
  }
}

5.2 crm-objects (новый индекс)

{
  "mappings": {
    "properties": {
      "object_id": {"type": "keyword"},
      "client_id": {"type": "keyword"},
      "name": {"type": "text"},
      "type": {"type": "keyword"},
      "status": {"type": "keyword"},
      "location": {"type": "text"},
      "created_at": {"type": "date"},
      "updated_at": {"type": "date"}
    }
  }
}

5.3 crm-clients

{
  "mappings": {
    "properties": {
      "client_id": {"type": "keyword"},
      "name": {"type": "text"},
      "industry": {"type": "keyword"},
      "segment": {"type": "keyword"},
      "created_at": {"type": "date"},
      "updated_at": {"type": "date"}
    }
  }
}

5.4 crm-activities

{
  "mappings": {
    "properties": {
      "activity_id": {"type": "keyword"},
      "project_id": {"type": "keyword"},
      "type": {"type": "keyword"},
      "description": {"type": "text"},
      "result": {"type": "text"},
      "created_at": {"type": "date"}
    }
  }
}

5.5 crm-tasks

{
  "mappings": {
    "properties": {
      "task_id": {"type": "keyword"},
      "project_id": {"type": "keyword"},
      "assignee_id": {"type": "keyword"},
      "status": {"type": "keyword"},
      "due_date": {"type": "date"}
    }
  }
}

5.6 crm-comments

{
  "mappings": {
    "properties": {
      "comment_id": {"type": "keyword"},
      "entity_type": {"type": "keyword"},
      "entity_id": {"type": "keyword"},
      "text": {"type": "text"},
      "author_id": {"type": "keyword"},
      "created_at": {"type": "date"}
    }
  }
}

{
  "mappings": {
    "properties": {
      "calculation_id": {"type": "keyword"},
      "project_id": {"type": "keyword"},
      "amount": {"type": "double"},
      "version": {"type": "integer"},
      "created_at": {"type": "date"}
    }
  }
}

5.8 crm-orders

{
  "mappings": {
    "properties": {
      "order_id": {"type": "keyword"},
      "project_id": {"type": "keyword"},
      "amount": {"type": "double"},
      "status": {"type": "keyword"},
      "created_at": {"type": "date"}
    }
  }
}

6. Распределение данных между PostgreSQL и OpenSearch

Данный раздел определяет, какие данные и в каком виде сохраняются в:

Ключевой принцип:

6.0 Диаграмма последовательности обмена данными

sequenceDiagram
    participant CRM
    participant Webhook
    participant SyncAgent
    participant PostgreSQL
    participant OpenSearch

    CRM->>Webhook: project-updated
    Webhook->>SyncAgent: событие

    SyncAgent->>CRM: GET /projects/{id}
    CRM-->>SyncAgent: project data

    SyncAgent->>SyncAgent: transform + normalize

    SyncAgent->>PostgreSQL: upsert
    SyncAgent->>OpenSearch: bulk index

    Note over SyncAgent: update last_sync_timestamp

6.1 Таблица распределения данных

Сущность PostgreSQL (что сохраняется) OpenSearch (что индексируется)
Projects (сделки) Полная структура проекта (raw JSON + нормализованные поля), статус синхронизации, технические поля (sync_state, timestamps) Денормализованная витрина: project_id, client_id, object_id, стадия, статус, сумма, менеджер, last_activity_at, activities_count
Clients (клиенты) Полная карточка клиента, связи, служебные поля Упрощённая витрина: client_id, название, отрасль, сегмент
Objects (объекты) Полная модель объекта, связь с клиентом Витрина: object_id, client_id, тип, статус, локация
Activities (активности) Полные записи активностей (raw), связь с проектом Индекс коммуникаций: тип, текст, результат, дата
Tasks (задачи) Полная структура задач, статусы, SLA Витрина: task_id, project_id, исполнитель, статус, due_date
Comments (комментарии) Полные тексты, связь с entity Индекс текстов для поиска: entity_type, entity_id, текст
Calculations (расчёты) Полные расчёты, версии, параметры Витрина: сумма, версия, привязка к проекту
Orders (заказы) Полная структура заказов Витрина: статус, сумма, дата
Users (пользователи) Полная модель пользователей и ролей Витрина: user_id, роль, команда
Sync metadata offset, updated_since, last_sync_time, retry state ❌ не индексируется
Ошибки / логи sync Полный лог операций ❌ не индексируется

6.2 Принципы формирования витрин OpenSearch

1. Денормализация

В OpenSearch данные агрегируются:

Пример:

2. Обогащение

При индексации добавляются:

Пример:

3. Оптимизация под сценарии поиска

OpenSearch индекс строится под:

НЕ под:

6.3 Поток записи данных

CRM → SyncAgent → PostgreSQL (raw + normalized)
                         ↓
                   Transformer
                         ↓
                  OpenSearch (витрины)

6.4 Ключевые различия слоёв

Критерий PostgreSQL OpenSearch
Тип данных нормализованные денормализованные
Назначение состояние системы поиск и аналитика
Обновление строгое (upsert) bulk indexing
Источник истины да (для AI слоя) нет
Использование Sync, Orchestrator Recommendation, Analytics

6.5 Важное архитектурное требование

7. Модель синхронизации: когда, что и как обновляется

Синхронизация реализуется через 3 параллельных механизма, каждый из которых решает свою задачу:

7.1 Webhooks (near real-time синхронизация)

Назначение

Мгновенная реакция на изменения в CRM.

Когда срабатывает

При событиях в CRM:

Поток

CRM → webhook → SyncAgent → точечный fetch → update

Какие данные синхронизируются

Сущность Что делаем
Projects загружаем 1 проект по ID
Activities загружаем активность или проект целиком
Tasks загружаем задачу
Comments при наличии webhook
Calculations при изменении проекта

Особенность

Webhook не доверяем полностью -> всегда делаем дочитывание через API

SLA

7.2 Polling (инкрементальная синхронизация)

Назначение

Гарантия, что:

Механика

Используется:

GET /api/*?updated_since=timestamp

Частота по сущностям

Сущность Частота Причина
Projects каждые 5 мин ключевая сущность
Activities каждые 5 мин динамика общения
Tasks 5–10 мин SLA
Comments 5–10 мин контекст
Objects 10–15 мин реже меняются
Clients 15–30 мин редко меняются
Calculations 10–15 мин средняя динамика
Orders 10–15 мин финансовые события
Users 1 раз/час почти статично

Поток

Scheduler → SyncAgent → API (bulk) → batch processing → upsert → index

Особенности реализации

SLA

7.3 Full Sync (полная синхронизация)

Назначение

Когда выполняется

Что синхронизируется

Сущность Поведение
Все полная выгрузка
Projects пересборка агрегатов
Activities полная история
Objects восстановление связей
Clients обновление справочника

Поток

Full load → overwrite / reindex → rebuild OpenSearch

SLA

7.4 Приоритет механизмов

Механизм Приоритет Роль
Webhooks высокий скорость
Polling средний надёжность
Full Sync низкий восстановление

7.5 Конфликты и консистентность

Правило:

последнее изменение по updated_at побеждает

Дополнительно:

7.6 Сводная схема

            ┌──────────────┐
            │    CRM       │
            └──────┬───────┘
                   │
      ┌────────────┼────────────┐
      │            │            │
      ▼            ▼            ▼
  Webhooks     Polling     Full Sync
 (реалтайм)   (дельта)     (полный)
      │            │            │
      └──────┬─────┴─────┬──────┘
             ▼           ▼
         Sync Agent (единая логика)
                   │
        ┌──────────┴──────────┐
        ▼                     ▼
   PostgreSQL           OpenSearch

7.7 Ключевой принцип (важно для разработки)

Нельзя полагаться только на один механизм:

➡️ Только вместе они дают:

Итог

Тип данных Как обновляется
Критичные (проекты, активности) webhook + polling
Средние (задачи, расчёты) polling + webhook (если есть)
Справочники (клиенты, users) редкий polling
Связи (objects) polling + full sync

8. Требования к реализации

Обязательные:

Производительность:

9. Ключевые особенности

10. Результат

После реализации: