本地AI如何直接修改代码：工具、模型、硬件配置与实战指南

🛠️ Cline：最直接的入门选择

• Cline可以读取项目文件、搜索代码库、应用Patch、创建文件并执行终端命令。面对“给登录系统增加记住我功能并运行测试”这类任务，它可以依次检查前端、认证逻辑和API，再根据测试结果继续修改。
• Plan模式适合先研究问题和设计方案，Act模式才会真正执行。若Agent只分析却不改文件，首先确认是否仍停留在Plan模式，以及“Edit project files”权限是否已经打开。
• Auto Approve能让Agent连续工作，但文件修改和终端命令的风险会同时放大。第一次使用时应保留人工审批，待模型行为稳定后再逐步开放安全操作。
• Cline CLI可在项目目录运行，例如使用cline "检查项目并修复失败的测试"。它更接近Codex或Claude Code的终端体验，同时保留同一套Agent能力。

🧰 Roo Code：权限和角色更灵活

• Roo Code把能力分为read、edit、command和MCP，可在本地模型上完成读取、写入、Shell执行及外部工具调用。
• 它和Cline的基础能力非常接近。偏好开箱即用时可先选Cline；需要更细的模式、权限与角色设置时，Roo Code通常更顺手。
• 两者都适合从小型测试开始，确认模型会稳定调用工具后，再让它进入真实仓库处理多文件修改。

🧠 Continue：适合做完整的本地Copilot替代方案

• Chat模式用于对话，Plan模式读取和分析项目，Agent模式才拥有创建文件、修改文件和运行终端命令的完整工具。
• 它可以将不同任务交给不同模型：轻量模型负责Autocomplete，大模型负责Agent，另行配置Embedding模型用于代码检索。
• 某些Ollama模型虽然标注支持工具调用，Agent仍可能无法使用工具。此时需要检查模型能力声明、Provider配置，以及是否正确启用了tool_use。

🧩 VS Code原生Agent：接入成功不代表执行稳定

• 本地模型可以参与VS Code的Chat和Agent工作流，但工具调用、推理和视觉能力取决于具体模型。能够正常聊天，并不能证明它会调用Edit File。
• 如果要求修改login.ts后，模型只是输出一段替代代码而没有产生文件变更，当前配置仍只是聊天助手。
• 本地BYOK模型用于Agent式修改时，不会自动替代VS Code原生的Tab补全。若要把补全也留在本地，需要Continue等能够连接本地Autocomplete模型的扩展。

🧪 Codex + Ollama

• 先用npm install -g @openai/codex安装Codex CLI，再运行ollama launch codex，也可以通过codex --oss选择本地模型。
• 进入项目目录后，Codex会直接操作硬盘上的仓库，因此编辑器可以自由选择。Codex App也能通过ollama launch codex-app连接Ollama，适合不喜欢纯终端界面的人。
• 这类Agent会持续携带工具说明、项目代码、命令输出和历史操作，实际使用宜从约64K上下文起步。

🧭 Claude Code + Ollama

• 运行ollama launch claude即可把Claude Code这个Agent外壳连接到Ollama，也可使用claude --model qwen3.5指定本地开放模型。
• Agent程序与模型来源是两件事。使用Claude Code的项目操作能力，并不表示一定在调用Anthropic的云端Claude模型。
• 为了容纳文件内容、工具定义和多轮调试，同样适合配置至少约64K上下文。

🌐 OpenCode、Copilot CLI与Cline CLI

• ollama launch opencode适合开放的终端工作流；ollama launch copilot则让Copilot CLI使用Ollama提供的模型。
• 终端Agent尤其适合Linux、SSH和服务器环境。只要进入正确的项目目录，它就能独立于编辑器读取仓库、修改文件和执行测试。
• 选择工具时不必只看名称，应检查它是否同时具备Read File、Edit File或Apply Patch、Terminal、Tool Calling和Agent Loop。

📏 参数量和实际Agent能力

