# CodingAgent в Kavor: любимый harness как часть графа

CodingAgent — ваш агент программирования, работающий в нативном интерфейсе своего provider и теперь видимый как
участник Canvas.

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

[![Селектор provider в toolbar Kavor перед добавлением CodingAgent на Canvas.](https://media.agentkavor.com/demos/coding-agent-provider-selector/poster.22c2dccb70c5.jpg)](https://agentkavor.com/ru/videos/coding-agent-provider-selector)

## Чем владеет CodingAgent

Каждый CodingAgent представляет отдельную сессию. Node хранит настройки и состояние для этой роли: выбранный
provider, а когда provider предоставляет такие возможности — модель, уровень effort, разрешения и нативную сессию.

Provider — настройка CodingAgent, а не другой вид Node. Селектор включает:

- Anthropic Claude Code;
- OpenAI Codex;
- Google Antigravity;
- xAI Grok;
- SST OpenCode.

При добавлении CodingAgent через toolbar сначала выбирается provider, затем сессия настраивается под работу. Набор
опций может различаться: Kavor сохраняет реальные возможности каждого harness, а не делает вид, что у всех один
контракт.

## Что он делает сам

Даже без Connection CodingAgent остаётся provider-native сессией внутри Workspace. С ним можно общаться, использовать
инструменты harness и удерживать работу в пределах root этого Workspace.

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

Connection превращает изолированную сессию в участника системы работы.

## Что он получает в графе

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

У прямых Connections с CodingAgent есть точные роли:

| Connection | Что она добавляет |
| --- | --- |
| **CodingAgent + Specification** | Помещает в граф долговечные намерение, область и критерии. Может содержать `specification_read_only`. |
| **CodingAgent + Sticky Note** | Добавляет общую неформальную память для открытых решений, прогресса и findings. Может содержать `sticky_note_read_only`. |
| **CodingAgent + File** | Делает канонический источник в filesystem явной частью работы. Может содержать `file_read_only`. |
| **CodingAgent + Terminal** | Позволяет выполнять команды, наблюдать процессы и читать свидетельства из shell. Может содержать `terminal_read_only`. |
| **CodingAgent + CodingAgent** | Объединяет участников в один компонент. Достижимые CodingAgents могут обмениваться асинхронными сообщениями и читать нужный для координации контекст. |
| **Trigger + CodingAgent** | Выбирает активную сессию прямой целью запланированного prompt. Trigger не запускает закрытую вами сессию. |

Достижимость не отменяет прямые контракты. Если точная Connection между CodingAgent и ресурсом содержит Guardrail,
ограничение продолжает действовать для этой пары, даже когда в графе существует другой путь.

## Три полезные схемы

### Реализация по контракту

Соедините Specification, CodingAgent в роли Implementer и Terminal. Агент читает контракт в источнике, изменяет
только необходимую область, выполняет проверки и регистрирует outputs в Specification.

Намерение остаётся вне истории беседы, а свидетельства — внутри Workspace.

### Разделение реализации и проверки

Используйте разные сессии для Implementer и Reviewer. Оба достигают одной Specification и свидетельств, но получают
разные вопросы.

Implementer спрашивает «как выполнить контракт?». Reviewer — «действительно ли результат выполняет контракт и какие
риски остались?». Разделение снижает вероятность того, что проверка автоматически унаследует предпосылки автора.

### Сочетание providers без соревнования

Разные providers могут участвовать в одном графе. Сочетайте их, когда иной интерфейс, модель или ход рассуждений
улучшает конкретную ответственность.

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

## Практический граф

```text
Specification — Implementer — Reviewer
                    │            │
                  Terminal    Sticky Note
                    │
                   File
```

Линии обозначают Connections без сохранённого направления. Все Nodes находятся в одном достижимом компоненте.
Implementer исполняет контракт, Reviewer независимо оценивает результат, а Sticky Note оставляет вопросы и findings
видимыми для решения человека.

Это не автоматическая последовательность. Сообщения координируют handoffs; Specifications и другие ресурсы сохраняют
то, что должно пережить сессии; вы решаете, когда принять работу.

## Более точный начальный prompt

Для Implementer:

> Реализуй только область, заданную достижимой Specification. До изменения кода определи нужные Files и проверки.
> Используй Terminal для получения свидетельств, зарегистрируй результат как output Specification и попроси
> Reviewer дать независимую оценку. Остановись, если необходимое решение выходит за рамки контракта.

Для Reviewer:

> Сравни реализацию и свидетельства с критериями Specification. Ищи неверное поведение, пропущенные сценарии,
> регрессии и операционные риски. Сначала запиши конкретные findings и не одобряй работу только потому, что
> существующие тесты прошли.

## Важные ограничения

- Визуальная близость не даёт CodingAgent доступ; нужен путь из Connections.
- Ссылка на Node в сообщении не предоставляет доступ.
- Guardrail ограничивает прямую пару, которой принадлежит; это не глобальная политика Workspace.
- Сообщения координируют работу, но не должны быть единственным хранилищем долговечного решения.
- Providers не обязательно предоставляют одинаковые модели, разрешения, события и операции сессии.
- Trigger доставляет prompt активной сессии; он не расширяет разрешения и не гарантирует, что внешний эффект
  произойдёт ровно один раз.
- Разрешение редактировать Canvas не разрешает удалять Nodes или менять Guardrails; эти границы остаются за человеком.

## Перед запуском сессии

Проверьте:

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

CodingAgent становится полезнее не от более длинного prompt, а когда ответственность, контекст, инструменты,
сотрудничество и границы образуют согласованную схему.

Продолжите в [Как выбирать CodingAgents и определять роли](./agents-and-roles.md), узнайте,
[как CodingAgents видят и строят Canvas](./coding-agents-and-canvas.md), или откройте
[матрицу поддерживаемых Connections](./connections.md).