Mô Hình Điều Phối Tác Nhân Đa Nhiệm Dựa Trên Sự Kiện

Giới thiệu

Trong các hackathon, thông thường mọi người chỉ xây dựng một ứng dụng, nhưng tôi đã xây dựng bốn ứng dụng. Không phải để khoe khoang, mà vì tôi muốn khám phá Kiro và thúc đẩy những gì có thể với kiến trúc dựa trên sự kiện. Trong bài viết này, tôi sẽ chia sẻ về cách tôi xây dựng những hệ thống đa tác nhân dựa trên sự kiện, những thách thức mà tôi gặp phải và những bài học quan trọng tôi đã học được.

Vấn đề với Hệ Thống Đa Tác Nhân Truyền Thống

Nhiều đội ngũ với hàng chục kỹ sư và hàng triệu đô la tài trợ đã cố gắng phát triển các hệ thống tác nhân khổng lồ, nhưng thường thì chúng không hoạt động hiệu quả. Họ kết nối mọi thứ lại với nhau mà không có mô hình điều phối rõ ràng, dẫn đến sự phụ thuộc lẫn nhau và mã nguồn trở nên rối rắm. Điều này khiến cho việc tìm kiếm sự phù hợp giữa sản phẩm và thị trường trở nên khó khăn.

Kiến Trúc Dựa Trên Sự Kiện (Phần Hay Nhất)

Với ứng dụng FinAgent2, tôi đã áp dụng mô hình kiến trúc dựa trên sự kiện sử dụng framework Motia. Thay vì các tác nhân gọi nhau trực tiếp, mọi thứ đều được xử lý qua các sự kiện. Dữ liệu thị trường đến? Đó là một sự kiện. Người dùng đặt câu hỏi? Là một sự kiện. Tác nhân hoàn thành phân tích? Đúng rồi - là một sự kiện.

So sánh cách làm truyền thống và cách làm dựa trên sự kiện

// Cách làm truyền thống (khó chịu)
const result = await marketAgent.analyze(data);
const enriched = await sentimentAgent.enrich(result);
const final = await portfolioAgent.optimize(enriched);

// So với cách làm dựa trên sự kiện (mượt mà hơn)
emit('market.data.received', data);
// các tác nhân chỉ lắng nghe và phản ứng độc lập

Vẻ đẹp của mô hình này là mỗi tác nhân lắng nghe các sự kiện mà nó quan tâm mà không có phụ thuộc trực tiếp. Không có sự chặn lại. Chỉ đơn giản là tách biệt hoàn toàn.

Dàn Nhạc Đa Tác Nhân

Đây là lúc Mastra phát huy tác dụng. Framework này cung cấp nhiều tính năng hữu ích:

• Tác nhân Phân Tích Thị Trường: Lắng nghe các sự kiện thị trường, phát ra các sự kiện phân tích
• Quản lý Rủi Ro: Đăng ký các thay đổi trong danh mục đầu tư, công bố các đánh giá rủi ro
• Theo Dõi Tâm Lý Thị Trường: Giám sát các sự kiện tin tức, phát sóng điểm số tâm lý
• Tối Ưu Danh Mục Đầu Tư: Phản ứng với tất cả các thông tin trên, đề xuất tái cân bằng
• Tác Nhân Nghiên Cứu: Thực hiện phân tích sâu theo yêu cầu, kết quả bất đồng bộ
• Chuyên Gia Chiến Lược Tùy Chọn: Các vấn đề phức tạp về phái sinh mà phần lớn người dùng sẽ không sử dụng nhưng rất ấn tượng trong các buổi trình diễn

Điểm nổi bật? Mỗi tác nhân đều có bộ nhớ riêng thông qua việc tích hợp Mem0. Điều này giúp cho tác nhân theo dõi tâm lý nhớ được những gì đã phân tích mà không làm ô nhiễm ngữ cảnh của tác nhân danh mục đầu tư.

Tại Sao Kiến Trúc Dựa Trên Sự Kiện Tốt Hơn Microservices

Tôi cũng đã xây dựng một phiên bản microservices (FinAgent1) với hơn 8 container. Nhưng tôi phát hiện ra rằng microservices thường là quá tải. Phiên bản dựa trên sự kiện với Motia chỉ cần hai container. Chỉ hai so với tám. Chức năng giống nhau nhưng giảm 75% độ phức tạp trong vận hành.

So sánh giữa Microservices và kiến trúc dựa trên sự kiện

# Cách tiếp cận Microservices (tại sao chúng ta lại làm điều này?)
services:
  api-gateway: ...
  market-service: ...
  sentiment-service: ...
  portfolio-service: ...
  research-service: ...
  oracle-service: ...

# Kiến trúc dựa trên sự kiện (đây mới là cách)
services:
  app:
    - Tất cả các tác nhân trong một tiến trình
    - Bus sự kiện đảm nhận việc điều phối
  redis:
    - Sự kiện, caching, pub/sub

Chi Tiết Thực Hiện

Motia cung cấp cho bạn các "bước" - giống như các giai đoạn công việc nhưng bất đồng bộ và được kích hoạt bởi sự kiện. Mỗi bước có thể khởi tạo nhiều hành động của tác nhân:

const analyzeTrade = step({
  trigger: 'trade.requested',
  agents: [marketAnalyst, riskManager, sentimentTracker],
  aggregate: results => {
    return consensus(results);
  }
});

