DeepSeek Harness: возможности и настройки, что хранится локально, а что глобально

Информация актуальна на сентябрь 2026 года. Всё описанное проверено на рабочей сборке DeepSeek Harness версии 0.2.0-rc.2 (канал nightly) и сверено с документацией пакетов, которая поставляется вместе с приложением. Продукт находится в стадии preview, поэтому между релизами отдельные пункты могут меняться — я отмечаю такие места прямо в тексте.

Почему вопрос «локально или глобально» важнее, чем кажется

Я потратил почти час на поиск причины, по которой правка правила в проекте не действовала. Правило лежало в файле AGENTS.md в корне репозитория — я был уверен, что агент его видит. Оказалось, что в корне монорепозитория лежал ещё один AGENTS.md, а третий, самый «сильный», стоял в домашнем каталоге Harness и подгружался ко всем сессиям без исключения. Агент послушно собирал всю цепочку файлов и применял ту инструкцию, которая была ближе к рабочей папке. Моя правка была не «проигнорирована» — она просто оказалась в середине иерархии, где её перекрывал более конкретный файл.

Таких сюрпризов в DeepSeek Harness много, потому что это не чат-клиент с одной кнопкой настроек, а среда для запуска автономных агентов: с деревом плагинов, песочницей, профилями, хранилищем сессий, набором инструментов и отдельным слоем пользовательских настроек. Когда вы меняете очередной переключатель, вы фактически отвечаете на вопрос: это изменится во всех проектах или только в текущем? Сохранится после перезапуска или до конца сессии? Увидит ли это коллега, если я передам ему папку? От ответа зависит, будет ваша конфигурация предсказуемой или превратится в набор необъяснимых чудес.

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

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

Что такое DeepSeek Harness и из чего он собран

DeepSeek Harness (сокращённо DSH) — это среда, в которой запускается агент: программный ассистент, умеющий читать и править файлы, выполнять команды в оболочке, искать в интернете, работать с документами, вызывать внешние инструменты и делегировать части работы другим агентам. Само по себе название «harness» буквально означает «упряжь»: обвязку, которая соединяет модель, инструменты, политику безопасности и интерфейс в одну управляемую систему.

Ключевое, что нужно понять про архитектуру: Harness собран из плагинов. Не «есть ядро и к нему несколько расширений», а «есть дерево плагинов, которое на старте собирается из упорядоченных слоёв». Даже базовые вещи — чтение файлов, запуск команды, обращение к модели, сохранение истории — это плагины. Такой подход объясняет почти все особенности настройки, поэтому начнём с него.

Cordis: контейнер, который собирает дерево плагинов

Основой служит Cordis — контейнер внедрения зависимостей и загрузки плагинов. Каждая запись в конфигурации описывает один плагин: его идентификатор, имя пакета, необязательный блок config и необязательный флаг disabled. Из этих записей на старте вырастает дерево. Порядок строк в файле сам по себе не определяет порядок работы: плагин активируется тогда, когда доступны сервисы, которые он запрашивает. Если плагину нужен сервис ctx.fs (файловая система) или ctx.llm (маршрут к модели), он ждёт, пока провайдер этого сервиса появится в дереве.

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

Бандлы: как распространяют готовые наборы плагинов

Патчи плагинов объединяют в бандлы («связки»). Бандл — это формат распространения: пакет, который несёт свой файл патча и тем самым вставляет в дерево целый набор согласованных строк. Базовые бандлы, которые поставляются вместе с Harness:

• dsh-base — общий фундамент: адаптеры моделей, инструменты, работа с сессиями и их хранением, песочница и политика подтверждений, настройки, учётные данные, телеметрия, работа с интернетом, MCP-клиент, субагенты, рабочие процессы;
• dsh-web-app — браузерный интерфейс: боковые панели, чат, страницы настроек, менеджер плагинов, терминал, просмотр документов;
• dsh-headless — режим одиночной задачи без интерфейса: запустился, отработал, напечатал ответ, вышел;
• dsh-sdk-app и dsh-sdk-minimal — серверные профили для программного управления по JSON-RPC;
• dsh-acp-app — профиль для интеграции с редакторами через протокол ACP;
• dsh-experimental-agent-team-profile — экспериментальный слой «команд агентов», о котором ниже.

Бандл можно установить из реестра как обычный npm-пакет, подключить локально или написать самому — для этого в экосистеме есть отдельные навыки и шаблоны.

Профиль: имя, под которым живёт вся конфигурация

Профиль — это именованный набор слоёв. Физически он лежит в каталоге Harness: $DSH_HOME/profiles/<имя>. Внутри профиля:

• package.json — список подключённых бандлов (поле dsh.profile.bundles) и внешние зависимости, установленные именно в этот профиль;
• cordis.yml — корень дерева, который в штатной поставке остаётся пустым списком: всё собирается патчами;
• cordis.patch.yml — ваш личный слой правок, который применяется после всех бандлов;
• pnpm-workspace.yaml — настройки менеджера пакетов;
• compatibility.json — появляется, если вы выдавали исключения по совместимости версий плагинов;
• служебные каталоги .plugin-manager/ с журналами установок.

Итоговое дерево собирается строго в таком порядке: сначала патч каждого бандла в том порядке, в котором бандлы перечислены в package.json, затем cordis.patch.yml профиля, затем глобальный $DSH_HOME/cordis.patch.yml, затем любые дополнительные патчи, переданные в командной строке. Каждый следующий слой может переопределить строки предыдущего по идентификатору. Это и есть ответ на вопрос «что глобально, а что нет» на уровне сборки: файл cordis.patch.yml в домашнем каталоге Harness действует на все профили сразу, а файл профиля — только на него.

Пять способов запустить Harness

Один и тот же движок запускается в разных режимах — это тоже профили, а не отдельные программы:

• dsh web — браузерный интерфейс, который по умолчанию слушает только локальный адрес;
• dsh —profile headless «задача» — одна задача, один ответ, выход: удобно для скриптов и CI;
• dsh —profile acp — обмен с редакторами по протоколу ACP через стандартный ввод-вывод;
• dsh —profile sdk и dsh —profile sdk-minimal — сервер для собственного кода по JSON-RPC;
• настольное приложение — тот же движок внутри Electron-оболочки, с профилем desktop, который зарезервирован за приложением и не запускается из обычной командной строки.

Есть и полезные служебные команды: посмотреть итоговое дерево вместе с вашими правками, посмотреть дерево без них, выгрузить JSON-схему всех плагинов, а также управлять плагинами профиля, передавая команды менеджеру пакетов.

Три независимых слоя конфигурации

Новички обычно смешивают в голове три разные вещи, и это порождает половину путаницы. В Harness конфигурация разделена на три независимых слоя с разными владельцами и разными правилами.

Первый слой — композиция (Profile). Это ответ на вопрос, какие плагины вообще существуют в вашей сборке и с какими стартовыми параметрами. Владелец — вы, файлы — cordis.patch.yml профиля и глобальный патч. Изменения здесь применяются к профилю целиком, то есть ко всем сессиям и всем проектам, которые в нём работают.

Второй слой — пользовательские настройки (Settings). Это один документ, разбитый по пространствам имён. Каждое пространство принадлежит какому-то плагину: например, интерфейс, модель по умолчанию, оболочка, поиск в интернете, журнал сессий. Значение для каждого поля собирается из трёх источников по порядку: значения по умолчанию из схемы плагина, базовое значение из композиции и, наконец, ваша пользовательская секция. Если вы что-то стёрли в пользовательской секции, поле не исчезает — оно снова наследует базовое значение и значение по умолчанию.

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

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

Слой	Что описывает	Где лежит	На что действует
Композиция (Profile)	Какие плагины загружены и с какими параметрами	$DSH_HOME/profiles/<имя>/cordis.patch.yml, $DSH_HOME/cordis.patch.yml, package.json профиля	На весь профиль: все проекты и все сессии
Настройки (Settings)	Пользовательские значения по пространствам имён	Документ настроек, который сохраняется в патч активного профиля	На конкретное поле, которое читает соответствующий плагин
Учётные данные (Credentials)	Сами секреты: ключи API, токены	$DSH_HOME/.credentials.yaml, переменные окружения, файлы .env	На запросы к провайдерам и внутренние сервисы

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

