这几天开始尝试一些 VS Code Coding 的插件，有一些我看介绍已经称之为 Agent 了。我现在对这个 Agent 基本的概念还不是特别明确，但是后续这肯定会是我研究学习的一个主要的对象。

今天工作期间有一段时间头脑比较昏沉，为了能够让自己进入状态，喝了一杯咖啡，顺便拿了一张纸、一支笔，在纸上写写画画，整理了一下最近两天自己使用一些 AI 工具的相关体会。整理的内容我会直接以附件的形式，把相关的照片图片直接贴到下面。放到文章的最后。

我今天尝试的一个点是什么呢？就是把写的这个乱七八糟的草稿，直接让 AI 给我提取一下文字，然后总结一下相关的观点，整理一下。我感觉整理的还是比较到位的，中间有小小的错误，可能跟我写字写的不是很清晰有一定的关系。整理的内容具体如下，中间有修改的点全都用斜体标注了。

根据你提供的两张手写笔记图片，我为你整理并提取了核心内容。这是一份关于本地大模型部署与 AI Agent 工具（特别是 Cline）的使用体验总结。

以下是基于你的笔记内容整理的详细报告：

📝 AI Agent 与本地大模型使用体验总结

1. 核心观点与工具对比

• 首选工具： 经过实际体验，目前认为 Cline 是更好用、更智能的选择。相比之下，虽然 Cursor（识别错误，本来表达的是continue） 也是优秀的工具，但 Cline 在智能化体验和流畅度上更胜一筹，甚至让人感觉不再需要 Cursor（识别错误，本来表达的是continue）。
• 学习策略： 尽管 Cline 表现优异，但 Codex 等类似工具仍然值得学习，从中可以挖掘出有价值的技能和思路。
• 插件对比： 在 VS Code 插件方面，对比了 Cline 和 Continue。两者都尝试使用后，发现 Cline 的体验更具“智能感”。

2. 具体应用场景测试

在使用 Cline 进行实际任务时，观察到了以下显著优势：

• Python 脚本设计：
  • 自我修正能力： Cline 不仅能完成代码设计，还会主动进行自我检查和修正。
  • 自动化测试： 除了编写代码，它还会自动执行测试流程，确保代码可用性。
• 小型 C 语言模块设计：
  • 自动化流程： 相比 Continue，Cline 增加了自动检查（Check）和构建（Build）步骤。
  • 迭代修复： 当 Build 失败时，它能够自动进行迭代修改，直到成功。
• 文档编写：
  • 在放弃 Continue 后，尝试使用 Cline 编写文档，效果极佳。
  • 意外收获： 在写文档的过程中，Cline 甚至帮忙发现了之前的一个 Bug。

3. 模型选择与 Token 消耗分析

在底层模型的选择上，进行了多轮对比测试：

• 模型对比： 对比了 DeepSeek V4 Flash 和 A3B（注：此处可能指代某种 3B 参数量的本地小模型或特定版本-）（千问的3.6-35B-A3B）。
  • DeepSeek V4 Flash： 使用的是硅基流动的 API，Token 消耗较少。
  • A3B (本地模型)： 中间生成的代码曾出现错误（如括号不匹配），但最终通过迭代修改成功了。
• 结论： A3B 的表现至少证实了在本地运行小参数模型以节省 Token 的可行性。但在处理复杂任务（如 C 语言模块）时，Token 使用量依然较多。

4. 当前挑战与下一步计划

• 上下文限制： 目前面临的主要瓶颈是 32k 上下文的限制，这成为了一些测试的限制点。

补充说明： 这个32K是为了能够让本地的token生成速度达到80t/s以上而配置的，是否还能够扩充的同时保证速度还有待于验证。

• 优化目标： 接下来的重点是尝试优化配置，目标是让 A3B 模型支持更大的上下文窗口，以提升处理长任务的能力。

💡 总结摘要

“现在的体验来看，Cline 比 Continue 更流畅且智能，甚至在写代码时能自动排查 Bug 和进行自动化测试。虽然本地小模型（如 A3B）偶尔会有语法错误，但通过迭代也能完成任务，证明了省 Token 方案的可行性。目前的短板在于上下文长度，后续将重点解决 32k 上下文的限制问题。”

笔记里提到了‘32k上下文’这个痛点，需要我帮你找几个突破本地模型上下文限制的优化方案吗？

下面是我的两张乱写乱画: