187 USD và 16 giờ: Trải nghiệm xây dựng ứng dụng với 1 triệu token và đội ngũ AI

06 tháng 4, 2026·14 phút đọc

Sự kết hợp giữa cửa sổ ngữ cảnh 1 triệu token và tính năng Agentic Teams của Claude đã cho phép tác giả xây dựng một ứng dụng web hoàn chỉnh chỉ trong một phiên làm việc kéo dài 16 giờ với chi phí 187 USD.

187 USD và 16 giờ: Trải nghiệm xây dựng ứng dụng với 1 triệu token và đội ngũ AI

Hai sự kiện công nghệ lớn đã diễn ra trong cùng một tuần: cửa sổ ngữ cảnh (context window) 1 triệu token và bản beta tính năng Agentic Teams của Claude. Một thứ mang đến không gian để suy nghĩ, còn thứ kia mang đến cách thức để song song hóa. Là một kỹ sư, tôi đã làm điều mà bất kỳ ai cũng sẽ làm: cố gắng "phá vỡ" cả hai bằng một dự án quá tham vọng.

Kế hoạch: Xây dựng hoàn chỉnh một ứng dụng web quản lý chiến dịch cashback — bao gồm backend, frontend, bộ test đầy đủ và triển khai container hóa — chỉ trong một phiên làm việc. Một điều phối viên (orchestrator). Tám tác nhân chuyên biệt (specialized agents) được triển khai như một đội ngũ. Không dừng lại cho đến khi ứng dụng live.

Những gì thực sự diễn ra còn thú vị hơn cả những thành công hay thất bại riêng lẻ.

Thiết lập hệ thống

Tính năng Agentic Teams là chìa khóa. Thay vì để một tác nhân làm mọi thứ tuần tự, tôi sử dụng một điều phối viên để tạo ra các tác nhân con chuyên biệt — mỗi tác nhân có một cửa sổ ngữ cảnh mới hoàn toàn và tập trung vào một lĩnh vực cụ thể:

  • Người triển khai Backend (Backend implementer) — Dịch vụ Spring Boot, các API endpoint, logic nghiệp vụ.
  • Người triển khai Frontend (Frontend implementer) — React SPA kết nối với backend.
  • Người kiểm tra QA (QA reviewer) — Chạy test, đánh dấu các khoảng trống, xem xét độ phủ mã.
  • Tác nhân triển khai (Deployment agent) — Dockerfile, tệp compose, cấu hình triển khai.
  • Tác nhân Git — Quản lý nhánh, commit, giữ kho mã sạch sẽ.
  • Xử lý PR (PR handler) — Tạo pull request, mô tả, phân công review.
  • Giám sát CI (CI monitor) — Theo dõi pipeline, phát hiện lỗi sớm.
  • Thông báo Slack — Cập nhật trạng thái về kênh nhóm.

Sự kết hợp giữa ngữ cảnh 1 triệu token và đội nhóm đã thay đổi hoàn toàn phương trình. Điều phối viên nắm giữ bức tranh toàn cảnh — kiến trúc, quyết định, điều phối — trong khi mỗi tác nhân con nhận được một ngữ cảnh mới hoàn toàn dành riêng cho lĩnh vực của mình. Không có sự ô nhiễm ngữ cảnh giữa các mối quan tâm. Cửa sổ của người làm backend không bị lộn xộn bởi các quyết định CSS. Tác nhân triển khai không phải gánh nặng đầu ra của các bài test.

Đó không phải là một cuốn sổ tay lớn hơn. Đó là một cách làm việc hoàn toàn khác về chất.

Những con số biết nói

Hãy xem "hóa đơn" trước khi đi vào câu chuyện chi tiết.

Hóa đơn phiên làm việc: 187 USD, 16 giờ, 729 bài test, sử dụng 34,8% ngữ cảnh điều phốiHóa đơn phiên làm việc: 187 USD, 16 giờ, 729 bài test, sử dụng 34,8% ngữ cảnh điều phối

Chỉ sốGiá trị
Tổng chi phí$186.92
Thời gian thực (Wall time)16 giờ
Thời gian API7 giờ 42 phút
Dòng mã được viết5,800+
Backend tests649 (tất cả pass)
End-to-end tests80 (tất cả pass)
Ngữ cảnh điều phối viên khi hoàn thành34.8% đã dùng

Khoảng cách giữa thời gian thực và thời gian API đã kể một câu chuyện riêng. Chín giờ chờ đợi — để build hoàn tất, để container khởi động, để pipeline CI chạy, và để tôi xem xét lại điều hướng. Hệ thống tác nhân thực sự rảnh rỗi hơn một nửa thời gian đồng hồ. Công việc đa tác nhân thường là về việc quản lý tính song song và các trạng thái chờ đợi hơn là thông lượng token thô.

