Local Quench 使用指南
默认设置是按模型选的：应用读取模型的名称和大小，据此选好 harness、工具和编辑格式。本页说明每个选项的作用，以及什么时候该改。除非另有说明，这里提到的设置都在 Settings › Agent 里。应用界面目前只有英文，所以设置名称保留英文原文。
在项目里做第一个任务
- 在 LM Studio 里加载模型（或启动 llama-server、Ollama、vLLM），上下文至少 32k token；中型仓库用 64k 比较宽裕。Local Quench 会在顶栏显示服务器实际加载的上下文长度。
- 打开项目文件夹，输入
/init。智能体会写好项目记忆（QUENCH.md）：怎么构建和测试、目录结构，以及项目里 CLAUDE.md、AGENTS.md 或 Cursor rules 中的规则。小模型更容易遵守简短的规则，所以它会写得很短。 - 为项目设置检查命令（Settings › Agent › Verify after changes），比如
pytest -q或npm test。智能体说“完成了”的时候会运行它，检查不通过就得回去接着改。 - 一次只提一个修改。小模型适合改动一到三个文件的任务；更大的功能，先拆成这样的一串步骤，每步发一条消息。
权限模式
在消息输入框里的按钮上切换（Shift+Tab 依次切换）。它决定智能体哪些事可以不问你就做。文件改动总能撤销，命令不能。
| 模式 | 作用 | 适用场景 |
|---|---|---|
| Plan | 只读：智能体调查代码并写出计划；不改文件，只运行只读命令。点 Execute plan 按钮切回来并执行计划。 | 涉及好几个文件以上的任务、模型没见过的仓库，或者想先观察一下再信任的新模型。 |
| Ask | 文件改动直接生效（可在 Diffs 里撤销）；每条 shell 命令和每次删除前都会询问。 | 日常工作。这是默认模式。 |
| Auto (safe) | 只读命令（ls、git status、grep、cat）直接运行，其他的都要询问。 | 你信任这个模型，希望它探索代码时少问几次。 |
| Skip permissions | 从不询问，命令和删除立即执行。 | 只用于有版本控制的项目：基准测试、夜间任务、仓库的单独副本。 |
| Autopilot | 从不询问，并由模型自己决定是否先做计划。 | 较强的模型做较大的任务，在单独副本或可以随时重置的仓库里。 |
Harness：Guided、Standard、Lean、Minimal、Auto
harness 是包在模型外面的一套规则：模型说了下一步却停下来时推它一把，出错后给提示，一直在测自己写的检查脚本时提醒它，结束前让它看一眼自己的 diff，接近上下文上限时丢掉旧的工具输出，还有限制它能思考多久。这些对容易卡住或看不懂报错的模型有帮助；对本来就表现很好的模型，只会多耗 token、多打断。一个模型需要哪一档，取决于它的实际表现，而不是参数量：训练得好的 4B 模型可能比老一点的 9B 模型需要的帮助还少。
- Guided：所有护栏全开，工具集更小。适合出错后就停住、只说不做或者兜圈子的模型。
- Standard：保留安全类规则（循环和重复警告、继续提示、思考上限），关闭额外的辅导（错误提示、自查提醒、结束前复查）。适合能力不错但偶尔失误的开源模型。
- Lean：关闭辅导，由模型自己安排检查。适合前沿模型，无论本地运行还是通过云端 API。
- Minimal：简短的系统提示词加五个工具（读、改、新建文件，运行命令，查看后台进程），每个工具只有一行说明，总共约 700-850 token，而不是 2,000-3,700；没有仓库地图，也没有结束前复查。不占提示词 token 的修复仍然开着：从文本中恢复工具调用、循环警告、推理失控时叫停、继续提示、shell 修复。适合在慢机器或小窗口上换取预填充速度和更多可用上下文。Auto 不会选它；请先在你的模型上测一下（QuenchBench 的 harness 消融测试）。
- Auto 先看我们对已知模型的实测结果（Model 标签页里的参考列表），再看模型的系列和型号（mini 或 flash 版比同系列的大模型得到更多帮助），量化到 1–2 bit 的模型再多给一档帮助。Model 标签页会显示选了哪一档以及原因。
harness 选项下方的说明文字，以及上下文指示条的提示，会显示在当前设置下系统提示词和工具占多少 token。每条规则在 harness 选项下面还有自己的开关，QuenchBench 可以测出某个开关对你的模型值多少（Benchmarks › ablation）。
工具集：Auto、All、Light、Core、Minimal
模型能调用的每个工具都会在每次请求中占用 token，因为工具说明就写在提示词里。工具一多，小模型选错工具的情况也会变多。
- Core：读、改、新建和删除文件，列目录和搜索，运行命令和测试，查看后台进程，任务列表。共 11 个工具。上下文小于 24k token 时 Auto 会选它。
- Light：Core 加上文件大纲、git、网页搜索和网页抓取。小模型 harness 下 Auto 会选它。
- All：全部工具，包括浏览器、子智能体、等待进程，以及来自语言服务器的符号工具。强模型下 Auto 会选它。
- Minimal：读、改、新建文件，运行命令，查看后台进程，配合简短的系统提示词。Minimal harness 下 Auto 会选它。
MCP 服务器和 skills 在每个工具集里都会出现，但只有在你配置过之后才会出现，免得小模型看到一个空列表。
编辑格式
模型以什么形式写出改动。Auto 按模型大小选：12B 及以下写整个文件（4B 模型写整个文件比写补丁可靠），12B 到 32B 的模型以及专门训练过的代码模型用旧文本/新文本工具，更大的模型用编辑块，GPT 和 gpt-oss 用 OpenAI 的 apply_patch。如果某个模型老是写出应用不上的改动，就换一种：Diffs 面板会列出每一次失败的编辑。
思考
消息输入框里的 Thinking 按钮用来开关模型的推理，并设置 token 预算（也可以用 /think on、/think off、/budget 4096）。对需要找原因的 bug，推理有帮助；对简单的修改反而有害，模型会推理好几分钟然后超时。harness 会按上下文大小和模型速度限制预算，免得慢模型把大半个任务的时间都花在思考上。用 LM Studio 时，请在它的模型设置里也设成同样的预算：应用每次请求都会把预算发给服务器，但只有 llama-server 会真正执行这个限制。
多个对话，多次尝试
- 在单独副本里工作（顶栏的文件夹菜单）：这个对话会在新分支上得到自己的 git worktree，几个对话可以同时修改同一个仓库，失败的尝试直接丢掉，不会碰到你的文件夹。完成后再合并回去。
- 子智能体：在 All 工具集下，智能体可以派出多个并行的探索者去翻大型仓库；每个探索者在对话里显示为一行，点开就是它自己的对话。
- Best of N（Settings › Agent › Experimental）：对同一个任务做 N 次尝试，由你的检查命令评判。适合有明确测试、显卡可以一直跑着的任务。
- 夜间任务（Settings › Night tasks）：你睡觉时在一个分支上跑 QuenchBench、harness 调优、修测试或更新依赖，早上给你一份报告。
在终端里使用
不开窗口也能用同样的智能体、模型、设置、权限和沙箱。命令在 Windows 上是 LocalQuench，其他系统上是 local-quench。
local-quench chat在当前文件夹开始一个对话。回复以流式输出。模型的推理折叠成一行灰色文字，每个工具调用一行并附简短结果，每次编辑都显示 diff。需要批准的命令或删除会直接在行内询问：y 允许一次，n 拒绝，a 在本对话中一直允许。禁止访问的路径（blocked paths）和 Permissions Center 与应用里一样生效，每次回答都会记录在它的历史里。选项：--model ID、--mode ask|safe|dangerous|autopilot|plan（默认用应用当前的模式）、--project DIR、--resume ID（或--resume last继续这个文件夹里最新的对话）。对话和应用里的对话保存在一起，可以在窗口里接着聊。- 对话中可用：
/model、/mode、/undo（撤销对某个文件的最后一次修改）、/compact、/thinking（推理完整显示或折叠）、/clear（新对话）、/help、/exit。Ctrl+C 停止回复，Ctrl+D 退出。行尾加\可以接着写下一行，或者把内容粘贴在两行"""之间。 local-quench run "fix the failing test"只执行一轮并打印回答。没有人在旁边回答问题，所以需要批准的命令会被拒绝（--mode dangerous会直接执行）。--json把这一轮按事件输出，每行一个 JSON 对象（assistant_start、thinking、answer、tool_start、patch、tool_end、assistant_done、warning、error），最后一定是一行result，包含exit_code、session_id和answer。脚本和其他工具可以用这种方式驱动智能体。local-quench run --help会列出所有字段。
用小模型做较大的任务
30B 参数的模型面对几万行代码的仓库，不可能一条消息就交付整个功能。但如果每一步都能检查，它可以一步一步做出来。先用 Plan 模式让它给出功能的计划；把计划切成每步一到三个文件的小步，每步结尾都有测试；然后在仓库的单独副本里，用 Ask 模式一步一步地发给它，每步之后运行检查命令。做完后导出对话（对话旁边的下载图标）：harness 在哪里介入过，导出的记录里都看得到。