И ещё одна деталь, которая многих удивляет: у части настроек вообще нет своего файла в домашнем каталоге. Значения, которые вы меняете в интерфейсе, сохраняются как правки строк в патче активного профиля. Именно поэтому в реальной установке в файле профиля можно найти и выбранную тему, и уровень подробности расшифровки, и таблицу пресетов разрешений. Файл settings.yaml, который встречается в старых описаниях, в текущих версиях считается наследием: при запуске он один раз импортируется, после чего переименовывается в settings.yaml.imported, чтобы не вводить в заблуждение.

Что именно хранится глобально

Глобальный слой — это каталог данных Harness. Он определяется по простому правилу: если указан явный путь в конфигурации, берётся он; иначе переменная окружения DSH_HOME; иначе домашний каталог пользователя плюс .dsh. Пустое значение переменной игнорируется — белый пробел не превратит домашний каталог в текущую папку. В интерфейсе и документации этот путь показывают символически: ~/.dsh, а если каталог переопределён через переменную — $DSH_HOME. Символическая запись не случайна: она не выдаёт абсолютный путь конкретной машины, что удобно при обмене конфигурациями и в скриншотах.

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

Путь в домашнем каталоге Harness	Что там лежит	Природа данных
profiles/<имя>/	Профили: манифест с бандлами, cordis.yml, ваш cordis.patch.yml, настройки pnpm, служебный .plugin-manager/	Композиция, общая для профиля
cordis.patch.yml	Глобальный патч для всех профилей. Может отсутствовать, пока вы его не создали	Композиция, самый приоритетный файл
.credentials.yaml	Хранилище секретов: ключи API и служебные записи вроде секрета браузерной сессии	Секреты, версионированный документ
.anonymous-user-id	UUID, который уходит как идентификатор в телеметрии. Удалили файл — при следующем запуске появится новый	Идентификация
.env	Пользовательские переменные окружения уровня машины	Окружение
AGENTS.md	Ваши глобальные инструкции для агента во всех проектах	Контекст
skills/	Ваши личные навыки, доступные во всех проектах. Служебный подкаталог .system не сканируется	Возможности
sessions/	Журналы сессий: по одному файлу на сессию, сжатие zstd, каталог на каждый рабочий путь	История
storages/	JSON-хранилища: список рабочих пространств, закрепления, архив, а также кэш проекций	Состояние приложения
attachments/v1/	Вложения: изображения, файлы, временная зона публикации	Данные
cache/	Кэш, например подготовленные под конкретный маршрут версии изображений. Удалять безопасно	Кэш
dsh-runtimes/	Встроенные среды исполнения: Python с библиотеками, Node, pnpm	Инструменты

Разберём самое важное подробнее.

Журналы сессий: append-only и по одному файлу на сессию

История разговоров пишется в формате JSONL, по одному файлу на сессию, с сжатием zstd. Файл организован как набор независимых сжатых блоков: отдельный блок под заголовок, дальше по блоку на каждую подтверждённую порцию событий. Это не косметика, а гарантия целостности: обрыв записи портит только последний блок, а уже записанные события не переписываются никогда. Событие сессии — единица журнала; текущая версия формата — четвёртая по счёту, и все предыдущие версии читаются с автоматической миграцией в память при чтении или в новый файл при следующей записи. Исходный файл при этом остаётся байт в байт неизменным: миграция никогда ничего не перезаписывает на месте.

Каталоги сгруппированы по рабочему пути, причём нечитаемые символы экранируются: кириллица превращается в последовательности вида ~0414~043E, двоеточие — в дефис. Отсюда длинные имена вида —C-Users-…-default-workspace—. Это не случайность и не признак сбоя, а способ сделать путь пригодным для файловой системы.

Отдельно стоит сказать о том, чего в интерфейсе нет. Удаления сессий не существует ни в графическом интерфейсе, ни в программном. Сессию можно закрепить, переименовать, ответвить, скрыть, отправить в архив — но не удалить. Файлы журналов накапливаются, пока вы не уберёте их вручную. Закрепление и архив — это тоже глобальные наборы идентификаторов, они лежат в общем хранилище и действуют на всю установку, а не на конкретный проект.

Рабочие пространства: локальные каталоги, глобальный список

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

Что ещё считается глобальным

Помимо очевидных секретов и списка проектов, глобальными являются:

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

Как проверить, что именно у вас получилось

Две команды дают полную картину. Одна показывает итоговое дерево плагинов со всеми наложенными слоями, включая ваш патч и переданные в командной строке файлы. Вторая показывает дерево без пользовательских слоёв — удобно, когда нужно понять, что добавил бандл, а что вы сами. Есть и третья: выгрузка JSON-схемы всех плагинов составленного дерева. Последней стоит пользоваться с осторожностью: она импортирует объявленные схемы плагинов, а значит, выполняет код сторонних пакетов.

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

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

Что считается локальным

Слово «локально» в Harness означает как минимум четыре разные вещи, и путаница между ними порождает большинство вопросов. Локальным может быть рабочая папка, проект, сессия или браузер. Разберём каждый уровень отдельно и посмотрим, что именно к нему привязано.

Уровень рабочей папки: граница записи и группировки

Рабочая папка, которую вы выбираете при старте, — это не просто «где искать файлы». Во-первых, это граница режима workspace-write: запись разрешена только туда, куда указывает канонизированный путь рабочей папки, плюс временный каталог платформы. Во-вторых, это ключ группировки: сессия приписывается проекту по каталогу, в котором она запущена. В-третьих, большинство инструментов по умолчанию работают относительно неё, хотя это именно значение по умолчанию, а не ограничение: абсолютные пути и переходы на уровень выше из рабочей папки возможны — за содержанием следит отдельный слой песочницы, а не сам выбор каталога.

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

Уровень проекта: инструкции

Инструкции — самая «проектная» часть Harness, потому что они читаются из файлов прямо в дереве каталогов. Работает это так. Перед первым запросом агент получает одно долговременное сообщение, в котором собрана цепочка файлов: сначала глобальный AGENTS.md из домашнего каталога Harness, затем файлы проекта от корня репозитория вниз до текущей рабочей папки — от общего к частному. Корень проекта определяется по ближайшему каталогу вверх по дереву, содержащему маркер, по умолчанию .git. Если маркера нет, корнем считается текущая рабочая папка.

Кандидаты имён по умолчанию: AGENTS.md и CLAUDE.md в каждом каталоге цепочки, плюс локальные надстройки AGENTS.local.md и CLAUDE.local.md. Если CLAUDE.md дословно повторяет соседний AGENTS.md, он не дублируется: совпадение определяется по содержимому. Понимается только это: строчные варианты имён, каталог правил .claude/rules/ и импорты по @path не интерпретируются.

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

Есть два свойства, о которых стоит знать заранее. Первое: обновление инструкций не отслеживается наблюдателем за файлами. Изменённый файл подхватывается при следующем успешном чтении, записи или правке в этом каталоге, а также при возобновлении сессии. Переход по каталогам через команду оболочки ничего не подхватывает: оболочка каждый раз стартует заново, и разбирать произвольный синтаксис команд как надёжный источник сведений о файловой системе разработчики не стали. Второе: если файл инструкций является символической ссылкой, содержимое читается по ссылке. Для чужого репозитория это означает, что инструкции могут прийти из-за пределов дерева проекта. Инструкции не имеют силы выше системных указаний разработчика и прямых указаний пользователя, но сам факт стоит держать в голове, когда вы открываете незнакомый код.

Уровень проекта: навыки

Навыки — это переиспользуемые инструкции со своим описанием, которые агент подгружает по необходимости. Ищутся они в нескольких корнях, и порядок поиска имеет приоритет:

Приоритет	Источник	Каталог
1	Проект, каталог Harness	<корень проекта>/.dsh/skills
2	Проект, общий каталог агентских настроек	<корень проекта>/.agents/skills
3	Ваши дополнительные каталоги	Задаются настройкой customSkillDirs
4	Личный каталог Harness	<домашний каталог Harness>/skills
5	Общий пользовательский каталог	<каталог агентских настроек>/skills, по умолчанию ~/.agents/skills
6	Встроенные навыки	Добавляются отдельной настройкой

