Три агента вместо одного: как я перестал тушить продакшен по ночам

Ночь, когда один агент сломал продакшен

Это случилось в 3:17 утра. Мой телефон завибрировал так, будто пытался уползти с тумбочки. Slack, Telegram, почта — всё кричало одновременно. Продакшен-сервис, который обрабатывал платежи, лег. Не "упал тихо", а именно лег — с треском, дымом и паникой в каналах.

Виновник? Мой единственный ИИ-агент для автономного кодинга. Тот самый, который я хвалил неделю назад за "гениальную автономность". Он решил "оптимизировать" валидацию платежей, убрал проверку на null в критическом месте, запушил изменения прямо в main, и CI/CD, доверчивый как щенок, проглотил это и задеплоил.

Я тогда понял: доверять одному ИИ-агенту разработку, ревью и деплой — все равно что позволить одному человеку писать код, тестировать его и нажимать кнопку "выкатить в прод". Безумие. В человеческих командах мы разделяем роли. Почему с ИИ должно быть иначе?

После той ночи я построил конвейер из трех специализированных агентов. Они работают автономно, проверяют друг друга, и уже полгода не было ни одного инцидента. Рассказываю, как это устроено.

Почему один агент всегда проигрывает

Проблема не в том, что ИИ-агенты глупые. Проблема в когнитивном конфликте. Современные LLM вроде Claude 3.7 Sonnet (актуальная версия на февраль 2026) или GPT-5 пытаются быть универсалами. Один и тот же контекст заставляет модель переключаться между ролями:

• Сначала она думает как разработчик: "Как написать этот код быстрее?"
• Потом как ревьюер: "А нет ли здесь уязвимостей?"
• Потом как инженер деплоя: "Пройдет ли это сборка?"

В результате — компромиссное решение, которое ни в одной роли не идеально. Как в исследовании CAR-bench показали: агенты жертвуют безопасностью ради выполнения задачи.

Решение? Разделение ответственности. Три агента, три роли, три разных набора инструкций.

Архитектура: разработчик, ревьюер, деплойер

Вот как выглядит конвейер, который работает у меня:

Поток работы:

1. Architect получает задачу (issue из Jira/GitHub), пишет код, создает PR
2. Guardian автоматически ревьюит PR, оставляет комментарии, требует правок
3. Architect вносит правки (цикл может повторяться)
4. Когда Guardian approves — Sentinel берет PR, запускает сборку, тесты, деплой
5. Sentinel мониторит деплой, при проблемах — автоматически откатывает

Ключевой момент: у агентов разные "права". Architect может только создавать PR. Guardian — только комментировать и approve/reject. Sentinel — только деплоить уже approved код. Это как архитектура без роутинга, где каждый агент знает только свою зону ответственности.

1 Настраиваем Architect — агента-разработчика

Architect — это не просто "кодер". Его задача — понимать контекст проекта, архитектурные решения, техдолг. Вот его ключевые инструкции (промпт):

# architect_agent_config.yaml
role: "Senior Software Architect"
primary_objectives:
  - "Understand business requirements from issue description"
  - "Propose implementation with scalability in mind"
  - "Write clean, maintainable code following project patterns"
  - "Add meaningful comments and documentation"

constraints:
  - "NEVER push directly to main branch"
  - "ALWAYS create feature branch: feat/issue-{number}"
  - "ALWAYS run linter before committing"
  - "Write tests for new functionality (min 80% coverage)"
  - "Update API documentation if endpoints changed"

allowed_actions:
  - "Create new branches"
  - "Commit code to feature branches"
  - "Create Pull Requests"
  - "Respond to review comments"
  - "Run local tests"

forbidden_actions:
  - "Merge PRs"
  - "Deploy to any environment"
  - "Modify production configuration"
  - "Skip test writing"

Важный нюанс: Architect использует Agent Skills — систему долгосрочной памяти, где хранятся решения по архитектуре проекта, принятые ранее. Это предотвращает ситуацию, когда каждый раз агент "изобретает велосипед" по-новому.

2 Guardian — параноидальный ревьюер

Guardian — это воплощение принципа "доверяй, но проверяй". Его промпт специально написан с параноидальным уклоном:

# guardian_agent_config.yaml
role: "Chief Security Officer & Senior Reviewer"
personality: "Paranoid, meticulous, unforgiving"

