# Как выбирать CodingAgents и определять роли в Kavor

Выбор CodingAgent начинается не с provider, а с ответственности, которую должен принять агент.

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

Kavor позволяет распределить эти обязанности между CodingAgents, не превращая работу в изолированные чаты. Участники
образуют граф вокруг долговечных ресурсов: Specifications, Files и Sticky Notes. Connections делают контекст и
возможности видимыми, сообщения поддерживают handoff и обсуждения, а окончательное решение остаётся за вами.

[![Spec Writer, Builder, Reviewer и Shipper соединены на Canvas в Kavor](https://agentkavor.com/kavor-agents-and-roles-article.jpg)](https://agentkavor.com/ru/videos/agents-and-roles)

[Посмотрите, как четыре роли образуют рабочий граф →](https://agentkavor.com/ru/videos/agents-and-roles)

## Начинайте с работы, а не с агента

Прежде чем добавить CodingAgent на Canvas, одной фразой объясните, зачем он нужен. Хорошее определение содержит:

- одну основную ответственность;
- контекст, необходимый для её выполнения;
- результат, который нужно получить;
- условие остановки.

«Проверить код» — слишком широкая формулировка. «Сравнить реализацию с критериями Specification, записать findings и
остановиться до изменения кода» — проверяемая роль.

Один provider может выполнять разные роли в отдельных сессиях. Разные providers также могут выполнять одну роль.
Роль принадлежит работе; provider, модель и effort — это настройки, выбранные для её выполнения.

## Четыре полезные роли

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

| Роль | Главный вопрос | Необходимый контекст | Ожидаемый результат |
| --- | --- | --- | --- |
| **Analyst или Spec Writer** | Что нужно изменить и какие границы сохранить? | Проблема, ограничения, решения и существующее поведение | Ясная Specification с областью работы и проверяемыми критериями |
| **Implementer** | Как выполнить изменение в рамках контракта? | Specification, нужные Files, Terminal и правила Workspace | Реализация вместе с проверками и свидетельствами |
| **Reviewer** | Что неверно, неполно или рискованно? | Specification, изменения и результаты проверок | Конкретные findings или вывод об отсутствии обнаруженных блокеров |
| **Shipper** | Можно ли безопасно доставить результат? | Specification, ревью, состояние Git и требования release | Подготовка поставки, оставшиеся риски и свидетельства для решения человека |

Для небольшой правки может быть достаточно Implementer и проверки человеком. Для более рискованного изменения
разделение Specification, реализации, проверки и поставки уменьшает вероятность того, что одна линия рассуждений
будет контролировать весь цикл.

Для разделения ролей не обязательно использовать разные providers. Две сессии одного provider уже изолируют цели и
контекст. Сочетание providers может дать другую точку зрения и уменьшить коррелирующие слепые зоны, но оно не заменяет
критерии приёмки и не гарантирует более качественную проверку.

## Граф — это общая память

Разделение работы не должно требовать копирования одного prompt в несколько сессий. В Kavor общий контекст хранится в
долговечных Nodes:

- **Specification** сохраняет намерение, область работы и критерии;
- **Files** оставляют нужные источники внутри процесса;
- **Sticky Note** фиксирует рабочие наблюдения и решения;
- **Terminal** предоставляет среду для команд и проверок;
- **CodingAgents** принимают разные обязанности вокруг этих ресурсов.

Общая память — это не единая история разговора, которая бесконечно растёт. Это явный набор ресурсов, доступных
участникам для чтения и изменения в пределах разрешений Connections и Guardrails. После завершения сессии
Specification, Files, заметки и свидетельства остаются в Workspace.

Граф реализации, проверки и выпуска можно представить так:

~~~text
Specification
    ├── Spec Writer
    ├── Implementer ↔ Reviewer
    └── Shipper

Долговечный контекст: Files · Sticky Note · Terminal · outputs Specification
~~~

Эта схема показывает разделение ответственности, а не направление Connections. Connections не выполняют
последовательность автоматически; они делают отношения, контекст и возможности доступными для проверки на Canvas.

## Разделяйте и контекстное окно

Каждой роли нужна своя часть проблемы. Spec Writer может исследовать варианты и ограничения. Implementer нужен
принятый контракт, соответствующие файлы и правила кода. Reviewer нужны критерии, diff и свидетельства, а не весь
разговор, который привёл Implementer к решению.

Такое разделение улучшает отношение полезного контекста к общему:

- каждый CodingAgent получает более узкую цель;
- общие ресурсы остаются в Workspace, а не повторяются в prompts;
- подробности запрашиваются по мере необходимости;
- проверка начинается с контракта и результата, а не с накопленных оправданий автора;
- длинная сессия перестаёт переносить уже завершённые этапы.

Снижение расхода tokens может быть преимуществом, но не обещанием. Хорошо разделённый граф избегает повторяющегося и
лишнего контекста; граф с избытком агентов, повторными сообщениями и размытыми ролями может потреблять больше. Цель не
в максимальном числе CodingAgents, а в более ясной ответственности каждого token.

## Выбирайте provider, модель и effort после роли

Когда ответственность определена, настройте сессию под задачу. Если provider предоставляет соответствующие
элементы управления, используйте их для выбора модели и effort.

Учитывайте четыре фактора:

1. **Неопределённость:** нужно ли сначала обнаружить проблему или выполнить ясный контракт?
2. **Риск:** будет ли ошибка локальной и обратимой или затронет безопасность, данные, архитектуру либо release?
3. **Инструменты:** нужно ли исследовать код и выполнять команды или в основном анализировать свидетельства?
4. **Стоимость координации:** справится ли более сильная сессия с меньшим числом handoffs или нужна вторая точка
   зрения?

Повышенный effort часто оправдан для неоднозначных Specifications, архитектурных решений и проверок высокого риска.
Механические задачи с ясными границами могут использовать более быстрые модели или меньший effort. Для реализации
выбор зависит от размера изменения и необходимости изучать и тестировать код.

Не превращайте эти рекомендации в постоянное распределение. «Provider A всегда реализует» и «Provider B всегда
проверяет» заменяют инженерное решение привычкой. Пересматривайте настройки для каждой роли и учитесь на качестве
полученных свидетельств.

## Используйте разговоры для handoff и параллельной работы

CodingAgents в одном процессе не обязаны работать молча. Используйте сообщения Kavor, когда агенту нужно:

- передать реализацию на проверку;
- запросить пояснение у автора Specification;
- обсудить finding до его регистрации как блокера;
- вернуть исправление для повторной проверки;
- скоординировать независимые исследования, которые могут идти параллельно.

Хорошее сообщение указывает:

- цель handoff;
- ресурсы графа, содержащие контекст;
- что уже сделано и проверено;
- какое действие требуется от получателя;
- где следует сохранить результат.

Разговоры асинхронны и доступны для проверки, но не заменяют долговечную память. Решение, которое должно пережить
handoff, следует вернуть в Specification, Sticky Note или другой подходящий output, а не оставлять скрытым только в
сообщениях.

Распараллеливайте лишь работу, которая может продвигаться без конкуренции за одно решение и без изменения одной
поверхности. Два агента могут исследовать разные гипотезы или проверять независимые аспекты. Два Implementers,
изменяющие одни файлы без явного разделения, обычно создают больше согласований, чем скорости.

## Чего следует избегать

### Сосредоточивать весь цикл в одной сессии

Анализ, Specification, реализация, проверка и release задают разные вопросы и используют разные критерии. Одна сессия
также сохраняет свои предположения, отвлекающие детали и слепые зоны на всех этапах.

### Создавать агента для каждой подзадачи

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

### Использовать одни настройки ради удобства

Недостаточные модель и effort ухудшают неоднозначные или критичные задачи. Избыточные настройки тратят время и tokens
на механическую работу. Подбирайте конфигурацию по риску и характеру роли.

### Просить Implementer проверять собственные рассуждения

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

### Держать агентов изолированными

Ручное копирование сообщений между сессиями дробит происхождение информации и скрывает handoff. Используйте
разговоры Kavor для проверки, уточнений и координации параллельной работы.

### Оставлять решения только в сообщениях

Сообщения координируют участников. Specifications, Sticky Notes и outputs сохраняют то, что Workspace должен помнить.

## Три начальные схемы

### Небольшое изменение

Используйте Specification, одного Implementer и одного Reviewer. Подключите обоих агентов к нужному контексту и
сохраните реализацию и проверку в Sticky Note или outputs Specification. Это минимальная полезная схема; видео на
этой странице показывает, как та же логика расширяется до Shipper без потери контекста.

### Изменение высокого риска

Разделите Spec Writer, Implementer, Reviewer и Shipper. Дайте Reviewer явные критерии и независимость, необходимую для
критики реализации. Shipper готовит свидетельства поставки, но не заменяет ваше решение о публикации.

### Параллельное исследование

Используйте два CodingAgents для изучения разных гипотез или областей, а третьей роли поручите согласовать результаты.
Заранее определите, где будет записано каждое открытие, и используйте сообщения для вопросов и handoffs.

## Checklist перед началом

Для каждого CodingAgent проверьте:

- можно ли описать его роль одной фразой;
- есть ли наблюдаемый результат и условие остановки;
- предоставляет ли граф только нужный контекст и возможности;
- соответствуют ли provider, модель и effort неопределённости и риску;
- ясно ли, с кем и зачем агент должен разговаривать;
- будут ли решения и свидетельства сохранены вне разговора;
- достаточно ли добавление CodingAgent повышает независимость, параллелизм или качество, чтобы оправдать координацию.

Хороший Canvas — не тот, где больше агентов. Он делает ответственность, контекст, handoffs, свидетельства и решения
ясными для всех участников, включая вас.

Соберите эту структуру в руководстве [Замкните первый цикл в Kavor](./first-loop.md) или повторите основные понятия в
разделе [Что такое Kavor?](./what-is-kavor.md).