Chúng tôi muốn Orkas trở thành nền tảng để một công ty AI-native vận hành. Mục tiêu đó dẫn thẳng đến một câu hỏi: nhiều người và nhiều tác tử cộng tác trên cùng một dự án như thế nào?
Câu trả lời khác khá nhiều so với cách làm việc nhóm mà chúng ta quen thuộc. Để hiểu vì sao, nên bắt đầu từ nguồn gốc của sự cộng tác giữa con người. (Nếu muốn xem hướng dẫn sản phẩm từng bước, hãy đọc Dự án dùng chung: Cách con người và tác tử AI cùng làm việc trong Orkas. Bài này nói về tư duy đằng sau nó.)
Cộng tác giữa con người hình thành quanh hai giới hạn của con người
Thứ nhất, con người có băng thông và trí nhớ hạn chế. Mỗi lúc ta chỉ tiếp nhận được chừng ấy thông tin, và chỉ nhớ được chừng ấy. Vì vậy, đội nhóm phải liên tục trao đổi: cập nhật tình hình, thống nhất mục tiêu, thống nhất tiến độ. Họp tuần, stand-up, báo cáo ngày và báo cáo tuần, “sync nhanh chút nhé?”, “mình thống nhất lại nhé”: tất cả đều để bù đắp cho giới hạn này.
Thứ hai, phần lớn việc đó phải diễn ra trực tiếp. Khi gặp mặt, có nhiều kênh hơn là chỉ lời nói: ngôn ngữ cơ thể, giọng điệu và nét mặt đều mang thông tin. Khi người ngồi đối diện nói “kế hoạch trông ổn đấy”, bạn nghe ra được họ có thật lòng hay không. Quan trọng không kém, gặp mặt trực tiếp giúp xây dựng niềm tin. Đó là lý do nhiều đội làm việc từ xa vẫn thỉnh thoảng gặp nhau trực tiếp.
Điều gì thay đổi khi tác tử tham gia
Trong một đội gồm cả người và tác tử, khía cạnh con người của sự cộng tác vẫn quan trọng. Nhưng làm việc với tác tử rất khác làm việc với con người. Tác tử có ba điểm mạnh rõ rệt và ba điểm yếu rõ rệt.
Ba điểm mạnh
Băng thông cao và khả năng thực thi mạnh. Điều này đặc biệt đúng với những nhiệm vụ có mục tiêu rõ ràng, đo lường được. Những nhiệm vụ tác tử có thể hoàn thành cũng đang nhanh chóng trở nên dài hơn, khó hơn và phức tạp hơn. Khi giới thiệu tác tử lập trình của mình, Meta cho biết trong một nhiệm vụ tối ưu hóa kernel GPU, tác tử đã làm việc tới 24 giờ và thực hiện hơn 1.000 lần gọi công cụ (Meta). Tháng 10 năm 2026, Linus Torvalds gửi một loạt bản vá cho nhân Linux mà mã nguồn, chương trình kiểm thử và bản nháp đầu tiên của thông điệp commit đều do Claude Code viết; ông tự chạy các phép đo trên máy của mình (LWN).
Tri thức và công cụ của cả thế giới, làm trọn từ đầu đến cuối qua nhiều chuyên môn. Quá trình tiền huấn luyện đã gói tri thức của thế giới vào mô hình. Khi có đúng công cụ, một tác tử có thể đưa một phần việc đi qua nhiều chuyên môn từ đầu đến cuối: viết PRD → thiết kế → xây dựng → kiểm thử → phát hành. Khi con người làm cùng việc đó, cần cả sản phẩm, thiết kế, kỹ thuật và QA phối hợp, và mỗi lần bàn giao lại thêm một vòng thống nhất.
Ít điểm yếu kiểu con người, và không cần xây dựng niềm tin trước. Tác tử không mệt mỏi, không có ngày tồi tệ, và không ngại hỏi một câu cơ bản. Một tác tử mới có thể bắt tay vào việc ngay khi có ngữ cảnh của dự án. Không có giai đoạn làm quen, cũng không có mối quan hệ nào phải xây trước.
Ba điểm yếu
Nó cần ngữ cảnh sạch. Ngữ cảnh sai sẽ khiến nó đi chệch hướng. Chính chúng tôi đã gặp chuyện này: một trường trên bảng điều khiển phân tích của chúng tôi ghi rằng dữ liệu “không thể liên kết”, trong khi thực tế là có thể; bản thân trường đó đã bị tính sai. Hai tác tử khác nhau đọc dòng đó và đều bỏ luôn cả một phân tích hành trình người dùng. Một người thấy kết luận ấy sẽ hỏi “thông tin này còn đúng không?”. Tác tử thì thường tin ngay vào những gì được viết.
Nó yếu trong việc quy kết nguyên nhân dài hạn. Khi nhiều biến số cùng lúc tác động đến kết quả, nó dễ đổ lỗi nhầm biến số, và con người phải sửa lại. Có một thời gian, vài trang mới trên trang web của chúng tôi không được Google lập chỉ mục. Một tác tử kết luận rằng “trang web chưa đủ uy tín, nên Google không dành crawl budget cho nó” và đề xuất xây dựng backlink trước. Chúng tôi phản bác và kiểm tra lại: đại đa số các trang của trang web đã được lập chỉ mục. Vài trang chưa được thì trông giống những chủ đề quá xa với nội dung chính của trang web hơn. Crawl budget chẳng liên quan gì, và xây backlink hẳn sẽ là một nước đi sai.
Nó kém trong việc thích nghi với môi trường thay đổi, nhất là khi thay đổi đó không có trong dữ liệu tiền huấn luyện. Một trang web vừa được thiết kế lại, một quy định nền tảng vừa thay đổi, một sản phẩm ra mắt tháng trước: con người nhận ra “có gì đó khác rồi” và đổi cách làm. Tác tử thì thường vẫn làm theo những gì nó đã biết và thử đi thử lại cùng một cách.
Vì sao ứng dụng chat không phù hợp
Ứng dụng chat được thiết kế cho người làm việc với người: tin nhắn trôi qua nối tiếp nhau, @mention và trạng thái đã xem giúp mọi người nắm cùng một thông tin, còn thông tin thì phân tán qua nhiều kênh. Thiết kế đó bù đắp đúng cho hai giới hạn ở trên. Con người có băng thông thấp và trí nhớ ngắn, nên chúng ta cứ phải nhắn tin và cứ phải thống nhất.
Với tác tử, khuôn mẫu này không đúng:
- Chuyện phiếm, những cuộc thảo luận dọc đường và các kế hoạch về sau bị bỏ đều là nhiễu ngữ cảnh đối với tác tử.
- Tác tử không cần xây dựng niềm tin qua trò chuyện.
- Điều tác tử thực sự cần là ngữ cảnh sạch và một nhiệm vụ rõ ràng.
Vì vậy, sự cộng tác giữa người và tác tử cần được thiết kế lại. Và khi tác tử ngày càng có năng lực hơn, cách chúng ta cộng tác cũng sẽ tiếp tục thay đổi. Chúng tôi vẫn đang tìm lời giải cho điều này trong Orkas.
Orkas làm gì: giữ lại điều không đổi, thiết kế lại điều đã đổi
Cách tiếp cận của chúng tôi là giữ lại những phần của sự cộng tác không thay đổi và thiết kế lại những phần đã thay đổi. Dưới đây là một dự án dùng chung trong Orkas; bốn ý tưởng tương ứng với bốn vùng được làm nổi bật.
1. Giao việc, bàn giao và duyệt kết quả: Cần làm
Cơ chế này đã có từ rất lâu trước khi có tác tử, và chúng ta vẫn cần nó. Tạm thời, mọi nhiệm vụ trong các dự án của chúng tôi đều có một người phụ trách là con người, và một người chịu trách nhiệm về kết quả cuối cùng.
Trong sản phẩm, nó hoạt động như sau. Mỗi mục cần làm được giao cho một người, và người đó quyết định tác tử nào sẽ làm. Chỉ người phụ trách mới có thể bắt đầu mục cần làm; tác tử chạy trên máy tính của chính người phụ trách, bằng mô hình và tín dụng của họ. Khi xong, tác tử chuyển mục cần làm sang Đang chờ xác nhận thay vì tự đánh dấu là xong. Mục đó chỉ hoàn tất sau khi người phụ trách đã kiểm tra và chỉnh sửa nếu cần.
2. Chia sẻ mục tiêu, bối cảnh và ngữ cảnh: Mục tiêu & quy tắc, Bộ nhớ
Ở đây, con người và tác tử dùng chung một ngữ cảnh, nên các dữ kiện quan trọng luôn thống nhất.
Mục tiêu & quy tắc và Bộ nhớ của một dự án được dùng chung cho mọi cuộc trò chuyện trong dự án, và tác tử tuân theo chúng mỗi lần. Ví dụ, hãy đặt một định nghĩa như “chỉ số giữ chân theo tháng = người dùng mới quay lại vào tháng kế tiếp” vào Mục tiêu & quy tắc, và ghi các quyết định quan trọng vào Bộ nhớ của dự án. Khi một thành viên mới và các tác tử của họ tham gia, họ đọc đúng cùng một nội dung ngay từ ngày đầu.
3. Bàn giao qua tệp, tách riêng quá trình
Thư viện của dự án được đồng bộ giữa các thành viên, và mỗi mục cần làm có thể đính kèm bất kỳ tệp nào. Công việc được bàn giao bằng tệp, không phải bằng lịch sử chat.
Chúng tôi chủ ý tách riêng phần lớn quá trình ở giữa, để nó không trở thành nhiễu ngữ cảnh gây hại cho tác tử. Hai tab Tác vụ và Tự động hóa bị khóa chỉ thuộc về bạn. Một tác tử có thể đi qua hàng trăm bước và thử ba cách tiếp cận trước khi tạo ra một bản báo cáo. Đồng nghiệp của bạn chỉ nhận được bản báo cáo; quá trình nằm lại trong các tác vụ của riêng bạn và không bao giờ lọt vào ngữ cảnh của các tác tử bên họ.
4. Chia sẻ tác tử riêng với cả đội
Thành viên có thể chia sẻ tác tử riêng của mình cho những người khác trong đội sử dụng. Những tác tử này mang theo kinh nghiệm và con mắt đánh giá chất lượng của chủ sở hữu. Chia sẻ chúng giúp mọi người làm nhanh hơn, và những vấn đề mọi người phát hiện khi dùng có thể được khắc phục qua cơ chế tự tiến hóa, giúp nâng năng lực của cả dự án.
Khi một tác tử được chia sẻ, Orkas đóng gói chỉ dẫn làm việc và kỹ năng của nó, bao gồm cả những kỹ năng nó tự tích lũy trong quá trình làm việc. Bộ nhớ và lịch sử trò chuyện của nó không được đưa vào. Khi người chia sẻ cập nhật tác tử, các thành viên tự động nhận được phiên bản mới.
Một bài toán còn sớm và còn bỏ ngỏ
Sự cộng tác giữa người và tác tử vẫn đang ở giai đoạn rất sớm, và các câu trả lời chưa hội tụ. Khi mô hình tốt lên, nhiều phần trong những gì tác tử cần để cộng tác sẽ chuyển vào chính mô hình.
Một số mô hình đã có sẵn khả năng này: chạy song song nhiều tác tử con để khám phá một vấn đề từ nhiều góc độ, hoặc lập kế hoạch trước rồi điều các tác tử con đi thực hiện kế hoạch. Muse Spark Open, mô hình Meta phát hành dạng trọng số mở vào tháng 10 năm 2026, được mô tả là đã được huấn luyện để chia nhỏ công việc, giao cho các tác tử con và điều phối chúng (blog PyTorch).
Vì vậy, cách chúng ta cộng tác sẽ thay đổi khi mô hình tốt hơn. Mục cần làm, ngữ cảnh dùng chung, bàn giao bằng tệp và tác tử dùng chung là câu trả lời của chúng tôi cho những gì mô hình làm được hôm nay, chứ không phải hình thái cuối cùng.
Lời kết
Chúng tôi giữ lại điều không đổi: có người chịu trách nhiệm cho công việc, có người duyệt lại, mục tiêu và ngữ cảnh luôn thống nhất. Chúng tôi thiết kế lại điều đã đổi: bàn giao qua tệp, tách riêng quá trình, và biến kinh nghiệm cùng gu của mỗi người thành những tác tử cả đội dùng được.
Chúng tôi vẫn đang khám phá điều này và rất muốn cùng trao đổi. Nếu bạn điều hành một đội mà con người và tác tử cùng làm việc, hãy thử trước trên một dự án. Bạn có thể tải Orkas miễn phí cho macOS và Windows.