Как топологията променя работата с няколко AI асистента

Ако си пробвал да използваш няколко AI модела едновременно за код, сигурно си се сблъсквал с един и същ проблем. Всеки път, когато рестартираш сесията, агентите започват от нулата. Трябва да им обясняваш отново контекста, да повтаряш решенията и да възстановяваш логиката, която сте изградили преди дни. Звучи като да наемаш нови хора всеки ден.

OpenRig решава този въпрос, като третира агентите като инфраструктура.

Защо изолираните сесии не стигат

Повечето разработчици стартират AI агентите си поотделно. Claude свършва задачата си и спира. GPT-4 идва след това без никаква представа какво е станало. Няма споделена памет, няма обща история, няма истински екип.

Това работи при прости задачи. Но при сериозна разработка бързо се появяват проблеми:

• Агентите губят идентичността си след всяко рестартиране
• Знанието не се предава между различните модели
• Архитектурните решения не оцеляват при следващото стартиране
• Координацията между десет агента става хаотична

Без слой за оркестрация дори най-добрите агенти не могат да работят като екип.

Rig като YAML дефиниция

OpenRig въвежда понятието rig — YAML файл, който описва цялата структура от агенти. Подобно е на Terraform, но вместо сървъри управлява AI модели.

Rig не е просто списък. Той представлява граф, в който агентите са организирани в pods. Всеки pod споделя контекст, а pods се свързват чрез дефинирани връзки. Цялата топология може да се запазва и възстановява като едно цяло.

Ето как изглежда примерна дефиниция:

pods:
  orchestration:
    agents:
      - lead (Claude Opus)
      - coordinator (Claude Sonnet)
  
  development:
    agents:
      - implementation (Claude Code)
      - review (Codex)
  
  research:
    agents:
      - explorer-1, explorer-2, explorer-3

Какво дава тази структура

Постоянна идентичност

Агентът запазва ролята и знанието си през седмици. Когато контекстният прозорец се запълни, състоянието се прехвърля в нова сесия. Не започва отначало — продължава оттам, където е спрял.

Споделена памет

Агентите в един pod могат да записват и четат общо състояние. Когато един агент компактира контекста си, останалите могат да възстановят наученото. Архитектурните решения и шаблоните се натрупват, вместо да изчезват при рестартиране.

Единна точка на управление

Цялата топология се управлява през един интерфейс. Можеш да проверяваш състоянието на всички агенти от телефона си чрез Claude Remote Control. Няма нужда от различни табла за всеки модел.

Реални примери за използване

Документацията показва няколко модела, които вече се прилагат:

• Adversarial Review — два агента преглеждат всеки pull request от различни ъгли и хващат различни грешки
• Research Cluster — четири агента изследват проблем паралелно без йерархия
• Security Hardening — едни агенти атакуват, други защитават, трети документират
• Continuous Refactor — рефакторингът върви нощем, докато екипът спи
• Agent-Managed Software — агент управлява HashiCorp Vault вместо човек

Защо това има значение

Когато агентите са еднократни инструменти, знанието не се трупа. Когато имат постоянна идентичност и споделена памет, те започват да работят като истински екип.

• Решенията стават по-добри с времето
• Не се налага да повтаряш едни и същи изисквания
• Всеки агент може да се специализира в конкретна област
• Работата продължава асинхронно, без да се губи контекст

Как да започнеш

OpenRig предлага режим на откриване. Ако вече имаш агенти в tmux или друга среда, командата rig discover анализира съществуващите сесии и предлага готова RigSpec. Не започваш от празно — формализираш това, което вече работи.

CLI инструментът позволява boot, snapshot, restore и visualize. Един файл и няколко команди управляват цялата инфраструктура от агенти.

Заключение

OpenRig е open source проект, който не изисква допълнителни API ключове. Той дава контрол върху топологията на агентите, вместо да разчиташ на затворени решения.

Когато агентите могат да помнят, да споделят знание и да работят координирано, разликата е между играчка и инструмент, който реално доставя резултати.

Твоята агентна топология е инфраструктура. Третирай я като такава.