Xây dựng lại Manus với Manus: Điều gì đã thay đổi, điều gì đã đổ vỡ, và cách chúng tôi làm việc hiện nay
Bởi Tao Zhang, Đồng sáng lập và Giám đốc Sản phẩm, Manus
Vào cuối tháng Chín, trong giai đoạn nước rút của Manus 2.0, tôi đã gửi cho một kỹ sư của chúng tôi vài yêu cầu tính năng và báo cáo lỗi qua Slack. Sau đó tôi ghé xem anh ấy làm đến đâu. Màn hình của anh ấy có một hàng các phiên agent đang mở, một số trong Manus và một số trong Codex. Tôi nhấp vào một phiên. Lời nhắc chính là tin nhắn Slack của tôi, được dán nguyên văn.
Một năm trước, anh ấy sẽ đọc tin nhắn của tôi, suy ra ý tôi muốn gì, rồi mới viết code. Giờ đây một agent đọc yêu cầu, tìm đoạn code liên quan, và đề xuất một thay đổi. Công việc của kỹ sư là chỉ đạo công việc, kiểm tra nó, và chịu trách nhiệm về kết quả. Phần lớn thời gian một yêu cầu đang chạy, chứ không chờ anh ấy. Ngày nay, ở đây một kỹ sư có 10 đến 20 yêu cầu cùng chạy một lúc là chuyện thường.
Tôi tự hào vì đội ngũ của mình đã thích nghi nhanh đến vậy. Nhưng tôi cũng bất an. Tốc độ này có đúng không? Chúng tôi còn chưa nhận ra điều gì?
Chúng tôi xây dựng các agent tại Manus, nên chúng tôi tự đặt ra hai nguyên tắc. Chúng tôi sử dụng chính sản phẩm của mình cho công việc thực tế. Và chúng tôi liên tục tìm kiếm những nơi mà AI ngừng hoạt động.
Tôi muốn ghi lại những gì diễn ra bên trong một công ty khi con người và các agent làm việc song hành như một mặc định. Bài viết này đề cập đến ba đội — kỹ thuật, sản phẩm, và tiếp thị — và nó bao gồm cả những điều chưa hiệu quả. Đây là một báo cáo về một thí nghiệm đang diễn ra, không phải là định nghĩa về một "tổ chức AI-native".
Những gì chúng tôi đã học được cho đến nay:
•Không có điểm giữa. Thêm AI vào các cách làm việc cũ đôi khi chỉ tạo ra nhiễu. Mọi thứ chỉ thay đổi khi vòng lặp được khép kín.
•Các agent cần toàn bộ bức tranh. Bối cảnh tốt hơn mang lại nhiều lợi ích hơn so với lời nhắc tốt hơn.
•Niềm tin đến từ các bài kiểm thử và bối cảnh, chứ không chỉ từ chất lượng mô hình.
•Tính tự chủ cần một vạch đích. Các agent chỉ có thể tự chạy khi thành công có thể được kiểm tra. Ở mọi nơi khác, một con người sẽ quyết định.
•Nút thắt cổ chai sẽ dịch chuyển. Khi kỹ thuật trở nên nhanh hơn, việc quyết định xây dựng cái gì lại trở thành ràng buộc.
•Vai trò của con người không hề giảm đi. Nó chỉ trở nên tập trung hơn vào những việc có tác động lớn hơn.
1. Không có điểm giữa
Trước năm 2026, chúng tôi làm điều mà hầu hết các công ty đều làm: chúng tôi thêm AI vào cách làm việc hiện có. Điều này có nghĩa là bộ phận hỗ trợ sẽ gắn cờ các vấn đề bằng bản tóm tắt AI, các kỹ sư sử dụng trợ lý lập trình, và các bot đăng phân tích lên các kênh. Mỗi phần đều hữu ích riêng lẻ, nhưng không có nhiều phần được kết nối với nhau. Cho đến khi vòng lặp thực sự khép kín, chúng tôi chỉ đơn giản là làm việc theo cách cũ nhưng với rất nhiều AI nói chuyện chồng chéo lên nhau.
Có một câu mà chúng tôi thường quay lại: kỹ thuật phần mềm là lập trình được tích hợp theo thời gian. Viết code thì dễ đo lường; giữ cho một sản phẩm phức tạp khỏe mạnh trong nhiều năm thì không. Một tỷ lệ phần trăm cao code do AI viết có thể có nghĩa là tiến bộ thực sự, hoặc có thể có nghĩa là chất đống rác thải mà ai đó sẽ phải dọn sau này.
Bài kiểm tra mà chúng tôi quan tâm còn khó hơn. Manus là một sản phẩm phức tạp đã hoạt động hơn một năm. Liệu nó có thể tiếp tục cải thiện dưới các cách làm việc mới mà không sụp đổ, trong khi mỗi người làm được nhiều việc hơn không? Cho đến nay câu trả lời là có.
2. Cung cấp cho agent toàn bộ bức tranh
Giống như hầu hết các công ty công nghệ, chúng tôi mất nhiều thời gian nhất ở các điểm bàn giao. Một kỹ sư frontend và một kỹ sư backend sẽ mỗi người diễn giải một yêu cầu, thống nhất về một interface, rồi dành nhiều ngày để sửa những điểm không khớp. Hai người hiếm khi hiểu một yêu cầu theo cùng một cách.
Nếu AI có thể viết code xuyên suốt toàn bộ stack, liệu một người có thể làm chủ một yêu cầu từ đầu đến cuối không? Trở ngại chính là bối cảnh. Code của chúng tôi nằm trong các repository riêng biệt, nên không agent nào có thể nhìn thấy toàn bộ hệ thống cùng một lúc.
Câu trả lời của chúng tôi cho điều đó bắt đầu bằng một thử nghiệm nội bộ. Chúng tôi muốn xem AI có thể đi xa đến đâu trong việc xây dựng một sản phẩm với sự can thiệp tối thiểu của con người và gần như không có mã viết tay. Phương pháp mà chúng tôi phát triển trong quá trình đó đã trở thành công cụ nội bộ mà hiện chúng tôi gọi là Manus-mono, hay Mono.
Mono không hợp nhất các kho mã của chúng tôi. Nó là một điểm truy cập duy nhất cộng với một sổ tay hướng dẫn được viết cho agent: mỗi kho mã làm gì, chúng kết hợp với nhau như thế nào, và chúng tôi làm việc ra sao. Agent sẽ lấy bất cứ thứ gì nó cần. Chúng tôi cũng duy trì một thư viện các bản ghi quyết định kiến trúc, nhờ đó mỗi phiên làm việc của agent đều bắt đầu với lý do đằng sau các quyết định trước đây, chứ không chỉ là mã. Khi bất kỳ ai làm việc với một agent, agent đó đã có ngữ cảnh của tất cả những người đi trước.
Mono phát triển theo từng bước, và mỗi bước giải quyết nút thắt mà bước trước đó bộc lộ:
1.Nhìn toàn bộ hệ thống. Chúng tôi bổ sung ngữ cảnh kinh doanh mà không một kho mã đơn lẻ nào chứa đựng, và sử dụng Git worktrees để làm việc song song.
2.Xác minh cục bộ. Trước đây, một lần push lên môi trường kiểm thử mất 5 đến 10 phút. Giờ đây toàn bộ Manus stack chạy được trên một chiếc laptop, và các kiểm tra chỉ mất vài giây.
3.Gỡ lỗi các sự cố môi trường production. Với quyền hạn được giới hạn phạm vi, Mono có thể đọc nhật ký, cấu hình và báo cáo lỗi mà nó cần để chẩn đoán lỗi trong môi trường production.
4.Thực hiện phát hành từ đầu đến cuối. Mono giờ đây xử lý các bước phát hành mà trước đây công việc hay bị đình trệ. Con người vẫn là người đưa ra quyết định phê duyệt.
5.Kiểm thử từ đầu đến cuối. Khi việc xác minh trở thành phần chậm chạp, Mono bắt đầu chạy các luồng người dùng thực với tài khoản thử nghiệm, trong trình duyệt và trong trình giả lập di động.
(Mono hoạt động như thế nào và nó đã phát triển ra sao. Được thực hiện bởi một đồng đội với Manus.)
Đôi khi mọi người hỏi liệu Mono có phải là một wiki mã nguồn hay không. Tài liệu là một phần của nó, nhưng phần còn lại là mọi thứ xoay quanh mã: cách chúng tôi kiểm thử, cách chúng tôi phát hành, chúng tôi quyết định điều gì và tại sao, cũng như agent được phép và không được phép đụng vào những gì.
Theo thời gian, Mono đã trở thành một cơ sở tri thức dùng chung ngày càng tốt hơn khi mọi người đóng góp vào. Ví dụ, kỹ sư vận hành của chúng tôi mệt mỏi vì liên tục được yêu cầu hỗ trợ phát hành, nên anh ấy đã viết quy trình phát hành vào Mono. Giờ đây ai cũng có thể thực hiện một lần phát hành, agent cũng vậy, nhưng việc phê duyệt vẫn thuộc về những người có quyền phát hành. Tôi thích cách đội ngũ làm việc: một người giải quyết nỗi bực bội của chính mình, và điều đó giúp cả công ty nhanh hơn một chút.
Đội ngũ giờ đây mặc nhiên cho rằng một người có thể phát hành một yêu cầu trên mọi nền tảng. Đội di động của chúng tôi suốt thời gian qua vẫn chỉ có bảy người. Họ duy trì bốn ứng dụng trên hai sản phẩm và theo kịp tốc độ với web.
Mono lan rộng khắp công ty mà không có bất kỳ mệnh lệnh từ trên xuống nào. Tôi nghĩ văn hóa giải thích cho điều đó nhiều như chính công cụ này. Thử nghiệm các giới hạn của AI là một phần lý do tồn tại của chúng tôi, và tổ chức của chúng tôi phẳng. Một công cụ chỉ đi xa đến mức tổ chức cho phép.
3. Khép kín vòng lặp: từ báo cáo lỗi của người dùng đến bản sửa lỗi đã được xác minh
Mono cho phép bất kỳ ai làm việc trên bất kỳ phần nào của sản phẩm. Đó là một nửa của câu chuyện. Nửa còn lại là để các agent tự tìm ra vấn đề.
Tại hầu hết các công ty internet, báo cáo lỗi của người dùng phải đi qua bộ phận hỗ trợ, sản phẩm và phân loại trước khi đến được tay một kỹ sư có thể khắc phục.
Với chúng tôi, một agent nội bộ giờ đây sẽ điều tra báo cáo trước và truy ngược vấn đề về thay đổi đã gây ra nó. Sau đó nó đăng trong Slack và gắn thẻ kỹ sư sở hữu thay đổi đó. Kỹ sư quyết định xem đây có phải là lỗi mình cần sửa hay không và giao cho agent của chính mình. Một agent riêng biệt sẽ kiểm tra bản sửa lỗi bằng cách chạy các bài kiểm thử và luồng quan trọng.
Ba agent, ba vai trò: một phân loại, một thực hiện công việc, một kiểm tra kết quả. Người ở giữa đưa ra các quyết định. Một tỷ lệ ngày càng tăng công việc kỹ thuật của chúng tôi giờ đây bắt đầu theo cách này, với một agent mang một vấn đề đến cho một người.
Vòng lặp này có những giới hạn rõ ràng. Agent đọc báo cáo người dùng không thể thay đổi mã. Nó chỉ có thể điều tra và báo cáo lại cho chúng tôi. Thay đổi đến từ agent của chính kỹ sư, sau khi kỹ sư quyết định. Không có gì được phát hành mà không có sự phê duyệt của một người có quyền phát hành.
4. Cách chúng tôi học được cách tin tưởng mã do agent viết
Trong một thời gian dài, mọi thay đổi được đưa vào nhánh chính của chúng tôi đều cần sự phê duyệt từ một trong hai kỹ sư cấp cao. Chúng tôi không đủ tin tưởng AI để bỏ qua bước đó. Khi các agent tạo ra nhiều mã hơn, bước đánh giá đó trở thành nút thắt cổ chai.
Về khả năng lập trình thuần túy, các mô hình đã khá mạnh. Chúng tôi nhận ra sự khác biệt nằm ở hai điều. Thứ nhất, con người biết cách kiểm thử công việc của mình. Thứ hai, con người đã tham gia vào các cuộc thảo luận ở thượng nguồn và hạ nguồn, nên họ biết "đúng" có nghĩa là gì đối với doanh nghiệp. Mã đúng không giống với sản phẩm đúng.
Chúng tôi đã giải quyết cả hai:
•Cho phép agent tham gia thảo luận. Agent của mỗi kỹ sư giờ đây hiện diện trong các luồng Slack mà nó được thêm vào, và theo dõi ngữ cảnh. Khi ai đó cuối cùng nói "Bắt đầu đi", agent đã biết nhóm đã quyết định gì và tại sao.
•Cho phép agent kiểm thử đầu cuối. Phối hợp với nhóm backend, chúng tôi đã trao cho agent khả năng chạy các luồng thực tế và kiểm thử hồi quy trong Manus sau mỗi thay đổi. Khi độ bao phủ kiểm thử tăng lên, lòng tin của chúng tôi cũng tăng theo.
Ngày nay, mọi thay đổi đều trải qua quá trình xác minh đó và qua một bot đánh giá mã chạy trên mô hình mạnh nhất hiện có, với các quy tắc bổ sung cho các khu vực nhạy cảm như thanh toán. Bot đã thay thế hàng đợi, chứ không phải quyết định của con người. Một agent có thể mở pull request, nhưng không thể merge vào nhánh chính của chúng tôi nếu không có sự phê duyệt rõ ràng từ một người. Con người vẫn quyết định những gì được xây dựng và ai có thể phát hành.
5. Tính tự chủ cần có mục tiêu cuối cùng
Lòng tin có giới hạn, và chúng tôi đã nhận ra điều này một cách khó khăn.
Có một thời điểm, mọi người đều hào hứng về các vòng lặp agent hoàn toàn tự chủ, nên chúng tôi đã thử. Một agent thu thập phản hồi từ các kênh phản hồi nội bộ của chúng tôi và khởi tạo một dự án cho mỗi mục. Một đồng đội đã để nó chạy suốt cuối tuần. Sáng thứ Hai, hơn 200 mục đang chờ quyết định của anh ấy.
Tại sao không để agent cũng đưa ra những quyết định đó? Các vòng lặp tự chủ hoạt động khi hệ thống có thể kiểm tra xem mục tiêu đã đạt được chưa. Kiểm thử đạt hoặc không đạt; một trang tải được hoặc không. Hầu hết công việc thực tế không có kiểm tra như vậy. Một người phải đánh giá xem nó đã hoàn thành chưa, và liệu nó có đáng làm hay không.
Chúng tôi rút ra hai bài học từ cuối tuần đó. Thứ nhất, con người không thể đưa ra quyết định nhanh như một vòng lặp không kiểm soát tạo ra chúng. Thứ hai, nếu không ai quyết định xem một việc nào đó có nên được thực hiện hay không, thì không ai chịu trách nhiệm về kết quả. Vòng lặp sửa lỗi trong phần 3 hoạt động vì các kiểm thử định nghĩa thành công. Các quyết định về sản phẩm không có kiểm thử, nên mọi thay đổi sản phẩm tại Manus vẫn bắt đầu bằng việc một người quyết định xem nó có đáng làm hay không.
6. Khi kỹ thuật trở nên nhanh hơn, sản phẩm trở thành nút thắt cổ chai
Một quy trình sản phẩm truyền thống có nhiều lần bàn giao, và ưu tiên bị trôi đi một chút ở mỗi lần. Khi các agent lập trình giúp các kỹ sư làm việc nhanh hơn, một vấn đề mới xuất hiện: không có đủ product manager để viết các yêu cầu tốt. Lần đầu tiên, kỹ thuật không còn là ràng buộc.
Tại Manus, giải pháp đầu tiên của chúng tôi là yêu cầu một vài kỹ sư trở thành "builder" sở hữu một vấn đề từ khám phá đến ra mắt. Rất ít người có cả phán đoán kỹ thuật và sản phẩm. Tiếp theo, chúng tôi cho phép PM thay đổi mã. Điều đó cũng bị đình trệ. Các lần bàn giao vẫn còn đó, và không có bản năng của một kỹ sư, PM có thể thay đổi nội dung và tương tác nhưng không thể thay đổi logic cơ bản.
Mono giải quyết cả hai vấn đề vì nó mang theo các quy tắc:
•Bất kỳ thay đổi nào ảnh hưởng đến lệnh gọi mô hình hoặc chi phí đều cần sự phê duyệt của chủ sở hữu trước khi viết mã.
•Mọi thay đổi đều trải qua quá trình đánh giá và kiểm thử giống như thay đổi của một kỹ sư.
•Mono có thể thực hiện đăng ký và thanh toán với tài khoản thử nghiệm và ghi lại từng bước, để PM có thể chỉ ra chính xác thời điểm có sự cố.
Đây là ví dụ thực tế. Một PM làm việc về chuyển giọng nói thành văn bản đã nhờ Manus đánh giá hơn 10 mô hình, sau đó chọn một. Cô ấy kéo mã frontend qua Mono, xây dựng bản demo trong hệ thống thiết kế của chúng tôi, và nhờ Manus kết xuất từng kịch bản người dùng thành hình ảnh để cô ấy xem xét. Cô ấy biến bản demo thành video. Kế hoạch đủ rõ ràng để cô ấy tự xây dựng tính năng, bao gồm cả giao diện web và desktop.
Mọi người đã đưa ra ba quyết định trong suốt quá trình. Cô ấy chọn mô hình. Bộ phận sản phẩm và thiết kế duyệt bản demo. Một kỹ sư có quyền phát hành đã xem xét mã nguồn. Một năm trước, không điều nào trong số này có thể thực hiện được.
Chúng tôi mô tả điều này là chuyển từ con người trong vòng lặp sang con người trên vòng lặp. AI từng làm 70-80% một tác vụ và con người làm nốt phần còn lại. Giờ đây con người đặt ra quy tắc, giám sát nhiều Agent, kiểm tra phương pháp và kết quả tại các điểm then chốt, can thiệp khi cần, và chịu trách nhiệm về kết quả.
Một số PM giờ đây bàn giao một video ngắn thay vì bản đặc tả hoặc mockup. Trong vài phút, nó cho thấy use case, từng màn hình, mỗi lượt nhấp làm gì, các trường hợp biên hoạt động ra sao, và tất cả vận hành bên dưới như thế nào. Với chúng tôi, bộ phận thiết kế, kỹ thuật và QA thống nhất nhanh hơn về định nghĩa "hoàn thành", và PM chỉ cần giải thích một lần.
(Video yêu cầu sản phẩm cho tính năng nhập liệu bằng giọng nói)
Hôm nay khoảng một nửa số PM của chúng tôi tự mình phát hành tính năng, và mọi PM đều đã commit mã. Các nhà thiết kế cũng đã bắt đầu. Một PM đã viết phần lớn giao diện Manus Studio trong Manus 2.0. Một người khác đã viết Video Editor. Đằng sau mỗi điều này là một người đã dành nhiều tháng để vượt qua giới hạn vai trò trước đây của họ. Đó là điều tôi tự hào nhất.
Điều này không có nghĩa là tất cả mọi người đều phải trở thành người xây dựng. Khi bất kỳ ai trong công ty cũng có thể xây dựng, mọi người có thể phát hành những thứ không nên tồn tại. Nhóm sản phẩm của chúng tôi thường đặt một câu hỏi: "Nếu việc này chỉ mất một giây và không tốn phí, bạn có phát hành nó không?" Đôi khi câu trả lời là không. Chúng tôi vẫn cần những người sở hữu mô-đun quyết định cái gì được xây dựng, cái gì không, và cái gì cuối cùng người dùng sẽ thấy. Chúng tôi cũng cần những người duy trì hạ tầng như Mono. Khi việc xây dựng trở nên dễ dàng, việc quyết định xây dựng cái gì lại càng quan trọng hơn.
7. Một đồng đội AI bên trong quy trình marketing
Một quan hệ đối tác marketing trải qua các bước xem xét kịch bản, định giá, hợp đồng, phê duyệt, thanh toán, ra mắt và xem xét kết quả. Những bước đó nằm trong email, công cụ hợp đồng, hệ thống phê duyệt, bảng tính và nền tảng quảng cáo. Phần lớn công việc trước đây là chuyển thông tin giữa chúng, khiến còn ít thời gian cho công việc sáng tạo đòi hỏi phán đoán.
Chúng tôi bắt đầu với một vấn đề nhỏ: khi nội dung đối tác hoặc quảng cáo được đăng tải, chúng tôi thường biết tin muộn. Vì vậy chúng tôi để AI viết một script phát hiện khi nội dung được xuất bản. Rồi chúng tôi muốn có dữ liệu hiệu suất. Rồi là bản đánh giá các quan hệ đối tác trong quá khứ. Rồi toàn bộ quy trình nội bộ được kết nối: khi hợp đồng được ký hoặc một phê duyệt được thông qua, Agent cập nhật trạng thái và thông báo cho người phụ trách bước tiếp theo.
Manus đã xây dựng tất cả những điều này vào một trang nội bộ. Với con người, đó là các dashboard và lịch. Với Agent, đó là một bộ công cụ. Agent sử dụng những công cụ đó bên trong quy trình của chúng tôi chính là thứ chúng tôi gọi là đồng đội AI. Nó chỉ hoạt động trong các kênh và hệ thống mà nhóm đã kết nối với nó, với phạm vi quyền truy cập giới hạn trong quy trình này.
Đây là những gì nó làm:
•Nó quản lý hàng đợi của chính mình. Nhiều người nhắn tin cho nó cùng lúc, vì vậy nó trò chuyện với mọi người trong một phiên "lễ tân" duy nhất và chuyển các tác vụ sang các phiên song song. Nó quyết định xem một tin nhắn có liên quan đến mình hay không, rồi quyết định có nên ngắt công việc hiện tại hay chờ đợi. Nó tự đề xuất những quy tắc này trong quá trình phát triển, và chúng tôi đã xem xét trước khi giữ lại.
•Nó học từ ngữ cảnh được chuyển tiếp. Một thay đổi chiến lược trước đây có nghĩa là một cuộc họp và một bản tóm tắt viết tay. Giờ đây trưởng nhóm marketing của chúng tôi chuyển tiếp cuộc thảo luận và nói, "Hãy học điều này."
•Nó luôn theo dõi các mục tiêu dài hạn. Có một lần, các đồng đội trong một luồng Slack mà nó đã được thêm vào không thể nhớ được dự án đang ở đâu. Không bị tag, nó đã trả lời: "B vẫn đang trong giai đoạn thử nghiệm. Chúng ta có nên chờ kết quả của A trước khi xem xét B không?"
•Nó kiểm tra sự thật với các nhóm khác. Sau khi chúng tôi ra mắt rigging mô hình 3D, nó đã hỏi nhóm sản phẩm những gì được hỗ trợ. Nó biết rằng rigging bao gồm bảy danh mục, bao gồm cá, rắn và động vật bốn chân, nên các mô tả của chúng tôi vẫn chính xác.
Giờ đây các đồng đội đưa nó vào các buổi đánh giá kịch bản và định giá, vì nó đã đọc các hồ sơ hợp tác trong quá khứ của chúng tôi. Con người vẫn là người ra quyết định.
Trang nội bộ cũng có thể được cải thiện từ chính người dùng của nó, bao gồm cả Agent. Khi Agent gặp trở ngại, nó gửi yêu cầu qua một endpoint phản hồi. Điều đó mở một tác vụ phát triển trong Manus thông qua Automations trong Manus 2.0, và một kỹ sư xem xét thay đổi trước khi phát hành. Nó đã chạy được khoảng một tuần. Chúng tôi cần nhiều trường hợp hơn nữa trước khi dựa vào nó.
Vậy mọi người trong nhóm làm gì? Ba điều vẫn thuộc về họ. Họ đưa ra và chịu trách nhiệm về mọi quyết định quan trọng. Họ xử lý những trường hợp mà Agent chưa từng gặp, và dạy nó phải làm gì hoặc hỏi ai. Và họ chuyển hướng nó bất cứ khi nào phân tích của nó chỉ ra một góc nhìn mới.
8. Ngắt quãng lẫn nhau ít hơn
Trên tất cả các nhóm này, nhiều câu hỏi không còn đòi hỏi phải làm gián đoạn ai đó.
Hỏi Agent trước. Một đồng nghiệp đã xây một bot Slack trên Mono chạy trên máy tính đám mây và trả lời trong luồng. Những người không phải kỹ sư sử dụng nó nhiều nhất. Tính năng này hoạt động như thế nào? Chuỗi này ở đâu? Đã phát hành chưa? Họ không cần phải tìm chủ sở hữu trước nữa.
Mở phiên làm việc thay vì hỏi về tình trạng cập nhật. Tiến trình của một kỹ sư trước đây nằm trong các cuộc trò chuyện AI riêng của họ, không ai thấy được khi họ đăng xuất. Vì vậy, chúng tôi đã xây dựng một tính năng nội bộ cho phép các thành viên trong một dự án xem phiên làm việc của nhau và yêu cầu tham gia. Một kỹ sư có thể xây dựng phần lớn một tính năng với Agent, sau đó một PM tham gia cùng phiên để điều chỉnh khoảng cách, kiểu dáng và nội dung. Đăng bài trong phiên của người khác cần được họ chấp thuận, và chúng tôi vẫn đang hoàn thiện các quyền truy cập.
(Ví dụ minh họa: cách một kỹ sư, một PM và một nhà thiết kế làm việc trong một phiên. Không phải thay đổi giá thực tế.)
Mục đích không phải là nói chuyện với nhau ít hơn. Mà là ngắt quãng nhau ít hơn.
Chỉ quyết định những gì cần quyết định. Người dùng AI nhiều nhất của chúng tôi duy trì một phiên chính với một nhiệm vụ duy nhất: liệt kê những gì cần anh ấy quyết định, kèm theo đề xuất cho từng mục. Khi Slack trở nên bận rộn, anh ấy đứng ngoài và hỏi: "Tôi cần quyết định gì ngay bây giờ?"
Tôi cũng làm điều tương tự. Tôi có hơn 20 việc cần làm mỗi ngày, và như tôi đã chia sẻ công khai, tôi bị ADHD. Bắt đầu là phần khó nhất đối với tôi. Giờ đây mỗi việc cần làm đều được đưa vào một dự án Manus chuyên dụng để biến từng việc thành nhiệm vụ riêng. Nó bắt đầu những gì có thể. Khi không chắc chắn, nó hỏi tôi về bối cảnh và PM nào nên phụ trách. Sau đó, sử dụng quyền truy cập mà tôi đã cấp cho nó vào Slack, Gmail và Notion của tôi, nó thu thập bối cảnh và giao cho PM một yêu cầu đầy đủ thay vì một ghi chú một dòng. Đối với tôi, sự thay đổi không chỉ về hiệu quả. Giờ đây tôi dành ít thời gian hơn trong ngày để lo lắng về việc nên bắt đầu từ đâu, điều này rất lớn ở mức độ cá nhân.
9. Có đáng với chi phí không?
Chúng tôi chi nhiều cho AI, và chúng tôi theo dõi chi tiêu đó sát sao. Chúng tôi không dùng nó để đánh giá hiệu suất của ai. Chúng tôi dùng nó để đánh giá chính khoản chi tiêu đó: nó có đang mang lại lợi ích ngay bây giờ, hay đang chuẩn bị cho tương lai?
Đây là những gì chúng tôi nghĩ nó mang lại cho chúng tôi và chúng tôi kỳ vọng chi phí sẽ đi đến đâu:
•Nó mua được thời gian và sự chú ý. Khi một nhóm phát triển, việc phối hợp ngốn sự chú ý của mọi người. AI bảo vệ sự chú ý của từng người và trao cho họ quyền sở hữu đầy đủ hơn đối với công việc của mình. Và chúng tôi vẫn đang tuyển dụng.
•Sử dụng những mô hình tốt nhất là cách chúng tôi tìm hiểu giới hạn của AI nằm ở đâu. Thiết lập xác minh và đánh giá mã được mô tả trong phần 4 chạy trên những mô hình mạnh nhất mà chúng tôi có thể có. Đồng nghiệp phụ trách năng suất nhà phát triển gọi đó là khoản chi có giá trị tốt nhất của chúng tôi.
•Chi phí sẽ giảm thông qua sản phẩm. Ngày càng nhiều quá trình phát triển của chúng tôi diễn ra trong Manus Studio, sản phẩm của chính chúng tôi, vì vậy dữ liệu sử dụng của chúng tôi cho thấy nơi tokens bị lãng phí. Các bản sửa lỗi được đưa vào sản phẩm, nên chúng cũng sẽ giúp Manus hiệu quả hơn cho người dùng. Chúng tôi kỳ vọng chi phí hôm nay sẽ giảm đáng kể khi các mô hình trở nên rẻ hơn và chúng tôi loại bỏ sự lãng phí. Đó là một niềm tin, không phải lời hứa!
10. Những gì chưa hoạt động
Có ít gián đoạn hơn, nhưng sự chú ý lại bị phân mảnh hơn. Một người từng xử lý bốn hoặc năm việc một ngày giờ có thể đẩy 20 hoặc 30 việc tiến lên cùng lúc. Mỗi lần chuyển đổi đồng nghĩa với việc tải lại bối cảnh. AI mở rộng những gì mọi người có thể làm, và nó cũng thúc đẩy họ làm nhiều hơn. Một PM nói với tôi rằng mỗi khi có một nhiệm vụ đang chạy, cô ấy không thể cưỡng lại việc khởi động một Agent khác. Làm nhiều việc hơn không phải là mục tiêu. Chúng tôi coi đây là vấn đề cần giải quyết, không phải tốc độ để ăn mừng.
Thông tin bị phân tán hơn. Trưởng bộ phận sản phẩm của chúng tôi trước đây biết mọi thay đổi và lý do thực hiện. Giờ đây đôi khi anh ấy chụp màn hình một vấn đề và hỏi Mono: "Ai đã thay đổi cái này?" Thật buồn cười, nhưng câu hỏi là có thật. Khi mọi người đều được trao quyền thay đổi sản phẩm, ai chịu trách nhiệm cho tổng thể?
Quyền chia sẻ cần được thiết kế lại. Khi công việc có thể được chia sẻ và bàn giao, và các Agent tham gia vào nhiều cuộc trò chuyện của chúng tôi hơn, chúng tôi phải quyết định cái gì mở và cái gì cần phê duyệt.
Các bản sửa lỗi của chúng tôi vẫn còn cơ bản. Hiện tại, một Agent giám sát các Agent khác và chỉ báo cáo những gì bị kẹt và những gì cần quyết định từ con người. Chúng tôi biết điều này có thể tốt hơn.
11. Những gì chúng tôi đang xây dựng tiếp theo
Những vấn đề này chỉ ra công việc sản phẩm mà có lẽ các nhóm khác cũng sẽ cần. Chúng tôi không lên kế hoạch cho những tính năng này từ trước. Chúng xuất phát từ những vấn đề mà chính chúng tôi liên tục gặp phải.
•Các phiên làm việc như không gian làm việc chung. Một người nêu vấn đề, một nhà thiết kế đề xuất giải pháp, một kỹ sư xây dựng nó, và một PM vận hành nó, tất cả cùng một nơi.
•Công việc di chuyển giữa các thiết bị và con người. Máy cục bộ và máy đám mây luôn kết nối, để công việc có thể tiếp tục khi mọi người rời đi.
•Agent tìm ra những phương án mà con người chưa nghĩ tới. Một Agent hoạt động bên trong hệ thống của công ty, với quyền truy cập phù hợp, sẽ có thể đề xuất giải pháp, chứ không chỉ thực thi chỉ dẫn.
Chúng tôi sẽ thử nghiệm những điều này trên chính mình trước, rồi mới mang đến cho người dùng.
12. Những gì mọi người làm bây giờ
Hình ảnh người kỹ sư mở một loạt phiên Agent không chỉ là câu chuyện về hiệu suất. Đó là sự thay đổi về nền tảng vận hành của một tổ chức. Trước đây, các công ty vận hành thông tin thông qua vai trò và cấp bậc. Những gì một người có thể làm phụ thuộc vào số lượng người và nguồn lực họ có thể huy động. Giờ đây, chúng ta dành một chút thời gian cung cấp bối cảnh và công cụ cho AI, và dành nhiều thời gian hơn cho việc đưa ra phán đoán và quyết định. Ngày càng thường xuyên hơn, chính Agent là bên mang vấn đề đến cho chúng ta. Quyết định phải làm gì với nó vẫn là công việc của chúng ta.
Chúng tôi đã đùa với nhau: nếu Manus có thể làm được nhiều như vậy, tại sao phải đến văn phòng? Cứ để các Agent tự giải quyết. Nhưng những câu hỏi quan trọng vẫn cần con người nêu ra, tranh luận và quyết định. Ví dụ, điều gì được coi là một sản phẩm tốt? Hoặc, nói hơi quá một chút: xây dựng một sản phẩm tuyệt vời với doanh thu thực tế liên tục đẩy giới hạn của AI, hay chạy theo biên lợi nhuận? AI không biết chúng ta muốn cái nào. Chúng ta thì biết. Văn hóa và niềm tin đến từ việc cùng nhau giải quyết mọi việc, ngày qua ngày và trong những khoảnh khắc quan trọng. Đó là nền tảng mà công việc trong mỗi phiên làm việc dựa vào.
Vì vậy, hiện tại, đây là câu trả lời của chúng tôi. Trong thử nghiệm của chúng tôi với tư cách là một tổ chức AI-native, vai trò của con người không hề giảm đi. Nó trở nên tập trung hơn vào những lĩnh vực mà họ có thể tạo ra tác động lớn nhất: xác định vấn đề, đánh giá chất lượng, quyết định việc gì đáng làm, chịu trách nhiệm về kết quả.
Đó cũng là lý do chúng tôi vẫn đang tuyển dụng. Kỹ năng và khả năng phán đoán của con người là trung tâm của cách làm việc này — và điều đó sẽ không thay đổi trong tương lai gần.
Khi viết những dòng này, tôi tò mò bài đăng này sẽ nói gì vào một năm sau. Mỗi công ty có mục tiêu, cấu trúc và văn hóa khác nhau, vì vậy có thể không có câu trả lời chuẩn nào và không có hình thức cuối cùng nào. Nhưng đối với một công ty xây dựng Agent, việc tìm ra cách con người và AI làm việc cùng nhau không phải là tùy chọn. Đó là một phần của công việc. Chúng tôi sẽ tiếp tục theo đuổi điều đó, và sẽ tiếp tục chia sẻ những gì chúng tôi học được.
Lưu ý về các con số. Số liệu trong bài đăng này đến từ các hồ sơ nội bộ. Quy mô nhóm và số liệu triển khai của PM được tính đến cuối tháng Mười. Một số điểm là ước tính hoặc trải nghiệm của một người chứ không phải là các phép đo lường.