• 3B～4B更接近高级代码补全，不宜承担复杂Agent任务；7B～9B可以修改单文件、写小功能和处理简单Bug，但长循环稳定性一般。
• 14B左右开始具有比较明确的生产力价值；24B～30B是本地Coding Agent的重要档位，可以认真处理代码库理解、多文件修改、Debug、重构和测试循环。
• 模型会写代码不代表会做Agent。真实任务还要求它选择正确工具、填写参数、分析工具输出、保持长期目标并判断何时停止，因此Agentic Coding能力比单一代码基准分数更重要。

📚 Context Window不能只看最大标称值

• Agent上下文同时包含系统提示、工具定义、用户要求、项目文件、终端输出、Git Diff和之前的操作记录。普通聊天可能用8K就够，Coding Agent以32K作为现实起点更稳妥。
• Cline和Roo Code可从32K开始；Codex、Claude Code和OpenCode等长循环终端Agent更适合64K以上。大型仓库或大规模重构再考虑继续增加。
• 模型支持256K不代表应该直接把num_ctx设为262144。上下文越大，KV Cache占用越多，可能造成显存溢出、内存紧张、速度降低和首Token等待变长。

🗜️ Q4、Q5、Q6和Q8怎样取舍

• Q4压缩程度较高，文件更小、显存要求较低、运行更快，但会损失少量精度；Q8更接近原始模型能力，内存与显存占用也明显增加。
• 普通本地Coding Agent可从Q4_K_M开始。能把完整模型与合理上下文稳定装入硬件，通常比追求高精度量化却频繁溢出更重要。

🎮 为什么显存排在第一位

• 模型参数全部进入GPU时速度通常最好；显存不足时，部分参数会转移到系统内存，虽然仍能运行，但CPU与GPU之间的数据交换会明显拖慢Agent循环。
• 纯CPU运行并非完全不可行，但Agent一次任务会连续多次请求模型。每一步都等待几十秒，会让调试、测试和修复流程变得难以使用。
• Qwen3-Coder 30B Q4文件约19GB，并不意味着24GB显存还固定剩余5GB。KV Cache、运行时和上下文都会额外占用资源，32GB或48GB显存会更从容。

💾 内存、SSD与CPU的优先级

• 64GB内存更适合长期开发，因为Windows、VS Code、浏览器、Docker、Node.js、数据库、Ollama和开发服务器会与模型同时占用资源。
• 模型文件常见容量从6GB、15GB、19GB到数十GB不等，安装多个模型后很容易占用数百GB。SSD至少1TB，长期使用更适合2TB NVMe。
• CPU当然重要，但预算有限时，通常不值得为了小幅CPU提升而把24GB显存降到16GB。对本地大模型而言，GPU显存的优先级更高。

🍎 Apple Silicon怎样选择统一内存

• Mac采用CPU与GPU共享的Unified Memory，不能直接套用“系统内存加独立显存”的PC算法。16GB适合较小模型，32GB可认真尝试Devstral 24B Q4一类模型。
• 64GB统一内存适合24B～35B本地Coding Agent，128GB则能容纳更大模型和更长上下文。只跑本地AI、不看重大型游戏时，大统一内存Mac有明显优势。
• 一个实用参考是：约8GB显存配16K上下文，约16GB显存配32K，24GB以上显存再尝试64K。具体占用仍会随模型架构和量化方式变化。

1️⃣ 安装运行器并下载合适的模型

• 先安装Ollama，再按硬件选择模型。24GB显存可尝试ollama pull qwen3-coder:30b或ollama pull devstral-small-2:24b；显存较小时可从ollama pull qwen3.5:9b开始。
• 如果更习惯图形界面，也可以使用LM Studio搜索、下载和加载模型。以Coding Agent为主要用途时，Ollama的自动化和集成范围通常更方便。

2️⃣ 安装Cline并连接Ollama

