迷麟の小站

本报告记录 OC-70 截至 2026-11-09 的阶段性交付。四模型手选聊天、会话切模和输出修补已验收，游戏停复模仍在准备。范围及后续依赖见《desktop 统一模型路由与游戏让渡》。 已交付的用户结果 交付点 已验证结果 原 M1 原 35B 实际聊天和既有记忆链路通过 原 M2 UD27B、Ara27B、DeepSeek Flash 统一路由及界面验收通过 T1 四模型手选 三款本地模型及 Flash 的接口与原生聊天共八项验收通过 S1–S3 手动切模 网页和 /provider 共用当前会话偏好，具备排队、加载、就绪和失败状态，当前版本获用户接受 普通输出修补 默认省略 max_tokens，显式正整数按调用方要求处理，长度终态保留正文并提示继续 本地模型包括 Qwen3.6-35B-A3B-UD-IQ3_S、Qwen3.8-27B-UD-Q3_K_XL 和 Qwen3.8-27B-Heretic-Ara-IQ4_XS。模型选型证据见《RTX 5080 本地 LLM 选型分析》。 输出修补的实际证据 Ara27B 接口样例 输...

OC-70 当前已交付 AstrBot 四模型手选聊天、会话级切模和普通输出上限修补。游戏启停让渡正在适配，尚待完整实机验收。阶段报告见《AstrBot 四模型聊天阶段报告》。 为什么把入口和模型生命周期放在一起 OpenClaw、AstrBot 和游戏共享 desktop 的 RTX 5080。游戏开始时需要禁止新加载，再排空和卸载现有模型。应用间共享唯一的本地模型管理者，以处理推理请求与游戏占用的冲突。 当前复用 llama-swap 及现有网关，首版允许 desktop 重启带来的短暂不可用。基础设施和参数来源见《RTX 5080 本地 LLM 选型分析》。 已经确认的用户行为 2026-11-05 起，首版采用 AstrBot 手动选择本地或 DeepSeek，以及自动游戏停复模。2026-10-29 原设计中的自动转云和双应用完整接线后置。 场景 首版目标与当前状态 日常聊天 手选 35B、UD27B、Ara27B、DeepSeek Flash，已通过四模型接口与原生聊天验收 本地换模 等待已有回答结束，再排队加载，已部署且用户接受当前体验 游戏启...

#OpenClaw #Guardian #模型路由 #FailClosed 记录 OpenClaw、llama-server、路由 controller 与 GPU Guardian 之间的职责拆分、交接协议和真实恢复闭环。基础安装与 provider 配置见《OpenClaw 配置续集》，当前任务状态见《OpenClaw 后续功能规划》。 一、问题边界 后继进展（2026-11-09）：OC-70 已交付 AstrBot 四模型手选聊天、会话切模和输出修补，游戏停复模待验收。见阶段报告与首版规划。本文历史 canary 与 limited close 结论保留。 desktop 的 RTX 5080 同时服务本地推理和桌面应用。OpenClaw 默认访问 192.168.2.10:11435 上的 llama-server，但游戏、图像生成和模型测评会占用显存。这里需要解决的不是简单的“进程启停”，而是： 停模型前先把 OpenClaw 切到允许的备用 provider，并排空在途请求； 恢复本地前确认端口、进程、模型身份和上下文参数均正确； 任一步失败都保...

#本地推理 #Ollama #GGUF #RTX5080 #模型选型 硬件背景 服务接入进展（2026-11-09）：OC-70 已完成 AstrBot 四模型手选、会话切模及普通输出上限修补，游戏停复模待实机验收。见《AstrBot 四模型聊天阶段报告》与首版规划。本文历史测评继续保留。 组件 规格 GPU NVIDIA GeForce RTX 5080（16GB GDDR7，Blackwell 架构） CPU AMD Ryzen 7 9800X3D（8 核，3D V-Cache） 内存 32GB DDR5 使用场景：为 openclaw agentic 框架 提供本地 LLM 后端，主要执行工具调用、长文档处理、代码生成与分析。对输出速度要求不高（15-30 tok/s 即可），优先质量与上下文长度。 硬件特点： Blackwell 架构原生支持 MXFP4 硬件加速（OpenAI GPT-OSS 专属优势） 9800X3D 的 3D V-Cache 使 CPU 推理带宽远优于同级处理器，CPU offload 惩罚较小 16GB ...

