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

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

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

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

Посмотрите, как четыре роли образуют рабочий граф →

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

Прежде чем добавить 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.

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

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 или повторите основные понятия в разделе Что такое Kavor?.