AI agent đầu tiên trong một nhóm giúp tăng năng suất. Agent thứ hai lại tạo ra vấn đề phối hợp. Phải có ai đó quyết định agent nào nhận thay đổi API, agent nào viết test, liệu việc refactor có phải chờ migration schema hay không, và ai kiểm tra kết quả tổng hợp trước khi một người phê duyệt. Ở hầu hết các nhóm, "ai đó" chính là một kỹ sư senior với mỗi tay cầm một terminal, và vai trò này không thể mở rộng quy mô.
Sharkly Crews ra đời đúng cho khoảnh khắc này. Crew là một nhóm People và Agent có thể tái sử dụng, được điều phối bởi một Agent leader duy nhất, và nó tồn tại bên trong Sharkly – nền tảng giữ cho công việc của agent nằm trong một hệ thống task chung. Thay vì một người tự tay điều phối từng subtask, bạn giao Task cho Crew. Agent leader đọc mục tiêu, quyết định thành viên nào nên đóng góp, rồi tập hợp kết quả của họ về một nơi để nhóm bạn review.
Hướng dẫn này trình bày Crew là gì, khi nào một Agent đơn lẻ là lựa chọn tốt hơn, cách thực thi theo hướng leader-first diễn ra ra sao trong từng lần chạy, và cách thiết lập một Crew mà nhóm bạn vẫn còn dùng sau ba tháng nữa.
TL;DR
Crew trong Sharkly là một nhóm People và Agent có thể tái sử dụng, được điều phối bởi một Agent leader duy nhất. Bạn giao Task cho Crew, leader khởi chạy trước, diễn giải mục tiêu, phân chia các phần việc cho các thành viên Agent bằng cách mention họ, rồi tổng hợp kết quả của họ trên Task. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và nghiệm thu kết quả.
Crew trong Sharkly là gì?
Crew là một nhóm có tên, có thể tái sử dụng: gồm People và Agent được nhóm lại quanh một loại công việc ổn định, với một Agent leader điều phối việc thực thi. Trong khi một Agent đơn lẻ là một cấu hình làm việc đã lưu cho một vai trò, thì Crew nắm bắt cách nhiều vai trò cộng tác với nhau, nhờ đó một Task phức tạp có thể được giao cho cả nhóm thay vì cho một người thực thi duy nhất.
Mọi Crew đều bao gồm:
- tên, mô tả và hướng dẫn Crew (không bắt buộc)
- một Owner – một người trong tổ chức quản lý Crew
- một leader, bắt buộc phải là một Agent trong Space của Crew
- các thành viên Agent và People có thể tham gia Space đó
- một Space sở hữu
- chế độ hiển thị Personal hoặc Space
- tuỳ chọn cấu hình thư mục Task dùng chung
Hai ranh giới cần nắm rõ trước mọi thứ khác.
Owner không phải là leader. Owner là người quản lý Crew: thành viên, cấu hình, chế độ hiển thị của nó. Leader là một Agent, và Agent này vẫn điều phối việc thực thi. Coi Owner như người thay thế cho Agent leader là hiểu sai cả hai vai trò.
Tư cách thành viên không đồng nghĩa với việc thực thi. Tư cách thành viên People ghi nhận ai tham gia Crew, nhưng chỉ các thành viên Agent mới có thể khởi chạy Agent run. Một người trong Crew vẫn cộng tác theo cách họ vẫn làm: qua bình luận trên Task, review và chat. Việc tham gia Crew không biến con người thành mục tiêu của một run.
Leader được tự động thêm làm thành viên, giữ vai trò leader và không thể bị xoá khi vẫn đang dẫn dắt Crew. Các thành viên khác có thể mang nhãn vai trò mô tả phần đóng góp của họ, chẳng hạn backend, tests hay docs, giúp leader có căn cứ cụ thể để suy xét khi phân công.
Khi nào nên dùng Crew thay vì một Agent đơn lẻ?
Cặp tiêu chí quyết định này đến trực tiếp từ tài liệu Sharkly, và nên hiểu theo đúng nghĩa đen. Với công việc nhỏ, đã được định nghĩa rõ ràng, hãy giao Task trực tiếp cho một Agent. Dùng Crew khi leader cần diễn giải mục tiêu, huy động các thành viên Agent khác, và tập hợp kết quả của họ về một Task hoặc một cuộc hội thoại duy nhất.
Một Agent đơn lẻ là lựa chọn đúng khi:
- Công việc nằm gọn trong một vai trò, ví dụ sửa một bug trong một service.
- Phạm vi đã rõ ràng và không cần chia nhỏ.
- Bạn muốn ít đầu mối chuyển động nhất giữa lúc giao việc và lúc review.
- Bạn vẫn đang tinh chỉnh hướng dẫn của một Agent riêng lẻ và muốn có tín hiệu rõ ràng.
Crew xứng đáng có chỗ đứng khi:
- Mục tiêu trải rộng nhiều vai trò, ví dụ một tính năng cần thay đổi ở backend, frontend và test.
- Phải có ai đó quyết định thứ tự đóng góp, và bạn muốn người đó là một Agent thay vì một người đang mở hai terminal.
- Cùng một tổ hợp chuyên gia cứ lặp lại cho mỗi yêu cầu mới.
- Kết quả từ nhiều Agent phải đổ về một Task thay vì phân tán khắp các phiên riêng lẻ.
Nếu nhóm bạn vẫn đang cân nhắc liệu công việc đa agent có đáng để cấu trúc hoá hay không, bài giới thiệu về điều phối AI agent sẽ phân tích các đánh đổi từ những nguyên lý cơ bản. Tóm gọn lại: thêm một agent thì rẻ, nhưng việc phối hợp giữa các agent mà không có ai quản lý thì không hề rẻ.
Cách thực thi theo hướng leader-first diễn ra
Khi bạn giao một Task cho Crew, quá trình thực thi tuân theo trình tự leader-first:
- Task được giao cho Crew thông qua nút Assignee, giống như bất kỳ Assignee nào khác.
- Nếu Task đang ở trạng thái có thể thực thi và leader đã sẵn sàng, Agent leader sẽ khởi chạy trước.
- Leader đọc ngữ cảnh của Task và hướng dẫn của Crew.
- Leader hoặc tự xử lý công việc, hoặc mention các thành viên Agent đủ điều kiện cho những phần đóng góp cụ thể.
- Các thành viên Agent được mention sẽ chạy trên cùng Task đó và thêm kết quả của họ vào phần chat của Task.
- Leader tiếp tục điều phối và tổng hợp các kết quả lại.
Mục tiêu thiết kế đằng sau trình tự này là sự tiết chế. Thực thi leader-first ngăn tất cả thành viên Agent khởi chạy cùng lúc. Nó cũng cho leader cơ hội nhận ra ngữ cảnh còn thiếu, chọn đúng người tham gia và kiểm soát thứ tự công việc. Một Crew không có leader sẽ chỉ là một nút fan-out; có leader, nó là một nhóm biết suy nghĩ trước khi chia việc.
Backlog hoạt động giống như với từng Agent riêng lẻ: giao một Task trong Backlog sẽ không khởi chạy leader. Backlog là bãi đỗ xe nơi công việc được chuẩn bị, và việc chuyển Task sang trạng thái có thể thực thi chính là hành động khởi chạy Crew. Việc giao việc không bao giờ kích hoạt công việc một cách bất ngờ.
Mọi thứ mà các thành viên tạo ra đều quay về Task: trạng thái run, kết quả và phần thảo luận xoay quanh chúng. Đó chính là lý do nên vận hành một nhóm bên trong Sharkly thay vì trải khắp năm terminal. Ngữ cảnh, tiến độ, điểm tắc nghẽn, kết quả và việc review của con người luôn hiển thị rõ từ lúc yêu cầu đến lúc phát hành, dù chỉ một Agent làm việc hay bốn Agent cùng làm.
Một lưu ý kỹ thuật cho các nhóm chạy thành viên song song: mặc định mỗi Agent run vẫn có thư mục làm việc riêng biệt, nên các thành viên không giẫm chân lên file của nhau. Mô hình cô lập này là chủ đề của bài cách Sharkly chạy các Agent song song mà không xung đột merge.
Quyền sở hữu, chế độ hiển thị và ai có thể dùng Crew
Những người có quyền tạo tài nguyên dùng chung trong một Space có thể tạo Crew tại đó. Mọi Crew đều thuộc về một Space, và chế độ hiển thị của nó quyết định ai có thể tìm thấy và sử dụng nó:
| Chế độ hiển thị | Ai có thể truy cập và chat | Ai có thể quản lý hoặc giao việc |
|---|---|---|
| Personal | Owner, các thành viên Crew là người, và chủ sở hữu của các thành viên Agent | Chỉ Owner mới có thể quản lý Crew hoặc chọn nó làm Task Assignee |
| Space | Thành viên của Space chứa Crew, cùng Organization Owners và Admins | Theo quyền hạn của Space và tổ chức |
Chế độ hiển thị áp dụng cho chính Crew, cho chat của Crew và cho việc chọn nó làm Task Assignee. Một Personal Crew do Owner của nó quản lý, và sau khi Owner của một Crew riêng tư thay đổi, Owner cũ sẽ mất quyền quản lý. Quy tắc bàn giao này rất quan trọng khi người xây dựng Crew chuyển sang nhóm khác: hãy chủ động chuyển quyền sở hữu thay vì để phát hiện ra lỗ hổng sau này.
Khi một Crew đã hoàn thành sứ mệnh, hãy archive nó thay vì xoá lịch sử. Một Crew đã archive sẽ ngừng nhận các phân công mới trong khi lịch sử hiện có vẫn được giữ lại. Trước khi archive, hãy kiểm tra xem các Task hay Automation hiện tại có còn dùng Crew đó không và chuyển công việc đó sang Assignee khác trước. Việc kiểm tra phụ thuộc tương tự cũng áp dụng trước khi archive một Agent thuộc về một Crew.
Crew chat: phối hợp trước khi có Task
Không phải cuộc thảo luận nào cũng cần một Task ngay từ ngày đầu. Crew chat tồn tại cho những cuộc trò chuyện diễn ra trước hạng mục công việc: khám phá một vấn đề, xác định đúng người tham gia, định hình một kế hoạch.
Mỗi người có một phiên chat thường trực với Crew, và Agent leader là người đối thoại ban đầu. Leader có thể mention các thành viên Agent để câu trả lời của họ xuất hiện trong cùng phiên chat, nghĩa là bạn có thể xem cả nhóm cùng suy luận trước khi cam kết bất cứ điều gì.
Ranh giới này rất rõ ràng và đáng để ghi nhớ: Crew chat không tạo ra Task. Khi cuộc thảo luận chuyển thành công việc cụ thể, hãy tạo một Task và giao cho Crew, để trạng thái, bình luận, các run và việc nghiệm thu luôn gắn với hạng mục công việc. Một kết luận chỉ tồn tại trong một phiên chat là kết luận mà nhóm bạn sẽ đánh mất. Bản ghi chung chính là Task, và các kết quả cần quay về đó.
Phần chi tiết Task cũng có các quick chat trên thanh công cụ ở phần header. Quick chat chạy một Agent hoặc Crew được chọn với task hiện tại làm ngữ cảnh, trong chế độ xem chia đôi bên cạnh Task. Đây là cách hữu ích để hỏi một Crew rằng "bạn sẽ làm gì với việc này?" trước khi chính thức giao việc.
Các kỹ thuật Crew nâng cao
Agent độc quyền cho Crew: những chuyên gia chỉ làm việc ở một nơi
Một số Agent chỉ có ý nghĩa khi nằm trong nhóm của chúng. Một merge coordinator vốn giả định có ba thành viên khác tồn tại, hay một reviewer được tinh chỉnh theo quy ước của một Crew cụ thể, không nên xuất hiện trong danh sách chọn Agent chung của tổ chức, nơi ai đó có thể giao cho nó công việc độc lập mà nó chưa từng được thiết kế để làm.
Đánh dấu một Agent là độc quyền cho Crew sẽ giới hạn phạm vi của nó vào Crew đó. Sau khi bật cấu hình này:
- Agent chỉ có thể được gọi bên trong Crew hiện tại
- nó không thể dùng cho chat riêng hay được giao Task một mình
- nó biến mất khỏi My Agents, thư mục, danh sách Agent của tổ chức và nút chọn Assignee
Tính độc quyền là giới hạn phạm vi của Agent, không phải một vai trò trong Crew. Nhãn vai trò mô tả thành viên đó làm gì; tính độc quyền mô tả Agent có thể được gọi ở đâu. Một Agent độc quyền cho Crew chỉ thuộc tối đa một Crew tại một thời điểm, nên nếu nó đã nằm trong Crew khác, hãy xoá nó khỏi đó trước. Tắt tính độc quyền sẽ khôi phục chế độ hiển thị và khả năng được giao việc thông thường, và các Task, chat trong lịch sử vẫn được giữ nguyên trong cả hai trường hợp. Thứ bị chặn là các phiên chat riêng mới và các phân công độc lập mới.
Thư mục Task dùng chung: khi các thành viên phải xây dựng trên cùng một bộ file
Mặc định, cô lập là nguyên tắc: các run riêng biệt có thư mục riêng. Một Crew có thể nới lỏng điều này một cách có chủ đích. Khi bật cấu hình thư mục Task dùng chung, một Agent run sau đó của Crew cho cùng Task có thể tái sử dụng thư mục đủ điều kiện mới nhất trên Computer đó và giữ lại các thay đổi cục bộ mà thành viên trước để lại.
Hai ràng buộc giúp việc này an toàn. Nó chỉ chia sẻ trạng thái hệ thống file, không chia sẻ phiên provider của Agent trước, nên mỗi thành viên vẫn bắt đầu quá trình suy luận của riêng mình từ bản ghi Task. Và nó chỉ áp dụng khi các run thuộc cùng một Task được giao cho Crew và thực thi trên cùng một Computer.
Quy tắc quyết định: bật tái sử dụng thư mục dùng chung khi các thành viên chạy tuần tự phải xây dựng trên cùng những thay đổi cục bộ, ví dụ một Agent triển khai implementation rồi đến một Agent test chạy thử đoạn code mới. Hãy để nó tắt khi cô lập an toàn hơn hoặc khi các chỉnh sửa đồng thời có thể xung đột. Nếu bạn bật nó, hãy nêu rõ thứ tự thực thi mong muốn trong hướng dẫn của Crew, bởi một thư mục dùng chung với thứ tự mơ hồ chính là một xung đột merge khoác áo đồng đội.
Viết hướng dẫn Crew đủ sức trụ vững
Hướng dẫn Crew là cẩm nang vận hành của leader cho việc điều phối. Tài liệu nói rất cụ thể về những gì nên có ở đó: cách leader quyết định có huy động Agent khác hay không, có những vai trò nào, kết quả nên được tổng hợp ra sao, và khi nào một người phải đưa ra quyết định.
Hãy giữ các tầng tách bạch. Các yêu cầu đặc thù của Task nằm trong phần mô tả và bình luận của Task. Một quy trình có thể tái sử dụng mà nhiều Agent cùng chia sẻ thì thuộc về một Skill. Hướng dẫn riêng của từng thành viên Agent chứa vai trò cá nhân của họ. Hướng dẫn Crew chỉ bao gồm các quy tắc cộng tác, giúp chúng đủ ngắn để leader theo được trong mọi lần chạy. Sao chép hướng dẫn của từng thành viên vào Crew là cách phổ biến nhất khiến việc phân công trở nên khó đoán.
Một bộ khung khả thi:
# Crew: Checkout Feature Crew
## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent
## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.
## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.
## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.
Khối escalation đó chính là hợp đồng người – agent được viết thẳng vào chính nhóm. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và nghiệm thu kết quả. Crew không thay đổi hợp đồng này; nó chỉ cho phía agent thêm nhiều tay hơn.
Thiết lập Crew đầu tiên của bạn
Tài liệu mô tả một trình tự thiết lập điển hình, và bạn có thể hoàn thành trong khoảng mười lăm phút nếu đã có sẵn các Agent:
- Xác định loại công việc ổn định mà Crew sẽ đảm nhiệm. "Mọi thứ" không phải là một loại công việc; "các thay đổi đối với luồng thanh toán" thì có.
- Chọn chế độ hiển thị và một Owner. Bắt đầu với Personal trong lúc tinh chỉnh, rồi chuyển sang chế độ hiển thị Space khi cấu hình đã đáng để tái sử dụng.
- Chọn một Agent làm leader. Hãy chọn Agent mà bạn tin tưởng về khả năng phán đoán để điều phối công việc, không nhất thiết là Agent viết nhiều code nhất.
- Thêm các thành viên People và Agent mà công việc cần, và gán cho họ nhãn vai trò mà leader có thể suy xét. Trên trang Members, bạn có thể thêm nhiều người cùng lúc, và menu của từng dòng có thể đặt leader mới hoặc xoá thành viên sau này.
- Viết hướng dẫn Crew cho việc điều phối và kết quả đầu ra, theo các quy tắc phân tầng ở trên.
- Chỉ bật thư mục Task dùng chung khi hành vi tái sử dụng của nó đúng là điều bạn muốn. Khi còn phân vân, hãy để tắt.
Sau đó hãy giao một Task thực tế. Đại loại như SH-312: "Thêm trường lý do huỷ vào luồng huỷ đăng ký, cả API và UI, kèm test." Quan sát leader khởi chạy, xem cách nó phân công, và review những gì quay về Task. Lần chạy Crew đầu tiên sẽ dạy bạn nhiều điều về hướng dẫn của mình hơn bất kỳ việc chỉnh sửa trước nào. Mỗi thành viên Agent vẫn chạy trên Runtime đã được cấu hình riêng của nó, dù đó là Claude Code, Codex, hay một công cụ CLI khác mà nhóm bạn đã trả phí, bởi Sharkly vẫn là tầng điều phối bao quanh những công cụ đó chứ không thay thế chúng.
Những mẫu Crew đáng để học theo
Đây là các mẫu cấu hình, không phải case study; mỗi mẫu ghép lại những hành vi đã được ghi trong tài liệu.
Crew tính năng. Một Agent leader lập kế hoạch, cùng các thành viên backend, frontend và test với nhãn vai trò tương ứng. Leader chia nhỏ một yêu cầu, sắp backend trước frontend khi có thay đổi contract, và mention thành viên test sau cùng. Đây chính là mẫu mà bộ khung thiết lập ở trên mô tả, phù hợp với những nhóm có yêu cầu thường xuyên vượt qua ranh giới giữa các vai trò.
Crew triage. Một leader đọc các báo cáo bug đến, một thành viên tái hiện xác nhận lỗi và thu thập bằng chứng, và một thành viên sửa lỗi chỉ hành động sau khi có kết quả tái hiện đã xác nhận quay về Task. Con người vẫn nằm trong vòng lặp với tư cách thành viên, bởi việc quyết định mức ưu tiên của một bug là định hướng, và phía đó của hợp đồng thuộc về con người.
Crew review. Một leader phân công các góc nhìn review: một thành viên đọc để kiểm tra tính đúng đắn, một thành viên khác xem các luồng nhạy cảm về bảo mật, thành viên thứ ba xem độ phủ test. Các phát hiện của họ đổ về Task thành những kết quả riêng để leader tổng hợp. Vì các thành viên review không bao giờ nên được giao việc tính năng một mình, đây là chỗ tự nhiên cho các Agent độc quyền cho Crew.
Crew hỗ trợ sprint. Trong một Sprint, một Crew đảm nhận những công việc lặp lại, có phạm vi rõ: nâng cấp dependency, cách ly các test chập chờn, tài liệu bị lệch. Nhiệm vụ chính của leader là từ chối những việc nằm ngoài phạm vi, giúp thông lượng của Crew đủ dự đoán được để lên kế hoạch xung quanh.
Dù bắt đầu với mẫu nào, hãy bắt đầu với một mẫu. Một nhóm vận hành tốt một Crew sẽ học được những thói quen phối hợp giúp Crew thứ hai trở nên rẻ và dễ dàng.
Khi nào Crew không phải là câu trả lời
Một danh sách ranh giới trung thực, bởi cách nhanh nhất để khiến cả nhóm chán ngấy công việc đa agent là dùng nó ở nơi nó làm giảm giá trị.
Một vai trò rõ ràng, một Agent. Nếu Task nằm gọn trong một vai trò, Crew chỉ thêm một bước phân công mà chẳng thêm gì khác. Hướng dẫn của chính tài liệu cũng là ưu tiên một Agent cho công việc đơn giản và Crew cho công việc thực sự cần phối hợp.
Kích hoạt định kỳ, hãy dùng Automation. Nếu công việc kích hoạt theo lịch hoặc theo sự kiện thay vì theo phán đoán, thì Automation là công cụ sắc bén hơn. Crew quyết định; Automation lặp lại. Chúng kết hợp tốt với nhau, nhưng không thể thay thế cho nhau.
Chia nhỏ trong một run, hãy dùng subagent của runtime. Những công cụ như Claude Code có thể sinh ra các subagent bên trong một run duy nhất. Điều này mang tính bổ trợ, không phải cạnh tranh: subagent của runtime chia nhỏ công việc của một Agent trong phiên của nó, còn Crew điều phối các Agent, Runtime và kết quả riêng biệt ở cấp độ Task, nơi cả nhóm có thể nhìn thấy. Nếu hiện tại bạn đang chạy nhiều agent Claude Code bằng script và tmux, thì Crew chính là con đường nâng cấp cho nửa phần phối hợp của thiết lập đó.
Một group chat với thêm vài bước. Nếu điều bạn muốn chỉ là một cuộc thảo luận, hãy dùng Crew chat và dừng ở đó. Đừng tạo một Crew mà công việc duy nhất là trả lời những câu hỏi mà một Agent đơn lẻ có thể trả lời.
Không điều nào ở đây yêu cầu bạn xây dựng lại bất cứ thứ gì. Các thành viên giữ nguyên Runtime, repository và gói đăng ký của mình; Crew là một tầng điều phối bên trên những Agent bạn đã cấu hình, và việc sử dụng model vẫn diễn ra qua các gói đăng ký và API key đã cấu hình trong những công cụ đó.
Kết luận
Crew là câu trả lời của Sharkly cho câu hỏi mà mọi nhóm đều gặp sau Agent thành công đầu tiên: làm sao vận hành nhiều agent như thế mà không phải chỉ định một người làm cảnh sát giao thông? Cơ chế gồm một Agent leader với các quy tắc phối hợp được viết ra, các thành viên với vai trò rõ ràng, và một Task mà mọi kết quả đều quay về đó. Sự tiết chế đã được tích hợp sẵn: thực thi leader-first, Backlog không bao giờ tự khởi chạy, cô lập theo mặc định, và con người nắm quyền nghiệm thu ở cuối.
Bước tiếp theo cụ thể rất nhỏ. Kết nối một Computer, cấu hình hai Agent mà bạn đã tin tưởng riêng lẻ, rồi gói chúng vào một Crew với khối hướng dẫn ba dòng. Giao một Task thực sự cần cả hai vai trò, và đọc những gì quay về. Tài liệu Sharkly đi sâu hơn vào từng khái niệm, còn bài bắt đầu với Sharkly sẽ dẫn bạn qua toàn bộ phần thiết lập nền tảng từ đầu đến cuối.
Câu hỏi thường gặp
Crew trong Sharkly là gì?
Crew là một nhóm People và Agent có thể tái sử dụng, được điều phối bởi một Agent leader duy nhất. Nó có một Owner quản lý, một Space sở hữu, chế độ hiển thị Personal hoặc Space, và hướng dẫn Crew tuỳ chọn. Hãy giao một Task cho Crew và leader sẽ điều phối thành viên nào đóng góp cũng như cách tổng hợp kết quả.
Khi nào tôi nên dùng Crew thay vì một Agent đơn lẻ?
Hãy giao công việc nhỏ, được định nghĩa rõ ràng trực tiếp cho một Agent. Dùng Crew khi mục tiêu cần được diễn giải, trải rộng nhiều vai trò, hoặc cần kết quả từ nhiều Agent quay về một Task. Nếu cùng một nhóm chuyên gia cứ lặp lại cho mỗi yêu cầu, sự lặp lại đó chính là tín hiệu để biến nhóm thành thứ có thể tái sử dụng.
Giao một Task cho Crew có khởi chạy mọi thành viên cùng lúc không?
Không. Quá trình thực thi theo hướng leader-first: Agent leader khởi chạy trước, đọc ngữ cảnh Task và hướng dẫn Crew, rồi mention các thành viên Agent đủ điều kiện cho những phần đóng góp cụ thể. Các thành viên được mention sau đó chạy trên cùng Task đó. Điều này ngăn tình trạng dồn dập cùng lúc và cho leader kiểm soát thứ tự cũng như mức độ tham gia.
Con người có thể là thành viên của Crew không?
Có. Tư cách thành viên People ghi nhận ai tham gia, và các thành viên là người của một Personal Crew có thể truy cập và chat với Crew đó. Tuy nhiên chỉ các thành viên Agent mới có thể khởi chạy Agent run. Con người đóng góp qua bình luận trên Task, các quyết định và việc review – đó là phía con người trong hợp đồng.
Agent độc quyền cho Crew là gì?
Agent độc quyền cho Crew bị giới hạn phạm vi vào một Crew: nó chỉ có thể được gọi bên trong Crew đó, không thể có chat riêng hay được giao Task độc lập, và không xuất hiện trong các danh sách Agent toàn tổ chức. Đây là giới hạn phạm vi chứ không phải một vai trò, và việc tắt nó sẽ khôi phục chế độ hiển thị thông thường của Agent.
Các thành viên Crew có thể chia sẻ file trong một Task không?
Có, nếu Crew bật cấu hình thư mục Task dùng chung. Run của một thành viên sau đó trên cùng Task có thể tái sử dụng thư mục đủ điều kiện mới nhất trên cùng Computer, giữ lại các thay đổi cục bộ trước đó. Nó chỉ chia sẻ trạng thái hệ thống file, không bao giờ chia sẻ phiên của Agent trước, và mặc định tắt vì cô lập an toàn hơn cho các chỉnh sửa đồng thời.
Crew chat có tự động tạo Task không?
Không. Crew chat dùng để khám phá một vấn đề hoặc định hình một kế hoạch, với leader là người đối thoại ban đầu. Khi cuộc thảo luận chuyển thành công việc cụ thể, bạn tạo một Task và giao cho Crew để trạng thái, các run và việc nghiệm thu luôn gắn với hạng mục công việc.
