fi1osof.ru

Cập nhật giao diện trang web

Это странно, потому что в целом он работает, но почему-то сломался именно в ловабл-компоненте. Кидает ошибку.

```text
Runtime Error
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
```

Tìm hiểu nguyên nhân khiến Markdown bị lỗi trên server

Có rất nhiều trang cũ trong lịch sử. Chúng ta cần tìm lại trang web cũ trong kho lưu trữ và khôi phục nội dung cũ, hoặc xóa sạch chúng. Lựa chọn đầu tiên chắc chắn là ưu tiên hơn.

Cập nhật thông tin trong Yandex.Webmaster

Tính năng này đã có ở backend, chỉ cần thêm vào giao diện

Thêm tính năng tạo nhiệm vụ con

На странице задачи вывести список таймеров

Cập nhật logo và tiến hành tái định vị thương hiệu nhỏ.

Cần thêm .nullable() vào schema, vì hiện tại nếu chưa nhập gì thì khi lưu sẽ xuất hiện lỗi projectId can not be null

Sửa lỗi tạo công việc không có dự án

Cần kiểm tra kỹ hơn Google và Yandex Webmaster. Rất có thể hàng đợi chỉ đơn giản là bị tắc nghẽn bởi các trang cũ đã lâu không còn tồn tại trên trang web. Nghĩa là, chúng ta cần thông báo cho họ rằng không cần tìm kiếm các trang đó nữa, mà cần lập chỉ mục các trang mới.&#x20;

Tìm hiểu nguyên nhân trang web được lập chỉ mục kém

Hiển thị thông tin dự án trên trang công việc

Việc khởi động bộ đếm thời gian sẽ tự động chuyển tác vụ sang trạng thái Đang thực hiện

Bản nháp:



```ts
 
type FetchWithProgress = (
  input: RequestInfo | URL,
  init?: RequestInit & { onUploadProgress?: (percent: number) => void },
) => Promise<Response>

const fetchWithUploadProgress: FetchWithProgress = (input, init) => {
  const onProgress = init?.onUploadProgress

  if (typeof window === 'undefined' || !onProgress || !init?.body) {
    return fetch(input, init)
  }

  return new Promise<Response>((resolve, reject) => {
    const xhr = new XMLHttpRequest()
    xhr.open(init.method || 'POST', input.toString())

    if (init.headers) {
      const headers = init.headers as Record<string, string>
      Object.entries(headers).forEach(([key, value]) => {
        xhr.setRequestHeader(key, value)
      })
    }

    xhr.upload.onprogress = (event) => {
      if (event.lengthComputable) {
        const percent = Math.round((event.loaded / event.total) * 100)
        onProgress(percent)
      }
    }

    xhr.onload = () => {
      resolve(
        new Response(xhr.responseText, {
          status: xhr.status,
          statusText: xhr.statusText,
        }),
      )
    }

    xhr.onerror = () => reject(new Error('Network error'))
    xhr.onabort = () => reject(new DOMException('Aborted', 'AbortError'))

    if (init.signal) {
      init.signal.addEventListener('abort', () => xhr.abort())
    }

    xhr.send(init.body as XMLHttpRequestBodyInit)
  })
}


```

Thêm tiến trình tải lên vào apollo-client

Nhìn chung, tất cả các tính năng đã có sẵn từ haih-agent, chúng ta chỉ cần đưa ra giao diện và tinh chỉnh lại một chút.

Thêm Blog

Cấu hình máy chủ bộ nhớ đệm Varnish

Thêm đa ngôn ngữ

Tối ưu SEO/GEO

# Mục tiêu

Đưa việc cộng tác với AI lên một tầm cao mới: người dùng xác định **mục tiêu làm việc** bằng ngôn ngữ tự nhiên, ví dụ:

> «Tìm hiểu lý do tại sao dự án X không hoạt động»

Sau đó, tác nhân sẽ tự động thực hiện quá trình từ tìm kiếm dự án và thu thập ngữ cảnh đến kiểm tra giả thuyết và ghi lại kết quả vào fi1osof.ru.

## Kịch bản Mục tiêu

Ví dụ về quy trình làm việc mong muốn:

1. Tìm dự án theo tên hoặc ID.
2. Lấy ngữ cảnh hiện tại của dự án đó.
3. Đọc các công việc liên quan.
4. Đọc các worklog gần đây.
5. Xem các sự kiện/thay đổi gần đây của dự án.
6. Kiểm tra tính khả dụng của trang web/API/dịch vụ, nếu có.
7. Lấy dữ liệu về các lần triển khai, lỗi, nhật ký (log) và trạng thái môi trường gần nhất.
8. Đưa ra một số giả thuyết về nguyên nhân gây ra sự cố.
9. Kiểm tra những giả thuyết có thể kiểm chứng bằng các công cụ có sẵn.
10. Tạo công việc mới hoặc cập nhật công việc hiện có.
11. Ghi lại kết quả điều tra, bằng chứng, liên kết và các bước tiếp theo vào công việc.

Tóm lược:

