Xây Dựng Vòng Lặp Tự Xác Minh Cho Claude Code

TL;DR - Claude Code có Stop hook chặn agent hoàn thành đến khi pass verification. Kết hợp với PostToolUse feedback injection, bạn có thể xây verification loop 3 lớp (syntax, intent, regression) trong 20 phút. Nhảy đến setup đầy đủ →

📊 Bài này xây dựng:

• Hệ thống verification 3 lớp dùng 2 hook event và 3 kiểu handler
• Stop hook copy-paste sẵn với anti-loop protection (stop_hook_active)
• Config .claude/settings.json đầy đủ kết hợp cả 3 lớp
• Walkthrough end-to-end: một task pagination, cả ba lớp lần lượt lên tiếng
• Phân tích ROI (lợi tức đầu tư): verification tốn token, nhưng bỏ qua nó tốn 7 giờ/tuần

Cùng một phiên Claude Code, hai cách setup hook, và kết quả thì khác nhau hoàn toàn:

# Cái mà đa số dev có: formatting hook
# PostToolUse: chạy prettier sau khi edit file
jq -r '.tool_input.file_path' | xargs npx prettier --write

# Cái bài này xây dựng: verification loop
# PostToolUse: kiểm tra syntax trên mỗi file thay đổi
# Stop: chặn hoàn thành đến khi pass test + verify xong intent
# Kết quả: agent không thể nói "xong" khi chưa thực sự xong

Setup đầu tiên chỉ bắt được lỗi formatting, còn setup thứ hai bắt lỗi logic, yêu cầu bị thiếu, và test bị fail trước khi agent kịp tuyên bố đã xong.

Tại sao cần verification loop?

Vì “xong” chỉ là một lời tuyên bố, không phải một kết quả đã được kiểm chứng. Bạn yêu cầu Claude Code sửa một thứ, nó edit bốn file, báo thành công rồi dừng — nhưng đến khi bạn chạy code thì một test bị fail và một yêu cầu bị bỏ sót. Agent không nói dối; nó chỉ không có cơ chế nào buộc phải kiểm tra lại trước khi tuyên bố hoàn thành.

Số liệu về niềm tin phản ánh đúng điều đó: chỉ 3% developer báo rằng họ tin tưởng cao vào code AI tạo ra (Qodo, State of AI Code Quality, 2025). Và cái giá đo đếm được: các team mất trung bình 7 giờ mỗi tuần mỗi engineer cho AI-related inefficiency, phần lớn là rework trên những đoạn code đã được tuyên bố là xong (Exceeds AI, 2026).

Đây không phải vấn đề của model, mà là vấn đề thiếu feedback. Trong một phiên Claude Code mặc định, không có gì chạy giữa lúc agent ngừng gõ và lúc bạn chấp nhận kết quả — mọi bước kiểm tra đều thủ công, nên mọi lỗi lọt lưới đều do bạn gánh. Verification loop đưa các bước kiểm tra đó vào ngay trong phiên, nơi agent buộc phải pass hết trước khi được phép kết thúc.

PreCompletionChecklistMiddleware của LangChain là ví dụ được ghi nhận nhiều nhất về pattern này. Nó góp phần vào mức tăng 13.7 điểm benchmark chỉ từ thay đổi harness. Bài này xây dựng phiên bản tương đương cho Claude Code bằng hook. Nhưng trước khi đụng vào config, cần thống nhất đã: “verification” ở đây cụ thể là kiểm tra cái gì?

”Verification” thực sự nghĩa là gì với AI coding agent?

Verification nghĩa là kiểm tra xem output của agent có khớp với intent của task hay không, chứ không chỉ dừng ở việc code có compile được. Đa số dev hiện mới check tới mức syntax (lint, format, type-check), trong khi verification cho production cần thêm hai lớp nữa.

Ba lớp verification, mỗi lớp bắt một loại lỗi khác nhau:

Ba lớp verification: mỗi lớp bắt một loại lỗi khác nhau, mỗi lớp map tới một Claude Code hook event cụ thể.

“Chạy test” mới chỉ cover được Layer 3, vì test chỉ xác minh những gì bạn đã viết test cho, chứ không phải những gì bạn yêu cầu agent làm. Nếu bạn yêu cầu Claude thêm pagination mà nó lại đi thêm sorting thì mọi test vẫn pass — Layer 2 sinh ra để bắt đúng loại lỗi đó.

