Когда мы работаем в паре с LLM-агентом, нужно принимать во внимание природу нашего "партнёра". Агент опирается только на тексты, действует в пределах ограниченного контекста и не удерживает долгосрочную историю. Поэтому особенно важным становится то, какие тексты мы ему предоставляем и как они структурированы.
Ниже - компактная, прикладная схема верхнего уровня, которую можно использовать в собственных проектах. Она помогает держать порядок, снижает шум для модели и делает работу агента более предсказуемой.
Общий принцип
Проект лучше разделять на три смысловых слоя:
./ctx/
product/
rules/
agent/
Это мой рабочий подход, сформировавшийся из личного опыта взаимодействия с LLM-агентами.
Каждый слой отвечает за свою часть когнитивной нагрузки и используется агентом по-разному.
./product/ - смысловой каркас продукта
В этом каталоге находятся документы, которые описывают продукт как идею:
назначение продукта;
ключевые сценарии;
цели и ограничения;
особенности, которые определяют направление разработки.
Это "скелет" приложения. Здесь нет технических деталей. Этот слой задаёт вектор: зачем существует продукт и что именно должно быть реализовано.
Документы в ./product/ небольшие по объёму, но определяют весь остальной проект.
./rules/ - нормативы разработки
Этот каталог служит опорной точкой для любой генерации кода. Здесь собираются технические правила:
соглашения по организации модулей;
архитектурные решения;
структура слоёв приложения;
особенности платформы (например, DI, файловая организация, правила взаимодействия между зонами);
требования к стилю и оформлению кода.
./rules/ - это набор норм, которые направляют агента. Если они сформулированы ясно, модель работает стабильнее, предсказуемее и реже ошибается.
Этот каталог - основной инструмент для управления качеством генерации.
./agent/ - фиксация хода работы
Этот каталог предназначен для фиксации итераций:
отчёты агента по выполненным задачам;
(опционально) журнал поставленных задач.
Эти материалы помогают восстановить контекст спустя время или при подключении новых людей.
Каталог ./agent/ делает процесс разработки наблюдаемым и прозрачным.
Итоговая схема
Структура верхнего уровня каталогов в ADSM:
./ctx/
product/ - что мы делаем
rules/ - как мы это делаем
agent/ - что было сделано
Такой подход помогает упорядочить работу с LLM-агентами и уменьшить вероятность ошибок, связанных с перегрузкой контекста и смешением смыслов.
Полное изложение и обоснование
Более подробное обоснование почему у меня сложилась именно такая структура и как я к ней пришёл — здесь. Для этой публикации на Хабре я специально представил только самую суть.
Внимание - это ресурс, который быстро заканчивается.
Благодарю за внимание!
Посмотреть результат применения излагаемого подхода можно в проекте "flancer64/pwa-home-call".
Комментарии (6)

funca
22.11.2025 09:59Как расшифровывается ADSM? У меня только одна ассоциация: сказал A, говори и B.

flancer Автор
22.11.2025 09:59Я рассматривал оба варианта. Но народу зашло с "А".

funca
22.11.2025 09:59Шедевриально.
BDSM — Business Driven Software Management
ADSM — Agent Driven Software Management
Вы думаете, что смена инструмента как-то влияет на суть?

flancer Автор
22.11.2025 09:59BDSM — Bot Driven Software Management
ADSM — Agent Driven Software Management
Если в основе бота/агента лежит LLM, то суть не изменяется. Но название - да. Название меняется. Как и отношение людей к тому, что стоит за тем или иным названием.
Но до сути надо ещё докопаться, а название - оно вот, перед глазами.
Kamil_GR
Выглядит логично. Ещё бы промпт связки посмотреть.
flancer Автор
У меня только отчёты агентов по работам фиксируются. Сами запросы есть в логах моей учётки (облачная версия) или в IDE (консольная версия). Могу выложить, если интересно. Но я стараюсь задавать рамки агенту скорее через контекст, чем через запрос.
Хотя некоторые запросы довольно развесистые получались - я их делал через GPT. Анализировал через него кодовую базу, корпус документов, обговаривал детали итерации и просил поставить задачу для агента. Но в некоторых случаях я просто правил документы контекста и просил агента привести код к новой версии документов.
Да, у меня довольно плотное общение идёт с чатиком перед постановкой задачи - в целях экономии токенов Codex-агента.