6.1 From Manual Implementation to Framework Development

Moving from writing one-time scripts to using a mature framework is an important mental leap in the field of software engineering. The code we wrote in Chapter 4 was primarily for teaching and understanding purposes. They can complete specific tasks well, but if we want to use them to build multiple, different types of agents with complex logic, we will soon encounter bottlenecks.

The essence of a framework is to provide a set of validated "specifications." It abstracts and encapsulates all the repetitive work common to all agents (such as main loops, state management, tool invocation, logging, etc.), allowing us to focus on their unique business logic when building new agents, rather than general underlying implementations.

6.1.1 Why Agent Frameworks Are Needed

Before we start the practical work, we first need to clarify why we should use frameworks. Compared to directly writing independent agent scripts, the value of using frameworks is mainly reflected in the following aspects:

1. Improve Code Reuse and Development Efficiency: This is the most direct value. A good framework will provide a general Agent base class or executor that encapsulates the core loop of agent operation (Agent Loop). Whether it's ReAct or Plan-and-Solve, they can be quickly built based on standard components provided by the framework, thus avoiding repetitive work.
2. Achieve Decoupling and Extensibility of Core Components: A robust agent system should consist of multiple loosely coupled modules. The framework's design will force us to separate different concerns:
   • Model Layer: Responsible for interacting with large language models, can easily replace different models (OpenAI, Anthropic, local models).
   • Tool Layer: Provides standardized tool definition, registration, and execution interfaces; adding new tools will not affect other code.
   • Memory Layer: Handles short-term and long-term memory, can switch different memory strategies according to needs (such as sliding window, summary memory). This modular design makes the entire system highly extensible, making it simple to replace or upgrade any component.
3. Standardize Complex State Management: The Memory class we implemented in ReflectionAgent is just a simple start. In real, long-running agent applications, state management is a huge challenge that needs to handle context window limitations, historical information persistence, multi-turn conversation state tracking, and other issues. A framework can provide a powerful and general state management mechanism, so developers don't have to deal with these complex issues every time.
4. Simplify Observability and Debugging Process: When agent behavior becomes complex, understanding its decision-making process becomes crucial. A well-designed framework can have built-in powerful observability capabilities. For example, by introducing an event callback mechanism (Callbacks), we can automatically trigger logging or data reporting at key nodes in the agent lifecycle (such as on_llm_start, on_tool_end, on_agent_finish), making it easy to track and debug the complete running trajectory of the agent. This is far more efficient and systematic than manually adding print statements in code.

Therefore, moving from manual implementation to framework development is not only a change in code organization, but also the necessary path to building complex, reliable, and maintainable agent applications.

6.1.2 Selection and Comparison of Mainstream Frameworks

The ecosystem of agent frameworks is developing at an unprecedented speed. If LangChain and LlamaIndex defined the paradigm of the first generation of general LLM application frameworks, then the new generation of frameworks is more focused on solving deep challenges in specific domains, especially Multi-Agent Collaboration and Complex Workflow Control.

In the subsequent practical work of this chapter, we will focus on four frameworks that are highly representative in these cutting-edge fields: AutoGen, AgentScope, CAMEL, and LangGraph. Their design philosophies are different, representing different technical paths for implementing complex agent systems, as shown in Table 6.1.

Table 6.1 Comparison of Four Agent Frameworks

• AutoGen: The core idea of AutoGen is to achieve collaboration through conversation^[1]. It abstracts multi-agent systems as a group chat composed of multiple "conversable" agents. Developers can define different roles (such as Coder, ProductManager, Tester) and set interaction rules between them (for example, after Coder finishes writing code, Tester automatically takes over). The task-solving process is the process where these agents continuously converse, collaborate, and iterate in the group chat through automated message passing until the final goal is achieved.
• AgentScope: AgentScope is a fully functional development platform designed specifically for multi-agent applications^[2]. Its core features are ease of use and engineering. It provides a very friendly programming interface that allows developers to easily define agents, build communication networks, and manage the entire application lifecycle. Its built-in message passing mechanism and support for distributed deployment make it very suitable for building and operating complex, large-scale multi-agent systems.
• CAMEL: CAMEL provides a novel collaboration method called Role-Playing^[3]. Its core concept is that we only need to set the respective roles and common task goals for two agents (for example, AI Researcher and Python Programmer), and they can autonomously conduct multiple rounds of dialogue under the guidance of "Inception Prompting," inspiring and cooperating with each other to complete tasks together. It greatly reduces the complexity of designing multi-agent dialogue processes.
• LangGraph: As an extension of the LangChain ecosystem, LangGraph takes a different approach by modeling the agent's execution process as a Graph^[4]. In traditional chain structures, information can only flow in one direction. LangGraph defines each operation (such as calling LLM, executing tools) as a Node in the graph and uses Edges to define the jump logic between nodes. This design naturally supports Cycles, making it exceptionally simple and intuitive to implement complex workflows such as Reflection that involve iteration, correction, and self-reflection.

In the following sections, we will deeply experience the framework-driven development model through a complete practical case for each of these four frameworks. Please note that all demonstrated project source files will be placed in the code folder, and only the principle part will be explained in the main text.