Agent cần tháp không lưu, không chỉ model

Agent vào production không hỏng vì trả lời xấu, mà vì đi sai quy trình nhưng vẫn đáp đúng. Đây là khung quyết định để biết nên build, mua hay dừng.

Bạn đang họp sprint planning. Một bạn dev mở demo agent: nhận ticket, đọc repo, gọi tool, sửa code, tạo PR. Cả phòng im 3 giây rồi có người nói câu quen thuộc: “Cái này đưa vào pipeline luôn được chưa?”

Mình hiểu cảm giác đó. Demo agent chạy trơn nhìn rất đã. Nhưng đưa vào production mà chỉ nhìn output cuối cùng thì hơi giống cho máy bay cất cánh vì thấy nó sơn đẹp: chưa ai kiểm tra đường băng, tháp không lưu, nhật ký bay, hay lúc gặp nhiễu động thì phi công làm gì.

Luận điểm của mình hôm nay khá gọn: agent chỉ đáng tin khi bạn đánh giá được đường đi của nó, không chỉ đáp án của nó. Và quyết định quan trọng không phải “dùng framework agent nào?”, mà là “team mình đã có đủ orchestration và guardrail để chịu trách nhiệm cho hành vi của agent chưa?”

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

Chuyện đang diễn ra: agent đang rời khỏi màn chat

Coding agent không còn là cái hộp chat ngồi cạnh developer nữa. Nó đang được kéo vào CI/CD, review code, tạo branch, chạy workflow dài, tương tác với Hub, cloud session, sandbox, dữ liệu nội bộ.

Vài tín hiệu đáng chú ý:

• Agent-EvalKit nhấn mạnh việc đánh giá agent theo toàn bộ execution path, tức đường chạy gồm tool nào được gọi, dữ liệu nào trả về, bước nào bị bỏ qua.
• Hugging Face chỉnh hf CLI để thân thiện hơn với coding agent: lệnh dễ đoán, an toàn khi retry, gợi ý bước tiếp theo, nhiều cách render output.
• Cursor SDK đưa agent từ app tương tác sang dạng hạ tầng lập trình được, chạy trong VM riêng, có sandboxing và session kéo dài.
• Các nền tảng chạy agent ở quy mô lớn bắt đầu nói nhiều hơn về workflow, observability, security, sandbox, không chỉ model.
• Lớp context doanh nghiệp nổi lên vì agent không tự nhiên hiểu “doanh thu”, “quyền truy cập”, “file nào được xem” theo định nghĩa riêng của công ty bạn.

Dịch sang quyết định kỹ thuật: agent càng tự động, phần quan trọng càng nằm ngoài model.

Model là động cơ. Nhưng production cần cả kiểm soát bay.

Mổ xẻ lớp dễ bị bỏ sót: đáp đúng chưa chắc làm đúng

Cách test phần mềm truyền thống thường hỏi: input này ra output kia chưa? Với agent, câu hỏi đó chưa đủ.

Vì agent không chỉ sinh câu trả lời. Nó còn:

• chọn tool;
• quyết định thứ tự gọi tool;
• đọc dữ liệu trung gian;
• tự diễn giải kết quả;
• có thể bỏ qua bước xác minh;
• có thể bịa nếu tool trả rỗng nhưng prompt vẫn ép trả lời.

Tool calling là khả năng model gọi API hoặc công cụ thay vì chỉ trả lời bằng chữ. Nghe đơn giản, nhưng đây là nơi nhiều lỗi production núp dưới thảm.

Ví dụ cụ thể: agent nghiên cứu chuyến công tác cho sales team. Nó gọi tool tìm chuyến bay, tool kiểm tra policy công ty, rồi viết đề xuất. Output cuối cùng có thể rất đẹp: “Nên bay chuyến A, khách sạn B, tổng chi phí hợp lệ.” Nhưng nếu tool policy bị lỗi, agent vẫn suy đoán policy từ lần trước, bạn sẽ không thấy lỗi nếu chỉ assert câu trả lời cuối.

Đây là kiểu failure nguy hiểm: đúng về hình thức, sai về quy trình.

Agent-EvalKit đánh vào điểm này bằng cách kéo evaluation vào development environment: tạo test case có ground truth — đáp án chuẩn để so — rồi ghi lại tool call, intermediate state và báo cáo vị trí code cần sửa. Mình không xem đây là “thêm một tool eval”, mà là dấu hiệu ngành đang đổi câu hỏi: từ “agent trả lời đúng không?” sang “agent có đi qua quy trình đáng tin không?”