• 在VS Code扩展商店安装Cline，进入Settings，把API Provider设为Ollama。
• 本机默认地址通常是http://localhost:11434，随后选择已经下载的模型，并为Agent设置合理的上下文长度。
• 第一次不要打开全自动终端权限，先允许读取项目、编辑工作区文件和执行安全命令。

3️⃣ 用最小测试确认Agent链路

• 创建test.txt并写入hello，要求Agent不要回复修改后的内容，而是直接把文件改成hello world。
• 如果文件确实改变，说明编辑工具已经被调用；如果只输出“应该改成hello world”，当前模式、权限、模型或工具配置仍有问题。
• 第二步让它创建hello.py，运行脚本并确认输出。能依次完成创建、执行和读取结果，才说明文件工具、终端工具和Tool Calling都已连通。

4️⃣ 再进入真实软件任务

• 先选择有测试或可构建的中小型项目，要求Agent查找TypeScript编译错误，直接修复，再运行npm run build，如果仍失败就继续处理。
• 清楚写明目标、允许修改的范围、必须运行的验证命令和停止条件，比只说“帮我修一下”更容易得到稳定结果。

🐛 修Bug与自动处理编译错误

• 面对刷新网页后登录状态消失的问题，Agent可以搜索认证代码，检查localStorage和Token逻辑，修改相关文件并运行测试。
• 当npm run build出现多条错误时，它可以读取错误、定位文件、修改、重新构建，重复循环直到通过。这类反馈明确的任务最能发挥Agent价值。

🧱 增加功能与多文件修改

• 给博客增加文章收藏功能时，Agent能够同时处理数据库、API、后端、前端、样式与测试，而不是只生成一个孤立函数。
• 需求应写清数据结构、用户流程、兼容性要求和验收命令，让Agent能够依据真实结果而不是主观判断结束任务。

♻️ 重构、依赖升级与测试循环

• 拆分一个2000行Python文件时，Agent可以分析依赖、创建模块、移动函数、调整import并持续运行测试，前提是项目已有可靠测试保护。
• 升级React等依赖时，它可以修改package.json、安装依赖、修复旧API，再通过构建和测试确认兼容性。

🔍 理解陌生仓库与从零搭建项目

• 进入陌生项目后，可以让Agent找出启动方法、登录入口、数据库初始化位置和请求链路。仓库搜索与跨文件关联通常比逐个文件阅读更省时间。
• 从零创建个人记账网站时，Agent能够生成目录、前后端、数据库和API，再实际启动并修正错误，但仍需要人工决定架构和检查安全边界。

❌ 模型没有稳定的Tool Calling能力

• Agent需要模型准确选择edit_file、read_file或终端工具，并填写正确的文件路径和参数。模型若只会生成自然语言，就只会给出代码建议。
• 小模型面对大量工具定义、项目文件、历史对话和复杂要求时容易混乱。3B或7B模型即便名义上支持工具，也可能在长任务中退回普通文字回答。

🔧 模式、权限或Provider配置不正确

• Chat、Plan模式通常不会执行真实修改，应切换到Agent、Act或Code模式。编辑权限关闭时，模型再聪明也无法写入文件。
• 确认Ollama地址、模型名称、上下文和工具能力声明正确。有些集成需要显式标注tool_use，否则模型不会收到可用工具。
• 不要用复杂仓库作为第一次诊断对象。test.txt的hello测试能快速把“模型能力问题”和“项目理解问题”分开。

🔁 Agent在复杂任务中反复或偏离目标

• 本地9B模型可能找错文件、重复同一操作、修复一个Bug又引入另一个Bug，或在长循环中忘记原始目标。工具齐全不等于智能水平达到最强云端模型。
• 把大任务拆成可验证的小任务，限制一次允许修改的目录和文件数量，并要求每个阶段运行测试，通常比一次性要求“重构整个项目”更稳。
• 当上下文开始堆积无关日志时，重新开启一个聚焦任务，比盲目把上下文窗口拉到最大更有效。