Trải nghiệm thực tế về tích hợp ChatGPT ↔ fi1osof.ru ↔ haih-agent

Động lực kinh tế

Lý do chính của việc tích hợp là chi phí gọi LLM trong haih-agent. Mỗi yêu cầu gửi đến mô hình được tính phí riêng biệt, và các mô hình mạnh, ngữ cảnh lớn cùng các vòng lặp reasoning/tool dài làm cho công việc trở nên đắt đỏ hơn đáng kể. Trong ChatGPT, với mô hình đăng ký (subscription), người dùng có thể thực hiện một cuộc trò chuyện tương tác dài và thực hiện một khối lượng lớn reasoning mà không cần kiểm soát ngân sách liên tục cho từng yêu cầu.

Từ đó dẫn đến nhu cầu cốt lõi: sử dụng ChatGPT như một môi trường tương tác có lợi về mặt kinh tế để reasoning và làm việc với dữ liệu thực tế của fi1osof.ru, đồng thời duy trì danh tính, bộ nhớ và các khả năng tự trị của haih-agent.

Quan trọng: haih-agent đã là một runtime tác vụ (agent runtime) hoàn chỉnh. ChatGPT không phải cần đến vì tác nhân thiếu reasoning, công cụ hay bộ nhớ, mà vì reasoning tương tác bên trong ChatGPT mang lại hiệu quả kinh tế cao hơn.

Tại sao lại chọn Custom GPT + Actions để khởi động nhanh

Tiêu chí chính cho sự lựa chọn ban đầu là khởi động nhanh.

Phía fi1osof.ru đã có sẵn HTTP/GraphQL API, vì vậy con đường ngắn nhất hóa ra là Custom GPT với Action gửi yêu cầu HTTP POST đến fi1osof.ru.

Hầu như không cần sửa đổi backend, ChatGPT đã có được quyền truy cập vào hệ thống thực tế. Mô hình GraphQL Action đa năng tỏ ra đặc biệt thành công: thay vì số lượng lớn các REST action riêng lẻ, ChatGPT có thể gửi một tài liệu GraphQL tùy ý, và nếu cấu trúc chưa rõ, trước tiên có thể thực hiện introspection.

Điểm mạnh của cơ chế Actions cũ là bản thân ChatGPT hỗ trợ thiết lập tích hợp: soạn thảo cấu hình OpenAPI, giúp phân tích cấu trúc API và phản hồi, gợi ý các thay đổi lược đồ (schema). Nhờ đó, bạn có thể kết nối nhanh chóng với hầu như bất kỳ HTTP API, REST hoặc GraphQL nào mà không cần điều chỉnh backend đặc biệt.

Trải nghiệm với MCP

Phía chúng tôi đã có sẵn máy chủ MCP, nhưng việc kết nối thông qua ChatGPT tỏ ra ít minh bạch hơn đáng kể.

Vấn đề chính là thiếu các công cụ chẩn đoán bình thường. Khi xảy ra lỗi, chỉ thấy văn bản chung chung, thiếu mã trạng thái HTTP, phần thân phản hồi (response body), tiêu đề (headers), nguyên nhân chi tiết, giai đoạn bắt tay (handshake) và các dữ liệu khác có thể giúp nhanh chóng hiểu rõ điều gì đang không hoạt động.

Vấn đề thứ hai là không có chế độ thiết lập tự động (agentic setup) cho chính việc tích hợp. Trong Actions, tác nhân giúp thu thập và sửa lỗi cấu hình, trong khi kết nối MCP gần như không thấy lỗi nội bộ và không thể tự mình nghiên cứu sự cố. Kết quả là kết nối giống như một hộp đen (black box), và việc khởi động nhanh đã không thành công ngay cả khi đã có sẵn máy chủ MCP.

Hạn chế của Custom GPT + Actions

Một cấu hình cho mỗi tên miền (domain)

