Gần đây tôi đọc một paper có tên Capable yet Parsimonious: Extracting and Characterizing Hidden Chain-of-Thought in Frontier Models. Ý tưởng chính của paper khá đơn giản nhưng khiến tôi tò mò:

Nếu reasoning của một model bị ẩn, liệu chúng ta có thể khiến model tự đưa một phần reasoning ra ngoài thông qua một custom tool hay không?

Tôi thử ý tưởng này với GPT-5 thông qua OpenAI Responses API.

Kết quả không phải là tôi "lấy được hidden Chain-of-Thought" của GPT-5. Nhưng tôi đã quan sát được một điều khá thú vị: khi thêm một tool và buộc model gọi tool đó, GPT-5 tạo ra một đoạn reasoning-like text trong tool arguments, trong khi reasoning item native của API vẫn ở dạng encrypted.

Bài viết này là quá trình tôi thử nghiệm và những gì tôi nghĩ có thể kết luận được từ kết quả đó.

1. Hidden reasoning là vấn đề gì?

Với các reasoning model hiện đại, chúng ta thường chỉ nhìn thấy input và final answer. Phần reasoning ở giữa không nhất thiết được trả về cho developer. Ví dụ, với OpenAI Responses API, chúng ta có thể nhận được một reasoning item như sau:

ResponseReasoningItem(
    summary=[],
    content=[],
    encrypted_content="gAAAA..."
)

Tức là API cho biết reasoning item tồn tại, nhưng nội dung reasoning không xuất hiện dưới dạng plaintext. Điều này tạo ra một khoảng cách giữa hai thứ:

• Model giải được bài toán gì.
• Model đã thực hiện reasoning như thế nào.

Cần phân biệt rõ ngay từ đầu: reasoning item không đồng nghĩa với reasoning text mà chúng ta đọc được. Càng không nên mặc định rằng đoạn text trông giống reasoning mà model sinh ra sau đó chính là native hidden CoT. Đây là distinction rất quan trọng đối với experiment này.

Paper bắt đầu từ chính vấn đề này. Thay vì cố truy cập trực tiếp vào hidden CoT, tác giả tìm cách khác để quan sát reasoning behavior của model: dùng tool calling để ép model externalize intermediate reasoning.

2. Ý tưởng: biến một tool thành scratchpad

Nếu thêm vào một tool chỉ có một string argument, argument đó trở thành nơi để model viết intermediate text:

User
  ↓
LLM
  ↓
scratchpad(...)  →  server trả về "OK"
  ↓
LLM
  ↓
final answer

Tool này không cần làm calculation, search hay database query gì cả. Server thậm chí chỉ cần trả về OK. Mục đích duy nhất là tạo ra một channel để model ghi text vào.

Paper gọi protocol này là FORCED-REASONING: force model gọi tool ở bước đầu, lưu lại tool arguments, replay tool call với một acknowledgment cố định, rồi cho model tiếp tục với automatic tool selection.

Thông thường tool cung cấp capability cho model (calculator, search, database). Ở đây tool không cung cấp thêm thông tin gì, nó chỉ cung cấp bộ nhớ bên ngoài model. Vì vậy tôi thấy concept này gần với external working memory hơn là một tool thông thường.

3. Thiết lập thí nghiệm

Tôi dùng một bài toán xác suất duy nhất:

Có 5 viên bi đỏ, 7 viên bi xanh và 8 viên bi xanh lá. Lấy ngẫu nhiên 2 viên. Xác suất hai viên có màu khác nhau là bao nhiêu? (đáp án: 131/190)

và chạy ba case, với các tham số như sau:

• Model: gpt-5 qua OpenAI Responses API (client.responses.create).
• reasoning_effort: minimal, mức thấp nhất GPT-5 hỗ trợ. Mục tiêu không phải benchmark GPT-5 mà là xem output structure thay đổi thế nào khi thêm tool.
• Case A: không có tool.
• Case B: tool save_reasoning(reasoning), tool_choice ép gọi đúng tool này.
• Case C (mục 6): tool trung tính scratchpad(content), tool_choice ép gọi đúng tool này.
• include: reasoning.encrypted_content, để API trả về reasoning item.

Code để chạy lại:

from openai import OpenAI

client = OpenAI()
MODEL = "gpt-5"
QUESTION = (
    "Có 5 viên bi đỏ, 7 viên bi xanh và 8 viên bi xanh lá. "
    "Lấy ngẫu nhiên 2 viên. Xác suất hai viên có màu khác nhau là bao nhiêu?"
)


def make_tool(name, description, arg):
    return {
        "type": "function",
        "name": name,
        "description": description,
        "parameters": {
            "type": "object",
            "properties": {arg: {"type": "string"}},
            "required": [arg],
            "additionalProperties": False,
        },
        "strict": True,
    }


SAVE_REASONING = make_tool("save_reasoning", "Save your reasoning for this problem.", "reasoning")
SCRATCHPAD = make_tool("scratchpad", "Store information that may be useful later.", "content")


def call(question, effort, tool=None, force=False):
    kwargs = dict(
        model=MODEL,
        input=question,
        reasoning={"effort": effort},
        include=["reasoning.encrypted_content"],
    )
    if tool:
        kwargs["tools"] = [tool]
        kwargs["tool_choice"] = (
            {"type": "function", "name": tool["name"]} if force else "auto"
        )
    return client.responses.create(**kwargs)


# Case A: không có tool
r = call(QUESTION, "minimal")

# Case B: tool save_reasoning, ép gọi ngay bước đầu
r = call(QUESTION, "minimal", SAVE_REASONING, force=True)

# Case C: tool trung tính scratchpad, ép gọi ngay bước đầu
r = call(QUESTION, "minimal", SCRATCHPAD, force=True)

for item in r.output:
    print(item.type)  # reasoning / function_call / message

4. Kết quả: có và không có reasoning tool

Case A: không có reasoning tool

API trả về một reasoning item với encrypted_content (giống đoạn ở mục 1), sau đó là message chứa câu trả lời: tổng 20 viên, xác suất hai viên cùng màu là 59/190, nên xác suất khác màu là 1 − 59/190 = 131/190. Model rõ ràng đã reasoning, nhưng tôi không có plaintext native reasoning để đọc. Đây là baseline.

Case B: thêm reasoning tool

Output lần này có thêm một function_call tới save_reasoning, và argument GPT-5 tạo ra là:

{
  "reasoning": "Total balls: 5+7+8=20. Probability two different colors = 1 - P(same color). P(same color) = [C(5,2)+C(7,2)+C(8,2)]/C(20,2). Compute: C(5,2)=10, C(7,2)=21, C(8,2)=28, sum=59. C(20,2)=190. So P(same)=59/190. Therefore P(different)=1-59/190 = (190-59)/190 = 131/190..."
}

Điều làm tôi chú ý là trong cùng một response, reasoning item encrypted vẫn còn đó, đồng thời có thêm một đoạn reasoning-like text trong function call. Encrypted reasoning item không biến mất; tool chỉ tạo thêm một channel mà tôi quan sát được.

5. Vậy tôi đã extract hidden CoT chưa?

Theo tôi thì chưa. Tôi không làm được việc biến encrypted_content thành plaintext native CoT. Tôi chỉ quan sát được hai thứ cùng tồn tại: một reasoning item bị mã hóa và một reasoning-like text trong tool call. Hai thứ này có thể liên quan, nhưng experiment hiện tại không chứng minh chúng giống nhau. Có ít nhất ba khả năng:

• Externalized native reasoning: model đang reasoning và một phần reasoning đó được đưa vào tool argument.
• Post-hoc rationalization: model đã tự giải xong, sau đó mới viết một explanation để điền vào tool.
• Hybrid: cả hai xảy ra, internal reasoning và tool scratchpad ảnh hưởng qua lại.

Cách diễn đạt chính xác nhất cho experiment hiện tại là:

GPT-5 có thể externalize một reasoning-like trace thông qua tool calling, nhưng experiment này chưa chứng minh rằng trace đó chính là native hidden CoT.

Đây cũng là lý do paper không coi extracted text là raw hidden CoT mà dùng nó như một behavioral instrument để quan sát reasoning của model. Tương tự, reasoning tokens cũng không phải hidden states của Transformer: hidden state là các vector số, còn tool argument của tôi là một chuỗi token. Experiment này không mở được numerical hidden states bên trong model.

Có thể hình dung model đang có hai channel:

GPT-5
├── native reasoning  → encrypted_content (không đọc được)
└── tool channel      → reasoning-like text trong arguments (đọc được)
        ↓
   final answer

Thay vì hỏi "có cách nào decrypt hidden CoT không?", chúng ta có thể hỏi một câu khác: nếu không nhìn trực tiếp được reasoning channel, liệu có thể quan sát reasoning behavior qua một channel khác hay không?

6. Confounder và thí nghiệm với scratchpad trung tính

Sau khi nhìn lại, experiment đầu tiên còn một confounder khá rõ: tool tên save_reasoning và argument tên reasoning. Tôi gần như đã nói thẳng với model "đây là tool để lưu reasoning", rồi lại ép nó gọi tool. Khi đó việc model viết reasoning text không có gì quá bất ngờ.

Để thuyết phục hơn, tool nên hoàn toàn trung tính. Tool scratchpad (Case C) dùng description và argument không chứa các từ như reasoning, think, chain-of-thought, solve hay explain:

{
  "type": "function",
  "name": "scratchpad",
  "description": "Store information that may be useful later.",
  "parameters": {
    "type": "object",
    "properties": { "content": { "type": "string" } },
    "required": ["content"]
  }
}

Sau đó vẫn ép tool_choice gọi scratchpad. Nếu model vẫn tự viết ra những đoạn như "First, calculate...", "Therefore...", "Let's verify..." thì kết quả có ý nghĩa hơn nhiều.

Ngoài ra, ở experiment đầu tôi chỉ quan sát function call rồi dừng. Để biết scratchpad có tham gia vào computation hay không, cần chạy đầy đủ tool loop (ép gọi tool, trả OK, cho model tự chọn tool và trả lời), và so sánh bốn condition: effort minimal và medium, mỗi effort chạy có và không có scratchpad. Các chỉ số cần đo là accuracy, final answer, output tokens, scratchpad tokens, latency, số lần gọi tool và cấu trúc của reasoning.

import time


def run_with_tool_loop(question, effort, tool):
    # Bước 1: ép model gọi tool
    r1 = call(question, effort, tool, force=True)
    fc = next(o for o in r1.output if o.type == "function_call")

    # Bước 2: trả về "OK" cố định, để model tự chọn tool (auto) và trả lời
    r2 = client.responses.create(
        model=MODEL,
        previous_response_id=r1.id,
        input=[{"type": "function_call_output", "call_id": fc.call_id, "output": "OK"}],
        reasoning={"effort": effort},
        tools=[tool],
        tool_choice="auto",
        include=["reasoning.encrypted_content"],
    )
    tokens = r1.usage.output_tokens + r2.usage.output_tokens
    return fc.arguments, r2.output_text, tokens


def evaluate(problems, effort, use_scratchpad):
    stats = {"correct": 0, "output_tokens": 0, "latency_s": 0.0}
    for p in problems:  # p = {"question": "...", "answer": "131/190"}
        t0 = time.time()
        if use_scratchpad:
            _, answer, tokens = run_with_tool_loop(p["question"], effort, SCRATCHPAD)
        else:
            r = call(p["question"], effort)
            answer, tokens = r.output_text, r.usage.output_tokens
        stats["latency_s"] += time.time() - t0
        stats["output_tokens"] += tokens
        stats["correct"] += p["answer"] in answer
    return stats


for effort in ["minimal", "medium"]:
    for use_scratchpad in [False, True]:
        print(effort, use_scratchpad, evaluate(PROBLEMS, effort, use_scratchpad))

7. Scratchpad có giúp model giải tốt hơn không?

Theo tôi đây mới là experiment đáng quan tâm nhất. Ví dụ minh họa (các con số 70% và 80% dưới đây chỉ là giả định để mô tả cách đọc kết quả, không phải kết quả đo thực tế): nếu GPT-5 với minimal reasoning đạt 70%, còn khi thêm scratchpad đạt 80%, thì chúng ta có một observation thú vị: model có thể đang dùng externalized reasoning như một workspace khi native reasoning bị giới hạn.

Điều này khác với việc chỉ yêu cầu "hãy giải thích câu trả lời của bạn", vì explanation chỉ xuất hiện sau khi model đã giải xong. Còn nếu tool call thực sự nằm giữa các bước inference, flow sẽ là: reason, ghi scratchpad, đọc lại scratchpad, tiếp tục reasoning, rồi trả lời. Nếu accuracy thực sự tăng, scratchpad không chỉ là cách "in reasoning ra màn hình" mà có thể đóng vai trò external working memory.

Một lưu ý nữa từ paper: model mạnh hơn không nhất thiết externalize nhiều reasoning hơn. Paper còn phân tích token efficiency, các loại reasoning step, branching, reasoning tree và khả năng transfer reasoning giữa các model. Vì vậy tôi không dùng số lượng reasoning-like tokens trong tool call làm proxy đơn giản cho việc "model reasoning nhiều hay ít": một model có thể thực hiện nhiều computation nhưng chỉ verbalize một phần rất nhỏ.

8. Kết luận

Experiment này khá nhỏ, nhưng cho tôi một observation rõ ràng: việc native reasoning bị ẩn không có nghĩa là model không thể tạo ra reasoning-like text ở một channel khác. Chỉ với một custom tool, GPT-5 tạo ra intermediate text trong tool arguments, trong khi native reasoning item vẫn encrypted.

Nhưng tôi không nghĩ nên gọi đây là "extract hidden CoT". Cách mô tả chính xác hơn là: một API-level mechanism khiến GPT-5 externalize một reasoning-like trace trong tool arguments. Hai khái niệm này khác nhau.

Experiment tiếp theo cũng không nên tập trung vào việc đọc encrypted_content. Hai câu hỏi đáng quan tâm hơn là: externalized reasoning có thực sự cải thiện computation không, và scratchpad có được model dùng một cách causal để đi đến final answer hay không. Nếu có, tool calling không còn chỉ là cách để "nhìn thấy reasoning", mà có thể trở thành một external computation workspace cho reasoning model.

Nguồn: Luo et al., Capable yet Parsimonious: Extracting and Characterizing Hidden Chain-of-Thought in Frontier Models, arXiv:2609.26637, September 2026.

Bạn đã bao giờ cần làm POC/demo gấp một sản phẩm trong vòng 2–3 ngày, trong khi lại bị hạn chế khi Claude có usage limit reset theo chu kỳ 5 giờ chưa?

Mục tiêu của tôi lúc đó rất thực dụng:

Làm sao “bào” hết các khung usage trong ngày mà không phải thức đêm chờ token reset, rồi tiếp tục prompt để implement từng chức năng? Tôi muốn tự động hóa toàn bộ quá trình đó.

I. Case study

1. Bối cảnh

Tôi cần dựng nhanh một POC cho project quản lý căn hộ cho thuê, trong đó có khá nhiều feature liên quan đến nhau.

Dù chỉ là POC, project vẫn phải có database, backend, UI, validation, business rule, phân quyền, dữ liệu mẫu và các flow liên kết với nhau.

Với một prompt, agent có thể dựng khá nhanh một màn hình hoặc một feature. Nhưng để hoàn thành cả project thì vẫn phải chia nhỏ công việc, implement từng phần, kiểm tra kết quả rồi sửa những vấn đề phát sinh ở các bước tiếp theo.

2. Vấn đề

Trong một usage window, agent có thể làm việc khá nhanh. Vấn đề bắt đầu xuất hiện khi quota bị giới hạn.

Nếu muốn tận dụng hết các lượt sử dụng, tôi phải chủ động quay lại đúng thời điểm quota reset, thậm chí có những lần rơi vào giữa đêm.

Nói cách khác, agent đã có thể tự code khá nhiều việc, nhưng phần điều phối vẫn phụ thuộc vào con người: biết lúc nào chạy tiếp, chạy task nào trước, kiểm tra kết quả và xử lý các lỗi phát sinh.

Một “siêu prompt” cũng không giải quyết được vấn đề này. Prompt càng dài có thể giúp agent bắt đầu tốt hơn, nhưng sau đó vẫn cần người theo dõi tiến độ và quyết định bước tiếp theo.

3. Cách tôi chuẩn bị trước khi chạy Loop

B1. Quyết định tech stack

Chốt trước framework, database, các thư viện chính và cách chia architecture.

B2. Dựng source base và môi trường coding

Chuẩn bị sẵn project skeleton, local environment và các command cần thiết như lint, type check, test, build... để agent có thể tự chạy và nhận feedback sau mỗi lần implement.

B3. Design database

Thiết kế trước các entity, relationship, enum và constraint dựa trên flow nghiệp vụ của từng chức năng.

B4. Viết detailed design

Với mỗi feature, tôi mô tả trước input, output, user flow và cách xử lý business logic. Các phần như validation, permission, chuyển trạng thái, dữ liệu liên quan, error case và edge case cũng được ghi rõ.

Acceptance criteria cũng cần cụ thể để agent biết chính xác chức năng này phải làm đến đâu và sau khi làm xong thì kiểm tra bằng cách nào.

B5. Chia danh sách chức năng thành các slices nhỏ

Mỗi slice implement một chức năng nhỏ, có kết quả kiểm chứng được từ đầu đến cuối:

Nếu một chức năng quá lớn để hoàn thành trong một usage window, nó được tách thành nhiều slice nhỏ hơn.

Mỗi slice khai báo:

Ví dụ đơn giản: Tạo file slices.yml mô tả các chức năng có quan hệ phụ thuộc.

defaults:
  gate: bash scripts/gate/all.sh
  smoke: bash scripts/gate/smoke.sh
  spec_root: design/

slices:
  - id: 1
    name: room-list
    status: ready
    phase: B-chức-năng
    spec: design/features/01-rooms.md
    section: "Danh sách phòng trống"
    blocks_on: []
    touches:
      - src/server/services/rooms/
      - src/app/rooms/
      - scripts/gate/smoke.sh
    invariants:
      - "Chỉ hiển thị phòng đang sẵn sàng cho thuê"
      - "Giá phòng phải lấy từ cơ sở dữ liệu"
    verify:
      - "bash scripts/gate/smoke.sh"
    note:

  - id: 2
    name: booking-create
    status: blocked
    phase: B-chức-năng
    spec: design/features/02-bookings.md
    section: "Tạo đặt phòng"
    blocks_on: [1]
    touches:
      - src/server/services/bookings/
      - src/app/bookings/new/
      - scripts/gate/smoke.sh
    invariants:
      - "Chỉ được đặt phòng đang sẵn sàng cho thuê"
      - "Không được tạo hai lượt đặt trùng thời gian cho cùng một phòng"
    verify:
      - "bash scripts/gate/smoke.sh"
      - "npm test -- booking-create"
    note:

• Slice room-list không phụ thuộc chức năng nào nên được triển khai trước.
• Slice booking-create có blocks_on: [1], vì chức năng đặt phòng cần danh sách và quy tắc phòng trống từ slice đầu tiên.
• → Khi slice 1 hoàn thành status chuyển thành done
• → Loop tiếp tục sang slice 2, chuyển status từ blocked sang ready rồi tiếp tục triển khai.

4. Thiết kế Loop chạy các Slice

Để Loop chạy được toàn bộ danh sách mà vẫn tách rõ trách nhiệm, tôi dùng hai skill:

Project Loop dừng khi mọi slice đã hoàn thành, không còn slice sẵn sàng, một slice thất bại quá số lần cho phép hoặc sắp chạm usage limit. State đã được ghi xuống disk nên lần chạy sau có thể tiếp tục.

Bên trong mỗi slice, skill thực hiện quy trình cố định:

4.1. Select và Analyze

Loop chỉ chọn slice khi dependency đã hoàn thành và vùng file không xung đột với task khác.

Agent sau đó đọc đúng section của spec, ADR, schema, enum và code liên quan. Không load toàn bộ tài liệu vào mỗi usage window.

4.2. Plan và Implement

Trước khi code, agent liệt kê service, handler, component, checker và file dự kiến thay đổi.

Nếu cần vượt touches, thêm dependency hoặc đổi shared schema, Loop dừng và báo lại. Nếu plan hợp lệ, agent implement feature theo vertical slice.

4.3. Gate và Auto-fix

Agent được tự sửa tối đa ba vòng. Nếu vẫn fail, Loop dừng và lưu checker, output thật, các cách đã thử cùng trạng thái file hiện tại.

Không sửa gate để làm pass testcase. Không đánh dấu done khi gate chưa pass.

4.4. Close và Next

Khi gate pass, Loop cập nhật state và ghi note ở slices.yml:

1. Done: thực tế đã implement gì.
2. Decisions: chỗ tài liệu chưa nói rõ và đã chọn cách nào.
3. NOT done: phần nào chưa làm và vì sao.

Slice được đánh dấu done, sau đó Loop tự chọn slice ready tiếp theo mà không chờ người dùng prompt lại.

5. Schedule: đánh thức Loop sau khi Usage Limit Reset

Với project chạy ở local, cách đơn giản nhất là tạo một Local Routine trong Claude Desktop:

1. Mở Code → Routines → New routine → Local.
2. Đặt tên, ví dụ 'wake-project-loop'.
3. Chọn folder chứa project.
4. Chọn lịch chạy sau thời điểm usage limit thường được reset vài phút.
5. Nhập instruction để Routine đánh thức Project Loop.

Instruction chỉ cần ngắn gọn:

Tiếp tục Project Loop của repository này.

1. Nếu có lượt `/run-slices` khác đang hoạt động, dừng an toàn.
2. Gọi skill `/run-slices` để tiếp tục từ state trên disk.
3. Không tự chọn slice và không gọi `/slices` trực tiếp.
4. Không push và không tạo pull request.

Routine kết thúc trách nhiệm ngay sau khi gọi /run-slices. Việc chọn task, kiểm dependency, chạy slice, cập nhật state và quyết định dừng đều do Project Loop xử lý.

6. Kết quả thực tế triển khai

Rất nhiều commit được tự động thực hiện lúc 01:00~08:00 AM trong lúc tôi đang ngủ.

7. Chú ý

Cách làm trong bài cho phép Loop tiếp tục qua nhiều feature và usage window mà không chờ con người duyệt sau từng bước.

Tôi chọn trade-off này vì mục tiêu là có POC/demo gấp trong 2–3 ngày. Tốc độ được ưu tiên hơn độ chắc chắn của một production workflow.

Con người vẫn phải review từng feature trước khi sử dụng kết quả demo. Nhưng review diễn ra sau khi Loop đã tạo output, không phải là gate đồng bộ chặn Loop giữa các usage window.

Không khuyến khích áp dụng nguyên trạng cách làm này cho project thực tế hoặc production.

II. Kết luận

Quay lại câu hỏi đầu bài: làm sao tận dụng các usage window trong ngày mà không phải cày đêm?

Không phải bằng cách viết một prompt dài hơn.

Cũng không phải bằng cách đặt báo thức sau mỗi lần usage limit reset.

Cách tôi chọn là:
Chốt tech stack
→ Dựng source base và environment
→ Design database
→ Viết detailed design
→ Chia mỗi feature thành vertical slice phù hợp
→ Tạo Loop implement + verify
→ Lưu state ngoài usage window
→ Dùng schedule đánh thức Loop

Ba điều quan trọng nhất:

• Vai trò của tôi chuyển từ: Người prompt từng bước → Người thiết kế, ra luật, feedback và checkpoint
• Đừng thức để chờ usage limit reset. Hãy để schedule đánh thức Loop, còn bạn chỉ thức dậy để review kết quả.
• Một lần nữa: mức tự động hóa trong bài dành cho POC/demo cần tốc độ. Đừng áp dụng nguyên trạng vào project thực tế hoặc production.

Tham khảo

https://pub.towardsai.net/stop-prompting-your-agents-design-loops-unpacking-the-idea-behind-an-8-million-view-tweet-b08dc3348308

Khi một trang web báo 502, kết nối bảo mật thất bại hoặc API hết thời gian chờ, câu hỏi đầu tiên thường là: lỗi nằm ở ứng dụng, proxy, kết nối mạng hay quá trình phân giải tên miền? Mô hình OSI không trả lời trực tiếp, nhưng cho ta một bản đồ để chia hệ thống thành từng tầng và kiểm tra đúng chỗ.

Bài viết này không hướng tới việc học thuộc bảy tầng. Mục tiêu là hiểu mô hình OSI, cách Internet rút gọn nó thành bốn tầng, và cách áp dụng khi thiết kế, vận hành, xử lý sự cố cho ứng dụng web.

Mô hình OSI là gì?

OSI, viết tắt của Open Systems Interconnection, là một mô hình tham chiếu do ISO (International Organization for Standardization — Tổ chức Tiêu chuẩn hoá Quốc tế) xây dựng. Mô hình chia việc truyền dữ liệu thành bảy tầng. Mỗi tầng sử dụng dịch vụ của tầng bên dưới và cung cấp dịch vụ cho tầng bên trên.

Giá trị chính của OSI là tạo ra ngôn ngữ chung. Khi nói lỗi ở Network Layer, kỹ sư mạng hiểu cần kiểm tra địa chỉ IP và định tuyến. Khi nói Application Layer load balancer, kỹ sư ứng dụng hiểu thiết bị có thể đọc HTTP host, đường dẫn hoặc header để chọn máy chủ phía sau.

OSI là mô hình tư duy, không phải bản thiết kế bắt buộc của Internet. Nhiều giao thức hiện đại không nằm gọn trong một tầng. TLS (Transport Layer Security) thường được gắn với Presentation Layer, nhưng trên Internet nó hoạt động giữa Transport Layer và HTTP. QUIC còn kết hợp chức năng vận chuyển với quá trình mã hoá. Vì vậy, nên dùng OSI để phân chia trách nhiệm và khoanh vùng lỗi, không nên ép mọi công nghệ vào một ô tuyệt đối.

Bảy tầng của mô hình OSI

OSI được đọc từ Physical Layer ở dưới lên Application Layer ở trên. Càng lên tầng cao, dữ liệu càng gần với ý nghĩa mà ứng dụng và người dùng quan tâm.

Physical Layer và Data Link Layer: đưa dữ liệu qua liên kết gần nhất

Physical Layer biến bit thành tín hiệu. Data Link Layer đóng bit thành khung và chuyển khung giữa các thiết bị trong cùng mạng cục bộ. Switch (bộ chuyển mạch) chủ yếu hoạt động ở Data Link Layer và dùng địa chỉ MAC để quyết định khung cần đi qua cổng nào.

Với nhà phát triển web, hai tầng này thường chỉ được chú ý khi Wi-Fi yếu, cáp lỗi, card mạng có vấn đề hoặc MTU (Maximum Transmission Unit) không phù hợp. Tuy nhiên, hiện tượng mất gói ở đây có thể xuất hiện ở tầng trên dưới dạng API chậm, TCP truyền lại nhiều lần hoặc WebSocket thường xuyên mất kết nối.

Network Layer: đưa gói tin tới đúng mạng

Network Layer dùng địa chỉ IP và bảng định tuyến để chuyển gói tin qua nhiều router. Địa chỉ MAC thay đổi theo từng chặng cục bộ, còn địa chỉ IP xác định nguồn và đích trên đường truyền đầu cuối, trừ khi đi qua NAT (Network Address Translation) hoặc proxy.

Lỗi ở Network Layer thường liên quan tới định tuyến, subnet, VPN (Virtual Private Network), tường lửa theo địa chỉ IP, Network ACL (Access Control List) hoặc việc không có đường tới mạng đích. traceroute có thể giúp quan sát các chặng, nhưng một router không phản hồi ICMP không đồng nghĩa lưu lượng ứng dụng bị chặn.

Transport Layer: kết nối đúng tiến trình

Transport Layer thêm khái niệm cổng. Một máy chủ có thể cùng lúc nhận HTTPS ở cổng 443, SSH (Secure Shell) ở cổng 22 và kết nối cơ sở dữ liệu ở một cổng khác.

TCP cung cấp kết nối có thứ tự, truyền lại dữ liệu bị mất và điều chỉnh tốc độ gửi. UDP gửi datagram mà không tự bảo đảm thứ tự hay truyền lại. HTTP/1.1 và HTTP/2 thường chạy trên TCP; HTTP/3 chạy trên QUIC, còn QUIC sử dụng UDP làm nền.

Session Layer, Presentation Layer và Application Layer: nơi ứng dụng web hoạt động

