Rốt cuộc thì tôi cũng cố gắng hiểu cơ bản được của ngon vật lạ trong hơn nửa triệu dòng code Claude Code. Và rồi đủng đỉnh nhìn lại phong trào build agent mọc ra ở khắp hang cùng ngõ hẻm. Vài sai lầm cần nói thẳng.
Sai lầm 1, dùng agent cho mọi thứ.
Agent nên là lựa chọn cuối cùng trong hầu hết trường hợp, nó không phải mặc định. Agent về bản chất là vòng lặp gọi LLM nhiều lần. Nghĩa là chi phí nhân N, độ trễ nhân N, xác suất fail lũy thừa N, độ khó debug nhân bình phương.
Bài toán tóm tắt tài liệu thông thường không cần agent, là pipeline. (Tóm tắt sách 500 trang với cross-reference thì là ngoại lệ). Và bài toán dịch câu hoặc đoạn không cần agent, là single prompt. Bài toán phân loại email không cần agent, là classifier. Bài toán hỏi đáp chatbot từ knowledge base không cần agent, là RAG mà thôi. Agent chỉ đúng khi không thể biết trước sẽ cần bao nhiêu bước, theo thứ tự nào, dùng tool nào. Khi bản thân kế hoạch cũng phải do LLM sinh tại runtime. Debug một lỗi chưa biết nằm đâu trong codebase. Điều tra sự cố sản phẩm chưa biết nguyên nhân. Research một chủ đề chưa biết nguồn nào đáng tin.
Nếu bài toán của bạn không thuộc nhóm trên, khả năng cao bạn đang trả gấp nhiều lần chi phí cho độ trễ cao hơn, độ tin cậy thấp hơn, đã thế còn khó debug hơn. Để làm gì nhể? Để gắn nhãn "agent-powered" lên sản phẩm ư? Đó là sính thuật ngữ, không phải engineering.
Sai lầm 2, cài một mớ skills có miền giao nhau.
Các bạn cài nhiều skills với mô tả chồng chéo kiểu "handle API requests", "process REST endpoints", "manage HTTP routes". Mấy skills liền tù tì cho cùng một việc. Agent đọc mô tả và không biết chọn cái nào. Nó chọn skill đầu tiên match keyword, không phải là skill đúng context. Rồi pipeline bẻ hướng từ bước đầu tiên. Đến bước thứ ba cả project đã lạc đường mà không ai nhận ra vì mỗi bước riêng lẻ trông có vẻ đúng. Claude Code giải bằng conditional activation theo file path. Skill api-scaffold chỉ xuất hiện khi agent touch file trong routes. Skill database-migration chỉ xuất hiện trong migrations. Domains tách biệt tuyệt đối.
Nguyên tắc là nếu 2 skills có thể cùng activate cho một tình huống thì một trong hai sai. Ít mà rõ ràng mạnh hơn cả rổ nhưng overlap.
Sai lầm 3, ôm đồm tools như balo chạy bộ.
Nào hãy tưởng tượng bạn chạy marathon 42km với balo 10kg đồ ăn thức uống trên vai do niềm tin nó sẽ bồi dưỡng cho mình tận đích. Chết chắc. Vì running loop khác hiking loop. Mỗi bước lặp lại nghìn lần, mỗi gram đều tính. Các agent vào vòng lặp giống marathon, mỗi vòng LLM đọc lại toàn bộ định nghĩa tool. 10 tools thì OK. Có 50 tools thì mỗi lần agent scan qua tận 50 định nghĩa chỉ để chọn lấy 1. Token, độ trễ, xác suất chọn nhầm đều tăng.
Tệ hơn, nhiều tools có schema tương tự khiến LLM confuse. Agent lúc ấy gọi send_email với parameters của send_sms vì cả hai đều có field "to" và "body". LLM ảo giác schema vì hai tools nằm gần nhau trong context window. Hiểu như vậy thì tools phải đóng gói như đồ ăn cho vận động viên marathon. Mỗi tool phải có lý do tồn tại rõ ràng, schema không trùng lặp, mô tả cần chính xác khi nào dùng và khi nào không dùng. Cắt tools không dùng mỗi tuần như vận động viên cắt calories không cần thiết. Và thường 5 tools rõ ràng mạnh hơn 20 tools trùng lặp.
Sai lầm 4, mâu thuẫn nội tại trong niềm tin vào LLM
Đây là cái đau nhất. Cơ mà ít vị người nào dám thừa nhận nó là chính mình. Bạn tin AI, không tin AI. Cả hai cùng lúc. Tin ở chỗ giao cho LLM task phức tạp, không kiểm tra kỹ output, push to production với tự tin cao. "AI nó thông minh mà". Không tin ở chỗ viết prompt cực cụ thể, chỉ đạo từng bước, ép LLM follow flow của mình, constraint output format đến mức cứng nhắc "phải làm theo cách này". Hai cái này triệt tiêu nhau. Bạn ép LLM follow cách nghĩ của bạn nhưng cách nghĩ của bạn chính là cái bạn đang muốn LLM cải thiện hộ. Thế là bạn giam LLM trong khuôn tư duy của chính người giao việc, rồi tin tuyệt đối nó ở trong cái khung ngạo nghễ ấy. Kết quả, LLM khó đưa ra giải pháp tốt hơn bạn.