Симптом: один и тот же Agent Preset загружается по-разному у разных пользователей, а после переустановки Mac никто не может точно сказать, какая версия была рабочей.
Быстрое решение: личные эксперименты и временные связки оставляйте на пользовательском уровне, командный стандарт размещайте на системном уровне, а для общего Mac используйте системную неизменяемую базу и ограниченный пользовательский слой.
Эта схема подходит, если вам нужно одновременно сохранить скорость индивидуальной настройки, исключить незаметную подмену Preset и воспроизводимо развернуть окружение на новом или удалённом Mac.
SECTION 01Кому нужен такой разбор
Материал рассчитан на разработчиков, которые сохраняют личные наборы Agent Preset, но не хотят влиять на других пользователей. Он также нужен платформенным инженерам, отвечающим за единый командный стандарт, и специалистам по безопасности, которые контролируют запись, аудит и возврат изменений на общем Mac.
В тексте рассматривается именно размещение и ответственность за Agent Preset. Это не руководство по разрешениям инструментов, не сравнение Plan Mode и прямого выполнения и не инструкция по поиску Skills.
DeepSeek Harness находится в режиме developer preview, поэтому каталоги, интерфейс и поведение загрузчика необходимо сверять с текущим выпуском перед эксплуатацией. Официальный репозиторий прямо предупреждает о возможных несовместимых изменениях. (github.com)
SECTION 02Почему уровень размещения — это вопрос доверия, а не удобства
DeepSeek Harness построен вокруг подключаемых компонентов, а Cordis используется как основа для композиции плагинов и сервисов. Поэтому Agent Preset — это не просто сохранённое имя профиля: он может определять, какие компоненты и рабочие связки будут доступны агенту в конкретном запуске. Официальное описание проекта отдельно подчёркивает плагинную архитектуру и зависимость от Cordis. (github.com)
Системный и пользовательский уровни отличаются прежде всего источником конфигурации и тем, кто отвечает за её содержимое.
Системный Preset обычно означает:
- конфигурация подготовлена платформенной командой или владельцем окружения;
- версия должна иметь источник, дату изменения и понятного ответственного;
- пользователи получают единый базовый набор;
- запись в каталог должна быть ограничена;
- удаление или замена выполняется через контролируемый процесс.
Пользовательский Preset обычно означает:
- конфигурацию создаёт конкретный разработчик, локальный скрипт или сам Agent;
- изменения происходят быстрее и чаще;
- содержимое может быть полезным, но ещё не прошло проверку;
- оно привязано к учётной записи и может исчезнуть после очистки домашнего каталога;
- соседние пользователи не обязаны видеть его или доверять ему.
Главная ошибка — считать Preset доверенным только потому, что он успешно загрузился. Успешное обнаружение файла подтверждает лишь техническую доступность источника. Оно не доказывает происхождение, отсутствие нежелательных инструментов, соответствие командной политике или совместимость с текущим выпуском.
Для команды это означает следующее: пользовательский слой подходит для эксперимента, но не должен быть единственным носителем обязательного поведения, правил обработки данных, корпоративных подключений и требований к поставке.
Что в этом контексте означает Cordis? Cordis — это инфраструктурный слой, связанный с компонуемостью компонентов, а не название уровня хранения конфигурации. Нельзя делать вывод «конфигурация использует Cordis, значит она системная». Источник, права и способ доставки определяются отдельно.
Полезно также читать официальные архитектурные материалы проекта и исходные файлы, отвечающие за конфигурацию, но перед внедрением нужно фиксировать конкретную ревизию, а не ссылаться на изменяемую ветку.
SECTION 03Как выбрать уровень размещения до первой установки
Если решение принимается только по принципу «где проще сохранить файл», вы пропускаете наиболее дорогие последствия: скрытую подмену, невозможность воспроизведения и неясный порядок отката.
Используйте этот список как оперативный инструмент. Отметьте все подходящие условия:
- [ ] Preset нужен только одному разработчику и часто меняется.
- [ ] Экспериментальная конфигурация не должна влиять на коллег.
- [ ] Preset должен входить в каждый новый командный Mac.
- [ ] Его содержимое нужно проверять до публикации.
- [ ] После сбоя требуется вернуть предыдущую версию без ручного поиска.
- [ ] На одном Mac работают несколько независимых пользователей.
- [ ] Нужно отделить клиентские проекты или разные уровни доступа.
- [ ] Пользователь должен иметь личные расширения поверх общей базы.
Дальше применяйте условия последовательно:
- Если отмечены только первые два пункта, выбирайте пользовательский уровень.
- Если отмечены пункты о командной поставке, проверке и откате, выбирайте системный уровень.
- Если одновременно отмечены командная база и личные расширения, используйте системный Preset только для чтения плюс пользовательский слой.
- Если отмечены независимые клиентские проекты или несовместимые права, разделяйте окружения, учётные записи или корни загрузки, а не пытайтесь решить проблему двумя одноимёнными файлами.
- Если вы не можете назначить владельца версии и доказать источник файла, не публикуйте Preset как командный стандарт.
- Если пользователь может изменять общий корень, вернитесь к системной установке с ограниченной записью либо полностью разделите среды.
Это не формальная классификация ради документации. Список связывает техническую настройку с ответственностью: кто имеет право менять Preset, кто подтверждает его происхождение и кто обязан восстановить рабочее состояние.
SECTION 04Как проверить путь загрузки и приоритет одноимённых Preset
Официальная конфигурационная модель подтверждает наличие нескольких корней сканирования, пользовательского корня, системного и пользовательского типа доверия. Но конкретные каталоги, порядок обхода и поведение при изменении версии должны проверяться по текущему исходному коду и выпуску, поскольку проект быстро меняется. (github.com)
Если один и тот же идентификатор существует в нескольких корнях, название в интерфейсе не отвечает на главный вопрос: какой файл реально победил. В результате можно редактировать пользовательский файл, а запуск продолжит брать системную копию — или наоборот.
Где искать пользовательский каталог для DeepSeek Harness? Не следует запоминать путь из чужой инструкции как постоянный факт. Сначала определите активную версию, найдите в её конфигурации список корней и зафиксируйте, включён ли пользовательский источник. Затем сохраните результат проверки вместе с ревизией проекта и датой.
Минимальный тест на изолированном окружении должен выглядеть так:
- создайте два безопасных Preset с одним идентификатором;
- разместите один в предполагаемом системном корне, второй — в пользовательском;
- добавьте в описание каждого источника различимый маркер, не содержащий секретов;
- перезапустите DeepSeek Harness после каждого изменения;
- проверьте фактически применённый маркер;
- сопоставьте результат с журналом или диагностикой загрузчика;
- удалите тестовые файлы после проверки.
Не используйте для такого эксперимента рабочие ключи, клиентские каталоги, сетевые подключения или команды с побочными эффектами. Цель теста — определить источник и приоритет, а не проверить функциональность конкретного Agent Preset.
Какой одноимённый Agent Preset загружается первым? Надёжный ответ можно получить только через контролируемый тест на текущей версии. Не делайте вывод по алфавитному порядку, дате изменения файла или отображаемому имени. Если порядок корней изменился между выпусками, прежняя локальная проверка перестаёт быть доказательством.
В журнале эксплуатации фиксируйте:
- версию DeepSeek Harness;
- ревизию исходного кода или идентификатор выпуска;
- включённые корни;
- фактический порядок сканирования;
- результат одноимённого теста;
- действие при конфликте идентификаторов;
- дату следующей проверки после обновления.
Это особенно важно для команды, которая считает пользовательскую копию временным расширением, но не проверяет, может ли она перекрывать системный Preset.
SECTION 05Когда системный уровень оправдан для команды
Системный уровень выбирайте, когда Preset должен стать частью поставляемого окружения, а не личной настройки. Критерий здесь не размер команды, а цена расхождения между двумя запусками.
Системный вариант имеет смысл, если:
- новый удалённый Mac должен получить тот же базовый набор;
- окружение регулярно пересоздаётся после сбоя или миграции;
- Preset участвует в регламентированном рабочем процессе;
- владельцу нужно проводить проверку изменений до публикации;
- требуется быстро вернуть предыдущую рабочую версию;
- поддержка должна диагностировать проблему без доступа к личному домашнему каталогу пользователя.
Как команде распространять Preset только для чтения? Храните исходник в версионируемом репозитории, а на Mac устанавливайте конкретную утверждённую ревизию в системный корень с правами, исключающими запись обычному пользователю. Установка должна выполняться скриптом или управляемой процедурой, а не ручным копированием неизвестного файла.
Для каждой версии сохраняйте:
- идентификатор ревизии;
- список изменённых Preset;
- владельца проверки;
- результат загрузки;
- разрешения файлов и каталога;
- предыдущую версию;
- процедуру удаления или возврата.
Не помещайте в Agent Preset секреты, токены и постоянные учётные данные. Preset должен ссылаться на контролируемые интерфейсы или внешние механизмы доступа, а не превращаться в плохо защищённый контейнер для ключей.
Официальный репозиторий предоставляет исходный код, документацию и инструкции запуска; для воспроизводимой поставки используйте зафиксированную ревизию, а не плавающую ветку. Встроенный запуск через пакетный менеджер и запуск из исходников описаны в официальном руководстве проекта. (github.com)
Плюсы и ограничения системного Preset
Преимущества:
- единый командный baseline;
- предсказуемое восстановление после переустановки;
- централизованный аудит;
- меньше скрытых различий между пользователями;
- понятный владелец изменения.
Ограничения:
- любая ошибка затрагивает больше запусков;
- тестирование перед публикацией становится обязательным;
- разработчику приходится получать разрешение на изменение общей базы;
- несовместимость новой версии может проявиться сразу у всей команды.
Системный уровень не является автоматически безопасным. Он просто делает ответственность видимой. Если системный каталог изменяется вручную и без истории, вы получаете централизованную, но всё ещё невоспроизводимую конфигурацию.
SECTION 06Что оставить пользователю для быстрой итерации
Пользовательский уровень нужен не для обхода командной политики, а для безопасной персонализации поверх проверенной основы.
Туда можно помещать:
- экспериментальные наборы агентов;
- временные связки инструментов;
- личные подсказки и формат ответа;
- тестовые варианты для отдельного проекта;
- настройки, которые не должны влиять на коллег;
- Preset, срок жизни которого заранее ограничен.
Пользовательский Agent Preset нельзя использовать как место для обязательных ограничений безопасности, командных стандартов, общих клиентских правил или скрытых зависимостей. Если удаление пользовательского файла ломает общий процесс, значит его выбрали не на том уровне.
Можно ли пользователю изменять Preset по умолчанию на общем Mac? Только если изменение ограничено его учётной записью и не способно заменить системную базу для других пользователей. Если пользователь может редактировать общий корень, менять содержимое одноимённого Preset или отключать аудит, это уже не персонализация, а изменение общей политики.
Для индивидуальной работы пользовательский слой удобнее: цикл «создал — проверил — удалил» короче, а риск случайно нарушить командный baseline ниже. Но именно из-за низкого барьера записи пользовательский источник нельзя считать доверенным без отдельной проверки.
SECTION 07Три схемы для общего Mac
На общем или удалённом Mac обычно встречаются три режима управления.
Системная база и пользовательские расширения
Это рекомендуемый вариант для большинства команд:
- системный корень содержит утверждённые Preset;
- обычный пользователь не может изменять базовые файлы;
- пользовательский корень разрешён для личных расширений;
- одноимённые идентификаторы запрещены или проверяются отдельно;
- при диагностике сначала отделяется базовый слой от расширения.
Такой режим сохраняет индивидуальную гибкость, но оставляет платформенной команде контроль над исходной конфигурацией.
Полностью раздельные окружения
Используйте раздельные корни или отдельные учётные записи, если пользователи работают с разными клиентскими проектами, имеют несовместимые требования или должны исключить взаимное влияние.
Переходите к полному разделению, если выполняется хотя бы одно условие:
- разные пользователи должны иметь несовместимые наборы инструментов;
- один проект содержит данные, которые нельзя смешивать с другим;
- требуется независимый журнал изменений;
- пользовательские расширения невозможно надёжно ограничить;
- после инцидента нужно быстро отозвать доступ только у одной стороны.
В таком случае общий Preset Root становится источником скрытой связанности. Экономия на общей папке обычно компенсируется более сложной диагностикой и восстановлением.
Общий изменяемый корень
Это самый быстрый, но наименее управляемый режим. Его можно применять только для краткоживущей лаборатории без чувствительных данных и без требования воспроизводимой поставки.
Недостатки очевидны:
- непонятно, кто изменил конфигурацию;
- обновление одним пользователем влияет на остальных;
- откат может вернуть не ту версию;
- одноимённый Preset создаёт скрытый конфликт;
- удаление учётной записи не гарантирует удаление её изменений.
Для постоянной общей среды этот вариант лучше считать временным исключением, а не целевой архитектурой.
SECTION 08Пошаговая схема внедрения
Первый шаг: зафиксируйте границы ответственности
Составьте список того, что должно быть одинаковым у всех, и того, что допускает персонализацию. Если элемент влияет на безопасность, клиентский проект, обязательный процесс или диагностику, отправьте его в системный слой.
Второй шаг: проверьте текущую версию
Запишите версию DeepSeek Harness, ревизию исходников и дату проверки. У проекта пока developer preview, поэтому старый пример каталога нельзя переносить в новую установку без проверки. (github.com)
Третий шаг: найдите и зафиксируйте корни
Проверьте конфигурацию, которая отвечает за Agent Preset: системный корень, пользовательский корень, возможность отключения пользовательского источника, порядок обхода и отметку доверия. Не публикуйте в документации реальные домашние пути клиентов или имена учётных записей.
Четвёртый шаг: проведите безопасный тест совпадающих идентификаторов
Создайте два безвредных тестовых Preset с одинаковым ID и различимым описанием. После запуска определите, какой источник реально применён. Результат сохраните в эксплуатационную запись, затем удалите тестовые файлы.
Пятый шаг: установите права
Для системного слоя запретите запись обычным пользователям. Для пользовательского слоя ограничьте область действия домашним каталогом владельца. Проверяйте не только права самого файла, но и возможность записи в каждый родительский каталог.
Шестой шаг: добавьте версионирование и возврат
Каждое изменение системного Preset должно ссылаться на конкретную ревизию. Храните предыдущую рабочую версию и проверяйте, что возврат действительно удаляет новую копию, а не оставляет конфликтующий пользовательский файл.
Седьмой шаг: проверьте новый Mac
Разверните чистое окружение, установите системный слой, создайте тестовую пользовательскую надстройку и убедитесь, что базовый Preset загружается предсказуемо. Затем удалите пользовательский слой и повторите запуск.
Восьмой шаг: оформите операционную запись
Минимальная запись должна содержать источник, версию, владельца, права, результат одноимённого теста, дату проверки и условия отката. Реальное содержимое Preset и внутренние пути в неё включать не нужно.
SECTION 09Как не смешать Agent Preset с другими механизмами
Проблемы часто возникают не из-за неправильного каталога, а из-за подмены понятий.
Agent Preset отвечает за состав и запуск определённой конфигурационной связки. Предустановка разрешений описывает доступы или ограничения выполнения. Plan Mode определяет режим работы с планированием и подтверждением действий. Skills являются отдельным механизмом обнаружения и подключения специализированных возможностей.
Если вы переносите файл между этими категориями, каталог может быть технически корректным, но результат окажется непредсказуемым. Перед публикацией проверьте, что документ описывает именно Agent Preset, а не набор разрешений, режим исполнения или проектные Skills.
Практическое правило простое: сначала определите сущность, затем её источник доверия, затем уровень размещения. Нельзя выбрать системный каталог только потому, что конфигурация кажется важной; сначала нужно подтвердить, что она действительно является Preset и что её состав допустим для общего окружения.
SECTION 10Решение без долгих споров
Используйте следующие условия:
- Если Preset нужен только вам для эксперимента, выбирайте пользовательский уровень.
- Если Preset обязателен для команды, выбирайте системный уровень.
- Если пользователи работают на общем Mac, но имеют личные расширения, выбирайте системную базу только для чтения плюс пользовательский слой.
- Если одноимённые Preset должны вести себя по-разному, не полагайтесь на приоритет — разделите корни или окружения.
- Если конфигурация содержит секреты или определяет обязательные границы доступа, не храните её как обычный пользовательский Preset.
- Если вы не можете доказать источник и версию загруженного файла, остановите распространение до завершения минимального теста.
- Если откат требует ручного поиска неизвестной папки, системная схема ещё не готова к командной эксплуатации.
Для небольших личных экспериментов такая дисциплина может казаться избыточной. На общем Mac она быстро окупается: вы отделяете ошибку пользователя от ошибки базовой поставки и не пытаетесь восстанавливать всю среду по памяти.
SECTION 11Когда для этой задачи нужен удалённый Mac
Локальный Mac удобнее, если вы единственный пользователь, часто меняете Preset и не обязаны воспроизводить среду. Но для командной проверки и временной выдачи окружения важнее другое: возможность получить чистую среду, установить системный baseline, проверить права и затем вернуть машину к известному состоянию.
При выборе размещения на удалённом Mac учитывайте реальные ограничения текущего варианта:
- общая машина может смешивать пользовательские каталоги;
- ручная настройка после каждого сброса создаёт расхождения;
- пользователю трудно подтвердить, какой источник Preset фактически победил;
- при совместном доступе расширения могут пережить завершение отдельной сессии.
Если вам нужно проверить такой сценарий на временной рабочей среде, сначала сопоставьте требования к изоляции, сроку работы и возврату с возможностями аренды Mac в MACNOX. Для постоянной тяжёлой нагрузки и требований к физическим интерфейсам собственный Mac может быть рациональнее, но для тестовой поставки, командной проверки и краткосрочного удалённого окружения управляемая аренда обычно избавляет от ручной подготовки каждой машины.
Главное — не переносить на MACNOX хаотичную модель с общим изменяемым корнем. Если вам нужен стабильный результат, заранее определите системную базу, пользовательские расширения, права записи и процедуру отката; варианты среды и условия аренды можно сопоставить на странице тарифов MACNOX.
В итоге выбор делается не по тому, какой каталог проще открыть. Пользовательский уровень отвечает за скорость личной итерации, системный — за доверенный командный baseline, а для общего Mac наиболее устойчивой остаётся двухслойная схема: системный Preset только для чтения, пользовательские дополнения в ограниченной области и обязательная проверка одноимённых источников перед эксплуатацией.