Hosting Minecraft 7 phút đọc

Phát triển phần mềm Agentic: Khi AI không chỉ code mà còn 'nghĩ' và 'làm' cho bạn?

Tác giả Thang Le Minh Đội ngũ hỗ trợ PIKAMC

Mình là dân vận hành server, bao năm nay cứ nói đến AI là nghĩ tới mấy con bot chat, lắm thì code suggestion. Nhưng gần đây, cái khái niệm phát triển phần mềm Agentic nó cứ nổi lên như cồn. Nghe thì hoành tráng lắm: AI không chỉ gõ code nữa mà nó còn 'nghĩ', còn tự 'làm' được. Hồi đầu mình nghe cũng thấy hơi nổ. AI mà biết nghĩ thay mình, biết chủ động vận hành như mình ư? Khó.

Nhưng mà thôi, cứ nghe đã. Rồi mình thử tìm hiểu sâu hơn một chút, xem nó rốt cuộc là cái quái gì mà thiên hạ đồn ầm ĩ thế. Có phải là công cụ 'đũa thần' biến không thành có, hay lại là một chiêu marketing mới?

Agentic AI: Thuật ngữ mới và là bước đột phá tiếp theo trong lĩnh vực trí tuệ nhân tạo (AI) | Advertising Vietnam

Phát triển phần mềm Agentic: Khi AI không chỉ code mà còn 'nghĩ' và 'làm' cho bạn?

Luận điểm của mình là: Agentic AI đúng là một bước tiến xa hơn so với mấy cái AI chỉ biết sinh code. Nó được thiết kế để xử lý những tác vụ phức tạp hơn bằng cách tự lập kế hoạch, tự thực thi, và thậm chí tự sửa sai. Tức là nó có vòng lặp perceive-reason-act (nhận thức - suy luận - hành động), gần giống như cách mình làm việc. Nó nhận thông tin, nó "nghĩ" xem làm gì, rồi nó "làm".

Nghe thì hấp dẫn, nhưng với kinh nghiệm làm vận hành của mình, thứ gì càng thông minh thì lúc nó "dở chứng" càng khó hiểu. Và với agentic AI, cái "dở chứng" của nó còn phức tạp hơn nhiều.

Agentic AI, explained | MIT Sloan

Lỗi không giống ai

Một điểm khiến mình tò mò là cách mấy con agent này thất bại. Mình cứ nghĩ nó lỗi thì cứ debug như code bình thường thôi chứ. Ai ngờ, một bạn trên GitHub issue của AgentRx (dự án chẩn đoán lỗi agent của Microsoft) kể rằng: lỗi của AI agent không giống lỗi code truyền thống. Nó hay lắm, thường là do tính ngẫu nhiên trong suy luận, chuỗi hành động quá dài, có nhiều agent cùng hoạt động, và nhất là output từ các tool nó dùng để tương tác với môi trường bên ngoài có khi… nhiễu tùm lum. Khó mà biết được nó lỗi ở bước nào, tại sao.

Bên AgentRx họ phân loại tới 10 kiểu lỗi khác nhau. Nghe mình kể mấy loại này bạn sẽ thấy nó "người" đến mức nào:

  • Instruction/Plan Adherence Failure: Đơn giản là "quên hướng dẫn", nhảy bước hoặc làm những việc không cần thiết.
  • Invention of New Information: Tự bịa thông tin hoặc bỏ sót những sự thật không có căn cứ. Như kiểu đọc báo lá cải vậy đó.
  • Invalid Invocation: Gọi tool sai cú pháp, sai tham số, sai kiểu dữ liệu. Cái này thì quen thuộc hơn.
  • Misinterpretation of Tool Output: Đọc kết quả từ tool mà hiểu sai bét.
  • Intent-Plan Misalignment: Lập kế hoạch sai mục tiêu ban đầu của người dùng.
  • Underspecified User Intent: Không đủ thông tin để tiếp tục, như mình đôi khi nhận ticket không rõ ràng vậy.
  • Intent Not Supported: Hành động không thể thực hiện với các tool hiện có.
  • Guardrails Triggered: Bị chặn bởi các chính sách an toàn, hoặc hạn chế quyền truy cập.
  • System Failure: Lỗi hạ tầng như timeout, không kết nối được endpoint.
  • Inconclusive: Không đủ bằng chứng để phân loại lỗi. Cái này mới hài, AI cũng có lúc "chịu chết" không biết sao nó lỗi.

Mấy con AI này cũng có lúc nó ngáo ngơ, vẫn có lúc nó "nhầm lẫn" đủ kiểu. Vấn đề là mình phải hiểu nó "ngáo" kiểu gì để còn "dạy" nó.

Cơ chế "chữa bệnh" cho AI

