记录一次博客断更六天后，发现 OpenViking 的模型端口 8443 早就没人听了（2026-10-21）

进程活着不等于链路活着，素材为零也不等于今天没事。

上午发现博客自动更新又停了，距最新一篇已经过去六天。我先入为主以为是 watchdog 没接住这条链，查完才发现，它每天 08:30 都在正常跑，真正断掉的是更下面一层。

一、先承认跑批系统没偷懒

第一轮只读排查就把怀疑对象排除了：

• watchdog 心跳在 09:52 还在刷新；
• daily.last_success=2026-10-21，10-15 到 10-21 每天 08:30 的 daily_refresh 一次没缺；
• 文章步骤每天执行，但每次结论都是 无新素材 待写 0。

所以不是任务没跑，是任务每天跑完都发现没米下锅。两个素材源的时间戳摆出来：OpenViking memories/events 最新目录停在 2026/09/10，resources/craw_app1_wz 最新文件是 2026-10-15。文章生成器看到空输入，照旧成功退出，把断流包装成了“今天没什么好写的”。

二、把“服务活着”和“端口有监听”分开看

OpenViking 的进程 OpenVikingService.exe 还在，这点很迷惑人。继续翻 C:/Users/Administrator/.openviking/ov.conf，发现 vlm.api_base 指向 http://127.0.0.1:8443/v1，一个本机转发端口；再用 netstat 一查，8443 已经没有任何进程监听。日志尾部是成串的：

openai.APIConnectionError: Connection error.

底层是 httpx.ConnectError: All connection attempts failed。

这就解释通了：OpenViking 抽记忆要调模型，模型接口连不上，整条记忆写入流程失败，events 不再更新。服务本身健康，所以从“服务在不在”完全看不出问题。

三、端口与 Host 头一起修正

动手前先验证上游。用配置里的 api_key 直接请求 https://api.minimaxi.com/v1/models，返回 200 和模型列表；再用 MiniMax-M3 调 chat/completions，也正常。说明问题确实在本地转发端口和配置，不在上游。

于是只改两个点：

• vlm.api_base 从 http://127.0.0.1:8443/v1 改成 https://api.minimaxi.com/v1；
• 删掉 extra_headers 里手工设置的 Host。

启动方式还是老样子，重启 OpenVikingService.exe。重启后再看 /api/v1/observer/models，返回 MiniMax-M3 configured、is_healthy=true。

四、用同步写入逼抽取链路现出原形

健康检查只能证明配置加载了，我要的是端到端证明。用带 user key 的接口调 /api/v1/content/write，写一条受控内容，设置 wait=true 同步等结果。返回是：

semantic_status=complete、queue_status.Semantic.processed=1、error_count=0、errors=[]。

这才能说语义抽取真的通了。顺手看任务列表，之前有 session_commit 任务串着一堆 failed 和 Connection error，最近一次失败就在我重启前七分钟——说明 codex 客户端一直在提交，每次都撞在同一堵墙上。

五、防复发：三个素材源，主源断流单独告警

只修端口不够，文章侧还得把“无声断流”变成可感知信号。当天给 build_articles.py 接了两个兜底源：

• collect_mem_logs() 读本机工作日志 .workbuddy/memory/YYYY-MM-DD.md；
• collect_sessions() 读 WorkBuddy 会话记录 *.jsonl，只保留 type=message 的真人问答，按 timestamp 分桶；
• collect_material() 在 OpenViking 路径之后调用两者，OpenViking 不存在也不再直接 return。

接兜底源有个新问题：总素材日期永远都是当天，原来的 gap 告警会失效。所以必须单独统计 OpenViking 这一源的最新日期，断流超过三天就单独告警，不被兜底的“新鲜”抑制。报告里也改成逐来源显示最新日期和断流天数，不再只报一个汇总最新日期。

会话兜底源当天还踩了三个坑：按索引配对问答会错位，compaction 摘要和工具残留会混进正文，都被加进 NOISE_PAT 过滤掉。

六、补写两篇验证生成器

素材源修通后，--list 一下：素材覆盖 94 个日期，待写 49 天。为了防止一次把首页灌满，daily_refresh.sh 里 ARTICLE_LIMIT 默认 2。当天端到端跑 ONLY=articles ARTICLE_LIMIT=2，产出两篇：

• 记录一次只读交叉验证，我把 funding_collector 的两个坑挖出来了（2026-10-18）
• 记录一次源码级测试被绕过的交叉验证（2026-10-19）

生成约 5m40s，单篇 LLM 大概 75 秒。线上 wz-git-hub.github.io 两篇 /posts/ov1018/、/posts/ov1019/ 都返回 200。

遗留

沙箱里跑 npx hexo deploy 还有已知环境坑：safe-delete shim 调 genie-trash 超时，FATAL 后 .deploy_git 会被清一半，重跑第二次能自愈。watchdog 通过 vbs 在正常环境跑，不受影响；判断推送是否真成功，不能只看 deploy.out 里那句 Deploy done，要 git ls-remote 比对远端与本地 git rev-parse HEAD。这条下一步还得再补一个部署成功校验，避免以后再被日志骗一次。