上个月帮朋友的设计院跑一批标书终检四十几份文档、每份两三百页。第一版方案很糙让智能体每份全文读一遍、逐条改、逐条写回。跑完一算账单朋友脸都绿了。复盘之后发现不是模型贵是我用得蠢。换了打法之后同样的活token 花销降到原来的零头。这篇把踩过的坑和换招的过程摊开讲全部是察元AI文档助手里现成的能力不用写一行代码。适合所有按量计费、又要批量处理长文档的团队。坑一全文硬取又贵又报错第一版直接让智能体用document_get_text整篇拿正文。长文档超过约 80k 文本阈值工具要求force:true才给全量或者改用分块接口。硬 force 的结果是上下文塞满、费用按整篇上下文计、重点反而被稀释——校对最需要的开头结尾和表格淹没在正文海洋里。换招先看体检报告再决定怎么读。document_meta会返回名称、字数、段数以及是否建议分块的提示。建议分块就用document_chunks带 cursor 和 limit 分页取智能体按需翻页哪段有问题读哪段。这招是整场省钱战役里收益最大的读取量从整篇乘以文档数变成相关块之和。坑二把知识库当附件整包塞第二版让智能体把单位的规章库整个读进来做依据。规章库几十万字每份标书都背一遍这个上下文成本是乘法增长的。换招检索增强代替整库投喂。用kb_retrieve做 RAG 检索只把与当前条款相关的片段召回放进上下文。依据更聚焦费用从乘法降回加法而且检索命中的出处可以人工回查比整库塞入时的模糊引用可控得多。坑三逐条写回来回跑空车第三版发现问题清单有三百多条智能体一条一条替换每条都是一次完整往返光写回就跑了三百轮。换招批量操作一次提交。document_apply_ops支持 replace、comment、comment-replace、insert-after 混合编排单次最多 200 个操作。三百条拆两次提交完事写回开销直接摊平。记住这个数字200 ops 是单次上限超了就分批。坑四边找边改返工没商量最隐蔽的坑是让智能体边校对边修改改完发现风格不统一要回滚重来同一批 token 花了两遍。换招先预览后写回。proofread_run默认 dryRun只返回问题清单不改正文人工过目后proofread_apply_comments把确认过的问题一次性写成批注。给智能体的指令直接这样下先跑一遍校对dryRun汇总问题列表不要先改正文我确认后再写成批注一轮读取、一轮确认、一轮落笔每个 token 都花在明处。压舱石粗筛本地精修云端如果模型端点是混合配置的再加一层分工Ollama 本地模型跑全量粗筛把明显问题先过滤出来云端模型只处理粗筛命中的段落和需要判断力的部分。本地推理没有按 token 计费的账单粗筛这层大头就省掉了。还有一个容易白花钱的动作长文档校对是异步任务跑完要轮询拿结果。用proofread_job_poll按节奏查询即可千万别因为没等到结果就重新发起一遍——重复跑等于把同一份文档的 token 花两次这在批量场景里是隐性大头。算总账复盘下来分块读取省读、检索增强省上下文、批量 ops 省写回、dryRun 省返工、本地粗筛省计费五招叠上同一批活费用降到零头速度还更快。省钱是小事流程顺了之后敢把 AI 校对常态化才是大事——以前心疼账单一个月跑一次现在每周跑问题反而暴露得更早。边界省 token 不能省质量分块可能漏读跨块上下文长句关联问题要靠多轮校对补RAG 检索有召回边界关键依据必须人工回原文核对账单优化后终审仍在人AI 清单只是给终审提速的输入。token 优化没有玄学本质就一句话让模型看该看的别让它看你想偷懒让它看的。