如何让网站自适应屏幕营销推广案例

1. 源码位置：
CLine 是一个开源的 VSCode 插件，其完整源码托管在 GitHub 的 cline/cline 仓库中。这个仓库包含 CLine 的核心逻辑（TypeScript 编写），包括与 LLM 的对话控制、工具调用接口，以及 VSCode 插件前端等模块。

2. 核心代码分析：
CLine 采用“LLM + 工具”的 Agent 架构，核心通过循环与模型交互并调用工具完成用户任务。主要流程如下：

• 用户输入解析：
  当用户在聊天窗口输入任务时，CLine 会对输入进行预处理。它支持特殊语法引用项目资源，例如以 @ 符号引用文件或URL。收到输入后，CLine 的后台会将用户任务和相关上下文封装成结构化提示。例如，如果用户在输入中提到文件路径或URL，CLine 会自动读取相应文件内容或抓取网页内容，并将它们附加在提示中。同时，CLine 会收集当前项目环境信息（如当前工作目录的文件列表、已打开的编辑器标签、当前时间、模式等）作为环境详情插入提示。这一系列处理使得发给 LLM 的系统提示包含丰富的上下文（包括用户任务描述和项目状态），方便模型理解当前环境。模型的系统提示还定义了一套XML风格的工具调用格式，明确告诉模型如何请求使用工具。例如，系统提示中规定 execute_command 工具应使用如下格式输出：

  <execute_command><command>...命令...</command><requires_approval>true/false</requires_approval>
  </execute_command>
  

  每种可用工具（读/写文件、搜索、执行命令、MCP 扩展工具等）都在系统提示里有类似定义和示例，使模型严格按照这种标记格式请求工具。

• 对话与工具调用循环：
  CLine 使用递归循环来处理模型响应和工具调用。它会将用户输入和系统提示发送给 LLM，并流式接收模型的回复。CLine 将模型回复解析为内容块，例如普通文本块和工具调用块。当模型需要使用某个工具时，会在回复中输出相应的XML标签块（例如 <read_file>...</read_file> 或 <execute_command>...</execute_command>）。CLine 的核心类（src/core/Cline.ts）监测到回复中包含工具调用标记后，会暂停直接回答用户，而是先解析出工具名称和参数，准备调用内部工具逻辑（例如，当检测到 <execute_command>，会提取其中的命令字符串和是否需要用户确认；如果是 <read_file>，则提取文件路径参数）。为了安全起见，CLine 在调用工具前还会根据当前模式验证该工具是否被允许使用（例如某些模式下可能禁止执行终端命令）。

• 工具执行与结果处理：
  对于解析出的工具调用，CLine 调用了 executeToolWithApproval 方法来执行。该方法首先根据设置决定是否自动批准此工具操作。如果配置允许自动执行（如读文件这类安全操作），则直接进行；否则（比如执行终端命令或写文件），会通过 UI 提示用户确认。下面是 executeToolWithApproval 的关键逻辑摘录：

  async executeToolWithApproval(block: ToolBlock) {// 1. 检查是否自动批准if (this.shouldAutoApproveTool(block.name)) {await this.say("tool", message);  // 显示即将执行的工具操作this.consecutiveAutoApprovedRequestsCount++;} else {// 2. 请求用户确认const didApprove = await askApproval("tool", message);if (!didApprove) {this.didRejectTool = true;return;  // 用户拒绝，则中止工具执行}}// 3. 执行工具const result = await this.executeTool(block);// 4. 保存检查点（用于撤销）await this.saveCheckpoint();// 5. 将结果返回return result;
  }
  

  上述代码中，block 描述了模型请求的工具及参数；如果需要用户确认则调用 askApproval 弹出确认对话框。确认后，通过 this.executeTool(block) 调用相应的实现。CLine 针对不同工具在内部做了分发：例如，终端命令由 TerminalManager/TerminalProcess 组件执行（利用 VSCode 的终端集成）并捕获输出，文件读写由文件系统工具（如 src/utils/fs.ts 和 DiffViewProvider 等）处理。执行完工具后，CLine 会创建一个快照以便出错时回滚，然后将工具执行结果作为返回值。

