Cơn áp thấp trong vòng lặp agent

Cơn áp thấp trong vòng lặp agent

Agent không chết vì thiếu thông minh, mà vì mỗi bước nhỏ bị lỗi, retry và đội chi phí. Đây là framework để builder đo đúng bottleneck.

Bạn có dám giao cho browser agent đặt vé, điền form, kiểm tra dashboard, rồi quay lại báo kết quả mà không ngồi canh như canh nồi nước sôi không?

Mình hỏi vậy vì nhiều team đang mắc một cái bẫy khá lặng: thấy model mới reasoning tốt hơn, benchmark cao hơn, giá token thấp hơn, rồi nghĩ agent production sẽ tự nhiên ổn hơn. Nhưng khi đưa vào vòng lặp thật — nhìn trang web, quyết định action, xuất JSON, gọi tool, quan sát tiếp — hệ thống lại bắt đầu lăn tăn như trời sắp áp thấp.

Fireworks AI có một thử nghiệm đáng để builder nhìn kỹ: 720 lượt chạy browser agent trên bốn LLM. Điều thú vị không nằm ở câu “model nào thông minh hơn”, mà ở chỗ nhiều lỗi đến từ execution — phần thực thi lặp đi lặp lại. Một model trong benchmark lãng phí gần 1 trong 5 LLM call vì JSON sai format phải retry. Với model tệ nhất, phần chi phí thực thi bị lãng phí — họ gọi là Agent Execution Tax — lên tới 22,9%. Model tốt nhất trong thử nghiệm là 0%.

Nói gọn: agent không chỉ cần não tốt. Nó cần dây thần kinh ổn.

Sơ đồ minh họa cho bài Cơn áp thấp trong vòng lặp agent

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

Cảnh của team Nam: demo chạy, production dở chứng

Nam là tech lead của một team SaaS ở Việt Nam. Team có một workflow rất “đúng thời đại”: browser agent đăng nhập vào portal đối tác, kiểm tra trạng thái đơn, tải invoice, rồi cập nhật lại CRM nội bộ.

Demo nội bộ chạy đẹp. Sếp xem xong gật gù. Product bắt đầu hỏi: “Vậy tuần sau cho chạy với 2.000 đơn/ngày được không?”

Đến đây mới có va chạm.

Ở môi trường test, agent chỉ chạy vài chục task. Nếu một bước lỗi, engineer bấm lại. Nhưng khi chạy batch lớn, lỗi nhỏ bắt đầu cộng dồn:

Guardrail ở đây là rào chắn kỹ thuật để giới hạn hành vi sai, ví dụ schema bắt buộc, kiểm tra quyền gọi tool, hoặc rule dừng khi quan sát bất thường. Orchestration là lớp điều phối nhiều bước, nhiều tool và nhiều quyết định của agent. Với browser agent, orchestration giống bản đồ thời tiết cho cả chuyến bay: không chỉ biết điểm đến, mà phải biết khi nào đổi hướng.

Điểm Nam nhận ra sau vài ngày log cháy đỏ: chọn model rẻ hơn mỗi token không giúp gì nếu mỗi task thành công lại cần quá nhiều retry.

Thứ đang diễn ra: giá token không còn là thước đo chính

Trong app chatbot đơn giản, bạn có thể nhìn token pricing và latency trung bình để ước lượng chi phí. Nhưng agent là một câu chuyện khác.

Agent thường chạy theo vòng:

  1. Quan sát trạng thái hiện tại.
  2. Suy nghĩ bước tiếp theo.
  3. Xuất action có cấu trúc.
  4. Gọi tool hoặc browser.
  5. Nhận kết quả.
  6. Lặp lại cho đến khi xong hoặc fail.

Structured output là đầu ra có cấu trúc cố định, thường là JSON theo schema. Ví dụ thay vì model nói “hãy bấm nút đăng nhập”, nó phải trả:

{
  "action": "click",
  "selector": "#login-button"
}

Nếu JSON sai, hệ thống phải sửa, retry, hoặc bỏ task. Vấn đề là mỗi lần retry không chỉ tốn token. Nó còn tốn thời gian, làm tăng xác suất trang thay đổi, session hết hạn, tool timeout, và log khó đọc hơn.

Đây là chỗ Fireworks gọi là Agent Execution Tax: tỷ lệ inference bị lãng phí so với inference có ích. Inference là lượt model chạy để tạo câu trả lời hoặc action. Nếu 100 call có 20 call chỉ để sửa format, bạn đang trả tiền cho việc dọn sương mù, không phải cho việc hoàn thành task.

Với builder, câu hỏi nên đổi từ:

“Model này giá bao nhiêu mỗi triệu token?”

sang:

“Một task thành công thật sự tốn bao nhiêu tiền, bao nhiêu giây, và bao nhiêu lần retry?”

Đây là cú đổi góc nhìn quan trọng nhất.

Mổ xẻ: bốn lớp thuế trong agent loop

Khi Nam bóc log, team không còn hỏi “model nào xịn hơn”. Họ chia chi phí thất thoát thành bốn lớp.

1. Thuế format

Đây là lỗi structured output: JSON sai, thiếu field, field sai kiểu dữ liệu, hoặc action không khớp schema.

