Blog / Series AI Agents Thực Chiến

Agent Skills 2026: knowledge gap đang thành nút thắt mới của coding agents

Vấn đề gốc: vì sao coding agents vẫn fail dù model ngày càng giỏi

Trong một năm qua, phần lớn cuộc tranh luận về coding agents xoay quanh model nào code hay hơn, reasoning tốt hơn, context dài hơn hay dùng tool ổn định hơn. Đó đều là những câu hỏi quan trọng. Nhưng khi đem agent vào công việc thật, một loại lỗi khác nổi lên rất nhanh: agent viết code hợp lý về mặt cú pháp, nhưng sai ở tầng kiến thức đang sống.

Nó import SDK cũ. Nó dùng method đã deprecated. Nó viết sample code theo tài liệu của 6 tháng trước. Nó gọi tên model không còn tồn tại. Nó cấu hình auth theo pattern đã bị thay bằng một luồng khác. Tệ hơn, đôi khi kết quả nhìn vẫn “trơn tru” đến mức reviewer non tay khó phát hiện vấn đề ngay.

Đây chính là knowledge gap. Khác với hallucination kiểu bịa đặt hoàn toàn, knowledge gap thường nguy hiểm hơn vì đầu ra vẫn có vẻ hợp lý. Agent không nói nhảm; nó chỉ bám vào một thế giới đã cũ hơn production vài vòng release.

Nếu bài Từ chatbot → AI Agent giải thích tại sao muốn đi từ trả lời sang hành động phải có tool, state và boundary, thì ở lớp coding agent, câu hỏi kế tiếp là: agent đang hành động dựa trên tri thức nào, tri thức đó mới đến đâu, và nó được cập nhật bằng cơ chế gì?

Agent skills là gì, và tại sao chủ đề này nóng lên đúng lúc này?

Về bản chất, agent skill là một gói hướng dẫn có cấu trúc giúp agent hiểu một domain cụ thể: API nào đang đúng, SDK nào nên dùng, pattern nào được khuyến nghị, entry point tài liệu nằm ở đâu, lệnh nào được phép dùng, anti-pattern nào cần tránh. Nó giống một lớp “bộ nhớ vận hành” mỏng, được gắn vào agent tại thời điểm chạy thay vì nhúng cứng trong model.

Chủ đề này nóng lên vì một tín hiệu rất thực dụng: các đội làm platform bắt đầu đo được rằng chênh lệch giữa model có reasoning tốt và model không có reasoning tốt không nằm ở việc viết code dài hơn, mà ở việc biết dùng đúng tri thức mới. Google DeepMind gần đây chia sẻ một bài đánh giá quanh skill cho Gemini API dev, cho thấy chỉ thêm một lớp skill mỏng nhưng đúng nguồn có thể cải thiện mạnh chất lượng đầu ra ở các tác vụ dùng SDK mới.

Điểm đáng chú ý không phải “skills là phép màu mới”. Điểm đáng chú ý là thị trường đang thừa nhận một sự thật khó chịu: pretraining không thể theo kịp nhịp thay đổi của hệ sinh thái phần mềm. Web search, MCP, tài liệu live, skill packs, AGENTS.md, repo conventions — tất cả đang được kéo vào để bù cho khoảng trống này.

Nói cách khác, nếu năm 2025 là giai đoạn mọi người học cách cho model dùng tool, thì 2026 đang chuyển sang câu hỏi khó hơn: làm sao để model dùng tool đúng theo tri thức mới nhất của domain?

Một use case end-to-end: giữ coding agent bám đúng SDK mới thay vì code theo ký ức cũ

Hãy lấy một use case đủ đời thường. Một đội sản phẩm muốn giao cho coding agent nhiệm vụ dựng nhanh một service phân tích tài liệu bằng SDK AI mới nhất của nhà cung cấp. Agent được cấp quyền đọc repo, viết code, chạy test và tạo pull request nháp.

Nếu không có lớp live knowledge, chuyện gì xảy ra?

1. Agent đọc vài file hiện có trong repo nhưng repo chưa dùng SDK mới.
2. Nó lấp chỗ trống bằng tri thức có sẵn trong model.
3. Nó chọn một package hoặc API signature đã cũ.
4. Nó tạo sample code rất mượt, thậm chí có test cơ bản.
5. Đến lúc chạy thật, build fail hoặc tệ hơn: build pass nhưng hành vi runtime sai do contract đã đổi.

Đây là lỗi tốn thời gian nhất vì team phải debug ở trạng thái “mọi thứ trông có vẻ hợp lý”.

Khi gắn đúng skill vào pipeline, flow thay đổi khá nhiều:

1. Agent kích hoạt skill theo domain, ví dụ skill dành cho SDK A hoặc framework B.
2. Skill chỉ rõ model/SDK/version hiện hành, pattern cài đặt đúng, entry point tài liệu và ví dụ cơ sở.
3. Skill buộc agent kiểm tra tài liệu nguồn trước khi code những phần dễ lệch phiên bản.
4. Nếu có fetch_url hoặc doc MCP, agent có thể kéo nội dung tài liệu mới nhất về ngay trong run.
5. Khi code xong, agent được nhắc chạy đúng loại kiểm chứng: lint, unit test, snippet execution hoặc sample notebook.

