История

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

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

Как составлена эта история

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

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

Сама эта запись необычна. Она охватывает больше пятнадцати месяцев, с июня 2025 по октябрь 2026 года: в архиве чата 852 разговора и 54 712 сообщений (июнь 2025 — май 2026), а с марта 2026 года — 1217 рабочих сессий той же пары «человек — агент», около 100 тысяч обменов репликами. Долгая непрерывная запись того, как один человек и один ИИ-агент месяцами работают вместе, — на наш взгляд, самостоятельный материал для исследования: манифест Silicon Psychology уже опирался на её более раннюю часть (422 сессии).

Хронология

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

Линии исследований

Граница самостоятельности агента: необратимое — по слову человека

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Хуки-«айкидо»: направлять, а не запрещать

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Психология модели и интервью модели

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Выбор имени замером

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Векторный поиск по памяти

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

• Два векторных канала видят разные части памяти: их первые десять результатов совпадают лишь примерно на 12 процентов (замер на 20 запросах). Совпадение измерено; считать его свойством моделей, а не дефектом, — наше прочтение.
• При повторной проверке на 40 подсказках судья, не знавший, откуда находка, признал прямо относящимися к делу 38 процентов находок второго канала и 42 — первого. Судья оказался мягче второй оценки, поэтому сравнению каналов мы доверяем больше, чем самим долям.
• Часть промахов поиска шла от описания, обещавшего больше, чем поиск делал по умолчанию; это измерено и проверено по источнику, а первый диагноз мы исправили.

Архитектура памяти и её внешние слои

Началась: март 2026 · последний записанный шаг — июль 2026

С чего началось

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

К чему пришли

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

Что нашли

• Хранить и иметь доступ — не одно и то же: знание, добытое вне сессии и сохранённое в файл, подсказкам сессии не видно. Это рабочая гипотеза с одним живым примером.
• Когда памятка переросла свой предел, первое объяснение — что записей стало слишком много — оказалось не главным: по замеру, около четверти её объёма занимала одна нераздробленная запись.
• Слой решений, ошибок и выводов можно связать с источниками в обе стороны, но обратно, как показал замер, связалась лишь часть записей.

Наследование между сессиями

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Язык: Tongue и калибровка утверждений

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Пробирщик: инструменты качества

Началась: март 2026 · последний записанный шаг — июнь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Метод исследования: от накопления к формализации

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

Метод пришёл из предыдущей среды; мы называем его по Бэкону и Коши, и суть его в двух шагах: сначала накопить опыт, потом строго формализовать. Нам был нужен инструмент, а не теория. Пять отдельных правил, которыми мы пользовались (не оптимизировать рано, исследовать до кода, проверять новое и другие), оказались одним правилом в пяти областях. А из рабочих сессий проступили повторяющиеся промахи агента: правила, записанные в память, сами по себе его привычек не меняли.

К чему пришли

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

Что нашли

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

Устройство инструмента, на котором мы работаем

Началась: апрель 2026 · последний записанный шаг — июль 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Экономика токенов и разделение труда между моделями

Началась: апрель 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Самонаблюдение системы

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

• Из 200 последних изменений подряд около половины пришлось на продукт и около трети на инфраструктуру. Это соотношение измерено, и оно согласуется с тем, что система росла частями, по ходу работы, а не по заранее составленному проекту.
• Тихие деградации копятся без шума и находятся случайно — так было не раз, и поэтому молчание при норме стало принципом наших проверок.
• Независимый проход проверки нашёл дефект, который дважды пропустил рецензент одного и того же рода; это был один случай.

Браузер как орган агента

Началась: февраль 2026 · последний записанный шаг — октябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

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

Хозяйство: ресурсы машины и сохранность данных

Началась: март 2026 · последний записанный шаг — сентябрь 2026

С чего началось

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

К чему пришли

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

Что нашли

• Привычный счётчик может обманывать в сотни раз: в одной задаче он показывал около 7 МБ там, где процесс держал около 1,8 ГБ.
• Мы измерили, где на самом деле лежат копии баз, а не положились на память, нашли пробелы в резервном копировании и закрыли их в тот же день.
• Важное решение может исчезнуть, если не записать его как открытый пункт: так однажды случилось с решением перенести хранилище баз.

Что система делает сегодня

Рабочие функции системы, по одной строке, с месяцем первой записи.

• Охрана данных (начало 2026) — Данные берегут по правилу: перед перезаписью сохраняется прежняя версия, удалённое уходит в корзину, а перед опасным изменением базы данных снимается её копия.
• Резервные копии (начало 2026) — Переписка сессий, память и базы данных регулярно копируются — с сентября 2026 года на отдельный диск, — и каждая копия сверяется с оригиналом.
• Память о сессиях (начало 2026) — Прошлые сессии очищаются от служебного шума и становятся доступны для поиска по словам и по смыслу, а то, что относится к делу, подаётся агенту вместе с запросом.
• Наследование между сессиями (начало 2026) — Каждая сессия оставляет следующей записку о передаче и свои размышления; новая начинается с их чтения, а прерванная сессия распознаётся и восстанавливается.
• Охрана выхода наружу (начало 2026) — Всё, что уходит за пределы машины, — публикация кода, сообщения, платежи — проходит проверки и требует явного согласия человека.
• Контроль действий агента (начало 2026) — Прежде чем действие выполнится, его проверяют: не уйдут ли с ним секреты и не тронет ли оно данные, не оставив копии.
• Проверка перед приёмкой работы (начало 2026) — Когда агент считает работу законченной, система напоминает, какие проверки ей ещё предстоят, прежде чем её примут.
• Здоровье системы (начало 2026) — Сессия начинается со сводки о состоянии системы, а за самими приборами следит отдельный слой — чтобы замолчавшая проверка не осталась незамеченной.
• Инструменты качества мышления (начало 2026) — Идеи и работа проходят проверку до и после действия: разбор на атомы, спецификация словами, целостность данных, соразмерность утверждений основаниям, проверка устройства.
• Проекты и планы (начало 2026) — Работа разбита на проекты со своим планом и порядком, и система следит, жив ли проект и не устарели ли его записи.
• База документации (начало 2026) — Документация, от которой мы зависим, и описания самой системы хранятся у нас и доступны для поиска по словам и по смыслу.
• Внешние модели и рабочие (начало 2026) — Рутинный труд уходит более дешёвым моделям, локальным или удалённым, — по классу задачи и классу данных; суждение и приёмка остаются за главной моделью.
• Сигналы для следующих сессий (начало 2026) — Решения и ошибки записываются так, чтобы следующие сессии знали, что уже случалось.
• Доступ к базам данных (начало 2026) — Ко всем базам данных ведёт один путь — через их реестр и живое описание их устройства, а не по памяти.
• Ограничение нагрузки от скриптов (начало 2026) — Скрипты, которые запускает агент, получают предел памяти и пониженный приоритет, чтобы тяжёлая работа реже мешала остальному на том же компьютере.
• Память агента (с марта 2026) — Агент ведёт между сессиями собственные заметки, а каждое правило своего поведения хранит вместе с дословными словами человека, из которых оно выведено.
• Правила и ядро (с марта 2026) — Короткое ядро принципов задаёт поведение агента с начала сессии, а частные правила приходят тогда, когда наступает их момент.
• Публикации (с апреля 2026) — Тексты пишутся как независимые оригиналы на двух языках, проверяются на утечки и на неподтверждённые утверждения и выходят только по слову человека.
• Замеры и испытания (с апреля 2026) — Небольшой набор отдельных проб измеряет, как работают память и вспомогательные приборы.
• Объектная память (с мая 2026) — Назови программу, проект или понятие — и система выдаст, что о нём записано и какой опыт работы с ним накоплен.
• Браузер агента (с мая 2026) — Свой браузер — рабочий орган агента: в нём агент работает на настоящих сайтах, понимает страницу прежде всего по её устройству, а не по картинке, и считает действие сделанным, лишь увидев его последствие. Платёж и отправка сообщения из него возможны только с согласия человека.
• Справочники по платформам (с мая 2026) — Рабочие руководства по двум внешним платформам: Golem — для запуска агентов и ботов, Cloudflare — для размещения сайта.
• Мессенджер (с мая 2026) — Агент читает каналы и чаты мессенджера, открытые нашей учётной записи, и проверяет, как работают боты.
• Страницы событий (с июля 2026) — Ранний прототип собирает из подготовленных материалов страницу события: расшифровка видео, временная шкала, переключение языков.

Публикации по пути

Формальные результаты этого пути опубликованы с DOI на странице Публикации.