Agent chạy lâu cần thước đo mới

Agent chạy lâu cần thước đo mới

Khi coding agent biết tự chạy hàng giờ, câu hỏi không còn là model nào giỏi hơn, mà là team bạn có kiểm soát được vòng làm-kiểm-sửa không.

“Em để agent chạy qua trưa, lát quay lại chắc xong.”

Câu này nghe trong một team product Việt Nam giả định tên là Mộc Studio, mình thấy vừa hào hứng vừa hơi lạnh gáy. Hào hứng vì đúng là coding agent đang bước sang pha mới: không chỉ gợi ý vài dòng code, mà nhận một mục tiêu lớn, tự lập kế hoạch, tự sửa, tự chạy kiểm tra. Lạnh gáy vì nếu bạn giao nhầm việc, agent có thể bào cả buổi chiều rất chăm chỉ… trên một miếng gỗ đặt lệch.

Điểm đáng bàn của các release gần đây không nằm ở chuyện “agent đã tự làm app 10.000 dòng” hay “chạy hàng giờ không cần người ngồi cạnh”. Câu hỏi thực tế hơn là: team builder nên đo năng lực agent bằng khả năng hoàn tất vòng làm-kiểm-sửa, không phải bằng độ ồn của demo.

Sơ đồ minh họa cho bài Agent chạy lâu cần thước đo mới

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

Cảnh ở Mộc Studio: demo đẹp, backlog vẫn đau

Mộc Studio có 6 developer, một tech lead, một repo frontend hơi cũ, một backend Node.js, và một danh sách bug cứ đến thứ Sáu là tự nhân bản. Team bắt đầu dùng coding agent trong terminal để xử lý việc nhỏ: đổi schema, thêm test, refactor component.

Ban đầu mọi thứ ổn. Agent giống một bạn phụ việc nhanh tay: bạn chỉ đâu làm đó. Nhưng rồi team muốn giao việc dài hơn:

Đây là lúc các tính năng kiểu /goal trong Grok Build trở nên đáng chú ý. Thay vì bạn prompt từng bước, agent nhận một objective, lập checklist, chạy lệnh, quan sát kết quả, sửa tiếp cho đến khi hoàn tất và được verify. Verification ở đây là bước kiểm chứng kết quả: đọc lại code, chạy script, kiểm tra webpage, hoặc test hành vi cụ thể.

Va chạm của Mộc Studio không phải “agent có thông minh không”. Va chạm là: ai định nghĩa xong là xong?

Nếu agent tự tick checklist nhưng không chạy đúng test quan trọng, team vẫn ôm nợ. Nếu agent deploy được preview nhưng dùng account tạm bợ, ngày mai link chết. Nếu agent sửa 20 file mà không để lại trace, code review thành trò đoán ý.

Mổ xẻ lớp thật sự mới: agent không còn là autocomplete

Các release gần đây đang cùng trỏ về một hướng: agent được thiết kế để chạy nền lâu hơn.

/goal trong Grok Build đóng gói một vòng observe-plan-act — quan sát, lập kế hoạch, hành động — vào một mode dành cho multi-step coding task. Qwen3.7-Plus đẩy câu chuyện sang multimodal agent, tức agent vừa đọc chữ vừa hiểu giao diện hình ảnh để thao tác app hoặc browser. Cloudflare thì xử lý một điểm nghẽn rất đời: agent muốn deploy nhưng mắc OAuth, dashboard, token, MFA; họ đưa ra temporary account để agent có nơi deploy thử trong thời gian ngắn. Perplexity Brain lại đi theo hướng context graph, một bản đồ ngữ cảnh ghi lại việc agent đã làm, cái gì hiệu quả, cái gì từng sai.

Nhìn riêng từng thứ thì dễ bị cuốn theo release. Ghép lại mới thấy miếng mộng gỗ: agent tương lai cần ba cạnh khớp nhau:

  1. Execution — có thể chạy việc dài, nhiều bước.
  2. Verification — có thể tự kiểm chứng bằng test, script, browser, hoặc review.
  3. Recoverability — có thể tạm dừng, tiếp tục, xem trạng thái, và hiểu tại sao nó làm vậy.

Thiếu một cạnh, khung sẽ lung lay. Agent chạy lâu mà không verify chỉ là một worker rất tự tin. Verify có mà không observable thì bạn không debug được. Observable có mà không sandbox thì một lệnh sai có thể chạm vào dữ liệu thật.

Ở đây có thêm một thuật ngữ đáng nhớ: sandbox — môi trường cô lập để chạy code mà không cho nó đọc file, gọi mạng, hoặc phá phần còn lại nếu chưa được phép. Cách Simon Willison thử MicroPython với WASM đáng để builder để mắt vì nó nhắc lại điều cũ nhưng hay bị quên: agent càng tự động, biên an toàn càng phải rõ.

Framework 4V: trước khi giao agent chạy lâu

Nói thẳng ra thì, đừng hỏi “model nào đang hot?”. Hỏi bốn chữ V này trước.

1. Việc: có đóng khung được không?

Một task phù hợp cho long-running agent phải có biên rõ. “Cải thiện UX dashboard” quá rộng. “Thêm filter theo status vào dashboard orders, giữ API hiện tại, thêm test cho empty state” tốt hơn.

Ví dụ cụ thể: nếu Mộc Studio muốn agent sửa billing page, brief nên ghi:

Goal: Refactor BillingPage để tách phần invoice list thành component riêng.
Constraints:
- Không đổi API contract.
- Không đổi copy hiển thị.
- Phải giữ behavior pagination hiện tại.
Verification:
- npm test BillingPage
- npm run lint
- mở /billing trong preview và kiểm tra invoice list render.

