Практический опыт интеграции 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'ами после экспериментов, а не считать заранее выбранными.