周五下午四点给一份 60 页的检修规程跑批量批注document_apply_ops一次塞了接近 200 个操作——接近单次批量上限。跑到中途工具调用突然报错服务没响应。当时心里一沉这批活要是废了重跑一遍又是半小时下班点又要往后挪。这篇记一次完整的实录顺便把察元AI文档助手 sidecar 的自愈机制说清楚。实录从报错到恢复发生了什么我的第一反应不是重启是先探活——习惯使然curlhttp://127.0.0.1:62588/healthz第一次探测没通正准备按排查清单去查自启项隔了几秒不死心又调了一次wps_status——已经恢复在线了。让 agent 把刚才失败的那批操作重发一次跑通200 个批注全部落盘。那批任务本身是发布前终检的落盘环节前一步的提示词是帮我做发布前终检错别字、标点、数字前后一致性、表格与正文是否一致全部用批注输出最后给我一份问题分级摘要严重/一般/建议问题清单先过目确认、再批量落盘——所以掉线那一刻丢的只是一次写回清单还在手上这是三段式流程给的底气。事后翻时间戳从第一次报错到下一次调用成功间隔 8 秒上下。也就是说我连排查清单的第一步都没走完服务自己爬起来了。它凭什么能自己爬起来查了版本说明4.1.2 这版有两个相关改动一是 sidecar 全面隐藏启动——不再弹黑窗用户关窗也不会杀掉服务二是「运行 Spike」场景的掉线自愈瞬时断连后服务自动恢复监听。第一点别小看。老版本时代最常见的服务暴毙其实是人祸用户看到任务栏一个黑色命令行窗口顺手就给关了服务跟着就没了然后一脸茫然地报AI 连不上文档。隐藏启动等于把这个事故源头直接铲了。第二点管的是另一种情况进程短暂卡顿、瞬断不需要人工介入几秒内自动回连。自愈不是免死金牌必须把边界说清自愈管的是瞬断不是永眠。偶发一次、几秒恢复继续干活没问题短时间内反复掉线就不是自愈能兜住的了得按排查清单查根因。按命中率排62588 端口被其他进程占用杀毒软件把 sidecar 拦了需要加白名单机器休眠唤醒后网络栈未就绪等半分钟再试自启项被清理软件优化掉了重新跑一遍安装脚本即可四步体检查到断点系统大更新后自启策略被重置重新确认一遍注册项。连续两次以上自愈失败还硬跑属于拿运气赌工期不如停下来查五分钟。重发失败批次前还有个细节让 agent 先看看已落盘的批注跳过已完成的部分再重发避免同一处被钉两条批注。自愈救的是服务流程救的是数据。为什么我在意这种小特性AI Agent 办公落地谈了这么久大家盯着的都是模型能力、工具数量真用起来才知道最后一公里是稳定性。一次批量写回中途断掉丢的不只是那半小时还有你对整条流水线的信任——信任这东西建立要一个月动摇只要一次掉线。自愈机制本质上是把偶发故障从需要人介入的事故降级成无感的小抖动这类工程细节不显山露水却决定了工具能不能进生产环境。那天科长后来问我掉线影响交付吗我说影响八秒。他愣了一下说这个答案可以写进周报——比系统运行良好这种废话有信息量多了。那次实录的结尾是六点前交了稿。现在我的习惯是批量任务照常跑、报错先探活、八秒没自愈再查根因。顺序对了周五就还是周五。