Nếu chỉ biết nó lỗi mà không biết sửa thì chán lắm. Cái hay là các nhà nghiên cứu cũng đang tìm cách để mấy con agent này tự "khôn" ra từ lỗi lầm. Một dự án khác là AgentDebug của ulab-uiuc, họ có hẳn một hệ thống phân loại 17 loại lỗi chia theo 5 module (memory, reflection, planning, action, system) và một quy trình debug hai giai đoạn để tìm ra nguyên nhân gốc rễ và đưa ra phản hồi sửa lỗi. Nghe cứ như mình đi tìm root cause của một incident vậy.

Họ còn có metrics rất rõ ràng: "Độ chính xác toàn diện" cải thiện +24%, "Độ chính xác từng bước" +17% và "Tỷ lệ thành công tác vụ" lên tới +26%. Những con số này cho mình thấy đây không chỉ là lý thuyết suông mà có cơ sở thực nghiệm rõ ràng.

À, một cái nhiều bạn hay quên... là đôi khi con agent nó "lì" lắm, cứ lặp đi lặp lại một lỗi. Có cái case trên một forum Nhật Bản về phát triển app iOS, một bạn kể con agent cứ chạy test xong bỏ qua lỗi, thậm chí còn lặp vô tận một lỗi y chang nhau. Rốt cuộc họ phải nghĩ ra cơ chế "Andon" — lấy ý tưởng từ hệ thống sản xuất của Toyota, tức là khi phát hiện lệnh quan trọng như git push hay deploy thất bại, phải chặn đứng lại. Kiểu như "thấy lỗi rồi, đừng cố nữa, dừng lại đã".

Cái hay là khi cái PostToolUse hook nó ngửi thấy mùi lỗi, nó sẽ bắt đầu phân tích log, phân loại lỗi và tính độ "tự tin" của nó. Nếu cùng một lỗi cứ lặp đi lặp lại trong thời gian ngắn, "Meta-ANDON" sẽ kích hoạt. Lúc này thì cấm sửa code luôn, bắt agent phải vào "chế độ lập kế hoạch" (planning mode) để phân tích toàn cục. Đây chính là điểm "depth spike" mình muốn nói: nó không chỉ biết lỗi, mà còn biết cách buộc mình phải "nghĩ lại".

Mình còn thấy một thư viện Python tên là triage. Thư viện này cũng làm nhiệm vụ tương tự: phân loại lý do agent thất bại và đưa ra chiến lược phục hồi thông minh. Chứ không phải cứ hễ lỗi là "retry" hay "bỏ cuộc". Triage có 9 loại FailureType, từ WRONG_TOOL_CALLED (gọi sai tool), LOOP_DETECTED (lặp vô tận), hay EXTERNAL_FAULT (lỗi bên ngoài như HTTP 500). Mỗi loại đều có gợi ý phục hồi mặc định. Ví dụ, nếu là SCHEMA_MISMATCH (lỗi sai định dạng dữ liệu), nó sẽ thử lại kèm theo "gợi ý schema".

Một ví dụ rất thực tế mà mình thấy trong các commit của dự án rjmurillo/ai-agents, họ có hẳn module phân loại lỗi kèm gợi ý phục hồi. Mình nhớ có lần con agent nó cứ loay hoay với một script Python, chạy đi chạy lại báo lỗi. Mình mò vào log thấy ngay dòng này:

ModuleNotFoundError

Nó cứ tưởng là lỗi code nhưng thật ra là thiếu thư viện. May mà có cái hệ thống recovery-hints. Cái hint gợi ý Missing Python dependency. Run uv pip install or check pyproject.toml. đúng bệnh luôn. Hoặc khi git báo not a git repository, nó hiểu ngay là đang chạy sai thư mục và gợi ý Current directory is not a git repo. Verify working directory.. Những cái này giúp agent tự sửa sai mà không cần mình can thiệp quá nhiều.

Một điểm mình thấy rất hay là họ có _GRADUATION_THRESHOLD = 3. Tức là nếu một kiểu lỗi được agent tự phục hồi thành công 3 lần trở lên, nó sẽ "tốt nghiệp", tự động áp dụng cách phục hồi đó cho lần sau. Như kiểu mình tự đúc rút kinh nghiệm vậy. Lại còn có khả năng nhận diện các lỗi "thoáng qua" (transient failures) như rate limit, HTTP 429 hay ETIMEDOUT để biết khi nào nên chờ và thử lại. Quá trình này được log lại vào file .agents/sessions/errors.jsonl để mình tiện theo dõi.

Tóm lại, những hệ thống này không chỉ biết rằng agent đã thất bại, mà còn hiểu tại sao nó thất bại. Và đó là mấu chốt để nó thực sự "nghĩ" và "làm" một cách thông minh hơn.

Vậy nên, agentic AI không phải là "phép thuật". Nó là một công cụ mạnh mẽ, nhưng cần được "huấn luyện" và "dạy dỗ" một cách bài bản. Nó sẽ là một "cánh tay" đắc lực, nhưng "bộ não" để định hướng, để hiểu sâu các lỗi và thiết kế hệ thống phục hồi vẫn phải là mình. Ít nhất là ở thời điểm hiện tại.