#OpenClaw #规划 #待办 记录 OpenClaw 当前运行状态，以及后续可以接入的功能、待解决问题和扩展方向。本文随进展持续更新。 待办维护约定（2026-07-23）：当前待办统一维护在跨设备共享的家庭实验室 TODO 源；本文保留规划背景与面向阅读的快照。新事项必须有优先级、状态、依赖、下一步与验收标准，完成后从活动列表移出，避免从旧博客或聊天记录反推状态。 文章边界：本文只维护状态、优先级、依赖、验收结论和专题入口。完整命令、性能矩阵、失败证据与清理清单以对应专题为准，避免规划快照成为第二份实施记录。 分流／审核状态（2026-08-10）：OC-06 已完成非生产分类评测；OC-07 的 deterministic PoC 已通过，但 Qwen3-4B 在冻结 3 秒门禁下不晋级。两者都只是建议层，不能替代确定性规则、显式审批或工具执行门禁。生产状态以共享 TODO 为准。 本系列：部署实录 · 配置续集 · 模型路由与 Guardian · Exec 审批治理 · 公网访问 · Headroom 接入 · 本地记忆与无审批能力边界 · 微信安全...

OpenSpec 的局部安装、规格闭环和 Codex 调用都能工作，不等于应该把它安装进所有工作区。 OC-69 在完成来源调研后，又做了固定版本、可撤销的项目级试点，最终结论是： 可用性与可回滚性通过；保留软件项目按需试点，不接入 HomeLab 全局任务控制面。 这不是“安装失败所以不采用”，也不是“生成了 skill 就证明 Agent 更高效”。本文区分规格工具、执行工具和运行治理，保留实际通过的结果，也明确没有测出的收益。现有多会话机制见 《Codex 多会话自动推进》，循环框架比较见 《Ralph、ULW 与 Superpowers 是否值得接入现有 Agent 工作流》。 OpenSpec 补的是哪一层 本次于2026年10月26日固定使用 OpenSpec 1.15.0，不是持续追踪最新版本。项目采用 MIT 许可证。它面向需求、场景、设计、任务拆分和规格变更归档，适合在跨模块实现前明确约束。参考：固定版本仓库、许可证。 在该版本中，Codex 适配生成项目内 .agents/skills/openspec-*/SKILL.md，不是安装另一个模型执行后端。官方...

Agent 能搜索到旧任务文档，并不等于它会正确阅读、引用并完成工作。这次 HomeLab 试点把问题拆成三层：检索质量、工具接入机制，以及真实 Agent 收益。最终结论是：SQLite 本地检索值得保留为工作区候选，但当前证据不足以支持 Codex 全局接入。 相关的多会话推进与证据边界见 《Codex 多会话自动推进：角色分流、回执续跑与有界修复》；OpenClaw 的本地记忆与执行权限边界见 《OpenClaw 本地记忆落地与无审批能力边界》。 最终状态补记：独立 Agent 试点没有显示净增益 后续以两个不继承研究历史的 gpt-5.6-sol/low Agent，完成同一组预登记的六个脱敏工作案例。A 使用已知路径、合理关键词 rg 和直接读取；B 在未知路径先使用 SQLite trigram，证据不足可退回相同基线。两组均为 6/6 核心事实正确、来源覆盖完整和引用有效，工具错误与错误依据均为 0。B 未出现任何核心正确性或来源覆盖净改善，因此本轮不增加默认检索步骤，继续保留现有路径与 rg。 两组自报耗时为60秒和63秒，实际token未知。样本小、并行缓存和...