```text
tìm dự án
→ thu thập các thay đổi gần đây
→ xem các công việc đang mở
→ đọc các worklog gần đây
→ kiểm tra tính khả dụng của trang web/API
→ xem các lỗi và bản triển khai
→ đưa ra giả thuyết
→ kiểm tra các giả thuyết khả thi
→ tạo/cập nhật công việc
→ ghi lại kết quả điều tra
```

# Những gì đã có sẵn

GraphQL API đã cung cấp các thực thể cơ bản cần thiết để bắt đầu quá trình này:

- dự án (projects);
- công việc (tasks);
- nhật ký công việc (task worklogs);
- kỹ năng (skills);
- bộ hẹn giờ/hoạt động (timers/activity);
- `executeSkill`;
- `readWebPage`;
- các truy vấn/thao tác GraphQL khác.

Điều này đã cho phép triển khai một phần chu trình tác nhân mà không cần hệ thống điều phối bên ngoài riêng biệt.

# Những gì còn thiếu

## 1. Ngữ cảnh Kỹ thuật Dự án Được Chuẩn hóa

Cần có khả năng truy xuất rõ ràng các nguồn kỹ thuật liên quan đến dự án:

- kho mã nguồn (repositories);
- các dịch vụ (services);
- môi trường production/staging/dev;
- URL công khai và nội bộ;
- điểm cuối API (API endpoints);
- các lần triển khai (deployments);
- quá trình chạy CI/CD;
- nhật ký (logs);
- lỗi (errors);
- giám sát (monitoring);
- cấu hình (configuration);
- tài liệu (documentation).

Nếu không có điều này, tác nhân có thể phân tích tốt các nhiệm vụ và lịch sử làm việc, nhưng không phải lúc nào cũng có thể xác định được nguyên nhân gốc rễ kỹ thuật của sự cố.

## 2. Mối quan hệ Rõ ràng Giữa các Thực thể

Nên có một đồ thị quan hệ có thể đọc bằng máy, ví dụ:

```text
Project
├─ Repository
├─ Service
│  ├─ Environment
│  ├─ Endpoint
│  ├─ Deployment
│  └─ LogSource
├─ Task
│  └─ TaskWorkLog
└─ Documentation
```

Điều quan trọng là tác nhân không xác định quyền sở hữu đối tượng chỉ dựa trên các tên gọi giống nhau.

## 3. Dòng Hoạt động / Lịch sử Thay đổi (Activity feed)

Cần có một cách thống nhất để trả lời câu hỏi:

> «Điều gì đã thay đổi ngay trước khi sự cố xảy ra?»

Các sự kiện hữu ích:

- thay đổi nhiệm vụ;
- worklog mới;
- bản triển khai (deployment);
- commit/release;
- thay đổi cấu hình;
- health-check thất bại;
- lỗi mới;
- thay đổi DNS/SSL;
- khởi động lại dịch vụ;
- các hành động của người dùng/tác nhân ảnh hưởng đến dự án.

Nên có một truy vấn duy nhất cho các sự kiện gần đây của dự án với bộ lọc theo thời gian và loại sự kiện.

## 4. Công cụ Kiểm tra Giả thuyết An toàn

Tác nhân cần các hành động chẩn đoán chỉ đọc (read-only) hoặc được kiểm soát, chẳng hạn như:

- HTTP health-check;
- đọc trang web;
- kiểm tra API endpoint;
- lấy HTTP status/headers/body fragment;
- tra cứu DNS (DNS lookup);
- kiểm tra chứng chỉ SSL;
- đọc nhật ký (logs);
- kiểm tra trạng thái dịch vụ;
- đọc các bản triển khai gần nhất;
- chạy kiểm tra (test);
- thực thi kỹ năng chẩn đoán.

Một phần trong số này có thể được xây dựng dựa trên `readWebPage` và `executeSkill` hiện có.

## 5. Chính sách Tự chủ

Cần xác định rõ ràng những hành động nào tác nhân có thể tự thực hiện.

### Được phép thực hiện mà không cần xác nhận thêm

- đọc dữ liệu;
- tìm kiếm dự án và các thực thể liên quan;
- thực hiện chẩn đoán chỉ đọc;
- đưa ra giả thuyết;
- đọc nhật ký và hệ thống giám sát;
- tạo worklog chẩn đoán;
- tạo công việc thông thường nếu đó là kết quả tự nhiên của cuộc điều tra;
- bổ sung kết quả chẩn đoán vào công việc.

### Chỉ thực hiện khi có lệnh rõ ràng từ người dùng

- triển khai lên production (production deploy);
- khởi động lại các dịch vụ production;
- thay đổi cấu hình production;
- xóa dữ liệu;
- thay đổi hàng loạt;
- giao dịch tài chính;
- các hành động quản trị;
- thay đổi quyền truy cập;
- bất kỳ hoạt động nào khác có khả năng gây phá huỷ.

# Kỹ năng Cấp cao (High-level Skills)

Không chỉ cần các kỹ năng cấp thấp như «lấy danh sách công việc», mà còn cần các quy trình ở cấp độ mục tiêu làm việc.

Các kỹ năng có thể có:

- `investigate_project`
- `check_project_health`
- `analyze_recent_failures`
- `summarize_project_state`
- `investigate_incident`
- `analyze_recent_changes`

Ví dụ, `investigate_project` có thể xác định một quy trình có thể lặp lại:

