docs: add detailed fine-tune path (distillation workflow, costs, gating)

Expands the fine-tune option: correct ordering (cheap levers first, fine-tune
only after they hit a wall), the distillation workflow (teacher model generates
tool-call trajectories -> SFT/LoRA -> compile to MLC/WebLLM), the irony that
bootstrapping data still needs a cloud model, ongoing retrain-on-tool-change
cost, realistic expectations (a tuned 3B is still a 3B), and a go/no-go
checklist for when it is actually worth it.

Author: chaxus

docs/explorations/2026-07-07-agent-llm-local-tooling-tradeoffs.md

@@ -84,10 +84,63 @@ pi 的 Direct Mode 仍把请求发往云端 Provider、仍要 key。所以**"Web
    工具调用成功率。是 **WebLLM 的能力,pi/langchain 不提供**。仍受小模型天花板限制(单步可救,
    复杂多步难)。具体 API 需按当前 `@mlc-ai/web-llm` 版本确认。
 3. **微调专属小模型** — LoRA + 造数据 + 编译 MLC/WebLLM。能抬一点天花板,但重、上限有限,
-   ROI 通常不如 1、2。与 pi/langchain 无关。
+   ROI 通常不如 1、2。与 pi/langchain 无关。**详见下节「Fine-tune 路径详解」。**
 4. **pi / langchain** — 对"本地模型能力不足"这个问题是**错的层级**,不解决能力,不必引入。
    自研 `agent-core` 已覆盖它们的编排职能。
 
+## Fine-tune 路径详解(先看清代价再决定)
+
+> 常见的错误理解:"先 fine-tune 出业务模型,再用 pi/langchain 推理"作为**起手式**。分层没错,
+> 但**顺序反了**——fine-tune 是撞墙后的最后一步,不是默认起点。
+
+### 正确顺序(投入从小到大,前一步撞墙才走下一步)
+
+```
+① 换更强的模型   → Ollama 跑 Qwen2.5-7B(本地无 key)/ 或云端
+② 推理时优化     → 约束解码 + few-shot + 工具 schema 设计(agent-core 已在做)
+③ fine-tune      → 仅当 ①② 都调过、仍有可量化缺口、且必须留在小本地模型上
+```
+
+跳过 ①② 直接微调是过度工程:很可能 ② 一个约束解码就够了,根本用不到训练链。
+
+### 真实工序:是"蒸馏(distillation)",不是手工标注
+
+```
+用强模型(Claude/GPT-4)对真实任务批量生成"正确的工具调用轨迹(trajectories)"
+        ↓ 这就是训练数据(几百 ~ 几千条 SFT 样本)
+在小模型(如 Qwen2.5-3B)上做 SFT / LoRA(Unsloth 或 PEFT + GPU)
+        ↓
+编译成 MLC / WebLLM 格式(浏览器要跑的话)
+        ↓
+再用 agent-core / pi 跑推理
+```
+
+**反讽点(必须知道)**:为了造训练数据,反而要**先借云端大模型**当 teacher。想彻底摆脱 API key,
+连 bootstrap 阶段都得先用一次云——纯离线连"造数据"这步都绕不过去。
+
+### 持续成本(不是一次性)
+
+- **工具一改就可能重训**:现有 8 个工具,任何一个 schema 变了(改参数、加工具),小模型就可能漂移,
+  要重新造数据 + 重训。这是长期维护负担。
+- GPU 训练迭代 + MLC 编译工具链的搭建与维护。
+- 每个目标模型/量化格式都要单独编译一份。
+
+### 期望值要摆正
+
+- **微调后的 3B 还是 3B**:它在**你的工具格式 + 领域措辞**上变准了,但**通用推理**仍是小模型水平,
+  复杂多步编辑的天花板抬不了多少。
+- **业务适配的大部分不需要训练**:你的业务特异性(哪 8 个工具、各做什么、系统提示词)已经在
+  `lib/agent-plugin` + `prompt.ts` 里,是**推理时**资产。微调只解决"小模型把 tool-call JSON 吐不稳"
+  这一个窄问题,而这个问题**约束解码(推理时,零训练)就能解决大半**。
+
+### 何时才值得做(前置门槛,建议全满足才上)
+
+- [ ] 已用够强的模型(Ollama 7B+ 或云端)+ 推理时约束解码,**仍有可量化的可靠性缺口**
+- [ ] **硬**隐私要求:必须小本地模型,云端 / Ollama 都不可接受
+- [ ] 任务窄而稳、调用量大,足以摊销"造数据 + 训练 + 每次改工具重训"的成本
+
+三条不全满足,就别进训练链——留在 ①②(Ollama / 约束解码)性价比高得多。
+
 ## 天花板是物理约束
 
 真正跳过小模型天花板只有两条:① 用更大的**本地**模型(Ollama 在本机跑 7B+);② 用**云端**大模型