Claude Code × AI Agent

Hiểu đúng để
dùng đúng

Xen kẽ giữa kỹ thuật kiến trúc thật sự và thực tế vận hành — không bỏ cái nào. Vì chỉ hiểu bề mặt là chưa đủ để master một công cụ.

Autoregressive LLM Context Window Tool Use Agentic Loop Claude Code
Chương 01 / 05

AI Agent thực ra là gì?
Và tại sao kiến trúc quan trọng

Trước khi học cách dùng, cần hiểu cơ chế bên trong. Những giới hạn mà bạn gặp khi dùng Claude Code không phải do "AI chưa đủ thông minh" — mà do đặc điểm kiến trúc cụ thể. Hiểu kiến trúc = biết tại sao giới hạn đó tồn tại = biết cách thiết kế quanh nó.

Nền tảng
Claude không "nghĩ" — nó dự đoán token tiếp theo
Đây là sự thật kỹ thuật quan trọng nhất. Claude là một Autoregressive Language Model — mỗi từ được sinh ra bằng cách tính xác suất: "Sau chuỗi token này, token nào có khả năng xuất hiện cao nhất?"

Không có "tra cứu" trong database. Không có "suy nghĩ" theo nghĩa con người. Chỉ là phép tính xác suất cực kỳ tinh vi trên hàng tỷ tham số.
Kỹ thuật — Autoregressive Generation
Mỗi token t được sinh ra dựa trên toàn bộ context trước đó:
P(t_n | t_1, t_2, ..., t_{n-1})

Model đã học phân phối xác suất này từ hàng trăm tỷ token text trong quá trình training. Khi inference, nó sample từ phân phối đó — không lookup, không retrieve, không reason theo nghĩa symbolic.
Hiểu theo cách này
Hình dung một người đã đọc toàn bộ internet và có khả năng "autocomplete" cực kỳ tinh vi. Khi bạn hỏi về Python syntax — nó autocomplete chính xác vì đã thấy triệu triệu ví dụ. Khi bạn hỏi về API nội bộ công ty bạn — không có trong training data, nên xác suất cao nó sẽ "autocomplete" thứ gì đó trông hợp lý nhưng sai.
Hệ quả thực tế: Độ tự tin trong giọng văn KHÔNG tương quan với độ chính xác của nội dung. Claude trả lời câu hỏi về SQL cơ bản và câu hỏi về API bạn tự viết với cùng một tone — dù cái trước gần như chắc chắn đúng, cái sau có thể sai hoàn toàn.
Kiến trúc Agent
Claude Code = LLM + Tool Use + Agentic Loop
Claude thông thường chỉ sinh text. Claude Code thêm vào ba thứ: Tools (bash, file read/write, web search), Loop (chạy tool → đọc output → quyết định bước tiếp), và State (theo dõi tiến trình qua context window). Ba thứ này biến LLM thành Agent.
Luồng hoạt động của AI Agent
User Prompt
→
LLM Reasoning
→
Tool Decision
↓ gọi tool thật
Tool Output
→
LLM Reasoning
→
Done / Next Tool
↑ Vòng lặp này tiếp tục cho đến khi LLM quyết định task hoàn thành
Kỹ thuật — ReAct Pattern
Claude Code triển khai pattern ReAct (Reasoning + Acting): mỗi bước gồm Thought (LLM suy luận) → Action (gọi tool) → Observation (đọc kết quả) → lặp lại. Toàn bộ lịch sử Thought/Action/Observation được nối vào context window — đây là cách Agent "nhớ" những gì đã làm trong session.
Khác biệt cốt lõi với chatbot thông thường
Chatbot: bạn hỏi → nó trả lời text → bạn tự làm gì đó với câu trả lời đó.
AI Agent: bạn giao mục tiêu → nó lập kế hoạch → tự chạy từng bước → đọc kết quả → điều chỉnh → báo cáo. Bạn là reviewer, không phải executor.
Giới hạn vật lý
Context Window — "RAM" của AI Agent
Claude Sonnet 4.5 có context window ~200,000 token (~150,000 từ). Mọi thứ AI "biết" trong một session đều phải nằm trong ô nhớ này: system prompt, lịch sử conversation, nội dung file đã đọc, output của tool, và câu trả lời đang sinh ra. Khi đầy — không có cơ chế "swap to disk" như RAM thật. Token cũ bị đẩy ra ngoài và biến mất hoàn toàn.
Kỹ thuật — Attention & Token Budget
Transformer attention tính mối quan hệ giữa mọi cặp token trong context. Độ phức tạp là O(n²) — context dài gấp đôi thì compute tốn gấp 4 lần. Ngoài ra, research cho thấy model có xu hướng attend nhiều hơn vào token đầu và cuối context — token ở giữa bị "lost in the middle." Đây là lý do instruction đặt ở đầu session quan trọng hơn đặt ở giữa.
Ước tính tiêu thụ token trong một session thực
System prompt + CLAUDE.md
~15k
1 file code Python 300 dòng
~3k
10 file code (codebase nhỏ)
~40k
20 lượt tool call + output
~60k
Session agentic dài điển hình
~150k
Context limit: 200,000 token ████████████████████████████████████████████████████
Triệu chứng đầy context: AI hỏi lại thứ đã nói, mâu thuẫn với quyết định cũ, bỏ qua constraint đã đặt từ đầu. Không phải AI "nổi loạn" — là instruction thật sự đã ra khỏi window và không còn tồn tại nữa.
Điểm yếu cốt lõi
AI không có memory — mỗi session là ngày đầu tiên đi làm
Đây là điểm nhiều người hiểu nhầm nhất. Claude Code không nhớ hôm qua bạn làm gì. Mỗi lần khởi động session mới, context window trắng hoàn toàn. Không có "ký ức dài hạn" được lưu ở đâu tự động — trừ khi bạn chủ động xây dựng cơ chế.
Kỹ thuật — 4 loại Memory trong AI System
1. In-context memory — thứ duy nhất Claude Code có mặc định. Sống trong 1 session, mất khi session kết thúc.

