Я подключил Codex к Яндекс.Диску через официальное приложение Яндекса, провёл metadata-only аудит, нашёл дубли, вынес мусор в карантин и подготовил облако к дальнейшей миграции.
Облако незаметно превращается в кладовку. Сначала туда падают документы, потом архивы, потом видео, потом «временные» папки, потом дубли, потом дубли дублей, потом старые рабочие материалы, которые уже никто не помнит. В какой-то момент ты заходишь в Яндекс.Диск и видишь не хранилище, а платную археологию.
Яндекс, как и все большие облака, довольно настойчиво напоминает: место заканчивается, тарифы меняются, платить придётся больше. Само по себе это нормально — хранение стоит денег. Но возникает вопрос: за что именно я плачу? За нужные файлы — или за десять лет цифрового осадка?
Я решил не гадать, а подключить к Яндекс.Диску Codex и провести нормальный аудит: посмотреть структуру, найти дубли, вынести мусор в карантин и подготовить переезд в более управляемую систему хранения.
И самое интересное: всё это делается не через хаки, не через парсинг веб-интерфейса и не через «дай пароль от аккаунта». Через официальный API Яндекс.Диска.
Обычный человек чистит облако руками: открывает папку, смотрит, устаёт, закрывает. Через неделю снова открывает, снова видит хаос — и решает купить ещё места.
У агента другой режим. Ему можно дать задачу:
md5 + sizeCodex работает не как «умная кнопка удалить всё», а как аккуратный оператор: сначала инвентаризация, потом классификация, потом карантин, потом отдельное решение на удаление.
Для личного облака это уже полезно. Для клиентской услуги — ещё интереснее: хаотичный «разберите мне Диск» превращается в повторяемый pipeline.
Сначала мы пошли сложным путём — через уже существующего агента на сервере, у которого был доступ к Яндексу. Это помогло быстро понять архитектуру и проверить, что задача вообще решаемая.
Но для нормальной повторяемой схемы такой путь плох. Он слишком косвенный: лишний сервер, лишний контур доступа, сложнее объяснять клиенту, сложнее сопровождать.
Поэтому мы сделали правильную версию:
600.Токен — это не пароль от аккаунта. Это отдельный ключ доступа для конкретного приложения с конкретными правами. Его можно отозвать. Можно выдать заново. Можно хранить отдельно от проекта. Его не надо печатать в чат, класть в git или отправлять подрядчикам.
В нашем случае токен лежит локально, вне репозитория, а все отчёты проходят secret-scan, чтобы туда случайно не попали OAuth-значения.
Самое опасное в таких задачах — слишком рано начать «наводить порядок».
Если агент сразу получает write-доступ и начинает двигать файлы, можно быстро получить красивую катастрофу: папки переехали, контексты смешались, релизные архивы разрушены, а через месяц выясняется, что «мусор» был единственной копией нужного исходника.
Поэтому первая фаза была строго read-only:
Мы собирали только безопасные поля: путь, тип, размер, md5, MIME-type, дату изменения, верхнюю папку. Этого достаточно, чтобы понять структуру и найти точные дубли, но недостаточно, чтобы случайно раскрыть содержимое файлов или начать вмешиваться в данные.
Обнаружилось ровно то, что обычно обнаруживается в многолетнем облаке:
_Review, _from-downloads, РазобратьНапример, если два файла совпадают по md5 + size — содержимое одинаковое. Один из них можно считать лишней копией, если мы понимаем, какая копия остаётся.
Но если похожие файлы лежат в разных контекстах — в релизном архиве, рабочем проекте и медиа-папке — это уже не технический дубль. Это вопрос политики хранения: какая папка каноническая, что считается архивом, что рабочей зоной, что публикационным материалом.
Codex здесь полезен именно тем, что не обязан притворяться всезнающим. Он может честно сказать: «это точный дубль, можно в карантин», а вот «это смысловой дубль, нужен ручной выбор».
Мы не удаляли файлы сразу.
Сначала завели _Quarantine — отдельную папку для всего, что надо убрать из активной структуры, но ещё нельзя окончательно уничтожать.
Это принципиально меняет психологию очистки. Удаление — страшно: ошибся, и файл пропал. Карантин — спокойнее: файл больше не мешает, но его можно вернуть.
В карантин попадали разные типы объектов:
Важная тонкость: карантин — это не «папка, которую можно удалить целиком». Внутри него разные классы. Поэтому перед финальным удалением мы сделали delete-readiness manifest: отделили подтверждённые дубли от всего остального.
После серии проходов появилась нормальная картина:
Загрузки были разгружены и оставлены как стандартная входящая папка_Music, _Projects, _Media, _Archive, Uplifto, Фабрика контента, НЕСПАТЬ! коллекцияОтдельный показательный момент: только подтверждённый Level A duplicate delete-pass освободил около 180 ГБ. Это не «мы удалили всё подряд». Это папки, которые прошли через quarantine pipeline и были признаны exact-дублями по правилам.
Хороший пример того, как агентная работа должна отличаться от бытовой уборки: не «кажется, можно стереть», а «есть manifest, есть evidence, есть approval, есть rollback через корзину».
Почти у каждого активного человека есть облако, которое когда-то было удобным, а потом превратилось в склад.
Особенно если вы работаете с видео, музыкой, документами, проектами, клиентами, презентациями, архивами. Там быстро накапливаются сотни гигабайт, где руками уже невозможно понять:
Вручную такая работа неприятная и дорогая. С агентом она превращается в понятный процесс:
Это уже не «помощь с файлами». Это маленький data-ops для личного или проектного архива.
Следующий шаг — не просто почистить Яндекс.Диск, а подготовить переезд.
Яндекс сейчас активно подталкивает к оплате дополнительного места. Я не против платить за инфраструктуру, но хочу понимать, что храню, где храню и зачем. Если часть данных лучше держать в Google Drive, часть в локальном Synology, часть в холодном хранилище, а часть вообще удалить — это моя архитектура, а не тарифная ловушка.
Codex здесь становится не «чатом, который пишет код», а оператором личной инфраструктуры:
И это, кажется, очень практичное будущее. Не абстрактные «ИИ-агенты когда-нибудь будут что-то делать», а вполне конкретный агент, который берёт старый Яндекс.Диск, смотрит на него спокойно, раскладывает по полкам и говорит:
Вот это дубли. Вот это архив. Вот это трогать нельзя. Вот это можно вынести. Вот это лучше перенести в другое хранилище. А вот здесь нужен человек.
С этого и начинается нормальное управление цифровым хозяйством.
Если у вас тоже накопился многолетний облачный архив и вы думаете, как к нему подступиться с помощью агента — пишите, разберёмся вместе.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov