015: Агент/Мета
- Требует:
- Дополняется:
Структурированный объект, который содержит явную идентификацию Запроса, включая его имя, пространство имён, версию, дату создания и ассоциации с ветками. Он предоставляет стабильный, машиночитаемый якорь для отслеживания происхождения и адресуемости запроса.
Хотя многие взаимодействия агентов могут быть эфемерными, для создания сложных систем с отслеживанием состояний требуется способ уникальной идентификации и отслеживания Запроса и его итогового Решения. Объект Meta служит именно этой цели. Это «визитная карточка» Запроса, предоставляющая стабильный, машиночитаемый идентификатор, который обеспечивает сохранение, версионирование, маршрутизацию и историческое отслеживание.
Ключевым моментом является то, что, делая идентификацию явной частью solution, объект Meta даёт LLM возможность создавать новые идентификаторы или ответвлять существующие в прямой реакции на свой контекст, превращая простой ответ в акт творения.>
Объект Meta в жизненном цикле Запроса
Объект Meta является полноправным участником жизненного цикла Запроса. Он появляется в context, чтобы информировать LLM о текущей идентификации запроса, и в schema как обязательная часть solution.
- В
context: Сообщениеmetaпредоставляет LLM идентификатор состояния или процесса, который он в данный момент обновляет. - В
schema: Схемаsolutionтребует свойствоmeta, заставляя LLM рассматривать и обновлять идентификатор как часть своей задачи. - В
solution: LLM генерирует новый объектmeta, часто с обновлённой версией, отражающей эволюцию процесса.
Этот цикл превращает LLM из простого обработчика в активного участника жизненного цикла версионируемой сущности с состоянием.
Весь этот конвейер Запроса — context (включая сообщение Meta), schema и итоговый solution — образует самодостаточную, воспроизводимую единицу. При сохранении эта единица становится тем, что система называет Идеей. Объект Meta — это ключ, который превращает эфемерный Request в постоянную, адресуемую Idea.
Пример структуры Запроса
// LLM получает текущие метаданные как контекст,
// и ей поручается создать новые в решении.
{
"context": [
{
"type": "meta",
"meta": {
"domain": "reactor.ideas.services",
"path": "/games/321",
"version": "1.2.3",
"branches": ["main"],
"createdAt": "2025-10-26T10:00:00Z"
}
},
{
"type": "state",
"state": {
"...текущее состояние игры..."
}
}
],
"schema": {
"type": "object",
"properties": {
"meta": {
"$ref": "MetaSchema"
},
"output": {
"$ref": "GameSchema"
}
}
}
}
Пример Решения
// Решение LLM включает следующее состояние игры
// и обновлённую версию в новом мета-объекте.
{
"meta": {
"domain": "reactor.ideas.services",
"path": "/games/321",
"version": "1.2.4",
"branches": ["main"],
"createdAt": "2025-10-26T10:05:00Z"
},
"output": {
"...следующее состояние игры..."
},
"calls": []
}
Автономная эволюция и версионирование
- Принципы автономного улучшения описаны в 106: Концепция/Эволюция.
Ключевая роль объекта Meta заключается в обеспечении автономной эволюции агентных процессов. Включая текущую версию и ветки в context и требуя новую версию в solution, система поручает LLM обновление версии. Создание нового solution по той же schema считается совместимым изменением, и поэтому агент должен инкрементировать минорную версию. Это создаёт новый, неизменяемый снимок его состояния и логики, формируя полную и проверяемую историю действий агента с течением времени.
Это создаёт проблему в распределённых системах: если два независимых процесса одновременно реагируют на разные события, они оба могут попытаться обновить версию с 1.2.3 до 1.2.4, создавая состояние гонки.
- Это подробно описано в 108: Концепция/Видимость.
Архитектура решает эту проблему с помощью механизма ветвления. При создании новой линии разработки процесс добавляет новую ветку в массив branches (например, ["main", "my-feature"]) и создаёт разветвлённую версию. Версии становятся соответственно 1.2.3.branch-A.1 и 1.2.3.branch-B.1. Это позволяет осуществлять параллельную, бесконфликтную эволюцию, при этом различные истории могут быть объединены или согласованы позже.
Связывание идентификатора с адресом
- Конкретный синтаксис этой схемы адресации определён в 110: Концепция/Адресация.
Поля в объекте Meta предоставляют все необходимые компоненты для присвоения Запросу глобально уникального адреса. Это позволяет программно извлекать, маршрутизировать или ссылаться на конкретный версионированный экземпляр пары запрос/решение.
Процесс разрешения связывает динамический запрос с конкретным, неизменяемым результатом. Вот подробное описание:
-
Мета: Свойства конкретного версионированного экземпляра.
- meta.domain:
my-project.com - meta.path:
bob - meta.version:
1.2.staging.1 - meta.branches:
['staging'] - meta.createdAt:
2025-10-26T10:00:00Z
- meta.domain:
-
Ссылка: Динамический запрос к сущности.
idea://my-project.com/bob?1.2- Путь поиска:
['staging'] - Дата отсечки:
2025-10-26T10:00:00Z(изcreatedAt)
-
Разрешено: Постоянный, однозначный URI, указывающий на найденный ресурс.
idea://my-project.com/~:staging/bob?1.2:1.2.staging.1- Ветка:
~:staging- запрошено: любая ветка в пути поиска
- получено:
staging
- Версия:
1.2:1.2.staging.1- запрошено: последняя совместимая с
1.2 - получено:
1.2.staging.1
- запрошено: последняя совместимая с
Это делает весь блок запрос-решение самоописываемым и адресуемым.