这次治理只回答一个问题：仍有恢复价值、但不再承担运行职责的会话备份，能否从家目录迁回所属工作区，并保留证据与恢复入口？ 结果是可以，但“可以归档”不是“可以删除”。本次同盘迁移 6 个文件，合计 38,781,694 字节。文件内容 SHA、inode、owner、权限和整数 mtime 保持一致；实际 rename 一次、回滚零次、删除零次。迁移后独立审核通过，精确路径写租约已释放。其它任务的回滚目录没有随之释放。 先回答归谁，而不是先看有多旧 目录属于哪个工作区、谁负责恢复、是否有服务或计划任务引用，都是迁移之前的问题。任务完成、运行 owner 释放、物理归档和删除，是不同的决定。 这份备份的长期恢复责任仍归运维 owner，治理任务只负责归档托管。归档后保留旧路径到新路径的映射，不修改历史证据中的原始路径字符串；恢复说明则指向当前位置。未来恢复仍需要独立维护窗口，不能把保存的回滚映射当作随时可执行的命令。 “没有输出”不一定意味着没有打开者 普通账户的进程可见性并不完整。一次管理员只读探针遇到与备份目录无关的 FUSE 挂载警告，单凭退出码和空结果不能直接放行。 处理过程...

当现有系统已经有任务卡、Goal、事件唤醒、持久 inbox、权限与租约边界时，再安装一套“让 Agent 不停工作”的循环框架，未必能增加可靠性。真正值得问的是：它补上了哪个已复现缺口，又增加了哪些状态和权限面？ 这次对 Ralph、LazyCodex ULW 和 Superpowers 做了来源审计、机制映射与隔离验证。结论不是选择一个框架全量安装，而是只保留一个很窄的候选：可选的本地完成证据指针检查。该隔离候选已通过独立差异审核，但没有安装到正式工作流。 结论先行 候选 决定 原因 Ralph Stop hook 不接入 主要能力是退出时重放同一提示，和既有续推机制重叠；难以表达长等待、人工硬停、权限差额和生产动作预算 ULW 整套 harness 不安装 evidence/checkpoint 思路有价值，但整套接入会增加第二份状态、hook 和角色边界 Superpowers 全流程 不接入运维控制面 调试与完成前验证纪律值得借鉴；worktree、细粒度计划、逐任务 review 流水线更适合代码开发 本地证据指针检查 隔离审核通过，保留为...

多会话协作最容易出现的假进展，是 Controller 已经批准，worker 却没有真正继续；另一个极端是 worker 一直修复周边小问题，主任务迟迟不能交付。这次维护围绕一个目标：在原有授权内，让任务实际续跑，并把非核心修复限制在明确预算内。 本文记录 HomeLab 的 task-tracker 两批小补丁与一次本地试跑，不是全部任务已收口的声明，也不是新增一套编排平台。 关于 Ralph、ULW 与 Superpowers 是否值得叠加到这套流程，以及为何最终只保留本地证据指针检查窄候选，参见 《Ralph、ULW 与 Superpowers 是否值得接入现有 Agent 工作流》。 关于“检索工具取回文档”与“Agent 实际使用证据”的区别，以及本地知识检索为何暂不全局接入，参见 《Codex 本地知识检索试点：从 SQLite 基线到全局 NO-GO》。 规格驱动工具的另一项独立试点见 《OpenSpec 可回滚试点：可用性通过，为何暂不全局接入》。它只补项目规格层，不替代本文的任务、权限或租约控制面。 当前结论：机制通过，不等于运行权限已恢复 截至 2026-...