Kết quả quan trọng nhất không phải số dòng code. Kết quả là đầu ra bám sát trạng thái hiện tại của hệ sinh thái. Đây là khác biệt giữa một coding agent “giỏi suy luận” và một coding agent “có thể giao việc thật”.

Ở góc nhìn rộng hơn, use case này cũng chạm tới bài workflow, memory và skills: muốn hệ chạy ổn định, phải phân biệt rõ tri thức nền, tri thức live và nguồn sự thật có thể truy xuất.

Kiến trúc hệ thống: skills, AGENTS.md, MCP docs và lớp nguồn sự thật

Rất nhiều đội mắc lỗi vì coi skill như một file prompt dài hơn. Cách nhìn đó quá nông. Trong production, bài toán không phải “thêm hướng dẫn”, mà là thiết kế đường đi của tri thức.

1. Skill layer: tri thức ngắn gọn, có mục đích

Skill nên chứa những gì agent cần để vào việc nhanh: feature map, version đang dùng, pattern code chuẩn, anti-pattern cần tránh, checklist kiểm chứng và đặc biệt là đường dẫn tới tài liệu gốc. Nó không nên cố thay tài liệu chính thức bằng một bản sao mini khổng lồ.

2. Repo instruction layer: AGENTS.md hoặc project convention

Skill trả lời câu hỏi “domain này vận hành thế nào”. Còn AGENTS.md hoặc file quy ước của repo trả lời câu hỏi “repo này làm việc thế nào”. Hai lớp này bổ sung cho nhau. Bài học quan trọng là: global knowledge và local convention không nên nhét chung vào một khối prompt.

3. Retrieval / doc layer: tài liệu mới nhất làm nguồn sự thật

Nếu chỉ có skill mà không có cơ chế lấy tài liệu mới, hệ thống vẫn sớm cũ. Đó là lý do nhiều đội chuyển sang kết hợp skills với search, doc fetch hoặc MCP servers. MCP đặc biệt hữu ích khi muốn chuẩn hóa việc agent truy cập nguồn docs, sandbox hoặc dịch vụ ngoài một cách có cấu trúc.

4. Verification layer: kiểm tra thay vì tin tưởng

Skill có thể hướng agent đi đúng hướng, nhưng không được xem là nguồn chân lý tuyệt đối. Production cần thêm kiểm chứng: chạy snippet, build tối thiểu, contract test hoặc notebook execution. Đây là nơi các môi trường thực thi như browser runtime hay cloud notebook bắt đầu gắn vào câu chuyện agent.

5. Update layer: ai chịu trách nhiệm làm tri thức luôn mới?

Lớp này thường bị quên nhất. Nếu không có owner, skill sẽ âm thầm hỏng. Một release SDK mới, một luồng auth đổi, một best practice không còn đúng — và từ đó, mọi agent run bắt đầu lặp lại một lỗi cũ nhưng rất tự tin.

Nói gọn, kiến trúc đúng không phải model + prompt. Nó là model + instructions + retrieval + verification + ownership.

Trade-off và failure mode: khi “live knowledge” biến thành debt mới

Agent skills hấp dẫn vì nhẹ và dễ áp dụng. Nhưng càng dễ, càng dễ lạm dụng.

1. Skill nhanh hơn fine-tuning, nhưng rất dễ drift

Viết một skill mới có thể nhanh hơn huấn luyện hay xây một hệ truy xuất đồ sộ. Nhưng khi có nhiều team, nhiều repo, nhiều vendor và nhiều version cùng sống, drift đến rất nhanh. Cùng một domain nhưng skill A nói một kiểu, skill B nói một kiểu khác.

2. Skill đơn giản hơn doc portal, nhưng không thay thế được doc portal

Nếu nhét quá nhiều chi tiết vào skill, nó trở thành một bản sao tài liệu nghèo nàn và nhanh lỗi thời. Nếu skill quá ngắn, nó lại không đủ giá trị. Điểm cân bằng thường là: skill định hướng, docs xác nhận, verification kết luận.

3. Reasoning tốt giúp skill phát huy tác dụng, nhưng không cứu được skill tệ

Một kết quả thú vị từ các đánh giá gần đây là skill cho hiệu quả cao hơn trên model reasoning mạnh. Điều này hợp lý: model giỏi hơn biết dùng skill để lập kế hoạch tốt hơn. Nhưng chiều ngược lại cũng đúng: nếu skill mơ hồ hoặc lỗi thời, model reasoning tốt có thể chỉ tự tin đi sai nhanh hơn.

4. Failure modes phổ biến

