aljaz/Auto-GPT
1
0
Fork 0
mirror of https://github.com/aljazceru/Auto-GPT.git synced 2025-12-17 22:14:28 +01:00
Code Issues Packages Projects Releases Wiki Activity
Files
a74548d3cd1ff57bdca13afd5d5281bf972d566c
Auto-GPT/docs/content/AutoGPT/component agent/introduction.md
Krzysztof Czerwinski a74548d3cd feat(agent): Component-based Agents (#7054) 
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.
2024-04-22 19:20:01 +02:00

1.9 KiB
Raw Blame History

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 to get started! Or you can explore the following topics in detail:

  • 🧩 Component: 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.
  • ⚙️ Protocol: an interface that defines a set of methods that a component must implement. Protocols are used to group related functionality.
  • 🛠️ Command: enable agent to interact with user and tools.
  • 🤖 Agent: 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 to learn more.