Чем меньше номер, тем выше приоритет. Навык — это либо каталог с файлом SKILL.md, либо плоский файл <имя>.md на верхнем уровне корня. Вложенные деревья намеренно не просматриваются: глубина поиска ровно один уровень. В начале файла обязательна шапка со связкой «имя и описание»: имя в нижнем регистре через дефис, описание обязательно. Необязательные поля управляют тем, кто может вызывать навык — только модель, только человек или оба. Ошибка в написании логического значения приводит к тому, что навык молча исчезает из каталога модели с предупреждением в журнале: агент не отличит отсутствующий навык от испорченного.

Приоритет устроен так, что проектный навык перекрывает ваш личный с тем же именем. Это удобно для команд: положите в репозиторий каталог .agents/skills — и правила работы с проектом поедут вместе с кодом. Но помните, что файл навыка читается заново при каждом вызове, а сам каталог отслеживается: правка тела видна сразу, а вот появление нового навыка в свежесозданном корне может занять немного времени, потому что за отсутствующим каталогом следят опросом, пока он не появится.

Уровень проекта: файл окружения и его пределы

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

Уровень сессии

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

Уровень браузера

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

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

Сводка: где что лежит

Что настраивается	Где живёт	Область действия
Состав плагинов, их параметры	Патч профиля, глобальный патч, оверлеи командной строки	Профиль или вся установка
Секреты, ключи API	Хранилище секретов, окружение, .env	Вся установка либо процесс
Модель по умолчанию	Документ настроек	Будущие агенты, не открытые сессии
Пресет разрешений по умолчанию	Документ настроек	Будущие сессии
Режим разрешений текущей сессии	Журнал сессии	Одна сессия
Инструкции для агента	AGENTS.md и совместимые файлы	Цепочка «глобально, затем проект»
Навыки	Проектные и пользовательские корни	По приоритету корней
Список проектов, закрепления, архив	Общее JSON-хранилище	Вся установка
Журналы сессий	Домашний каталог, сжатые файлы	Вся установка, группировка по каталогу
Вложения	Домашний каталог, хранилище объектов	Вся установка
Порядок сессий в списке, черновики	Браузер	Одно рабочее место

Два вывода из этой таблицы я считаю самыми практичными. Первый: всё, что должно ехать вместе с проектом, нужно либо класть в сам проект (инструкции и навыки), либо описывать в патче профиля явно. Второй: всё, что вы настроили в интерфейсе, по умолчанию действует на будущее и на всю установку, а не на конкретный проект. Если вам нужны разные модели или разные пресеты разрешений для разных проектов, придётся либо создавать отдельные профили, либо переключать параметры вручную в каждой сессии — автоматического правила «для этого каталога такой режим» в этой версии нет.

Возможности: что агент умеет и как это включается

Любая возможность в Harness — это плагин, который добавляет либо инструмент для модели, либо сервис для других плагинов, либо элемент интерфейса. Поэтому «включить возможность» почти всегда означает «добавить строку в композицию» или «переключить готовый пункт в списке плагинов». Ниже — разбор по группам: что доступно, чем ограничено и на что обратить внимание при настройке.

Файловые операции

Основной набор — чтение, запись, правка и просмотр изображений. Чтение по умолчанию отдаёт не больше двух тысяч строк, одна строка не длиннее двух тысяч символов, а весь ответ ограничен пятьюдесятью килобайтами; большие файлы читаются постранично через смещение и лимит. Инструмент работы с изображениями регистрируется только при наличии хранилища вложений и отказывает, если выбранная модель не заявляет поддержку изображений. Правка выполняется заменой уникального фрагмента, при необходимости — всех вхождений.

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

Поиск по коду

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

Оболочка и фоновые задачи

Команды выполняются в оболочке, соответствующей платформе: на Unix-подобных системах это bash, на Windows — PowerShell. Каждый вызов запускает новый процесс, состояние между вызовами не сохраняется: переменные окружения и текущий каталог, заданные в одной команде, не действуют в следующей. Рабочий каталог передаётся параметром. Ненулевой код возврата — это результат команды, а не сбой инструмента: агент видит пометку с кодом и должен сам решить, что с этим делать. Тайм-аут по умолчанию — две минуты, максимальное значение, которое можно запросить, — десять минут; превышение выводит пометку о превышении времени. Ограничение вывода — 64 килобайта на поток, дальше вывод уходит в временный файл.

Фоновые задачи — отдельная подсистема. Любая команда, запущенная в фоне, становится задачей с предсказуемым идентификатором вида «тип-номер». Задачами можно управлять: посмотреть список, прочитать вывод (в том числе с ожиданием до десяти минут), остановить. Идентификаторы предсказуемы намеренно: защита строится не на секретности, а на правах — задача принадлежит запустившей её сессии, чужие агенты не могут ни прочитать её вывод, ни остановить её. Когда фоновая задача завершается, владелец получает уведомление: занятый агент увидит его на следующем шаге, свободный будет разбужен новым ходом. Живут задачи только в памяти процесса: после перезапуска Harness они исчезают, на диск не пишутся, и никакого восстановления не предусмотрено.

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

Интернет

Два инструмента: поиск и загрузка страницы. Поиск принимает от одной до четырёх формулировок и объединяет результаты; до восьми результатов на запрос, до трёхсот секунд ожидания. Загрузка отдаёт не больше двухсот тысяч символов, разметка преобразуется в текст, ответ с ошибочным статусом не считается сбоем инструмента, а честно возвращается как результат. Публичные адреса загружаются без запроса подтверждения. Провайдер поиска и провайдер загрузки выбираются композицией, а ключ берётся из того же хранилища секретов, что и ключ для моделей; для официального поиска DeepSeek используется отдельная конечная точка, настраиваемая независимо от маршрута модели. Если ключа нет, поиском смогут пользоваться только сессии, работающие через официальную модель с аккаунтом.

Навыки

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

Субагенты

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

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

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

Команды агентов

Экспериментальный слой превращает роли в явные: ведущий и участники, общая доска задач, долговременные адресуемые участники. Ведущий создаёт участников, ставит задачи, прерывает работу, переназначает. Задача может иметь зависимости и подсказки по файлам; взять её можно только тогда, когда все зависимости завершены. Любое изменение задачи выполняется по проверке версии: устаревшая ревизия отклоняется. Участники обмениваются сообщениями, которые гарантированно доставляются в ближайшую точку между шагами, а не в середину шага. Есть команда ожидания изменений, которая честно возвращает «прогресса нет», если никто, кроме вас, не работает.

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

Рабочие процессы

Инструмент рабочих процессов запускает не разговор, а программу-оркестратор на JavaScript. Внутри скрипта доступны четыре конструкции: запустить одного агента и дождаться результата, провести каждый элемент через несколько этапов без общего барьера, выполнить набор функций параллельно с барьером, а также объявить фазу и написать сообщение в журнал прогресса. У агента можно запросить структурированный ответ по схеме, причём набор допустимых конструкций схемы намеренно узкий: объект, свойства, обязательные поля, перечисления, константы, объединение вариантов. Это защита от «умных» схем, которые невозможно надёжно проверить.

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

Цели

Цель — это долговременное намерение, к которому среда возвращается сама. У сессии может быть одна текущая цель. Состояния: активна, на паузе, заблокирована, завершена. Изменения идут с проверкой версии, а состояние живёт только в событиях сессии. Полномочия устроены строго: создать, изменить, поставить на паузу или возобновить цель может только прямой запрос человека в текущем ходу; завершить или пометить блокировку может ещё и текущий автоматический раунд.

Автоматическое продолжение — самая интересная часть. Среда ставит в очередь раунд цели только тогда, когда агент полностью свободен, цель активна и «взведена», а лимит раундов не исчерпан. Флаг «взведена» намеренно не сохраняется на диск: после возобновления или ответвления сессии активная цель оказывается разряженной и сама не продолжается, пока человек явно не скажет продолжить. Пометить цель заблокированной можно не раньше, чем блокирующее условие сохраняется три раунда подряд, и с обязательным указанием причины. Ограничение по раундам по умолчанию — двести пятьдесят шесть; при его исчерпании причина блокировки записывается как исчерпание лимита, а не как содержательная проблема. Автоматических повторов при аварийных сбоях не делается.

Планирование и список задач

Режим планирования переключает поведение агента: он обязан исследовать и проектировать, а не менять файлы, и завершает работу вызовом отдельного инструмента с готовым планом. Тонкость, которую многие путают: инструмент выхода из режима остаётся в списке доступных инструментов даже когда планирование выключено — сделано это намеренно, чтобы смена режима не меняла состав инструментов и не ломала кэш запросов. Поэтому «агент видит инструмент, значит он в режиме плана» — неверное рассуждение; вызов вне режима отклоняется.

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

