Agent production: prompt hay loop?

Agent production: prompt hay loop?

Đừng hỏi model nào thông minh hơn trước. Hãy hỏi workflow của bạn cần một câu trả lời, một vòng lặp, hay một hệ thống có phanh.

“Nếu task này fail lúc 3 giờ sáng, ai respawn nó?”

Mình từng nghe một tech lead hỏi câu đó trong một buổi review agent nội bộ. Cả phòng im vài giây, vì trước đó mọi người đang hăng hái bàn model mới, tool calling, browser automation, memory, đủ món. Nhưng câu hỏi kia kéo cả team về mặt đất: agent production không chết vì prompt dở trước tiên; nó chết vì không ai thiết kế vòng lặp, checkpoint và guardrail.

Tranh luận thật sự không phải “prompt engineering hết thời chưa?”. Cũng không phải “loop engineering có phải tên mới của agent không?”. Tranh luận đáng tiền là: khi nào bạn chỉ cần một prompt tốt, khi nào phải build loop, và khi nào loop đó đã đủ nguy hiểm để cần một lớp orchestration riêng?

Nói thẳng ra thì: prompt là một lượt nói chuyện với model; loop là hệ thống biết hỏi lại, kiểm tra, quyết định bước tiếp theo mà không chờ người bấm nút.

Sơ đồ minh họa cho bài Agent production: prompt hay loop?

Sơ đồ tóm tắt ý chính của bài viết.

Phe A: cứ prompt tốt đã, đừng build mê cung

Prompt engineering — thiết kế cách nói chuyện với model trong một lượt — vẫn là nền móng. Nếu prompt một lần đã không rõ input, output, format, tiêu chí đúng sai, thì bọc thêm loop chỉ làm lỗi chạy nhanh hơn.

Prompt phù hợp khi task có ba đặc điểm:

Ví dụ cụ thể: bạn có một issue GitHub dài và muốn model rút ra “nguyên nhân khả dĩ, file liên quan, câu hỏi cần hỏi lại”. Một prompt tốt với format cố định là đủ:

Bạn là code reviewer. Đọc issue sau và trả về:
1. Tóm tắt lỗi trong 3 dòng
2. 3 giả thuyết nguyên nhân
3. File/khu vực code cần kiểm tra
4. Câu hỏi cần hỏi reporter
Không tự bịa stack trace nếu issue không có.

Ở đây build loop là hơi quá tay. Giống vào màn tutorial mà đã lôi gear đánh boss cuối: nhìn oai, nhưng nặng người.

Nhược điểm của phe prompt-only là nó đẩy phần “vòng lặp” sang con người. Bạn copy output, chạy test, thấy sai, sửa prompt, hỏi lại, dán kết quả vào tool khác. Với một task/ngày thì ổn. Với một workflow lặp 200 lần/tuần, con người thành scheduler bằng cơm.

Phe B: loop mới là nơi sản phẩm AI bắt đầu

Loop engineering — thiết kế vòng lặp model → kiểm tra → quyết định → hành động — xuất hiện khi workflow có trạng thái và nhánh rẽ.

Một loop tối thiểu thường có 5 phần:

  1. Input contract: dữ liệu vào có schema rõ.
  2. Model step: prompt hoặc tool call tạo kết quả.
  3. Evaluator: bộ kiểm tra tự động, có thể là rule, test, hoặc một model khác.
  4. Decision policy: nếu pass thì đi tiếp, fail thì retry/sửa/dừng.
  5. Trace log: ghi lại input, output, decision, tool đã gọi.

Hình dung thế này: team bạn muốn agent xử lý bug report. Nó không chỉ đọc issue rồi trả lời. Nó phải phân loại bug, tìm file liên quan, tạo patch, chạy test, nếu test fail thì sửa, nếu quá 2 lần fail thì mở PR draft kèm ghi chú.

Đó không còn là “viết prompt hay”. Đó là orchestration — điều phối nhiều bước, nhiều tool và nhiều quyết định để hoàn thành việc.

Nhưng loop cũng có giá của nó:

| Lựa chọn | Hợp khi | Rủi ro chính | Cần đo gì |
|---|---|---|---|
| Prompt một lượt | Task ngắn, có người duyệt | Output lệch format, thiếu ngữ cảnh | Tỷ lệ dùng được sau chỉnh sửa |
| Loop bán tự động | Task nhiều bước, có test/rule | Retry vô hạn, sửa sai chồng sai | Pass rate, số lần retry, thời gian xử lý |
| Agent có tool thật | Có API, repo, browser, quyền ghi | Tool gọi nhầm, prompt injection, leak dữ liệu | Action log, block rate, rollback rate |

Điểm nhiều team hiểu sai: loop không làm hệ thống thông minh hơn một cách miễn phí. Loop chỉ biến một lần đoán thành nhiều lần đoán có kiểm tra. Nếu kiểm tra yếu, loop sẽ farm exp cho lỗi.

Biến số 1: task có “điểm kiểm tra” được không?

Trước khi build agent, hãy hỏi: workflow này có checkpoint rõ không?

