Kỹ thuật xây dựng AI Agent biết viết và triển khai phần mềm thật: Bên trong kiến trúc của Jobbit

Hầu hết các "AI agent" dừng lại ở mức trò chuyện. Chúng trả lời, rồi con người mới là người làm việc. Bài toán kỹ thuật thú vị — và thực sự khó — là xây dựng những agent tự làm việc: viết một ứng dụng full-stack, chạy nó, tự sửa lỗi của chính mình, và triển khai lên môi trường production. Đó chính là bài toán mà đội ngũ kỹ thuật tại Jobbit và bộ phận R&D của họ, Jobbit Labs (jobbitlabs.com), giải quyết mỗi ngày.

Bài viết này là một phân tích kỹ thuật chuyên sâu về các mô hình (pattern) đằng sau những AI agent biết xây dựng và triển khai phần mềm — kiến trúc, các kiểu thất bại, và những bài học rút ra. Bài viết cố ý mang tính thực hành và không phụ thuộc nhà cung cấp nào: dù bạn đang xây dựng trên LLM, điều phối đa agent (multi-agent orchestration), tool calling, hay RAG, những nguyên tắc này đều áp dụng được.

Chatbot thì trả lời; agent thì hành động

Bước nhảy từ chatbot sang agent chính là bước nhảy từ việc sinh ra văn bản sang việc hành động trong thế giới thực. Một agent phải lập kế hoạch cho một tác vụ nhiều bước, gọi các công cụ (tool), đọc kết quả, và quyết định việc tiếp theo cần làm — rồi lặp lại cho đến khi đạt mục tiêu. Vòng lặp đó, thường được gọi là vòng lặp agent (agentic loop) (hay vòng lặp suy luận–hành động), chính là trái tim của hệ thống.

Thách thức kỹ thuật nằm ở chỗ mỗi bước đều có thể thất bại. Mô hình có thể "ảo giác" ra một hàm không tồn tại, viết mã không biên dịch được, đọc sai output của một công cụ, hoặc âm thầm đi chệch khỏi tác vụ. Một chatbot trả lời sai chỉ tạo ra một câu văn dở; một agent làm sai sẽ tạo ra một lần triển khai hỏng. Độ tin cậy, chứ không phải năng lực thô, mới là công việc kỹ thuật thực sự.

Kiến trúc: bộ lập kế hoạch, bộ thực thi, công cụ

Một nền tảng agent vững chắc tách biệt lập kế hoạch (planning) khỏi thực thi (execution). Lớp lập kế hoạch phân rã một mục tiêu ("xây một ứng dụng đặt lịch có tích hợp thanh toán") thành các bước cụ thể; lớp thực thi triển khai từng bước bằng các công cụ (tool). Giữ cho hai mối quan tâm này tách biệt làm cho hệ thống dễ gỡ lỗi: bạn có thể kiểm tra kế hoạch một cách độc lập với cách từng bước được chạy.

Tool use là nơi agent có được "đôi tay" của mình. Công cụ là những hàm được định nghĩa rõ ràng mà mô hình có thể gọi — đọc một tệp, viết mã, chạy build, truy vấn cơ sở dữ liệu, triển khai. Kỷ luật kỹ thuật ở đây là thiết kế giao diện: mỗi công cụ cần một lược đồ (schema) chặt chẽ, rõ ràng, đầu vào được kiểm chứng, và đầu ra có cấu trúc mà mô hình có thể phân tích một cách đáng tin cậy. Giao diện công cụ lỏng lẻo là một trong những nguồn gây lỗi agent hàng đầu; giao diện chặt chẽ là khoản đầu tư rẻ nhất để có được độ tin cậy.

Với những công việc phức tạp, một agent đơn lẻ thường nhường chỗ cho điều phối đa agent (multi-agent orchestration) — các agent chuyên biệt lo việc lập kế hoạch, viết mã, đánh giá, và kiểm chứng, được điều phối bởi một orchestrator. Việc phân rã mang lại cho bạn sự tập trung (mỗi agent có một nhiệm vụ hẹp và một ngữ cảnh hẹp) và khả năng song song hóa (các tác vụ con độc lập chạy đồng thời). Đánh đổi ở đây là chi phí điều phối, nên lớp orchestration phải mang tính tất định (deterministic) ở những nơi có thể và bền bỉ (resilient) ở những nơi không thể.

Chạy và triển khai mã thật một cách an toàn

Một agent viết phần mềm thì phải chạy được phần mềm đó — và chạy mã do mô hình sinh ra là một vấn đề bảo mật trước khi nó là bất cứ điều gì khác. Lời giải là chạy mã trong sandbox (sandboxed code execution): mã không đáng tin cậy chạy trong một môi trường cô lập với tài nguyên bị giới hạn, không có quyền truy cập vào secret, và ranh giới mạng chặt chẽ. Sandbox chính là thứ cho phép agent lặp lại quy trình — biên dịch, kiểm thử, đọc lỗi, sửa — mà không khiến nền tảng hay những người dùng khác gặp rủi ro.