Управление контекстом

Контекст — расходуемый ресурс, и в Harness им управляют несколько механизмов сразу.

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

Второе: сжатие разговора. Когда оценка заполнения окна превышает порог, среда заменяет часть истории одним сообщением-конспектом. Механика аккуратная: сжатие всегда парное — начало и конец операции фиксируются в журнале, а границы выбираются так, чтобы ни один вызов инструмента не остался без ответа. Свежая часть истории сохраняется дословно: по умолчанию около шестнадцати процентов доступного объёма. Системное описание, схемы инструментов и префикс сессии никогда не сжимаются; при подготовке конспекта они передаются модели байт в байт, чтобы вспомогательный запрос попал в тёплый кэш провайдера. Команда сжатия вручную доступна из интерфейса и отказывает, пока агент занят.

Третье: вытеснение изображений. Если маршрут отвергает запрос из-за бюджета на изображения, самые старые изображения заменяются текстовыми пометками со ссылкой на файл, и запрос повторяется. Операция необратима в пределах истории.

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

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

Внешние инструменты по протоколу MCP

Поддержка MCP позволяет подключить сторонний сервер инструментов и получить его возможности прямо в сессии. Есть два транспорта: запуск дочернего процесса и потоковый HTTP. Настройка выполняется не в отдельном файле, а строкой композиции: имя сервера (только латиница, цифры, дефис и подчёркивание, до тридцати двух символов), команда или адрес, дополнительные переменные окружения или заголовки, тайм-аут вызова.

Несколько деталей, которые полезно знать заранее. Имена инструментов формируются как «mcp, имя сервера, исходное имя», причём при неоднозначном преобразовании к имени добавляется короткий хэш — чтобы разные инструменты никогда не слились в один. Собственное имя сервера, которое он сообщает о себе, не используется: оно не уникально и может меняться. Дочерний процесс не получает переменные окружения, похожие на секреты, и вообще все переменные с префиксом Harness: их нужно перечислить явно, если они действительно нужны. Кроме инструментов поддерживаются ресурсы — их можно перечислять и читать, но двоичные ресурсы приходят текстовой пометкой, а не изображением. Шаблоны подсказок MCP и подписки на обновления ресурсов не поддерживаются. Ничего не включено по умолчанию: MCP — это всегда осознанное добавление.

Хуки

Есть мост, который позволяет переиспользовать хуки из двух других экосистем агентских инструментов. Настройка — тот же файл в формате JSON, который вы, возможно, уже ведёте для другого инструмента; поддерживаются события начала сессии, отправки запроса, до и после вызова инструмента, остановки, а также старта и завершения субагента. Командные хуки выполняются как процессы, код возврата два блокирует действие, текст ошибки становится причиной блокировки, остальные коды пишутся в журнал как неуспех без блокировки. Маски для сопоставления имени инструмента поддерживаются, порядок — строго последовательный.

Ограничения стоит знать до того, как вы перенесёте в Harness сложную конфигурацию хуков. Выполняются только командные обработчики: HTTP-обработчики, вызовы инструментов и «подсказки» распознаются, но пропускаются с предупреждением. Поддерживается меньшая часть событий исходной экосистемы; например, события сжатия контекста, завершения сессии и запросов разрешений не поддержаны. Директива «прекратить» записывается в журнал, но не останавливает прогон. Изменённые аргументы вызова инструмента не применяются: они разбираются и игнорируются с предупреждением. Путь к расшифровке разговора всегда пуст, потому что журнал сессии сжат и хукам недоступен. Конфигурация читается один раз на процесс, без многослойного поиска и без перезагрузки на ходу.

Документы, вложения и артефакты

Для офисных форматов есть отдельные наборы навыков и конвертер: документы, таблицы и презентации создаются и правы через библиотеки, а преобразование в PDF выполняется встроенным офисным движком — ставить офисный пакет в систему не требуется. Изображения принимаются в распространённых форматах с ограничениями: до двадцати мегабайт на файл, до двадцати изображений в сообщении, до двухсот мегабайт суммарно, с приведением к единому виду и удалением метаданных. Если хотя бы одно изображение не проходит проверку, сообщение отклоняется целиком. Файлы произвольных типов ограничений по типу и размеру не имеют: модель получает не содержимое, а строку-ссылку с дайджестом, размером и путём только для чтения.

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

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

Что ещё есть и чего пока нет

Дополнительно в поставке или в виде необязательных бандлов присутствуют: сервер языковых протоколов для навигации по коду, планировщик напоминаний с секундными, суточными и cron-выражениями, распознавание речи для голосового ввода, просмотр веб-страниц в боковой панели настольной версии, а также экспериментальные пакеты для автоматизации браузера и управления компьютером. Планировщик, например, поставляется выключенным отдельным бандлом и работает только при запущенном приложении: при закрытом Harness ничего не срабатывает, а при следующем запуске доставляется только последнее пропущенное срабатывание повторяющейся задачи.

Чего в этой версии нет: удаления сессий, откатов к произвольному сообщению, автоматических правил вида «в этом каталоге использовать такую модель», вложенных рабочих процессов, поддержки шаблонов подсказок MCP и полноценного многослойного поиска конфигурации хуков. Перечисленное стоит учитывать при планировании процессов, чтобы не строить схему работы на функции, которой не существует.

Настройки в интерфейсе: что где переключается

Интерфейс Harness — не «тонкая оболочка над файлами конфигурации», а полноценная поверхность управления: значительная часть настроек имеет форму, а формы пишут значения в патч активного профиля. При этом интерфейс осознанно ограничен: он редактирует только те поля, которые соответствующий плагин объявил изменяемыми на ходу. Обычные параметры плагинов формы не получают и остаются в файлах композиции. Понимание этого разделения экономит время: если в интерфейсе нет нужного переключателя, это не ошибка сборки, а решение авторов плагина.

Общие настройки

Раздел «Общие» содержит несколько строк, принадлежащих разным плагинам, но собранных в одном месте:

• переключатель «Инструменты для программирования» — включает и выключает саму возможность выбирать агентские пресеты;
• текущая версия сборки — строка только для чтения, её значение приходит из окружения;
• внешний вид: светлая, тёмная или системная тема, а также размер шрифта контента в диапазоне от десяти до двадцати двух пикселей, по умолчанию четырнадцать;
• поведение ссылок на разговоры: открывать в боковой панели приложения или в системном браузере;
• подробность сведений о производительности и расходе;
• отправка журнала сессии при работе через официальный API моделей — включена по умолчанию, ограничение в восемь мегабайт;
• язык интерфейса: по поставке доступны английский и китайский, дополнительные языки могут регистрировать плагины; выбор браузера определяется системными настройками с откатом на английский;
• пресет агента по умолчанию для сессий, создаваемых позже;
• строка вызова диалога горячих клавиш;
• открытие файла конфигурации в системном текстовом редакторе — доступно только при работе через локальный адрес.

Последний пункт заслуживает пояснения: он открывает именно тот документ, которым владеет приложение, в редакторе операционной системы. Для удалённого браузера он не регистрируется вообще, и привилегированное чтение настроек не выполняется. Это одна из нескольких мер, которыми локальный и сетевой режимы разведены.

Модели и ключи

Раздел «Модели» — самое практичное место во всех настройках, потому что здесь решается вопрос доступа к моделям. Устройство раздела: список провайдеров, из которых одновременно раскрыт один. Для каждой карточки доступны: единственное поле для ключа API (только на запись — после сохранения интерфейс получает обезличенное описание и никогда не возвращает сам ключ), адрес конечной точки, параметры моделей — идентификатор, отображаемое имя, размер контекстного окна, ограничение на длину ответа, а также типы входных данных: текст и изображения. Есть кнопка восстановления моделей по умолчанию, сбрасывающая все правки каталога.

Несколько деталей, которые я считаю важными:

