Agent đầu tiên trong một nhóm là câu chuyện về năng suất cá nhân. Đến agent thứ năm, đó đã là câu chuyện của cả tổ chức. Ở khoảng giữa hai cột mốc ấy, một nhóm thôi chỉ còn là tập thể dùng AI và trở thành nhóm agentic: con người và agent cùng làm việc trên một bảng, cùng một nhiệm vụ, dưới những quy tắc mà ai đó đã phải ngồi viết ra.
Chính ở bước chuyển này mới nảy sinh phần lớn những câu hỏi thú vị. Ai chịu trách nhiệm cho công việc mà agent đã thực hiện? Buổi standup còn nói về điều gì khi bảng công việc tự cập nhật? Một người review có thể hấp thụ được bao nhiêu agent? Hướng dẫn này bàn về thành phần của một nhóm agentic, cách phân chia công việc nào trụ được khi chạm vào công việc thực tế, và những thỏa thuận làm việc đáng để học theo. Sharkly là nền tảng chúng tôi xây dựng cho kiểu nhóm này, và những kiểu thất bại dưới đây đến từ việc quan sát chúng đi sai hướng.
TL;DR
Nhóm agentic là tập thể mà cả con người lẫn AI agent đều nắm phần việc được giao trong cùng một hệ thống, với con người giữ vai trò định hướng, thẩm quyền và nghiệm thu. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người đặt định hướng, cấp thẩm quyền và nghiệm thu kết quả. Yêu cầu thực tế gồm: một bản ghi nhiệm vụ mà cả hai đều đọc được, người thực thi tách biệt với người chịu trách nhiệm, một trạng thái review có người nhận, và phạm vi được viết đủ rõ để agent không phải đoán.
Một nhóm agentic gồm những gì
Có ba loại thành viên tham gia, và gọi tên chúng cho thật chính xác sẽ rất hữu ích.
Con người tạo và cập nhật nhiệm vụ, bình luận, nhận các mục trong hàng đợi, được giao việc, review kết quả của agent và quản lý những cài đặt mà vai trò của họ cho phép. Họ là những thành viên duy nhất có thể chịu trách nhiệm.
Agent là những cấu hình làm việc được lưu lại chứ không phải prompt dùng một lần: chỉ dẫn, runtime như Claude Code hay Codex, repository, môi trường, cài đặt chạy và các skill được gắn kết. Một agent gần với một vai trò được ghi thành văn bản hơn là với một con người. Bài giải thích về Sharkly Agents của chúng tôi nói rõ một agent gồm những gì.
Crew nhóm nhiều agent dưới một agent trưởng cho những công việc cần phối hợp. Việc thực thi diễn ra theo thứ tự trưởng nhóm trước: agent trưởng đọc nhiệm vụ và chỉ dẫn của crew, sau đó hoặc tự xử lý công việc, hoặc kéo thêm những thành viên cụ thể vào. Thứ tự này tồn tại để ngăn mọi thành viên lao vào cùng lúc. Chi tiết có trong hướng dẫn về Sharkly Crews của chúng tôi.
Quyền truy cập được xếp thêm lên trên: vai trò trong tổ chức quyết định năng lực quản trị ở mức rộng, còn tư cách thành viên của space quyết định người đó chạm được tới những khu vực công việc nào. Agent cũng được giới hạn phạm vi theo cách tương tự, tới những repository và những máy cụ thể.
Cách phân chia công việc hiệu quả
Nguyên tắc của chính Sharkly là một mặc định tốt, vì nó đủ hẹp để có thể thực thi: agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người đặt định hướng, cấp thẩm quyền và nghiệm thu kết quả.
Bốn trách nhiệm luôn thuộc về con người, bất kể agent có giỏi đến đâu.
- Định hướng. Quyết định việc gì đáng làm và làm theo thứ tự nào.
- Ngữ cảnh. Viết ra phạm vi mà agent có thể hành động dựa trên đó: vì sao công việc này quan trọng, những gì nằm ngoài phạm vi, các file và ràng buộc liên quan, và kết quả hoàn thành sẽ được review như thế nào.
- Nghiệm thu. Đọc bằng chứng và quyết định công việc đã xong. Một lượt chạy kết thúc không đồng nghĩa với một kết quả được nghiệm thu.
- Leo thang. Quyết định điều gì xảy ra khi agent bị chặn, làm sai, hoặc gặp một câu hỏi cần phán đoán.
Mọi thứ còn lại đều có thể thương lượng, và phụ thuộc vào mức độ nhóm bạn tin tưởng thành tích của một agent cụ thể với một loại công việc cụ thể.
Công việc luân chuyển trong nhóm như thế nào
Vòng lặp này ngắn và đáng được nói rõ, vì những nhóm bỏ qua một bước sẽ cảm nhận được hậu quả chỉ trong vòng một tuần.
- Một người viết nhiệm vụ với kết quả mong đợi và tiêu chí nghiệm thu được nêu rõ.
- Nhiệm vụ có một người được giao để chịu trách nhiệm, và một agent hoặc crew làm người thực thi. Đây là hai trường riêng biệt, thay đổi trường này không làm thay đổi trường kia.
- Việc chuyển nhiệm vụ ra khỏi trạng thái backlog đang tạm dừng sẽ khởi động lượt chạy khi agent được giao sẵn sàng.
- Lượt chạy diễn ra trên một máy đã kết nối, trong một thư mục tách biệt, với tiến độ và các điểm tắc nghẽn được đẩy ngược trở lại nhiệm vụ.
- Agent để công việc ở trạng thái chờ con người phản hồi hoặc chờ con người review, và những mục này rơi vào hộp thư agent của người chịu trách nhiệm.
- Một người đọc trace và diff, rồi nghiệm thu, bình luận để tiếp tục, hoặc giao lại.
Bình luận là cuộc hội thoại bền vững. Một bình luận trên nhiệm vụ có agent sẵn sàng có thể đưa lượt chạy tiếp theo vào hàng đợi, khiến phản hồi review và thực thi trở thành cùng một động tác thay vì hai hệ thống riêng.
Ba mô hình hiệu quả
Lập trình viên kèm agent. Mỗi lập trình viên giữ một hai agent cho những công việc lặp lại của riêng mình: bổ sung test coverage, nâng cấp dependency, refactor những đoạn họ đã làm cả hai mươi lần. Lợi ích cho cả nhóm nằm ở chỗ các định nghĩa agent đó được chia sẻ, nên một người mới sẽ thừa hưởng luôn năm cấu hình đang chạy tốt ngay ngày đầu tiên thay vì phải tự dựng lấy.
Nhóm nhỏ với một crew dùng chung. Một crew đảm nhận một loại công việc mà cả nhóm đều phụ thuộc, chẳng hạn chuẩn bị release hay phân loại sự cố. Agent trưởng quyết định thành viên nào tham gia, và một người chịu trách nhiệm cho toàn bộ loại công việc đó. Đây là mô hình mở rộng được xa nhất trước khi năng lực review trở thành nút thắt.
Đội platform chuẩn hóa. Một nhóm platform hoặc developer experience sở hữu các định nghĩa agent, skill và cấu hình máy cho nhiều nhóm sản phẩm. Các nhóm sản phẩm giao việc; nhóm platform giữ runtime, quyền hạn và chỉ dẫn luôn cập nhật. Mô hình này đánh đổi chút tự chủ để lấy tính nhất quán, và thường là đánh đổi hợp lý khi vượt qua khoảng ba mươi kỹ sư.
Cả ba mô hình đều không đòi hỏi phải tái cơ cấu bất cứ thứ gì. Chúng là những khuôn mẫu về việc ai sở hữu cấu hình agent — câu hỏi quyết định năng lực agent sẽ tích lũy trong cả nhóm hay chỉ dừng ở mức cá nhân.
Những thỏa thuận làm việc đáng áp dụng
Mỗi nhiệm vụ chỉ có một người chịu trách nhiệm. Kể cả khi cả một crew bốn agent làm việc đó. Nhất là khi đó.
Phạm vi phải được viết trước khi giao việc. Nếu không ai nói được kết quả sẽ được kiểm tra thế nào, thì nhiệm vụ đó chưa sẵn sàng cho agent. Chỉ riêng quy tắc này đã loại bỏ phần lớn những lượt chạy hỏng.
Review là năng lực được lên lịch, không phải thời gian rảnh. Hãy xác định mỗi người review tiếp nhận được bao nhiêu việc của agent mỗi ngày và giữ đúng con số đó. Một đống kết quả agent chưa review ngày càng cao cũng chính là món nợ giống như các pull request chưa merge, chỉ có điều nó phình nhanh hơn.
Lượt chạy thất bại cần được chẩn đoán, không phải chạy lại. Hãy mở log thực thi và đọc tiêu đề cùng chi tiết kỹ thuật trước. Những lỗi từ nhà cung cấp trông giống nhau lại thường cần cách khắc phục ngược nhau, nên việc chạy lại theo phản xạ chỉ che đi nguyên nhân thật.
Mỗi định nghĩa agent cần có người sở hữu và ngày review. Chỉ dẫn sẽ mục ruỗng theo thời gian. Lập trình viên viết ra agent migration nghỉ việc, các quy ước thay đổi, và agent thì vẫn cứ tự tin áp dụng những quy tắc của quý trước.
Điều gì vỡ trước khi nhóm lớn lên
Năng lực review luôn là thứ vỡ trước tiên, không có ngoại lệ. Ràng buộc thứ hai là năng lực máy: các lượt chạy xếp hàng chờ đến lượt chạy đồng thời hoặc chờ một thư mục làm việc trống, và một nhóm thêm agent mà không thêm máy sẽ phát hiện ra một hàng đợi mà họ không nhìn thấy được từ bảng công việc.
Thứ ba là sự trôi dạt quyền sở hữu. Khi nhiều agent cùng đóng góp vào những nhiệm vụ liên quan mà không ai đổi tên người sở hữu sau khi bàn giao, bạn sẽ có những công việc trên danh nghĩa là đã giao nhưng thực tế chẳng ai sở hữu. Một lượt rà soát hàng tuần các nhiệm vụ có agent được giao và người sở hữu là con người đã cũ chỉ mất mười phút, và ngăn được phiên bản lộn xộn của vấn đề này. Nếu bạn muốn bắt đầu từ một hệ thống đã tách sẵn những trường này, hãy tải Sharkly và chạy thử một loại công việc lặp lại trong một tuần.
FAQ
Mỗi lập trình viên nên có bao nhiêu agent là hợp lý? Hãy bắt đầu với một hoặc hai, và để thông lượng review quyết định mức trần. Con số đúng là con số mà ở đó kết quả không phải chờ quá một ngày làm việc để có quyết định của con người.
Agent có dự standup không? Công việc của chúng thì có. Bảng công việc đã mang theo trạng thái, nên standup trở thành danh sách ngoại lệ: các thất bại, những lượt chạy bị chặn và những kết quả đang chờ con người.
Có bao giờ nên để agent là người được giao duy nhất không? Không. Hãy luôn giữ một người chịu trách nhiệm cho kết quả, còn agent nằm ở vị trí thực thi. Hướng dẫn của chúng tôi về quản lý dự án bằng AI agent giải thích vì sao sự tách biệt đó càng quan trọng khi khối lượng công việc tăng lên.
Làm thế nào để đưa một agent mới vào nhóm? Giống hệt cách bạn onboarding một con người: giao cho nó một nhiệm vụ đầu tiên hẹp, review sát sao, rồi mở rộng dần phạm vi. Lưu lại những gì hiệu quả thành chỉ dẫn và skill của agent để nhóm sau không phải khám phá lại từ đầu.