• 继续对话：
  工具执行完毕后，CLine 将结果封装回对话，继续与模型交互。执行工具的方法返回结果字符串后，CLine 会将该结果作为新的“用户”消息插入会话，再次调用 LLM。这在代码中体现为再次调用 recursivelyMakeClineRequests，将之前工具的输出文本作为参数。例如，在执行完 <execute_command> 后，CLine 可能生成如下用户消息内容：

  [execute_command for 'npm install three @types/three'] Result:
  Command executed.
  Output:
  <命令输出日志>...
  found 0 vulnerabilities
  # VSCode Visible Files
  ... # Current Time ... # Current Mode ACT MODE
  

  如上所示，CLine 将工具名称、参数和执行结果组织成 特殊格式的用户消息 发回模型。这相当于模拟了“环境对话者”的角色——上一轮助手要求执行工具，现在这一轮用户把工具结果告诉它。代码中通过设置 this.userMessageContent 为结果并标记 Ready 后，再次进入递归对话循环，将结果发给模型。模型收到工具结果后，可以据此决定下一步操作或给出最终答案。

• 消息呈现与用户反馈：
  在整个过程中，CLine 一边执行后台逻辑，一边通过前端 Webview 界面向用户展示进展。例如，当模型请求执行一个命令时，聊天窗口会插入一条特殊消息如“🖥️ CLine 想要执行命令： npm install three ...”，等待用户确认。上述 executeToolWithApproval 中 this.say("tool", message) 就是将该工具调用请求显示在UI。如果用户确认或操作自动批准，执行结果（或错误信息）也会在聊天窗口展示在“Command Output”折叠区域。整个任务完成后，CLine 会将最终结果（例如修改过的代码片段或运行成功的提示）作为助手消息展示给用户。

综上，CLine的工作机制可以概括为：通过精心设计的系统提示，让模型以特定格式请求使用工具；扩展程序识别这些格式，调用对应本地/远程工具执行实际操作；然后将操作结果反馈给模型，形成一个闭环，直到模型生成最终解。这种架构实现了模型与外部环境的交互，使 AI 可以“思考-行动-再思考”，逐步完成复杂的编程任务。

3. 关键源码片段解析：

• 工具调用格式定义（提示词片段）:
  CLine 在系统提示中定义了XML风格的工具调用规范，如下面 execute_command 工具的用法示例所示：

  Usage:
  <execute_command><command>Your command here</command><requires_approval>true or false</requires_approval>
  </execute_command>
  

  解析: 这段提示指导 LLM 按上述格式请求执行终端命令，其中 <command> 包含具体命令字符串，<requires_approval> 指示是否需要用户确认。类似地，系统提示中还列出了 read_file、write_to_file、use_mcp_tool 等所有工具的 XML 格。通过这些约定，CLine 确保模型回复易于解析。

• 检测并执行工具调用:
  模型的回复被拆解成若干块进行处理。当遇到类型为“tool_use”的块时，CLine 调用 executeToolWithApproval 来处理。下面是该函数核心逻辑的摘录：

  if (this.shouldAutoApproveTool(block.name)) {// 自动批准，直接显示并执行await this.say("tool", message);
  } else {// 请求用户审批const didApprove = await askApproval("tool", message);if (!didApprove) {this.didRejectTool = true;return;  // 用户拒绝则终止}
  }
  // 执行工具并获取结果
  const result = await this.executeTool(block);
  await this.saveCheckpoint();  // 保存检查点
  return result;
  

  解析: 上面代码展示：如果配置或工具类型允许自动执行，则通过 say 方法直接把工具操作发送到UI显示（无需等待用户），然后继续执行工具；否则调用 askApproval 弹出确认对话框，用户拒绝则退出流程。接下来通过 executeTool(block) 实际执行模型请求的操作，并将结果返回。executeTool 内部根据 block.name 分发调用相应模块：例如若 block.name 是 "execute_command"，则调用终端集成模块执行命令并收集输出；若是 "read_file"，则调用文件系统读取模块获取文件内容，以字符串形式返回结果。这样，实现了对模型请求的具体动作的执行。

