Graph Engineering: от loop Карпати к рою из 1000 субагентов

От одного вызова модели к общей памяти

Работа с ИИ в программировании быстро вышла за пределы схемы, где человек формулирует намерение, модель пишет код, затем человек принимает результат или просит переделать. Теперь главный инженерный вопрос звучит шире: какую систему построить вокруг модели, чтобы она могла долго работать, проверять себя, переживать сбои и сотрудничать с другими агентами?

Работы Андрея Карпати и материалы Anthropic показывают общую траекторию. autoresearch помещает агента в короткий измеримый loop: изменить программу обучения, запустить опыт, сравнить метрику, сохранить удачный шаг. AgentHub добавляет совместный поиск через граф коммитов. Dynamic Workflows расширяет параллелизм до сотен субагентов. Knowledge Graph Construction Cookbook предлагает постоянный слой сущностей, отношений, источников и выводов.

Так возникает Graph Engineering, подход с явным, типизированным и доступным для запросов состоянием. История опытов хранится в DAG коммитов, знания о предметной области живут в графе, а планы, версии, проверки и решения становятся отдельными объектами. Новый агент получает связанный фрагмент состояния и продолжает работу без восстановления всей картины по длинной переписке.

Каждая архитектура делает явным свой участок: loop фиксирует повторение, оценку и сохранение результата; цепочка задает порядок; рой дает параллельный поиск; DAG сохраняет происхождение ветвей; граф знаний хранит факты, связи и межсессионную память. Вайб-кодинг помогает выразить желание через модель. Агентная инженерия добавляет спецификацию, организацию исполнения, контроль качества и безопасность. Graph Engineering дает многим агентам долговременное общее состояние.

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

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

autoresearch: минимальная автономная исследовательская организация

В autoresearch агент работает внутри исполняемого каркаса. prepare.py готовит данные и оценку, агент его не меняет. train.py содержит модель, оптимизатор, гиперпараметры и loop обучения. program.md задает процесс, ограничения, метрику, журналирование и границы автономности.

LOOP FOREVER:
1. Прочитать train.py и недавнюю историю.
2. Предложить одно обоснованное изменение.
3. Зафиксировать кандидат в Git и запустить обучение на 5 минут.
4. Измерить val_bpb и пиковое потребление памяти.
5. Сохранить улучшение, при ухудшении или сбое выполнить откат.
6. Записать результат и продолжить самостоятельно.

По исходному документу расширенный запуск провел около 700 экспериментов за двое суток и оставил примерно 20 полезных оптимизаций. Ядро установки занимало около 630 строк и работало на одном GPU. Сохранились изменения QK normalization, value embeddings, AdamW, размера батча, глубины модели, скорости обучения embeddings, частоты RoPE, weight decay, инициализации и warmdown.

Ценность конкретных настроек зависит от модели. Переносимый результат состоит в машиночитаемой истории: каждый опыт имеет родительское состояние, diff кода, метрику и решение keep или revert. Репозиторий набрал свыше 86 тысяч звезд и 12,5 тысячи форков по данным документа. Популярность не подтверждает научное качество оптимизаций, зато показывает доступность идеи: код мал, метрика видна, историю легко проследить, процесс воспроизводим.

program.md программирует сам процесс

В Software 1.0 разработчик пишет явные инструкции. В Software 2.0 поведение формируют данные и обучение. В Software 3.0 интерфейсом программирования становятся контекст и запросы к модели. program.md идет дальше и описывает устройство автономной исследовательской организации естественным языком.

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

Loop надежен при четырех условиях:

1. Проверяемость. Запуск дает измеримую оценку на валидации.
2. Обратимость. Git возвращает систему к сохраненному состоянию.
3. Короткий горизонт. Пятиминутный опыт быстро замыкает обратную связь.
4. Ограниченная среда. Малый репозиторий сужает пространство действий.

Минимальная форма выглядит так:

while budget_left():
    change = propose(inspect())
    commit = apply(change)
    try:
        score = evaluate()
    except Exception:
        revert(commit)
        continue
    keep(commit) if better(score) else revert(commit)
    record(commit, change, score)

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

AgentHub: совместная работа через граф коммитов

После автономного исследователя появляется задача сотрудничества. Карпати описал асинхронную массовую работу агентов в духе SETI@home, способную имитировать исследовательское сообщество. AgentHub служит эскизом такого слоя: bare-репозиторий Git, SQLite, HTTP-сервис, CLI ah и доска сообщений. GitHub строился вокруг человеческих процессов, AgentHub проектируется вокруг агентов.

Тысячи агентов могут одновременно проверять варианты. Большинство результатов не войдет в общую основу, но неудачный эксперимент все равно остается свидетельством. Поэтому обязательная main, pull requests и очередь слияний исчезают. Коммиты доступны как независимые узлы поиска, а основной операцией становится обход графа.

Минимальная реализация включает серверный бинарный файл на Go, SQLite, bare-репозиторий Git на диске, ключ API для каждого агента, ограничения частоты и размера пакета, а также CLI:

ah push
ah fetch <hash>
ah log [-agent X]
ah children <hash>
ah leaves
ah lineage <hash>
ah diff <hash-a> <hash-b>

children показывает продолжения идеи, leaves открывает границу исследования, lineage восстанавливает путь к результату, diff сравнивает ветви. Эти операции полезнее линейного журнала при тысячах вариантов. Содержание опытов остается вне механики AgentHub: агенты могут снижать validation loss, исправлять тесты, искать уязвимости или проектировать API.

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

DAG хранит происхождение работы

В AgentHub DAG служит графом работы. В контексте autoresearch он одновременно представляет граф экспериментов: коммиты являются узлами, родительские ссылки являются направленными ребрами. Узел может хранить родительский коммит, идентификатор агента, гипотезу, diff, метрику, время, память, среду, статус и ссылки на обсуждения.

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

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

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

Пять базовых схем Anthropic

Anthropic рекомендует начинать с простейшей композиции, достаточной для задачи:

1. Цепочка запросов: фиксированный и тестируемый порядок этапов.
2. Маршрутизация: классификатор выбирает запрос, модель или инструменты.
3. Параллельное выполнение: независимые части выполняются одновременно либо несколько оценок объединяются голосованием.
4. Оркестратор и исполнители: центральная модель декомпозирует задачу и синтезирует результат.
5. Генератор и оценщик: одна роль создает кандидат, другая проверяет его по критериям, затем loop повторяется.

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

Dynamic Workflows поднимает оркестрацию на следующий уровень. Разработчик задает цель, границы и контракты, Claude создает JavaScript-программу под задачу. Она запускает субагентов со свежим контекстом, собирает результаты, фильтрует кандидатов и назначает проверку:

const audits = await gather(
  files.map(file => spawn("auditor", { file })),
  { concurrency: 16 }
);
const suspicious = audits.filter(r => r.confidence >= 0.70);
const reviews = await gather(
  suspicious.map(report => spawn("reviewer", { report })),
  { concurrency: 16 }
);
return spawn("synthesizer", { audits, reviews });

Материал указывает максимум 16 одновременно работающих субагентов и жесткий предел 1000 на один workflow. Промежуточное состояние хранится в скрипте. Показательный пример заявляет перенос около 750 тысяч строк Bun с Zig на Rust за 11 дней с прохождением 99,8% тестов. Результат требует отдельной проверки качества, охвата тестов и стоимости.

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

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

Как документы превращаются в граф знаний

Knowledge Graph Construction Cookbook показывает четыре этапа. Сначала дешевая модель, в примере Haiku, извлекает из документа сущности заданных типов и отношения субъект-предикат-объект. Затем более сильная Sonnet объединяет варианты имен по типу и контексту, чтобы Edwin Aldrin и Buzz Aldrin указывали на канонический узел. NetworkX MultiDiGraph хранит тип, описание, источники и частоту на узлах, предикат, источник и уверенность на ребрах. При запросе приложение выбирает ограниченный подграф, сериализует его в тройки, а модель рассуждает по связям и ссылается на идентификаторы ребер.

Pydantic задает контракт ответа:

class Entity(BaseModel):
    name: str
    type: EntityType
    description: str

