夜雨聆风AI Agent 真正进入生产环境时，最难的不是“会写”，而是“改得准、改得少、改错了能定位”。
这张图只画了三个动作：看见、精确替换、插入。它们看起来很小，却决定了 Agent 能不能从“演示玩具”变成“可托付的工具”。
不是所有编辑，都该交给自由生成
Simon Willison 发布了一个早期插件：datasette-agent-edit 0.1a0。
它本身不是一个大新闻，也不是一个宏大的 Agent 平台发布。真正值得关注的是它背后的工程判断：当 Agent 要修改已有文本、SQL、Markdown 或 SVG 时，不应该让模型直接“重写一整段”。
更稳的方式，是把编辑动作拆成几个可审计的小工具：
view：先看文件的某个范围，并带上行号；str_replace：用唯一的旧字符串做精确替换，如果不唯一就失败；insert：在指定行后插入内容。
这套设计参考了 Claude text editor tool 的思路。它的价值不在于复杂，而在于限制。
好的 Agent 工具，不是给模型更大的自由，而是给它更可靠的边界。
为什么“精确替换”比“重新生成”重要
很多 Coding Agent 失败，并不是因为模型不会写代码，而是因为它不知道自己改动的上下文边界。
如果工具只提供“把这个文件改好”，模型就容易做三件危险的事：
顺手重构无关内容； 覆盖掉用户刚改过的细节； 在长文件里产生看似合理、实际错位的补丁。
str_replace 的要求很苛刻：旧字符串必须精确匹配，而且必须唯一。匹配不到，或者出现多处，就失败。
这会让 Agent 看起来“笨一点”，但生产环境恰恰需要这种笨。
因为失败是可处理的，静默改错才是灾难。
这背后是一条 Agent 产品原则
今天很多 Agent 产品还在强调“它能自动完成多少事”。但真正决定留存的，往往是另外几个问题：
它有没有办法解释自己看到了什么？ 它能不能只改用户希望它改的地方？ 它失败时，是不是足够早、足够明确？ 它能不能把一次大动作拆成一组可回放的小动作？
这也是为什么文件编辑、数据库查询、表格更新这类能力，都不适合只靠聊天框完成。
聊天是入口，工具协议才是产品本体。
对开发者工具的启发
如果你在做 AI Coding Agent、内部自动化、文档助手或数据分析 Agent，可以直接借鉴这个最小结构：
1. 先让 Agent 读取局部，而不是吞下全部
局部读取能降低上下文噪音，也能减少模型“凭印象改文件”的概率。
2. 修改动作必须有唯一锚点
精确替换、行号插入、结构化 patch，都比自然语言“把这里优化一下”更可靠。
3. 失败条件要设计在工具层
不要等模型自己判断是否安全。工具应该在不唯一、不匹配、越界时直接拒绝执行。
4. 可复用能力应该沉到基础插件
Simon 把这套能力抽成基础插件，是一个很产品化的动作：不要让每个上层插件重复发明编辑协议。
小工具，可能比大模型更关键
Agent 的下一阶段竞争，不只是模型能力竞争，也会是工具边界竞争。
谁能把“模型想做的事”翻译成可验证、可回滚、可组合的小动作，谁就更接近真正可用的 Agent。
这篇小发布的提醒是：AI Agent 的工程化，不一定从宏大框架开始。它可能从一个非常朴素的问题开始——
“你到底要改哪一行？”
参考资料
Simon Willison: datasette-agent-edit 0.1a0 Anthropic Claude text editor tool 文档
