Context isolation и worktree isolation

1. После tools и scoped knowledge остаётся вопрос среды

Когда вы впервые слышите про изоляцию, легко решить, что это просто «ещё одна настройка безопасности». На практике она нужна уже после того, как вы сузили агенту и права, и контур знаний. Даже идеально ограниченный по правам агент испортит вам работу двумя способами. Либо завалит основную сессию промежуточными чтениями, grep-выводом и логами. Либо начнёт писать в то же рабочее дерево, где вы уже правите файлы руками.

Представьте, что основная сессия — это ваш рабочий стол. Вы дали коллеге задачу: «Проверь, как в Commerce OS устроен refund flow». Вернулся с короткой сводкой и тремя ссылками — счастье. Притащил на стол весь архив отдела за три года — уже не рабочий стол, а документальный сериал. Это проблема без context isolation.

С worktree история другая. Агент образцово лаконичен в контексте, но пишет код в том же checkout, где вы ведёте свои изменения — и diff распух, непонятно, где ваши правки, где агентские, а git status смотрит на вас осуждающе. Изоляция защищает не мысли, а файлы.

Полезно держать различие перед глазами:

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

2. Context isolation: защищаем ход мысли сессии

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

Context isolation — это когда подзадача уходит в отдельное контекстное окно. Чаще всего subagent со своей рабочей памятью: читает файлы, анализирует, а в основную сессию возвращает только краткую сводку. Не весь маршрут рассуждения, не двадцать кусков grep-вывода, не полкода из трёх пакетов — короткий результат с опорой на evidence.

На примере Workflow Kit это хорошо видно на agents/tester.md. Иногда нужен не основной рабочий tester, который пишет test-файлы, а узкий read-only вариант для разведки. Предположим, вы расследуете странное поведение refund flow в Commerce OS: какие тесты есть, а каких нет. Править нечего — пройтись по support/, payments/, orders/, найти тестовые классы, посмотреть regression-пробелы, вернуться с компактной сводкой. Investigation-only вариант:

---
name: tester
description: Анализирует пробелы в тестах refund flow и не меняет production-код
tools:
  - Read
  - Grep
  - Bash
# read-only investigation variant: здесь tester только собирает evidence
---

Здесь важно не только то, что у агента нет Edit. Важно и то, что вы используете его именно как изолированного исследователя: основная сессия не должна видеть всё, что он читал по дороге. Ей нужен результат вроде «Нашёл три тестовых набора, нет regression check на partial refund, вероятная точка добавления теста — RefundPolicyServiceTest». Выгрузить в основную сессию пять экранов промежуточных заметок — значит сделать context isolation и тут же своими руками её отменить.

Хороший практический ориентир такой: изоляция нужна, когда агент много читает, сравнивает и фильтрует, а вы хотите сохранить главную сессию чистой. Особенно для исследования архитектуры, поиска пробелов в тестах, проверки чувствительных зон безопасности, анализа логов или документации. Но не переусердствуйте: один test file и один service class отдельного subagent не стоят.

Есть и ещё одна тонкая ошибка: «Раз агент работал в отдельном окне, результату можно доверять больше». Нет. Context isolation защищает чистоту основной сессии, но не корректность вывода. Агент по-прежнему ошибается и пропускает файлы. Изоляция тут — хороший архивист: приносит документы на стол, но не подписывает за вас выводы.

3. Worktree isolation: защищаем файлы и чистоту diff

Теперь переключимся на более осязаемую вещь. Бывает, что проблема вовсе не в шуме контекста. Агент лаконичен и дисциплинирован, но ему разрешили править — и он пишет в тот же checkout, где вы работаете. Начинаются вопросы «а это чьё изменение?» и «почему тестовый фикс тронул соседний модуль?».

Worktree isolation — изоляция на уровне Git и файловой системы. Вы создаёте отдельное рабочее дерево — отдельную директорию под своей веткой — и запускаете там отдельную сессию Claude Code. Главная мысль простая: рискованные, экспериментальные или параллельные правки не должны расти в том же каталоге, где ваш основной diff.

В Git это выглядит очень приземлённо:

git worktree add ../commerce-os-refund-lab -b exp/refund-rules
cd ../commerce-os-refund-lab
git status   # убеждаемся, что мы в отдельной ветке и рабочее дерево чистое
claude       # запускаем отдельную сессию в изолированном каталоге

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