• ключ принимает только непустые печатаемые ASCII-символы; вставленная строка вида «ИМЯ=значение» или значение в кавычках отклоняется — это защита от неаккуратной вставки из .env;
• идентификатор пользовательского провайдера задаётся один раз и не меняется никогда; выбирайте осмысленно;
• при добавлении провайдера предлагаются три протокола: совместимый с чатом OpenAI, совместимый с Responses и «сообщения Anthropic»;
• уровень рассуждений в этом разделе намеренно не редактируется: это свойство конкретной модели, а не провайдера, и любое управление на уровне провайдера позволило бы выставить значение, которое часть моделей отвергнет;
• для официальных маршрутов DeepSeek отдельная карточка управляет и адресом, и учётными данными, и каталогом моделей;
• указание изображения во входных типах — это утверждение о конечной точке, а не проверка: никто не опрашивает шлюз о том, что он принимает. Если заявить изображения, а шлюз их не обслуживает, отказ придёт от провайдера посреди хода.

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

Для задач без графического интерфейса, например в автоматических сборках, ключ задают переменной окружения процесса или файлом .env. Здесь важно помнить порядок разрешения: переменные запускающего процесса, затем хранилище секретов, затем проектный .env, затем пользовательский .env. Первый источник неизменяем: запись туда отклоняется. И ещё: снимок окружения фиксируется в момент запуска, поэтому переменная, появившаяся в системе позже, не будет замечена работающим процессом.

Плагины

Управление плагинами живёт в двух местах, и это осознанное разделение.

Первое — страница «Плагины» в боковой панели. Здесь собраны группы: официальные плагины, поставляемые с продуктом, и установленные отдельно. Официальный плагин можно включить, но нельзя удалить; экспериментальные помечены отдельным ярлыком. Кнопка добавления принимает имя пакета с версией, адрес репозитория системы контроля версий, архив или абсолютный локальный путь. Есть выбор реестра и отдельное предупреждение о важной особенности: установленные плагины не обновляются автоматически, обновление — это удаление и установка заново. Если установка пакета требует разрешения на выполнение скриптов сборки, интерфейс покажет список ожидающих разрешений и предложит разрешить их и повторить; разрешение сохраняется по имени пакета и действует с правами пользователя системы, то есть это небезопасное действие, требующее осознанного решения.

Второе — раздел «Встроенные плагины» в настройках. Его единственная вкладка показывает список плагинов только для чтения: пресеты, глобальный состав, метки включения, состояние загрузки, идентификаторы строк и условия отключения. Изменить здесь ничего нельзя, и определить, какой именно слой добавил конкретный плагин, тоже нельзя — инструмент диагностический, а не управляющий.

Отдельные страницы настроек официальных плагинов дают доступ к их пространствам имён:

• «Цикл агента» — число параллельных вызовов инструментов: по умолчанию десять, значение один означает строго последовательное выполнение. Значение «живое»: оно применяется к следующей группе вызовов;
• «Субагент» — максимальная глубина вложенности (по умолчанию единица, ноль запрещает делегирование полностью) и предел параллелизма, а также переключатель выбора модели для субагентов, который требует хотя бы одного выбранного маршрута;
• «Поиск в интернете» — ключ, конечная точка и максимальное число поисковых запросов на один запрос; поля с изменённым значением помечаются как переопределённые и имеют отдельный сброс;
• «Оболочка» — тайм-аут команды и ограничение вывода на поток. Эта страница редактирует тот исполнитель оболочки, который реально собран в вашей конфигурации: на Windows это PowerShell, на других системах — bash. Поэтому набор полей может отличаться по платформам.

Что переключается вне страницы настроек

Часть управления вынесена в поле ввода и в командную строку сессии:

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

Список команд зависит от того, какие плагины собраны: в режимах без графического интерфейса, например в headless, программном доступе и ACP, командной поверхности нет вообще.

Пресеты агентов

Пресет — это готовый набор плагинов, который монтируется в область конкретного агента: его инструменты, разделы системного описания, навыки, делегирование. В поставке есть несколько вариантов: standard — базовый рабочий набор, он же выбран по умолчанию; minimal — облегчённый; ptc — режим, в котором модель получает не десятки схем инструментов, а одну точку входа и сгенерированный программный интерфейс, что заметно сокращает объём описаний в запросе; cordis — режим разработки плагинов с дополнительными инструментами инспекции и чтения композиции.

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

Безопасность и права: как это устроено на самом деле

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

Три режима песочницы

Режим	Что разрешено	Что запрещено
Только чтение	Чтение любых доступных файлов, запись в обязательные приёмники вроде системного «нулевого» устройства	Любая запись в файлы за пределами этих приёмников
Запись в рабочей папке	Запись внутри рабочего каталога и в системный временный каталог	Запись за пределами рабочего каталога
Полный доступ	Всё	Ничего: песочница не подключается вовсе

Третий режим устроен принципиально иначе, чем первые два: он не «расширенный профиль песочницы», а отказ от неё. Провайдер ограничения не вызывается вообще, команда запускается в исходном виде, а в результате фиксируется, что ограничений не применялось.

Контроль эффекта бывает полным и частичным. Частичный означает, что гарантирована лишь часть обещанных ограничений файловых операций — так бывает на некоторых версиях ядра Linux и в реализации для Windows. Если ни один доступный механизм не может обеспечить выбранный режим, операция отклоняется с ошибкой недоступности песочницы: молчаливый проход без ограничений запрещён.

Реализация зависит от платформы. В Linux сначала пробуют изолирующий запуск через отдельное окружение, затем механизм ядра Landlock. В macOS используется профиль Seatbelt. В Windows применяется ограниченный токен: токен процесса дублируется с ограничивающими идентификаторами безопасности, отдельно для рабочей папки и для временного каталога, после чего уровень целостности понижается. Выбор механизма кэшируется на время жизни провайдера, поэтому установка или починка компонента изоляции требует перезагрузки плагина, а не просто перезапуска команды.

Ключевое ограничение: песочница говорит только о файлах

Самое важное, что нужно усвоить: словарь политики — это файловые эффекты. Режим «только чтение» ограничивает запись, но не сеть, не процессы, не системные вызовы, не устройства и не доступ к учётным данным. Изолированный процесс в Linux и macOS видит сеть как обычно. В Windows ограничиваются запись и удаление, но не чтение: процесс может прочитать любой файл, доступный пользователю, включая данные другого проекта, и может открывать сетевые соединения. Режим «только чтение» на Windows поэтому нуждается в отдельной политике чтения, которой в этой версии нет.

Есть и другие честно задокументированные оговорки. Проверка доступа в файловой песочнице — это политика в доверенном коде над путём, которым управляет модель, а не граница ядра: остаточное окно между разрешением пути и системным вызовом сужено повторной канонизацией непосредственно перед записью, но не закрыто полностью. Враждебные процессы в той же системе вне модели угроз. На Windows остаётся постоянная запись в списках доступа рабочей папки, и она не удаляется при переключении режима: это осознанный компромисс, чтобы повторное повышение прав не требовало новой подготовки, но такая запись является невидимым следом, переживающим переименование каталога. Пониженная метка целостности тоже общая поверхность: любой другой процесс того же пользователя с низким уровнем целостности сможет писать и удалять внутри рабочей папки. Захват вывода дочерних процессов через программные каналы в ограниченном режиме на Windows невозможен — это документированная особенность, а не дефект настройки.

Есть и практические следствия, которые вы встретите в работе. В ограниченном режиме на Windows часть команд идентификации и инвентаризации системы просто не работает: например, инструменты опроса оборудования через WMI и CIM отказывают, потому что соответствующий идентификатор безопасности не включён в список. Запись в общедоступные системные каталоги запрещена, хотя права на них у пользователя есть. В PowerShell под режимом «только чтение» оболочка стартует в ограниченном языковом режиме: часть конструкций .NET, обращения через COM и рефлексия становятся недоступны.

Отдельно скажу про диагностику. В поставке есть навык, который проверяет и починяет права доступа, связанные с песочницей на Windows, но запускать его нужно вне песочницы. Если подтверждения отключены, а канал подтверждений недоступен, этот единственный вызов не пройдёт, и причину отказа выяснить не удастся. Это ровно та ситуация, в которой я оказался однажды и потратил лишний час: полезно заранее знать, что диагностический инструмент сам подчиняется тем же правилам.

Подтверждения

