Cách tạo một coding agent
(ghuntley.com)- Tính đến năm 2025, việc tự tay xây dựng một coding agent là một trong những dự án tốt nhất mà một lập trình viên cá nhân có thể thử
- Agent có thể hoạt động chỉ với 300 dòng code và một vòng lặp token của LLM, đồng thời mang lại cơ hội chuyển từ người tiêu dùng AI sang người sản xuất AI
- Các thành phần cơ bản gồm những công cụ như đọc file, liệt kê file, chạy Bash, chỉnh sửa file, tìm kiếm code, qua đó hiện thực hóa các chức năng tự động hóa thực tế
- Về lựa chọn mô hình, các mô hình agentic như Claude Sonnet, Kimi K2 là phù hợp; khi cần có thể nối thêm các mô hình oracle như GPT làm công cụ để thực hiện kiểm chứng ở mức cao hơn
- Trên thực tế, các sản phẩm thương mại như Amp, Cursor, Claude Code, GitHub Copilot cũng có cấu trúc tương tự
Tổng quan workshop
- Đây là workshop miễn phí do Geoffrey Huntley tổ chức, hướng dẫn theo hướng thực hành cách tự xây dựng coding agent và nguyên lý vận hành của nó
- Workshop so sánh cấu trúc và nguyên lý với các trợ lý AI thương mại hiện có như Roo code, Cline, Amp, Cursor, Windsurf, OpenCode, đồng thời tạo cơ hội để tự mình hiện thực hóa
- Thông qua trải nghiệm xây dựng, bạn có thể vượt ra khỏi vai trò người chỉ dùng AI để trở thành lập trình viên trực tiếp tạo công cụ tự động hóa bằng AI
- Cấu trúc cốt lõi là tạo ra chức năng agent bằng cách dùng token của LLM theo cơ chế vòng lặp trong khoảng 300 dòng code
- Các primitive của từng công cụ như đọc, liệt kê file, thực thi, chỉnh sửa, tìm kiếm code được bổ sung dần; ví dụ hoạt động thực tế và mã nguồn được công khai tại kho GitHub
Agent là gì
- Gần đây, thuật ngữ "agent" được dùng rất rộng rãi, nhưng ý nghĩa thực chất và nguyên lý vận hành bên trong lại chưa rõ ràng
- Khi rào cản để tạo agent ngày càng thấp, bạn có thể vượt khỏi vai trò người tiêu dùng AI để trở thành người sản xuất có thể dẫn dắt tự động hóa công việc
- Tính đến năm 2025, giống như các khái niệm cơ sở dữ liệu cơ bản như Primary key, nguyên lý xây dựng agent đã trở thành kiến thức thiết yếu
- Các công ty như Canva đã khuyến khích sử dụng AI ngay trong quy trình phỏng vấn, và năng lực tự động hóa bằng AI đang trở thành yếu tố cốt lõi trong tuyển dụng
- Lý do tụt lại giờ đây không còn là vì AI, mà là vì không chủ động tự phát triển bản thân để học các công cụ mới
Nguyên lý cốt lõi của coding agent
- Coding agent được cấu thành chỉ từ 300 dòng code và một vòng lặp token của LLM, thực hiện chức năng thông qua việc lặp đi lặp lại đầu vào token
- Khái niệm làm việc đồng thời (concurrent work) rất quan trọng
- Ví dụ: ngay cả khi đang họp Zoom, agent vẫn có thể tiến hành công việc song song, giúp hiệu suất công việc tăng đáng kể
- Không phải mọi LLM đều mang tính agentic
- 'An toàn cao' (ví dụ: Anthropic, OpenAI)
- 'An toàn thấp' (ví dụ: Grok)
- 'Oracle' (có lợi cho tóm tắt và tư duy bậc cao)
- 'Agentic' (thiên về hành động, lặp nhanh và gọi công cụ)
- Lập trình viên cần hiểu đặc tính của từng mô hình và chọn mô hình phù hợp với mục đích sử dụng
- Việc cấp phát context window một cách vô điều kiện là yếu tố làm giảm hiệu năng; cần ghi nhớ rằng "càng cấp ít thì kết quả càng tốt"
- Đăng ký quá nhiều công cụ MCP sẽ dẫn tới suy giảm hiệu năng
- Quy tắc: "Less is more" → chỉ nên đặt đúng lượng công cụ và dữ liệu cần thiết vào ngữ cảnh để đạt hiệu năng tối ưu
Luồng xây dựng coding agent
-
1. Đăng ký công cụ và gọi hàm
- Ví dụ, đăng ký với LLM một công cụ tra cứu thời tiết để LLM có thể phản hồi dưới dạng gọi hàm trong những tình huống phù hợp
- MCP(Model Context Protocol) giống như một "biểu ngữ thông tin về hàm"; chỉ cần đăng ký phần mô tả hàm là cũng có thể tự động gọi
-
2. Chức năng cốt lõi theo từng primitive tool
- Đọc file (ReadFile): khi truyền đường dẫn thì đọc nội dung file vào context
- Liệt kê file (ListFiles): cung cấp danh sách file và thư mục trong thư mục
- Thực thi lệnh (Bash): cho phép LLM chạy lệnh shell của hệ thống và trả về kết quả
- Chỉnh sửa file (Edit): tự động hóa việc tạo mới hoặc sửa file được chỉ định
- Tìm kiếm code (CodeSearch): nhanh chóng tìm kiếm toàn bộ codebase dựa trên pattern, từ khóa hoặc tên hàm (sử dụng ripgrep)
-
3. Ví dụ và luồng kết quả
- Bằng cách tích hợp từng công cụ vào LLM, có thể tự động hóa các tác vụ liên tiếp chỉ bằng prompt ngôn ngữ tự nhiên (ví dụ: tạo code FizzBuzz → chạy để kiểm tra, duyệt thư mục → phân tích nội dung)
- Các hàm công cụ được gọi tuần tự theo đầu vào của người dùng hoặc theo kịch bản, và việc trả kết quả được lặp lại bên trong vòng lặp
- Trình tự vận hành chính của agent: đầu vào người dùng → phán đoán có gọi công cụ hay không → thực thi công cụ → gán kết quả vào context → lặp lại
Khả năng mở rộng và mã nguồn mở
- Hiện nay, phần lớn coding agent hoạt động dựa trên các công cụ mã nguồn mở sẵn có như ripgrep
- Trên GitHub có những dự án agent đơn giản nhưng mạnh mẽ như SST Open Code, mini-swe-agent được triển khai chỉ với khoảng 100 dòng, nên có thể tham khảo về hiệu năng và cấu trúc
- Thay vì chỉ so sánh với sản phẩm có sẵn, các lập trình viên được khuyến khích tự xây dựng để hiểu nguyên lý và cách ứng dụng
- Khi áp dụng vào công việc thực tế và tự động hóa, việc tạo agent riêng và phổ biến nó trong tổ chức sẽ chuyển hóa thành năng lực cạnh tranh
Kết luận và hàm ý
- Coding agent không phải là công nghệ phức tạp mà được tạo nên từ cấu trúc vòng lặp đơn giản và sự kết hợp công cụ
- Cốt lõi của việc xây dựng coding agent là hiểu cấu trúc và khả năng triển khai nhanh; trải nghiệm tự tay xây dựng giúp chủ động thích ứng với các thay đổi của công nghệ AI
- Điều quan trọng lúc này không phải chỉ là bản thân AI, mà là sự đầu tư vào chính mình như liên tục tự phát triển và xây dựng năng lực tạo công cụ
- "Thứ đe dọa không phải là AI cướp việc của bạn, mà là đồng nghiệp của bạn được trang bị agent để tự động hóa và làm việc nhanh hơn"
4 bình luận
Ý kiến trên Hacker News
Nhóm Princeton SWE-bench của chúng tôi đã tạo ra một agent chỉ với khoảng 100 dòng code nhưng đạt kết quả tốt trên SWE-bench, ai quan tâm thì nên xem thử mini-swe-agent
Thật sự khá ngạc nhiên vì cấu trúc của nó đơn giản đến vậy, cảm ơn vì đã chia sẻ thông tin này
Toàn bộ code thực ra chạy dựa trên các prompt này mã nguồn prompt mặc định của agent
Trong các prompt mẫu của agent, phần “1. tìm và đọc các file liên quan trong codebase 2. tạo script tái hiện issue 3. sửa issue 4. xác minh bản sửa bằng script 5. test edge case” khá hữu ích
Tôi cũng dùng prompt kiểu tương tự trong vòng lặp debug của mình
Cách “phân tích codebase rồi liệt kê các khả năng gây ra nguyên nhân, xếp hạng theo mức độ khả dĩ, rồi kiểm chứng giả thuyết bằng script hoặc debug logging” giúp ích rất nhiều cho quy trình giải quyết vấn đề của tôi
Khi vấn đề tự chứa gọn trong một file thì dùng LLM để sửa là rất dễ
Nhưng với codebase thông thường, file và ngữ cảnh lại rải rác khắp nơi nên không dễ nắm bắt theo ý đồ thiết kế có cấu trúc và cách tổ chức của lập trình viên
Hoan nghênh nỗ lực tuyệt vời này, nhưng điều hơi tiếc là công cụ không nhiều
Phần lớn code thuộc về framework agent, còn code chuyên biệt riêng cho SWE thì không nhiều như tưởng tượng
Tôi cũng từng làm một SWE agent cho vui, nên có thể tham khảo thêm autocode
Tôi đã thêm nó vào phần tài liệu tham khảo như một lời cảm ơn
Một “hướng dẫn cách xây agent” rất giống do Thorsten Ball viết cũng có ở AmpCode How To Guide
Nhìn chung Amp cũng khá thú vị
Giờ nó không còn là một dịch vụ bí mật nữa, nhưng vẫn rất vui khi thấy các công cụ liên quan đến agent coding tiếp tục được công khai
Tôi nghĩ về sau những mô hình agent kiểu này sẽ được tích hợp sẵn trong nhiều phần mềm khác nhau
Cái này nhìn dễ xem hơn nhiều nên thấy biết ơn
Cũng có nhắc rằng chính tác giả đang làm việc tại Amp
Ghuntley cũng làm ở Amp
Người ta hay nói một bức ảnh đáng giá 1000 từ, nhưng trong tài liệu này thì cảm giác giá trị của các hình đã bị giảm giá 99,6%
Không rõ đây là cái gì nữa
Phần chữ là bản chép lại lời nói thực tế trong lúc trình bày
Không biết có ai xác nhận giúp cách tool được dùng trong thực tế không
Tôi hiểu là Claude, ChatGPT v.v. cung cấp “tool” qua API, và khi có yêu cầu gọi tool thì phía responder sẽ thực sự chạy tool rồi trả kết quả lại
Nhưng bản chất mô hình nói cho cùng vẫn là dựa trên ký tự, nên tôi tò mò API làm thế nào để biến phản hồi của mô hình thành nhiều cấu trúc khác nhau
Tôi đoán hẳn trong quá trình fine-tuning đã có các ví dụ chèn lời gọi tool cụ thể dưới dạng block đặc biệt để mô hình học được, rồi máy chủ của Claude/ChatGPT sẽ diễn giải nó
Tôi muốn biết có tài liệu nào liên quan đến chuyện này, hoặc có thông tin nào về các special token dùng nội bộ không, và làm sao để chặn việc người dùng lợi dụng những token “mang ý nghĩa” đó
Có tài liệu triển khai do Anthropic công bố
Anthropic Tool Use Documentation
Ở đây có thể thấy rõ rằng mô hình thực ra không hoạt động trên “văn bản” mà ở mức token
Nó tương tự việc compiler parse source code để tạo ra chuỗi “token” gồm keyword, dấu ngoặc và cấu trúc
Trong output có thể chứa cả metadata bên cạnh từ ngữ thực tế
Về mặt khái niệm thì bạn hiểu đúng
Giao diện thực sự duy nhất với LLM chỉ là “token”, không có sự tách biệt giữa kênh điều khiển và kênh dữ liệu
Ở tầng API của mô hình, instruction cho việc gọi tool và danh sách các tool khả dụng được chèn vào prompt, kèm theo mô tả cho từng tool
Khi cần gọi tool, mô hình sẽ chèn một block đặc biệt trong phản hồi (bao gồm special token, tên tool và tham số), rồi tầng API sẽ trích xuất và chuyển nó sang dạng JSON
Kết quả chạy tool cũng được chèn vào bằng special token
Tầng API ngăn người dùng tự ý chèn các token kiểu này vào input
Các mô hình hiện đại nhất (SoTA) đã được fine-tune rất nhiều cho việc gọi tool, bao gồm cả fine-tuning cho gọi tool đa dụng lẫn những trường hợp chuyên biệt cho tool cụ thể (ví dụ model Claude Sonnet được tối ưu cho các tool của Claude Code)
Thật sự ngạc nhiên là mọi thứ vận hành trơn tru được, vì trong việc gọi tool thì fine-tuning giữ vai trò cực kỳ quan trọng
Không fine-tuning thì vẫn có thể hoạt động, nhưng tỷ lệ thành công giảm đi đáng kể
Tôi nghĩ phỏng đoán “được fine-tune để trả về các ví dụ cần gọi tool dưới dạng block đặc biệt” là đúng
Mô hình được huấn luyện để trả lời theo format gọi tool khi không biết đáp án hoặc khi được chỉ dẫn làm vậy
Có cả việc huấn luyện theo ví dụ gọi tool tuân thủ format (chính format đó) lẫn huấn luyện chuyên biệt cho một số công cụ nhất định
Ví dụ gpt-oss có xu hướng muốn dùng công cụ tìm kiếm ngay cả khi không được nhắc đến
Trong tài liệu của Anthropic cũng có danh sách các công cụ quen thuộc riêng (ví dụ
text_editor,bash), và rất có thể các công cụ này còn được học riêng ở mức ngữ nghĩa sâu hơn về cách sử dụngThực tế thì cấu trúc này khá dễ vỡ và được thực hiện thông qua các tín hiệu mức thấp như “special token hoặc chuỗi token”
Câu “cứ ném token liên tục vào vòng lặp thì sẽ có agent” nghe khá châm biếm thực tế nếu thay “token” bằng “tiền”
Rốt cuộc cứ đốt tiền liên tục thì sẽ sinh ra agent
Các mô hình local cũng đang ngày càng tốt hơn
Hiện tại để có kết quả tốt nhất thì vẫn cần token (= tiền), nhưng tương lai có thể sẽ khác
Toàn ảnh như thế này thì đọc quá mệt
Cảm giác như đang xem một trình mô phỏng cuộn trang
Tôi thắc mắc ngoài tool bash ra thì tại sao còn cần các tool khác
Những việc như liệt kê file, tìm và khám phá repo, chỉnh sửa nội dung file chẳng phải đều làm được chỉ với bash sao
Hay là ý đang nói đến trường hợp minh họa trong ví dụ mini-swe-agent ở trên
Về mặt kỹ thuật thì chỉ với bash cũng đã có thể làm được rất nhiều việc, và thực tế tôi cũng từng thành công theo cách đó
Điều thú vị là càng giới hạn tool thì agent lại càng tiếp cận sáng tạo hơn
Nhưng nếu cung cấp nhiều tool đã được huấn luyện sẵn, mô hình vốn đã biết khá rõ cách dùng từng tool nên vừa tiết kiệm token hơn vừa nâng tỷ lệ thành công tổng thể
Nếu chỉ dùng bash thì nó cũng hay loay hoay với bashism, xử lý argument hay khoảng trắng
Dùng tool riêng sẽ đơn giản hơn nhiều so với dồn hết vào một tool bash
Nếu xử lý tất cả bằng bash thì bạn phải tự xây thêm cơ chế phân biệt lệnh nào chắc chắn an toàn để chạy ngay (ví dụ liệt kê file) và lệnh nào nguy hiểm cần xin người dùng phê duyệt
Nếu cung cấp chức năng liệt kê file dưới dạng tool riêng thì cũng có thể ngăn lộ file nằm ngoài thư mục project
Trên thực tế chỉ với tool bash và tool Edit là đã đủ để vận hành coding agent (Edit không hẳn bắt buộc, nhưng thiếu thì kém hiệu quả hơn nhiều)
Dù vậy, phần tìm kiếm code có thể sẽ khó hơn
Ví dụ có thể bù lại bằng cách chỉnh prompt để nó dùng
ripgrepqua bashVì sao cần IDE? Dù ở shell làm được mọi thứ thì tại sao vẫn phải dùng?
UI (giao diện) có vai trò cung cấp đúng thông tin và hành động cần thiết ngay tại thời điểm đó
Về câu hỏi tại sao lại có thêm các tool khác ngoài bash, tôi nghĩ là vì lúc đầu người ta muốn bắt đầu với bộ công cụ tối thiểu, rồi sau này vẫn có thể bổ sung bash vào
Thay vì giải thích dài dòng về “cách tạo agent”, tôi muốn thấy một dự án thật sự do agent tạo ra hơn
Có ai giải thích được các trục Oracle, Agent, high safety, low safety có ý nghĩa gì không
Tôi đã thử trực tiếp với các mô hình on-device của edge và chrome (phi4-mini, gemini nano), và khá bất ngờ vì nó hoạt động tốt hơn mong đợi so với kích thước mô hình
thử nghiệm xây agent on-device
Buồn cười vãi hahaha, lúc đầu không hiểu đang nói gì, mà bấm vào link xong thì hiểu ngay ngay lập tức
Các hình thu nhỏ của những bài viết khác trên blog cũng tệ y như vậy, nhìn là thấy hoàn toàn không muốn bấm vào.
kkkkkkkkkkkkkkkkkkkkkkkkkkk