Агентная система может жить в графе

Агенту не обязательно существовать как постоянной персоне с должностью и закрепленным местом в процессе. Он может собираться во время выполнения из контекста, возможностей, правил, разрешений и связей, хранящихся в графе.

Это превращает оркестрацию из цепочки имитируемых человеческих ролей в систему, построенную вокруг долговечного состояния. Граф хранит знания системы и связи между ними; модель выполняет работу; человек сохраняет намерение, суждение и ответственность.

Многие мультиагентные системы начинают с воссоздания организации внутри промпта. Запрос проходит через интервьюера, бизнес-аналитика, архитектора решений, дизайнера, критика, судью, delivery-менеджера, планировщика, исполнителя, код-ревьюера, специалиста по безопасности, тестировщика производительности и оператора развертывания.

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

Каждая передача работы расходует контекст. Каждому агенту нужны его роль, инструкции, релевантная история, текущее состояние артефактов и пересказ решений предыдущего агента. Постепенно система тратит все больше контекстного окна на объяснение и обслуживание процесса вместо решения задачи.

При этом что-нибудь все равно проскальзывает. Правила не могут предусмотреть каждую ситуацию, границы ролей остаются открытыми для интерпретации, а пересказ одного агента становится частичной реальностью для другого. Добавление критика и судьи может выглядеть как усиление контроля, но если это экземпляры одной модели, читающие одинаково сжатые доказательства, их слепые зоны часто совпадают.

В результате получается испорченный телефон с дорогой памятью.

При создании OpCon Graph я пошел другим путем. Вместо того чтобы считать разговор местом, где система хранит память о себе, я вынес непрерывность в артефакты за пределами чата.

Контекстный граф хранит факты, события, сущности, связи, источники, открытые вопросы, решения, ограничения и доказательства. Backlog хранит работу, приоритеты, зависимости, состояние и критерии приемки. Правила проекта автоматизируют повторяемую механику: обслуживание графа, журналы разработки, проверки, коммиты, push и обновления о доставке результата.

Человеческий слой становится меньше, но остается важным. Я по-прежнему выбираю направление в неоднозначных ситуациях, решаю, чему уделить внимание, и принимаю или отклоняю результат. Система автоматизирует то, что уже достаточно стабильно для формализации; за мной остаются решения, которые зависят от суждения и ответственности.

Это уже оркестрация, но она распределена между состоянием, правилами, артефактами и человеческой границей принятия решений. Для нее не нужна отдельная персона-оркестратор, которая проговаривает каждый переход.

Полезную часть роли можно отделить от вымышленного сотрудника, которым она обернута. В операционном смысле важны контекст, необходимый роли, доступные ей возможности, разрешенные действия, обязательные доказательства и условия приемки работы.

Нода факта не является агентом, потому что у нее нет агентности. Связь не является оркестратором, потому что сама ничего не выполняет. Но нода, определяющая цель, контекст, инструменты, разрешения, правила и критерии приемки, может действовать как декларативный агент в неактивном состоянии. Связь с условием активации может действовать как правило маршрутизации.

Runtime-модель материализует нужного оператора из релевантной части графа только тогда, когда этого требует работа. Вместо поддержки пятнадцати персон в фиксированной последовательности система собирает одну ограниченную возможность из текущих доказательств.

Получается другое распределение ответственности:

Граф становится латентной агентной системой. Его операторам не нужно постоянно существовать в виде именованных персонажей. В момент выполнения они становятся активными конфигурациями контекста и возможностей.

Полная автономность не является единственной серьезной формой оркестрации. Система может автоматизировать детерминированные части работы и намеренно оставлять решения с высокой неопределенностью под контролем человека.

В моих проектах можно автоматизировать состояние приоритетов, зависимости, регулярные проверки, обновление графа, журналы, версионирование, коммиты, push и другую механику жизненного цикла. Человеку не приходится вручную переносить это операционное состояние из одного разговора в другой.

Выбор направления и приемка результата устроены иначе. Они зависят от вкуса, неполных доказательств, меняющихся целей и ответственности за последствия. Их преждевременная автоматизация часто заменяет видимое человеческое решение непрозрачной догадкой модели.

Граница должна двигаться вслед за доказательствами, а не за амбициями. Сначала нужно записать, как принимаются решения. Затем позволить системе рекомендовать маршрут. Автоматизировать маршрут стоит только после того, как он станет повторяемым, наблюдаемым и дешевым для отмены.

Поэтому ручное суждение не обязательно является техническим долгом. Иногда это правильный интерфейс управления неопределенностью.

Я рассматривал перенос OpCon Graph в SQL. Ожидаемые преимущества выглядели очевидно: более быстрый поиск, более структурированные запросы и меньший расход токенов.

На текущем масштабе тесты не подтвердили эту гипотезу. Практического преимущества не оказалось, а Markdown был немного быстрее в проверенном процессе. Что еще важнее, формат хранения не определял расход токенов. Токены тратились на контекст, выбранный и сериализованный для модели, а не на то, находился источник в Markdown или SQL.

Markdown также сохранил важные для системы свойства: стабильные пути, прямую проверяемость, читаемые diff, историю Git, простое восстановление и возможность для людей и агентов изменять одни и те же артефакты без дополнительного административного слоя.

Это не делает SQL универсально худшим решением. База данных становится ценной, когда системе нужны высокая конкурентность записи, транзакции, масштабные индексированные запросы, строгие runtime-ограничения или операционные гарантии, которые файлы не могут обеспечить эффективно. Вывод уже: инфраструктуру следует добавлять, когда ее требует наблюдаемое поведение, а не потому, что графу по умолчанию полагается графовая база данных.

На проверенном масштабе Markdown остается конкурентоспособным source of truth, а не прототипом, который только ждет замены.

Архитектура прояснилась в использовании, а не на диаграмме оркестрации. В SQVL-MESH граф и backlog поддерживают product discovery, решения по протоколу, мобильную и серверную разработку, тестирование на физических устройствах, инфраструктуру, нерешенные риски и доказательства доставки. Проект может переходить между этими областями, не восстанавливая свой операционный контекст в каждом новом чате.

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

Это показывает, что ценность OpCon Graph не привязана к личному планированию, разработке программ или одному типу артефактов. Это многоразовая операционная модель для работы, которая должна продолжаться между разговорами, инструментами, агентами и моментами времени.

Граф не устраняет суждение. Он делает доказательства вокруг суждения долговечнее, а повторяемые операции проще для автоматизации.

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

Возможно, это более полезное будущее агентных систем. Вместо имитации целой компании с надеждой, что ее искусственные отделы правильно договорятся друг с другом, можно построить общую операционную основу, которая помнит, маршрутизирует, проверяет и показывает точки, где все еще требуется настоящее решение.

Агенту не обязательно быть постоянной персоной. Он может быть возможностью, собранной из контекста, правил, разрешений и связей в момент выполнения.

И оркестрации не обязательно быть еще одним агентом. Она может жить в графе.