Tác giả: 0xhhh Nguồn: X, @hhh69251498
Chuỗi bài giới thiệu về nguyên lý Eliza sẽ được chia thành ba phần:
Nguyên lý hoạt động của Provider và Action
Nguyên lý hoạt động của Evaluator
Ý tưởng thiết kế Eliza Memory
Bài viết hiện tại là phần đầu tiên, chủ yếu giới thiệu về nguyên lý hoạt động của Provider và Action.
1. Kiến trúc của Eliza bao gồm 3 phần chính
Lớp trừu tượng cao nhất là Provider, Evaluator và Action, tương ứng với khả năng thu thập thông tin (mắt thu thập thông tin thị giác, tai thu thập thông tin thính giác, v.v.) và khả năng thực hiện hành động dựa trên thông tin (ví dụ: dựa trên thông tin thị trường để đưa ra quyết định về BTC trong tương lai) của con người, cũng như khả năng tư duy (Evaluator) tương tự như con người, thông qua việc suy nghĩ để trích xuất kiến thức từ khối lượng thông tin khổng lồ để hình thành nhận thức cá nhân.
Lớp dưới cùng là các mô hình AI khác nhau: hiện tại, khung Eliza hỗ trợ hầu hết các mô hình AI phổ biến trên thị trường, chẳng hạn như openai, claude, gemini, gork, xai, v.v., tương tự như bộ não của con người, đây là mô-đun xử lý then chốt để đưa ra các quyết định.
Memory cho phép các Agent AI khởi chạy thông qua khung Eliza vượt qua giới hạn nội dung, vì AI có thể nén và lưu trữ thông tin thu thập từ môi trường trong giai đoạn Provider cũng như thông tin về kết quả thực hiện Action vào Memory; và cũng có thể trích xuất các thông tin then chốt từ quá trình đối thoại với con người hoặc bất kỳ quá trình tương tác nào khác thông qua Evaluator (điều này sẽ được trình bày chi tiết hơn trong chủ đề tiếp theo).
2. Trong phần tiếp theo, chúng tôi sẽ giới thiệu chi tiết về nguyên lý hoạt động của "Provider" và "Action"
「Provider」
Đối với Provider, chúng ta cần xem xét ba vấn đề:
Tại sao cần Provider (Tại sao khung Eliza lại thiết kế thành phần Provider)?
AI sẽ hiểu thông tin do Provider cung cấp như thế nào?
Làm thế nào để gọi Provider (Trong khung Eliza, AI sẽ lấy thông tin thông qua Provider như thế nào)?
Tại sao cần Provider?
Provider chủ yếu được sử dụng để giải quyết vấn đề thông tin mà chúng ta có thể yêu cầu AI lấy thông qua prompt không chính xác và không đầy đủ, vì các mô hình mà chúng ta đang sử dụng là các mô hình lớn phổ dụng, nên việc lấy thông tin cho các lĩnh vực cụ thể đôi khi sẽ không đầy đủ.
Ví dụ, đoạn mã dưới đây là cách thực hiện TokenProvider trong Eliza, nó cuối cùng sẽ sử dụng API mà chúng tôi cung cấp để lấy các thông tin then chốt của một Token trên chuỗi, chẳng hạn như 10 holder lớn nhất của token này và tỷ lệ nắm giữ của họ, biến động giá 24h của token, v.v. và cuối cùng sẽ trả về thông tin dưới dạng văn bản, để từ đó mô hình AI có thể dựa vào những thông tin này để đưa ra quyết định có nên mua token meme hay không.
Nhưng nếu chúng ta trực tiếp yêu cầu AI thông qua Prompt để lấy những thông tin tương ứng, bạn sẽ thấy AI sẽ cung cấp cho chúng ta đoạn mã tương ứng (và đôi khi mã mà AI cung cấp không chạy được, chúng ta cần phải gửi lại lỗi cho AI để cuối cùng mã mới chạy trơn tru), nhưng chúng ta vẫn cần triển khai nó trong môi trường blockchain (đồng thời chúng ta cũng cần cung cấp API-KEY đáng tin cậy).
Ví dụ như đoạn mã dưới đây:
Vì vậy, để đảm bảo việc lấy dữ liệu được trơn tru, trong khung Eliza, chúng tôi sẽ đóng gói đoạn mã lấy dữ liệu này vào định nghĩa của Provider, như vậy chúng ta sẽ có thể dễ dàng lấy thông tin về tài sản trên Solana của bất kỳ tài khoản nào, đây là lý do cốt lõi tại sao cần có Provider.
AI sẽ hiểu thông tin do Provider cung cấp như thế nào?
Thông tin mà khung Eliza lấy thông qua Provider cuối cùng sẽ được trả về cho mô hình AI dưới dạng văn bản (ngôn ngữ tự nhiên), vì yêu cầu về định dạng thông tin của mô hình AI chính là ngôn ngữ tự nhiên.
Làm thế nào để gọi Provider (Trong khung Eliza, AI sẽ lấy thông tin thông qua Provider như thế nào)?
Hiện tại, đối với Provider trong khung Eliza, mặc dù đã cung cấp các giao diện trừu tượng tương ứng, nhưng cách gọi Provider vẫn chưa theo mô-đun hóa, vẫn có những Action cụ thể dựa trên nhu cầu thông tin của chính mình để gọi trực tiếp Provider tương ứng, sơ đồ mối quan hệ như sau:
Giả sử chúng ta có một Action BuyToken, khi nó đang xem xét có nên mua một Token theo khuyến nghị của con người hay không, nó sẽ yêu cầu TokenProvider và WalletProvider cung cấp thông tin trong quá trình thực hiện Action này, TokenProvider sẽ cung cấp thông tin để hỗ trợ Agent AI đánh giá xem Token có đáng mua hay không, WalletProvider sẽ cung cấp thông tin private key để ký giao dịch, đồng thời cũng cung cấp thông tin về tài sản có sẵn trong ví.
「Action」
Bạn có thể dễ dàng tìm thấy định nghĩa của Action tại liên kết Github dưới đây, nhưng nếu bạn không xem kỹ mã, bạn sẽ khó hiểu:
Tại sao cần Action? (Tại sao khung Eliza cần phải trừu tượng hóa Action)
Làm thế nào để gọi Action? (Khung Eliza sẽ làm thế nào để AI gọi Action)
Action trong khung Eliza thực sự thực hiện những gì?
Làm thế nào để để AGI hiểu những gì nó vừa gọi Action thực hiện?
Tại sao cần Action? (Tại sao khung Eliza cần phải trừu tượng hóa Action?)
Giả sử tôi nói với AI: private key của tôi là
0xajahdjksadhsadnjksajkdlad12612
Trong đó có 10 sol, bạn có thể giúp tôi mua 100 token Ai16z không.
Phản hồi của Claude như sau:
Rõ ràng việc cung cấp private key như vậy là không an toàn, đồng thời AGI cũng khó thực hiện các thao tác trên chuỗi.
Ở đây chúng ta có thể hỏi tiếp AGI: Bạn có thể viết mã thực hiện tương ứng không: khi chúng tôi có Sol trong ví, tôi muốn có thể mua tất cả Sol thành token meme mà tôi chỉ định.
Tất nhiên Claude có khả năng này, nhưng vẫn cần chúng ta hướng dẫn nhiều lần mới có thể cuối cùng nhận được mã mà chúng ta hài lòng.
Do đó, chúng ta có thể đóng gói mã mà AI cung cấp thành một Action trong Eliza, và cung cấp một số ví dụ Prompt để giúp AI hiểu khi nào nên gọi Action này.
(Và trong các kịch bản sử dụng thực tế, những thao tác chúng ta muốn thực hiện còn phức tạp hơn nhiều, ví dụ như một giao dịch Swap, chúng ta muốn có giới hạn trượt giá, thì những điều kiện giới hạn này giao cho mô hình AI lớn hoàn thành thực sự rất khó đảm bảo rằng mọi yếu tố trong quá trình thực hiện đều đáp ứng được yêu cầu của chúng ta).
Làm thế nào để gọi Action? (Khung Eliza sẽ làm thế nào để AI gọi Action)
Dưới đây là một ví dụ Prompt trong khung Eliza, dùng để cho phép mô hình AI tạo một token meme trong Pumpfun và mua một số lượng nhất định của token meme đó, khi chúng ta cung cấp các ví dụ Prompt như vậy trong Action tương ứng, Agent AI sẽ biết rằng khi gặp nội dung tương tự trong quá trình tương tác với con người, nó sẽ gọi thực hiện Action tương ứng.
Tuy nhiên, khung Eliza cũng hỗ trợ nhiều Action cùng một lúc, vì nó cũng cung cấp HandlerMessageTemplate sau đây để giúp mô hình AI lựa chọn Action phù hợp để gọi.
Thực tế, mẫu này đã sắp xếp lại tất cả dữ liệu theo logic hơn, cung cấp cho mô hình AI theo cách có logic hơn, giúp mô hình AI có thể gọi những Action được định nghĩa trước chính xác hơn. (Đây cũng là điều mà chúng ta khó làm được khi trực tiếp sử dụng khách hàng mô hình AI).
Action trong khung Eliza thực sự thực hiện những gì?
https://github.com/elizaOS/eliza/blob/main/packages/plugin-solana/src/actions/pumpfun.ts#L279
Cụ thể, vẫn lấy ví dụ về Action Pumpfun, quy trình của nó như sau:
Lấy thông tin từ WalletProvider và TokenProvider
Tạo giao dịch để tạo MemeToken và mua MemeToken