内容摘录
Embabel Agent Framework
<img align="left" src="https://github.com/embabel/embabel-agent/blob/main/embabel-agent-api/images/315px-Meister_der_Weltenchronik_001.jpg?raw=true" width="180">
Docs
!Build
YourKit
JProfiler
Quality Gate Status
Discord
[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
[//]: # ([](https://sonarcloud.io/summary/new_code?id=embabel_embabel-agent))
!Kotlin
!Java
!Spring
!Spring Boot
!Apache Tomcat
!Apache Maven
!JUnit
!ChatGPT
!Jinja
!JSON
!GitHub Actions
!SonarQube
!Docker
!IntelliJ IDEA
License
Commits
Embabel (Em-BAY-bel) is a framework for authoring agentic flows on the JVM that seamlessly mix LLM-prompted interactions
with code and domain models. Supports
intelligent path finding towards goals. Written in Kotlin
but offers a natural usage
model from Java.
From the creator of Spring.
Key Concepts
Models agentic flows in terms of:
**Actions**: Steps an agent takes
**Goals**: What an agent is trying to achieve
**Conditions**: Conditions to assess before executing an action or determining that a goal has been achieved.
Conditions are reassessed after each action is executed.
**Domain model**: Objects underpinning the flow and informing Actions, Goals and Conditions.
**Plan**: A sequence of actions to achieve a goal. Plans are dynamically formulated by the system, not the programmer.
The
system replans after the completion of each action, allowing it to adapt to new information as well as observe the
effects of the previous action.
This is effectively an OODA loop.
Application developers don't usually have to deal with these concepts directly,
as most conditions result from data flow defined in code, allowing the system to infer
pre and post conditions.
These concepts underpin these differentiators versus other agent frameworks:
**Sophisticated planning.** Goes beyond a finite state machine or sequential execution
with nesting by introducing a true planning step, using a
non-LLM AI algorithm. This enables the system to perform tasks it wasn’t programmed to do by combining known
steps in
a novel order, as well as make decisions about parallelization and other runtime behavior.
**Superior extensibility and reuse**: Because of dynamic planning, adding more domain objects, actions, goals and
conditions
can extend the capability of the system, _without editing FSM definitions_ or existing code.
**Strong typing and the benefits of object orientation**: Actions, goals and conditions are informed by a domain
model, which can
include behavior. Everything is strongly typed and prompts and
manually authored code interact cleanly. No more magic maps. Enjoy full refactoring support.
Other benefits:
**Platform abstraction**: Clean separation between programming model and platform internals allows running locally
while
potentially offering higher QoS in production without changing application code.
**Designed for LLM mixing**: It is easy to build applications that mix LLMs, ensuring the most cost-effective yet
capable solution.
This enables the system to leverage the strengths of different models for different tasks. In particular, it
facilitates
the use of local models for point tasks. This can be important for cost and privacy.
**Built on Spring and the JVM,** making it easy to access existing enterprise functionality and capabilities.
For example:
Spring can inject and manage agents, including using Spring AOP to decorate functions.
Robust persistence and transaction management solutions are available.
**Designed for testability** from the ground up. Both unit testing and agent end to end testing are easy.
Flows can be authored in one of two ways:
An annotation-based model similar to Spring MVC, with types annotated with the Spring stereotype @Agent, using
@Goal, @Condition and
@Action methods.
Idiomatic Kotlin DSL with agent { and action { blocks.
Either way, flows are backed by a domain model of objects that can have rich behavior.
We are working toward allowing natural language actions and goals to be deployed.
The planning step is pluggable.
The default planning approach is
Goal Oriented Action Planning.
GOAP is a popular AI planning algorithm used in gaming. It allows for dynamic decision-making and action selection based
on the current state of the world and the goals of the agent.
Goals, actions and plans are independent of GOAP. Embabel also
supports Utility AI out of the box, which can run the same actions but
chooses actions
based on (potentially dynamic) utility scores rather than strict preconditions and postconditions. This is valuable for
exploration and
open-ended tasks, when we do not need to achieve a specific goal but want to maximize overall utility.
The framework executes via an AgentPlatform implementation.
An agent platform supports the following modes of execution:
**Focused**, where user code requests particular functionality: User code calls a method to run a particular agent,
passing in input. This is ideal for code-driven flows such as a flow invoked in response to an incoming event.
**Closed**, where user intent (or another incoming event) is classified to choose an agent. The platform tries to
find a
suitable agent among all the agents it knows about.
Agent choice is dynamic, but only actions defined within the particular agent
will run.
**Open**, where the user's intent is assessed and the platform uses _all_ its resources to try to achieve it. The
platform tries to find a
suitable goal among all the goals it knows about and builds a custom agent to achieve it from the start state,
including relevant actions and conditions. The platform will not pr…