@elizaos/core 1.0.0-beta.70 → 1.0.0-beta.72
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +233 -0
- package/dist/index.js +0 -2
- package/package.json +2 -2
package/README.md
ADDED
|
@@ -0,0 +1,233 @@
|
|
|
1
|
+
# @elizaos/core
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
|
|
5
|
+
The `@elizaos/core` package provides a robust foundation for building AI agents with dynamic interaction capabilities. It enables agents to manage entities, memories, and context, and to interact with external systems, going beyond simple message responses to handle complex scenarios and execute tasks effectively.
|
|
6
|
+
|
|
7
|
+
## Key Features
|
|
8
|
+
|
|
9
|
+
- **AgentRuntime:** Central orchestrator for managing agent lifecycle, plugins, and interactions.
|
|
10
|
+
- **Actions:** Define tasks the agent can perform, with validation and execution logic.
|
|
11
|
+
- **Providers:** Supply real-time data and context to the agent, enabling interaction with dynamic environments and external APIs.
|
|
12
|
+
- **Evaluators:** Process conversation data to extract insights, build long-term memory, and maintain contextual awareness.
|
|
13
|
+
- **Plugin System:** Extensible architecture allowing for modular addition of functionalities.
|
|
14
|
+
- **Entity and Memory Management:** Core support for tracking entities and their associated information.
|
|
15
|
+
|
|
16
|
+
## Installation
|
|
17
|
+
|
|
18
|
+
1. Add `@elizaos/core` to your `agent/package.json` dependencies:
|
|
19
|
+
|
|
20
|
+
```json
|
|
21
|
+
{
|
|
22
|
+
"dependencies": {
|
|
23
|
+
"@elizaos/core": "workspace:*"
|
|
24
|
+
}
|
|
25
|
+
}
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
2. Navigate to your `agent/` directory.
|
|
29
|
+
3. Install dependencies:
|
|
30
|
+
```bash
|
|
31
|
+
bun install
|
|
32
|
+
```
|
|
33
|
+
4. Build your project:
|
|
34
|
+
```bash
|
|
35
|
+
bun run build
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Configuration
|
|
39
|
+
|
|
40
|
+
The following environment variables are used by `@elizaos/core`. Configure them in a `.env` file at your project root.
|
|
41
|
+
|
|
42
|
+
- `LOG_LEVEL`: Logging verbosity (e.g., 'debug', 'info', 'error').
|
|
43
|
+
- `LOG_DIAGNOSTIC`: Enable/disable diagnostic logging (`true`/`false`).
|
|
44
|
+
- `LOG_JSON_FORMAT`: Output logs in JSON format (`true`/`false`).
|
|
45
|
+
- `DEFAULT_LOG_LEVEL`: Default log level if not in debug mode.
|
|
46
|
+
- `SECRET_SALT`: Secret salt for encryption purposes.
|
|
47
|
+
- `SENTRY_DSN`: Sentry DSN for error reporting.
|
|
48
|
+
- `SENTRY_ENVIRONMENT`: Sentry deployment environment (e.g., 'production', 'staging').
|
|
49
|
+
- `SENTRY_TRACES_SAMPLE_RATE`: Sentry performance tracing sample rate (0.0 - 1.0).
|
|
50
|
+
- `SENTRY_SEND_DEFAULT_PII`: Send Personally Identifiable Information to Sentry (`true`/`false`).
|
|
51
|
+
|
|
52
|
+
**Example `.env`:**
|
|
53
|
+
|
|
54
|
+
```plaintext
|
|
55
|
+
LOG_LEVEL=debug
|
|
56
|
+
LOG_DIAGNOSTIC=true
|
|
57
|
+
LOG_JSON_FORMAT=false
|
|
58
|
+
DEFAULT_LOG_LEVEL=info
|
|
59
|
+
SECRET_SALT=yourSecretSaltHere
|
|
60
|
+
SENTRY_DSN=yourSentryDsnHere
|
|
61
|
+
SENTRY_ENVIRONMENT=development
|
|
62
|
+
SENTRY_TRACES_SAMPLE_RATE=1.0
|
|
63
|
+
SENTRY_SEND_DEFAULT_PII=true
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
**Note:** Add your `.env` file to `.gitignore` to protect sensitive information.
|
|
67
|
+
|
|
68
|
+
## Core Architecture
|
|
69
|
+
|
|
70
|
+
`@elizaos/core` is built around a few key concepts that work together within the `AgentRuntime`.
|
|
71
|
+
|
|
72
|
+
### AgentRuntime
|
|
73
|
+
|
|
74
|
+
The `AgentRuntime` is the heart of the system. It manages the agent's lifecycle, loads plugins, orchestrates interactions, and provides a central point for actions, providers, and evaluators to operate. It's typically initialized with a set of plugins, including the `corePlugin` which provides foundational capabilities.
|
|
75
|
+
|
|
76
|
+
### Actions
|
|
77
|
+
|
|
78
|
+
Actions define specific tasks or capabilities the agent can perform. Each action typically includes:
|
|
79
|
+
|
|
80
|
+
- A unique `name`.
|
|
81
|
+
- A `description` explaining its purpose and when it should be triggered.
|
|
82
|
+
- A `validate` function to determine if the action is applicable in a given context.
|
|
83
|
+
- A `handler` function that executes the action's logic.
|
|
84
|
+
|
|
85
|
+
Actions enable the agent to respond intelligently and perform operations based on user input or internal triggers.
|
|
86
|
+
|
|
87
|
+
### Providers
|
|
88
|
+
|
|
89
|
+
Providers are responsible for supplying data and context to the `AgentRuntime` and its components. They can:
|
|
90
|
+
|
|
91
|
+
- Fetch data from external APIs or databases.
|
|
92
|
+
- Provide real-time information about the environment.
|
|
93
|
+
- Offer access to external services or tools.
|
|
94
|
+
|
|
95
|
+
This allows the agent to operate with up-to-date and relevant information.
|
|
96
|
+
|
|
97
|
+
### Evaluators
|
|
98
|
+
|
|
99
|
+
Evaluators analyze conversation data and other inputs to extract meaningful information, build the agent's memory, and maintain contextual awareness. They help the agent:
|
|
100
|
+
|
|
101
|
+
- Understand user intent.
|
|
102
|
+
- Extract facts and relationships.
|
|
103
|
+
- Reflect on past interactions to improve future responses.
|
|
104
|
+
- Update the agent's knowledge base.
|
|
105
|
+
|
|
106
|
+
## Getting Started
|
|
107
|
+
|
|
108
|
+
### Initializing with `corePlugin`
|
|
109
|
+
|
|
110
|
+
The `corePlugin` bundles essential actions, providers, and evaluators from `@elizaos/core`. To use it, add it to the `AgentRuntime` during initialization:
|
|
111
|
+
|
|
112
|
+
```typescript
|
|
113
|
+
import { AgentRuntime, corePlugin } from '@elizaos/core';
|
|
114
|
+
|
|
115
|
+
const agentRuntime = new AgentRuntime({
|
|
116
|
+
plugins: [
|
|
117
|
+
corePlugin,
|
|
118
|
+
// You can add other custom or third-party plugins here
|
|
119
|
+
],
|
|
120
|
+
// Other AgentRuntime configurations can be specified here
|
|
121
|
+
});
|
|
122
|
+
|
|
123
|
+
// After initialization, agentRuntime is ready to be used.
|
|
124
|
+
// You should see console messages like "✓ Registering action: <plugin actions>"
|
|
125
|
+
// indicating successful plugin registration.
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### Example: Defining a Custom Action (Conceptual)
|
|
129
|
+
|
|
130
|
+
While `corePlugin` provides many actions, you might need to define custom actions for specific agent behaviors. Here's a conceptual outline:
|
|
131
|
+
|
|
132
|
+
```typescript
|
|
133
|
+
// myCustomAction.ts
|
|
134
|
+
// (This is a simplified conceptual example)
|
|
135
|
+
|
|
136
|
+
export const myCustomAction = {
|
|
137
|
+
name: 'customGreet',
|
|
138
|
+
description: 'Greets a user in a special way.',
|
|
139
|
+
validate: async ({ context }) => {
|
|
140
|
+
// Logic to determine if this action should run
|
|
141
|
+
// e.g., return context.message.text.includes('special hello');
|
|
142
|
+
return true; // Placeholder
|
|
143
|
+
},
|
|
144
|
+
handler: async ({ runtime, context }) => {
|
|
145
|
+
// Logic to execute the action
|
|
146
|
+
// e.g., runtime.sendMessage(context.roomId, "A very special hello to you!");
|
|
147
|
+
console.log('Custom Greet action executed!');
|
|
148
|
+
return { success: true, message: 'Custom greeting sent.' };
|
|
149
|
+
},
|
|
150
|
+
};
|
|
151
|
+
|
|
152
|
+
// Then, this action would be registered with the AgentRuntime, typically via a custom plugin.
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
For detailed instructions on creating and registering plugins and actions, refer to the specific documentation or examples within the codebase.
|
|
156
|
+
|
|
157
|
+
## Development & Testing
|
|
158
|
+
|
|
159
|
+
### Running Tests
|
|
160
|
+
|
|
161
|
+
The `@elizaos/core` package uses **Vitest** for testing.
|
|
162
|
+
|
|
163
|
+
1. **Prerequisites**:
|
|
164
|
+
|
|
165
|
+
- Ensure `bun` is installed (`npm install -g bun`).
|
|
166
|
+
- Environment variables in `.env` (as described in Configuration) are generally **not required** for most core tests but might be for specific integration tests if any.
|
|
167
|
+
|
|
168
|
+
2. **Setup**:
|
|
169
|
+
|
|
170
|
+
- Navigate to the `packages/core` directory: `cd packages/core`
|
|
171
|
+
- Install dependencies: `bun install`
|
|
172
|
+
|
|
173
|
+
3. **Execute Tests**:
|
|
174
|
+
```bash
|
|
175
|
+
bun test
|
|
176
|
+
```
|
|
177
|
+
Test results will be displayed in the terminal.
|
|
178
|
+
|
|
179
|
+
### TODO Items
|
|
180
|
+
|
|
181
|
+
The following improvements and features are planned for `@elizaos/core`:
|
|
182
|
+
|
|
183
|
+
- **Feature**: Add ability for plugins to register their sources (Context: Exporting a default `sendMessageAction`).
|
|
184
|
+
- **Enhancement**: Improve formatting of posts (Context: Returning formatted posts joined by a newline).
|
|
185
|
+
- **Bug**: Resolve server ID creation/retrieval issues (Context: Creating a room with specific world, name, and server IDs).
|
|
186
|
+
- **Enhancement**: Refactor message sending logic to an `ensureConnection` approach (Context: Sending messages to room participants).
|
|
187
|
+
|
|
188
|
+
## Troubleshooting & FAQ
|
|
189
|
+
|
|
190
|
+
### Common Issues
|
|
191
|
+
|
|
192
|
+
- **AgentRuntime not responding to triggers**:
|
|
193
|
+
|
|
194
|
+
- **Cause**: Improperly defined action `validate` functions or handlers. Trigger conditions might not be met.
|
|
195
|
+
- **Solution**: Verify `validate` functions correctly identify trigger conditions. Ensure `handler` functions execute as intended. Check console logs for errors during validation/handling.
|
|
196
|
+
|
|
197
|
+
- **Provider data is outdated/incorrect**:
|
|
198
|
+
|
|
199
|
+
- **Cause**: Issues with external data source integration or API failures.
|
|
200
|
+
- **Solution**: Check API connections and ensure the provider's data fetching logic is accurate. Review network configurations if needed.
|
|
201
|
+
|
|
202
|
+
- **Evaluator fails to maintain context**:
|
|
203
|
+
- **Cause**: Evaluator not capturing necessary facts/relationships correctly.
|
|
204
|
+
- **Solution**: Review evaluator configuration. Ensure it uses correct data from `AgentRuntime` and is updated with the latest configuration for accurate context.
|
|
205
|
+
|
|
206
|
+
### Frequently Asked Questions
|
|
207
|
+
|
|
208
|
+
- **Q: How do I define and use a new Action?**
|
|
209
|
+
|
|
210
|
+
- **A**: Define an action object with `name`, `description`, `validate`, and `handler` functions. Integrate it into `AgentRuntime` usually by creating a plugin that registers the action. Ensure the action's name and description clearly align with its task for proper triggering.
|
|
211
|
+
|
|
212
|
+
- **Q: My action is registered, but the agent is not calling it.**
|
|
213
|
+
|
|
214
|
+
- **A**: Double-check the action's `name` and `description` for clarity and relevance to the triggering conditions. Verify that the `validate` function correctly returns `true` (or a truthy value indicating applicability) under the desired conditions. Inspect logs for any errors or warnings related to your action.
|
|
215
|
+
|
|
216
|
+
- **Q: Can Providers access external API data?**
|
|
217
|
+
|
|
218
|
+
- **A**: Yes, Providers are designed to interact with external systems, including fetching data from external APIs. This enables the agent to use real-time, dynamic context.
|
|
219
|
+
|
|
220
|
+
- **Q: How do I extend the agent's evaluation capabilities?**
|
|
221
|
+
|
|
222
|
+
- **A**: Implement custom evaluators and integrate them with `AgentRuntime` (typically via a plugin). These can be tailored to extract specific information, enhancing the agent's memory and contextual understanding.
|
|
223
|
+
|
|
224
|
+
- **Q: How can I create a mock environment for testing?**
|
|
225
|
+
- **A**: The package may include mock adapters (e.g., `MockDatabaseAdapter` if it's part of core utilities) that simulate interactions (like database connections) without actual external dependencies, facilitating controlled testing.
|
|
226
|
+
|
|
227
|
+
### Debugging Tips
|
|
228
|
+
|
|
229
|
+
- Utilize console logs (`LOG_LEVEL=debug`) for detailed error messages and execution flow during action validation and handler execution.
|
|
230
|
+
- Use mock classes/adapters where available to simulate environments and isolate functions for testing specific behaviors.
|
|
231
|
+
- Ensure `AgentRuntime` is loaded with the correct configurations and plugins.
|
|
232
|
+
|
|
233
|
+
---
|
package/dist/index.js
CHANGED
|
@@ -5352,7 +5352,6 @@ import { RecursiveCharacterTextSplitter } from "langchain/text_splitter";
|
|
|
5352
5352
|
import pkg from "stream-browserify";
|
|
5353
5353
|
import { names as names2, uniqueNamesGenerator as uniqueNamesGenerator2 } from "unique-names-generator";
|
|
5354
5354
|
import { z as z2 } from "zod";
|
|
5355
|
-
import * as pdfjsLib from "pdfjs-dist/legacy/build/pdf.mjs";
|
|
5356
5355
|
|
|
5357
5356
|
// src/logger.ts
|
|
5358
5357
|
import pino from "pino";
|
|
@@ -29742,7 +29741,6 @@ var elizaLogger = logger3;
|
|
|
29742
29741
|
var logger_default = logger3;
|
|
29743
29742
|
|
|
29744
29743
|
// src/utils.ts
|
|
29745
|
-
pdfjsLib.GlobalWorkerOptions.workerSrc = "./pdf.worker.mjs";
|
|
29746
29744
|
var { PassThrough, Readable } = pkg;
|
|
29747
29745
|
function getWavHeader(audioLength, sampleRate, channelCount = 1, bitsPerSample = 16) {
|
|
29748
29746
|
const wavHeader = Buffer2.alloc(44);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@elizaos/core",
|
|
3
|
-
"version": "1.0.0-beta.
|
|
3
|
+
"version": "1.0.0-beta.72",
|
|
4
4
|
"description": "",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -87,5 +87,5 @@
|
|
|
87
87
|
"publishConfig": {
|
|
88
88
|
"access": "public"
|
|
89
89
|
},
|
|
90
|
-
"gitHead": "
|
|
90
|
+
"gitHead": "6c367b48e9948cb4f91e0a072448f8db46a28a8e"
|
|
91
91
|
}
|