Hệ thống Honk của Spotify chứng minh điều này ở quy mô lớn: 1,500+ PR được merge qua verification loop, xử lý khoảng 50% tổng số PR tự động (Spotify Engineering, Dec 2025). Lựa chọn thiết kế đáng chú ý của họ là agent không hề biết verification hoạt động như thế nào — nó chỉ nhận feedback pass/fail, và chính sự tách biệt này giữ cho agent tập trung vào task.

Hai trong ba lớp ở bảng trên — Intent và Regression — đứng trên cùng một cơ chế của Claude Code: Stop hook. Đáng để chúng ta dành vài phút hiểu kỹ cơ chế này trước khi viết dòng config đầu tiên.

Điểm mấu chốt: Chỉ 3% developer tin tưởng cao vào code AI (Qodo, 2025). Hệ thống Honk của Spotify đã merge 1,500+ PR qua verification loop bằng cách chỉ trả về pass/fail cho agent mà không tiết lộ logic verification. Agent tập trung vào task, không phải vào việc tìm cách qua mặt verifier (Spotify Engineering, Dec 2025).

Stop hook của Claude Code hoạt động như thế nào?

Stop hook chạy mỗi khi Claude kết thúc một phản hồi, và exit code 2 sẽ chặn nó dừng lại, buộc nó tiếp tục làm việc — cơ chế đơn giản này chính là thứ ngăn agent nói “xong” khi chưa xong (Claude Code docs). Stop hook hỗ trợ 4 loại handler; để so sánh chi tiết, xem Hook Decision Guide.

Đây là phần quan trọng mà hầu hết các tutorial bỏ qua: trường stop_hook_active.

Exit code 2 đẩy Claude quay lại làm việc thay vì cho nó kết thúc; guard stop_hook_active là thứ ngăn điều đó biến thành loop vô hạn.

#!/bin/bash
INPUT=$(cat)

# QUAN TRỌNG: ngăn vòng lặp verification vô hạn
# Khi true, Claude đang ở trạng thái forced-continuation
if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0  # Cho Claude dừng, đừng loop mãi
fi

# Chạy test, chặn stop nếu test fail
npm test 2>&1 || {
  echo "Test đang fail. Sửa trước khi hoàn thành." >&2
  exit 2
}

exit 0

Nếu không kiểm tra stop_hook_active, hook sẽ chặn mọi lần agent cố dừng: Claude sửa test, cố dừng, bị chặn, sửa tiếp, lại cố dừng, lại bị chặn — một loop vô hạn. Vì vậy, luôn phải kiểm tra trường này.

Stop hook nhận JSON đầu vào như sau:

{
  "session_id": "abc123",
  "transcript_path": "/path/to/transcript.jsonl",
  "cwd": "/your/project",
  "hook_event_name": "Stop",
  "stop_hook_active": false
}

Hai cách gửi feedback về cho model:

1. Exit 2 + stderr: Nội dung stderr xuất hiện như feedback để Claude đọc, hành động, rồi thử dừng lại lần nữa.
2. Exit 0 + JSON với additionalContext: Inject context vào turn tiếp theo mà không chặn — hợp với những cảnh báo không cần hành động ngay.

Feedback qua additionalContext bị giới hạn 10,000 ký tự, nên nếu output test dài hơn thì phải lọc bớt. HumanLayer đã học bài này khi 4,000 dòng test pass tràn ngập context window làm agent mất dấu task — hãy chỉ hiển thị lỗi.

Điểm mấu chốt: Stop hook của Claude Code chạy mỗi khi agent hoàn thành phản hồi; exit code 2 chặn agent và gửi stderr làm feedback. Trường stop_hook_active ngăn loop vô hạn bằng cách báo hiệu khi Claude đang ở trạng thái forced-continuation — luôn kiểm tra trường này trong mọi Stop hook (Claude Code docs).

Làm sao xây verification loop 3 lớp?

