Đề xuất kiến trúc Super Session PG-native cho Hội đồng/Agent

Ngày: 2026-04-20
Agent: Incomex Hội đồng AI (GPT)
Mục tiêu: đánh giá liệu tạo collection/tables riêng kiểu “super session” lưu trực tiếp trên PG có nhanh hơn KB hiện tại hay không, và đề xuất cấu trúc tối ưu cho tương tác AI/agent nhanh nhất.

1. Kết luận ngắn

Có, nhưng chỉ đúng nếu đổi cả mô hình dữ liệu lẫn đường truy cập.

Tạo riêng một collection/tập bảng “super session” cho hội đồng chat/thảo luận sẽ nhanh hơn rõ rệt so với dùng KB document hiện tại, nếu:

dữ liệu session được lưu dưới dạng records append-only thay vì document dài/revision-heavy,
agent đọc/ghi qua collection actions trực tiếp (Directus/PG-native API hoặc MCP tools riêng cho session),
bỏ vectorization / re-index / render document khỏi hot path của chat.

Không nên kỳ vọng tăng tốc lớn nếu chỉ tạo “một document KB riêng cho mỗi phiên” rồi vẫn đọc/ghi bằng getDocument/createDocument/searchKnowledge kiểu hiện tại.

2. Căn cứ từ tài liệu cũ

2.1. Thiết kế cũ đã đi đúng hướng “record-based chat”

Tài liệu knowledge/dev/planning/comment-module/design.md mô tả CommentModule = phòng họp của máy, dùng collection task_comments với CRUD comment, filter theo tab, polling/real-time. Đây là hướng đúng cho dữ liệu hội thoại ngắn, nhiều lượt, tần suất cao.

2.2. “Super Session” cũ đã đặt mục tiêu hiệu năng kiểu chat app

operations/tasks/comments/comment-30 ghi rõ mục tiêu:

comment theo 8 tab,
full-text search,
audit rõ,
SLA comment < 500ms (mục tiêu).

Điều này xác nhận tư duy cũ không phải là “viết KB đẹp”, mà là “dòng thảo luận có UX nhanh”.

2.3. Kiến trúc hiện tại phân biệt rõ Agent Data store vs business collections

Hiến pháp knowledge/dev/laws/constitution.md nêu incomex_metadata là store kiểu document cho Agent Data (kb_documents, history, audit log, chat_messages, metadata_store...), còn directus là warehouse business collections. Vì vậy, nếu dùng KB/document store cho hội thoại nóng thì rất dễ chạm overhead không cần thiết của document lifecycle.

3. Vì sao KB hiện tại chậm hơn cho “hội thoại nóng”

KB hiện tại phù hợp cho:

luật,
báo cáo,
memo,
kế hoạch,
văn bản dài,
semantic search.

Nhưng không tối ưu cho:

nhiều message ngắn liên tiếp,
append liên tục,
lấy 50–200 tin nhắn gần nhất theo thời gian,
poll nhanh giữa nhiều agent,
unread cursor / checkpoint / turn ordering.

Nút thắt chính không nằm ở PG, mà ở kiểu dữ liệu + đường truy cập

Nếu đi theo KB document path, thường có các overhead sau:

document-centric body lớn,
revision/history,
search/rag path,
chunk/vector sync,
render/truncate/merge nội dung,
semantics “1 tài liệu = 1 blob” thay vì “1 turn = 1 row”.

Cho hội thoại đa agent, các overhead đó là thừa.

4. Trả lời trực tiếp câu hỏi: tạo collection Super Session có nhanh hơn không?

4.1. Có nhanh hơn trong 3 tình huống này

Append-only messages: mỗi message = 1 row, insert cực nhẹ.
Recent-window reads: đọc 50 tin cuối bằng index (session_id, seq_no) hoặc (session_id, created_at).
Cursor polling: agent hỏi “có message nào sau seq 128 không?” thay vì đọc lại cả document.

4.2. Không nhanh hơn mấy nếu vẫn giữ 3 thứ sau

vẫn lưu 1 phiên = 1 document text dài,
vẫn dùng searchKnowledge/RAG làm đường đọc chính,
vẫn trigger embed/index ngay trên every write của hot path.

Kết luận kỹ thuật:

Super Session nhanh hơn không phải vì “thêm collection”, mà vì chuyển từ document store pattern sang event/message log pattern.

5. Đề xuất cấu trúc mới — PG-native, tối ưu tương tác nhanh nhất

5.1. Nguyên tắc thiết kế

PG-first (HP NT13)
SSOT duy nhất cho session runtime (HP NT1)
append-only cho message log để đơn giản và nhanh
separate hot path vs cold path
- hot path = session/messages/checkpoints
- cold path = KB summary / archival / vector search
không vectorize trên hot path
snapshot + summary bất đồng bộ sau, không chặn chat

6. Mô hình dữ liệu đề xuất

A. `super_sessions`

Đại diện một phiên hội đồng/agent.

Field đề xuất:

