Lagent Lightweight Agent Framework
A lightweight framework for building LLM-based agents, inspired by PyTorch's design philosophy.
- Source repo
- InternLM/lagent
- Stars
- ★ 2.3k
- Last updated
- 6mo ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 43/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformOpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Developers needing to quickly build an agent that solves math problems by writing and executing Python code.
- Not a fit if
- Users who want a ready-made GUI or chat bot
- Teams without GPUs or local model serving resources
- Source review
- 43/100 · Major gaps 4 safety controls not found
What does this agent do, and when should you use it?
Lagent is a lightweight framework for building LLM-based agents, inspired by PyTorch's design philosophy of layers and message passing. It provides an Agent class that communicates via AgentMessage, enabling intuitive workflow construction. The framework supports various LLM backends (e.g., VllmModel, GPTAPI, AsyncGPTAPI) and tools (e.g., IPythonInterpreter, WebBrowser), with synchronous and asynchronous interfaces. Key features include memory management, custom aggregators, flexible output formatting (ToolParser), and tool invocation via ActionExecutor. Installation is straightforward via pip, and examples cover math problem solving, multi-agent blogging, and data visualization. Licensed under Apache-2.0.
Lagent allows users to build agents by defining Agent instances and passing AgentMessage. It supports multiple LLM providers (e.g., VllmModel, GPTAPI) and integrates tools like IPythonInterpreter and WebBrowser. The core flow: Agent receives messages, maintains context via memory, formats messages using an aggregator, calls the LLM for a response, and optionally executes tool calls via ActionExecutor. It provides synchronous and asynchronous variants (e.g., AsyncAgent) and allows custom aggregators, output parsers, and hooks.
- Developers needing to quickly build an agent that solves math problems by writing and executing Python code.
- Teams aiming to implement multi-agent collaboration, such as a writer and critic improving a blog post.
- Researchers requiring web search, data collection, and chart plotting for a data-to-visualization pipeline.
- Projects needing a unified interface across multiple LLM providers.
- Developers wanting to leverage asynchronous execution for large-scale inference to maximize resource utilization.
How do you install or deploy this agent?
Install from source:\n``bash\ngit clone https://github.com/InternLM/lagent.git\ncd lagent\npip install -e .\n``
How do you use this agent?
After installation, you can create an LLM instance (e.g., VllmModel) and an Agent, then pass user messages to get responses. For example:\n``python\nfrom lagent.llms import VllmModel\nfrom lagent.agents import Agent\nfrom lagent.schema import AgentMessage\n\nllm = VllmModel(path='Qwen/Qwen2-7B-Instruct')\nagent = Agent(llm)\nuser_msg = AgentMessage(sender='user', content='What is the weather today?')\nbot_msg = agent(user_msg)\nprint(bot_msg)\n``\nFor tool use, define an ActionExecutor with hooks to execute code.
What are this agent's strengths and limitations?
- PyTorch-like design philosophy makes it easy to understand and extend.
- Supports multiple LLM backends (Vllm, GPTAPI) and tools (IPython, WebBrowser).
- Provides synchronous and asynchronous interfaces for different scale requirements.
- Flexible aggregators and parsers allow customization of message formats and tool usage.
- Requires users to have some Python and LLM knowledge.
- Documentation may be limited; users may need to rely on examples.
- Depends on external LLM APIs or local model serving, requiring API keys or hardware resources.
- Async usage requires ensuring component consistency, adding configuration complexity.
How does this agent compare with similar options?
Similar to AutoGen and LangGraph, but Lagent is lighter and emphasizes a PyTorch-style design with more intuitive layer and message passing concepts.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Lagent Lightweight Agent Framework This agent | 43 · Major gaps | Library / SDKFree + model costs | ★ 2.3k | 6mo ago | Python | OpenAI API |
| ConnectOnion AI Agent Framework | 47 · Major gaps | CLIFree + model costs | ★ 1.5k | today | Python | OpenAI API · Claude API |
| Hello-Agents | 54 · Major gaps | Web appFree + model costs | ★ 84k | 5d ago | Python | OpenAI API |
| AgentVerse | 28 · Major gaps | CLIFree + model costs | ★ 5.2k | 2y ago | JavaScript | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows the framework provides hook mechanisms (e.g., CodeProcessor) allowing message modification before/after actions, but least privilege is not enforced; default actions like IPythonInteractive can execute arbitrary code, which is excessive. User confirmation mechanism is absent; tool calls execute automatically. Data flow transparency is partial: AgentMessage structure is clear, but it is not explained how data is processed by external services. Sensitive data handling is not mentioned. Dependency security is not assessed; requirements.txt only lists files without version pinning or vulnerability scanning. External effects: actions like WebBrowser can make network requests, but no sandbox or restrictions are provided. Rollback mechanism is not mentioned. Source attribution: README and citation provide author info, but publisher is unverified.
Self-consistency: README examples are consistent with API docs, but not verified by execution. Dependency availability: dependencies are not version-pinned, which may affect reproducibility. Failure messages: tests cover API errors and timeouts, but not all scenarios.
Audience and scenarios: README provides single-agent and multi-agent examples covering various scenarios. Capability boundaries: documentation explains tool calling and async interfaces, but does not specify limitations. Trigger precision: tool invocation format is clear, but not verified. Environment fit: supports sync and async, but does not specify all environment requirements.
Information architecture: README is well-structured with TOC and examples. Install notes: provides source installation command. Naming stability: API naming is consistent, but no version history. Examples and FAQ: rich examples, but no FAQ. Known limitations: not mentioned. License: Apache-2.0 complete. Versioning changelog: not provided. Maintenance responsibility: contributor info exists, but no explicit maintenance policy.
Output usability: example outputs are clear, but not verified. Marginal value: provides multi-agent framework with unique value. Cost-benefit: no performance or resource consumption data.
Claim traceability: README examples can be traced to code, but not verified. Cross-source corroboration: no external verification. Fact-inference separation: examples and inferences are mixed, not clearly separated.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: sensitive-data handlingUse dedicated, low-privilege, revocable API keys — never production credentials — and keep secrets out of logs.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- Default actions like IPythonInteractive can execute arbitrary code, posing security risks; consider restricting permissions or adding user confirmation.
- Dependencies are not version-pinned, which may introduce incompatibilities or vulnerabilities; consider locking versions and regular scanning.
- Known limitations and changelog are not provided, making it hard for users to assess risks.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
What's Changed * Update runtime.txt add tenacity by @vansin in https://github.com/InternLM/lagent/pull/280 * Fixed the search API of AsyncDDGS by @braisedpork1964 in https://github.com/InternLM/lagent/pull/281 * [Model] support Claude by @Harold-lkk in https://github.com/InternLM/lagent/pull/283 * fix anthropic by @Harold-lkk in https://github.com/InternLM/lagent/pull/284 * support o1 and claude by @Harold-lkk in https://github.com/InternLM/lagent/pull/285 * Add do_sample in AsyncLMDeployPipeline (lmdeploy_wrapper.py) by @shinkungoo in https://github.com/InternLM/lagent/pull/290 …View on GitHub ↗ -
v0.5.0rc2 V0.5.0rc2
Release notes excerpt
What's Changed * Update dependencies by @braisedpork1964 in https://github.com/InternLM/lagent/pull/268 * [Feat] Add Sequential and AsyncSequential agents by @braisedpork1964 in https://github.com/InternLM/lagent/pull/270 * [Fix] Alternative for aioify by @braisedpork1964 in https://github.com/InternLM/lagent/pull/274 * [Feat] Support resetting agent memory recursively or by keypath by @braisedpork1964 in https://github.com/InternLM/lagent/pull/271 * Fix: http agent server by @liujiangning30 in https://github.com/InternLM/lagent/pull/276 …View on GitHub ↗