EN
Связаться
Глава 3

Полная архитектура помещается в семь блоков

Агент - это не "модель в браузере". Браузер не общается с моделью напрямую: сервер получает identity пользователя, запускает общий agent runtime, а провайдерский адаптер переводит единый контракт в конкретный формат API. Вся система умещается в семь блоков с ясными зонами ответственности.

Блок · Ответственность · Нельзя передавать модели

  • UI - Сообщения, streaming, карточка подтверждения; API keys
  • API route - Сессия, rate limit, validation, request id; Решение authorization
  • Agent runtime - Шаги, tools, timeout, outcome, trace; Неограниченный цикл
  • Provider adapter - Формат Responses, Messages или Interactions; Бизнес-правила
  • Tool handlers - Доступ к RAG, заказам и preview; Секреты и лишние поля
  • Approval service - Проверка preview, nonce, версии и actor; Свободный текст как разрешение
  • Event store - Собственная история, usage, audit и replay; Слепая зависимость от provider state

Смысл таблицы - в колонке "нельзя передавать модели". У каждого блока есть то, что он держит при себе: UI не отдаёт API-ключи, API route не отдаёт решение об authorization, runtime не отдаёт неограниченный цикл, адаптер не отдаёт бизнес-правила, tool-handlers не отдают секреты и лишние поля. Модель видит ровно то, что нужно для следующего решения, и ни байтом больше.

В коде это выглядит как две точки входа, а не одна.

UI
  POST /api/support/turn
    session + validation
      runCommerceAgent(context)
        provider adapter
        tool registry
        event store

  POST /api/support/approve
    approval service
      refund transaction

Почему именно два endpoint - вопрос не структуры, а риска.

Почему два endpoint. Разговор и исполнение финансового действия имеют разные уровни риска. Второй endpoint повторно проверяет пользователя, срок preview и idempotency key. Он не доверяет тексту предыдущего ответа модели.

Это и есть материализация главной границы: диалог ведёт агент, а необратимое действие выполняет отдельный доверенный путь. Дальше по книге мы соберём оба, но сначала решим, на чём их строить - на прямом API или на фреймворке.

Ссылки