Trong hệ thống Internet thực tế, trách nhiệm của ba tầng trên thường nằm chung trong thư viện và ứng dụng. HTTP định nghĩa yêu cầu, phản hồi, phương thức, mã trạng thái và header. JSON hoặc Protocol Buffers biểu diễn dữ liệu. TLS mã hoá kênh truyền. Cookie, token và nơi lưu phiên duy trì trạng thái đăng nhập.

Điểm cần nhớ là Session Layer không đồng nghĩa hoàn toàn với phiên HTTP của ứng dụng. Phiên HTTP là một cách ứng dụng duy trì trạng thái người dùng; Session Layer là khái niệm rộng hơn về việc duy trì cuộc trao đổi giữa hai bên.

Từ 7 tầng OSI đến 4 tầng TCP/IP

Các ứng dụng Internet thường dùng mô hình bốn tầng được mô tả trong RFC (Request for Comments) 1122: Application Layer, Transport Layer, Internet Layer và Link Layer.

Mô hình bốn tầng gần với cách Internet được triển khai hơn, còn OSI chi tiết hơn khi cần thảo luận trách nhiệm. Trong công việc, hai mô hình bổ sung cho nhau: dùng TCP/IP để nhìn kiến trúc thực tế, dùng OSI để diễn đạt chính xác vị trí của một vấn đề.

Một yêu cầu HTTPS đi qua các tầng như thế nào?

Giả sử người dùng mở https://example.com/products. Trước khi ứng dụng nhận được yêu cầu HTTP, nhiều bước đã xảy ra.

1. Phân giải tên miền

Trình duyệt cần đổi tên miền thành địa chỉ IP. Nó kiểm tra bộ nhớ đệm cục bộ, hệ điều hành và bộ phân giải DNS. DNS thuộc Application Layer dù nhiệm vụ của nó hỗ trợ kết nối mạng. DNS truyền thống thường dùng UDP hoặc TCP ở cổng 53; DNS over HTTPS lại gửi truy vấn DNS bên trong HTTPS.

Nếu DNS trả NXDOMAIN, trình duyệt chưa hề kết nối tới máy chủ web. Kiểm tra code ứng dụng lúc này không giúp ích.

2. Thiết lập kết nối và mã hoá

Với HTTP/1.1 hoặc HTTP/2, phía gửi thường mở kết nối TCP tới cổng 443, sau đó thực hiện quá trình bắt tay TLS. TLS xác minh chứng chỉ, thoả thuận thuật toán mã hoá và tạo khoá phiên. Sau bước này, yêu cầu HTTP mới được gửi trong kênh mã hoá.

Với HTTP/3, phía gửi dùng QUIC trên UDP. QUIC tích hợp quá trình thiết lập kết nối với TLS 1.3, hỗ trợ nhiều luồng độc lập và giảm ảnh hưởng khi một gói tin của luồng khác bị mất. Đây là ví dụ cho thấy giao thức hiện đại không luôn khớp hoàn toàn với ranh giới OSI.

3. Đóng gói và truyền qua mạng

Với HTTP/1.1 hoặc HTTP/2, dữ liệu HTTP được đặt trong TLS record, rồi vào phân đoạn TCP, gói IP và cuối cùng là khung Ethernet hoặc Wi-Fi. Với HTTP/3, HTTP/3 frame được đặt trong QUIC packet, sau đó vào UDP datagram, gói IP và khung liên kết. QUIC dùng TLS để bắt tay và bảo vệ kết nối, nhưng không dùng TLS record layer như HTTP/1.1 hoặc HTTP/2 chạy trên TCP.

Mỗi router bỏ lớp liên kết của chặng cũ, chọn đường đi tiếp và tạo lớp liên kết mới. Quá trình thêm thông tin theo từng tầng gọi là đóng gói; phía nhận thực hiện ngược lại để lấy yêu cầu HTTP.

4. Đi qua hạ tầng web

Địa chỉ IP đích có thể thuộc CDN, WAF (Web Application Firewall), Layer 7 load balancer hoặc Layer 4 load balancer thay vì máy chạy ứng dụng. CDN và Layer 7 load balancer thường kết thúc kết nối từ trình duyệt, đọc thông tin HTTP rồi mở kết nối khác tới hệ thống phía sau. Layer 4 load balancer kiểu passthrough có thể chỉ chuyển tiếp kết nối TCP hoặc UDP mà không kết thúc TLS hay đọc HTTP.

Yêu cầu có thể tiếp tục qua reverse proxy, service mesh và API gateway trước khi tới ứng dụng. Phản hồi quay lại theo đường logic ngược lại, nhưng các gói tin trên Internet không bắt buộc đi qua đúng cùng một tuyến. Điều ứng dụng nhìn thấy thường là yêu cầu HTTP đã qua nhiều lần chuyển tiếp, không phải kết nối trực tiếp từ trình duyệt. Trong Kubernetes, chuỗi này có thêm Ingress (proxy ở Layer 7), Service qua kube-proxy (NAT theo IP và cổng) và, với một số CNI (Container Network Interface), overlay network như VXLAN đóng gói lại khung Ethernet của Pod bên trong UDP; cách khoanh vùng theo tầng vẫn áp dụng như trên.

Ứng dụng mô hình phân tầng khi thiết kế hệ thống web

Phân biệt Layer 4 và Layer 7 load balancer

Layer 4 load balancer định tuyến dựa trên địa chỉ IP, cổng và giao thức của Transport Layer. Nó không cần hiểu nội dung HTTP, nên phù hợp với TCP/UDP nói chung và có chi phí xử lý thấp.

Layer 7 load balancer hiểu giao thức ứng dụng. Với HTTP, nó có thể chọn hệ thống phía sau theo domain, đường dẫn, phương thức hoặc header; đồng thời kết thúc kết nối TLS, chuyển hướng và áp dụng một số chính sách bảo mật.

Đặt kiểm soát bảo mật đúng tầng

Không có một tầng duy nhất giải quyết toàn bộ bảo mật. Tường lửa hoặc Security Group ở Network Layer và Transport Layer giới hạn nguồn, đích và cổng. TLS bảo vệ dữ liệu trên đường truyền. WAF ở Application Layer kiểm tra yêu cầu HTTP. Xác thực và phân quyền nằm trong ứng dụng.

Nếu chỉ mở cổng 443, hệ thống vẫn có thể có lỗi phân quyền. Nếu chỉ dùng WAF, cổng quản trị không cần thiết vẫn có thể bị phơi ra mạng. Mỗi lớp kiểm soát xử lý một loại rủi ro khác nhau.

Hiểu nơi phát sinh độ trễ

Thời gian tải trang không chỉ là thời gian chạy code trên máy chủ. Nó có thể gồm phân giải DNS, thiết lập TCP, quá trình bắt tay TLS, truyền dữ liệu qua mạng, hàng đợi ở proxy, thời gian xử lý ứng dụng và truy vấn cơ sở dữ liệu.

Mô hình phân tầng giúp tách các phần này. Bộ nhớ đệm DNS giảm thời gian phân giải tên. Tái sử dụng kết nối giảm số lần bắt tay TCP/TLS. CDN đưa nội dung tới gần người dùng. HTTP/2 và HTTP/3 cải thiện cách nhiều yêu cầu dùng chung kết nối. Tối ưu code ứng dụng không giải quyết được độ trễ do mất gói hoặc kết nối mới được tạo quá thường xuyên.

Thiết kế thời gian chờ theo chuỗi

Một yêu cầu thường đi qua trình duyệt, CDN, bộ cân bằng tải, reverse proxy, ứng dụng và cơ sở dữ liệu. Mỗi thành phần có thời gian chờ riêng. Quy tắc thực tế là thời gian chờ của tầng trong phải ngắn hơn tầng ngoài: ví dụ database ngắn hơn ứng dụng, ứng dụng ngắn hơn proxy, proxy ngắn hơn CDN hoặc trình duyệt. Khi lỗi xảy ra, thành phần bên trong kết thúc trước và trả lỗi cụ thể cho tầng gọi nó, thay vì để tầng ngoài cùng trả 504 chung chung.

Giá trị cụ thể phụ thuộc vào tác vụ, nhưng mọi timeout cần nằm trong ngân sách thời gian của toàn yêu cầu. Log và trace phải cho biết yêu cầu dừng ở thành phần nào thay vì chỉ ghi một thông báo timeout chung chung.

Dùng mô hình phân tầng để xử lý sự cố web

Cách hiệu quả nhất là bắt đầu từ triệu chứng rồi thu hẹp phạm vi. Nếu người dùng nhận được mã trạng thái HTTP, kết nối đã đi qua nhiều tầng bên dưới; nên kiểm tra từ Application Layer đi xuống. Nếu không tạo được kết nối, nên kiểm tra DNS, cổng và định tuyến trước khi đọc code nghiệp vụ.

Một bộ lệnh tối thiểu có thể kiểm tra nhiều tầng:

# macOS: dùng TCP probe tới cổng HTTPS
traceroute -P tcp -p 443 example.com

# Linux: dùng TCP probe tới cổng HTTPS
traceroute -T -p 443 example.com

dig example.com
nc -vz example.com 443
openssl s_client -connect example.com:443 -servername example.com
curl -v https://example.com/health

traceroute mặc định thường dùng probe không giống lưu lượng HTTPS. TCP probe tới cổng 443 gần với đường đi cần kiểm tra hơn, nhưng vẫn không bảo đảm giống hoàn toàn do định tuyến theo luồng, proxy hoặc CDN. Nếu có sẵn, mtr giúp quan sát loss và độ trễ qua nhiều lần probe.

Thứ tự trên lần lượt kiểm tra tên miền, khả năng mở kết nối, TLS, HTTP và đường mạng. Không phải lúc nào cũng cần chạy tất cả. Nếu curl đã trả 401, mạng và TLS cơ bản đang hoạt động; vấn đề nhiều khả năng nằm ở xác thực tại Application Layer.

ping không phải phép kiểm tra website. Máy chủ hoặc tường lửa có thể chặn ICMP nhưng vẫn phục vụ HTTPS bình thường. Ngược lại, ping thành công chỉ chứng minh đích phản hồi ICMP, không chứng minh ứng dụng ở cổng 443 hoạt động.

Những điểm dễ hiểu sai

Không cần tranh luận TLS chính xác thuộc Session Layer, Presentation Layer hay Application Layer để xử lý một chứng chỉ hết hạn. Chỉ cần thống nhất rằng lỗi xảy ra sau khi có kết nối ở Transport Layer nhưng trước khi HTTP trao đổi thành công. Mô hình tốt là mô hình giúp đội ngũ hành động nhanh hơn.

Kết luận

Mô hình OSI chia truyền thông thành bảy tầng để mô tả trách nhiệm rõ ràng. Mô hình TCP/IP gộp các trách nhiệm này thành bốn tầng gần với cách Internet vận hành hơn.

Với kỹ sư phần mềm, lợi ích lớn nhất của OSI không phải trả lời câu hỏi phỏng vấn. Nó giúp đọc kiến trúc, hiểu Layer 4 và Layer 7 load balancer, đặt kiểm soát bảo mật đúng vị trí, phân tích độ trễ và khoanh vùng sự cố. Khi gặp lỗi, hãy xác định tầng cao nhất còn hoạt động và tầng thấp nhất bắt đầu thất bại, rồi kiểm tra ranh giới giữa hai tầng đó.

Tài liệu tham khảo

Mô hình mạng

• ITU-T X.200 — OSI Basic Reference Model: The Basic Model — định nghĩa mô hình tham chiếu OSI bảy tầng
• RFC 1122 — Requirements for Internet Hosts: Communication Layers — mô tả các layer giao tiếp của Internet host

Giao thức web

• RFC 9293 — TCP — đặc tả TCP hiện hành
• RFC 8446 — TLS 1.3 — đặc tả TLS 1.3 và quá trình bắt tay
• RFC 9110 — HTTP Semantics — ngữ nghĩa chung của HTTP request và response
• RFC 9000 — QUIC và RFC 9114 — HTTP/3 — QUIC trên UDP và cách HTTP/3 sử dụng QUIC
• RFC 9849 — TLS Encrypted Client Hello — SNI, ECH và giới hạn riêng tư của TLS

Thử gõ vào Claude Code một dòng:

$ claude-code "Tạo cho tôi API đăng nhập."

Vài giây sau bạn có một endpoint chạy được. Nhưng AI vừa phải tự đoán hàng loạt thứ thay bạn: dùng JWT hay session? Payload validate thế nào? Tài khoản bị khóa thì sao? Token sống bao lâu? Mỗi câu nó đoán sai một chút, cộng dồn qua vài chục prompt, và bạn có một hệ thống chạy được nhưng không ai giải thích nổi kiến trúc.

Đây là câu chuyện mình muốn chia sẻ với anh em: từ ngày có Codex, Claude Code và mấy tool tương tự, tốc độ build một ứng dụng tăng chóng mặt. Trước đây một app cần vài tuần đến vài tháng để phân tích, code, debug, hoàn thiện. Giờ đưa yêu cầu cho AI, nó tạo giao diện, backend, database, API, authentication, viết test, thậm chí tự sửa lỗi rồi làm tiếp chức năng mới.

Và câu hỏi tự nhiên bật ra: nếu AI viết code nhanh như vậy, có còn cần phân tích và thiết kế hệ thống trước khi xây không?

Câu trả lời của mình sau một thời gian làm việc với AI Agent: cần, và cần hơn trước rất nhiều.

"Xây được" và "xây đúng" là hai chuyện khác nhau

Có một sự khác biệt rất lớn giữa hai thứ:

1. Xây dựng được một phần mềm — prompt "AI, viết cho tôi app quản lý công việc", nhận về 10.000 dòng code sinh ngẫu nhiên chưa qua phân tích nghiệp vụ.
2. Xây dựng đúng hệ thống — có Problem Definition, Requirements Analysis, System Architecture, Database Schema trước khi một dòng code nào được sinh ra.

AI làm rất tốt vế thứ nhất. Nhưng AI không thể tự biết chính xác bạn đang muốn giải quyết vấn đề gì nếu ngay từ đầu bài toán chưa được phân tích rõ ràng. Nó chỉ có thể lấp chỗ trống bằng phỏng đoán, và phỏng đoán thì có xác suất sai.

Nên thay vì bỏ bước thiết kế, mình chuyển bước thiết kế thành đầu vào cho AI. Cụ thể là quy trình 8 bước dưới đây. Mình sẽ dùng một ví dụ xuyên suốt: Task App cho sinh viên.

Bước 1 — Xác định bài toán (Problem Definition)

Việc đầu tiên không phải là chọn React, Node.js hay MySQL. Mà là trả lời: chúng ta đang giải quyết vấn đề gì?

Nếu chỉ nói "Tôi muốn xây dựng một ứng dụng quản lý công việc" thì đây chưa phải là yêu cầu đủ rõ để bắt đầu. Cần hiểu tại sao ứng dụng này tồn tại:

Sinh viên có rất nhiều bài tập, deadline, lịch học và việc cá nhân, nhưng đang dùng quá nhiều công cụ khác nhau để quản lý. Chúng ta muốn một hệ thống giúp sinh viên quản lý công việc, deadline và lịch cá nhân trong một nơi duy nhất.

Ba câu hỏi bắt buộc phải trả lời ở bước này:

• Ai đang gặp vấn đề? (sinh viên đại học & cao đẳng)
• Vấn đề thực sự là gì? (phân tán công cụ → bỏ sót deadline — tìm root cause, đừng chữa triệu chứng)
• Tại sao cần giải quyết? (tập trung hóa quản lý trên một nền tảng)

Nếu bước đầu tiên đã xác định sai vấn đề, những bước phía sau dù làm tốt đến đâu cũng có thể vô nghĩa. AI code càng nhanh thì cái "vô nghĩa" đó đến càng sớm.

Bước 2 — Phân tích yêu cầu (Requirements)

Khi đã hiểu bài toán, câu hỏi tiếp theo: hệ thống cần làm được những gì?

Functional Requirements — với Task App, sinh viên cần:

• Đăng ký tài khoản, đăng nhập
• Tạo / chỉnh sửa / xóa công việc
• Đặt deadline, phân loại công việc
• Đánh dấu hoàn thành
• Nhận thông báo khi gần đến deadline

Non-functional Requirements — phần hay bị bỏ qua khi prompt AI, nhưng lại quyết định kiến trúc:

• Hệ thống phải phản hồi nhanh
• Dữ liệu người dùng phải được bảo mật
• Phục vụ được nhiều người dùng đồng thời
• Dữ liệu phải được backup
• Có khả năng mở rộng trong tương lai

Bước này biến một ý tưởng chung chung thành danh sách những thứ hệ thống thực sự phải đáp ứng. Danh sách đó sau này chính là tiêu chí để review code AI sinh ra.

Bước 3 — Business Rules: chỗ AI hay "tự ý" nhất

Đây là bước mình thấy khác biệt rõ nhất giữa người có kinh nghiệm và người mới prompt AI.

Ví dụ một task có 3 trạng thái: Todo → In Progress → Done. Nghe đơn giản, nhưng phải hỏi tiếp:

• Task đã Done có được chuyển lại In Progress không?
• Ai được phép thay đổi trạng thái?
• Người dùng xóa task thì xử lý thế nào — soft delete hay hard delete?
• Một user bị xóa thì các task của họ đi đâu?

Lấy riêng câu soft/hard delete. Nếu không nói rõ, AI sẽ tự chọn:

-- AI "tự đoán": hard delete
DELETE FROM tasks WHERE id = ?;
-- Mất hoàn toàn, không khôi phục được, dễ gây mâu thuẫn FK

trong khi cái bạn cần có thể là:

-- Soft delete: chuyển vào thùng rác
UPDATE tasks SET is_deleted = true, deleted_at = NOW() WHERE id = ?;
-- Cho phép khôi phục trong 30 ngày, an toàn dữ liệu người dùng

Hai lựa chọn này kéo theo hai schema khác nhau, hai bộ query khác nhau, hai kiểu xử lý FK khác nhau. Xác định rõ trước khi yêu cầu AI sinh code, để AI không tự thiết kế sai database.

Ở giai đoạn này mình dùng Use Case Diagram, Activity Diagram, Sequence Diagram, User Flow hoặc đơn giản là một tài liệu Business Rules dạng bullet. Mục tiêu duy nhất: biến mong muốn mơ hồ thành mô tả kỹ thuật để AI triển khai chính xác.

Bước 4 — Kiến trúc hệ thống (System Architecture)

Khi đã hiểu hệ thống, lúc này mới bắt đầu trả lời: hệ thống này sẽ được xây dựng như thế nào?

Với Task App, các thành phần và cách chúng nói chuyện với nhau:

• Web / Mobile (React UI) gửi request HTTPS + JSON đến Backend
• Backend API xử lý business logic, gồm các module Auth, Task, Calendar, Notification
• PostgreSQL là source of truth
• Message Queue nhận event deadline.reminder.requested, worker gửi Email / Push

Nguyên tắc mình chốt: business logic nằm ở backend; database là nguồn dữ liệu chuẩn; notification chạy bất đồng bộ để cô lập lỗi (external side effect không được kéo sập luồng chính).

Bước này xuất hiện rất nhiều quyết định kỹ thuật mà developer phải tự chốt, đừng đẩy cho AI:

• Frontend: React hay Vue?
• Backend: Node.js, Java hay Python?
• Database: PostgreSQL, MySQL hay MongoDB?
• API: REST hay GraphQL?
• Authentication: JWT hay Session?
• Cache: có cần Redis không?
• Async: có cần Message Queue không?
• Hình thái: Monolith hay Microservices?

Đây là phần quan trọng nhất mà developer cần đầu tư. Bởi vì nếu kiến trúc sai, AI code càng nhanh thì hệ thống càng đi xa khỏi hướng đúng. 15.000 dòng code sinh ra trong 4 giây trên một kiến trúc không xác định = 15.000 dòng coupling cao và zero boundary check.

Bước 5 — Thiết kế dữ liệu (Data Design)

Có kiến trúc tổng thể rồi, xác định hệ thống cần lưu những dữ liệu gì.

Task App có hai entity chính:

CREATE TABLE users (
  id        SERIAL PRIMARY KEY,
  name      VARCHAR(100) NOT NULL,
  email     VARCHAR(255) UNIQUE NOT NULL,
  password  VARCHAR(255) NOT NULL
);

CREATE TABLE tasks (
  id           SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  description  TEXT,
  status       VARCHAR(20) NOT NULL DEFAULT 'todo'
               CHECK (status IN ('todo', 'in_progress', 'done')),
  deadline     TIMESTAMP,
  user_id      INT NOT NULL REFERENCES users(id),
  -- Soft delete (quyết định ở bước 3)
  is_deleted   BOOLEAN NOT NULL DEFAULT false,
  deleted_at   TIMESTAMP
);

Quan hệ: một User có nhiều Task, một Task thuộc về đúng một User (1:N). Từ đó ra Database Schema.

Để ý hai cột is_deleted và deleted_at: đó là hệ quả trực tiếp của quyết định soft delete ở bước 3, khớp với câu UPDATE ở trên. Tương tự, CHECK trên cột status khóa đúng vòng đời todo → in_progress → done. Business rule nào đã chốt thì phải hiện ra trong schema, nếu không AI sẽ sinh query hard delete hoặc tự chế thêm trạng thái mới.

Nhưng thiết kế database không chỉ là tạo vài bảng. Phải nghĩ đến Foreign Key, Relationship, Index, Constraint, Transaction, Data Consistency, Security và khả năng mở rộng. Nếu database sai ngay từ đầu, backend, API và thậm chí frontend đều phải làm lại — sai một bảng là kéo cả hệ thống theo.

Bước 6 — Chia module (Component Design)

Chia hệ thống thành các module độc lập để AI Agent viết code chính xác trong phạm vi hẹp, thay vì "viết cả app" một lượt.

Task App chia thành:

• Authentication & User Module — xác thực JWT, phân quyền, quản lý hồ sơ. Emits: AuthToken, UserPayload
• Task Management Engine — business rules, vòng đời Todo → In Progress → Done. Requires: valid JWT. Emits: TaskCreated, StatusChanged
• Notification & Event Service — subscribe TaskEvents, gửi cảnh báo deadline. Output: Push Notification
• Calendar, Reporting tách riêng tương tự

Trong từng module lại có Controller / Service (ví dụ TaskController, TaskService). Mỗi module đúng một trách nhiệm (Single Responsibility).

Mục tiêu của bước này là trả lời: module nào chịu trách nhiệm cho việc gì, dữ liệu được truyền qua các module như thế nào? Làm tốt thì hệ thống dễ phát triển, dễ bảo trì, dễ mở rộng — và AI nhận task theo đúng ranh giới module, không "chọc" lung tung sang chỗ khác.

Bước 7 — Specification: bước quan trọng nhất trong thời đại AI

Đây là bước biến toàn bộ phân tích và thiết kế ở trên thành tài liệu AI có thể thực thi.

Quay lại ví dụ mở đầu. Thay vì nói với Claude Code "Tạo cho tôi API đăng nhập", mình đưa một specification cụ thể:

{
  "endpoint": "/api/auth/login",
  "method": "POST",
  "input": {
    "email": "user@domain.com",
    "password": "string (min 8 chars)"
  },
  "rules": [
    "Email không tồn tại hoặc password sai → trả về cùng một lỗi 401 'Email hoặc mật khẩu không đúng'",
    "Không để lộ email có tồn tại hay không qua message, status code hay thời gian phản hồi",
    "Sai quá 5 lần trong 15 phút → tạm khóa đăng nhập 15 phút (rate limit theo email + IP)",
    "Tài khoản bị khóa → chỉ thông báo khóa sau khi email và password đã đúng",
    "Đăng nhập thành công → trả về access token và refresh token"
  ],
  "tokens": {
    "access_token_ttl": "15 phút",
    "refresh_token_ttl": "7 ngày"
  }
}

Chú ý rule đầu tiên. Nếu spec ghi "email không tồn tại → lỗi A, password sai → lỗi B", AI sẽ làm đúng y như vậy, và kẻ tấn công chỉ cần thử từng email để biết email nào đã đăng ký (user enumeration). Spec tốt phải chốt luôn cả những yêu cầu bảo mật kiểu này, vì AI sẽ không tự thêm vào nếu bạn không nói.

Khi mô tả rõ như vậy, AI không cần phải tự đoán. Nó chỉ cần dựa trên specification để triển khai. Và đây chính là lúc thấy rõ mối quan hệ giữa System Design và AI Agent:

System Design là bản đồ. AI Agent là động cơ. Có bản đồ rõ ràng, AI không đi sai hướng.

Bước 8 — Implementation: giao cho AI, nhưng con người vẫn review

Đến đây mới bắt đầu code. Và đây là phần AI Agent hỗ trợ cực kỳ mạnh:

• Tạo API, tạo frontend
• Viết authentication
• Viết unit test, integration test
• Refactor, thậm chí tự kiểm tra code

Nhưng có một nguyên tắc mình không bỏ: AI không nên là người duy nhất đánh giá kết quả của chính nó. Checklist review của mình sau mỗi lượt AI sinh code:

• Code có đúng architecture đã thiết kế không?
• Business logic có đúng rules ở bước 3 không?
• Database có đúng schema ở bước 5 không?
• Có vấn đề security không?
• Có thêm dependency không cần thiết không?
• Có phá vỡ những phần khác của hệ thống không? (AI sửa Task Service, Notification có gãy theo không?)

Vì sao review lại quan trọng hơn trước — bài toán tốc độ lệch pha

Lý do nằm ở một vấn đề mới của thời AI: tốc độ AI sinh code vượt xa tốc độ con người đọc hiểu code.

• AI sinh code: một module phức tạp trong vài phút — tốc độ ~1.500+ dòng / phút
• Con người đọc hiểu: cùng module đó mất vài ngày — tốc độ ~200 dòng / giờ

Kịch bản quen thuộc mình từng chứng kiến:

1. AI tạo module đầu tiên. Ổn.
2. Prompt tiếp: thêm authentication. AI sửa code.
3. Thêm notification. AI sửa tiếp.
4. Thêm payment. AI sửa tiếp.
5. Vài tuần sau: hàng chục nghìn dòng code tự sinh, ứng dụng vẫn chạy, xuất hiện hàng trăm circular dependency, và không ai trong team hiểu kiến trúc.

Đó chính là lúc technical debt bắt đầu. Và sửa một hệ thống đã xây sai kiến trúc khó hơn rất nhiều so với thiết kế đúng ngay từ đầu — vì lúc này bạn phải đọc hiểu với tốc độ 200 dòng/giờ thứ đã được sinh ra với tốc độ 1.500 dòng/phút.

Vai trò của Software Engineer đang dịch chuyển

Quy trình cũ chúng ta hay hình dung là 4 bước: nhận yêu cầu, viết code, test, deploy. Trong thời AI Agent, nó giãn ra thành 8 bước — và bước "viết code" không còn là của con người nữa:

Nói cách khác:

• Con người quyết định WHAT — xây cái gì, tại sao, business rules là gì, hệ thống phải đáp ứng yêu cầu nào.
• Con người thiết kế HOW — architecture, database, module.
• AI thực hiện IMPLEMENTATION — viết code, tạo test, debug, refactor.

AI đề xuất và thực thi. Con người quyết định, xác minh và chịu trách nhiệm cuối cùng. Specification là shared contract giữa hai bên.

Tóm lại: pipeline mình đang dùng

Đây không phải quy trình chỉ dành cho dự án lớn. Ngay cả một app nhỏ, nếu có tư duy phân tích và thiết kế tốt thì quá trình phát triển rõ ràng hơn rất nhiều — vì mỗi bước đều có đầu vào rõ ràng cho bước sau.

AI có thể giúp chúng ta xây phần mềm nhanh hơn rất nhiều. Nhưng AI không đảm bảo rằng thứ chúng ta đang xây là thứ chúng ta thực sự cần. AI tạo ra hàng nghìn dòng code trong vài phút — và nếu thiết kế ban đầu sai, AI cũng giúp chúng ta tạo ra hàng nghìn dòng code sai nhanh hơn bao giờ hết.

Nên kỹ năng quan trọng nhất của Software Engineer sắp tới, theo mình, không còn là "tôi có thể code nhanh đến đâu?" mà là:

• Tôi hiểu bài toán sâu đến đâu?
• Tôi thiết kế hệ thống tốt đến đâu?
• Tôi sử dụng AI thông minh đến đâu để biến thiết kế thành hệ thống thực tế?

AI không làm Software Engineering thừa thãi. Ngược lại, nó khiến Software Engineering quan trọng hơn. AI giúp xây nhanh hơn, System Analysis giúp hiểu mình cần xây gì, System Design giúp biết phải xây như thế nào, và AI Agent biến thiết kế đó thành sản phẩm nhanh hơn bao giờ hết.

Trước khi bắt đầu bất kỳ ứng dụng nào, đừng hỏi "hôm nay tôi sẽ viết code gì?". Hãy hỏi ba câu:

1. Tôi đang giải quyết vấn đề gì?
2. Hệ thống này cần hoạt động như thế nào?
3. Tôi đã thiết kế nó đủ rõ để AI có thể triển khai đúng hay chưa?

AI là động cơ — System Design là vô lăng.

Trong thời đại AI Agent, việc lưu trữ kiến thức không còn đơn giản là viết tài liệu để con người đọc. Khi các AI Agent ngày càng tham gia sâu vào quá trình phát triển phần mềm, phân tích dữ liệu và vận hành hệ thống, chúng ta cần một cách để chia sẻ và tái sử dụng kiến thức giữa con người và AI. Open Knowledge Format (OKF) là một hướng tiếp cận mới cho bài toán này.

1. Open Knowledge Format là gì?

Ngày 12/6/2026, Google Cloud giới thiệu Open Knowledge Format (OKF), một định dạng mở giúp biểu diễn và trao đổi kiến thức giữa con người, hệ thống và AI Agent.

Không giống như các hệ thống quản lý tài liệu truyền thống, OKF tập trung vào việc tổ chức kiến thức sao cho AI có thể dễ dàng đọc, hiểu, truy xuất và tái sử dụng.

Đến phiên bản v0.2 được giới thiệu ngày 24/7/2026, OKF bổ sung những khả năng mô tả nguồn gốc, trạng thái xác minh và vòng đời của kiến thức.

Tại sao chúng ta cần OKF?

Hãy tưởng tượng bạn đang xây dựng một dự án với Claude Code.

Trong quá trình phát triển, Claude Code có thể học được rất nhiều thông tin về hệ thống:

• Kiến trúc backend đang sử dụng Clean Architecture.
• Authentication được triển khai bằng JWT và Redis.
• Một số business rules đặc biệt của dự án.
• Những quyết định kỹ thuật đã được đưa ra.
• Những lỗi thường gặp và cách giải quyết.

Nhưng một vấn đề xuất hiện: Làm thế nào để những kiến thức này được duy trì và sử dụng lại trong các phiên làm việc tiếp theo?

Chúng ta có thể viết chúng vào Markdown, lưu trong database hoặc sử dụng các memory engine như Mem0, Letta hay Zep.

Tuy nhiên, mỗi giải pháp có cách tổ chức và quản lý kiến thức riêng.

OKF tiếp cận vấn đề từ một góc độ khác:

Thay vì xây dựng thêm một hệ thống lưu trữ kiến thức, tại sao không tạo ra một định dạng chung để các hệ thống có thể trao đổi kiến thức với nhau?

Đây chính là ý tưởng cốt lõi của Open Knowledge Format.

2. Format của OKF

Một điểm thú vị là OKF không giới thiệu cú pháp tài liệu hoàn toàn mới.

Thay vào đó, nó sử dụng những công nghệ quen thuộc với lập trình viên: Markdown + YAML.

• Markdown: Chứa nội dung kiến thức, ví dụ, giải thích và các liên kết.
• YAML Frontmatter: Chứa metadata giúp hệ thống phân loại, tìm kiếm và xác định nguồn gốc của kiến thức.

2.1. Cấu trúc Knowledge Bundle

Trong OKF, một tập hợp tài liệu được gọi là Knowledge Bundle.

Ví dụ, một Knowledge Bundle dành cho dự án phần mềm có thể có cấu trúc:

knowledge/
│
├── index.md
├── log.md
│
├── architecture/
│   ├── index.md
│   ├── authentication.md
│   └── database.md
│
├── business-rules/
│   ├── index.md
│   └── payment.md
│
└── troubleshooting/
    ├── index.md
    └── redis-connection.md

Trong đó:

Đặc biệt, các file index.md giúp AI khám phá knowledge base theo từng cấp, thay vì phải đọc toàn bộ tài liệu ngay từ đầu.

2.2. Cấu trúc một Concept

Ví dụ, chúng ta muốn mô tả kiến trúc Authentication:

---
type: Architecture
title: Authentication System
description: Authentication architecture
tags:
  - security
  - authentication
  - backend

generated:
  by: human:developer
  at: 2026-09-20T10:00:00Z

status: active
---

# Authentication System

The system uses JWT authentication.

## Components

- NestJS
- Passport JWT
- Redis

## Authentication Flow

1. User submits credentials.
2. Backend validates credentials.
3. Access token is generated.
4. Refresh token is stored in Redis.

## Related Concepts

- [User Database](./database.md)
- [Redis Configuration](../infrastructure/redis.md)

Một concept được chia thành hai phần chính:

Phần thứ nhất: Metadata

YAML Frontmatter giúp hệ thống hiểu tài liệu đang mô tả điều gì, thuộc nhóm nào, được tạo bởi ai và đang ở trạng thái nào.

Phần thứ hai: Knowledge Content

Markdown chứa nội dung thực tế mà con người và AI Agent sử dụng.

Theo specification v0.2, type là trường duy nhất luôn bắt buộc đối với concept document; những metadata khác có thể được bổ sung tùy nhu cầu.

2.3. Trust và Freshness — điểm đáng chú ý của OKF v0.2

Giả sử một AI Agent tự động phân tích source code và tạo tài liệu kiến trúc.

Chúng ta cần trả lời được những câu hỏi:

• Kiến thức này được tạo ra bởi ai?
• Nó dựa trên nguồn dữ liệu nào?
• Đã được con người xác minh chưa?
• Nó có còn đúng với hệ thống hiện tại không?

OKF v0.2 bổ sung các trường metadata như sources, generated, verified, status và stale_after để biểu diễn những thông tin này.

Ví dụ:

---
type: Architecture
title: Authentication System

generated:
  by: claude-code/1.0
  at: 2026-09-20T10:00:00Z

verified:
  - by: human:developer
    at: 2026-09-21T10:00:00Z

status: active
stale_after: 2026-10-21T10:00:00Z
---

Nhờ đó, hệ thống có thể phân biệt kiến thức được AI tạo ra với kiến thức đã được con người xác minh.

Điều quan trọng là OKF chỉ cung cấp định dạng để ghi nhận những thông tin này. Việc xác minh thực tế vẫn cần được thực hiện bởi con người hoặc một quy trình kiểm tra phù hợp.

3. OKF khác gì với các AI Memory Engine?

Đây có lẽ là câu hỏi thú vị nhất khi tìm hiểu OKF.

Hiện nay đã có nhiều giải pháp hỗ trợ AI Agent ghi nhớ và tái sử dụng thông tin, chẳng hạn:

• Mem0
• Letta
• Zep
• Graphiti

Vậy OKF có phải là một memory engine mới?

Câu trả lời là không.

OKF và các memory engine giải quyết hai vấn đề khác nhau:

OKF — Knowledge Representation: Kiến thức được biểu diễn và trao đổi như thế nào?

Memory Engine — Memory Management: AI lưu, cập nhật, tìm kiếm và sử dụng lại kiến thức như thế nào?

3.1. So sánh với Mem0

Mem0 tập trung vào việc tạo ra persistent memory cho AI Agent.

Nó cung cấp các cơ chế để trích xuất thông tin quan trọng từ tương tác, lưu trữ memory và tìm kiếm những thông tin liên quan khi cần thiết. Mem0 cũng hỗ trợ graph memory để biểu diễn các mối quan hệ.

Ví dụ:

User:
Our backend uses NestJS.

Mem0:
Extract and store the information.

Later...

User:
How should I implement authentication?

Mem0:
Retrieve relevant backend knowledge.

Trong khi đó, OKF tập trung vào việc mô tả kiến thức:

---
type: Architecture
title: Backend Architecture
tags:
  - nestjs
  - backend
---

# Backend Architecture

The backend uses NestJS.

Mem0 cung cấp hệ thống vận hành memory, còn OKF cung cấp định dạng để biểu diễn kiến thức.

3.2. So sánh với Letta

Letta phát triển hệ thống AI Agent có khả năng duy trì trạng thái và quản lý memory.

Một trong những cơ chế của Letta là Memory Blocks, cho phép agent duy trì những thông tin quan trọng trong context và chia sẻ chúng giữa nhiều agent.

OKF không trực tiếp quyết định thông tin nào phải luôn nằm trong context.

Nó cung cấp một cấu trúc tài liệu để agent có thể sử dụng khi cần.

3.3. So sánh với Zep và Graphiti

Zep sử dụng temporal knowledge graph để biểu diễn các thực thể, quan hệ và sự thay đổi của thông tin theo thời gian.

Graphiti là framework mã nguồn mở hỗ trợ xây dựng loại knowledge graph này.

OKF cũng có thể biểu diễn các liên kết giữa concept thông qua Markdown links.

Tuy nhiên, đây không phải là hệ thống temporal knowledge graph hoàn chỉnh như Graphiti.

Bảng so sánh tổng quan

Bảng trên so sánh vai trò và khả năng được cung cấp, không phải hiệu năng hay chất lượng ghi nhớ.

OKF không nhất thiết phải cạnh tranh với Memory Engine. Chúng có thể kết hợp với nhau.

Ví dụ:

        AI Agent
           |
           v
       Mem0 / Zep
           |
           v
     Knowledge Retrieval
           |
           v
    OKF Knowledge Base

Đây là một kiến trúc có thể xây dựng, không phải một cơ chế tích hợp tự động có sẵn trong OKF.

4. Lợi ích khi sử dụng OKF

4.1. Không phụ thuộc vào một AI Provider

Một Knowledge Bundle có thể được lưu trữ trong Git repository và sử dụng bởi nhiều AI Agent như Claude Code, Codex hoặc Gemini CLI.

Bạn không cần chuyển toàn bộ kiến thức sang một định dạng tài liệu khác mỗi khi thay đổi AI Provider.

Tất nhiên, mỗi agent vẫn cần có khả năng đọc và xử lý OKF để tận dụng đầy đủ metadata.

4.2. Knowledge as Code

Vì OKF sử dụng Markdown và YAML, chúng ta có thể quản lý kiến thức tương tự source code.

Ví dụ:

git add knowledge/
git commit -m "Update authentication knowledge"
git push

Điều này mang lại những khả năng quen thuộc:

• Version control.
• Code review cho thay đổi kiến thức.
• Theo dõi lịch sử cập nhật.
• Rollback khi cần thiết.
• Đồng bộ kiến thức giữa các thành viên.

Thay vì xem tài liệu như một thứ được viết một lần rồi bị lãng quên, chúng ta có thể xem nó là một phần của quá trình phát triển phần mềm.

4.3. Hỗ trợ AI Agent quản lý context hiệu quả hơn

Các file index.md cho phép agent khám phá tài liệu theo từng cấp.

Ví dụ:

Task: Fix authentication bug

Read:
  knowledge/index.md
       |
       v
  architecture/index.md
       |
       v
  authentication.md

Thay vì đưa toàn bộ knowledge base vào context window, agent có thể chỉ đọc những kiến thức liên quan đến nhiệm vụ.

Điều này có tiềm năng giảm token đầu vào và hạn chế thông tin không liên quan, nhưng kết quả phụ thuộc vào cách hệ thống retrieval được triển khai.

4.4. Chia sẻ kiến thức giữa nhiều AI Agent

Hãy tưởng tượng một hệ thống có nhiều agent:

Architecture Agent
       |
       v
  OKF Knowledge
       ^
       |
 Coding Agent
       |
       v
 Review Agent

Architecture Agent có thể tạo tài liệu thiết kế.

Coding Agent sử dụng tài liệu đó để triển khai.

Review Agent đối chiếu implementation với thiết kế đã được xác minh.

Nhờ sử dụng một định dạng chung, các agent có thể phối hợp thông qua những knowledge artifacts có thể đọc và kiểm tra được.

5. Những hạn chế của OKF

Mặc dù có nhiều ý tưởng đáng chú ý, OKF không phải là giải pháp hoàn chỉnh cho mọi bài toán AI memory.

5.1. OKF chỉ là format, không phải memory engine

OKF không tự động:

• Ghi nhớ toàn bộ cuộc hội thoại.
• Trích xuất kiến thức quan trọng.
• Tìm kiếm semantic similarity.
• Phát hiện mâu thuẫn giữa các memory.
• Quyết định thông tin nào cần đưa vào context.

Để triển khai những khả năng này, chúng ta vẫn cần xây dựng thêm hệ thống hoặc tích hợp memory engine hiện có.

5.2. Không bảo đảm tính chính xác của kiến thức

Một concept có metadata đầy đủ vẫn có thể chứa thông tin sai.

Ví dụ:

verified:
  - by: human:developer
    at: 2026-09-20T10:00:00Z

Metadata cho biết hoạt động xác minh đã được ghi nhận, nhưng không chứng minh nội dung luôn đúng.

Đặc biệt với những knowledge base được AI tự động tạo ra, việc kiểm soát chất lượng thông tin vẫn rất quan trọng.

5.3. Cần xây dựng tooling cho hệ thống lớn

Đối với vài chục tài liệu, chúng ta có thể sử dụng OKF bằng những công cụ quản lý file thông thường.

Nhưng khi knowledge base có hàng nghìn concept, hệ thống có thể cần thêm:

• Knowledge indexing.
• Semantic search.
• Metadata filtering.
• Dependency tracking.
• Conflict detection.
• Automated validation.

OKF không quy định bắt buộc một hệ thống lưu trữ hay truy vấn cụ thể. Đây vừa là ưu điểm về tính linh hoạt, vừa là phần công việc mà đội ngũ triển khai phải tự giải quyết.

5.4. Hệ sinh thái còn mới

OKF mới được Google Cloud giới thiệu vào tháng 6/2026, trong khi phiên bản v0.2 xuất hiện vào tháng 7/2026.

Một số đề xuất như typed relationships và agent-routing hints vẫn nằm trong những hướng phát triển được cộng đồng thảo luận tại thời điểm công bố v0.2.

Vì vậy, khi xây dựng hệ thống production, cần đánh giá mức độ tương thích của các công cụ và chuẩn bị cho khả năng specification tiếp tục thay đổi.

6. Kết luận

Open Knowledge Format không phải là một memory engine mới và cũng không nhằm thay thế Markdown, Vector Database hay những hệ thống như Mem0 và Zep.

Điểm đáng chú ý của OKF nằm ở cách tiếp cận: chuẩn hóa việc biểu diễn và trao đổi kiến thức để con người và AI Agent có thể cùng sử dụng.

Trong một thế giới mà AI Agent không chỉ đọc tài liệu mà còn có khả năng tạo ra và cập nhật kiến thức, việc quản lý nguồn gốc, trạng thái xác minh và vòng đời của thông tin trở nên ngày càng quan trọng.

Với các dự án nhỏ, Markdown thông thường có thể đã đủ đáp ứng nhu cầu.

Nhưng nếu bạn đang xây dựng một hệ thống AI Agent có khả năng tích lũy kiến thức lâu dài, cộng tác giữa nhiều agent hoặc chia sẻ knowledge base giữa nhiều công cụ AI, OKF là một định dạng đáng để tìm hiểu và thử nghiệm.

Có lẽ tương lai của AI memory không chỉ nằm ở việc AI ghi nhớ được bao nhiêu thông tin, mà còn ở việc những kiến thức đó được biểu diễn, kiểm chứng, chia sẻ và tái sử dụng như thế nào.

Tài liệu tham khảo

1. Google Cloud — Introducing Open Knowledge Format
2. Google Cloud — OKF v0.2 tackles agentic trust
3. GitHub — Open Knowledge Format
4. GitHub — OKF v0.2 Specification
5. Mem0 Documentation
6. Letta Documentation
7. Graphiti Documentation

Reinforcement Learning · Kỳ 1

Nếu bạn từng nghe chuyện một chương trình máy tính tự học chơi cờ vây giỏi hơn nhà vô địch thế giới, hay một cánh tay robot tự học cách cầm nắm đồ vật mà chẳng ai lập trình sẵn từng động tác, thì phần lớn thời gian, thứ đứng sau những câu chuyện đó là Reinforcement Learning — học tăng cường. Nghe hoành tráng thật, nhưng gốc rễ của cả hệ thuật toán đồ sộ ấy lại bắt đầu từ một ý tưởng rất nhỏ: học bằng thử và sai, không hơn không kém.

Để thấy ý tưởng đó trần trụi nhất, không cần tới AlphaGo hay cánh tay robot nào cả — chỉ cần một cái lưới ô vuông trống trơn, và một con robot tên là Pixel.

Pixel nhỏ, hình dáng như một con chuột, bị thả xuống giữa lưới ô vuông đó mà không có gì trong tay: không bản đồ, không ai chỉ đường, cũng chẳng ai nói cho nó biết đích đến nằm ở đâu, hay "đi đúng" nghĩa là gì.

Nhưng nó có một thứ, dù chỉ một: sau mỗi hành động, thế giới lặng lẽ trả lại một con số. Số dương giống như một cái gật đầu. Số âm giống một cái lắc đầu. Còn phần lớn thời gian, chỉ có im lặng.

Bài toán của Pixel

Với chừng đó thông tin, nhiệm vụ của Pixel là tối đa hoá tổng những con số ấy, cộng dồn theo thời gian. Không ai dạy nó luật chơi — nó phải tự suy ra, bằng cách chơi.

Đó chính là bài toán Reinforcement Learning đặt ra. Và Q-Learning là một trong những câu trả lời lâu đời và cứng cựa nhất cho bài toán đó.

Nghe hơi giống cách người ta huấn luyện một con chó: không giải thích khái niệm "ngồi xuống" là gì, chỉ thưởng snack mỗi khi con chó tình cờ làm đúng. Nhưng có một khác biệt: chẳng có bàn tay nào đứng ngoài chỉnh hành vi của Pixel cả. Nó phải tự mò, tự thử, tự sai, và — quan trọng nhất — tự ghi nhớ.

Chính chữ "tự ghi nhớ" đó là chỗ Q-Learning bước vào.

Giờ thì Pixel vẫn đang đứng ở góc lưới ô vuông, chưa biết gì cả.

Hãy xem nó bắt đầu như thế nào.

Trạng thái, hành động, phần thưởng

Pixel đứng ở ô góc trái. Việc đầu tiên nó nhận ra: nó đang ở một chỗ cụ thể, trong một tình huống cụ thể — gọi là trạng thái (state). Mỗi ô trên lưới là một trạng thái khác nhau.

Từ trạng thái đó, nó có thể làm vài việc: đi lên, đi xuống, đi trái, đi phải. Mỗi lựa chọn như vậy là một hành động (action).

Nó chọn đại một hướng — đi lên. Ô mới. Trạng thái mới. Và ngay sau đó, thế giới trả lời bằng một con số: phần thưởng (reward), đúng như đã nói ở phần trước.

Ba thứ đó — trạng thái, hành động, phần thưởng — là toàn bộ những gì Pixel có để làm việc. Câu hỏi còn lại: làm sao từ đó suy ra hành động nào tốt?

Q-Learning gán cho mỗi cặp (trạng thái, hành động) một con số gọi là Q-value — ước tính "nếu đứng ở đây và làm việc này, về sau mình sẽ thu được bao nhiêu điểm". Toàn bộ những con số đó gộp lại thành một bảng, gọi là Q-table.

Ban đầu, Q-table trống trơn. Mỗi bước đi, Pixel cập nhật lại đúng một ô trong bảng đó, dựa trên phần thưởng vừa nhận và ước tính ở bước kế tiếp. Vòng lặp cứ thế lặp lại: hành động → phản hồi → cập nhật → hành động tiếp theo.

Nghe thì trừu tượng. Nhưng nếu bỏ hết mọi lựa chọn hành động, chỉ giữ lại đúng một phép cập nhật duy nhất, chuyện gì sẽ xảy ra?

Thử xem.

Demos

Q-Learning, nhìn thấy tận mắt

Đọc công thức là một chuyện. Thấy nó chạy thật, từng bước một, là chuyện khác hẳn.

Hai demo dưới đây cùng một mục đích: giúp bạn nhìn thấy Q-Learning học, không chỉ đọc về nó.

• Demo 1 cắt bỏ hết mọi thứ gây rối — không có lựa chọn, không có nhiều hướng đi — chỉ giữ lại đúng phép cập nhật, để bạn thấy giá trị lan dần từ đích ngược về điểm xuất phát.
• Demo 2 trả lại cho Pixel quyền lựa chọn: nhiều hành động, một mê cung nhỏ, và phải tự tìm đường.

Giờ trả lại cho Pixel những gì nó vừa mất: nhiều ô để đi, nhiều hướng để chọn.

Phép cập nhật vẫn y hệt — chỉ có một chỗ thay đổi: giờ nó phải quyết định sẽ làm gì tiếp theo, trước khi biết chuyện gì xảy ra.

Khai thác hay khám phá?

Pixel giờ đã có chút hiểu biết: vài ô nó tin là ổn, một hai ô nó nghi là bẫy. Nhưng "tin" và "nghi" không phải "chắc chắn."

Nếu Pixel luôn chọn hành động nó tin là tốt nhất — gọi là khai thác (exploitation) — nó có thể mắc kẹt mãi với con đường tạm ổn tìm ra đầu tiên, trong khi một con đường ngắn hơn chưa từng được thử. Nếu nó luôn chọn hành động ngẫu nhiên — khám phá (exploration) — nó chẳng bao giờ dùng được những gì đã học.

Cách giải quyết dùng trong demo và code ở bài này gọi là ε-greedy:

• với xác suất ε, chọn một hành động ngẫu nhiên (khám phá)
• với xác suất 1 − ε, chọn hành động Pixel tin là tốt nhất, tức argmax Q(s, a) (khai thác)

ε càng lớn, Pixel càng hay thử cái mới. ε càng nhỏ, Pixel càng bám sát những gì đã biết. Ở demo dưới, kéo thanh trượt "Khám phá ε" để thấy tận mắt hai thái cực đó.

Ở trên là Q-Learning chạy ngay trong trình duyệt, viết bằng JavaScript, cho dễ nhìn.

Nhưng nếu bạn muốn tự tay chạy lại, sửa phần thưởng, đổi kích thước lưới — thì mã Python bên dưới là bản để bạn nghịch.

Cài đặt bằng Python

Đúng bài toán ở demo trên — lưới 5×5, một đích, hai bẫy — viết lại bằng Python và NumPy:

import numpy as np
import random

N = 5
START = (0, 0)
GOAL = (4, 4)
TRAPS = {(1, 3), (3, 1)}
ACTIONS = [(-1, 0), (1, 0), (0, -1), (0, 1)]  # lên, xuống, trái, phải

alpha = 0.3
gamma = 0.9
epsilon = 0.2
episodes = 200
max_steps = 100

Q = np.zeros((N, N, len(ACTIONS)))


def step(state, action):
    r, c = state
    dr, dc = ACTIONS[action]
    nr, nc = r + dr, c + dc
    if not (0 <= nr < N and 0 <= nc < N):
        nr, nc = r, c
    if (nr, nc) == GOAL:
        return (nr, nc), 10, True
    if (nr, nc) in TRAPS:
        return (nr, nc), -10, True
    return (nr, nc), -1, False


def choose_action(state, eps):
    if random.random() < eps:
        return random.randrange(len(ACTIONS))
    r, c = state
    return int(np.argmax(Q[r, c]))


for ep in range(episodes):
    state = START
    for t in range(max_steps):
        action = choose_action(state, epsilon)
        next_state, reward, done = step(state, action)
        r, c = state
        nr, nc = next_state
        best_next = 0 if done else np.max(Q[nr, nc])
        Q[r, c, action] += alpha * (reward + gamma * best_next - Q[r, c, action])
        state = next_state
        if done:
            break

Toàn bộ thuật toán nằm trong đúng một dòng: Q[r, c, action] += alpha * (reward + gamma * best_next - Q[r, c, action]) — công thức ở phần trước, viết lại bằng code.

Một chi tiết dễ bị bỏ sót: khi done là True (Pixel vừa tới đích hoặc sa bẫy), không có "bước kế tiếp" nào để tính giá trị tốt nhất — nên best_next phải là 0, không phải Q[nr, nc]. Bỏ chi tiết if done này thường không gây lỗi rõ ràng ngay (vì ô đích và ô bẫy không bao giờ được chọn làm điểm xuất phát của một bước đi, nên giá trị của chúng vốn dĩ vẫn luôn là 0) — nhưng viết tường minh ra vẫn tốt hơn: dễ đọc hơn, và không còn âm thầm dựa vào một sự trùng hợp.

Sau khi train xong, xem Pixel đi đường nào bằng chính sách đã học (không còn khám phá ngẫu nhiên nữa):

def run_greedy():
    state = START
    path = [state]
    for _ in range(40):
        r, c = state
        action = int(np.argmax(Q[r, c]))
        state, reward, done = step(state, action)
        path.append(state)
        if done:
            break
    return path

print(run_greedy())

Muốn nghịch thêm, vài chỗ đáng sửa trước tiên:

• TRAPS — đổi vị trí hoặc thêm bẫy, xem đường đi học được thay đổi ra sao.
• epsilon — để cao suốt quá trình train (không giảm dần) là một sự đơn giản hoá. Thử giảm dần epsilon theo từng episode, Pixel sẽ khai thác nhiều hơn về cuối.
• N — tăng kích thước lưới lên 10×10 hoặc hơn, rồi xem episodes cần bao nhiêu mới đủ để hội tụ.

Chỉnh cái cuối cùng đó đủ lâu, bạn sẽ đụng đúng vấn đề mà phần tiếp theo nói tới.

Giới hạn

Khi bảng không còn chứa nổi

Tăng N lên 10, Q-table có 400 ô. Lên 50, có 10.000 ô. Với môi trường thực — ảnh chụp màn hình game, cảm biến robot, hàng trăm biến số liên tục — số trạng thái không còn đếm được nữa.

Đây là giới hạn của Q-Learning dạng bảng: nó cần một ô riêng cho từng cặp (trạng thái, hành động), và phải ghé thăm từng ô đó ít nhất một lần mới học được gì. Bảng càng lớn, càng lâu học, càng tốn bộ nhớ — tới một lúc không còn khả thi.

Một thắc mắc hay gặp: nếu Q(s, a) phụ thuộc vào Q(s′, a′) ở bước kế tiếp, thì cái bảng đó phải "biết trước" gì để dựng lên được? Câu trả lời: hình dạng của bảng — bao nhiêu hàng, bao nhiêu cột — được cố định ngay từ đầu, trước khi Pixel học bất cứ điều gì: một hàng cho mỗi trạng thái có thể có, một cột cho mỗi hành động có thể có, giá trị khởi tạo bằng 0. Việc học chỉ thay đổi các con số bên trong từng ô, không thay đổi hình dạng bảng. Nói cách khác: bảng không lớn dần khi Pixel học — nó đã phải đủ lớn để chứa mọi trạng thái có thể xảy ra, kể cả những trạng thái Pixel chưa từng ghé qua. Đó chính xác là lý do số lượng trạng thái là vấn đề chí mạng: nó quyết định kích thước bảng phải dựng lên ngay từ đầu, không phải tốc độ học.

Thử tưởng tượng đem cách này áp vào một bàn cờ vua. Mỗi thế cờ hợp lệ là một trạng thái. Số thế cờ hợp lệ trên bàn cờ vua ước tính vào khoảng 10⁴⁷ — một con số không cách nào liệt kê hết, chứ đừng nói dựng thành hàng trong một cái bảng. Đây cũng chính là lý do chương trình chơi cờ vây nhắc ở đầu bài viết này không hề dùng Q-table: với cờ vây, con số đó còn lớn hơn nhiều.

Cách sửa phổ biến nhất: thay cái bảng bằng một mạng neural. Thay vì tra một ô có sẵn, mạng đó ước lượng Q-value trực tiếp từ trạng thái đầu vào — kể cả những trạng thái nó chưa từng thấy. Gọi là Deep Q-Network (DQN).

Nguyên tắc lõi — thử, sai, cập nhật theo đúng công thức ở phần trước — không đổi. Chỉ có nơi lưu trữ hiểu biết là đổi: từ một cái bảng, thành trọng số của một mạng neural.

Kết

Pixel chưa bao giờ hiểu cái lưới ô vuông đó. Nó không có khái niệm gì về hình học, về khoảng cách, về việc góc nào gần đích hơn góc nào. Suốt từ đầu tới cuối, nó chỉ làm đúng một việc, lặp đi lặp lại: so sánh cái vừa xảy ra với cái nó từng nghĩ, rồi sửa sai một chút.