```text
resolve project
→ collect context
→ collect recent activity
→ inspect tasks/worklogs
→ run health checks
→ inspect deployments/errors/logs
→ produce hypotheses
→ test hypotheses
→ persist findings
```

Kỹ năng nên mô tả một **thuật toán điều tra**, các quy tắc an toàn và định dạng ghi nhận kết quả thay vì chỉ một câu trả lời cụ thể.

# Định dạng Kết quả Điều tra

Nên lưu kết quả vào `Task.content` hoặc worklog bằng định dạng Markdown.

Ví dụ về cấu trúc:

```markdown
# Kết quả điều tra

## Triệu chứng
...

## Những gì đã kiểm tra
- ...
- ...

## Quan sát
- ...

## Giả thuyết
1. ...
2. ...

## Nguyên nhân đã xác nhận
...

## Bằng chứng
- [log / URL / deployment / commit](...)

## Những việc đã làm
- ...

## Hành động tiếp theo
- [ ] ...
- [ ] ...
```

# Nguyên tắc Lưu trữ Công việc Quan trọng

Đối với các công việc trong fi1osof.ru, cần tuân thủ việc phân tách:

- `description` — mô tả ngắn gọn về bản chất của công việc, nghĩa đen là vài câu;
- `content` — toàn bộ nội dung chính, chi tiết, Markdown, liên kết, danh sách kiểm tra (checklist), ví dụ, ngữ cảnh kỹ thuật và kết quả phân tích.

Không sử dụng `description` làm trường nội dung dài chính của công việc.

# Giai đoạn Thực tế Đầu tiên

Trước khi triển khai toàn bộ quy trình làm việc, cần kiểm toán (audit) lược đồ GraphQL hiện tại và các kỹ năng có sẵn:

1. Xác định nguồn dữ liệu nào trong số các nguồn được liệt kê đã tồn tại.
2. Kiểm tra các mối quan hệ hiện có giữa `Project`, `Task`, `TaskWorkLog`, các kỹ năng và các thực thể khác.
3. Tìm các thao tác có sẵn để chẩn đoán web/API.
4. Xác định xem các mô hình deployments, logs, environments, repositories, events/activity đã có sẵn chưa.
5. Thực hiện phân tích khoảng trống (gap analysis): **những gì có thể làm ngay bây giờ / những gì còn thiếu trong API / những gì còn thiếu trong các kỹ năng**.
6. Dựa vào đó, thiết kế quy trình `investigate_project` tối thiểu.

# Tiêu chí Hoàn thành

Một nhiệm vụ được coi là đã hoàn thành khi một lệnh dạng:

> «Tìm hiểu tại sao haih.net hôm nay không hoạt động»

có thể được xử lý bởi tác nhân như một mục tiêu làm việc, thay vì một loạt lệnh GraphQL thủ công, và kết quả là tác nhân:

- tự động thu thập ngữ cảnh có liên quan;
- cho biết chính xác những gì nó đã kiểm tra;
- phân biệt rõ ràng giữa sự thật và giả thuyết;
- kiểm tra các giả thuyết khả thi;
- không thực hiện các hành động nguy hiểm mà không có sự cho phép;
- lưu tóm tắt kết quả điều tra vào fi1osof.ru.

Thiết kế và triển khai một quy trình làm việc an toàn, trong đó AI tự động thu thập ngữ cảnh dự án, kiểm tra các giả thuyết và ghi lại kết quả điều tra dựa trên một mục tiêu duy nhất.

Chế độ Tác nhân Điều tra Sự cố Dự án

# Vấn đề

Hiện tại, vai trò của những người tham gia công việc chưa được hiển thị đủ rõ ràng trong giao diện công việc. Người dùng cần có thể nắm bắt ngay lập tức:

- ai là người giao việc;
- ai chịu trách nhiệm thực hiện công việc đó.

Điều này đặc biệt quan trọng trong việc cộng tác giữa con người và các tác nhân AI, cũng như trong các nhóm mà người giao việc và người thực hiện thường khác nhau.

# Cần làm gì

Thêm hiển thị của hai vai trò riêng biệt:

- **Người tạo** — người dùng/tác nhân đã tạo hoặc giao công việc;
- **Người thực hiện** — người dùng/tác nhân được giao công việc.

# Hiển thị ở đâu

## Danh sách công việc

Mỗi dòng/thẻ trong danh sách cần hiển thị rõ:

- người tạo;
- người thực hiện.

Giao diện hiển thị phải nhỏ gọn và không làm quá tải danh sách.

## Thẻ công việc

Trong thẻ chi tiết công việc, cả hai vai trò phải được hiển thị rõ ràng và tách biệt, kèm theo các nhãn dễ hiểu.

# Cần kiểm tra

- những trường GraphQL nào đã chứa creator / author / owner / assignee;
- có sự khác biệt nào giữa người tạo thực tế của công việc và người giao việc không;
- người dùng và tác nhân AI có được hiển thị chính xác không;
- điều gì xảy ra nếu chưa gán người thực hiện;
- điều gì xảy ra nếu người tạo và người thực hiện là cùng một người dùng;
- đảm bảo các vai trò không bị gộp chung vào một trường giao diện.

# Hành vi mong đợi

Khi mở danh sách hoặc thẻ công việc, người dùng có thể hiểu ngay mà không cần thêm thao tác nào:

> ai đã giao công việc và ai chịu trách nhiệm cho công việc đó.

# Tiêu chí hoàn thành

- hiển thị cả hai vai trò trong danh sách công việc;
- hiển thị cả hai vai trò trong thẻ công việc;
- người tạo và người thực hiện được hiển thị như hai thực thể riêng biệt;
- hỗ trợ chính xác cả người dùng thông thường lẫn tác nhân AI;
- trường người thực hiện để trống được hiển thị một cách dễ hiểu, ví dụ: "Chưa phân công".

Giao diện công việc cần hiển thị rõ ràng cả người tạo và người thực hiện ở cả danh sách công việc lẫn thẻ chi tiết công việc.

Hiển thị người tạo và người thực hiện trong danh sách và thẻ công việc

# Tại sao điều này cần thiết

Phiên làm việc hiện tại cung cấp bối cảnh ngắn hạn tốt, nhưng tự nó không nên là nguồn bộ nhớ duy nhất. Sau khi khởi động phiên mới, agent phải có khả năng khôi phục trạng thái làm việc từ fi1osof.ru và tiếp tục công việc như thể đó là cùng một agent làm việc chứ không phải là một mô hình mới "từ con số không".

Mục tiêu là xây dựng bộ nhớ dài hạn bên ngoài, có thể kiểm chứng và do con người quản lý cho agent.

# Các nhu cầu cơ bản của agent

## 1. Khôi phục bối cảnh khi khởi động phiên mới

Khi bắt đầu một phiên mới, agent cần bối cảnh bootstrap tối thiểu:

- người dùng hiện tại là ai;
- bản thân agent là ai;
- các dự án đang hoạt động;
- các tác vụ đang mở và mới được sửa đổi;
- các worklog gần đây;
- các quyết định và giới hạn quan trọng;
- các skills hiện hành;
- hoạt động mới nhất;
- khi cần thiết, các ưu tiên hiện tại của người dùng hoặc dự án.

Điều quan trọng là không tải mọi thứ một cách bừa bãi. Bootstrap phải nhỏ gọn, và tri thức sâu hơn sẽ được lấy về khi cần thiết.

## 2. Phân tách các loại bộ nhớ khác nhau

Nên phân biệt rõ ràng một số cấp độ bộ nhớ:

### Bộ nhớ ngắn hạn

Đối thoại hiện tại và bối cảnh của phiên hiện tại.

### Bộ nhớ vận hành (Operational memory)

Những gì cần thiết cho công việc hiện tại:

- các dự án;
- các tác vụ;
- trạng thái;
- các worklog;
- các sự kiện gần đây;
- các điểm nghẽn (blocker) hiện tại.

### Bộ nhớ sự thật dài hạn (Long-term factual memory)

Tri thức bền vững phải duy trì qua các tác vụ và phiên làm việc riêng lẻ:

- các sự thật kiến trúc;
- đặc điểm của dự án;
- nguyên nhân đã được xác nhận của các sự cố trước đó;
- các phụ thuộc kỹ thuật quan trọng;
- các quy tắc và giới hạn bền vững.

### Bộ nhớ quyết định (Decision memory)

Lưu trữ riêng biệt các quyết định do con người hoặc nhóm đưa ra:

- quyết định cái gì;
- tại sao;
- những phương án thay thế nào đã được xem xét;
- quyết định được đưa ra khi nào;
- ai đưa ra;
- thuộc về dự án/tác vụ nào.

### Bộ nhớ quy trình (Procedural memory)

Skills, runbooks và các phương thức làm việc có thể tái tạo:

- cách điều tra sự cố dự án;
- cách kiểm tra bản phát hành (release);
- cách lập báo cáo lỗi (bug report);
- cách hoàn thành tác vụ sau khi kiểm tra;
- cách thực hiện các thao tác lặp đi lặp lại một cách an toàn.

### Kết luận của agent

Các giả thuyết và diễn giải của AI phải được lưu trữ riêng biệt với các sự thật đã được xác nhận và được đánh dấu rõ ràng là kết luận của agent.

# 3. Tích lũy tri thức trong quá trình làm việc

Vòng đời công việc không nên kết thúc chỉ bằng một câu trả lời trong chat.

Khi thực hiện công việc, agent phải có khả năng ghi lại:

- các sự thật mới;
- quan sát;
- kết quả kiểm tra;
- nguyên nhân lỗi;
- các quyết định đã đưa ra;
- liên kết hữu ích;
- kết luận;
- giới hạn;
- những bài học đáng tái sử dụng.

Đồng thời, không phải mọi tin nhắn và mọi suy luận trung gian đều phải trở thành bộ nhớ dài hạn.

Cần có cơ chế lựa chọn: **điều gì thực sự đáng nhớ trong thời gian dài**.

# 4. Hợp nhất bộ nhớ (Consolidation)

Dữ liệu thô theo thời gian cần được thu gọn thành tri thức gọn gàng hơn.

Ví dụ:

```text
10 worklog điều tra
→ nguyên nhân gốc rễ
→ quyết định được đưa ra
→ bài học hữu ích
→ skill/runbook mới nếu cần
```

Nếu không, bộ nhớ dài hạn sẽ nhanh chóng biến thành lịch sử sự kiện rất tốn kém và khó đọc lại.

Việc hợp nhất phải duy trì các liên kết đến nguồn gốc sơ cấp.

# 5. Truy vấn (Retrieval) theo mục tiêu hiện tại

Phiên mới không được đọc lại toàn bộ bộ nhớ.

Nếu người dùng hỏi về một dự án cụ thể, agent phải nhận được đồ thị con tri thức liên quan:

```text
Project
→ các tác vụ hiện tại
→ worklogs gần đây
→ các quyết định liên quan
→ các facts liên quan
→ lessons
→ skills
→ hoạt động mới nhất
```

Nghĩa là bộ nhớ phải hỗ trợ retrieval theo:

- dự án;
- tác vụ;
- người dùng/agent;
- thực thể (entity);
- chủ đề;
- khoảng thời gian;
- loại tri thức;
- mối quan hệ giữa các thực thể.

# 6. Nguồn gốc (Provenance) và độ tin cậy của tri thức

Đối với tri thức quan trọng, nên lưu trữ provenance:

- nguồn;
- tác giả;
- ngày tạo;
- ngày kiểm tra gần nhất;
- dự án liên quan;
- tác vụ/worklog liên quan;
- mức độ tin cậy;
- trạng thái tính thời sự;
- liên kết đến dữ liệu sơ cấp.

Agent không được coi mọi bản ghi được lưu là chân lý tuyệt đối.

Cần phân biệt ít nhất:

- sự thật đã được xác nhận;
- quyết định của con người;
- quan sát;
- kết luận của agent;
- giả thuyết;
- tri thức lỗi thời;
- hướng dẫn/skill hoạt động.

# 7. Cập nhật và sự lỗi thời của tri thức

Bộ nhớ phải có khả năng thay đổi.

Cần dự kiến:

- thay thế (supersede) tri thức cũ bằng tri thức mới;
- gán nhãn `outdated` / không còn актуально (thời sự);
- đánh giá lại giả thuyết sau khi có dữ liệu mới;
- lịch sử thay đổi;
- khả năng con người sửa hoặc xóa tri thức sai.

Các sự thật mâu thuẫn với nhau không được âm thầm "nhá" chung thành một.

# 8. Tiến hóa của các kỹ năng (Skills)

Quy trình làm việc thành công lặp đi lặp lại nên có cơ hội biến thành skill.

Vòng đời mong muốn:

```text
quan sát
→ hành động
→ kết quả
→ ghi nhận
→ kiểm tra
→ hợp nhất
→ tái sử dụng
→ biến kinh nghiệm lặp lại thành skill
```

Bằng cách này, agent phát triển không chỉ bằng cách tích lũy sự thật mà còn bằng cách tích lũy các quy trình.

# 9. Khả năng kiểm soát bởi con người

Bộ nhớ dài hạn không được là trạng thái ẩn của mô hình.

Người dùng phải có khả năng:

- xem những gì agent coi là tri thức;
- nhìn thấy nguồn;
- sửa bản ghi;
- đánh dấu nó là lỗi thời;
- xóa nó;
- tăng hoặc giảm độ tin cậy;
- ghim rõ ràng một quyết định là mang tính thẩm quyền (authoritative).

Điều này cực kỳ quan trọng đối với công việc cộng tác.

# 10. Các thực thể có thể có

Cần nghiên cứu xem mô hình fi1osof.ru hiện tại đã đáp ứng các nhu cầu này đến mức nào.

Có thể sử dụng các thực thể cấp độ hiện có hoặc mới:

- `Fact`;
- `Concept`;
- `Decision`;
- `Observation`;
- `Lesson`;
- `KnowledgeSpace`;
- `Skill`;
- `Task`;
- `TaskWorkLog`;
- các mối quan hệ giữa chúng.

Không nhất thiết phải tạo ra các thực thể mới nếu ngữ nghĩa cần thiết đã được mô hình hiện tại biểu diễn chính xác.

# Vòng đời mong muốn của agent

## Bắt đầu phiên

1. Xác định người dùng và agent.
2. Tải bối cảnh bootstrap tối thiểu.
3. Nhận các skills và giới hạn hiện hành.
4. Khôi phục vùng làm việc đang hoạt động.

## Thực hiện công việc

1. Nhận mục tiêu của người dùng.
2. Lấy các tri thức liên quan.
3. Kiểm tra tính thời sự của chúng ở những nơi quan trọng.
4. Thực hiện công việc.
5. Ghi lại kết quả vào các thực thể làm việc.

## Hoàn thành một giai đoạn quan trọng

1. Xác định xem có tri thức dài hạn mới nào xuất hiện không.
2. Lưu facts/decisions/observations/lessons.
3. Liên kết chúng với các nguồn sơ cấp.
4. Cập nhật tri thức hiện có thay vì tạo bản sao nếu cần.

## Hợp nhất định kỳ

1. Tìm kiếm tri thức lặp lại hoặc bị phân mảnh.
2. Thu gọn chúng thành biểu diễn gọn gàng.
3. Lưu trữ provenance.
4. Đánh dấu các bản ghi lỗi thời.
5. Tách các quy trình lặp lại thành các skills.