Các tác nhân không biết về nhau. Chúng chỉ biết đến các sự kiện. Tác nhân phân tích thị trường thấy "trade.requested" và bắt đầu phân tích. Quản lý rủi ro thực hiện trách nhiệm của mình. Theo dõi tâm lý kiểm tra các yếu tố môi trường. Tất cả đều hoạt động song song, độc lập.

Một điểm quan trọng là khả năng phát lại sự kiện. Nếu hệ thống bị sập? Chỉ cần phát lại các sự kiện. Cần kiểm tra lỗi? Phát lại với logging. Muốn kiểm tra lại? Chỉ cần phát lại các sự kiện lịch sử. Đây thực sự là một giải pháp hoàn hảo mà không gặp phải những cơn ác mộng của Java doanh nghiệp.

Thách Thức (Bởi Vì Không Gì Là Dễ Dàng)

Dịch vụ Azure App không thích WebSockets. Hoặc đúng hơn, nó chỉ thích đôi khi và không bao giờ khi bạn đang trình diễn. Vì vậy, chúng tôi đã xây dựng một giải pháp hybrid:

// Phải sáng tạo ở đây
const stream = isAzureBeingDifficult() 
  ? new PollingFallback('/api/events', 1000)
  : new EventSource('/api/stream');

Ngoài ra, tài liệu của Motia... hãy gọi nó là "đang trong quá trình phát triển". Tôi đã dành nhiều thời gian để đọc mã nguồn và thực sự đã đóng góp một số sửa lỗi trở lại vì lý do cộng đồng mã nguồn mở.

Quản lý bộ nhớ với nhiều tác nhân có thể trở nên kỳ lạ. Mỗi tác nhân duy trì ngữ cảnh của mình có thể dẫn đến việc sử dụng bộ nhớ tăng cao. Tôi đã thực hiện việc dọn dẹp nghiêm ngặt:

// Học được bài học này vào lúc 3 giờ sáng
afterEach(event => {
  if (context.memoryUsage > threshold) {
    context.trimOldestEvents();
  }
});

Những Gì Đã Được Triển Khai

Cả hai hệ thống hiện đang hoạt động trên Azure. Hệ thống dựa trên sự kiện đang xử lý dữ liệu thị trường thực từ Alpaca, xử lý các quy trình làm việc đa tác nhân phức tạp và cung cấp phân tích hữu ích. Thời gian phản hồi dưới 200ms cho hầu hết các truy vấn, có khả năng mở rộng khi cần thiết.

Giao diện người dùng không giống như bất kỳ ứng dụng tài chính Bootstrap nào khác. Biểu đồ TradingView cho các chuyên gia, giao diện sạch sẽ thực sự hợp lý. Bản sao thứ hai cho phép người dùng xây dựng giao diện của riêng họ hoàn toàn vì... khả năng kết hợp hơn là tính năng.

Bài Học Rút Ra

1. Dựa trên sự kiện > microservices cho 90% trường hợp sử dụng - Trừ khi bạn là Netflix, bạn có thể không cần 50 microservices.
2. Framework quan trọng - Motia và Mastra đã giúp tiết kiệm hàng tháng công việc. Đừng tái xây dựng những gì đã được giải quyết.
3. Tín dụng đám mây tác động đến kiến trúc - Chúng tôi sử dụng Azure vì họ đã cung cấp hàng ngàn tín dụng. AWS chỉ cho chúng tôi khoảng 200 đô la. Kiến trúc theo sau những động lực.
4. Điều phối tác nhân đa nhiệm là về sự phối hợp, không phải kiểm soát - Hãy để các tác nhân tự chủ, phối hợp qua sự kiện, không phải qua lệnh.
5. Bộ nhớ lưu trữ là rất quan trọng - Tác nhân không có bộ nhớ chỉ là các hàm không trạng thái. Tích hợp Mem0 là một bước ngoặt.

Kế Hoạch Tiếp Theo

Thực sự? Tôi muốn mã nguồn mở toàn bộ dự án này. Có quá nhiều nền tảng fintech "cách mạng" đóng cửa chết trong sự mờ mịt. Hãy để cộng đồng xây dựng trên nền tảng này.

Tôi muốn thêm nhiều loại sự kiện hơn - sụp đổ thị trường, thay đổi quy định, sự chuyển động của cá voi. Kiến trúc hỗ trợ điều đó, chỉ cần thực hiện các trình xử lý.

Việc kiểm tra lại qua phát lại sự kiện thực sự đã có sẵn, chỉ cần có một giao diện người dùng. Hãy tưởng tượng phát lại năm 2008 qua hệ thống tác nhân của bạn... thực sự có thể buồn.

Kết Luận

Tôi đã xây dựng bốn ứng dụng sản xuất cho một hackathon vì một ứng dụng cảm thấy nhàm chán. Hệ thống đa tác nhân dựa trên sự kiện với Motia/Mastra thực sự tốt hơn những gì tôi thấy từ các đội ngũ được tài trợ. Nó đang hoạt động, có khả năng mở rộng và thực sự hiệu quả.

Hãy sẵn sàng cho một tương lai của các hệ thống đa tác nhân độc lập, được xử lý bất đồng bộ và có khả năng mở rộng theo chiều ngang.