Không thể thêm nhiều cấu hình Action riêng biệt vào cùng một tên miền. Điều này buộc phải gộp các tính năng khác nhau vào một lược đồ OpenAPI duy nhất, ngay cả khi về mặt logic, việc tách chúng ra sẽ thuận tiện hơn.

Giới hạn đường dẫn (path) nghiêm ngặt

Có giới hạn cấu hình/mô tả rất nhỏ áp dụng cho một path, khoảng 300 ký tự. Do đó, một số action không thể được mô tả thuận tiện qua một path /api/ duy nhất, và phải tạo nhiều path, mặc dù ở backend tất cả chúng vẫn có thể được gói gọn vào một điểm cuối (endpoint) GraphQL duy nhất.

Rủi ro Legacy

Actions trông giống như một hướng đi cũ (legacy) với triển vọng dài hạn không rõ ràng. Điều này làm cho chúng trở thành một công cụ tốt để khởi động nhanh, nhưng lại là một nền tảng rủi ro cho kiến trúc cuối cùng.

Sự cô lập của Custom GPT

Custom GPT hoạt động như một đoạn chat cô lập riêng biệt và không có quyền truy cập đầy đủ vào các tính năng khác của môi trường ChatGPT chính, cụ thể là Projects, Library và một phần ngữ cảnh làm việc chung. Điều này làm hạn chế giá trị của việc tích hợp vì quyền truy cập API đã có, nhưng một số điểm mạnh của bản thân chatgpt.com lại bị mất đi.

Những gì đã thực sự làm được thông qua tích hợp hiện tại

Mô hình hiện tại đã chứng minh được tính khả thi trong các kịch bản thực tế.

Thông qua GraphQL Action, chúng tôi đã có thể:

• lấy danh sách các dự án;
• thực hiện GraphQL introspection;
• lấy người dùng/tác nhân hiện tại;
• đọc người dùng để xác định người được giao việc (assignee);
• khám phá các kiểu đầu vào (input types) và enum trước khi mutation;
• tạo công việc (tasks);
• gán công việc cho người dùng hoặc tác nhân;
• tạo worklogs;
• cập nhật trạng thái công việc;
• hoàn thành công việc sau khi kiểm tra kết quả.

Trên thực tế, một chu trình end-to-end hoàn chỉnh đã được thực hiện:

phát hiện sự cố
→ tạo báo cáo lỗi (bug report)
→ kiểm tra lại API sau khi sửa
→ thêm worklog
→ chuyển trạng thái công việc sang Done

Ngoài ra, trong quá trình làm việc thực tế, các công việc đã được tạo cho:

• sửa lỗi lọc danh sách dự án ẩn;
• quản trị viên chỉnh sửa công việc, dự án và worklog của người khác;
• hiển thị người giao việc và người thực hiện trong danh sách và thẻ công việc;
• bộ nhớ dài hạn và vòng đời của tác nhân AI;
• tích hợp ChatGPT hiện tại với fi1osof.ru và haih-agent.

Một định dạng làm việc đã được thiết lập cho các công việc:

• description — tóm tắt ngắn gọn;
• content — nội dung đặt vấn đề chi tiết chính bằng Markdown.

Tương tác với haih-agent

Trong tích hợp hiện tại có hai vòng lặp khác nhau:

ChatGPT → trực tiếp qua GraphQL → fi1osof.ru

và

ChatGPT → haih-agent → vòng lặp reasoning/tools của chính nó

Giữa chúng có sự khác biệt cơ bản về kinh tế.

Nếu bản thân ChatGPT thực hiện reasoning và gọi API trực tiếp, thì không cần đến runtime LLM haih-agent bổ sung, và không có yêu cầu LLM tốn phí mới nào ở phía tác nhân.

Nếu một tác vụ được chuyển giao hoàn toàn cho haih-agent, nó có thể chạy vòng lặp reasoning/tool của riêng mình, và chi phí lại bắt đầu phụ thuộc vào mô hình và số lượng các bước.

Do đó, chatWithAgent hữu ích như một kênh kết nối với runtime của chính tác nhân, nhưng việc sử dụng nó làm con đường chung cho mọi thao tác là không có lợi về mặt kinh tế.

Kết luận kiến trúc từ kinh nghiệm thực tế

Thực tế cho thấy runtime reasoning của tác nhân và danh tính/bộ nhớ/runtime của nó không nhất thiết phải là một thành phần duy nhất.

Cùng một thực thể tác nhân trong fi1osof.ru có khả năng nhận trí thông minh từ các nguồn khác nhau:

• ChatGPT;
• runtime haih-agent của chính nó;
• một mô hình API bên ngoài;
• một mô hình nội bộ (local model).

Đồng thời, các tác vụ, kiến thức, worklog, danh tính và lịch sử có thể vẫn ở trong hệ thống chung.

Điều này mở ra cơ hội tối ưu hóa kinh tế: thực hiện công việc tương tác ở nơi mà reasoning rẻ hơn cho người dùng, và để lại công việc tự trị cho haih-agent.

Kết luận hiện tại về các cơ chế tích hợp bên trong chatgpt.com

Custom GPT + Actions

Ưu điểm:

• khởi động rất nhanh;
• hầu như không đòi hỏi thay đổi backend;
• tác nhân giúp thiết lập OpenAPI;
• phù hợp cho cả REST và GraphQL;
• reasoning nằm lại trong gói đăng ký ChatGPT;
• đã chứng minh tính khả thi trong các kịch bản đọc/ghi thực tế.

Nhược điểm:

• một cấu hình Action cho mỗi tên miền;
• giới hạn nghiêm ngặt về path;
• phải điều chỉnh hình dạng API theo các giới hạn của ChatGPT;
• Custom GPT bị cô lập khỏi môi trường ChatGPT chính;
• có rủi ro là Actions sẽ tiếp tục bị thay thế bởi các cơ chế mới hơn.

ChatGPT App / MCP

Ưu điểm tiềm năng:

• phương thức tích hợp hiện đại và chuẩn hóa hơn;
• mô hình tools/resources tự nhiên;
• tích hợp sâu hơn tiềm năng với giao diện ChatGPT;
• máy chủ MCP đã tồn tại ở phía chúng tôi.

Các vấn đề thực tế của việc triển khai ChatGPT hiện tại:

• chẩn đoán kết nối kém;
• thiếu đầu ra debug minh bạch;
• các lỗi không có đủ chi tiết kỹ thuật;
• tác nhân không hỗ trợ gỡ lỗi chính kết nối đó;
• vì là hộp đen, việc khởi động nhanh hóa ra kém hơn so với qua Actions.

Tổng kết chính của giai đoạn

Actions được chọn không phải vì đây là lựa chọn dài hạn tốt nhất, mà vì chúng cung cấp con đường ngắn nhất từ API hiện đang có đến một tích hợp hoạt động thực sự.

Sự lựa chọn này hoàn toàn đáp ứng tiêu chí khởi động nhanh: không cần đại tu backend, ChatGPT đã có thể đọc và sửa đổi dữ liệu làm việc của fi1osof.ru và tham gia vào vòng đời công việc thực tế.

Đồng thời, quá trình vận hành cho thấy Actions có những giới hạn sản phẩm nghiêm trọng, và Custom GPT quá cô lập với môi trường ChatGPT chính.

MCP tiềm năng phù hợp hơn như một hướng đi dài hạn, nhưng trải nghiệm người dùng (UX) kết nối hiện tại và việc thiếu công cụ gỡ lỗi bình thường bên trong ChatGPT tạo ra rào cản gia nhập cao.

Các quyết định kiến trúc cụ thể cho sự phát triển tiếp theo của việc tích hợp nên được ghi nhận bằng các worklog riêng sau khi thử nghiệm, thay vì được coi là đã chọn trước.