Không có gì thông minh trong chuyện đó. Chỉ có sự lặp lại, và một cuốn sổ không bao giờ ngừng cập nhật.

Đó cũng chính là bí mật đứng sau chương trình chơi cờ vây, đứng sau cánh tay robot nhắc tới ở đầu bài viết này. Vẫn là phép cập nhật đó — chỉ được lặp lại nhiều triệu lần hơn, trên những cuốn sổ lớn hơn rất nhiều lần.

Đọc thêm

• An Introduction to Q-Learning: A Tutorial For Beginners — DataCamp
• Q-Learning in Reinforcement Learning — GeeksforGeeks
• Reinforcement Q-Learning from Scratch in Python with OpenAI Gym — LearnDataSci
• Reinforcement Learning Explained Visually (Part 4): Q-Learning, step-by-step — Towards Data Science
• Q-Learning By Examples — Revoledu

Chào anh em,
Chắc hẳn anh em đều biết đến phiên livestream chấn động của một tiktoker hải ngoại hồi tháng 8 vừa qua - đỉnh điểm cán mốc hơn 2 triệu người xem cùng lúc. Tất nhiên, là chất lượng nó vẫn cứ gọi là mướt mườn mượt. Điều đó dấy lên trong tôi một câu hỏi: "Rốt cuộc thì đằng sau màn hình, cái hệ thống đó được thiết kế bá đạo đến mức nào mà không bị đè sập?"

Nhiều anh em nghĩ rất đơn giản rằng: "Chắc ByteDance lại đập vào cả đống tiền, mua máy chủ xịn với nạp thêm nhiều băng thông chứ có gì đâu." Nhưng dưới góc độ kỹ thuật hệ thống, nếu chỉ giải quyết bằng cách mua thêm phần cứng, anh em sẽ phá sản trước khi server kịp sập. Xử lý 2 triệu view không phải câu chuyện "làm cho nhanh hơn", mà là bài toán quy mô khuếch tán (Fan-out).

Hôm nay, hãy cùng tôi bóc tách xem các kỹ sư ByteDance thực sự làm gì để phát một luồng video tới 2 triệu màn hình cùng lúc một cách TIẾT KIỆM NHẤT và HIỆU QUẢ NHẤT.

1. Bài toán hại não: 2 triệu view ở 1 chỗ hay rải rác toàn cầu khó hơn?

Giả sử có 2 kịch bản livestream cùng đạt mốc 2 triệu viewer cùng lúc:

• Kịch bản A: Dồn hết 2 triệu viewer tại Việt Nam (như phiên live của bà Ph**** H**g).
• Kịch bản B: 2 triệu viewer rải rác khắp thế giới (Mỹ, Trung Quốc, Châu Âu,...).

Theo anh em, kịch bản nào tàn phá hạ tầng mạng khủng khiếp hơn?

Tôi đoán là nhiều anh em sẽ nghĩ: "Rõ ràng dồn hết 2 triệu view vào Việt Nam khó hơn chứ! Nhồi hàng triệu kết nối cùng lúc sẽ đè sập băng thông nhà mạng nội địa, gây nghẽn cổ chai ngay cổng ISP trong nước."

Nhìn qua thì có vẻ "nặng nề" thật. Nhưng tưởng thế, mà lại không phải là thế. Dưới góc độ System Design, bài toán dồn traffic vào một vùng địa lý lại là "chế độ Dễ" mà các hệ thống CDN đã giải quyết cực kỳ gọn gàng từ lâu:

• Tỷ lệ Cache Hit gần như 100%: 2 triệu người ở cùng 1 quốc gia nghĩa là máy chủ rìa (Edge Node) tại khu vực đó chỉ cần kéo luồng video từ máy chủ gốc về đúng 1 lần, rồi nhân bản phát lại cho 2 triệu người xung quanh. Tải trọng đường truyền nội bộ gần như bằng 0.
• Dự báo dễ dàng: Khung giờ vàng cố định (ví dụ 8h - 10h tối), hệ thống chủ động warmup cache (làm nóng bộ nhớ đệm) và auto-scale máy chủ sẵn sàng trước giờ G.

Ngược lại, kịch bản 2 triệu view rải rác toàn cầu mới chính là "chế độ Ác mộng" thực sự mà ít ai ngờ tới:

• Bề nổi (Yếu tố thời gian): Múi giờ lệch nhau hoàn toàn, không có khung giờ vàng chung để hệ thống tính toán dự báo traffic.
• Bản chất kỹ thuật (Yếu tố không gian): Khi rải mỏng người xem ra toàn cầu, bài toán Cache hoàn toàn vỡ vụn. Theo công bố của ByteDance, dữ liệu thực tế chỉ ra một sự thật oái oăm: Ngay cả với một livestream siêu hot (>100,000 viewer toàn cầu), có tới 77% số cụm Edge Node (máy chủ rìa) phục vụ nó lại ở trong trạng thái "lạnh cục bộ" (<10 viewer tại chính node đó).

Hãy hình dung: Một Edge Node ở New York có đúng 3 người xem, Edge Node ở Paris có 5 người xem. Dù buổi live đang có 2 triệu view cháy máy, từng node lẻ này vẫn liên tục bị trượt cache. Kết quả là hàng ngàn node trên thế giới đều phải đồng loạt chạy ngược về máy chủ gốc để kéo dữ liệu nội bộ. Sự nhân bản dữ liệu rải rác và vô nghĩa này mới chính là thứ âm thầm đốt sạch tiền ngân sách băng thông của TikTok.

Vậy cái việc "chạy ngược về máy chủ gốc" đó bản chất là gì, và tại sao nó lại trở thành hố đen âm thầm rút sạch ví của các nhà vận hành hệ thống?

Để trả lời câu hỏi này, chúng ta cần phải bóc tách cách một luồng video đi trong mạng lưới CDN và phân diện hai loại lưu lượng hoàn toàn khác nhau.

2. Bóc tách lưu lượng: Egress vs Midgress — Hố đen tài chính đằng sau màn hình

Về bản chất, một luồng livestream không bao giờ đi thẳng một mạch từ điện thoại streamer tới màn hình của 2 triệu người xem. Nó phải đi qua 3 trạm luân chuyển như sau:

Dựa trên luồng đi này, ByteDance chia lưu lượng mạng ra làm 2 loại rõ rệt với cơ chế tính phí khác nhau:

• Egress Traffic (Lưu lượng đầu ra): Dữ liệu truyền từ Edge Node (máy chủ rìa) đến thiết bị người xem.
  Đây là khoản chi phí công khai mà TikTok bắt buộc phải trả cho các nhà mạng (ISP) dựa trên số lượt xem thực tế. Anh em có 2 triệu view thì phải tốn tiền Egress cho 2 triệu view, điều này là hiển nhiên và tính toán trước được.
• Midgress Traffic (Lưu lượng nội bộ): Dữ liệu truyền giữa các máy chủ CDN với nhau (Origin đẩy sang Edge, hoặc Edge relay sang Edge).
  Đây mới chính là "hố đen" âm thầm đốt sạch ngân sách mà ít kỹ sư để ý tới.

Tại sao Midgress lại đáng sợ đến vậy?

Hãy tưởng tượng Edge Node tại một khu vực nhỏ bị trượt cache (cache miss) vì chỉ có lèo tèo vài người xem. Để phục vụ 3 người xem đó, Edge Node bắt buộc phải kéo nguyên một luồng video chất lượng cao từ Origin Node về qua đường truyền Midgress.  Nếu kịch bản này lặp lại ở 10.000 Edge Node rải rác trên toàn cầu, hệ thống của anh em đang phải gửi cùng 1 luồng video 10.000 lần qua mạng nội bộ!  Cái giá phải trả lúc này không chỉ là tiền băng thông liên vùng (Inter-datacenter cost), mà còn làm nghẽn luôn các đường truyền mạng lõi, đẩy tỷ lệ lãng phí MER (Midgress-Egress Ratio) tăng vọt. Một hệ thống có MER càng cao nghĩa là hệ thống đó càng "ngu" trong việc quản lý bộ nhớ đệm.

Bây giờ anh em đã thấy rõ chân tướng của bài toán rồi: Muốn 2 triệu view mượt mà mà không phá sản, TikTok bắt buộc phải tìm cách triệt hạ lưu lượng Midgress và tối ưu đơn giá Egress tại các Edge Node.

3. Đánh đổi thực tế: Tốc độ điều hướng vs Trải nghiệm người dùng (QoE)

Câu hỏi tiếp theo của đội ngũ kỹ sư ByteDance là: Làm sao để nắn dòng dữ liệu, điều hướng (redirect) người xem từ các node đang bị lạnh sang các node đang nóng hoặc hạ tầng giá rẻ?

Trong kiến trúc hệ thống, Redirection là một con dao 2 lưỡi: nó linh hoạt, nắn dòng cực nhanh, nhưng cái giá phải trả cho trải nghiệm người dùng (QoE) thì không hề rẻ.

Để bắt người dùng đổi từ Edge Node A sang Edge Node B, hệ thống phải trả về một lệnh Redirection. Muốn chuyển hướng thì client phải gửi request --> nhận lệnh --> bắt đầu mở kết nối mới tới IP mới.

Và thế là tốn thêm ít nhất 1 vòng round-trip (RTT) trên đường truyền mạng.

Với ứng dụng đọc tin tức hay xem ảnh, vài chục millisecond trễ này chẳng ai nhận ra. Nhưng với video livestream thời gian thực, thì nó tạo ra một thảm họa. Đo lường thực tế từ ByteDance chỉ ra rằng việc Redirection ngây thơ lập tức kéo tăng độ trễ khung hình đầu tiên (First-frame delay) lên tới 12.3% và số lần video bị giật lag (Stalls) tăng thêm tới 7.5%.

Chúng ta đang đứng trước bài toán lựa chọn:

• Chấp nhận để video giật lag một tí để tiết kiệm tiền băng thông cho công ty?
• Hay chấp nhận tốn tiền để giữ app chạy mượt?

Và tất nhiên rồi, những kỹ sư ưu tú của ByteDance, đơn giản là họ CHỌN HẾT.

Họ giải bài toán này bằng một tư duy kết hợp cực kỳ thông minh giữa Client (App TikTok) và Server (CDN) thông qua tầng Thuật toán Gợi ý (Recommendation Feed), gọi là Proactive Quality Assurance (PQA)

Anh em hãy nhớ lại giao diện lướt video của TikTok: các video/livestream tiếp theo đã được xếp sẵn thành một danh sách (feed) theo thứ tự ưu tiên. Phải công nhận là là mấy ông Tiktok giỏi thật, :>> luôn biết hiện những cái video mà mình ưa thích.

1. Đoán trước tương lai: Khi ngón tay anh em còn đang dừng ở video hiện tại, SDK ở Client đã âm thầm nhìn xuống danh sách gợi ý và biết chính xác luồng livestream nào anh em sắp sửa vuốt tới.
2. Xử lý trước ngầm (Off critical path): Ngay lập tức, app tự động thực hiện phân giải DNS, nhận sẵn lệnh Redirection từ CDN controller, mở trước kết nối TCP/QUIC tới Edge Node mục tiêu và kéo luôn một ít khung hình video đầu tiên về bộ nhớ đệm.
3. Tối ưu tuyệt đối: Đến khi ngón tay anh em vuốt màn hình lên, luồng live lập tức nảy lên tức thì mà không hề dính 1 millisecond trễ nào của quá trình Redirection.

Nói một cách dễ hiểu thì: ByteDance không triệt tiêu được độ trễ của việc chuyển hướng, nhưng họ đã đẩy toàn bộ độ trễ đó ra khỏi thời điểm người dùng thao tác.

Kết quả thực nghiệm cho thấy, khi bật Proactive QA, thời gian giật lag thậm chí còn giảm tới 21% - 41% so với việc phát video thông thường.

4. HCDN Stream Scheduler: Bộ điều phối luồng dữ liệu của ByteDance

Ở Phần 3, chúng ta đã tháo gỡ thành công rào cản lớn nhất: "Liệu chuyển hướng thế này có làm lag app không?. Vậy thì câu chuyện chính là họ nắn dòng dữ liệu (Stream Scheduling) như thế nào để có thể tối ưu chi phí băng thông nhất?.  Đây chính là trọng tâm của bài blog này.

HCDN là gì?

Chúng ta sẽ đến với một khái niệm mới được Bytedance cung cấp - HCDN (Heterogeneous Content Delivery Network), nôm na tiếng Việt có thể dịch là CDN dị thể/không đồng nhất.

Cái tên này phản ánh đúng bản chất hạ tầng của ByteDance: Họ không "ném tiền" vào một hệ thống máy chủ đồng nhất đắt đỏ, mà kết hợp lai ghép nhiều loại hạ tầng máy chủ khác nhau (dị thể) để tối ưu chi phí.

Trước tiên, họ nâng cấp hạ tầng CDN tiêu chuẩn thành hệ thống 3 tầng phân cấp:

• Layer 1 (Regular Edge): Máy chủ rìa tiêu chuẩn, chất lượng cao nhưng đắt đỏ.
• Layer 1.5 (Multihomed Edge): Máy chủ "đặc nhiệm" nối đa nhà mạng và đa khu vực (cross-ISP / cross-region).
• Layer 0.5 (Alternative Edge): Máy chủ giá rẻ của nhà mạng (ISP Edge Node), chạy trên các cổng không tiêu chuẩn để tối ưu chi phí hạ tầng ở mức tối đa

Dưới đây là cách ByteDance điều phối dòng chảy của dữ liệu bằng cách sử dụng các phân cấp hạ tầng trên, theo ngôn ngữ của các cụ nhà ta, thì gọi là "Chia để trị".

4 chiến thuật "nắn dòng" điều trị tận gốc cơn ác mộng Midgress

Chiến thuật 1: Đẩy "Luồng đóng băng" ra rìa đa mạng (Frozen Stream Offloading)

• Vấn đề: Có những phòng live chỉ có lác đác 1-2 người xem trên toàn cầu (Frozen streams). Nếu rải rác ở máy chủ Layer 1 thông thường, mỗi node ở mỗi quốc gia sẽ phải kéo một luồng Midgress riêng về, vừa tốn tiền vừa vướng luật cấm truyền dữ liệu chéo ISP.
• Cách giải: HCDN đẩy thẳng các luồng này sang Layer 1.5 (Multihomed Nodes). Nhờ khả năng kết nối đa mạng, Layer 1.5 kéo trực tiếp dữ liệu từ máy chủ gốc (Origin) về phục vụ khán giả rải rác mà không sinh ra bất kỳ chặng Midgress trung gian nào

Chiến thuật 2: Gom luồng lạnh (Cold Stream Aggregation)

• Vấn đề: Các luồng live ít người xem (Cold streams) nếu rải rác trên 50 Edge Node thì cả 50 node đều tốn Midgress.
• Cách giải: Gom (aggregate) toàn bộ khán giả của luồng đó về đúng 1-2 Edge Node cố định trong cùng khu vực
• Điểm tinh tế: ByteDance phát hiện các luồng nén tải song song (Substreams) hay luồng vá lỗi khung hình (Patch streams) chiếm 30% hệ thống nhưng tốn Midgress gấp 1.72 đến 5.76 lần luồng thường. Do đó, hệ thống áp dụng cơ chế gom luồng cực đoan (aggressive aggregation) hơn với các loại stream "đốn tài nguyên" này.

Chiến thuật 3: Dồn quân cho luồng nóng (Hot Stream Aggregation)

• Vấn đề: Đây chính là lời giải cho con số 77% node bị "lạnh cục bộ" ở Phần 1. Một phiên live 2 triệu view hot toàn cầu nhưng tại một Edge Node thành phố nhỏ chỉ có 10 người xem.
• Cách giải: Hệ thống đo lường thời gian thực: node nào có dưới 100 người xem sẽ bị coi là "cold node". HCDN sẽ âm thầm điều hướng những người xem đó sang các "hot node" lân cận đã có sẵn video. Khi "cold node" không còn ai xem, nó tự động ngắt kết nối Midgress, triệt tiêu hàng ngàn đường kéo dữ liệu thừa thãi.

Chiến thuật 4: Dàn quân sang hạ tầng giá rẻ (Hot Stream Offloading)

• Vấn đề: Khi phiên live 2 triệu view đã dồn thành công về các "hot node" thuộc Layer 1, các cụm máy chủ đắt tiền này sẽ đối mặt với nguy cơ quá tải băng thông Egress.
• Cách giải: Khi luồng đã đủ "nóng", HCDN đẩy bớt (Offload) traffic sang tầng Layer 0.5 (Alternative Edge). Vì luồng này quá phổ biến, các máy chủ Layer 0.5 giá rẻ chỉ tốn đúng 1 lần kéo dữ liệu ban đầu, nhưng lại gánh được hàng trăm ngàn lượt xem đầu ra với đơn giá Egress cực kỳ ưu đãi.

Biết được 4 chiến thuật trên là một chuyện, nhưng làm sao để vận hành hàng ngàn quy tắc điều phối này trên hàng ngàn cụm máy chủ toàn cầu mà không làm sập hệ thống hay làm phình bộ nhớ máy chủ trung tâm?

5. Kết quả thực nghiệm: Tối ưu 36% chi phí mà không gãy hệ thống

Nắn dòng trên lý thuyết là một chuyện, nhưng vận hành nó trên hàng ngàn cụm Edge Cluster liên tục lại là câu chuyện hoàn toàn khác. Để tránh rủi ro sập hệ thống mỗi khi cập nhật quy tắc nắn dòng, ByteDance chọn tư duy "Code không chạm lõi" qua bộ điều phối OpenTiga:

• Tách biệt tuyệt đối: Khung CDN lõi (C++/Go) được giữ cố định. Toàn bộ quy tắc nắn dòng được viết bằng Lua Script siêu nhẹ. Cần đổi chiến thuật cho sự kiện live 2 triệu view? Chỉ cần đẩy script mới lên, không phải biên dịch lại hay restart máy chủ.
• Tối ưu tài nguyên: Hệ thống chỉ lưu dữ liệu chi tiết cho luồng nóng, luồng lạnh chỉ lưu dữ liệu thô. Nhờ đó, bộ nhớ RAM của Controller trung tâm chỉ tốn dưới 270 MB, còn băng thông điều khiển chiếm chưa tới 150 Mbps.

Kết quả thực chiến ấn tượng từ báo cáo NSDI (Trung tâm hạ tầng dữ liệu không gian địa lý quốc gia):

• Giảm 33% Midgress: Chỉ số MER giảm từ 0.30 xuống 0.20 (cắt bỏ 1/3 lượng dữ liệu kéo nội bộ lãng phí)
• Giảm 32% đơn giá Egress: Nhờ đẩy bớt luồng nóng sang máy chủ giá rẻ Layer 0.5.
• Giảm 36% tổng chi phí băng thông tương đối: Tiết kiệm hàng chục triệu USD mỗi năm ở quy mô toàn cầu mà trải nghiệm người xem (QoE) vẫn mượt mà tuyệt đối.

6. Lời kết

Nhìn lại toàn bộ hành trình, chúng ta đã đi qua một chuỗi tư duy kiến trúc cực kỳ chặt chẽ - từ bài toán rải mỏng traffic, phân diện Egress/Midgress, Proactive QA cho đến 4 chiến thuật HCDN.

Toàn bộ giải pháp hạ tầng này đã giúp TikTok xử lý trơn tru bài toán phân phối luồng phát video cho 2 triệu view mà vẫn tiết kiệm tới 36% chi phí băng thông.

Nhưng toàn bộ những phần trên, vẫn chỉ là MỘT NỬA BÀI TOÁN, thậm chí còn là một nửa dễ dàng.

Chúng ta chỉ vừa giải quyết được luồng Hình ảnh & Âm thanh (Media Fan-out). Nhưng còn hàng trăm nghìn comment đẩy lên mỗi giây, mưa thả tim dồn dập và hiệu ứng quà VIP, tặng hoa tràn ngập màn hình thì sao?

Hẹn gặp lại anh em ở Phần 2 nhé!

Author: DucNT

Một buổi chiều, bạn dựng thử tính năng có AI. Chạy mười lần đúng chín. Demo xong, câu trả lời cho "bao giờ xong?" là "một tháng, còn vài ca lẻ".

Ba tháng sau vẫn "còn vài ca lẻ". Sáu tháng sau vẫn thế — nhưng là ca khác. Sang năm thứ hai, vẫn "gần xong".

Chuyện này có quy luật. Bài viết nói về quy luật đó, cách đo cho đúng, và cuối bài: model 2026 mạnh hơn hẳn thì quy luật còn đúng không.

1. Đơn vị đo: "số 9"

Phần mềm thường chạy chắc chắn — cùng đầu vào luôn ra cùng kết quả. Hệ thống AI thì chỉ có tỷ lệ. Nên câu hỏi đúng là "đúng bao nhiêu phần trăm số lần", và thêm một số 9 = chia lỗi cho 10.

Hệ thống 1 triệu lượt/ngày:

90%     ████████████████████████████████████████  100.000 lỗi/ngày
99%     ████                                       10.000
99,9%   ▌                                            1.000
99,99%  ▏                                              100

Người dùng thử vài chục lần thấy 99% và 99,9% giống hệt nhau. Với vận hành, đó là 9.000 sự cố mỗi ngày. Nên báo cáo bằng số lỗi tuyệt đối, đừng báo cáo bằng phần trăm.

2. Quy luật

Andrej Karpathy, 5 năm phụ trách mảng tự lái của Tesla: "Every single nine is a constant amount of work."

Từ khoá là march — hành quân, chặng nào cũng dài như chặng nào. Hình dung phổ biến thì ngược lại: về đích, được 90% rồi thì phần còn lại phải ngắn.

Đội Autopilot của Tesla, 2017–2022, đi được 2–3 số 9 trong 5 năm.

Đây là quan sát từ thực tế vận hành, không phải định lý.

3. Vì sao lúc nào cũng thấy "gần xong"

4. Agent nhiều bước: lỗi nhân lên

Mọi bước phải đúng thì cả việc mới xong, nên xác suất nhân với nhau.

Mỗi bước 99% nghe giỏi, nhưng việc 20 bước chỉ xong 81,8% — cứ 5 lần chạy hỏng 1. Tính ngược: muốn việc 20 bước đạt 99% thì mỗi bước phải đạt 99,95%.

Cắt bớt một bước thường rẻ hơn làm từng bước giỏi thêm một số 9.

Điều kiện: phép nhân chỉ đúng khi các bước không ảnh hưởng nhau. Thực tế bước 2 sai thì bước 3, 4, 5 sai theo — nên đây là mốc hình dung, không phải dự báo.

5. Đo: pass@k và pass^k

• pass@k — đúng ít nhất một lần trong k lần. Che lỗi.
• pass^k — đúng cả k lần. Đo độ ổn định.

Số thật từ τ-bench: agent dùng GPT-4o ở mảng bán lẻ, đòi đúng cả 8 lần thì còn ~25% — giảm khoảng 60% so với chính nó khi đo một lần. Cùng agent, cùng bộ việc, chỉ đổi cách đo.

Chạy mỗi trường hợp 8 lần trong một cấu hình cố định, ghi 1/0, rồi phân loại:

Dãy 1 0 1 1 1 0 1 1 = 75% khi đo một lần, 0% khi đòi đúng cả 8.

6. Việc nào code làm được thì đừng giao cho AI

Với AI, "sửa" thường chỉ là dịch chỗ lỗi sang chỗ khác: sửa prompt cho đúng ca A thì ca B đang đúng có thể bắt đầu sai. Đổi model là dịch chỗ lỗi trên toàn hệ thống.

Nên: việc nào máy làm chắc chắn được thì để máy làm, đừng giao cho AI đoán.

• Sai: nhờ model tính tổng tiền rồi ghi thẳng vào cơ sở dữ liệu.
• Đúng: model trích mã sản phẩm và số lượng; code tra giá, tính tiền, kiểm hợp lệ rồi mới ghi.
• Rẻ nhất: nhờ AI viết ra quy tắc (ví dụ ORD-\d{5}\b) rồi để máy chạy quy tắc — chạy triệu lần vẫn một kết quả.

Cảnh báo kèm theo: chạy chắc chắn không có nghĩa là chạy đúng. Quy tắc sai sẽ lặp lại cái sai rất ổn định — nhưng nó lộ ra ngay trên bộ trường hợp đã chuẩn bị.

Mỗi việc chuyển từ AI sang code là bỏ hẳn một mặt trận số 9.

7. Chọn mức, rồi chọn điểm dừng

Đọc ngược từ cột cuối: chịu được hậu quả nào thì chọn mức thấp nhất tương ứng.

                số 9 thứ 2   thứ 3    thứ 4    thứ 5
công phải bỏ    ████████   ████████ ████████ ████████
giá trị thu về  ████████   █████    ██       ▌
                                      ↑ điểm dừng

Và khoản hay bị quên — chi phí chứng minh: để tin 95% rằng mình đạt mục tiêu, cần ~299 lần chạy không lỗi cho 99%, ~2.995 cho 99,9%, ~29.956 cho 99,99%. Mỗi số 9, chi phí chứng minh nhân mười.

8. Model 2026 thì quy luật còn đúng không?

Chi tiết hay bị bỏ qua: METR đo ở mức đúng 50% số lần — làm đúng một nửa số lần còn chưa tới số 9 đầu tiên. Khoảng từ đó tới 99% chính là march of nines.

Model mạnh lên dịch điểm xuất phát, không đổi độ dốc.

Nâng model có làm tụt độ tin cậy không? Có, ở ba chỗ:

1. Lỗi đổi chỗ — trung bình cao hơn không bảo đảm cao hơn ở mọi nhóm ca của bạn.
2. Việc được giao dài hơn — nhiều bước hơn thì nhân lỗi nhiều hơn.
3. Ít chốt chặn của người hơn — lỗi đi xa hơn trước khi bị bắt.

Nên coi mỗi lần nâng model là một lần phát hành: chạy lại bộ trường hợp cố định, so pass^k trước/sau theo từng nhóm, đừng nhìn điểm trung bình.

9. Đúc kết

Bốn sai lầm: hứa ngày dựa trên demo 90% · cố đạt 99,99% cho việc chỉ cần 99% · dùng AI cho phần code làm chắc chắn được · đo một lần rồi gọi đó là độ tin cậy.

Ba điều mang đi:

1. Demo 90% chỉ là số 9 đầu tiên.
2. Agent nhiều bước nhân lỗi — đo bằng pass^k, chọn sẵn điểm dừng.
3. Số 9 rẻ nhất ở nơi kiểm được.

Một câu nếu chỉ nhớ một câu: hãy làm cho công việc của bạn dễ kiểm hơn.

Tham khảo

• Karpathy — Dwarkesh Podcast (10/2025): https://www.dwarkesh.com/p/andrej-karpathy
• Karpathy — Sequoia Ascent 2026: https://karpathy.bearblog.dev/sequoia-ascent-2026/
• Yao et al. — τ-bench (arXiv 2406.12045): https://arxiv.org/abs/2406.12045
• Sierra — Benchmarking AI agents: https://sierra.ai/blog/benchmarking-ai-agents
• METR — Time horizons: https://metr.org/time-horizons/
• Google SRE — Embracing Risk: https://sre.google/sre-book/embracing-risk/

Khi bạn gõ một địa chỉ web và nhấn Enter, cảm giác rất kỳ diệu: trình duyệt hỏi, server đáp, mọi thứ xong xuôi trong chớp mắt. Nhưng phía sau hậu trường, request của bạn không hề đi "đường thẳng". Nó phải chạy qua một loạt các "trạm trung chuyển" trước khi chạm đến đích: phân giải DNS (đã là một tầng chia tải), định tuyến anycast tới PoP gần nhất, CDN trả lời luôn nếu là nội dung tĩnh, rồi mới tới lượt các trạm bên trong hệ thống.

Bài viết này sẽ tập trung vào phần "bên trong": proxy, load balancer, API gateway — những trạm sau khi request đã tới được hệ thống của bạn.

Mỗi công cụ sinh ra để giải quyết đúng "nỗi đau" mà giai đoạn trước để lại:

Chúng ta hãy cùng bóc tách từng trạm một nhé.

Phần 1. Proxy — Những "Người gác cổng" của Internet

Dù mang tên gì, bản chất của mọi loại proxy đều làm đúng một việc: đứng ở giữa để đánh chặn (intercept) và chuyển tiếp (forward) request. Điểm khác biệt duy nhất  — nằm ở câu hỏi: nó quay mặt về phía ai ?

• Nếu nó quay mặt về phía người dùng — giúp giấu họ, hoặc kiểm soát họ đi đâu — đó là Forward Proxy.
• Nếu nó quay mặt về phía hệ thống của mình — bảo vệ server, gánh việc nặng, chia traffic — đó là Reverse Proxy.

1.1 Forward Proxy — đại diện cho phía Client

Forward Proxy là server đứng giữa máy tính của bạn và mạng Internet.

[Bạn] --> [Forward Proxy] --> [ Internet ] --> [Website]

Khi bạn lướt web qua Forward Proxy, trang web đầu bên kia chỉ nhìn thấy IP của proxy chứ không thấy IP thật của bạn. Tuy nhiên, proxy không đồng nghĩa với ẩn danh hoàn toàn: nó có thể gửi IP gốc qua header như X-Forwarded-For, trong khi cookie và fingerprint trình duyệt vẫn có thể nhận diện bạn. Hơn nữa, proxy vẫn biết bạn là ai và đang truy cập gì — bạn chỉ đang chuyển niềm tin từ website sang chủ sở hữu proxy.

Trong các doanh nghiệp, người ta hay dùng Transparent Proxy. Cơ chế của nó là: việc bẻ hướng traffic diễn ra ở tầng Network (router đẩy toàn bộ port 80/443 sang proxy bằng policy routing hoặc iptables -j REDIRECT), nhưng bản thân proxy vẫn đọc HTTP ở tầng 7 để lọc URL. Nhờ vậy nó ép được toàn bộ thiết bị trong công ty tuân thủ luật kiểm duyệt mạng mà không cần cấu hình thủ công trên từng máy — nhân viên thậm chí không biết là traffic của mình đang đi qua proxy.

1.2 Reverse Proxy — Vệ sĩ của Server

Reverse Proxy thì lật ngược ván cờ lại. Nó đứng giữa Internet và cụm server của bạn, thay mặt hệ thống đứng ra hứng mọi "viên đạn" (request) từ bên ngoài bắn vào. Client không biết mình đang nói chuyện với ai phía sau.

[Client] --> [ Internet ] --> [Reverse Proxy] --> [Server của bạn]

Đây là thành phần bạn sẽ gặp trong gần như mọi hệ thống production, vì nó gánh cùng lúc bốn việc:

1. Che giấu mục tiêu: Backend không có public IP, chỉ nằm trong private subnet. Kẻ tấn công không có mục tiêu trực tiếp để nhắm DDoS.
2. Đỡ đạn SSL (SSL Termination): Lý do không đơn giản là "giải mã HTTPS tốn CPU". Với CPU hiện đại có hardware acceleration như AES-NI, symmetric encryption/decryption tương đối rẻ. Chi phí đáng chú ý hơn thường nằm ở việc thiết lập connection mới và TLS handshake. Lý do chính để terminate TLS tại Reverse Proxy là:

• Quản lý certificate tập trung: chỉ cần gia hạn và quản lý certificate tại một nơi thay vì từng service.
• Tái sử dụng kết nối — proxy giữ sẵn connection pool keep-alive tới backend, backend không phải handshake lại liên tục.

3. Phân tải nhẹ (Load Balancing): Chia đều khách cho các server phía sau.

4. Caching: Nhớ sẵn các nội dung tĩnh (ảnh, CSS) và trả về luôn cho khách mà không làm phiền backend.

Tóm lại: Forward Proxy đại diện cho phía Client. Reverse Proxy đại diện cho phía Server.

Phần 2. Load Balancer — chia tải ở tầng nào?

Đến đây dễ nảy ra một câu hỏi: Reverse Proxy đã chia tải được rồi, vậy Load Balancer là con gì khác?

Câu trả lời hơi phản trực giác: không khác. Nginx, HAProxy, Envoy vừa là Reverse Proxy vừa là Load Balancer — đó là hai vai trò trên cùng một tiến trình, không phải hai thiết bị. "Reverse Proxy" mô tả việc nó đứng thay mặt server; "Load Balancer" mô tả việc nó chia request cho nhiều server.

Vậy thứ thực sự phân biệt là gì? Là nó đọc được đến tầng nào của gói tin — và từ đó, nó chia tải dựa trên thông tin gì.

• Chỉ đọc IP và port → L4, nhanh, mù nội dung.
• Đọc được URL, header, cookie → L7, chậm hơn, nhưng định tuyến theo nghiệp vụ được.

Trong hệ thống lớn, hai tầng này thường xếp chồng chứ không thay thế nhau: L4 quyết định "connection này về Proxy nào", L7 quyết định "request này về Service nào".

2.1 Chia tải ở tầng 4 — Kẻ "mù chữ" siêu tốc độ

L4 hoạt động ở tầng Transport (TCP/UDP). Nó giống như một nhân viên điều phối giao thông bận rộn: chỉ nhìn đúng IP và Cổng (Port) rồi vẫy xe đi tiếp. Nó hoàn toàn không thèm đọc xem bên trong gói tin chứa nội dung gì.

Nghe có vẻ ngốc nghếch, nhưng sự "mù tịt" đó tạo ra tốc độ kinh hoàng. Vì không mất thời gian mở gói tin ra đọc, L4 tốn cực ít CPU và gánh được hàng triệu kết nối cùng lúc. Bạn bắt buộc phải dùng L4 khi:

• Giao thức không phải HTTP: SSH, SMTP, Redis (RESP), game server dùng UDP.
• TLS passthrough: khi backend cần tự xác thực client certificate (mTLS), proxy không được phép giải mã ở giữa.
• Tầng ngoài cùng của hệ thống lớn: L4 hứng toàn bộ traffic vào rồi phân phối cho cụm L7 phía sau.

2.2 Chia tải ở tầng 7 — Bộ não định tuyến thông minh

L7 hoạt động ở tầng Application (HTTP/HTTPS). Trái với L4, nó mở tung gói tin ra để đọc. Nó có thể nhìn vào URL Path, HTTP Headers và Cookies để định tuyến thông minh..

Ví dụ kinh điển là chia route theo URL:

