Jack Dorsey, nhà sáng lập Twitter, ra mắt Buzz kết hợp chat nhóm, AI agent và lưu trữ Git

 (runtimewire.com)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Block ra mắt workspace mã nguồn mở Buzz, kết nối nhân viên, AI agent, hội thoại và kho phần mềm vào một hệ thống định danh duy nhất, nhằm giảm phụ thuộc vào Slack và GitHub
  • Lưu tin nhắn, phản ứng, bước workflow, sự kiện mã nguồn và phê duyệt dưới dạng sự kiện Nostr đã ký, đồng thời cấp cặp khóa, tư cách thành viên kênh và audit trail giống nhau cho con người lẫn agent
  • Agent có thể làm từ tìm kiếm hội thoại đến gửi patch, review code và chạy workflow; các harness Goose, Codex, Claude Code tách workspace khỏi mô hình nền tảng
  • Cung cấp khả năng tự host và quyền sở hữu dữ liệu, nhưng mọi thao tác đọc/ghi đều đi qua một relay trung tâm duy nhất, nên đơn vị vận hành phải chịu trách nhiệm về tính sẵn sàng, sao lưu, bảo mật và nâng cấp
  • Gộp chat, lưu trữ mã nguồn, tự động hóa, tìm kiếm và điều phối agent vào một nơi, nhưng ứng dụng di động và thông báo đẩy vẫn chưa hoàn thiện; tỷ lệ áp dụng, giá và số khách hàng bên ngoài cũng chưa được công bố

Workspace hợp nhất kết nối con người và agent

  • Buzz là workspace mã nguồn mở có thể tự host, đặt nhân viên, AI agent, hội thoại và kho phần mềm dưới một hệ thống định danh duy nhất
    • Jack Dorsey muốn dùng nó để giảm sự phụ thuộc của Block vào Slack và GitHub
    • Kho công khai của Block cũng ghi tài liệu về bản build nội bộ riêng, được tùy chỉnh cho relay nội bộ và nhà cung cấp agent
  • Lấy Nostr relay tự host làm trung tâm, Buzz lưu tin nhắn, phản ứng, bước workflow, sự kiện mã nguồn và phê duyệt dưới dạng sự kiện được ký bằng mật mã
    • Cả nhân viên lẫn agent đều có cặp khóa riêng, tư cách thành viên kênh và audit trail
    • Nhờ định danh chung và sự kiện đã ký, agent có thể tham gia như những thành viên có thể truy vết trách nhiệm, vượt ra ngoài vai trò chatbot truyền thống
  • Agent có thể tìm kiếm hội thoại trước đó, xem kho, gửi patch, review code, chạy workflow, chỉnh sửa canvas dùng chung và tạo kênh
    • Cung cấp CLI cho agent và các harness Goose, Codex, Claude Code để tách mô hình nền tảng khỏi workspace
  • Đặc tả dự án định nghĩa một software forge tích hợp sử dụng chuẩn Git Smart HTTP
    • Biến nhánh tính năng thành kênh chuyên dụng và lưu giữ patch, kết quả tích hợp liên tục, ý kiến review và quyết định merge trong cùng một bản ghi
    • Kho, hội thoại và lịch sử workflow cùng chia sẻ một chỉ mục tìm kiếm
  • Hiện các kênh, thread, tin nhắn trực tiếp, canvas dùng chung, media, tìm kiếm, audit log, ứng dụng desktop và workflow dựa trên YAML đã hoạt động
    • Cung cấp các bản build package cho macOS, Windows và Linux, áp dụng giấy phép Apache 2.0