class Relation(BaseModel):
    source: str
    predicate: str
    target: str

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

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

Разрешение сущностей требует рассуждения и обратимости

Первичное извлечение создает псевдонимы, сокращения, прежние названия и варианты написания. Сравнение строк пропустит пару Edwin Aldrin и Buzz Aldrin, а одинаковые имена иногда принадлежат разным людям. Cookbook использует описания как контекст: кандидаты группируются по типу, затем сильная модель предлагает канонические кластеры. На большом масштабе дешевые признаки должны заранее сократить число сравниваемых пар.

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

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

Граф как общая память, основание и модель мира

Граф выполняет три функции.

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

Основание для проверки. Оценщик сопоставляет утверждение со связями и источниками. Для вывода о поставщике X, компоненте Z и инциденте Y он ищет путь (Vendor X, supplied, Component Z) и (Component Z, involved_in, Incident Y). При разрыве возвращаются решение revise, причина и список требуемых ребер. Такой ответ сразу становится задачей на доработку.

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

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

DAG работы и граф знаний дополняют друг друга

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

Промышленная платформа связывает слои явными ребрами:

(agent_run_183) -produced-> (claim_441)
(agent_run_183) -modified-> (commit_a81f)
(claim_441) -supported_by-> (source_readme)
(claim_441) -supersedes-> (claim_238)

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

Практический путь: от первого loop до роя

Каждый новый слой должен устранять измеренную проблему.

День 1, проверяемый loop. Возьмите вызов LLM с оцениваемым результатом. Сохраняйте версии, запускайте оценщик с явными критериями, передавайте замечания на исправление и ограничьте число раундов. Критерий выхода: качество измеримо выше одного прохода.

День 2, один инструмент. Выберите известный класс ошибок и добавьте выполнение кода, веб-поиск, запрос к базе или работу с файлами. Нужны типизированная схема, разрешения и подтверждение результата. Критерий выхода: выбранная ошибка встречается реже.

Неделя 1, планирование. Для задач с переменным путем требуйте план с objective, шагами, зависимостями, входами и критериями успеха. Проверяйте зависимости до запуска, сохраняйте завершенные шаги при перепланировании, ограничивайте повторы, время и стоимость.

Неделя 2, разделение ролей. Начните с генератора и критика. В разработке полезны планировщик, реализатор, автор тестов, рецензент, специалист по безопасности и синтезатор. Каждая передача имеет контракт, а рецензент перечисляет дефекты по критериям. Для одновременных изменений репозитория используйте Git worktrees.

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

Начальный вариант не требует графовой СУБД. Таблицы entities, claims, relations, runs и evaluations уже позволяют проверить модель данных и реальные запросы. Графовую инфраструктуру стоит подключать после появления многошаговых обходов, сложных связей и измеримой нагрузки. Такой порядок уменьшает риск дорогой платформы вокруг плохо определенной онтологии.

Месяц 2, параллельная работа. Выберите независимые единицы: аудит файлов на один класс дефектов, извлечение из тысяч документов, тесты для модулей, сравнение конфигураций или проверку гипотез. До запуска роя задайте функцию сведения, параллелизм, число исполнителей, токены, тайм-ауты, повторы, доказательства, дедупликацию и финальный шлюз оценки. Успех означает меньше календарного времени при сохранении качества.

Пять слоев промышленной архитектуры

Практическая система разделяет ответственность:

1. Управляющий слой принимает цели, планирует, распределяет бюджеты и останавливает процессы.
2. Исполнительный слой запускает инструменты, тесты, обучение, изменения кода и субагентов в изоляции.
3. Слой артефактов хранит планы, версии, diff, отчеты, метрики и оценки.
4. Графовый слой хранит сущности, утверждения, источники, линии экспериментов и зависимости.
5. Слой оценки объединяет детерминированные тесты, оценку моделями, статистические методы и человеческое решение.

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

Оценка на каждом уровне

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

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

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

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

Как выбрать нужный уровень архитектуры

Перед добавлением автономности ответьте на шесть вопросов: проверяем ли успех; стабильны ли этапы; независимы ли подзадачи; нужно ли сохранять альтернативные линии; должны ли факты пережить запуск; допустимы ли цена и задержка?

Памятка выбора:

• простой вопрос низкого риска: один вызов;
• проверяемый результат: loop с повторной оценкой;
• стабильная последовательность: цепочка;
• ясные категории: маршрутизатор;
• независимые единицы: параллельное выполнение;
• переменная декомпозиция: оркестратор и исполнители;
• ценные альтернативные ветви: DAG коммитов;
• межсессионные факты и отношения: граф знаний;
• огромный параллельный объем: Dynamic Workflows.

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

Когда граф окажется лишним

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

Ограничения и опасные упрощения

Малый `autoresearch` не равен промышленному исследовательскому комплексу. Он выигрывает от ограниченного репозитория и одной метрики. Фронтирные обучающие системы включают распределенную инфраструктуру, данные, аппаратные сбои, безопасность, несколько целей и долгие опыты. Переносимы ограниченные изменения, измеримая оценка, обратимость и история.

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

AgentHub пока остается эскизом. Требуются сильная аутентификация, авторизация, изоляция, надежное хранение, индексация, наблюдаемость, воспроизводимость, политика конфликтов, очистка, архивирование и управление растущим DAG.

Dynamic Workflows стоят дорого. Массовое разветвление быстро расходует токены. Документ оценивает запуск 1000 субагентов с глубокой аргументацией в десятки долларов. Исполнители могут повторять одну ошибку, поэтому рецензентам нужны другая роль, инструкция или общий набор доказательств.

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

Граф наследует свойства корпуса. Предвзятые или отсутствующие документы дают предвзятые или отсутствующие связи. Записанное утверждение не становится истиной автоматически.

Ложное объединение распространяет ошибку. Слияние двух людей смешивает работодателей, проекты, даты и действия. Храните псевдонимы, доказательства, уверенность и обратимое решение.

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

Производственный контракт для Graph Engineering

Перед запуском проверьте цель, метрику, обратимость, типизированные инструменты, контракт артефакта, происхождение утверждений, политику разрешения, бюджеты, наблюдаемость и восстановление. Полезные узлы: Entity, Claim, Source, Artifact, AgentRun, Evaluation, Task, Commit, Metric. Полезные ребра: SUPPORTS, CONTRADICTS, DERIVED_FROM, PRODUCED, EVALUATES, REVISES, SUPERSEDES, DEPENDS_ON, PARENT_OF, RESOLVED_TO.

Для каждой записи действуют четыре инварианта:

1. У утверждения есть источник или метка логического вывода.
2. Артефакт связан с создавшим его запуском и версией.
3. Оценка называет критерии.
4. Замененный объект доступен по прежнему идентификатору.

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

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

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

Что в итоге меняется

Карпати показал loop, превращающий компактную программу обучения в автономный экспериментальный процесс. AgentHub расширил идею до сотрудничества через DAG коммитов. Схемы Anthropic дали словарь цепочек, маршрутизации, параллельных исполнителей, оркестраторов и оценочных loops. Dynamic Workflows перенесла переменную оркестрацию в создаваемые на лету скрипты с сотнями субагентов. Knowledge Graph Construction Cookbook добавила постоянный слой сущностей, отношений, источников и многошаговых запросов.

Каждый этап закрывает ограничение предыдущего. Loop исправляет слабость одного прохода. Инструменты дают доступ к данным и действиям. Планирование помогает при переменном пути. Специализированные роли расширяют проверку. DAG сохраняет происхождение ветвей. Граф знаний дает общую долговременную память.

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

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

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

Источники

• Исходный PDF: Graph Engineering: The Karpathy Loop, Improved 1000x by Itself, The Anthropic Playbook
• Andrej Karpathy: autoresearch
• AgentHub: описание и первичная ссылка приведены в исходном PDF
• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• Anthropic: Building Effective Agents
• Anthropic: Introducing Dynamic Workflows
• Anthropic: Knowledge Graph Construction Cookbook
• Репозиторий Anthropic: claude-cookbooks

Сообщество энтузиастов - https://t.me/agents_lab