Triển khai (deployment) là bước biến một ứng dụng được sinh ra thành một sản phẩm. Một trình xây dựng ứng dụng AI (AI app builder) thực thụ làm chủ toàn bộ đường đi từ mã nguồn đến một URL chạy thật: build, cấp phát hosting, gắn tên miền, kết thúc TLS. Làm tốt phần kỹ thuật này nghĩa là khiến cho việc triển khai có thể lặp lại và có thể đảo ngược — cùng một đầu vào tạo ra cùng một kết quả, và một lần triển khai hỏng có thể được rollback. Tính idempotency và rollback gọn gàng không hào nhoáng, nhưng chúng chính là thứ làm cho việc triển khai tự động trở nên đáng tin cậy.

Ngữ cảnh, bộ nhớ, và truy hồi

LLM có ngữ cảnh hữu hạn, và những dự án thực tế thì không vừa với nó. Vì vậy, một hệ thống agent nghiêm túc đầu tư mạnh vào kỹ thuật ngữ cảnh (context engineering): quyết định mô hình được "thấy" những gì ở mỗi bước. Nhồi mọi thứ vào prompt vừa tốn kém vừa phản tác dụng — quá nhiều ngữ cảnh không liên quan sẽ làm suy giảm khả năng suy luận.

Đây chính là nơi RAG (retrieval-augmented generation) và cơ sở dữ liệu vector (vector database) chứng minh giá trị của mình. Thay vì đổ toàn bộ codebase vào ngữ cảnh, hệ thống truy hồi (retrieve) chỉ một vài tệp, ký hiệu (symbol), hoặc tài liệu liên quan đến bước hiện tại. Kết hợp với bộ nhớ (memory) có cấu trúc — một bản ghi các quyết định, bản đặc tả đang tiến hóa, và những gì đã được thử — việc truy hồi giữ cho agent bám sát thực tế xuyên suốt một tác vụ dài mà không làm tràn cửa sổ ngữ cảnh. Truy hồi tốt thường là đòn bẩy chất lượng lớn hơn cả một mô hình lớn hơn.

Độ tin cậy: evals, kiểm chứng, và rào chắn

Nếu có một ý tưởng tách biệt việc làm kỹ thuật agent cho production khỏi những bản demo, thì đó là: bạn không thể triển khai thứ bạn không thể đo lường. Các hệ thống agent mang tính ngẫu nhiên (stochastic), nên độ tin cậy được tạo ra nhờ evals — những bộ kiểm thử tự động chấm điểm agent trên các tác vụ tiêu biểu và bắt được các điểm thoái lui (regression) trước khi người dùng phát hiện ra. Một thay đổi "cảm giác có vẻ tốt hơn" nhưng làm tụt điểm eval của bạn là một thay đổi bạn không triển khai.

Bên trên evals là các rào chắn (guardrail) và kiểm chứng (verification) ở thời gian chạy. Mô hình hiệu quả nhất là tự kiểm tra đối kháng (adversarial self-checking): sau khi một agent tạo ra một kết quả — một đoạn mã, một kế hoạch, một bản sửa lỗi — một lượt kiểm chứng riêng biệt sẽ cố bác bỏ nó. Mã có biên dịch được không? Các bài kiểm thử có pass không? Output có khớp với schema không? Coi kiểm chứng như một bước riêng biệt, đầy hoài nghi sẽ bắt được một phần lớn các thất bại mà một lượt chạy tự tin đơn lẻ sẽ bỏ sót. Cơ chế thử lại có backoff, circuit breaker, và leo thang cho con người (human escalation) lo phần còn lại.

Khả năng quan sát mà bạn có thể gỡ lỗi

Khi một hệ thống tự động đưa ra hàng chục quyết định cho mỗi tác vụ, bạn cần phải nhìn thấy chúng. Khả năng quan sát (observability) — truy vết (tracing) có cấu trúc cho từng prompt, từng lệnh gọi công cụ, và từng kết quả — là điều không thể thương lượng. Khi một agent đi sai, bản truy vết chính là cách bạn tìm ra đúng bước đã đi chệch, tái hiện nó, và sửa từ gốc rễ. Những đội kỹ thuật coi bản truy vết của agent như telemetry hạng nhất sẽ gỡ lỗi trong vài phút; những đội không làm vậy sẽ gỡ lỗi trong nhiều ngày.

Edge và khả năng co giãn linh hoạt

Khối lượng công việc của agent có tính bùng nổ và nhạy với độ trễ, điều này khiến điện toán biên (edge computing) trở thành một lựa chọn tự nhiên. Chạy gần người dùng — trên các nền tảng như Cloudflare Workers và các kho dữ liệu edge — cắt giảm độ trễ khứ hồi (round-trip) và co giãn linh hoạt theo nhu cầu. Jobbit Labs dựa vào cách tiếp cận edge-first này cho một phần hạ tầng dữ liệu và sản phẩm của mình: phân tán toàn cầu, tự động mở rộng, và trả tiền theo mức sử dụng, để công suất bám theo tải thay vì nằm chờ vô ích.

Lớp con người trong vòng lặp (human-in-the-loop)

Mảnh ghép cuối cùng của kiến trúc lại là thứ mà hầu hết các nền tảng agent thiếu: một đường đi con người trong vòng lặp (human-in-the-loop). AI lo phần khối lượng và tốc độ, nhưng một số quyết định — logic nhạy cảm về bảo mật, câu chữ pháp lý, sự phán đoán về thiết kế — thuộc về một con người. Làm kỹ thuật cho phần này nghĩa là xây dựng những điểm bàn giao gọn gàng nơi một chuyên gia con người đã được thẩm định có thể tham gia vào, với cơ chế ký quỹ (escrow) bảo vệ giao dịch. Agent và mạng lưới con người không phải là hai lớp cạnh tranh nhau; chúng là một phương án dự phòng được thiết kế sẵn để làm cho toàn bộ hệ thống đủ an toàn để dựa vào.

Bài học cho các kỹ sư xây dựng agent

Nếu bạn đang xây dựng các hệ thống agent, một vài nguyên tắc sẽ hoàn vốn đầu tư cho bạn gấp nhiều lần.

Thiết kế giao diện công cụ chặt chẽ. Hầu hết các thất bại của agent đều bắt nguồn từ những công cụ mơ hồ. Schema nghiêm ngặt và I/O được kiểm chứng là độ tin cậy rẻ nhất mà bạn từng mua được.

Kiểm chứng theo kiểu đối kháng. Đừng tin vào một lượt chạy đầu tiên đầy tự tin. Hãy thêm một bước riêng biệt mà nhiệm vụ của nó là bác bỏ kết quả.

Đo lường bằng evals. Hãy xây bộ khung eval trước khi mở rộng quy mô agent. Bạn không thể cải thiện thứ bạn không thể chấm điểm.

Hãy thiết kế ngữ cảnh, đừng đổ tràn nó. Truy hồi những gì liên quan; ghi nhớ những gì quan trọng. Prompt dài hơn không phải là prompt tốt hơn.

Cô lập mọi thứ không đáng tin cậy trong sandbox. Nếu một agent chạy mã, sự cô lập là một điều kiện tiên quyết, không phải một tính năng.

Giữ một đường đi cho con người. Hệ thống tự động an toàn nhất là hệ thống biết khi nào cần hỏi một con người.

Câu hỏi thường gặp

Điều gì khiến một AI agent khác với một chatbot?

Một chatbot sinh ra văn bản; một AI agent lập kế hoạch và hành động — gọi công cụ, chạy mã, và lặp lại để tiến tới một mục tiêu. Khó khăn về mặt kỹ thuật nằm ở độ tin cậy xuyên suốt nhiều bước, nơi mà chỉ một lỗi đơn lẻ cũng có thể phá hỏng kết quả.

Làm thế nào để chạy mã do AI sinh ra một cách an toàn?

Bằng cách chạy mã trong sandbox (sandboxed code execution): mã không đáng tin cậy chạy trong một môi trường cô lập với tài nguyên hạn chế, không có quyền truy cập secret, và mạng bị ràng buộc, để agent có thể biên dịch, kiểm thử, và sửa lỗi mà không gây rủi ro cho nền tảng.

Tại sao evals lại quan trọng đến vậy đối với các hệ thống agent?

Bởi vì agent mang tính ngẫu nhiên, bạn cần đến evals tự động để đo lường chất lượng trên các tác vụ tiêu biểu và bắt được các điểm thoái lui trước khi triển khai. Không có chúng, những "cải tiến" chỉ là phỏng đoán.

Jobbit Labs làm gì?

Jobbit Labs (jobbitlabs.com) là bộ phận R&D và dữ liệu đứng sau Jobbit, tập trung vào phần kỹ thuật nặng hơn, thiên về dữ liệu, và cấp doanh nghiệp — nghiên cứu, nền tảng dữ liệu, và những nền móng agent mà sản phẩm được xây dựng trên đó.

Tò mò về kỹ thuật đằng sau những agent biết triển khai phần mềm? Khám phá jobbit.uk và jobbitlabs.com.