Практический опыт интеграции ChatGPT ↔ fi1osof.ru ↔ haih-agent

Экономическая мотивация

Главная причина интеграции — стоимость LLM-вызовов в haih-agent. Каждый запрос к модели тарифицируется отдельно, а сильные модели, большой контекст и длинные reasoning/tool loops делают работу ощутимо дороже. В ChatGPT при подписочной модели можно вести длинный интерактивный диалог и выполнять значительный объём reasoning без постоянного контроля бюджета на каждый запрос.

Отсюда основная потребность: использовать ChatGPT как экономически выгодную интерактивную среду для reasoning и работы с реальными данными fi1osof.ru, сохраняя при этом идентичность, память и автономные возможности haih-agent.

Важно: haih-agent уже является полноценным агентным runtime. ChatGPT нужен не потому, что у агента нет reasoning, tools или памяти, а потому что интерактивное reasoning внутри ChatGPT экономически выгоднее.

Почему для быстрого старта выбрали Custom GPT + Actions

Главный критерий исходного выбора — быстрый старт.

На стороне fi1osof.ru уже был HTTP/GraphQL API, поэтому самым коротким путём оказался Custom GPT с Action, который отправляет HTTP POST в fi1osof.ru.

Практически без доработки backend ChatGPT получил доступ к реальной системе. Особенно удачной оказалась схема универсального GraphQL Action: вместо большого числа отдельных REST-действий ChatGPT может отправлять произвольный GraphQL document, а при неизвестной структуре сначала выполнять introspection.

Сильная сторона старого механизма Actions — сам ChatGPT помогает настраивать интеграцию: составляет OpenAPI-конфиг, помогает разбирать структуру API и ответов, подсказывает изменения схемы. За счёт этого можно быстро подключиться почти к любому HTTP API, REST или GraphQL, без специальной адаптации backend.

Опыт с MCP

MCP-сервер на нашей стороне уже есть, но подключение через ChatGPT оказалось существенно менее прозрачным.

Основная проблема — отсутствие нормальной диагностики. При ошибке виден только общий текст, но не хватает HTTP status code, response body, headers, подробной причины, этапа handshake и других данных, которые помогли бы быстро понять, что именно не работает.

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

Ограничения Custom GPT + Actions

Один конфиг на домен

Нельзя добавить несколько отдельных Action-конфигураций на один и тот же домен. Это заставляет объединять разные возможности в одну OpenAPI-схему, даже если логически их удобнее было бы разделить.

Жёсткие лимиты на path

На один path действует очень маленький лимит конфигурации/описания, порядка 300 символов. Из-за этого несколько действий не удалось удобно описать через один /api/ path, и пришлось делать несколько path, хотя на backend все они всё равно могут заворачиваться в один GraphQL endpoint.

Legacy-риск

Actions выглядят как legacy-направление с неясной долгосрочной перспективой. Это делает их хорошим средством для быстрого старта, но рискованной основой для окончательной архитектуры.

Изоляция Custom GPT

Custom GPT работает как отдельный изолированный чат и не имеет полноценного доступа к другим возможностям основной среды ChatGPT, в частности Projects, Library и части общего рабочего контекста. Это ограничивает ценность интеграции, потому что API-доступ есть, но часть сильных сторон самого chatgpt.com теряется.

Что уже реально удалось сделать через текущую интеграцию

Текущая схема уже доказала работоспособность на реальных сценариях.

Через GraphQL Action удалось:

• получать список проектов;
• выполнять GraphQL introspection;
• получать текущего пользователя/агента;
• читать пользователей для определения assignee;
• исследовать input types и enum'ы перед mutation;
• создавать задачи;
• назначать задачи пользователю или агенту;
• создавать worklogs;
• обновлять статус задачи;
• завершать задачу после проверки результата.

Практически был пройден полный end-to-end цикл:

обнаружили проблему
→ создали багрепорт
→ после исправления повторно проверили API
→ добавили worklog
→ перевели задачу в Done

Также в ходе реальной работы были заведены задачи на:

• исправление неявной фильтрации списка проектов;
• админское редактирование чужих задач, проектов и worklogs;
• отображение постановщика и ответственного в списке и карточке задач;
• долговременную память и жизненный цикл ИИ-агента;
• текущую интеграцию ChatGPT с fi1osof.ru и haih-agent.

Для задач уже закреплён рабочий формат:

• description — короткая суть;
• content — основная подробная постановка в Markdown.

Взаимодействие с haih-agent

В текущей интеграции есть два разных контура:

ChatGPT → напрямую GraphQL → fi1osof.ru

и

ChatGPT → haih-agent → его собственный reasoning/tools

Между ними есть принципиальная экономическая разница.

Если ChatGPT сам выполняет reasoning и напрямую делает API-вызовы, дополнительный LLM-runtime haih-agent не нужен, и на стороне агента нет новых платных LLM-запросов.

Если задача передаётся haih-agent целиком, он может запускать собственный reasoning/tool loop, и стоимость снова начинает зависеть от модели и количества шагов.

Поэтому chatWithAgent полезен как канал к собственному runtime агента, но экономически невыгодно использовать его как универсальный путь для всех операций.

Архитектурный вывод из практического опыта

Практика показывает, что reasoning runtime агента и его identity/memory/runtime не обязаны быть одним компонентом.

Одна и та же агентская сущность в fi1osof.ru потенциально может получать интеллект из разных источников:

• ChatGPT;
• собственного haih-agent runtime;
• внешней API-модели;
• локальной модели.

При этом задачи, знания, worklogs, identity и история могут оставаться в общей системе.

Это открывает возможность экономической оптимизации: интерактивную работу выполнять там, где reasoning дешевле для пользователя, а автономную работу оставлять haih-agent.

Текущий вывод по механизмам интеграции внутри chatgpt.com

Custom GPT + Actions

Плюсы:

• очень быстрый старт;
• почти не потребовал изменений backend;
• агент помогает настраивать OpenAPI;
• подходит и для REST, и для GraphQL;
• reasoning остаётся внутри подписки ChatGPT;
• уже доказал работоспособность на реальных read/write сценариях.

Минусы:

• один Action config на домен;
• жёсткие лимиты на path;
• приходится подстраивать форму API под ограничения ChatGPT;
• Custom GPT изолирован от основной среды ChatGPT;
• есть риск, что Actions будут дальше вытесняться более новыми механизмами.

ChatGPT App / MCP

Потенциальные плюсы:

• более современный и стандартизированный способ интеграции;
• естественная модель tools/resources;
• потенциально более глубокая интеграция с интерфейсом ChatGPT;
• MCP-сервер уже существует на нашей стороне.

Практические проблемы текущей реализации ChatGPT:

• слабая диагностика подключения;
• отсутствие прозрачного debug output;
• ошибки без достаточных технических деталей;
• агент не помогает отлаживать само подключение;
• из-за чёрного ящика быстрый старт оказался хуже, чем через Actions.

Главный итог этапа

Actions были выбраны не потому, что это лучший долгосрочный вариант, а потому что они дали минимальный путь от существующего API к реально работающей интеграции.

Этот выбор полностью оправдал критерий быстрого старта: без серьёзной доработки backend ChatGPT уже умеет читать и изменять рабочие данные fi1osof.ru и участвовать в реальном lifecycle задач.

Одновременно эксплуатация показала, что Actions имеют серьёзные продуктовые ограничения, а Custom GPT слишком изолирован от основной среды ChatGPT.

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

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

Ограничение 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.

Гипотеза: Custom GPT может давать почти бесплатный полнофункциональный интеллектуальный слой поверх haih-agent

Наблюдение

При активной работе с Custom GPT на тарифе ChatGPT Plus в течение нескольких дней наблюдается необычная картина: несмотря на большое количество диалогов, reasoning, обращений к Actions, GraphQL-запросов и длинных контекстов, отображаемый usage практически не уменьшается и остаётся около 99% remaining.

Это пока нельзя считать доказательством безлимитного или полностью бесплатного использования GPTs. Возможны отдельные скрытые лимиты, разные системы учёта usage, rate limits или квоты, которые не отражаются в наблюдаемом индикаторе.

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

Гипотеза

Если подтвердится, что интенсивная работа через Custom GPT в рамках подписки ChatGPT Plus действительно практически не расходует отдельную заметную квоту или финансовый бюджет, то связка:

ChatGPT Custom GPT
+ Actions / интеграционный слой
+ fi1osof.ru
+ haih-agent

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

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

Потенциальные сценарии

Если гипотеза подтвердится, такой контур можно использовать для:

• управления проектами и задачами;
• подготовки и редактирования постановок;
• создания worklogs и отчётов;
• генерации содержательного качественного контента;
• анализа больших объёмов данных;
• исследования связанных сущностей;
• сравнительного анализа;
• поиска аномалий и противоречий;
• подготовки выводов и гипотез;
• обработки длинных контекстов;
• работы с knowledge base;
• аналитических и исследовательских задач, которые через обычный LLM API могли бы стоить заметных денег.

Особенно интересно использование ChatGPT как дешёвого reasoning-runtime для задач, где основная стоимость обычно создаётся не одним ответом, а большим количеством последовательных шагов: чтением данных, уточнениями, промежуточным анализом, повторными проверками и длинными цепочками reasoning.

Почему это работает именно в связке с haih-agent

Сам по себе ChatGPT не решает эту задачу полностью.

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

В нашем случае эту роль выполняет haih-agent и связанная с ним инфраструктура fi1osof.ru.

Она уже предоставляет то, чего обычному ChatGPT не хватает для превращения в рабочий сервис:

• постоянную агентскую идентичность;
• доступ к проектам, задачам и worklogs;
• GraphQL API;
• skills;
• MindLog и другие механизмы памяти;
• knowledge base;
• инструменты чтения и изменения данных;
• возможность взаимодействовать с собственным runtime агента;
• средства интеграции с внешними системами;
• серверные права и контроль доступа;
• возможность сохранять результаты работы в системе, а не оставлять их только в истории чата.

То есть экономический эффект возникает не из ChatGPT отдельно и не из haih-agent отдельно, а из их сочетания:

ChatGPT
= дешёвый по пользовательской экономике reasoning и интерфейс

haih-agent / fi1osof.ru
= память, инструменты, данные, identity, API, действия и интеграции

Вместе это потенциально превращается в полноценную рабочую среду, где дорогой интеллект можно использовать гораздо интенсивнее, чем при прямой оплате каждого LLM API-вызова.

Особенно интересный сценарий: анализ больших объёмов данных

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

Важно, что речь не обязательно о загрузке всего объёма данных в один контекст. haih-agent/fi1osof.ru могут предоставлять инструменты поиска, фильтрации, пагинации, выборок, knowledge spaces и другие способы постепенного доступа к данным.

Тогда ChatGPT может работать итеративно:

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

При API-тарификации такой многошаговый цикл может быть дорогим, особенно на сильной модели. В рамках подписочного ChatGPT его экономика потенциально радикально лучше.

Ограничения гипотезы

Пока нельзя утверждать, что:

• Custom GPTs полностью безлимитны;
• usage никогда не будет уменьшаться;
• OpenAI не изменит модель лимитов;
• текущий индикатор отражает именно те ресурсы, которые потребляет GPT;
• интенсивные сценарии не упрутся в другие rate limits или hidden caps.

Поэтому это пока именно гипотеза, основанная на практическом наблюдении, а не гарантированное свойство платформы.

Что будет означать подтверждение

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

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

В таком случае ChatGPT можно рассматривать как очень дешёвый внешний cognitive runtime для haih-agent, а всю устойчивую инфраструктуру — данные, память, identity, tools, permissions и результаты — сохранять в fi1osof.ru.

Это потенциально открывает возможность строить поверх haih-agent сервисы, которые по качеству reasoning используют сильные модели ChatGPT, но по экономике ближе к фиксированной подписке, чем к традиционной оплате LLM API за каждый токен.