Политика подтверждений имеет всего два значения. «Спрашивать» передаёт решение зарегистрированным обработчикам: если ни один терминальный обработчик не подключён, запрос завершается недоступностью и действие не выполняется — то есть поведение закрытое по умолчанию. «Никогда» отклоняет любой запрос детерминированно, до обращения к обработчикам. Второе значение нельзя обойти плагином с более высоким приоритетом: отклонение происходит раньше, чем кто-либо получит запрос. Именно это значение действует в моей текущей сессии, и формулировка, которую видит модель, прямая: подтверждения отключены, действия, требующие подтверждения, отклоняются автоматически, запрашивать расширение прав не следует.

Три особенности, которые стоит знать:

1. Разрешение выдаётся только однократно. В словаре результатов есть «разрешено один раз», но нет «разрешить всегда», нет запоминаемых правил, нет отзыва и нет хранилища разрешений. Каждое расширение прав подтверждается заново.
2. Запрос подтверждения не несёт аргументы инструмента. Человек принимает решение по имени инструмента, причине и, возможно, идентификатору вызова. Показывать ли текст самой команды, зависит от интерфейса.
3. Расширение прав возможно только вверх и только на один шаг за раз: из «только чтение» можно запросить запись в рабочей папке или полный доступ, из «запись в рабочей папке» — только полный доступ. Запрос более узкого режима отклоняется до выполнения. Повторный запрос уже действующего режима ничего не меняет и не требует подтверждения.

Пресеты разрешений

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

Два имени зарезервированы. «Пользовательский» — это производное состояние, которое возникает, когда текущая комбинация не совпадает ни с одним пресетом: из него можно выйти, но выбрать или сохранить его нельзя. «Авто-проверка» — экспериментальный слой, который добавляет автоматический разбор вызова перед выполнением. Его оценки ограничены тремя уровнями риска, а вытеснение данных за границу доверия всегда считается высоким риском и отклоняется. Слой поставляется выключенным, включается отдельно и документирован честно: он может и пропустить опасное действие, и отклонить полезное, и потратить дополнительные токены; постоянных исключений и настраиваемой политики у него нет. Важное ограничение: у авто-проверки нет файловой песочницы, и прямые эффекты внутри программного режима вызова инструментов не проходят через эту проверку.

Что происходит при переключении и как это хранится

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

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

Сеть и доступ к интерфейсу

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

Первая — прокси для исходящих запросов. Он читается из переменных окружения и файла настроек пользователя. Имена переменных прокси в проектном .env запрещены, и запуск в таком случае не состоится: иначе клонированный репозиторий мог бы диктовать, куда уходит трафик. Локальные адреса всегда обходятся стороной, поэтому локальные серверы нельзя случайно завернуть в прокси. Программы, которые пишет модель, прокси-настройки не получают — это сделано, чтобы адрес с логином и паролем не попал в код, сгенерированный моделью.

Вторая — доступ к самому интерфейсу. Встроенный веб-сервер по умолчанию слушает только локальный адрес; номер порта задаётся при запуске, а если не задан — подставляется значение из композиции (в разных слоях поставки встречаются 3000 и 3080, и это ещё одна иллюстрация того, как слой конфигурации меняет поведение по умолчанию). Каждый процесс генерирует случайный маркер запуска, который печатается в строке адреса и обменивается на подписанную cookie, привязанную к конкретному источнику; cookie живёт тридцать дней, помечена как недоступная для скриптов и отправляется только на тот же сайт. Отдельно проверяется заголовок узла и источник запроса — это защита от перенаправления доменного имени и межсайтовых запросов. Проверки честно описаны как защита от конкретных атак, а не как установление личности.

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

И последнее, самое неприятное для паранойи. Хранилище секретов защищено правами файловой системы: документ создаётся доступным только владельцу, а на Unix-подобных системах файл, читаемый другим пользователем, отвергается. Но процессы инструментов запускаются от того же пользователя, что и Harness. Значит, агент технически может прочитать этот файл. Продукт просто не сообщает агенту путь к нему. Документация называет это прямо: сдержанность, а не граница. Если в вашей модели угроз агент не должен иметь доступа к ключам, единственный надёжный способ — не держать ключи в этой среде вообще, а выдавать их через внешний слой, недоступный процессу агента.

Практические рецепты

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

Рецепт 1. Навести порядок в инструкциях для агента

Начните с разделения по смыслу. В глобальный AGENTS.md в домашнем каталоге Harness кладите только личные привычки, которые не зависят от проекта: язык ответов, стиль комментариев, предпочтения по форматированию, отношение к эмодзи в коде. В проектный AGENTS.md — то, что знает только команда: как поднимать окружение, как запускать тесты, какие каталоги нельзя трогать, какие соглашения об именах.

Проверьте цепочку на практике: положите в корне репозитория короткую строку-маркер, затем такую же в подкаталоге, в котором работаете, и попросите агента пересказать полученные инструкции. Так вы сразу увидите порядок «от общего к частному» и убедитесь, что маркер корня найден верно. Если в проекте есть .gitignore-логичная пара «базовый файл плюс локальный», используйте для личных надстроек имена с суффиксом .local и не добавляйте их в репозиторий: они предназначены ровно для этого.

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

Рецепт 2. Сделать проект самодостаточным

Чтобы правила и полезные процедуры ехали вместе с кодом, положите в репозиторий каталог .agents/skills и создайте в нём навыки: отдельный каталог с файлом SKILL.md на каждый. Имя — в нижнем регистре через дефис, описание — обязательное и осмысленное, потому что именно по описанию агент решает, нужен ли навык. В теле опишите процедуру: какие команды запускать, что проверять, чего не делать.

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

Чего этим приёмом не добиться: MCP-серверы и хуки так не переносятся. Они настраиваются на уровне композиции профиля, то есть глобально. Если команде нужен общий MCP-сервер, придётся либо описать его в общем бандле, который все устанавливают, либо зафиксировать инструкцию по установке в проектном AGENTS.md.

Рецепт 3. Правильно дробить работу между субагентами

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

Практические правила, которые я вывел:

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

Рецепт 4. Массовая однотипная работа через сценарий

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

Схема, которая хорошо работает: получить список элементов, провести каждый через конвейер независимо (без общего барьера), а в конце собрать результат. Внутри этапа запускайте агента с запросом структурированного ответа по схеме — тогда на выходе вы получите объект с нужными полями, а не свободный текст, который придётся разбирать регулярками. Схема намеренно ограничена: объект, свойства, обязательные поля, перечисления, константы, объединение. Если нужна более сложная валидация, делайте её сами уже после получения результата.

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

Рецепт 5. Безопасно открыть чужой репозиторий

Порядок действий, который я применяю к незнакомому коду:

1. переключите сессию в режим «только чтение» и работайте в нём, пока не поймёте, что внутри;
2. выключите автоподтверждения на время анализа и не выдавайте расширений прав «на всякий случай»;
3. проверьте, нет ли в репозитории файлов инструкций, и посмотрите, не являются ли они символическими ссылками: содержимое по ссылке читается, а значит, инструкции могут прийти из-за пределов дерева проекта;
4. помните, что песочница ограничивает файловые эффекты, но не сеть. Если репозиторий содержит скрипты, которые что-то скачивают, запрет на запись их не остановит, а проектный .env не сможет подменить прокси — эта попытка вообще не даст запуститься;
5. не храните в этой среде долгоживущие ключи с широкими правами. Идеальный вариант — отдельный ключ с минимальными правами и лимитом расходов, который можно отозвать.

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

Рецепт 6. Подобрать режим доступа под задачу

Практическое правило: режим выбирается по худшему действию, которое задача может потребовать.

• «Только чтение» — аудит, ревью, исследование, ответы на вопросы по коду. Всё, где агент не должен ничего менять.
• «Запись в рабочей папке» — обычная разработка: правки в проекте, запуск тестов, сборка. Всё, что остаётся внутри рабочего каталога.
• «Полный доступ» — установка пакетов, работа с системными путями, настройка окружения. Это режим, в котором исчезает основная граница безопасности, поэтому он заслуживает отдельного решения, а не «поставлю, чтобы не отвлекало».

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

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

Рецепт 7. Подключить внешний сервер инструментов

Добавьте в патч профиля строку с плагином внешнего клиента и блоком настроек: транспорт, локальное имя сервера, команда запуска с аргументами или адрес, переменные окружения, тайм-аут вызова. Имя сервера выбирайте осмысленно и коротко: оно попадёт в имена инструментов, которые увидит модель, и должно быть уникальным в области видимости.

Что учесть сразу:

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

Рецепт 8. Перенести хуки из другой экосистемы

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

