🎯 P22：AgentMeshOS 系统基座、职责域与运行闭环重构
📌 计划结论
P22 是 AgentMeshOS 的系统级治理计划，不是一次网络迁移、代码重写或控制台局部改版。它的目标是重新确认系统基座、模块职责、探针业务、告警处理、AI Boss 协作、状态数据和 Console 导航之间的关系，消除当前“部分功能已经实现，但职责、入口和闭环没有统一”的问题。用户已于 2026-11-03 确认本总范围，作为后续 P22-0 只读盘点的边界。
本计划已于 2026-11-03 完成核心范围并归档，但不是原计划全部验收通过。最终收口证据和验收边界见已完成归档；本页保留为详细计划、职责矩阵、验收契约和历史决策原文。
依据是当前架构入口 docs/architecture/index.md、项目宪法 docs/architecture/02_项目宪法.md、总体架构 docs/architecture/03_总体架构设计.md、核心模块设计 docs/architecture/04_核心模块设计.md，以及 P19、P20、P21 的现有计划与收口记录。影响是 P22 将成为后续系统整改的统一范围边界，防止继续用局部补丁修复单个页面或单条告警链路。
当前文档的定位是详细计划与验收底稿：它负责冻结范围、边界、依赖、工作包和验收方向。依据是项目规则要求“完整工作包、四态状态和阶段出口”与“当前阶段摘要”分离维护。影响是后续复核必须同时对照本页和已完成归档，不能只引用计划阶段的初始判断。
🧾 P22 最终收口记录（2026-11-03）
| 收口项 | 最终结论 | 生产证据 |
|---|---|---|
| 101 网络稳定性 | 无线永久关闭后完成重启复验，只有有线默认路由与 DNS | nmcli、ip route、resolvectl、Tailscale BackendState |
| Console 职责域导航 | 六个一级职责组已上线，支持折叠、展开、当前路径恢复 | 生产 Console 静态回读与浏览器契约 |
| 恢复与 AI Boss 分离 | recovery_status 独立于 handling_status，恢复不再冒充 AI Boss 已处理 |
告警状态机测试与 API 契约 |
| 网络唯一数据源 | 节点 UDP 只使用 101、102 双源 Tailnet 快照，不再回退 R4 | 拓扑负向回归 PASS |
| R4 运行对象退役 | 101、102、RR 的相关 service、timer 和当前快照均已移除 | 三节点 LoadState=not-found 与运行目录回读 |
| R4 历史归档 | 单元、快照、程序文本、状态、二进制哈希和环境文件元数据已保存到 101 备份盘并附 SHA256 清单 | 20261103T201022+0800 与 20261103T203934+0800 两个批次 |
| 生产部署回读 | API Gateway v0.18.0、Console 与文档站镜像健康，Reachability Refresh 执行器哈希一致 | 容器健康、镜像 revision、/health 与文件 SHA256 |
🧭 初始化决策与分支边界
| 分支 | 原始设想 | 当前决定 | 处理方式 |
|---|---|---|---|
| 分支一：建立总计划 | 先建立 P22 总计划，再逐项讨论、修正和执行，最后统一更新架构基座与 Console | 重新启动 | 作为当前 P22 主线 |
| 分支二：先改整体网络架构 | 先迁移 RR 或改变整体节点网络，再用新网络约束 P22 | 取消 | 不再拆分工作包，不进入 P22 |
| 分支三：推倒重建整套系统 | 新建一套干净生产栈，整体交割后下线旧系统 | 暂停 | 不作为 P22 前置条件，不继续向下分发 |
| 代理链路与节点网络分离 | 将代理网络职责从节点网络中分离 | 保留为局部议题 | 作为 P22 的一个候选工作包，不代表 P22 全部范围 |
P22 的正式方向是：先认清系统，再确认职责，再重建闭环，最后统一修改基座和 Console。网络架构迁移和整套系统重建若未来重新启动，必须另立计划并重新评审。
📚 目录
- 计划结论
- 初始化决策与分支边界
- 系统范围与目标
- 目标 Console 信息架构
- P22-0 详细规格：范围冻结与事实盘点
- P22-1 详细规格：模块与职责域重构
- P22-2 详细规格：探针业务与告警闭环
- P22-3 详细规格：告警与 AI Boss 联动模型
- P22-4 详细规格：权威数据与状态源统一
- P22-5 详细规格：Console 导航与页面归属
- 现状事实与根因假设
- 数据、状态与职责契约
- 工作包总表
- 验收与证据要求
- 分布式底座接入声明
- 回退与兼容原则
- 风险与未决项 / 需要用户决策
- 下一步
🧩 系统范围与目标
目标范围
| 领域 | 本计划要解决的问题 | 预期结果 |
|---|---|---|
| 系统基座 | 架构文档与实际运行职责存在漂移 | 形成一份与生产事实一致的职责模型 |
| Agent 与节点 | Agent、节点、网络节点、控制面节点和平台服务边界混杂 | 每个节点和模块有明确角色、能力、权限和状态来源 |
| 探针体系 | 探针既有网络探测，也有业务健康、运行态和资源检查，但没有完整清单 | 每个探针都有业务目的、运行状态、数据出口和责任归属 |
| 告警中心 | 告警产生、恢复、关闭和“已处理”之间责任不清 | 明确发现、通知、处置、恢复和关闭的状态机 |
| AI Boss | AI Boss 是否参与处理、是否真的执行过、是否只是展示不清楚 | AI Boss 处理记录与告警事件形成可验证关联 |
| Console 导航 | 告警中心、OA、AI 平台等被错误放入 Agent 状态 | 按工作台、Agent 与节点、网络态势、平台服务、告警与处置、系统维护重新组织 |
| 数据与证据 | 页面可能使用不同快照或重复探测 | 统一权威数据源、更新时间、证据引用和过期标识 |
| 架构文档 | 原始文档描述的架构和当前实际系统不同 | 讨论定稿后一次性更新基座，保留历史更正记录 |
明确不包含
本阶段不执行 RR 迁移、不更换控制面、不新建第二套生产 Runtime、不重建整套 AgentMeshOS、不改动生产网络、不自动恢复已暂停的 P19 工作包，也不因为 P22 立项就重新启用已归档阶段。
🧭 目标 Console 信息架构
用户已经暂时接受以下六个一级方向，作为 P22 的初始设计约束。它们是待评审的目标结构，不代表当前 Console 已经完成改造。
| 一级导航 | 主要内容 | 归属边界 |
|---|---|---|
| 工作台 | 当前问题、待处理事项、系统总览 | 面向日常工作的入口，不复制底层状态机 |
| Agent 与节点 | Agent 状态、节点管理、任务运行、节点能力 | 展示 Agent 和节点运行事实 |
| 网络态势 | 实时分布图、网络可达性、节点路径视图、双节点诊断 | 展示 IP、TCP、UDP、Tailnet、Peer Relay、DERP 和业务链路 |
| 平台服务 | OA 平台、AI 平台、存储与文件、搜索与外部服务 | 展示平台服务，不归入 Agent 状态 |
| 告警与处置 | 当前告警、历史告警、AI Boss 处理记录、恢复与审计 | 展示错误输出和处置闭环 |
| 系统维护 | 发布与部署、运行检查、变更记录、系统证据 | 面向维护和证据，不作为日常首页入口 |
“基线、变更、例外、审计”等治理资料继续保留，但原则上作为第二层证据或详情内容，不再作为普通用户的第一层导航。
导航层级可读性与折叠交互
当前 Console 已经存在菜单分级，问题不是“没有层级”，而是层级视觉差异和展开状态不够清楚。P22-5 必须把以下内容作为正式设计目标：
| 层级 | 必须表现 | 交互要求 | 验收重点 |
|---|---|---|---|
| 一级导航 | 平台主领域，如“工作台”“网络态势”“告警与处置” | 始终可识别；当前一级区域有明确选中状态 | 用户能一眼看出当前属于哪个系统领域 |
| 二级导航 | 该领域下的功能组，如“网络可达性”“节点路径视图” | 与一级导航有稳定缩进、字号、颜色或分隔差异 | 不得与一级菜单混成同一层 |
| 三级或页面入口 | 具体页面、详情或诊断入口 | 只在需要时展示，避免首屏过度展开 | 能看出它属于哪个二级功能组 |
| 折叠状态 | 当前未展开的功能组 | 显示折叠图标和展开方向，不隐藏当前选中路径 | 用户能知道还有下级内容 |
| 展开状态 | 当前正在浏览或操作的功能组 | 支持展开、收起；当前路径保持可见 | 切换页面后状态不丢失或产生误导 |
| 移动端状态 | 有限宽度下的导航层级 | 使用同一套自定义抽屉/折叠交互，不横向溢出 | 一级、二级、当前项仍能区分 |
推荐交互是“一级导航可见，二级导航按组折叠，当前路径自动展开，用户可以手动收起；刷新或重新进入时恢复合理的当前组状态”。这不是简单增加箭头，而是要同时定义缩进、字号、颜色、分隔线、选中态、悬停态、键盘焦点、移动端行为和无障碍语义。最终视觉方案必须以当前 Console 主题为基准，不能引入浏览器原生 alert、prompt、confirm 或与项目主题不一致的系统弹窗。
🧭 P22-0 详细规格：范围冻结与事实盘点
📌 工作包结论
P22-0 不是“把已有文档再读一遍”，而是建立后续所有职责、页面和状态判断的事实基线。它必须只读盘点当前仓库、运行服务和 Console 页面，形成一份带来源、时间、状态和可信等级的资产清单。依据是项目宪法中的“真实状态优先”原则，以及 P22 当前发现的架构、探针、告警和导航漂移。影响是 P22-1 和 P22-5 只能使用 P22-0 已冻结的事实，不能按页面名称或历史记忆自行推断。
📊 盘点范围与证据优先级
| 盘点域 | 必须回答的问题 | 首选证据 | 禁止替代 |
|---|---|---|---|
| 架构文档 | 哪些文件是现行权威，哪些只是历史或归档 | docs/architecture/、docs/plans/state.json、计划索引 |
只看路线图标题 |
| Console 页面 | 当前有哪些路由、页面、标签、入口和重复页面 | 已部署 Console 路由清单、API 返回、真实浏览器页面 | 只看导航文字 |
| 导航结构 | 每个入口的一级、二级、三级归属是什么 | 页面路由与实际功能映射 | 按文件目录猜归属 |
| 探针 | 探针的业务目的、调度、输入、输出和运行状态是什么 | 注册配置、timer/service、运行快照和日志 | 只按告警表反推探针 |
| 告警 | 哪些探针真正进入告警，恢复和关闭由谁触发 | 告警事件、恢复事件、状态机和审计 | 只看当前角标 |
| AI Boss | 是否接收、分析、执行、等待人工和完成 | Runtime 事件、处理记录、动作审计 | 把告警已恢复当成 AI Boss 已处理 |
| 数据源 | 哪个页面读取哪个快照或接口，是否重复探测 | API 路由、快照字段、刷新器和调用记录 | 只按页面显示结果判断 |
| 运行职责 | 当前节点、服务、Agent、网络和平台服务各自承担什么角色 | 部署清单、服务状态、架构文档和实时回读 | 只按主机名称判断 |
证据优先级固定为：实时运行回读 > 正式配置/代码契约 > 当前架构文档 > 计划与历史记录 > 推断。低等级资料可以提出待核对项，但不能直接冻结为系统事实。每条事实至少记录来源、读取时间、对应对象、状态和“已验证/待验证/冲突”标记。
🧩 P22-0 产物与字段
P22-0 必须产出以下四份结果；它们属于计划验收材料，不新增运行时数据库。
| 产物 | 最低内容 | 后续用途 |
|---|---|---|
| 系统事实清单 | 模块、服务、节点、页面、探针、告警、事件、数据源和状态 | 作为 P22-1 职责边界输入 |
| 页面归属初表 | 路由、页面名称、当前入口、目标一级/二级/三级归属、重复/冲突标记 | 作为 P22-5 导航重构输入 |
| 探针—告警—AI Boss 关系表 | 探针目的、运行状态、是否告警、恢复事件、AI Boss 入口和证据 | 作为 P22-2、P22-3 输入 |
| 冲突与待决清单 | 文档与运行态不一致、重复权威源、缺失页面、未登记探针和历史残留 | 作为 P22-1 和 P22-6 的整改边界 |
每条清单记录至少包含：人类可读名称、内部对象标识、所属职责域、权威来源、更新时间、当前状态、证据位置、冲突说明和下一步。内部编号只能作为二级证据，不能作为用户界面的主标题或结论。
🔧 P22-0 执行步骤
- 固定本轮读取范围和只读边界，确认不修改
state.json、生产配置、服务和页面代码。 - 读取架构入口、项目宪法、核心模块、AI 协作、部署规范、路线图、P19 至 P21 计划和当前计划看板。
- 盘点 Console 当前导航、路由、页面功能、API 来源和页面重复项，区分“存在于代码”“已发布”“当前可访问”三种状态。
- 盘点探针、刷新器、timer、service、告警适配器、恢复事件和 AI Boss 处理事件，建立对象关系，不以告警记录反推全部探针。
- 对每一项冲突保留双方证据，先标记为“冲突/待决”，不使用局部补丁掩盖差异。
- 由用户确认范围和重大职责冲突后，冻结 P22-0 基线，才允许进入 P22-1 和 P22-5 的详细设计。
🧪 P22-0 完成标准
| 验收项 | 通过条件 | 失败表现 |
|---|---|---|
| 范围完整 | 架构、Console、探针、告警、AI Boss、数据源和节点职责均有记录 | 只盘点某一个页面或某一类探针 |
| 证据可追溯 | 每条事实可回指文件、接口、运行回读或日志 | 只有结论没有来源 |
| 状态不混淆 | 设计、仓库修改、已部署、已验证四态分开 | 用计划文字冒充生产完成 |
| 冲突不丢失 | 文档与运行态冲突单独登记并保留两侧证据 | 直接选择一侧覆盖另一侧 |
| 只读边界成立 | 没有代码、配置、服务或生产写入 | 盘点过程改变运行状态 |
| 用户可读 | 主表使用业务名称和人类可读状态，技术字段折叠为证据 | 直接把编号、端口和内部字段当主结论 |
📊 P22-0 只读盘点记录（2026-11-03）
本轮已完成第一批只读事实盘点，范围覆盖当前工作区的架构入口、Console 导航与路由、API Gateway 告警接口、AI Runtime 告警生命周期、探针源码、systemd 单元定义，以及 101 本机的探针 timer/service 运行回读。结论是：P22-0 尚未完全冻结，但已经确认了三类必须进入后续职责重构的事实：Console 目前只有视觉分组，没有真正的一级/二级/三级导航；探针与告警的接入关系是“部分统一、部分独立”；运行检查把“按时启动”与“业务探测成功”混在了一起。
证据边界如下：源码和仓库配置属于“正式定义已确认”；101 本机 pcdell-101 的 systemd 回读属于“当前节点运行态已确认”；RR/API Gateway 正式告警数据库、102、RR、MM、d02、DD、dog 的生产运行态在本轮尚未直接回读，因此不能把本表写成全网生产结论。影响是后续 P22-0 仍需要补做跨节点和告警数据库的只读核对，但不需要推翻本轮已确认的职责冲突。
🧭 Console 页面与导航归属初表
| 事实项 | 当前只读结论 | 证据 | 状态与影响 |
|---|---|---|---|
| 当前视觉分组 | 只有“工作台”“Agent 状态”“系统入口”三个平面分组 | tools/console-site/src/index.html 的 nav-label 与连续 nav-item |
仓库源码已确认；尚未形成真正层级 |
| Agent 状态混入内容 | 网络态势、告警中心、AI 平台运行概览、CPA、MCP 记忆、Web 搜索、OpenCode 记忆库、OmniRoute 均放在该组 | tools/console-site/src/index.html |
仓库源码已确认；与 P22 目标职责冲突 |
| 网络页面内部结构 | 网络态势页已有“网络可达性”“网络态势实时分布图”“节点路径视图”三个标签，并已有“两节点链路诊断” | tools/console-site/src/index.html、tools/console-site/src/app.js |
仓库源码已确认；P22 不应重复创建网络页面 |
| 路由与数据来源 | #topology 读取 /api/network/topology；#alerts 读取 /api/alerts?scope=all；AI Boss 读取 /__agentmeshos/boss/v1 |
tools/console-site/src/app.js |
仓库源码已确认；三者数据边界可继续统一 |
| 折叠/展开 | 导航没有组级折叠按钮、父子层级状态或当前路径自动展开逻辑；现有折叠主要位于页面内部 | tools/console-site/src/index.html、tools/console-site/src/app.js |
仓库源码已确认；属于 P22-5 实施缺口 |
| 页面主归属 | 当前导航按历史入口排列，不是按 Network、Platform、Alert、AI Boss 等职责域排列 | tools/console-site/src/index.html、tools/console-site/src/app.js |
仓库源码已确认；需由 P22-1 冻结后改造 |
🧪 探针、调度、业务目的与告警出口关系表
下表只列出本轮已在仓库中找到的正式探针或探针相关机制。直接接入告警表示源码中明确调用统一告警适配器或告警评估器；仅业务输出表示当前只发现快照、日志、退出码或专用接口，尚未证明会进入告警中心。
| 探针或机制 | 业务目的 | 调度/来源 | 当前输出 | 告警中心关系 | 当前状态 |
|---|---|---|---|---|---|
| 中国网络可达性 / Globalping | 观察中国方向主机、入口和网络可达性 | tools/network-probe/src/collector.py、agentmeshos-globalping-china-probe.py、网络采集部署脚本 |
网络可达性快照与配额台账 | 网络拓扑可在 --alert 时投影 network-topology；Globalping 采集器是否独立生成告警仍需生产回读 |
定义已确认，生产状态待核对 |
| DERP 资格探测 | 根据可达性结果维护 Headscale DERP 资格/地图 | tools/network-probe/src/derp_eligibility_probe.py、agentmeshos-derp-eligibility.py、对应 timer |
DERP 资格快照、Headscale 资格计划 | 本轮未确认其直接调用统一告警适配器；不能把“资格变化”自动等同于告警 | 定义已确认，告警关系待核对 |
| Tailnet UDP 101/102 | 在同一套 Tailnet 网络中，由 101、102 两个观测点观察直连、Peer Relay/DERP 路径 | tools/tailnet-udp-probe/src/probe.py 与两节点部署脚本，5 分钟一轮 |
tailnet-udp-v1.json、tailnet-udp-102-v1.json |
本轮源码未确认其直接进入告警；网络页面读取统一快照，不能据此推断已产生告警 | 101、102 timer 均已回读为 active/enabled |
| R4 Proxy UDP 101/102 | 观察代理 UDP/QUIC 业务通道 | tools/proxy-udp-probe/src/probe.py、两节点部署脚本 |
proxy-udp-v1.json、proxy-udp-102-v1.json |
由 tools/probe-plan/src/alert_eval.py 统一评估，并经 agentmeshos-probe-alert.sh 使用 runtime-probe scope |
101、102 timer 均已回读为 inactive/disabled；只能列为退役/人工诊断 |
| R4 探测计划器与告警评估器 | 分配 101/102 探测槽位并根据合并结果形成告警 | scripts/deploy/probe-plan/agentmeshos-probe-plan-deploy.sh；计划每 1 分钟刷新，告警评估每 5 分钟 |
计划文件、状态文件、告警去重状态 | 直接接入统一告警适配器 | RR 已回读为已安装但 inactive/disabled；属于退役对象 |
| 探针陈旧检查 | 检查一组 timer/service 是否按周期触发 | agentmeshos-probe-stale-check.py，5 分钟一轮 |
每个登记单元的年龄、缺失或启动异常结果 | 直接向 runtime-probe 发送 DEGRADED/HEALTHY |
101 本机运行正常，但监测范围不完整 |
| 备份健康检查 | 检查备份服务、独立备份盘和最近成功时间 | agentmeshos-backup-health-check.sh，5 分钟一轮 |
备份健康、磁盘挂载和容量结论 | 直接使用 Console 告警提交入口；恢复事件也由脚本发送 | 101 本机最近一次执行成功 |
| OmniRoute 健康观察 | 记录迁移后的 OmniRoute 服务、边缘代理和官方健康事实 | agentmeshos-omniroute-health-observation.py，15 分钟一轮 |
/srv/codex-hub-backup/agentmeshos/omniroute-health/observations/ 下的证据文件与退出码 |
本轮未找到直接调用统一告警适配器的源码证据；目前主要依赖 systemd 失败态和陈旧检查 | 101 本机连续以退出码 1 失败，需单独处理 |
| Edge DNS 控制器 | 评估保存的 Globalping Edge 快照并执行受控 DNS 切换 | agentmeshos-edge-dns-controller.py，30 秒一轮 |
Edge 候选、切换和 DNS 评估状态 | 直接使用 agentmeshos-probe-alert.sh 投影 runtime-probe |
101 本机最近一次执行成功 |
| Home Bridge 状态拉取 | 拉取 Home Codex Host Bridge 只读状态 | agentmeshos-home-bridge-status-pull.sh，2 分钟一轮 |
Home Bridge 状态快照 | 直接使用统一告警适配器 | 101 本机最近一次执行成功 |
| Runner 容量门禁 / 卡死看门狗 | 检查 GitHub Actions runner 容量、卡死和必要的受控恢复 | runner-capacity-gate.sh、runner-stall-watchdog.sh，1/5 分钟一轮 |
runner 状态、日志和动作结果 | 直接使用统一告警适配器 | 101 本机 timer 运行，业务结果仍需独立核对 |
| Android ADB 网络桥 | 读取 Android 设备网络计数并导入清洗快照 | agentmeshos-android-adb-network-bridge.sh、agentmeshos-android-network-probe-import.sh，1 分钟一轮 |
Android 探针快照与 API 接收记录 | 直接使用统一告警适配器；业务数据另有 /api/android/probes/ingest |
101 本机 timer 运行，设备业务状态待核对 |
| ClawBot 状态探针 | 检查微信/ClawBot 绑定、通道和探测结果 | agentmeshos-clawbot-status.py |
ClawBot 脱敏状态快照 | 直接使用 runtime-probe；支持 --no-alert，因此存在“只写快照不告警”的分支 |
定义已确认，实际启动参数待核对 |
| 日志与资源门禁 | 检查日志风暴、磁盘阈值与 OOM 签名 | agentmeshos-log-guard.sh |
资源台账与退出码 | 直接使用统一告警适配器 | 101 本机 timer 运行 |
| SearXNG/搜索健康 | 检查搜索服务或外部搜索健康 | searxng-google-health、searxng-endpoint-probe 单元 |
日志和健康结果 | 本轮未确认所有搜索检查都进入统一告警 | 需要逐单元核对 |
本表暴露出的核心缺口是：项目存在“探针注册表”，但还没有一份可供 Console 读取的统一探针目录。当前 agentmeshos-probe-stale-check.py 只登记 7 个单元，而 101 本机实际还存在 Android、Memory、Edge DNS、Home Bridge、SearXNG、备份、Tailnet UDP、项目副本等其他观察对象；其中 memory-probe-101.timer 在 101 本机回读为 enabled/active，但对应的仓库部署单元未在本轮限定的正式定义中找到，应标为“运行中、来源待确认”，不能据此删除，也不能继续作为无人负责的隐式探针。P22-2 必须先定义“正式探针目录”和“非告警业务观察”的边界，不能继续靠脚本列表和告警记录拼接。
🔔 告警发现、恢复、AI Boss 处理与关闭关系表
| 环节 | 当前源码行为 | 已确认依据 | 当前判断 |
|---|---|---|---|
| 故障发现 | 探针或 Runtime 通过 HMAC 签名提交 /api/alerts/ingest；同一去重键重复上报只刷新最近观测时间和次数 |
tools/api-gateway/src/main.py 的告警接收与去重逻辑 |
发现链路存在 |
| 恢复发现 | severity=resolved 的恢复事件进入接收接口；link_recovery_alert() 按组件上下文关联活动告警 |
tools/api-gateway/src/main.py |
恢复由来源探针报告，不等于 AI Boss 执行修复 |
| 自动变为已处理 | API Gateway 初始化时会把 severity=resolved 的待处理记录改成 handling_status=completed；后续恢复事件也会把匹配活动告警标记为 completed |
initialize_alert_store()、link_recovery_alert() |
这正是“没有人手工处理，但告警显示已处理”的代码原因 |
| 告警已读 | Console 的 /read 只记录管理员查看和审计，不改变故障处置状态 |
tools/api-gateway/src/main.py、tools/console-site/src/app.js |
已读与已恢复/已处理应继续分开 |
| AI Boss 接收 | Console 创建 Incident，Runtime 先写 processing，再调用 alerts.update_incident() |
tools/console-site/src/app.js、ai-runtime/src/main.py、ai-runtime/src/alerts.py |
AI Boss 接收链路存在 |
| AI Boss 完成 | 当前多数告警类型进入 needs_benson_decision；没有已验证 Handler 时不会自动修复 |
ai-runtime/src/main.py 的 process_incident() |
AI Boss 处理与来源恢复是两条独立链路 |
| 历史关闭 | 旧 C2/C3 事件在 Gateway 初始化时按历史截止时间标记完成并写入 historical_closed |
tools/api-gateway/src/main.py |
历史自动关闭必须在页面单独标明，不能进入当前告警 |
| 当前闭环是否完整 | 发现、恢复、告警投影和 AI Boss 处置对象都有；但探针目录、生产事件关联、恢复来源和跨节点数据库回读尚未统一 | 以上源码与 101 本机回读 | 当前只能判定为“源码闭环、运行态未冻结” |
⚠️ 已确认冲突与根因候选
| 冲突 | 证据 | 根因判断 | P22 后续处理 |
|---|---|---|---|
| 探针按时触发但业务失败仍被判健康 | 101 本机 OmniRoute 观察在 2026-11-03 01:32 至 03:02 多轮退出码 1；同一时段陈旧检查仍输出 HEALTHY |
probe-stale-check.py 有意只把 200/201/203/216/217/218/226 视为启动失败，普通退出码 1 被当成“探针确实运行”而不是“业务失败” |
P22-2/P22-4 明确区分“调度健康”“探针执行成功”“业务目标健康”三种状态 |
| 探针清单不完整 | 陈旧检查只登记 7 个单元；101 本机还存在未纳入该清单的 timer/service | 没有统一探针注册目录，陈旧检查、告警适配器和 Console 各自维护部分列表 | 建立单一探针目录，明确每项是否纳入告警、谁负责恢复、谁只服务自身业务 |
| Console 导航没有真正层级 | 三个平面 nav-label 下所有入口都是同级按钮，没有父组状态 |
页面增加速度快于职责域重构，导航按历史入口累积 | P22-1 冻结归属后由 P22-5 统一改造 |
| 恢复事件会关闭原告警，但不代表修复动作存在 | API Gateway 自动关联后续 resolved 事件，AI Boss 另有 Incident 生命周期 |
“来源已恢复”“AI Boss 已处置”“管理员已验证关闭”共用用户可见的“已处理”语义 | P22-3 细化独立状态和页面文案，保留恢复来源与证据 |
| 101 本机存在独立失败业务 | OmniRoute 观察连续失败；Project DD 副本在 2026-11-03 03:00 因 SSH 连接超时失败 | 这是实际业务探针失败，不等于告警中心整体失败 | 先在 P22-0 记录并在后续运维事件中单独处理，不在本计划中用导航改造掩盖 |
🧪 P22-0 当前阶段结论
本轮 P22-0 已达到“跨节点运行态取得多批证据、重大冲突已登记、告警语义决策已冻结、停用探针退役删除边界已确认、101/102/RR 当前探针分层已回读”，尚未达到“统一探针目录和全网告警关系冻结”。已完成的是：Console 现状、源码告警状态机、AI Boss 生命周期、主要探针类型、101/102 网络探针运行态、RR 集中探针运行态、101 业务探针分层、RR 告警数据库当前记录与动作分布、四台 VPS 本机职责边界、关键失败证据、同一套 Tailnet 的两个观测点定义，以及“已恢复”和“AI Boss 已处理”必须分开的用户决策。尚未完成的是：所有仓库探针与实际 timer/service、集中观察目标、页面投影和告警出口的逐项对齐，以及代表性生产告警的完整事件链回读。
下一步仍不进入代码实施。先完成“本机运行、集中观察、仅业务输出、已停用历史”四类探针目录，并从 RR 告警事件中按 producer、context、恢复来源和 AI Boss incident_id 回读代表性样本；用户已经确认的状态语义直接作为 P22-2/P22-3 的设计约束，不再重复等待同一决策。P22-0 只有在目录、事件链和页面投影逐项对齐后，才能标记为事实冻结。
🌐 跨节点只读回读（2026-11-03）
本轮从 101 按节点登记表显式解析地址、端口、用户和密钥，使用带墙钟、CPU、I/O 和输出上限的只读 SSH 回读；没有修改远端配置、服务或告警数据。回读结果说明：网络探测不是“五台 VPS 各自运行一套探针”，而是由 RR、101、102 集中运行不同职责的探针，再把结果投影到网络页面和告警中心。
| 节点 | 本轮确认的探针/调度事实 | 证据边界 | 对 P22 的影响 |
|---|---|---|---|
| RR | DERP 资格、网络拓扑、网络采集、Edge Endpoint、Home Bridge 等 timer 在运行；告警数据库存在 | RR 本机 systemctl list-timers 与告警库只读聚合 |
RR 是网络与告警的主要集中采集点 |
| 101 | Tailnet UDP 101、探针陈旧检查、备份、Edge DNS、Runner、Android ADB、OmniRoute 观察等在本机运行；OmniRoute 观察连续退出码 1 | 101 本机 systemd 与 journal | 101 同时承担项目交付、探针观测和告警适配，不是单一业务角色 |
| 102 | Tailnet UDP 102 timer 在运行 | 102 本机 systemd 只读回读 | 102 是第二 Tailnet 观测源，但本轮尚未完成其全部探针/告警关系核对 |
| MM | 本次限定的 systemd 筛选发现 Edge Endpoint timer | MM 本机限定列表回读 | MM 的 Edge 能力和集中式网络探测职责必须分开展示 |
| d02 | 本次限定的 systemd 筛选未发现 AgentMeshOS 探针 timer | d02 本机限定列表回读 | 不能把 d02 没有本地 timer 写成“d02 不参与网络状态”；还需核对 RR 集中探测结果 |
| DD | 本次限定的 systemd 筛选未发现 AgentMeshOS 探针 timer | DD 本机限定列表回读 | DD 的存储/Edge 业务状态与网络可达性由集中探针观察，不能按本机 timer 推断 |
| dog-public | 本次限定的 systemd 筛选未发现 AgentMeshOS 探针 timer | dog 本机限定列表回读 | dog 的正常状态来自集中观测和节点能力投影，不要求本机部署同一套探针 |
上一批 RR 告警数据库只读聚合（2026-11-03 早前回读）给出了闭环的关键事实：当时共 827 条记录，handling_status=completed 为 827 条，pending/processing/needs_benson_decision/failed 均为 0；其中 804 条 read_at 为空。按严重级别统计，resolved 758 条、critical 48 条、warning 21 条。来源最多的是发布控制器 722 条，其次是 101 探针 35 条、存储健康 19 条、AI Runtime 13 条。审计动作包含 recovery_linked 56 次、historical_closed 5 次、boss_completed 7 次、boss_processing 3 次、boss_needs_benson_decision 3 次，只有 3 条告警带有 incident_id。这些数字是带读取时间的历史快照，不应被页面当作永久总量。
这些数字直接确认三个问题。第一，告警中心不是没有“未读”，而是“未读”与“待处理”被分成两个统计口径：数据库仍有 804 条未读，但全部已经是 completed，所以页面的“待处理”会显示为 0。第二，当前大量“已处理”来自来源恢复关联、发布控制器或历史关闭，不等于 AI Boss 处理；真正进入 AI Boss Incident 的记录只有 3 条，不能用总完成数代表 AI Boss 处置量。第三，告警库已经记录了恢复和 Boss 动作，但没有形成可供用户直接理解的“恢复来源—是否执行动作—是否验证关闭”统一视图，这正是 P22-2/P22-3 的职责问题。
本轮跨节点回读仍不等于全网探针闭环完成。RR、101、102 的集中探针和告警关系已取得第一批证据；MM、d02、DD、dog 的本地 timer 只证明限定筛选下的本机调度，不证明它们在网络可达性中没有被集中探测。后续必须把“本机探针”“集中探针目标”“页面投影对象”三类关系写入统一探针目录，并为每条记录标注“本机运行、集中观察、仅业务输出或真正接入告警”。
🧪 第二批运行态回读：现行网络探针与过渡探针分离（2026-11-03）
本轮继续以只读方式回读 101、102、RR 及四台 VPS 的 systemd、快照和告警适配状态，没有执行手动探测、没有消耗 Globalping 额度，也没有启停或修改任何服务。结果已经足以冻结“哪些探针属于当前网络主口径”的第一版事实。
| 对象 | 实际回读结果 | 业务解释 | 当前判断 |
|---|---|---|---|
| 101 Tailnet 路径探针 | agentmeshos-tailnet-udp-probe.timer 为 active；最新快照在本轮读取前约 1 分钟内生成，来源为 101 |
观察 101 到在线节点的真实 Tailnet 路径，区分直连、Peer Relay、DERP 和无响应 | 现行网络 UDP 主探针，非独立告警探针 |
| 102 Tailnet 路径探针 | agentmeshos-tailnet-udp-probe-102.timer 为 active；最新快照与 101 相差约 1 分钟，来源为 102 |
提供第二观测源，用于路径对照和“任一来源直连即正常”的页面汇总 | 现行网络 UDP 主探针，非独立告警探针 |
| 101/102 代理 UDP 探针 | 两台 agentmeshos-proxy-udp-probe*.timer 均为 inactive/disabled；两份旧快照仍停留在 2026-11-01 |
这是 R4 Hysteria2 端到端过渡诊断，不再代表节点网络 UDP | 代码仍存在、生产调度已停用，必须标为历史/过渡数据，不能继续作为当前网络状态 |
| RR Globalping 主机与公网入口 | agentmeshos-network-collector.timer active；本轮读取到新的 china-reachability-v1.json |
负责五台公网节点的主机可达性和公网入口 TCP 443，不负责节点间 UDP | 现行集中探针 |
| RR DERP 资格探针 | agentmeshos-derp-eligibility-probe.timer active；本轮已回读最近触发时间 |
依据公网入口证据维护 DERP 资格，不等于每条节点路径都正常 | 现行控制探针；是否形成独立用户告警仍需在 P22-2 冻结 |
| RR 网络拓扑采集 | agentmeshos-network-topology.timer active；本轮已回读最近触发时间 |
生成实时分布图、主机身份和业务链路投影，并可在冷连接金丝雀翻转时发 network-topology 告警 |
现行页面投影与特定告警出口 |
| RR 旧代理探测计划 | agentmeshos-probe-plan.timer inactive，运行目录中的计划文件不存在；RR 仍保留代理告警状态文件 |
计划器已经退出当前调度链，但旧状态文件仍可能被历史页面或告警统计读取 | 运行对象已停用，历史状态残留是 P22-0 必须登记的冲突 |
| 101 探针告警适配器 | /var/lib/agentmeshos/probe-alert 当前有 14 个状态/升级文件，覆盖 Android ADB、Edge DNS、Home Bridge、日志、Memory、OmniRoute、Runner、SearXNG 等 |
这些是 101 上各业务探针自己的告警去重与升级状态，不是网络 UDP 快照本身 | 告警出口存在，但探针目录与告警目录仍未统一 |
| 四台 VPS 本机 | MM 只有 Edge Endpoint timer；dog 有 Three Dogs 业务同步 timer；d02、DD 本轮限定筛选未发现 AgentMeshOS 网络探针 timer；四台均未发现本机网络快照 | VPS 节点主要作为被观测目标、Edge/DERP/Peer Relay 或业务服务节点，不是每台各自运行一套网络探针 | 当前网络主口径来自 RR、101、102 集中探测，不能按 VPS 本机 timer 判断其网络状态 |
路径快照的实际结果也验证了现行汇总规则：本轮 101 与 102 都能看到 RR、d02、DD、dog 通过直连路径；MM 在两个观测点上都显示为经 DERP。两份快照分别来自同一套 Tailnet 网络中的 101、102，时间相差约 1 分钟，说明两个观测点在连续刷新；该结论只用于网络路径页面，不代表公网入口 TCP、业务网站或代理 UDP 端到端状态。
探针目标映射已经可以从正式代码冻结为三层关系。第一层，Globalping 常态采集器固定检查 RR、MM、d02、DD、dog 五个公网目标，Edge 候选为 MM、d02、DD、dog；每个目标输出主机状态、公网入口状态和独立时间。第二层，101/102 Tailnet 探针从登记表和在线节点发现目标，输出每个观测源到节点的路径和时间；两份结果由 API Gateway 合并，页面不应重新发起探测。第三层，代理 UDP 探针仍保留旧目标集合 RR、MM、d02、DD、dog，但调度已经停用，不能再投影为当前节点 UDP 状态。
告警关系的第二批核验进一步明确了“有快照不等于有告警”。Tailnet UDP 探针源码只负责 tailscale status、tailscale ping、原子写入快照和发布到 RR，没有调用统一告警适配器；因此当前 Tailnet UDP 结果进入网络页面，但没有被证明会直接在告警中心生成逐节点告警。Globalping 采集器同样主要写入可达性快照和额度台账；网络拓扑采集器只有在启用 --alert 且冷连接金丝雀发生状态翻转时，才向 network-topology 告警出口发送事件。代理 UDP 过渡链路则由 RR 的 alert_eval.py 合并 101、102 两个观测点产生的旧快照后调用 runtime-probe 告警适配器，但其生产 timer 已停用，旧告警状态不能代表当前网络探针仍在运行。
因此，P22-0 当前可以把探针分成四种可读类别：现行页面数据源、现行告警来源、仅业务观察、已停用但保留历史资料。同一探针可以同时属于前两类，也可能只属于其中一类；后续不能再用“文件存在”“timer 存在”或“告警库里曾出现过”推断它当前仍在运行。
🧭 第三批运行态回读：集中探针与本机业务探针分层（2026-11-03）
本轮于 2026-11-03 约 10:34 CST 继续只读回读 101、102 和 RR 的 timer、unit 文件及最近触发时间，没有启停服务、删除文件或修改配置。结果进一步确认：当前网络探测和业务探针分层运行，不能把所有 AgentMeshOS timer 都当成网络探针，也不能把“节点没有本机网络 timer”解释为该节点没有被集中观测。
| 节点 | 当前运行对象 | 已确认业务含义 | 状态分类 |
|---|---|---|---|
| 101 | Tailnet UDP、Edge DNS、日志资源门禁、Memory、Android ADB、备份、Home Bridge、Runner、OmniRoute 观察、探针陈旧检查等 | 101 同时承担网络观测点、项目交付和业务健康观察 | 本机业务探针 + Tailnet 网络观测点 |
| 102 | Tailnet UDP timer active/enabled；R4 代理 timer disabled | 102 提供同一套 Tailnet 的第二观测点，不运行 R4 自动代理探测 | Tailnet 网络观测点 |
| RR | 网络拓扑、Globalping 网络采集、DERP 资格、DERP 控制、Edge Endpoint、节点清单、Home Bridge 等；R4 计划器和代理告警 timer disabled | RR 承担集中采集、网络控制和告警入口，不是节点 UDP 的观测点 | 集中网络探针 + 控制探针 |
当前状态的精确口径是：101、102 的 Tailnet 探针是现行网络路径数据源；RR 的 Globalping、网络拓扑和 DERP 资格是现行集中网络/控制数据源；101 的 Memory、Android、备份、Runner、OmniRoute 等服务于各自业务；R4 代理探测及计划器属于已停用退役对象。P22-2 的统一探针目录必须增加“网络观测点、集中采集、控制探针、业务探针、退役探针”分类，避免把不同业务混成一个健康总数。
此次回读同时确认了两个不同的治理事项。RR 上 agentmeshos-probe-plan.timer 和 agentmeshos-proxy-udp-alert.timer 仍是已安装 unit，但均 disabled/inactive，属于可以按 P22-4 退役删除的 R4 运行对象。101 上 agentmeshos-memory-probe.timer 则是 enabled/active，最近触发正常；其现场来源是 /etc/systemd/system/agentmeshos-memory-probe.service，执行 /usr/local/lib/agentmeshos/memory_probe.py，使用独立的 memory-probe.env，属于外部 Memory Server 业务探针，不是网络探针。它在仓库 deploy/systemd/ 和本轮限定部署脚本检索中没有找到对应正式来源，因此应标为“运行中、来源待确认”，在查清业务归属和部署责任前不得删除。该区别说明“停用就退役删除”不等于“仓库没找到就删除”。
🧩 仓库定义、部署生成与页面投影核对（2026-11-03）
本轮继续只读核对仓库正式定义，重点区分“静态提交在仓库里的 systemd 文件”“部署脚本运行时生成的 systemd 文件”“当前页面读取的快照”和“告警出口”。结果说明：探针运行对象并不由一个目录统一管理，P22-0 不能只依赖 deploy/systemd/ 或 agentmeshos-probe-stale-check.py 得出完整清单。
| 核对对象 | 本轮证据 | 冻结结论 | 后续影响 |
|---|---|---|---|
| 静态 systemd 目录 | deploy/systemd/ 当前有 20 个 timer 文件 |
这些是仓库提交的部分运行定义，不包含全部网络探针 | 目录清单不能直接当作全项目探针注册表 |
| 网络 Globalping 与 DERP 资格 | scripts/deploy/network-probe/agentmeshos-network-probe-deploy.sh 动态生成采集 timer 和 DERP 资格 timer；分别为 10 分钟和 15 分钟节奏 |
关键网络探针的运行定义由部署脚本生成 | 必须把“生成源”和“现场单元”作为同一对象登记 |
| Tailnet UDP | scripts/deploy/tailnet-udp-probe/agentmeshos-tailnet-udp-probe-deploy.sh 按 101/102 生成两个独立 timer，默认 5 分钟 |
101/102 是同一套 Tailnet 中的两个现行观测点 | 探针目录必须记录观测点、快照和发布目标，而不是把它描述成两套节点网络 |
| R4 代理 UDP | scripts/deploy/probe-plan/agentmeshos-probe-plan-deploy.sh 生成计划器和告警评估器；README 明确其为过渡组件 |
代码和部署入口仍存在，但业务定位已降为人工/历史诊断 | 运行态、页面引用和历史快照必须分开 |
| 陈旧检查器 | scripts/maintenance/agentmeshos-probe-stale-check.py 只登记 7 个 ProbeUnit，且包含仓库静态目录中未出现的 memory-probe-101.timer；101 本机该 timer 为 enabled/active |
陈旧检查器不是统一探针目录，且存在运行对象与仓库来源不一致 | 当前检查结果不能代表全项目探针完整性；Memory 探针需单独确认来源和业务归属 |
| 网络拓扑采集 | scripts/deploy/api-gateway/agentmeshos-api-gateway-deploy.sh 动态生成每分钟运行的 agentmeshos-network-topology.service，带 --alert |
拓扑页面与 network-topology 告警共享一个采集器，但告警只针对冷连接金丝雀翻转 |
节点级网络状态不能自动等同于逐节点告警 |
| 告警页面与 AI Boss | Console 分别读取 /api/alerts?scope=all 和 /__agentmeshos/boss/v1；点击处理时才创建 AI Boss Incident |
两个模块当前仍是两个数据入口，关联发生在人工操作路径 | P22-3 必须把“未关联”作为正式页面状态 |
本轮还发现一个需要在 P22-4 冻结的代码级冲突：tools/api-gateway/src/network_topology.py 的 public_china_reachability() 会先读取同一套 Tailnet 网络中 101、102 两个观测点的快照；当 Tailnet 投影不是明确的 healthy 或 down 时，effective_udp_status 会回退到 proxy_status。而仓库 README 已将 R4 代理探针定义为“仅保留人工诊断”，P21 和本轮生产回读也已确认其 timer 停用、旧快照可能残留。由此得到的严格结论是：当前代码存在过渡探针回退路径。 本轮尚未据此断言生产页面当前已经被旧快照污染。
🗑️ 停用探针退役与删除清单
本轮生产只读回读已确认以下运行对象属于停用或过渡状态。按照本轮确认的规则，停用探针按正式退役删除处理：必须从生产运行路径、页面引用、API 当前状态读取和自动告警入口中清理；历史告警、历史快照和必要的审计证据另行归档，不得继续作为当前状态输入。本轮仍不直接删除，因为 P22 目前处于事实盘点阶段，删除动作要在映射、备份和回退点齐全后执行。
| 对象 | 已验证状态 | 当前是否仍参与现行网络主口径 | 正式处理 |
|---|---|---|---|
| 101 R4 代理 UDP timer | inactive、disabled；service 为 loaded inactive static |
否，Tailnet 路径探针已承担节点 UDP 主口径 | 退役删除生产 timer/service、旧状态和页面兼容引用；历史证据迁移后清理运行副本 |
| 102 R4 代理 UDP timer | inactive、disabled |
否 | 与 101 同步退役删除，不能只停一台 |
| RR R4 计划器 timer | loaded inactive、disabled |
否 | 退役删除计划器运行单元、计划状态和告警评估运行入口 |
| RR R4 代理告警 timer | loaded inactive、disabled |
否 | 退役删除自动告警评估入口，历史告警保留为历史记录 |
| R4 代理快照 | 代码和 API 仍读取 proxy-udp-v1.json、proxy-udp-102-v1.json |
不应参与当前节点 UDP 判定 | 先移除当前状态读取和回退，再归档并删除运行副本；人工诊断是否保留另行确认 |
101 memory-probe.timer |
本机 enabled/active；service 执行 /usr/local/lib/agentmeshos/memory_probe.py，使用独立环境文件；仓库 deploy/systemd/ 未发现对应正式单元 |
外部 Memory Server 业务探针，不属于网络主口径 | 不得直接删除；先确认其正式部署来源、业务用途和告警关系 |
| d02、MM、DD、dog 本机网络探针 | 本轮限定回读未发现 AgentMeshOS 网络探针 timer | 否；由 RR、101、102 集中观测 | 不新增同类本机探针，避免重复探测和额度浪费 |
因此，本轮冻结三条规则：第一，停用探针不得继续作为当前页面的隐式回退数据源；第二，停用运行对象必须退役删除，历史告警和必要审计证据单独归档；第三，删除动作必须先完成页面引用、API 读取、告警出口和历史证据的反向检索，并提供回退点。
该冲突的正确处理顺序是：先在 P22-0 目录中记录 R4 的停用状态和所有仍被读取的路径，再由 P22-4 决定“Tailnet 主口径不可用时显示未验证/不可用”还是保留经过明确标记的兼容回退；在决定前不得用删除旧快照或硬编码绿色状态掩盖问题。
🔔 告警接口代表性回读（2026-11-03 03:51 CST）
本轮通过 RR 本机 API Gateway 的只读接口读取告警元数据，没有调用写接口、恢复接口或 AI Boss 处理入口。接口当前返回的计数为：总量 832、completed 832、未读 809，pending/processing/needs_benson_decision/failed 均为 0。最近返回的 100 条记录中，98 条来自发布控制器，2 条来自 101 探针；其中一条 101 探针异常样本为 runtime-probe / DEGRADED / critical / completed，没有 incident_id。这与上一批数据库聚合的 827 条不同，说明告警数量会随发布和探针事件继续增长，页面必须显示读取时间和统计口径。
这次代表性回读把“告警显示已完成但 AI Boss 没有处理”的机制证据进一步锁定为三层：告警事件已经被来源组件投递；恢复关联或其他自动收尾逻辑把 handling_status 变成 completed；AI Boss Incident 是否存在则由独立的 incident_id 决定。当前样本中，探针告警的 incident_id 为空，不能把它解释为 AI Boss 已接收、已分析或已完成。P22-2/P22-3 必须将“来源恢复”“系统自动收尾”“AI Boss 接收/处置”“管理员已验证关闭”拆成独立字段和页面状态。
📌 告警语义决策记录（2026-11-03）
本轮已经确认两条必须写入系统契约的业务规则。第一，探针确认目标恢复后，可以自动结束“活动故障”并显示“已恢复”；这表示故障观测已经消失，不表示有人执行过修复，也不表示 AI Boss 完成了处置。第二，“已处理”只允许表示 AI Boss 已经接收并完成了有证据的处置流程；来源恢复、系统自动收尾、人工查看和管理员验证关闭不得继续共用这个词。依据是告警接口回读中存在大量 completed、未读记录和空 incident_id 的探针样本，且用户已明确确认上述状态边界。影响是 P22-2/P22-3 必须以独立字段、状态和页面筛选实现，旧数据不能直接删除或批量改写为 AI Boss 已处理。
| 用户可见状态 | 触发者 | 能证明什么 | 不能证明什么 |
|---|---|---|---|
| 活动故障 | 探针提交故障事件且尚未收到真实恢复 | 当前仍有故障观测 | 不能证明 AI Boss 已接收或已执行动作 |
| 已恢复 | 同一组件上下文收到有效恢复观测 | 来源探针确认故障现象消失 | 不能证明谁修复、不能证明 AI Boss 处理完成 |
| AI Boss 已接收 | AI Boss 创建并关联有效 Incident | AI Boss 已接收该告警 | 不能证明动作已完成或结果已验证 |
| AI Boss 处理中 | AI Boss/Runtime 有正在运行的处理事件 | 当前存在处置过程 | 不能证明系统已经恢复 |
| 等待人工 | 规则要求 Benson 决策或外部操作 | 系统明确停在人工门禁 | 不能显示为已处理或已关闭 |
| 已验证关闭 | 有独立验证人、验证时间和验证证据 | 人工或受控流程确认事件可以关闭 | 不能反推 AI Boss 一定参与 |
| 历史未读 | 记录尚未被查看，但事件已结束或归档 | 阅读状态 | 不能反推仍有活动故障 |
后续实现必须保留至少四条可独立追踪的关系：source_event（来源事件）、recovery_event（恢复证据）、incident_id（AI Boss 事件）和 closure_evidence（关闭验证证据）。如果其中任一关系不存在，页面必须如实显示“未关联”“未接收”或“未验证”，不得根据 completed 单字段补全。
🧱 P22-1 详细规格：模块与职责域重构
📌 工作包结论
P22-1 要把 P22-0 的事实转换为“谁负责什么、谁可以读什么、谁可以写什么、谁不能替代谁”的职责模型。它不是立即移动代码或拆服务，而是先冻结系统边界和跨域接口。依据是现行总体架构已经把 AI Boss、Runtime、Nomad、API Gateway、Console、Network、Storage 和 OmniRoute 分层，但当前计划仍缺少面向 Console 和告警闭环的完整职责矩阵。影响是没有 P22-1 的矩阵，P22-2、P22-3 和 P22-5 会继续围绕页面或事件局部打补丁。
🗺️ 目标职责域
| 职责域 | 负责什么 | 权威事实 | 可以暴露给谁 | 明确禁止 |
|---|---|---|---|---|
| Network | Tailnet、节点网络、路径、Edge、DERP、Peer Relay 和网络探针边界 | 网络状态快照与网络配置 | Network 页面、相关告警和诊断 | 代替业务平台状态或代理业务状态 |
| Agent 与节点 | Agent、节点、任务运行、节点能力和节点生命周期 | Agent Registry、节点清单和运行事实 | Agent 页面、工作台 | 代替网络路径判断 |
| Runtime | Plan、Task、状态、预算、证据、验收和受控 Adapter | Runtime SQLite 与结构化事件 | AI Boss、Console、审计 | 代替 AI Boss 做语义决策 |
| AI Boss | 目标理解、规划、派工建议、审核、返工和汇总 | AI Boss 事件与审核记录 | AI Boss 页面、告警处置记录 | 把模型文本当系统动作或凭空宣称已处理 |
| Alert | 告警发现、通知、恢复、处置、关闭和审计投影 | 告警事件及其组件上下文 | 告警与处置页面、工作台摘要 | 自行执行未登记动作或把恢复当处置完成 |
| Platform | OA、AI 平台、存储与文件、搜索与外部服务 | 各平台正式健康和业务接口 | 平台服务页面 | 混入 Agent 状态或网络状态 |
| Console | 导航、页面投影、交互和人类可读呈现 | API Gateway/Runtime 只读投影 | Benson | 保存权威状态、复制状态机或直接访问底层凭据 |
| Storage | Runtime 数据、Cloudreve 系统云盘和证据存储边界 | SQLite、WebDAV 和证据引用 | Runtime、成果和审计页面 | 由 Worker、Console 或网络节点绕过正式数据面 |
🔐 跨域契约
P22-1 必须为每个跨域关系写出“调用方向、数据类型、写入权、失败行为、证据和回退”。最低契约如下：
| 关系 | 允许方向 | 数据 | 失败时的正确表现 |
|---|---|---|---|
| 探针 → 告警 | 探针事件进入告警适配器 | 脱敏观测、组件上下文、去重键、时间 | 记录投递失败，不伪造告警已处理 |
| 探针 → 业务页面 | 探针结果投影到所属业务页面 | 业务结果、数据年龄、证据引用 | 页面显示未更新/过期，不另起一套探测 |
| 告警 → AI Boss | 告警按明确动作交给 AI Boss | 告警引用、上下文、处理权限、预算 | 显示未接收、等待人工或失败，不自动标记完成 |
| AI Boss → Runtime | AI Boss 提交结构化计划或固定动作 | Plan、Action、审核和证据引用 | Runtime 拒绝越权或不完整契约 |
| Runtime → Console | Console 读取只读聚合 | 状态、结果、时间、证据、下一步 | 显示真实错误和来源，不使用旧缓存冒充新结果 |
| Console → Runtime | 只调用已登记、幂等的交互 | 确认、重审、返工、受控动作 | 返回可读结果和审计引用，不直接写底层数据库 |
任何跨域契约都必须区分“事件已产生”“事件已接收”“动作已执行”“结果已验证”四个层次。只有真实验证完成，才允许页面显示“已处理”“已关闭”或“已完成”。
📊 P22-1 产物与验收
| 产物 | 内容 | 通过标准 |
|---|---|---|
| 职责域矩阵 | 领域、责任、权威源、读写边界、失败行为和禁止事项 | 每个现有模块只有一个主职责 |
| 跨域数据流图 | 探针、告警、AI Boss、Runtime、Gateway、Console 的方向和状态 | 不出现循环写入或隐式第二权威源 |
| 页面—职责映射 | 每个页面所属职责域、数据来源、操作边界和导航归属 | 页面不因历史名称放错一级菜单 |
| 冲突决策表 | 现行架构与运行态冲突的取舍依据 | 未决项明确保留，不用猜测关闭 |
| 负向规则清单 | 越权、重复探测、重复状态源、伪造恢复和错误归类案例 | 后续实施可以逐项写成回归测试 |
P22-1 只有在上述产物通过评审后才算“详细设计完成”；代码、部署和生产变更不属于本工作包的完成证据。
🧪 P22-1 评审工作步骤
- 以 P22-0 的事实清单为输入，逐项确认每个模块的业务目的、权威状态源和读写边界。
- 对同一事实存在多个来源的情况，建立“主来源、投影来源、历史来源”三层关系，不以页面当前显示结果直接决定权威性。
- 对 Network、Agent、Runtime、AI Boss、Alert、Platform、Console、Storage 八个职责域分别列出允许写入的对象和禁止代替的对象。
- 对告警恢复、AI Boss 处理、人工关闭和历史归档分别绘制事件方向，确认任何自动收尾都不会伪装成 AI Boss 动作。
- 将每条跨域关系转换为一个可测试的失败行为：超时、重复投递、无关联 ID、过期快照、权限不足和验证缺失都必须有明确页面结果。
P22-1 的评审出口不是“大家同意大致方向”，而是形成一份可以直接约束 P22-2、P22-3、P22-4 和 P22-5 的职责矩阵版本。若仍有一个模块既写权威状态又写页面投影，或一个状态由多个模块无条件关闭，P22-1 不得通过。
🧾 P22-1 当前评审输入矩阵
下表把已确认事实转换为评审问题。已冻结表示本轮证据足以作为设计约束；待决表示必须在职责评审中明确，不能由实现阶段自行猜测。
| 职责域 | 当前主责任 | 当前权威来源 | 已冻结边界 | 待决问题 |
|---|---|---|---|---|
| Network | Tailnet 路径、Globalping、DERP、Edge 和节点网络状态 | Tailnet 快照、Globalping 快照、拓扑快照、DERP 资格快照 | 不负责 OA、AI 平台或代理业务健康；停用 R4 不得回灌网络主状态 | DERP 资格异常是否单独进入告警中心 |
| Agent 与节点 | 节点身份、角色、能力和任务运行 | 节点登记、Agent Registry、Runtime/Nomad | 不根据网络路径替代节点生命周期状态 | 节点离线和网络不可达如何在工作台合并展示 |
| Runtime | 计划、任务、预算、证据、受控动作 | Runtime 事件和任务状态 | 不把探针恢复或模型文本当作已完成动作 | 哪些告警动作可以进入固定 Handler |
| AI Boss | 分析、决策、派工建议、审核和汇总 | AI Boss Incident、处理事件、审核记录 | 不自动冒充恢复、验证关闭或执行成功 | 告警进入 AI Boss 的默认条件和人工门禁 |
| Alert | 发现、通知、恢复、处置状态和审计投影 | Alert Store、来源事件、恢复事件 | “已恢复”不等于“AI Boss 已处理” | 旧 completed 数据如何在兼容层显示 |
| Platform | OA、AI、存储、搜索和外部服务 | 各平台业务健康接口 | 不归入 Agent 状态或网络状态 | 平台级故障是否需要工作台摘要 |
| Console | 导航、只读投影、人类可读交互 | API Gateway/Runtime 聚合 | 不保存第二份权威状态，不重复发起探测 | 哪些页面允许受控写操作 |
| Storage | 告警、Runtime、证据和历史归档存储 | SQLite、证据目录、WebDAV 边界 | 不因展示方便删除历史审计 | R4 历史证据的正式归档位置 |
✅ P22-1 通过条件
P22-1 评审必须逐项回答以下问题后才能通过：每个状态只有一个写入权威；每个页面只有一个主职责归属；每个告警状态都能区分来源恢复、AI Boss 处理和人工验证；任何跨域失败都有页面可见结果；停用探针没有继续写入或被当前状态读取；Console 不通过第二次探测补齐数据。任一问题没有明确答案，状态保持“待评审”，不得进入代码实施。
🧪 P22-2 详细规格：探针业务与告警闭环
📌 工作包结论
P22-2 负责回答“每个探针为什么存在、服务哪个业务、是否进入告警、谁负责恢复、页面在哪里展示”。它不是把所有探针强行接入告警中心，而是把现有探针按业务目的重新登记，明确“只服务自身业务”和“同时进入告警”的合法差异。依据是 P22-0 已确认网络 Tailnet 探针、Globalping 采集器、代理 UDP 过渡探针和 101 本机业务探针并不共享同一条告警出口。影响是没有 P22-2，告警中心无法解释为什么某些探针有快照却没有告警，也无法解释某些历史告警对应的探针是否还在运行。
🧭 探针分类与最小注册字段
| 探针类别 | 主要目的 | 是否必须进入告警 | 页面归属 | 关闭依据 |
|---|---|---|---|---|
| 网络可达性探针 | 观察主机、入口和节点间网络路径 | 仅在定义了用户影响和告警阈值时进入 | 网络态势 | 对应来源恢复观测或人工验证 |
| 控制探针 | 维护 DERP 资格、Edge 切换或网络控制状态 | 进入控制域告警，不等于普通节点故障 | 网络态势/系统维护 | 控制状态恢复并完成资格复核 |
| 业务健康探针 | 观察 OA、存储、搜索、代理等业务 | 按业务影响进入告警 | 平台服务或对应业务页 | 业务探针的真实恢复证据 |
| 调度陈旧探针 | 判断 timer/service 是否按期运行 | 进入运行检查和告警 | 系统维护 | 调度恢复且下一轮业务结果成功 |
| 仅业务观察 | 记录指标、日志或证据，不承担故障通知 | 默认不进入告警 | 所属业务详情 | 由业务页面保留观察记录 |
| 已停用/历史探针 | 兼容旧快照和历史审计 | 不得生成新告警 | 系统证据/历史告警 | 明确标记退役，不参与当前状态 |
每个正式探针必须登记：人类可读名称、唯一标识、业务目的、责任域、运行节点、调度方式、输入、输出、当前状态、是否进入告警、告警组件上下文、恢复事件格式、页面归属、数据保留期、停用方式和证据路径。登记缺失时，探针只能被标记为“未纳管”，不能自动计入健康总数。
📋 P22-2 首版探针目录样表
下表是基于本轮仓库与生产只读回读形成的首版目录，不是最终注册表。最终注册表必须在 P22-0 完成全量对齐后冻结。
| 人类可读名称 | 当前类别 | 运行位置 | 当前状态 | 当前页面/告警关系 | 目录处理 |
|---|---|---|---|---|---|
| Tailnet 节点路径观测（101） | 网络观测点 | 101 | active/enabled | 网络态势数据源；未证明逐节点直接告警 | 正式纳管 |
| Tailnet 节点路径观测（102） | 网络观测点 | 102 | active/enabled | 网络态势数据源；未证明逐节点直接告警 | 正式纳管 |
| 中国方向主机与公网入口观测 | 集中网络采集 | RR | active/enabled | 网络可达性、额度和 Edge 依据 | 正式纳管 |
| DERP 资格观测 | 控制探针 | RR | active/enabled | 维护 DERP 资格；是否独立告警待决 | 正式纳管，告警关系待评审 |
| 网络拓扑与冷连接检查 | 集中网络采集/控制 | RR | active/enabled | 实时分布图；冷连接状态变化进入网络告警 | 正式纳管 |
| R4 代理 UDP 探针 | 退役探针 | 101、102 | inactive/disabled | 不得进入当前节点 UDP 状态 | 退役删除，历史归档 |
| R4 计划器与代理告警评估 | 退役控制探针 | RR | inactive/disabled | 不得生成新计划或新告警 | 退役删除，历史归档 |
| Memory Server 业务探针 | 业务健康探针 | 101 | active/enabled，来源待确认 | 服务 Memory Server 业务，不属于网络态势 | 正式来源待追溯后纳管 |
| OmniRoute 健康观察 | 业务观察 | 101 | timer 运行，曾有业务失败 | 服务 OmniRoute 迁移后健康观察 | 纳入业务探针，区分调度与业务结果 |
| 探针陈旧检查 | 调度陈旧探针 | 101 | active/enabled | 统一发送运行态告警，但当前只覆盖部分对象 | 扩展为目录驱动 |
| Edge DNS 控制器 | 控制探针 | 101 | active/enabled | Edge 切换和恢复事件 | 正式纳管 |
| 备份、Android、Runner、日志等业务检查 | 业务健康探针 | 101 | 多项 active/enabled | 各自业务告警，不属于网络 UDP | 按业务拆分登记 |
目录冻结前必须补齐每项的 producer、context_id、恢复方式、是否需要 AI Boss、页面主归属和历史保留策略。没有这些字段的对象只能显示“未纳管”，不能进入“系统健康总数”。
🔗 探针到告警的闭环规则
| 环节 | 必须记录 | 通过条件 | 失败时页面显示 |
|---|---|---|---|
| 探针执行 | 调度时间、执行结果、目标、错误类别 | 能区分未运行、执行失败、业务失败 | 未运行/执行失败/业务失败 |
| 告警投递 | 事件 ID、去重键、组件上下文、投递结果 | 事件能回指原始观测 | 告警未投递或关联缺失 |
| 故障保持 | 活动事件和最近观测 | 重复故障不会生成无限重复告警 | 当前活动故障与最近观测 |
| 恢复发现 | 恢复事件、来源、时间、验证内容 | 只关闭同一组件上下文的活动故障 | 已恢复，显示恢复来源 |
| 处置关联 | AI Boss Incident 或人工操作引用 | 告警和处置能双向回查 | 未接收/等待人工 |
| 关闭验证 | 验证人、时间、证据和回退 | 关闭不是由单一 completed 字段推断 |
未验证关闭 |
P22-2 必须产出一份“探针—业务—告警目录”和一份“已停用/历史探针清理映射”。前者供 Console 和告警中心读取，后者用于防止旧快照、旧状态文件和历史告警继续被误认为当前运行态。不得通过删除历史记录来解决重复或混乱。
✅ P22-2 验收标准
| 验收项 | 必须证明 | 证据 |
|---|---|---|
| 目录完整 | 现行、仅业务、已停用和未纳管探针均有记录 | 注册目录、timer/service 回读、部署清单 |
| 业务目的明确 | 每个探针都有业务目的和责任域 | 目录字段与所属页面 |
| 告警关系真实 | 每个告警来源能回指探针或明确为系统事件 | 事件样本、组件上下文和去重键 |
| 恢复不冒充处置 | 恢复事件只改变恢复状态，不生成 AI Boss 完成记录 | 负向回归和审计记录 |
| 旧数据隔离 | 停用探针不再产生新告警，历史数据仍可查询 | 停用标记、历史查询和新事件窗口 |
| 页面可解释 | 用户能看懂探针是否运行、是否告警、最后更新时间 | Console 页面与过期状态证据 |
🔔 P22-3 详细规格：告警与 AI Boss 联动模型
📌 工作包结论
P22-3 负责把告警中心和 AI Boss 变成两个有明确边界、可以互相引用的模块。告警中心是错误和恢复事件的统一输出渠道；AI Boss 是可选的分析、决策和受控处置渠道；两者不能因为同一条记录存在就互相冒充。依据是当前告警接口已经出现 completed 但 incident_id 为空的探针样本。影响是 P22-3 必须在数据模型、页面文案、自动收尾和审计中同时分离“恢复”和“处理”。
🔄 状态机与允许转换
| 当前状态 | 触发事件 | 允许的下一状态 | 禁止的隐式转换 |
|---|---|---|---|
| 活动故障 | 有效恢复观测 | 已恢复 | 不得直接变成 AI Boss 已处理 |
| 活动故障 | AI Boss 接收 | AI Boss 已接收/处理中 | 不得因创建 Incident 就显示已处理 |
| AI Boss 处理中 | 动作执行成功 | 待验证或已恢复 | 不得把动作返回成功当成业务恢复 |
| AI Boss 处理中 | 需要 Benson 决定 | 等待人工 | 不得自动跳过人工门禁 |
| 已恢复 | 独立验证通过 | 已验证关闭 | 不得只因恢复事件自动变成已验证关闭 |
| 任意活动状态 | 外部投递失败 | 保持原状态并记录失败 | 不得静默标记 completed |
| 历史记录 | 用户查看 | 历史已读 | 不得改变故障处置状态 |
🧾 AI Boss 处理记录的最低字段
AI Boss 关联记录必须至少包含告警引用、接收时间、处理目标、上下文快照、决策或动作类型、执行结果、证据引用、是否需要人工、完成时间和失败/回退信息。incident_id 为空时，页面必须明确显示“AI Boss 未接收”；只有存在有效处理事件、结果证据和适用的验证条件时，才可以显示“AI Boss 已处理”。
🖥️ 页面与人类可读表达
| 页面区域 | 必须显示 | 不得显示 |
|---|---|---|
| 当前告警 | 当前故障、影响范围、最近观测和恢复状态 | 把历史未读当成当前故障 |
| 历史告警 | 已恢复、已验证关闭、历史未读和来源 | 把所有 completed 统一翻译为已处理 |
| AI Boss 处理记录 | 是否接收、处理阶段、动作、结果和证据 | 只显示一个完成数量 |
| 恢复与审计 | 谁报告恢复、何时恢复、是否验证关闭 | 把自动恢复写成 AI Boss 动作 |
| 工作台摘要 | 当前需关注事项和待人工事项 | 用未读数量代替活动故障数量 |
✅ P22-3 验收标准
| 验收项 | 必须证明 | 证据 |
|---|---|---|
| 自动恢复 | 探针恢复后活动故障变为已恢复 | 恢复事件、关联键和状态回读 |
| AI Boss 分离 | 无 incident_id 的告警不会显示 AI Boss 已处理 |
负向样本和页面截图 |
| 人工门禁 | 需要 Benson 决策的事件停在等待人工 | Runtime 事件和页面状态 |
| 关闭可验证 | 已验证关闭有独立验证证据 | 验证记录、时间和操作者 |
| 历史可读 | 历史未读不污染当前告警 | 筛选、计数和页面状态 |
| 投递失败可见 | 告警或 AI Boss 入口失败不会静默完成 | 错误日志、失败状态和重试记录 |
P22-3 的实施前置是先完成 P22-2 探针目录和事件关系，不允许先改页面文案再猜告警来源。现有历史数据按兼容层读取，不能在没有迁移映射和回退方案的情况下批量重写。
🧊 P22-4 详细规格：权威数据与状态源统一
📌 工作包结论
P22-4 负责冻结每个页面的唯一权威数据源、更新时间、过期规则和禁止回退路径，并清理已经停用的 R4 代理探针对当前网络状态的影响。依据是本轮反向引用核对发现：R4 快照仍被 API Gateway、API Gateway 部署环境、即时刷新 Worker、旧计划器、旧告警评估器和测试契约引用；仅停用 timer 不能阻止旧快照继续被读取。影响是 P22-4 必须先切断当前状态读取，再执行运行对象退役，最后清理代码、测试和历史副本。
🗂️ 当前数据源与目标数据源
| 页面或功能 | 当前主数据 | 当前风险 | 目标权威数据 |
|---|---|---|---|
| 网络可达性主机/IP | Globalping 主机快照 | 采集周期、入口时间和主机时间容易混淆 | Globalping 主机快照，主机时间与入口时间分开显示 |
| 网络可达性节点 UDP | Tailnet 101、102 两个观测点快照 | Tailnet 不明确时可能回退到 R4 代理快照 | 仅使用 Tailnet 路径快照；无有效结果显示未验证 |
| 节点路径视图 | 网络拓扑 + Tailnet 路径快照 | 页面可能把过渡代理字段当作节点 UDP | 只读取节点路径字段和观测点明细 |
| 即时刷新 | node_udp 与旧 proxy 两类刷新入口 |
用户仍可请求已退役的 proxy 类型 |
保留主机、入口和 node_udp；删除 proxy 自动刷新入口 |
| DERP 资格 | 独立公网 TCP 443 资格快照 | 不应受 Tailnet 或 R4 代理结果影响 | 继续使用 DERP 资格专用快照 |
| 历史 R4 诊断 | 旧代理快照和旧告警 | 历史数据可能污染当前状态 | 仅归档查询，不进入当前状态聚合 |
🔍 已确认的 R4 反向引用
| 引用位置 | 当前用途 | 退役动作 |
|---|---|---|
tools/api-gateway/src/network_topology.py |
读取两份 R4 快照，并在 Tailnet 状态不明确时回退 | 删除当前状态回退和代理投影字段 |
scripts/deploy/api-gateway/agentmeshos-api-gateway-deploy.sh |
向 API Gateway 容器注入 R4 快照路径 | 删除 R4 环境变量和对应挂载/目录声明 |
tools/reachability-refresh/src/worker.py |
接受 proxy 刷新请求并远程执行 R4 探针 |
删除 proxy 类型、命令和结果路径 |
scripts/deploy/reachability-refresh/agentmeshos-reachability-refresh-deploy.sh |
部署 R4 快照路径 | 删除 R4 运行目录配置 |
tools/probe-plan/src/planner.py、alert_eval.py |
读取旧快照，生成计划或告警 | 退役运行入口；代码和测试迁移后删除 |
scripts/deploy/probe-plan/agentmeshos-probe-plan-deploy.sh |
生成旧计划器和告警 timer | 删除部署入口及其卸载兼容分支 |
tools/console-site/src/app.js |
保留 proxy 刷新状态和代理状态兼容显示 |
删除代理刷新按钮和当前页面兼容字段 |
| 相关测试与 README | 验证 R4 运行链路 | 转为历史归档测试或删除，不得继续作为当前生产门禁 |
🔁 退役删除批次
- 批次一：切断当前状态影响。 API Gateway 只保留 Tailnet 节点 UDP 投影；Tailnet 快照缺失、过期或格式错误时显示“未验证/数据不可用”，禁止回退到 R4。即时刷新只保留主机、入口和
node_udp。 - 批次二：运行对象退役。 在 101、102、RR 上删除 R4 timer、计划器 timer、告警 timer、旧服务单元、计划状态和运行目录；回读确认没有新的 R4 快照或 R4 告警事件产生。
- 批次三：部署与代码清理。 删除 API Gateway 的 R4 环境注入、Worker 的
proxy分支、旧部署入口和当前页面代理字段；保留必要的历史读取器时必须明确标记为归档，不得被当前 API 调用。 - 批次四：历史归档和负向回归。 保存 R4 旧快照、旧告警和必要测试证据到正式历史位置；构造“Tailnet 快照缺失但 R4 旧快照存在”的负向场景，确认页面仍显示未验证，不显示代理结果或默认绿色。
✅ P22-4 验收标准
| 验收项 | 必须证明 | 证据 |
|---|---|---|
| 唯一数据源 | 节点 UDP 当前状态只来自 Tailnet 观测点 | API 回读、字段映射和代码测试 |
| 无隐式回退 | Tailnet 缺失时不会读取 R4 旧快照 | 负向夹具和页面结果 |
| 刷新边界 | 页面不能再提交已退役的 proxy 刷新请求 |
浏览器契约和 API 负向回归 |
| 运行对象清理 | 101、102、RR 没有 R4 自动 timer 或告警 timer | systemd 只读回读 |
| 状态文件隔离 | 旧 R4 文件不再进入当前运行目录 | 目录、挂载和容器环境回读 |
| 额度不增加 | 节点路径视图和双节点诊断不新增 Globalping 调用 | 调用链审计和额度台账 |
| 历史可追溯 | 旧 R4 告警和诊断证据仍可查询，但标记为历史 | 归档索引和页面筛选 |
P22-4 不允许通过直接删除快照来“修绿”页面；必须先移除读取关系，再归档和删除运行副本。任何一批删除前都必须保存 last-known-good、执行记录和回退步骤。
🧪 P22 核心实现回归记录（2026-11-03）
本轮已在仓库落地 P22 核心行为并完成本地回归。网络聚合不再把停用 R4 代理快照作为 Tailnet 结果缺失时的当前状态回退；手动刷新仅保留主机、入口和 Tailnet 节点路径，不再接受 proxy 类型；告警恢复新增独立 recovery_status，恢复事件不会再自动伪装成 AI Boss completed；Console 导航改为一级职责域分组、可折叠/展开、当前路径自动展开。
| 实现面 | 本地证据 | 当前状态 |
|---|---|---|
| API Gateway 网络聚合 | tools/api-gateway/tests/test_network_topology.py |
PASS；R4 缺失时保持未验证，不回退决定节点状态 |
| 告警状态机 | tools/api-gateway/tests/test_alerts.py |
PASS；恢复状态与 AI Boss 处置状态分离 |
| 手动刷新边界 | tools/api-gateway/tests/test_reachability_refresh.py、tools/reachability-refresh/tests/test_worker.py |
PASS；R4 proxy 刷新被移除 |
| 部署契约 | API Gateway、Reachability Refresh 部署契约 | PASS |
| Console 导航与页面 | tools/console-site/tests/browser-contract.sh、网络拓扑浏览器契约 |
PASS；桌面/移动端和折叠交互通过 |
| 完整本地测试 | scripts/ci/run-local-tests.sh |
主体测试通过；现有节点指标不可达输出和 MkDocs 非阻断链接警告仍需在部署后区分处理 |
这条记录只证明仓库实现和本地契约已通过，不代表生产服务已经部署。生产部署、R4 现场运行对象退役、Memory 探针来源追溯和最终生产 API/页面回读仍是 P22-8 收口证据。
🧭 P22-5 详细规格：Console 导航与页面归属
📌 工作包结论
P22-5 的目标不是把菜单换个名字，而是让用户能够从导航层级直接理解“这是哪个系统领域、当前在哪个功能组、页面显示什么事实、下一步能做什么”。依据是当前 Console 已有分级菜单，但一级、二级和页面入口视觉差异不足，同时告警中心、OA、AI 平台等职责域被错误地放入 Agent 状态。影响是导航必须先按 P22-1 的职责矩阵归属，再设计折叠展开；不能先画 UI 再反推系统边界。
🗂️ 目标导航树与页面归属
| 一级方向 | 二级功能组 | 页面/入口 | 页面主问题 | 权威来源 |
|---|---|---|---|---|
| 工作台 | 当前问题 | 当前异常、影响范围、下一步 | 现在最需要关注什么 | Alert/Runtime 聚合 |
| 工作台 | 待处理事项 | 待处理告警、待审核、待决策 | 哪些事项需要 Benson 处理 | Alert/AI Boss/Acceptance |
| 工作台 | 系统总览 | 系统健康、阶段状态、关键变化 | 系统总体处于什么状态 | 多域只读聚合 |
| Agent 与节点 | Agent 状态 | Agent 在线、运行、版本和能力 | Agent 当前是否可用 | Agent Registry |
| Agent 与节点 | 节点管理 | 节点身份、角色、能力和生命周期 | 节点承担什么职责 | 节点清单 |
| Agent 与节点 | 任务运行 | 计划、任务、Allocation 和结果 | 任务运行到哪一步 | Runtime/Nomad |
| Agent 与节点 | 节点能力 | 能力注册、版本、可用性和限制 | 能做什么、为什么不能做 | Capability Registry |
| 网络态势 | 实时分布图 | 节点、路径、主机和业务链路 | 谁与谁通过什么路径连接 | 网络快照 |
| 网络态势 | 网络可达性 | 主机 IP、TCP、UDP、Globalping 和 Tailnet | 从不同来源能否到达 | 网络探针快照 |
| 网络态势 | 节点路径视图 | 选定节点之间的路径和原因 | 这条链路为何直连/中继/失败 | 同一套 Tailnet 的 101、102 两个观测点路径快照 |
| 网络态势 | 双节点诊断 | 起点、终点、逐层诊断和证据 | 如何一次性解释一条链路 | 诊断结果与证据 |
| 平台服务 | OA 平台 | OA 服务状态和业务入口 | OA 服务是否可用 | OA 健康接口 |
| 平台服务 | AI 平台 | AI Runtime、模型和调用概览 | AI 平台是否可用 | Runtime/OmniRoute 只读投影 |
| 平台服务 | 存储与文件 | Cloudreve、私人硬盘和文件服务 | 文件服务是否可用 | Storage 健康接口 |
| 平台服务 | 搜索与外部服务 | 搜索、Fetch 和外部依赖 | 外部能力是否可用 | Web 能力路由快照 |
| 告警与处置 | 当前告警 | 活动故障、待处理和影响 | 当前有哪些真实问题 | Alert Store |
| 告警与处置 | 历史告警 | 已恢复、已验证关闭、历史未读 | 过去发生过什么 | Alert Store/审计 |
| 告警与处置 | AI Boss 处理记录 | 接收、分析、动作、结果和证据 | AI Boss 是否真正处理过 | AI Boss 事件 |
| 告警与处置 | 恢复与审计 | 恢复来源、验证、关闭和操作历史 | 谁在什么时候做了什么 | Alert/Runtime 审计 |
| 系统维护 | 发布与部署 | 版本、Actions、发布、回滚和健康 | 当前版本是否完整发布 | CI/CD 与部署证据 |
| 系统维护 | 运行检查 | 服务、依赖、数据年龄和门禁 | 系统是否满足运行条件 | 检查器与实时回读 |
| 系统维护 | 变更记录 | 变更、影响、回退和操作者 | 最近改了什么 | Change Store |
| 系统维护 | 系统证据 | 原始证据、哈希、时间和引用 | 结论依据在哪里 | Evidence Store |
页面可以在多个工作台摘要中被引用，但只能有一个主归属。摘要页只显示摘要和跳转，不复制该页面的状态机、写入动作或第二份数据。
🧱 导航视觉与折叠行为
| 规则 | 桌面端要求 | 移动端要求 | 验收证据 |
|---|---|---|---|
| 一级菜单 | 固定显示，使用明显的视觉分组、图标和区域标题 | 抽屉中固定显示，不能与页面标题混淆 | 截图与 DOM/可访问树 |
| 二级菜单 | 稳定缩进、字号、颜色和左侧轨道，与一级明显区分 | 以组标题或折叠行显示，点击后展开 | 展开前后截图和交互记录 |
| 三级/页面入口 | 进一步缩进，使用页面级选中态，不伪装成一级功能 | 组内纵向列表，长标题可换行 | 当前路径和选中元素证据 |
| 当前路径 | 一级、二级、当前页面同时高亮，面包屑或等价路径可见 | 抽屉关闭后仍显示当前页面和所属组 | 路由切换回读 |
| 折叠组 | 显示真实展开/收起图标和状态；当前组默认展开 | 支持触摸展开、收起和返回 | 状态属性和点击结果 |
| 刷新恢复 | 刷新后按当前路由自动展开所属组，保留用户手动收起的非当前组 | 返回页面后不丢失当前组，不产生空白导航 | 刷新/返回测试 |
| 状态角标 | 角标只表示该组真实可见状态，不把历史未读伪装成活动故障 | 角标不挤压文本，不造成横向溢出 | 数据映射与移动截图 |
| 权限隐藏 | 无权限页面和空组不展示；直接访问时返回可读的无权限状态 | 抽屉不保留空标题或错误计数 | 权限负向测试 |
| 技术详情 | 原始 ID、端口、哈希和日志默认放在可展开技术详情 | 技术详情纵向展开，不覆盖主内容 | 展开/收起和折行测试 |
“折叠”只改变可见性，不改变路由、数据源或权限；“展开”不能触发探测、刷新或写操作。导航状态可以是页面局部 UI 状态，但当前页面和权限必须由路由与服务端投影决定，不能由浏览器本地缓存伪造。
🧪 P22-5 验收矩阵
| 验收类别 | 测试场景 | 必须通过的条件 |
|---|---|---|
| 结构 | 展开六个一级方向并逐组检查 | 每个页面只在一个主归属下出现，层级无跳级 |
| 路由 | 直接打开二级和三级页面 | 自动展开完整父级路径，当前页高亮正确 |
| 折叠 | 手动展开、收起当前组和非当前组 | 当前组不会被错误隐藏；收起不改变页面内容 |
| 刷新 | 在三级页面刷新、前进、后退 | 路由、当前路径、展开状态和页面数据来源一致 |
| 数据 | 从网络可达性进入节点路径视图 | 复用同一网络快照，不额外触发探测或消耗额度 |
| 状态 | 活动告警、历史未读、AI Boss 处理中分别存在 | 三者显示不同状态和入口，不互相冒充 |
| 响应式 | 桌面 1440x900、移动 390x844 |
无页面级横向滚动，文字、角标和按钮不重叠 |
| 键盘 | Tab、Enter、Space、Escape 操作导航 | 焦点可见，组可展开/收起，Escape 可关闭移动抽屉 |
| 触摸 | 移动端点击组标题、页面入口和返回 | 点击目标稳定，不误触，不触发重复请求 |
| 权限 | 隐藏一个页面权限后重新加载 | 不出现空组、错误角标或可访问但不可用的入口 |
| 负向 | 模拟过期快照、后端失败和未知状态 | 页面显示“过期/未验证/不可用”，不显示默认绿色 |
| 视觉 | 对比一级、二级、三级以及当前态 | 不依赖颜色单一差异；缩进、字号、轨道和图标至少有两种稳定区别 |
P22-5 的完成证据必须同时包括：导航树与页面归属表、桌面和移动端真实页面证据、键盘/触摸交互记录、权限负向测试、数据源映射和“无额外探测”的调用证据。仅提交截图或仅通过前端单测，都不能作为完成依据。
🔍 现状事实与根因假设
| 现象 | 当前判断 | 需要验证的根因 |
|---|---|---|
| 探针数量和业务目的不完整可见 | 已确认存在探针与告警中心脱节 | 是否存在未登记、已停用、退役但仍被引用的探针 |
| 告警可能自动变成已处理 | 已确认恢复事件和处置状态曾被混用 | 恢复事件是否被错误写成 AI Boss 处置完成 |
| AI Boss 处理记录不清晰 | 已确认 AI Boss 与告警中心是两个渠道 | 是否存在事件关联 ID、处理动作和真实验收证据 |
| Console 菜单职责混杂 | 已确认部分平台模块归类不合理 | 当前菜单是否按历史实现而不是系统职责组织 |
| 页面之间可能重复读取或重复探测 | P21 已证明统一快照可避免重复消耗 | 其他模块是否仍自行触发探测或维护第二份状态 |
| 过渡探针仍可能被兼容回退读取 | API 的网络投影在 Tailnet 结果不明确时仍可读取 R4 代理快照；P21 已将 R4 定位为停用/人工诊断 | P22-4 必须冻结回退规则，避免历史快照影响当前节点状态 |
| 文档和实际部署可能漂移 | 架构文档存在旧阶段状态和窄化的 P22 标题 | 哪些文档属于权威、哪些只是历史记录、哪些需要更正 |
这些内容在 P22-0 事实冻结阶段统一验证，不在计划建立阶段直接假设为已修复。
🧱 数据、状态与职责契约
P22 后续实现必须建立以下对象关系，具体字段在 P22-0 和 P22-1 评审后冻结：
| 对象 | 权威来源 | 必须记录 |
|---|---|---|
| 探针 | 探针注册表或正式配置 | 业务目的、负责人、运行状态、调度、输入、输出、告警出口 |
| 探针观测 | 探针运行产物 | 观测时间、来源、目标、结果、错误类别、证据引用 |
| 告警事件 | 告警数据库 | 发现事件、组件上下文、去重键、当前状态、恢复事件 |
| AI Boss 处理 | AI Boss/Runtime 事件 | 是否接收、分析、执行、等待人工、完成或失败 |
| 处理动作 | Runtime 或固定系统动作审计 | 动作 ID、目标、前置检查、结果、回滚和操作者 |
| 恢复事件 | 同一组件上下文的真实恢复观测 | 恢复时间、来源、验证结果、关联活动告警 |
| Console 投影 | API Gateway 只读聚合 | 页面来源、快照时间、过期状态和详情引用 |
状态必须至少区分：发现、已通知、AI Boss 已接收、处理中、等待人工、已恢复、已验证关闭、历史未读。其中“已恢复”只能由真实恢复观测触发，“已验证关闭”不能由恢复事件自动冒充，“AI Boss 已接收”不能冒充“AI Boss 已处理”。
🛠️ 工作包总表
| 编号 | 工作包 | 目标 | 依赖 | 计划状态 |
|---|---|---|---|---|
| P22-0 | 范围冻结与事实盘点 | 固定系统边界、权威资料和禁止事项；产出事实清单、页面归属初表、探针—告警—AI Boss 关系表和冲突清单 | P21 收口 | 已完成并归档 |
| P22-1 | 模块与职责域重构 | 建立职责域矩阵、跨域数据流、页面—职责映射和负向规则清单 | P22-0 | 已完成并归档 |
| P22-2 | 探针业务与告警闭环 | 建立探针目录，区分页面数据源、告警来源、仅业务观察和历史探针 | P22-0、P22-1 | 核心分类完成；运行时注册表和完整验收转入 P23 |
| P22-3 | 告警与 AI Boss 联动模型 | 区分发现、通知、接收、处理、恢复、验证关闭和历史未读 | P22-2 | 语义分层完成；严格不变量和验证关闭转入 P23 |
| P22-4 | 权威数据与状态源统一 | 统一快照、更新时间、证据、过期和投影规则，并切断停用 R4 对当前状态的影响 | P22-1、P22-2 | 已完成并归档；R4 运行对象已全部移除 |
| P22-5 | Console 信息架构与导航重构 | 按六个一级方向重组菜单、页面入口、层级视觉、折叠/展开交互和桌面/移动端验收 | P22-1、P22-4 | 已完成并归档 |
| P22-6 | 架构基座与文档统一 | 根据已确认职责修订架构原文和计划导航 | P22-1 至 P22-5 | 已完成并归档 |
| P22-7 | 兼容、迁移与回退设计 | 明确旧页面、旧接口、旧告警、历史对象的兼容边界 | P22-4、P22-5 | 核心边界完成；历史告警迁移转入 P23 |
| P22-8 | 分批实施与验收 | 为后续代码、部署和生产验收建立批次门 | P22-6、P22-7 | 核心发布完成；告警端到端负向回归转入 P23 |
工作包不是按编号自动执行。每个工作包开始前必须重新确认目标、证据、写入范围和回退方式。
🧪 验收与证据要求
| 验收层 | 必须证明的事实 | 证据 |
|---|---|---|
| 文档层 | P22 范围、分支和边界一致 | 计划页、历史记录、计划门禁 |
| 架构层 | 每个模块只有一个明确职责和权威状态源 | 架构矩阵、数据流图、职责表 |
| 探针层 | 每个探针有业务目的、运行状态和告警出口 | 注册表、timer/service、运行快照 |
| 告警层 | 发现、恢复、处置、关闭状态可区分 | API 返回、数据库记录、负向回归 |
| AI Boss 层 | AI Boss 是否接收和是否完成处理可以独立证明 | 调用事件、处理记录、审核结果 |
| Console 层 | 菜单归类、权限、数据来源和过期提示正确 | 浏览器契约、桌面验收、移动端验收 |
| 发布层 | 代码、文档、生产版本和远端 Action 一致 | 提交 SHA、远端 SHA、Action、生产回读 |
任何页面显示“正常”“已处理”“已恢复”时，必须能够追溯到真实证据。不能通过前端硬编码、默认绿色或旧快照制造正常状态。
P22-5 还必须增加导航专属验收：一级、二级、三级层级在桌面和移动端均可区分；折叠组显示真实展开状态；当前页面的完整路径清楚可见；切换页面不会把用户带到错误层级；键盘和触摸操作均能展开、收起和返回；页面权限隐藏菜单时不会留下空组或错误计数。
🧭 计划细化后的执行顺序（历史）
以下顺序已按门禁执行完毕，保留为复盘基线：
- P22-0 只读盘点：冻结现状事实、权威来源、页面清单和冲突项。
- P22-1 职责评审：确认 Network、Agent、Runtime、AI Boss、Alert、Platform、Console、Storage 的边界和跨域契约。
- P22-2/P22-3 业务闭环评审：依据本计划已写入的状态机、探针目录字段和用户确认语义，完成探针、告警、恢复、AI Boss 处理和关闭状态的逐项关系核对。
- P22-4 数据源冻结：确定每个页面的唯一数据源、快照复用、更新时间、过期标识、禁止重复探测规则，以及 Tailnet 主口径失效时是否允许读取 R4 过渡快照。
- P22-5 导航与页面设计：根据 P22-1 和 P22-4 的结果定稿导航树、页面归属、折叠行为和验收矩阵。
- P22-6/P22-7/P22-8：最后统一修订架构基座、兼容边界、实施批次、回退和发布验收。
每个工作包都必须经过“计划细化 → 用户确认 → 只读事实或设计验收 → 才能进入实施”的门禁。P22 已按该顺序完成并归档；最终生产证据见已完成归档。
🧪 P22-8 收口现场证据补充（2026-11-03）
101 的无线网络永久关闭和重启持久性复验已经完成。重启后的启动时间为 2026-11-03 17:58:06 CST；重启后 Wi-Fi 仍为 disabled/unmanaged，默认 IPv4 路由只保留有线接口，DNS 默认路由只保留有线接口；Tailscale BackendState=Running，101、RR、102、MM、d02、DD、dog 等主要节点恢复在线，外部 API 健康请求返回 HTTP 200。依据是 101 本机重启后的 nmcli、ip route、resolvectl、tailscale status --json 和 HTTPS 健康回读。
该复验确认“双网卡争抢默认路由/DNS”已通过机制层配置关闭，而不是继续依赖路由 metric。当前仍存在的 systemd-networkd-wait-online.service 失败、Android ADB 无设备和 OmniRoute 观察失败，分别属于未使用的 networkd 等待门禁、设备业务探针和既有业务观察失败，不能重新归因到本次网络掉线。
生产收口过程中还发现并修复了两个发布边界问题：第一，文档站尚未发布 Reachability Refresh 部署脚本，HTTP 404 不能作为部署成功依据；第二，手动刷新部署脚本在 R4 退役后仍残留 PROXY_SNAPSHOT 状态字段，现场安装的核心服务已启用但状态命令失败。修正版已重新部署，RR 上 /usr/local/lib/agentmeshos/reachability-refresh/worker.py 的 SHA256 与仓库提交 64003785 一致，执行器 path 单元为 active/enabled。
🔌 分布式底座接入声明
P22 实施期间不接入分布式执行底座。 本阶段完成的是职责域、告警语义、Console 导航、网络数据源和 R4 退役，未提交 Nomad Job、未运行 Worker、未写入 Cloudreve；Runtime、API Gateway、Console 和节点网络只做已声明的部署与回读。
| 层 | 本阶段处理 |
|---|---|
| Network | 不接入；只记录网络职责边界，不改网络 |
| Nomad | 不接入；不提交任务 |
| Compute | 不接入；不分发脚本或构建产物 |
| Storage | 不接入；计划正文写入 Git，不写 Cloudreve |
| Observability | 仅引用已有证据，不增加探针 |
| Adapter | 不适用；不调用 NomadAdapter、StorageAdapter 或 ToolAdapter |
| 凭据 | 不读取或分发生产凭据 |
后续进入实施工作包后，若需要采集、解析、迁移或运行验证，必须在对应工作包中重新声明底座接入、数据路径、凭据边界和验收证据。
🔁 回退与兼容原则
计划阶段的回退方式是保留现有 P21、P19、P20 和架构文档，不改变当前生产状态。后续实现阶段必须采用批次化发布、旧接口兼容、last-known-good 配置和可回退页面入口。
旧告警、旧探针、旧菜单和历史状态不能直接删除。只有完成对象映射、历史读取和负向回归后，才允许退役；历史审计记录必须保留，不能用删除数据解决展示混乱。
⚠️ 风险与未决项 / 需要用户决策
| 未决项 | 当前状态 | 需要确认的内容 |
|---|---|---|
| P22 是否正式切为当前阶段 | 已完成并归档 | state.json 已滚动到 P23 占位阶段 |
| P19 是否在 P22 内重新启动 | 尚未决定 | 当前只审查其职责，不自动恢复 P19 |
| 告警中心与 AI Boss 的最终关系 | 已有方向，契约未冻结 | 确认 AI Boss 是处置执行者、分析者，还是可选处理渠道 |
| 六类 Console 导航 | 用户暂时接受 | 后续需要按真实页面清单逐项归类 |
| 导航视觉和折叠细节 | 目标已明确，具体样式未冻结 | P22-0 盘点现有菜单，P22-5 提交线框、交互规则和桌面/移动端验收矩阵 |
| 架构基座更新时间漂移 | 已发现 | P22-6 统一修订，不在计划创建阶段直接改写 |
| 网络迁移和整套重建 | 已取消/暂停 | 如未来重新启动，必须另立计划 |
🔜 下一步
P22 已归档，不再继续追加实施范围。Memory Server 业务探针的正式部署来源、职责归属和告警出口转入 P23 后续治理评审；在 P23 完成范围冻结前，不删除仍在运行的 Memory 探针，也不把它当成网络探针。