My Architect, частка 1: памяць і план для AI-агента

Гэта першы артыкул серыі пра My Architect — сістэму, у якой праект жыве паміж сесіямі AI-агента. Чалавек бачыць і правіць карціну праз візуальны інтэрфейс, агент кіруе тым жа праектам праз MCP. У серыі сем частак, план — у канцы артыкула.

Праблема: агент геніяльны і беспамятны

Claude Code за паўгадзіны вырашае задачу, на якую сеньёр патраціў бы дзень. Потым сесія заканчваецца. Наступнай раніцай агент не памятае, чаму вы выбралі Postgres, якія фічы адклалі да другога рэлізу і на чым спыніліся ўчора а восьмай вечара.

Кантэкстнае акно канечнае. Доўгі дыялог сціскаецца, і першымі выпадаюць якраз рашэнні двухтыднёвай даўніны, на якіх усё трымаецца. Вы тлумачыце нанова, агент «перадумвае» ўжо вырашанае, часам перарабляе тое, што працавала.

Чым гэта звычайна лечаць:

CLAUDE.md і нататкі ў рэпазіторыі. Працуе, пакуль файл кароткі. Да сотага радка ён ператвараецца ў звалку, дзе побач ляжаць правілы лінтэра і лёсавызначальныя архітэктурныя рашэнні.
Планы ў markdown-файлах. PLAN.md, ROADMAP.md, TODO.md — кожны жыве сваім жыццём, супярэчыць суседзям, і агент сам вырашае, які з іх лічыць праўдай.
Jira ці Linear. Зроблены для людзей і працэсаў. У агента туды ў лепшым выпадку API-доступ без структуры, якую яму зручна чытаць: ні спадкавання патрабаванняў, ні паняцця «вазьмі наступную задачу з улікам рэлізу і глыбіні дрэва».

Агульная бяда ва ўсіх трох: няма аднаго месца, якое аднолькава зручнае і чалавеку, і агенту.

Ідэя: адна крыніца праўды, два інтэрфейсы

My Architect захоўвае праект як іерархію вузлоў: Epic → Feature → Story → Task (ёсць схемы SAFe і спрошчаная). На вузлы вешаюцца патрабаванні, дакументы і дыяграмы. Пад капотам гэта звычайныя YAML- і Markdown-файлы — ніякай закрытай базы, даныя перажывуць любы інструмент.

Паверх аднаго сховішча — два раўнапраўныя ўваходы.

Чалавеку — canvas: дрэва WBS з аўтаматычнай раскладкай, User Story Map з рэлізамі па гарызанталі, drag-n-drop для перападпарадкавання вузлоў, статусы колерам. Перацягнулі story ў іншы рэліз — файл змяніўся.

Агенту — больш за 30 MCP-інструментаў. Тыповая сесія выглядае так:

get_project_context(pid)   → іерархія, бэклог, рэлізы — адным выклікам
get_next_task(pid)         → задача з улікам рэлізу і глыбіні дрэва
start_task(pid, node-42)   → статус in-progress, агент прызначаны
create_doc(...)            → спека прымацаваная проста да вузла
complete_task(pid, node-42, summary)
                           → done, статусы бацькоў пералічаныя,
                             у адказе адразу наступная задача

Сінхранізацыя жывая: агент закрыў задачу — вузел на канве стаў шэрым проста падчас сесіі, без перазагрузкі. Спрацаваў file watcher: бэкенд заўважыў змену YAML на дыску і разаслаў падзею ў браўзер па WebSocket.

Што агент памятае паміж сесіямі

Новая сесія пачынаецца не з чыстага аркуша, а з аднаго выкліку get_project_context: уся іерархія, бэклог, рэлізы, статыстыка. Далей агент дакладна ведае, што зроблена, што заблакавана і чаму, што браць наступным.

Рашэнні захоўваюцца не ў тэксце дыялогу, а як патрабаванні чатырох тыпаў: функцыянальныя (FR), нефункцыянальныя (NFR), архітэктурныя (SAR) і абмежаванні (CON). Патрабаванні спадкуюцца ўніз па дрэве: NFR «адказ да 200 мс», павешаны на эпік, бачны з кожнай укладзенай задачы. Агент, узяўшы задачу трэцяга ўзроўню, атрымлівае і яе ўласныя патрабаванні, і ўсё, што назапасілася ў продкаў.

Памяць агента — гэта не кантэкстнае акно. Гэта структура праекта, якую ён чытае за адзін выклік у пачатку кожнай сесіі.

Чаму MCP, а не чарговая інтэграцыя

MCP — адкрыты пратакол, і My Architect будаваўся вакол яго з першага дня, а не як надбудова. Падключаецца любы сумяшчальны агент: Claude Code, агенты на Anthropic SDK, што заўгодна заўтрашняе. Канфігурацыя — пяць радкоў у .mcp.json.

Адваротны бок таго ж медаля: і UI, і MCP-інструменты ходзяць праз адзін бэкенд і адну даменную логіку. Агент не можа зламаць тое, што бачыць чалавек — у іх фізічна адны і тыя ж файлы і адны і тыя ж правілы змен.

Дробязь, якая шмат каштуе

Сістэма не дасць агенту назваць вузел «Implement login» або «Fix bug in auth». Вузлы называюцца сутнасцямі: «Login system», «Auth flow». Убудаваны лінтэр заварочвае дзеясловы, імператывы і фармулёўкі-прыёмкі яшчэ на этапе build_hierarchy.

Выглядае прыдзіркай. Але праз месяц працы бэклог з дзвюх сотняў вузлоў чытаецца як карта прадукту, а не як пратакол даручэнняў — і чалавекам, і агентам.

Усе часткі серыі

Памяць і план для AI-агента — гэты артыкул.
Архітэктура без базы даных — YAML-файлы як крыніца праўды, атамарны запіс, м'ютэкс праекта і жывая сінхранізацыя праз WebSocket. І гісторыя пра тое, як паралельныя запісы гублялі 85% змен.
Мадэль планавання — іерархія, патрабаванні са спадкаваннем, User Story Map і рэлізы: як прымусіць агента планаваць як архітэктар, а не як генератар тудушак.
Рабочы цыкл агента — ад get_next_task да complete_task: дакументацыя як частка задачы, living source of truth і зверка плана з рэальным кодам.
Дыстрыбуцыя праз Claude Code marketplace — плагін, які адной камандай ставіць і skill, і MCP-сервер: як зладжаны маркетплейс, версіянаванне і чаму skill жыве ў публічным рэпазіторыі.
Бок чалавека — WBS, Building Blocks і User Story Map — як інструментам карыстаецца архітэктар рукамі: WBS паверх building blocks, User Story Map для прыярытызацыі і дыяграма, якую выконвае агент.
Obsidian, Claude Code docs і OpenClaw — палявыя нататкі — якую працу робяць чужыя інструменты захоўвання ведаў, дзе ў кожнага столь і чаму «весці праект з агентам» — асобная праца.

Паспрабаваць My Architect можна на my-architect.app. Пытанні і пярэчанні — пішыце, самыя цікавыя разбяру асобна.