2. External memory — files, database, vector store. Cần explicit read/write. CLAUDE.md là ví dụ đơn giản nhất.

3. In-weights memory — kiến thức từ training (Python syntax, SQL...). Cố định, không thay đổi trong inference.

4. In-cache memory — KV cache để tăng tốc, không phải semantic memory.

Claude Code chỉ có 1 và 3 mặc định. 2 là thứ bạn phải chủ động xây.
Hình dung thực tế
Nhân viên giỏi nhưng mỗi sáng mất hết ký ức. Bạn cần có "onboarding doc" đưa cho họ mỗi buổi sáng. Đó chính là CLAUDE.md — external memory duy nhất hoạt động xuyên session trong Claude Code.
# CLAUDE.md — file đặt ở root project # Claude đọc file này ở đầu mỗi session → persistent memory ## Project Context - Đây là n8n automation cho ATS (Avenue to Success) - Stack: n8n, Airtable, PostgreSQL, Meta CAPI - Production domain: n8n.ats.org.vn ## Rules — KHÔNG được vi phạm - KHÔNG sửa workflow đang active trên production - KHÔNG xóa credential đã có - KHÔNG push trực tiếp lên main branch ## Nếu không chắc - Dừng lại, hỏi trước khi tiếp tục - Báo rõ điều đang không chắc là gì
Chương 02 / 05

Điểm mạnh thực sự —
làm tốt rồi, làm tốt hơn nữa

AI không giỏi đều mọi thứ. Nhưng có những thứ nó xuất sắc một cách đáng kể. Tập trung khai thác những điểm này — ROI cao nhất, rủi ro thấp nhất.

10×
Tốc độ với task lặp đi lặp lại
~90%
Độ chính xác với boilerplate code
24/7
Không mệt, không chán, không sai nhịp
Điểm mạnh 1 — Pattern Recognition
Nhận diện và reproduce pattern cực nhanh
AI đã học từ hàng tỷ đoạn code. Nó biết cách cấu trúc một REST API, cách viết migration script, cách tổ chức folder theo convention phổ biến. Với những thứ có pattern rõ ràng và phổ biến — nó gần như không bao giờ sai.
Làm tốt hơn bằng cách nào?
Cho AI thấy pattern bạn muốn thay vì mô tả bằng lời. "Viết function tương tự cái này nhưng cho table kia" cho kết quả tốt hơn nhiều so với mô tả đặc tả dài.
✓ Hiệu quả