• Stale skill: skill vẫn nhắc SDK cũ sau khi vendor đã đổi chuẩn.
• Conflicting instructions: AGENTS.md, README và skill nói ba kiểu khác nhau.
• Over-trust: agent coi skill là chân lý, bỏ qua việc kiểm tra docs hoặc chạy thử.
• Prompt stuffing: nhét toàn bộ tài liệu vào skill làm agent mất khả năng ưu tiên tín hiệu quan trọng.
• No owner: không ai chịu trách nhiệm cập nhật sau mỗi release hoặc deprecation.
• Invisible failures: code vẫn chạy ở local sample nhưng sai ở environment production do auth, quota hoặc behavior model đã đổi.

Nếu nhìn từ góc vận hành, skill không xóa debt; nó chỉ dịch debt từ mô hình sang quy trình tri thức. Và đó là một dạng debt lành mạnh hơn chỉ khi team thực sự quản trị nó.

Triển khai thực tế: khi nào nên dùng skill, khi nào nên đẩy sang MCP hoặc docs retrieval?

Không phải mọi bài toán knowledge gap đều cần cùng một công cụ.

• Dùng skill khi bạn cần lớp hướng dẫn mỏng, ổn định, dễ kích hoạt theo domain hoặc tác vụ.
• Dùng AGENTS.md / repo convention khi tri thức gắn chặt vào cách làm việc của một codebase cụ thể.
• Dùng docs retrieval / MCP khi thông tin thay đổi nhanh, cần nguồn sự thật động hoặc cần truy cập có cấu trúc tới dịch vụ ngoài.
• Dùng verification environment khi sai một bước là phải trả giá ở runtime, billing, compliance hoặc security.

Với nhiều team, chiến lược bền nhất là kết hợp cả bốn. Cách này nghe có vẻ nặng hơn, nhưng thực ra lại rẻ hơn nhiều so với việc để agent “tự nhớ” cả thế giới phần mềm đang thay đổi từng tuần.

Checklist triển khai thực dụng cho team sản phẩm và platform

Giai đoạn 1: chọn domain có pain rõ ràng

• Ưu tiên nơi agent thường xuyên dùng sai SDK, sai pattern auth hoặc sai API signature.
• Không bắt đầu bằng việc viết skill cho mọi thứ cùng lúc.
• Chọn một domain có owner rõ và tài liệu gốc rõ.

Giai đoạn 2: thiết kế skill đủ ngắn để dùng, đủ sâu để có giá trị

• Liệt kê feature map, version hiện hành, anti-pattern, docs entry point.
• Không copy nguyên tài liệu vào skill.
• Thêm hướng dẫn bắt buộc kiểm tra tài liệu nguồn ở các bước nhạy cảm.

Giai đoạn 3: gắn verification ngay từ đầu

• Build tối thiểu, snippet execution hoặc unit test phải nằm trong flow agent.
• Đo tỷ lệ code dùng API cũ trước và sau khi có skill.
• Log rõ agent đã dùng skill nào, đã fetch tài liệu nào, đã kiểm chứng ra sao.

Giai đoạn 4: quản trị vòng đời tri thức

• Đặt owner cho từng skill.
• Review lại mỗi khi SDK có breaking change hoặc tài liệu đổi cấu trúc.
• Có versioning hoặc ít nhất timestamp để biết skill đang mới đến đâu.

Giai đoạn 5: chỉ scale khi đã nhìn thấy hành vi tốt hơn, không chỉ output đẹp hơn

• Đo số lỗi do API cũ, số run phải sửa tay, thời gian debug.
• Ưu tiên giảm lỗi âm thầm hơn là tăng tốc sinh code thuần túy.
• Nếu domain đổi quá nhanh, cân nhắc chuyển trọng tâm từ skill sang retrieval/MCP.

Insight cuối cùng: cuộc đua coding agents đang chuyển từ “model quality” sang “knowledge operations”

Điều đáng chú ý nhất ở làn sóng agent skills không phải việc xuất hiện thêm một định dạng hướng dẫn mới. Điều đáng chú ý là cả ngành đang dần chấp nhận rằng chất lượng của agent không chỉ là chất lượng mô hình, mà là chất lượng vận hành tri thức quanh mô hình.

Một coding agent có reasoning mạnh nhưng dùng SDK cũ vẫn là một nhân sự mới đầy tự tin nhưng cầm handbook lỗi thời. Một agent có skill tốt nhưng không được kiểm chứng cũng chỉ là người đọc thuộc quy trình mà chưa từng chạy hệ thống thật. Còn một agent được đặt đúng vào kiến trúc gồm skill + repo instruction + docs retrieval + verification mới bắt đầu có cơ hội bước qua ranh giới từ demo sang năng lực triển khai.

Vì vậy, câu hỏi chiến lược cho 2026 không còn chỉ là “model nào code giỏi nhất”. Câu hỏi sâu hơn là: đội ngũ của bạn đang vận hành tri thức cho agent như thế nào, và liệu tri thức đó có theo kịp tốc độ thay đổi của hệ sinh thái phần mềm hay không?

Ai trả lời tốt câu hỏi đó sẽ không chỉ có agent viết code nhanh hơn. Họ sẽ có agent bám sát hiện thực hơn — và đó mới là thứ tạo ra chênh lệch dài hạn.