• Khách vào /api/users/* ➔ Mời sang cụm User Server.
• Khách vào /api/orders/* ➔ Mời sang cụm Order Server.
• Khách vào /static/* ➔ Chuyển luôn thẳng ra CDN.

Cái giá phải trả không nằm ở phép giải mã — như đã nói ở Phần 1, symmetric decryption với AES-NI khá rẻ. Chi phí thật của L7 là: phải parse toàn bộ cú pháp HTTP, phải buffer request body trước khi định tuyến, và phải giữ state cho từng request thay vì từng connection. Cộng thêm việc L7 buộc phải terminate connection nên gánh trọn TLS handshake, trong khi L4 passthrough thì không.

2.3 Chia request cho ai? (Thuật toán điều phối)

Chọn được tầng rồi, câu hỏi tiếp theo là: trong cụm server phía sau, request này nên đi về máy nào? Có ba nhóm thuật toán.

• Static (Tĩnh) — Round Robin. Chia request tuần tự theo vòng lặp: máy 1, máy 2, máy 3, rồi quay lại máy 1. Ưu điểm là cực kỳ dễ triển khai. Nhược điểm là nó chia đều một cách máy móc, nên vẫn có thể gây quá tải nếu không giám sát tốt — chẳng hạn khi một máy nhận toàn request nặng còn máy khác toàn request nhẹ.
• Dynamic (Động) — Least Connections. Ưu tiên đẩy request về server đang có ít kết nối mở nhất. Vì nhìn vào tình trạng thực tế của từng máy tại thời điểm đó, cách chia này sát với công suất thực tế hơn nhiều. Nhưng nó cũng có tử huyệt riêng: một server đang lỗi và trả 500 tức thì sẽ đóng connection rất nhanh, nên trông như đang rảnh nhất và bị dồn thêm traffic. Con máy hỏng nhất lại hút nhiều request nhất. Vì vậy Least Connections luôn phải đi kèm health check để loại máy hỏng ra khỏi pool, chứ không dùng một mình.
• Hash-based — hash(source_IP) % N hoặc hash(session_id) % N. Dùng khi cần sticky session: cùng một user phải luôn về đúng một máy, chẳng hạn khi session được lưu in-memory. Ưu điểm là không cần lưu bảng ánh xạ ở đâu cả, cứ tính là ra.

Nhóm thứ ba này có một tử huyệt chết người nằm ngay trong công thức của nó. Chúng ta sẽ gặp lại nó ở Phần 4.

Phần 3. Khi hệ thống thành Microservices — API Gateway vào cuộc

Khi hệ thống lớn lên và chia nhỏ thành nhiều Microservices (Backend 1 lo user, Backend 2 lo thanh toán...), nếu Client gọi trực tiếp từng backend thì sẽ cực kỳ hỗn loạn, khó bảo mật và khó quản lý. Ta cần một "người gác cổng" đứng ra hứng mọi đạn pháo và phân loại

API Gateway sinh ra để giải quyết chuyện đó. Hãy hình dung nó như một lễ tân thông minh của tòa nhà: khách chỉ cần đến quầy lễ tân, không cần biết phòng ban nào nằm ở tầng mấy.

API Gateway làm gì?

1. Single Point of Entry. Nó là điểm truy cập duy nhất cho Client, giúp che giấu toàn bộ cấu trúc mạng phức tạp của các dịch vụ backend. Bạn tách service, gộp service, đổi địa chỉ — client không hề hay biết.

2. Authentication & Rate Limiting. Nó thực hiện xác thực tập trung, và kiểm tra giới hạn số request theo IP và Session để chống DDoS. Thay vì mỗi service tự viết logic auth, tất cả gom về một chỗ.

3. Protocol Translation. Nó chuyển đổi giao thức giữa hai thế giới: nhận HTTP/REST từ client (thứ trình duyệt nói được) và dịch sang gRPC để giao tiếp với backend (thứ nhanh hơn cho internal service).

4. Circuit Breaking. Đây là tính năng cứu mạng hệ thống. Khi một backend bắt đầu lỗi, Gateway sẽ ngắt mạch tự động, ngừng gửi request tới nó. Nhờ vậy một service chết không kéo sập cả hệ thống theo hiệu ứng dây chuyền.

Vậy API Gateway khác gì Load Balancer?

Cả hai đều đứng trước backend và đều nhận request, nhưng mục đích khác hẳn:

Nói ngắn gọn: Load Balancer lo tải, API Gateway lo luật và định tuyến nghiệp vụ. Trong thực tế chúng thường đứng cạnh nhau, không thay thế nhau.

Phần 4. Consistent Hashing — Chia dữ liệu

Bạn biết cách chia traffic rồi, giờ tới bài toán đau đầu hơn: Chia dữ liệu.

Giả sử bạn có 4 con server Cache. Khi một request xin dữ liệu tới, làm sao biết dữ liệu đó đang nằm ở con số mấy?

Cách "ngây thơ" nhất là chia lấy dư (Simple Hashing): vị_trí = hash(key) % 4.

Chạy rất ngon! Cho đến một ngày hệ thống quá tải, bạn cắm thêm con server thứ 5. Mẫu số chia đổi từ 4 thành 5. Bùm! 80% dữ liệu bị tính sai vị trí. Cache miss hàng loạt, Database bị dội bão request và hệ thống của bạn chìm trong biển lửa.

Vòng tròn băm (Consistent Hashing) sinh ra để vá lỗi này.

Thay vì chia lấy dư, người ta bẻ một trục đường thẳng thành một vòng tròn (Hash ring). Sau đó, họ ném cả IP của Server lẫn Dữ liệu (Key) lên cái vòng tròn đó.

Quy tắc tìm đồ cực kỳ thông minh:

1. Đứng từ vị trí của Dữ liệu (Key) trên vòng tròn.
2. Cứ đi bộ theo chiều kim đồng hồ.
3. Vấp phải con Server nào đầu tiên — thì dữ liệu nằm ở đó!

Cái đỉnh cao của Consistent Hashing là gì? Khi bạn thêm hoặc rút một Server, chỉ những dữ liệu nằm trong cung tròn của nó bị ảnh hưởng. Cụ thể, thêm 1 node vào N node có sẵn thì chỉ khoảng 1/(N+1) dữ liệu phải chuyển nhà:

Nhưng vòng tròn thuần có một lỗ hổng chết người. Khi một server chết (khác với việc bạn chủ động thêm vào), toàn bộ cung tròn của nó dồn hết sang đúng một hàng xóm kế tiếp theo chiều kim đồng hồ. Hàng xóm đó vừa gánh phần mình vừa gánh phần người chết → nó cũng gục → lại dồn tiếp sang người thứ ba. Đây là cascading failure.

Virtual Nodes chính là lời giải cho lỗi này — không phải một "mẹo nhỏ" cho đẹp. Mỗi server vật lý được nhân bản thành hàng trăm vị trí ảo rải khắp vòng tròn. Nhờ vậy khi một node chết, tải của nó được rải đều ra tất cả node còn lại thay vì dồn vào một máy duy nhất.

Bản Đồ Ghi Nhớ (Cheat Sheet)

Và mạch logic xuyên suốt: giấu và trung chuyển (Proxy) → chia tải (Load Balancer) → quản lý luật chơi (API Gateway) → chia dữ liệu (Consistent Hashing).

Bạn không cần triển khai cả bốn thứ ngay từ đầu. Thực tế trên cloud, một dòng Terraform tạo ALB đã có sẵn Reverse Proxy, L7 Load Balancer, TLS Termination và Health Check — tất cả nằm trong một “hộp đen”.

Vì vậy, điều quan trọng không phải là tự xây lại chúng, mà là hiểu hộp đen đang làm gì để biết phải nhìn vào đâu khi có sự cố.

"Agent của mình mất 45 giây để trả lời câu hỏi 'Đà Lạt hôm nay thế nào?'. Không biết lỗi ở model, ở tool, hay ở đâu." — Câu này mình nghe từ không ít anh em đang build AI Agent. Và câu trả lời thường là: đoán mò, rồi đổi model, rồi tinh chỉnh prompt, rồi vẫn chậm.

Bài này mình sẽ chỉ cách dùng OpenTelemetry để không phải đoán nữa. Nhìn vào một cái dashboard là biết ngay lỗi nằm ở tầng nào, mất bao nhiêu giây ở bước nào, và dữ liệu đầu vào của model có đúng không.

Mình sẽ demo bằng Python (FastAPI + OpenAI SDK), viết tay từng span để bạn hiểu rõ cơ chế — không phải magic box auto-instrument.

Vấn đề: tại sao print() không đủ để debug AI Agent?

Khi build một ứng dụng web thông thường, print() hay structured log là đủ.
Nhưng AI Agent không phải là một hàm đơn — nó là một chuỗi nhiều tầng lồng nhau:

User request
  → LLM call lần 1 (gpt-4o-mini đọc câu hỏi, quyết định cần tool gì)
      → finish_reason = "tool_calls" → model muốn gọi tool
          → execute_tool get_weather(city="Đà Lạt")   ← có thể chậm ở đây
          → execute_tool search_flights(origin=...)    ← hoặc ở đây
      → LLM call lần 2 (tổng hợp kết quả tool → câu trả lời cuối)
  → Response trả về user

Khi Agent chậm hoặc trả lời sai, nguyên nhân có thể nằm ở bất kỳ tầng nào:

Giờ thử tưởng tượng bạn debug với print():

# Cách debug "dân gian" — mình đã từng làm đúng kiểu này
print(f"Gọi LLM lần 1...")
t0 = time.time()
response = client.chat.completions.create(...)
print(f"LLM xong: {time.time() - t0:.2f}s")

print(f"Gọi tool get_weather...")
t1 = time.time()
result = get_weather(city)
print(f"Tool xong: {time.time() - t1:.2f}s")

Output trong terminal:

Gọi LLM lần 1...
LLM xong: 0.62s
Gọi tool get_weather...
Tool xong: 6.10s        ← okay, chậm ở đây
Gọi LLM lần 2...
LLM xong: 0.91s

Với Agent đơn giản 2 bước thì okay, nhưng khi Agent có 5-10 tool, retry logic, multi-step planning, parallel tool calls... bạn phải:

• Tự time.time() ở khắp nơi trong codebase
• Tự tạo correlation ID để ghép log của cùng 1 request
• Tự tính tổng thời gian từng tầng
• Không có cách nào so sánh request này với request trước một cách trực quan
• Khi deploy production, log sẽ đến từ nhiều process/pod — ghép lại càng khó hơn

Đây chính xác là bài toán mà Distributed Tracing ra đời để giải quyết — và OpenTelemetry là chuẩn mở để làm điều đó.

OpenTelemetry và GenAI Semantic Conventions — nền tảng cần biết

OpenTelemetry là gì?

OpenTelemetry (OTel) là một dự án của CNCF (Cloud Native Computing Foundation) — nơi Google, Microsoft, AWS, Datadog và hàng chục công ty khác cùng đóng góp. Nó định nghĩa:

1. API — interface chuẩn để instrument code (tạo span, gắn attribute...)
2. SDK — implementation cho từng ngôn ngữ (Python, Go, Java, JS...)
3. OTLP — giao thức truyền tải telemetry data (OpenTelemetry Protocol)
4. Semantic Conventions — quy ước đặt tên attribute để mọi công cụ hiểu nhau

OTel thu thập 3 loại tín hiệu:

Bài này sẽ tập trung vào Trace — thứ hữu ích nhất để debug AI Agent.

OTLP — giao thức gửi dữ liệu đi đâu cũng được

Điểm mạnh lớn nhất của OTel là vendor-neutral. App của bạn chỉ cần nói ngôn ngữ OTLP — rồi muốn gửi đến đâu cũng được:

App (Python + OTel SDK)
  │  OTLP gRPC :4317 / HTTP :4318
  ▼
┌──────────────────────────────────────────────┐
│  Aspire Dashboard   — dev local, 1 docker run│
│  Jaeger             — self-hosted, miễn phí  │
│  Grafana + Tempo    — production stack       │
│  Datadog / New Relic — cloud, có GenAI view  │
└──────────────────────────────────────────────┘

Muốn đổi từ Aspire Dashboard sang Datadog? Chỉ đổi biến môi trường OTEL_EXPORTER_OTLP_ENDPOINT. Không sửa một dòng code app.

GenAI Semantic Conventions

Nếu OTel là "chuẩn chung cho observability", thì GenAI Semantic Conventions là "chuẩn con dành riêng cho AI/LLM". Nó định nghĩa tên span và attribute chuẩn cho model, agent, và tool.

Thay vì mỗi team tự đặt tên theo ý mình:

# Team A
span.set_attribute("model_name", "gpt-4o-mini")
span.set_attribute("tokens_in", 142)

# Team B
span.set_attribute("llm.model", "gpt-4o-mini")
span.set_attribute("prompt_tokens", 142)

Tất cả đều dùng gen_ai.*:

# Chuẩn GenAI Semantic Conventions — mọi tool đều hiểu
span.set_attribute("gen_ai.request.model", "gpt-4o-mini")
span.set_attribute("gen_ai.usage.input_tokens", 142)

Kết quả: Datadog, Grafana, Aspire Dashboard đều hiển thị đúng — không cần cấu hình gì thêm.

3 nhóm span chính:

Các attribute quan trọng nhất cần biết

Trước khi vào code, mình tổng hợp các gen_ai.* hay dùng nhất — đây là thứ bạn sẽ nhìn vào mỗi khi debug:

Trên span chat (LLM call)

finish_reasons=["length"] là một trong những lỗi phổ biến nhất — Agent trả lời thiếu, bị cắt giữa câu, mà dev cứ nghĩ do model không hiểu prompt. Thực ra chỉ cần tăng max_tokens.

Trên span execute_tool (tool call)

Demo thực tế: instrument Travel Agent từng bước

Mình sẽ build một Travel Agent — nhận câu hỏi về thời tiết và chuyến bay, gọi OpenAI, gọi tool, rồi trả lời. Toàn bộ code chạy được ngay.

Setup môi trường

pip install openai fastapi uvicorn python-dotenv \
    opentelemetry-api==1.27.0 \
    opentelemetry-sdk==1.27.0 \
    opentelemetry-exporter-otlp==1.27.0 \
    opentelemetry-instrumentation-fastapi==0.48b0 \
    httpx==0.27.2   # pin version tránh conflict với openai SDK

Tạo file .env:

OPENAI_API_KEY=sk-your-key-here
OPENAI_MODEL=gpt-4o-mini
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=travel-agent

# Bật để xem nội dung prompt/response trong trace (chỉ dùng khi dev!)
OTEL_GENAI_CAPTURE_CONTENT=true

# Cờ để giả lập lỗi khi muốn test
SIMULATE_SLOW_TOOL=false
SIMULATE_WRONG_DATA=false

Khởi động Aspire Dashboard — không cần tài khoản cloud, không cần config gì:

docker run -d \
  --name aspire-dashboard \
  -p 18888:18888 \
  -p 4317:18889 \
  -e ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS=true \
  mcr.microsoft.com/dotnet/aspire-dashboard:latest

Mở http://localhost:18888 — dashboard đang chờ nhận trace.

Bước 1 — Khởi tạo OTel SDK

# otel_genai.py
import os, time, json, contextlib
from typing import Any

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.trace import SpanKind, Status, StatusCode

CAPTURE_CONTENT = os.getenv("OTEL_GENAI_CAPTURE_CONTENT", "false").lower() == "true"
OTLP_ENDPOINT   = os.getenv("OTEL_EXPORTER_OTLP_ENDPOINT", "http://localhost:4317")
SERVICE_NAME     = os.getenv("OTEL_SERVICE_NAME", "travel-agent")


def setup_tracing() -> trace.Tracer:
    resource = Resource.create({
        "service.name": SERVICE_NAME,
        "service.version": "1.0.0",
    })
    provider = TracerProvider(resource=resource)

    exporter = OTLPSpanExporter(endpoint=OTLP_ENDPOINT, insecure=True)

    # BatchSpanProcessor: gom span gửi theo lô, async — overhead < 1ms/span
    # Dùng SimpleSpanProcessor nếu muốn gửi ngay (chỉ khi debug OTel)
    provider.add_span_processor(BatchSpanProcessor(exporter))
    trace.set_tracer_provider(provider)

    return trace.get_tracer(SERVICE_NAME)


tracer = setup_tracing()  # chạy 1 lần khi module được import

BatchSpanProcessor là lý do OTel không làm chậm app — nó buffer span trong memory, gom lại gửi theo lô mỗi vài giây. Nếu dùng SimpleSpanProcessor (gửi ngay từng span) thì mỗi request phải chờ network round-trip đến collector — rất tốn latency.

Bước 2 — Tạo 3 context manager cho 3 loại span

Đây là phần lõi. Mình dùng @contextlib.contextmanager để wrap span, Python
tự đóng span khi thoát khỏi with block — kể cả khi có exception:

# ── SPAN 1: invoke_agent ──────────────────────────────────────────────────────
@contextlib.contextmanager
def traced_agent(agent_name: str, user_message: str):
    """Span cha bọc toàn bộ 1 lượt xử lý của Agent."""
    with tracer.start_as_current_span(
        f"invoke_agent {agent_name}",
        kind=SpanKind.INTERNAL,  # INTERNAL: xử lý trong tiến trình
    ) as span:
        span.set_attribute("gen_ai.operation.name", "invoke_agent")
        span.set_attribute("gen_ai.agent.name", agent_name)
        if CAPTURE_CONTENT:
            span.set_attribute("gen_ai.input.messages",
                json.dumps([{"role": "user", "content": user_message}]))
        try:
            yield span
            span.set_status(Status(StatusCode.OK))
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.set_attribute("error.type", type(e).__name__)
            raise


# ── SPAN 2: chat ──────────────────────────────────────────────────────────────
@contextlib.contextmanager
def traced_chat_call(provider: str, model: str, messages: list[dict]):
    """Span bọc 1 lần gọi LLM. Gắn request attribute trước, response sau."""
    start = time.time()
    with tracer.start_as_current_span(
        f"chat {model}",
        kind=SpanKind.CLIENT,   # CLIENT: gọi ra ngoài qua network
    ) as span:
        # Gắn request attribute TRƯỚC khi gọi API
        span.set_attribute("gen_ai.operation.name", "chat")
        span.set_attribute("gen_ai.provider.name", provider)
        span.set_attribute("gen_ai.request.model", model)
        if CAPTURE_CONTENT:
            span.set_attribute("gen_ai.input.messages", json.dumps(messages))

        ctx: dict[str, Any] = {"span": span, "start": start}
        try:
            yield ctx
            span.set_status(Status(StatusCode.OK))
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.set_attribute("error.type", type(e).__name__)
            raise
        finally:
            span.set_attribute("gen_ai.client.operation.duration_s",
                round(time.time() - start, 3))


def record_chat_response(ctx: dict, response) -> None:
    """Gắn response attribute vào span SAU KHI nhận được từ LLM.

    Tách riêng vì token count, finish_reason, response model... chỉ có
    sau khi API trả về — không thể gắn trước khi gọi.
    """
    span = ctx["span"]
    span.set_attribute("gen_ai.response.model", response.model)
    span.set_attribute("gen_ai.response.id", response.id)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.prompt_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.completion_tokens)
    span.set_attribute("gen_ai.response.finish_reasons",
        [c.finish_reason for c in response.choices])

    if CAPTURE_CONTENT:
        output = []
        for choice in response.choices:
            msg = {"role": choice.message.role, "content": choice.message.content}
            if choice.message.tool_calls:
                msg["tool_calls"] = [
                    {"id": tc.id, "name": tc.function.name,
                     "arguments": tc.function.arguments}
                    for tc in choice.message.tool_calls
                ]
            output.append(msg)
        span.set_attribute("gen_ai.output.messages", json.dumps(output))


# ── SPAN 3: execute_tool ──────────────────────────────────────────────────────
@contextlib.contextmanager
def traced_tool_call(tool_name: str, tool_call_id: str, arguments: dict):
    """Span bọc 1 lần thực thi tool. Duration đo riêng, tách biệt khỏi span chat."""
    start = time.time()
    with tracer.start_as_current_span(
        f"execute_tool {tool_name}",
        kind=SpanKind.INTERNAL,
    ) as span:
        span.set_attribute("gen_ai.operation.name", "execute_tool")
        span.set_attribute("gen_ai.tool.name", tool_name)
        span.set_attribute("gen_ai.tool.call.id", tool_call_id)
        if CAPTURE_CONTENT:
            span.set_attribute("gen_ai.tool.call.arguments",
                json.dumps(arguments))

        ctx: dict[str, Any] = {"span": span}
        try:
            yield ctx
            span.set_status(Status(StatusCode.OK))
        except Exception as e:
            span.set_status(Status(StatusCode.ERROR, str(e)))
            span.set_attribute("error.type", type(e).__name__)
            raise
        finally:
            span.set_attribute("gen_ai.client.operation.duration_s",
                round(time.time() - start, 3))


def record_tool_result(ctx: dict, result: Any) -> None:
    if CAPTURE_CONTENT:
        ctx["span"].set_attribute("gen_ai.tool.call.result",
            json.dumps(result, default=str))

Tại sao OTel tự biết span nào là cha/con? Vì start_as_current_span() lưu span hiện tại vào context thread-local của Python. Khi bạn tạo span mới bên trong with của span cha, OTel SDK đọc context đó và tự set parent_id. Không cần truyền gì thủ công.

Bước 3 — Tool definitions và tool functions

# tools.py
import os, time, random

# Cờ để giả lập 2 tình huống lỗi kinh điển — rất hữu ích để demo/test
SIMULATE_SLOW_TOOL  = os.getenv("SIMULATE_SLOW_TOOL", "false").lower() == "true"
SIMULATE_WRONG_DATA = os.getenv("SIMULATE_WRONG_DATA", "false").lower() == "true"


def get_weather(city: str) -> dict:
    if SIMULATE_SLOW_TOOL:
        time.sleep(6)   # giả lập API thời tiết bên ngoài bị nghẽn mạng

    weather_db = {
        "đà nẵng": {"temp_c": 31, "condition": "Nắng nhẹ"},
        "hà nội":  {"temp_c": 24, "condition": "Nhiều mây"},
        "đà lạt":  {"temp_c": 18, "condition": "Mát mẻ, có sương"},
    }
    data = weather_db.get(city.strip().lower(), {"temp_c": 27, "condition": "N/A"})

    if SIMULATE_WRONG_DATA and city.strip().lower() == "đà lạt":
        data = {"temp_c": 35, "condition": "Nắng nóng"}  # sai có chủ đích để demo

    return {"city": city, **data}


def search_flights(origin: str, destination: str) -> dict:
    time.sleep(random.uniform(0.2, 0.5))  # độ trễ thực tế nhỏ, bình thường
    base = random.randint(800_000, 2_500_000)
    return {
        "origin": origin, "destination": destination,
        "flights": [
            {"airline": "VietJet", "price_vnd": base, "duration_min": 75},
            {"airline": "Vietnam Airlines", "price_vnd": base + 350_000, "duration_min": 70},
        ],
    }


TOOL_DEFINITIONS = [
    {"type": "function", "function": {
        "name": "get_weather",
        "description": "Lấy thời tiết hiện tại của một thành phố Việt Nam",
        "parameters": {"type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"]},
    }},
    {"type": "function", "function": {
        "name": "search_flights",
        "description": "Tìm chuyến bay giữa 2 thành phố",
        "parameters": {"type": "object",
            "properties": {
                "origin": {"type": "string"},
                "destination": {"type": "string"},
            },
            "required": ["origin", "destination"]},
    }},
]

TOOL_FUNCTIONS = {"get_weather": get_weather, "search_flights": search_flights}

Bước 4 — Agent loop với span đầy đủ

# agent.py
import json
from openai import OpenAI
from otel_genai import (
    traced_agent, traced_chat_call, record_chat_response,
    traced_tool_call, record_tool_result, CAPTURE_CONTENT,
)
from tools import TOOL_DEFINITIONS, TOOL_FUNCTIONS

client = OpenAI()
MODEL  = "gpt-4o-mini"

SYSTEM_PROMPT = (
    "Bạn là trợ lý du lịch. Khi cần thông tin thời tiết hoặc chuyến bay, "
    "hãy dùng tool — đừng tự đoán. Trả lời ngắn gọn, tiếng Việt."
)


def run_agent(user_message: str) -> str:
    with traced_agent("travel-agent", user_message):   # span cha

        messages = [
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user",   "content": user_message},
        ]

        # LLM lần 1: model đọc câu hỏi → quyết định gọi tool nào
        with traced_chat_call("openai", MODEL, messages) as ctx:
            response = client.chat.completions.create(
                model=MODEL,
                messages=messages,
                tools=TOOL_DEFINITIONS,
            )
            record_chat_response(ctx, response)

        choice = response.choices[0]
        messages.append(choice.message.model_dump(exclude_none=True))

        # Mỗi tool call của model → 1 span execute_tool riêng biệt
        if choice.finish_reason == "tool_calls":
            for tc in choice.message.tool_calls:
                args = json.loads(tc.function.arguments)

                with traced_tool_call(tc.function.name, tc.id, args) as tool_ctx:
                    result = TOOL_FUNCTIONS[tc.function.name](**args)
                    record_tool_result(tool_ctx, result)

                messages.append({
                    "role": "tool",
                    "tool_call_id": tc.id,
                    "content": json.dumps(result, ensure_ascii=False),
                })

            # LLM lần 2: tổng hợp kết quả tool → câu trả lời cuối
            with traced_chat_call("openai", MODEL, messages) as ctx:
                response = client.chat.completions.create(
                    model=MODEL, messages=messages
                )
                record_chat_response(ctx, response)

        return response.choices[0].message.content

Bước 5 — Expose qua FastAPI

# main.py
from fastapi import FastAPI
from pydantic import BaseModel
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from agent import run_agent

app = FastAPI()
FastAPIInstrumentor.instrument_app(app)  # 1 dòng này tự tạo span HTTP cho mọi route

class AskRequest(BaseModel):
    message: str

@app.post("/ask")
def ask(req: AskRequest):
    return {"answer": run_agent(req.message)}

FastAPIInstrumentor tự tạo span POST /ask bao bên ngoài span invoke_agent — nên trên dashboard bạn thấy cả overhead HTTP, không chỉ phần AI.

Chạy thử:

uvicorn main:app --reload --port 8000

curl -X POST http://localhost:8000/ask \
  -H "Content-Type: application/json" \
  -d '{"message": "Đà Nẵng hôm nay thế nào, có chuyến bay tới Hà Nội không?"}'

Đọc trace trên Aspire Dashboard

Giao diện tổng thể:

Sau khi gửi request, mở http://localhost:18888 → tab Traces → click vào trace mới nhất. Bạn sẽ thấy cây span kiểu này:

Phân tích tình huống 1: Agent phản hồi CHẬM

Cài SIMULATE_SLOW_TOOL=true rồi restart server, gửi lại request:

invoke_agent travel-agent   ████████████████████████████████  8.2s
├── chat gpt-4o-mini        ██  0.6s
├── execute_tool get_weather ████████████████████████  6.1s  ← thủ phạm
├── execute_tool search_flights  █  0.4s
└── chat gpt-4o-mini        ███  0.9s

Nhìn vào timeline là biết ngay: tool chậm, không phải model chậm. Nếu không có trace, theo mình estimate khoảng 70% anh em sẽ:

• Thử đổi sang gpt-4o (nhanh hơn nhưng đắt hơn) → không giải quyết gì
• Thử giảm độ phức tạp của prompt → cũng không giải quyết gì
• Sau 2 tiếng vò đầu bứt tai mới nghĩ đến việc check API thời tiết bên ngoài

Với trace, mất 5 giây để biết chính xác. Không cần đoán.

Phân tích tình huống 2: Agent trả lời SAI

Cài SIMULATE_WRONG_DATA=true. Agent sẽ trả lời "Đà Lạt nắng nóng 35°C" — sai thực tế. Hầu hết anh em đầu tiên sẽ nghĩ: model ảo giác (hallucination).

Click vào span execute_tool get_weather → panel attribute → xem gen_ai.tool.call.result:

{"city": "Đà Lạt", "temp_c": 35, "condition": "Nắng nóng"}

Dữ liệu đã sai từ tầng tool, trước khi model nhìn vào. Model chỉ đang tổng hợp trung thực dữ liệu sai nó nhận được. Đây không phải hallucination —
đây là garbage in, garbage out.

Phân biệt được "AI ảo giác thật" vs "dữ liệu tool sai" quyết định bạn sửa ở tầng nào — rất quan trọng khi bàn với PM hay sếp về nguyên nhân sự cố.

Đọc attribute trên span chat

Click vào span chat gpt-4o-mini đầu tiên:

gen_ai.provider.name           = openai
gen_ai.request.model           = gpt-4o-mini
gen_ai.response.model          = gpt-4o-mini-2024-07-18   ← version thật của OpenAI
gen_ai.usage.input_tokens      = 142
gen_ai.usage.output_tokens     = 38
gen_ai.response.finish_reasons = ["tool_calls"]            ← model muốn gọi tool
gen_ai.client.operation.duration_s = 0.623

gen_ai.request.model vs gen_ai.response.model: hai cái này có thể khác nhau vì OpenAI map alias (gpt-4o-mini) sang version cụ thể. Nếu provider có tính năng auto-fallback khi model quá tải, bạn sẽ thấy ngay ở đây — không cần thêm log nào.

Sơ đồ cây span đầy đủ của 1 request

HTTP POST /ask
└── invoke_agent travel-agent          [INTERNAL]   ~8.2s
    │   gen_ai.operation.name   = "invoke_agent"
    │   gen_ai.agent.name       = "travel-agent"
    │
    ├── chat gpt-4o-mini                [CLIENT]     0.6s
    │       gen_ai.provider.name         = "openai"
    │       gen_ai.request.model         = "gpt-4o-mini"
    │       gen_ai.response.model        = "gpt-4o-mini-2024-07-18"
    │       gen_ai.usage.input_tokens    = 142
    │       gen_ai.usage.output_tokens   = 38
    │       gen_ai.response.finish_reasons = ["tool_calls"]
    │
    ├── execute_tool get_weather        [INTERNAL]   6.1s ⚠️
    │       gen_ai.tool.name             = "get_weather"
    │       gen_ai.tool.call.id          = "call_abc123"
    │       gen_ai.tool.call.arguments   = {"city": "Đà Lạt"}
    │       gen_ai.tool.call.result      = {"temp_c": 18, ...}
    │
    ├── execute_tool search_flights     [INTERNAL]   0.4s
    │       gen_ai.tool.name             = "search_flights"
    │       gen_ai.tool.call.id          = "call_def456"
    │
    └── chat gpt-4o-mini                [CLIENT]     0.9s
            gen_ai.usage.input_tokens    = 387
            gen_ai.usage.output_tokens   = 112
            gen_ai.response.finish_reasons = ["stop"]  ← kết thúc bình thường

Chú ý SpanKind: CLIENT cho lời gọi ra ngoài qua network (LLM API), INTERNAL cho xử lý trong tiến trình. Phân biệt này giúp APM tool tự tính đúng network latency vs compute latency.

Thêm Metrics để nhìn xu hướng dài hạn

Trace giúp debug một request cụ thể. Nhưng nếu muốn biết "trong 1 tuần qua, latency LLM có tăng không?" hay "tổng token tiêu tốn mỗi ngày là bao nhiêu?" — bạn cần Metrics.

# metrics_setup.py
from opentelemetry import metrics
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter

def setup_metrics():
    exporter = OTLPMetricExporter(endpoint=OTLP_ENDPOINT, insecure=True)
    reader = PeriodicExportingMetricReader(exporter, export_interval_millis=10_000)
    provider = MeterProvider(resource=resource, metric_readers=[reader])
    metrics.set_meter_provider(provider)
    return metrics.get_meter(SERVICE_NAME)

meter = setup_metrics()

# 2 metric hay dùng nhất theo GenAI Semantic Conventions
token_histogram = meter.create_histogram(
    name="gen_ai.client.token.usage",
    description="Số token sử dụng mỗi LLM call",
    unit="token",
)
duration_histogram = meter.create_histogram(
    name="gen_ai.client.operation.duration",
    description="Thời gian mỗi LLM call",
    unit="s",
)

Ghi metric sau mỗi LLM call:

def record_chat_response(ctx: dict, response) -> None:
    # ... gắn attribute vào span như trước ...

    # Thêm: ghi metric
    labels = {"gen_ai.provider.name": "openai", "gen_ai.request.model": MODEL}
    token_histogram.record(response.usage.prompt_tokens,
        {**labels, "gen_ai.token.type": "input"})
    token_histogram.record(response.usage.completion_tokens,
        {**labels, "gen_ai.token.type": "output"})
    duration_histogram.record(
        time.time() - ctx["start"], labels
    )

Trên Aspire Dashboard (tab Metrics) hoặc Grafana, bạn sẽ thấy:

• Token usage theo thời gian → phát hiện prompt nào đang "ăn" nhiều token bất thường, ảnh hưởng chi phí
• P50/P95/P99 latency của LLM call → phát hiện degradation sớm trước khi user phàn nàn
• Tỷ lệ finish_reason=length → phát hiện khi nào nên tăng max_tokens

Quy tắc đơn giản: 1 request bị lỗi → mở Trace. Xu hướng toàn hệ thống → mở Metrics.

Dùng auto-instrumentation ở dự án thật

Mình viết tay span trong demo để bạn hiểu cơ chế bên trong. Ở dự án thật, có thư viện làm hết việc này tự động:

openinference (Arize Phoenix)

pip install openinference-instrumentation-openai

from openinference.instrumentation.openai import OpenAIInstrumentor
OpenAIInstrumentor().instrument()  # patch OpenAI SDK, tự tạo span cho mọi call

Mọi client.chat.completions.create() từ đây sẽ tự có span đầy đủ với các gen_ai.* attribute — không cần with traced_chat_call(...) nữa.

OpenLLMetry (Traceloop)

pip install traceloop-sdk

from traceloop.sdk import Traceloop
Traceloop.init(app_name="travel-agent")  # 1 dòng duy nhất

Hỗ trợ OpenAI, Anthropic, Cohere, LangChain, LlamaIndex out of the box.

Khi nào nên viết tay, khi nào dùng auto?

4 sai lầm phổ biến mình hay thấy anh em dính

❌ Sai lầm 1: không tách span tool ra khỏi span Agent

Nhiều người wrap traced_agent() rồi thôi, không tạo traced_tool_call() riêng cho mỗi tool. Kết quả trace trông như thế này:

invoke_agent travel-agent   ████████████████████████  8.2s
└── chat gpt-4o-mini        ████████████████████████  7.8s  ← thấy chat "chậm"?

Nhìn vào trace thấy chat tốn 7.8s — nghĩ ngay model chậm. Thực ra 6.1s nằm trong tool call bên trong không được đo riêng nên bị gộp vào thời gian của Agent. Mỗi tool call phải là 1 span riêng — nguyên tắc bất di bất dịch.

❌ Sai lầm 2: bật CAPTURE_CONTENT=true ở production không nghĩ đến privacy

Attribute gen_ai.input.messages, gen_ai.output.messages, và gen_ai.tool.call.result rất hữu ích khi debug nhưng có thể chứa:

• Thông tin cá nhân của user (tên, địa chỉ, lịch sử hội thoại)
• Dữ liệu nhạy cảm từ tool (kết quả query DB, nội dung tài liệu nội bộ)
• Token hoặc credential nếu prompt không được sanitize kỹ

OTel spec thiết kế mặc định không ghi content là vì lý do này. Ở production, nếu muốn bật, cần có cơ chế redact PII trước khi ghi:

import re

def redact_pii(text: str) -> str:
    text = re.sub(r'\b[\w.]+@[\w.]+\.\w+\b', '[EMAIL]', text)         # email
    text = re.sub(r'\b(0[3-9]\d{8}|\+84\d{9})\b', '[PHONE]', text)   # SĐT VN
    text = re.sub(r'\b\d{9,12}\b', '[ID_NUMBER]', text)               # CMND/CCCD
    return text

if CAPTURE_CONTENT:
    span.set_attribute("gen_ai.input.messages",
        redact_pii(json.dumps(messages)))

❌ Sai lầm 3: quên gắn finish_reasons vào span

gen_ai.response.finish_reasons là attribute "chẩn đoán nhanh" quan trọng nhất nhưng hay bị bỏ quên vì cần đọc từ response object sau khi gọi API.

# Hay bị bỏ sót:
span.set_attribute("gen_ai.response.finish_reasons",
    [c.finish_reason for c in response.choices])

Nếu thiếu attribute này, bạn sẽ không phát hiện được khi nào length bắt đầu xuất hiện nhiều trong production — dấu hiệu context window đang ngày càng bị đẩy đến giới hạn, cần xem xét lại chiến lược chunking prompt.

❌ Sai lầm 4: dùng SimpleSpanProcessor ở production

# ❌ Đừng làm vậy ở production
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
provider.add_span_processor(SimpleSpanProcessor(exporter))

# ✅ Luôn dùng BatchSpanProcessor
from opentelemetry.sdk.trace.export import BatchSpanProcessor
provider.add_span_processor(BatchSpanProcessor(exporter))

SimpleSpanProcessor gửi từng span ngay khi span đóng — mỗi request phải chờ network round-trip đến OTLP endpoint. Với Agent có 4-5 span/request, điều này cộng thêm hàng trăm ms latency không cần thiết. BatchSpanProcessor buffer trong memory và gửi async, overhead < 1ms/span.

Tóm tắt

• AI Agent là chuỗi nhiều tầng — LLM, Tool, Orchestration. Lỗi có thể nằm ở bất kỳ đâu, debug bằng print() không scale.

• OpenTelemetry GenAI Semantic Conventions chuẩn hóa cách ghi lại chuỗi đó thành 1 cây trace với tên span/attribute thống nhất (gen_ai.*) — vendor-neutral, dùng được với mọi backend.

• 3 loại span cốt lõi, tách riêng hoàn toàn: invoke_agent (span cha), chat (mỗi lần gọi LLM), execute_tool (mỗi lần chạy tool).

• Nhìn timeline để biết tầng nào chậm. Nhìn finish_reasons để phát hiện câu trả lời bị cắt cụt. Nhìn tool.call.result để phân biệt "AI ảo giác" vs "dữ liệu tool sai".

• Content mặc định không ghi — phải opt-in, cân nhắc redact PII trước khi bật ở production.

• BatchSpanProcessor luôn luôn — overhead < 1ms/span, không làm chậm app.

• Dùng auto-instrumentation (openinference, OpenLLMetry) ở dự án thật để tiết kiệm thời gian, chỉ viết tay khi cần custom logic đặc thù.

Tài liệu tham khảo

Nếu bạn muốn đào sâu hơn, đây là những nguồn mình dùng khi viết bài này — sắp xếp theo thứ tự từ dễ đến khó.

Đọc trước — nền tảng

Đào sâu — GenAI Semantic Conventions

Auto-instrumentation — dùng ở dự án thật

Production stack — khi cần scale

MCP & Multi-agent (hướng nâng cao)

Video & talk

Trong những năm gần đây, các AI coding assistant ngày càng được sử dụng nhiều hơn trong quá trình phát triển phần mềm, từ sinh code, refactoring cho đến code review.

Một cách sử dụng phổ biến là cung cấp git diff hoặc nội dung của Pull Request cho AI và yêu cầu:

Review this change.

Với những thay đổi nhỏ và độc lập, cách tiếp cận này thường mang lại kết quả khá tốt.

Tuy nhiên, khi codebase trở nên lớn hơn và có nhiều dependency giữa các module, chỉ đọc phần code thay đổi thường chưa đủ để đánh giá đầy đủ tác động của một thay đổi.

Một reviewer có thể cần trả lời thêm những câu hỏi như:

• Function được sửa đang được gọi từ đâu?
• Module nào phụ thuộc vào phần code này?
• Thay đổi có ảnh hưởng tới execution flow nào khác không?
• Test nào liên quan tới đoạn code vừa thay đổi?
• Có dependency gián tiếp nào có khả năng bị ảnh hưởng không?

Đây là một trong những thách thức lớn của AI Code Review: không chỉ cần hiểu code thay đổi, mà còn cần có đủ context về codebase xung quanh thay đổi đó.

Trong bài viết này, chúng ta sẽ tìm hiểu một cách tiếp cận sử dụng Code Graph để hỗ trợ quá trình này, thông qua open-source tool Code Review Graph.

1. Giới hạn của việc chỉ review Git Diff

Giả sử một backend NestJS có use case như sau:

@Injectable()
export class UpdateUserEmailUseCase {
  async execute(userId: string, email: string) {
    const user = await this.userRepository.findById(userId);

    user.changeEmail(email);

    await this.userRepository.save(user);
  }
}

Một Pull Request thay đổi logic thành:

user.changeEmail(email.toLowerCase());

Nếu chỉ nhìn vào diff, một reviewer có thể kiểm tra được:

• xử lý null hoặc undefined;
• validation;
• việc sử dụng trim();
• naming;
• coding convention.

Tuy nhiên, để đánh giá tác động của thay đổi này, chúng ta còn cần biết những phần khác của hệ thống đang sử dụng email như thế nào.

Ví dụ, một flow update email có thể đi qua:

UserResolver → UpdateUserEmailUseCase → User.changeEmail

Trong khi flow đăng nhập lại đi qua:

LoginResolver → LoginUseCase → UserRepository.findByEmail

Nếu email được normalize khi update nhưng không được normalize khi login, hệ thống có thể phát sinh hành vi không nhất quán.

Ví dụ:

Stored email:
foo@example.com

Login input:
Foo@Example.com

Result:
User not found

Đây là loại vấn đề khó phát hiện nếu reviewer chỉ quan sát những dòng code xuất hiện trong git diff.

2. AI cần context về dependency

Khi một developer đã làm việc lâu với một hệ thống, họ thường có sẵn một mental model về codebase.

Ví dụ, trong một backend theo hướng DDD, developer có thể hiểu rằng UseCase đóng vai trò orchestration layer: nhận request từ Resolver/Controller, sử dụng Domain để thực thi business rule và gọi Repository để đọc hoặc ghi dữ liệu.

Các thành phần này không nhất thiết tạo thành một pipeline tuyến tính kiểu:

Resolver → UseCase → Domain → Repository → Database

Thay vào đó, một UseCase có thể phối hợp nhiều dependency khác nhau:

Resolver → UseCase → { Domain, Repository, External Service, Event }

Trong đó Repository implementation có thể truy cập Database, còn Event có thể kích hoạt các Handler khác.

Developer cũng thường biết module nào phụ thuộc module nào, event nào được publish sau một thay đổi và test nào thường liên quan tới một flow cụ thể.

AI coding assistant không mặc định có kiến thức này.

Để xây dựng context, agent thường phải:

• đọc git diff;
• tìm identifier;
• đọc caller;
• follow import;
• đọc service liên quan;
• tìm test;
• đọc thêm source code;
• sau đó mới bắt đầu reasoning.

Các coding agent hiện nay có thể thực hiện quá trình trên bằng các công cụ như grep, ripgrep, filesystem search hoặc language server.

Tuy nhiên, với repository lớn, quá trình khám phá dependency này có thể phải lặp lại nhiều lần.

Một hướng tiếp cận khác là xây dựng sẵn một representation của các relationship trong codebase để AI có thể truy vấn khi cần.

3. Nhìn codebase dưới dạng Graph

Khi mở một repository, chúng ta thường nhìn thấy cấu trúc dạng cây:

src/
├── users/
├── authentication/
├── payments/
└── notifications/

Cấu trúc này rất hữu ích để biết source code nằm ở đâu.

Tuy nhiên, relationship thực tế giữa các thành phần trong hệ thống lại gần với một graph hơn.

Ví dụ, một UpdateUserEmailUseCase có thể đồng thời:

• gọi UserRepository.findById() để lấy dữ liệu;
• gọi User.changeEmail() để thực thi business rule;
• gọi UserRepository.save() để persist thay đổi;
• publish một event sau khi update thành công.

Như vậy relationship không đơn giản là:

UseCase → Domain → Repository

mà có thể là nhiều cạnh xuất phát từ cùng một node UseCase.

Trong graph đó, các thành phần có thể được biểu diễn dưới dạng node:

• Function
• Class
• Module
• File
• Test

Relationship giữa chúng có thể trở thành edge:

• CALLS
• IMPORTS
• INHERITS
• IMPLEMENTS
• TESTS
• DEPENDS_ON

Ví dụ, graph có thể biểu diễn các loại relationship khác nhau:

UpdateUserEmailUseCase --calls--> User.changeEmail

UpdateUserEmailUseCase --uses--> UserRepository

TypeOrmUserRepository --implements--> UserRepository

TypeOrmUserRepository --accesses--> PostgreSQL

Điều này phản ánh codebase chính xác hơn một chuỗi tuyến tính đơn giản.

Khi đã có representation này, nhiều câu hỏi về codebase trở thành bài toán graph traversal.

Ví dụ:

Ai đang gọi function X?

Có thể tìm incoming relationships.

Hoặc:

Nếu function X thay đổi, những component nào có khả năng bị ảnh hưởng?

Có thể traverse dependency graph theo hướng ngược lại.

Đây là ý tưởng nền tảng phía sau Code Review Graph.

4. Code Review Graph là gì?

Code Review Graph là một open-source tool xây dựng một structural graph từ source code của repository.

Source code được parse để xác định các relationship như function call, import, inheritance, test relationship và execution relationship.

Ở mức kiến trúc, có thể xem Code Review Graph như một code intelligence layer nằm giữa source code và AI agent.

Mục tiêu không phải thay thế khả năng đọc source code của AI, mà giúp agent xác định:

Phần source code nào cần đọc cho task hiện tại?

Một điểm đáng chú ý khác là graph có thể được cập nhật incrementally khi codebase thay đổi, thay vì phải rebuild toàn bộ repository cho mỗi lần review.

Điều này làm cho graph trở thành một lớp knowledge có thể tái sử dụng cho nhiều task khác nhau.

5. Ví dụ với Next.js và NestJS

Giả sử một hệ thống sử dụng các thành phần sau.

Frontend

• Next.js
• Apollo Client
• GraphQL

Backend

• NestJS Resolver: entry point của GraphQL;
• UseCase: điều phối application flow;
• Domain Entity / Domain Service: chứa business rule;
• Repository Interface: abstraction để UseCase đọc hoặc ghi dữ liệu;
• Repository Implementation: implementation cụ thể bằng TypeORM hoặc công nghệ persistence tương ứng;
• Database: nơi dữ liệu được persist.

Các thành phần backend trên không tạo thành một pipeline tuyến tính cố định.

Trong ví dụ này, UseCase đóng vai trò orchestration layer:

• gọi Repository để load entity;
• gọi Domain Entity để thực thi business logic;
• gọi Repository để persist trạng thái mới;
• và tùy use case có thể gọi thêm event bus hoặc external service.

Giả sử có requirement:

Khi user thay đổi email, hệ thống phải chuyển email về lowercase trước khi lưu.

Developer thay đổi use case:

async execute(userId: string, email: string) {
  const user = await this.userRepository.findById(userId);

  user.changeEmail(email.toLowerCase());

  await this.userRepository.save(user);
}

Đoạn code này thể hiện khá rõ vai trò của từng thành phần:

• UpdateUserEmailUseCase điều phối flow;
• UserRepository.findById() load entity;
• User.changeEmail() thực thi business logic;
• UserRepository.save() persist trạng thái mới.

Repository giúp UseCase không cần biết dữ liệu phía dưới được lưu bằng PostgreSQL, MySQL hay một persistence mechanism khác.

Nếu chỉ review local code, một AI assistant có thể đưa ra nhận xét như:

Consider trimming the email before converting
it to lowercase.

Nhận xét này có thể đúng.

Nhưng nó chưa trả lời được câu hỏi quan trọng hơn:

Thay đổi này ảnh hưởng tới những phần nào khác trong hệ thống?

6. Từ Changed Code đến Blast Radius

Giả sử User.changeEmail() không chỉ được sử dụng bởi UpdateUserEmailUseCase.

Nó còn có thể được gọi từ:

• RegisterUserUseCase;
• AdminUpdateUserUseCase.

Sau khi thay đổi email, hệ thống có thể publish UserUpdatedEvent, sau đó một EmailSyncHandler đồng bộ dữ liệu sang hệ thống khác.

Ngoài ra còn có các test liên quan tới entity, use case và registration flow.

Đây là khái niệm thường được gọi là blast radius hoặc impact radius.

Thay vì chỉ cung cấp cho AI:

Changed:
User.changeEmail()

graph có thể giúp tạo context gần với:

Changed node:
User.changeEmail()

Direct callers:
- UpdateUserEmailUseCase
- RegisterUserUseCase
- AdminUpdateUserUseCase

Affected flows:
- Profile email update
- Registration
- Admin user update

Related tests:
- user.entity.spec.ts
- update-user-email.usecase.spec.ts
- register-user.usecase.spec.ts

Đây là sự khác biệt giữa:

Review code vừa thay đổi

và:

Review impact của thay đổi.

7. Blast Radius có ý nghĩa gì đối với Code Review?

Một code review thông thường trả lời câu hỏi:

Code vừa thay đổi có vấn đề gì không?

Nhưng trong các hệ thống lớn, reviewer còn cần trả lời:

Nếu thay đổi này sai, những phần nào khác có thể bị ảnh hưởng?

Quay lại ví dụ normalize email.

Graph có thể giúp reviewer chú ý tới một dependency khác:

LoginResolver → LoginUseCase → UserRepository.findByEmail

Từ đó AI có thể nhận ra một vấn đề tiềm ẩn:

Potential inconsistency:

UpdateUserEmailUseCase normalizes the email before
saving, while LoginUseCase passes the raw email to
UserRepository.findByEmail.

Consider normalizing the email consistently at a
shared domain boundary or repository query layer.

Giá trị của graph trong trường hợp này không nằm ở việc graph tự phát hiện bug.

Graph giúp AI tìm đúng context để reasoning về bug.

8. Tại sao không chỉ dùng grep hoặc code search?

Một câu hỏi tự nhiên là:

Các AI coding agent hiện nay đã có grep, ripgrep, filesystem search và language server. Vậy thêm graph để làm gì?

Code Graph không nên được xem là sự thay thế cho code search.

Sự khác biệt nằm ở cách dependency được khám phá.

Không có graph, agent phải lặp lại nhiều bước:

• search identifier;
• đọc file;
• follow import;
• tìm caller;
• tìm test;
• đọc thêm implementation.

Có graph, agent có thể truy vấn dependency đã được index trước để lấy:

• callers;
• related flows;
• related tests;
• affected components.

Sau đó agent vẫn đọc source code thực tế trước khi reasoning.

Có thể tóm tắt sự khác biệt như sau:

Repeated dependency discovery

so với:

Query dependency đã được index trước

Với repository nhỏ, khác biệt này có thể không đáng kể.

Với monorepo hoặc hệ thống có nhiều layer, giá trị bắt đầu rõ ràng hơn.

9. MCP đóng vai trò gì?

Code Review Graph expose code intelligence thông qua MCP.

Điều này cho phép AI agent truy vấn các loại context như:

• minimal context;
• impact radius;
• review context;
• graph traversal;
• affected flows;
• changed components.

Điểm đáng chú ý là LLM không cần nhận toàn bộ repository trong context.

Agent có thể yêu cầu đúng loại thông tin cần thiết cho task hiện tại.

Đây cũng là một pattern có thể áp dụng rộng hơn cho các AI system:

Không cung cấp toàn bộ dữ liệu cho model.
Cung cấp tool để model truy vấn dữ liệu cần thiết.

10. Code Graph và Semantic Search

Code Graph và semantic search đều có mục tiêu hỗ trợ retrieval, nhưng chúng giải quyết những loại câu hỏi khác nhau.

Ví dụ semantic search phù hợp với câu hỏi:

Đoạn code nào có nội dung liên quan tới payment?

Kết quả có thể là:

• PaymentService;
• PaymentController;
• PaymentDTO;
• PaymentDocumentation.

Trong khi graph phù hợp hơn với:

Ai đang gọi PaymentService.capture()?

Kết quả có thể biểu diễn một dependency chain như:

CheckoutController → CheckoutUseCase → PaymentService.capture → StripeClient

Hai cách tiếp cận bổ sung cho nhau.

Semantic search giúp tìm semantic relevance.

Graph giúp tìm structural relationship.

Một hệ thống code intelligence hoàn chỉnh có thể kết hợp cả hai.

11. Test Impact Analysis

Ngoài code review, graph cũng có thể hỗ trợ một use case khác: xác định test liên quan tới thay đổi.

Ví dụ một PR thay đổi:

UpdateUserEmailUseCase

Các test liên quan có thể bao gồm:

update-user-email.usecase.spec.ts
user.resolver.spec.ts
profile.e2e-spec.ts

Với repository có test suite lớn, selective testing có thể trở thành một use case đáng quan tâm.

Tuy nhiên, cần lưu ý rằng affected-test analysis không nên được hiểu là:

Chỉ cần chạy các test graph trả về là chắc chắn đủ.

Độ chính xác vẫn phụ thuộc vào mức độ đầy đủ của relationship trong graph.

Danh sách test nên được xem như candidates cần ưu tiên chạy hoặc kiểm tra.

12. Ưu điểm của cách tiếp cận Code Graph

12.1. Context có cấu trúc

Thay vì cung cấp cho AI hàng loạt source file không có relationship rõ ràng, graph có thể biểu diễn context theo chuỗi:

Changed Function → Direct Caller → Use Case → Entry Point

Điều này giúp model hiểu vì sao một file hoặc function xuất hiện trong context.

12.2. Có thể tái sử dụng knowledge về codebase

Nếu không có index, agent có thể phải khám phá dependency lại cho từng task.

Graph cho phép:

• parse repository;
• lưu relationship;
• update incrementally;
• reuse knowledge cho nhiều task khác nhau.

Điều này đặc biệt phù hợp với repository được AI agent truy cập thường xuyên.

Một lợi ích khác của graph là có thể giữ được loại relationship giữa các thành phần thay vì chỉ biết rằng hai file “có liên quan”.

Ví dụ:

UseCase --uses--> Repository Interface

Repository Implementation --implements--> Repository Interface

Repository Implementation --accesses--> Database

Việc phân biệt các relationship này giúp AI có context chính xác hơn khi phân tích architecture hoặc impact của một thay đổi.

12.3. Phù hợp với Blast Radius Analysis

Blast radius về bản chất là một dependency problem.

Khi một function thay đổi, reviewer thường muốn lần theo:

Function → Caller → Service → API

Graph là một representation tự nhiên cho loại traversal này.

12.4. Giúp AI tập trung vào reasoning

Graph không thay thế việc đọc source code.

Nó có thể giúp giảm thời gian agent dành cho câu hỏi:

File nào cần đọc?

để dành nhiều hơn cho:

Các file liên quan đang thể hiện behavior gì và thay đổi có vấn đề gì?

Một workflow hợp lý là:

Git Diff → Detect Changed Nodes → Impact Analysis → Relevant Execution Flows → Related Tests → Read Actual Source Code → AI Reasoning → Developer Review

13. Những giới hạn cần lưu ý

Code Graph không phải là representation hoàn chỉnh của runtime behavior.

13.1. Static dependency không đồng nghĩa với runtime dependency

Ví dụ:

eventBus.publish(
  new UserEmailUpdatedEvent(),
);

và:

@EventsHandler(UserEmailUpdatedEvent)
export class SyncCRMHandler {
  // ...
}

Runtime flow thực tế là:

UserService → EventBus → UserEmailUpdatedEvent → SyncCRMHandler

Nhưng trong source code có thể không tồn tại direct call:

UserService → SyncCRMHandler

Điều tương tự xảy ra với:

• Kafka;
• RabbitMQ;
• SQS;
• SNS;
• Webhooks;
• Dependency Injection;
• Reflection;
• Dynamic Import.

Các relationship này khó phân tích hơn direct function call.

13.2. Business dependency không nhất thiết xuất hiện trong Call Graph

Giả sử Authentication Service và CRM Sync Service đều phụ thuộc vào:

users.email

Hai service không nhất thiết gọi trực tiếp lẫn nhau.

Chúng cũng có thể nằm ở những application flow hoàn toàn khác nhau.

Tuy nhiên, chúng cùng phụ thuộc vào một business invariant:

Email phải được normalize theo cùng một rule.

Call graph không tự động hiểu được loại dependency này. Dependency này không thể hiện bằng một direct function call hay một chuỗi:

Service A → Service B

Do đó, ngay cả khi structural graph mô tả chính xác quan hệ giữa UseCase, Domain và Repository, graph vẫn chưa chắc hiểu được những business invariant được chia sẻ giữa các flow khác nhau.

Đây là một ví dụ cho thấy structural dependency và business dependency là hai khái niệm khác nhau.

13.3. Kết quả phụ thuộc vào chất lượng của parser

Nếu parser bỏ sót relationship:

A → B

thì blast radius có thể thiếu A.

Ngược lại, nếu graph cố tình theo hướng conservative, kết quả có thể chứa thêm những component thực tế không bị ảnh hưởng.

Do đó output của impact analysis nên được xem là:

Danh sách candidates cần kiểm tra

thay vì:

Danh sách chính xác tuyệt đối các component bị ảnh hưởng

Đây là distinction quan trọng khi áp dụng code graph vào production workflow.

14. Khi nào Code Graph có thể mang lại nhiều giá trị?

Không phải repository nào cũng cần thêm một graph layer.

Một project có:

• 20–30 files;
• architecture đơn giản;
• ít dependency;

có thể chỉ cần:

rg "functionName"

Code Graph bắt đầu đáng cân nhắc hơn khi hệ thống có:

• nhiều module;
• nhiều architectural layer;
• dependency chain dài;
• nhiều developer;
• test suite lớn;
• AI agent được sử dụng thường xuyên.

Trong các hệ thống như vậy, một UseCase thường không chỉ gọi một component theo một chuỗi tuyến tính.

Ví dụ:

Controller → UseCase

sau đó UseCase có thể phối hợp:

• Domain Service;
• Repository → Database;
• Event → Handler;
• external service hoặc các dependency khác.

Một flow xuyên hệ thống cũng có thể đi qua:

Frontend → GraphQL → Backend → Event System → Worker

Trong trường hợp này, impact analysis không còn đơn giản là follow một chuỗi:

A → B → C

mà phải xem xét nhiều nhánh relationship cùng lúc.

Trong những hệ thống như vậy, việc xác định impact của một thay đổi không còn đơn giản nữa.

15. Code Graph nên đóng vai trò Navigation Layer

Một điểm quan trọng khi sử dụng công cụ loại này là không nên chuyển từ:

AI tự search source code

sang:

AI hoàn toàn tin vào graph

Cách tiếp cận phù hợp hơn nằm ở giữa.

Một workflow phù hợp là:

Graph → Tìm vùng có khả năng liên quan → Đọc source code thực tế → Reasoning

Nói cách khác:

Graph nên giúp AI biết nên nhìn ở đâu, chứ không nên thay thế source code như nguồn thông tin cuối cùng.

Developer vẫn cần review kết quả cuối cùng, đặc biệt với các thay đổi liên quan tới:

• business logic;
• security;
• data integrity;
• production-critical flow.

Graph là navigation và context-retrieval layer, không phải single source of truth.

Một ví dụ điển hình là Repository.

Graph có thể cho AI biết rằng:

UpdateUserEmailUseCase sử dụng UserRepository

và:

TypeOrmUserRepository implement UserRepository.

Từ đó agent biết cần đọc cả UseCase, repository contract và implementation khi thay đổi liên quan tới persistence.

Tuy nhiên, graph không nên khiến agent tự suy luận rằng:

UseCase → Domain → Repository → Database

luôn là execution order của hệ thống.

Relationship graph cho biết các thành phần liên quan với nhau như thế nào, còn execution behavior cuối cùng vẫn phải được xác nhận bằng source code thực tế.

16. Một góc nhìn rộng hơn về AI Coding Agent

Ý tưởng đáng chú ý nhất của Code Review Graph không chỉ nằm ở một công cụ cụ thể.

Nó đặt ra một câu hỏi rộng hơn:

Một AI coding agent cần bao nhiêu source code trong context, và quan trọng hơn, nó cần source code nào?

Một model có context window lớn có thể đọc nhiều source code hơn.

Nhưng nhiều context hơn không nhất thiết đồng nghĩa với context tốt hơn.

Có thể hình dung một developer mới tham gia dự án.

Nếu đưa cho họ:

2 triệu dòng source code

và yêu cầu:

Hãy hiểu hệ thống.

Technically, toàn bộ thông tin đã ở đó.

Nhưng đây không phải cách hiệu quả nhất để onboarding.

Thứ họ cần thường là:

• Architecture;
• Modules;
• Dependencies;
• Execution Flows;
• Important Entry Points.

AI agent cũng có thể hưởng lợi từ một structure tương tự.

Theo hướng này, một coding agent có thể sử dụng nhiều nguồn intelligence khác nhau:

• Code Search;
• Code Graph;
• Git History;
• Documentation;
• Issue Tracker;
• Pull Request History;
• Logs;
• Tracing;
• Metrics.

Khi đó LLM trở thành reasoning layer nằm trên nhiều nguồn thông tin khác nhau, thay vì chỉ dựa vào khả năng đọc source code trong context window.

Đây có thể là một hướng phát triển đáng chú ý của AI coding agent trong tương lai.

Kết luận

Khi sử dụng AI trong code review, vấn đề không chỉ là khả năng reasoning của model.

Một yếu tố quan trọng không kém là:

Model đang reasoning trên context nào?

Git diff cho biết:

What changed?

Nhưng một reviewer thường cần thêm:

• What depends on it?
• What can be affected?
• What should be tested?

Code Graph là một trong những cách có thể giúp nối các câu hỏi này lại với nhau.

Quá trình review lúc đó không chỉ dừng ở:

Git Diff

mà có thể mở rộng thành:

Git Diff → Changed Functions → Dependencies → Blast Radius → Affected Flows → Related Tests → Code Review

Cách tiếp cận này đặc biệt đáng quan tâm với:

• repository lớn;
• monorepo;
• hệ thống có nhiều layer;
• dependency chain dài;
• test suite lớn;
• team sử dụng AI coding agent thường xuyên.

Tuy nhiên, Code Graph không phải giải pháp hoàn hảo.

Static analysis vẫn có giới hạn.

Runtime dependency, event-driven architecture và business relationship vẫn là những bài toán khó.

Vì vậy graph nên được sử dụng như một navigation và context-retrieval layer, không phải nguồn sự thật duy nhất.

Cuối cùng, có lẽ câu hỏi quan trọng không phải là:

Làm sao để AI đọc được nhiều source code hơn?

Mà là:

Làm sao để AI biết source code nào đáng đọc?

Thay vì cố gắng đưa thật nhiều code vào context của AI, có thể hiệu quả hơn nếu giúp AI xác định đúng code cần đọc.

Góc nhìn của một backend engineer sau vài tháng nhét agent vào production

Mở đầu: agent thực ra rất nhỏ

Trước khi bàn "chạy ở đâu", cần thống nhất "chạy cái gì". Bỏ hết marketing đi, một AI agent chỉ là vòng lặp này:

async function agentLoop(messages: Message[], tools: Tool[]) {
  while (true) {
    const res = await llm.createMessage({ messages, tools });
    messages.push({ role: 'assistant', content: res.content });

    if (res.stop_reason !== 'tool_use') return res;

    const toolResults = await Promise.all(
      res.content
        .filter((b) => b.type === 'tool_use')
        .map(async (b) => ({
          type: 'tool_result' as const,
          tool_use_id: b.id,
          content: await executeTool(b.name, b.input),
        })),
    );

    messages.push({ role: 'user', content: toolResults });
  }
}

Hai mươi dòng. Chạy được. Và cũng chính vì nó nhỏ như vậy nên câu hỏi thú vị không phải "agent là gì", mà là:

Vòng lặp này sống ở đâu, ai giữ state của nó, và chuyện gì xảy ra khi process chết ở vòng thứ bảy?

Bài này đi qua bốn trục quyết định: runtime, kiến trúc loop, cách kích hoạt, và cách cấp tool. Bốn trục này gần như độc lập với nhau, bạn có thể mix tuỳ ý, và phần lớn tranh cãi về "agent framework nào tốt nhất" thật ra là do người ta đang nói chuyện ở bốn trục khác nhau mà không biết.

Trục 1: Runtime — vòng lặp sống ở đâu

1.1. CLI trên máy dev

Claude Code, Codex CLI, aider, Cursor Agent. Vòng lặp chạy trong một process ngắn hạn ngay trên máy bạn.

Đặc điểm: có quyền truy cập filesystem và shell thật, state nằm trong RAM, người dùng ngồi ngay đó để duyệt từng hành động.

Hợp với: coding, refactor, migration, script hoá công việc lặp đi lặp lại.

Không hợp với: bất cứ thứ gì multi-tenant. Không có isolation giữa các user, không có audit trail, không scale ngang được. Nếu bạn thấy mình đang viết wrapper HTTP quanh một CLI agent để phục vụ nhiều người dùng, dừng lại, đó là dấu hiệu chọn sai runtime.

Cạm bẫy: trust boundary. Agent có shell nghĩa là prompt injection từ nội dung một file bất kỳ trong repo cũng có thể thành rm -rf. Sandbox và allowlist không phải là tuỳ chọn.

1.2. Long-running service trong container

ECS Fargate, EKS, EC2, hoặc bất cứ chỗ nào giữ được một process sống lâu. Vòng lặp nằm trong service của bạn, kết quả stream ra client qua SSE hoặc WebSocket.

@Sse('chat/:id/stream')
stream(@Param('id') id: string): Observable<MessageEvent> {
  return this.agentService.run(id).pipe(
    map((chunk) => ({ data: chunk })),
  );
}

Đặc điểm: không giới hạn thời gian chạy thực tế, giữ được connection, dễ debug vì mọi thứ trong một process.

Hợp với: interactive agent, chat, các loop chạy từ 30 giây đến vài phút.

Cạm bẫy lớn nhất: state nằm trong RAM của một pod cụ thể. User đóng laptop, mở lại, load balancer route sang pod khác, và toàn bộ hội thoại biến mất. Deploy giữa lúc có 50 loop đang chạy thì mất cả 50. Đây là lý do phần lớn team bắt đầu từ mô hình này rồi sớm muộn cũng phải chuyển sang mô hình queue bên dưới.

1.3. Serverless

Lambda, Cloud Run, Vercel Functions.

Đặc điểm: scale về 0, trả tiền theo request, và bị chặn cứng bởi timeout. Lambda tối đa 15 phút. Một agent loop gọi 12 lần tool, mỗi lần chờ LLM 8 giây, đã ăn hết 2 phút chỉ riêng phần suy nghĩ.

Hợp với: từng bước riêng lẻ trong workflow, không phải cả vòng lặp. Ví dụ Lambda làm tool executor, còn loop điều phối nằm chỗ khác.

Cạm bẫy: streaming qua Lambda function URL thì được, nhưng qua API Gateway thì buffer. Ai từng debug "tại sao SSE không ra chữ nào cho đến khi xong" đều đã gặp chuyện này.

1.4. Queue và worker pool

Dispatcher nhận request, đẩy job vào Redis Streams hoặc SQS, worker pool tiêu thụ và ghi từng chunk kết quả ngược lại stream. Client đọc stream đó, không đọc trực tiếp từ worker.

Client ──HTTP──▶ Dispatcher ──XADD──▶ redis stream: job:{id}
                                            │
                                     ┌──────┴──────┐
                                  worker A     worker B
                                     │
                              XADD chunks ──▶ stream: out:{id}
                                                    │
Client ◀────────── SSE ─────────────────────────────┘

Đây là mô hình duy nhất trong danh sách này cho ra durability thật:

• Worker chết giữa chừng thì message chưa XACK, consumer group giao lại cho worker khác.
• Client rớt mạng thì reconnect với Last-Event-ID, server XRANGE từ cursor đó và replay phần đã lỡ.
• Deploy không mất job, chỉ mất connection.

// Client reconnect: replay từ cursor rồi mới stream tiếp
async *resume(jobId: string, lastEventId?: string) {
  const from = lastEventId ?? '0';
  const missed = await this.redis.xrange(`out:${jobId}`, from, '+');
  for (const [id, fields] of missed) {
    yield { id, data: fields[1] };
  }
  yield* this.subscribe(jobId);
}

Cạm bẫy: phức tạp hơn hẳn. Bạn phải tự lo idempotency (worker chạy lại một job đã gọi tool "gửi email" thì sao?), phải nghĩ về ordering, phải có TTL cho stream kẻo Redis phình. Đừng bắt đầu từ đây nếu chưa thật sự cần.

1.5. Managed agent runtime

Bedrock AgentCore, OpenAI Responses/Agents API, Vertex AI Agent Engine, Claude Agent SDK. Nhà cung cấp lo hộ vòng lặp, session state, sandbox, đôi khi cả memory.

Đặc điểm: đi từ 0 đến demo trong một buổi chiều. Session dài hơn hẳn serverless, có sẵn observability.

Cạm bẫy: ba thứ thường vỡ khi lên production nghiêm túc.

1. BYOK. Nếu sản phẩm của bạn cho khách hàng dùng API key của chính họ, phần lớn managed runtime không có chỗ nhét key theo tenant vào runtime của nhà cung cấp.
2. Lock-in ở tầng state. Session state nằm trong hệ thống của họ, migrate đi rất đau.
3. Kiểm soát loop. Bạn muốn chèn một bước validate giữa tool call và execution? Tuỳ runtime, có thể không có hook nào cho việc đó.

Kiểm tra tài liệu mới nhất trước khi chốt, mảng này thay đổi từng quý.

Bảng so sánh nhanh

Trục 2: Kiến trúc vòng lặp

Runtime trả lời "chạy ở đâu". Trục này trả lời "chạy như thế nào".

2.1. Single-loop ReAct

Đúng đoạn code ở đầu bài. Một model, một context window, lặp đến khi không còn tool call.

Đây là mặc định đúng cho khoảng 80% trường hợp. Dễ debug vì chỉ có một luồng suy luận để đọc, chi phí dễ dự đoán, không có chuyện agent này chờ agent kia.

Giới hạn: context window. Loop dài, tool trả về nhiều dữ liệu, và đến vòng thứ 20 thì nửa context là output của mấy lần grep không còn liên quan.

2.2. Planner → worker → synthesizer

Một model cắt việc thành các nhánh độc lập, fan-out cho worker pool chạy song song, rồi một model khác gộp kết quả.

                    ┌──▶ worker 1 (context riêng) ──┐
planner ──plan──────┼──▶ worker 2 (context riêng) ──┼──▶ synthesizer ──▶ output
                    └──▶ worker 3 (context riêng) ──┘

Lợi: giảm latency đuôi khi các nhánh thật sự độc lập. Ba nhánh mỗi nhánh 20 giây chạy song song ra 20 giây thay vì 60. Mỗi worker có context window riêng nên không bị tràn.

Hại: tốn token hơn nhiều, vì planner và synthesizer đều phải đọc lại đề bài. Và nó chỉ có lợi khi các nhánh độc lập thật. Nếu worker 2 cần kết quả của worker 1 thì fan-out chẳng giúp được gì, chỉ thêm một hop.

Câu hỏi cần trả lời trước khi chọn: bạn có thể viết ra được cái plan bằng tay không? Nếu có, có lẽ bạn cần workflow cố định ở mục 2.4 chứ không cần planner LLM.

2.3. Multi-agent / subagent

Mỗi agent có system prompt, tool set và context riêng, gọi nhau như gọi tool.

Lợi ích thật sự nằm ở cô lập context, không phải ở "chuyên môn hoá". Một subagent chuyên đọc log có thể ngốn 100k token rồi trả về ba dòng tóm tắt cho agent cha, phần rác không bao giờ chạm vào context chính.

Hại: lỗi lan truyền rất khó truy vết. Agent cha nhận một tóm tắt sai từ agent con, và bạn phải đọc ngược ba tầng trace để biết chỗ nào bịa ra. Đầu tư vào tracing trước khi đầu tư vào tầng thứ ba.

2.4. Workflow cố định

Step Functions, Temporal, LangGraph với graph tĩnh. Các bước do con người định nghĩa, LLM chỉ điền vào chỗ trống.

Đây là lựa chọn bị đánh giá thấp nhất. Nếu quy trình đã biết trước, ví dụ "đọc ticket → tìm code liên quan → sinh patch → chạy test → mở PR", thì để LLM tự quyết thứ tự chẳng thêm giá trị gì, chỉ thêm chỗ để sai. Đổi lại bạn được retry theo từng bước, replay, và observability gần như miễn phí.

Nguyên tắc thực dụng: dùng agent ở chỗ không đoán trước được đường đi, dùng workflow ở mọi chỗ còn lại. Rất nhiều hệ thống gọi là "agent" thực ra là workflow có một bước gọi LLM.

Trục 3: Cách kích hoạt

Trục này quyết định nhu cầu persistence, và người ta hay bỏ quên nó.

• Interactive (SSE/WebSocket): có người ngồi chờ. Cần streaming, cần resume, cần cancel. Đắt nhất về mặt hạ tầng.
• Cron / scheduled: không ai chờ. Không cần streaming, chỉ cần ghi kết quả và báo khi xong. Đơn giản hơn hẳn.
• Event-driven (webhook): PR mở ra, message Slack, file upload lên S3. Cần idempotency vì webhook được gửi lại là chuyện bình thường.
• CI pipeline: agent chạy trong GitHub Actions, có timeout tự nhiên và log sẵn. Sandbox tốt để thử nghiệm trước khi đưa vào sản phẩm.

Một agent thường phải phục vụ nhiều kiểu trigger. Tách phần lõi (loop + tool) khỏi phần transport ngay từ đầu, đừng để logic SSE lẫn vào trong loop.

Trục 4: Cấp tool cho agent bằng cách nào

4.1. Function calling trực tiếp

Schema hardcode trong code, executeTool là một switch. Nhanh, ít tầng, không có gì bí ẩn.

Giới hạn: tool schema chiếm chỗ trong mọi request. Ba mươi tool là vài nghìn token trả tiền cho mỗi lượt, kể cả lượt chỉ chào hỏi.

4.2. MCP qua stdio

MCP server chạy như child process, giao tiếp qua stdin/stdout. Hợp với CLI và môi trường local, vì tool chạy cùng máy với agent, thừa hưởng quyền của user.

4.3. MCP remote qua HTTP

Server độc lập, có OAuth, nhiều client dùng chung. Đây là hướng đúng khi tool cần chia sẻ giữa nhiều agent, nhiều team, hoặc nhiều tenant.

Phần khó không nằm ở protocol mà ở authorization. Vài câu hỏi phải trả lời trước khi mở một MCP server ra ngoài:

• Token của user cuối hay của service? Nếu là user, đường đi từ agent đến MCP server đến API đích giữ được identity đó không?
• Scope tối thiểu là gì? Một tool đọc lịch không có lý do gì cần quyền ghi Drive.
• Consent hiển thị cho user lúc nào, và họ có hiểu mình đang đồng ý cho cái gì không?

Đây là chỗ mà "làm cho chạy" và "làm cho an toàn" cách nhau rất xa.

4.4. Code execution thay cho tool

Thay vì khai báo 40 tool, cho agent một sandbox và một SDK, để nó viết code gọi API. Schema từ vài nghìn token xuống còn một tool duy nhất, và agent có thể compose (lọc, gộp, lặp) mà không cần round-trip qua model sau mỗi bước.

Đổi lại bạn phải có sandbox thật sự cách ly. Agent sinh code là agent có thể sinh code gọi ra internet, đọc biến môi trường, hoặc lặp vô hạn.

Những thứ thật sự quyết định lựa chọn

Sau khi đi qua bốn trục, những câu hỏi dưới đây mới là thứ tách một prototype khỏi một hệ thống dùng được.

Durability. Process chết ở vòng thứ bảy thì sao? Nếu câu trả lời là "user gõ lại", bạn đang chạy prototype, và điều đó hoàn toàn ổn cho đến khi nó không ổn nữa.

Resume. User đóng tab rồi mở lại có thấy tiếp không? Muốn có tính năng này thì output phải nằm ở nơi có thể replay theo cursor, không thể là buffer trong RAM.

Idempotency. Retry là chuyện chắc chắn xảy ra. Tool nào có side effect thì phải có idempotency key, nếu không một cú retry sẽ gửi email hai lần.

Observability. Token vào ra mỗi bước, tool nào được gọi với input gì, tại sao loop dừng. Không có ba thứ này thì mọi bug đều thành chuyện đoán mò. Log toàn bộ conversation là chưa đủ, bạn cần trace có cấu trúc.

Chi phí. Vòng lặp gửi lại toàn bộ lịch sử mỗi lượt. Chi phí tăng theo bình phương độ dài hội thoại, không phải tuyến tính. Đặt trần số vòng lặp và trần token ngay từ ngày đầu, không phải sau khi nhận hoá đơn.

Multi-tenant key. Nếu khách hàng dùng key của họ, key phải được mã hoá khi lưu, chỉ giải mã đúng lúc gọi API, và không bao giờ xuất hiện trong log hay trong trace. Chuyện này ảnh hưởng ngược lên lựa chọn runtime, vì managed runtime thường không cho bạn chỗ để làm việc đó.

Chọn thế nào

Một đường đi thực dụng:

1. Bắt đầu bằng single-loop trong một container, tool khai báo trực tiếp, trigger là SSE. Ít tầng nhất, học được nhiều nhất về bài toán của bạn.
2. Khi loop bắt đầu chạy quá một phút hoặc user phàn nàn mất hội thoại: chuyển output sang stream có cursor để resume được. Chưa cần đổi kiến trúc loop.
3. Khi deploy làm mất job: đưa loop vào worker pool sau queue.
4. Khi context tràn hoặc latency đuôi quá tệ: mới tính đến fan-out hoặc subagent. Không phải trước đó.
5. Ở bất kỳ bước nào, nếu bạn viết được plan bằng tay: bỏ agent, dùng workflow.

Điều dễ nhầm nhất là tưởng agent phức tạp hơn thì tốt hơn. Phần lớn giá trị nằm ở một vòng lặp đơn giản có tool tốt và observability tử tế. Phần phức tạp còn lại là để giải quyết những vấn đề bạn chưa chắc đã có.

Nếu bạn đang chạy agent theo cách khác với năm kiểu ở trên, mình rất muốn nghe.

Giới thiệu chung

Mình làm lập trình web trên Windows trong một thời gian dài và nhìn chung mọi thứ đều ổn.
Vài năm trở lại đây Windows ngày càng có nhiều biểu hiện khó chịu, nhưng vì đã quá quen nên mình đều tặc lưỡi cho qua.

Vài tháng trước mình xem một số bài về "rice" Linux trên Reddit và khá thích thú với giao diện của những người dùng này.

Nếu thích giao diện windows, bạn hoàn toàn có thể "rice" giống như No_Beyond_5483 trên reddit đã làm:

"Start Menu"	"Explorer"

Mình không xa lạ với Linux: có vài dự án yêu cầu làm việc với Ubuntu, các dự án khác mình làm trên WSL.
Ý tưởng nhảy sang CachyOS luẩn quẩn trong đầu mình mấy tuần nhưng chưa đủ để làm một cú "leap of faith".
Cho đến một sáng nọ, Windows tự động update và restart lại máy của mình giữa lúc đang làm việc.

Bài viết này là cảm nhận sau 3 tháng dùng CachyOS làm hệ điều hành chính cho công việc.
Cấu hình máy: Intel Core i7-12700, 64 GB RAM. Máy công ty, hiện mình dual boot Windows 11 và CachyOS — công ty cho phép xóa hẳn Windows nhưng mình vẫn giữ lại để phòng vài trường hợp bắt buộc.

Lý do chuyển đổi

Muốn dùng Hyprland

Đây là lý do đầu tiên khiến mình nghiêm túc nghĩ tới chuyện đổi hệ điều hành.
Hyprland là một Wayland compositor dạng tiling: giao diện đẹp, dễ tùy biến, nhanh và mượt hơn hẳn phần mềm tương tự trên Windows (komorebi).
Về mặt kỹ thuật Hyprland không phải đặc sản của CachyOS — nó chạy trên hầu hết distro — nhưng để dùng được nó thì mình phải rời Windows, và CachyOS là phương tiện mình chọn (lý do ở phần sau).
Mình sẽ đi vào chi tiết trong phần "Cái hay".

Start menu Windows 11 chật chội, quảng cáo

Bấm nút Start lên là đập vào mắt một loạt app và group app, nhìn rất rối.
Windows còn chèn quảng cáo mà người dùng không tắt được nếu không can thiệp sâu vào hệ thống.

Tự động cập nhật Windows

Vì lý do bảo mật, máy công ty không thể tắt hẳn chế độ cập nhật Windows.
Dù đã thiết lập chỉ cập nhật bằng tay, đôi khi Windows vẫn tự động update và khởi động lại — đúng vào lúc không mong muốn nhất.

Các vấn đề khi làm việc với WSL

Hẳn nhiều bạn ít nhiều gặp các vấn đề sau trong WSL:

• Chạy Node chậm khi file nằm ngoài WSL (truy cập qua /mnt)
• Vấn đề quyền khi file nằm trong Windows
• Tên file Windows chứa dấu cách
• Vấn đề CRLF và LF khi commit
• Vấn đề network với Docker

Các vấn đề trên có thể giải quyết bằng cách đưa toàn bộ project vào trong WSL, cài Docker/Git trong WSL, chạy code . / cursor . từ WSL...
Nhưng nếu mọi thứ đều nằm trong WSL hết thì tại sao không chuyển hẳn sang Linux thay vì dùng Windows?

Tại sao chọn CachyOS

Mình có cân nhắc vài lựa chọn:

• Arch thuần: mạnh nhưng tốn công dựng từ đầu.
• EndeavourOS: gần Arch, dễ cài, nhưng không có phần tối ưu hiệu năng.
• Fedora: ổn định, nhưng mình muốn kiểu rolling release + AUR + Arch Wiki.

Cuối cùng chọn CachyOS vì:

• Dựa trên Arch: giữ triết lý tối giản, rolling release, kho AUR và toàn bộ Arch Wiki. Không cài sẵn nhiều thứ rác nhưng vẫn đủ dùng ngay sau khi cài (driver, DE, công cụ cơ bản).
• Kernel và package được tối ưu: kernel riêng của CachyOS (scheduler BORE/sched-ext) và các gói biên dịch cho tập lệnh x86-64-v3/v4, hợp với CPU đời mới.
• Trình cài đặt đồ họa (Calamares), chọn desktop environment ngay lúc cài — mình chọn Hyprland.

Cái hay

Tốc độ, đặc biệt là môi trường dev

Nhìn chung mọi thứ nhanh hơn Windows: thời gian tìm file, mở app, và rõ rệt nhất là tốc độ build.
Lý do chính: không còn lớp ảo hóa của WSL và không còn I/O chậm khi thao tác file qua ranh giới Windows ↔ Linux.
Toàn bộ source code, Docker, Git nằm trên hệ thống file Linux native.

Docker chạy native

Đây gần như là câu trả lời trực tiếp cho cả danh sách vấn đề WSL ở trên.
Docker chạy thẳng trên kernel Linux, không qua máy ảo, không vướng vấn đề quyền file, không vướng CRLF/LF, network đơn giản hơn.

Terminal có nhiều lựa chọn hơn

Windows Terminal hoạt động tốt, nhưng không tương thích với komorebi và phần hỗ trợ image protocol còn hạn chế — mình thử chạy fastfetch kèm ảnh (Sixel) thì không hiển thị được.
Trên Linux mình có thể dùng gần như mọi terminal phổ biến: Ghostty, kitty, WezTerm, Alacritty, foot, Tilix, Hyper...
Có thể xem danh sách terminal hỗ trợ trên từng OS ở đây: https://github.com/cdleon/awesome-terminals

Thao tác workspace mượt mà hơn

CachyOS hỗ trợ nhiều desktop environment; mình chọn Hyprland vì đã thích nó từ lâu.
Hyprland chia màn hình thành nhiều workspace, mỗi workspace chứa nhiều app.

Cải thiện lớn nhất — ngoài giao diện đẹp — là tốc độ truy cập app.
Thử tưởng tượng bạn đang mở:

• 3 trình duyệt (một cho công việc, một cho Messenger vì app desktop bị khai tử, một cho YouTube)
• DBeaver
• 2 IDE (1 backend, 1 frontend)
• File manager
• Terminal
• Slack

Bạn đang ở IDE backend và muốn chuyển sang Slack: trên Windows bạn phải Alt+Tab một hoặc nhiều lần, hoặc rê chuột xuống taskbar để chọn — mà mình thì muốn hạn chế dùng chuột.

Với Hyprland, mỗi app gắn vào một workspace cố định. Chỉ một tổ hợp Super + số là nhảy đến đúng nơi.
Nếu vẫn thích Alt+Tab thân thuộc, có thể cấu hình bằng hyprswitch.
Hyprland cũng cho phép nhảy qua lại giữa các app trong cùng một workspace.

Trên Windows 11 có komorebi hoạt động tương tự, nhưng komorebi còn non trẻ, hệ sinh thái và khả năng tùy biến chưa bằng Hyprland.

Animation trên Komorebi không mượt bằng Hyprland, bạn có thể xem video so sánh bên dưới.

Komorebi

Hyprland

Tối giản, không quảng cáo

Không quảng cáo, launcher không bị phình bởi app không cần thiết.

Ít chiếm dụng tài nguyên hơn khi tải nặng

Khi mở nhiều ứng dụng cùng lúc và đang chạy một web app, CachyOS tiêu thụ RAM/CPU thấp hơn Windows trong cùng kịch bản.

So sánh 2 OS:

• Windows 11: 4 trình duyệt, 1 IDE, 1 slack, 2 terminal -> 50% RAM
• CachyOS: 4 trình duyệt, 1 IDE, 1 slack, 1 DBeaver, 6 terminal -> 40% RAM

Tài nguyên trên Windows 11 - 50%

Tài nguyên trên CachyOS (1) - 40%

Tài nguyên trên CachyOS (2) - 40%

Phần lớn app đều chạy được

Với web dev, phần lớn công cụ trên Windows đều chạy được trên CachyOS: VS Code, Cursor, trình duyệt, DBeaver, Slack, Zoom, Docker...

Một số app không có bản Linux thì đã có phần mềm tương đương:

Nếu thật sự cần app Windows, có thể chạy qua Wine (kèm một số hạn chế) hoặc bật lại Windows ở phân vùng dual boot.

Cái dở

Gõ tiếng Việt

fcitx5 mặc định đi kèm vài vấn đề phải chỉnh lại thiết lập mới gõ thoải mái được:

• Phím tắt chuyển bộ gõ không ăn nếu con trỏ không nằm trong input field
• Cách gõ chưa tự do như Unikey
• Chữ hiện trong một ô trắng riêng thay vì ngay tại con trỏ

Vấn đề hiển thị với Hyprland

• App cửa sổ nhỏ vẫn bị bó trong khung tiling, nhìn không tự nhiên

• Ở một số app khi mở hộp thoại option, nó nhảy sang vị trí khác

Rolling release có lúc "vỡ"

CachyOS là bản rolling release dựa trên Arch, nên một lần update có thể làm hỏng thứ gì đó (driver, package AUR không build được...).
Kinh nghiệm của mình: chỉ update khi thật sự cần, đọc thông báo của Arch/CachyOS trước, và tránh update ngay trước một buổi họp hay deadline.

Zoom bản 7.x bị giật lag

Slack và Google Meet không có vấn đề gì.
Riêng Zoom, bản 7.x chạy giật lag trên máy mình, phải hạ về bản 6.x mới dùng ổn.

Dành khá nhiều thời gian để thiết lập

Với người muốn tránh chuột càng nhiều càng tốt, việc dựng một bộ keybind hợp lý cho Hyprland, Neovim, kitty... không hề dễ.
Còn phải: chỉnh Waybar cho vừa mắt, chỉnh hyprlock cho màn hình khóa đẹp hơn, viết alias dùng để khởi chạy một loạt tiến trình, cài hyprswitch để có lại Alt+Tab.
Để chạy được thì không mất bao lâu, nhưng để đúng ý mình thì tốn rất nhiều thời gian.

Kết luận

Chuyển sang CachyOS mình cảm thấy quy trình làm việc trôi chảy hơn hẳn.

Xét về mặt công việc, bạn vẫn có thể làm được mọi việc dù dùng Windows 11 hay CachyOS.

Nhưng về mặt trải nghiệm, CachyOS là một nâng cấp rõ ràng. Workflow mượt mà hơn. Bỏ được lớp WSL đồng nghĩa với build nhanh hơn, Docker chạy native, không còn vướng vấn đề quyền file hay CRLF/LF. Toàn bộ source code, Git, container nằm trên một hệ thống file Linux duy nhất — thứ mà trước đây mình phải chắp vá giữa hai thế giới.

Phần còn lại phụ thuộc vào việc bạn nhìn nhận thời gian vọc như thế nào. Vài ngày đầu gần như không làm được việc gì ngoài cấu hình, và sau đó vẫn có "thuế vọc" định kỳ mỗi khi update làm hỏng thứ gì đó. Với mình, việc được toàn quyền kiểm soát máy, một giao diện đúng ý, và không còn bị quảng cáo hay update ép buộc làm phiền là xứng đáng. Sau 3 tháng, mình không có ý định quay lại Windows làm hệ điều hành chính — phân vùng Windows giờ chủ yếu để dự phòng.

Nên hay không nên chuyển:

• Nên thử nếu công việc của bạn chủ yếu xoay quanh web, terminal và Docker, và bạn thấy việc tùy biến hệ thống là thú vui chứ không phải gánh nặng.
• Chưa nên nếu bạn phụ thuộc vào Adobe, MS Office bản đầy đủ, hoặc phần mềm nội bộ bắt buộc của công ty chỉ chạy trên Windows — hoặc đơn giản là bạn không muốn mất thời gian vọc.
• Nếu quyết định chuyển, hãy dual boot hoặc giữ một máy ảo Windows cho một hai app không thể thay thế, và đừng đổi máy production ngay trước kỳ deadline.

Làm quen với Linux không khó nhưng vẫn đòi hỏi bạn chủ động tìm hiểu và tinh chỉnh — và với mình, đó vừa là nhược điểm vừa là điểm hấp dẫn.

Tham khảo

• [KDE] Do I blend in as windows user? :P
• How to Dual Boot CachyOS and Windows 11 (EASY WAY)

Hẹ hẹ, chào anh em!

Chắc anh em nào gần đây tích hợp AI vào quy trình CI/CD hay dùng các công cụ AI coding agent như Claude Code, Codex để tự động review code đều từng nếm trải cảm giác vừa mừng vừa… ức chế (haizz).

Mừng là vì bot phản hồi nhanh như chớp, vừa tạo Pull Request (PR) xong là 30 giây sau đã thấy thông báo ting ting. Nhưng mở ra đọc thì hỡi ôi:

• Một PR sửa đúng 3 dòng logic fix bug gấp thì bot nhảy vào yêu cầu: “Bạn nên refactor lại toàn bộ module này theo Clean Architecture, tách 5 interface và viết bổ sung 12 unit test bao phủ 100%…” (ảo ma thực sự).
• Vòng review 1 dev đã sửa xong các issue quan trọng, push commit mới lên thì bot lại… đẻ thêm 5 cái góp ý lặt vặt về cách đặt tên biến và thụt lề mà vòng trước nó không hề nhắc tới.
• Dev vào comment giải thích lý do tại sao đoạn đó phải viết như vậy, vòng sau bot vào review tiếp và… lặp lại y nguyên nhận xét cũ như chưa hề có cuộc chia ly (sad).

Cuối cùng, thay vì giúp tăng tốc độ phát triển, con bot AI trở thành một “bà mẹ chồng khó tính” soi từng cọng rác, gây tắc nghẽn toàn bộ luồng merge code của anh em. (Bottleneck)

Tại hội thảo AI Engineer World’s Fair, hai kỹ sư của Uber (Will Bond & Ameya Ketkar) đã công bố hệ thống uReview — Dùng Multi-Agent Code Review xử lý hơn 25.000 comments mỗi tuần. Và khi đối chiếu bài toán của Uber với chính trải nghiệm thực tế từ các dự án mình tham gia trong thời đại AI hiện nay, mình nhận ra: Tất cả chúng ta đều đang vấp phải những cái bẫy y hệt nhau khi để AI review code.

Hôm nay, mình cùng anh em mổ xẻ từ kiến trúc cấp enterprise của Uber cho đến những kinh nghiệm thực chiến để thuần hóa AI Review thành một trợ thủ đắc lực thay vì một máy spam comment rác.

1. Nỗi đau chung: Khi AI trở thành nút thắt cổ chai của PR

Tại Uber, với quy mô hàng nghìn kỹ sư trên 6 monorepo khổng lồ, khi AI coding tools bùng nổ, lượng code sinh ra tăng vọt khiến thời gian chờ review đầu tiên (Time to First Review) tăng từ 3 giờ (2024) lên tới 9 giờ (2026).

Nhưng ở chiều ngược lại, khi anh em vội vã cắm một con bot AI đơn lẻ vào để “chữa cháy”, một loạt vấn đề nhức nhối xuất hiện:

Bẫy 1: False Positive & “Chủ nghĩa hoàn hảo” viển vông

• Quá strict: Bot đánh giá code theo tiêu chuẩn “sách giáo khoa”, đòi hỏi sự hoàn hảo lý thuyết thay vì tính thực tế của dự án.
• Over-engineering: Một thay đổi nhỏ (hotfix) bị đòi hỏi phải tái cấu trúc toàn diện, thêm thắt các pattern không cần thiết.
• Áp dụng best practice chung chung: Không hiểu bối cảnh riêng của codebase, đưa ra các đề xuất xung đột với convention nội bộ của team.

Bẫy 2: Review lặp lại & Spam nhiễu loạn (Noisy Loops)

• Lặp lại comment cũ: Không đọc được ngữ cảnh trao đổi trong thread comment của GitHub/GitLab.
• Soi nits ngoài scope: Nhảy vào bắt lỗi ở những file hoặc những dòng code không hề bị sửa trong PR hiện tại.
• Đẻ thêm feedback mới liên tục: Mỗi lần dev push commit fix lỗi chính, bot lại “ngứa tay” tìm thêm lỗi phụ, khiến PR rơi vào vòng lặp review vô tận không bao giờ được approve.

2. Kiến trúc uReview của Uber: Đừng bắt một con Bot làm mọi thứ

Ví von: Một bác bảo vệ gác cổng vs. Hội đồng chuyên môn có bộ lọc

Nếu anh em chỉ quăng diff code vào một prompt duy nhất của Claude hay GPT, điều đó giống như việc anh em thuê một bác bảo vệ đứng gác cổng và bắt bác ấy vừa phải kiểm tra thẻ nhân viên, vừa soi lỗi chính tả tài liệu, vừa thẩm định bản vẽ kết cấu chịu lực của tòa nhà. Bác ấy chắc chắn sẽ hoa mắt và phán bừa.

Uber giải quyết việc này bằng mô hình Multi-Agent kết hợp Bộ lọc hậu xử lý (Post-Processing):

Nhân tiện architecture này mình vẽ bằng skill này: https://github.com/tt-a1i/archify, cũng khá hay và tiện.

Tiếp nào:

Bí quyết cốt lõi từ Uber:

Chia nhỏ generator (The Review Stack): Tách riêng prompt bắt lỗi logic, AI linter bắt quy chuẩn cú pháp, và agent chuyên sâu đọc tài liệu dự án monorepo, lấy context xung quanh.

1. Post-Processing (Bộ lọc khử trùng lặp): Khi nhiều generator cùng chạy, lượng nhận xét trùng nhau rất lớn. Bước hậu xử lý sẽ xếp hạng độ tin cậy (Confidence Score) và khử trùng lặp. Chỉ những nhận xét có độ tự tin cao và thực sự có giá trị hành động mới được hiển thị cho dev.
2. Observability ghìm cương LLM: Đo lường Addressal Rate (tỷ lệ dev thực sự sửa code theo comment) và Sentiment Analysis (phản ứng vui vẻ hay tức giận của dev) để loại bỏ các prompt vô dụng.

Nhờ các cơ chế quan sát và đánh giá này, Uber đã đạt được những con số cực kỳ ấn tượng:

• Chi phí vận hành giảm 60%, chất lượng & độ chính xác tăng 70%.
• Tỷ lệ giải quyết nhận xét (Addressal Rate) đạt 67%, với lỗi nghiêm trọng đạt tới ~74%.
• Tỷ lệ nhận phản hồi tiêu cực trên toàn công ty chỉ còn 4%.

3. Bài học thực chiến: Tối ưu luồng Review-in-Loop cho dự án thật

Từ mô hình của Uber kết hợp với kinh nghiệm triển khai, trải nghiệm thực tế của bản thân qua các dự án dùng Full AI Review, Full AI Coding của mình , dưới đây là bộ khung giải pháp giúp anh em dẹp tan hoàn toàn tình trạng review rác.

3.1. Phân tách hai luồng độc lập: Spec Conformance vs. Code Quality

Đừng bắt một model vừa đọc hiểu tài liệu requirement vừa soi bug thuật toán. Hãy chia làm 2 Track rõ ràng:

• Track A — Kiểm tra tính tương thích đặc tả (Spec Conformance): Đọc file requirement/spec hoặc Acceptance Criteria của Task/Issue, đối chiếu từng dòng diff xem code có đáp ứng đúng nghiệp vụ hay không. Phần lớn các lỗi P1 nghiêm trọng trong thực tế xuất phát từ việc lệch spec chứ không phải lỗi cú pháp.
• Track B — Kiểm tra chất lượng code & bảo mật: Chuyên tâm rà soát bug logic, race condition, lỗ hổng SQL/XSS, trùng lặp code và vấn đề performance.

Hai track này sau đó được tổng hợp (Synthesis) lại, lọc bỏ trùng lặp trước khi xuất ra kết quả cuối cùng.

3.2. Phân loại mức độ nghiêm trọng (Severity Taxonomy) và Điều kiện Approve rõ ràng

Một sai lầm phổ biến là coi mọi nhận xét đều bình đẳng như nhau. Cần thiết lập ranh giới rõ ràng:

• [P1] Blocker (Bắt buộc sửa): Lỗi sai lệch requirement, bug logic nghiêm trọng gây crash, lỗ hổng bảo mật, hỏng tương thích ngược. Có P1 là Request Changes, cấm merge.
• [P2] Important (Nên sửa): Thiết kế dễ vỡ (fragile), thiếu xử lý edge-case, nguy cơ chậm query nhưng chưa chết ngay.
• [P3] Nit / Minor (Tham khảo): Đặt tên biến chưa hay, gợi ý refactor cho đẹp, cách viết ngắn hơn. Tuyệt đối không bao giờ chặn PR vì lỗi P3.

Nguyên tắc vàng để kết thúc vòng lặp (Loop Termination): Khi số lượng lỗi [P1] = 0, hệ thống BẮT BUỘC PHẢI APPROVE. Toàn bộ các góp ý P2/P3 chỉ mang tính chất ghi chú (FYI) hoặc chuyển thành ticket cải tiến sau. Không được phép giữ PR làm con tin vì những góp ý mức độ thấp.

3.3. Cơ chế Context-Aware Re-Review (Chống lặp lại khi review vòng sau)

Để tránh tình trạng bot bị “mất trí nhớ” và comment lại những thứ dev đã giải thích:

1. Giới hạn phạm vi (Scope Discipline): Ở các vòng review sau (follow-up rounds), bot chỉ được phép đọc các commit mới được push lên. Tuyệt đối không xới lại những đoạn code cũ đã duyệt ở vòng trước.
2. Đọc lịch sử thảo luận (Thread History): Trước khi xuất nhận xét, bot phải đọc các reply của developer trong thread. Nếu dev đã phản hồi lý do giữ nguyên thiết kế hoặc chấp nhận rủi ro có chủ đích, bot phải ghi nhận và không được lặp lại góp ý đó.
3. Bảng trạng thái xử lý rõ ràng: Tạo bảng so sánh đối chiếu:

• Issue cũ 1: Đã khắc phục (Resolved) — kèm dẫn chứng commit/line code.
• Issue cũ 2: Chưa khắc phục (Unresolved) — chỉ nhắc lại nếu là P1.

3.4. Chiến thuật “Song kiếm hợp bích” Codex x Claude Code (Cross-Model Multi-Review)

Một trong những bước tiến thực chiến mạnh mẽ gần đây là việc OpenAI chính thức phát hành Codex plugin cho Claude Code (openai/codex-plugin-cc). Sự kết hợp này mang lại mô hình Cross-Model Validation (Review chéo giữa 2 AI Model khác họ) ngay trong cùng một phiên làm việc CLI.

Tại sao một model tự code rồi tự review lại kém hiệu quả?

• Điểm mù của Claude (Opus / Sonnet): Rất xuất sắc trong việc lập kế hoạch tổng thể (Plan mode), hiểu ngữ cảnh sâu và refactor linh hoạt, nhưng lại hay có xu hướng over-engineering (vẽ ra kiến trúc cồng kềnh cho task nhỏ), ngốn token và dễ có “thiên kiến tự xác nhận” (confirmation bias) với code chính mình vừa sinh ra.
• Điểm mạnh của Codex (GPT-5.6): Được trang bị năng lực reasoning và giải quyết (solve) các bài toán kỹ thuật phức tạp vượt bậc, dẫn đầu ở các benchmark thực tế như SWE-bench Pro — thước đo sát sườn nhất về năng lực bóc tách lỗi logic ngầm và phân tích diff hóc búa. Thêm vào đó, chi phí token tối ưu hơn đáng kể cùng tốc độ xử lý nhanh giúp Codex trở thành “cỗ máy quét lỗi” lý tưởng để gánh tải review liên tục mà không lo đội chi phí.

Luồng phối hợp 3 bước thực chiến:

1. Claude Code (Tác giả): Đảm nhận vai trò Author, tận dụng Plan mode để phân tích yêu cầu nghiệp vụ và viết code tính năng.
2. Codex Plugin (Phản biện độc lập):

• /codex:review: Review nhanh các thay đổi cục bộ (uncommitted changes) trước khi commit. Chế độ chỉ đọc (read-only), bắt lỗi logic tức thì mà không can thiệp sửa file.
• /codex:adversarial-review: Phản biện chuyên sâu (Adversarial Review) đối với các thay đổi phức tạp. Codex sẽ đóng vai một Reviewer nghiêm khắc để soi xét thiết kế, bóc tách edge-case và phân loại mức độ nghiêm trọng (P1/P2/P3).

Claude Code (Khắc phục & Chuẩn hóa): Claude đọc danh sách issue từ Codex, đối chiếu lại với spec nghiệp vụ ban đầu để fix triệt để các lỗi P1/P2 trước khi đẩy PR lên CI/CD.

# 1. Thêm marketplace của OpenAI vào Claude Code
/plugin marketplace add openai/codex-plugin-cc

# 2. Cài đặt plugin Codex
/plugin install codex@openai-codex

# 3. Kết nối tài khoản ChatGPT (hỗ trợ cả tài khoản Free/Plus)
/codex:setup

Tip thực chiến: Đối với các thay đổi đa file (multi-file), việc review sâu có thể mất từ 1-3 phút. Hãy chọn chế độ Run in background và dùng /codex:status để theo dõi tiến độ, tránh ngắt quãng luồng tư duy khi đang làm việc.

4. Hiện tượng “Cavitation” trong Inner Loop và tương lai của Dev

Ví von: Tài xế chạy theo Google Maps bị trễ 5 phút

Khi đưa AI vào cả 2 đầu: AI tự code và AI tự review trong nội bộ (Inner Loop), hiện tượng nguy hiểm nhất là Agent Cavitation (Vòng xoáy lú lẫn).

Hãy tưởng tượng anh em lái xe theo một app bản đồ bị delay. Vừa rẽ trái xong, app bảo “Hãy quay đầu lại”. Quay đầu xong, nó lại bảo “Hãy rẽ trái”. Cứ thế anh em chạy lòng vòng quanh bùng binh mà không bao giờ tới đích.

Khi AI Review đưa ra nhận xét sai hoặc quá khắt khe, Coding Agent sẽ tin lời, sửa code làm hỏng logic cũ, rồi lại bị con Review Agent khác bắt lỗi mới… Vòng lặp này đốt sạch token và làm nát bét cả codebase.

AI có “cướp việc” của Software Engineer?

AI có “cướp việc” của Software Engineer?

Không. AI không giết chết quy trình review của con người, mà nó nâng tầm trách nhiệm của kỹ sư lên một nấc mới (Expanding the Outer Loop):

• AI Agent: Gánh toàn bộ các công việc chân tay tẻ nhạt: bắt lỗi cú pháp, kiểm tra spec cơ bản, rà soát type/linting, tối ưu hóa vi mô.
• Kỹ sư phần mềm: Được giải phóng khỏi hàng giờ căng mắt soi từng dấu chấm phẩy, chuyển toàn bộ sự tập trung sang Kiến trúc hệ thống (Architecture), Tư duy sản phẩm (Product Thinking) và Nghiệp vụ đặc thù (Domain Expertise).

BÀI HỌC KINH NGHIỆM

Từ case study của Uber và kinh nghiệm tự tối ưu luồng review-code, mình đúc kết lại 5 nguyên tắc sống còn:

1. Review dựa trên bằng chứng (Evidence-Based), không đoán mò: Mọi cảnh báo bug phải trace được ra call site thực tế. Nếu một đoạn code chỉ “có vẻ hơi nguy hiểm” nhưng hiện tại không có caller nào kích hoạt lỗi, hãy gắn nhãn P3 (Fragile) chứ đừng biến nó thành P1 blocker.
2. Khuôn khổ rõ ràng cho PR nhỏ: PR dưới 50 dòng thì cấm tiệt bot gợi ý refactor lớn hay bắt viết thêm cả hệ thống test phức tạp. Tránh tuyệt đối over-engineering.
3. P1 = 0 là Approve ngay: Giữ vững kỷ luật kết thúc vòng lặp. Không om PR vì những góp ý “nice-to-have”.
4. Tôn trọng phản hồi của Developer: Luồng review phải biết đọc thread comment cũ để hiểu tại sao dev lại chọn giải pháp đó thay vì cứ lặp lại một bài ca máy móc.
5. Observability là chìa khóa: Luôn theo dõi xem team có thực sự tiếp thu comment của bot hay đang bấm dismiss hàng loạt. Bot sinh ra để phục vụ team, không phải để làm phiền team.

Kết luận

AI Code Review không phải là một chiếc đũa thần cắm vào là xong, mà là một hệ thống kỹ thuật đòi hỏi sự tinh chỉnh cẩn trọng giữa độ nhạy (precision) và độ bao phủ (recall).

Khi anh em biết cách tổ chức đa luồng (Multi-Track), thiết lập bộ lọc khử nhiễu (Deduplication) và xác định điều kiện dừng thông minh, AI sẽ trở thành một người cộng sự đắc lực giúp giải phóng toàn bộ năng lượng của team để tập trung vào những bài toán kiến trúc lớn hơn.

Hy vọng bài viết này giúp anh em có thêm góc nhìn thực tế để thiết kế hoặc tinh chỉnh lại con bot review code cho dự án của mình. Còn một chủ đề cực kỳ hay nữa mà anh em cũng nên đào sâu là Automated Merge Gates & CI/CD Governance — cách kết hợp AI review với pipeline tự động deploy an toàn (nhớ tìm hiểu thêm nhé!).

Nguồn tham khảo:

• AI Engineer World’s Fair — Building uReview, Uber’s Multi-Agent Code Review Engine (Will Bond & Ameya Ketkar, Uber)
• Codex plugin for Claude Code: Why, when, and how you should use it in the product design process (Nick Babich, UX Planet)
• Uber Engineering Blog