Зачем это нужно на практике? Представьте тот же Commerce OS. Проблема, возможно, в логике partial refund, и вы хотите попробовать два варианта: поправить условие в RefundPolicyService или сначала написать regression test и посмотреть, на чём он падает. В основном checkout это превратится в общий комок изменений. Когда каждый эксперимент живёт в отдельном worktree, всё управляемо: сравнить диффы, запустить тесты отдельно, выбросить неудачную ветку без боли.

Это особенно полезно для agents/tester.md, когда вы разрешаете ему править тесты. Пусть tester пишет только в tests/ — уже неплохо. Но безопаснее дать ему отдельное worktree: его ошибочная попытка не перепутается с вашими ручными правками.

При этом worktree isolation — не магия и не индульгенция. Отдельное дерево не делает плохой diff хорошим, не заменяет review, не запускает тесты. Оно делает эксперимент дешевле и чище: правка неудачная — удаляете worktree, а основной checkout остаётся в состоянии «ничего страшного не произошло». Но не превращайте его в ритуал на каждый чих: для правки в одном файле отдельная директория — чистый overhead. Видите риск заранее — окупается.

4. Выбор: context, worktree isolation или сразу обе

После знакомства с обеими изоляциями хочется спросить самое практичное: что брать в реальной задаче? Хорошая новость в том, что выбор сводится не к абстрактной «сложности», а к двум простым вопросам. Агент будет много читать без правок? Context isolation. Будут правки, особенно экспериментальные или параллельные? Worktree isolation. Часто сначала нужен широкий анализ, потом аккуратный эксперимент: subagent в отдельном окне находит проблему, а отдельная сессия в отдельном worktree пробует правки. Защищены и голова основной сессии, и чистота файлов.

Для быстрого выбора удобно смотреть на ситуацию так:

Здесь полезно помнить, что изоляция — не признак «продвинутости». Иногда самый профессиональный выбор — не включать её: задача короткая, scope понятен, diff маленький — один Claude в одной сессии лучше всего.

5. Сквозной сценарий: Workflow Kit и Commerce OS

Чтобы всё это не осталось красивой теорией, давайте соберём целостную картину. У вас Workflow Kit с agents/tester.md и Commerce OS с проблемой refund flow: жалоба в issue звучит так — «после partial refund система иногда считает eligibility неправильно, а regression test этого не ловит». Задача, где одна изоляция неизбежно тянет вторую.

Сначала вы оставляете основную сессию в роли координатора. Вы делегируете tester-агенту read-only исследование: пройти по payments/, support/ и test-пакетам, найти проверки, указать пробелы, вернуть короткую сводку с файлами. Это context isolation. Главная сессия не видит шум поиска, но получает вывод: regression coverage отсутствует вокруг сценария partial refund после manual approval.

После этого становится ясно, что одного чтения мало — нужно добавить regression test и посмотреть, где падает логика. Вот тут подключается worktree isolation: отдельное дерево, отдельная сессия, tester-агент добавляет test-файл, при необходимости правит test fixtures, гоняет локальные проверки. Основной checkout чист. Эксперимент плохой — закрываете ветку и удаляете worktree. Хороший — сравниваете diff, переносите только нужное.

Схема получается очень понятной:

Основная сессия
   ├─ context isolation → агент читает код и тесты, возвращает короткую сводку
   └─ worktree isolation → отдельная сессия пробует правки и гоняет тесты

Заметьте, как красиво тут распределяются роли. Workflow Kit даёт reusable artifact — agents/tester.md, Commerce OS — реальную инженерную задачу. Взрослая инженерная привычка: сначала понять, что именно вы хотите защитить, потом выбрать границу.

Именно поэтому две изоляции нельзя смешивать в одну абстрактную тему «про безопасность». Context isolation отвечает: как не утопить основную сессию в деталях. Worktree isolation: как не превратить основной checkout в экспериментальный полигон. Пока вы не различаете эти боли, выбор изоляции — гадание: включаете «на всякий случай» или не включаете вовсе. Как только называете защищаемое своим именем — засоряется контекст или мешается diff, — граница выбирается сама, а нужную изоляцию вы ставите ровно там, где она окупается.

1

Задача

Claude code, 12 уровень, 2 лекция

Недоступна

Выбор изоляции для субагента refund flow

Выбор изоляции для субагента refund flow

Открыть

1

Задача

Claude code, 12 уровень, 2 лекция

Недоступна

Гайд по выбору изоляции

Гайд по выбору изоляции

Открыть