Да, согласен. Access с VBA это хорошая архитектура. У меня в основе, по сути, та же идея, только SQLite вместо Access: база лежит файлом на диске
По напоминалкам - я разные варианты думал. Но сейчас у меня в целом напоминания из crm приходят мне от агентов в чат, который я каждое утро просматриваю - там собрано все важное для меня из всех сегментов моих работ. Я с этого чата начинаю свое личное планирование дня
Git у меня тоже есть, просто на другом слое: код, скрипты и правила лежат в git и коммитятся, а Syncthing возит волт с заметками.
Git требует ручного шага: закоммитить, запушить, подтянуть. А Syncthing все делает сам и молча.
Но насчёт истории вы правы… У меня с диска пропала пара скриптов, а версий Syncthing на том узле включено не было, и восстанавливать оказалось нечем. Так что польза в истории точно есть, особенно понимаешь это когда что-то потерялось
Про несколько тематических агентов в одном волте: у меня также, да, у каждого свой домен и свои правила. Работает. Только когда идут одномоментные правки документа разными агентами - это было сложно, но я сделал замок: агент берёт файл на 15 минут, второй в это время туда не лезет.
Спасибо, по всем трём пунктам вы правы, и по последнему особенно!
Про 4 мегабайта для CLAUDE.md не знал, я останавливался на 400 килобайтах и дальше не проверял...
Rules и skills у меня как раз используются. Но верхний файл всё равно разросся: каждое новое правило туда дописываю но старые-то не удаляю... ревизия точно назрела. Ваш комментарий её ускорит.
За beads и AgentMail особое спасибо, оба видел впервые. Beads прям ответ на мою боль - у меня задачи и договорённости - в markdown и в самодельных журналах, а граф зависимостей приходится держать в голове. Пойду поизучаю внимательнее
Понял, принял Я думал, у вас мерж вместо конфликтов, а на деле и то и другое
Дифф между публикацией и черновиком звучит хорошо, у меня такого нет: отличие черновика от опубликованного у меня в папке и поле в заголовке файла, а что именно поменялось между ними, я сам глазами смотрю через git . Для текста правила, по которому потом работает агент, отдельный дифф был бы кстати
Идея рабочая. У меня стартовый контекст сессии вышел около 90K токенов по медиане, и заметная часть там как раз описания команд MCP, которые читаются при каждом старте, даже если к ним не обращались.
С CLI этой постоянной платы нет как я понимаю, агент зовёт утилиту в тот момент, когда она ему понадобилась.
Про мерж понял, спасибо! У меня ограничение на изменение файла сделано простым: общий слой это обычные файлы, и мне спокойнее, когда при одновременной правке рядом просто появляются две версии и выбираю я, иначе объединённый текст правила может получиться таким, какого никто не писал, а агент же по нему действует
Лимит токенов прямо в запросе это очень хорошая идея, я до такого не додумался У меня та же задача решена со стороны хранения: файл, который агент читает при каждом старте, содержит только строку «когда это правило срабатывает и где лежит подробное описание», а сам текст правила -отдельной заметкой и он читается, только когда понадобился.
Спасибо, уже смотрю MCP с oAuth к воркспейсу - этого у меня как раз нет: у меня общий слой -это просто файлы на дисках, и агент читает их локально
Два вопроса, если не сложно. Первый: что происходит, когда двое правят один документ одновременно? У меня для этого замок на файл минут на пятнадцать, но я еще думаю, как по-другому сделать Второй: MCP отдаёт агенту весь воркспейс или ходит по нему выборочно? У меня стартовый контекст сессии вышел под 91 тысячу токенов, поэтому правила и пришлось резать на слои.
Спасибо за комментарии! Наработок у меня много но вот писать о них понятнее я еще учусь - прошу понять и простить
по статье - про заголовок согласен бенчмарк меряет соблюдение объявленных процессов, а не автономность вообще. Формулировку поправлю
И аналогия с холодильником точная:) я оценил INV-2 на 7.7% это про «морозилка не морозит» VERIFY в протоколе это advisory-флаг, а не прекондишн коммита, и измеряется именно этот разрыв. В v1 он становится жёстким прекондишном для Tier-2, вот тогда это уже имеет значение
Invariant Guardrails и AgentEvals не смотрел - тут посмотрю - спасибо!
И перепишу вступление чтобы было понятно с первых строк что я тут хочу описать
Да, согласен. Access с VBA это хорошая архитектура. У меня в основе, по сути, та же идея, только SQLite вместо Access: база лежит файлом на диске
По напоминалкам - я разные варианты думал. Но сейчас у меня в целом напоминания из crm приходят мне от агентов в чат, который я каждое утро просматриваю - там собрано все важное для меня из всех сегментов моих работ. Я с этого чата начинаю свое личное планирование дня
Git у меня тоже есть, просто на другом слое: код, скрипты и правила лежат в git и коммитятся, а Syncthing возит волт с заметками.
Git требует ручного шага: закоммитить, запушить, подтянуть. А Syncthing все делает сам и молча.
Но насчёт истории вы правы… У меня с диска пропала пара скриптов, а версий Syncthing на том узле включено не было, и восстанавливать оказалось нечем. Так что польза в истории точно есть, особенно понимаешь это когда что-то потерялось
Про несколько тематических агентов в одном волте: у меня также, да, у каждого свой домен и свои правила. Работает. Только когда идут одномоментные правки документа разными агентами - это было сложно, но я сделал замок: агент берёт файл на 15 минут, второй в это время туда не лезет.
Спасибо, по всем трём пунктам вы правы, и по последнему особенно!
Про 4 мегабайта для CLAUDE.md не знал, я останавливался на 400 килобайтах и дальше не проверял...
Rules и skills у меня как раз используются. Но верхний файл всё равно разросся: каждое новое правило туда дописываю но старые-то не удаляю... ревизия точно назрела. Ваш комментарий её ускорит.
За beads и AgentMail особое спасибо, оба видел впервые. Beads прям ответ на мою боль - у меня задачи и договорённости - в markdown и в самодельных журналах, а граф зависимостей приходится держать в голове. Пойду поизучаю внимательнее
Понял, принял Я думал, у вас мерж вместо конфликтов, а на деле и то и другое
Дифф между публикацией и черновиком звучит хорошо, у меня такого нет: отличие черновика от опубликованного у меня в папке и поле в заголовке файла, а что именно поменялось между ними, я сам глазами смотрю через git . Для текста правила, по которому потом работает агент, отдельный дифф был бы кстати
Идея рабочая. У меня стартовый контекст сессии вышел около 90K токенов по медиане, и заметная часть там как раз описания команд MCP, которые читаются при каждом старте, даже если к ним не обращались.
С CLI этой постоянной платы нет как я понимаю, агент зовёт утилиту в тот момент, когда она ему понадобилась.
Про мерж понял, спасибо!
У меня ограничение на изменение файла сделано простым: общий слой это обычные файлы, и мне спокойнее, когда при одновременной правке рядом просто появляются две версии и выбираю я, иначе объединённый текст правила может получиться таким, какого никто не писал, а агент же по нему действует
Лимит токенов прямо в запросе это очень хорошая идея, я до такого не додумался
У меня та же задача решена со стороны хранения: файл, который агент читает при каждом старте, содержит только строку «когда это правило срабатывает и где лежит подробное описание», а сам текст правила -отдельной заметкой и он читается, только когда понадобился.
Спасибо, уже смотрю
MCP с oAuth к воркспейсу - этого у меня как раз нет: у меня общий слой -это просто файлы на дисках, и агент читает их локально
Два вопроса, если не сложно. Первый: что происходит, когда двое правят один документ одновременно? У меня для этого замок на файл минут на пятнадцать, но я еще думаю, как по-другому сделать
Второй: MCP отдаёт агенту весь воркспейс или ходит по нему выборочно? У меня стартовый контекст сессии вышел под 91 тысячу токенов, поэтому правила и пришлось резать на слои.
И заодно: self-host возможен?
Человек не сможет, это ж человек
А про 192 килобайта вы правы, и у меня уже зреет необходимость ревизии, и немного страшно браться за эту задачу ))
Благодарю
И за фидбек благодарю
есть над чем работать
Спасибо за комментарии! Наработок у меня много но вот писать о них понятнее я еще учусь - прошу понять и простить
по статье - про заголовок согласен бенчмарк меряет соблюдение объявленных процессов, а не автономность вообще. Формулировку поправлю
И аналогия с холодильником точная:) я оценил INV-2 на 7.7% это про «морозилка не морозит» VERIFY в протоколе это advisory-флаг, а не прекондишн коммита, и измеряется именно этот разрыв. В v1 он становится жёстким прекондишном для Tier-2, вот тогда это уже имеет значение
Invariant Guardrails и AgentEvals не смотрел - тут посмотрю - спасибо!
И перепишу вступление чтобы было понятно с первых строк что я тут хочу описать