Apache Burr: Xây dựng các tác nhân và ứng dụng AI đáng tin cậy

 (burr.apache.org)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Apache Burr là một framework để xây dựng các ứng dụng AI ra quyết định bằng Python, từ chatbot đơn giản đến các hệ thống đa tác nhân phức tạp
  • Ứng dụng được định nghĩa bằng tập hợp action và transition, và được viết bằng hàm Python cùng decorator mà không cần DSL hay YAML
  • Burr UI cung cấp khả năng giám sát · gỡ lỗi · truy vết theo từng bước thực thi, đồng thời có thể theo dõi thay đổi trạng thái theo thời gian thực
  • Có thể lưu trạng thái vào đĩa, cơ sở dữ liệu hoặc backend tùy chỉnh, rồi tiếp tục từ điểm dừng; đồng thời hỗ trợ chờ đầu vào từ con người và thực thi song song
  • Tích hợp với các công cụ hiện có như OpenAI, Anthropic, LangChain, FastAPI, PostgreSQL mà không tạo lock-in hay cần wrapper

Xây dựng các tác nhân và ứng dụng AI đáng tin cậy

  • Apache Burr là một Apache Incubating Project giúp việc phát triển các ứng dụng có khả năng ra quyết định trở nên dễ dàng hơn
  • Phạm vi áp dụng mở rộng từ chatbot đơn giản đến các hệ thống đa tác nhân phức tạp
  • Cách triển khai là Python thuần, theo triết lý “no magic”
  • Các chỉ số công khai hiển thị gồm GitHub Stars 1,641, PyPI Downloads 379k+, Discord Members 457+

API Python đơn giản nhưng mạnh mẽ

  • Burr cung cấp giao diện có thể kết hợp để xây dựng từ chatbot đến hệ thống đa tác nhân
  • Mã ví dụ sử dụng burr.core với action, State, ApplicationBuilder để định nghĩa action chat
  • @action(reads=["messages"], writes=["messages"]) dùng để chỉ định trạng thái được đọc và trạng thái được ghi
  • ApplicationBuilder() thiết lập action, transition, trạng thái ban đầu và local tracker trước khi build ứng dụng
  • Ví dụ thực thi truyền LLM client dưới dạng đầu vào với app.run(halt_after=["chat"], inputs={"llm_client": client})

Những yếu tố cần có để xây dựng ứng dụng AI

  • Simple Python API định nghĩa ứng dụng như một tập hợp action và transition, chỉ dùng hàm Python và decorator mà không cần DSL hay YAML
  • Built-in Observability cho phép giám sát, gỡ lỗi và truy vết mọi bước của ứng dụng theo thời gian thực bằng Burr UI
  • Persistence & State Management tự động lưu trạng thái vào đĩa, cơ sở dữ liệu hoặc backend tùy chỉnh và cho phép tiếp tục từ điểm bị gián đoạn
  • Human-in-the-Loop cho phép dừng thực thi ở bất kỳ bước nào để chờ đầu vào từ con người, phù hợp với workflow phê duyệt và tác nhân tương tác
  • Branching & Parallelism hỗ trợ chạy action song song, fan out / fan in, xây dựng DAG phức tạp và kết hợp các ứng dụng con
  • Testing & Replay tăng độ tin cậy vào hệ thống AI thông qua phát lại các lần chạy trước, kiểm thử đơn vị cho từng action và xác minh chuyển đổi trạng thái

Tích hợp với stack hiện có

  • Burr tích hợp với các công cụ và framework bạn đang dùng mà không yêu cầu lock-in hay wrapper
  • Các mục tích hợp LLM được hiển thị gồm OpenAI, Anthropic, Instructor
  • Các mục tích hợp framework được hiển thị gồm LangChain, Hamilton, Haystack
  • Các mục tích hợp UI và serving được hiển thị gồm Streamlit và FastAPI
  • Các mục tích hợp xác thực và lưu trữ được hiển thị gồm Pydantic và PostgreSQL
  • Có thể xem toàn bộ danh sách tích hợp trong tài liệu

