Как собрать управляемый агентный стек

Разговор начинается с разных уровней выбора. Руководство компании отвечает за риск всей экосистемы: утечки, персональные данные, секреты и цену ошибочного действия. Разработчик выбирает инструмент под конкретную задачу и думает о качестве, удобстве и доступности завтра. Поэтому дилемма build versus buy слишком груба: организация скорее проводит границу труда между собой и поставщиками, оставляя внутри то, что определяет её риск и конкурентное преимущество.

Рабочая формула выпуска состоит из пяти частей. Harness поддерживает агентный цикл и поставляет контекст; модель рассуждает и предлагает tool calls; инструменты создают реальный эффект; идентичность показывает, от чьего имени выполняется действие; технические границы ограничивают процессы, сеть, файловую систему и capabilities. Open source не гарантирует local inference, self-hosted модель не делает действия безопасными, а внутренний MCP без узких прав способен открыть агенту больше, чем предполагалось.

Восемь конфигураций образуют карту компромиссов, а не рейтинг. На одном краю — автономный air-gapped стек со своей обвязкой, моделью и эксплуатацией; рядом — готовый клиент с локальной моделью. Другие варианты используют собственный harness с внешним API, вендорского агента с внутренними инструментами, полный SaaS, multi-model router, внешний planner с внутренним executor или личный набор клиента, SaaS и MCP. Каждая комбинация по-разному распределяет TCO, lock-in, свежесть модели и операционную ответственность.

Практический корпоративный центр тяжести — два контролируемых choke point. Model gateway классифицирует контекст, выбирает разрешённые provider, регион и модель, фильтрует секреты, применяет бюджет и безопасный fallback. Tool gateway проверяет identity, policy, scopes, dry-run и фактический эффект, сохраняя аудит. Это позволяет отдать frontier-модели планирование, но не credentials: наружу уходит санитизированный контекст или типизированный план, а выполнение остаётся внутри с on-behalf-of правами и проверкой бизнес-инвариантов.

Модель угроз строится от поверхности атаки и ценности данных, а не от моды на максимальную изоляцию. Недоверенный README, issue, письмо или вывод инструмента может превратить легитимную задачу в prompt injection. Риск проходит через все границы: workspace — harness — model — tool gateway — целевая система. Отдельный класс проблем возникает, когда агент наследует полную человеческую идентичность и получает право не только прочитать таблицу, но и изменить или удалить её.

Политика поэтому должна исполняться вне модели: OS sandbox, deny-by-default egress, least privilege, короткоживущие credentials, allowlist инструментов, разделение read, propose, write и commit, независимая проверка эффекта и kill switch. Выбор начинается с трёх вопросов: могут ли данные покидать trust zone, должен ли агент действовать во внутренних системах и есть ли масштаб вместе со зрелыми evals. Конфигурация выбирается под ответы, а не под логотип клиента.