- Kiến trúc agent thuần hàm định nghĩa trạng thái và hành động dưới dạng dữ liệu, đồng thời tách tác dụng phụ thành chỉ thị mệnh lệnh (directive) để đơn giản hóa việc kiểm thử và gỡ lỗi
- Áp dụng API ngắn gọn và thiết kế xoay quanh BEAM, đồng thời tách các mô-đun như
jido_action, jido_signal để cung cấp hệ thống action·signal được chuẩn hóa
- Lớp cấp cao hơn là Jido AI hỗ trợ 6 chiến lược suy luận như ReAct, Chain-of-Thought, đồng thời có thể tận dụng 11 nhà cung cấp và 665 mô hình nhờ tích hợp LLM dựa trên ReqLLM
- Jido hiện đang mở rộng thành nền tảng hệ sinh thái agent, và thông qua tích hợp với Ash Framework (
ash_jido), hỗ trợ chuyển CRUD thành công cụ có thể được AI gọi
Tổng quan về Jido 2.0
- Jido 2.0 là framework agent dựa trên Elixir được hoàn thiện sau 18 tháng phát triển và thiết kế lại
- Ban đầu, dự án khởi đầu vào năm 2024 với nền tảng bot mang tên BotHive, sau đó chọn runtime BEAM làm nền tảng cho hệ thống agent
- Để vượt qua những giới hạn của các framework dựa trên TypeScript hoặc Python, dự án tận dụng tính đồng thời và độ ổn định của BEAM
Thay đổi từ 1.0 lên 2.0
- Jido 1.0 bị giảm tính dễ dùng do trừu tượng hóa quá mức, nhưng ở phiên bản 2.0, điều này đã được cải thiện bằng API được đơn giản hóa và cấu trúc xoay quanh BEAM
- Phản ánh phản hồi từ người dùng, dự án loại bỏ độ phức tạp không cần thiết và giảm tối đa ma sát khi thực hiện các chức năng cơ bản
- Thể hiện yêu cầu rằng “người dùng muốn tạo agent, chứ không muốn vật lộn với framework”
Lõi agent mạnh mẽ và bền bỉ
- Trọng tâm của Jido 2.0 là kiến trúc agent thuần hàm
- Agent được định nghĩa như một struct đơn giản gồm trạng thái (state), hành động (actions) và công cụ (tools)
- Mọi hoạt động đều được xử lý bằng hàm
cmd/2, và tùy theo action đầu vào sẽ trả về agent đã được cập nhật cùng danh sách chỉ thị
- Tác dụng phụ được biểu diễn dưới dạng chỉ thị (directive) để runtime thực thi, giúp việc kiểm thử và gỡ lỗi trở nên dễ dàng
Jido.AgentServer bao bọc agent trong một GenServer được giám sát, hỗ trợ định tuyến signal và cấu trúc phân cấp agent cha-con- Strategy là điểm mở rộng, với hai lựa chọn mặc định là Direct (thực thi tuần tự) và FSM (máy trạng thái)
- Các chiến lược AI như ReAct, Chain-of-Thought cũng hoạt động với cùng một giao diện
Tách mô-đun action và signal
jido_action: hợp đồng action phổ quát định nghĩa mọi chức năng của agent
- Bao gồm kiểm tra schema khi biên dịch, hook vòng đời và khả năng tự động chuyển đổi sang định dạng công cụ ReqLLM
- Cung cấp hơn 25 công cụ dựng sẵn và workflow planner dựa trên DAG
jido_signal: hệ thống nhắn tin dựa trên CloudEvents v1.0.2
- Cung cấp định dạng signal chuẩn hóa, router dựa trên trie, bus pub/sub và 9 adapter dispatch
- Có thể tích hợp với nhiều hệ thống khác nhau mà không cần giao thức phi chuẩn
Lớp tích hợp Jido AI
jido_ai là lớp tích hợp chuyển các lời gọi LLM thành trí tuệ agent có cấu trúc
- Tích hợp sẵn 6 chiến lược suy luận gồm ReAct, Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, TRM, Adaptive
- Giữ nguyên hợp đồng
cmd/2 và hệ thống chỉ thị, tích hợp lớp AI như một phần mở rộng thay vì một thế giới tách biệt
- Hoạt động dựa trên ReqLLM, hỗ trợ 11 nhà cung cấp và hơn 665 mô hình
- Thiết kế ưu tiên streaming, kiến trúc đa nhà cung cấp và có sự đóng góp tích cực từ cộng đồng
Hệ sinh thái đang mở rộng
- Jido đang phát triển vượt ra ngoài một framework đơn thuần để trở thành hệ sinh thái agent
- Cộng đồng đang xây dựng trên BEAM các trợ lý lập trình, bộ điều phối workflow, agent nghiên cứu, hệ thống hỗ trợ vận hành cùng nhiều ứng dụng khác
- Nhiều gói đã xuất hiện cho tự động hóa trình duyệt, hệ thống bộ nhớ, evaluation harness, tích hợp MCP và hơn thế nữa
- Tích hợp Ash Framework (
ash_jido)
- Khi thêm khối DSL
jido vào tài nguyên Ash, các action CRUD sẽ được chuyển thành công cụ có thể được AI gọi
- Vẫn giữ nguyên chính sách phân quyền, lớp dữ liệu và tính an toàn kiểu
ash_ai cũng đang được chuyển sang ReqLLM, cho thấy sự hội tụ của hai hệ sinh thái
Cộng đồng và lời cảm ơn
- Jido 2.0 được xây dựng trên hệ sinh thái của cộng đồng Elixir
- Được củng cố nhờ đóng góp từ các thư viện chủ chốt như Phoenix, LiveView, Ash, Req, Telemetry, NimbleOptions
Bắt đầu
1 bình luận
Ý kiến trên Hacker News
Tôi vẫn chưa thực sự dùng Jido, nhưng cứ khoảng mỗi tháng lại vào xem một lần
Tôi nghĩ BEAM cực kỳ phù hợp với framework agent, nhưng hệ sinh thái vẫn còn hạn chế nên tôi chưa đào sâu được
Tôi rất mong chờ phiên bản 2.0. Nhân tiện, có vẻ một vài mẫu code đang gặp vấn đề về entity escape
Tôi rất thích cách tiếp cận nhấn mạnh vào data và pure function ngay từ đầu bài
Mọi người thường nói mô hình thực thi của BEAM phù hợp với AI, nhưng trên thực tế, độ bền vững trong các tình huống như node lỗi hay rolling deploy lại hay bị bỏ qua
Cũng có một hiểu lầm rằng Elixir cung cấp location transparency, nhưng thực ra không phải vậy. Nếu node chết thì các process bên trong cũng sẽ dừng theo
Nếu giữ trạng thái agent rõ ràng và thuần khiết ở mỗi bước gọi API thì có thể giải quyết vấn đề này. Chỉ cần lưu trạng thái vào Mnesia hoặc Redis rồi tiếp tục ở node khác. Cuối cùng thì checkpointing mới là cốt lõi
Vì vậy nên Jido core hoàn toàn không có hỗ trợ LLM.
Đã có hơn 40 năm nghiên cứu về agent, nhưng từ khi LLM xuất hiện thì dường như mọi người quên sạch điều đó. Vì thế tôi đã quay lại học lịch sử đó và cố gắng đưa nó vào Jido
Tất nhiên tôi vẫn thích LLM, nhưng đó là vai trò của gói Jido AI
Thời điểm quá hoàn hảo. Tôi đã tự làm framework agent bằng cách trộn gen server với Oban, và đó thực sự là một công việc đau đớn
Dự án này có vẻ sẽ giúp giảm bớt rất nhiều nỗi đau trong quá trình phát triển. Cảm ơn thật sự
Tôi tò mò không biết cái này có giống với OpenAI Symphony không
Tôi theo dõi phía Elixir nhiều hơn là AI, nên thật mới mẻ khi thấy Elixir và BEAM được dùng cho những workload orchestration kiểu này
Trang web đang khó truy cập vì lưu lượng tăng đột biến. Vì vậy tôi chia sẻ liên kết backup trên archive.org
Cảm ơn vì đã chia sẻ! Tôi chắc chắn sẽ xem thử
Gần đây tôi có làm một gói A2A với LLM, nó là một abstraction tương tự GenServer
Đã có các triển khai A2A khác rồi, nhưng gói của tôi có semantics khác nên tôi cứ phát hành riêng
Ai quan tâm có thể xem tại đây
Tôi đã theo dõi dự án này vài tháng rồi, và Elixir/BEAM là nền tảng hoàn hảo để chạy agent
BEAM thực sự rất nhẹ và hiệu quả, nên về mặt lý thuyết có thể chạy hàng nghìn agent trên một server
Tôi rất mong chờ xem những người hiểu điều này sẽ xây ra thứ gì tiếp theo
Thậm chí còn có nỗ lực triển khai BEAM lên môi trường bare metal (embedded) để chạy agent bên trong đó
Tương lai có vẻ sẽ rất thú vị
Tôi muốn xem ảnh chụp màn hình cây process khi các agent đang hoạt động trong ‘observer’
Nhân tiện, observer là công cụ dùng để trực quan hóa các process Erlang bên trong BEAM VM
Có thể xem ảnh chụp ví dụ trong tài liệu Fly.io
jido_studio. Nó sẽ trực quan hóa cấu trúc processCó thể xem ảnh teaser ở đây
Các agent được bọc bằng AgentRuntime thường hoạt động như một process GenServer duy nhất, nhưng vẫn có ngoại lệ khi cần topology lớn hơn
Thời điểm quá hoàn hảo. Tôi cũng đang tự làm một framework agent Erlang, nhưng cái này tốt hơn nhiều
Tôi tò mò không biết bảo mật được đảm bảo như thế nào. Nếu không có container isolation thì sẽ khó ngăn rò rỉ secret production
Tôi thực sự đã thấy các trường hợp Jido được triển khai theo cách đó
Tuy vậy điều này còn tùy use case, và bảo mật là chủ đề rộng hơn rất nhiều so với chỉ vấn đề “agent trong container”
Mục tiêu của Jido không phải là trực tiếp giải quyết bảo mật, mà là cung cấp công cụ để người dùng tự giải quyết theo cách họ cần