Trải nghiệm sử dụng từ nhà phát triển và đội ngũ

  • Đánh giá từ Peanut Robotics cho biết sau khi đánh giá nhiều framework LLM, quản lý trạng thái của Burr là câu trả lời mạnh mẽ cho việc triển khai robot dựa trên ra quyết định bằng AI
  • Đánh giá từ Watto.ai cho biết Burr giúp dễ dàng xây dựng các ứng dụng AI mô-đun, và UI giúp việc gỡ lỗi trở nên đơn giản
  • Đánh giá từ Paxton AI nhấn mạnh rằng Burr không dùng những khái niệm kỳ quặc và khó hiểu chỉ vì đó là AI
  • Đánh giá từ Provectus cho biết quản lý trạng thái của Burr hữu ích cho việc tạo snapshot trạng thái, gỡ lỗi, phát lại và xây dựng các ca đánh giá
  • Đánh giá từ CognitiveGraphs cho biết khi so với nhiều nền tảng LLM agentic như LangChain, CrewAi, AutoGen, Agency Swarm, Burr cung cấp framework vững chắc hơn cho việc thiết kế hành vi phức tạp
  • Đánh giá từ TaskHuman cho biết sau khi chuyển từ LangChain sang Burr, họ bắt đầu chỉ trong vài giờ và đã chuyển toàn bộ codebase sang Burr

Cộng đồng và trạng thái dự án

  • Cộng đồng được xây dựng như một không gian để yêu cầu hỗ trợ, chia sẻ dự án và đóng góp cho tương lai của Burr
  • Các kênh tham gia gồm Discord, GitHub, Twitter / X
  • Tài nguyên dự án liên kết tới tài liệu, ví dụ, YouTube, roadmap và changelog
  • Apache Burr là một dự án đang trong giai đoạn ươm tạo tại Apache Software Foundation, với sự bảo trợ của Apache Incubator
  • Trạng thái ươm tạo không nhất thiết phản ánh mức độ hoàn thiện hay ổn định của mã nguồn, mà cho thấy dự án vẫn chưa nhận được sự phê duyệt đầy đủ từ ASF

Bài viết liên quan