id bigint PK
session_code text unique (SSN-20260420-001)
title text
session_kind text
- council_review
- implementation_room
- debug_room
- handoff_room
topic text
status text
- active / paused / closed / archived
context_type text
- law / task / incident / design / mixed
source_entity_type text nullable
source_entity_id text nullable
source_doc_path text nullable
owner_agent text nullable
created_by text
created_at timestamptz
last_message_at timestamptz
message_count int default 0
last_seq_no bigint default 0
priority text nullable
tags jsonb
metadata jsonb

Mục đích: bảng đầu phiên, rất nhẹ, phục vụ list/open/resume.

B. `super_session_participants`

Thành viên của phiên.

Field:

id bigint PK
session_id FK
participant_type text (agent,user,system,tool)
participant_code text (gpt,claude,gemini,chairman,mcp_router)
role_in_session text (chair,critic,executor,observer,reporter)
join_state text (active,muted,left)
joined_at timestamptz
last_seen_at timestamptz
permissions jsonb

Mục đích: không hardcode ai được nói, ai là chair/critic.

C. `super_session_messages` (bảng nóng nhất)

Mỗi lượt chat = 1 row.

Field bắt buộc:

id bigint PK
session_id FK
seq_no bigint
parent_message_id bigint nullable (nếu cần thread nhẹ)
sender_type text (agent,user,system,tool)
sender_code text
sender_role text nullable
message_kind text
- chat
- proposal
- review
- decision
- summary
- question
- answer
- warning
- tool_result
content_md text
content_text text generated/stored hoặc sync nhẹ
tab_scope text nullable (general,plan,rules,verify,reports...)
action_code text nullable
importance smallint default 0
visibility text default internal
created_at timestamptz
token_estimate int nullable
metadata jsonb

Field hỗ trợ truy vết:

source_doc_path text nullable
source_tool text nullable
citation_data jsonb nullable
reply_to_seq_no bigint nullable
dedupe_key text nullable

Index quan trọng:

unique (session_id, seq_no)
index (session_id, created_at desc)
index (session_id, sender_code, created_at desc)
index (session_id, tab_scope, created_at desc)
GIN full-text trên content_text

D. `super_session_checkpoints`

Bảng trạng thái điều hành phiên, không trộn vào message.

Field:

id bigint PK
session_id FK
checkpoint_code text
checkpoint_name text
status text (pending,active,done,blocked,dropped)
owner_code text nullable
notes text nullable
evidence_message_id bigint nullable
updated_at timestamptz

E. `super_session_links`

Liên kết phiên với luật/tài liệu/task/collection.

Field:

id bigint PK
session_id FK
link_type text (law,doc,task,collection,issue,report,artifact)
target_ref text
relation text (input,evidence,output,related,supersedes)
created_at timestamptz

F. `super_session_summaries`

Lớp lạnh hơn — tóm tắt phiên theo mốc.

Field:

id bigint PK
session_id FK
summary_type text (rolling,handoff,closing,daily_digest)
from_seq_no bigint
to_seq_no bigint
summary_md text
generated_by text
approved_by text nullable
created_at timestamptz

Mục đích: agent mới vào không phải đọc 500 message.

G. `super_session_artifacts`

File kết quả của phiên.

Field:

id bigint PK
session_id FK
artifact_type text (report,draft_law,sql,plan,patchlist)
artifact_ref text (path KB, Directus item, file path)
status text
created_at timestamptz

7. Luồng vận hành khuyến nghị

Hot path (siêu nhanh)

Agent/Claude/GPT:

appendMessage(session_id, seq_no, content...)
listMessages(session_id, after_seq_no, limit)
listOpenSessions(...)
ackCursor(session_id, agent) (nếu cần)

Warm path

full-text search trong 1 session
lấy decision messages
lấy unresolved checkpoints

Cold path

generate rolling summary
write biên bản sang KB
vectorize summary/report
update context pack / law reports

Chìa khóa: KB chỉ nhận kết luận/tóm tắt/biên bản, không nhận toàn bộ chat log nóng làm tài liệu chính.

8. Truy cập qua MCP nên thiết kế thế nào

Không nên

tái dùng createDocument/getDocument/searchKnowledge làm API chính cho super session runtime

Nên

Tạo tool/action chuyên biệt kiểu:

createSession
appendSessionMessage
listSessionMessages
listActiveSessions
updateCheckpoint
createSessionSummary
linkSessionArtifact
closeSession

Nếu cần tối ưu hơn nữa:

appendSessionMessageBatch
getSessionDelta(after_seq_no)
markRead(session_id, participant)

Điểm mấu chốt: MCP phải gọi vào bảng runtime theo access path thẳng, không đi vòng qua lớp document/RAG.

9. Hiệu năng: kỳ vọng thực tế

Nhanh hơn ở đâu

insert 1 message nhỏ nhanh hơn update 1 document dài
poll delta nhanh hơn đọc full body
query ORDER BY seq_no DESC LIMIT 50 rất rẻ
full-text trong 1 session rẻ hơn semantic search toàn KB

Không nhanh hơn ở đâu

nếu mỗi message đều bị sync ngay sang vector store
nếu mỗi thao tác vẫn phải render markdown/report/history như KB
nếu vẫn bắt agent đọc 1 “summary blob” lớn thay vì delta rows