Checkpoint là điều kiện khách quan để biết bước vừa rồi đủ tốt hay chưa. Trong coding agent, checkpoint có thể là:

Nếu task không có checkpoint, loop dễ biến thành cuộc độc thoại tự tin. Ví dụ “hãy nghiên cứu thị trường và đề xuất chiến lược” nghe có vẻ hợp agent, nhưng nếu không có tiêu chí kiểm chứng, agent chỉ chạy vòng quanh với nhiều chữ hơn.

Với builder, câu hỏi đổi cách nghĩ là: đừng hỏi agent làm được gì; hỏi bạn có thể kiểm tra được gì sau mỗi bước.

Biến số 2: ai giữ quyền điều khiển — model hay harness?

Một ý đáng chú ý trong tranh luận gần đây là không nên giao toàn bộ “suy nghĩ vận hành” cho một model hoặc một harness đóng kín. Harness ở đây là lớp bao quanh model: nơi giữ context, memory, tool, policy và workflow.

Nếu harness dính chặt vào một vendor, bạn khó đổi model, khó giữ metadata, và khó phân tích vì sao agent làm sai. Metadata — dữ liệu quanh mỗi lần dùng như prompt, output, tool call, latency, cost, decision — là thứ giúp team debug và cải thiện hệ thống sau này.

Với production, mình sẽ tách ba lớp:

[Workflow / Orchestration]
        ↓
[Policy / Guardrail / Logging]
        ↓
[Model Provider A/B/C]

Model có thể thay. Workflow và log nên thuộc về bạn. Không phải vì “tự chủ” nghe cho mạnh mẽ, mà vì khi incident xảy ra, bạn cần replay được đường đi nước bước.

Prompt injection — kiểu tấn công nhét chỉ dẫn độc hại vào dữ liệu đầu vào để model làm trái lệnh — là ví dụ rõ nhất. Một model mạnh hơn có thể giảm rủi ro, nhưng lớp phòng thủ thật sự thường nằm ở cả trước và sau model: scan input, giới hạn tool, chặn action nguy hiểm, yêu cầu xác nhận với hành động nhạy cảm.

Nói kiểu game: đừng để nhân vật tự nhặt mọi vật phẩm lạ trên map rồi uống ngay. Ít nhất phải có inventory rule.

Một buổi thử nhỏ trước khi scale

Nếu team bạn đang phân vân prompt hay loop, đừng họp thêm ba tuần. Lấy một workflow thật và test trong một buổi chiều.

Chọn task có đủ ba điều kiện:

Ví dụ minh họa: “từ bug report → đề xuất patch nhỏ → chạy test → tạo PR draft”.

Thiết kế thử nghiệm như sau:

Bước 1: khóa phạm vi

allowed_paths:
  - src/components/**
  - tests/components/**
blocked_actions:
  - deploy
  - delete_branch
  - modify_secrets
max_retries: 2
require_human_approval:
  - create_pr
  - push_commit

Bước 2: định nghĩa checkpoint

checks:
  - output_schema_valid
  - unit_tests_pass
  - diff_under_200_lines
  - no_secret_touched
  - rationale_in_pr_description

Bước 3: ghi trace tối thiểu

Mỗi lượt loop cần log:

Bước 4: đặt tiêu chí dừng

Dừng thử nghiệm nếu gặp một trong các dấu hiệu:

Câu cuối nghe phũ, nhưng rất production: nếu agent tạo thêm việc kiểm tra, nó chưa phải automation; nó là mini-boss phụ.

Khi nào chọn prompt, loop, hay agent có guardrail?

Nếu là mình, mình sẽ chọn theo khung này:

Guardrail — rào chắn vận hành — không chỉ là “đừng làm điều xấu” trong system prompt. Nó phải nằm ngoài model: quyền truy cập, allowlist tool, policy engine, sandbox, human approval, logging, rollback.

Một dấu hiệu nên scale: loop tạo kết quả ổn định trên nhiều input thật, log đủ để debug, và failure mode lặp lại có thể sửa bằng rule hoặc checkpoint.

Một dấu hiệu nên dừng: team liên tục phải viết prompt chữa cháy cho từng case lẻ, không có metric nào ngoài cảm giác “có vẻ tốt hơn”, hoặc model đổi là workflow vỡ.

Kết luận: đừng build agent, build vòng kiểm soát

Sau bài này, mình muốn bạn đổi một câu hỏi.

Thay vì hỏi: “Model nào làm agent tốt nhất?”, hãy hỏi: “Workflow này cần bao nhiêu vòng lặp, checkpoint nào đáng tin, và quyền nào tuyệt đối không giao cho model?”

Prompt vẫn quan trọng. Loop mới biến prompt thành hệ thống. Nhưng orchestration và guardrail mới quyết định hệ thống đó có sống được trong production hay không.

Boss fight của agent không nằm ở demo chạy mượt lần đầu; nó nằm ở lần fail thứ ba mà log vẫn đủ rõ để bạn biết nên sửa đâu.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo