Antigravity Swarm vs Teamwork khác nhau chủ yếu ở cách tổ chức công việc. Swarm hợp với nhiệm vụ tách được thành các phần độc lập, phối hợp trên bảng tin chung. Teamwork thiên về dự án nhiều mốc, chốt yêu cầu trước khi chạy và có các tầng kiểm định riêng. Cả hai đều có điều phối, làm song song và kiểm tra kết quả.

Bật thêm agent chưa chắc giải quyết được một dự án đang rối. Ba file xử lý độc lập khác hẳn một đợt chuyển đổi framework có nhiều phụ thuộc. Chọn đúng cơ chế quan trọng hơn việc chọn đội đông nhất.

Đối chiếu tài liệu Google ngày 12/11/2026. Đây là phân tích tài liệu sản phẩm, không phải benchmark hoặc báo cáo thử nghiệm của DPS.MEDIA.

Với nhóm đang phát triển ứng dụng AI từ bản mẫu đến production, lựa chọn multi-agent nên đi cùng tiêu chí kiểm thử, quyền sửa mã và cách bàn giao. Một bản demo chạy được chưa đồng nghĩa sản phẩm đã sẵn sàng vận hành.

So sánh nhanh Swarm và Teamwork trong Antigravity

Swarm đặt trọng tâm vào chia việc rõ và trao đổi công khai trên một board. Teamwork tổ chức cả vòng đời dự án: phỏng vấn phạm vi, duyệt đặc tả, triển khai theo milestone và kiểm định trước bàn giao. Bảng dưới đây tổng hợp khác biệt từ hai tài liệu chính thức.

Không nên đọc hàng cuối như cam kết tốc độ. Google dùng khoảng thời gian để mô tả loại công việc phù hợp, không công bố rằng hai chế độ đã chạy cùng một đề bài để đo thắng thua.

Swarm: chia việc độc lập, phối hợp trên một bảng tin

Khi chạy Swarm, cuộc hội thoại hiện tại trở thành coordinator. Agent này chia nhiệm vụ, đặt tên worker và giao phạm vi không chồng lấn. Mỗi worker mở một hội thoại với ngữ cảnh sạch; brief ghi rõ được sửa gì, không được chạm vào đâu và thế nào là hoàn thành.

Coordinator không tự ôm phần triển khai

Tài liệu nói rõ coordinator giao việc, đánh giá đầu ra và báo cáo cho người dùng, thay vì tự làm phần kỹ thuật. Nó vẫn có thể phản hồi khi workers đang chạy. Bạn có thể thay đổi ưu tiên qua coordinator, không cần gõ lại yêu cầu cho từng thành viên.

Ví dụ giả định: một dịch vụ có ba API xử lý người dùng, đơn hàng và sản phẩm. Nếu ranh giới file đã rõ, mỗi worker thêm validation và test cho một API. Coordinator tổng hợp; verifier kiểm tra cả bộ thay đổi. Khó khăn nằm ở ranh giới công việc, không phải ở việc mở thêm ba cửa sổ chat.

Shared board giữ trao đổi giữa các agent ở một nơi

Brief, câu hỏi, tóm tắt diff và kết quả test được đăng lên board bằng @name, @group hoặc @all. Workers không nhắn riêng cho nhau. Riêng người dùng vẫn có thể nhắn trực tiếp một worker; tin đó không được đưa lên board.

Trong App, các tab Board, Members và Graph cho phép xem trao đổi, trạng thái và quan hệ nhắc tên. Với CLI, dùng /swarm board hoặc Alt+S. Graph thể hiện tương tác, không phải chứng nhận chất lượng mã.

Verifier kiểm tra, monitor gỡ tình trạng đình trệ

Theo tài liệu, coordinator thường thêm một verifier cho mỗi hai đến bốn workers. Verifier đọc diff, chạy test và trả vấn đề về đúng người thực hiện để sửa. Đây là cách bố trí thường dùng, không phải lời khẳng định mọi swarm có số thành viên cố định.

Monitor có nhiệm vụ khác: chờ khi đội còn tiến triển và lên tiếng nếu mọi thành viên đều im lặng trước khi xong việc. Worker đang chờ trên board không dùng token và được đánh thức khi có người nhắc tên. Tuy vậy, thời gian suy nghĩ, dùng công cụ và trao đổi khi hoạt động vẫn cần được tính đến.

Teamwork: chốt đặc tả, làm theo milestone và kiểm định nhiều tầng

Teamwork dành trọng tâm cho mục tiêu lớn cần duy trì trạng thái qua nhiều chặng. Thay vì bắt đầu triển khai ngay sau câu lệnh, agent phỏng vấn để làm rõ yêu cầu và tạo prompt artifact cho bạn duyệt. Chỉ khi được chấp thuận, đội mới bước sang giai đoạn thực thi tự chủ.

Hai giai đoạn giúp tách yêu cầu khỏi cách triển khai

Giai đoạn đầu tuân theo nguyên tắc “nêu cần gì, không áp đặt làm thế nào”. Bạn cùng agent thống nhất mục tiêu, đối tượng sử dụng, yêu cầu, phép kiểm tra độc lập và tiêu chí hoàn thành. Workspace mặc định là ~/teamwork_projects/{PROJECT_NAME}.

Sau phê duyệt, Sentinel điều phối cấp ngoài và giao dự án cho Project Orchestrator. Orchestrator chia milestone, tổ chức các nhánh song song và ủy nhiệm công việc. Giữa các milestone, vai trò này bàn giao cho một người kế nhiệm mới nhằm hạn chế suy giảm ngữ cảnh.

Explorers chỉ đọc để khảo sát repository và đánh giá hướng giải quyết. Workers triển khai, refactor và viết unit test trong phần việc riêng. Request artifact giữ mục tiêu; project plan giữ lộ trình; progress artifact ghi tiến độ. Các tài liệu đó là nền tảng bàn giao, thay vì phụ thuộc vào một cuộc chat ngày càng dài.

Bốn vai trò kiểm định không làm cùng một việc

• Critic: review độc lập về tính đúng, tính đầy đủ, độ vững, hợp đồng giao diện và phong cách mã.
• Challenger: tạo ca biên, đường lỗi và đầu vào bất lợi để thử sức chịu đựng của giải pháp.
• Auditor: đối chiếu integrity mode và kiểm tra bằng chứng test với đầu ra lệnh thực tế.
• Success Auditor: kiểm tra end-to-end cuối cùng trước khi Sentinel trình kết quả hoàn tất.

Giá trị của Teamwork nằm ở quy trình đối chứng, không phải lời hứa “nhiều người kiểm thì hết bug”. Đội kỹ thuật vẫn cần xác định đúng bài test, môi trường và tiêu chí chấp nhận.

Integrity mode là chính sách làm việc, không phải gói giá

development là mặc định, cho phép dùng thư viện, framework và tái sử dụng mã nhưng vẫn đánh dấu đầu ra giả hoặc triển khai chỉ có bề ngoài. demo cấm thêm những shortcut như sao chép logic cốt lõi và đọc mã test để suy ngược hành vi mong đợi.

benchmark nghiêm ngặt nhất: triển khai độc lập từ đầu, chỉ dùng thư viện chuẩn của ngôn ngữ. Không nên chọn mode này cho dự án tích hợp thông thường chỉ vì tên nghe chuyên nghiệp hơn. Hãy nêu rõ những shortcut bị cấm trong bước chốt yêu cầu.

Nên chọn Swarm hay Teamwork cho việc cụ thể?

Hãy nhìn vào cấu trúc phụ thuộc và cách nghiệm thu trước khi nhìn vào số file. Nếu từng phần có thể làm riêng rồi kiểm tra chung, Swarm thường là điểm bắt đầu hợp lý. Nếu dự án cần nhiều mốc, bàn giao trạng thái và các cổng kiểm định, Teamwork sát mục tiêu hơn.

Chọn Swarm khi chia phần việc đã đủ rõ

Những tình huống phù hợp gồm thêm test cho các module độc lập, sửa lỗi theo từng package hoặc điều tra ba giả thuyết riêng về lỗi khởi động. Với điều tra, có thể yêu cầu workers chỉ đọc. Tài liệu cũng cho phép đặt verifier trên model khác, miễn model đó có trong danh sách bạn được chọn.

Không nên để hai worker cùng sửa một file cấu hình rồi hy vọng coordinator tự xử lý. Swarm dùng chung workspace mặc định. Khi cần, coordinator có thể cấp working copy riêng; phải đưa thay đổi về trước khi xóa worker vì thao tác đó xóa cả bản làm việc riêng.

Chọn Teamwork khi thành công cần nhiều mốc kiểm chứng

Giả định bạn chuyển dịch vụ từ Express sang Fastify, vẫn phải giữ hợp đồng API, kiểu TypeScript và hành vi lỗi. Đó không chỉ là danh sách file: thay đổi middleware có thể ảnh hưởng authentication, logging và kiểm thử tích hợp. Milestone và tiêu chí chấp nhận giúp kiểm soát những phụ thuộc này.

Một ngoại lệ đáng nhớ: Teamwork có nhánh iterative coding nhẹ cho thay đổi tự chứa, kích hoạt bằng tín hiệu như keep it small hoặc keep it focused. Nhánh này không phân rã tác vụ. Ngoài coding, tài liệu còn mô tả document review và math/proof. Vì thế, “Swarm cho việc nhỏ, Teamwork chỉ cho việc lớn” là cách nhớ thiếu chính xác.

Mẫu prompt: nêu ranh giới và bằng chứng hoàn thành

