Мультиагентные команды и DevOps-pipeline
Один агент в IDE — уже мощно. В продакшене и в зрелых командах часто работают несколько агентов и несколько моделей — Claude для архитектурного ревью, Codex или Cursor Agent для кода, DeepSeek или Qwen для дешёвых черновиков, Gemini для длинного контекста, Grok — для быстрых итераций. AgentOps здесь — про то, как они передают задачи, не ломают репозиторий и проходят тот же CI/CD, что и люди.
Обзор дисциплины — AgentOps — операции с ИИ-агентами.
Типовые роли в мультиагентной команде
| Роль | Задача | Частый выбор модели |
|---|---|---|
| Planner / PM | Декомпозиция, acceptance criteria | Модель с сильным reasoning |
| Coder / Implementer | Патч, тесты, refactor | Быстрая coding-модель |
| Reviewer | Diff, security, стиль | Отдельная модель или тот же с другим system prompt |
| Ops / Deployer | IaC, pipeline, runbook | Агент с ограниченным toolset |
| Orchestrator | Маршрутизация, лимиты, handoff | Код (LangGraph, Temporal) или meta-agent |
Роли могут быть отдельными процессами (Cloud Agent в фоне, CI job, локальный subagent) или сессиями одного хоста (Cursor: parent agent + Task tool с subagent_type).
Как агенты "обсуждают" и передают работу
Shared artifact — самый надёжный паттерн. Агенты не «разговаривают в чате», а пишут в общее хранилище:
- issue / ticket с чек-листом;
docs/design/FEATURE.md— спека;- комментарии в PR;
agent-transcripts/или trace ID в описании PR.
Message bus — очередь (Redis, SQS) или orchestration framework (LangGraph, CrewAI, AutoGen). Planner кладёт задачу, Coder забирает, Reviewer подписан на событие pr.opened.
Handoff prompt — orchestrator передаёт следующему агенту сжатый контекст — цель, сделанные шаги, ошибки, ссылки на файлы. Без этого каждый агент заново "изобретает" архитектуру.
Debate / critique — два агента генерируют альтернативы, третий (или человек) выбирает. Дорого по токенам; оправдано на security review и миграциях данных.
Coder и Reviewer могут зациклиться — "исправь" → "ещё замечание" → … Лимит раундов, эскалация человеку, финальный arbiter с жёстким rubric.
Git, ревью и merge
Агенты используют те же правила, что команда людей — см. Git и GitFlow.
Типичный flow
- Orchestrator создаёт ветку
agent/ISSUE-123-fix-login. - Coder коммитит атомарные commits с понятными сообщениями (правила из user rules / AGENTS.md).
- Push → Pull Request; в body — trace ID, модель, список tools.
- Reviewer-агент (или bot) оставляет review comments; обязательный human approve на prod-критичных репо.
- CI — lint, unit, integration, agent eval на golden tasks.
- Merge → CD на staging → smoke → prod по стратегии выката.
Что запрещать агентам без явного approve
git push --forceна shared branches;- merge в
mainбез green CI; - прямой
kubectl apply/terraform applyв prod — только через pipeline с IaC review.
Cursor и аналоги часто дают агенту git_write и shell — это реальные права. Политика "агент только на feature-ветке + PR" должна быть в rules, а не надеждой.
Несколько моделей — routing
| Критерий | Routing |
|---|---|
| Сложность задачи | Hard → Claude/GPT-4 class; рутина → smaller / local |
| Контекст | Длинный repo → Gemini / модель с большим окном |
| Стоимость | Черновик на DeepSeek/Qwen; финальный patch на premium |
| Latency | Интерактив в IDE — fast model; nightly batch — cheap |
| Compliance | Данные не покидают перimeter → self-hosted (Ollama, vLLM) |
Model router — тонкий слой (конфиг YAML или код), который выбирает endpoint по тегу задачи — plan, code, review. Логи router'а — часть AgentOps tracing.
CI/CD и инфраструктура под агентов
Runner / sandbox
- Изолированная VM или container per agent run;
- Secrets через vault CI, не в промпте;
- Network egress allow-list (только GitHub API, npm, internal registry).
Pipeline stages для agent-generated PR
| Stage | Назначение |
|---|---|
lint / typecheck | Отсечь нейрослоп |
unit + integration | Как для human PR |
agent-eval | Golden prompts → expected tool sequence / diff shape |
security scan | SAST, secret scan, dependency audit |
deploy preview | Ephemeral env для human QA |
IaC для agent infrastructure
- Terraform module — runner pool, observability backend (Langfuse self-host), queue;
- Ansible — конфиг агентских хостов, MCP servers;
- GitOps — desired state agent policies в репозитории.
Observability — trace каждого run linked to commit_sha и pr_number; метрики "стоимость PR", "время до merge", "% PR без human edits" — см. мониторинг и Инструменты AgentOps.
Практические сценарии
Cursor Cloud Agents / фоновые агенты — задача в issue, агент в облаке, результат PR. Человек triage утром.
PR bot — на каждый PR reviewer-агент + auto-fix trivial comments (imports, typos) вторым commit.
On-call copilot — read-only доступ к logs/metrics через MCP; runbook в skills; без auto-remediation в prod без approve.
Split-to-PRs — один planner разбивает монолитный diff на серию маленьких PR (skill split-to-prs в Cursor).