深入解析Eliza框架：Provider与Action的工作机制

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

本文为介绍Eliza工作原理系列文章的第一篇，主要聚焦于Provider和Action的运行原理。该系列将分为三部分：

1. Provider 和 Action 的运行原理

2. Evaluator 的运行原理

3. Eliza Memory 的设计思想

1. Eliza 架构概览

• 顶层包括Provider、Evaluator及Action，分别模拟人类感知信息（如视觉、听觉）、执行能力（根据市场信息判断比特币走势等）以及思考过程（从大量数据中提炼知识形成认知）。

• 底层则支持多种AI模型，比如OpenAI, Claude, Gemini等，作为决策的核心处理器。

• Memory功能允许通过Eliza启动的AI代理超越内容限制，不仅能够存储来自环境的信息或行动结果的压缩版，还可在交互过程中提取重要信息。

2. Provider与Action详解

「Provider」

关于Provider的设计考量有三点：

1. 为什么需要Provider？

2. AI怎样理解Provider提供的信息？

3. 如何在Eliza框架内调用Provider获取信息？

为什么需要Provider？

为了克服通用大模型在特定领域信息获取上的局限性，Provider组件直接从专业API获取详细数据，确保信息全面准确。例如，TokenProvider能提供代币持有者分布、价格变动等关键信息，帮助做出投资决策。

然而，如果仅依靠Prompt让AI自行获取这些信息，则可能遇到代码生成不准确或需反复调试的问题，因此Provider的存在显得尤为重要。

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

所有通过Provider获取的数据都会被转换成自然语言格式返回给AI模型，以满足其对输入格式的要求。

如何调用Provider？

当前，在Eliza框架下，Provider的调用仍依赖特定Action根据需求直接发起请求，而非模块化的方式。例如，在购买代币的过程中，BuyToken Action会利用TokenProvider来评估代币价值，并通过WalletProvider管理交易细节。

「Action」

对于Action的理解涉及以下几个方面：

1. 为何需要Action？

2. 如何触发Action？

3. Action具体做了什么？

4. 如何使AGI明白它执行了哪些操作？

为什么需要Action？

直接向AI提供私钥并要求其完成链上交易既不安全也不现实。通过封装这类行为到Action中，并结合示例Prompt，可以更有效地指导AI完成复杂任务。

如何触发Action？

使用预定义的Prompt Example可以帮助AI识别何时应调用相应的Action，同时HandlerMessageTemplate也促进了多Action环境下的选择优化。

Action执行流程

以创建并购买Meme Token为例，Action首先收集必要信息，随后构建交易，签名并提交至区块链网络，最后将结果反馈给AI的记忆系统以便后续学习。

使AGI理解Action的行为

通过总结每个Action的结果并将其存入记忆库，可以让AI更好地理解和追踪自己的行为轨迹。

完整的Eliza架构图如下所示: