Giải mã khóa học AI: Ba mô hình vận hành Agent và bài toán kinh tế từ nhà cung cấp

Hầu hết các đội ngũ đều coi "chọn mô hình nào" là quyết định quan trọng nhất. Tuy nhiên, các tài liệu kỹ thuật về harness (bộ khung điều khiển) lại chỉ ra điều ngược lại. Trong thí nghiệm Terminal-Bench của LangChain, chỉ cần thay đổi harness—trong khi vẫn giữ nguyên mô hình—đã giúp một coding agent nhảy vọt từ vị trí thứ 30 lên top 5.

Kết quả đó định hình lại vấn đề. Nếu harness quyết định chất lượng, thì cách bạn vận hành vòng lặp (loop) trở thành một quyết định về kiến trúc, chứ không phải chi tiết triển khai. Khóa học mã nguồn mở "Building a Coding Agent From Scratch" của Paul Iusztin đã xây dựng một Python agent có tên là Decode. Được xuất bản thông qua Decoding AI, nó phân tách thành ba chế độ chạy. Mỗi chế độ có một cấu hình độ trễ khác nhau. Do đó, mỗi chế độ lại cần một nhà cung cấp dịch vụ suy luận (inference provider) khác nhau.

Một lõi headless, ba hình thái

Trung tâm của hệ thống là một harness headless không có giao diện riêng. Bên trong nó chạy vòng lặp agent mà mọi harness đều chia sẻ: LLM chọn một hành động, một công cụ thực thi, và quan sát được phản hồi lại. Mọi thứ đều đọc từ và ghi vào context window.

Bản thân agent rất nhỏ gọn. Trong Decode, nó chỉ là một định nghĩa Pydantic AI khoảng 20 dòng bao gồm mô hình, công cụ và kiểu đầu ra. Trong mã nguồn bị rò rỉ của Claude Code, vòng lặp cốt lõi chỉ khoảng 150 dòng. Mọi thứ khác—bộ nhớ, kỹ năng, sandbox, quyền hạn, phản hồi LSP, nén dữ liệu—đều thuộc về harness.

Sau đó, các giao diện sẽ được kết nối vào lõi đó. Đó là nơi xuất hiện ba chế độ:

Chế độ 1: Tương tác, trực tuyến (Interactive, online)

Một giao diện dòng lệnh (terminal UI) được kết nối với một phiên làm việc trực tiếp, nằm trong bộ nhớ, trong cùng một tiến trình. Các sự kiện được truyền ngược lại thông qua các async generator khi token đến.

Vấn đề khó ở đây là việc điều hướng (steering). Nếu bạn nhập liệu trong khi một lệnh gọi công cụ đang thực thi, việc chèn tin nhắn ngay lập tức sẽ làm hỏng lượt hội thoại. Giải pháp của Decode là một hàng đợi điều hướng cộng với một cổng ưu tiên. Dữ liệu đầu vào được lưu vào bộ đệm khi đến và chỉ được chèn vào tại một ranh giới an toàn. Vòng lặp cung cấp hai ranh giới: MODEL_REQUEST, trước khi gọi mô hình tiếp theo, và WOULD_STOP, khi lượt hội thoại sắp kết thúc.

Ba chế độ nhập liệu ánh xạ vào điều đó. Phím Enter thông thường điều hướng trong lượt hội thoại. Alt+Enter xếp hàng một yêu cầu tiếp theo cho đến khi lượt hội thoại dừng lại. Esc kích hoạt một lệnh hủy hợp tác tại ranh giới tiếp theo, xóa cả hai hàng đợi để lịch sử vẫn được giữ nguyên.

Con người đang đọc từng token. Chế độ này bị giới hạn bởi độ trễ, đó là lý do tại sao nó phù hợp với các API được lưu trữ có độ trễ thấp.

Chế độ 2: Từ xa, ngoại tuyến (Remote, offline)

Chế độ từ xa giữ cho harness ở dạng headless và chạy nó trên máy chủ thông qua một agent runtime. Decode sử dụng Kitaru, agent runtime của ZenML, được triển khai trên GCP, với các agent thực thi trên Modal.