Дальше держите в голове границы переносимости. Выполняются только командные обработчики. Часть событий не поддержана, в том числе события сжатия контекста, завершения сессии и запросов разрешений. Директива «остановить прогон» записывается, но не останавливает. Изменённые аргументы вызова не применяются. Путь к расшифровке разговора всегда пуст. Конфигурация читается один раз при запуске, без многослойного поиска и без перезагрузки на ходу. Если ваша логика опирается на что-то из этого списка, переносить её в Harness в текущей версии не стоит.

Рецепт 9. Резервное копирование и перенос рабочего места

Что копировать, если вы хотите воспроизвести среду на другой машине:

• каталог профиля целиком, вместе с манифестом и патчем — это вся композиция;
• глобальный AGENTS.md и каталог личных навыков;
• при необходимости — журналы сессий;
• отдельно и осознанно — файл секретов, либо, что безопаснее, заново ввести ключи на новой машине.

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

Для передачи отдельного разговора используйте экспорт: архив содержит журнал, дочерние сессии и вложения. Вложения при этом копируются как файлы, а объявленные артефакты — только как объявления: сам инструмент выдачи хранит пути, а не содержимое.

Рецепт 10. Настроить несколько провайдеров и ключей

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

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

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

Рецепт 11. Экономить контекст и деньги

Работающие приёмы, проверенные на практике:

• включайте программный режим вызова инструментов там, где задач много и они однотипны: вместо десятков схем инструментов модель получает одну точку входа и сгенерированный программный интерфейс, что сокращает объём каждого запроса;
• делегируйте исследование субагентам: их промежуточные шаги не попадают в вашу историю;
• не держите в контексте большие выводы: механизм сохранения во внешние файлы оставляет в истории начало, конец и путь, а полный текст читается по требованию;
• используйте команду сжатия осознанно: она уменьшает историю, но теряет детали, и после неё часть прежних рассуждений исчезает;
• помните, что повторные попытки при сетевых сбоях тарифицируются каждая: безлимитная политика повторов удобна, но у неё есть цена;
• снижайте уровень рассуждений для рутинных задач и повышайте для сложных: это самый прямой рычаг расхода;
• не включайте лишние необязательные бандлы: планировщик, например, добавляет четыре схемы инструментов в каждый запрос живого агента и одно чтение часов на шаг.

Рецепт 12. Автоматизация по расписанию

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

Что предусмотреть: приложение должно быть запущено, иначе ничего не сработает; при следующем запуске доставится только последнее пропущенное срабатывание повторяющейся задачи; у каждой задачи обязателен заголовок до ста двадцати символов; интервал повторения не может быть меньше минуты, а для сложных случаев есть пятипольное cron-выражение без расширений вроде «последний день месяца». Архивация сессии с активными напоминаниями не пройдёт, пока они не остановлены, а остановка удаляет их безвозвратно.

Частые ошибки и как их не допустить

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

Ошибка 1. Патч затирает настройки строки

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

Ошибка 2. Забыт глобальный патч

Файл cordis.patch.yml в домашнем каталоге Harness применяется после патча профиля и потому перекрывает всё, что сохраняет интерфейс. Если после правки в настройках ничего не меняется, ищите именно этот файл. Интерфейс, к его чести, откажет в записи, которую перекроет верхний слой, но догадаться о причине отказа без знания иерархии трудно.

Ошибка 3. Пустой файл патча

Файл, в котором остались только комментарии, останавливает запуск. Чтобы отключить слой, положите внутрь пустой список — это документированный способ, а не хитрость.

Ошибка 4. Ожидание, что настройка подействует на открытую сессию

Модель, уровень рассуждений, режим доступа и пресет фиксируются при создании сессии. Изменение значения по умолчанию влияет только на будущие сессии и будущих агентов. Если нужно другое поведение сейчас, переключайте его в текущей сессии или создавайте новую.

Ошибка 5. Ставка на проектный файл окружения

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

Ошибка 6. Путаница между глобальными и проектными инструкциями

Инструкции собираются в цепочку: сначала глобальный файл, затем файлы проекта от корня вниз. Если правило не действует, проверьте, не перекрыто ли оно более конкретным файлом ниже по дереву. И помните, что обновление подхватывается не мгновенно: изменения видны после успешной файловой операции в этом каталоге или после возобновления сессии, а переход по каталогам через команду оболочки ничего не подхватывает.

Ошибка 7. Навык не находится

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

Ошибка 8. Ожидание удаления сессии или отката к сообщению

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

Ошибка 9. Поиск по истории «не работает»

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

Ошибка 10. Полный доступ «чтобы не мешало»

Самая дорогая в перспективе ошибка. В настольной сборке полный доступ уже назначен режимом по умолчанию для новых сессий, и это следствие конкретного файла патча, а не свойство продукта. Если вам не нужны системные изменения в каждой задаче, разумнее оставить умеренный режим и повышать его точечно. И помните, что подтверждения выдаются однократно: политики «разрешить всегда» здесь нет.

Ошибка 11. Вера в то, что песочница закрывает сеть и чтение

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

Ошибка 12. Долгая работа в фоне

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

Ошибка 13. Хуки, перенесённые без проверки

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

Ошибка 14. Субагент, которому поручили диалог

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

Ошибка 15. Декларация возможностей вместо проверки

Типы входных данных, которые вы указываете для модели, — это утверждение о конечной точке, а не её проверка. Никто не опрашивает шлюз о том, что он принимает. Если заявить изображения для шлюза, который их не обслуживает, отказ придёт посреди хода, а не при сохранении настроек.

Ошибка 16. Ключ, который «не сохраняется»

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

Сравнение подходов: что выбрать и в чём слабое место

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

Глобальная настройка против проектной

Критерий	Глобально (профиль, домашний каталог)	Проектно (файлы в репозитории)
Что покрывает	Состав плагинов, модели, ключи, доступ, интерфейс	Инструкции, навыки, локальные соглашения
Переносимость	Требует копирования файлов профиля	Едет вместе с кодом
Предсказуемость	Высокая: один источник для всех проектов	Высокая внутри проекта, если все их читают
Риск	Одна правка меняет поведение везде	Правила могут конфликтовать с личными привычками
Слабое место	Приоритеты слоёв легко перепутать	часть возможностей так не переносится: MCP и хуки живут только в композиции

Практический вывод: правила и процедуры — в проект, всё остальное — в профиль. Это разделение даёт максимум переносимости при минимуме сюрпризов.

Инструкции против навыков против MCP

Три способа дать агенту знания, и они не взаимозаменяемы.

Способ	Когда уместен	Слабое место
Файлы инструкций	Постоянные правила проекта: как запускать, что не трогать	Всегда в контексте, поэтому занимают бюджет запроса; ограничены по объёму
Навыки	Процедуры, нужные не всегда: конкретные операции, редкие сценарии	Подгружаются по решению модели; испорченный навык молча исчезает
Внешние инструменты	Доступ к системам за пределами файловой системы	Требуют настройки на уровне композиции, то есть глобальны; чужие имена инструментов занимают контекст

Мой порядок такой: сначала инструкции для того, что должно действовать всегда; затем навыки для процедур; внешние инструменты — только когда нужны реальные данные из внешней системы.

Субагенты против команд против сценариев

Инструмент	Сильная сторона	Слабая сторона
Субагент	Простота, изоляция контекста, ветвление с наследованием	Глубина один уровень, восемь одновременных детей, диалог невозможен
Команда агентов	Явные роли, общая доска задач, зависимости, долговременные участники	Экспериментальный слой, подсказки по файлам не блокируют, владение не освобождается само
Сценарий оркестрации	Много однотипных элементов, структурированные ответы, фазы	Нет возобновления после сбоя, ошибка в скрипте рушит прогон, дедлайна нет

Правило выбора простое: одна независимая задача — субагент; несколько исполнителей с общим планом и зависимостями — команда; сотни однотипных элементов — сценарий.

Обычные инструменты против программного режима

Обычный режим даёт модели десятки явных схем инструментов. Программный режим даёт одну точку входа и сгенерированный интерфейс, а модель пишет программу, которая вызывает нужные операции. Второй режим заметно сокращает объём описаний в запросе и позволяет аккуратно выражать циклы и условия, но требует от модели навыка программирования и хуже подходит для одиночных действий. Промежуточный вариант посылает и то, и другое, что удобно для переходного периода, но не экономит контекст.

