v1.5 Edit 工具 + 四级容错替换算法

- 新增 EditFileTool，支持局部字符串替换
- 四级容错降级：精确匹配 → 换行符归一 → Trim Space → 逐行滑动窗口
- 工具集扩展至 4 个（read/write/edit/bash）
- 新增 server.go 测试目标文件

README.md

@@ -65,6 +65,29 @@ func main() {
 
 ## 版本历史
 
+### v1.5 — Edit 工具：从"重写整个文件"进化到"精准局部替换"
+
+#### 变更
+
+- **新增 EditFileTool** — 实现四级容错降级替换算法（L1 精确 → L2 换行符归一 → L3 Trim Space → L4 逐行去缩进滑动窗口），解决大模型代码修改时缩进丢失、换行符不一致等幻觉问题
+- **工具扩展** — 工具集从 3 个（read / write / bash）扩展到 4 个（+ edit）
+- **cmd/claw 任务更新** — 演示 edit_file 的局部替换能力，编辑 server.go 中的鉴权逻辑
+- **server.go** — 新增测试目标文件
+
+#### 踩坑记录
+
+| 问题 | 原因 | 解决 |
+|---|---|---|
+| 大模型生成的代码缩进不一致 | 模型推理时对源文件缩进（tab/空格）感知不准，产生多一个空格或少一个 tab | 编辑工具内建多级模糊匹配，不要求模型生成的 old_text 与原文件严格一致 |
+| 同一段代码在文件中出现多次 | 模型给的 old_text 上下文不够，匹配到多处 | 算法检测多匹配后直接返回错误给模型："匹配到 X 处，请提供更多上下文" |
+| Windows 换行符 `\r\n` vs `\n` 不一致 | 模型通常输出 `\n`，Windows 文件可能是 `\r\n` | L2 换行符归一化：统一转成 `\n` 后再对比 |
+
+#### 经验教训
+
+1. **Agent 工具要做"容错输入，严格输出"** — 接受模型可能不完美的输入（多级模糊匹配），但输出清晰的错误信息帮模型自我纠正（"匹配到 3 处"而非"匹配失败"）
+2. **工具语义要匹配模型的能力边界** — 模型擅长生成文本但弱于精确复制。`edit_file`（给 old_text + new_text）比"重写整个文件"更适合 Agent 场景，因为它不要求模型完整认知整个文件
+3. **工具组合产生协作效应** — read_file + edit_file 是天然搭档：read 建立上下文认知 → edit 执行局部修改 → bash 验证结果。单一工具的力量有限，组合后才是真正的 Agent
+
 ### v1.4 — 工具集扩展与 Windows 编码攻坚
 
 #### 变更