Technical explanation of how Eliza works: Provider and Action

Author: 0xhhh Source: X, @hhh69251498

This series on the Eliza principle will be divided into three parts:

1. The operating principle of Provider and Action

2. The operating principle of Evaluator

3. The design concept of Eliza Memory

This is the first article, mainly introducing: The operating principle of Provider and Action

1. The Eliza architecture is as follows, mainly divided into 3 parts

• The top layer is abstracted into Provider, Evaluator and Action, corresponding to the human's ability to acquire information (the eyes acquire visual information, the ears acquire auditory information, etc.), as well as the human's ability to execute based on information (such as judging that BTC will still have a future based on market information), and the Evaluator is similar to the human's thinking ability, extracting knowledge from a large amount of information through thinking to form personal cognition.

• The bottom layer is different AI Models: Currently, the Eliza framework supports most of the AI Models on the market, such as openai, claude, gemini, gork, xai, etc., which is similar to the human brain and is the key processing module for all decision-making.

• Memory allows the AI Agent launched through the Eliza framework to have the ability to break out of the Content Limitation, because AI can compress the information acquired from the environment in the Provider stage and the information on the results of Action execution, and store them in Memory; and can also extract key information through the Evaluator from the dialogue with humans or any other interaction process (this will be discussed in detail in the next Thread)

2. In the following, we will introduce the operating principles of "Provider" and "Action" in detail

"Provider"

For Provider, we need to consider three questions:

1. Why need Provider (why does the Eliza framework need to design the Provider component)?

2. How does AI understand the information provided by Provider?

3. How to invoke Provider (how does the AI in the Eliza framework obtain information through Provider)?

Why need Provider?

Provider is mainly used to solve the problem that the information we obtain through prompts is not accurate and comprehensive enough for AI, because the models we are currently using are general large models, so there may be insufficient comprehensiveness in obtaining information in specific fields.

For example, the following code is the implementation of TokenProvider in Eliza, which will ultimately use the APIs we provide to obtain key information about a Token on the chain from multiple dimensions, such as who the top 10 Holders of the token are and how much of the token each person holds, the 24-hour price change of the token, etc., and will return this information in text form, so that the AI Model can make key decisions on whether to buy the meme token based on this information.

But if we directly tell the AI through Prompt to help us get the corresponding information, you will find that the AI will provide us with the corresponding code (and sometimes the code provided by the AI may not be able to run smoothly, and we need to submit the errors generated by running the code to the AI before the code can run smoothly), but we still need to deploy it to the blockchain environment (and we also need to provide a reliable API-KEY).

For example, the following example:

So in order to ensure the smoothness of data acquisition, the code for acquiring this data will be encapsulated in the definition of Provider in the Eliza framework, so that we can easily obtain the asset information of any account on Solona, so this is the core reason for Why need Provider.

How does AI understand the information provided by Provider?

The information obtained by the Eliza framework through Provider will ultimately be returned to the AI Model in the form of text (natural language), because the format required by the AI Model for the requested information is natural language.

How to invoke Provider (how does the AI in the Eliza framework obtain information through Provider)?

Currently, for Provider in the Eliza framework, although there is an interface abstraction provided, the invocation method of Provider is not modular, but still has specific Actions directly calling the corresponding Provider to obtain information, the relationship diagram is as follows:

Suppose we have a BuyToken Action, when it is judging whether it should buy a Token based on human recommendation, it will request information from TokenProvider and WalletProvider during the execution of this Action, TokenProvider will provide information to assist the AI Agent in judging whether this Token is worth buying, and WalletProvider will provide private key information for transaction signing, and also provide information on the available assets in the wallet.

"Action"

You can easily find the definition of Action in the following Github link, but if you don't look at the code in depth, you'll have a hard time understanding:

1. Why need Action? (Why does the Eliza framework need Action)

2. How to Invoke Action? (How does the Eliza framework allow AI to call Action)

3. What does the Eliza framework Action specifically execute?

4. How to let AGI understand what the Action it just called did?

Why Need Action? (Why does the Eliza framework need to abstract out Action?)

Suppose I tell the AI: My private key

0xajahdjksadhsadnjksajkdlad12612

There are 10 sol in it, can you help me buy 100 Ai16z tokens.

Claude's response is as follows:

Obviously, providing the private key in this way is not secure, and AGI also has a hard time executing this kind of on-chain operation.

Here we can further ask AGI: Can you give us the corresponding execution code: when we have Sol in our wallet, I hope we can buy all the Sol in our wallet into the meme token I specified.

Of course Claude has this capability, but we still need to guide it multiple times to finally get the code that satisfies us.

Therefore, we can encapsulate the code given by AI into an Action of Eliza, and give some Prompt Examples to help AI understand when I should call this Action.

(And in real-world usage scenarios, the operations we want to do are much more complex than this, such as a Swap transaction, we hope to have slippage limits, then these conditional constraints are difficult for the AI large model to complete to ensure that every element of the execution process meets our requirements).

How to Invoke Action? (How does the Eliza framework allow AI to call Action)

The following is an example of a Prompt in the Eliza framework to allow the AI Model to create a meme token in Pumpfun and buy a certain value of that meme token. After we provide these Example Prompts in the corresponding Action, the AI Agent will know that when similar content appears in the subsequent interaction process with humans, it will call the corresponding Action to execute based on the Prompt Example we provided.

But the Eliza framework also supports multiple Actions at the same time, as it also provides the following HandlerMessageTemplate to allow the AI Model to choose the appropriate Action to call.

In fact, this Template rearranges all the data in a more logical way, providing the data to the AI Model, so that the AI Model can make more accurate calls to these pre-defined Actions. (This is something that is difficult to do directly using the AI Model client)

What does the Eliza framework Action specifically execute?

https://github.com/elizaOS/eliza/blob/main/packages/plugin-solana/src/actions/pumpfun.ts#L279

Still using the example of the Pumpfun Action, its flow is as follows:

1. Obtain information from WalletProvider and TokenProvider

2. Generate transactions for creating MemeToken and buying MemeToken

3. Sign the transaction and send it to the chain

4. Call the callback function to process the result of the Action execution.

The core is actually two parts, one part is to obtain information from the Provider, and then generate the operation function to perform the action.

How to let AGI understand what the Action it just called did?

If this problem is not solved, we cannot let AI understand and execute related tasks.

The answer is: After we execute the Action, we will use text to summarize what results this action has produced, and add this result to the AI's memory.

The details are as follows: The fourth parameter of the Action's Handle function is a callback function, and we will define the callback function to add the execution result to the Memory module of the AI Model.

The definition of the callback function is as follows:

The complete Eliza Action and Provider architecture is as follows: