Lagent is a lightweight framework for building agents based on large language models (LLMs), developed by the InternLM team and open-sourced on GitHub (https://github.com/InternLM/lagent），采用 Released under the Apache 2.0 license. Its design philosophy is inspired by PyTorch, with the hope of drawing on the analogy of neural network layers to make workflows clearer and more intuitive. Users only need to focus in Python style on creating layers and defining message passing between layers to quickly build multi-agent applications.
Main capabilities and design points:
-
Models as Agents: Agents communicate with each other using AgentMessage.
-
Memory as State: On each forward pass, input and output messages are added to the Agent's memory. This operation is performed in call rather than forward. Official materials show this mechanism in pseudocode form.
-
Two ways to view memory: The materials mention that memory can be inspected, but do not elaborate on the specific code content.
-
Clear memory: The memory of the current session (default session_id=0) can be cleared.
-
Custom Message Aggregation: Under the hood, DefaultAggregator is called to assemble and convert AgentMessage into OpenAI message format. Developers can implement a simple aggregator that can receive few-shots.
-
Flexible Response Formatting: In AgentMessage, the formatted field is reserved for storing information parsed from the model output by output_format. A tool parser can be used.
-
Consistency of Tool Calling: ActionExecutor and Agent use the same communication data structure, but the content of the input AgentMessage is required to be a dictionary containing the following fields: name (tool name, for example 'IPythonInterpreter', 'WebBrowser.search'), parameters (keyword arguments for the tool API, for example {'command': 'import math;math.sqrt(2)'}, {'query': ['recent progress in AI']}). Custom message conversion can be registered.Righteousness hook. For ease of use, Lagent provides InternLMActionProcessor, which adapts to the messages formatted by the aforementioned ToolParser.
-
Dual Interfaces: Almost every component (LLM, action, action executor, etc.) has a corresponding asynchronous variant, with the identifier prefix 'Async'. It is recommended to use synchronous agents when debugging and asynchronous agents for large-scale inference, so as to fully utilize idle CPU and GPU resources. However, internal consistency of the agent must be ensured, that is, an asynchronous agent should be paired with an asynchronous LLM and an asynchronous action executor that drives asynchronous tools. Unless necessary, one should implement the subclass's forward rather than call as much as possible; and always explicitly include the session_id parameter, which is used to isolate memory, LLM requests, and tool calls during concurrency (for example, maintaining multiple independent IPython environments).
Example applications (listed in the materials):
- Math agents that solve problems by programming.
- Multi-agent: an asynchronous blog agent that improves writing quality through self-refinement (the original AutoGen example).
- Multi-agent workflow: performing information retrieval, data collection, and chart plotting (the original LangGraph example).
Installation method: Install from source; the materials do not provide specific installation commands.
Applicable scenarios: research and development scenarios that require building LLM agents, multi-agent collaboration, tool calling, and asynchronous large-scale inference in a Python way.
Limitations: the materials do not specify specific platform compatibility, dependency versions, charging methods, or performance metrics; some mechanisms (such as the two ways of viewing memory, and the specific calls for clearing memory) are only mentioned as existing but are not given with complete code; the installation commands are not provided in the materials.
