Статья

SYNAPSE: прототип software engineering с adaptive control

SYNAPSE — framework 2025 года для AI-агентов, которые ведут software lifecycle и адаптируют свои критерии успеха через MCDM. Идея детерминированного control plane позже вышла как Bernstein.

15 июля 2025 г.7 мин чтения

Delivery Research

На странице(8)

Большинство agent loop в 2025 выбирали fitness function один раз и держали её константной. SYNAPSE — попытка положить решение «что в этом запуске значит хорошо» внутрь самого loop.

TL;DR

SYNAPSE предлагает автономный control loop, который сам адаптирует свои критерии успеха через multi-criteria decision-making (MCDM). Adaptive слой я проверил на синтетическом 2D pathfinding-сценарии. Small, single seed, направление, а не статистика. Концептуальный выигрыш в разделении: ЧТО агент оптимизирует (metric profile) и КАК он исполняет (внутренний loop). Control plane — обычный Python. LLM трогает только генерацию кандидатов. Framework — эскиз. Эксперимент — sanity check. Вместе их хватает, чтобы аргументировать форму.

Форма loop

Большинство agent framework середины 2025 года читались одинаково. Planner выдаёт шаг. Executor его выполняет. Scorer возвращает число. Loop замыкается. Fitness function (то, что решает, идёт ли запуск хорошо) — константа. Её задают на старте и с ней живут.

SYNAPSE пытается сломать это допущение. В реальной инженерной работе правильный trade-off нестабилен. Первый проход заботится о корректности. Hardening pass — о safety и risk. Spike перед дедлайном — о wall-clock time за счёт maintainability. Если агент работает на всех этих фазах, ему нужно разрешить пересматривать критерии. Явно, легитимно, с записью в лог.

Loop состоит из пяти шагов. Сгенерировать кандидата. Провалидировать его на quality gates. Оценить результат против текущего metric profile. Скорректировать profile если сценарий требует. Выбрать следующий ход. Первый и последний трогают LLM. Три средних — детерминированный Python.

SYNAPSE control loop

Generation, validation, scoring, metric adjustment, next-move selection. LLM трогает только генерацию; всё остальное — код.

Новизна в шаге четыре. Агент читает сценарий, выбирает metric profile (наклониться в safety, потому что коридор шумный; наклониться во время, потому что дедлайн жёсткий) и пересчитывает следующего кандидата под новые веса. Vocabulary MCDM7 (PerfGain, SecRisk, DevTime, Maintainability, Cost, Scalability, DX) даёт profile форму, с которой можно спорить. Weight-векторы лежат в config. Decision logs — в файле. Ничего не прячется в чате.

Синтетический эксперимент

Концептуальный loop выше требует evaluation harness гораздо большего, чем я собрал. Что реально шипанулось — один proof-of-concept run: continuous 2D pathfinding под dynamic wind. Два агента двигают симулированный дрон из старта в цель под конфликтующим давлением — time, energy, safety margin, payload integrity.

StaticAgent использует фиксированный weight vector на весь запуск.
SYNAPSEAgent читает сценарий, выбирает metric profile (здесь: наклон в safety, потому что ветер делает коридор шумным) и пересчитывает на каждом шаге.

Вопрос был узкий: меняет ли адаптация критериев выбранный путь измеримо, под одним adversarial-сценарием?

Agent	Energy	Safety (меньше = безопаснее)	Time	Path found
StaticAgent	170.28	3.97	59.71 с	yes
SYNAPSEAgent	122.32	1.24	61.50 с	yes

SYNAPSEAgent потратил ~28% меньше энергии и получил ~3.2× лучший safety-метрик (1.24 против 3.97), при ~3% штрафе по времени. CSV закоммичен дословно в results/experiment_results_20250708_225100.csv. Ничего не сглажено.

Что сработало

Несколько вещей выдержали лучше, чем я ожидал.

Архитектурный паттерн. Разделение ЧТО агент оптимизирует и КАК исполняет — чистый разрез. Когда metric profile становится first-class объектом (dict в YAML-файле, а не предложение в промпте), агент перестаёт спорить сам с собой что важнее: скорость или safety. Берёт profile, исполняет под него, следующая корректировка видна в diff.

Vocabulary. MCDM7 достаточно opinionated, чтобы быть полезным, и достаточно small, чтобы держаться в голове. Ложится на trade-off-ы, которые senior engineers и так обсуждают вслух. Сделать их явными.

Детерминированно, где можно. Оркестратор не тратит ни одного LLM-токена на собственный scheduling. Каждое решение control plane воспроизводимо из config и seed. Это аргумент про debuggability. Когда что-то ведёт себя криво, ты читаешь decision log, а не гадаешь, что подумала модель.

Что не сработало

Часть вещей оказалась преждевременной.

Нет реальных CLI-агентов, которыми можно оркестрировать. До-Claude-Code эпоха. Нет зрелого agentic CLI, который берёт бриф, редактирует файлы, запускает тесты и возвращается. SYNAPSE описывает control plane для инструментов, которых ещё нет. LlamaAdapter в прототипе — тонкая обёртка над Ollama. Умеет сгенерировать кандидата. Не умеет работать с репозиторием.

Нет grounding-слоя. До-MCP. У агента нет стандартизованного способа дёрнуть filesystem, build-тул, linter или базу. Каждый адаптер пишется руками. Цена «дать агенту настоящий инструмент» достаточно высока, чтобы прототип валидировал loop только на закрытой симуляции.

Эксперимент слишком маленький. Один сценарий, один seed, нет факториального дизайна, нет теста значимости. Числа реальные. История маленькая. В roadmap-файле репо этот gap зафиксирован явно. Это тот пробел, который превращает «research preview» во что-то публикуемое.

Во что это выросло

SYNAPSE был эскизом. Форма, которую он отстаивал, дозрела через два следующих проекта.

Kotef — durable single-agent runner

Kotef взял SYNAPSE-loop и поставил его на реальные репозитории. Supervisor-flow planner → researcher → coder → verifier → janitor гоняет цикл по живому коду, с durable state в .sdd/runtime/, MCP-grounded инструментами и resume по thread ID. Это single-agent. Metric profile стал quality-gate конфигом; адаптивный слой стал backlog-driven планнером, который перепересчитывает приоритеты на каждом тике. Kotef — причина, почему я поверил, что loop переживает контакт с файловой системой.

Bernstein — детерминированный control plane на масштабе

Что Kotef сделал для одного агента, Bernstein делает для многих. Детерминированный Python scheduler декомпозирует цель, диспатчит короткоживущих агентов в изолированные git worktrees, верифицирует выход через janitor и коммитит то, что выжило. LLM пишет код; оркестратор решает, что запускается и что мёржится. Decision log — каталог с обычными файлами. Vocabulary поменялся (tasks, adapters, budget caps, MCP integration); форма — та же пятиступенчатая SYNAPSE-петля (generate, validate, score, adjust criteria, choose next move) с whiteboard. Уроки Kotef про durable state и backlog-driven планирование переехали туда же.

Репо остаётся публичным, потому что lineage честнее, чем polish. SYNAPSE — это маленький кусок evidence, что loop работает на лёгком кейсе. Production-системы, которые пришли позже, — это настоящий аргумент. Этот — карточка над столом.

Оркестратор и есть продукт. Ему разрешено менять мнение о том, что такое «успех». Условие одно: каждое такое изменение остаётся читаемым и воспроизводимым, а человек может его перебить.

Репозитории

SYNAPSE на GitHub — прототип 2025 года
Kotef на GitHub — durable single-agent runner, который пришёл следом
Bernstein на GitHub — multi-agent control plane, выросший из той же ДНК

По теме

Дальнейшее чтение

Hwang & Yoon, Multiple Attribute Decision Making (1981) — линия TOPSIS, через которую проходит каждая adaptive-metric routine здесь.
Sutton & Barto, Reinforcement Learning: An Introduction (2nd ed., 2018) — policy-iteration framing для внешнего loop.
Brooks, The Mythical Man-Month (1975) — conceptual integrity как первая обязанность инженера.

— Alex Chernysh, alexchernysh.com