Coding agent triển khai model sai không hẳn vì suy luận kém
Một thử nghiệm AWS cho thấy coding agent có thể lập kế hoạch ổn nhưng vẫn chọn serving container đã lỗi thời. Bài học nằm ở lớp kiến thức triển khai phải được cập nhật và kiểm chứng trước khi tạo tài nguyên cloud.
Ngày 18/09/2026, một nhóm AWS mô tả hai lần thử giao việc triển khai model Hugging Face cho coding agent. Chi tiết đáng chú ý không phải là agent “ngu” hay “thông minh”, mà là loại thông tin nó thiếu.
Trong yêu cầu đầu tiên, nhóm thử Kiro và Claude Code với Qwen3-0.6B. Theo AWS, cả hai ban đầu chọn Text Generation Inference (TGI). Build TGI sẵn có trong Region mà nhóm dùng lại có trước kiến trúc Qwen3, nên endpoint không vượt qua health check. Agent thử phiên bản khác, thất bại thêm rồi mới chuyển sang vLLM. Mỗi lần dựng endpoint GPU rồi lỗi đều có thể tạo chi phí.
Yêu cầu thứ hai còn rõ hơn: một model multimodal mixture-of-experts dạng diffusion mới được phát hành vài tuần trước thử nghiệm cũng bị agent chuẩn bị script dựa trên TGI, dù TGI là server cho text generation và không có backend phù hợp cho loại model đó.
AWS kết luận nguyên nhân chung trong hai run này là thiếu deployment facts hiện hành, không phải agent không biết lập kế hoạch hay debug. Đây là một phân biệt hữu ích khi dùng coding agent cho hạ tầng: reasoning tốt không tự làm cho kiến thức triển khai trở nên mới.
Một kế hoạch hợp lý vẫn có thể bắt đầu từ fact đã cũ
Serving stack thay đổi nhanh hơn nhiều tài liệu hướng dẫn và dữ liệu huấn luyện. Một lựa chọn từng là mặc định có thể không còn hỗ trợ kiến trúc model mới. Image tag phụ thuộc Region; phiên bản Python có thể không có wheel tương thích; instance phải đủ bộ nhớ; endpoint cần monitoring và một đường teardown có thể kiểm chứng.
Điều này làm thay đổi cách đọc output của coding agent. Một file kế hoạch đẹp, có IAM role đúng và script chạy được về cú pháp chưa phải là bằng chứng deployment sẽ lên. Trước khi tạo tài nguyên, những fact phụ thuộc thời điểm cần được resolve từ nguồn đang được duy trì.
Tài liệu SageMaker hiện tại cũng cho thấy Hugging Face inference dựa vào các Deep Learning Containers được duy trì và cập nhật, đồng thời hỗ trợ nhiều cách triển khai model. Vì vậy, container hay image URI không nên được xem như một hằng số mà agent có thể nhớ mãi.
Skill ở đây đóng vai trò như một lớp kiến thức có thể thay
Trong thử nghiệm AWS, nhóm cài sáu open-source agent skills. Với lớp này, agent chọn vLLM trước khi tạo tài nguyên, resolve image từ AWS Deep Learning Containers catalog, thêm target-tracking autoscaling, ba CloudWatch alarms và thực sự chạy rồi kiểm tra teardown.
Điểm quan trọng là vị trí của kiến thức. Thay vì hy vọng model nền đã học đúng phiên bản deployment mới nhất, các fact thay đổi nhanh được đưa vào những file skill có thể sửa và kiểm tra độc lập. Cách tổ chức này làm cho một phần tri thức vận hành có vòng đời ngắn hơn model và gần nguồn hiện hành hơn.
Nhưng đây vẫn là thử nghiệm do AWS thực hiện trên chính stack AWS. Nó không chứng minh rằng sáu skill này luôn tạo deployment production-ready, không phải benchmark độc lập giữa Kiro và Claude Code, và cũng không chứng minh mọi lỗi coding agent đều là lỗi freshness. Kết quả nên được đọc như một failure case có ghi nhận và một cách khắc phục cụ thể, không phải lời bảo đảm.
Trước khi agent tạo endpoint, resolve bốn nhóm fact
Với một deployment tương tự, phần đáng tách khỏi suy luận chung của agent là bốn nhóm thông tin:
- Model và serving backend: kiến trúc model hiện được backend nào hỗ trợ, thay vì dùng mặc định cũ.
- Runtime và image: image/tag nào thực sự tồn tại cho Region, accelerator và runtime đang dùng.
- Vận hành: autoscaling, metric và alarm nào cần có để endpoint không chỉ “lên được” mà còn quan sát được.
- Vòng đời tài nguyên: cách xóa endpoint, autoscaling target và tài nguyên liên quan, rồi kiểm tra rằng chúng thực sự đã biến mất.
Đây không phải checklist bảo đảm an toàn cho mọi hệ thống. Nó là ranh giới thực dụng rút ra từ failure mode trong thử nghiệm: đừng để agent tạo tài nguyên tính phí khi những fact quyết định compatibility vẫn chỉ là phỏng đoán từ trí nhớ model.
Một cách vận hành hợp lý là yêu cầu agent viết plan trước, đánh dấu những dòng phụ thuộc kiến thức hiện hành, resolve chúng từ catalog/tài liệu chính thức, rồi mới cho phép bước tạo tài nguyên. Nếu deployment thất bại, log nên giúp phân biệt fact nào sai với bước reasoning nào sai. Phân biệt được hai loại lỗi này quan trọng hơn việc chỉ đổi sang một model lớn hơn.
Điều cần theo dõi tiếp
Agent skills đang trở thành một cách đưa kiến thức chuyên môn cập nhật vào coding assistants, nhưng giá trị lâu dài phụ thuộc vào việc chính các skill có được duy trì, test và gắn với nguồn hiện hành hay không. Một skill cũ cũng có thể trở thành một lớp trí nhớ cũ khác.
Với nhóm đang tự động hóa deployment, câu hỏi hữu ích sau bài thử nghiệm này không phải “agent nào thông minh nhất?” mà là: những fact nào thay đổi nhanh đến mức không nên giao cho trí nhớ của model?
Nguồn
- AWS Machine Learning Blog, 18/09/2026: mô tả hai failure cases của unguided coding agents và so sánh với deployment có agent skills.
- Amazon SageMaker AI documentation: tài liệu hiện hành về Hugging Face Deep Learning Containers và các đường training/inference trên SageMaker AI.