In-depth analysis of 7 Agent design patterns
From thinking chains to multi-agent collaboration, understanding these cognitive frameworks will lead to understanding the "thinking model library" of the Agent world.
These modes are not mutually exclusive and are often mixed and matched in actual development. Understanding them allows us to think more thoroughly when selecting frameworks (LangChain, LangChain4j, LlamaIndex, Dify, Spring AI Alibaba, etc.) and architecture design.

Panoramic overview
mindmap
root((Agent design pattern))
CoT Thought chain
Write the reasoning process step by step
Google Research 2022
Self-Ask Ask and answer yourself
Break down big problems into small ones
Microsoft Research 2022
ReAct reasoning+action
Alternate thinking and tool invocation
Princeton & Google 2022
Plan-and-Execute Planning and Execution
Plan first and then execute step by step
LangChain Community 2023
Tree of Thoughts tree thinking
Multi-branch exploration and selection
Princeton & DeepMind 2023
Reflexion Reflection and iteration
Correct yourself after making a mistake
2023
Role-playing role play
Multi-agent division of labor and collaboration
AutoGPT / ChatDev / CAMEL
The core differences of the seven modes can be quickly perceived with a table:
| model | One sentence summary | core competencies | Typical scenario |
|---|---|---|---|
| CoT | Step by step writing process | linear reasoning | Mathematical calculations, logical reasoning |
| Self-Ask | Break it into small problems | Problem decomposition | Multi-hop fact retrieval |
| ReAct | Both thinking and doing | Reasoning + Tool Calling | Real-time information query, API call |
| Plan-and-Execute | Plan first and then execute | mission planning | Multi-step long task |
| ToT | Tree-like multi-branch exploration | Search + Evaluate | Puzzle solving, complex planning |
| Reflexion | Self-reflective iteration | self-correction | Code generation, process execution |
| Role-playing | Multi-person collaboration and division of labor | Multi-agent collaboration | Software development, cross-functional collaboration |
1. Chain of Thought (CoT)
present background
Google Research published a paper "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" in 2022, which systematically proposed for the first time that by guiding the large language model to display the reasoning process step by step before giving the final answer, the performance of the model on complex reasoning tasks can be significantly improved.
core idea
In the traditional prompting method, the model is required to give answers directly - "report the results in one breath". This is no problem for simple questions, but when faced with tasks that require multi-step reasoning (mathematical calculations, logical derivation, causal analysis), giving answers directly often leads to "step skipping" and errors.
The core insights of CoT are:The reasoning process itself is a kind of "thinking scaffolding". When the model is asked to explicitly write out the intermediate reasoning steps, the output of each step will be used as context input for the next step, which is equivalent to asking the model to calculate on a "scratch paper" instead of doing mental calculations. This "explicitness" brings three benefits:
- Reduce the burden of single-step reasoning: The model does not need to complete all reasoning in one forward pass, but splits complex reasoning into multiple simple steps, and only needs to do a small piece of reasoning for each step.
- Provide a traceable chain of reasoning: If the final answer is wrong, you can trace back to the specific step where the problem occurred, which is convenient for debugging and improvement.
- Stimulate the potential reasoning ability of the model: Large models have learned a lot of reasoning knowledge in the pre-training stage, and CoT provides an "activation" mechanism to release these capabilities.
There are two main variants of CoT:Zero-shot CoT(Add "Let's think step by step" directly to the end of prompt) and Few-shot CoT(An example with reasoning process is given in prompt). The former is simple and crude, while the latter is more stable.
flow chart
flowchart LR
A[User questions] --> B[The model starts inference]
B --> C[step1: Understanding the problem<br/>Extract known conditions]
C --> D[step2: Set variables<br/>build relationships]
D --> E[step3: Calculate step by step<br/>Derivation of intermediate results]
E --> F[step4: Verification results<br/>get the final answer]
F --> G[output answer + reasoning process]
style A fill:#e1f5fe,stroke:#0288d1
style G fill:#c8e6c9,stroke:#388e3c
style C fill:#fff9c4,stroke:#f9a825
style D fill:#fff9c4,stroke:#f9a825
style E fill:#fff9c4,stroke:#f9a825
style F fill:#fff9c4,stroke:#f9a825
Scenario example
question: Xiao Ming purchased a 3.8 kilogram package online. The express company charges 10 yuan for the first 1 kilogram, and 3 yuan per kilogram for additional weights. If the package is less than 1 kilogram, it will be calculated as 1 kilogram. How much does Xiao Ming need to pay for express delivery?
CoT reasoning process:
Step 1: Confirm the weight of the package → 3.8 Kilogram
Step 2: Calculate billing weight → insufficient 1 kilogram 1 Calculated in kilograms → 4 Kilogram
Step 3: Separate the first weight and the additional weight → top priority 1 Kilogram = 10 Yuan
Step 4: Calculate the additional weight → 4 - 1 = 3 Kilogram
Step 5: Calculate the re-weighting fee → 3 × 3 = 9 Yuan
Step 6: Add up the costs → 10 + 9 = 19 Yuan
Answer: Xiao Ming needs to pay 19 Yuan express fee.
Each step of reasoning is written out explicitly. If the model directly reports the answer "19 yuan", you can't tell whether it can really calculate or guess. But with the inference chain, you can see that it has done the correct upward rounding in the step of "counting as 1 kg if it is less than 1 kg", and the idea is completely traceable.
Applicable business scenarios
- Mathematical Computation and Numerical Reasoning: Scenarios involving multi-step operations in financial statement analysis, investment income calculation, and risk assessment models. The model needs to first extract parameters, then establish formulas, and finally solve. CoT makes every step auditable.
- Logical reasoning and decision analysis: In the risk control rule engine and compliance review process, it is necessary to gradually derive conclusions based on multiple rules. For example, "If the user meets condition A and does not meet condition B, then trigger rule C."
- Analyze problems step by step: In assisted medical diagnosis, diseases are gradually eliminated based on symptoms, in legal reasoning, conclusions are gradually derived based on legal provisions, and in technical troubleshooting, root causes are gradually located based on phenomena.
- Education and training: In the AI tutoring system, it not only gives answers, but also shows the problem-solving process to help students understand the reasoning path.
Applicable systems and integration solutions
Compatible system type:
- Intelligent reporting and financial analysis system: The report does not just show numbers, but shows "how these numbers came about." When users click on any indicator, they can see the complete reasoning chain from the original voucher to the final report.
- Risk control decision engine: For every loan approval and every anti-fraud determination, the system is bound to a reasoning chain, and auditors can trace back "why this application was rejected" one by one.
- AI tutoring and online education platform: When a student makes a wrong question, he or she not only sees "the correct answer is C", but follows the systematic reasoning steps to understand "how to derive the answer to this question step by step."
- Medical auxiliary diagnosis system: After entering the symptoms, the system not only gives "possibly XX disease", but also displays the complete derivation of "from symptoms → differential exclusion → most likely diagnosis".
System integration method:
flowchart LR
A[raw data] --> B[CoT inference engine]
B --> C[Reasoning chain storage]
B --> D[Conclusion output]
C --> E[audit / Traceability interface]
D --> F[Front-end display: in conclusion + reasoning process]
style B fill:#fff9c4,stroke:#f9a825
style C fill:#f3e5f5,stroke:#7b1fa2
Integration points:
- Embedded in decision-making processes rather than stand-alone modules: CoT is not a separate "inference service", but is embedded in every decision-making node of report query, risk control approval, and diagnostic analysis. The user requests an analysis → the system returns not only conclusions but also structured fields
reasoning_chain. - The reasoning chain must be stored in a structured way:Save the inference steps as
[{step: 1, thought: "...", result: "..."}, ...]Format, the front end can expand/collapse each step, and can be traced back one by one during audit. - Coexists with existing rules engines: CoT does not replace the existing rule engine, but complements it - the rule engine is responsible for fast hard judgments (such as "direct rejection if the amount exceeds the limit"), and CoT is responsible for fuzzy reasoning (such as "this transaction pattern looks suspicious, explain why").
2. Self-Ask (self-ask and answer)
present background
Microsoft Research proposed the Self-Ask method in the 2022 research work "Measuring and Narrowing the Compositionality Gap in Language Models" (the paper is titled Self-Ask with Search). The researchers found that when questions require the combination of multiple facts to answer (i.e., "combinatorial questions"), the model's performance drops dramatically—even if the model knows each individual fact, it cannot correctly combine them.
core idea
Self-Ask solves the problem of Compositionality Gap. The so-called combinatorial gap means that the model can answer each sub-question correctly, but when these sub-questions are combined into a large question, the accuracy of the model is much lower than the product of the accuracy of each sub-question.
Self-Ask’s strategy is:Let the model learn to "question yourself". When faced with a complex problem, the model does not try to answer it in one step. Instead, it first determines "What do I need to know first to answer this question?", then breaks the big question into a series of follow-up questions, answers them one by one, and then combines them into the final answer.
The key difference from CoT is that CoT is a linear chain of reasoning - each step is a natural extension of the previous step; Self-Ask isProblem decomposition——Split a question that requires multi-hop reasoning into multiple independent sub-questions, and each sub-question can be queried and answered independently. More importantly, Self-Ask is usually used in conjunction with external retrieval (such as search engines): every time a follow-up question is asked, the answer is retrieved, and then the next question is raised based on the retrieval results.
This model is particularly suitable forlong fact linkThe question - the answer requires concatenating multiple facts, each of which may not be in the model's training data.
flow chart
flowchart TD
A[Users ask complex questions] --> B{Is it necessary<br/>break down?}
B -->|yes| C[Generate follow-up questions1]
C --> D[Search/Answer follow-up questions1]
D --> E{Do you still need<br/>More information?}
E -->|yes| F[Generate follow-up questions2]
F --> G[Search/Answer follow-up questions2]
G --> H{Do you still need<br/>More information?}
E -->|no| I[Combine all sub-answers]
H -->|no| I
I --> J[output final answer]
style A fill:#e1f5fe,stroke:#0288d1
style J fill:#c8e6c9,stroke:#388e3c
style C fill:#fff3e0,stroke:#ef6c00
style F fill:#fff3e0,stroke:#ef6c00
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#f3e5f5,stroke:#7b1fa2
Scenario example
question: What is the market value of Elon Musk’s first company now?
Self-Ask process:
Q: What was the first company founded by Elon Musk??
→ Search results: 1996 In 2006, Musk co-founded the company with his brother Kimbal Musk Zip2,
A company that provides online city guides and business directories for newspapers.
Ask: Zip2 What happened to the company? Is it still on the market now??
→ Search results: 1999 Compaq(Compaq)By appointment 3.07 Acquired for US$100 million Zip2,
Later integrated into Compaq's AltaVista In business, it is no longer an independent company.
Follow-up question (adjust direction): Now that it has been acquired, what was its value when it was acquired??
→ Search results: Zip2 by Compaq 3.07 Acquisition worth US$100 million, of which Musk received approximately 2200 million dollars.
Combined answer: Musk’s first company Zip2 There is currently no independent listing,
1999 Appointed by Compaq 3.07 US$100 million acquisition.
This example shows the flexibility of Self-Ask - when the first inquiry found that "Zip2 is no longer an independent company", the model did not continue to ask about "market value" rigidly, but dynamically adjusted the direction of inquiry to check "value when acquired". This is the advantage of Self-Ask compared to a fixed process: it can flexibly generate the next query based on the search results of each step, rather than a hard-coded query pipeline.
Applicable business scenarios
- Multi-hop knowledge Q&A: In enterprise knowledge bases, user questions often require concatenating information from multiple documents. For example, "What was the product line with the highest revenue in our company's East China region in Q4 last year? What is its profit margin?" You need to check the revenue data first, then position the product line, and finally check the profit margin.
- Information retrieval with long fact links: Competitive product analysis requires multi-hop queries such as "Who is the parent company of competing product A → What does the parent company's latest financial report say → What is the strategic direction mentioned in the financial report?"
- Compliance and due diligence: In background investigations and due diligence, it is necessary to connect multi-source data such as industrial and commercial information, judicial information, and related relationships. Self-Ask can automatically disassemble the query path.
- Customer service and intelligent Q&A: Users ask "When will my order arrive?" They need to first check the order number → check the logistics status → check the estimated delivery time. Self-Ask can automatically complete this disassembly.
Applicable systems and integration solutions
Compatible system type:
- Enterprise intelligent customer service system: The user asks "When will my order arrive?" → Self-Ask is automatically broken down into "Check order number → Check logistics → Calculate estimated delivery". It is no longer just a keyword-matching FAQ answer, but a true understanding of the user's compound query needs.
- Enterprise knowledge base Q&A platform: Knowledge is scattered in multiple document libraries, Wikis, and rules and regulations. Self-Ask splits complex questions into multiple sub-questions, retrieves different knowledge sources separately and then synthesizes the answer, solving the dilemma of "the answer to a question is hidden in three documents".
- Compliance and Due Diligence System: Enter a company name → Automatically decompose it into four sub-queries: "Industrial and Commercial Information → Judicial Risk → Related Relationships → Public Opinion", and call Tianyancha, Judgment Documents, Enterprise Chacha and other interfaces in parallel, and finally summarize it into a due diligence summary.
- Competitive product intelligence analysis platform: Enter "Latest developments of competing product
System integration method:
flowchart TD
A[User questions] --> B[Self-Ask problem decomposer]
B --> C1[subproblem 1: Check order]
B --> C2[subproblem 2: Check Logistics]
B --> C3[subproblem 3: Estimated time]
C1 --> D1[Order system API]
C2 --> D2[Logistics inquiry API]
C3 --> D3[Timeliness calculation engine]
D1 --> E[answer synthesizer]
D2 --> E
D3 --> E
E --> F[final answer]
style B fill:#fff3e0,stroke:#ef6c00
style E fill:#f3e5f5,stroke:#7b1fa2
style F fill:#c8e6c9,stroke:#388e3c
Integration points:
- Subproblem and data source mapping: Maintain a mapping table of "Problem Type → Data Source" in the system. Each sub-question decomposed by Self-Ask is labeled with a type, and the scheduler routes the sub-question to the corresponding business API or search engine based on the type.
- The answer is synthesis, not building blocks: The synthesizer does not simply put together sub-answers, but does "duplication removal, conflict resolution, and information completion." For example, sub-problem A says "Zip2 has a market value of 0", sub-problem B says "Zip2 has been acquired", and the synthesizer needs to output "Zip2 no longer has an independent market value and was valued at US$307 million when it was acquired".
- Progressive rendering improves experience: There is no need to wait for all sub-questions to be answered during front-end display. The answer to each sub-question is pushed in real time - what the user sees is "Checking your order number... ✅ Found → Checking logistics... ✅ On the way → Estimated delivery at 3pm tomorrow". The experience is much better than "turning in circles for 5 seconds and then getting the result".
3. ReAct (reasoning + action)
present background
Princeton University and Google Research jointly published the paper "ReAct: Synergizing Reasoning and Acting in Language Models" in 2022, proposing the ReAct framework. This is one of the most influential papers in the Agent field and is still the underlying paradigm for most Agent frameworks.
core idea
Before ReAct, CoT and Self-Ask mainly solved the "what to think" problem, but they had a common limitation:The model can only reason based on the knowledge stored in its own parameters and cannot interact with the external world.. If the model does not know a fact, or if the fact has changed (such as real-time weather, latest news), pure inference mode cannot help.
The core innovations of ReAct are:Let the model alternate between Reasoning and Acting. Specifically, the model does two things at each step:
- Thought: The model reasons about the current state and decides what to do next. For example, "The user asked about yesterday's weather in Hangzhou. I don't know this information and need to call the weather API to query."
- Action: The model performs a specific action, such as calling a search engine, querying a database, or calling an API. The results of the action are fed back to the model as new observations.
- Observation: The model receives the return result of the action and performs the next round of thinking based on this new information.
This Thought → Action → Observation cycle can be repeated until the model feels it has collected enough information to answer the question.
The fundamental reasons why ReAct is more versatile than CoT and Self-Ask are:It is not only a reasoning mode, but also has a built-in closed loop for interaction with the external world.. CoT can only "think", Self-Ask can "check" but the process is relatively fixed, while ReAct can dynamically adjust subsequent strategies based on feedback from each action - if the search results are not satisfactory, it can search again with a different keyword; if the API returns an error, it can analyze the error and try to fix it.
It is this closed loop of "thinking-action-observation" that makes ReAct the default execution paradigm of current mainstream Agent frameworks (LangChain, LangChain4j, LlamaIndex, Dify, Spring AI Alibaba, etc.).
flow chart
flowchart TD
A[User input issues] --> B[Thought: Analyze the problem<br/>Determine what information is needed]
B --> C{Does it already exist<br/>enough information?}
C -->|yes| D[generate final answer]
C -->|no| E[Action: Select and call tools<br/>search/QueryAPI/Read database]
E --> F[Observation: Get the results returned by the tool]
F --> B
style A fill:#e1f5fe,stroke:#0288d1
style D fill:#c8e6c9,stroke:#388e3c
style B fill:#fff9c4,stroke:#f9a825
style E fill:#ffcdd2,stroke:#c62828
style F fill:#f3e5f5,stroke:#7b1fa2
Scenario example
question: Help me check the current air quality in Beijing. If it is not suitable for outdoor activities, help me recommend some good indoor places.
ReAct execution process:
Thought: The user wants to know the current air quality in Beijing. I need to call weather/air quality API
Obtain real-time data that cannot be found online"Now"data.
Action: Call the air quality query tool
→ parameter: city=Beijing
Observation: Beijing current AQI 172, PM2.5 125μg/m³, belong"moderate pollution".
It is recommended to reduce outdoor activities and sensitive people should avoid going out..
Thought: AQI 172 Moderate pollution, really not suitable for outdoor activities. Need to recommend indoor places to users.
But I don’t know any good indoor places in Beijing. I need to search for them..
Action: search"Recommended indoor activities in Beijing: business districts, museums, shopping malls"
→ call search engine
Observation: Search results show——
1. Taikoo Li Sanlitun (shopping+FOOD)
2. National Museum of China (free reservation to visit))
3. 798 Art District Indoor Exhibition Hall (Contemporary Art Exhibition)
4. Hop Sheng Hui (shopping mall+Indoor go-kart)
5. Wangfujing APM(Shopping+Cinema)
Thought: Enough information is now available. Combined with air quality data(AQI 172 moderate pollution)
and indoor destination recommendations, you can give users a comprehensive reply..
Final Answer: Beijing’s current air quality is moderately polluted(AQI 172, PM2.5 125μg/m³),
Not really suitable for outdoor activities. Here are some recommended indoor places:
① National Museum of China - free but requires reservation in advance, directly accessible by subway
② 798 Indoor exhibition hall in the art district - multiple contemporary art exhibitions are being held
③ Taikoo Li Sanlitun/Wangfujing APM——Eat and watch movies all in one package
④ Hop Sheng Hui - There is an indoor go-kart, suitable for friends who want to get active
Remember to wear a mask when going out!
This example demonstrates the core value of ReAct: the model goes beyond "thinking" - it actively calls tools to obtain real real-time data, and dynamically adjusts follow-up actions based on the results returned by the tools (poor air quality → move indoors). The entire process is a complete "perception-decision-action" closed loop.
Applicable business scenarios
- Real-time information query and decision-making: Any scenario that requires the latest data - stock quotes query, weather query, news summary, flight status query. The model "knows" that it does not know the real-time information and actively calls the API to obtain it.
- Multi-tool orchestration and API calls: Intelligent assistants within the enterprise need to call multiple system APIs (CRM, ERP, OA). ReAct allows the model to independently select and combine the order of tool calls according to task needs.
- Data analysis and report generation: The model first thinks about "what data is needed", calls the database query tool to obtain the data, then thinks about "how to analyze", calls the analysis tool or writes code for processing, and finally generates a report.
- Operation and maintenance troubleshooting: After receiving the alarm, the Agent first analyzes the alarm information, calls the monitoring API to view the indicators, and then calls the log query tool based on the abnormal indicators to locate the root cause and provide repair suggestions.
- Intelligent customer service and technical support: After the user describes the problem, the Agent first understands the problem and queries the knowledge base to obtain the solution. If necessary, it can also call the work order system, check the user's order status, etc.
Applicable systems and integration solutions
Compatible system type:
- Enterprise unified intelligent assistant: Open up the enterprise’s internal CRM, ERP, OA, email, calendar and other systems. The employee said, "Help me check where Mr. Chen's contract approval is, and by the way, make an appointment with him for a meeting tomorrow afternoon." - ReAct automatically determines the need to adjust the contract system → check the calendar → send a meeting invitation, and complete the cross-system operation in one conversation.
- Intelligent operation and maintenance platform (AIOps): System alarm triggers Agent → Thought: "CPU surges by 85%, need to troubleshoot" → Action: Call Prometheus to check indicators → Observation: "The QPS of service A has also increased 3 times" → Action: Check the log of service A → Locate the slow SQL → Give repair suggestions and automatically create a work order.
- Data Analysis and BI Platform: The user uses natural language to ask "Why did the gross profit margin of East China District drop by 3 points last month?" → ReAct automatically writes SQL → checks data → analyzes trends → correlates influencing factors → outputs analysis reports. The user does not need to open the SQL editor.
- Intelligent customer service work order system: After the user reports for repair, the Agent not only gives a standard reply, but automatically checks the equipment model, fault history, and inventory of spare parts, and provides a complete solution of "the engineer will bring XX model spare parts + is expected to arrive within 2 hours."
System integration method:
flowchart TD
A[user input] --> B[ReAct cycle engine]
B --> C{Thought: what is needed?}
C --> D[Tool Registration Center / API gateway]
D --> E1[CRM system]
D --> E2[ERP system]
D --> E3[OA Approval]
D --> E4[Monitoring system]
D --> E5[Database query]
E1 & E2 & E3 & E4 & E5 --> F[Observation: Summary of results]
F --> C
F --> G[final reply]
style B fill:#ffcdd2,stroke:#c62828
style D fill:#fff9c4,stroke:#f9a825
style G fill:#c8e6c9,stroke:#388e3c
Integration points:
- The tool registration center is the core hub: ReAct does not directly call the API of each business system, but through a unified tool registration center. Each tool declares "name, description, parameter schema, calling address", and the ReAct engine automatically matches the appropriate tool based on Thought. This is exactly what LangChain4j does
@Tooland Spring AI’s@ToolThe design logic behind annotations. - Permission boundaries must be preceded: In a production environment, the ReAct Agent calling tool must go through the permission gateway. Mark the required permission level for each tool in the tool registration center, and the gateway will intercept and verify it before the Agent executes the action - AI cannot be allowed to call all APIs at will.
- Observability is the bottom line: Each round of Thought → Action → Observation is recorded to the log system (timestamp, time consumption, tool name, parameters, return summary, Token consumption). When something goes wrong, you can quickly trace back "at which step the Agent made a wrong judgment" instead of guessing the reason for a final result.
4. Plan-and-Execute
present background
The Plan-and-Execute pattern appeared in the Agent application development framework practice around 2023, mainly derived from the engineering practice of the LangChain community. It is not the product of an academic paper, but an engineering improvement to the limitations of ReAct mode in complex long task scenarios.
core idea
ReAct mode performs well on simple tasks, but has a significant problem when faced with complex multi-step tasks:The model re-reasons "what to do next" at every step, lacking global planning.. This leads to two consequences - first, it is easy to "deviate" in the intermediate steps and deviate from the original goal; second, repeated reasoning brings a lot of token consumption and delay.
The Plan-and-Execute solution is to break the task into two clear phases:
The first stage - Planning: The model first overviews the entire task and generates a complete step plan. This plan is an ordered list of subtasks, each of which is specific and executable. For example, "writing a market research report on new energy vehicles" will be broken down into a sequence of steps such as "collecting sales data → analyzing policy trends → summarizing consumer feedback → writing a conclusion".
The second stage - Execution (execution): Execute each sub-task one by one according to the plan. Each subtask can be executed using any suitable strategy - it can be a simple LLM call, a ReAct loop, or a call to an external tool. The key is that the execution phase does not require repeated reasoning about "what to do next" because the plan has already been determined.
The benefits of this separation are obvious: the planning phase can focus on the "global optimal" task decomposition, and the execution phase can focus on the "local optimal" sub-task completion. At the same time, if a subtask fails to execute, you only need to re-execute the subtask without overturning the entire plan.
The advanced version also supportsDynamic re-planning (Re-planning): If you find that the plan is unreasonable during the execution process (for example, a certain subtask cannot be completed, or the execution results change the subsequent premise), you can go back to the planning stage and make adjustments.
flow chart
flowchart TD
A[Users assign complex tasks] --> B[Planning stage<br/>Generate complete plan]
B --> C[plan: subtask1]
B --> D[plan: subtask2]
B --> E[plan: subtask3]
B --> F[plan: subtaskN]
C --> G[Execute subtask1]
G --> H{Executed successfully?}
H -->|yes| D
H -->|no| I[Try again/Adjustment]
D --> J[Execute subtask2]
J --> K{Executed successfully?}
K -->|yes| E
K -->|no| L[Try again/Adjustment]
E --> M[Execute subtask3]
M --> N[...Continue execution]
N --> O[All subtasks completed]
O --> P[Integrated result output]
Q{Needs re-planning?} -.->|yes| B
style A fill:#e1f5fe,stroke:#0288d1
style B fill:#fff9c4,stroke:#f9a825
style P fill:#c8e6c9,stroke:#388e3c
style O fill:#c8e6c9,stroke:#388e3c
Scenario example
Task: Help me plan an outdoor birthday party for 30 people with a budget of 3,000 yuan.
Planning stage:
Plan generation:
1. Determine suitable venue types and candidates based on budget and number of people
2. Develop catering plan (self-service barbecue or Takeaway meal or Setting the buffet table)
3. Planning activity process (game session) + song + cutting cake)
4. Make a shopping list for supplies (decorations, tableware, drinks, cakes)
5. Make a time schedule (starting in the afternoon and ending in the evening)
6. Generate final plan document with budget details
Execution phase:
Execution steps 1: search"Beijing 30People outdoor party venue"
→ Compare park lawns (free) and camping sites (per capita30Yuan), B&B courtyard (private room)1500Yuan)
→ Choose: camping site(900Yuan / 30people)+ Bring your own tent area, the most cost-effective
Execution steps 2: Develop catering plans
→ Compare three options and choose"Buffet BBQ": Food wholesale agreement600Yuan + drinks200Yuan
Execution steps 3: Planning event process
→ 14:00-14:30 Sign in and take a group photo → 14:30-16:00 team games → 16:00-17:30 barbecue
→ 17:30-18:00 Singing and cutting the cake → 18:00-19:00 Free time to take photos
Execution steps 4: Material list
→ decoration (balloons+banner+photo wall)150yuan, disposable tableware120Yuan,
Cake customization300Yuan, drinks200yuan, snacks150yuan, small gifts200Yuan
Execution steps 5: budget summary
→ site900 + Ingredients600 + drinks200 + decorate150 + tableware120 +
cake300 + snack150 + small gifts200 + contingency budget280 = total2900Yuan
✓ not exceeded3000yuan budget
Execution steps 6: Generate final plan documents (including site address, procurement link, timetable, and budget details))
(if step1The campground is fully booked → Switch candidate plans and recalculate the budget. Other steps will not be affected.)
The advantage of Plan-and-Execute here is obvious: it first takes 5 seconds to generate the global plan, and the user can see clearly "how the entire party is going to happen" at a glance; then the details are executed step by step, and each step is independently verified - if the camping site is full, just change a plan, and the entire plan will not be overturned.
Applicable business scenarios
- Long process content generation: Market research reports, industry analysis reports, technical solution documents, product PRD documents. These tasks have many steps and are time-consuming. They need to plan the structure first and then fill it in section by section.
- Data processing pipeline: ETL tasks, data cleaning and analysis pipelines. First plan the data processing steps (extract → clean → convert → load → analyze), and then execute them step by step. Each step can be independently verified.
- Automated operation and maintenance process: System deployment, grayscale release, fault recovery and other operation and maintenance scenarios. Develop an operation plan first, then execute it step by step, and check the status after each step to ensure safety.
- Project management and task decomposition: Automatically break down large projects into executable sub-task lists and assign them to different executors or automated processes.
- Multi-step research and research: Literature review in academic research, multi-dimensional comparison in competitive product analysis, and multi-dimensional verification in investment due diligence all require planning the research framework first and then going in-depth one by one.
Applicable systems and integration solutions
Compatible system type:
- Automated deployment and release platform: User submits "Release User Center Service to Production Environment" → Plan Agent generates "Environment Check → Grayscale Release 10% → Monitor for 5 Minutes → Full Release → Regression Test → Notification" six-step plan → Execute Agent executes step by step, each step is independently verified. If it fails, just retry the failed step without overturning the entire process.
- AI document generation system: The user said "write a Q2 quarterly technical review report" → Plan Agent generates an outline (business goal review → technical achievements → problems and lessons → next quarter plan) → user confirms or adjusts → Execute Agent fills in the content paragraph by paragraph, and each paragraph of output can be independently reviewed.
- ETL data processing pipeline: The data engineer configures "Extract order data from MySQL → Clean and remove duplication → Convert field format → Load to ClickHouse → Run data quality check" → Plan generates DAG (directed acyclic graph), Execute executes according to dependencies, and the downstream is automatically blocked if the previous step fails.
- Multi-step automated testing platform: Test scenario "User registration → Login → Place order → Payment → View order" → Plan is divided into 5 test steps → Execute is run in order. When each step fails, it automatically takes a screenshot and saves the context for easy positioning.
System integration method:
flowchart TD
A[User task input] --> B[Plan Agent]
B --> C[step plan<br/>Can be manually reviewed and adjusted]
C --> D[Execute Agent]
D --> E1[step 1: ReAct implement]
E1 --> E2[step 2: ReAct implement]
E2 --> E3[step 3: ReAct implement]
E3 --> F{Needs re-planning?}
F -->|yes| B
F -->|no| G[Result summary output]
subgraph Step status tracking
H[(Task status storage<br/>Redis / DB)]
end
E1 -.-> H
E2 -.-> H
E3 -.-> H
style B fill:#fff9c4,stroke:#f9a825
style D fill:#ffcdd2,stroke:#c62828
style G fill:#c8e6c9,stroke:#388e3c
Integration points:
- The plan must be auditable, not a black box: After Plan Agent generates the plan, it must give the user (or automated approval rules) a chance to confirm/adjust, and then enter Execute after passing the plan. This is the red line of the enterprise environment - AI cannot be allowed to independently decide "how to change the production environment."
- Step state must be persisted: Long tasks may execute for tens of minutes or even hours. Redis or a database must be used to record the status of each step (pending → running → success → failed), and support resumption of downloads at breakpoints. A common scenario on the operation and maintenance platform is "the container restarts when executing step 4, and continues from step 4 after restarting".
- Dynamic re-planning is the soul: If step 3 fails, you should not start over from the beginning. Re-plan should be triggered: "Step 3 failed due to XX reasons, please re-plan the remaining steps based on the new situation." This is the core advantage of Plan-and-Execute over fixed scripts.
5. Tree of Thoughts (ToT, tree thinking)
present background
Princeton University and Google DeepMind jointly published the paper "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" in 2023. The paper is inspired by the theory of human "System 2 thinking" in cognitive science - when human beings solve complex problems, they will explore multiple ideas, evaluate various possibilities, and go back and start over when necessary, instead of going one way to the end.
core idea
CoT is linear reasoning - one chain to the end. This is enough for simple problems, but when faced with truly complex problems (such as puzzle solving, games, creative planning), the limitations of single-line reasoning are obvious:If one step goes in the wrong direction, the whole chain goes wrong, and there is no turning back..
The core idea of ToT is:It is not a single line of thinking, but generates multiple branches of thinking, unfolding like a tree.. Specifically:
- Thought Decomposition: Decompose the problem-solving process into a series of intermediate "thinking steps" (thoughts). Each thought is a meaningful intermediate state of problem-solving.
- Thought Generation: At each node, generate multiple candidate next thoughts (such as 3-5) to form branches of the tree.
- State Evaluation: An assessment of the current state of each branch - is there hope for this direction? Evaluation can be done by the model itself ("This idea looks reasonable/doesn't work"), or it can be done through external feedback.
- Search Algorithm: Use tree search algorithms (BFS breadth first, DFS depth first, beam search, etc.) to explore in the thinking tree, prune based on the evaluation results, and finally find the optimal path.
The relationship between ToT and CoT can be compared to: CoT is "walking a road", and ToT is "looking at the map and choosing the best route". The price of ToT is that it is more computationally expensive (requiring multiple LLM calls), but in scenarios that really require "thoughtful", this price is worth it.
flow chart
flowchart TD
A[Question input] --> B[initial state]
B --> C1[Ideas A]
B --> C2[Ideas B]
B --> C3[Ideas C]
C1 --> D1[Ideas A-1]
C1 --> D2[Ideas A-2]
C2 --> D3[Ideas B-1]
C2 --> D4[Ideas B-2]
C3 --> D5[Ideas C-1]
D1 --> E1{Evaluate: There is hope?}
D2 --> E2{Evaluate: There is hope?}
D3 --> E3{Evaluate: There is hope?}
D4 --> E4{Evaluate: There is hope?}
D5 --> E5{Evaluate: There is hope?}
E1 -->|no| X1[pruning ✂]
E2 -->|yes| F1[Continue to expand]
E3 -->|yes| F2[Continue to expand]
E4 -->|no| X2[pruning ✂]
E5 -->|no| X3[pruning ✂]
F1 --> G1[...continue searching]
F2 --> G2[...continue searching]
G1 --> H[Find the optimal solution]
G2 --> H
style A fill:#e1f5fe,stroke:#0288d1
style H fill:#c8e6c9,stroke:#388e3c
style X1 fill:#ffcdd2,stroke:#c62828
style X2 fill:#ffcdd2,stroke:#c62828
style X3 fill:#ffcdd2,stroke:#c62828
style B fill:#fff9c4,stroke:#f9a825
Scenario example
question: I am going to Chengdu from Beijing for 4 days with a budget of 2,500 yuan. How can I arrange the trip to save money and have fun?
ToT process:
Initial state: Beijing→Chengdu, 4sky3late, budget2500Yuan
No.1Layer thinking generation (travel mode):
Ideas A: High-speed rail round trip (second-class seat approx. 780×2=1560 Yuan, one way approx. 7.5 Hour)
Ideas B: Round trip flight (book a special ticket in advance to make an appointment) 600×2=1200 Yuan, one way approx. 3 Hour)
Ideas C: Hard sleeper train (approx. 350×2=700 Yuan, one way approx. 23 Hour)
Evaluate (considering budget and time)):
Ideas A → Transportation accounts for the budget 62%, Remaining 940 Yuan for accommodation and food → ❌ too tight
Ideas B → Transportation accounts for the budget 48%, Remaining 1300 Yuan and the most time-saving → ✅ optimal
Ideas C → Transportation accounts for the budget 28%, But the round trip is close 46 hours on the road → ❌ Too little time to play
keep ideas B, Continue to expand ↓
No.2layer thinking generation (accommodation + journey):
Ideas B-1: Stay in a youth hostel(50 Yuan/Night = 150 Yuan), all scenic spots are classic lines
(Kuanzhai Alley+Jinli+Giant Panda Base+Dujiangyan)
Ideas B-2: Stay in a budget hotel(150 Yuan/Night = 450 Yuan),
Focus on food experience (hot pot+Chuanchuan+Snack check-in+Sichuan Opera Face Changing)
Ideas B-3: Stay in a B&B(100 Yuan/Night = 300 Yuan),
nature+Humanities Mixture (Qingcheng Mountain+Giant Panda Base+Chuanbo+hot pot)
Evaluation (comprehensive budget, experience richness):
Ideas B-1 → The hotel is too bad and affects the experience → ❌
Ideas B-2 → total cost 1200+450+650(eat and drink+Tickets)= 2300 Yuan, good experience → ✅
Ideas B-3 → Just eating hot pot is monotonous → ⚠️ Optimizable
reserve B-2, Continue to expand ↓
No.3Generation of layered thinking (refinement of food routes)):
B-2-1: Day1 Taikoo Li+Jinli Snacks → Day2 Giant Panda Base+Hot pot dinner
→ Day3 Kuanzhai Alley+Chuanchuan+Sichuan Opera → Day4 People's Park+Tsai'er+return trip
B-2-2: Day1 Rest on landing+Chuanbo → Day2 Qingcheng Mountain One Day Tour
→ Day3 Giant Panda Base+Jianshe Road Snacks → Day4 Kuanzhai Alley+return trip
Assessment (travel rhythm, physical exertion):
B-2-1 → The rhythm is relaxed, the experience is rich and not tiring → ✅ optimal!
Final plan selected B-2-1:
transportation 1200 + stay 450 + eat and drink 450 + Tickets 200 + other 200 = total 2500 Yuan
The itinerary is full and you don’t have to rush, the food check-in is all covered, and the budget is just stuck ✓
The key here is: ToT does not just plan one path and then execute it, but expands multiple branches at the same time. Through the "evaluation" level, unreliable directions are cut off in a timely manner (hard sleep is too time-consuming, the youth hostel experience is too poor), and the computing power is concentrated on the most promising branches. It's as if a military advisor helped you calculate 9 options at the same time and finally picked the best solution.
Applicable business scenarios
- Complex planning and decision-making: Strategic planning, project design, resource allocation optimization. These problems often have multiple possible paths, and it is necessary to evaluate the feasibility and benefits of each path and select the optimal solution. ToT can systematically explore multiple combinations of strategies.
- Puzzle solving and constraint satisfaction problems: Constrained optimization problems such as shift scheduling, path planning, and resource allocation. These problems have explicit constraints, and ToT can prune by evaluating how well the constraints are met.
- Idea generation and solution exploration: Brainstorming in product design, multi-dimensional exploration of marketing plans, and comparison of multiple plans in technical architecture. ToT can generate a variety of creative directions, and then select the optimal one for in-depth development after evaluation.
- Games and Confrontation Strategies: Game AI, negotiation strategies, competing product response strategies. It is necessary to search for the optimal response plan among multiple possible opponent response branches.
- Code generation and debugging: Faced with complex programming problems, generate multiple implementation solutions, evaluate the complexity, performance, and maintainability of each solution, and select the optimal implementation. When debugging, you can also try multiple reasoning paths to locate bugs.
Applicable systems and integration solutions
Compatible system type:
- Intelligent shift scheduling system: Input constraints (personnel availability, skill matching, working hours regulations, business peaks and valleys), ToT explores multiple scheduling options at the same time, prunes through the evaluation function (compliance × efficiency × employee satisfaction), and finally outputs the optimal schedule, with an explanation of "why the other two options were not selected."
- Logistics route planning system: Input "100 distribution points, 5 vehicles, time window constraints", ToT simultaneously explores multiple path combinations, evaluates total mileage, timeliness, vehicle load balance, and selects the optimal scheduling plan.
- Technical architecture selection decision-making system: Input business requirements, and ToT simultaneously generates three branches: "monolithic architecture solution", "microservice solution", and "Serverless solution". It evaluates from multiple dimensions such as cost, maintainability, scalability, and team capabilities, recommends the optimal solution, and explains the trade-off logic.
- AI-assisted programming tools: Faced with "implementing a high-concurrency flash sale system", ToT simultaneously generates multiple architectural ideas (Redis pre-stock reduction + MQ asynchronous ordering, database row-level locks, pure Redis Lua scripts), evaluates concurrency capacity, data consistency, and implementation complexity before selecting the optimal path and starting coding.
System integration method:
flowchart TD
A[constraint / Requirements input] --> B[ToT search engine]
B --> C[No. 1 layer: generate N candidate branches]
C --> D[Evaluator: Score each branch]
D --> E{pruning: reserve Top-K}
E --> F[No. 2 layer: Continue to expand the reserved branch]
F --> D
E -->|Termination condition reached| G[Optimal solution output]
subgraph Evaluate dimension configuration
H[cost weight]
I[efficiency weight]
J[risk weight]
K[Compliance weight]
end
D -.-> H & I & J & K
style B fill:#fff9c4,stroke:#f9a825
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#c8e6c9,stroke:#388e3c
Integration points:
- The evaluation function is the soul of ToT: 90% of the quality of ToT depends on the accuracy of the evaluation function. In an actual system, the evaluation function should be a mixture of "rule engine + LLM self-evaluation" - hard constraints (such as working hours not exceeding 40 hours/week) are hard pruned by the rule engine, and soft indicators (such as solution aesthetics and user experience) are scored by LLM.
- Controlling search costs is a necessity: With each additional layer of branches, the amount of LLM calls increases exponentially. Actual systems must be configured with "maximum exploration width K" (how many branches are retained per layer) and "maximum exploration depth D" (up to how many layers are expanded). Typical business configuration: K=3, D=5, a total of 15 LLM calls, and the cost is controllable.
- Results must be interpretable: Users need to see not only the final plan, but also "why the other two plans were eliminated" - ToT needs to output the complete reason for pruning ("Although plan B is the lowest cost, the logistics timeout rate is 15%, which does not meet SLA requirements").
6. Reflexion / Iterative Refinement (reflection and iterative optimization)
present background
The 2023 paper "Reflexion: Language Agents with Verbal Reinforcement Learning" proposed the Reflexion framework. The core contribution of this paper is to propose the concept of "Verbal Reinforcement Learning" - not updating model parameters through gradients, but improving model behavior through self-reflection in the form of natural language.
core idea
The problems with traditional Agents are:If you make a mistake and don’t know why, you will make the same mistake next time. Even powerful LLMs make mistakes in complex tasks—bugs in their code, holes in their reasoning, and biased answers. If the Agent simply "retries" without summarizing the reasons for the failure, the result of the retry is likely to be wrong.
The core idea of Reflexion is to give Agent self-correction ability, the key lies in the "reflection" step:
- Act:Agent attempts to complete a task and produce an output or action.
- Evaluate: Determine whether the output is correct through external feedback (such as compiler errors, test case results, user feedback) or self-evaluation.
- Reflect: If the output is wrong, the Agent not only knows "it's wrong", but uses natural language to summarize "why it's wrong" - "the function parameter types are mixed up", "boundary conditions are not taken into account", "the search keywords are too broad and the results are irrelevant".
- Retry: Try again with reflection and summary. This time, with the lessons learned from the previous failure, the success rate will be significantly improved.
This cycle of Act → Evaluate → Reflect → Retry can be repeated until the task succeeds or the maximum number of retries is reached. Each reflection is accumulated as "language memory" to guide subsequent attempts.
Unlike traditional reinforcement learning (which learns through gradient update parameters), Reflexion learns throughNatural language feedbackTo improve - the model remains the same, but there is more "lessons learned from the last failure" in the context. This method does not require retraining the model, and only requires adding reflection records to the prompt, which is very lightweight in terms of engineering.
flow chart
flowchart TD
A[receive tasks] --> B[No.1attempts]
B --> C[Generate output]
C --> D{Evaluate: Is it correct??}
D -->|yes| E[Mission accomplished ✓]
D -->|no| F[Reflection: Analyze the cause of failure]
F --> G[Record lessons learned]
G --> H{Number of retries<br/>Whether it exceeds the limit?}
H -->|no| I[No.2attempts<br/>with reflective experience]
I --> C
H -->|yes| J[Task failed<br/>Transfer to manual processing]
subgraph reflective memory area
K[No.1failure lessons:<br/>Parameter types are mixed up]
L[No.2failure lessons:<br/>Missing boundary conditions]
M[accumulated experience...]
end
G -.-> K
K -.-> I
style A fill:#e1f5fe,stroke:#0288d1
style E fill:#c8e6c9,stroke:#388e3c
style J fill:#ffcdd2,stroke:#c62828
style F fill:#fff9c4,stroke:#f9a825
style G fill:#fff9c4,stroke:#f9a825
Scenario example
Task: Give me a reply. The customer said that the cake box that arrived by express delivery was crushed and asked for a refund. We are a handmade cake shop, and every cake comes with delivery insurance.
Reflexion process:
=== No.1attempts ===
Generated reply:
"Hello, we are very sorry for the inconvenience. According to our delivery insurance terms,
If the cake is damaged during transportation, we will provide a full refund. please provide
Order number and photos of the damage to the cake, we will process it immediately after verification. thank you for your understanding."
Assessment (Customer Perspective)): ❌ The reply is too mechanical and template-like - the guest gets the emotion (their birthday expectations are dashed)),
But there was no empathy in the reply, and the process was coldly followed..
=== Reflection ===
Analysis failure reason: only stated"Claims process", Doesn’t respond to the guest’s emotions at all.
Customers don’t buy cakes just to be entertained"process processing", It’s to celebrate your birthday with dignity.
Lesson: Empathize first → Admit mistakes again → Give more compensation → Finally give a promise.
=== No.2attempts (with reflective experience)===
Generated reply:
"It really hurts me to see this picture! We spent several hours making the cake by hand,
It was in perfect condition when it was sent out - it fell down on the way and lost your surprise.
It’s all gone. It’s really because we didn’t do a good enough job..
We will give you a full refund for this year’s birthday cake, and the money will be in 24 Return to the original route within hours.
In addition, next time you order a cake, we will call you directly 5 discount, and this time it will definitely
Require couriers to sign for receipt, unpack and inspect the goods in person. We can’t let this happen again..
I hope it didn’t ruin your mood today too much. Happy birthday 🎂"
Evaluate: ✅ Empathize first("Feeling distressed")→ Attribution but no shirk (we will compensate for express delivery problems))
→ Compensation exceeded expectations (refunds+50% off next time)→ Process improvement commitment → Blessings at the end
Warmth, responsibility and action.
Mission accomplished!
The value of Reflexion is very intuitive here - the difference between the first and second times is not essentially a problem of the model's ability, but after the reflective experience of "it was too much like a machine customer service last time", the model knows where its problems are and can make targeted improvements next time. The cost of this "language memory" is extremely low - no need to retrain the model, just add a line of reflection summary in the prompt context.
Applicable business scenarios
- Code generation and automatic repair: The AI programming assistant automatically runs the test after generating the code. If an error is reported, the error message is analyzed and corrected. The essence of the "automatic repair" function of AI programming tools such as Cursor and Copilot is Reflexion. Within the enterprise, it can be used for automated remediation in CI/CD pipelines.
- Document writing and content polishing: After AI writes, it discovers deficiencies (incoherent logic, insufficient arguments, and fluent language) through self-evaluation or other evaluations, and then revise and optimize after reflection. Suitable for automatic generation and iteration of technical documents, marketing copywriting, and reports.
- Data analysis and result verification: After the Agent completes the data analysis, check whether the results are reasonable (whether the data is abnormal and whether the conclusion is tenable). If problems are found, reflect on the data quality or analysis method and reanalyze.
- Process execution and exception recovery: If an exception is encountered during the execution of the automated process, the Agent will analyze the cause of the exception, adjust the strategy and try again. Much smarter than simply "retry 3 times" because each retry comes with the understanding of the last failure.
- Dialogue system and customer service: After the Agent answers the user's question, if the user expresses dissatisfaction or asks further questions, the Agent will reflect on "Did I misunderstand the user's intention", adjust the understanding and answer again.
Applicable systems and integration solutions
Compatible system type:
- CI/CD automatic repair pipeline: Code submission → Automatic build → Run test → Test failed? → Reflexion Agent analyzes the cause of the error → generates a repair patch → automatically submits the repair code → rebuilds. During the entire process, developers only need to see "3 test issues have been automatically fixed, please confirm" in the MR.
- AI writing and content optimization platform: Users say "I'm not satisfied with this copy, it's too official" → Reflexion is not simply "rewriting it", but analyzing "what's too official" (words? Sentence structure? Tone?) and optimizing with specific directions for improvement. Each round of revisions has clear anchor points for improvement, rather than random rewrites.
- Automated test generation platform: Agent generates unit tests for a piece of code → runs the test → finds that the coverage is only 65% → reflects on "which branches are not covered" → supplements test cases for boundary conditions and abnormal paths → runs again → the coverage reaches 90%.
- Intelligent customer service quality inspection system: After the customer service agent responds to the work order → the quality inspection agent evaluates the quality of the reply → unqualified → reflect on "what exactly is the problem" (not good enough? Didn't solve the fundamental problem? gave wrong information?) → reply after correction to avoid the perfunctory "say it again in another way".
System integration method:
flowchart TD
A[Task input] --> B[actuator]
B --> C[Output results]
C --> D{evaluator judgment}
D -->|pass| E[Mission accomplished]
D -->|failed| F[Reflexion reflection engine]
F --> G[Generate reflective lessons]
G --> H[(Lessons Storage<br/>vector library / cache)]
H --> I[Try again with reflection]
I --> B
style F fill:#fff9c4,stroke:#f9a825
style H fill:#f3e5f5,stroke:#7b1fa2
style E fill:#c8e6c9,stroke:#388e3c
Integration points:
- Without a good evaluator, Reflexion is just introspection.:The effectiveness of Reflexion depends entirely on the evaluator quality. Different scenarios require different evaluators: test case results are used for coding scenarios; LLM self-evaluation + manual scoring is used for writing scenarios; monitoring indicators and SLA are used for operation and maintenance scenarios. Let’s polish the evaluator first, and then talk about Reflexion.
- Lessons must be accumulated and reusable: Don’t limit reflection to the context of a single conversation. Store historical lessons in a vector database, and relevant lessons can be retrieved for subsequent similar tasks. The lesson "the last time I wrote SQL without adding an index resulted in slow query" can still be retrieved and avoided when generating new SQL a month later.
- Set hard stop conditions: Avoid infinite reflection loops. Set the "maximum number of reflections" (usually 3 to 5 times is enough) and the "reflection quality degradation threshold" - if the reflection content is highly repetitive for two consecutive times, it means that the ability ceiling has been reached, stop and transfer to manual processing.
7. Role-playing Agents (role-playing/multi-agent collaboration)
present background
The concept of role-playing agents originates from community projects such as AutoGPT, ChatDev, and CAMEL. The common feature of these projects is that instead of using a single Agent to complete all the work, multiple Agents with different roles and responsibilities are introduced to complete complex tasks through dialogue and collaboration. The CAMEL (Communicative Agents Mind Exploration) paper systematically studied the communication mechanism of multi-agent role-playing for the first time; ChatDev applied it to the software development process; AutoGPT demonstrated the prototype of autonomous multi-step execution.
core idea
No matter how powerful a single Agent is, it still has cognitive boundaries - it is difficult for it to play multiple roles such as product manager, programmer, test engineer, and designer at the same time, because each role has different thinking patterns, concerns, and professional languages.
The core idea of Role-playing Agents is:Split tasks to Agents with different roles. Each Agent has exclusive responsibilities and completes tasks through dialogue and collaboration.. Specifically:
- role definition: Assign a clear role (Persona) to each Agent, including its responsibilities, areas of expertise, code of conduct, and output format. For example, "You are a senior Java back-end engineer, focusing on system architecture design, and your output must be a technical solution document."
- Task allocation: Decompose complex tasks into subtasks that each role is responsible for. Each Agent is only responsible for the part he is good at.
- Conversational collaboration: Agents collaborate through structured dialogue. The output of one Agent becomes the input of another Agent, forming a collaboration chain. For example, the product manager agent outputs requirements documents → the programmer agent writes code according to the requirements → the test agent writes test cases according to the requirements and code → the code review agent reviews the code quality.
- feedback loop: The downstream Agent can provide feedback on the output of the upstream Agent. When the test agent finds that the requirements are not clear, it can "question" the product manager agent; when the code review agent finds design problems, it can "suggest" the programmer agent to make changes.
The core value of this model isProfessional division of laborandDiversity of perspectives. Each Agent "thinks" within its own role framework, producing more professional and focused output; collisions and verifications between different roles also make it easier to find problems than a single Agent's self-examination.
flow chart
flowchart TD
A[Users assign complex tasks] --> B[product manager Agent]
B -->|Requirements document| C[Architect Agent]
C -->|Technical solution| D[programmer Agent]
D -->|Code implementation| E[test Agent]
E -->|test case + Test results| F{pass or not?}
F -->|no| G[code review Agent]
G -->|Modification suggestions| D
F -->|yes| H[Delivery completed]
E -.->|Demand questions| B
G -.->|Architectural recommendations| C
subgraph Multi-agent collaborative team
B
C
D
E
G
end
style A fill:#e1f5fe,stroke:#0288d1
style H fill:#c8e6c9,stroke:#388e3c
style B fill:#fff9c4,stroke:#f9a825
style C fill:#fff9c4,stroke:#f9a825
style D fill:#fff9c4,stroke:#f9a825
style E fill:#fff9c4,stroke:#f9a825
style G fill:#fff9c4,stroke:#f9a825
Scenario example
Task: Planning an online launch conference for the company’s new smart bracelet product
Multi-agent collaboration process:
[Brand planning Agent]
Output press conference positioning plan:
- theme: "Your first health manager"——Take the people-friendly technology route, don’t focus on parameters, focus on life
- Tonality: Warmth, reliability, concern like a friend
- target group: 25-35 A 20-year-old urban white-collar worker who cares about sleep and exercise but doesn’t want to be too professional
- Core story line: the health of an ordinary office worker 24 Hour
↓ Deliver planning plan
[content copywriting Agent]
Output copywriting and scripts based on positioning:
- Opening video script: Early morning 6 Click the alarm clock → Bracelet records sleep quality ⭐⭐⭐⭐
Reminder for sitting for long periods of time during commuting → Lunch break blood oxygen monitoring → Heart rate zones for running after get off work → sleep breathing test
- Product introduction page copywriting: 5 Great health functions, 3 Speak clearly and don’t pile up parameters
- ending call to action: "Order today, before 1000 Customized watch strap"
↓ Pass copywriting script
[visual design Agent]
Output visual plan based on copywriting:
- Main color: warm orange + dark blue (warm × sense of technology)
- host KV Design draft: close-up of bracelet + "Visible good sleep"copywriting
- Product page layout: each screen only talks about one function, large white space, and large emotional copywriting
- countdown poster 3 Zhang (before the press conference 3 sky/1 sky/that day)
→ Ask a question: "24 Can there be an extra weekend version of the hourly storyline??
The rhythms of weekdays and weekends are very different, and the two versions are more touching."
↓ Feedback to content copywriters Agent
[content copywriting Agent]
Supplement after receiving suggestions from designers:
- Increase"Saturday edition"Storyline: Sleep until you wake up naturally → Recommended route for morning jog → Calorie statistics for dinner with friends
- Keep it"weekday version"Let target users choose one of the two, A/B test
↓ The updated copy is for everyone Agent
[data analysis Agent]
Provide recommendations based on historical conference data:
- Suggested release time: Thursday evening 8 point (past 8 The period with the highest conversion rate during the press conference)
- Notice cycle: 7 days (the countdown is too long and loses attention, and the countdown is too short and there is insufficient water storage))
- Pricing strategy: initial price 299, Compare similar products 349-399, Has price impact
↓ Feedback to brand planning and content copywriting
[Brand planning Agent]
Combine all opinions and output the final "Press Conference Execution Manual"":
Contains themes, timelines, copywriting scripts, visual material lists, delivery channels, and data monitoring indicators.
[Delivery completed]
This scene shows the essence of multi-agent collaboration - instead of letting a large model "think all of this", people who are good at branding can think of slogans, people who are good at writing can write copy, people who are good at drawing can provide visuals, and people who are good at data can provide strategies. Moreover, the designer can make suggestions for improving the copy ("Add one more weekend version"), and the data agent can correct the release time - this kind of cross-role collision and feedback is difficult for a single agent to achieve.
Applicable business scenarios
- The whole process of software development: The complete software life cycle from requirements analysis to design, development, testing, and code review. Projects such as ChatDev have proven that multiple agents can complete the entire process of a simple software project. It can be used within the enterprise to assist the development process and improve the efficiency of each link.
- Content creation team: Simulate editorial department collaboration - planning Agent to select topics, research Agent to collect materials, Writing Agent to write the first draft, Editing Agent to review and polish, SEO Agent to optimize keywords. Suitable for media operations, technology blogs, and mass production of marketing content.
- Investment research and decision-making: The macro analyst Agent studies economic trends, the industry analyst Agent analyzes the track, the financial analyst Agent evaluates financial reports, the risk control Agent evaluates risks, and finally the investment decision-making Agent gives suggestions based on the opinions of all parties.
- Cross-functional project collaboration: Large-scale projects involve the collaboration of multiple functions including product, technology, operations, legal affairs, and finance. Each function is responsible for a dedicated Agent, simulating the real project collaboration process.
- Education and Training Simulation: Simulated case teaching - the teacher Agent asks questions, the student Agent tries to answer, and the Comment Agent gives feedback. Scenes such as business negotiations and interviews can also be simulated, with different role Agents playing different positions.
Applicable systems and integration solutions
Compatible system type:
- Software development collaboration platform (ChatDev mode): Product manager Agent writes PRD → Architect Agent comes up with technical solutions → Programmer Agent writes code → Test Agent runs tests → Review Agent reviews code. The entire software development pipeline is completed by multi-Agent collaboration, and human developers only need to review and confirm at key nodes.
- Content production pipeline (self-media matrix): The topic selection agent focuses on hot topics → the research agent collects materials → the writing agent generates the first draft → the editing agent polishes → the SEO agent optimizes the title and keywords → the publishing agent pushes it to each platform regularly. Manuscripts polished by multiple roles are automatically produced every day.
- Investment research and decision-making system: Macro analysis Agent studies the economic cycle → Industry analysis Agent evaluates the track prosperity → Financial analysis Agent disassembles the financial report of the target company → Risk control Agent evaluates downside risks → Decision-making Agent comprehensively provides investment suggestions based on the opinions of all parties, with points of disagreement and confidence.
- Enterprise cross-department collaboration platform: Large-scale projects require collaboration from multiple parties including product, technology, operations, legal affairs, and finance. Each department is represented by a dedicated agent. The legal agent reviews compliance risks → the financial agent calculates the budget → the product agent adjusts the plan - simulating the chain of real cross-department collaboration.
System integration method:
flowchart TD
A[Mission entrance] --> B[task allocator<br/>Orchestrator]
B --> C1[Agent 1: product manager<br/>Prompt + Toolset]
B --> C2[Agent 2: Architect<br/>Prompt + Toolset]
B --> C3[Agent 3: develop<br/>Prompt + Toolset]
B --> C4[Agent 4: test<br/>Prompt + Toolset]
C1 --> D[message bus / event driven]
C2 --> D
C3 --> D
C4 --> D
D --> E[Collaboration orchestration engine]
E --> F{process control}
F -->|trigger next step| C1 & C2 & C3 & C4
F -->|End of process| G[Deliverable assembly]
style B fill:#fff9c4,stroke:#f9a825
style D fill:#f3e5f5,stroke:#7b1fa2
style G fill:#c8e6c9,stroke:#388e3c
Integration points:
- Role definition is the threshold, and writing the Prompt is the beginning.: Each Agent's Prompt needs to contain four core elements - "role positioning, scope of responsibilities, output format, and collaboration rules". "You are a senior product manager" is the positioning, "Only output PRD documents (Markdown format)" is the output format, and "Do not write code, but can accept development deliverables" is the collaboration rule. Without any of these, the agent will go out of bounds.
- The collaboration process requires a state machine to cover everything: Multi-Agent collaboration is not about "everyone chatting casually", but a clear status flow. Implementation method: Use the orchestration engine (Orchestrator) to manage the state machine - "Product manager output → automatically trigger architect → architect output → automatically trigger development → development output → trigger test → test failure → fall back to development." Without a state machine, multiple agents are just a group of stragglers without a command.
- What is passed between Agents are deliverables, not chat records.: Use files or database records for intermediate storage - the PRD output by the product manager is stored as a document record, and the architect reads the record and produces a technical solution document. Don't pile up the entire conversation history in the prompt context, otherwise token consumption will quickly get out of control.
- Human-machine collaboration is the red line for implementation: Don’t try to let multiple Agents run the entire pipeline automatically. Set up manual review points at key nodes - "The PRD of the product manager Agent needs to be confirmed by the human product manager before entering the architect link." This is the core principle for enterprise-level multi-agent systems to run stably in production environments.
Mode comparison and mixed use
The seven modes are not mutually exclusive and are often used in combination in practical applications. The following are common combination strategies:
flowchart LR
subgraph simple reasoning
A1[CoT]
end
subgraph information retrieval
B1[Self-Ask] --> B2[+ search engine]
end
subgraph Tool call
C1[ReAct] --> C2[CoT as Thought engine]
end
subgraph complex tasks
D1[Plan-and-Execute] --> D2[for each subtask ReAct]
D2 --> D3[Used when failed Reflexion]
end
subgraph Deep exploration
E1[ToT] --> E2[Each branch uses CoT]
end
subgraph Teamwork
F1[Role-playing] --> F2[for each role ReAct]
F2 --> F3[Used between roles Reflexion mutual review]
end
style A1 fill:#c8e6c9,stroke:#388e3c
style B1 fill:#c8e6c9,stroke:#388e3c
style C1 fill:#c8e6c9,stroke:#388e3c
style D1 fill:#c8e6c9,stroke:#388e3c
style E1 fill:#c8e6c9,stroke:#388e3c
style F1 fill:#c8e6c9,stroke:#388e3c
Selection decision reference
| your scene | Recommendation mode | reason |
|---|---|---|
| Mathematical calculations, logical reasoning | CoT | Linear reasoning is sufficient, simple and efficient |
| Multi-hop fact query | Self-Ask | Automatically disassemble the problem and cooperate with the search |
| Need to call tools/API | ReAct | Reasoning + action closed loop, dynamic decision-making |
| Multi-step long task | Plan-and-Execute | Plan the overall situation first, then implement it step by step |
| Puzzle solving/complex planning | ToT | Multi-branch exploration, evaluation and selection |
| Need self-correction | Reflexion | Reflect on the reasons for failure and iteratively improve |
| Cross-functional complex projects | Role-playing | Professional division of labor, multi-perspective collaboration |
| All needed? | Mixed use | Plan-and-Execute is the skeleton, ReAct is the execution, Reflexion is the backbone, and Role-playing is the division of labor. |
Framework supports status quo
These design patterns have been widely built into mainstream Agent development frameworks:
flowchart TD
subgraph Agent development framework
L1[LangChain / LangChain4j]
L2[LlamaIndex]
L3[Dify]
L4[Spring AI Alibaba]
L5[Google ADK]
end
subgraph Built-in mode support
M1[ReAct - basic execution paradigm]
M2[Plan-and-Execute - mission planning]
M3[Reflexion - Retry and error correction]
M4[Role-playing - multi-agent]
M5[CoT - Reasoning enhancement]
end
L1 --> M1
L1 --> M2
L1 --> M3
L1 --> M4
L2 --> M1
L2 --> M5
L3 --> M1
L3 --> M2
L4 --> M1
L4 --> M4
L5 --> M1
L5 --> M4
style M1 fill:#c8e6c9,stroke:#388e3c
style M2 fill:#fff9c4,stroke:#f9a825
style M3 fill:#fff9c4,stroke:#f9a825
style M4 fill:#fff9c4,stroke:#f9a825
style M5 fill:#e1f5fe,stroke:#0288d1
- ReAct It has become the basic execution paradigm of almost all frameworks and is the "operating system" of Agent.
- Plan-and-Execute There is a special implementation (Plan-and-Execute Agent) in LangChain.
- Reflexion The idea is integrated into the retry mechanism and error handling logic of each framework.
- Role-playing / Multi-Agent There is direct support in the multi-agent module of LangGraph and Spring AI Alibaba.
- CoT Usually used as part of the prompt project and does not require special support at the framework level.
Understanding these underlying patterns can help developers make more accurate judgments when selecting a framework - not by looking at "how many functions the framework supports", but by looking at "how it implements these cognitive patterns" and which implementation method is most suitable for your business scenario.
sum up one sentence: CoT is a step-by-step writing process, Self-Ask is broken down into small problems, ReAct is both thinking and doing, Plan-Execute is planning first and then executing, ToT is tree-like multi-branch exploration, Reflexion is self-reflection and iteration, and Role-playing is multi-person collaboration and division of labor. They form the thinking model library of the Agent world, and when used in a mixed and matched manner, they are most powerful.
