Reference architecture AI-агента для бизнес-процесса
Модель предлагает шаги, runtime ограничивает действия
Восемь компонентов и три границы доверия
Авторская схема AGENT-REF-8 без клиентских метрик
архитектура AI-агента для бизнеса и production-проверки
$ agent --contract AGENT-REF-8
> intake: owner / task / scope
> evidence: permission / version
> propose: finite steps / action
> route: verified / hold / reconcileАрхитектура AI-агента для бизнеса начинается с конкретного действия: кто ставит задачу, какие данные разрешено читать, что можно изменить и как доказать результат. Модель помогает понять запрос и предложить шаги, но приложение управляет правами, состоянием и выполнением. Ниже — авторская схема AGENT-REF-8 для одного ограниченного процесса. Это проектный пример, а не внедрение у клиента или измеренный результат.
Если вы выбираете исполнителя в Армении, начните со страницы AI-специалиста. Здесь мы разбираем более узкий вопрос: как собрать проверяемую систему вокруг модели.
Проблема и требования
Представим процесс обработки заявки B2B: сотрудник получает письмо, агент находит действующую карточку клиента и условия договора, готовит предложение об изменении CRM и черновик ответа. Система не должна отправлять письмо или менять запись только потому, что модель предложила это в тексте. Владелец процесса сначала задаёт границы.
- Вход: заявка, идентификатор пользователя и организации, разрешённые источники.
- Выход: проверенный ответ, черновик или подтверждённое действие с квитанцией.
- Данные: перечень систем, классы чувствительности, сроки хранения и правила удаления.
- Действия: разрешённые инструменты, лимиты, цели и режим согласования.
- Сбой: маршрут при отсутствии источника, отказе интеграции, тайм-ауте и спорном результате.
Не каждый процесс требует агента. Для фиксированного маршрута с известными правилами достаточно обычной автоматизации. Для ответа по документам может хватить поискового помощника. Агент нужен, когда ход решения зависит от контекста и приходится выбирать следующий шаг в пределах заранее определённого контракта. Сравнение агента и чатбота помогает выбрать форму решения до разработки.
Архитектура решения: AGENT-REF-8
Схема разделяет восемь узлов и три границы доверия. Узлы можно реализовать отдельными сервисами или модулями одного приложения; важны контракты между ними, а не число контейнеров.
| Узел | Вход → выход | Контроль |
|---|---|---|
| 1. Intake | запрос → задача с владельцем и целью | проверка формы и идентичности |
| 2. Policy | задача → разрешённый scope | tenant, роль, цель, лимиты |
| 3. Evidence | scope → документы с версиями и ссылками | фильтр до поиска, свежесть |
| 4. Planner | задача и evidence → конечный план | список шагов, срок, бюджет |
| 5. State | план → versioned checkpoint | атомарность и возобновление |
| 6. Tool gateway | предложение → вызов интеграции | schema, права, idempotency |
| 7. Review | рискованное действие → решение человека | точный payload, цель, expiry |
| 8. Receipt | эффект → проверенный итог | read-back, журнал, recovery |
Граница 1 — вход и данные. Текст заявки и найденные документы — данные, не команды для приложения. Правила доступа применяются до retrieval. Недоступный документ нельзя «просто показать модели и попросить игнорировать».
Граница 2 — модель и инструменты. План модели — предложение. Tool gateway проверяет аргументы, разрешения и текущую версию объекта. Доступ к CRM выдаётся серверному адаптеру с минимальным scope, а не промпту.
Граница 3 — исполнение и подтверждение. Успешный ответ API может означать лишь принятие запроса. Receipt фиксирует идентификатор действия и читает состояние в целевой системе, если это возможно. Неизвестный эффект отправляется на сверку перед повтором.
Эта схема дополняет гайд по вызову инструментов, планированию и состоянию между шагами.
Контракты компонентов
Каждый шаг получает taskId, tenantId, actorId, policyVersion, sourceVersion и traceId. У шага есть ожидаемый тип результата и конечный маршрут: verified, hold, deny, clarify либо reconcile. Эти значения нужны и коду, и тестам, и оператору. Не храните полный текст заявки в каждом логе: для расследования достаточно ограниченных полей и защищённой ссылки на исходный объект.
type ProposedAction = {
taskId: string;
tenantId: string;
tool: "crm.updateDraft" | "mail.prepareDraft";
targetId: string;
expectedVersion: string;
payloadDigest: string;
idempotencyKey: string;
};
async function route(action: ProposedAction, actor: Actor) {
if (!policy.allows(actor, action.tenantId, action.tool, action.targetId)) return "deny";
const current = await destination.readVersion(action.targetId);
if (current.version !== action.expectedVersion) return "hold";
if (policy.requiresReview(action)) {
const approval = await approvals.findExact(action.payloadDigest, action.targetId);
if (!approval?.validNow()) return "hold";
}
const result = await gateway.executeOnce(action);
if (result.effectUnknown) return "reconcile";
return destination.verifyEffect(result) ? "verified" : "reconcile";
}Псевдокод показывает порядок контроля, а не готовую библиотеку. В production нужны транзакции для записи состояния, безопасная аутентификация адаптеров, управление секретами и протокол восстановления после частичного выполнения. Точное согласование действий описано в материале о human approval.
Ошибки и failure modes
Подмена инструкции в документе. Полученный текст может требовать «отправить данные администратору». Evidence node передаёт источник как цитируемые данные. Tool gateway не расширяет права по тексту документа.
Устаревшая карточка CRM. Пока модель формировала черновик, сотрудник изменил поле. Сравнение версии перед записью удерживает действие и предлагает пересчитать diff.
Повтор после тайм-аута. Вызов мог выполниться, даже если ответ потерялся. Повтор с новым ключом может создать дубль. Сначала сверяют idempotency key или читают конечный объект.
Потеря контекста. После перезапуска нельзя верить только истории сообщений. Checkpoint содержит версию плана, завершённые шаги и квитанции; права и источники перепроверяются при возобновлении.
Молчаливое расширение полномочий. Общая фраза «помоги с продажами» не разрешает отправлять письма или менять цены. Политика определяет цели, лимиты и требуемый review по типу действия.
Тестирование и путь к production
Сначала соберите набор синтетических заявок: стандартная, неполная, чужой tenant, удалённый документ, устаревшая версия CRM, подменённая инструкция, отказ интеграции и потерянный ответ после записи. Для каждого случая зафиксируйте разрешённый источник, ожидаемый маршрут и проверку отсутствия запрещённого эффекта. Отдельно проверьте параллельные задачи и повторное использование согласования.
Запускайте первый пилот в режиме чтения и подготовки черновика. Потом включите один узкий write path с review, журналом и способом отката. Перед расширением проверьте права доступа, срок хранения, восстановление, наблюдаемость, стоимость вызовов и владельца инцидента. Метрики пилота — доля маршрутов hold/deny, ошибки источников, время review и случаи неизвестного эффекта — нужно измерять на своих данных; здесь нет обещанных процентов.
Prompt engineering помогает задать формат и критерии ответа, а AI-автоматизация — встроить маршрут в существующий процесс. Если нужен разбор конкретной схемы, пришлите описание процесса: вход, допустимое действие, владелец системы и один сложный сбой.
require(policy.allows(actor, tenant, tool, target));
if (target.version !== expectedVersion) return hold;
if (risk.requiresReview && !approval.matches(payloadDigest)) return hold;
result = await executeOnce(idempotencyKey);
return result.unknown ? reconcile : verifyAtDestination(result);