- Kỹ thuật tác nhân (Agentic Engineering) là sự thay đổi tư duy từ việc sử dụng AI như một công cụ đơn thuần sang làm việc với nó như một cộng tác viên, đặc biệt là một lập trình viên cấp dưới rất nhanh nhưng thiếu óc phán đoán.
- Hiệu quả của việc làm việc với AI phụ thuộc vào "Kỹ thuật ngữ cảnh" – nghệ thuật và khoa học quản lý thông tin bạn cung cấp cho AI, vì ngữ cảnh không phù hợp hoặc quá nhiều có thể làm giảm chất lượng và tăng chi phí.
- Áp dụng vòng lặp "Nghiên cứu - Lập kế hoạch - Triển khai" là cần thiết để tận dụng tối đa AI, tập trung vào việc hiểu rõ vấn đề và lập kế hoạch chi tiết trước khi để AI tạo mã, tránh việc nhảy vội vào triển khai gây ra lỗi và lãng phí thời gian.
Agentic Engineering: Working With AI, Not Just Using It — Brendan O'Leary
- Thay đổi mô hình tư duy: Coi AI agent như một "lập trình viên cấp dưới" năng động, thông thái nhưng thiếu óc phán đoán và ngữ cảnh kinh doanh, đòi hỏi sự hướng dẫn rõ ràng từ con người.
- Quản lý ngữ cảnh chủ động: Ngữ cảnh (context) là đắt đỏ và không phải lúc nào nhiều cũng tốt hơn; vượt quá giới hạn nhất định có thể làm giảm chất lượng đầu ra ("vùng ngu ngốc").
- Lựa chọn ngữ cảnh có chọn lọc: Duy trì thông tin không trực tiếp liên quan (scratch pad, memory files) bên ngoài cửa sổ ngữ cảnh và chỉ đưa vào những gì thật sự cần thiết cho từng bước giải quyết vấn đề cụ thể.
- Cô lập và nén ngữ cảnh: Bắt đầu phiên làm việc mới khi cần thay đổi hướng hoặc khi ngữ cảnh trở nên quá lớn, hoặc sử dụng các tác nhân song song để chia nhỏ công việc và tránh tích tụ ngữ cảnh xấu. Yêu cầu AI tóm tắt phiên làm việc để tái sử dụng ngữ cảnh cô đọng.
- Tuân thủ vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai (RPI):
- Nghiên cứu (
Ask Mode): Tập trung vào việc hiểu hệ thống, xác định các tệp liên quan, mô hình cần mô phỏng, và các trường hợp ngoại lệ. Sản phẩm đầu ra là tài liệu nghiên cứu chi tiết. - Lập kế hoạch: Vạch ra các bước cụ thể, tệp cần thay đổi, cách xác minh và phạm vi công việc. Sản phẩm đầu ra là một tài liệu kế hoạch rõ ràng, từng bước.
- Triển khai: Chỉ thực hiện giai đoạn này sau khi nghiên cứu và lập kế hoạch kỹ lưỡng. Bắt đầu một phiên mới với ngữ cảnh thấp và cam kết thay đổi thường xuyên.
- Nghiên cứu (
- Tránh vội vàng tạo mã: Đừng yêu cầu AI trực tiếp "triển khai tính năng này" ngay từ đầu. Phương pháp này thường dẫn đến các giả định sai lầm, lãng phí thời gian và tạo ra mã chất lượng kém.
- Giám sát chặt chẽ cửa sổ ngữ cảnh: Luôn để ý đến "đồng hồ ngữ cảnh" của AI. Nếu cảm thấy mọi thứ đang chệch hướng, hãy bắt đầu một phiên mới và yêu cầu AI tóm tắt trạng thái hiện tại để tái khởi động với ngữ cảnh sạch và phù hợp.
- Kỹ thuật tác nhân — Agentic Engineering
- Luồng công việc — Workflow
- Tạo mã — Code Generation
- Mô hình — Model (AI) / Paradigm (mindset)
- Tác nhân AI — AI Agent
- Tác vụ — Task
- Lập trình viên cấp dưới — Junior Engineer
- Ngữ cảnh — Context
- Kỹ thuật ngữ cảnh — Context Engineering
- Mã thông báo — Token
- Cửa sổ ngữ cảnh — Context Window
- Lời nhắc — Prompt
- Mô hình ngôn ngữ lớn (LLM) — Large Language Model (LLM)
- Vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai — Research-Plan-Implement (RPI) loop
- Chế độ hỏi — Ask Mode
Giới thiệu về Kỹ thuật Tác nhân (Agentic Engineering)
Hãy cùng bàn một chút về ý nghĩa của kỹ thuật tác nhân (agentic engineering). Chúng ta hãy bắt đầu bằng một câu hỏi: Nếu tôi hỏi bạn ngay bây giờ, bạn đang sử dụng AI trong công việc của mình như thế nào? Bạn có thực sự giải thích được không? Không chỉ đơn giản là "nó giúp tôi tạo mã nhanh hơn" hay "nó có thể viết mã rất nhanh", mà là luồng công việc thực tế: bạn giao phó những gì, bạn giữ lại những gì, và bạn quyết định như thế nào giữa các công việc. Hầu hết các kỹ sư không thể làm vậy, và điều đó khá lạ đối với tôi, bởi vì 90% kỹ sư đã và đang sử dụng công cụ AI. Có thể chỉ một nửa trong số họ sử dụng thường xuyên, nhưng con số đó chắc chắn đang tăng lên. Đó là tình hình hiện tại.
Vậy câu hỏi không phải là liệu nhóm của bạn có sử dụng AI hay không – họ đang sử dụng. Câu hỏi là liệu bạn có tận dụng tối đa nó hay chỉ đang tự động hoàn thành công việc cả ngày. Khoảng cách giữa việc sử dụng AI và khả năng diễn đạt cách bạn làm việc với nó – đó chính là nội dung của bài nói chuyện này. Và thực sự, tôi nghĩ nó đại diện cho một mô hình thay đổi trong cách chúng ta nghĩ về AI.
Lịch sử và Sự Chuyển Đổi của AI trong Kỹ thuật Phần Mềm
Lịch sử AI và kỹ thuật phần mềm đang phát triển rất nhanh, và cũng đáng ngạc nhiên là khá ngắn ngủi. Đầu những năm 2020, chúng ta có các công cụ có thể hoàn thành các dòng mã cho bạn. Bạn gõ nửa chữ ký của một hàm và mô hình sẽ đoán phần còn lại, giống như một tự động hoàn thành được nâng cấp mạnh mẽ. Đó là một mẹo hay.
Và rồi vào năm 2022, các mô hình bắt đầu có khả năng gợi ý toàn bộ hàm. Bạn có thể mô tả những gì bạn muốn, trò chuyện với một mô hình, và có thể nhận lại một bản triển khai hoạt động được. Đây là lúc GitHub Copilot lần đầu tiên xuất hiện và tạo ra đột phá. Hàng triệu nhà phát triển bắt đầu sử dụng nó, và lần đầu tiên, có vẻ như AI không còn là một điều mới lạ, mà có thể thực sự hữu ích.
Nhưng rồi vào năm 2025, một điều thực sự đột phá đã xảy ra. Cái mà chúng ta đang sống trong năm 2026 này, các mô hình không chỉ gợi ý, chúng còn có thể thực thi. Chúng có thể nhận một tác vụ và chia nhỏ nó, tìm ra tệp nào cần chỉnh sửa, thực hiện thay đổi, tự chạy kiểm thử, và sau đó đưa ra một pull request thực sự. Điều đó không chỉ là tự động hoàn thành cao cấp, không chỉ là một con ngựa nhanh hơn. Đó là một cộng tác viên. Đó là một cách làm việc khác.
Armand, người tạo ra Flask (dành cho những người dùng Python ở đây), đã nói một cách hoàn hảo: "Chúng ta không còn chỉ sử dụng máy móc, chúng ta đang làm việc với chúng." Cách diễn đạt này, tôi nghĩ, nắm bắt được sự thay đổi thực sự này. Công cụ là những thứ bạn cầm lên và đặt xuống. Bạn dùng một cái búa, bạn không làm việc với một cái búa. Nhưng các Tác nhân AI (AI agent) tạo mã mà chúng ta có ngày nay, chúng ở đâu đó giữa hai thái cực đó. Và có lẽ chúng giống như làm việc với một kỹ sư khác. Chỉ là kỹ sư này đã đọc mọi câu trả lời trên Stack Overflow từng được viết.
Mô hình Tư duy Mới: Xem AI như một Lập trình viên Cấp dưới
Tôi nghĩ điều này đòi hỏi một sự thay đổi trong mô hình tư duy. Và đây là mô hình tư duy mà tôi muốn bạn mang theo trong suốt phần còn lại của video này, và thành thật mà nói, trong vài năm tiếp theo của sự nghiệp bạn khi làm việc với các công cụ này. Tôi vẫn nghĩ chúng là công cụ, nhưng chúng ta phải nghĩ về chúng một cách khác.
Bạn có thể phải coi Tác nhân AI của mình như một lập trình viên cấp dưới năng động, nhiệt tình, đọc rất nhiều, và thường tự tin sai. Lập trình viên cấp dưới này cực kỳ nhanh, không dễ mệt mỏi, không có cái tôi về mã của mình – họ sẽ vui vẻ viết lại thứ gì đó sáu lần nếu bạn yêu cầu. Và họ có một kiến thức đáng kinh ngạc: họ đã thấy rất nhiều ngôn ngữ, rất nhiều khung làm việc, rất nhiều mô hình.
Nhưng, và đây là điều quan trọng, cái mà họ không có là óc phán đoán. Họ không biết ngữ cảnh kinh doanh của bạn. Họ không hiểu lý do tại sao bạn đưa ra quyết định kiến trúc rất cụ thể đó ba tháng trước. Và họ sẽ tự tin viết mã đúng về mặt kỹ thuật nhưng sai về mặt ngữ cảnh. Armand cũng nói rằng anh ấy đã tiết kiệm hơn 30% thời gian trong ngày vì máy móc đang làm rất nhiều công việc. Đó là một lợi ích thực sự. Nhưng anh ấy đạt được 30% đó vì anh ấy biết mình có thể giao phó những gì và phải giữ lại những gì cho bản thân. Anh ấy không chỉ mù quáng chấp nhận mọi gợi ý. Anh ấy đang hướng dẫn công việc. Và đó là sự khác biệt giữa việc sử dụng AI và làm việc với AI. Đó chính là ý nghĩa thực sự của kỹ thuật tác nhân.
Kỹ thuật Ngữ cảnh (Context Engineering)
Vậy thì hãy đi vào thực tế. Nếu bạn là một kỹ sư, làm thế nào để chúng ta thực sự làm tốt điều này? Tôi nghĩ điều số một cần suy nghĩ là kỹ thuật ngữ cảnh. Karpathy nói rằng kỹ thuật ngữ cảnh là "một nghệ thuật và khoa học tinh tế trong việc điền cửa sổ ngữ cảnh với chính xác những gì cần thiết để Tác nhân có ngữ cảnh phù hợp cho lần lặp phù hợp cho bước tiếp theo."
Tôi nghĩ điều đó thực sự quan trọng vì một vài lý do.
Thứ nhất, ngữ cảnh rất đắt đỏ. Mỗi mã thông báo (token) bạn thêm vào ngữ cảnh sẽ làm tăng chi phí vì tất cả lịch sử trò chuyện đó được gửi lại dưới dạng mã thông báo đầu vào mỗi khi bạn gửi. Và điều đó có thể tăng lên khá nhanh.
Và điều quan trọng khác là nhiều ngữ cảnh hơn không phải lúc nào cũng có nghĩa là kết quả tốt hơn. Trên thực tế, nó có thể làm cho mô hình thực sự "ngu ngốc hơn". Đúng vậy, không chỉ là vấn đề tiền bạc. Chất lượng bắt đầu giảm sút khi bạn vượt quá khoảng 50% cửa sổ ngữ cảnh. Có rất nhiều điều có thể khiến bạn mắc bẫy ở đây, trong đó có cả việc máy chủ MCP trở nên phổ biến đến mức chúng ta bật rất nhiều tính năng này mọi lúc. Mỗi tính năng đó tải thêm và thêm ngữ cảnh, tức là thêm và thêm mã thông báo đầu vào vào ngữ cảnh. Và đó có thể là một vấn đề thực sự nếu bạn bắt đầu đi vào "vùng ngu ngốc" (dumb zone) này ở khoảng 50% ngữ cảnh.
Và đó cũng không phải là vấn đề duy nhất, bởi vì không chỉ nhiều ngữ cảnh hơn có thể là một vấn đề, mà ngữ cảnh xấu cũng có thể là một vấn đề và có thể đầu độc mọi thứ. Đúng vậy, điều này xảy ra khi bạn có thể đang trộn lẫn hai tác vụ khác nhau không thực sự chồng chéo, hoặc bạn có một số nhận xét lỗi thời trong mã hoặc bạn đã thực hiện nó như một Tác nhân. Hoặc tệ hơn nữa, điều tôi đã thấy nhiều người làm là họ bắt đầu đi theo một hướng với một Tác nhân và sau đó nhận ra rằng, "này, chúng ta đã đi sai đường, chúng ta đã đưa ra rất nhiều quyết định sai lầm," và họ cố gắng điều chỉnh Tác nhân quay lại. Nhưng vấn đề là, một lần nữa, Tác nhân không thực hiện suy luận thực sự như bạn và tôi với tư cách là một con người. Đúng vậy, nó lấy tất cả ngữ cảnh đó mỗi lần. Và nó có thể bị lạc ở giữa hoặc thậm chí xem một số điều tiêu cực mà bạn đã có trước đây như vẫn là một phần của ngữ cảnh. Và bạn sẽ thấy những mô hình tiêu cực đó len lỏi trở lại nếu bạn không cẩn thận. Đó là lý do tại sao tốt hơn là không để những điều này tích tụ. Nhưng cũng nên, bạn biết đấy, luôn bắt đầu một phiên mới khi bạn nhận ra mọi thứ đang đi chệch đường ray. Đúng vậy, bởi vì ngữ cảnh không chỉ đắt đỏ. Càng có nhiều ngữ cảnh không phải lúc nào cũng có nghĩa là chất lượng tốt hơn. Trên thực tế, tại một điểm nhất định, có một điểm giới hạn mà nó có nghĩa là chất lượng tệ hơn. Và ngữ cảnh xấu có thể làm hỏng đầu ra.
Vì vậy, điều thực sự quan trọng đối với các kỹ sư là quản lý ngữ cảnh. Và điều đó có nghĩa là gì?
Quản lý Ngữ cảnh Hiệu quả
Thứ nhất, tôi nghĩ điều đó có nghĩa là duy trì rất nhiều thông tin bên ngoài cửa sổ ngữ cảnh để chúng ta có thể đưa nó vào. Đúng vậy, đây là những thứ như scratch pad cho những gì chúng ta đang làm, tệp bộ nhớ, tệp MD của Tác nhân, những loại tệp giúp các Tác nhân có ngữ cảnh về những gì bạn đang làm.
Chúng ta cũng cần rất có chọn lọc khi chọn ngữ cảnh đó. Điều đó có nghĩa là chỉ lấy những gì liên quan cho bước giải quyết vấn đề này. Đúng vậy, đừng chỉ đưa vào mọi thứ có thể hữu ích. Và điều đó có thể có nghĩa là, bạn biết đấy, đưa vào các thẻ nhắc (at mentions) phù hợp cho các tệp mà chúng ta đang tham chiếu, điều đó có thể có nghĩa là đảm bảo chúng ta không bật các máy chủ MCP không cần thiết. Và điều đó có nghĩa là, bạn biết đấy, đảm bảo rằng Tác nhân có dữ liệu phù hợp và chúng ta, với tư cách là con người, đã tuyển chọn dữ liệu đó cho Tác nhân.
Và sau đó, khi nó ngày càng lớn hơn và cửa sổ đó ngày càng lớn hơn, chúng ta muốn tóm tắt, cắt giảm và nén ngữ cảnh đó. Đúng vậy, nếu chúng ta đã trải qua một phiên gỡ lỗi và nghiên cứu sâu toàn diện với Tác nhân và bây giờ chúng ta nghĩ rằng mình đã có vấn đề và giải pháp, thì điều đó thật tuyệt vời. Có thể đã đến lúc nén ngữ cảnh đó và chỉ tập trung lại Tác nhân vào việc "được rồi, bây giờ chúng ta hiểu vấn đề này. Chúng ta sẽ đi khắc phục nó."
Và sau đó, điều quan trọng nhất khác là cô lập ngữ cảnh (isolate context). Và tôi nghĩ đây là lý do tại sao chúng ta thấy sự gia tăng lớn trong sáu hoặc tám tháng qua của các Tác nhân song song (parallel agents), bởi vì chia nhỏ công việc giữa nhiều Tác nhân hoặc nhiều phiên có thể giúp mọi thứ không tích tụ và thực sự thúc đẩy loại phân tách tác vụ này.
Và một lần nữa, nếu bạn nghĩ về nó, không phải tất cả những điều này đều là những điều mà tôi sẽ nói với một quản lý kỹ thuật mới về việc quản lý một kỹ sư cấp dưới (junior engineer) sao? Câu chuyện tôi kể ở đây là khi tôi mới bắt đầu sự nghiệp, tôi đã dành rất nhiều thời gian làm quản lý kỹ thuật và quản lý sản phẩm trước khi tôi bước vào nghệ thuật đen tối của quan hệ nhà phát triển. Và trong công việc đầu tiên của tôi với tư cách là quản lý kỹ thuật, tôi làm việc tại một công ty phần mềm chăm sóc sức khỏe. Và có một điều mới sắp ra mắt gọi là iPad – điều đó cho thấy tôi đã lớn tuổi một chút. Nhưng nó được phát hành trên thị trường và chúng tôi nghĩ đây có thể là một nơi tuyệt vời để thu thập lịch sử bệnh án. Bạn biết đấy, đối với tôi, tôi phải điền vào mỗi năm tại bác sĩ. Nó rất quan trọng để đánh giá nhiều nguy cơ bệnh tật của bạn. Nhưng việc phải điền từ đầu mỗi lần thì không vui chút nào.
Và vì vậy tôi đã thiết kế trong một công cụ lỗi thời khác mà một số người có thể đã nghe nói đến tên là Balsamiq – về cơ bản là một công cụ tạo wireframe – một wireframe về giao diện sẽ như thế nào. Công cụ tạo wireframe đó đã sử dụng những thứ như Comic Sans và các biểu tượng mặt cười ngớ ngẩn làm chỗ giữ chỗ. Và rất nhiều thứ khác như vậy mà bạn mong đợi từ một wireframe. Và tôi đã giao nó cho một nhóm thực tập sinh mà chúng tôi có làm việc cho chúng tôi vào mùa hè năm đó, nghĩ rằng đây là một dự án mới tuyệt vời để họ dành thời gian vào. Và bạn biết đấy, vài tuần sau, tôi nhận lại một nguyên mẫu hoạt động được. Và phông chữ là Comic Sans và có các biểu tượng emoji ngớ ngẩn. Và đó là vì đó là những gì đặc tả có. Vậy lỗi của ai? Rõ ràng đó không phải là lỗi của thực tập sinh. Đó là lỗi của tôi với tư cách là quản lý kỹ thuật vì đã không cung cấp ngữ cảnh phù hợp cho những kỹ sư cấp dưới đó về điều gì là quan trọng, điều gì không, và chúng ta thực sự cần tập trung vào điều gì và vấn đề chúng ta đang giải quyết là gì.
Thói quen Hiệu quả khi Làm việc với AI
Vì vậy, tôi nghĩ các thói quen có thể kết nối tất cả những điều đó lại với nhau là: bạn không cần phải suy nghĩ về cả bốn điều đó cho mỗi tác vụ. Bạn chỉ cần nghĩ về việc thực hiện một tác vụ cho mỗi phiên.
Hãy để mắt đến đồng hồ ngữ cảnh của bạn. Và nếu bạn nghi ngờ và cảm thấy mọi thứ đang chệch hướng, bạn có lẽ đã đúng. Vì vậy, bắt đầu một phiên mới, yêu cầu Tác nhân đó tóm tắt phiên cho một Tác nhân mới. Hóa ra, AI thực sự rất giỏi trong việc viết lời nhắc (prompt) cho AI. Vì vậy, nếu bạn đã làm việc với một Tác nhân trong một thời gian, hãy yêu cầu Tác nhân đó tóm tắt trạng thái hiện tại của bạn. Bây giờ bạn có thể đọc nó, đảm bảo nó khớp với sự hiểu biết của bạn và sau đó bắt đầu một phiên mới với chính ngữ cảnh phù hợp đó. Một chút nghệ thuật và một chút khoa học.
Vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai
Vậy làm thế nào để chúng ta đưa điều này vào thực tế? Chà, tôi nghĩ có rất nhiều luồng công việc. Có rất nhiều thứ đã được viết ra mà bạn có thể đọc. Tôi thậm chí đã tập hợp rất nhiều trong số đó tại path.kilo.ai. Đó là nơi bạn có thể tìm thấy tất cả các loại xu hướng, ý tưởng và mô hình luồng công việc đã được thảo luận. Nhưng điều tôi luôn quay trở lại là một trong những điều đơn giản hơn. Và đó là vòng lặp "nghiên cứu, lập kế hoạch, triển khai" (research plan implement loop).
Và tôi nghĩ điều này thực sự giúp chúng ta giải quyết rất nhiều sai lầm cổ điển mà mọi người mắc phải khi lần đầu tiên bắt đầu kỹ thuật tác nhân hoặc sử dụng AI để giúp họ thực hiện một số công việc kỹ thuật. Và điều mà hầu hết mọi người làm là nói, "này, giúp tôi triển khai tính năng này. Tôi muốn nó làm X và Y." Và bạn biết đấy, các Mô hình ngôn ngữ lớn (LLM) rất giỏi trong việc tạo ra rất nhiều mã.
Sai lầm khi vội vàng tạo mã
Thực tế, khi tôi gia nhập Kilo Code hơn một năm trước, tôi đã tuyên bố rằng trang web của chúng tôi sẽ không bao giờ chỉ là một lời nhắc và hàng loạt mã chạy vèo vèo. Điều đó tạo ra một bản demo tuyệt vời, và bạn đã thấy rất nhiều Tác nhân lập trình thể hiện khả năng của chúng theo cách đó. Nhưng tôi nghĩ rằng việc nhảy thẳng vào mã như vậy có thể gây ra nhiều giả định sai lầm. Nó có thể lãng phí nhiều thời gian hơn là tiết kiệm thời gian và chỉ tạo ra sự thất vọng. Nó thực sự tạo ra một mô hình mà chúng ta đã thấy, nơi mọi người có vẻ như "chống lại AI" hoặc nghĩ rằng AI không phải là một công cụ hữu ích vì họ đã nhảy ngay vào và nhận được "đầu vào rác, đầu ra rác". Hoặc có lẽ đã lâu rồi họ chưa sử dụng nó, phải không? Tôi nghĩ đến video về Will Smith ăn mì spaghetti khi nói đến các video AI – chúng ta đã tiến một chặng đường dài chỉ trong hai, ba, bốn năm qua. Điều tương tự cũng đúng với các mô hình ngôn ngữ lớn hỗ trợ lập trình, nhưng bạn phải làm những gì cần thiết để chúng có cơ hội tốt nhất đạt được kết quả tuyệt vời. Và điều đó trước tiên là phải hiểu rất rõ vấn đề và đảm bảo bạn và Tác nhân AI có thể hiểu rất rõ vấn đề. Sau đó, đặt ra các bước rõ ràng để thực hiện những thay đổi hoặc khắc phục vấn đề đó. Chỉ khi đó chúng ta mới chuyển sang giai đoạn triển khai nơi chúng ta viết mã. Dexhorthy có một câu nói tuyệt vời ở đây: "Một hướng nghiên cứu tồi tiềm ẩn hàng trăm dòng mã tồi". Vì vậy, chúng ta sẽ thực sự tập trung vào cách chúng ta có được nghiên cứu và kế hoạch phù hợp để mang lại cơ hội tốt nhất cho ra đời mã chất lượng.
Giai đoạn nghiên cứu (Ask Mode)
Trong giai đoạn đầu tiên đó, chúng ta sẽ sử dụng một công cụ chỉ tập trung vào nghiên cứu. Đối với Kilo, chúng tôi gọi đó là ask mode. Lý do chúng tôi gọi như vậy là vì ask mode thực sự không thể làm gì. Nó chỉ có thể trò chuyện. Nó không thể ghi file. Nó có thể đọc file nếu bạn cho phép. Nhưng nó không thể bắt đầu cố gắng tạo mã một giải pháp. Vì vậy, thay vì cố gắng tạo mã giải pháp ngay từ đầu, chúng ta sẽ cố gắng hiểu hệ thống trước. Nó thực sự hoạt động như thế nào ngày nay? Những file nào sẽ được liên quan? Những mô hình nào chúng ta muốn mô phỏng? Hoặc điều này khác với những gì chúng ta đã có như thế nào? Và bạn biết đấy, chỉ cần tìm hiểu xem trong codebase phần này sẽ được đặt ở đâu, và cách dữ liệu sẽ chảy qua hệ thống và cách nó sẽ thay đổi với sự thay đổi của chúng ta. Cũng như bất kỳ trường hợp ngoại lệ nào chúng ta cần xem xét, Tác nhân AI rất giỏi trong việc brainstorming. Vì vậy, nó có thể giúp bạn brainstorming những điều đó và đảm bảo bạn đã xem xét kỹ lưỡng mọi khía cạnh. Và sau khi bạn hoàn thành nghiên cứu đó, sản phẩm đầu ra sẽ là một tài liệu chi tiết về nghiên cứu đó. Để bạn có thể đọc và về cơ bản đồng ý và hiểu, "Ồ, điều này khớp với hiểu biết của tôi về vấn đề. Tôi nghĩ chúng ta đã sẵn sàng chuyển sang kế hoạch."
Giai đoạn lập kế hoạch
Và sau khi chúng ta đã xem xét tài liệu nghiên cứu với tư cách một con người. Bây giờ chúng ta có thể nói, "Được rồi, hãy vạch ra các bước tiếp theo." Những loại file nào chúng ta sẽ tạo hoặc thay đổi? Có thể có một số đoạn mã, nhưng không phải lúc nào cũng là ý hay khi có một đoạn mã trong kế hoạch. Vì vậy, chúng ta sẽ bao gồm cách chúng ta sẽ xác minh xem thay đổi này có đúng không. Những thay đổi hoặc bổ sung kiểm thử nào chúng ta sẽ thực hiện để biết điều đó. Và chúng ta cũng sẽ rất rõ ràng trong giai đoạn lập kế hoạch về những gì nằm trong và ngoài phạm vi. Những gì sẽ thay đổi. Những gì sẽ không thay đổi. Và một lần nữa, đầu ra của giai đoạn đó sẽ là một file kế hoạch rất rõ ràng. Bạn sẽ thấy rất nhiều kho lưu trữ GitHub ngày nay có một thư mục tên là "plans". Và chúng ta muốn file kế hoạch đó có các hướng dẫn từng bước, với những thay đổi cụ thể mà chúng ta sẽ thực hiện, có các lệnh kiểm thử để xác minh, có một chiến lược để hiểu cách nó sẽ thay đổi hệ thống. Và nó sẽ rất rõ ràng để chúng ta thậm chí có thể sử dụng một mô hình ngôn ngữ lớn nhỏ hơn, nhanh hơn hoặc rẻ hơn để triển khai nó, bởi vì chúng ta đã dành thời gian trong giai đoạn nghiên cứu và lập kế hoạch để thực sự hiểu những gì chúng ta sẽ làm khi đến lúc triển khai thay đổi.
Giai đoạn triển khai và sự giám sát của con người
Và khi chúng ta đến giai đoạn triển khai thay đổi, bây giờ chúng ta có thể bắt đầu một phiên mới và chỉ cung cấp cho nó việc thực hiện kế hoạch. Điều này cho phép chúng ta giữ cửa sổ ngữ cảnh trong phiên đó rất thấp. Nó cho phép chúng ta xem xét cẩn thận từng thay đổi và tôi nghĩ là commit rất thường xuyên. Bây giờ, tôi vẫn làm việc tại một công ty tên là GitLab trong nhiều năm, vì vậy có lẽ tôi hơi thiên vị git, nhưng tôi nghĩ git có thể là một trợ thủ đắc lực ở đây. Khi nói đến việc giúp bạn dần dần lặp lại và hiểu những thay đổi mà các Tác nhân đang thực hiện, tôi coi git trên máy cục bộ của mình giống như việc tự kiểm tra pull request đầu tiên với các Tác nhân của mình trước khi tôi có thể gửi một pull request thực sự cho đồng nghiệp của mình xem xét. Nhưng tôi nghĩ điều quan trọng là phải hiểu ở đây rằng thời gian của con người trong các giai đoạn lập kế hoạch và nghiên cứu thực sự là cách sử dụng thời gian có đòn bẩy cao nhất. Khi bạn đang triển khai, bạn muốn hoàn thành tất cả những suy nghĩ khó khăn đó. Và điều đó thực sự quan trọng bởi vì một lần nữa, quay trở lại Dexhorthy, người đã nói rất nhiều về chủ đề này và tôi đặc biệt khuyên bạn nên xem các video của anh ấy trên YouTube nói về điều này. Anh ấy nói rất đúng rằng AI không thể thay thế việc suy nghĩ, nó chỉ có thể khuếch đại suy nghĩ bạn đã thực hiện hoặc sự thiếu suy nghĩ mà bạn chưa thực hiện hoặc thực tế là bạn chưa suy nghĩ kỹ.
Cấu hình Tác nhân: Chế độ, quy tắc và tự động hóa
Vì vậy, hãy nói về cách chúng ta cấu hình các Tác nhân của mình, giống như một bước nữa để từ mô hình nghiên cứu, lập kế hoạch, triển khai để thực sự đảm bảo chúng ta làm được điều này.
Đầu tiên, chúng ta đã nói về các chế độ và tùy chỉnh. Chúng ta đã nói về các chế độ này như ask, code, architect – các chế độ được chuyên biệt hóa và tập trung vào điều chúng ta đang cố gắng hoàn thành, phải không? Architect có thể là để lập kế hoạch, ask mode là để nghiên cứu, code mode là để thực sự triển khai.
Sau đó, chúng ta cũng muốn có một bộ quy tắc có ý nghĩa cho không gian làm việc của chúng ta, phải không? Đối với kho lưu trữ GitHub chúng ta đang ở. Hoặc có thể là trên toàn cầu trên máy của chúng ta để chúng ta hiểu rằng chúng ta có một bộ quy tắc nhất định mà chúng ta luôn muốn tuân thủ. Và các Tác nhân khá giỏi trong việc tải và hiểu những quy tắc đó. Nhưng chúng ta phải viết chúng ra để chúng có những quy tắc đó trong cửa sổ ngữ cảnh của chúng.
Và tôi nghĩ rằng nhiều hành vi của Tác nhân sau đó là những điều chúng ta muốn điều chỉnh khi chúng ta học hỏi, phải không? Chúng ta có muốn làm việc với nhiều Tác nhân cùng lúc không? Chúng ta có muốn các Tác nhân đó sử dụng worktrees để chúng ta có thể hợp nhất chúng trở lại vào kho lưu trữ GitHub cục bộ của chúng ta trước khi commit chúng vào một pull request không? Chúng ta muốn tự động phê duyệt đến mức nào? Hầu hết các Tác nhân đều có khả năng điều chỉnh những gì chúng có thể làm độc lập, những công cụ nào chúng có thể sử dụng độc lập, liệu chúng có thể đọc file, ghi file bên trong hay bên ngoài không gian làm việc. Liệu chúng có thể chạy kiểm thử không? Tác nhân có thể làm gì một cách tự chủ mà không cần sự can thiệp của bạn so với những gì bạn cần phê duyệt. Và tôi nghĩ đây là điều bạn phải thiết lập để cảm thấy thoải mái ngay từ đầu và sau đó bạn cũng cần phải thoải mái thay đổi khi bạn học cách sử dụng những công cụ này.
Các loại cấu hình Tác nhân: Chế độ, Agents.md và Skills.md
Và tôi nghĩ một mô hình tinh thần tốt cho cấu hình Tác nhân này có thể là ba nhóm riêng biệt, phải không? Chúng ta đã nói về các chế độ, đây là cấu hình dựa trên vai trò đó, hành vi của một Tác nhân mà chúng ta muốn. Nhưng có hai điều quan trọng khác, đó là agents.md và sau đó là skills.md mà bạn nghe nói đến. Vậy chúng là gì, sự khác biệt giữa hai cái này là gì? Agents.md đang nhanh chóng trở thành tiêu chuẩn de facto cho nơi tất cả các Tác nhân tìm đến, giống như README của chúng, cho các quy tắc luôn bật và chi tiết về dự án. Vì vậy, tôi nghĩ điều quan trọng là dự án của bạn phải có một agents.md với lượng thông tin tối thiểu mà một Tác nhân cần biết về các quy ước chúng ta đang sử dụng, các lệnh chúng ta đang sử dụng để xây dựng hoặc kiểm thử, và các yêu cầu xung quanh việc kiểm thử. Hoặc các yêu cầu mà chúng ta cần đảm bảo kiểm tra trước khi commit.
Và sau đó skills (kỹ năng) là một quy trình làm việc cụ thể hơn. Có những playbooks có thể tái sử dụng cho các Tác nhân. Vì vậy, nếu có điều gì đó bạn làm thường xuyên, bạn tạo đồ họa chuyển động thường xuyên, hoặc bạn đang thực hiện một loại change log hàng ngày, hàng tuần hoặc hàng tháng nào đó, biên soạn những thứ đó. Những loại công việc đó rất tốt để đặt vào skills mà một Tác nhân có thể sử dụng khi cần để thực hiện các quy trình làm việc cụ thể đó. Và vì vậy, thông thường, những thứ đó là theo yêu cầu và bạn nói, "Này, hãy sử dụng kỹ năng này cho nhiệm vụ này," trong khi agents.md hầu như luôn được tải vào cửa sổ ngữ cảnh cho Tác nhân để nó biết điều gì đang diễn ra.
Mẹo cho người dùng nâng cao và vượt ra ngoài IDE
Và sau đó, tất nhiên, tôi làm việc tại Kilo Code, vì vậy tôi có một số mẹo cho người dùng nâng cao ở đó, nhưng tôi nghĩ một số trong số này, nhiều trong số này, áp dụng cho bất kể Tác nhân nào bạn đang sử dụng, nhưng tôi nghĩ chúng rất quan trọng khi bạn bắt đầu cảm thấy thoải mái với những mô hình ban đầu đó. Làm thế nào để tôi tùy chỉnh điều này và làm cho nó phù hợp với mình?
Một là @mentioning (đề cập) để có ngữ cảnh. Vì vậy, đề cập các file hoặc commit hoặc những thứ từ terminal xuất ra. Những thứ đó và đưa chúng vào ngữ cảnh một cách nhanh chóng thực sự hữu ích khi sử dụng các lệnh / để làm những việc như bắt đầu một nhiệm vụ mới khi chúng ta cần hoặc nén ngữ cảnh khi nó trở nên quá đầy. Những lệnh nhanh đó có thể giúp chúng ta di chuyển nhanh hơn nhiều.
Chúng tôi cũng đang làm việc trong VS Code với Kilo Code, chúng ta có thể chọn một phần mã và nhấp chuột phải và nói "thêm vào Kilo Code", và sau đó ngữ cảnh đó được đưa thẳng vào đó và tôi có thể nói chuyện hoặc hỏi các câu hỏi về phần mã đó hoặc yêu cầu Tác nhân thay đổi một phần cụ thể của mã đó. Và sau đó, tất nhiên, chúng tôi cũng có tính năng tự động hoàn thành được tích hợp sẵn, mà tôi nghĩ vẫn hữu ích, đặc biệt là vì chúng tôi có nó không chỉ trong mã mà còn khi bạn đang lời nhắc.
Và sau đó, vượt ra ngoài IDE, tôi nghĩ chúng ta cũng đang thấy sự thay đổi trong năm nay về việc tôi muốn có thể sử dụng cái này ở đâu khác: trong CLI, từ điện thoại di động của tôi, trong một Tác nhân đám mây trực tiếp trong Slack. Khả năng sử dụng những Tác nhân này ở bất cứ đâu bạn đang ở là điều đang trở nên được mong đợi nhiều hơn từ mọi người và các Tác nhân của mọi người, và tôi nghĩ đó là một điều tốt. Tôi nghĩ điều đó có nghĩa là chúng ta đang bắt đầu học cách chúng ta có thể sử dụng những Tác nhân này một lần nữa giống như một cộng tác viên có mặt ở khắp mọi nơi chúng ta cần.
Giao thức ngữ cảnh mô hình (MCP)
Và một điều nữa tôi muốn nói đến là việc đưa các ngữ cảnh khác vào. Trước hết, Giao thức ngữ cảnh mô hình (Model Context Protocol - MCP). Ngữ cảnh nằm ngay trong tên. Ý tưởng của điều này là về cơ bản các mô hình này ban đầu chỉ có thể nhận mã thông báo đầu vào và tạo mã thông báo đầu ra. Dần dần, chúng ta đã cho phép chúng sử dụng công cụ nơi chúng có thể thực hiện gọi công cụ và tác động đến mọi thứ trong môi trường như chạy kiểm thử.
Khái niệm MCP về cơ bản mở rộng điều này để nói rằng, "Này, tôi muốn cung cấp cho Tác nhân những công cụ khác." Chẳng hạn, GitHub MCP cung cấp cho Tác nhân rất nhiều công cụ để tương tác với GitHub API, tra cứu các pull request, tra cứu các bình luận, tra cứu các issue và hiểu nhiều hơn về môi trường GitHub của bạn. Hoặc Context Seven giúp nó tìm kiếm tài liệu framework cập nhật, bởi vì tất nhiên, như bạn đã biết, các Mô hình Ngôn ngữ Lớn có một ngày cắt giảm kiến thức, và sau đó bất cứ điều gì được cải thiện kể từ đó, chúng không biết. Vì vậy, các máy chủ MCP này có thể rất hữu ích và có hàng ngàn trong số đó.
Tối ưu hóa System Prompt và Quản lý Công cụ
Tuy nhiên, mối lo ngại là mỗi công cụ sẽ thêm ít nhất một số thông tin (chi tiết về các công cụ mà nó có) vào lời nhắc hệ thống được gửi đi mỗi khi bạn tương tác với một Tác nhân. Vì vậy, bạn muốn đảm bảo rằng nếu không thực sự sử dụng công cụ đó, hãy tắt nó đi. Chẳng hạn, tôi có một MCP của Postgres kết nối với cơ sở dữ liệu của mình, và tôi đang thực hiện rất nhiều công việc giao diện người dùng mà không liên quan gì đến cơ sở dữ liệu. Khi đó, MCP của Postgres đó sẽ chỉ lãng phí mã thông báo, và tệ hơn nữa, có thể là những mã thông báo gây nhầm lẫn cho Tác nhân và khiến nó không hiểu rằng nó không được phép truy cập cơ sở dữ liệu tại thời điểm đó. Vì vậy, chúng ta cần rất cẩn thận để không lạm dụng MCP.
Tích hợp API nội bộ
Một vấn đề khác mà chúng tôi thường nghe từ các doanh nghiệp là làm thế nào để làm việc với các Giao diện lập trình ứng dụng (API) của nền tảng nội bộ. Tôi nghĩ có bốn cách khác nhau để thực hiện điều này. Thứ nhất: nếu đã có một OpenAPI spec hoặc Swagger spec cho API đó, hãy sử dụng nó. Nếu chưa có, hãy chuyển đổi nó sang định dạng Markdown để bạn có thể lưu trữ Markdown đó trong agents.md hoặc một nơi nào đó khác trong kho lưu trữ GitHub repo để tham chiếu. Nếu đó là một thứ thay đổi thường xuyên hơn một chút, có thể bạn cần một URL tham chiếu để có thể kéo dữ liệu vào và để Tác nhân tự động lấy thông tin mới nhất mỗi lần. Và chúng tôi cũng đã thấy một số khách hàng có các quy trình làm việc phức tạp gồm nhiều bước, nhiều hệ thống, trong đó việc xây dựng máy chủ MCP của riêng họ có thể là lựa chọn đúng đắn.
Cách làm việc với Tác nhân và Kilo
Tuy nhiên, dù bằng cách nào đi nữa, tôi nghĩ điều cốt lõi là khi làm việc cùng với Kilo hoặc bất kỳ Tác nhân nào trong số này, hãy môi trường cô lập công việc của bạn khỏi công việc của Tác nhân, sau đó xem xét công việc của Tác nhân đó dưới dạng một pull request, đúng không? Điều đó giúp bạn hiểu rõ... Và sau đó, chúng ta có thể xem xét mã code tốt nhất giống như cách tôi xem xét mã của một kỹ sư mới vào nghề.
Các tính năng mới của Kilo và Tác nhân OpenClaw
Và đó là phần trình bày của tôi về Kilo. Chúng tôi có một số tính năng mới thú vị sắp ra mắt, được mở rộng trên tất cả các bề mặt. Chúng tôi cũng đặc biệt chú trọng vào OpenClaw và KiloClaw để tạo ra một cách rất an toàn khi sử dụng các Tác nhân OpenClaw. Và để tìm hiểu thêm về Kilo, tôi xin giới thiệu ở cuối đây: hãy truy cập kilo.ai và chúng tôi rất mong nhận được phản hồi của bạn về những gì chúng tôi đang xây dựng.
Tư duy làm việc với Mô hình ngôn ngữ lớn và tương lai
Và, để cho bạn thấy chúng ta sẽ đi đến đâu từ đây. Tôi nghĩ bạn phải chọn một công cụ và thực hành thật nhiều. Chúng tôi đã nói từ trước rằng đây vừa là nghệ thuật vừa là khoa học. Và tôi nghĩ điều đó có nghĩa là bạn cần thực hành rất nhiều để có thể cảm nhận được những gì tôi có thể tin tưởng các Mô hình ngôn ngữ lớn làm được và những gì tôi không thể tin tưởng chúng làm được. Sau đó, hãy thử quy trình này: nghiên cứu, lập kế hoạch, triển khai, vòng lặp phản hồi (feedback loop), xem nó hiệu quả với bạn như thế nào. Và tôi nghĩ có thể bạn sẽ giống như một số kỹ sư cấp cao khác đã nói: "Này, nhìn xem, tôi đang lập trình vui hơn bao giờ hết trong nhiều năm qua, khi chúng ta giao một số công việc tẻ nhạt này cho các Tác nhân và để bộ não của chúng ta giải quyết các vấn đề kỹ thuật khó hơn."
TL;DR
- Kỹ thuật tác nhân (Agentic Engineering) là sự thay đổi tư duy từ việc sử dụng AI như một công cụ đơn thuần sang làm việc với nó như một cộng tác viên, đặc biệt là một lập trình viên cấp dưới rất nhanh nhưng thiếu óc phán đoán.
- Hiệu quả của việc làm việc với AI phụ thuộc vào "Kỹ thuật ngữ cảnh" – nghệ thuật và khoa học quản lý thông tin bạn cung cấp cho AI, vì ngữ cảnh không phù hợp hoặc quá nhiều có thể làm giảm chất lượng và tăng chi phí.
- Áp dụng vòng lặp "Nghiên cứu - Lập kế hoạch - Triển khai" là cần thiết để tận dụng tối đa AI, tập trung vào việc hiểu rõ vấn đề và lập kế hoạch chi tiết trước khi để AI tạo mã, tránh việc nhảy vội vào triển khai gây ra lỗi và lãng phí thời gian.
Điểm chính
- Thay đổi mô hình tư duy: Coi AI agent như một "lập trình viên cấp dưới" năng động, thông thái nhưng thiếu óc phán đoán và ngữ cảnh kinh doanh, đòi hỏi sự hướng dẫn rõ ràng từ con người.
- Quản lý ngữ cảnh chủ động: Ngữ cảnh (context) là đắt đỏ và không phải lúc nào nhiều cũng tốt hơn; vượt quá giới hạn nhất định có thể làm giảm chất lượng đầu ra ("vùng ngu ngốc").
- Lựa chọn ngữ cảnh có chọn lọc: Duy trì thông tin không trực tiếp liên quan (scratch pad, memory files) bên ngoài cửa sổ ngữ cảnh và chỉ đưa vào những gì thật sự cần thiết cho từng bước giải quyết vấn đề cụ thể.
- Cô lập và nén ngữ cảnh: Bắt đầu phiên làm việc mới khi cần thay đổi hướng hoặc khi ngữ cảnh trở nên quá lớn, hoặc sử dụng các tác nhân song song để chia nhỏ công việc và tránh tích tụ ngữ cảnh xấu. Yêu cầu AI tóm tắt phiên làm việc để tái sử dụng ngữ cảnh cô đọng.
- Tuân thủ vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai (RPI):
- Nghiên cứu (
Ask Mode): Tập trung vào việc hiểu hệ thống, xác định các tệp liên quan, mô hình cần mô phỏng, và các trường hợp ngoại lệ. Sản phẩm đầu ra là tài liệu nghiên cứu chi tiết. - Lập kế hoạch: Vạch ra các bước cụ thể, tệp cần thay đổi, cách xác minh và phạm vi công việc. Sản phẩm đầu ra là một tài liệu kế hoạch rõ ràng, từng bước.
- Triển khai: Chỉ thực hiện giai đoạn này sau khi nghiên cứu và lập kế hoạch kỹ lưỡng. Bắt đầu một phiên mới với ngữ cảnh thấp và cam kết thay đổi thường xuyên.
- Nghiên cứu (
- Tránh vội vàng tạo mã: Đừng yêu cầu AI trực tiếp "triển khai tính năng này" ngay từ đầu. Phương pháp này thường dẫn đến các giả định sai lầm, lãng phí thời gian và tạo ra mã chất lượng kém.
- Giám sát chặt chẽ cửa sổ ngữ cảnh: Luôn để ý đến "đồng hồ ngữ cảnh" của AI. Nếu cảm thấy mọi thứ đang chệch hướng, hãy bắt đầu một phiên mới và yêu cầu AI tóm tắt trạng thái hiện tại để tái khởi động với ngữ cảnh sạch và phù hợp.
Từ vựng
- Kỹ thuật tác nhân — Agentic Engineering
- Luồng công việc — Workflow
- Tạo mã — Code Generation
- Mô hình — Model (AI) / Paradigm (mindset)
- Tác nhân AI — AI Agent
- Tác vụ — Task
- Lập trình viên cấp dưới — Junior Engineer
- Ngữ cảnh — Context
- Kỹ thuật ngữ cảnh — Context Engineering
- Mã thông báo — Token
- Cửa sổ ngữ cảnh — Context Window
- Lời nhắc — Prompt
- Mô hình ngôn ngữ lớn (LLM) — Large Language Model (LLM)
- Vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai — Research-Plan-Implement (RPI) loop
- Chế độ hỏi — Ask Mode
Nội dung chi tiết
Giới thiệu về Kỹ thuật Tác nhân (Agentic Engineering)
Hãy cùng bàn một chút về ý nghĩa của kỹ thuật tác nhân (agentic engineering). Chúng ta hãy bắt đầu bằng một câu hỏi: Nếu tôi hỏi bạn ngay bây giờ, bạn đang sử dụng AI trong công việc của mình như thế nào? Bạn có thực sự giải thích được không? Không chỉ đơn giản là "nó giúp tôi tạo mã nhanh hơn" hay "nó có thể viết mã rất nhanh", mà là luồng công việc thực tế: bạn giao phó những gì, bạn giữ lại những gì, và bạn quyết định như thế nào giữa các công việc. Hầu hết các kỹ sư không thể làm vậy, và điều đó khá lạ đối với tôi, bởi vì 90% kỹ sư đã và đang sử dụng công cụ AI. Có thể chỉ một nửa trong số họ sử dụng thường xuyên, nhưng con số đó chắc chắn đang tăng lên. Đó là tình hình hiện tại.
Vậy câu hỏi không phải là liệu nhóm của bạn có sử dụng AI hay không – họ đang sử dụng. Câu hỏi là liệu bạn có tận dụng tối đa nó hay chỉ đang tự động hoàn thành công việc cả ngày. Khoảng cách giữa việc sử dụng AI và khả năng diễn đạt cách bạn làm việc với nó – đó chính là nội dung của bài nói chuyện này. Và thực sự, tôi nghĩ nó đại diện cho một mô hình thay đổi trong cách chúng ta nghĩ về AI.
Lịch sử và Sự Chuyển Đổi của AI trong Kỹ thuật Phần Mềm
Lịch sử AI và kỹ thuật phần mềm đang phát triển rất nhanh, và cũng đáng ngạc nhiên là khá ngắn ngủi. Đầu những năm 2020, chúng ta có các công cụ có thể hoàn thành các dòng mã cho bạn. Bạn gõ nửa chữ ký của một hàm và mô hình sẽ đoán phần còn lại, giống như một tự động hoàn thành được nâng cấp mạnh mẽ. Đó là một mẹo hay.
Và rồi vào năm 2022, các mô hình bắt đầu có khả năng gợi ý toàn bộ hàm. Bạn có thể mô tả những gì bạn muốn, trò chuyện với một mô hình, và có thể nhận lại một bản triển khai hoạt động được. Đây là lúc GitHub Copilot lần đầu tiên xuất hiện và tạo ra đột phá. Hàng triệu nhà phát triển bắt đầu sử dụng nó, và lần đầu tiên, có vẻ như AI không còn là một điều mới lạ, mà có thể thực sự hữu ích.
Nhưng rồi vào năm 2025, một điều thực sự đột phá đã xảy ra. Cái mà chúng ta đang sống trong năm 2026 này, các mô hình không chỉ gợi ý, chúng còn có thể thực thi. Chúng có thể nhận một tác vụ và chia nhỏ nó, tìm ra tệp nào cần chỉnh sửa, thực hiện thay đổi, tự chạy kiểm thử, và sau đó đưa ra một pull request thực sự. Điều đó không chỉ là tự động hoàn thành cao cấp, không chỉ là một con ngựa nhanh hơn. Đó là một cộng tác viên. Đó là một cách làm việc khác.
Armand, người tạo ra Flask (dành cho những người dùng Python ở đây), đã nói một cách hoàn hảo: "Chúng ta không còn chỉ sử dụng máy móc, chúng ta đang làm việc với chúng." Cách diễn đạt này, tôi nghĩ, nắm bắt được sự thay đổi thực sự này. Công cụ là những thứ bạn cầm lên và đặt xuống. Bạn dùng một cái búa, bạn không làm việc với một cái búa. Nhưng các Tác nhân AI (AI agent) tạo mã mà chúng ta có ngày nay, chúng ở đâu đó giữa hai thái cực đó. Và có lẽ chúng giống như làm việc với một kỹ sư khác. Chỉ là kỹ sư này đã đọc mọi câu trả lời trên Stack Overflow từng được viết.
Mô hình Tư duy Mới: Xem AI như một Lập trình viên Cấp dưới
Tôi nghĩ điều này đòi hỏi một sự thay đổi trong mô hình tư duy. Và đây là mô hình tư duy mà tôi muốn bạn mang theo trong suốt phần còn lại của video này, và thành thật mà nói, trong vài năm tiếp theo của sự nghiệp bạn khi làm việc với các công cụ này. Tôi vẫn nghĩ chúng là công cụ, nhưng chúng ta phải nghĩ về chúng một cách khác.
Bạn có thể phải coi Tác nhân AI của mình như một lập trình viên cấp dưới năng động, nhiệt tình, đọc rất nhiều, và thường tự tin sai. Lập trình viên cấp dưới này cực kỳ nhanh, không dễ mệt mỏi, không có cái tôi về mã của mình – họ sẽ vui vẻ viết lại thứ gì đó sáu lần nếu bạn yêu cầu. Và họ có một kiến thức đáng kinh ngạc: họ đã thấy rất nhiều ngôn ngữ, rất nhiều khung làm việc, rất nhiều mô hình.
Nhưng, và đây là điều quan trọng, cái mà họ không có là óc phán đoán. Họ không biết ngữ cảnh kinh doanh của bạn. Họ không hiểu lý do tại sao bạn đưa ra quyết định kiến trúc rất cụ thể đó ba tháng trước. Và họ sẽ tự tin viết mã đúng về mặt kỹ thuật nhưng sai về mặt ngữ cảnh. Armand cũng nói rằng anh ấy đã tiết kiệm hơn 30% thời gian trong ngày vì máy móc đang làm rất nhiều công việc. Đó là một lợi ích thực sự. Nhưng anh ấy đạt được 30% đó vì anh ấy biết mình có thể giao phó những gì và phải giữ lại những gì cho bản thân. Anh ấy không chỉ mù quáng chấp nhận mọi gợi ý. Anh ấy đang hướng dẫn công việc. Và đó là sự khác biệt giữa việc sử dụng AI và làm việc với AI. Đó chính là ý nghĩa thực sự của kỹ thuật tác nhân.
Kỹ thuật Ngữ cảnh (Context Engineering)
Vậy thì hãy đi vào thực tế. Nếu bạn là một kỹ sư, làm thế nào để chúng ta thực sự làm tốt điều này? Tôi nghĩ điều số một cần suy nghĩ là kỹ thuật ngữ cảnh. Karpathy nói rằng kỹ thuật ngữ cảnh là "một nghệ thuật và khoa học tinh tế trong việc điền cửa sổ ngữ cảnh với chính xác những gì cần thiết để Tác nhân có ngữ cảnh phù hợp cho lần lặp phù hợp cho bước tiếp theo."
Tôi nghĩ điều đó thực sự quan trọng vì một vài lý do.
Thứ nhất, ngữ cảnh rất đắt đỏ. Mỗi mã thông báo (token) bạn thêm vào ngữ cảnh sẽ làm tăng chi phí vì tất cả lịch sử trò chuyện đó được gửi lại dưới dạng mã thông báo đầu vào mỗi khi bạn gửi. Và điều đó có thể tăng lên khá nhanh.
Và điều quan trọng khác là nhiều ngữ cảnh hơn không phải lúc nào cũng có nghĩa là kết quả tốt hơn. Trên thực tế, nó có thể làm cho mô hình thực sự "ngu ngốc hơn". Đúng vậy, không chỉ là vấn đề tiền bạc. Chất lượng bắt đầu giảm sút khi bạn vượt quá khoảng 50% cửa sổ ngữ cảnh. Có rất nhiều điều có thể khiến bạn mắc bẫy ở đây, trong đó có cả việc máy chủ MCP trở nên phổ biến đến mức chúng ta bật rất nhiều tính năng này mọi lúc. Mỗi tính năng đó tải thêm và thêm ngữ cảnh, tức là thêm và thêm mã thông báo đầu vào vào ngữ cảnh. Và đó có thể là một vấn đề thực sự nếu bạn bắt đầu đi vào "vùng ngu ngốc" (dumb zone) này ở khoảng 50% ngữ cảnh.
Và đó cũng không phải là vấn đề duy nhất, bởi vì không chỉ nhiều ngữ cảnh hơn có thể là một vấn đề, mà ngữ cảnh xấu cũng có thể là một vấn đề và có thể đầu độc mọi thứ. Đúng vậy, điều này xảy ra khi bạn có thể đang trộn lẫn hai tác vụ khác nhau không thực sự chồng chéo, hoặc bạn có một số nhận xét lỗi thời trong mã hoặc bạn đã thực hiện nó như một Tác nhân. Hoặc tệ hơn nữa, điều tôi đã thấy nhiều người làm là họ bắt đầu đi theo một hướng với một Tác nhân và sau đó nhận ra rằng, "này, chúng ta đã đi sai đường, chúng ta đã đưa ra rất nhiều quyết định sai lầm," và họ cố gắng điều chỉnh Tác nhân quay lại. Nhưng vấn đề là, một lần nữa, Tác nhân không thực hiện suy luận thực sự như bạn và tôi với tư cách là một con người. Đúng vậy, nó lấy tất cả ngữ cảnh đó mỗi lần. Và nó có thể bị lạc ở giữa hoặc thậm chí xem một số điều tiêu cực mà bạn đã có trước đây như vẫn là một phần của ngữ cảnh. Và bạn sẽ thấy những mô hình tiêu cực đó len lỏi trở lại nếu bạn không cẩn thận. Đó là lý do tại sao tốt hơn là không để những điều này tích tụ. Nhưng cũng nên, bạn biết đấy, luôn bắt đầu một phiên mới khi bạn nhận ra mọi thứ đang đi chệch đường ray. Đúng vậy, bởi vì ngữ cảnh không chỉ đắt đỏ. Càng có nhiều ngữ cảnh không phải lúc nào cũng có nghĩa là chất lượng tốt hơn. Trên thực tế, tại một điểm nhất định, có một điểm giới hạn mà nó có nghĩa là chất lượng tệ hơn. Và ngữ cảnh xấu có thể làm hỏng đầu ra.
Vì vậy, điều thực sự quan trọng đối với các kỹ sư là quản lý ngữ cảnh. Và điều đó có nghĩa là gì?
Quản lý Ngữ cảnh Hiệu quả
Thứ nhất, tôi nghĩ điều đó có nghĩa là duy trì rất nhiều thông tin bên ngoài cửa sổ ngữ cảnh để chúng ta có thể đưa nó vào. Đúng vậy, đây là những thứ như scratch pad cho những gì chúng ta đang làm, tệp bộ nhớ, tệp MD của Tác nhân, những loại tệp giúp các Tác nhân có ngữ cảnh về những gì bạn đang làm.
Chúng ta cũng cần rất có chọn lọc khi chọn ngữ cảnh đó. Điều đó có nghĩa là chỉ lấy những gì liên quan cho bước giải quyết vấn đề này. Đúng vậy, đừng chỉ đưa vào mọi thứ có thể hữu ích. Và điều đó có thể có nghĩa là, bạn biết đấy, đưa vào các thẻ nhắc (at mentions) phù hợp cho các tệp mà chúng ta đang tham chiếu, điều đó có thể có nghĩa là đảm bảo chúng ta không bật các máy chủ MCP không cần thiết. Và điều đó có nghĩa là, bạn biết đấy, đảm bảo rằng Tác nhân có dữ liệu phù hợp và chúng ta, với tư cách là con người, đã tuyển chọn dữ liệu đó cho Tác nhân.
Và sau đó, khi nó ngày càng lớn hơn và cửa sổ đó ngày càng lớn hơn, chúng ta muốn tóm tắt, cắt giảm và nén ngữ cảnh đó. Đúng vậy, nếu chúng ta đã trải qua một phiên gỡ lỗi và nghiên cứu sâu toàn diện với Tác nhân và bây giờ chúng ta nghĩ rằng mình đã có vấn đề và giải pháp, thì điều đó thật tuyệt vời. Có thể đã đến lúc nén ngữ cảnh đó và chỉ tập trung lại Tác nhân vào việc "được rồi, bây giờ chúng ta hiểu vấn đề này. Chúng ta sẽ đi khắc phục nó."
Và sau đó, điều quan trọng nhất khác là cô lập ngữ cảnh (isolate context). Và tôi nghĩ đây là lý do tại sao chúng ta thấy sự gia tăng lớn trong sáu hoặc tám tháng qua của các Tác nhân song song (parallel agents), bởi vì chia nhỏ công việc giữa nhiều Tác nhân hoặc nhiều phiên có thể giúp mọi thứ không tích tụ và thực sự thúc đẩy loại phân tách tác vụ này.
Và một lần nữa, nếu bạn nghĩ về nó, không phải tất cả những điều này đều là những điều mà tôi sẽ nói với một quản lý kỹ thuật mới về việc quản lý một kỹ sư cấp dưới (junior engineer) sao? Câu chuyện tôi kể ở đây là khi tôi mới bắt đầu sự nghiệp, tôi đã dành rất nhiều thời gian làm quản lý kỹ thuật và quản lý sản phẩm trước khi tôi bước vào nghệ thuật đen tối của quan hệ nhà phát triển. Và trong công việc đầu tiên của tôi với tư cách là quản lý kỹ thuật, tôi làm việc tại một công ty phần mềm chăm sóc sức khỏe. Và có một điều mới sắp ra mắt gọi là iPad – điều đó cho thấy tôi đã lớn tuổi một chút. Nhưng nó được phát hành trên thị trường và chúng tôi nghĩ đây có thể là một nơi tuyệt vời để thu thập lịch sử bệnh án. Bạn biết đấy, đối với tôi, tôi phải điền vào mỗi năm tại bác sĩ. Nó rất quan trọng để đánh giá nhiều nguy cơ bệnh tật của bạn. Nhưng việc phải điền từ đầu mỗi lần thì không vui chút nào.
Và vì vậy tôi đã thiết kế trong một công cụ lỗi thời khác mà một số người có thể đã nghe nói đến tên là Balsamiq – về cơ bản là một công cụ tạo wireframe – một wireframe về giao diện sẽ như thế nào. Công cụ tạo wireframe đó đã sử dụng những thứ như Comic Sans và các biểu tượng mặt cười ngớ ngẩn làm chỗ giữ chỗ. Và rất nhiều thứ khác như vậy mà bạn mong đợi từ một wireframe. Và tôi đã giao nó cho một nhóm thực tập sinh mà chúng tôi có làm việc cho chúng tôi vào mùa hè năm đó, nghĩ rằng đây là một dự án mới tuyệt vời để họ dành thời gian vào. Và bạn biết đấy, vài tuần sau, tôi nhận lại một nguyên mẫu hoạt động được. Và phông chữ là Comic Sans và có các biểu tượng emoji ngớ ngẩn. Và đó là vì đó là những gì đặc tả có. Vậy lỗi của ai? Rõ ràng đó không phải là lỗi của thực tập sinh. Đó là lỗi của tôi với tư cách là quản lý kỹ thuật vì đã không cung cấp ngữ cảnh phù hợp cho những kỹ sư cấp dưới đó về điều gì là quan trọng, điều gì không, và chúng ta thực sự cần tập trung vào điều gì và vấn đề chúng ta đang giải quyết là gì.
Thói quen Hiệu quả khi Làm việc với AI
Vì vậy, tôi nghĩ các thói quen có thể kết nối tất cả những điều đó lại với nhau là: bạn không cần phải suy nghĩ về cả bốn điều đó cho mỗi tác vụ. Bạn chỉ cần nghĩ về việc thực hiện một tác vụ cho mỗi phiên.
Hãy để mắt đến đồng hồ ngữ cảnh của bạn. Và nếu bạn nghi ngờ và cảm thấy mọi thứ đang chệch hướng, bạn có lẽ đã đúng. Vì vậy, bắt đầu một phiên mới, yêu cầu Tác nhân đó tóm tắt phiên cho một Tác nhân mới. Hóa ra, AI thực sự rất giỏi trong việc viết lời nhắc (prompt) cho AI. Vì vậy, nếu bạn đã làm việc với một Tác nhân trong một thời gian, hãy yêu cầu Tác nhân đó tóm tắt trạng thái hiện tại của bạn. Bây giờ bạn có thể đọc nó, đảm bảo nó khớp với sự hiểu biết của bạn và sau đó bắt đầu một phiên mới với chính ngữ cảnh phù hợp đó. Một chút nghệ thuật và một chút khoa học.
Vòng lặp Nghiên cứu - Lập kế hoạch - Triển khai
Vậy làm thế nào để chúng ta đưa điều này vào thực tế? Chà, tôi nghĩ có rất nhiều luồng công việc. Có rất nhiều thứ đã được viết ra mà bạn có thể đọc. Tôi thậm chí đã tập hợp rất nhiều trong số đó tại path.kilo.ai. Đó là nơi bạn có thể tìm thấy tất cả các loại xu hướng, ý tưởng và mô hình luồng công việc đã được thảo luận. Nhưng điều tôi luôn quay trở lại là một trong những điều đơn giản hơn. Và đó là vòng lặp "nghiên cứu, lập kế hoạch, triển khai" (research plan implement loop).
Và tôi nghĩ điều này thực sự giúp chúng ta giải quyết rất nhiều sai lầm cổ điển mà mọi người mắc phải khi lần đầu tiên bắt đầu kỹ thuật tác nhân hoặc sử dụng AI để giúp họ thực hiện một số công việc kỹ thuật. Và điều mà hầu hết mọi người làm là nói, "này, giúp tôi triển khai tính năng này. Tôi muốn nó làm X và Y." Và bạn biết đấy, các Mô hình ngôn ngữ lớn (LLM) rất giỏi trong việc tạo ra rất nhiều mã.
Sai lầm khi vội vàng tạo mã
Thực tế, khi tôi gia nhập Kilo Code hơn một năm trước, tôi đã tuyên bố rằng trang web của chúng tôi sẽ không bao giờ chỉ là một lời nhắc và hàng loạt mã chạy vèo vèo. Điều đó tạo ra một bản demo tuyệt vời, và bạn đã thấy rất nhiều Tác nhân lập trình thể hiện khả năng của chúng theo cách đó. Nhưng tôi nghĩ rằng việc nhảy thẳng vào mã như vậy có thể gây ra nhiều giả định sai lầm. Nó có thể lãng phí nhiều thời gian hơn là tiết kiệm thời gian và chỉ tạo ra sự thất vọng. Nó thực sự tạo ra một mô hình mà chúng ta đã thấy, nơi mọi người có vẻ như "chống lại AI" hoặc nghĩ rằng AI không phải là một công cụ hữu ích vì họ đã nhảy ngay vào và nhận được "đầu vào rác, đầu ra rác". Hoặc có lẽ đã lâu rồi họ chưa sử dụng nó, phải không? Tôi nghĩ đến video về Will Smith ăn mì spaghetti khi nói đến các video AI – chúng ta đã tiến một chặng đường dài chỉ trong hai, ba, bốn năm qua. Điều tương tự cũng đúng với các mô hình ngôn ngữ lớn hỗ trợ lập trình, nhưng bạn phải làm những gì cần thiết để chúng có cơ hội tốt nhất đạt được kết quả tuyệt vời. Và điều đó trước tiên là phải hiểu rất rõ vấn đề và đảm bảo bạn và Tác nhân AI có thể hiểu rất rõ vấn đề. Sau đó, đặt ra các bước rõ ràng để thực hiện những thay đổi hoặc khắc phục vấn đề đó. Chỉ khi đó chúng ta mới chuyển sang giai đoạn triển khai nơi chúng ta viết mã. Dexhorthy có một câu nói tuyệt vời ở đây: "Một hướng nghiên cứu tồi tiềm ẩn hàng trăm dòng mã tồi". Vì vậy, chúng ta sẽ thực sự tập trung vào cách chúng ta có được nghiên cứu và kế hoạch phù hợp để mang lại cơ hội tốt nhất cho ra đời mã chất lượng.
Giai đoạn nghiên cứu (Ask Mode)
Trong giai đoạn đầu tiên đó, chúng ta sẽ sử dụng một công cụ chỉ tập trung vào nghiên cứu. Đối với Kilo, chúng tôi gọi đó là ask mode. Lý do chúng tôi gọi như vậy là vì ask mode thực sự không thể làm gì. Nó chỉ có thể trò chuyện. Nó không thể ghi file. Nó có thể đọc file nếu bạn cho phép. Nhưng nó không thể bắt đầu cố gắng tạo mã một giải pháp. Vì vậy, thay vì cố gắng tạo mã giải pháp ngay từ đầu, chúng ta sẽ cố gắng hiểu hệ thống trước. Nó thực sự hoạt động như thế nào ngày nay? Những file nào sẽ được liên quan? Những mô hình nào chúng ta muốn mô phỏng? Hoặc điều này khác với những gì chúng ta đã có như thế nào? Và bạn biết đấy, chỉ cần tìm hiểu xem trong codebase phần này sẽ được đặt ở đâu, và cách dữ liệu sẽ chảy qua hệ thống và cách nó sẽ thay đổi với sự thay đổi của chúng ta. Cũng như bất kỳ trường hợp ngoại lệ nào chúng ta cần xem xét, Tác nhân AI rất giỏi trong việc brainstorming. Vì vậy, nó có thể giúp bạn brainstorming những điều đó và đảm bảo bạn đã xem xét kỹ lưỡng mọi khía cạnh. Và sau khi bạn hoàn thành nghiên cứu đó, sản phẩm đầu ra sẽ là một tài liệu chi tiết về nghiên cứu đó. Để bạn có thể đọc và về cơ bản đồng ý và hiểu, "Ồ, điều này khớp với hiểu biết của tôi về vấn đề. Tôi nghĩ chúng ta đã sẵn sàng chuyển sang kế hoạch."
Giai đoạn lập kế hoạch
Và sau khi chúng ta đã xem xét tài liệu nghiên cứu với tư cách một con người. Bây giờ chúng ta có thể nói, "Được rồi, hãy vạch ra các bước tiếp theo." Những loại file nào chúng ta sẽ tạo hoặc thay đổi? Có thể có một số đoạn mã, nhưng không phải lúc nào cũng là ý hay khi có một đoạn mã trong kế hoạch. Vì vậy, chúng ta sẽ bao gồm cách chúng ta sẽ xác minh xem thay đổi này có đúng không. Những thay đổi hoặc bổ sung kiểm thử nào chúng ta sẽ thực hiện để biết điều đó. Và chúng ta cũng sẽ rất rõ ràng trong giai đoạn lập kế hoạch về những gì nằm trong và ngoài phạm vi. Những gì sẽ thay đổi. Những gì sẽ không thay đổi. Và một lần nữa, đầu ra của giai đoạn đó sẽ là một file kế hoạch rất rõ ràng. Bạn sẽ thấy rất nhiều kho lưu trữ GitHub ngày nay có một thư mục tên là "plans". Và chúng ta muốn file kế hoạch đó có các hướng dẫn từng bước, với những thay đổi cụ thể mà chúng ta sẽ thực hiện, có các lệnh kiểm thử để xác minh, có một chiến lược để hiểu cách nó sẽ thay đổi hệ thống. Và nó sẽ rất rõ ràng để chúng ta thậm chí có thể sử dụng một mô hình ngôn ngữ lớn nhỏ hơn, nhanh hơn hoặc rẻ hơn để triển khai nó, bởi vì chúng ta đã dành thời gian trong giai đoạn nghiên cứu và lập kế hoạch để thực sự hiểu những gì chúng ta sẽ làm khi đến lúc triển khai thay đổi.
Giai đoạn triển khai và sự giám sát của con người
Và khi chúng ta đến giai đoạn triển khai thay đổi, bây giờ chúng ta có thể bắt đầu một phiên mới và chỉ cung cấp cho nó việc thực hiện kế hoạch. Điều này cho phép chúng ta giữ cửa sổ ngữ cảnh trong phiên đó rất thấp. Nó cho phép chúng ta xem xét cẩn thận từng thay đổi và tôi nghĩ là commit rất thường xuyên. Bây giờ, tôi vẫn làm việc tại một công ty tên là GitLab trong nhiều năm, vì vậy có lẽ tôi hơi thiên vị git, nhưng tôi nghĩ git có thể là một trợ thủ đắc lực ở đây. Khi nói đến việc giúp bạn dần dần lặp lại và hiểu những thay đổi mà các Tác nhân đang thực hiện, tôi coi git trên máy cục bộ của mình giống như việc tự kiểm tra pull request đầu tiên với các Tác nhân của mình trước khi tôi có thể gửi một pull request thực sự cho đồng nghiệp của mình xem xét. Nhưng tôi nghĩ điều quan trọng là phải hiểu ở đây rằng thời gian của con người trong các giai đoạn lập kế hoạch và nghiên cứu thực sự là cách sử dụng thời gian có đòn bẩy cao nhất. Khi bạn đang triển khai, bạn muốn hoàn thành tất cả những suy nghĩ khó khăn đó. Và điều đó thực sự quan trọng bởi vì một lần nữa, quay trở lại Dexhorthy, người đã nói rất nhiều về chủ đề này và tôi đặc biệt khuyên bạn nên xem các video của anh ấy trên YouTube nói về điều này. Anh ấy nói rất đúng rằng AI không thể thay thế việc suy nghĩ, nó chỉ có thể khuếch đại suy nghĩ bạn đã thực hiện hoặc sự thiếu suy nghĩ mà bạn chưa thực hiện hoặc thực tế là bạn chưa suy nghĩ kỹ.
Cấu hình Tác nhân: Chế độ, quy tắc và tự động hóa
Vì vậy, hãy nói về cách chúng ta cấu hình các Tác nhân của mình, giống như một bước nữa để từ mô hình nghiên cứu, lập kế hoạch, triển khai để thực sự đảm bảo chúng ta làm được điều này.
Đầu tiên, chúng ta đã nói về các chế độ và tùy chỉnh. Chúng ta đã nói về các chế độ này như ask, code, architect – các chế độ được chuyên biệt hóa và tập trung vào điều chúng ta đang cố gắng hoàn thành, phải không? Architect có thể là để lập kế hoạch, ask mode là để nghiên cứu, code mode là để thực sự triển khai.
Sau đó, chúng ta cũng muốn có một bộ quy tắc có ý nghĩa cho không gian làm việc của chúng ta, phải không? Đối với kho lưu trữ GitHub chúng ta đang ở. Hoặc có thể là trên toàn cầu trên máy của chúng ta để chúng ta hiểu rằng chúng ta có một bộ quy tắc nhất định mà chúng ta luôn muốn tuân thủ. Và các Tác nhân khá giỏi trong việc tải và hiểu những quy tắc đó. Nhưng chúng ta phải viết chúng ra để chúng có những quy tắc đó trong cửa sổ ngữ cảnh của chúng.
Và tôi nghĩ rằng nhiều hành vi của Tác nhân sau đó là những điều chúng ta muốn điều chỉnh khi chúng ta học hỏi, phải không? Chúng ta có muốn làm việc với nhiều Tác nhân cùng lúc không? Chúng ta có muốn các Tác nhân đó sử dụng worktrees để chúng ta có thể hợp nhất chúng trở lại vào kho lưu trữ GitHub cục bộ của chúng ta trước khi commit chúng vào một pull request không? Chúng ta muốn tự động phê duyệt đến mức nào? Hầu hết các Tác nhân đều có khả năng điều chỉnh những gì chúng có thể làm độc lập, những công cụ nào chúng có thể sử dụng độc lập, liệu chúng có thể đọc file, ghi file bên trong hay bên ngoài không gian làm việc. Liệu chúng có thể chạy kiểm thử không? Tác nhân có thể làm gì một cách tự chủ mà không cần sự can thiệp của bạn so với những gì bạn cần phê duyệt. Và tôi nghĩ đây là điều bạn phải thiết lập để cảm thấy thoải mái ngay từ đầu và sau đó bạn cũng cần phải thoải mái thay đổi khi bạn học cách sử dụng những công cụ này.
Các loại cấu hình Tác nhân: Chế độ, Agents.md và Skills.md
Và tôi nghĩ một mô hình tinh thần tốt cho cấu hình Tác nhân này có thể là ba nhóm riêng biệt, phải không? Chúng ta đã nói về các chế độ, đây là cấu hình dựa trên vai trò đó, hành vi của một Tác nhân mà chúng ta muốn. Nhưng có hai điều quan trọng khác, đó là agents.md và sau đó là skills.md mà bạn nghe nói đến. Vậy chúng là gì, sự khác biệt giữa hai cái này là gì? Agents.md đang nhanh chóng trở thành tiêu chuẩn de facto cho nơi tất cả các Tác nhân tìm đến, giống như README của chúng, cho các quy tắc luôn bật và chi tiết về dự án. Vì vậy, tôi nghĩ điều quan trọng là dự án của bạn phải có một agents.md với lượng thông tin tối thiểu mà một Tác nhân cần biết về các quy ước chúng ta đang sử dụng, các lệnh chúng ta đang sử dụng để xây dựng hoặc kiểm thử, và các yêu cầu xung quanh việc kiểm thử. Hoặc các yêu cầu mà chúng ta cần đảm bảo kiểm tra trước khi commit.
Và sau đó skills (kỹ năng) là một quy trình làm việc cụ thể hơn. Có những playbooks có thể tái sử dụng cho các Tác nhân. Vì vậy, nếu có điều gì đó bạn làm thường xuyên, bạn tạo đồ họa chuyển động thường xuyên, hoặc bạn đang thực hiện một loại change log hàng ngày, hàng tuần hoặc hàng tháng nào đó, biên soạn những thứ đó. Những loại công việc đó rất tốt để đặt vào skills mà một Tác nhân có thể sử dụng khi cần để thực hiện các quy trình làm việc cụ thể đó. Và vì vậy, thông thường, những thứ đó là theo yêu cầu và bạn nói, "Này, hãy sử dụng kỹ năng này cho nhiệm vụ này," trong khi agents.md hầu như luôn được tải vào cửa sổ ngữ cảnh cho Tác nhân để nó biết điều gì đang diễn ra.
Mẹo cho người dùng nâng cao và vượt ra ngoài IDE
Và sau đó, tất nhiên, tôi làm việc tại Kilo Code, vì vậy tôi có một số mẹo cho người dùng nâng cao ở đó, nhưng tôi nghĩ một số trong số này, nhiều trong số này, áp dụng cho bất kể Tác nhân nào bạn đang sử dụng, nhưng tôi nghĩ chúng rất quan trọng khi bạn bắt đầu cảm thấy thoải mái với những mô hình ban đầu đó. Làm thế nào để tôi tùy chỉnh điều này và làm cho nó phù hợp với mình?
Một là @mentioning (đề cập) để có ngữ cảnh. Vì vậy, đề cập các file hoặc commit hoặc những thứ từ terminal xuất ra. Những thứ đó và đưa chúng vào ngữ cảnh một cách nhanh chóng thực sự hữu ích khi sử dụng các lệnh / để làm những việc như bắt đầu một nhiệm vụ mới khi chúng ta cần hoặc nén ngữ cảnh khi nó trở nên quá đầy. Những lệnh nhanh đó có thể giúp chúng ta di chuyển nhanh hơn nhiều.
Chúng tôi cũng đang làm việc trong VS Code với Kilo Code, chúng ta có thể chọn một phần mã và nhấp chuột phải và nói "thêm vào Kilo Code", và sau đó ngữ cảnh đó được đưa thẳng vào đó và tôi có thể nói chuyện hoặc hỏi các câu hỏi về phần mã đó hoặc yêu cầu Tác nhân thay đổi một phần cụ thể của mã đó. Và sau đó, tất nhiên, chúng tôi cũng có tính năng tự động hoàn thành được tích hợp sẵn, mà tôi nghĩ vẫn hữu ích, đặc biệt là vì chúng tôi có nó không chỉ trong mã mà còn khi bạn đang lời nhắc.
Và sau đó, vượt ra ngoài IDE, tôi nghĩ chúng ta cũng đang thấy sự thay đổi trong năm nay về việc tôi muốn có thể sử dụng cái này ở đâu khác: trong CLI, từ điện thoại di động của tôi, trong một Tác nhân đám mây trực tiếp trong Slack. Khả năng sử dụng những Tác nhân này ở bất cứ đâu bạn đang ở là điều đang trở nên được mong đợi nhiều hơn từ mọi người và các Tác nhân của mọi người, và tôi nghĩ đó là một điều tốt. Tôi nghĩ điều đó có nghĩa là chúng ta đang bắt đầu học cách chúng ta có thể sử dụng những Tác nhân này một lần nữa giống như một cộng tác viên có mặt ở khắp mọi nơi chúng ta cần.
Giao thức ngữ cảnh mô hình (MCP)
Và một điều nữa tôi muốn nói đến là việc đưa các ngữ cảnh khác vào. Trước hết, Giao thức ngữ cảnh mô hình (Model Context Protocol - MCP). Ngữ cảnh nằm ngay trong tên. Ý tưởng của điều này là về cơ bản các mô hình này ban đầu chỉ có thể nhận mã thông báo đầu vào và tạo mã thông báo đầu ra. Dần dần, chúng ta đã cho phép chúng sử dụng công cụ nơi chúng có thể thực hiện gọi công cụ và tác động đến mọi thứ trong môi trường như chạy kiểm thử.
Khái niệm MCP về cơ bản mở rộng điều này để nói rằng, "Này, tôi muốn cung cấp cho Tác nhân những công cụ khác." Chẳng hạn, GitHub MCP cung cấp cho Tác nhân rất nhiều công cụ để tương tác với GitHub API, tra cứu các pull request, tra cứu các bình luận, tra cứu các issue và hiểu nhiều hơn về môi trường GitHub của bạn. Hoặc Context Seven giúp nó tìm kiếm tài liệu framework cập nhật, bởi vì tất nhiên, như bạn đã biết, các Mô hình Ngôn ngữ Lớn có một ngày cắt giảm kiến thức, và sau đó bất cứ điều gì được cải thiện kể từ đó, chúng không biết. Vì vậy, các máy chủ MCP này có thể rất hữu ích và có hàng ngàn trong số đó.
Tối ưu hóa System Prompt và Quản lý Công cụ
Tuy nhiên, mối lo ngại là mỗi công cụ sẽ thêm ít nhất một số thông tin (chi tiết về các công cụ mà nó có) vào lời nhắc hệ thống được gửi đi mỗi khi bạn tương tác với một Tác nhân. Vì vậy, bạn muốn đảm bảo rằng nếu không thực sự sử dụng công cụ đó, hãy tắt nó đi. Chẳng hạn, tôi có một MCP của Postgres kết nối với cơ sở dữ liệu của mình, và tôi đang thực hiện rất nhiều công việc giao diện người dùng mà không liên quan gì đến cơ sở dữ liệu. Khi đó, MCP của Postgres đó sẽ chỉ lãng phí mã thông báo, và tệ hơn nữa, có thể là những mã thông báo gây nhầm lẫn cho Tác nhân và khiến nó không hiểu rằng nó không được phép truy cập cơ sở dữ liệu tại thời điểm đó. Vì vậy, chúng ta cần rất cẩn thận để không lạm dụng MCP.
Tích hợp API nội bộ
Một vấn đề khác mà chúng tôi thường nghe từ các doanh nghiệp là làm thế nào để làm việc với các Giao diện lập trình ứng dụng (API) của nền tảng nội bộ. Tôi nghĩ có bốn cách khác nhau để thực hiện điều này. Thứ nhất: nếu đã có một OpenAPI spec hoặc Swagger spec cho API đó, hãy sử dụng nó. Nếu chưa có, hãy chuyển đổi nó sang định dạng Markdown để bạn có thể lưu trữ Markdown đó trong agents.md hoặc một nơi nào đó khác trong kho lưu trữ GitHub repo để tham chiếu. Nếu đó là một thứ thay đổi thường xuyên hơn một chút, có thể bạn cần một URL tham chiếu để có thể kéo dữ liệu vào và để Tác nhân tự động lấy thông tin mới nhất mỗi lần. Và chúng tôi cũng đã thấy một số khách hàng có các quy trình làm việc phức tạp gồm nhiều bước, nhiều hệ thống, trong đó việc xây dựng máy chủ MCP của riêng họ có thể là lựa chọn đúng đắn.
Cách làm việc với Tác nhân và Kilo
Tuy nhiên, dù bằng cách nào đi nữa, tôi nghĩ điều cốt lõi là khi làm việc cùng với Kilo hoặc bất kỳ Tác nhân nào trong số này, hãy môi trường cô lập công việc của bạn khỏi công việc của Tác nhân, sau đó xem xét công việc của Tác nhân đó dưới dạng một pull request, đúng không? Điều đó giúp bạn hiểu rõ... Và sau đó, chúng ta có thể xem xét mã code tốt nhất giống như cách tôi xem xét mã của một kỹ sư mới vào nghề.
Các tính năng mới của Kilo và Tác nhân OpenClaw
Và đó là phần trình bày của tôi về Kilo. Chúng tôi có một số tính năng mới thú vị sắp ra mắt, được mở rộng trên tất cả các bề mặt. Chúng tôi cũng đặc biệt chú trọng vào OpenClaw và KiloClaw để tạo ra một cách rất an toàn khi sử dụng các Tác nhân OpenClaw. Và để tìm hiểu thêm về Kilo, tôi xin giới thiệu ở cuối đây: hãy truy cập kilo.ai và chúng tôi rất mong nhận được phản hồi của bạn về những gì chúng tôi đang xây dựng.
Tư duy làm việc với Mô hình ngôn ngữ lớn và tương lai
Và, để cho bạn thấy chúng ta sẽ đi đến đâu từ đây. Tôi nghĩ bạn phải chọn một công cụ và thực hành thật nhiều. Chúng tôi đã nói từ trước rằng đây vừa là nghệ thuật vừa là khoa học. Và tôi nghĩ điều đó có nghĩa là bạn cần thực hành rất nhiều để có thể cảm nhận được những gì tôi có thể tin tưởng các Mô hình ngôn ngữ lớn làm được và những gì tôi không thể tin tưởng chúng làm được. Sau đó, hãy thử quy trình này: nghiên cứu, lập kế hoạch, triển khai, vòng lặp phản hồi (feedback loop), xem nó hiệu quả với bạn như thế nào. Và tôi nghĩ có thể bạn sẽ giống như một số kỹ sư cấp cao khác đã nói: "Này, nhìn xem, tôi đang lập trình vui hơn bao giờ hết trong nhiều năm qua, khi chúng ta giao một số công việc tẻ nhạt này cho các Tác nhân và để bộ não của chúng ta giải quyết các vấn đề kỹ thuật khó hơn."