Контекст

При интеграции ChatGPT с fi1osof.ru обнаружилась системная проблема: ChatGPT умеет генерировать большие объёмы промежуточного контента и выполнять последовательность API-вызовов, но у него нет удобной переиспользуемой адресуемой рабочей памяти, на которую можно сослаться между отдельными Action-вызовами.

На практике это проявилось при создании большого worklog. Текст worklog был сформирован один раз, но при повторной попытке записи его пришлось снова целиком передавать внутри GraphQL variables. Если операция падает, повторяется или используется в другом контексте, один и тот же большой payload приходится снова переносить через ChatGPT Action.

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

Основная потребность

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

Условно:

создать переменную / артефакт
→ получить ID
→ использовать ID в других действиях

Пример:

var_abc123 = "# Большой Markdown..."

а затем:

создать worklog
content = var_abc123

или:

создать задачу
content = var_abc123

Почему обычных GraphQL variables недостаточно

GraphQL variables живут только внутри одного HTTP-запроса.

Они не дают возможности:

• сохранить результат одного шага и сослаться на него в следующем;
• переиспользовать большой текст без повторной передачи;
• адресовать промежуточный результат по ID;
• разделить этапы «сформировать → проверить → использовать»;
• восстановить рабочий объект после ошибки или новой попытки;
• передать один и тот же артефакт нескольким операциям.

Почему текущий диалог ChatGPT тоже не решает проблему

Текст в истории чата доступен модели как контекст, но это не полноценный адресуемый объект API.

Нельзя надёжно сделать операцию уровня:

возьми именно тот Markdown, который был сформирован два шага назад,
и передай его как content без повторной генерации/пересборки

На уровне Action всё равно требуется фактическое значение аргумента, и большой текст снова попадает в payload.

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

Почему не стоит решать это отдельными предметными сущностями

Можно было бы сохранять промежуточный текст как Task, File, Fact, Draft и т.п., но это создаёт лишнюю семантику и загрязняет предметную модель.

Промежуточный рабочий state должен быть универсальным и не зависеть от того, используется он затем для:

• worklog;
• задачи;
• комментария;
• GraphQL mutation;
• передачи другому агенту;
• JSON-конфига;
• списка ID;
• результата запроса;
• большого Markdown;
• временного анализа.

Предлагаемая абстракция

Важно не привязываться к слову «файл». Нужен устойчивый адресуемый артефакт / variable / workspace value.

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

id
name?
type
value
scope
createdBy
createdAt
expiresAt?

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

string
json

В дальнейшем при необходимости можно добавить binary/file/reference и другие варианты.

Время жизни

Полезно различать как минимум два режима.

Session / temporary

Для краткосрочного рабочего state:

• промежуточные результаты;
• большие тексты;
• результаты query;
• подготовленные payload'ы.

Могут автоматически удаляться по TTL.

Persistent

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

Возможная модель использования

Шаг 1. Сохранить значение

createVariable(
  name: "integration_worklog",
  value: "# Практический опыт интеграции...",
  type: "string"
)

Ответ:

var_abc123

Шаг 2. Использовать значение

Вариант A — специализированное поле:

createTaskWorkLog(
  taskId: "...",
  contentVariableId: "var_abc123"
)

Вариант B — универсальная ссылка внутри аргумента:

{
  "taskId": "...",
  "content": {
    "$var": "var_abc123"
  }
}

Перед вызовом доменного resolver промежуточный слой разворачивает $var в фактическое значение.

Как именно реализовать resolution — отдельный архитектурный вопрос. В этой задаче важнее сама потребность и универсальность механизма.

Что это даёт внешним AI-клиентам

1. Переиспользование больших результатов

Большой Markdown или JSON передаётся один раз, после чего используется по короткому ID.

2. Нормальный многошаговый workflow

Появляется возможность разделить процесс:

сгенерировать
→ сохранить
→ проверить
→ отредактировать при необходимости
→ использовать
→ переиспользовать

3. Устойчивость к ошибкам

Если конечная mutation упала, не нужно заново генерировать или заново передавать весь исходный контент. Можно повторить действие с тем же variable ID.

4. Экономия контекста и payload

Снижается объём повторно передаваемых данных между ChatGPT и backend.

Особенно это важно для длинных:

• worklogs;
• постановок задач;
• отчётов;
• результатов исследований;
• JSON-конфигураций;
• списков сущностей.

5. Универсальность

Один механизм работает для разных AI-клиентов и разных операций, а не только для ChatGPT или worklogs.

Это может использоваться:

• ChatGPT Actions;
• ChatGPT App / MCP;
• haih-agent;
• другие внешние агенты;
• IDE-агенты;
• локальные модели.

Важное архитектурное свойство

Этот механизм фактически становится workspace/runtime state для внешнего reasoning runtime.

Внешний агент думает и формирует промежуточные результаты, а fi1osof.ru/haih-agent предоставляет ему адресуемую оперативную память, которая существует независимо от конкретного LLM-вызова.

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

Что нужно продумать

• API создания, чтения, обновления и удаления переменных;
• owner/createdBy;
• scope и права доступа;
• TTL и автоочистку temporary values;
• ограничения размера;
• string/json типы;
• безопасный variable resolution;
• защиту от рекурсивных ссылок;
• audit trail;
• возможность использовать переменную как аргумент в разных mutations;
• поведение при удалённой/просроченной переменной;
• нужно ли поддерживать versioning;
• нужно ли различать private/session/agent/project scope.

Критерий готовности

Внешний AI-клиент должен быть способен выполнить сценарий:

1. Сформировать большой Markdown.
2. Один раз сохранить его как адресуемый value.
3. Получить короткий ID.
4. Выполнить несколько независимых API-операций, передавая только этот ID.
5. Повторить упавшую операцию без повторной передачи исходного Markdown.

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