Ограничение ChatGPT: нет переиспользуемой адресуемой рабочей памяти между Action-вызовами

Практическая проблема

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

Проблема проявилась при записи большого worklog в задачу. Текст worklog был уже сформирован в диалоге, но при каждом вызове createTaskWorkLog его приходилось снова целиком вкладывать в GraphQL variables.

Когда первая попытка записи завершилась ошибкой resolver, при повторе пришлось снова отправлять тот же длинный Markdown целиком.

То есть фактически отсутствует промежуточный слой вида:

сформировать контент
→ сохранить как var/draft/artifact
→ получить ID
→ использовать ID в последующих API-операциях

Какие средства есть сейчас и почему их недостаточно

GraphQL variables

GraphQL variables подходят только для параметризации одного HTTP-запроса.

Они не живут между вызовами и не позволяют сослаться на результат предыдущего шага.

История текущего диалога

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

Нельзя надёжно передать в Action нечто вроде:

content = тот Markdown, который был сформирован несколько сообщений назад

На уровне HTTP/GraphQL всё равно требуется фактическое значение content, поэтому оно повторно сериализуется и отправляется целиком.

Предметные сущности fi1osof.ru

Технически можно временно сохранить текст как Task, File, Fact или другую постоянную сущность, но это неправильная семантика и загрязнение доменной модели промежуточными runtime-данными.

Проблема требует универсальной рабочей памяти, независимой от конкретной бизнес-сущности.

Почему это плохо

1. Повторная передача больших payload

Длинные тексты, JSON, результаты анализа и другие объекты приходится снова и снова передавать через Action.

Это увеличивает размер запросов и делает интеграцию более хрупкой.

2. Нет нормального многошагового workflow

Невозможно естественно разделить работу на этапы:

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

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

3. Плохая устойчивость к ошибкам

Если конечная mutation падает, исходный payload приходится передавать заново.

Нельзя просто повторить операцию с тем же ID уже сохранённого артефакта.

4. Проблема не ограничивается worklogs

То же самое возникнет для:

• длинных постановок задач;
• отчётов;
• Markdown-документов;
• JSON-конфигураций;
• результатов исследований;
• списков ID;
• результатов GraphQL query;
• подготовленных payload'ов;
• данных, которые нужно передать другому агенту.

5. Это ограничивает agentic workflows

ChatGPT в нашей схеме используется как внешний reasoning runtime. Для нормальной агентной работы ему нужна не только долговременная knowledge memory, но и оперативный адресуемый workspace state между отдельными действиями.

Без этого внешний агент умеет думать и вызывать API, но его промежуточные рабочие результаты остаются привязаны к текстовому контексту диалога вместо нормального runtime state.

Желаемая абстракция

Нужен не обязательно «файл» и не специализированный TaskWorkLogDraft, а универсальный адресуемый value/artifact/variable.

Условно:

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

После чего можно выполнить:

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

или использовать тот же объект в другой операции.

Такой механизм превращается в промежуточную рабочую память между внешним AI-клиентом и fi1osof.ru/haih-agent.

Связанная задача на доработку haih-agent

Подробная постановка вынесена в отдельную задачу проекта haih-agent:

tasks/cmt839tuu000kmq0q72h9ppm9

«Добавить адресуемую переиспользуемую рабочую память для внешних AI-клиентов».

В ней описаны требования к универсальным переменным/артефактам, возможные scope/TTL, типы string/json, повторное использование по ID, устойчивость к ошибкам и использование этой механики разными внешними reasoning runtimes.

Вывод для интеграции ChatGPT

Текущая интеграция уже позволяет ChatGPT выполнять реальную работу через API, но выявила важный недостающий слой:

между reasoning context ChatGPT и постоянными доменными сущностями fi1osof.ru нужна адресуемая оперативная память.

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