Ví dụ cụ thể: schema yêu cầu action chỉ được là click, type, wait, extract. Model trả press_button. Người đọc thấy hiểu, máy thì không.

Cách đo:

Nếu phần này cao, đừng vội đổi prompt dài hơn. Hãy siết schema, dùng constrained decoding nếu serving layer hỗ trợ, và log riêng lỗi parse thay vì gộp vào “agent failed”.

2. Thuế latency cộng dồn

Inference latency là thời gian model mất để trả output. Với agent, latency không cộng kiểu một lần. Nó xếp lớp qua từng bước.

Giả sử minh họa: một task cần 8 bước. Mỗi bước chậm thêm 700ms thì task chậm thêm 5,6 giây, chưa tính browser wait và retry. Nếu task chạy hàng nghìn lần mỗi ngày, “hơi chậm” trở thành thời tiết xấu kéo dài.

Cách đo:

Điểm cần nhớ: model nhanh ở benchmark một lượt chưa chắc thắng trong agent nếu output hay hỏng.

3. Thuế tool mismatch

Tool calling là khả năng để model gọi công cụ hoặc API thay vì chỉ trả lời chữ. Trong browser automation, tool có thể là click, type, navigate, screenshot, extract.

Lỗi hay gặp: model gọi đúng tool nhưng sai tham số. Ví dụ type vào ô tìm kiếm, nhưng selector lại trỏ vào label. Đây không hẳn là lỗi reasoning, cũng không hẳn là lỗi browser. Nó nằm ở biên giữa quan sát, schema và action.

Cách giảm:

4. Thuế quan sát

Browser agent sống nhờ trạng thái trang. Nếu observation quá nghèo, model đoán. Nếu observation quá dài, model bị nhiễu.

Ở đây context window — vùng ngữ cảnh model còn xử lý được trong một lượt — không phải kho chứa vô hạn. Nhét cả DOM, screenshot text, lịch sử action và lỗi cũ vào một prompt có thể làm agent lạc giữa mây mù.

Cách xử lý:

Điều đáng giữ: framework đo task thành công

Nếu là team Nam, mình sẽ không bắt đầu bằng cuộc thi model. Mình sẽ dựng một bảng đo theo task.

Gọi nó là STAR cho agent production:

| Thành phần | Câu hỏi cần trả lời | Metric nên log |
|---|---|---|
| S — Schema | Output có đúng cấu trúc ngay lần đầu không? | parse success rate, retry vì format |
| T — Time | Mỗi task thành công mất bao lâu? | task latency, step latency, P95 |
| A — Action | Tool được gọi có đúng ý và đúng tham số không? | tool error rate, invalid action rate |
| R — Recovery | Khi lỗi, agent phục hồi hay làm loạn thêm? | retry count, stop reason, success after retry |

Hình dung thế này: nếu bạn chỉ nhìn tổng bill cuối tháng, bạn biết “mưa to”. Nhưng nếu log theo STAR, bạn biết mưa từ đám mây nào: schema, latency, tool hay recovery.

Một buổi chiều là đủ để làm bản đầu:

  1. Chọn 20 task đại diện, có cả case dễ và case khó.
  2. Ghi log từng LLM call với task_id, step_id, schema_valid, tool_name, tool_error, latency_ms, retry_reason.
  3. Tính cost per successful task — chi phí cho mỗi task hoàn thành, không phải chi phí mỗi token.
  4. So sánh hai model hoặc hai prompt trên cùng bộ task.
  5. Đọc 10 task fail bằng mắt để phân loại lỗi, đừng chỉ nhìn dashboard.

Điều này không hào nhoáng, nhưng nó trả lời câu hỏi production cần nhất: “Khi tăng tải, hệ thống hỏng ở đâu trước?”

Điều nên bỏ qua: tiếng ồn quanh model mới nhất

Có ba thứ mình sẽ không lấy làm tiêu chí quyết định chính.

Thứ nhất, benchmark reasoning chung. Nó hữu ích, nhưng không thay thế được browser task thật của bạn. Agent loop phạt rất nặng những lỗi nhỏ lặp lại.

Thứ hai, giá token đơn lẻ. Một model rẻ nhưng retry nhiều có thể đắt hơn model đắt mà đi thẳng đến đích.

Thứ ba, demo một lần. Demo giống khoảng lặng gió giữa ngày; production mới là nơi bạn biết mái nhà có dột không.

Câu trả lời rõ ràng sau bài này: đừng nghĩ agent đáng tin hơn chỉ vì model thông minh hơn; hãy nghĩ nó đáng tin hơn khi execution tax giảm xuống và guardrail đo được.

Với team builder, quyết định thực tế là: trước khi nâng cấp model hoặc rewrite agent framework, hãy đo STAR trên workflow thật. Nếu thuế format cao, xử schema. Nếu latency cộng dồn cao, tối ưu serving và số bước. Nếu tool mismatch cao, sửa contract giữa model và tool. Nếu recovery tệ, thêm stop rule và retry policy có giới hạn.

Agent production không cần bạn xem dự báo bằng niềm tin. Nó cần trạm đo đủ tốt để biết cơn áp thấp đang hình thành ở đâu.

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

Nguồn tham khảo