Ba lựa chọn trước mặt team builder

Nếu bạn đang lead một team Việt Nam 4-10 người, không có cả đội platform riêng cho AI infra, mình sẽ không bắt đầu bằng câu “hãy tự build mọi thứ”. Quyết định thực tế hơn là chọn một trong ba hướng sau.

| Hướng | Khi nào hợp | Điểm mạnh | Cái giá phải trả |
|---|---|---|---|
| Tự build orchestration | Workflow lõi, dữ liệu nhạy cảm, cần kiểm soát sâu | Chủ động logic, audit, quyền truy cập | Tốn công observability, retry, state, sandbox |
| Dùng SDK/runtime có sẵn | Muốn ship nhanh automation quanh code, PR, CI/CD | Có sẵn session, sandbox, môi trường chạy | Bị ràng buộc vào runtime và cách platform quan sát |
| Dùng toolkit eval bổ trợ | Đã có agent, cần biết có đáng tin không | Tập trung vào test path, tool usage, faithfulness | Vẫn phải sửa kiến trúc nếu agent loop lộn xộn |

Ở đây có vài thuật ngữ cần neo nhanh:

• Orchestration: cách điều phối nhiều bước, nhiều tool, nhiều agent để hoàn thành việc.
• Guardrail: rào chắn vận hành, như rule cấm hành động, check quyền, xác minh dữ liệu trước khi trả lời.
• Observability: khả năng nhìn thấy hệ thống đang làm gì qua log, trace, metric.
• Sandboxing: chạy agent trong môi trường cô lập để nếu nó làm bậy thì thiệt hại bị giới hạn.
• Durable state: trạng thái bền, giúp phiên agent không mất sạch khi mạng rớt hoặc process chết.

Nói thẳng ra thì: nếu bạn không log được agent đã gọi tool gì, nhận dữ liệu gì, và vì sao quyết định bước tiếp theo, bạn chưa có agent production. Bạn mới có demo biết nói chuyện.

Framework quyết định: kiểm soát bay trước khi tăng tốc

Thay vì hỏi “có nên dùng Agent-EvalKit, Cursor SDK, hf CLI, hay nền tảng X không?”, mình đề xuất dùng khung 4 câu hỏi này.

1. Agent có quyền gây thiệt hại không?

Nếu agent chỉ draft nội dung, gợi ý commit message, hoặc tạo checklist, rủi ro thấp hơn. Nếu agent có thể push code, tạo PR, cập nhật dữ liệu khách hàng, gửi email, chạy job tốn tiền, thì nó đã chạm vào vùng cần guardrail.

Hình dung thế này: một agent được quyền mở PR khác hẳn agent được quyền merge. Một cái mới lăn trên đường băng; cái kia đã cất cánh.

Quyết định: càng gần hành động không đảo ngược, càng cần sandbox, approval gate và trace chi tiết.

2. Thành công nằm ở output hay ở quy trình?

Có bài toán chỉ cần kết quả cuối: phân loại ticket, tóm tắt log, gợi ý tài liệu. Nhưng có bài toán quy trình quan trọng hơn output: compliance check, phân tích tài chính, migration code, research có citation.

Nếu agent trả lời đúng nhưng bỏ qua bước kiểm chứng, bạn có chấp nhận không? Nếu câu trả lời là không, test output không đủ.

Quyết định: với workflow cần chứng minh đường đi, hãy thêm evaluation theo execution path: tool call, dữ liệu trả về, bước xác minh, mapping từ bằng chứng sang kết luận.

3. Tool của bạn có được thiết kế cho agent không?

Nguồn về hf CLI đáng chú ý ở chỗ họ không chỉ nói “agent dùng CLI được”. Họ thiết kế lại CLI để agent dùng ít vòng đoán mò hơn: command dễ khám phá, output có nhiều rendering, thao tác an toàn khi retry, có next-command hints.

Đây là chi tiết nhiều team bỏ qua. Bạn có thể có model tốt, nhưng nếu tool nội bộ trả output rối, lỗi không nhất quán, retry gây side effect, agent sẽ tiêu token vào việc mò đường.

Quyết định: trước khi đổi model, hãy kiểm tra tool surface. API/CLI cho agent nên có schema rõ, lỗi đọc được, idempotency khi cần, và mode dry-run cho hành động nguy hiểm.

4. Context có phải dữ liệu, hay là luật chơi?