• 继续对话循环:
  工具执行完毕后，CLine 将结果包装成下一轮对话的用户消息，再次调用模型。代码中通过设置 this.userMessageContent 并调用递归函数继续对话来实现：

  // 等待工具结果准备好
  await pWaitFor(() => this.userMessageContentReady);
  // 将工具结果作为新一轮用户消息，递归调用模型
  const didEndLoop = await this.recursivelyMakeClineRequests(this.userMessageContent);
  

  解析: 上面摘自 Cline.ts 的主循环逻辑。this.userMessageContent 即存放了工具执行的输出文本（例如文件内容或命令行输出等），userMessageContentReady 表示结果已写入。然后调用 recursivelyMakeClineRequests(...) 将结果发送给 LLM，促使其依据新信息继续生成后续回答或下一步动作。这个递归循环会持续进行，直到模型不再请求新工具，转而给出最终答复。在整个过程中，CLine 还会动态调整对话历史以控制上下文长度（采用滑动窗口截断旧消息），并在每次工具交互后保存检查点方便出错恢复。

3. 工作机制总结：
综上，CLine 通过系统提示 + 解析器 + 工具执行器的配合，实现了聊天过程中的内部工具调用。模型在强指令的引导下，会输出特定格式的“请求”，CLine 插件捕获这些请求并调用 VSCode 环境的能力（文件系统、终端、浏览器等）完成实际操作，再将操作结果反馈给模型，形成一个闭环。整个架构确保每一步都有人工监控点（需要时征求用户确认），既保证了安全，又赋予了模型“执行环境”的代理能力。这种设计极大拓展了助手的能力边界——它不仅能回答问题，还能自主阅读/修改代码、运行构建、打开浏览器调试等，真正成为IDE中的智能代理。

4. 可扩展与优化方向：
CLine 的工具调用机制建立在Model Context Protocol (MCP) 标准之上，这意味着可以方便地接入自定义工具服务。例如，用户可以让 CLine “添加一个新工具”，模型会据此编写出符合 MCP 标准的服务器代码并注册到插件中，从而扩展其能力。今后可以考虑的扩展/优化包括：

• 更多工具类型：
  利用 MCP 扩展接口，集成更多开发相关的工具（如数据库查询、云服务操作等），让 AI 助手具备更广泛的操作能力。CLine 已支持模型自行创建新工具，未来这种自我进化能力可以进一步增强。

• 更细粒度的文件编辑：
  目前 CLine 在写入文件时通常让模型提供完整新文件内容（或用 diff 应用修改）。这有时会重写大量未变动的代码。一种优化方向是在插件侧计算差异，只应用必要改动，或让模型直接输出更小粒度的修改指令，以减少不必要的上下文占用和潜在错误。

• 上下文与记忆优化：
  CLine 已实现对长对话的截断策略。未来可引入更智能的上下文管理，如根据任务阶段有选择地提供关键信息，或结合向量数据库检索项目知识，从而在不丢失重要信息的前提下减少每轮prompt长度，降低API调用成本。

• 性能和健壮性：
  目前每轮工具调用都会产生一次新的LLM请求，复杂任务可能循环很多次，导致延迟和开销较高。可以探索批处理或并行某些操作的可能性，或利用模型的函数调用接口直接传输结构化结果而非文本嵌入，以减少格式解析的开销。另一个方向是在错误处理中更自动化，如检测出连续失败的操作时，引导模型反思策略或切换备用模型。

通过上述改进，CLine 有望变得更加强大和高效。例如，社区已经出现基于 CLine 思路的衍生项目（如 Roo-Cline）整合了多模型协作。总体而言，CLine 的源码实现展示了一种人机协作编程助手的雏形，其通过解析对话中的特殊标记实现工具调用的机制，为后续类似系统奠定了基础。开发者可以参考其架构，在自己的应用中定制类似的“工具调用”能力，将大模型与现有软件工具衔接起来。最终，这种可扩展的代理式对话机制将推动更高级的 AI 编程助手的发展。