Prompt tốt cho cả hai chế độ cần nói rõ đầu ra, giới hạn thay đổi và phép kiểm tra. Swarm hưởng lợi từ ranh giới phần việc độc lập. Với Teamwork, nên mô tả kết quả mong muốn và để cuộc phỏng vấn làm rõ đặc tả, thay vì tự áp đặt sơ đồ agent.

Ví dụ minh họa cho repository TypeScript có bộ test sẵn:

/swarm Thêm validation cho src/routes/users.ts và src/routes/orders.ts. Mỗi worker phụ trách một handler và test tương ứng, không sửa file của worker khác. Verifier chạy npm test, kiểm tra diff và xác nhận không xóa assertion để làm test pass.

Ví dụ mở đầu dự án migration:

/teamwork Chuyển dịch vụ REST từ Express sang Fastify, giữ nguyên hợp đồng API và hành vi lỗi. Mục tiêu là chạy production. Hãy phỏng vấn để chốt phạm vi, môi trường kiểm thử và tiêu chí chấp nhận trước khi triển khai. Không giả kết quả test; mọi kết luận cần có log lệnh thực tế.

Các đường dẫn và lệnh trên chỉ là ví dụ, cần đổi theo repository thật. Với dự án chứa dữ liệu khách hàng hoặc thông tin xác thực, nên bổ sung giới hạn truy cập ngay từ đầu; không mặc định mọi agent cần quyền triển khai production.

Giới hạn cần biết trước khi giao việc cho nhiều agent

Hai tài liệu không cung cấp benchmark đối đầu về thời gian, tổng token, chi phí hay tỷ lệ sửa lỗi. Do đó, chưa có cơ sở từ các nguồn này để kết luận Swarm luôn rẻ hơn hoặc Teamwork luôn chính xác hơn. Hãy đo trên tác vụ đại diện và tính cả thời gian review.

Swarm có lưu ý vận hành riêng: thành viên hết quota sẽ tạm dừng, không tự chạy lại chỉ vì quota đã hồi. Bạn cần có bài đăng mới, đổi model hoặc nhắn cho thành viên để tiếp tục. Worker bị xóa cũng không thể hồi sinh; coordinator phải thêm worker mới.

Với cả hai chế độ, hãy đọc diff và log kiểm thử thay vì chỉ đọc câu “đã xong”. Những phần phụ thuộc chặt vẫn phải tuân theo thứ tự; tăng số worker không làm dependency biến mất. Các biện pháp phân quyền file cũng không thay thế kiểm soát secrets, backup và phê duyệt phát hành.

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

Swarm có phải các agent tự làm, không có người điều phối?

Không. Conversation hiện tại trở thành coordinator, chia việc và tổng hợp kết quả. Workers, verifier và monitor phối hợp qua board. Mô hình này có điều phối rõ ràng, không phải một nhóm agent hoạt động tự phát.

Teamwork có chạy song song không?

Có. Project Orchestrator tổ chức các workstream song song với phạm vi file riêng. Điểm khác biệt không phải Swarm song song còn Teamwork tuần tự, mà là Teamwork quản trị dự án qua đặc tả, milestone, artifact và kiểm định.

Có dùng được trên cả App và CLI?

Có. Cả hai trang tài liệu đều liệt kê Antigravity App và Antigravity CLI. Cách xem tiến độ khác nhau theo giao diện, nhưng nguyên tắc chọn chế độ dựa trên cấu trúc công việc vẫn giữ nguyên.

Nên chọn chế độ nào nếu chưa rõ yêu cầu?

Nên làm rõ mục tiêu và tiêu chí nghiệm thu trước. Teamwork có sẵn bước phỏng vấn phạm vi, nhưng điều đó không thay thế quyết định sản phẩm của bạn. Khi chỉ cần một việc phụ nhỏ, subagent thông thường cũng có thể đủ, không nhất thiết mở cả đội.

Kết luận: chọn cách phối hợp, không chọn đội đông nhất

Chọn Swarm nếu bạn cần chia một nhiệm vụ thành các phần tương đối độc lập và muốn theo dõi trao đổi trên board. Chọn Teamwork khi cần chốt đặc tả, đi qua nhiều milestone, bàn giao ngữ cảnh và kiểm định nhiều tầng. Hãy bắt đầu bằng đầu ra đo được, ranh giới file và một cách chứng minh “đã hoàn thành”.

Nguồn chính thức: Google Antigravity — Swarm và Google Antigravity — Teamwork agent teams. Tính năng có thể thay đổi sau ngày đối chiếu.

Biên soạn: CÔNG TY CỔ PHẦN DPS.MEDIA · 56 Nguyễn Đình Chiểu, P. Tân Định, TP. HCM · Email: marketing@dps.media · Hotline/Zalo: 0961 545 445.