Kỳ vọng hợp lý

Nếu làm đúng access path riêng, mục tiêu kiểu cũ comment < 500ms là thực tế hơn nhiều so với dùng KB document path.

10. Đề xuất cấu trúc triển khai tối ưu nhất

Phương án khuyến nghị: Hybrid 2 tầng

Tầng 1 — Runtime Session Store (mới)

Nằm trên PG/directus collections hoặc schema riêng trong directus
Chứa super_sessions, super_session_messages, super_session_checkpoints, super_session_links, super_session_summaries
Tối ưu cho CRUD nhanh, polling, list recent, filters

Tầng 2 — KB Archive / Knowledge Output (hiện có)

Chỉ lưu:
- session summary,
- final decisions,
- reports,
- enacted drafts,
- handoff docs.
Dùng createDocument / searchKnowledge như hiện tại cho tri thức bền vững.

Đây là phương án cân bằng nhất:

hội thoại nóng nhanh,
tri thức dài hạn vẫn vào KB,
không phá kiến trúc hiện có.

11. Khuyến nghị không nên làm

Không dùng 1 document KB cho 1 phiên chat dài.
Không embed/vectorize mỗi message nóng. Chỉ summary hoặc decision messages mới nên qua KB/vector.
Không trộn checkpoint/decision với chat text trong cùng 1 blob.
Không phụ thuộc chỉ vào semantic search để đọc lịch sử phiên; phải có ordered log chuẩn.

12. Đề xuất chốt

Trả lời trực tiếp cho câu hỏi của Chủ tịch

Có, tạo riêng collection/tables “super session” PG-native sẽ nhanh hơn đáng kể cho thảo luận Hội đồng/agent.
Nhưng tốc độ đến từ việc dùng message-log collections + MCP actions chuyên biệt, không phải chỉ vì “lưu vào PG”.
Thiết kế tốt nhất hiện nay là Hybrid:
- PG session runtime store cho tương tác nhanh,
- KB cho biên bản/tóm tắt/kết luận lâu dài.

Thứ nên làm tiếp

Chốt schema 5 bảng lõi:
- super_sessions
- super_session_participants
- super_session_messages
- super_session_checkpoints
- super_session_summaries
Tạo MCP actions riêng cho session runtime.
Chỉ sync sang KB ở mức summary/decision/handoff.
Đặt KPI:
- append message < 300–500ms
- fetch 50 tin gần nhất < 200ms
- create rolling summary bất đồng bộ < 3s

13. Liên hệ với Điều 43

Điều 43 nên đọc output đã chốt từ session summaries / decisions, không nên đọc toàn bộ chat log nóng. Như vậy context pack không bị nhiễu bởi đối thoại trung gian, chỉ hấp thụ tri thức đã qua chưng cất.

Đề xuất kiến trúc Super Session PG-native cho Hội đồng/Agent

1. Kết luận ngắn

2. Căn cứ từ tài liệu cũ

2.1. Thiết kế cũ đã đi đúng hướng “record-based chat”

2.2. “Super Session” cũ đã đặt mục tiêu hiệu năng kiểu chat app

2.3. Kiến trúc hiện tại phân biệt rõ Agent Data store vs business collections

3. Vì sao KB hiện tại chậm hơn cho “hội thoại nóng”

Nút thắt chính không nằm ở PG, mà ở kiểu dữ liệu + đường truy cập

4. Trả lời trực tiếp câu hỏi: tạo collection Super Session có nhanh hơn không?

4.1. Có nhanh hơn trong 3 tình huống này

4.2. Không nhanh hơn mấy nếu vẫn giữ 3 thứ sau

5. Đề xuất cấu trúc mới — PG-native, tối ưu tương tác nhanh nhất

5.1. Nguyên tắc thiết kế

6. Mô hình dữ liệu đề xuất

A. super_sessions

B. super_session_participants

C. super_session_messages (bảng nóng nhất)

D. super_session_checkpoints

E. super_session_links

F. super_session_summaries

G. super_session_artifacts

7. Luồng vận hành khuyến nghị

Hot path (siêu nhanh)

Warm path

Cold path

8. Truy cập qua MCP nên thiết kế thế nào

Không nên

Nên

9. Hiệu năng: kỳ vọng thực tế

Nhanh hơn ở đâu

Không nhanh hơn ở đâu

Kỳ vọng hợp lý

10. Đề xuất cấu trúc triển khai tối ưu nhất

Phương án khuyến nghị: Hybrid 2 tầng

Tầng 1 — Runtime Session Store (mới)

Tầng 2 — KB Archive / Knowledge Output (hiện có)

11. Khuyến nghị không nên làm

12. Đề xuất chốt

Trả lời trực tiếp cho câu hỏi của Chủ tịch

Thứ nên làm tiếp

13. Liên hệ với Điều 43

A. `super_sessions`

B. `super_session_participants`

C. `super_session_messages` (bảng nóng nhất)

D. `super_session_checkpoints`

E. `super_session_links`

F. `super_session_summaries`

G. `super_session_artifacts`