## Phiên tiếp theo

Một thể hiện (instance) agent mới khôi phục trạng thái từ fi1osof.ru và tiếp tục công việc, sử dụng bộ nhớ ngoài làm nguồn chân lý về kinh nghiệm trước đó.

# Những gì cần nghiên cứu

Ở giai đoạn tiếp theo, cần nghiên cứu các khả năng hiện tại của fi1osof.ru và xác định:

1. Những thực thể hiện có nào đã phù hợp cho bộ nhớ dài hạn.
2. Các `facts`, `concepts`, `knowledge spaces` và liên kết của chúng được cấu trúc như thế nào.
3. Có các mô hình nào về quyết định, người tham gia, hình chiếu (projections), xung đột và giới hạn có thể được sử dụng thay vì tạo thực thể mới không.
4. Tìm kiếm/retrieval tri thức hoạt động thế nào.
5. Các thực thể tri thức liên kết với dự án, tác vụ, người dùng và agent ra sao.
6. Cách triển khai provenance và tính thời sự.
7. Cách tổ chức bootstrap phiên mới tốt nhất.
8. Những skills nào đã tồn tại để làm việc với tri thức.
9. API hoặc mô hình dữ liệu còn thiếu những gì.

# Tiêu chí sẵn sàng của kiến trúc

Giải pháp có thể được coi là thành công nếu sau khi bắt đầu phiên mới, agent có khả năng dựa trên dữ liệu fi1osof.ru để:

- hiểu nó là ai và đang làm việc với ai;
- khôi phục bối cảnh làm việc có liên quan;
- ghi nhớ các quyết định và sự thật quan trọng từ các phiên trước;
- không nhầm lẫn giả thuyết với tri thức đã được xác nhận;
- xác định nguồn gốc của tri thức;
- nhận thấy tri thức đã lỗi thời;
- sử dụng kinh nghiệm tích lũy vào công việc mới;
- dần biến các quy trình lặp lại thành skills;
- cho phép con người hoàn toàn kiểm soát và chỉnh sửa bộ nhớ này.

Nguyên tắc cốt lõi: **bộ nhớ của agent phải là bên ngoài, có cấu trúc, có thể kiểm chứng và chỉnh sửa, và một phiên mới phải khôi phục trạng thái làm việc từ đó thay vì bắt đầu từ con số không.**

Xác định cách một AI agent nên tích lũy, kiểm tra và khôi phục tri thức giữa các phiên làm việc để không bị mất bối cảnh công việc và dần dần cải thiện các kỹ năng của mình.

Bộ nhớ dài hạn và vòng đời của AI Agent

# Ngữ cảnh

haih-agent đã có hạ tầng tác nhân của riêng mình: danh tính (identity), quyền truy cập dữ liệu, xử lý tri thức, công cụ, khả năng suy luận (reasoning) và khả năng tự động thực hiện các tác vụ.

Vấn đề không nằm ở việc thiếu các khả năng tác nhân tự thân.

Yếu tố thực tiễn chính là **chi phí gọi LLM**.

Khi haih-agent hoạt động, mỗi truy vấn gửi đến mô hình được tính phí riêng. Mô hình được sử dụng càng chất lượng, ngữ cảnh càng lớn và vòng lặp tác nhân càng dài, thì chi phí càng rõ rệt. Kết quả là người ta luôn phải tìm kiếm sự cân bằng giữa:

- chất lượng suy luận;
- số lượng các bước;
- kích thước ngữ cảnh;
- lựa chọn mô hình;
- tính tự chủ;
- chi phí thực thi.

Trong ChatGPT, với mô hình thuê bao (subscription), yếu tố này ít được cảm nhận rõ rệt hơn đáng kể: người ta có thể duy trì một đoạn hội thoại dài, suy luận nhiều, làm rõ, phân tích và thực hiện một chuỗi các hành động mà hầu như không cần suy nghĩ về giá của từng lệnh gọi LLM riêng lẻ.

# Nhu cầu cốt lõi

Cần cung cấp cho người dùng khả năng sử dụng ChatGPT như một môi trường làm việc đầy đủ để tương tác với hệ thống và tác nhân của chính họ, sao cho phần lớn công việc trí tuệ có thể được thực hiện mà không cần kiểm soát ngân sách liên tục cho từng truy vấn.

Đồng thời, việc tích hợp không được biến ChatGPT thành một thực thể riêng biệt, bị cô lập khỏi haih-agent với một bộ nhớ khác, trạng thái khác và lịch sử làm việc không liên kết.

# Các nhu cầu mà việc tích hợp cần đáp ứng

## 1. Công việc tương tác hiệu quả về mặt chi phí

Người dùng phải có khả năng, mà không sợ về chi phí:

- thảo luận kéo dài về một tác vụ;
- làm rõ đề bài;
- phân tích dữ liệu;
- phân rã các mục tiêu;
- hình thành các giả thuyết;
- so sánh các phương án;
- tiến hành các bước kiểm tra tuần tự;
- tạo và làm rõ các tác vụ;
- duy trì một đoạn hội thoại công việc dài.