Không có ai giám sát. Một danh sách các tác vụ (backlog) được phân phối đến N harness song song, mỗi harness tạo ra PR riêng của mình. Vì runtime ghi lại tiến trình từng bước, một sandbox bị ngắt giữa chừng sẽ tiếp tục từ bước đã ghi cuối cùng thay vì khởi động lại. Một tiến trình tạm dừng để chờ con người nhập liệu sẽ đóng băng và không tiêu tốn tài nguyên tính toán trong khi chờ đợi.

Các công cụ thực thi bên trong Modal Sandboxes từ xa, hoặc Docker cục bộ. Chỉ số quan trọng ở đây là thông lượng trên mỗi đô la, không phải thời gian để có token đầu tiên.

Chế độ 3: Bất đồng bộ, trực tuyến (Async, online)

Hình thái thứ ba nằm giữa hai loại trên. Một phiên làm việc trực tiếp chuyển công việc vào hàng đợi tác vụ và trả về kết quả ngay lập tức. Các quy trình nền sẽ phân phối các lệnh gọi LLM và đăng kết quả lại sau.

Người dùng đang trực tuyến nhưng không theo dõi từng bước. Hàng đợi chịu trách nhiệm cho công việc, vì vậy tiến trình vẫn tồn tại ngay cả khi client khởi tạo nó đã đóng. Đây là mô hình đằng sau các agent kích hoạt qua Slack và đánh giá PR nền, và nó được tính phí như xử lý theo lô (batch), không phải như chat.

Giải thích tương tác

Tại sao nhà cung cấp thay đổi theo chế độ

Mô hình chi phí tuân theo yêu cầu về độ trễ, và khoảng cách này là rất lớn.

Hãy lấy ví dụ với 1.000 tài liệu, mỗi tài liệu 30.000 token đầu vào, khoảng 500 token đầu ra mỗi tài liệu. Với mức giá API tiên phong là 3 USD cho mỗi triệu token đầu vào và 15 USD cho mỗi triệu token đầu ra, phép tính cho bài học này rơi vào khoảng 97 USD. Prompt caching không giải quyết được vấn đề này vì mỗi tài liệu có một tiền tố khác nhau. Khi xử lý theo lô trên GPU serverless với tốc độ khoảng 3.000 token mỗi giây, cùng khối lượng công việc đó chỉ mất dưới ba giờ thời gian GPU—khoảng 13 USD.

Trường hợp ngược lại cũng rõ ràng không kém. Mô hình kiểm thử mặc định của Decode, Qwen3.6 35B, chạy trên một chiếc H200 duy nhất. Bảng giá công khai của Modal cho H200 SXM là 0,001261 USD mỗi giây, hay khoảng 4,54 USD mỗi giờ. Nếu để một agent tương tác chạy không tải qua đêm để chờ xác nhận "y", mười giờ nhàn rỗi đó sẽ cộng thêm khoảng 45 USD vào hóa đơn.

Đó chính là toàn bộ lập luận. Công việc tương tác trả phí theo token vì con người đang chờ đợi. Công việc ngoại tuyến và bất đồng bộ trả phí theo giờ GPU vì thông lượng là mục tiêu và thời gian nhàn rỗi là kẻ thù.

Có một trục thứ hai: serverless so với dung lượng dự trữ (reserved capacity). Phân tích giá của Modal quy nó về một sự so sánh duy nhất. Các hợp đồng dự trữ tính phí theo mức giá cao nhất cho toàn bộ hợp đồng; serverless tuân theo đường cong nhu cầu. Khi tỷ lệ đỉnh-trên-trung bình vượt quá mức chiết khấu dự trữ, serverless sẽ rẻ hơn. Modal báo cáo mức chiết khấu thông thường từ 2–5 lần so với tỷ lệ đỉnh-trung bình từ 5–10 lần cho suy luận, đào tạo và phát triển agent. Các khảo sát trong ngành mà họ trích dẫn cho thấy mức sử dụng dự trữ dưới 30%, thường là dưới 10%.

Những điểm chính cần lưu ý

Nguồn:

Michal Sutter là một chuyên gia khoa học dữ liệu với bằng Thạc sĩ Khoa học Dữ liệu từ Đại học Padova. Với nền tảng vững chắc về phân tích thống kê, học máy và kỹ thuật dữ liệu, Michal xuất sắc trong việc chuyển đổi các tập dữ liệu phức tạp thành những thông tin chi tiết có thể hành động được.