把 Claude Code 接上察元的 MCP 之后我花了不少时间琢磨 46 个工具里最不起眼的三个document_open、document_ensure_open、document_save。读正文、写批注这些显学大家都在讲但多文档任务能不能稳拼的恰恰是这三块入门积木。这篇按拼图的方式拆给大家。三块拼图各自管什么document_open 负责明确打开一份文档相当于你双击文件它会建立一个新的文档会话。document_ensure_open 是它的幂等版本目标文档如果已经打开它什么都不做直接返回现状没打开才去打开。document_save 负责保存当前文档还支持另存为把结果写成一个新文件。幂等这一下值钱在哪Agent 不是人它会重试、会在多份文档间来回切换、会在上下文丢失后重新对齐状态。如果每次都无脑 open轻则多开一串重复会话重则焦点漂移把批注写错文档。ensure_open 的一致则不动保证了状态收敛Agent 怎么折腾都在同一份文档上。这是工程直觉在工具设计上的直接体现。配套的读侧工具也值得认识document_list_paragraphs 返回的段落带锚点document_locate 定位时会给出多个命中锚点写回前锚点校验不过就报 LOCATE_MISMATCH宁可失败也不落错位置。读和写之间靠锚点对账是多文档任务不出乱子的另一半原因。场景一多文档交叉校对典型任务一批纪要要互相核对术语和表述。直接把意图丢给 Agent打开目录下这几份文档交叉检查错别字与术语是否一致背后 Agent 会用 ensure_open 逐份确保打开读正文比对把不一致的地方分别批注回各自的文档。全程不需要你手工排顺序幂等保证重复调用也不乱。这类任务以前人工对表要做一下午现在主要时间花在复核批注上。数字勾稽也能并进同一单任务加一句核对数表与正文数字是否一致合计、百分比术语和数字一次交差省得第二轮再开一单。场景二改副本、不动原件部门规矩送审前的修改必须在副本上做。传统做法是先复制文件再打开Agent 的做法是 open 原稿、完成修改最后 document_save 另存为新文件名原件一个字节不动。整个流程在提示词里说清楚改完另存为送审版即可。配合批注类工具还可以做成原稿只批注、副本落修改的双轨模式留痕和修改两不误。批量改动还有 document_apply_ops 兜底replace、comment、insert-after 混编成操作清单一次提交单次上限 200 条不带确认只返回 preview。几百处术语统一这种活逐条调用不如攒成清单批量走先看 preview 再决定落不落盘。场景三读之前先体检打开之后别急着整篇读先 document_meta名称、字数、段数、是否建议分块一眼看完。短文档直接 document_get_text长文档老实走 document_chunks 分页超过约 80k 还硬要整篇会吃 DOCUMENT_TOO_LARGE这时候要么分块要么 force:true 强制一般不建议Token 消耗大。从零起稿的场景则换 document_new 建新文档走 insert 系列写入。新文档配 document_save 另存起草和归档一条链走完。别忘了表格里的坐标思维多文档任务经常碰到表格插行列这类操作的口语化提示词设计得很顺在合计行上面插入一行列结构和上一行一致Agent 的执行路径是先 header_read、column_read 把表格结构和锚点找齐再按显式坐标执行插入。工具不猜、只按坐标执行所以锚点变了宁可报 LOCATE_MISMATCH 也不乱插这是拼图里另一块安全垫。适用人群与边界这套拼图适合三类人需要批量处理成套文档的行政文书岗、做交叉审校的编辑岗、用 Claude Code 或 Cursor 编排文档流水线的开发者。要提醒的边界有两点一是写回默认带确认机制document_replace 不带 confirm 只返回 preview批量写回上限 200 条操作超了分批二是校对和交叉核对的结果是辅助参考送审前的最终一致性还得人签字。把这三块积木摆顺多文档任务就从能不能做变成了怎么排流水线。