Cline VSCode 扩展架构深潜WebviewProvider、Controller 与 Task 执行系统的全景解析【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本篇基于 Cline 仓库内部的开发指南 cline-overview.md 展开系统讲解 Cline VSCode 扩展的分层架构核心扩展后端 React Webview 前端、状态管理机制、多模型 API Provider 体系、Task 执行循环与 Plan/Act 双模式系统并结合当前仓库的实际源码位置apps/vscode/与sdk/packages/给出可验证的实现佐证。读完后你将理解一次用户输入 → 模型流式响应 → 工具执行 → 状态持久化在 Cline 内部如何流转以及在新功能开发中应遵循哪些状态管理与目录约定。一、项目总览与架构全景Cline 是一个基于 TypeScript 构建的 VSCode 扩展提供 AI 编码助手能力。它的架构遵循模块化分层模式核心扩展后端Extension Host 侧负责与 VSCode API、模型 API、MCP 服务器交互React Webview 前端负责用户可见的全部交互界面。两者之间通过 VSCode 的消息传递机制gRPC 风格的 proto 协议双向通信。原文档给出的完整架构图如下核心数据流ExtensionEntry → WebviewProvider → Controller → Task以及 Webview 侧 React App → ExtensionStateContext → Components路径说明原文档中的src/...与webview-ui/...路径对应当前 monorepo 中的 apps/vscode/src/extension.ts、apps/vscode/src/core/webview/index.ts、apps/vscode/src/core/controller/index.ts、apps/vscode/src/services/mcp/McpHub.ts 与 apps/vscode/webview-ui/src/App.tsx。这些文件均已确认存在于当前仓库。二、核心概念定义与分层职责原文档对四个关键概念给出了精确定义这是理解整个系统的词汇表概念定义与职责Core Extension核心扩展src目录内的一切按模块化组件组织Core Extension State核心扩展状态由Controller类管理作为扩展状态的单一事实来源管理 global state、workspace state、secrets 等多种持久化存储负责将状态分发到核心扩展与 Webview 两侧并协调多实例间的一致性API 配置、任务历史、设置、MCP 配置等WebviewWebview 前端webview-ui目录内的一切即用户可见的全部 React 视图与交互组件Webview StateWebview 状态由ExtensionStateContext通过 Context Provider 模式提供维护 UI 本地状态、处理消息事件实时更新与流式内容的部分更新并以自定义 HookuseExtensionState提供类型安全的状态访问核心扩展的三层调用链核心扩展遵循清晰的层级结构WebviewProviderapps/vscode/src/core/webview/index.ts管理 Webview 生命周期与通信Controllerapps/vscode/src/core/controller/index.ts处理 Webview 消息与任务管理Task执行 API 请求与工具操作这种分层带来明确的关注点分离WebviewProvider 只关心 VSCode Webview 集成Controller 负责状态管理与任务协调Task 负责 AI 请求与工具操作的实际执行。从入口文件 extension.ts 的activate流程可以印证这条链路扩展激活时先通过setupHostProvider注册宿主能力再执行旧版 VSCode 原生存储到共享文件存储的迁移exportVSCodeStorageToSharedFiles随后调用initialize(storageContext)创建 Webview 并注册 sidebar 视图——返回的webview.controller正是后续所有命令如 PlusButton、AddToChat、FixWithCline操作的中央对象。Controller 管理的三类持久化存储Controller管理三类持久化存储Global State跨所有 VSCode 实例共享用于全局设置与数据Workspace State特定于当前工作区用于任务相关数据与设置SecretsAPI Key 等敏感信息的加密存储实例间的状态同步依靠四类机制基于文件的任务历史与对话数据存储、VSCode global state API设置与配置、Secrets 存储敏感信息、以及文件变更与配置更新的事件监听。当前仓库中这一设计有直接佐证state-keys.ts 文件头注释明确自称是SINGLE SOURCE OF TRUTH FOR STORAGE KEYS存储键的单一事实来源集中定义键的类型、默认值与元数据并说明新增字段后会通过scripts/generate-state-proto.mjs自动重新生成proto/cline/state.proto。同时 general.md 记录了更进一步的演进持久化状态已改为由StateManager以文件为底层存储内存缓存在initialize()时加载不再直接读写 VSCodeExtensionContext的原生存储——后者仅作为旧版迁移数据源。这解释了架构图上 VSCode Global State / Secrets Storage 框旁为何还并存 Per-Task Files History 的 Task Storage。Webview 侧的 ExtensionStateContextExtensionStateContextapps/vscode/webview-ui/src/context/ExtensionStateContext.tsx通过 Context Provider 模式向 React 组件提供扩展状态上下文内容包括扩展版本号消息messages任务历史主题themeAPI 配置MCP 服务器Marketplace 目录工作区文件路径它通过 VSCode 消息传递机制与核心扩展同步并以自定义 Hook 提供类型安全访问——当前源码中useExtensionState位于该文件的第 1018 行附近且在 Provider 之外调用会直接抛出错误强制约束了使用方式。它同时承担四类职责消息事件驱动的实时状态更新、流式内容的部分消息更新、通过 setter 方法修改状态、以及经 Hook 的类型安全读取。值得注意的是Webview 与后端的通信并非散落的postMessage而是 proto 定义的 RPC。仓库中 apps/vscode/proto/cline/ 目录下按功能域组织了common.proto、mcp.proto、checkpoints.proto、models.proto、marketplace.proto等文件general.md 记录了完整流程proto 变更后运行bun run protos会生成src/shared/proto/共享类型、src/generated/grpc-js/服务实现、src/generated/nice-grpc/Promise 客户端等目录——这正是架构图中WebviewProvider --|postMessage| ExtStateContext双向边的工程实现。三、API Provider 系统多模型接入的模块化设计Cline 通过模块化的 API Provider 系统支持多家 AI 服务商。每个 Provider 是一个独立模块遵循统一接口。整个 API 子系统由四部分构成API HandlersProvider 特定实现API Transformers流式响应转换工具API Configuration用户的 API Key 与端点设置API Factory构建函数按配置创建合适的 handler文档列出的关键 Provider 包括AnthropicClaude 模型直连OpenRouter聚合多模型服务商的元 ProviderAWS Bedrock接入 Amazon 的 AI 服务GeminiGoogle 模型Cerebras高性能推理Llama、Qwen、DeepSeek 模型Ollama/LM Studio本地模型托管VSCode LMVSCode 内置语言模型从源码结构看这一子系统当前已迁入 SDK 包apps/vscode/src/core/api/index.ts 的头部注释明确说明buildApiHandler现在通过 Cline SDK 路由推理请求位于apps/vscode/src/sdk/sdk-api-handler.ts并且该 barrel 文件刻意保持 types-only避免把整个 SDK 运行时依赖图拉入所有类型导入方。Provider 的具体实现位于 sdk/packages/llms/src/providers/其中可以看到ai-sdk.ts、factory-registry.ts、builtins.ts、gateway.ts、error-classification.ts等模块——与文档描述的Handler Factory 错误处理结构一一对应。API 配置的安全管理配置管理遵循密钥与配置分离原则API Key 存入 VSCode Secrets Storage模型选择与非敏感设置存入 Global StateController 负责 Provider 切换与配置更新系统层面支持API Key 安全存储、模型选择与配置、自动重试与错误处理、Token 用量统计与成本计算、上下文窗口管理。Plan/Act 双模型配置Cline 支持为 Plan 与 Act 模式分别配置模型规划与执行可以使用不同模型切换模式时系统保留各自已选的模型Controller 处理模式切换并相应更新 API 配置四、Task 执行系统核心循环、流式呈现与容错Task 类负责执行 AI 请求与工具操作。每个任务运行在独立的 Task 实例中保证隔离与状态管理的正确性。4.1 任务执行主循环核心执行循环的模式如下继承自原文档展示请求 → 流式解析 → 工具执行 → 递归续跑的骨架class Task { async initiateTaskLoop(userContent: UserContent, isNewTask: boolean) { while (!this.abort) { // 1. Make API request and stream response const stream this.attemptApiRequest() // 2. Parse and present content blocks for await (const chunk of stream) { switch (chunk.type) { case text: // Parse into content blocks this.assistantMessageContent parseAssistantMessageV2(chunk.text) // Present blocks to user await this.presentAssistantMessage() break } } // 3. Wait for tool execution to complete await pWaitFor(() this.userMessageContentReady) // 4. Continue loop with tool result const recDidEndLoop await this.recursivelyMakeClineRequests( this.userMessageContent ) } } }这个循环体现了典型的 Agent 编排模式模型输出内容块文本或工具调用工具执行结果作为userMessageContent回填对话历史再次进入 API 请求直到recursivelyMakeClineRequests判定结束或用户中止。4.2 消息流式呈现系统流式系统处理实时更新与部分内容关键是呈现锁防止竞态class Task { async presentAssistantMessage() { // Handle streaming locks to prevent race conditions if (this.presentAssistantMessageLocked) { this.presentAssistantMessageHasPendingUpdates true return } this.presentAssistantMessageLocked true // Present current content block const block this.assistantMessageContent[this.currentStreamingContentIndex] // Handle different types of content switch (block.type) { case text: await this.say(text, content, undefined, block.partial) break case tool_use: // Handle tool execution break } // Move to next block if complete if (!block.partial) { this.currentStreamingContentIndex } } }presentAssistantMessageLockedpresentAssistantMessageHasPendingUpdates的组合保证同一时刻只有一个呈现流程在跑后续更新会被标记并在当前块完成后补发block.partial标志驱动增量推送 → 定稿后推进索引的流式语义。4.3 工具执行的审批流工具遵循严格的执行模式先判断自动审批否则请求用户批准然后执行、存档检查点、回传结果class Task { async executeToolWithApproval(block: ToolBlock) { // 1. Check auto-approval settings if (this.shouldAutoApproveTool(block.name)) { await this.say(tool, message) this.consecutiveAutoApprovedRequestsCount } else { // 2. Request user approval const didApprove await askApproval(tool, message) if (!didApprove) { this.didRejectTool true return } } // 3. Execute tool const result await this.executeTool(block) // 4. Save checkpoint await this.saveCheckpoint() // 5. Return result to API return result } }注意consecutiveAutoApprovedRequestsCount字段——它用于追踪连续自动批准次数是防止 Agent 在无人监督下连续执行大量操作的防护机制的一部分。4.4 错误处理与资源清理class Task { async handleError(action: string, error: Error) { // 1. Check if task was abandoned if (this.abandoned) return // 2. Format error message const errorString Error ${action}: ${error.message} // 3. Present error to user await this.say(error, errorString) // 4. Add error to tool results pushToolResult(formatResponse.toolError(errorString)) // 5. Cleanup resources await this.diffViewProvider.revertChanges() await this.browserSession.closeBrowser() } }错误处理链条检查任务是否已被放弃 → 格式化 → 展示给用户 → 把错误作为工具结果回灌模型让模型有机会自我修正→ 回滚 diff 视图、关闭浏览器会话等资源清理。4.5 API 请求、上下文窗口与 Token 管理attemptApiRequest是重试、截断与流式恢复的集中点class Task { async *attemptApiRequest(previousApiReqIndex: number): ApiStream { // 1. Wait for MCP servers to connect await pWaitFor(() this.controllerRef.deref()?.mcpHub?.isConnecting ! true) // 2. Manage context window const previousRequest this.clineMessages[previousApiReqIndex] if (previousRequest?.text) { const { tokensIn, tokensOut } JSON.parse(previousRequest.text || {}) const totalTokens (tokensIn || 0) (tokensOut || 0) // Truncate conversation if approaching context limit if (totalTokens maxAllowedSize) { this.conversationHistoryDeletedRange this.contextManager.getNextTruncationRange( this.apiConversationHistory, this.conversationHistoryDeletedRange, totalTokens / 2 maxAllowedSize ? quarter : half ) } } // 3. Handle streaming with automatic retry try { this.isWaitingForFirstChunk true const firstChunk await iterator.next() yield firstChunk.value this.isWaitingForFirstChunk false // Stream remaining chunks yield* iterator } catch (error) { // 4. Error handling with retry if (isOpenRouter !this.didAutomaticallyRetryFailedApiRequest) { await setTimeoutPromise(1000) this.didAutomaticallyRetryFailedApiRequest true yield* this.attemptApiRequest(previousApiReqIndex) return } // 5. Ask user to retry if automatic retry failed const { response } await this.ask( api_req_failed, this.formatErrorWithStatusCode(error) ) if (response yesButtonClicked) { await this.say(api_req_retried) yield* this.attemptApiRequest(previousApiReqIndex) return } } } }四大关键特性上下文窗口管理跨请求追踪 token 用量接近上限时自动截断对话保留关键上下文、释放空间适配不同模型的上下文尺寸流式架构实时分块处理、部分内容处理、竞态预防呈现锁、流式过程中的错误恢复。代码中先取出firstChunk再yield*剩余迭代器的写法正是为了区分首块超时可自动重试与流中断需要用户介入两类故障错误处理瞬时故障自动重试如 OpenRouter 场景下等待 1 秒后递归重试一次持续性问题弹出api_req_failed询问用户是否重试详细的状态码错误报告失败后的状态清理Token 追踪每请求粒度计数、累计用量追踪、成本计算、缓存命中监控4.6 上下文管理系统ContextManagerContext Manager 负责对话历史截断防止上下文窗口溢出。它确保长对话始终处于模型上下文限制之内同时保留关键上下文。关键特性模型感知尺寸按模型动态调整——DeepSeek 64K、多数模型 128K、Claude 200K主动截断监控 token 用量接近上限时预先截断保留 27K–40K token 缓冲视模型而定智能保留截断时始终保留原始任务消息并维持用户/助手对话结构完整自适应策略按上下文压力选择截断力度——中等压力移除一半对话严重压力移除四分之三对应上文getNextTruncationRange的half/quarter参数错误恢复针对各 Provider 的上下文窗口错误做专门检测必要时自动重试并采用更激进的截断4.7 任务状态持久化与恢复class Task { async resumeTaskFromHistory() { // 1. Load saved state this.clineMessages await getSavedClineMessages(this.getContext(), this.taskId) this.apiConversationHistory await getSavedApiConversationHistory(this.getContext(), this.taskId) // 2. Handle interrupted tool executions const lastMessage this.apiConversationHistory[this.apiConversationHistory.length - 1] if (lastMessage.role assistant) { const toolUseBlocks content.filter(block block.type tool_use) if (toolUseBlocks.length 0) { // Add interrupted tool responses const toolResponses toolUseBlocks.map(block ({ type: tool_result, tool_use_id: block.id, content: Task was interrupted before this tool call could be completed. })) modifiedOldUserContent [...toolResponses] } } // 3. Notify about interruption const agoText this.getTimeAgoText(lastMessage?.ts) newUserContent.push({ type: text, text: [TASK RESUMPTION] This task was interrupted ${agoText}. It may or may not be complete, so please reassess the task context. }) // 4. Resume task execution await this.initiateTaskLoop(newUserContent, false) } private async saveTaskState() { // Save conversation history await saveApiConversationHistory(this.getContext(), this.taskId, this.apiConversationHistory) await saveClineMessages(this.getContext(), this.taskId, this.clineMessages) // Create checkpoint const commitHash await this.checkpointTracker?.commit() // Update task history await this.controllerRef.deref()?.updateTaskHistory({ id: this.taskId, ts: lastMessage.ts, task: taskMessage.text, // ... other metadata }) } }状态管理的关键方面任务持久化每个任务有唯一 ID 与专属存储目录每条消息后保存对话历史文件变更通过 Git 检查点追踪终端输出与浏览器状态也被保留状态恢复任务可从任意点恢复被中断的工具调用会被优雅处理为未完成的tool_use块补一条任务被中断的tool_result保证对话协议合法文件变更可从检查点还原上下文跨 VSCode 会话保留工作区同步Git 追踪文件变更工具执行后创建检查点可恢复到任意检查点、可在检查点之间对比错误恢复失败的 API 请求可重试被中断的工具执行被明确标记资源被妥善清理用户获知状态变化恢复流程中最有工程价值的是中断工具调用补全Anthropic 协议要求每个tool_use必须有对应tool_result否则后续请求会直接报错——resumeTaskFromHistory通过在历史尾部注入占位tool_result解决了这个问题并追加[TASK RESUMPTION]提示让模型重新评估任务上下文。五、Plan/Act 双模式系统Cline 实现了将规划与执行显式分离的双模式系统。模式架构模式状态存储在 Controller 状态中的chatSettings.mode模式切换由 Controller 的togglePlanActModeWithChatSettings处理模式特定模型可选地为每种模式配置不同模型模式特定提示规划与执行使用不同的系统提示词模式切换流程切换时依次发生当前模型配置保存到对应模式的专属状态恢复目标模式之前保存的模型配置Task 实例更新为新模式Webview 收到模式变更通知捕获遥测事件用于分析Plan 模式与 Act 模式的分工Plan 模式面向信息收集与上下文构建、提出澄清性问题、制定详细执行计划、与用户讨论方案。此模式下 AI 使用plan_mode_respond工具进行对话式规划而不执行任何变更动作。Act 模式面向执行计划中的动作、用工具修改文件/运行命令、实现方案、给出结果与完成反馈。此模式下 AI 可访问除plan_mode_respond之外的全部工具聚焦实现而非讨论。用户侧的详细说明可参见官方文档 Plan Act Mode其中强调 Plan 模式可以读代码、搜索、讨论策略但不能修改文件——这一约束是有意为之保证对话聚焦于理解与规划。六、数据流与支撑子系统Controller 的中心角色Controller 是所有持久化状态的单一事实来源管理 VSCode global state 与 secrets 存储协调组件间状态更新保证 Webview 重载后状态一致性处理任务级状态持久化管理检查点的创建与恢复终端管理Task 类管理终端实例与命令执行命令输出实时流式回传给用户class Task { async executeCommandTool(command: string): Promise[boolean, ToolResponse] { // 1. Get or create terminal const terminalInfo await this.terminalManager.getOrCreateTerminal(cwd) terminalInfo.terminal.show() // 2. Execute command with output streaming const process this.terminalManager.runCommand(terminalInfo, command) // 3. Handle real-time output let result process.on(line, (line) { result line \n if (!didContinue) { sendCommandOutput(line) } else { this.say(command_output, line) } }) // 4. Wait for completion or user feedback let completed false process.once(completed, () { completed true }) await process // 5. Return result if (completed) { return [false, Command executed.\n${result}] } else { return [ false, Command is still running in the users terminal.\n${result}\n\nYou will be updated on the terminal status and new output in the future. ] } } }关键特性终端实例管理支持多终端、终端状态追踪busy/inactive、进程冷却监控、按终端维护输出历史命令执行实时输出流、用户反馈处理、进程状态监控、错误恢复。注意长命令不会阻塞任务循环——未完成时返回仍在运行后续会收到新输出的提示输出通过command_output消息异步回推浏览器会话管理Task 通过 Puppeteer 处理浏览器自动化class Task { async executeBrowserAction(action: BrowserAction): PromiseBrowserActionResult { switch (action) { case launch: // 1. Launch browser with fixed resolution await this.browserSession.launchBrowser() return await this.browserSession.navigateToUrl(url) case click: // 2. Handle click actions with coordinates return await this.browserSession.click(coordinate) case type: // 3. Handle keyboard input return await this.browserSession.type(text) case close: // 4. Clean up resources return await this.browserSession.closeBrowser() } } }要点固定 900x600 分辨率窗口保证截图坐标可预测、每个任务生命周期单实例、任务结束自动清理、控制台日志捕获交互层面支持坐标点击、键盘输入模拟、截图捕获与错误恢复。七、MCPModel Context Protocol集成MCP 架构MCP 子系统由五部分组成McpHub 类位于apps/vscode/src/services/mcp/McpHub.ts的中央管理器MCP 连接管理到外部 MCP 服务器的连接MCP 设置以 JSON 文件存储的配置MCP Marketplace可用 MCP 服务器的在线目录MCP 工具与资源已连接服务器暴露的能力McpHub 的职责管理 MCP 服务器连接生命周期、通过设置文件处理服务器配置、提供调用工具/访问资源的方法、实现 MCP 工具的自动审批设置、监控服务器健康并处理重连。MCP 服务器类型Cline 支持两类 MCP 服务器连接Stdio基于命令行、通过标准输入输出通信SSE基于 HTTP、通过 Server-Sent Events 通信这一点可直接从 McpHub.ts 的导入得到印证文件引入了modelcontextprotocol/sdk的Client、StdioClientTransport、SSEClientTransport以及StreamableHTTPClientTransport并定义了MIN_MCP_TIMEOUT_SECONDS/MAX_MCP_TIMEOUT_SECONDS超时边界——与文档所述支持设置超时与自动审批规则一致。服务器管理与工具集成McpHub 提供的方法覆盖发现并连接 MCP 服务器、监控服务器健康状态、按需重启服务器、管理服务器配置、设置超时与自动审批规则。Controller 通过一组细粒度 handler 暴露这些能力当前仓库 apps/vscode/src/core/controller/mcp/ 目录下可见restartMcpServer.ts、toggleMcpServer.ts、updateMcpTimeout.ts、toggleToolAutoApprove.ts、subscribeToMcpServers.ts等文件与文档描述一一对应。MCP 工具与 Task 执行系统的集成方式连接时自动发现并注册工具Task 通过 McpHub 调用 MCP 工具工具结果流式回传给 AI支持按工具粒度配置自动审批。MCP MarketplaceMarketplace 提供可用 MCP 服务器目录、一键安装、README 预览与服务器状态监控。其一键安装的实现路径在 Controller 中从 Marketplace 拉取服务器详情后不是直接执行安装脚本而是构造一段携带 GitHub 仓库地址的任务提示词交给initClineWithTask启动一个 Cline 任务——即由 Agent 依据 README 上下文自主完成服务器接入配置。Marketplace 侧 handler 位于 apps/vscode/src/core/controller/marketplace/。八、开发约定与贡献指南原文档结尾给出了一份面向贡献者的清单结合仓库内的其他开发规则文件.clinerules/ 目录可以完整还原本项目的工程约定核心扩展开发的Remember清单原文档逐条列出始终在扩展中持久化重要状态核心扩展遵循WebviewProvider → Controller → Task的流程为所有状态与消息使用恰当的类型处理错误与边界情况测试状态在 Webview 重载后的持久性遵循既有模式保持一致性把新代码放入合适的目录保持清晰的关注点分离把依赖安装进正确的 package.json添加新工具或 API Provider时应分别遵循src/integrations/与 API providers 目录中的既有模式确保代码有良好文档与恰当的错误处理。同时必须尊重.clineignore规则——该文件允许用户指定 Cline 不应访问的文件与目录新功能实现不得尝试读取或修改被忽略的文件。从配套规则文件补充的两条高信号约定来自 general.md新增全局状态键需要多步联动在src/shared/storage/state-keys.ts的类型定义中加键可附默认值/转换、通过StateManager的setGlobalState()/getGlobalStateKey()读写若键可从设置界面切换还需同时接线updateSettings.ts与updateSettingsCli.ts两条更新路径并把字段加入state.proto的UpdateSettingsRequest、getStateToPostToWebview()与 Webview 默认值中——漏掉任何一步都会造成开关在一个界面变了、后端却没变之类的静默故障全仓库使用 bun 管理依赖与任务统一使用bun run X/bun install/bunx bin构建验证脚本以package.json中实际定义的为准例如bun run compile而非bun run buildNode 仍是运行时VSCode Extension Host 与独立 cline-core 运行于 Node相关约定见 bun-and-node.md此外sdk-migration.md 说明了当前仓库的一个重要架构演进方向VSCode 扩展通过apps/vscode/src/sdk/下的适配层运行在 Cline SDKcline/core、cline/llms、cline/shared之上Webview 仍走 gRPC 通信适配层负责在 gRPC handler 与 SDK 调用之间做翻译——这解释了第四章中Task 执行循环 API 请求经由 SDK 路由的源码组织方式。九、小结Cline 扩展的架构可以浓缩为三条主线控制面extension.ts→WebviewProvider→Controller→Task的单向职责链Controller 作为状态单一事实来源统一 global state、workspace state 与 secrets 三类存储数据面Webview 与后端经 proto 定义的 gRPC 风格消息双向通信ExtensionStateContextuseExtensionState在前端形成类型安全的状态边界执行面以initiateTaskLoop为中心循环串联 API 流式请求、上下文窗口截断、工具审批执行、Git 检查点与任务恢复并由 McpHub 接入外部 MCP 生态对于要在该项目上开发功能的工程师最重要的实践原则是状态持久化必须经过 StateManager/存储键体系、新增设置要打通后端双更新路径 proto 往返 Webview 默认值全链路、新增 Provider 或工具要沿用对应目录的既有模式并在 Webview 重载场景下验证状态完整性。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cline VSCode 扩展架构深潜：WebviewProvider、Controller 与 Task 执行系统的全景解析
Cline VSCode 扩展架构深潜WebviewProvider、Controller 与 Task 执行系统的全景解析【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline本篇基于 Cline 仓库内部的开发指南 cline-overview.md 展开系统讲解 Cline VSCode 扩展的分层架构核心扩展后端 React Webview 前端、状态管理机制、多模型 API Provider 体系、Task 执行循环与 Plan/Act 双模式系统并结合当前仓库的实际源码位置apps/vscode/与sdk/packages/给出可验证的实现佐证。读完后你将理解一次用户输入 → 模型流式响应 → 工具执行 → 状态持久化在 Cline 内部如何流转以及在新功能开发中应遵循哪些状态管理与目录约定。一、项目总览与架构全景Cline 是一个基于 TypeScript 构建的 VSCode 扩展提供 AI 编码助手能力。它的架构遵循模块化分层模式核心扩展后端Extension Host 侧负责与 VSCode API、模型 API、MCP 服务器交互React Webview 前端负责用户可见的全部交互界面。两者之间通过 VSCode 的消息传递机制gRPC 风格的 proto 协议双向通信。原文档给出的完整架构图如下核心数据流ExtensionEntry → WebviewProvider → Controller → Task以及 Webview 侧 React App → ExtensionStateContext → Components路径说明原文档中的src/...与webview-ui/...路径对应当前 monorepo 中的 apps/vscode/src/extension.ts、apps/vscode/src/core/webview/index.ts、apps/vscode/src/core/controller/index.ts、apps/vscode/src/services/mcp/McpHub.ts 与 apps/vscode/webview-ui/src/App.tsx。这些文件均已确认存在于当前仓库。二、核心概念定义与分层职责原文档对四个关键概念给出了精确定义这是理解整个系统的词汇表概念定义与职责Core Extension核心扩展src目录内的一切按模块化组件组织Core Extension State核心扩展状态由Controller类管理作为扩展状态的单一事实来源管理 global state、workspace state、secrets 等多种持久化存储负责将状态分发到核心扩展与 Webview 两侧并协调多实例间的一致性API 配置、任务历史、设置、MCP 配置等WebviewWebview 前端webview-ui目录内的一切即用户可见的全部 React 视图与交互组件Webview StateWebview 状态由ExtensionStateContext通过 Context Provider 模式提供维护 UI 本地状态、处理消息事件实时更新与流式内容的部分更新并以自定义 HookuseExtensionState提供类型安全的状态访问核心扩展的三层调用链核心扩展遵循清晰的层级结构WebviewProviderapps/vscode/src/core/webview/index.ts管理 Webview 生命周期与通信Controllerapps/vscode/src/core/controller/index.ts处理 Webview 消息与任务管理Task执行 API 请求与工具操作这种分层带来明确的关注点分离WebviewProvider 只关心 VSCode Webview 集成Controller 负责状态管理与任务协调Task 负责 AI 请求与工具操作的实际执行。从入口文件 extension.ts 的activate流程可以印证这条链路扩展激活时先通过setupHostProvider注册宿主能力再执行旧版 VSCode 原生存储到共享文件存储的迁移exportVSCodeStorageToSharedFiles随后调用initialize(storageContext)创建 Webview 并注册 sidebar 视图——返回的webview.controller正是后续所有命令如 PlusButton、AddToChat、FixWithCline操作的中央对象。Controller 管理的三类持久化存储Controller管理三类持久化存储Global State跨所有 VSCode 实例共享用于全局设置与数据Workspace State特定于当前工作区用于任务相关数据与设置SecretsAPI Key 等敏感信息的加密存储实例间的状态同步依靠四类机制基于文件的任务历史与对话数据存储、VSCode global state API设置与配置、Secrets 存储敏感信息、以及文件变更与配置更新的事件监听。当前仓库中这一设计有直接佐证state-keys.ts 文件头注释明确自称是SINGLE SOURCE OF TRUTH FOR STORAGE KEYS存储键的单一事实来源集中定义键的类型、默认值与元数据并说明新增字段后会通过scripts/generate-state-proto.mjs自动重新生成proto/cline/state.proto。同时 general.md 记录了更进一步的演进持久化状态已改为由StateManager以文件为底层存储内存缓存在initialize()时加载不再直接读写 VSCodeExtensionContext的原生存储——后者仅作为旧版迁移数据源。这解释了架构图上 VSCode Global State / Secrets Storage 框旁为何还并存 Per-Task Files History 的 Task Storage。Webview 侧的 ExtensionStateContextExtensionStateContextapps/vscode/webview-ui/src/context/ExtensionStateContext.tsx通过 Context Provider 模式向 React 组件提供扩展状态上下文内容包括扩展版本号消息messages任务历史主题themeAPI 配置MCP 服务器Marketplace 目录工作区文件路径它通过 VSCode 消息传递机制与核心扩展同步并以自定义 Hook 提供类型安全访问——当前源码中useExtensionState位于该文件的第 1018 行附近且在 Provider 之外调用会直接抛出错误强制约束了使用方式。它同时承担四类职责消息事件驱动的实时状态更新、流式内容的部分消息更新、通过 setter 方法修改状态、以及经 Hook 的类型安全读取。值得注意的是Webview 与后端的通信并非散落的postMessage而是 proto 定义的 RPC。仓库中 apps/vscode/proto/cline/ 目录下按功能域组织了common.proto、mcp.proto、checkpoints.proto、models.proto、marketplace.proto等文件general.md 记录了完整流程proto 变更后运行bun run protos会生成src/shared/proto/共享类型、src/generated/grpc-js/服务实现、src/generated/nice-grpc/Promise 客户端等目录——这正是架构图中WebviewProvider --|postMessage| ExtStateContext双向边的工程实现。三、API Provider 系统多模型接入的模块化设计Cline 通过模块化的 API Provider 系统支持多家 AI 服务商。每个 Provider 是一个独立模块遵循统一接口。整个 API 子系统由四部分构成API HandlersProvider 特定实现API Transformers流式响应转换工具API Configuration用户的 API Key 与端点设置API Factory构建函数按配置创建合适的 handler文档列出的关键 Provider 包括AnthropicClaude 模型直连OpenRouter聚合多模型服务商的元 ProviderAWS Bedrock接入 Amazon 的 AI 服务GeminiGoogle 模型Cerebras高性能推理Llama、Qwen、DeepSeek 模型Ollama/LM Studio本地模型托管VSCode LMVSCode 内置语言模型从源码结构看这一子系统当前已迁入 SDK 包apps/vscode/src/core/api/index.ts 的头部注释明确说明buildApiHandler现在通过 Cline SDK 路由推理请求位于apps/vscode/src/sdk/sdk-api-handler.ts并且该 barrel 文件刻意保持 types-only避免把整个 SDK 运行时依赖图拉入所有类型导入方。Provider 的具体实现位于 sdk/packages/llms/src/providers/其中可以看到ai-sdk.ts、factory-registry.ts、builtins.ts、gateway.ts、error-classification.ts等模块——与文档描述的Handler Factory 错误处理结构一一对应。API 配置的安全管理配置管理遵循密钥与配置分离原则API Key 存入 VSCode Secrets Storage模型选择与非敏感设置存入 Global StateController 负责 Provider 切换与配置更新系统层面支持API Key 安全存储、模型选择与配置、自动重试与错误处理、Token 用量统计与成本计算、上下文窗口管理。Plan/Act 双模型配置Cline 支持为 Plan 与 Act 模式分别配置模型规划与执行可以使用不同模型切换模式时系统保留各自已选的模型Controller 处理模式切换并相应更新 API 配置四、Task 执行系统核心循环、流式呈现与容错Task 类负责执行 AI 请求与工具操作。每个任务运行在独立的 Task 实例中保证隔离与状态管理的正确性。4.1 任务执行主循环核心执行循环的模式如下继承自原文档展示请求 → 流式解析 → 工具执行 → 递归续跑的骨架class Task { async initiateTaskLoop(userContent: UserContent, isNewTask: boolean) { while (!this.abort) { // 1. Make API request and stream response const stream this.attemptApiRequest() // 2. Parse and present content blocks for await (const chunk of stream) { switch (chunk.type) { case text: // Parse into content blocks this.assistantMessageContent parseAssistantMessageV2(chunk.text) // Present blocks to user await this.presentAssistantMessage() break } } // 3. Wait for tool execution to complete await pWaitFor(() this.userMessageContentReady) // 4. Continue loop with tool result const recDidEndLoop await this.recursivelyMakeClineRequests( this.userMessageContent ) } } }这个循环体现了典型的 Agent 编排模式模型输出内容块文本或工具调用工具执行结果作为userMessageContent回填对话历史再次进入 API 请求直到recursivelyMakeClineRequests判定结束或用户中止。4.2 消息流式呈现系统流式系统处理实时更新与部分内容关键是呈现锁防止竞态class Task { async presentAssistantMessage() { // Handle streaming locks to prevent race conditions if (this.presentAssistantMessageLocked) { this.presentAssistantMessageHasPendingUpdates true return } this.presentAssistantMessageLocked true // Present current content block const block this.assistantMessageContent[this.currentStreamingContentIndex] // Handle different types of content switch (block.type) { case text: await this.say(text, content, undefined, block.partial) break case tool_use: // Handle tool execution break } // Move to next block if complete if (!block.partial) { this.currentStreamingContentIndex } } }presentAssistantMessageLockedpresentAssistantMessageHasPendingUpdates的组合保证同一时刻只有一个呈现流程在跑后续更新会被标记并在当前块完成后补发block.partial标志驱动增量推送 → 定稿后推进索引的流式语义。4.3 工具执行的审批流工具遵循严格的执行模式先判断自动审批否则请求用户批准然后执行、存档检查点、回传结果class Task { async executeToolWithApproval(block: ToolBlock) { // 1. Check auto-approval settings if (this.shouldAutoApproveTool(block.name)) { await this.say(tool, message) this.consecutiveAutoApprovedRequestsCount } else { // 2. Request user approval const didApprove await askApproval(tool, message) if (!didApprove) { this.didRejectTool true return } } // 3. Execute tool const result await this.executeTool(block) // 4. Save checkpoint await this.saveCheckpoint() // 5. Return result to API return result } }注意consecutiveAutoApprovedRequestsCount字段——它用于追踪连续自动批准次数是防止 Agent 在无人监督下连续执行大量操作的防护机制的一部分。4.4 错误处理与资源清理class Task { async handleError(action: string, error: Error) { // 1. Check if task was abandoned if (this.abandoned) return // 2. Format error message const errorString Error ${action}: ${error.message} // 3. Present error to user await this.say(error, errorString) // 4. Add error to tool results pushToolResult(formatResponse.toolError(errorString)) // 5. Cleanup resources await this.diffViewProvider.revertChanges() await this.browserSession.closeBrowser() } }错误处理链条检查任务是否已被放弃 → 格式化 → 展示给用户 → 把错误作为工具结果回灌模型让模型有机会自我修正→ 回滚 diff 视图、关闭浏览器会话等资源清理。4.5 API 请求、上下文窗口与 Token 管理attemptApiRequest是重试、截断与流式恢复的集中点class Task { async *attemptApiRequest(previousApiReqIndex: number): ApiStream { // 1. Wait for MCP servers to connect await pWaitFor(() this.controllerRef.deref()?.mcpHub?.isConnecting ! true) // 2. Manage context window const previousRequest this.clineMessages[previousApiReqIndex] if (previousRequest?.text) { const { tokensIn, tokensOut } JSON.parse(previousRequest.text || {}) const totalTokens (tokensIn || 0) (tokensOut || 0) // Truncate conversation if approaching context limit if (totalTokens maxAllowedSize) { this.conversationHistoryDeletedRange this.contextManager.getNextTruncationRange( this.apiConversationHistory, this.conversationHistoryDeletedRange, totalTokens / 2 maxAllowedSize ? quarter : half ) } } // 3. Handle streaming with automatic retry try { this.isWaitingForFirstChunk true const firstChunk await iterator.next() yield firstChunk.value this.isWaitingForFirstChunk false // Stream remaining chunks yield* iterator } catch (error) { // 4. Error handling with retry if (isOpenRouter !this.didAutomaticallyRetryFailedApiRequest) { await setTimeoutPromise(1000) this.didAutomaticallyRetryFailedApiRequest true yield* this.attemptApiRequest(previousApiReqIndex) return } // 5. Ask user to retry if automatic retry failed const { response } await this.ask( api_req_failed, this.formatErrorWithStatusCode(error) ) if (response yesButtonClicked) { await this.say(api_req_retried) yield* this.attemptApiRequest(previousApiReqIndex) return } } } }四大关键特性上下文窗口管理跨请求追踪 token 用量接近上限时自动截断对话保留关键上下文、释放空间适配不同模型的上下文尺寸流式架构实时分块处理、部分内容处理、竞态预防呈现锁、流式过程中的错误恢复。代码中先取出firstChunk再yield*剩余迭代器的写法正是为了区分首块超时可自动重试与流中断需要用户介入两类故障错误处理瞬时故障自动重试如 OpenRouter 场景下等待 1 秒后递归重试一次持续性问题弹出api_req_failed询问用户是否重试详细的状态码错误报告失败后的状态清理Token 追踪每请求粒度计数、累计用量追踪、成本计算、缓存命中监控4.6 上下文管理系统ContextManagerContext Manager 负责对话历史截断防止上下文窗口溢出。它确保长对话始终处于模型上下文限制之内同时保留关键上下文。关键特性模型感知尺寸按模型动态调整——DeepSeek 64K、多数模型 128K、Claude 200K主动截断监控 token 用量接近上限时预先截断保留 27K–40K token 缓冲视模型而定智能保留截断时始终保留原始任务消息并维持用户/助手对话结构完整自适应策略按上下文压力选择截断力度——中等压力移除一半对话严重压力移除四分之三对应上文getNextTruncationRange的half/quarter参数错误恢复针对各 Provider 的上下文窗口错误做专门检测必要时自动重试并采用更激进的截断4.7 任务状态持久化与恢复class Task { async resumeTaskFromHistory() { // 1. Load saved state this.clineMessages await getSavedClineMessages(this.getContext(), this.taskId) this.apiConversationHistory await getSavedApiConversationHistory(this.getContext(), this.taskId) // 2. Handle interrupted tool executions const lastMessage this.apiConversationHistory[this.apiConversationHistory.length - 1] if (lastMessage.role assistant) { const toolUseBlocks content.filter(block block.type tool_use) if (toolUseBlocks.length 0) { // Add interrupted tool responses const toolResponses toolUseBlocks.map(block ({ type: tool_result, tool_use_id: block.id, content: Task was interrupted before this tool call could be completed. })) modifiedOldUserContent [...toolResponses] } } // 3. Notify about interruption const agoText this.getTimeAgoText(lastMessage?.ts) newUserContent.push({ type: text, text: [TASK RESUMPTION] This task was interrupted ${agoText}. It may or may not be complete, so please reassess the task context. }) // 4. Resume task execution await this.initiateTaskLoop(newUserContent, false) } private async saveTaskState() { // Save conversation history await saveApiConversationHistory(this.getContext(), this.taskId, this.apiConversationHistory) await saveClineMessages(this.getContext(), this.taskId, this.clineMessages) // Create checkpoint const commitHash await this.checkpointTracker?.commit() // Update task history await this.controllerRef.deref()?.updateTaskHistory({ id: this.taskId, ts: lastMessage.ts, task: taskMessage.text, // ... other metadata }) } }状态管理的关键方面任务持久化每个任务有唯一 ID 与专属存储目录每条消息后保存对话历史文件变更通过 Git 检查点追踪终端输出与浏览器状态也被保留状态恢复任务可从任意点恢复被中断的工具调用会被优雅处理为未完成的tool_use块补一条任务被中断的tool_result保证对话协议合法文件变更可从检查点还原上下文跨 VSCode 会话保留工作区同步Git 追踪文件变更工具执行后创建检查点可恢复到任意检查点、可在检查点之间对比错误恢复失败的 API 请求可重试被中断的工具执行被明确标记资源被妥善清理用户获知状态变化恢复流程中最有工程价值的是中断工具调用补全Anthropic 协议要求每个tool_use必须有对应tool_result否则后续请求会直接报错——resumeTaskFromHistory通过在历史尾部注入占位tool_result解决了这个问题并追加[TASK RESUMPTION]提示让模型重新评估任务上下文。五、Plan/Act 双模式系统Cline 实现了将规划与执行显式分离的双模式系统。模式架构模式状态存储在 Controller 状态中的chatSettings.mode模式切换由 Controller 的togglePlanActModeWithChatSettings处理模式特定模型可选地为每种模式配置不同模型模式特定提示规划与执行使用不同的系统提示词模式切换流程切换时依次发生当前模型配置保存到对应模式的专属状态恢复目标模式之前保存的模型配置Task 实例更新为新模式Webview 收到模式变更通知捕获遥测事件用于分析Plan 模式与 Act 模式的分工Plan 模式面向信息收集与上下文构建、提出澄清性问题、制定详细执行计划、与用户讨论方案。此模式下 AI 使用plan_mode_respond工具进行对话式规划而不执行任何变更动作。Act 模式面向执行计划中的动作、用工具修改文件/运行命令、实现方案、给出结果与完成反馈。此模式下 AI 可访问除plan_mode_respond之外的全部工具聚焦实现而非讨论。用户侧的详细说明可参见官方文档 Plan Act Mode其中强调 Plan 模式可以读代码、搜索、讨论策略但不能修改文件——这一约束是有意为之保证对话聚焦于理解与规划。六、数据流与支撑子系统Controller 的中心角色Controller 是所有持久化状态的单一事实来源管理 VSCode global state 与 secrets 存储协调组件间状态更新保证 Webview 重载后状态一致性处理任务级状态持久化管理检查点的创建与恢复终端管理Task 类管理终端实例与命令执行命令输出实时流式回传给用户class Task { async executeCommandTool(command: string): Promise[boolean, ToolResponse] { // 1. Get or create terminal const terminalInfo await this.terminalManager.getOrCreateTerminal(cwd) terminalInfo.terminal.show() // 2. Execute command with output streaming const process this.terminalManager.runCommand(terminalInfo, command) // 3. Handle real-time output let result process.on(line, (line) { result line \n if (!didContinue) { sendCommandOutput(line) } else { this.say(command_output, line) } }) // 4. Wait for completion or user feedback let completed false process.once(completed, () { completed true }) await process // 5. Return result if (completed) { return [false, Command executed.\n${result}] } else { return [ false, Command is still running in the users terminal.\n${result}\n\nYou will be updated on the terminal status and new output in the future. ] } } }关键特性终端实例管理支持多终端、终端状态追踪busy/inactive、进程冷却监控、按终端维护输出历史命令执行实时输出流、用户反馈处理、进程状态监控、错误恢复。注意长命令不会阻塞任务循环——未完成时返回仍在运行后续会收到新输出的提示输出通过command_output消息异步回推浏览器会话管理Task 通过 Puppeteer 处理浏览器自动化class Task { async executeBrowserAction(action: BrowserAction): PromiseBrowserActionResult { switch (action) { case launch: // 1. Launch browser with fixed resolution await this.browserSession.launchBrowser() return await this.browserSession.navigateToUrl(url) case click: // 2. Handle click actions with coordinates return await this.browserSession.click(coordinate) case type: // 3. Handle keyboard input return await this.browserSession.type(text) case close: // 4. Clean up resources return await this.browserSession.closeBrowser() } } }要点固定 900x600 分辨率窗口保证截图坐标可预测、每个任务生命周期单实例、任务结束自动清理、控制台日志捕获交互层面支持坐标点击、键盘输入模拟、截图捕获与错误恢复。七、MCPModel Context Protocol集成MCP 架构MCP 子系统由五部分组成McpHub 类位于apps/vscode/src/services/mcp/McpHub.ts的中央管理器MCP 连接管理到外部 MCP 服务器的连接MCP 设置以 JSON 文件存储的配置MCP Marketplace可用 MCP 服务器的在线目录MCP 工具与资源已连接服务器暴露的能力McpHub 的职责管理 MCP 服务器连接生命周期、通过设置文件处理服务器配置、提供调用工具/访问资源的方法、实现 MCP 工具的自动审批设置、监控服务器健康并处理重连。MCP 服务器类型Cline 支持两类 MCP 服务器连接Stdio基于命令行、通过标准输入输出通信SSE基于 HTTP、通过 Server-Sent Events 通信这一点可直接从 McpHub.ts 的导入得到印证文件引入了modelcontextprotocol/sdk的Client、StdioClientTransport、SSEClientTransport以及StreamableHTTPClientTransport并定义了MIN_MCP_TIMEOUT_SECONDS/MAX_MCP_TIMEOUT_SECONDS超时边界——与文档所述支持设置超时与自动审批规则一致。服务器管理与工具集成McpHub 提供的方法覆盖发现并连接 MCP 服务器、监控服务器健康状态、按需重启服务器、管理服务器配置、设置超时与自动审批规则。Controller 通过一组细粒度 handler 暴露这些能力当前仓库 apps/vscode/src/core/controller/mcp/ 目录下可见restartMcpServer.ts、toggleMcpServer.ts、updateMcpTimeout.ts、toggleToolAutoApprove.ts、subscribeToMcpServers.ts等文件与文档描述一一对应。MCP 工具与 Task 执行系统的集成方式连接时自动发现并注册工具Task 通过 McpHub 调用 MCP 工具工具结果流式回传给 AI支持按工具粒度配置自动审批。MCP MarketplaceMarketplace 提供可用 MCP 服务器目录、一键安装、README 预览与服务器状态监控。其一键安装的实现路径在 Controller 中从 Marketplace 拉取服务器详情后不是直接执行安装脚本而是构造一段携带 GitHub 仓库地址的任务提示词交给initClineWithTask启动一个 Cline 任务——即由 Agent 依据 README 上下文自主完成服务器接入配置。Marketplace 侧 handler 位于 apps/vscode/src/core/controller/marketplace/。八、开发约定与贡献指南原文档结尾给出了一份面向贡献者的清单结合仓库内的其他开发规则文件.clinerules/ 目录可以完整还原本项目的工程约定核心扩展开发的Remember清单原文档逐条列出始终在扩展中持久化重要状态核心扩展遵循WebviewProvider → Controller → Task的流程为所有状态与消息使用恰当的类型处理错误与边界情况测试状态在 Webview 重载后的持久性遵循既有模式保持一致性把新代码放入合适的目录保持清晰的关注点分离把依赖安装进正确的 package.json添加新工具或 API Provider时应分别遵循src/integrations/与 API providers 目录中的既有模式确保代码有良好文档与恰当的错误处理。同时必须尊重.clineignore规则——该文件允许用户指定 Cline 不应访问的文件与目录新功能实现不得尝试读取或修改被忽略的文件。从配套规则文件补充的两条高信号约定来自 general.md新增全局状态键需要多步联动在src/shared/storage/state-keys.ts的类型定义中加键可附默认值/转换、通过StateManager的setGlobalState()/getGlobalStateKey()读写若键可从设置界面切换还需同时接线updateSettings.ts与updateSettingsCli.ts两条更新路径并把字段加入state.proto的UpdateSettingsRequest、getStateToPostToWebview()与 Webview 默认值中——漏掉任何一步都会造成开关在一个界面变了、后端却没变之类的静默故障全仓库使用 bun 管理依赖与任务统一使用bun run X/bun install/bunx bin构建验证脚本以package.json中实际定义的为准例如bun run compile而非bun run buildNode 仍是运行时VSCode Extension Host 与独立 cline-core 运行于 Node相关约定见 bun-and-node.md此外sdk-migration.md 说明了当前仓库的一个重要架构演进方向VSCode 扩展通过apps/vscode/src/sdk/下的适配层运行在 Cline SDKcline/core、cline/llms、cline/shared之上Webview 仍走 gRPC 通信适配层负责在 gRPC handler 与 SDK 调用之间做翻译——这解释了第四章中Task 执行循环 API 请求经由 SDK 路由的源码组织方式。九、小结Cline 扩展的架构可以浓缩为三条主线控制面extension.ts→WebviewProvider→Controller→Task的单向职责链Controller 作为状态单一事实来源统一 global state、workspace state 与 secrets 三类存储数据面Webview 与后端经 proto 定义的 gRPC 风格消息双向通信ExtensionStateContextuseExtensionState在前端形成类型安全的状态边界执行面以initiateTaskLoop为中心循环串联 API 流式请求、上下文窗口截断、工具审批执行、Git 检查点与任务恢复并由 McpHub 接入外部 MCP 生态对于要在该项目上开发功能的工程师最重要的实践原则是状态持久化必须经过 StateManager/存储键体系、新增设置要打通后端双更新路径 proto 往返 Webview 默认值全链路、新增 Provider 或工具要沿用对应目录的既有模式并在 Webview 重载场景下验证状态完整性。【免费下载链接】clineAutonomous coding agent as an SDK, IDE extension, or CLI assistant.项目地址: https://gitcode.com/GitHub_Trending/cl/cline创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考