Nhiều team nghĩ “cho agent đọc thêm tài liệu là xong”. Nhưng trong doanh nghiệp, context không chỉ là docs. Nó là quan hệ giữa dữ liệu, quyền truy cập, thuật ngữ, workflow, ownership.

Context graph là cách biểu diễn quan hệ giữa thực thể và tri thức nghiệp vụ, ví dụ khách hàng A thuộc segment nào, ai được xem hợp đồng, chỉ số revenue được tính theo định nghĩa nào. Nếu thiếu lớp này, agent có thể tìm đúng file nhưng hiểu sai luật chơi.

Quyết định: nếu bài toán phụ thuộc quyền, định nghĩa nội bộ, hoặc quan hệ dữ liệu phức tạp, đừng chỉ tăng context window. Hãy thiết kế lớp context có kiểm soát.

Điều đáng giữ: eval nằm trong vòng dev, không nằm cuối đường

Điểm mình thích ở hướng Agent-EvalKit là nó kéo evaluation về gần code. Team mô tả mục tiêu eval bằng ngôn ngữ tự nhiên, toolkit đọc source, tạo test case, chạy đánh giá, rồi trỏ khuyến nghị về vị trí cụ thể trong codebase.

Bạn không nhất thiết phải dùng đúng tool đó. Nhưng tư duy đáng giữ là: evaluation phải là một phần của vòng build agent, không phải nghi thức sau khi launch.

Một buổi làm việc thực tế có thể như sau:

1. Chọn một workflow agent đang có rủi ro thật, ví dụ “đọc issue và tạo PR sửa bug nhỏ”.
2. Viết 10-20 test case đại diện, gồm cả case tool trả rỗng, repo thiếu file, permission bị chặn.
3. Ghi trace bắt buộc: prompt, tool call, tool result, bước reasoning đã lưu được, output cuối.
4. Chấm 3 nhóm metric: accuracy bề mặt, faithfulness với dữ liệu tool, và tool usage có đúng quy trình không.
5. Đặt rule fail rõ: nếu agent không kiểm chứng trước khi sửa file, test fail dù PR compile được.

Faithfulness ở đây là mức độ câu trả lời bám vào dữ liệu thật từ tool, không tự chế thêm. Với agent, đây là chỉ số sống còn.

Điều nên bỏ qua: chạy theo runtime mới khi chưa biết lỗi cũ

SDK mới, cloud agent mới, CLI tối ưu cho agent — tất cả đều hữu ích. Nhưng nếu team bạn chưa trả lời được “agent fail ở đâu?”, đổi runtime chỉ làm lỗi di chuyển sang chỗ đắt hơn.

Đừng mua thêm đường băng khi tháp không lưu chưa có radar.

Mình sẽ bỏ qua ba thứ trong giai đoạn đầu:

• Benchmark chung chung không phản ánh workflow của bạn.
• Demo end-to-end quá đẹp nhưng không có trace từng bước.
• Tự động hóa full quyền trước khi có approval gate và rollback path.

Ngược lại, mình sẽ ưu tiên những thứ hơi chán nhưng cứu production:

• log tool call có cấu trúc;
• test case có ground truth;
• sandbox cho hành động nguy hiểm;
• policy rõ về quyền đọc/ghi;
• report lỗi gắn về code, không chỉ screenshot output.

Nếu là mình, mình sẽ chọn thế này

Nếu team đang mới thử agent automation: dùng runtime/SDK có sẵn cho phần chạy, nhưng tự định nghĩa eval suite của mình. Đừng tự build sandbox và session management ngay nếu đó không phải lợi thế cạnh tranh.

Nếu team đã có agent trong workflow nội bộ: thêm evaluation theo execution path trước khi mở rộng quyền. Tool như Agent-EvalKit đáng xem vì nó giúp biến “agent có vẻ ổn” thành câu hỏi kiểm chứng được.

Nếu team đang làm sản phẩm agent cho khách hàng: đầu tư sớm vào orchestration, observability, permission model và context layer. Ở mức này, agent không còn là feature; nó là hệ thống vận hành.

Sau bài này, điều mình muốn bạn nghĩ khác là: độ tin cậy của agent không nằm ở câu trả lời hay nhất trong demo, mà ở khả năng giải thích và kiểm soát những bước nó đã đi qua.

Chọn model giống chọn máy bay. Nhưng production là nghệ thuật giữ lịch bay không loạn khi trời đổi gió.

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