Bạn có thể trò chuyện với một AI agent, hoặc giao cho nó một nhiệm vụ. Các nhóm vận hành coding agent mỗi ngày coi đây là hai công cụ khác nhau, và những nhóm nhầm lẫn giữa chúng sẽ phải trả giá về sau: các quyết định bị chôn vùi trong lịch sử chat riêng tư, công việc đã xong nhưng chẳng ai review, và một đồng đội hỏi "chúng ta đã thống nhất điều đó ở đâu vậy?" ba tuần sau khi phiên chat đã trôi đi mất.
Sharkly đưa sự phân biệt này vào thẳng sản phẩm. Chat dùng để khám phá, lập kế hoạch, hoặc hành động cùng một Agent trước khi công việc cần một bản ghi được theo dõi. Task dùng cho công việc cần người chịu trách nhiệm, trạng thái, lịch sử thực thi và review. Cả hai đều có thể khởi chạy Agent. Chúng lưu những bản ghi khác nhau, và chính sự khác biệt đó mới là điều cốt lõi.
Bài viết này giải thích mỗi giao diện dùng để làm gì, các chế độ chat của Sharkly hoạt động ra sao, cách chuyển một cuộc chat đầy triển vọng thành một Task thực sự, và những quy tắc quyết định giúp bản ghi chung của nhóm bạn luôn trung thực.
Tóm tắt nhanh
Hãy trò chuyện với AI agent khi bạn muốn đặt câu hỏi, tìm hiểu một chủ đề, hoặc định hình một kế hoạch mà không cần mở task. Hãy gán một Task khi công việc cần Assignee, trạng thái, tiêu chí nghiệm thu, review, hoặc một bản ghi lâu dài mà cả nhóm có thể thấy. Tin nhắn chat nằm lại trong phiên chat; kết quả Task thì trả về Task, nơi mọi người review và nghiệm thu.
Vấn đề: một agent, hai kiểu công việc
Bất kỳ ai từng chạy Claude Code hay Codex trong terminal đều đã biết cả hai kiểu công việc này. Có những phiên chỉ là câu hỏi: module này làm gì, vì sao test này chập chờn, migrate tốn bao nhiêu. Những phiên khác lại là cam kết: sửa bug này, ship endpoint này, cập nhật đám docs này.
Terminal đối xử với cả hai như nhau. Mỗi phiên đều là một bản ghi riêng tư trên máy của một người, bất kể nó vừa trả lời một câu hỏi vu vơ hay tạo ra một thay đổi mà cả nhóm phụ thuộc vào. Những phiên câu hỏi thì ổn. Những phiên cam kết thì không, vì chẳng ai khác nhìn thấy mục tiêu, diff, phần thảo luận hay kết quả.
Phần lớn các nhóm phát hiện điều này theo cách khá đau. Một dev chat với agent để xử lý bản fix production, bản fix được ship, còn lý do đằng sau nó thì nằm trong buffer scrollback bị xóa vào thứ Sáu. Kiểu thất bại ngược lại cũng có: một nhóm đẩy mọi câu hỏi nhỏ nhặt qua task tracker, và bảng task đầy ắp những ticket chết với tiêu đề "hỏi về caching".
Cách khắc phục không phải là một quy tắc cấm một trong hai giao diện. Mà là hiểu rõ mỗi giao diện ghi lại những gì, và chủ động chuyển công việc giữa chúng. Điều đó bắt đầu từ việc hiểu chat với AI agent lưu những gì, và không lưu những gì.
Agent Chat trong Sharkly là gì?
Agent Chat là một cuộc chat độc lập với một Agent hoặc Crew. Dùng nó khi bạn muốn đặt câu hỏi, tìm hiểu một chủ đề, định hình kế hoạch, hoặc bắt đầu công việc mà không cần mở task trước. Mỗi cuộc chat độc lập được hỗ trợ bởi phiên và các tin nhắn riêng, và phiên đó thuộc về người tạo ra nó.
Sharkly có hai giao diện chat, và tài liệu rất nghiêm ngặt trong việc tách biệt chúng:
- Agent Chat độc lập nằm ngoài mọi task. Bạn mở giao diện chat của một Agent, gửi tin nhắn, và một phiên mới bắt đầu. Đây là không gian làm việc của bạn với Agent đó.
- Agent chat trên một task nằm ngay trong task đó. Nó không phải là comment của task, và không yêu cầu task phải được gán cho Agent đó trước.
Có ba ranh giới quan trọng ở đây, vì mỗi ranh giới là một chỗ mà một người bình thường rất dễ đoán sai.
Chat không phải là comment. Gửi tin nhắn trong Agent Chat không tạo ra comment của task. Gửi tin nhắn trong Agent chat của một task cũng không xuất hiện trong Activity như một comment. Comment của task vẫn là bản ghi chính thức cho các thảo luận trong task; chat là một bản ghi riêng ở cả hai giao diện.
Mặc định chat không hiển thị cho cả nhóm. Một phiên độc lập thuộc về người tạo ra nó, và các thành viên khác trong tổ chức không được cấp quyền truy cập phiên đó qua các chat API hiện tại. Trên một task, tin nhắn chat mới sẽ thông báo cho Assignee và những người đã có trong cuộc trò chuyện đó. Chúng không được phát cho tất cả những ai đang theo dõi task.
Chat không yêu cầu phải gán. Bạn có thể mở một task và chat với bất kỳ Agent nào trong Space về task đó, dù Agent đó có phải là Assignee hay không. Việc gán kiểm soát trách nhiệm thực thi, chứ không kiểm soát quyền trò chuyện.
Nếu bạn chưa biết Agent thực chất là gì (một cấu hình làm việc đã lưu với instructions, Runtime, Skills và repositories), bài giải thích về Agents sẽ trình bày nền tảng đó.
Task cho bạn những gì mà chat không có?
Task là đơn vị công việc chính trong Sharkly. Nó mang theo mục tiêu và mô tả, trạng thái, độ ưu tiên, nhãn, người chịu trách nhiệm, Agent hoặc Crew được gán để thực thi, comment và tệp đính kèm, cùng trạng thái thực thi, trace và kết quả của Agent. Mọi thứ về công việc đều quay về Task, nơi bất kỳ ai có quyền truy cập đều có thể xem xét.
Chỉ một câu đó đã ẩn chứa bốn đảm bảo cụ thể mà chat không thể đưa ra:
- Quyền sở hữu. Một Task có Assignee. Khi có gì đó đình trệ, ta biết ngay tên người chịu trách nhiệm. Một phiên chat chỉ có danh sách người tham gia và không hề có cấu trúc trách nhiệm.
- Trạng thái. Một Task di chuyển qua quy trình làm việc mà nhóm bạn đã định nghĩa: backlog, started, review, done. Bất kỳ ai cũng có thể nhìn bảng và biết công việc đang ở đâu mà không cần hỏi.
- Lịch sử thực thi. Mỗi lần chạy trên một Task đều để lại một trace: khi nào nó vào hàng đợi, khi nào bắt đầu, đã gọi những công cụ nào, vì sao thất bại. Khi một lần chạy hỏng, bạn đọc bản ghi thực thi thay vì dựng lại sự việc từ ký ức.
- Review. Một Agent có thể để Task ở trạng thái chờ con người trả lời hoặc chờ con người review, và những tín hiệu đó rơi vào Inbox của người chịu trách nhiệm. Việc nghiệm thu là một bước được ghi lại, không phải cảm tính.
Thực thi dựa trên Task cũng có những lợi thế về cấu trúc. Công việc repository trên một Task chạy trong một thư mục biệt lập, thường là một git worktree riêng cho mỗi lần chạy, nhờ đó nhiều Task có thể thay đổi cùng một codebase song song mà không giẫm chân lên nhau. Cơ chế này được trình bày trong cách Sharkly chạy agents song song. Một comment tiếp theo trên Task đã được gán có thể khởi chạy một lần chạy khác, và Sharkly gộp các comment nhanh liên tiếp để chúng không tạo ra công việc trùng lặp.
Đây là giao kèo giữa người và agent khiến Task trở thành nơi phù hợp cho công việc thực sự: Agent nghiên cứu, thực thi, kiểm thử và báo cáo trên Task. Con người định hướng, trao quyền và nghiệm thu kết quả. Một phiên chat chỉ đáp ứng được nửa đầu của giao kèo đó. Chỉ Task mới đáp ứng được nửa sau.
Agent chat vs gán task: bảng quyết định
Quyết định nằm ở chỗ công việc cần được ghi lại những gì, chứ không phải công việc lớn đến đâu.
| Câu hỏi về công việc | Chat với Agent | Gán một Task |
|---|---|---|
| Có ai cần chịu trách nhiệm chính không? | Không cần người sở hữu | Có Assignee |
| Cả nhóm có cần thấy tiến độ không? | Riêng tư với người tham gia | Trạng thái hiển thị trên bảng |
| Có ai review kết quả không? | Bạn đọc câu trả lời | Review là một bước được ghi lại |
| Có cần lịch sử thực thi không? | Chỉ có bản ghi phiên chat | Trace đầy đủ của lần chạy trên Task |
| Đây là việc tìm hiểu hay cam kết? | Tìm hiểu | Cam kết |
| Một tháng nữa bạn có còn quan tâm không? | Chắc là không | Bản ghi vẫn còn đó |
Dùng chat khi bạn đang hỏi, so sánh, tìm hiểu hoặc định hình. Dùng Task khi công việc cần Assignee, trạng thái, tiêu chí nghiệm thu, hoặc một kết quả mà ai đó phải phê duyệt.
Hai quy tắc phản biện trung thực giúp điều này không biến thành giáo điều:
Đừng tạo Task cho mọi câu hỏi. "Module này làm gì?" xứng đáng có một cuộc chat, không phải một ticket. Một bảng đầy những Task mang hình dạng câu hỏi chỉ là tiếng ồn chôn vùi công việc thực sự, và tiếng ồn chính là thứ mà một hệ thống quản lý công việc cho cả người và agent sinh ra để ngăn chặn.
Đừng để một cuộc chat âm thầm biến thành cả một dự án. Khoảnh khắc cuộc trò chuyện tạo ra thứ mà cả nhóm phải hành động, phải review hoặc phải ghi nhớ, nó đã vượt khỏi khuôn khổ phiên chat. Nếu cả nhóm cần thấy một kết luận, hãy sao chép nó vào mô tả task hoặc một comment. Phiên chat gốc vẫn là lịch sử riêng của bạn; Task trở thành bản ghi chung.
Ba chế độ chat: Explore, Plan, Execute
Chat trong Sharkly không chỉ có một kiểu hành vi. Khung soạn tin có ba chế độ, chế độ được chọn sẽ lưu cùng phiên chat, và bạn có thể đổi nó trước bất kỳ lượt nào.
Explore là tìm hiểu ở chế độ chỉ đọc. Agent xem xét, giải thích, so sánh và tóm tắt mà không thay đổi gì. Hãy giữ nguyên Explore khi bạn chỉ muốn phân tích và không muốn gì khác. Đây là chế độ dành cho "giải thích luồng auth cho tôi" và "codebase hiện đã phụ thuộc vào thư viện nào trong hai thư viện này".
Plan cho phép Agent đề xuất hành động để bạn xem xét. Agent phác thảo một task đã lên kế hoạch kèm các subtask, và không có gì xảy ra cho đến khi bạn xác nhận. Bạn có thể chỉnh sửa đề xuất, xác nhận mà không bắt đầu công việc, hoặc xác nhận và bắt đầu ngay. Chế độ Plan là cầu nối giữa một cuộc trò chuyện hay và một cam kết được theo dõi, và chính nó khiến việc chuyển từ chat sang Task trở nên dễ dàng.
Execute cho phép Agent hành động trực tiếp qua CLI đã cấu hình và trả kết quả về phiên chat. Các cuộc chat mới bắt đầu ở chế độ Execute trừ khi bạn đặt mặc định khác — điều này nên biết ngay từ ngày đầu: nếu muốn một cuộc trò chuyện chỉ đọc, hãy chuyển sang Explore trước tin nhắn đầu tiên, chứ không phải sau khi Agent đã bắt đầu làm gì đó.
Cặp quyết định cho các chế độ cũng phản chiếu quyết định lớn hơn. Dùng Explore hoặc Plan khi kết quả vẫn còn là một câu hỏi. Chỉ dùng Execute trong chat cho những công việc mà bạn thấy thoải mái khi để ngoài bản ghi của nhóm, còn mọi thứ khác thì dùng Task.
Một vài hành vi khiến chat trở nên dễ chịu trên thực tế. Kết quả của Agent được truyền trực tiếp vào phiên khi một lần chạy đang hoạt động, và bạn có thể dừng lần chạy bất cứ lúc nào. Nếu bạn gửi thêm tin nhắn trong khi Agent đang làm việc, Sharkly sẽ xếp nó vào lượt tiếp theo thay vì khởi chạy một lần chạy song song trùng lặp. Bản nháp chưa gửi được giữ lại theo từng cuộc trò chuyện khi bạn chuyển đổi giữa các chat trong cùng trình duyệt. Phiên chat có thể được đổi tên, lưu trữ và mở lại từ lịch sử; các phiên đã lưu trữ vẫn đọc được nhưng chỉ ở chế độ chỉ đọc.
Cách chuyển một cuộc chat thành Task
Điểm chuyển giao là nơi hai giao diện gặp nhau, và tài liệu của Sharkly đưa ra một trình tự cụ thể. Khi một cuộc thảo luận tạo ra hành động đáng để cam kết:
- Tóm tắt kết quả ngay trong chat. Yêu cầu Agent nêu mục tiêu, phạm vi, ràng buộc và tiêu chí nghiệm thu trong một tin nhắn. Đây chính là đoạn mà Task cần, và Agent đã nắm đủ ngữ cảnh để viết nó.
- Dùng chế độ Plan để phác thảo Task. Chuyển sang Plan và để Agent đề xuất task cùng các subtask. Xem lại đề xuất và chỉnh sửa trước khi xác nhận. Bạn cũng có thể bỏ qua bước này và tự tạo Task thủ công; điều quan trọng là con người định hình nên cam kết.
- Xác nhận, kèm hoặc không kèm việc bắt đầu. Xác nhận sẽ tạo ra Task đã lên kế hoạch. Xác nhận và bắt đầu khi công việc cần chạy ngay; xác nhận mà không bắt đầu khi nó cần chờ một Sprint hoặc một phụ thuộc.
- Gán nó. Điều hướng Task đến đúng người, Agent hoặc Crew thông qua điều khiển Assignee. Một bản tóm tắt chat có phạm vi rõ ràng chính là thứ khiến Task có thể gán được. Với công việc gồm nhiều vai trò, một Crew có leader Agent có thể đảm nhận toàn bộ Task thay vì chỉ một người thực thi đơn lẻ.
- Chuyển ngữ cảnh, không chuyển bản ghi cuộc trò chuyện. Sao chép mọi thứ mà Task cần giữ vào mô tả hoặc comment của nó. Phiên chat vẫn là lịch sử riêng của bạn; đừng dựa vào nó như ký ức của cả nhóm, vì nhóm không thể thấy nó.
Từ đó trở đi, phản hồi tuân theo các quy tắc của Task. Trao đổi qua lại riêng cho task tiếp tục trong Agent chat của task; những kết luận mà cả nhóm nên thấy thì đặt vào comment trong Activity; một comment đủ điều kiện trên Task đã được gán sẽ khởi chạy một lần chạy tiếp theo. Kết quả, điểm tắc nghẽn và phản hồi cuối cùng đều quay về Task, và chính điều đó giúp việc review về sau trở nên khả thi.
Một lưu ý về vị trí: Task đã gán cho một Agent sẽ không khởi chạy khi còn nằm trong Backlog. Backlog là khu vực chờ. Di chuyển Task ra khỏi Backlog sẽ khởi chạy Agent được gán khi Computer và Runtime của nó sẵn sàng, nhờ đó bạn có thể chuẩn bị công việc từ chat ngay bây giờ và thả nó ra khi cả nhóm đã sẵn sàng. Việc thực thi diễn ra ở đâu về mặt vật lý là một vấn đề riêng, được trình bày trong bài giải thích về Computers.
Quick chat: ngữ cảnh task mà không cần rời khỏi task
Có một giao diện thứ ba đáng biết sau khi bạn đã nắm những điều cơ bản. Trang chi tiết Task có các quick chat trên thanh công cụ ở phần đầu: những tổ hợp prompt kèm Agent đã lưu, chạy với task hiện tại làm ngữ cảnh.
Mỗi quick chat có tên, prompt tùy chọn, Agent hoặc Crew được chọn, và cài đặt hiển thị. Quick chat riêng tư chỉ người tạo thấy và kích hoạt được. Quick chat chia sẻ thì mọi người trong Space đều thấy, tuy chỉ người tạo mới chỉnh sửa được. Chọn một cái sẽ mở chế độ xem chia đôi với task bên trái và chat bên phải, còn prompt, Agent và ngữ cảnh task được gửi đi cùng nhau.
Điều này biến những câu hỏi lặp đi lặp lại thành thao tác một cú nhấp. Một quick chat chia sẻ tên "Estimate this" gửi task đến một Agent lập kế hoạch, hay "Find related code" nối với một Agent am hiểu repository, sẽ trở thành thứ mà mọi người trong Space đều có thể kích hoạt trên bất kỳ task nào. Đây cũng chính là luận điểm đằng sau Skills: giá trị đến từ việc chia sẻ một thiết lập tốt, chứ không phải từ việc mỗi người mở thêm nhiều cuộc chat.
Có hai cơ chế cần phân biệt rõ. Mỗi lần kích hoạt quick chat tạo ra một cuộc trò chuyện riêng ở cấp task, và cuộc trò chuyện đó nằm lại trên Task; nó không dùng lại chat thông thường của Agent được gán. Và khi xóa một quick chat, bạn xóa cấu hình đã lưu, chứ không xóa những cuộc trò chuyện đã được tạo từ nó.
Nếu stack của bạn không có lớp task thì sao?
Rất nhiều nhóm chạy agent mà chẳng có nền tảng điều phối nào: những phiên terminal thô, các pane tmux, script shell. Cách thiết lập đó xử lý khá ổn nửa "chat" trong sự phân biệt của bài này. Một phiên terminal là cuộc trò chuyện riêng tư, mang tính tìm hiểu với agent, giống như Agent Chat.
Thứ mà stack tự dựng còn thiếu là nửa còn lại. Không có Assignee, không có trạng thái, không có trace của lần chạy để đồng đội mở ra xem, không có bước review, và không có nơi nào để kết quả tự động đổ về. Mọi phiên cam kết trông y hệt mọi phiên câu hỏi, và sự khác biệt chỉ lộ ra khi có gì đó hỏng và không ai dựng lại được nguyên nhân. Bài so sánh Claude Squad, Conductor và các thiết lập dựa trên tmux sẽ chỉ ra từng cách tiếp cận dừng lại ở đâu.
Bạn không cần xây lại quy trình của mình chỉ để bổ sung nửa còn thiếu. Sharkly không thay thế Claude Code, Codex hay các công cụ thực thi khác; nó bổ sung lớp task, ngữ cảnh và review dùng chung quanh những công cụ mà nhóm bạn đang dùng, còn việc sử dụng model vẫn diễn ra qua các subscription hoặc API key đã cấu hình trong những công cụ đó. Cứ giữ terminal cho công việc nháp nếu bạn thấy thuận tiện. Đưa công việc đã cam kết đi qua Task, và nếu ticket của bạn đã nằm ở nơi khác, một Jira ticket có thể đi thẳng đến Agent mà nhóm bạn không cần đổi công cụ quản lý.
Ba tình huống cụ thể
Bài test chập chờn. Một kỹ sư nhận thấy một test thỉnh thoảng lại fail. Cô mở chat với Code Reader Agent của nhóm ở chế độ Explore: "Vì sao auth_session_test lại fail khi chạy song song?" Sau mười phút đọc, Agent chỉ ra một fixture dùng chung bị race. Giờ đây nó là một cam kết: cô chuyển sang chế độ Plan, Agent phác thảo task SH-341 với phạm vi sửa và một tiêu chí nghiệm thu ("test pass 50 lần chạy song song liên tiếp"), cô xác nhận và bắt đầu, rồi gán cho fixer Agent. Phần tìm hiểu nằm lại trong lịch sử chat của cô. Bản fix, diff và review thì đáp xuống SH-341.
Câu hỏi về kiến trúc. Một tech lead muốn biết chi phí áp dụng một queue trên ba service là bao nhiêu. Việc này tốn nhiều ngày đọc, nhưng vẫn là một câu hỏi, nên nó nằm trong một phiên chat độc lập mà cô đổi tên thành "nghiên cứu áp dụng queue". Suốt một tuần, cô quay lại phiên đó, hỏi thêm, và để Agent so sánh các phương án. Khi ban lãnh đạo đồng ý, bản tóm tắt cuối cùng của phiên trở thành mô tả cho một Task cấp epic, được chia nhỏ thành các subtask trong chế độ Plan. Không có gì bị theo dõi nửa vời.
Câu hỏi standup cứ lặp lại mãi. Một nhóm để ý rằng mỗi sáng đều có người nhờ Agent tóm tắt những thay đổi của hôm qua trên task mà họ đang review. Một người lưu nó thành quick chat chia sẻ tên "What changed here?" nối với một Agent am hiểu repository. Câu hỏi không còn bị gõ lại nữa, và mỗi lần kích hoạt đều để lại cuộc trò chuyện trên đúng task mà nó chạy. Với những bản tóm tắt chạy theo lịch thay vì theo yêu cầu, chính bản năng đó sẽ tiến hóa thành Automations.
Ở cả ba tình huống, cùng một quy tắc quyết định giao diện: câu hỏi ở lại trong chat, cam kết thì có Task, và việc chuyển giao diễn ra ngay khi câu trả lời ngụ ý có việc phải làm.
Kết luận
Hãy chat với AI agent khi bạn đang tìm hiểu; hãy gán một Task khi bạn đang cam kết. Sharkly cố ý tách biệt hai giao diện để bảng task của bạn ghi lại công việc thực sự thay vì các câu hỏi, và để những câu hỏi của bạn không biến mất vào một bản ghi không ai đọc. Phiên chat thuộc về bạn. Task thuộc về cả nhóm, và ngữ cảnh, tiến độ, điểm tắc nghẽn, kết quả cùng phần review của con người luôn hiển thị trên đó từ lúc yêu cầu đến lúc phát hành.
Việc phân biệt này chẳng tốn gì để áp dụng, vì cả hai giao diện đã ở ngay trước mắt bạn. Hãy mở chat với một Agent và hỏi nó điều mà bình thường bạn phải lục tung codebase để tìm. Lần đầu cuộc trò chuyện đó tạo ra thứ đáng để cam kết, hãy chuyển sang chế độ Plan và để nó phác thảo Task. Kết nối một Computer, tạo một Agent, và thử cả hai nửa với một việc nhàm chán nào đó. Bài tổng quan về sản phẩm chủ lực sẽ trình bày phần còn lại của nền tảng khi bạn sẵn sàng.
Câu hỏi thường gặp
Tôi có thể chat với một Agent về một task mà không gán task đó không?
Có. Hãy mở task và bắt đầu chat với bất kỳ Agent nào trong Space. Việc gán không phải điều kiện tiên quyết để trò chuyện; nó quyết định ai thực thi task, chứ không quyết định bạn được nói chuyện với ai về task đó.
Tin nhắn chat có xuất hiện trong feed Activity của task không?
Không. Comment mới xuất hiện trong Activity cho cả nhóm. Agent chat trên một task sẽ thông báo cho Assignee và những người đã có trong cuộc trò chuyện đó, và nó được lưu tách biệt với comment ở cả hai giao diện.
Đồng đội của tôi có đọc được các phiên Agent Chat độc lập của tôi không?
Không. Mỗi phiên độc lập thuộc về người tạo ra nó, và các thành viên khác trong tổ chức không được cấp quyền truy cập qua các chat API hiện tại. Nếu một kết luận quan trọng với cả nhóm, hãy sao chép nó vào mô tả task hoặc comment.
Điều gì xảy ra nếu tôi nhắn cho một Agent đang offline hoặc đã lưu trữ?
Một Agent offline sẽ hiển thị là offline chứ không phải đang suy nghĩ hay đang trong hàng đợi, nên đừng chờ một câu trả lời sẽ không đến. Agent đã lưu trữ không thể nhận tin nhắn mới: khung soạn tin bị vô hiệu hóa, dù lịch sử phiên vẫn đọc được.
Tôi nên bắt đầu với chế độ chat nào?
Các cuộc chat mới bắt đầu ở chế độ Execute trừ khi bạn đổi mặc định. Nếu muốn phân tích mà không có thay đổi, hãy chuyển sang Explore trước khi gửi tin nhắn đầu tiên. Dùng Plan khi bạn muốn Agent đề xuất một task để bạn review và xác nhận.
Chat với một Agent có dùng thiết lập thực thi task của tôi không?
Có. Các lần chạy chat đi qua đúng cấu hình Agent đó: instructions, Runtime và Computer của nó. Ở chế độ Execute, Agent hành động qua CLI đã cấu hình, cũng chính là bộ máy vận hành các lần chạy task.
Khi nào một cuộc chat nên trở thành Task?
Ngay khi cuộc trò chuyện tạo ra công việc mà ai đó phải chịu trách nhiệm, phải review hoặc phải ghi nhớ. Hãy tóm tắt mục tiêu, phạm vi, ràng buộc và tiêu chí nghiệm thu, phác thảo Task ở chế độ Plan hoặc thủ công, rồi gán nó. Lịch sử chat không phải là bản ghi của cả nhóm.
Hai người có thể dùng chung một phiên chat với một Agent không?
Không, với các phiên độc lập thì không, vì chúng chỉ có một chủ sở hữu. Trên một task, Agent chat thông báo cho Assignee và những người tham gia trước đó, nên một nhóm nhỏ có thể theo dõi một cuộc trò chuyện ở cấp task tại đó. Với thảo luận cần cả nhóm thấy, hãy dùng comment của task.
