Chương 9
AI Agent Thực Sự Là Gì?

Chín chương trước đã dựng framework SDD. Chương này lùi một bước để trả lời câu hỏi nền tảng: AI Agent thực sự là gì ở góc nhìn kiến trúc kỹ thuật, không phải khẩu hiệu.

Điểm cốt lõi cần hiểu: cơ chế nào cho phép agent đọc file, chạy test, tự sửa lỗi và lặp lại đến khi đạt mục tiêu; khi nào agent đang thật sự suy luận và khi nào nó chỉ đang đoán theo pattern.

Từ "agent" bị lạm dụng. Định nghĩa kỹ thuật chính xác: một AI Agent phải có khả năng nhận thức trạng thái môi trường (Perception), lập kế hoạch theo trạng thái (Reasoning), thực thi hành động (Action), rồi điều chỉnh dựa trên phản hồi (Feedback Loop) cho đến khi đạt mục tiêu.

Inference-time Compute giải thích vì sao agent hiện đại thông minh hơn simple autocomplete. Thay vì sinh output ngay, model dành compute để suy luận rồi mới commit kết quả.

Claude Sonnet hay o1 có thể chậm hơn GPT-3.5 ở tốc độ phản hồi tức thời nhưng thường chất lượng tốt hơn cho task nhiều bước, logic phức tạp, debugging đa file.

Extended Thinking trong Claude tạo thinking tokens ẩn trước output, hữu ích cho phân tích vấn đề, cân nhắc nhiều approach và phát hiện edge case; đổi lại token cost thường tăng 2-5 lần.

Ba thế hệ công cụ coding AI có năng lực kiến trúc khác nhau: autocomplete chỉ gợi token kế tiếp; conversational tạo code/text theo prompt; agent có khả năng lập kế hoạch, thực thi tool, nhận phản hồi và tự sửa lỗi theo vòng lặp.

Khi chạy pytest và nhận lỗi AssertionError, IntegrityError, agent không dừng để hỏi tiếp mà tự parse output, trace root cause, tạo bản sửa và chạy test lại.

FAILED test_cart_merge_max_qty: assert 5 == 3
FAILED test_concurrent_add: duplicate key value violates unique constraint
1 passed, 2 failed in 0.23s

Agentic coding system không chỉ là "LLM + khả năng chạy code". Đây là pipeline gồm model lõi, context management, tool orchestration, state tracking, feedback parsing và inject lại context cho vòng kế tiếp.

Trước MCP, mỗi tool phải tích hợp riêng cho từng agent. MCP chuẩn hóa giao tiếp kiểu "write once, use everywhere": bất kỳ server nào implement protocol đều dùng lại được trên host tương thích.

Trong SDD, agent cần đọc spec từ issue tracker, đọc code từ filesystem, chạy test ở terminal và cập nhật trạng thái project. MCP là lớp chuẩn hóa để các luồng này nối liền.

Khi nhận task "Fix failing cart merge test", agent không phản hồi ngay. Nó đọc failure, đối chiếu SPEC, so sánh approach, dự báo side effects, rồi mới quyết định sửa logic cộng quantity thành lấy max.

<thinking>
Approach 1: change add -> max
Approach 2: verify test vs spec
SPEC §3 says keep max(guest_qty, user_qty)
=> Test đúng, code sai. Fix CartMergeService.merge().
</thinking>

Một hiểu lầm phổ biến: nghĩ HITL là dấu hiệu AI chưa đủ mạnh. Thực tế, đây là thiết kế chủ ý để kiểm soát risk tại các điểm khó đảo ngược.

Đọc logs cho biết agent đã làm gì, vì sao làm, lúc nào sai. Các mốc quan trọng: TASK_START, TOOL_CALL, THINKING duration, HUMAN_APPROVED, exit_code, TASK_COMPLETE.

[10:23:05] read_file SPEC.md -> Agent đọc spec
[10:23:08] THINKING duration 3.2s
[10:23:18] execute_command pytest -> exit_code 1
[10:23:19] THINKING duration 4.1s (analyze error)
[10:23:28] execute_command pytest -> exit_code 0
[10:23:30] TASK_COMPLETE total_tokens 22450

Extended Thinking thường ẩn nhưng có thể bật trong Cline (`cline.showThinking`) hoặc qua API (`thinking: enabled`) để quan sát logic ra quyết định.

{
  "cline.showThinking": true,
  "cline.budgetTokens": 5000
}

client.messages.create(
 model="claude-sonnet-4-5",
 thinking={"type":"enabled","budget_tokens":5000}
)

Ngay cả model mạnh như Claude Opus hay GPT-4o vẫn có giới hạn từ kiến trúc. Mục tiêu không phải nản, mà là thiết kế quy trình phù hợp với điểm mạnh và điểm mù của agent.

Mỗi thao tác đọc file, chạy command, nhận output, reasoning đều đốt token. Task tưởng nhỏ có thể lên 50K-200K token.

Loop trap xuất hiện khi fix lỗi A sinh lỗi B rồi quay lại A. Mỗi vòng trông khác nhau cục bộ nhưng không tiến bộ toàn cục.

Cline, Claude Code, Cursor đều là orchestration layer. Trần chất lượng vẫn phụ thuộc năng lực model bên dưới. Agent architecture tốt + model yếu vẫn có thể tệ hơn architecture đơn giản + model mạnh.