Режимы доступа

Режим	Когда	Цена
Только чтение	Анализ, ревью, ответы на вопросы	Невозможны правки и установка пакетов
Запись в рабочей папке	Обычная разработка	Запись вне рабочей папки требует повышения
Полный доступ	Системные изменения, установка	Граница файловой безопасности исчезает полностью

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

Практический чек-лист

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

Профиль и композиция:

1. Проверьте, какой путь используется как домашний каталог Harness, и запишите его.
2. Выгрузите итоговую конфигурацию и сохраните её рядом с проектом — это ваша карта на случай непонятного поведения.
3. Проверьте, нет ли глобального патча, который перекрывает настройки профиля.
4. Решите, какие бандлы вам действительно нужны, и отключите лишние необязательные.
5. Зафиксируйте, какой пресет агента выбран по умолчанию.

Инструкции и навыки:

6. Напишите глобальный файл инструкций и ограничьте его личными привычками.
7. Напишите проектный файл инструкций: команды запуска, тесты, запретные каталоги, соглашения.
8. Проверьте, что маркер корня проекта найден и цепочка собирается в правильном порядке.
9. Следите за суммарным объёмом инструкций и держите его ниже бюджета.
10. Создайте навыки для повторяющихся процедур и проверьте, что они видны в каталоге.
11. Убедитесь, что локальные надстройки не попадают в репозиторий.

Безопасность:

12. Выберите режим доступа, исходя из худшего действия, которое может понадобиться.
13. Проверьте, какие подтверждения действуют и есть ли вообще канал для них.
14. Убедитесь, что вы понимаете: сеть и чтение песочницей не ограничиваются.
15. Проверьте права на файл секретов и не держите в среде ключи с широкими правами.
16. Для чужих репозиториев работайте в строгом режиме и просматривайте инструкции на предмет символических ссылок.
17. Решите, нужен ли вам сетевой доступ к интерфейсу, и если да — организуйте его через туннель, а не через открытый порт.

Модели и ключи:

18. Настройте основной маршрут и проверьте, что ключ действительно используется, а не перекрыт окружением.
19. Добавьте резервный маршрут, если зависите от одного провайдера.
20. Проверьте, какие модели заявляют приём изображений, и не заявляйте лишнего.

Контекст и расход:

21. Оцените, нужен ли вам программный режим вызова инструментов.
22. Проверьте порог сохранения больших выводов: если он не задан, механизм отключён.
23. Определите политику повторных попыток: безлимитные повторы тарифицируются.
24. Настройте ограничение параллельных вызовов инструментов под свою машину.

Команда и процессы:

25. Договоритесь о зонах ответственности, если работаете с командой агентов.
26. Зафиксируйте, что делается субагентом, что сценарием, а что руками.
27. Проверьте, что продолжение работы после сбоя обеспечено системой контроля версий, а не средой агента.

Обслуживание:

28. Настройте периодическую выгрузку важных сессий.
29. Почистите кэш и временные файлы сохранённых выводов.
30. Проверьте, как изменилась конфигурация после последнего обновления продукта: preview-версии меняются быстро.

Пять малоизвестных фактов

Я собрал то, что редко попадает в обзоры, но полезно на практике.

Первый: песочница вообще не занимается сетью. Даже в самом строгом режиме изолированный процесс может открывать сетевые соединения, а на Windows — читать любые файлы, доступные пользователю. Словарь политики ограничен файловыми эффектами; ни процессов, ни системных вызовов, ни устройств, ни учётных данных он не описывает. Любая защита данных строится вне этой границы.

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

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

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

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

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

Частые вопросы

Где хранятся настройки DeepSeek Harness?

В нескольких местах, и это принципиально. Глобально — в домашнем каталоге Harness (по умолчанию это скрытый каталог .dsh в домашнем каталоге пользователя, переопределяется переменной окружения DSH_HOME): там лежат профили, состав плагинов, секреты, журналы сессий, хранилища состояния, вложения и кэш. Локально в проекте — файлы инструкций и навыки. Отдельно живут настройки сессии: режим доступа, модель, цель, план. И отдельно — состояние браузера: порядок сессий в списке, раскрытые группы, черновики.

Чем локальная настройка отличается от глобальной?

Глобальная действует на все проекты и обычно сохраняется в патч профиля или в хранилище. Локальная относится к конкретному каталогу или к конкретной сессии. Ключевое отличие в том, что автоматических правил вида «в этом каталоге использовать такую модель» нет: модель и режим доступа выбираются для сессии. Зато инструкции и навыки действительно привязаны к каталогу, потому что читаются из файлов проекта.

Как задать разные модели для разных проектов?

Штатного правила по каталогу нет. Работающие варианты: создавать отдельные профили под разные типы работы, переключать модель в начале сессии командой выбора модели или переопределять модель по умолчанию в патче профиля и держать для этого отдельный профиль. Первый вариант чище: профиль — это как раз именованный набор слоёв.

Почему изменение настройки не подействовало?

Три типичные причины. Первая: настройка относится к будущим сессиям, а вы смотрите на текущую. Вторая: значение перекрыто слоем с более высоким приоритетом, например глобальным патчем или оверлеем командной строки. Третья: настройка читается один раз при создании компонента и требует перезапуска. Проверяйте в этом порядке.

Можно ли удалить сессию?

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

Как перенести всю конфигурацию на другую машину?

Скопируйте каталог профиля (манифест с бандлами и патч), глобальный файл инструкций, личные навыки. Секреты переносите отдельно и лучше вводите заново. Журналы сессий переносите только при необходимости и помните, что группировка привязана к путям каталогов: на новой машине пути будут другими, и сессии окажутся вне группировки.

Насколько безопасна песочница?

Она ограничивает файловые эффекты и делает это добросовестно, но не является границей ядра и не касается сети, процессов и чтения. Часть гарантий на Windows помечена как частичная. Постоянные записи в правах доступа остаются после переключения режима. Если вам нужна настоящая изоляция, используйте виртуальную машину или контейнер: документация прямо говорит, что контейнеры и удалённое исполнение требуют замены реализаций, а не настройки этой песочницы.

Как добавить свои правила для агента?

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

Что будет, если удалить домашний каталог Harness?

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

Как отключить телеметрию?

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

Вывод: что делать читателю

Если сжать всё сказанное до последовательности действий, получится такой план.

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

Затем разведите ответственность между глобальным и проектным. В проект положите инструкции и навыки: что запускать, что проверять, чего не касаться. В глобальные настройки — то, что не зависит от проекта: маршруты моделей, режим доступа по умолчанию, оформление. Это разделение окупается при первой же передаче проекта коллеге или при переустановке.

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

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

И последнее, самое важное. Относитесь к конфигурации как к коду: держите патчи профиля в системе контроля версий, фиксируйте, почему выбрано то или иное значение, пересматривайте решения после обновлений. Продукт находится в стадии preview, отдельные детали между релизами меняются, и единственная страховка от неожиданностей — понимание слоёв и собственные заметки о том, что вы и зачем настроили. Информация в этой статье проверена по состоянию на сентябрь 2026 года на сборке 0.2.0-rc.2; если вы читаете её заметно позже, сверьте ключевые для вас пункты с текущей выгрузкой конфигурации.

Если хотите опереться на фундаментальные работы по теме, а не только на документацию конкретного продукта, полезны несколько текстов. Принцип вынесения конфигурации в окружение и разделения сред разобран в «Двенадцатифакторном приложении» Адама Уиггинса (2011) — оттуда, по сути, и растёт вся логика «конфигурация отдельно от кода». Цикл «рассуждение — действие» как основу агентского поведения описали Шунью Яо и соавторы в работе «ReAct: Synergizing Reasoning and Acting in Language Models» (2023). Обучение моделей пользоваться инструментами разобрано у Тимо Шика и соавторов в «Toolformer» (2023), а идея вербальной саморефлексии агента — у Ноа Шинн и соавторов в «Reflexion» (2023). Обзорное устройство автономных агентов на больших языковых моделях дали Лэй Ван и соавторы в работе «A Survey on Large Language Model based Autonomous Agents» (2023). Наконец, стандарт подключения внешних инструментов и данных описан в спецификации Model Context Protocol (Anthropic, 2024) — именно на этот подход опирается поддержка внешних серверов в Harness.