1 bình luận

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

  • Tôi vẫn tạm thời giữ quan điểm trung lập với các framework agent, và tính hữu dụng của chúng thay đổi tùy theo bản chất của agent. Ví dụ, trường hợp cần trả về một phản hồi đủ ổn trong vòng 3 giây rất khác với trường hợp phải giải một bài toán trong 3 giờ
    Cuối cùng, agent có thể được rút gọn thành: xây dựng ngữ cảnh, gọi LLM, thực thi các lệnh gọi công cụ được yêu cầu, phân tích đầu ra cuối cùng của mô hình, rồi trả về cho frontend. Có các phần mở rộng như bộ nhớ hay gọi công cụ bất đồng bộ, nhưng từ góc nhìn kỹ thuật phần mềm truyền thống thì không quá phức tạp
    Ai cũng muốn tạo framework agent của riêng mình, nhưng nếu phải xây một agent cụ thể thì tôi thấy mã 1:1 được thiết kế riêng cho agent đó vừa dễ hơn vừa dễ bảo trì hơn nhiều. Các lớp trừu tượng của framework thường che khuất và cản trở logic cốt lõi, và rốt cuộc lại phải ép theo kiểu trừu tượng mà framework chọn, nên đôi khi lệch khỏi mục tiêu thực tế

    • Tôi cho rằng cốt lõi của hệ thống kiểu agent không nằm ở việc dùng agent, mà là chỉ dùng khi thực sự cần. Một hệ thống vận hành được cần có pipeline/recipe để biểu diễn luồng nhiều bước, hệ điều hành để chạy ổn định các bước mô hình và bước có con người can thiệp trong pool nhiều worker agent, cùng khả năng quản lý/triển khai/bảo mật/phân quyền cho các skill “dày” xử lý được càng nhiều việc bằng code càng tốt, và quản lý ngữ cảnh để đưa đúng ngữ cảnh vào đúng phiên
      Ngoài ra còn cần quản lý dự án để xử lý ticket, dependency, tiến độ, khởi động lại ticket bị kẹt; lưu lịch sử hội thoại cùng bộ nhớ, dreaming, học tích lũy; quan sát được chi phí và mức sử dụng; đánh giá prompt và tự động tinh chỉnh; thay đổi nhà cung cấp mô hình và cố định phiên bản mô hình; cùng sandbox để chạy các phiên thực tế
      Không nhất thiết phải lấy tất cả từ một nhà cung cấp, nhưng trong đa số trường hợp thì không nên bị khóa vào một nhà cung cấp mô hình duy nhất, và ngữ cảnh của riêng mình cùng học tích lũy thì nên tự sở hữu
    • Điểm nghiêm trọng nhất ở phần lớn framework agent là che khuất logic cốt lõi. Cần phải thấy thật rõ cái gì đang được gửi tới mô hình ngôn ngữ thực tế và cái gì đang được trả về
      Mọi thứ trong ứng dụng kiểu agent rốt cuộc đều được hiện thực hóa thành chuỗi token hoặc lệnh gọi tới nhà cung cấp, nên ở gần như mọi tầng của ứng dụng điều đó phải được thể hiện rõ ràng
    • Tôi từng có suy nghĩ tương tự với hàng chục framework frontend. Chúng bắt người ta gánh một đống trừu tượng hóa và độ phức tạp khổng lồ để đổi lấy phần thưởng tưởng như sẽ đến trong tương lai nhưng rồi lại không đến
      Dù vậy, con người vẫn cần việc để làm hoặc đồ chơi thú vị để nghịch, và “người tiếp theo” thường chẳng được coi trọng lắm, nên có vẻ họ không ngại đẩy sang cho người khác kết quả của những giờ vui chơi có lương
    • Tôi phần nào đồng ý với cách tạo mã 1:1 dành riêng cho một agent cụ thể. Tuy nhiên, khi tạo kỹ thuật hay phương thức mới trong agent mới, thì về mặt bảo trì vẫn còn câu hỏi là cập nhật agent cũ thế nào và liệu có muốn cập nhật chúng hay không
      Ví dụ, có vẻ Apache Burr hỗ trợ hoặc sẽ hỗ trợ hệ thống vector RAG dạng plugin, nhưng thứ tôi cần là cách thêm tài liệu vào ngữ cảnh và giữ chúng như một phần của system prompt đã cập nhật, đồng thời chèn vào quá trình đó những điều chỉnh rất cụ thể. Đây là cách dùng tùy biến cho khái niệm RAG vốn có, nên không thật sự khớp với một framework cụ thể nào
      Với nhu cầu của tôi thì triển khai tùy biến là phù hợp, nhưng các lựa chọn kỹ thuật để làm mới agent cũ vẫn còn là vấn đề
    • Điểm mạnh của framework không hẳn là giúp viết agent dễ hơn, mà nằm ở công cụ và khả năng quan sát các thứ tương tự. LangChain dù có nhiều điểm đáng phê bình, nhưng điều này đã thể hiện rất rõ từ sớm
      Tự làm chatbot từ đầu có thể dễ hoặc thậm chí dễ hơn, nhưng khi cần thêm observability hay tracing thì câu chuyện khác hẳn. Nếu chỉ cần thêm một biến môi trường là có thể xem toàn bộ trace trên UI gần như không cần làm gì thêm, thì giải pháp tự làm rất khó cạnh tranh

  • Tôi tự hỏi liệu trang này có được làm bằng https://vorpus.github.io/performativeUI/ không
    Nó đạp trúng gần như mọi khuôn sáo điển hình của một trang đích do AI tạo ra. Hay là họ cố tình châm biếm nhỉ

  • Tôi rất thích dùng framework này trong cả dự án cá nhân lẫn dự án công việc. Thật tốt khi có được workflow có trạng thái đáng tin cậy cho các mô hình AI cùng observability miễn phí
    Tôi đã ghép một công cụ để mount state machine của Burr bằng MCP, vừa cho agent các đường ray để đi theo, vừa đảm bảo rằng dù state machine có phức tạp đến đâu thì công cụ MCP cũng chỉ bị giới hạn trong việc duyệt state machine: https://github.com/msradam/theodosia
    Hiện tôi đang làm việc chuyển các skill thành state machine. Nhiều skill phổ biến vốn đã được viết dưới dạng các bước để mô hình AI làm theo, nên có vẻ dùng các tính năng tường minh của Burr sẽ giúp chúng ổn định hơn

  • Tôi muốn biết nó so với https://strandsagents.com/ thế nào. Tôi quan tâm đến các công cụ trong mảng này và hiện chưa bị ràng buộc vào công cụ nào, nhưng Bedrock + Serverless on Agent Core đem lại cảm giác như một “lộ trình hướng dẫn dễ đi”. Chỉ là tôi không thích sự phụ thuộc vào nền tảng

    • Tôi cũng muốn nghe thêm trải nghiệm sử dụng. Tôi đang dùng stack này, nhưng vẫn băn khoăn liệu Strands có mang lại bí quyết đặc biệt nào khi đi cùng Agent Core hay không
      Cho tới giờ thì tôi chưa thấy như vậy, thậm chí đôi lúc còn có cảm giác hai thứ này xung đột với nhau

  • Ở đây thấy có builder pattern và decorator. Python cũng có decorator, nhưng tôi cho rằng cách dùng phù hợp nhất là như một “bộ lọc” áp vào hàm hoặc phương thức. Kiểu như hàm này thì cache, đầu ra của hàm này thì luôn serialize, hàm này thì chuẩn bị làm công cụ cho bộ thực thi kiểu agent
    Tôi không nghĩ nó nên được dùng cho đăng ký hay điều khiển luồng. Có thể bạn không đồng ý, nhưng phải có người nói ra. FastAPI đã kéo cách dùng decorator hiện đại đi sai hướng quá nhiều
    Builder pattern gần như là một quy ước nảy sinh vì Rust không có keyword argument được đặt tên, còn hàm Python vốn đã phơi bày một giao diện có tên rõ ràng. Hầu như không có lý do gì để truyền các tham số cấu hình theo thứ tự bằng các lời gọi phương thức nối chuỗi
    Nếu cần thêm trạng thái chưa có trong constructor hay factory thì đó không phải builder pattern mà là đăng ký. Nơi duy nhất tôi thấy có thể chấp nhận builder pattern là query builder. Vì ở đó ta lặp đi lặp lại việc ghép các khái niệm lại với nhau, và các slot metadata như tên phương thức và keyword argument thực sự hữu ích. Dùng các phương thức nhận một tham số đơn thay cho keyword argument thì tôi cho là sai

    • Ở đây decorator cụ thể là để gắn metadata vào hàm nhằm biến nó thành thành phần có thể tái sử dụng, còn builder thì tạo workflow. Trong Hamilton, vì cấu hình thuần khai báo nên mọi thứ đều được xử lý bằng decorator, nhưng khả năng tái sử dụng thực ra gần như là một vấn đề riêng
    • Builder pattern không chỉ được dùng trong Rust, nhưng tôi đồng ý là dùng trong Python thì khá xấu

  • Có vẻ đây là một phiên bản khá ngây thơ về việc AI agent đáng tin cậy là gì
    Độ tin cậy có nghĩa là “nó có thể hoàn thành việc được giao hay không”, chứ không liên quan gì đặc biệt đến máy trạng thái

  • Tôi mới lần đầu nghe về Burr, tò mò không hiểu vì sao nó lại được Apache ươm tạo

    • Không có lý do gì để không làm vậy. ASF có một lịch sử lâu dài trong việc ươm tạo các dự án phần mềm tự do mã nguồn mở mới
      Một số dự án tốt nghiệp rồi trở thành những cái tên ai cũng biết, một số thất bại và bị đưa vào attic. ASF cung cấp hỗ trợ ở cấp tổ chức và nhìn chung nuôi dưỡng cộng đồng khá tốt
    • Vì tôi đã nộp nó. Quá trình này diễn ra chậm vì tôi vừa học thủ tục của Apache vừa làm những việc khác, nhưng giờ thì nó đã có được một mức động lực nhất định và bắt đầu phát hành đều đặn hơn

  • Trang này trông như rác dùng một lần được làm bằng Claude Code, và thậm chí còn không hề cố gắng hoạt động nếu không có JavaScript. Ít nhất thì tính nhất quán thương hiệu vẫn có

  • Tôi không tìm thấy căn cứ nêu tên một cách rõ ràng, nhưng cho ai tò mò thì đây là ví dụ Hamilton: https://github.com/apache/burr/tree/main/examples/multi-agen...

    • Burr được đặt theo tên Aaron Burr, một trong các quốc phụ Hoa Kỳ, phó tổng thống thứ 3, đồng thời là kẻ sát hại và đối thủ không đội trời chung của Alexander Hamilton
      Mối liên hệ với Hamilton nằm ở chỗ đây là thư viện mã nguồn mở thứ hai mà DAGWorks công bố sau thư viện Hamilton. Cái tên này xuất phát từ việc tưởng tượng xem điều gì sẽ xảy ra nếu Burr và Hamilton hòa hợp với nhau, vượt qua khác biệt để xây dựng một liên bang tốt đẹp hơn
      Ban đầu Burr được tạo ra như một cơ chế xử lý trạng thái giữa các lần thực thi DAG của Hamilton. Vì DAG không có chu trình. Sau đó chúng tôi nhận ra phạm vi áp dụng của nó rộng hơn nên đã phát hành rộng rãi hơn
      https://pypi.org/project/burr/

  • Tôi muốn hỏi có công cụ hay nền tảng điều phối coding agent nào đáng để đề xuất không. Tôi muốn chạy, quản lý và giám sát các agent codex hoặc claude trên nhiều máy
    Nếu có thể thì nên tự host được hoặc là mã nguồn mở. Tôi biết claude code nội bộ đã có nhiều tính năng kiểu này, nhưng nó chỉ dành cho claude

    • Xem tài liệu thì Burr có agent cookbook để bắt đầu việc này, và cũng có thể xử lý workflow nhiều máy. Không biết có phải đúng thứ bạn đang tìm không
      Tôi không chắc nó tích hợp với skills các thứ như thế nào, nhưng nhìn qua thì có vẻ sẽ hoạt động
      https://burr.apache.org/docs/examples/agents/