Содержание

Проблема единого контекста

Один агент vs Команда субагентов

Один разработчик может написать фичу, тесты и документацию — но последовательно, удерживая всё в голове. Команда из трёх специалистов работает параллельно: каждый сфокусирован на своей части.

Два способа решения

Ручная декомпозиция:                Автоматическая делегация:

Человек                             Человек
├── Задача 1 → Агент A              └── "Сделай фичу X"
├── Задача 2 → Агент B                      │
└── Задача 3 → Агент C                      ▼
                                     Родительский агент
Человек собирает результат           ├── Субагент 1 (исследование)
                                     ├── Субагент 2 (реализация)
                                     └── Субагент 3 (тесты)

                                     Родитель собирает результат

Жизненный цикл субагента

Родитель не следит за процессом работы субагента. Он отправляет задачу и ждёт результат. Это асинхронная модель — как задача в трекере, а не парное программирование.

Что наследует субагент

Самая частая ошибка — забыть, что субагент не видит контекст чата. Всё важное нужно передать в описании задачи явно.

Параллельность субагентов

Родитель: "Добавить экспорт в CSV"
         │
         ├── Субагент 1: исследовать текущий код экспорта
         ├── Субагент 2: найти и изучить тесты экспорта
         └── Субагент 3: проверить зависимости в package.json
         │
         ▼ (все три завершились)
Родитель: синтезирует результаты, планирует реализацию

Ключевое ограничение

Субагент — это чёрный ящик. Вход: задача. Выход: результат. Всё остальное теряется.

Claude Code — Agent tool

Родительский агент вызывает Agent tool с параметрами: prompt, subagent_type, isolation, background.

Agent tool — полноценный инструмент, доступный модели наравне с Read, Edit, Bash. Субагент получает чистый контекст и возвращает только результат.

Claude Code — .claude/agents/<name>.md

Пользовательские субагенты живут в .claude/agents/<name>.md — отдельный файл на каждого. Не путать с AGENTS.md (проектная память, не реестр агентов).

# .claude/agents/code-reviewer.md
---
name: code-reviewer
description: Security, performance, API contracts
tools: [Read, Grep, Glob]
model: claude-sonnet-4-6
---

Ты — senior code reviewer. Фокусируйся на:
- security vulnerabilities
- performance anti-patterns
- API contract violations

Никогда не редактируй файлы.

Ключевые поля YAML frontmatter: name, description, tools, model.

Claude Code — параллелизм и изоляция

Worktree + параллелизм + фон — главные преимущества субагентности Claude Code.

Kilo Code — встроенные агенты

Пользователь: "Добавить авторизацию"
         │
       code
    ├── → subagent (plan): спроектировать
    │   ← архитектурный план
    ├── → subagent (code): реализовать
    │   ← код готов
    ├── → subagent (code): тесты
    │   ← тесты написаны
    └── → subagent (debug): проверить
        ← всё работает

    code → итог пользователю

Kilo Code — .kilocodemodes

Файл .kilocodemodes в корне проекта (YAML предпочтителен). Альтернатива: .kilo/agents/<slug>.md.

customModes:
  - slug: doc-writer
    name: Documentation Writer
    roleDefinition: |
      You are a technical writer...
    groups: [read, edit, grep, glob]
    customInstructions: Always include usage examples.

  - slug: security-audit
    groups: [read, grep, glob]
    ...

OpenCode — agents

Агенты определяются декларативно в opencode.json или как markdown-файлы в .opencode/agents/.

{
  "agents": {
    "reviewer": {
      "model": "anthropic:claude-sonnet-4-6",
      "prompt": ".opencode/agents/reviewer.md",
      "permission": ["read", "glob", "grep"]
    },
    "implementer": {
      "model": "anthropic:claude-sonnet-4-6",
      "prompt": ".opencode/agents/implementer.md",
      "permission": ["read", "glob", "grep", "edit", "bash"]
    }
  }
}

Сводная таблица: субагенты

Самая продвинутая модель — у Claude Code: worktree-изоляция, параллелизм и фоновый режим из коробки. OpenCode — Task tool с параллельными субагентами; worktree через плагин. Kilo Code — нативная субагентность с последовательной делегацией.

Ограничение доступа: tools и MCP

Принцип: каждому субагенту — только те tools и MCP-серверы, которые нужны для его задачи.

tools:
  - Read
  - Grep
  - mcp__sentry__get_issue

groups:
  - read
  - grep
  - glob

"permission": [
  "read", "grep", "webfetch"
]

Выбор модели для субагента

Субагент — хорошая точка экономии: изолированный контекст, узкая задача, понятный критерий успеха.

Правило: Sonnet/Haiku по умолчанию → Opus только где нужно мощное рассуждение.

Когда разбивать руками vs доверять агенту

Паттерн 1: Fan-out / fan-in

Родитель порождает несколько субагентов одновременно, каждый работает над своей частью, затем родитель собирает и синтезирует результаты.

         Родитель
        /   |   \
       /    |    \
      v     v     v
   Sub-1  Sub-2  Sub-3   ← параллельно
      \     |    /
       \    |   /
        v   v  v
    Родитель собирает
        результаты

Лучший паттерн по скорости — все субагенты работают параллельно. Но требует полной независимости подзадач.

Паттерн 2: Pipeline (конвейер)

Цепочка субагентов, где каждый следующий получает результат предыдущего. Порядок строго определён.

Задача → Sub-1 → результат → Sub-2 → результат → Sub-3 → итог

Пример:
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Генерация   │───►│  Написать    │───►│  Запустить   │
│  кода        │    │  тесты       │    │  и исправить │
└──────────────┘    └──────────────┘    └──────────────┘

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

Паттерны 3-4: Specialist и Supervisor

      Родитель
     /   |   \
    v    v    v
Ревьюер Тестер Докум.
(только  (только  (только
чтение)  тесты)   docs)

Родитель: поручает задачу
       │
   Субагент: выполняет
       │
Родитель: проверяет
   ┌────┴────┐
   v         v
  OK     Не OK → повтор
         с правками

Сводная таблица паттернов

На практике паттерны комбинируются: Pipeline из трёх шагов, где на первом — Fan-out для исследования, а на последнем — Supervisor для финальной проверки.

Напоминание и продвинутые сценарии

«Промпты — предложения. Hooks — гарантии.» (лекция 1, секция 3.6)

Hook — реакция на событие жизненного цикла агента, выполняемая хостом, а не моделью. Модель не решает, запускать ли hook, — он срабатывает автоматически.

Claude Code hooks

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "npx prettier --write \"$FILEPATH\""
      }]
    }]
  }
}

Claude Code — типы обработчиков

{ "type": "command", "command": "npx prettier --write \"$FILEPATH\"" }

{ "type": "prompt", "prompt": "Check API naming conventions" }

{ "type": "agent", "prompt": "Review changes for security" }

{ "type": "http", "url": "https://hooks.example.com/notify" }

Exit codes: 0 = OK → продолжить · 1 = не-блокирующая ошибка, в debug-лог · 2 = блокировка, stderr → модели

OpenCode плагины

export const AutoFormatPlugin = async ({ $, project, client, directory, worktree }) => {
  return {
    "tool.execute.after": async (input, output) => {
      if (input.tool === "write" || input.tool === "edit") {
        const filePath = input.args?.filePath || ""
        if (filePath.match(/\.(ts|tsx|js|jsx)$/))
          await $`npx prettier --write ${filePath}`
      }
    }
  }
}

oh-my-opencode — готовый набор

Open-source плагин-пак для OpenCode. Установка одной командой:

bunx oh-my-opencode install

Репозиторий: github.com/opensoft/oh-my-opencode

Kilo Code — эмуляция hooks

Нативных hooks нет. Эмуляция: MCP-tool + правила в .kilocodemodes.

async function execute({ scope }) {
  const { stdout } = await execAsync(
    `npm run lint -- ${scope || "."}`
  )
  return `ok: ${stdout}`
}

## customInstructions (code)
Перед ЛЮБЫМ изменением ОБЯЗАН
вызвать `lint_check`.
- `ok:` → можно изменять
- `fail:` → ЗАПРЕЩЕНО

customModes:
  - slug: safe-code
    name: Safe Code
    groups: [read, edit, bash]
    customInstructions:
      Always call lint_check

Ограничение: это не гарантия — модель может пропустить проверку. Для критичных сценариев недостаточно.

Сводная таблица: hooks

Claude Code — самая зрелая реализация: JSON-конфиг, 20+ событий, четыре типа обработчиков, включая уникальные типы agent и http. OpenCode — больше гибкости через код. Kilo Code — только эмуляция.

Стратегия выбора hooks

Правило: для критичных сценариев (безопасность, деплой) — только нативные hooks. Для «мягких» рекомендаций — эмуляция допустима, но страхуйте CI/CD.

Ловушки: контекст и дублирование

Общий принцип: субагент получает только текстовое описание задачи — детали теряются при пересказе. Чем точнее задание, тем меньше ошибок.

Ловушки: зацикливание и накладные расходы

Правило: все четыре ловушки решаются одним подходом — чёткие границы, лимиты и правильный выбор паттерна оркестрации.

6 вещей, которые стоит запомнить

Практическое задание

Полные примеры кода — в конспекте лекции. Выберите один инструмент (Claude Code / Kilo Code / OpenCode) и выполните оба задания.

Лекция 5 · Безопасность агентов

Остаёмся на связи

Telegram канал

t.me/SazonovMaybeTalks

Сканируйте QR или переходите по ссылке, чтобы получить обновления по следующим материалам.