Con số ngữ cảnh cần giải thích: 34,8% là mức sử dụng ngữ cảnh của điều phối viên — tác nhân trung tâm điều phối mọi thứ. Nhưng điểm mấu chốt của các đội nhóm tác nhân là: mỗi tác nhân con đều được tạo ra với một cửa sổ ngữ cảnh mới. Người triển khai backend đã tiêu hao phần lớn ngữ cảnh riêng để viết hơn 3.000 dòng mã Spring Boot. Người triển khai frontend đã lấp đầy một cửa sổ riêng với các thành phần React. Tổng số token tiêu thụ trên tất cả các tác nhân lớn gấp nhiều lần so với điều phối viên sử dụng.

Cửa sổ 1 triệu token quan trọng đối với khả năng của điều phối viên trong việc nắm giữ toàn bộ trạng thái dự án — mọi quyết định kiến trúc, trạng thái của mọi tác nhân, mọi sự cố và quá trình phục hồi — mà không bị mất mát khi tóm tắt. Các tác nhân con được hưởng lợi từ ngữ cảnh mới hoàn toàn dành riêng cho lĩnh vực của họ.

Điều phối viên sử dụng 34,8% ngữ cảnh 1 triệu token — mỗi tác nhân con có cửa sổ riêngĐiều phối viên sử dụng 34,8% ngữ cảnh 1 triệu token — mỗi tác nhân con có cửa sổ riêng

Chúng tôi đã xây dựng gì

Một ứng dụng web quản lý chiến dịch cashback. Người dùng đăng ký chiến dịch, gửi xác minh mua hàng và nhận tiền hoàn lại. Backend cung cấp các REST endpoint với đầy đủ xác thực, quản lý chiến dịch, xử lý gửi bài và xử lý thanh toán. Frontend xử lý hành trình của người dùng: danh sách chiến dịch, biểu mẫu gửi bài, theo dõi trạng thái và quản lý tài khoản.

649 bài test backend bao gồm unit, tích hợp và hợp đồng API. 80 bài test end-to-end kiểm tra các luồng người dùng hoàn chỉnh đối với hệ thống đã triển khai. Cả hai bộ test đều pass tại thời điểm triển khai.

Được đóng gói bằng Docker, triển khai lên máy chủ demo, có thể truy cập qua HTTPS. Toàn bộ stack đã live — không phải là prototype hay local-dev, mà thực sự được triển khai và chạy với một URL có thể chia sẻ.

Tất cả trong một phiên làm việc.

Những gì đã bị hỏng

Ba thứ đã bị hỏng theo những cách đáng để ghi nhận.

Tác nhân tinh chỉnh UI bị treo giữa phiên. Khoảng 10 giờ vào phiên làm việc, tôi khởi chạy một tác nhân thêm để làm đẹp giao diện frontend. Nó bắt đầu làm việc, sau đó ngừng tạo đầu ra, rồi lại bắt đầu, sau đó ngừng vĩnh viễn. Quy trình vẫn đang chạy — tiêu thụ token nhưng không trả lại ý nghĩa nào. Tôi phải buộc dừng nó và phân phối lại các nhiệm vụ còn lại cho người triển khai frontend. Nguyên nhân: không rõ. Giả thuyết: ngữ cảnh đã tích lũy đủ tín hiệu mơ hồ khiến tác nhân rơi vào cực tiểu cục bộ (local minimum) và không thể thoát ra mà không có sự can thiệp của con người.

Cấu hình Docker yêu cầu nhiều chu trình debug. Ba nỗ lực đầu tiên của tác nhân triển khai cho Dockerfile tạo ra các hình ảnh build thành công nhưng thất bại khi chạy. Các chế độ thất bại khác nhau mỗi lần: tên biến môi trường sai, thiếu endpoint kiểm tra sức khỏe, đường dẫn mount volume không khớp. Không vấn đề nào khó khăn — đó là loại vấn đề mất 10 phút để sửa khi bạn biết sai ở đâu. Nhưng mỗi chu kỳ mất 15-20 phút thời gian build, cộng lại là một khoản lớn. Tác nhân không sai một cách có hệ thống; nó sai một cách ngẫu nhiên, điều này khó chẩn đoán hơn.

CORS whitelist bị thiếu trong lần triển khai đầu tiên. Backend đã triển khai, frontend đã triển khai, chúng tôi truy cập URL thực từ trình duyệt — và gặp lỗi CORS. Frontend và backend nằm trên các nguồn gốc khác nhau và không ai cấu hình các nguồn được phép trong API. Đây là loại vấn đề hiển nhiên một cách tầm thường khi nhìn lại và vô hình khi bạn đang nghĩ về mọi thứ khác. Chúng tôi sửa nó trong 20 phút, nhưng khoảng cách giữa "nó chạy trong test" và "nó chạy khi bạn thực sự mở trình duyệt" là có thật và không nên được xem nhẹ.

Những thất bại này đều có thể phục hồi. Không cái nào là thảm khốc. Nhưng chúng đáng được gọi tên vì câu chuyện "đội ngũ AI đa tác nhân xây dựng ứng dụng hoàn chỉnh trong một phiên" có thể khiến mọi thứ nghe mượt mà hơn thực tế.

187 USD có đáng giá không?

Đây là câu hỏi mà mọi người đều hỏi.

$186.92 cho một ứng dụng web hoàn chỉnh, đã triển khai và đã test. Câu hỏi là: so với cái gì?

Ước tính của tôi cho việc phát triển hệ thống này một mình — làm vào buổi tối và cuối tuần, chế độ thực tế cho một dự án phụ — là hai đến ba tuần. Đó có lẽ là 40-60 giờ lập trình thực tế, trải dài trong một tháng dương lịch. Bạn không thể làm nhanh hơn bằng cách làm việc chăm chỉ hơn; bạn làm nhanh hơn bằng cách có nhiều giờ hơn.

Phiên làm việc này đã nén tất cả vào một khoảng thời gian dài — bắt đầu vào tối ngày 17 và kéo dài đến những giờ đầu của ngày 18. Không chỉ về thời gian thực, mà còn về ngữ cảnh. Khi bạn làm việc qua ba buổi tối, bạn dành một phần không nhỏ của mỗi buổi để thiết lập lại ngữ cảnh. Tôi đã xây dựng cái gì lần trước? Tôi dừng lại ở đâu? Tại sao tôi đưa ra quyết định kiến trúc này? Cửa sổ ngữ cảnh 1M token đảm bảo điều đó không bao giờ xảy ra. Mọi tác nhân tại mọi thời điểm đều có quyền truy cập vào trạng thái đầy đủ của dự án.

Sự nén ngữ cảnh đó chính là giá trị. $187 không phải trả cho việc sinh mã — bạn có thể nhận được sinh mã giá rẻ. Nó trả cho sự liên tục không bị gián đoạn trên toàn bộ dự án, từ kho mã trống đến ứng dụng đã triển khai.

187 USD có nhiều không? Nó là một bữa ăn tối. Nó ít hơn một giờ tư vấn. Với những gì nó tạo ra, nó rẻ một cách nực cười nếu đầu ra có thể sử dụng được — và trong trường hợp này, đầu ra có thể sử dụng được.

Câu hỏi ROI trở nên khó hơn khi bạn hỏi: "Được thôi, nhưng tôi trả 187 USD cho mỗi tính năng, nó sẽ mở rộng thế nào?" Công bằng. Nếu bạn chạy các phiên như vậy hàng tuần, bạn đang chi 800-1000 USD một tháng cho ngữ cảnh. Đó không phải là không có gì. Nhưng bạn cũng đang nén nhiều tuần làm việc vào nhiều ngày, và cơ sở so sánh nên là "tôi sẽ trả bao nhiêu cho một nhà thầu" thay vì "tôi sẽ trả bao nhiêu cho tính toán".

1 triệu token thực sự thay đổi điều gì

Tiếp thị xung quanh các cửa sổ ngữ cảnh lớn thường mơ hồ theo những cách che khuất giá trị thực sự.

Không phải về việc nhét nhiều tệp hơn vào. Bạn luôn có thể tải nhiều tệp hơn vào nhiều phiên. Điểm không phải là dung lượng lưu trữ.

Là về việc điều phối viên nắm giữ bức tranh toàn cảnh. Cửa sổ 1M cho phép tác nhân điều phối theo dõi mọi quyết định, mọi thất bại, mọi lựa chọn kiến trúc trong suốt phiên 16 giờ mà không bao giờ phải tóm tắt hay mất đi sắc thái. Khi tác nhân backend báo cáo thay đổi lược đồ, điều phối viên chuyển ngữ cảnh đó cho tác nhân frontend một cách chính xác — không phải qua bản tóm tắt bị mất mát, mà qua quyết định thực tế với lý luận còn nguyên vẹn.

Các đội nhân lên ngữ cảnh hiệu quả. Tám tác nhân, mỗi người có cửa sổ ngữ cảnh riêng, có nghĩa là bộ nhớ làm việc tổng của hệ thống lớn hơn nhiều so với 1 triệu token. Mỗi chuyên gia nhận được một cửa sổ mới tập trung vào lĩnh vực của họ. Cửa sổ 1M của điều phối viên điều phối giữa chúng. Đó không phải là một ngữ cảnh lớn — đó là một kiến trúc của các ngữ cảnh.

Nó loại bỏ "thuế tóm tắt" tại lớp điều phối. Các cửa sổ điều phối viên ngắn hơn có nghĩa là bạn phải liên tục tóm tắt: "đây là những gì tôi xây dựng, đây là trạng thái hiện tại, đây là những gì đang thất bại." Mọi bản tóm tắt đều gây ra mất mát. Với 1 triệu token trên điều phối viên, mọi thứ diễn ra trên tất cả tám tác nhân vẫn có thể theo dõi được. Không có bàn giao mất mát.

Nó làm cho các thất bại có thể phục hồi mà không cần khởi động lại. Khi tác nhân UI bị treo phải bị dừng, điều phối viên vẫn có ngữ cảnh hoàn chỉnh về những gì nó đã cố gắng. Khởi chạy một tác nhân thay thế với các hướng dẫn đúng là đơn giản — điều phối viên biết chính xác công việc đã dừng ở đâu.

Đó là lý do tôi mô tả nó là một cách xây dựng phần mềm khác. Không phải là phiên bản lớn hơn của cách cũ. Một chế độ mới trở nên khả thi khi bạn kết hợp một ngữ cảnh điều phối viên lớn với các tác nhân song song chuyên biệt.

Những gì tôi sẽ làm khác biệt

Không nhiều — nhưng có một vài thứ.

Tôi sẽ thêm cấu hình CORS vào danh sách kiểm tra triển khai ngay từ đầu. Không phải vì thêm nó khó, mà vì nó thường xuyên bị quên và tốn thời gian. Mô hình này đủ nhất quán để trở thành kiến thức thể chế.

Tôi sẽ xây dựng các kiểm tra sức khỏe tác nhân rõ ràng. Tác nhân UI bị treo đã chạy hơn một giờ trước khi tôi nhận ra nó không tạo ra đầu ra hữu ích. Một quy tắc đơn giản "nếu không có đầu ra có ý nghĩa trong X phút, hãy gắn cờ để xem xét của con người" sẽ bắt nó nhanh hơn.

Tôi sẽ quyết liệt hơn trong việc chia nhỏ công việc frontend từ trước. Ở quy mô của một ứng dụng hoàn chỉnh, người triển khai frontend có nhiều diện tích bề mặt. Chia nhỏ nó thành các thành phần UI và tích hợp dữ liệu ngay từ đầu sẽ song song hóa nhiều công việc hơn.

Điểm cốt lõi

Tôi đã làm điều này vào tháng 2 năm 2026. Cửa sổ ngữ cảnh 1 triệu token là mới. Bản beta Agentic Teams là mới. Các mô hình điều phối đa tác nhân là những thứ tôi đã xây dựng trong nhiều tháng. Mọi thứ đã hội tụ cùng một lúc.

Điều ấn tượng tôi nhất không phải là đầu ra — mà là trải nghiệm xây dựng. Trong mười sáu giờ, tôi không gõ phím. Tôi không viết mã. Tôi đưa ra quyết định, xem xét đầu ra, điều hướng lại các tác nhân, suy nghĩ về kiến trúc. Việc triển khai được xử lý. Suy nghĩ là của tôi.

Đó là chế độ mà tôi nghĩ kỹ thuật tác nhân đang hướng tới: không phải "AI viết mã cho tôi" mà là "tôi kiến trúc trong khi AI triển khai, liên tục, theo thời gian thực". Phiên làm việc không phải là mười sáu giờ nhìn thanh tiến trình. Đó là mười sáu giờ làm việc sáng tạo có định hướng, ở một mức độ trừu tượng cao hơn mã.

Dù điều đó thú vị hay đáng lo ngại phụ thuộc vào vị trí của bạn. Đối với tôi, nó là cả hai, điều này thường là dấu hiệu của một điều gì đó thực sự đang xảy ra.

187 USD là tiền được tiêu tốt. Mười sáu giờ đã dạy tôi nhiều hơn về thiết kế hệ thống đa tác nhân so với bất kỳ hướng dẫn nào. Hóa đơn nằm ngay đó trong bảng tính toán API.

Bây giờ tôi biết cảm giác một triệu token từ bên trong là như thế nào. (Những gì tôi học tiếp theo — làm cho các hệ thống đó sẵn sàng cho sản xuất — có trong "Production Hardening".)

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