Bối cảnh

Khi tích hợp ChatGPT với fi1osof.ru, một vấn đề hệ thống đã được phát hiện: ChatGPT có khả năng tạo ra lượng lớn nội dung trung gian và thực hiện một chuỗi các lệnh gọi API, nhưng nó lại thiếu một bộ nhớ làm việc có thể định địa chỉ và tái sử dụng tiện lợi để có thể tham chiếu giữa các lệnh gọi Action riêng lẻ.

Trong thực tế, điều này xuất hiện khi tạo một worklog lớn. Nội dung worklog được tạo một lần, nhưng khi thử ghi lại, nó lại phải được truyền lại toàn bộ bên trong GraphQL variables. Nếu một thao tác gặp lỗi, được thử lại hoặc được sử dụng trong ngữ cảnh khác, thì cùng một payload lớn đó lại phải được chuyển qua lại thông qua ChatGPT Action.

Vấn đề này rộng hơn các worklog. Nó áp dụng cho bất kỳ kết quả suy luận trung gian nào cần được sử dụng nhiều hơn một lần.

Nhu cầu cốt lõi

Cần có một cơ chế đa năng cho phép AI client bên ngoài lưu trữ một giá trị tùy ý dưới dạng một đối tượng độc lập có thể định địa chỉ, sau đó sử dụng liên kết đến nó trong các thao tác tiếp theo.

Khái quát:

tạo biến / artifact
→ nhận ID
→ sử dụng ID trong các hành động khác

Ví dụ:

var_abc123 = "# Markdown lớn..."

và sau đó:

tạo worklog
content = var_abc123

hoặc:

tạo task
content = var_abc123

Tại sao các GraphQL variables thông thường là chưa đủ

GraphQL variables chỉ tồn tại bên trong một yêu cầu HTTP duy nhất.

Chúng không cung cấp khả năng:

• lưu kết quả của một bước và tham chiếu đến nó ở bước tiếp theo;
• tái sử dụng văn bản lớn mà không cần truyền lại;
• định địa chỉ kết quả trung gian theo ID;
• tách biệt các giai đoạn «tạo → kiểm tra → sử dụng»;
• khôi phục đối tượng làm việc sau lỗi hoặc lần thử mới;
• truyền cùng một artifact cho nhiều thao tác.

Tại sao lịch sử trò chuyện ChatGPT hiện tại cũng không giải quyết được vấn đề

Văn bản trong lịch sử trò chuyện có sẵn cho mô hình dưới dạng ngữ cảnh, nhưng nó không phải là một đối tượng API có thể định địa chỉ hoàn chỉnh.

Bạn không thể thực hiện một cách đáng tin cậy một thao tác ở mức:

lấy chính xác đoạn Markdown được tạo ra từ hai bước trước,
và truyền nó làm content mà không cần tạo lại/tổng hợp lại

Ở cấp độ Action, giá trị đối số thực tế vẫn được yêu cầu và văn bản lớn lại rơi vào payload một lần nữa.

Lịch sử trò chuyện cũng không phải là một giao diện lập trình ổn định để lưu trữ các artifact.

Tại sao không nên giải quyết việc này bằng các thực thể miền riêng biệt

Có thể lưu văn bản trung gian dưới dạng Task, File, Fact, Draft, v.v., nhưng điều này tạo ra ngữ nghĩa dư thừa và làm ô nhiễm mô hình miền.

Trạng thái làm việc trung gian phải mang tính phổ quát và không phụ thuộc vào việc sau đó nó được dùng cho:

• worklog;
• task;
• bình luận (comment);
• GraphQL mutation;
• truyền cho agent khác;
• cấu hình JSON;
• danh sách ID;
• kết quả truy vấn;
• Markdown lớn;
• phân tích tạm thời.

Trừu tượng hóa được đề xuất

Điều quan trọng là không gắn chặt với từ «tệp» (file). Cần có một artifact / variable / workspace value bền vững có thể định địa chỉ.

Mô hình tối thiểu có thể trông như sau:

id
name?
type
value
scope
createdBy
createdAt
expiresAt?

Đối với giai đoạn đầu, các kiểu dữ liệu sau là đủ:

string
json

Trong tương lai, nếu cần, có thể thêm binary/file/reference và các tùy chọn khác.

Thời gian sống (Lifespan)

Nên phân biệt ít nhất hai chế độ.

Session / temporary

Dành cho trạng thái làm việc ngắn hạn:

• kết quả trung gian;
• văn bản lớn;
• kết quả truy vấn;
• các payload đã chuẩn bị.

Có thể tự động xóa thông qua TTL.

Persistent

Dành cho các artifact cần được sử dụng giữa các phiên hoặc lưu trữ lâu dài như một đối tượng làm việc.

Mô hình sử dụng có thể có

Bước 1. Lưu giá trị

createVariable(
  name: "integration_worklog",
  value: "# Trải nghiệm tích hợp thực tế...",
  type: "string"
)

Phản hồi:

var_abc123

Bước 2. Sử dụng giá trị

Phương án A — trường chuyên dụng:

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

Phương án B — tham chiếu phổ quát bên trong đối số:

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

Trước khi gọi domain resolver, lớp trung gian sẽ giải quyết $var thành giá trị thực tế.

Cách triển khai việc phân giải (resolution) cụ thể như thế nào là một vấn đề kiến trúc riêng. Trong tác vụ này, nhu cầu cốt lõi và tính phổ quát của cơ chế mới là quan trọng hơn.

Lợi ích mang lại cho các AI client bên ngoài

1. Tái sử dụng kết quả lớn

Markdown hoặc JSON lớn được truyền một lần, sau đó được sử dụng thông qua ID ngắn gọn.

2. Quy trình làm việc đa bước chuẩn mực

Có khả năng tách biệt quy trình:

tạo ra
→ lưu lại
→ kiểm tra
→ chỉnh sửa nếu cần
→ sử dụng
→ tái sử dụng

3. Khả năng chống chịu lỗi

Nếu mutation cuối cùng gặp lỗi, không cần phải tạo lại hoặc truyền lại toàn bộ nội dung ban đầu. Có thể thử lại hành động với cùng một variable ID.

4. Tiết kiệm ngữ cảnh và payload

Giảm lượng dữ liệu phải truyền lại giữa ChatGPT và backend.

Điều này đặc biệt quan trọng đối với các mục dài:

• worklogs;
• mô tả task;
• báo cáo;
• kết quả nghiên cứu;
• cấu hình JSON;
• danh sách thực thể.

5. Tính phổ quát

Một cơ chế duy nhất hoạt động cho nhiều AI client và nhiều thao tác khác nhau, không chỉ riêng ChatGPT hay worklogs.

Nó có thể được sử dụng bởi:

• ChatGPT Actions;
• ChatGPT App / MCP;
• haih-agent;
• các agent bên ngoài khác;
• IDE agents;
• các mô hình cục bộ (local models).

Thuộc tính kiến trúc quan trọng

Cơ chế này trên thực tế sẽ trở thành workspace/runtime state cho external reasoning runtime.

Agent bên ngoài suy nghĩ và tạo ra các kết quả trung gian, trong khi fi1osof.ru/haih-agent cung cấp cho nó bộ nhớ hoạt động có thể định địa chỉ, tồn tại độc lập với lệnh gọi LLM cụ thể.

Điều này đặc biệt quan trọng đối với kiến trúc nơi một danh tính agent duy nhất có thể sử dụng các cognitive runtime khác nhau.

Những điểm cần cân nhắc

• API tạo, đọc, cập nhật và xóa biến;
• owner/createdBy;
• scope và quyền truy cập;
• TTL và tự động dọn dẹp các giá trị tạm thời;
• giới hạn kích thước;
• kiểu dữ liệu string/json;
• phân giải biến an toàn (secure variable resolution);
• bảo vệ chống tham chiếu đệ quy;
• audit trail;
• khả năng sử dụng biến làm đối số trong các mutation khác nhau;
• hành vi khi biến bị xóa hoặc hết hạn;
• có cần hỗ trợ versioning hay không;
• có cần phân biệt private/session/agent/project scope hay không.

Tiêu chí hoàn thành

Một AI client bên ngoài phải có khả năng thực hiện kịch bản sau:

1. Tạo một Markdown lớn.
2. Lưu nó một lần dưới dạng giá trị có thể định địa chỉ.
3. Nhận được một ID ngắn gọn.
4. Thực hiện một số thao tác API độc lập, chỉ truyền ID này.
5. Thử lại thao tác bị lỗi mà không cần truyền lại Markdown gốc.

Đồng thời, cơ chế này không được gắn chặt với một thực thể cụ thể như TaskWorkLog mà phải phù hợp như một bộ nhớ làm việc đa năng cho các agentic workflow.