Hiểu cơ chế rồi thì phần còn lại là lắp ráp: chúng ta kết hợp ba hook trên hai event — command hook PostToolUse cho syntax (Layer 1), command hook Stop cho regression (Layer 3), và prompt hook Stop cho intent (Layer 2). Mỗi lớp chạy tự động để agent nhận feedback và tự sửa. Đây là một ví dụ harness engineering cụ thể, áp dụng Layer 4 trong mô hình harness 5 lớp cho verification thay vì chỉ guardrail.

Layer 1: Verification syntax (PostToolUse)

Lớp này chạy sau mỗi lần Write hoặc Edit để kiểm tra lint và lỗi kiểu dữ liệu trên file vừa thay đổi — nhanh, deterministic (luôn cho cùng một kết quả), và không tốn token nào.

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Bỏ qua file không phải JS/TS
if [[ ! "$FILE_PATH" =~ \.(ts|tsx|js|jsx)$ ]]; then
  exit 0
fi

Guard clause thoát sớm với file không phải JS, còn phần lint check chạy trên tất cả file còn lại:

# Chạy ESLint trên file đã thay đổi, chỉ hiển thị error
LINT_OUTPUT=$(npx eslint "$FILE_PATH" --quiet 2>&1)
LINT_EXIT=$?

if [ $LINT_EXIT -ne 0 ]; then
  echo "{\"additionalContext\": \"Lint error trong $FILE_PATH:\\n$LINT_OUTPUT\"}"
  exit 0
fi

exit 0

Chi tiết quan trọng nằm ở chỗ hook này trả exit 0 chứ không phải exit 2: PostToolUse hook không thể undo một file write, nên trường additionalContext sẽ inject lint error vào turn tiếp theo để Claude thấy lỗi và tự sửa.

PostToolUse chỉ có thể thì thầm vào turn tiếp theo; Stop thì đóng sập cửa. Chọn kênh dựa trên việc agent có buộc phải hành động ngay hay không.

Đừng in output khi mọi thứ pass mà hãy chỉ hiển thị lỗi — nếu mỗi lần lint pass đều dump output vào context, bạn đang đốt token vô ích.

Layer 2: Verification intent (prompt hook Stop)

Lớp này chạy khi Claude cố dừng, hỏi một LLM (mô hình ngôn ngữ lớn) kiểm tra xem yêu cầu ban đầu đã được giải quyết hết chưa — chính là phiên bản Claude Code của PreCompletionChecklistMiddleware từ LangChain.

{
  "type": "prompt",
  "prompt": "Review what was accomplished in this session. Check if all requirements from the user's original request were addressed. If anything is incomplete or missing, respond with {\"decision\": \"block\", \"reason\": \"Incomplete: <what remains>\"}. If everything looks complete, respond with {\"decision\": \"allow\"}."
}

Với task phức tạp, hãy thay prompt hook bằng agent hook: nó tạo một subagent có thể Read file, Grep codebase, và chạy Bash command — kỹ lưỡng hơn, đổi lại chậm thêm 2-10 giây.

{
  "type": "agent",
  "prompt": "Verify the work is complete. Read the modified files. Check that the changes match the user's request. Run the test suite. If anything is missing or broken, explain what needs fixing.",
  "timeout": 120
}

Layer 3: Verification regression (command hook Stop)

Lớp này cũng chạy khi Claude cố dừng, nhưng là kiểm tra deterministic: test có pass không, build có thành công không?

#!/bin/bash
INPUT=$(cat)

# Anti-loop protection, BẮT BUỘC
if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
  exit 0
fi

# Chạy test
TEST_OUTPUT=$(npm test 2>&1)
if [ $? -ne 0 ]; then
  TRIMMED=$(echo "$TEST_OUTPUT" | tail -50)
  echo "Test đang fail. Sửa trước khi hoàn thành:\\n$TRIMMED" >&2
  exit 2
fi

Nếu test pass, script kiểm tra tiếp đến build:

# Chạy build (tiếp tục verify-regression.sh)
BUILD_OUTPUT=$(npm run build 2>&1)
if [ $? -ne 0 ]; then
  TRIMMED=$(echo "$BUILD_OUTPUT" | tail -30)
  echo "Build đang fail:\\n$TRIMMED" >&2
  exit 2
fi

exit 0

Config đầy đủ

Giờ chúng ta gom cả ba lớp vào một .claude/settings.json, trong đó PostToolUse hook xử lý syntax (Layer 1):

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/verify-syntax.sh" }
        ]
      }
    ]
  }
}

