Update Introduction_to_Jarvis.md

Introduction_to_Jarvis.md

@@ -114,6 +114,8 @@ Let's go through some basic ideas of Jarvis and its components now.
 
 
 ### Memory Management Mechanisms
+Above all, the role separation into a hierarchy structure of LLMs largely increases the token upper limits.
+
 For long-term memory, the goal is to refine the quality of LLM's chat history, to do this, we utilize memory files, for now there are three kinds of memory_files:
 - `plan`: the step-by-step plan to achieve the goal, it will be updated by the `update_plan` executor when the controller realizes that one (or some, depending on the LLM's response) step of the plan is (are) done.
 - `logs`: the history of subflows execution results, it will be updated by the `MemWriteFlow` executor whenever one branching executor is finished.
@@ -125,6 +127,8 @@ We also applied a sliding window for history chat messages as a workaround for t
 - Whenever the chat that utilizes the sliding window is called, we inject a new system prompt with the newest memory (plan, logs, for `Coder` and some other flows, `code_library` is also injected) into the chat history.)
 - We crop the chat history with a tailing window of length 3, that will include the assistant's previous call, the updated system prompt, the the user's new response.
 
+When the `Coder` and `ExtendLibraryFlow` is finished, we reset the flows, that means the chat history is cleaned as well -- which is fine, because the plan and logs are preserved in the upper level of flow (`JarvisFlow` and `Coder`). By doing this, Jarvis is able to clear unused tokens.
+
 As a result, Jarvis is able to run for quite a long time, and it's able to use the code written before.
 
 ### An Example run of Jarvis