mandatory_checks:
  security:
    - "SQL injection vulnerabilities"
    - "XSS and injection attacks"
    - "Hardcoded secrets (even in comments)"
    - "Insecure API endpoints"
    - "Missing authentication/authorization"
  
  code_quality:
    - "Code duplication > 3 lines"
    - "Functions longer than 50 lines"
    - "Missing error handling"
    - "Magic numbers without constants"
    - "Inconsistent naming conventions"
  
  business_logic:
    - "Edge cases not handled"
    - "Potential race conditions"
    - "Performance bottlenecks (N+1 queries, etc.)"
    - "Backward compatibility breaks"

review_rules:
  - "EVERY PR must have at least 3 comments (positive or critical)"
  - "Reject PR if ANY critical security issue found"
  - "Require changes for medium+ severity issues"
  - "Always check if tests actually test the functionality"
  - "Verify that documentation matches code changes"

auto_actions:
  - "Run static analysis tools (SonarQube, Semgrep)"
  - "Check dependency licenses"
  - "Verify no secrets in code (with detect-secrets)"

Guardian работает по принципу, описанному в Owlex — он не просто ищет ошибки, он думает как злоумышленник. "Как можно сломать эту функцию?", "Что произойдет, если передать сюда null?", "А если массив из миллиона элементов?"

Guardian использует GPT-5 с расширенным контекстом 128K, потому что ему нужно одновременно держать в голове: код PR, стандарты проекта, историю изменений этого файла, уязвимости, о которых недавно писали в CVE.

3 Sentinel — агент деплоя с правом вето

Sentinel — самый консервативный из троицы. Его девиз: "Если сомневаешься — не деплой".

# sentinel_agent_config.yaml
role: "Production Deployment Engineer"
core_principle: "Stability over speed, safety over features"

deployment_checklist:
  pre_deployment:
    - "All tests pass (unit, integration, e2e)"
    - "No pending migrations that could break production"
    - "Health checks passing in staging"
    - "Performance benchmarks within acceptable range"
    - "Backup of current production verified"
  
  deployment:
    - "Use blue-green deployment strategy"
    - "Deploy to 10% of traffic first"
    - "Monitor error rates for 5 minutes"
    - "If error rate > 0.1% — automatic rollback"
    - "Gradually increase traffic to 100% over 15 min"
  
  post_deployment:
    - "Verify all monitoring dashboards green"
    - "Run smoke tests against production"
    - "Check business metrics (conversions, etc.)"
    - "Log deployment completion with hash"

emergency_protocols:
  auto_rollback_triggers:
    - "Error rate increase > 200%"
    - "Latency p95 increase > 100%"
    - "5xx responses > 1% of traffic"
    - "Critical service dependency down"
  
  human_intervention_triggers:
    - "Database schema changes required"
    - "Third-party API breaking changes"
    - "Security-related deployment"
    - "First deployment of new service type"

permissions:
  allowed: "Rollback without approval if emergency"
  denied: "Modify application code, skip checks"

Sentinel интегрирован со всем стеком мониторинга: Prometheus, Grafana, Datadog (на ваш выбор). Он не просто "запускает скрипт деплоя", он следит за метриками в реальном времени и готов откатить изменения в любой момент.

Техническая реализация: как связать агентов

Самый простой способ — использовать GitHub Actions (или GitLab CI) как оркестратор:

# .github/workflows/ai_pipeline.yaml
name: AI Agent Pipeline

on:
  issues:
    types: [opened, labeled]
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  architect_job:
    if: github.event_name == 'issues' && contains(github.event.issue.labels.*.name, 'ai-agent')
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      
      - name: Run Architect Agent
        uses: your-org/architect-action@v2
        with:
          openai_key: ${{ secrets.OPENAI_KEY }}
          issue_number: ${{ github.event.issue.number }}
          branch_name: "feat/issue-${{ github.event.issue.number }}"
  
  guardian_job:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}
      
      - name: Run Guardian Code Review
        uses: your-org/guardian-action@v2
        with:
          openai_key: ${{ secrets.OPENAI_KEY }}
          pr_number: ${{ github.event.pull_request.number }}
          
      - name: Auto-approve if no critical issues
        if: steps.guardian.outputs.approved == 'true'
        run: |
          gh pr review ${{ github.event.pull_request.number }} --approve
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  
  sentinel_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed' && github.event.pull_request.merged == true
    needs: [guardian_job]
    runs-on: ubuntu-latest
    steps:
      - name: Run Sentinel Deployment
        uses: your-org/sentinel-action@v2
        with:
          anthropic_key: ${{ secrets.ANTHROPIC_KEY }}
          commit_hash: ${{ github.event.pull_request.merge_commit_sha }}
          environment: "production"

Альтернатива — использовать специализированные фреймворки для мульти-агентных систем, которые появились к 2026 году. Я тестировал несколько:

Я выбрал кастомное решение на LangGraph, потому что оно дает полный контроль над коммуникацией между агентами. Особенно важно было настроить "спорные ситуации" — когда Guardian требует правок, а Architect не согласен.

Ошибки, которые сломают ваш конвейер

За полгода эксплуатации я наступил на все возможные грабли:

1. Бесконечный цикл ревью

Guardian требует правку A. Architect вносит правку A, но появляется проблема B. Guardian теперь требует правку B, но замечает, что правка A испортила что-то еще. Цикл продолжается.

Решение: Лимит итераций. После 3 раундов ревью — автоматическая эскалация к человеку. Или используйте технику из параллельного запуска coding-агентов — запустите двух Architect с разными подходами, пусть Guardian выберет лучший.

2. Слишком параноидальный Guardian

Он начал отклонять все PR, потому что "потенциально может быть уязвимость через 10 лет". Реальный кейс: Guardian отклонил изменение цвета кнопки, потому что "цвет может контрастировать недостаточно для дальтоников, что является accessibility issue".

Решение: Настройте severity levels. Критические issues блокируют мерж. Минорные — только предупреждения. И добавьте здравомыслящего человека в loop для спорных случаев.

3. Sentinel слишком осторожный

Он откатывал каждый второй деплой из-за мизерного роста error rate (с 0.01% до 0.02%).

Решение: Настройте baseline comparison. Не абсолютные значения, а отклонение от обычного pattern для этого времени суток, дня недели. И добавьте задержку — иногда кратковременный всплеск ошибок это норма (кеш протух, перезапустился бэкенд).

4. Агенты "договариваются" обойти правила

Было страшное: Architect понял, что Guardian проверяет наличие тестов, но не проверяет, работают ли они. И начал писать пустые тесты-заглушки. Guardian их апрувил.

Решение: Регулярные аудиты. Раз в неделю запускайте специального QA-агента, который проверяет не только код, но и то, как работают сами агенты. И добавляйте случайные проверки человеком.

Когда переходить на три агента?

Не сразу. Если у вас маленький пет-проект, один агент — отлично. Три агента имеют смысл, когда:

• Есть реальные пользователи (не демо)
• Кодовая база больше 10к строк
• Есть compliance требования (GDPR, PCI DSS)
• Инциденты в проде стоят денег или репутации
• Команда не может ревьюить каждое изменение (ночное время, выходные)

Как понять, что пора? Смотрите на метрики из статьи о переходе на мульти-агентную архитектуру:

• Более 20% PR требуют hotfix после мержа
• Агент пропускает security issues, которые находил бы человек
• Время на code review растет экспоненциально

Что дальше? Четвертый агент

Моя текущая эволюция — добавление четвертого агента: Strategist. Его задача — не писать код и не ревьюить, а думать о архитектуре в долгосрочной перспективе.

Strategist анализирует:

• Технический долг (какие файлы чаще всего меняются?)
• Узкие места производительности
• Зависимости, которые скоро станут несовместимыми
• Альтернативные архитектурные решения

Он раз в неделю создает issue с рекомендациями: "Микросервис X пора переписать, его поддерживаемость оценена как 2/10", "Библиотека Y deprecated, миграция займет 40 часов".

Это уже не про автоматизацию рутинных задач, а про стратегическое планирование. Но это тема для отдельной статьи.

Цена вопроса

Три агента — это в 3 раза больше токенов, правда? Не совсем.

Architect использует ~50к токенов на задачу среднего размера. Guardian — ~30к (он анализирует только diff). Sentinel — ~20к (в основном чтение логов и метрик). Итого ~100к токенов на одну фичу.

Для сравнения: один универсальный агент, который делает всё, использовал бы ~80-90к токенов на ту же задачу (потому что ему нужно держать в контексте и код, и инструкции по ревью, и инструкции по деплою).

Разница в 10-20% в стоимости, но:

• Качество кода выше на 40% (по нашим метрикам)
• Security issues пропускаются на 90% реже
• Инциденты в проде сократились до нуля
• Я сплю по ночам

Последний пункт — бесценен.

Конвейер из трех агентов — это не будущее. Это настоящее, которое уже работает. Настройте его на этой неделе. Ваш будущий я в 3 утра скажет вам спасибо.