Cấu trúc relay đơn và các hạn chế của sản phẩm giai đoạn đầu

  • Dorsey giới thiệu Buzz như một sản phẩm phi tập trung và có chủ quyền tự quản, nhưng theo tài liệu kiến trúc, hiện chưa có trao đổi sự kiện P2P giữa các relay, tầng gossip hay chức năng sao chép
    • Mọi thao tác đọc và ghi đều đi qua một relay duy nhất, nơi xác thực người dùng, xác minh chữ ký, lưu trữ và phân phối sự kiện
    • Tổ chức có thể sở hữu relay, domain và dữ liệu của riêng mình, đồng thời dùng cặp khóa Nostr có thể di chuyển, nhưng trong từng cộng đồng, relay đó vẫn là máy chủ có thẩm quyền
    • Nhà cung cấp hosting có thể vận hành nhiều cộng đồng được cô lập với nhau trên hạ tầng dùng chung
  • Tự host mang lại quyền kiểm soát hạ tầng và vị trí dữ liệu, nhưng chuyển trách nhiệm về tính sẵn sàng, sao lưu, bảo mật và nâng cấp cho bên vận hành
    • Sự kiện đã ký hỗ trợ quy trách nhiệm hành vi và audit trail, nhưng không loại bỏ rủi ro vận hành máy chủ
  • Buzz có thể dùng cho thử nghiệm và phát triển, nhưng tài liệu nhiều lần xếp nó là sản phẩm chưa hoàn thiện
    • Client di động đang được phát triển và thông báo đẩy hiện chưa được cung cấp
    • Cổng phê duyệt workflow có các thành phần cơ sở dữ liệu, API và giao diện, nhưng chưa có đường thực thi hoàn chỉnh
    • Bản desktop 0.4.21 được phát hành ngày 21/7, gồm các bổ sung và sửa lỗi liên quan đến điều khiển agent, xác thực và onboarding workspace
  • Buzz muốn thay thế chat, lưu trữ mã nguồn, tự động hóa workflow, tìm kiếm dự án và một phần điều phối agent bằng một hệ thống sự kiện duy nhất
    • Cấu trúc hợp nhất có thể giảm công việc tích hợp cần thiết để cung cấp ngữ cảnh và quyền truy cập hạn chế cho agent
    • Ngược lại, các sản phẩm hiện có được tách theo vai trò cho phép chỉ thay một công cụ mà không cần di chuyển toàn bộ stack phát triển
  • Block là case khách hàng đầu tiên được nêu trong tài liệu Buzz, nhưng tỷ lệ áp dụng, giá và số lượng khách hàng bên ngoài chưa được công bố; hiện dự án đang ở giai đoạn cung cấp bản build mã nguồn mở và kêu gọi đóng góp

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Ý kiến trên Hacker News

  • Ảnh chụp màn hình đó trông như một phim kinh dị kiểu David Lynch. Khi ai đó nói “#engineering. Đây là hướng đi mới. Chúng ta chuyển prototype sang Flutter”, người và bot agent với những cái tên dễ thương cùng emoji trò chuyện kiểu “Phần vật lý xử lý xong rồi, UI shell thì sao @Honeybot?”
    Khó tưởng tượng một thế giới nơi việc tổ chức phát triển phần mềm theo cách này lại tự nhiên, và việc nó dùng thứ gì đó giống blockchain cũng tạo cảm giác rất điển hình
    https://github.com/block/buzz/blob/main/docs/assets/screensh...

    • Tôi e rằng lập trình trong tương lai sẽ mang lại kiểu tuyệt vọng như Ian McKellen quay phông xanh. Có thể giống tình cảnh một lão làng sân khấu Shakespeare khi quay 《The Hobbit》 mà không có diễn viên thật bên cạnh, cảm thấy “công việc của tôi là diễn với người khác, không phải diễn một mình”
      https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
    • Một trong những lý do tôi lao vào nghiên cứu AI khi còn nhỏ là kỳ vọng rằng một ngày nào đó sẽ có những thực thể thông minh có thể trò chuyện và tương tác như con người. Giờ điều đó đã thực sự khả thi, dường như ai cũng ghét, nhưng tôi vẫn thích và thấy nỗ lực biến AI agent thành thành viên nhóm là rất hay
      Tuy nhiên, thay vì những bản sao chỉ biết nịnh nọt, cần trao cho chúng cá tính thật sự, để sự khác biệt giữa từng agent thể hiện rõ cả ở năng lực lẫn hành vi
    • Màn hình đó là demo dựa trên script vì khó đồng bộ chuyển động của nhiều người và agent theo thời gian thực; cũng có thể xem PR tương ứng trong repository
      Không cần đánh giá thấp cách dàn dựng vui nhộn trong việc khiến một thứ vốn xa lạ trở nên trực quan. Mỗi bot có chủ thể quản lý, năng lực và quyền hạn khác nhau, nên tên và hình ảnh là cách gọi tắt tiện lợi để phân biệt instance; còn trang trí cho dễ thương hay không là tùy chọn
    • Ở đây không có blockchain. Nostr chỉ là một chuẩn định dạng thông điệp đã ký, đi qua các relay server lưu rồi chuyển tiếp đơn giản
    • Vì thời gian của mọi tin nhắn đều là 5:42, có vẻ đây là ảnh chụp từ dữ liệu test được nạp sẵn hoặc mockup dựa trên ảnh chụp đó

  • Nói là “giải thích như cho trẻ 5 tuổi” nhưng lại giải thích rằng “Buzz là workspace mã nguồn mở tự host, kết hợp chat nhóm, AI agent và Git hosting bằng các sự kiện Nostr đã ký”, nên trình độ của đứa trẻ 5 tuổi mà họ kỳ vọng có vẻ khá khác thường

    • Thật thú vị khi ELI5, vốn là tên một subreddit phái sinh từ thread AskReddit ban đầu, nay đã trở thành một cụm marketing phổ biến trong ngành công nghệ. Hiện nó gần giống một cách viết tắt cho “hãy giải thích từ các nguyên lý đầu tiên mà độc giả dự kiến cần biết”, và có vẻ nhiều người trong ngành vẫn hoài niệm Reddit thập niên 2010
    • Có lần tôi bảo agent eli5 (tác vụ) rồi lo nó sẽ thật sự giải thích như nói với trẻ 5 tuổi. Đó là một lo ngại vô lý; agent thường hiểu ý định thực tế, không như phần bình luận HN
    • Hôm qua tôi nhận được một ELI5 mà vẫn không hiểu, nên bước tiếp theo hợp lý là yêu cầu “ELI4”
    • Nó gần nghĩa với “hãy giải thích như thể đang công bố tại TechCrunch Disrupt”
    • Đọc về Buzz chỉ thấy chồng chất buzzword và thuật ngữ doanh nghiệp, nên khó biết thực sự nó làm gì

  • Tôi làm ở Slack nhưng đây là quan điểm cá nhân. Việc agent có thể thấy mọi thứ mà tôi và đồng nghiệp thấy thì rất hay, nhưng ngay khi muốn chỉ tiết lộ một số thông tin cho một số người nhất định thì mọi chuyện trở nên khó khăn
    Với agent đa người dùng, phải viết và duy trì các quy tắc truy cập theo từng tài nguyên một cách phức tạp để chúng không làm rò rỉ dữ liệu. Ngược lại, agent đơn người dùng thay mặt một người dùng nên cấu trúc đơn giản hơn; điểm cốt lõi là không cho phép đưa dữ liệu riêng tư ra không gian dùng chung nếu không có cho phép rõ ràng

    • Trong môi trường cộng tác thực sự, nhóm riêng tư là tệ nhất. Ước gì Slack có nút xuất toàn bộ thread sang kênh công khai
    • Có thể tôi thiên vị vì từng ở Asana, nhưng tôi đồng ý rằng agent đơn người dùng dễ hơn. Dù vậy, agent đa người dùng hiểu toàn bộ luồng công việc sẽ cực kỳ mạnh
      Chúng tôi đã phải suy nghĩ và tốn rất nhiều thời gian để chú ý đến quyền riêng tư và ngăn thông tin rò rỉ đến sai đối tượng. Tôi chưa dùng Buzz, nhưng đánh giá cao nỗ lực suy nghĩ khác đi và tạo ra thứ thú vị
    • Trong Buzz, agent có vẻ không phải là tích hợp ứng dụng mà là người dùng hạng nhất. Nếu tạo một người dùng tên Claude và áp dụng ACL thông thường, có lẽ không cần quan tâm đó là người hay bot
    • Môi trường chạy trên cloud của chúng tôi phân biệt bí mật dùng chung và bí mật cá nhân. Các mục được xác thực bằng bí mật dùng chung có thể dùng trong môi trường công khai, còn mục cá nhân chỉ truy cập được qua kênh tin cậy, nên cũng áp dụng được cho Slack hay Telegram
      Agent Slack mạnh ở điểm này và bảo đảm không rò rỉ bất kỳ thông tin riêng tư nào
    • Chẳng phải chỉ cần dùng ID chat nhóm và thông tin bổ sung làm khóa hội thoại là được sao

  • Giờ khi nhìn một dự án phần mềm mới, điều đầu tiên tôi nghĩ đến là bao nhiêu phần được làm bằng agent, cùng với sự bất ổn và khả năng bị bỏ cuộc dễ dàng đi kèm. Nếu là 10 năm trước thì có thể phần nào đoán chất lượng sản phẩm, nhưng tôi không nói riêng về Buzz

    • Trước đây, bản thân ma sát khi xây dựng thứ gì đó là dấu hiệu cho thấy đã có phần nào cân nhắc kỹ, còn giờ có vẻ họ ném cho người dùng rồi để người dùng tự xác định xem có giá trị hay không
      Với những sản phẩm như vậy, rủi ro lớn hơn lợi ích của việc áp dụng sớm, nên tốt hơn là đợi vài tháng. Nếu là sản phẩm bền vững thì chậm vài tháng cũng không khác biệt nhiều
    • Phần lớn phần mềm rốt cuộc đều biến mất bất kể có dùng agent hay không, nên lối suy nghĩ đó có vấn đề. Google cũng từng ra mắt một sản phẩm xã hội tương tự tên Google Buzz vào năm 2010, trước thời LLM, nhưng đã kết thúc chỉ sau 16 tháng
      Điểm cốt lõi là dự án có tìm được product-market fit hay không; việc nó còn tồn tại sau 2 năm không gắn chặt với chất lượng code như các kỹ sư muốn tin
    • Giờ tôi không muốn làm early adopter nữa; cần ít nhất 6 tháng kiểm chứng để xem đó có chỉ là một cơn sốt nhất thời hay không
    • An toàn hơn là giả định mọi thứ đều được tạo bằng LLM
    • Việc trở nên dễ bỏ cuộc là có thật. Quy trình sẽ thành: dùng AI tạo hàm và test, dùng AI sửa hàm, rồi nếu test hỏng thì xóa hết và lại dùng AI tạo test

  • Trước đây từng làm ở Slack. Việc thách thức hiện trạng của chat là điều tốt, nhưng tôi hoài nghi liệu Slack và Teams có sống sót hoặc tiến hóa đến mức đó trong kỷ nguyên agent hay không
    Tuy vậy tôi cũng tò mò liệu Nostr có thực sự là giao thức phù hợp không. Ở các tập đoàn lớn, phải xử lý vô số client, bao gồm điện thoại di động và agent cục bộ, cùng các agent theo từng nhóm. Với agent được host tập trung thì cấu trúc danh tính hiện tại phù hợp, nhưng không rõ agent cá nhân sẽ tái sử dụng thông tin xác thực của người dùng hay được tách riêng
    Tôi cũng nghi ngờ liệu Git có cần là phụ thuộc bắt buộc không. Với Block thì có thể cần, nhưng vì nó làm tăng độ phức tạp, cũng có thể tách ra bằng cách gộp các sự kiện của host quản lý phiên bản vào event log của Buzz
    Tôi cũng tò mò những vấn đề nào sẽ phát sinh khi các tính năng mới xuất hiện, như việc Sol và Claude render các thành phần native trong cửa sổ chat để cụ thể hóa thay đổi thiết kế. Cũng muốn biết lý do chọn Rust và các phương án thay thế đã xem xét

    • Một phương án thỏa hiệp như Signal có vẻ tốt hơn. Slack đã trở thành thứ khó tách khỏi các quan hệ kinh doanh văn phòng, nhưng trong bối cảnh bị phơi trước các cuộc tấn công mạng 24/7, sẽ tốt hơn nếu tính bảo mật và an toàn thông qua hệ thống zero-knowledge được bảo đảm thay vì chỉ dựa vào lời hứa của công ty
      Signal là client có trải nghiệm nhắn tin đa nền tảng tốt nhất trong số những thứ tôi đã dùng với các nhóm bạn; nếu thêm một cấu trúc kiểu Slack vào kiến trúc hiện tại, nó sẽ hữu ích để giảm vấn đề các kênh quá ồn ào
    • Thông tin được chia sẻ như code và file sẽ ngày càng quan trọng để giữ con người và agent cùng được căn chỉnh, và các công ty AI-native sẽ phụ thuộc vào code nhiều hơn, nên tích hợp Git là hợp lý
    • Tôi tò mò vì sao Rust lại có cảm giác là lựa chọn tệ. Theo kinh nghiệm phát hành phần mềm thiết bị y tế, nó rất tuyệt để giữ cho code do nhóm viết có tính gắn kết và chính xác

  • Google Buzz và Wave đã xuất hiện quá sớm so với thời đại
    https://en.wikipedia.org/wiki/Google_Buzz

    • Đến giờ vẫn không thể tạo nhãn Buzz trong Gmail
    • Vừa nhìn thấy là tôi nghĩ ngay đến Google+ và Buzz

  • Đưa bot vào chat nhóm không phải ý tệ; tôi đã thử nghiệm vài tháng nay. Slack thì chạy được, nhưng việc cấu hình vô số quyền rất đau khổ và phải lặp lại cho mỗi bot mới
    Tôi đã thử Matrix như một lựa chọn tự host, nhưng mã hóa đầu cuối quá nghiêm ngặt nên cản trở việc chia sẻ thông tin với bot. Vài tuần trước tôi chuyển sang Zulip, và mọi thứ từ cài đặt, tạo người dùng bot đến tự động hóa đều đơn giản. Phần tự động hóa tạo bằng Openclaw đã được thay bằng code dựa trên Haystack có trạng thái ít lộn xộn hơn
    Sau khi cài đặt tôi mới biết ban lãnh đạo Zulip đã được Anthropic tuyển dụng. Có vẻ Jack Dorsey công bố trước, nhưng Anthropic cũng có thể có kế hoạch tương tự
    Agent ở cấp độ nhóm là hoàn toàn hợp lý. Khi tổ chức lớn hơn, chi phí cộng tác tăng lên và rất phù hợp để tối ưu bằng AI; càng dùng AI nhiều, nhu cầu chia sẻ và điều phối công việc trong các kênh công khai cũng càng lớn. Team chat cũng rất phù hợp với các quy trình phức tạp có cơ chế an toàn chung và bàn giao giữa người với agent

    • Không biết XMPP thì sao

  • Nó có thể lấp một ngách hữu ích, nhưng khả năng cao Anthropic và OpenAI sẽ thúc đẩy bằng sản phẩm riêng trong vòng 6–12 tháng
    Khi xem các Git forge dành cho cụm agent, Radicle thiếu lớp danh tính nhưng mô hình COB liên hợp trông ổn, còn Tangled không hỗ trợ repo riêng tư nhưng lớp xã hội khá vững. Tuy nhiên, việc mô hình hóa issue thành bài đăng thay vì đối tượng thuộc sở hữu của repo thì hơi gượng
    Vì vậy vẫn còn chỗ cho một forge riêng tư, ưu tiên agent. Anthropic đã đi theo hướng này, và sản phẩm mới nhất Tag là một mô hình xác thực để chạy agent bất đồng bộ trong Slack
    Bước tiếp theo tự nhiên có thể là một forge. Khi UI của agent không còn phải thông qua GitHub, Anthropic có thể tự do thay thế triển khai nội bộ, và chat nhiều người dùng cùng quản lý repo/dự án có vẻ là các thành phần nền tảng tiếp theo

    • Tôi đang làm một code forge mới tại https://juju.bi. Đây không phải sản phẩm ưu tiên agent, nhưng ngoài khả năng mở rộng, tôi chưa nghĩ ra tính năng nào đặc biệt cần cho agent

  • Lý do lớn khiến Slack tồn tại là vì IRC thiếu các tính năng mặc định như lịch sử kênh và tìm kiếm. Để AI agent phát triển mạnh, Slack phải mở hoàn toàn mạng của mình thành một giao thức, hoặc cuối cùng sẽ bị thay thế
    Sẽ thật tốt nếu Slack áp dụng chat dựa trên AT Protocol và các ứng dụng như Buzz triển khai nó. Người dùng có thể dùng domain handle như @yourname.com, agent dùng @agent1.yourname.com, đồng thời vẫn có toàn quyền kiểm soát

    • Tôi không hiểu vì sao việc làm cho agent phát triển mạnh lại là trách nhiệm của Slack. Tôi đang trực tiếp chứng kiến trong toàn ngành tình trạng đảo ngược chủ-khách khi thay đổi quy trình làm việc để phù hợp với AI; công cụ phải phục vụ con người, chứ không phải ngược lại
    • Tương tự tài khoản bot/puppet của Matrix
    • Lý do ban đầu tôi thích Slack là vì nó là “IRC với các tiện ích hiện đại”. Sau khi bị Microsoft lấn át và được bán cho Salesforce, về cơ bản nó đã trì trệ, và phần lớn thay đổi khiến sản phẩm tệ hơn
    • Cơ chế quyền của ATProto vẫn chưa được chốt sẽ thiếu khả năng kiểm soát chi tiết mà doanh nghiệp yêu cầu. Các tính năng như group sẽ được triển khai ở app view nên thực chất sẽ tập trung hóa, còn ACL là cách làm lùi hai thế hệ trong lịch sử quản lý danh tính và truy cập
      Chat cũng không phải định dạng phù hợp với PDS/ATP. Roomy cũng nhận ra điều này và đang xây dựng giao thức cùng bridge chuyên dụng
    • Nó giống HipChat hơn là Slack, và đã lệch thời đại khoảng 15 năm

  • Đây là lần đầu tôi có trải nghiệm khó chịu khi trên website chuyển động con trỏ bị trễ tới 0,5 giây