Stop hook xử lý regression (Layer 3) và intent (Layer 2), theo thứ tự đó:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "bash .claude/hooks/verify-regression.sh" },
          {
            "type": "prompt",
            "prompt": "Review what was accomplished. Check if all requirements from the user's original request were addressed. If incomplete, respond with {\"decision\": \"block\", \"reason\": \"<what remains>\"}. If complete, respond with {\"decision\": \"allow\"}."
          }
        ]
      }
    ]
  }
}

Stop hook chạy theo thứ tự định nghĩa, nên hãy đặt command hook nhanh (Layer 3) lên trước: nếu test fail thì không cần tốn công chạy prompt hook chậm hơn (Layer 2). Command hook chặn, Claude sửa, và chỉ khi test pass thì prompt hook mới vào đánh giá intent.

Boris Cherny, người tạo ra Claude Code, cho biết verification feedback loop cải thiện chất lượng đáng kể: “Hãy cho Claude một cách để verify công việc của nó. Khi Claude có feedback loop đó, chất lượng kết quả cuối cùng sẽ tăng 2-3 lần” (X thread, 2026).

Tất nhiên, mức cải thiện đó không miễn phí — câu hỏi còn lại là cái giá cụ thể.

Điểm mấu chốt: Boris Cherny, người tạo ra Claude Code, cho biết verification feedback loop cải thiện chất lượng đáng kể: “Hãy cho Claude một cách để verify công việc của nó. Khi Claude có feedback loop đó, chất lượng kết quả cuối cùng sẽ tăng 2-3 lần.” Đây là quan sát từ người tạo ra tool, không phải nghiên cứu có kiểm soát (X thread, 2026).

Nhận tip Claude Code hàng tuần - Config thực tế, không lý thuyết. Một email mỗi tuần. Đăng ký AI Developer Weekly →

Chi phí chạy verification hook là bao nhiêu?

Verification hook thêm khoảng 10-20% token overhead mỗi phiên, chủ yếu từ prompt/agent Stop hook; command hook thì không tốn token và chạy dưới 5 giây wall time. Nhưng bỏ qua verification còn tốn nhiều hơn thế: các team mất trung bình 7 giờ mỗi tuần mỗi engineer cho AI-related inefficiency, và tỷ lệ rework code AI đạt 20-30% khi code AI vượt 40% codebase (Exceeds AI, 2026).

Các ước tính giảm rework ở trên là định hướng chứ không đến từ nghiên cứu có kiểm soát, nhưng dù tính thận trọng thì bài toán vẫn có lợi cho bạn: nếu một task fail tốn 30 phút rework và verification ngăn được một failure mỗi ngày, bạn đã tiết kiệm 2.5 giờ mỗi tuần với chỉ khoảng 500 token thêm mỗi phiên.

Còn một vấn đề nhận thức nữa: developer cảm thấy nhanh hơn 20% khi dùng AI tool nhưng thực tế lại chậm hơn 19% trên task phức tạp (Exceeds AI, 2026) — khoảng cách đó chính là rework đang ẩn sau cảm giác năng suất. Verification đóng khoảng cách này bằng cách bắt vấn đề ngay ở bước N thay vì đợi đến bước N+5.

Bạn không cần cả 3 lớp cùng lúc — theo best practice harness engineering, bắt đầu với một layer vẫn tốt hơn là ngồi plan cả ba. Layer 3 (test-runner Stop hook) là bổ sung có ROI cao nhất: chỉ 15 dòng bash, không tốn token, và bắt được kịch bản thất bại (failure mode) phổ biến nhất — agent nói “xong” trong khi test đang fail.

Adopt theo thứ tự 3 → 1 → 2: bắt đầu với test-runner Stop hook, thêm syntax kế tiếp, và chỉ thêm intent checking sau một lần intent thực sự lỗi.

Điểm mấu chốt: Tỷ lệ rework code AI đạt 20-30% khi code AI vượt 40% codebase, và các team mất 7 giờ mỗi tuần mỗi engineer cho AI-related inefficiency. Verification hook thêm 10-20% token overhead nhưng ngăn các chu kỳ rework thực sự làm giảm năng suất (Exceeds AI, 2026).

Khi nào nên dùng mỗi lớp verification?

Layer 1 (syntax) thì lúc nào cũng nên bật: nó miễn phí, bắt lỗi hiển nhiên, và chạy dưới 2 giây. Layer 3 (regression) dùng khi project có test suite — đây là hook đơn lẻ có ROI cao nhất. Còn Layer 2 (intent) dành cho task phức tạp hoặc nhiều bước, nơi agent có thể giải quyết sai vấn đề ngay từ đầu.

Cách áp dụng dần:

1. Tuần 1: Thêm Stop hook Layer 3 (test runner) bằng cách copy script verify-regression.sh ở trên — một hook duy nhất nhưng bắt được kịch bản thất bại phổ biến nhất.
2. Tuần 2: Thêm PostToolUse hook Layer 1 (syntax) bằng cách copy verify-syntax.sh — từ giờ lint error được tự động sửa thay vì chồng chất.
3. Khi gặp lỗi intent: Thêm prompt hook Layer 2 — bạn sẽ biết mình cần nó khi Claude hoàn thành một task pass mọi test nhưng lại không khớp với yêu cầu bạn đặt ra.

Cách này đi theo phương pháp failure-first: thêm constraint sau những thất bại thực, chứ không phải trước những thất bại tưởng tượng.

Điểm mấu chốt: Pattern failure-first (Layer 3 trước, rồi Layer 1, rồi Layer 2 khi cần) phản ánh cách các team production xây dựng độ tin cậy: giải quyết thất bại đã thấy trước khi phòng chống thất bại giả định. Bắt đầu với Stop hook test-runner 15 dòng và mở rộng chỉ khi gặp lỗi intent thực tế.

Thử ngay:

1. Copy verify-regression.sh vào .claude/hooks/
2. Thêm Stop hook config vào .claude/settings.json
3. Làm cho nó executable: chmod +x .claude/hooks/verify-regression.sh
4. Yêu cầu Claude thay đổi code, rồi kiểm tra xem Stop hook có chạy khi test fail không
5. Xác nhận agent sửa vấn đề trước khi hoàn thành

Verification loop trông như thế nào trên một task thực tế?

Checklist ở trên mới là lý thuyết — giờ chúng ta xem vòng lặp vận hành trên một yêu cầu điển hình, với cả ba lớp từ config ở trên đang bật. Task: “Thêm pagination cho GET /api/posts — page size mặc định là 20.”

Turn 1 — Layer 1 lên tiếng. Claude edit src/api/posts.ts và để sót một biến offset không dùng. PostToolUse hook chạy ESLint trên file đó và inject lỗi vào turn kế tiếp qua additionalContext. Claude tự xóa biến thừa mà không cần ai nhắc — không chặn, không ồn ào, lỗi được sửa ngay giữa task.

Turn 4 — Layer 3 chặn. Claude làm xong endpoint và cố dừng. Command hook Stop chạy npm test: hai contract test fail vì response đổi cấu trúc (posts chuyển vào trong data). Exit 2 gửi phần lỗi đã cắt gọn về qua stderr, Claude đọc output, sửa serializer rồi chạy lại.

Turn 5 — Layer 2 chặn. Chốt chặn stop_hook_active cho command hook đi qua — Claude đã tự chạy lại test sau khi sửa serializer — và prompt hook bắt đầu đối chiếu intent: yêu cầu ghi “page size mặc định là 20” nhưng Claude hard-code 10. Hook trả về {"decision": "block", "reason": "Incomplete: default page size is 10, request specified 20"}. Claude sửa hằng số và thêm một test cho chính nó.

Turn 6 — vòng lặp buông tay. Claude dừng lần nữa. Intent check trả về {"decision": "allow"}, và — như mọi lần cố dừng kể từ lần chặn đầu tiên — stop_hook_active giữ cho command hook không chạy lại. Agent báo xong, và lần này xong thật.

Tổng chi phí chỉ là thêm ba turn và vài trăm token; không có vòng lặp, cả ba lỗi trên sẽ trôi thẳng vào code review — hoặc tệ hơn, vào production.

Kết luận

Verification loop biến “xong” từ một lời tuyên bố thành một kết quả đã được kiểm chứng. Ba lớp chia nhau việc: PostToolUse bắt lỗi syntax ngay khi file thay đổi, command hook Stop bắt regression trước khi agent kết thúc, và prompt hook Stop bắt thứ mà test không nhìn thấy — giải quyết sai vấn đề.