#ClaudeCode #Syncthing #开发环境 #服务器运维 上一篇用 Syncthing 打通了三端 ~/.claude/，但直接同步各工作区的 memory/ 目录会遇到一个坑：不同设备的工作区路径编码不一样。本文记录把记忆层重构成 canonical _shared/ + 软链、把 .stignore 从黑名单改成白名单，并新增两个跨工作区 skill 与记忆治理约定的过程——一次完整的"开发环境梳理"。 一、上一版留下的坑：per-encoding 路径错位 Claude Code 把每个工作区的记忆存在 projects/<路径编码>/memory/ 下，而路径编码含绝对路径： Mac：projects/-Users-lin-infra/memory/ Windows：projects/C--Users-milin-infra/memory/ 同一个 ~/infra 工作区，两台机器编码不同。若直接同步 projects/*/memory，两端各写各的目录，记忆根本对不上，同步等于白做。 二、方案：canon...

#N100 #数据恢复 #Docker #systemd #ext4 #btrfs 背景与结论 N100 出现开机即卡死、反复重启并最终无法进入系统。原 128 GB NVMe 被取出，通过 Mac 做只读取证、镜像和文件系统恢复，再克隆到 256 GB NVMe。新盘已经成功从 N100 启动，SSH、系统盘和 Docker 基础能力均通过验证。 本轮能够确认的是： 原系统盘 ext4 存在由异常断电/硬重启留下的 journal、inode bitmap、free count 和 checksum 不一致；修复后连续两次只读检查干净。 原盘完整镜像和独立回读校验一致，ddrescue 未报告读错误或坏扇区。 新 256 GB NVMe 的系统分区和文件系统已扩容，当前根分区约 234 GiB。 旧启动链把 USB 外盘挂载和 Docker 放进主机启动关键路径，会放大外盘、USB 或文件系统异常的影响；现已解耦。 现有证据不能把唯一根因锁定为 Btrfs、Wi-Fi 或某个硬件部件。ext4 损坏是确定事实，但 USB/硬盘柜/供电等因素仍需观察。 旧...

#MTPhotos #Docker #DNS #腾讯地图 #N100 记录 MT Photos 从高德地址解析迁移到腾讯地图时，如何把表面的 API 超时拆成容器 DNS 与签名配置两层问题，并将临时 resolver 修复固化为可重建、可重启的 Docker 配置。 相关：《MT Photos 语义检索接入 RAG 可行性分析》 · 《N100 网络重构与服务修复记录》 一、问题不是单一的“腾讯 API 不通” MT Photos 已切换到腾讯地图 provider，但 GUI 对固定公开坐标执行测试时返回 network timeout。分层探针得到的结果并不支持“腾讯接口故障”这个直觉判断： 层级 N100 宿主 MT Photos 容器 DNS 正常 UDP 查询超时，TCP 查询成功 TCP 443 正常 使用已解析 IPv4 地址可达 TLS/SNI 正常 正常 无凭据 HTTPS HTTP 200 HTTP 200 容器对腾讯和通用对照域名都会在普通 DNS 查询阶段超时，因此故障并非腾讯单域名规则。一次性设置 RES_OPTI...

#OpenClaw #qBittorrent #最小权限 #网络隔离 记录 OC-23：让微信里的“帮我下载 X”能够进入自动化流程，同时不把网页文本、模型判断或一个 magnet 直接等同于下载权限。 相关笔记：《OpenClaw 本地记忆落地与无审批能力边界》 · 《OpenClaw Exec 审批与生命周期治理》 · 《OpenClaw 后续功能规划》 · 《N100 安全事件响应与 fail2ban 加固》 一、问题不在 qB API，而在权限兑换 qBittorrent 的新增、暂停、恢复和删除接口并不复杂。真正危险的是这条隐含链路： 1网页内容 → 模型相信它 → 直接调用下载接口 搜索结果和网页正文都可能包含 prompt injection，也可能指向内网、重定向到不同主机，或提供与页面描述不一致的 torrent。仅靠 system prompt 要求模型“注意安全”，不能形成可审计的权限边界。 因此这轮把流程拆成三个角色： 1download-discovery → download coordinator → deterministic Gate → ...