"Đây là hàm xử lý lead từ Facebook: [paste code]. Viết hàm tương tự cho lead từ Zalo, cấu trúc giống hệt, chỉ thay đổi field mapping."

✗ Kém hiệu quả

"Viết hàm xử lý Zalo lead cho tôi."

Điểm mạnh 2 — Transformation & Synthesis
Chuyển đổi dữ liệu và tổng hợp thông tin
JSON → CSV, raw log → structured report, 50 email → extracted fields — những task "transform có cấu trúc rõ" là vùng AI hoạt động gần như hoàn hảo. Đầu vào cố định, đầu ra có thể verify ngay.
Tại sao AI giỏi task này về mặt kỹ thuật
Transformer được pre-train trên massive text data có cấu trúc (code, markdown, JSON, XML). Nó đã học implicit grammar của các format này. Khi transform giữa các format có cấu trúc rõ, model chỉ cần mapping pattern đã biết — không cần "creative generation" hay domain knowledge đặc thù. Đây là lý do task này ít hallucinate nhất.
Điểm mạnh 3 — Debug với context đủ
Tìm lỗi nhanh khi được cung cấp đủ thông tin
AI đã "đọc" hàng triệu bug report, stack trace, và discussion về lỗi. Nó nhận diện error pattern rất nhanh. Điều kiện: bạn phải cung cấp đủ — error message đầy đủ, code liên quan, và kỳ vọng của bạn.
Chương 03 / 05

Điểm yếu —
không phải để sợ, mà để thiết kế quanh nó

Biết điểm yếu giúp bạn biết khi nào cần đứng ra tự làm, khi nào cần verify kỹ hơn, và khi nào cần thiết kế guardrail. Không có công cụ nào không có điểm yếu.

Cố hữu — không thể vá
Hallucination — bịa thông tin nghe rất thật
AI sinh text bằng xác suất. Với thông tin phổ biến, xác suất cao → đúng. Với thông tin đặc thù (API nội bộ, thư viện mới, logic nghiệp vụ riêng) → xác suất thấp nhưng model vẫn tự tin sinh ra thứ gì đó "trông hợp lý nhất." Không có warning, không có dấu hiệu phân biệt với output đúng.
Tại sao xảy ra về mặt kỹ thuật
Model optimize để sinh token có xác suất cao nhất theo phân phối training data. Nếu context hiện tại không match bất kỳ pattern rõ ràng nào trong training, model vẫn phải sinh output — nó không có option "không biết, dừng lại." Kết quả là interpolation giữa các pattern gần nhất, trông hợp lý nhưng factually sai.
Mức độ rủi ro hallucination theo loại thông tin
Python/SQL syntax
Thấp
Thư viện phổ biến (stable)
Thấp
Framework mới (<1 năm)
Trung bình
Logic nghiệp vụ đặc thù
Cao
API/SDK nội bộ
Rất cao
Cách phòng: Với thông tin đặc thù, luôn cung cấp documentation hoặc ví dụ thật vào context. Không để AI tự đoán — paste vào thẳng. Và luôn yêu cầu AI chạy test ngay sau khi viết code, đừng chờ.
Cố hữu — giới hạn vật lý
Context Decay — "quên" khi session quá dài
Không phải AI cố tình quên. Instruction bạn đặt ở đầu session thật sự biến mất khỏi window khi context đầy. Ngoài ra, research "Lost in the Middle" (Stanford, 2023) cho thấy ngay cả khi chưa đầy context, model attend kém hơn vào thông tin ở giữa window — prefer đầu và cuối.
Kỹ thuật — Lost in the Middle Problem
Attention mechanism có bias toward primacy (đầu sequence) và recency (cuối sequence). Thông tin ở giữa context window có attention score thấp hơn và dễ bị "bỏ qua" trong reasoning. Với 200k token context, thông tin ở token 50k-150k có thể bị under-utilized đáng kể — dù vẫn "trong window."
Triệu chứng
— AI hỏi lại thứ đã dặn
— Mâu thuẫn với quyết định cũ
— Bỏ qua constraint đã đặt
— Overwrite code đúng bằng code cũ
Giải pháp
— Đặt rule quan trọng vào CLAUDE.md
— Dùng /clear reset context khi dài
— Chia task thành session nhỏ
— Repeat constraint ở cuối prompt dài
Có thể phòng tránh
Goal Drift — làm xong nhưng không phải thứ bạn muốn
Trong task nhiều bước, AI có thể "re-interpret" mục tiêu ban đầu dựa trên kết quả trung gian vừa thu được. Nó không cố tình làm sai — nó đang tiếp tục optimize theo objective nó hiểu, nhưng objective đó đã drift khỏi ý bạn từ lúc nào.
Ví dụ thực tế tại ATS
Yêu cầu: "Tối ưu query Airtable để load nhanh hơn." AI đọc code, thấy schema có vấn đề → tự quyết định refactor schema luôn → phá migration script đang dùng ở chỗ khác. Nó đúng về technical — nhưng scope đã drift xa khỏi yêu cầu ban đầu.
# Prompt phòng Goal Drift Nhiệm vụ: Tối ưu hàm fetchLeads() để nhanh hơn Scope — CHỈ được làm: ✓ Thay đổi logic bên trong hàm fetchLeads() ✓ Thêm index nếu cần (báo tôi trước) KHÔNG được làm: ✗ Sửa schema Airtable ✗ Thay đổi interface của hàm (tham số, return type) ✗ Đụng vào file migration Nếu thấy vấn đề ngoài scope: → Báo tôi biết, không tự sửa
Có thể phòng tránh
Sycophancy — báo "xong" khi thực ra chưa xong
AI được train bằng RLHF (Reinforcement Learning from Human Feedback) — nó được reward khi human rater hài lòng. Hệ quả: model học bias toward làm hài lòng người dùng, kể cả khi điều đó có nghĩa là over-claim completion hoặc tránh thừa nhận thất bại.
Kỹ thuật — RLHF Sycophancy Bias
Trong RLHF, human rater thường rate higher response nào nghe "tự tin và có ích." Model học được correlation này: confident + helpful tone → higher reward. Kết quả là model có xu hướng sinh ra "tôi đã hoàn thành" hơn là "tôi gặp vấn đề và cần giúp đỡ" — vì cái trước từng được reward cao hơn trong training.
Cách phòng đơn giản nhất: Đừng hỏi "Xong chưa?" — hỏi "Chạy test và paste output cho tôi xem." Evidence cụ thể không thể fake. Yêu cầu AI tự verify trước khi báo cáo — không phải verify bằng lời, mà bằng kết quả thật.
✗ Dễ bị lừa

"Bạn đã fix được bug chưa?"
→ "Đã fix rồi!" (có thể sai)

✓ Evidence-based

"Chạy test suite và paste toàn bộ output cho tôi."
→ Kết quả thật, không thể fake.

Chương 04 / 05

Tool Use —
học tool, kiểm soát tool

Tool use là thứ biến LLM thành Agent. Hiểu cơ chế tool use giúp bạn hiểu tại sao Claude Code đôi khi chọn sai tool, dùng tool không hiệu quả, và cách hướng dẫn nó tốt hơn.

Cơ chế
AI không "biết" cần dùng tool nào — nó suy luận từ context
Claude Code không có hardcode rule "task X dùng tool Y." Nó suy luận tool nào phù hợp từ mô tả task trong context. Nếu prompt mơ hồ, nó có thể chọn tool sai — đọc cả file khi chỉ cần grep một dòng, chạy bash command nguy hiểm khi chỉ cần preview.
Các tool Claude Code có và khi nào nên dùng
SAFE — dùng thoải mái
Read file — đọc nội dung file
List directory — xem cấu trúc folder
Web search — tìm kiếm thông tin
Grep/search — tìm pattern trong file
CAREFUL — cần review trước
Write file — ghi đè nội dung
Bash execute — chạy lệnh thật
Delete — xóa file/data
API call — tác động bên ngoài
Kỹ thuật — Tool Selection trong LLM
Claude Code được cung cấp tool schemas dưới dạng JSON trong system prompt. Khi reasoning, model phân loại task và map vào tool schema phù hợp nhất theo attention pattern. Nếu bạn explicit nêu tên tool trong prompt, model sẽ attend trực tiếp vào tool đó thay vì phải inference — giảm đáng kể lỗi tool selection.
# Thay vì để AI tự chọn tool: "Tìm tất cả chỗ dùng hàm sendEvent() trong project" # → AI có thể đọc từng file một (chậm, tốn token) # Explicit guide tool choice: "Dùng grep -r 'sendEvent' trong thư mục /src để tìm tất cả usage" # → AI dùng đúng tool, nhanh và chính xác hơn # Với bash commands nguy hiểm: "Trước khi chạy bất kỳ command nào có thể irreversible, hãy hiển thị command đó cho tôi xem và chờ tôi confirm."
Rủi ro thực tế
Agentic Loop không có exit — tool call spiral
Khi một tool call fail, AI mặc định retry với variation. Không có built-in exit condition. Nếu root cause là thứ AI không thể fix (permission issue, network error, missing credential) — nó có thể loop 10-15 lần, tiêu hết token, và vẫn fail. Không có warning nào được đưa ra.
Kịch bản thực tế
AI đang cố install dependency, server trả về 403 Forbidden do firewall. AI retry với sudo, với pip --user, với conda, với pip3 — lần lượt từng cái, mỗi lần đọc error và thử cách khác. 15 tool calls sau, vẫn 403, hết 30k token.
# Prompt phòng tool spiral Khi gặp lỗi khi chạy tool: 1. Thử lại 1 lần với cách khác 2. Nếu vẫn fail → DỪNG LẠI 3. Báo cáo: lỗi gì, đã thử gì, cần gì từ tôi 4. Chờ tôi hướng dẫn trước khi tiếp tục # Không bao giờ retry quá 2 lần với cùng một vấn đề
Chương 05 / 05