Đừng cố xây cả ba lớp ngay trong tuần này mà hãy bắt đầu với Stop hook chạy test 15 dòng: đây là bổ sung đơn lẻ có ROI cao nhất, và nó chặn đúng kịch bản thất bại phổ biến nhất — “xong” trong khi test đang fail. Thêm lớp syntax kế tiếp, và chỉ thêm intent check sau lần lỗi intent thực tế đầu tiên; dù thêm lớp nào, luôn giữ chốt chặn stop_hook_active trong mọi Stop hook.

Pattern lớn hơn đằng sau những gì chúng ta vừa xây: Agent = Model + Harness. Model đã viết được code; harness mới là thứ làm cho chữ “xong” của nó đáng tin. Verification là lớp harness có đòn bẩy lớn nhất — bắt đầu từ đó, rồi xây tiếp phần còn lại của harness engineering stack.

Xây dựng harness, không chỉ prompt. Verification là một layer. Hệ thống đầy đủ gồm memory, tool, permission, và observability. Đăng ký AI Developer Weekly →

FAQ

Self-verification loop trong Claude Code là gì?

Self-verification loop là hệ thống hook tự động kiểm tra output của Claude Code ở nhiều cấp độ (syntax, intent, regression) trước khi cho phép agent hoàn thành. Nó dùng PostToolUse hook để kiểm tra từng file và Stop hook để verify khi hoàn thành task; agent nhận feedback và tự sửa mà không cần review thủ công. Đây là phiên bản Claude Code của PreCompletionChecklistMiddleware từ LangChain.

Verification có làm chậm Claude Code không?

Command hook thêm dưới 5ms, prompt hook thêm 300-2000ms mỗi Stop event, còn agent hook thêm 2-10 giây — và chúng chỉ chạy một lần khi Claude cố dừng chứ không phải trên mỗi tool call. Overhead này nhỏ so với 7 giờ mỗi tuần các team mất cho AI-related rework (Exceeds AI, 2026).

Stop hook trong Claude Code là gì?

Stop hook chạy mỗi khi Claude kết thúc một phản hồi; exit code 2 chặn Claude dừng lại và buộc nó tiếp tục với feedback từ stderr. Trường stop_hook_active ngăn loop vô hạn bằng cách báo hiệu khi Claude đang ở trạng thái forced-continuation. Nó hỗ trợ 4 loại handler: command, prompt, agent, và http (Claude Code docs).

Làm sao ngăn loop vô hạn trong verification hook?

Luôn kiểm tra trường stop_hook_active trong Stop hook: khi giá trị là true, Claude đang ở trạng thái forced-continuation từ lần chặn trước và hook nên trả exit 0 để cho nó dừng. Thiếu kiểm tra này, hook sẽ chặn mọi lần cố dừng vô thời hạn, tạo thành loop vô hạn đốt token đến khi phiên hết thời gian.

Harness engineering là gì?

Harness engineering là kỷ luật xây dựng constraint, tool, feedback loop, và observability quanh AI agent để nó hoạt động ổn định trong production. Công thức: Agent = Model + Harness — model giữ nguyên, còn hệ thống quanh nó mới là thứ cải thiện kết quả, và self-verification loop là một ví dụ như vậy. Để hiểu framework đầy đủ, đọc Harness Engineering: Hệ Thống Quanh AI Quan Trọng Hơn AI.

Đọc Tiếp

• Harness Engineering: Hệ Thống Quanh AI Quan Trọng Hơn AI - Framework giải thích tại sao verification quan trọng, với dữ liệu benchmark LangChain và tổng quan harness 5 lớp.
• Chọn Hook Nào Cho Claude Code? Hướng Dẫn Quyết Định - So sánh 4 loại handler với decision tree. Dùng bài này để chọn giữa command, prompt, agent, và http hook cho các lớp verification.
• Nghịch Lý Ràng Buộc: Ít Tự Do AI Hơn, Code Tốt Hơn - Tại sao thêm constraint như verification loop thực sự cải thiện output của agent, với ba nguồn dữ liệu độc lập làm bằng chứng.