Опубликовано: 19.09.2026 | Источник: MIT Technology Review

Агентная коммерция в дипломе: архитектура доверия, entity resolution и контекст-сервисы

MIT Technology Review опубликовал материал о том, что автономные ИИ-агенты перестают быть ассистентами и становятся исполнителями транзакций: они сами собирают маршрут, бронируют отель, оплачивают покупку. Ключевой тезис статьи простой и жёсткий — узким местом становится не скорость платежа, а скорость доверия. Если данные о пользователе, торговце, плательщике и правах агента противоречивы, автоматизация ломается не на уровне модели, а на уровне мастер-данных. Для выпускника ИТ-направления это готовый сюжет для ВКР: тема свежая, опирается на реальные корпоративные стандарты (MDM, entity resolution, токенизация прав), а значит — легко защищается на ГЭК.

Три темы ВКР, которые вырастают из этой статьи

Тема 1. Сервис разрешения сущностей (entity resolution) для мультиагентных торговых сценариев

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

Цель: спроектировать сервис, который по входящему потоку событий определяет, идёт ли речь об одной и той же сущности (клиент, торговец, плательщик), и отдаёт решение за миллисекунды.

Задачи:

• Проанализировать алгоритмы сопоставления записей (детерминированные правила, вероятностные модели, гибридные схемы).
• Спроектировать схему мастер-данных с версионированием и аудитом изменений.
• Реализовать прототип сервиса и API для вызова из агентных workflow.
• Провести нагрузочное тестирование и оценить латентность при пиковых запросах.

Структура: Глава 1 — обзор MDM-подходов и стандартов качества данных; Глава 2 — архитектура сервиса, схема данных, алгоритм matching; Глава 3 — нагрузочные тесты, метрики точности и полноты, оценка экономического эффекта от снижения ручных сверок.

Тема 2. Контекст-сервис как единая точка правды для ИИ-агентов

Актуальность. Авторы называют «систему контекста реального времени» недостающим слоем: модели умеют планировать и рассуждать, но не знают, действует ли агент в рамках выданных прав и не истёк ли бюджет. Это классическая задача сервис-ориентированной архитектуры, только с новым потребителем — не человеком, а агентом.

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

Задачи:

• Формализовать модель контекста и контракт API (OpenAPI).
• Спроектировать кэширование и предвычисление сигналов, чтобы runtime оставался лёгким.
• Реализовать прототип с интеграцией в тестовый каталог товаров.
• Замерить p95/p99 латентности и построить дашборд наблюдаемости.

Структура: Глава 1 — анализ подходов к управлению контекстом и политиками; Глава 2 — проектирование сервиса и диаграммы последовательностей; Глава 3 — тестирование производительности, отказоустойчивости, оценка применимости.

Тема 3. Управление жизненным циклом агента как субъекта доступа

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

Цель: построить модель управления агентскими идентичностями и проверить её на сценариях с разграничением ответственности.

Задачи:

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

Структура: Глава 1 — теория управления идентичностями и делегирования; Глава 2 — проектирование модели прав и токенов; Глава 3 — сценарии тестирования, оценка рисков, рекомендации по внедрению.

Аналитическая глава: чем обосновывать выбор решения

Первая глава ВКР чаще всего проваливается из-за пересказа маркетинговых материалов. Здесь статья даёт хорошую опору: она сравнивает три типа «правды» — о товаре, о плательщике и о личности. Это удобная рамка для сравнительной таблицы решений.

Для обоснования качества стоит опереться на ISO/IEC 25010: характеристики «функциональная полнота», «производительность», «защищённость» и «надёжность» из этой модели отлично ложатся в критерии сравнения. А требования к самой системе удобно оформить по ГОСТ 34.602-89 — это снимает половину вопросов на защите.

Что даёт статья в качестве источника

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

Проектная глава: схемы, алгоритмы, интеграция

Модель сущностей и связи между ними

Прежде чем рисовать диаграммы, зафиксируйте четыре роли: человек, агент, контрагент, ограничение. Дальше стройте UML-диаграмму классов и диаграмму последовательностей для сценария «агент оформляет бронирование». В статье описан ровно этот сценарий — значит, его можно взять как сквозной пример и провести от требований до тестов.

Предвычисление сигналов вместо тяжёлых вызовов

Один из самых защищаемых архитектурных приёмов из статьи: разрешение и подготовку контекста делают заранее, а на этапе выполнения агент получает уже сжатый пакет данных. Это классический паттерн «тонкий runtime — тяжёлый precompute». В ВКР его удобно показать через диаграмму потока данных и обосновать расчётом: сколько миллисекунд экономит предвычисление на каждом вызове и как это влияет на пропускную способность.

# Псевдокод контракта контекст-сервиса
GET /context/{agent_id}
{
  "subject": { "user_id": "u-8841", "confidence": 0.997 },
  "agent":   { "role": "booking", "scopes": ["travel:book"],
               "budget_limit": 4500, "expires_at": "2026-09-19T18:00Z" },
  "counterparty": { "merchant_id": "m-2210", "verified": true },
  "constraints": ["loyalty:prefer_partners", "risk:low"]
}

Токенизация прав: куда двигается отрасль

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

Тестирование и метрики: что измерять, а не что перечислять

Слабое место большинства работ — блок тестирования, где стоят фразы вида «система работает корректно». ГЭК это читает как отсутствие работы. Ниже — набор метрик, которые напрямую следуют из логики статьи.

Для сбора данных удобно развернуть связку инструментов наблюдаемости в локальном кластере. Даже упрощённый стенд на контейнерах даёт живые графики, которые сильно повышают вес работы. Метрики стоит связать с характеристиками ISO/IEC 25010 — тогда защита идёт не «по ощущениям», а по стандарту.

Чему вы научитесь на такой теме

• Проектировать сервисы с жёсткими требованиями по латентности, а не только по функциональности.
• Обосновывать выбор стека и архитектурного паттерна через измеримые критерии.
• Работать с мастер-данными: дедупликация, слияние, аудит, версионирование.
• Оформлять документацию по ГОСТ 34.602-89 и описывать систему на языке ISO/IEC 25010.
• Строить наблюдаемость: трассировка, метрики, логи, дашборды.

Частые вопросы студентов

Источник: Agentic commerce runs on truth and context (опубликовано 2026-03-25)