mirror of
https://github.com/aljazceru/Auto-GPT.git
synced 2026-02-19 13:14:26 +01:00
a74548d3cd
This incremental re-architecture unifies Agent code and plugins, so everything is component-based. ## Breaking changes - Removed command categories and `DISABLED_COMMAND_CATEGORIES` environment variable. Use `DISABLED_COMMANDS` environment variable to disable individual commands. - Changed `command` decorator; old-style commands are no longer supported. Implement `CommandProvider` on components instead. - Removed `CommandRegistry`, now all commands are provided by components implementing `CommandProvider`. - Removed `prompt_config` from `AgentSettings`. - Removed plugin support: old plugins will no longer be loaded and executed. - Removed `PromptScratchpad`, it was used by plugins and is no longer needed. - Changed `ThoughtProcessOutput` from tuple to pydantic `BaseModel`. ## Other changes - Created `AgentComponent`, protocols and logic to execute them. - `BaseAgent` and `Agent` is now composed of components. - Moved some logic from `BaseAgent` to `Agent`. - Moved agent features and commands to components. - Removed check if the same operation is about to be executed twice in a row. - Removed file logging from `FileManagerComponent` (formerly `AgentFileManagerMixin`) - Updated tests - Added docs See [Introduction](https://github.com/kcze/AutoGPT/blob/kpczerwinski/open-440-modular-agents/docs/content/AutoGPT/component%20agent/introduction.md) for more information.
18 lines
1.9 KiB
Markdown
18 lines
1.9 KiB
Markdown
# Component Agents
|
|
|
|
This guide explains the component-based architecture of AutoGPT agents. It's a new way of building agents that is more flexible and easier to extend. Components replace some agent's logic and plugins with a more modular and composable system.
|
|
|
|
Agent is composed of *components*, and each *component* implements a range of *protocols* (interfaces), each one providing a specific functionality, e.g. additional commands or messages. Each *protocol* is handled in a specific order, defined by the agent. This allows for a clear separation of concerns and a more modular design.
|
|
|
|
This system is simple, flexible, requires basically no configuration, and doesn't hide any data - anything can still be passed or accessed directly from or between components.
|
|
|
|
### Definitions & Guides
|
|
|
|
See [Creating Components](./creating-components.md) to get started! Or you can explore the following topics in detail:
|
|
|
|
- [🧩 Component](./components.md): a class that implements one or more *protocols*. It can be added to an agent to provide additional functionality. See what's already provided in [Built-in Components](./built-in-components.md).
|
|
- [⚙️ Protocol](./protocols.md): an interface that defines a set of methods that a component must implement. Protocols are used to group related functionality.
|
|
- [🛠️ Command](./commands.md): enable *agent* to interact with user and tools.
|
|
- [🤖 Agent](./agents.md): a class that is composed of components. It's responsible for executing pipelines and managing the components.
|
|
- **Pipeline**: a sequence of method calls on components. Pipelines are used to execute a series of actions in a specific order. As of now there's no formal class for a pipeline, it's just a sequence of method calls on components. There are two default pipelines implemented in the default agent: `propose_action` and `execute`. See [🤖 Agent](./agents.md) to learn more.
|