Kinh tế học sử dụng không được buộc người dùng phải cắt giảm suy luận một cách nhân tạo chỉ để giảm số lượng lệnh gọi LLM.

## 2. Quyền truy cập của ChatGPT vào ngữ cảnh làm việc thực tế

ChatGPT phải có quyền truy cập vào dữ liệu của fi1osof.ru cần thiết cho hoạt động đầy đủ:

- người dùng và tác nhân;
- dự án;
- tác vụ (tasks);
- nhật ký công việc (worklogs);
- tri thức;
- kỹ năng (skills);
- các thực thể liên quan;
- trạng thái hiện tại của hệ thống.

Nếu không có điều này, ChatGPT vẫn chỉ là một bên đối thoại bên ngoài, người mà mỗi lần đều phải được thuật lại ngữ cảnh một cách thủ công.

## 3. Bảo tồn danh tính thống nhất của tác nhân

Công việc thực hiện từ ChatGPT phải được liên kết với tác nhân hiện có trong fi1osof.ru.

Cần tránh tình trạng xuất hiện hai thực thể độc lập:

- tác nhân bên trong haih-agent;
- «tác nhân khác» bên trong ChatGPT.

Các hành động, tri thức, tác vụ và kết quả công việc phải có tác giả rõ ràng và được gắn kết với danh tính tác nhân chung ở những nơi phù hợp.

## 4. Bộ nhớ làm việc chung

Kết quả của công việc trí tuệ trong ChatGPT không được bị mất đi sau khi phiên làm việc kết thúc.

Cần có khả năng lưu trữ vào fi1osof.ru:

- các tác vụ;
- nhật ký công việc (worklogs);
- các sự thật;
- các quyết định;
- các quan sát;
- các kết luận;
- các liên kết;
- các hướng dẫn hữu ích;
- kết quả điều tra.

Phiên làm việc tiếp theo phải có khả năng khôi phục ngữ cảnh có liên quan từ hệ thống chung.

## 5. Loại bỏ việc thanh toán lại cho phần suy luận đã được thực hiện

Nếu một phân tích phức tạp đã được thực hiện trong ChatGPT, haih-agent không được phép lặp lại một cách không cần thiết chính công việc trí tuệ đó từ đầu thông qua các lệnh gọi LLM riêng lẻ.

Cần có khả năng truyền tải giữa các môi trường ngữ cảnh công việc đã được chuẩn bị sẵn:

- mục tiêu;
- các sự thật đã được xác nhận;
- các vấn đề đã tìm thấy;
- giả thuyết;
- các quyết định đã được đưa ra;
- các giới hạn;
- các hành động tiếp theo cần thiết.

Điều quan trọng là phải bảo tồn giá trị của phần suy luận đã thực hiện và không trả tiền lại cho việc tái tạo hoàn toàn nó.

## 6. Khả năng sử dụng các mô hình mạnh ở nơi có lợi hơn

Chất lượng mô hình ảnh hưởng đáng kể đến chi phí làm việc của haih-agent.

Việc tích hợp phải cho phép sử dụng các khả năng trí tuệ mạnh mẽ của ChatGPT cho các tác vụ mà chất lượng suy luận đặc biệt quan trọng, mà không buộc phải liên tục chuyển toàn bộ runtime của tác nhân sang một mô hình API đắt đỏ.

Điều này đặc biệt có ý nghĩa đối với:

- phân tích phức tạp;
- các quyết định kiến trúc;
- các tác vụ không rõ ràng;
- các cuộc điều tra;
- chuỗi suy luận dài;
- làm việc với ngữ cảnh lớn;
- đặt và làm rõ tác vụ.

## 7. Bảo tồn tính tự chủ của haih-agent

Bất chấp việc sử dụng ChatGPT, haih-agent vẫn phải là một hệ thống độc lập.

Việc tích hợp không được tạo ra sự phụ thuộc mà trong đó tác nhân ngừng hoạt động khi không có ChatGPT.

Cần duy trì khả năng:

- tự động thực hiện các tác vụ;
- làm việc thông qua các mô hình API;
- sử dụng các mô hình cục bộ;
- chạy các tiến trình nền;
- thực hiện hành động mà không cần phiên người dùng ChatGPT đang hoạt động.

ChatGPT nên mở rộng các lựa chọn tương tác và giảm chi phí cho một số loại công việc nhất định, chứ không trở thành điểm tồn tại duy nhất của tác nhân.

## 8. Phân tách rõ ràng giữa chế độ tương tác và chế độ tự động

Cần xác định nhu cầu của hai chế độ khác nhau:

### Chế độ tương tác

Người dùng hiện diện trong cuộc đối thoại và tham gia tích cực vào quá trình.

Tại đây, những điểm có giá trị đặc biệt là:

- suy luận phong phú;
- làm rõ nhanh chóng;
- ngữ cảnh dài;
- công việc trí tuệ tiết kiệm về mặt kinh tế đối với người dùng.

### Chế độ tự động

Người dùng không ở trong cuộc đối thoại tích cực.

Tại đây, những điểm quan trọng là:

- runtime riêng của tác nhân;
- các tiến trình nền;
- bộ lập lịch (schedulers);
- phản ứng tự động;
- tính độc lập khỏi phiên ChatGPT.

Việc tích hợp phải tính đến cả hai chế độ và không trộn lẫn chúng một cách nhân tạo.

## 9. Giảm thiểu việc trùng lặp các vòng lặp tác nhân

ChatGPT và haih-agent có tiềm năng chồng chéo các khả năng:

- suy luận (reasoning);
- sử dụng công cụ (tool use);
- làm việc với ngữ cảnh;
- lập kế hoạch;
- gọi API bên ngoài.

Cần tránh việc thực hiện kép không cần thiết cùng một công việc bởi hai hệ thống.

Đặc biệt quan trọng là không cho phép các kịch bản kiểu như:

```text
ChatGPT phân tích toàn bộ vấn đề
→ chuyển nó cho haih-agent
→ haih-agent lại phân tích lại từ đầu toàn bộ vấn đề đó
→ chỉ sau đó mới thực hiện hành động
```

Quy trình như vậy làm xấu đi cả về chi phí lẫn tốc độ.

## 10. Bảo mật và kiểm soát hành động

ChatGPT có quyền truy cập vào hệ thống làm việc thực tế, vì vậy các giới hạn phía máy chủ và tính minh bạch của hành động phải được duy trì.

Cần có:

- định danh tác giả hành động;
- quyền truy cập;
- vết kiểm toán (audit trail);
- hoạt động chính xác dưới danh nghĩa của tác nhân hoặc người dùng;
- các giới hạn đối với các thao tác nhạy cảm;
- khả năng hiểu rõ chính xác những gì đã được thực hiện thông qua ChatGPT.

Bảo mật không được chỉ phụ thuộc vào hành vi của LLM — các quy tắc cuối cùng phải được kiểm soát bởi hệ thống.

# Kịch bản người dùng cần được đảm bảo

Người dùng phải có khả năng mở ChatGPT và làm việc đại loại như sau:

```text
«Hiển thị các dự án của tôi»
«Tạo một lỗi (bug)»
«Kiểm tra xem nó đã được sửa chưa»
«Thêm kết quả vào worklog và đóng tác vụ»
«Tìm hiểu lý do tại sao dự án không hoạt động»
```

Đồng thời, ChatGPT phải có đủ quyền truy cập vào fi1osof.ru để thực hiện công việc đó trong hệ thống thực, và kết quả phải trở thành một phần lịch sử chung của người dùng và tác nhân.

Người dùng không được yêu cầu phải chuyển dữ liệu thủ công giữa ChatGPT và haih-agent hoặc phải trả tiền lại cho cùng một phân tích thông qua mô hình API một cách không cần thiết.

# Tiêu chí giá trị chính

Việc tích hợp có ý nghĩa nếu nó cho phép đồng thời đạt được:

1. mức độ công việc trí tuệ và sự tiện lợi cao từ ChatGPT;
2. độ nhạy cảm thấp hơn đáng kể đối với chi phí của mỗi lần gọi LLM trong công việc tương tác;
3. quyền truy cập vào dữ liệu và hành động thực tế của fi1osof.ru;
4. bảo tồn bộ nhớ chung và danh tính của tác nhân;
5. tính tự chủ của haih-agent ở những nơi thực sự cần thiết;
6. không có sự suy luận lại thừa thãi giữa hai môi trường.

# Những gì CHƯA CẦN cố định như một giải pháp

Ở giai đoạn này, bài toán cần mô tả các **nhu cầu**, chứ không phải kiến trúc được chọn trước.

Chưa nên coi là bắt buộc đối với một phương án cụ thể nào đó như:

- các lệnh gọi GraphQL trực tiếp từ ChatGPT;
- việc ủy quyền hoàn toàn các yêu cầu cho haih-agent;
- một MCP proxy riêng biệt;
- một bộ điều phối (orchestrator) duy nhất;
- sơ đồ đồng bộ hóa bộ nhớ cụ thể;
- sự phân chia cụ thể các vòng lặp công cụ (tool loops).

Những giải pháp này cần được nghiên cứu và ghi lại sau này trong các worklog của tác vụ cùng với các lập luận, thử nghiệm và kết quả.

# Tiêu chí hoàn thành của đề bài

Đề bài được coi là hoàn chỉnh nếu từ đó làm rõ được:

- tại sao chỉ riêng hoạt động của haih-agent thông qua các API LLM trả phí là chưa đủ từ góc độ kinh tế;
- tại sao cần có ChatGPT như một môi trường làm việc bổ sung;
- những dữ liệu và khả năng nào cần phải có sẵn giữa các hệ thống;
- tại sao không thể làm mất bộ nhớ chung và danh tính;
- tại sao việc không thanh toán lại cho phần suy luận đã thực hiện lại quan trọng;
- tại sao haih-agent trong đó phải giữ được tính độc lập;
- những yêu cầu nào được đặt ra đối với bảo mật và kiểm soát;
- rằng các quyết định kiến trúc cụ thể sẽ được xác định riêng theo kết quả của công việc tiếp theo.

Ghi nhận các nhu cầu tích hợp ChatGPT với fi1osof.ru và haih-agent, trước hết nhằm giảm chi phí lao động trí tuệ và duy trì ngữ cảnh tác nhân (agent) đầy đủ.