#OpenClaw #qBittorrent #字幕 #媒体自动化 #最小权限 相关：《OpenClaw 微信安全下载体系》 · 《高权限 NAS Skill 静态审计》 · 《OpenClaw 后续功能规划》 下载完成不等于媒体已经适合进入媒体库。真正麻烦的是后半段：验证音轨和字幕、匹配字幕版本、生成不破坏原件的成品、规范命名、保留来源关系，以及识别重复文件。 这次没有接入第三方 NAS Skill 的预编译二进制、私有 API 或 session。它有价值的部分不是“能执行很多命令”，而是先观察、形成计划、绑定对象、返回结构化结果。实际实现全部使用 N100 上可审计的本地 Python 与固定 ffmpeg/ffprobe。 处理链 qBittorrent 完成对象先经过只读观察器。观察器只接受固定分类和下载根目录，并把 infohash、文件清单、字节数和媒体探测结果写入报告。 后续处理遵循四条硬规则： 只有本地确认过的作品别名才能自动生成媒体库名称；未知标题进入人工审核。 原件始终只读，成品只能写入固定的 OpenClaw-Processed。目标已存在就拒...

#Codex #DeepSeek #CC Switch #服务器运维 Codex Desktop 通过 CC Switch 接 DeepSeek 的完整收口记录：503 来自旧版本地路由的 Responses→Chat 转换层；DeepSeek 已支持原生 Responses，改直连即可；CC Switch 3.19.2 内置 DeepSeek 官方模型目录（low/high/max 三档推理）；Codex Desktop 还需要在「可用推理等级」里启用 max，否则下拉框只显示 low/high。 一、问题现象 Codex Desktop 通过 CC Switch 选择 DeepSeek，请求报： unexpected status 503 Service Unavailable: Unknown error, url: http://127.0.0.1:15721/v1/responses 开启本地路由时，DeepSeek 与 OpenAI 官方接口都不可用 切换到 DeepSeek 后能继承历史会话；切回官方模式时会话为空（provider 索引不一致，属独...

#Windows11 #OpenSSH #防火墙 #最小权限 #安全审计 背景与结论 旧工作节点 milin_win11 长期承担过本地模型、OCR、WSL 和远程维护实验。用途变化后，机器上留下了重复 SSH 启动链、失效端口转发、临时模型发布任务、空 Ollama 服务、宽泛第三方入站规则和测试管理员账户。 本轮没有按“看到监听就停服务”的方式处理，而是先建立受限日常入口和独立管理员维护入口，再按账户、任务、端口、规则、模型与安全基线逐项取证。最终完成以下收口： 日常 SSH 使用标准账户 milin_auto，保持非管理员 token，并禁止端口转发；管理员入口仅用于明确维护。 删除失效的 2222/18789 portproxy、模型 blob HTTP 发布任务、重复 SSH 启动任务和过期 WSL 关机任务。 停止空 Ollama 的登录自启动与 LAN 暴露，但保留软件和未来测试所需模型资产。 删除遗留管理员 sshtest，并把 SSH、ASUS、Logitech、Steam 相关入站规则收敛到实际用途。 计划重启后再次验证任务、账户、规则、S...

#OpenClaw #NAS #SMART #最小权限 最小权限不是把功能永久停在“只能看容量”。更实用的目标是最大安全权限包络：尽量增加诊断能力，但把身份、对象、路径、副作用、回执和回滚全部冻结。 基础快照隔离架构见 《N100 只读 NAS Observer：从高权限 Skill 到快照隔离》。本文只记录后续能力扩展。 一、从五个查询扩展到十七个工具 扩展后的能力分为三组： 九个只读投影：宿主资源、存储、磁盘、SMART 脱敏摘要、共享、Docker 状态、定时任务、统一风险和综合诊断； 固定诊断动作：即时刷新、受控临时写探针、脱敏诊断包、SMART short 计划/启动/状态、配置 preview； 服务恢复 preview：生成对象哈希、身份绑定、十分钟 TTL、单次使用、前后置检查和自动回滚方案，但不开放生产执行。 OpenClaw 仍然没有 Docker socket、root、通用命令、任意路径、凭据或第三方网络。容器日志也不是任意查询，只在宿主端按固定窗口归约为 error、timeout、OOM、storage 等计数，原文不进入快照。 二...