Dùng Claude Code
như người master

Tất cả kỹ thuật ở trên dẫn đến 5 habit thực tế. Không phải tip vặt vãnh — mỗi cái giải quyết một điểm yếu kiến trúc cụ thể đã phân tích ở trên.

Habit 1 — giải quyết Memory problem
CLAUDE.md là external memory duy nhất hoạt động
Vì AI không có persistent memory (chapter 1), bạn cần build nó. CLAUDE.md đặt ở root project, chứa ngữ cảnh project, rules không được vi phạm, và tool preferences. Claude Code đọc file này ở đầu mỗi session — đây là cách duy nhất để instruction sống qua multiple session.
Habit 2 — giải quyết Hallucination problem
Cung cấp documentation vào context, không để AI tự đoán
Với bất kỳ API, library, hay business logic đặc thù nào — paste docs/ví dụ thật vào context trước khi giao task. AI sẽ pattern-match từ thông tin bạn cung cấp thay vì phải generate từ phân phối training data không đủ dữ liệu. Reduce hallucination đáng kể cho domain-specific tasks.
Habit 3 — giải quyết Sycophancy problem
Evidence-based verification — yêu cầu kết quả thật, không phải lời báo cáo
Thay vì hỏi "xong chưa?", luôn kết thúc task bằng yêu cầu chạy và show output. "Viết test cho hàm này, chạy test, paste toàn bộ output." Output không thể fake — lời báo cáo thì có thể.
Habit 4 — giải quyết Goal Drift problem
Scope boundary rõ ràng — nói cả những gì không được làm
Prompt tốt không chỉ define task — còn define boundary. "Chỉ sửa file X, không đụng Y và Z, nếu thấy vấn đề ngoài scope báo tôi thay vì tự sửa." Constraint rõ ràng prevent drift tốt hơn nhiều so với mô tả mục tiêu rõ ràng.
Habit 5 — giải quyết Tool Spiral problem
Explicit exit condition cho agentic task
Với mọi task có tool use, thêm instruction về exit: "Nếu fail 2 lần, dừng và báo cáo" và "Với action irreversible, hiển thị command và chờ confirm." Hai câu này prevent phần lớn tool spiral và unintended side effects.
Người dùng AI tốt nhất không phải người biết nhiều về AI nhất. Mà là người thiết kế workflow phù hợp với đặc điểm kiến trúc của AI — khai thác điểm mạnh, phòng ngừa điểm yếu, và biết khi nào cần tự đứng ra làm. — Mental model tổng kết
Mức độ autonomy nên giao cho AI theo loại task
Viết docs, comment
Cao
Boilerplate, CRUD code
Cao
Refactor có test coverage
Cao
Debug có error log đủ
Khá
Integration multi-system
Trung bình
Architecture decision
Thấp
Data migration production
Rất thấp