Đây không phải prompt màu mè. Đây là bản vẽ trước khi đục chạm.

2. Vòng kiểm: agent tự chứng minh bằng gì?

Verification không nên là “trông có vẻ đúng”. Với builder, hãy ép agent trả lời bằng artifact:

Nếu dùng môi trường deploy tạm như Cloudflare temporary account, hãy coi đó là sân thử, không phải production. Nó rất hợp cho vòng write → deploy → curl → sửa tiếp, nhưng cần quy ước rõ: cái gì hết hạn, cái gì được claim, cái gì không chứa secret thật.

3. Vết tích: có pause/resume/status không?

Agent chạy 20 phút mà bạn không xem được nó đang làm gì là rủi ro vận hành. Các lệnh kiểu status, pause, resume, clear nghe nhỏ, nhưng với team thật lại là chỗ phân biệt đồ chơi và công cụ.

Mộc Studio đặt rule đơn giản: mọi long run phải có checkpoint sau mỗi nhóm việc. Ví dụ:

Checkpoint 1: đọc code và lập kế hoạch
Checkpoint 2: sửa implementation
Checkpoint 3: thêm/cập nhật test
Checkpoint 4: chạy verification
Checkpoint 5: tóm tắt rủi ro còn lại

Không cần nghi thức phức tạp. Chỉ cần đủ để tech lead biết lúc nào nên can thiệp.

4. Vùng cấm: agent không được chạm vào đâu?

Đây là phần nhiều team bỏ qua vì demo thường chạy trong repo sạch. Production repo thì khác: .env, token, migration, billing logic, customer data.

Trước khi bật agent tự chạy lâu, hãy có danh sách:

Nếu agent cần chạy code tùy ý, hãy nghĩ đến sandbox. Không phải vì mình bi quan, mà vì quyền chạy lệnh trong terminal là quyền rất lớn.

Điều đáng giữ từ làn sóng release này

Thứ đáng giữ không phải tên sản phẩm. Thứ đáng giữ là mẫu kiến trúc.

Grok Build /goal cho thấy coding workflow đang chuyển từ prompt ngắn sang goal-driven run: giao mục tiêu, theo dõi checklist, verify kết quả. Cloudflare nhắc rằng agent muốn hữu dụng phải có hạ tầng ít ma sát, đặc biệt ở bước deploy thử. Qwen3.7-Plus kéo UI vào cùng vòng agent, nghĩa là verification không chỉ nằm ở unit test mà còn ở thao tác giao diện. Perplexity Brain đặt câu hỏi sâu hơn: agent có nhớ được bài học từ các lần làm trước không, và memory đó phục vụ performance hay chỉ phục vụ personalization?

Với team builder, đây là tín hiệu để thiết kế hệ thống theo “vòng chạy có kiểm chứng”, không phải “model trả lời hay”.

Hình dung thế này: bạn không thuê thợ chỉ vì họ cầm cái đục sáng bóng. Bạn xem họ có đo, có thử ráp, có sửa đường mộng khi lệch, và có để lại bản vẽ cho người sau hiểu không. Agent cũng vậy.

Điều nên bỏ qua, ít nhất là lúc này

Có ba thứ mình sẽ không vội mua bằng cả niềm tin.

Một là demo chạy rất lâu. Chạy lâu không đồng nghĩa với làm đúng. Một agent có thể tạo nhiều file, nhiều commit, nhiều log, nhưng vẫn miss constraint quan trọng.

Hai là benchmark tổng quát. Với coding agent, benchmark chỉ nói một phần. Repo của bạn có legacy, convention nội bộ, test flaky, quyền deploy, và nợ kỹ thuật riêng. Hãy benchmark trên task thật của team, dù nhỏ.

Ba là memory nghe quá thông minh. Long-term memory — bộ nhớ dài hạn qua nhiều phiên — chỉ hữu ích nếu nó traceable, chỉnh được, và không nhét nhầm assumption cũ vào task mới. Một ký ức sai được agent dùng lại nhiều lần còn khó chịu hơn một câu trả lời sai đơn lẻ.

Nếu là mình ở Mộc Studio

Mình sẽ không bật long-running agent cho mọi việc ngay. Mình sẽ chọn một nhóm task vừa đủ rõ, ví dụ UI bug có test hoặc refactor không đổi API, rồi chạy thử trong một buổi chiều theo khung 4V:

  1. Viết goal và constraint trong file markdown.
  2. Cho agent lập plan, nhưng chưa sửa code.
  3. Duyệt plan, thêm verification bắt buộc.
  4. Cho agent chạy trong nhánh riêng hoặc workspace riêng.
  5. Yêu cầu output cuối gồm diff summary, test log, rủi ro còn lại.
  6. Review như review PR của junior developer, không như nhận phép màu.

Sau 3-5 task, team mới quyết định mở rộng: task nào phù hợp, task nào vẫn cần người lái sát, tool nào cần sandbox, deploy preview nên đi qua đường nào.

Câu trả lời rõ ràng sau bài này là: đừng đánh giá agent theo mức tự chủ nó khoe được; hãy đánh giá theo vòng kiểm chứng mà team bạn có thể vận hành.

Agent chạy lâu là chuyện hay. Nhưng chạy lâu mà không có thước, không có vết cắt thử, không có khung giữ thẳng thì cuối cùng chỉ ra một đống mùn cưa rất tự tin.

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

Nguồn tham khảo