#OpenClaw #NAS #Docker #最小权限 高权限 NAS Skill 未通过供应链与权限门禁，不代表 Agent 只能完全放弃 NAS 可观测性。更安全的做法是把宿主探测和 Agent 工具隔开：宿主定时生成脱敏快照，OpenClaw 只读快照，并只暴露固定无参数查询。 前置审计与不晋级原因见 《高权限 NAS Agent Skill 静态审计：为什么“有确认”仍不足以接入生产》。 一、目标不是移植 fnOS 当前 N100 同时承担 Ubuntu Docker 宿主和 NAS 职责，但它不是 fnOS。原 Skill 依赖 fnOS 私有 API、session 和预编译 CLI，直接移植既不适配，也会把文件、Docker、用户和存储写能力一并带入 Agent。 本阶段只保留五种只读意图： nas_status：容量与容器健康摘要； nas_storage：固定挂载点容量； nas_disks：块设备结构，不含序列号； nas_shares：固定共享挂载状态，不含远端 source； nas_containers：名称、镜像标识、运行状态...

#OpenClaw #Exec审批 #最小权限 #微信 记录 OC-05 的生产审批基线、D2b 审批等待缺陷和 OC-22 微信文本式审批边界。基础插件配置见 《OpenClaw 配置续集》，无审批日常能力见《OpenClaw 本地记忆落地与无审批能力边界》，任务状态见《OpenClaw 后续功能规划》。 一、为什么不能用“始终允许”解决 OpenClaw 的 exec 能触达 shell、网络、Docker 和宿主机文件。把下载或邮件中的一个审批问题转化为通用 shell 放行，会让自然语言、网页内容和 prompt injection 获得远超任务所需的能力。 当前原则是： 123信息获取与固定只读快照 → 无审批有限参数、可验证、可回滚的动作 → 精确 allowlist外发、删除、系统变更和通用执行 → 人工确认 审批模型或语义分类器只能补充风险提示，不能替代确定性的权限策略。 二、生产审批基线 实际生效文件位于 OpenClaw 的容器数据挂载中，而不是顶层历史配置。生产基线已统一为： defaults、main、download、heartbeat：allo...

#OpenClaw #Agent-Skill #供应链安全 #NAS 本文记录一次只做静态取证的高权限 NAS Skill 审计。结论不是“发现恶意代码”，而是：在来源、许可证、构建链和宿主侧权限治理均无法闭合时，功能再完整也不应直接接入生产 Agent。 一、审计边界 目标制品来自厂商官方论坛附件，包含一份 Skill 文档、模块参考、三个平台 wrapper，以及 macOS、Linux、Windows 五个预编译 CLI。审计期间坚持四条边界： 不安装、不执行、不导入 Agent； 不连接 NAS、OpenClaw 或其它生产服务； 文本复制到隔离目录，二进制只在原下载目录做格式、签名、字符串和 SHA-256 取证； 文件清单、字节数和哈希必须逐项复算。 制品共 34 个文件，约 26 MiB，其中五个二进制占绝大部分。隔离目录只保留 29 个文本文件，没有二进制落入后续工作区。 二、供应链先于功能 manifest 声明版本为 0.1.0，但制品没有提供： 源码仓库； 精确 commit 或 tag； LICENSE、COPYING、...

#Docker #WebDAV #frp #Samba #openclaw #服务器运维 背景 路由器设备更换，局域网网段从 192.168.0.0/24 整体迁移至 192.168.2.0/24。N100 重启后各服务需要恢复，同时处理 openclaw 权限修复遗留的路径问题、WebDAV 公网访问故障及 LLM 连接问题。 文章边界：本文是“网段迁移后的整体恢复”事件记录，按同一恢复窗口组织而非作为 WebDAV、Samba、OpenClaw 或代理的长期配置手册。事件闭环后只补勘误、最终状态和专题链接。 本文涉及的 openclaw 权限修复遗留问题，源自 《N100 安全事件响应：OpenClaw SSH 暴力破解与 fail2ban 加固》。 MT Photos 后续腾讯地图迁移中发现的容器 UDP DNS 异常、TCP DNS 声明式修复及 restart 持久化验收，见 《MT Photos 腾讯地图迁移与容器 TCP DNS 持久化》。 一、磁盘检查与挂载恢复 btrfs RAID1 健康验证 2026-08 复核更正： 本节的 no error...

#OpenClaw #FRP #nginx #HTTPS #公网访问 接上篇 《OpenClaw 配置续集：网络修复、邮件插件与 Ollama 接入》，记录第三阶段：为 OpenClaw 配置公网 HTTPS 访问。 文章边界：本文的权威范围是 FRP、nginx、TLS、浏览器 Origin 与设备配对组成的公网访问链路。文中保留的环境变量、CLI 写入和 ollama.auth 故障是当时的连带排障证据；后续通用配置问题应转入对应专题，本文只补充公网链路的勘误或验收结果。 一、整体架构 123456789101112131415用户浏览器 │ HTTPS 443 ▼MyServer（Aliyun 公网，x.x.x.x） └── nginx 反向代理 → 127.0.0.1:17890 │ ▼ frps（已运行，bind_port=6000） │ FRP 隧道 ▼N100（本地，192.168.0.155） └── frpc → 127.0.0.1:18789 │ ...

#OpenClaw #Docker #Ollama #邮件插件 #网络排障 接上篇 《N100 自托管 OpenClaw + Hermes Agent 部署实录》，记录第二阶段的配置与踩坑；后续任务见 《OpenClaw 后续功能规划与待办任务》。 文章边界：本文已作为“基础配置第二阶段”历史实录冻结。邮件、早期 Ollama 和 llama-server 迁移保留当时的完整过程；新的模型路由、执行审批、微信投递和本地记忆只更新各自专题，本文不再追加跨主题实施章节。 一、修复 Docker 容器无法访问公网 WAN TCP 现象 容器内 ping 1.1.1.1 正常（ICMP 通），但 curl https://api.deepseek.com 超时。导致 DeepSeek / Anthropic API 全部失败，日志输出： 1Error: All models failed (2): deepseek/deepseek-chat: LLM idle timeout (120s) 根本原因 N100 使用 WiFi（wlp2s0）上网。Docker bridge 模...

#Docker #btrfs #systemd #服务器运维 2026-08 更新： 本文记录的是旧自动挂载方案，已不再用于当前 N100。外盘现改为 noauto,nofail，Docker 与外盘均退出主机启动关键路径。独立 Rescue U 盘虽通过第一轮静态结构验收，但后续发现包管理内容损坏，当前禁止启动、设置 BootNext 或执行真实镜像。请勿在当前主机照搬下文的 ext-mount.service 和 mount-retry.sh；现行设计、恢复过程与 Rescue 门禁见 《N100 系统盘取证恢复与安全启动重构》。 磁盘与挂载结构 设备 容量 类型 挂载点 说明 sda (SSD) 119G ext4 / 系统盘，已用 93% sdb (WD 4T) 3.6T exfat /smb 外部硬盘，影视/文件共享 sdc (WD 2T) 1.8T btrfs /nfs btrfs 多设备卷成员 1 sdd (2T) 1.8T btrfs —（内核接管） btrfs 多设备卷成员 2 btrfs 卷说明 sdc 与 sdd 共享同一...