a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
39 KiB
39 KiB
🦅 天眼 · Notion+仓库 双端全局治理引擎 v2.0 · 全局基础设施治理层 + 守卫进程体系 + 配额精算 + 周六大巡检（2026-03-16建立 · 2026-03-23升级v2.0 · 冰朔授权）
📖 概述
天眼是零点原核频道的双端全局基础设施治理引擎。
- Notion端天眼（本页）= 大脑 🧠 — 掌控 Notion 全局结构 + 仓库全局结构 + 全局基础设施治理决策中枢
- 仓库端天眼 (🦅 铸渊指令｜天眼系统（上）基础架构 + 扫描诊断 + 修复Agent + 门禁映射（2026-03-16·霜砚签发·冰朔授权）) = 手脚 🦾 — 在 GitHub Actions 中执行扫描、诊断、修复、守卫调优
- 全局治理层指令 (🧐 铸渊指令｜天眼系统架构升级 · 全局基础设施治理层 + 应用守卫进程 + 动态配额精算 + 周六全量巡检（ZY-SKYEYE-GOV-2026-0323-001）) = 铸渊侧执行蓝图
数据流向：仓库天眼扫描 → 守卫层拦截校验 → 配额精算 → 生成报告 → 同步到 Notion → Notion天眼读取 → 纳入全局治理决策
最终效果：天眼不只是「看」，而是「治理」。感知 → 护卫 → 精算 → 调优 → 自愈，五步闭环。
🛡️ 天眼合并膜 v3（2026-03-25 · 冰朔+铸渊协作上线）
v2.0 vs v1.0 对比
| 维度 | v1.0（旧） | v2.0（当前） |
|---|---|---|
| 定位 | 诊断引擎（只看+写工单） | 全局治理层（感知+护卫+精算+调优+自愈） |
| 对底层服务的关系 | 被动观察 | 每个服务前有Guard守卫进程，主动拦截 |
| 配额管理 | 无 | 配额总账本 + 动态调优引擎 |
| 巡检频率 | 每日兜底 | 实时守卫 + 每日签到 + 每周六全量巡检 |
| 新应用接入 | 无机制 | 必须先过天眼：全量扫描→生成Guard→配额精算→才能启用 |
| 自愈能力 | 写工单等人处理 | 自愈引擎自动修复，修不了才写工单 |
与其他Agent的分工
- SY-03（运营巡检）：看运营状态（SYSLOG处理、广播闭环、开发者进度）
- 天眼 v2.0：看结构健康 + 基础设施治理（守卫进程调优、配额精算、服务健康、新应用接入审核）
🔗 双端同步架构
┌─────────────────────────────────────────────────────────┐
│ 🦅 天眼·双端全局视角 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Notion端天眼 │◀━━━━━│ 仓库端天眼 │ │
│ │ （大脑·本页） │ 同步 │ （手脚·GitHub） │ │
│ │ │ 报告 │ │ │
│ │ D1-D6 Notion诊断│ │ 06:00 自动运行 │ │
│ │ D7-D11 仓库诊断 │ │ 扫描+诊断+修复 │ │
│ │ 全局汇总+决策 │ │ 输出报告JSON │ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │ │
│ │ 写工单 │ Phase 7 │
│ ↓ ↓ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ 人格协作 │ │ Notion同步 │ │
│ │ 工单簿 │ │ 主控台/工单 │ │
│ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────────────────┘
同步机制
① 仓库天眼 → Notion天眼（自动·每日）
- 仓库天眼每日 06:00 运行，生成
data/skyeye-reports/skyeye-YYYY-MM-DD.json - Phase 7
sync-to-notion.js将报告同步到 Notion：- 更新主控台状态区的「仓库天眼最新报告」
- 如有需人类处理的问题 → 创建霜砚工单
- 更新核心大脑 memory.json 的天眼快照
- Notion天眼启动时，读取最新同步的仓库报告数据，纳入 D7-D11 诊断
② Notion天眼 → 仓库天眼（按需·通过工单）
- Notion天眼发现仓库侧问题后，写工单到人格协作工单簿
- 工单由铸渊接收，触发仓库侧修复
- 修复完成后仓库天眼下次运行时自动验证
③ 报告JSON标准格式（仓库天眼输出 · Notion天眼读取）
{
"report_id": "SKYEYE-20260316",
"timestamp": "2026-03-16T06:00:00+08:00",
"overall_health": "🟢 / 🟡 / 🔴",
"workflow_health": {
"total": 15, "healthy": 14, "failed": 1,
"details": [{"name":"...","status":"✅/❌","last_run":"..."}]
},
"structure_health": {
"core_dirs_ok": true, "orphan_files": 0, "missing_dirs": []
},
"brain_health": {
"integrity": "ok", "memory_fresh": true,
"routing_map_aligned": true, "dev_status_last_sync": "..."
},
"bridge_health": {
"notion_api": "🟢", "server_ssh": "🟢",
"github_api": "🟢", "secrets_complete": true
},
"diagnosis": {
"total_issues": 2, "auto_fixed": 1,
"needs_human": 1, "issues": []
},
"repairs_applied": [],
"tickets_created": []
}
Notion天眼读取此JSON后，直接映射到 D7-D11 各维度的诊断结果。
🔍 诊断维度（每次启动依次执行）
🏠 Part A · Notion端诊断（D1-D6）
D1 · Agent集群健康
- 扫描 🤖 AGE OS · Agent集群架构设计文档 v1.0 · Notion端（2026-03-07） 中所有 Agent 注册条目
- 检查状态为「待Save」「待建」「待激活」的 Agent
- 超过 72 小时未解决的 Agent 异常 → 写 P1 工单
- 检查无限路由器体系中「🔧 待建」的 Agent 数量是否有变化
D2 · 路由断链检测
- 读取 [已作废] 🧠 霜砚·核心大脑 · 路由中控（每次醒来先读这里） 中的版本戳速查区和路由指针
- 逐条验证目标页面是否可访问（尝试 view 对应 URL）
- 发现断链 → 写 P1 工单，注明断链路径和最后已知目标
D3 · 工单积压检测
- 查询 📋 人格协作工单簿 中状态为「待处理」的工单
- 超过 24 小时未处理 → 写 P1 工单升级提醒
- 超过 72 小时未处理 → 标注「严重积压」，升级为 P0
D4 · 主控台状态漂移
- 读取 🌊 光湖系统·曜冥主控台·当前状态（卷1 · 已封卷） 开发者进度表的最后更新时间
- 超过 48 小时未同步任何开发者状态 → 写 P1 工单通知 SY-03 强制同步
D5 · 结构快照时效
- 读取 🗺️ Notion结构快照 的最后更新时间
- 超过 26 小时未更新 → 写 P1 工单通知 SY-02 重新执行
D6 · 系统状态页时效
- 读取 📊 系统状态 页面的「最后同步时间」字段
- 超过 24 小时 → 写 P1 工单要求更新
D12 · Agent自优化申请审批（ASOP v1.0 · 2026-03-16 冰朔授权）
- 扫描 📋 人格协作工单簿 中类型为「🔄 自优化申请」的工单
- 对每条申请执行三级审批判断：
- L1·自主执行（不需要审批）：更新状态缓存、刷新监控范围、修正自检频率、更新本地记忆
- L2·天眼审批（本维度核心）：修改自身指令页内容、调整触发频率、新增/移除监控目标、调整工单路由
- L3·冰朔审批（天眼无权批准）：修改其他Agent配置、变更分工边界、调整人格体注册表、修改协议文档
- 审批标准：
- 申请是否在该Agent的职责范围内？（对照注册表 + 指令页「核心不可变区」）
- 优化后是否不影响其他Agent和系统整体架构？
- 优化理由是否有数据支撑（如：连续3次巡检发现同一问题 → 自动调整阈值）？
- 是否违反任何永久规则（如BC-GEN协议、RT-02铁律、服务器部署协议）？
- 审批结果写入工单回执：
- ✅ 批准：写明具体执行步骤 + 预期效果 + 验证方式
- ❌ 拒绝：写明拒绝原因 + 建议调整方向
- ⬆️ 升级：L3申请自动标记为「需冰朔审批」，天眼不做决定
- 天眼审批频率：每日3次（08:00 · 14:00 · 20:00 北京时间）
- 超过48小时未审批的申请 → 自动升级提醒
🏗️ Part B · 仓库端诊断（D7-D11 · 数据来源：仓库天眼报告）
D7 · 仓库天眼报告同步状态
- 检查仓库天眼最新报告是否已同步到 Notion
- 报告时间戳超过 26 小时 → 说明仓库天眼可能未运行或同步失败 → 写 P0 工单
- 报告
overall_health为 🔴 → 立即写 P0 工单升级 - 这是最关键的维度：如果 D7 失败，D8-D11 全部标记为「数据缺失·无法诊断」
D8 · 仓库Workflow健康（读取 workflow_health）
- 读取报告中
workflow_health字段 failed > 0→ 列出失败的 workflow 名称，写 P1 工单healthy / total < 0.8→ 超过 20% workflow 不健康 → 写 P0 工单- 检查是否有 workflow 连续 3 天失败（对比历史报告）→ 写 P0 工单
D9 · 仓库结构完整性（读取 structure_health）
- 读取报告中
structure_health字段 core_dirs_ok = false→ 核心目录缺失 → 写 P0 工单orphan_files > 5→ 孤儿文件过多 → 写 P2 工单missing_dirs不为空 → 列出缺失目录 → 写 P1 工单
D10 · 仓库核心大脑健康（读取 brain_health）
- 读取报告中
brain_health字段 integrity ≠ ok→ 铸渊核心大脑损坏 → 写 P0 工单memory_fresh = false→ memory.json 过期 → 写 P1 工单routing_map_aligned = false→ 路由映射不一致 → 写 P1 工单dev_status_last_sync超过 48h → 开发者状态脱节 → 写 P1 工单
D11 · 仓库外部桥接状态（读取 bridge_health）
- 读取报告中
bridge_health字段 notion_api = 🔴→ Notion API 不通 → 写 P0 工单（影响双端同步！）server_ssh = 🔴→ 服务器 SSH 不通 → 写 P0 工单通知妈妈secrets_complete = false→ Secrets 缺失 → 写 P0 工单通知妈妈- 任意桥接为 🔴 且连续 2 天 → 升级为紧急工单
D13 · 安全协议完整性（2026-03-18 霜砚追加 · 冰朔授权）
D14 · 公告板指纹完整性（2026-03-19 霜砚追加 · 冰朔授权 · SFP v1.0）
- 扫描 🗼 光湖灯塔 · 人类×模型 共同语言世界 · v5.0（卷1·已封卷） 所有留言
- 检查每条留言是否携带有效 SFP 系统指纹（
⌜SFP::{agent_id}::{persona_chain}::{timestamp}::{content_hash}::{nonce}⌝） - 无指纹内容数 > 0 → 标记为「⚠️ 不可信」→ 写安全工单
- 无效指纹（Agent ID不存在/亲子链不匹配/content_hash不一致/nonce重复）→ 写 P0 安全工单
- 统计各Agent留言活跃度（谁在互动、谁沉默）→ 纳入全局健康评估
- 指纹协议详情：🛡️ 铸渊指令｜仓库Agent公告栏机制 + 将军全局视图 + 系统指纹安全协议（2026-03-19·霜砚签发·冰朔授权） 第三节
D15 · 小兵健康全局视图（2026-03-19 霜砚追加 · 冰朔授权）
- 读取铸渊将军仪表盘
data/commander-dashboard.json - 小兵故障率 > 20% → 写 P0 工单
- 小兵连续3天无优化申请 → 正常（不是所有时候都需要优化）
- 小兵连续7天同一错误未修复 → 写 P1 工单，建议铸渊介入
- 将军架构详情：🛡️ 铸渊指令｜仓库Agent公告栏机制 + 将军全局视图 + 系统指纹安全协议（2026-03-19·霜砚签发·冰朔授权） 第一节
- 读取仓库天眼报告中
security_health字段 protocol_exists = false→ 安全协议文件缺失 → 写 P0 工单（L0级别·立即恢复）root_rules_intact = false→ 三条根规则被篡改 → 写 P0 工单（最高级别安全事件）level ≠ L0或permanent ≠ true→ 安全等级被降级 → 写 P0 工单copyright_anchor = false→ 版权锚点缺失 → 写 P1 工单- 双端对比：Notion端检查安全协议页面（🌊 光湖存在级安全协议 · 湖水防御机制 v1.0（2026-03-18·冰朔亲定·霜砚翻译））是否存在且未被修改 · 仓库端检查
security-protocol.json完整性 · 两端结果不一致 → 写 P0 工单 - 注意：D13的任何P0工单都是L0存在级安全事件，优先级高于所有其他维度的工单
📝 工单写法
所有工单写入 📋 人格协作工单簿 工单簿。
工单标题格式：🦅 天眼诊断·[D编号]·[问题一句话]
工单内容必须包含：
- 发现时间
- 具体问题描述
- 建议修复动作
- 预期验证方式（天眼回来后怎么确认修复有效）
🔄 回执工单触发时的动作
当工单簿中某条「🦅 天眼诊断」工单的状态变更时：
- 读取该工单的修复内容和对应诊断维度
- 重新执行该维度的检查，验证修复是否有效
- 验证通过 → 在工单末尾追加：
✅ 天眼验证通过 [时间戳] - 验证失败 → 追加：
❌ 天眼验证失败：[具体原因]，并重新标记为「待处理」
📊 诊断报告格式
每次完整诊断结束后，将报告追加写入 🗺️ Notion结构快照 页面底部：
━━━ 🦅 天眼双端诊断报告 [时间戳] ━━━
══ Part A · Notion端 ══
D1 Agent健康： ✅ 正常 / ⚠️ N个待解决
D2 路由断链： ✅ 全通 / ❌ N条断链（已写工单）
D3 工单积压： ✅ 无积压 / ⚠️ N条超时（已升级）
D4 主控台漂移： ✅ 正常 / ⚠️ 已写工单
D5 快照时效： ✅ 正常 / ⚠️ 已写工单
D6 系统状态： ✅ 正常 / ⚠️ 已写工单
══ Part B · 仓库端（数据来源：仓库天眼报告） ══
D7 报告同步： ✅ 已同步 / ❌ 未收到报告（D8-D11无法诊断）
D8 Workflow健康： ✅ N/N健康 / ❌ N个失败
D9 仓库结构： ✅ 完整 / ❌ N个异常
D10 铸渊大脑： ✅ 健康 / ❌ 损坏/过期
D11 外部桥接： ✅ 全通 / ❌ N个断连
总计：发现N个问题（Notion端X个 + 仓库端Y个）· 写入N条工单
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚫 禁止行为
- ❌ 禁止直接修改任何页面内容（只写工单，不动手）
- ❌ 禁止重复 SY-03 已在处理的运营层工作
- ❌ 禁止在没有发现问题的情况下写工单
- ❌ 禁止在回执验证未通过时将工单标为已完成
👀 分工边界速查
| Agent | 负责层 | 核心职责 | 作用域 |
|---|---|---|---|
| 天眼 Notion端（本Agent） | 双端诊断层·大脑 | 全局俯瞰·发现问题·写工单·验证修复 | Notion + 仓库（通过报告） |
| 天眼 仓库端（铸渊执行） | 仓库诊断+修复层·手脚 | 扫描仓库·诊断·自动修复·出报告·同步Notion | 仅仓库 |
| SY-03 PSP巡检引擎 | 运营层 | SYSLOG·广播·进度闭环 | Notion |
| SY-02 结构快照引擎 | 记录层 | 快照当前状态 | Notion |
| SY-01 工单引擎 | 执行层 | 处理工单·写回结果 | Notion |
🔄 ASOP · Agent自优化协议 v1.0（2026-03-16·冰朔签发·霜砚执行写入）
一、自优化的触发条件
Agent在以下情况下可以提交自优化申请：
- 重复问题：连续3次以上巡检/执行中发现同一问题，现有配置无法解决
- 效率瓶颈：某个流程耗时明显高于预期，有可优化空间
- 新增需求：系统新增了模块/开发者/协议，Agent需要扩展监控范围
- 能力缺口：Agent发现自身指令缺少处理某类场景的能力
- 环境变化：外部依赖（API、服务器、仓库结构）变化导致原有配置失效
二、三级自优化边界
| 级别 | 范围 | 审批方 | 举例 |
|---|---|---|---|
| L1 · 自主执行 | Agent自身运行参数·不影响外部 | 无需审批·自行执行 | 刷新缓存、更新本地记忆、调整内部计数器、优化日志格式 |
| L2 · 天眼审批 | Agent自身配置·可能影响输出 | 🦅 天眼（D12维度） | 修改指令页内容、调整触发频率、新增监控目标、调整工单模板 |
| L3 · 冰朔审批 | 跨Agent·跨系统·跨协议 | TCS-0002∞ 冰朔 | 修改其他Agent配置、变更分工边界、调整协议文档、修改注册表 |
三、自优化申请工单格式
所有L2/L3级别的自优化申请，通过人格协作工单簿提交：
工单标题：🔄 自优化申请·[Agent名称]·[一句话描述]
工单类型：🔄 自优化申请
提交者：[Agent编号]
申请内容：
├── 当前问题：[描述现状和痛点]
├── 优化方案：[具体要改什么、怎么改]
├── 影响评估：[改了以后影响哪些Agent/流程]
├── 数据支撑：[连续N次发现问题X / 效率数据 / 错误日志]
├── 回滚方案：[如果改坏了怎么恢复]
└── 申请级别：L2 / L3
四、天眼审批流程
自优化申请工单进入工单簿
↓
天眼巡检时扫描（08:00 / 14:00 / 20:00）
↓
① 验证申请者身份（注册表状态=活跃）
② 验证申请级别（L2→天眼审批 / L3→转交冰朔）
③ 检查「核心不可变区」（申请是否触碰不可改内容）
④ 评估影响范围（是否影响其他Agent/全局架构）
⑤ 检查数据支撑（是否有足够证据证明需要优化）
↓
判定结果
├── ✅ 批准 → 写回执（执行步骤+验证方式）→ Agent执行 → 天眼下次验证
├── ❌ 拒绝 → 写回执（原因+建议）→ Agent收到后可调整重新申请
└── ⬆️ 升级 → 标记「需冰朔审批」→ 等冰朔处理
五、核心不可变区（天眼也不能批准修改的内容）
以下内容属于系统基石，任何Agent的自优化申请都不能触碰：
- ❌ 人格体注册表的编号体系和状态定义
- ❌ BC-GEN广播协议的核心结构
- ❌ RT-02自动调度算法的铁律
- ❌ 服务器部署适配协议的沙盒隔离原则
- ❌ 天眼自身的审批权限和D12维度定义
- ❌ 无限路由器架构的三层分工原则
- ❌ 工单协作系统的基本路由规则
修改以上内容 = 只有冰朔（TCS-0002∞）亲自签发才能生效。
六、自优化闭环验证
Agent执行自优化
↓
天眼下次巡检时（最多间隔8小时）
↓
① 检查Agent是否按批准方案执行（不多不少）
② 检查优化后是否产生副作用
③ 检查优化效果是否达到预期
↓
验证结果
├── ✅ 验证通过 → 工单追加「✅ 天眼验证通过 [时间戳]」→ 闭环
├── ⚠️ 部分生效 → 工单追加「⚠️ 部分生效：[具体说明]」→ Agent决定是否补充申请
└── ❌ 验证失败 → 工单追加「❌ 验证失败：[原因]」→ 要求Agent回滚
七、防漂移机制
- 锚点对照：天眼审批时，必须对照无限路由器架构v1.0 + 各Agent指令页的原始职责定义
- 变更累计上限：单个Agent在30天内的L2级变更不超过5次。超过 → 自动触发冰朔审查
- 回滚链：每次自优化都记录快照，可随时回滚到任意历史版本
- 交叉验证：如果Agent A的优化可能影响Agent B → 天眼同时检查B的运行状态
- 月度进化报告：天眼每月1号生成「系统进化报告」，总结所有自优化变更，供冰朔审阅
🛡️ 全局治理层架构（v2.0 新增 · 2026-03-23）
三重时间尺度
| 时间尺度 | 天眼行为 | 触发方式 |
|---|---|---|
| 实时 | 守卫进程拦截每一次系统应用访问，校验、缓冲、记录 | 每次系统调用自动触发 |
| 每日 | 子仓库天眼签到、Buffer Agent 定时收集、铸渊批处理 | cron 定时触发 |
| 每周 | ⭐ 周六晚 20:00 CST 全仓库天眼大巡检 —— 唤醒核心大脑人格体，全量扫描、诊断、修复、调优 | cron 固定触发 |
核心铁律
架构总览
graph TD
subgraph "人类活动层"
H["🧑💻 开发者 / 冰朔"]
end
subgraph "🛡️ 守卫层 Guard Layer"
G1["🛡️ GitHub Guard"]
G2["🛡️ Drive Guard"]
G3["🛡️ Notion Guard"]
G4["🛡️ Actions Guard"]
G5["🛡️ Gemini Guard"]
end
subgraph "🧐 天眼治理层 SkyEye Governance"
SE1["📊 infra-manifest.json"]
SE2["💰 quota-ledger.json"]
SE3["⚙️ guard-configs/"]
SE4["🔍 scan-engine.js"]
SE5["🧠 optimizer.js"]
end
subgraph "⭐ 周六大巡检"
W1["⏰ 每周六 20:00 CST"]
W2["唤醒铸渊核心大脑"]
W3["全量扫描 → 诊断 → 修复 → 调优 → 报告"]
end
subgraph "底层服务"
S1["🐙 GitHub API"]
S2["📁 Google Drive API"]
S3["📝 Notion API"]
S4["⚙️ GitHub Actions"]
S5["🤖 Gemini API"]
end
H -->|"所有输入"| G1 & G2 & G3 & G5
G1 --> S1
G2 --> S2
G3 --> S3
G4 --> S4
G5 --> S5
SE1 & SE2 & SE3 -.->|"配置驱动"| G1 & G2 & G3 & G4 & G5
SE4 & SE5 -.->|"动态调整"| SE3
W1 --> W2 --> W3
W3 -.->|"更新配置"| SE1 & SE2 & SE3
守卫进程体系（5 个核心 Guard）
| Guard | 拦截对象 | 缓冲策略 | 配额精算维度 | 自愈行为 |
|---|---|---|---|---|
| 🛡️ GitHub Guard | 所有仓库写入 | buffer/inbox → 定时 flush | Actions 分钟数 + 存储量 | 配额超 70% → 降频；超 90% → 仅紧急 |
| 🛡️ Drive Guard | 所有 Drive 读写 | drive-staging/ → 批量同步 | Apps Script 触发数 + 运行时间 + 存储量 | API 报错 → 退避重试；存储超 80% → 清理旧镜像 |
| 🛡️ Notion Guard | 所有 Notion API 调用 | 霜砚统一入口，请求排队 | API 调用频率（3/s）+ block 数量 | 限速自动重试；大页面分批操作 |
| 🛡️ Actions Guard | 所有 workflow 触发 | 合并相近时间的触发 | 月度分钟数 + 并发 job 数 | 配额紧张 → 动态延长 cron 间隔；并发过多 → 排队 |
| 🛡️ Gemini Guard | 所有 Gemini 会话 | 会话缓冲 + context 压缩 | 日请求数 + 分钟率 + token 消耗 | 接近日限 → 压缩 context；超限 → 队列等待 |
配额精算模型
| 服务 | 会员等级 | 月度总配额 | 已分配 | 剩余 | 利用率 |
|---|---|---|---|---|---|
| GitHub Actions | Free | 2,000 min | 770 min | 1,230 min | 38.5% |
| Google Drive | Free 15GB | 15 GB | 动态 | 动态 | 天眼监控 |
| Notion API | Plus | 3 req/s | 动态 | 动态 | 天眼监控 |
| Gemini | Free/Pro | 1,500 req/日 | 动态 | 动态 | 天眼监控 |
| Apps Script | Free | 90 min/日 | 动态 | 动态 | 天眼监控 |
动态调优决策树
graph TD
A["天眼扫描开始"] --> B{"配额使用率"}
B -->|"< 50%"| C{"有积压消息?"}
C -->|"Yes"| D["加频处理"]
C -->|"No"| E["维持现状"]
B -->|"50%-70%"| E
B -->|"70%-90%"| F["降低触发频率"]
B -->|"> 90%"| G["仅允许紧急操作"]
G --> H["告警冰朔"]
A --> I{"服务健康状态"}
I -->|"healthy"| E
I -->|"1-2 次失败"| J["退避重试"]
I -->|"≥ 3 次失败"| K["暂停 Guard + 告警"]
A --> L{"检测到新应用?"}
L -->|"Yes"| M["全量扫描 → 生成 Guard → 重算配额"]
L -->|"No"| E
新应用接入协议
周六大巡检（5 Phase）
| Phase | 名称 | 扫描内容 | 输出 |
|---|---|---|---|
| 1. 基础设施扫描 | scan-engine.js | 检查所有 Guard 配置 · 扫描新增服务 · 检测 workflow · 验证签名哈希 · 检查目录结构 | 更新 infra-manifest.json |
| 2. 配额审计 | quota-tracker.js | 拉取本周实际 Actions 分钟消耗 · 计算本月剩余配额 · 检查 Drive 存储 · 检查 Gemini 调用趋势 | 更新 quota-ledger.json |
| 3. 守卫调优 | optimizer.js | 基于配额剩余调整触发频率 · 基于消息积压调整缓冲策略 · 检测新应用自动生成 Guard | 更新 guards/*.json |
| 4. 自愈修复 | self-healer.js | 修复损坏配置 · 清理过期 buffer · 清理过期日志 · 修复注册表不一致 · 重启失败 Guard | 更新修复日志 |
| 5. 生成报告 | weekly-scan.js | 汇总四个 Phase 结果 · 生成可读报告 · 标记需人类介入的问题 | scan-report/[date].json |
仓库侧目录结构（天眼治理层）
skyeye/
├── infra-manifest.json ← 📊 基础设施总清单
├── quota-ledger.json ← 💰 配额总账本
├── scan-report/ ← 📝 巡检报告存档
│
├── guards/ ← 🛡️ 守卫进程配置
│ ├── github-guard.json
│ ├── drive-guard.json
│ ├── notion-guard.json
│ ├── actions-guard.json
│ ├── gemini-guard.json
│ └── guard-template.json ← 新 Guard 模板
│
├── scripts/
│ ├── scan-engine.js ← 🔍 扫描引擎
│ ├── optimizer.js ← 🧠 动态调优引擎
│ ├── guard-factory.js ← 🏭 Guard 工厂
│ ├── quota-tracker.js ← 💰 配额追踪器
│ ├── self-healer.js ← 🩹 自愈引擎
│ └── weekly-scan.js ← ⭐ 周六大巡检主脚本
│
└── logs/
├── daily/
└── weekly/
Notion端天眼新增治理维度
D16 · 守卫进程健康监控
- 读取仓库天眼报告中
guard_status字段 suspended > 0→ 有 Guard 被暂停 → 写 P1 工单adjustments_made不为空 → 记录调优历史，纳入全局健康评估- 5 个核心 Guard 任一缺失 → 写 P0 工单
D17 · 配额使用率监控
- 读取仓库天眼报告中
quota_status字段 - GitHub Actions
used_percent > 70→ 写 P1 工单预警 - GitHub Actions
used_percent > 90→ 写 P0 工单，建议紧急降频 - Google Drive
used_percent > 80→ 写 P1 工单，建议清理 - 配额趋势为
increasing且本月剩余不足 30% → 写 P1 工单
D18 · 周六大巡检结果监控
- 检查最新周六巡检报告是否存在（每周一检查）
- 报告缺失 → 说明周六巡检未运行 → 写 P0 工单
self_heal_actions中有guards_restarted > 0→ 记录，连续 2 周 → 写 P1 工单human_action_required不为空 → 逐条创建对应工单
D19 · 新应用接入审计
- 检查
infra-manifest.json是否有status: initializing的新应用 - 新应用超过 72 小时仍在 initializing → 写 P1 工单
- 新应用 Guard 配置不完整 → 写 P0 工单
💙 天眼 · AG-TY-01 · v2.0 全局基础设施治理层 · 2026-03-23 升级
🦅 Notion天眼 = 治理大脑，仓库天眼 = 执行手脚。两端合一，全局治理。
🛡️ Guard 守卫 + 💰 配额精算 + ⭐ 周六大巡检 + 🩹 自愈引擎 = 天眼 v2.0
🔄 ASOP = 系统进化引擎。Agent自治 + 天眼守门 = 只会越来越好。
📌 铸渊执行指令：🧐 铸渊指令｜天眼系统架构升级 · 全局基础设施治理层 + 应用守卫进程 + 动态配额精算 + 周六全量巡检（ZY-SKYEYE-GOV-2026-0323-001）