015: Агент/Мета
- Требуется:
- Дополняется:
Это как паспорт для запроса. Он содержит всю важную информацию: имя, адрес, версию, дату создания и к каким группам (веткам) он относится. Это надёжная, понятная компьютеру метка, которая помогает отслеживать историю запроса и легко его находить.
Хотя многие простые команды для искусственного интеллекта могут быть одноразовыми, для создания сложных систем, которые помнят, что было раньше, нужен способ точно определять и отслеживать каждый запрос и его решение. Для этого и служит объект Meta. Это «визитная карточка» запроса, которая даёт ему уникальное имя, понятное компьютеру. С её помощью можно сохранять результаты, создавать новые версии, отправлять задачи по нужному адресу и просматривать всю историю изменений.
Самое важное: когда эта «визитка» становится обязательной частью ответа, искусственный интеллект (ИИ) сам может создавать новые «личности» для задач или делать их копии (ветки) в зависимости от ситуации. Так простой ответ превращается в акт творения чего-то нового.>
Объект Meta в жизненном цикле запроса
Объект Meta — это главный участник в жизни запроса. Он появляется в context (входных данных), чтобы ИИ знал, с чем работает, и в schema (правилах), как обязательная часть solution (ответа).
- В
context: Сообщениеmetaпередаёт ИИ «паспорт» той задачи или процесса, который он сейчас обновляет. - В
schema: Правила дляsolutionтребуют наличия свойстваmeta. Это заставляет ИИ думать об «личности» задачи и обновлять её как часть своей работы. - В
solution: ИИ создаёт новый объектmeta, обычно с новой версией, показывая, что задача развилась и перешла на следующий этап.
Такой цикл превращает ИИ из простого исполнителя в активного участника, который помогает жить и развиваться сложным, версионным системам.
Вся эта цепочка — context (включая сообщение Meta), schema и итоговый solution — образует единый, самодостаточный блок. Когда этот блок сохраняется, система называет его Идеей. Объект Meta — это ключ, который превращает одноразовый Запрос в постоянную, адресуемую Идею.
Пример структуры Запроса
// ИИ получает текущие метаданные как контекст
// и должен создать новые в своём решении.
{
"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"
}
}
}
}
Пример Решения
// Решение ИИ включает следующее состояние игры
// и обновлённую версию в новом мета-объекте.
{
"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, мы даём ему задачу обновить версию. Если ИИ вносит совместимое изменение, он должен увеличить номер версии (например, с 1.2.3 до 1.2.4). Это создаёт новый, неизменяемый «снимок» состояния и логики, формируя полную и прозрачную историю действий агента.
Это создаёт проблему в больших системах: если два разных процесса одновременно отреагируют на разные события, они оба могут попытаться обновить версию с 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): Свойства конкретной версии.
- 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:
-
Ссылка (Reference): Динамический запрос чего-либо.
idea://my-project.com/bob?1.2- В каких ветках искать:
['staging'] - Не старше чем:
2025-10-26T10:00:00Z(изcreatedAt)
-
Результат (Resolved): Постоянный, однозначный адрес, указывающий на найденный ресурс.
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
- Искали: последнюю, совместимую с
Это делает каждую пару «запрос-решение» полностью самоописываемой и адресуемой.