Сколько инфраструктуры нужно AI-агенту?

За последние полгода, помогая десяткам команд оценить «переход на Agent», мы чаще всего слышали два крайних сценария: либо покупали только API модели и ждали, что она сама правит прод; либо разворачивали Kubernetes + vector DB + три MCP-сервера + автономную платформу Agent — и через три месяца это уже никто не обслуживал. То, что реально блокирует поставку, редко сводится к «модель недостаточно умна» — чаще расходятся среда исполнения, цепочка верификации и шлюз контекста. Эта статья использует послойную модель Cloud Mac AI Stack, чтобы превратить вопрос «сколько инфраструктуры нужно AI-агенту?» в таблицы решений — вы подбираете стек под размер команды, а не копируете чужой архитектурный shopping list.

1. Почему эта проблема существует: «умеет чатиться» ≠ «умеет поставлять»

После того как слово «Agent» стало перегруженным, многие смешивают чат-интерфейсы с инженерными агентами. Для чата достаточно API модели; инженерный агент должен как минимум читать репозиторий, править файлы, запускать команды и получать объективные сигналы верификации. Отсутствие любого звена проявляется так:

• Агент правит код, но никто не знает, прошли ли тесты — нет L1 Fact (execution engine Runner).
• Агент правит только открытый файл; кросс-модульный рефакторинг — угадывание — нет L4 Context (тройное подключение MCP).
• Каждый инструмент работает сам по себе, но на целый issue уходит 40 минут присмотра — нет L5 Workflow (платформа OpenHands).
• На Windows-ноутбуке нужны сборки Xcode, но у агента нет легальной поверхности исполнения — нет L0 с настоящим macOS (Cloud Mac vs локальный Mac).

Старый рефлекс — «купить более сильную модель»; новый — заполнять слои исполнения и верификации по очереди. Именно это спрашивают клиенты ZavCloud при аренде Cloud Mac — не «хватит ли RAM для Ollama», а какую роль этот узел играет в стеке.

2. Как классифицировать инфраструктуру Agent: шесть слоёв, а не шесть продуктов

Мы используем L0–L5 (согласовано с серией Stack). Важно: слои — это зоны ответственности, а не обязательный shopping list. Solo-разработчик может остановиться на L3; L2 inference (Ollama) опционален на всех уровнях.

Конфликт очевиден: чат-агенты останавливаются до L3; инженерным нужны минимум L0+L3; mergeable — L1; масштабируемым обсуждают L4+L5. Многие команды проваливаются, пропуская слои — например, OpenHands до Runner, и автономные задачи меняют код, а никто не доказывает зелёную сборку.

3. Ключевое сравнение: solo / малая команда / инженерный уровень

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

Железо: когда L0 и L1 делят одну машину (частый случай), ориентируйтесь на эту таблицу — потолок упирается в RAM раньше, чем в модель CPU, потому что Agent, Runner и опциональный Ollama конкурируют за unified memory:

4. Матрица сценариев

Быстрая triage по принципу «если вы X — выбирайте Y»:

5. Рекомендуемые стеки: три рецепта copy-paste

Стек A · Самый быстрый solo-запуск (в течение 1 дня)

L0  Локальный MacBook или Cloud Mac pay-per-day
L3  Claude Code (руководство по установке)
Model  Подписка Anthropic API

Пропустить: Runner, MCP, vector DB, K8s

Стек B · Mergeable для малой команды (1–2 недели)

L0  Cloud Mac M4 16GB always-on узел
L1  GitHub Actions self-hosted Runner (стоит ли?)
L3  Claude Code + командный CLAUDE.md
L4  GitHub MCP read-only (issue-driven)

Опционально L2: Ollama 7B для приватных черновиков, вне критического пути

Стек C · Автономная поставка для инженерной команды (1 месяц+)

L0  Cloud Mac M4 24GB+
L1  Runner · один job одно workspace
L3  Claude Code
L4  MCP triple-connect + CodeGraph
L5  OpenHands (сначала sandbox repo)
Orchestration  OpenClaw triggers + audit (опционально)

Красная линия: prod API / Runner creds никогда в MCP (гид по permissions)

6. Типичные ошибки: пять «не делайте так»

1. Считать API модели полной инфраструктурой. API решает «думать», но не «делать» и «верифицировать».
2. Открывать запись в репо L5 без Runner. Автономный Agent без слоя Fact — слепое письмо; цена отката экстремальна.
3. Строить vector DB + RAG-платформу в первый день. У большинства code Agent узкое место — символический контекст (CodeGraph), а не embedding search.
4. VM на Windows, выдаваемая за macOS CI. Подпись, notarization и device tests всё равно требуют настоящего Apple Silicon.
5. Покупать чужой полный shopping list. Сначала опишите границу исполнения, добавляйте слои инкрементально; глубина стека ≠ численность команды.

7. Внедрение: чеклист из 7 шагов

1. Определить границу исполнения — Перечислите разрешённые действия агента: какие каталоги, shell, prod-триггеры.
2. Подтвердить L0 — Xcode / notarization требуют macOS; оцените аренду vs покупку Mac.
3. Добавить L3 coding Agent — Сначала один файл, один репо; напишите CLAUDE.md / командные нормы промптов.
4. Поднять L1 Runner — Разделите macOS и Linux jobs; отделите secrets от токенов Agent.
5. Добавить L4 MCP по необходимости — Read-only по умолчанию; запись — через short-lived token на отдельном сервисе.
6. Оценить L5 — Две недели всё ещё вручную связываете инструменты → добавьте Workflow класса OpenHands.
7. Аудит и красные линии — Каждая автономная задача привязана к PR + CI run ID; ежеквартальный review матрицы permissions.

FAQ

Заключение

Сколько инфраструктуры нужно AI-агенту, зависит от того, где останавливается граница исполнения — а не от leaderboard моделей. Solo: достаточно начать с L3; организациям, которым нужен merge, — L1; большим репо — L4; автономной поставке — L5. При покупке Cloud Mac или Mac mini спрашивайте, является ли машина «поверхностью исполнения», «поверхностью верификации» или «поверхностью inference» — это полезнее, чем смотреть на TOPS.