作者：0xhhh 来源：X，@hhh69251498

Eliza 原理介绍这个系列会分成三部分来写:

1. Provider 和 Action 的运行原理

2. Evaluator 的运行原理

3. Eliza Memory 的设计思想

当前是第一篇文章主要介绍：Provider 和 Action 的运行原理

1. Eliza 的架构如下，主要分为 3 个部分

• 最上层抽象成了 Provider 和 Evaluator 以及 Action ，分别对应人类获取信息的能力 ( 眼睛获取视觉信息，耳朵获取听觉信息等等 )，以及人类根据信息的执行能力 ( 比如通过市场信息判断 BTC 未来还有 )，还有 Evaluator 只类似人类的思考能力，通过思考从海量的信息中提取知识从而形成个人的认知。

• 最下层是不同的 AI Model:目前 Eliza 框架支持了市面上大多数的 AI Model，比如 openai, claude, gemini, gork, xai 等等，这个类似人类的大脑是所有做出决策的关键处理模块。

• memory 则是让通过 Eliza 框架启动的 Ai Agent 拥有跳出 Content Limitation 限制的能力，因为 AI 既可以在 Provider 阶段把从环境中获取的信息和 Action 执行后结果的信息压缩之后存储进入 Memory 之中；并且也可以通过 Evaluator 提取跟人类对话或者其他任意交互过程中一些关键信息 ( 这个会在下一个 Thread 里详细介绍 )

2. 在接下来的部分我们将详细介绍「Provider」 和 「Action」的运行原理

「Provider」

对于 Provider 我们需要思考三个问题：

1. Why need Provider(Eliza 框架为什么要设计 Provider 这个组件 )?

2. AI 如何理解 Provider 提供的信息？

3. How to invoke Provider(Eliza 框架内 AI 如何通过 Provider 获取信息 )?

Why need Provider?

Provider 主要用来解决在一些信息我们通过 prompt 让 AI 获取不准确也不够全面的问题，因为我们现在使用的模型都是通用大模型，所以对特定领域的信息获取有时候会存在不够全面的问题。

比如下面的代码就是 Eliza 中 TokenProvider 的实现，它最终会通过我们提供的 Api 去拿到一个 Token 在链上多个纬度的关键信息，比如这个代币前十个 Holder 是谁每个人占据了多少份额的代币，这个代币 24h 的价格变化等等信息并且最终会用文本的方式返回给 AI Model，这样一来 AI Model 就可以根据这些信息来作做出一些是否购买 meme token 的关键决策了。

但是如果我们直接通过 Prompt 告诉 AI 帮我获取对应的这些信息，你会发现 AI 会提供给我们对应的代码 ( 并且有些时候 AI 提供的代码不一定能跑出来还需要把对应代码运行产生的错误提交给 AI 最终才能让代码顺畅运行 )，但是我们还是需要将其部署到区块链环境（同时我们也需要提供可靠的 API-KEY).

比如下面的例子:

所以为了保证获取数据的顺畅性，在 Eliza 的框架里会这部分获取数据的代码封装到 Provider 的定义下，这样以来我们就能很方便的获取任意账户内在 solona 上的资产信息了，因此这是 Why need Provider 的核心原因.

AI 如何理解 Provider 提供的信息？

Eliza 框架通过 Provider 拿到的信息最终会用文本 ( 自然语言 ) 的形式来返回给 AI Model，因为 AI Model 对请求信息的格式要求就是自然语言。

How to invoke Provider(Eliza 框架内 AI 如何通过 Provider 获取信息 )?

目前 Eliza 框架内对于 Provider，虽然有提供对应的接口抽象，但是目前 Provider 的调用方式并不是模块化的，还是有特定的 Action 根据自己的信息需求直接调用对应的 Provider 进行获取，关系图如下:

假设我们有一个 BuyToken Action 当他在判断自己是否应该根据人类的推荐购买一个 Token 时，他就会在执行这个 Action 过程中请求 TokenProvider 和 WalletProvider 提供信息，TokenProvider 会提供信息辅助 AI Agent 判断这个 Token 值不值得买，Wallet Provider 会提供私钥信息用于交易签名，同时也提供该钱包可用资产的信息。

「Action」

可以在以下 Github 链接很方便的找到 Action 的定义，但是你如果没有深入看代码你很难理解：

1. Why need Action？（Eliza 框架为什么需要 Action）

2. How to Invoke Action？(Eliza 框架如何让 AI 调用 Action)

3. Eliza 框架 Action 具体执行了什么？

4. 怎么让 AGI 理解他刚刚调用的 Action 做了什么 ？

Why Need Action? (Eliza 框架为什么需要抽象出 Action?)

假如我跟 AI 说: 我的私钥

0xajahdjksadhsadnjksajkdlad12612

这里面有 10 个 sol，你能不能帮我买 100 个 Ai16z 的代币。

Claude 的回复如下：

很明显通过这样给予私钥的操作并不安全，同时 AGI 也很难执行这种链上操作。

这里我们可以进一步问 AGI: 你能不能给我们实现相应的执行代码：当我们钱包中有 Sol 的时候，我希望可以把钱包里的所有 sol 都买成我指定的 meme 代币。

Claude 当然有这个能力，但是还是需要我们多次引导，才最终可以得到让我们满意的代码。

因此我们可以把 AI 给予的代码封装成 Eliza 的一个 Action,并且给一些 Prompt 的 Example，来帮助 AI 理解什么时候我该调用这个 Action。

（而且在真实的使用场景里我们想做的操作比这个要复杂很多，比如一笔 Swap 交易我们希望有滑点限制，那么这些条件限制交给 AI 大模型去完成的时候我们其实很难保证执行过程后每一个要素都可以满足我们的要求）。

How to Invoke Action？(Eliza 框架如何让 AI 调用 Action)

下面就是 Eliza 框架中，一个在用来让 AI Model 在 Pumpfun 中创建一个 meme 代币并且买入一定价值的该 meme 代币的 Prompt Example,当我们在对应的 Action 中给出这些 Example 之后，AI Agent 就知道,之后跟人类的交互过程中出现类似的内容的时候就会因为我们提供的这类 Promt Exapmle 知道要调用执行哪个 Action。

但是 Eliza 框架是同时支持多个 Action 的，因为也提供了以下的 HandlerMessageTemplate 来让 AI Model 会选择合适的 Action 进行调用。

事实上，这个 Template 对所有的数据进行了重排，把数据更有逻辑的提供给了 AI Model，从而让 AI Model 可以做出更准确的调用这些预定义好的 Action.（这也是我们直接使用 AI Model 客户端比较难做到的）

Eliza 框架 Action 具体执行了什么？

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

具体还是以 Pumpfun Action 的这个例子来解释，它的流程如下：

1. 从 WalletProvider 和 TokenProvider 获取信息

2. 生成创建 MemeToken 以及购买 MemeToken 的交易

3. 对交易进行签名并发送到链上

4. 调用 callback 函数对 Action 执行后的结果进行处理。

其实核心就是两部分，一部分就是从 Provider 获取信息，然后生成要执行动作的操作函数。

怎么让 AGI 理解它调用的 Action 做了什么 ？

这个问题如果没有解决,那么我们就无法让 AI 理解并执行有关联性的任务。

答案如下：我们执行 Action 之后会用文本来总结这个动作产生了什么结果，并且把这个结果加入到 AI 的 memory 之中。

细节如下：Action 的 Handle 函数第四个参数是一个 callback 函数，我们会把 callback 函数定义成把执行结果加入到 AI Model 的 Memory 模块中。

callback 函数的定义如下:

完整的 Eliza 的 Action 和 Provider 架构如下: