Cline architecture overview

源码版本v4.0.10

In one sentence

Cline is an AI coding assistant built on a VSCode extension + recursive agent loop + tool coordinator stack: activate wires up the Controller → a user message creates a Task → the Task drives "LLM stream → parse assistant message → execute tools → feed results back" recursively via recursivelyMakeClineRequests until the turn ends. Tools are dispatched by name through ToolExecutorCoordinator, providers are switched in buildApiHandler, and MCP / sub-agents / context truncation / checkpoints / hooks each live as their own module.

Layers

One sentence per layer

• Startup and host: activate sequentially wires up host → migration → webview → command registration. Controller owns Task, McpHub, and StateManager.
• Agent main loop: The Task class is a per-turn state machine; recursivelyMakeClineRequests drives each round recursively.
• Assistant message parsing: parseAssistantMessageV2 slices the LLM text stream into text / tool / reasoning blocks; the diff algorithm builds new file contents.
• Tool system: ToolExecutorCoordinator dispatches by ClineDefaultTool name to 25+ handlers.
• Provider channel: buildApiHandler is a single switch that fans out to 40+ vendor handlers.
• System prompts and modes: PromptBuilder assembles the system prompt by model variant; plan / act modes control whether to only plan or actually execute.
• MCP and sub-agents: McpHub connects to external MCP servers, SubagentRunner runs isolated sub-tasks, and ContextManager truncates history.
• Storage and hooks: StateManager persists global state, Hooks fire external commands on lifecycle events, and Checkpoints snapshot tasks.

Why layered this way

Cline fully decouples "how to integrate with VSCode" (host), "how to drive a turn" (Task loop), "how to parse LLM output" (parsing), "how to execute tools" (tools), "how to call the model" (providers), "how to assemble prompts" (prompts), "how to extend" (MCP / sub-agents), and "how to persist" (storage). This way swapping a model does not affect tools, swapping a tool does not affect the loop, and adding an MCP server does not touch the core. The Task class is the single hub — all turn state lives on it.

Common misreadings

• "Cline is a ChatGPT wrapper" — not quite. Provider switching is just the surface; the real core is the recursive agent loop plus the tool coordinator. The LLM is only one step in the loop.
• "Tools are hard-coded" — ToolExecutorCoordinator is registry-based, handlers live in independent files, and they can be registered and extended by name.
• "plan and act are two codebases" — they are not. Both share the Task loop; only the system prompt and the allowed tool set differ.

Suggested reading order

Start with startup and host, then read the Task class and recursive driving, and continue in this order: tool system → Provider → system prompts and modes → MCP and sub-agents → storage and hooks.

See official docs: Cline website · Cline docs · GitHub