Pull to refresh

Comments 6

Спасибо интересно

Звучит немного дико, но жутко интересно

Сходный паттерн на разработке компилятора — гоняю агентов автономно часами через тот же подход: план как контракт, нулевая регрессия тестов как жёсткий барьер. Без email/systemd, но идея та же — несколько часов работы без присмотра.

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

Как у тебя с самомодификацией — есть какой-то антифриз чтобы не самостирался?

Так как это просто набор скриптов и конфигов, то их можно просто хранить в git. Ничего особенного придумывать там не нужно. Если я верно понял, то что ты написал...я пытался.

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

Интересно «я пытался» — пытался конкретно с email-циклом или с подходом «план как контракт» в принципе? У меня работает когда задача разбита на 5-15 минут исполнения с явными критериями приёмки. На задачах с непредсказуемым исполнением — ломается так же.

Мне кажется мы говорим о разных вещах. Описанный в статье подход это заготовка для построения агента с любой логикой какая тебе нужна. Все, что придумаешь можно на этом подходе реализовать, причем с минимальным кодом. Я не пытался описать какого то конкретного агента, его логику, я описал подход для построения любого агента из пары утилит и почти без кода. Хочешь выдумать что то, вперед, подход покроет что угодно. Напирмер в нем легко сделать
1. Бридж из обсидиан в FSM описанный или откуда угодно.
2. Любые рассуждения или формирования длинных ответов.
3. Даже обработку звука на вход в виде бриджа можно сделать, я может позже накатаю статью как, но пока мне просто не нужно.

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

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

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

Спасибо за статью, идея «email как универсальный протокол» интересная.

Sign up to leave a comment.

Articles