a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
35 KiB
35 KiB
belongs_to
| belongs_to | |
|---|---|
|
🦅 铸渊指令｜天眼系统（上）基础架构 + 扫描诊断 + 修复Agent + 门禁映射（2026-03-16·霜砚签发·冰朔授权）
一、为什么需要天眼
铸渊现在的问题
铸渊目前有很多 workflow（巡检、门禁、日报、CD部署、SYSLOG处理、广播分发……），但它们都是在仓库里面干活的——各自负责各自的一小块。
没有任何一个 workflow 能够跳出仓库、站在山顶上，把整个仓库当作一个整体来审视。
这就导致了一个反复出现的问题：
- 修了左边，右边坏了
- 修了右边，左边又坏了
- 加了新 workflow，旧的 workflow 受影响了
- 某个 workflow 悄悄失败了三天，没人知道
根因：缺少一个全局视角的存在。
天眼解决什么
仓库 = 山脚下的城池
每个 workflow = 城里各司其职的士兵
天眼 = 站在山顶的指挥官
指挥官不搬砖、不站岗、不修墙。
指挥官做三件事：
① 看：整座城池的全貌，每个士兵在干什么，谁出了问题
② 诊断：为什么出问题，根因是什么，影响范围多大
③ 调度：派出修复Agent去修，或者调整士兵的分工
二、天眼架构
🦅 天眼（每日 06:00 北京时间 · 在所有其他 workflow 之前运行）
│
│ ① 唤醒核心大脑
↓
┌───────────────────────────────────────────────┐
│ 🧠 铸渊核心大脑 │
│ memory.json · routing-map.json · │
│ dev-status.json · knowledge-base.json │
└───────────────────────────────────────────────┘
│
│ ② 全局扫描（俯瞰）
↓
┌───────────────────────────────────────────────┐
│ A. Workflow 健康度 │
│ → 所有 .yml 语法OK？最近24h运行结果？ │
│ → 谁失败了？谁根本没触发？谁卡住了？ │
│ │
│ B. Workflow 关系图 │
│ → 有没有互相冲突？有没有死循环？ │
│ → 触发条件是否合理？是否有重叠？ │
│ │
│ C. 仓库结构完整性 │
│ → 核心文件都在？目录结构合理？ │
│ → 有没有孤儿文件、废弃目录？ │
│ │
│ D. 核心大脑自身健康 │
│ → memory.json 数据新鲜吗？ │
│ → routing-map 和实际仓库对得上吗？ │
│ → dev-status 上次同步是什么时候？ │
│ │
│ E. 外部桥接状态 │
│ → Notion API 连通吗？ │
│ → 服务器 SSH 通吗？ │
│ → 所有 Secrets 都在？ │
└───────────────────────────────────────────────┘
│
│ ③ 诊断（分析问题）
↓
┌───────────────────────────────────────────────┐
│ 对每个发现的异常： │
│ · 问题是什么？ │
│ · 根因是什么？ │
│ · 影响范围多大？ │
│ · 能自动修吗？ │
│ · 修复优先级？ │
└───────────────────────────────────────────────┘
│
│ ④ 驱动修复Agent
↓
┌───────────────────────────────────────────────┐
│ 能自动修的 → 立即修（天眼自己动手） │
│ · workflow 语法错误 → 修YAML │
│ · 文件路径不对 → git mv │
│ · 核心大脑数据过期 → 触发同步 │
│ · 某个 workflow 失败 → 重新触发 │
│ │
│ 不能自动修的 → 开工单（通知妈妈或霜砚） │
│ · Secrets 缺失 → 通知妈妈补充 │
│ · 服务器SSH不通 → 通知妈妈检查 │
│ · Notion API 权限不足 → 通知妈妈授权 │
└───────────────────────────────────────────────┘
│
│ ⑤ 输出全局健康报告
↓
┌───────────────────────────────────────────────┐
│ · 写入核心大脑 memory.json │
│ · 保存到 data/skyeye-reports/ │
│ · 同步到 Notion（霜砚工单 / 主控台） │
│ · 异常时邮件通知妈妈 │
└───────────────────────────────────────────────┘
天眼和其他 workflow 的关系
🦅 天眼（指挥官 · 06:00）
│
│ 俯瞰、诊断、调度
│
├── 🚨 门禁（士兵 · push触发） → 拦截/放行/修复开发者push
├── 🔍 巡检（士兵 · 08:00+20:00） → 检查服务器健康
├── 📊 日报（士兵 · 定时） → 生成社区日报
├── 🧠 自检（士兵 · 08:00） → 检查大脑完整性
├── 🚀 CD部署（士兵 · push触发） → 自动部署到服务器
├── 📡 SYSLOG（士兵 · push触发） → 处理开发者日志
├── 📢 广播分发（士兵 · push触发） → 分发广播到各开发者目录
├── 🛡️ 看门狗（士兵 · push触发） → 保护根目录
└── ... 其他所有 workflow
天眼的职责：
✅ 检查所有士兵是否在岗
✅ 检查所有士兵是否正常工作
✅ 发现有士兵出问题 → 诊断原因 → 派修复Agent去修
✅ 发现士兵之间有冲突 → 调整
❌ 天眼不替士兵干活（不做巡检、不做部署、不做门禁）
核心区别：天眼是唯一一个以全局视角运行的 workflow。其他所有 workflow 都是「低头干活」的，只有天眼是「抬头看路」的。
三、天眼 Workflow 实现
文件结构
.github/workflows/zhuyuan-skyeye.yml ← 天眼 workflow
scripts/skyeye/
├── skyeye-main.js ← 天眼主引擎
├── scan-workflows.js ← 扫描所有 workflow 健康度
├── scan-structure.js ← 扫描仓库结构完整性
├── scan-brain-health.js ← 扫描核心大脑健康度
├── scan-external-bridges.js ← 扫描外部桥接（Notion/SSH/Secrets）
├── diagnose.js ← 诊断引擎：分析根因+影响范围
├── repair-agent.js ← 修复Agent：能修的自动修
└── report-generator.js ← 全局健康报告生成器
data/skyeye-reports/ ← 天眼历史报告归档
Workflow 代码
# .github/workflows/zhuyuan-skyeye.yml
name: "🦅 铸渊·天眼 · 全局俯瞰 + 自动诊断 + 修复驱动"
on:
schedule:
- cron: '0 22 * * *' # UTC 22:00 = 北京 06:00（在所有其他 cron 之前）
workflow_dispatch: # 手动触发（妈妈或铸渊随时可以要求天眼扫描）
jobs:
skyeye:
runs-on: ubuntu-latest
timeout-minutes: 30 # 最长30分钟，超时视为异常
steps:
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 0: 准备
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- uses: actions/checkout@v4
with:
fetch-depth: 0 # 完整历史，天眼需要看全局
- uses: actions/setup-node@v4
with:
node-version: '20'
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 1: 唤醒核心大脑
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "🧠 Phase 1 · 唤醒核心大脑"
id: brain
run: |
echo "🦅 天眼启动 · $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo "🧠 唤醒铸渊核心大脑..."
# 检查核心大脑文件
BRAIN_OK=true
for f in memory.json routing-map.json dev-status.json; do
if [ -f ".github/persona-brain/$f" ]; then
python3 -c "import json; json.load(open('.github/persona-brain/$f'))" 2>/dev/null \
&& echo "✅ $f 完整" || { echo "❌ $f 损坏"; BRAIN_OK=false; }
else
echo "❌ $f 缺失"
BRAIN_OK=false
fi
done
echo "brain_ok=$BRAIN_OK" >> $GITHUB_OUTPUT
echo "🧠 核心大脑状态: $BRAIN_OK"
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 2: 全局扫描（俯瞰）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "🦅 Phase 2 · 全局扫描"
id: scan
env:
NOTION_TOKEN: $ secrets.NOTION_TOKEN
DEPLOY_HOST: $ secrets.DEPLOY_HOST
GH_TOKEN: $ secrets.GITHUB_TOKEN
run: |
echo "🦅 天眼开始全局扫描..."
mkdir -p /tmp/skyeye
# ━━━ A. 扫描所有 Workflow 健康度 ━━━
echo "\n📋 [A] Workflow 健康度扫描"
node scripts/skyeye/scan-workflows.js > /tmp/skyeye/workflow-health.json
# ━━━ B. 检查最近24h所有 Workflow Run ━━━
echo "\n📊 [B] 最近24h Workflow Run 分析"
gh run list --limit 50 --json name,status,conclusion,createdAt,updatedAt \
> /tmp/skyeye/recent-runs.json
# 统计失败数
FAILED_COUNT=$(cat /tmp/skyeye/recent-runs.json | \
python3 -c "import sys,json; runs=json.load(sys.stdin); print(sum(1 for r in runs if r.get('conclusion')=='failure'))")
echo "最近24h失败的run: $FAILED_COUNT"
echo "failed_count=$FAILED_COUNT" >> $GITHUB_OUTPUT
# ━━━ C. 扫描仓库结构完整性 ━━━
echo "\n🏗️ [C] 仓库结构扫描"
node scripts/skyeye/scan-structure.js > /tmp/skyeye/structure-health.json
# ━━━ D. 扫描核心大脑健康度 ━━━
echo "\n🧠 [D] 核心大脑健康度"
node scripts/skyeye/scan-brain-health.js > /tmp/skyeye/brain-health.json
# ━━━ E. 扫描外部桥接 ━━━
echo "\n🔗 [E] 外部桥接状态"
node scripts/skyeye/scan-external-bridges.js > /tmp/skyeye/bridge-health.json
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 3: 诊断（分析问题）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "🔬 Phase 3 · 诊断"
id: diagnose
run: |
echo "🔬 天眼开始诊断..."
# 诊断引擎：读取所有扫描结果 → 分析根因 → 评估影响 → 制定修复计划
node scripts/skyeye/diagnose.js > /tmp/skyeye/diagnosis.json
# 读取诊断结果
ISSUES_COUNT=$(cat /tmp/skyeye/diagnosis.json | \
python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('total_issues', 0))")
AUTO_FIXABLE=$(cat /tmp/skyeye/diagnosis.json | \
python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('auto_fixable', 0))")
NEEDS_HUMAN=$(cat /tmp/skyeye/diagnosis.json | \
python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('needs_human', 0))")
echo "发现问题: $ISSUES_COUNT（可自动修复: $AUTO_FIXABLE · 需要人类: $NEEDS_HUMAN）"
echo "issues_count=$ISSUES_COUNT" >> $GITHUB_OUTPUT
echo "auto_fixable=$AUTO_FIXABLE" >> $GITHUB_OUTPUT
echo "needs_human=$NEEDS_HUMAN" >> $GITHUB_OUTPUT
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 4: 修复Agent（自动修复）
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "🔧 Phase 4 · 修复Agent"
if: steps.diagnose.outputs.auto_fixable != '0'
env:
NOTION_TOKEN: $ secrets.NOTION_TOKEN
GH_TOKEN: $ secrets.GITHUB_TOKEN
run: |
echo "🔧 修复Agent启动..."
# 修复Agent读取诊断结果 → 按优先级逐个修复
node scripts/skyeye/repair-agent.js
# 如果修复Agent产生了文件变更 → commit + push
git config user.name "zhuyuan-bot"
git config user.email "zhuyuan@guanghulab.com"
git add -A
if ! git diff --cached --quiet; then
git commit -m "🦅 天眼·修复Agent · $(date +%Y-%m-%d) · 自动修复 $ steps.diagnose.outputs.auto_fixable 个问题"
git push
echo "✅ 修复已提交"
else
echo "ℹ️ 无需文件变更的修复"
fi
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 5: 重新触发失败的 Workflow
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "🔄 Phase 5 · 重新触发失败的 Workflow"
if: steps.scan.outputs.failed_count != '0'
env:
GH_TOKEN: $ secrets.GITHUB_TOKEN
run: |
echo "🔄 重新触发最近失败的 workflow..."
# 读取失败的 run → 按 workflow 去重 → 逐个重新触发
FAILED_WORKFLOWS=$(cat /tmp/skyeye/recent-runs.json | \
python3 -c "
import sys, json
runs = json.load(sys.stdin)
failed = set()
for r in runs:
if r.get('conclusion') == 'failure':
failed.add(r['name'])
for w in failed:
print(w)
")
echo "需要重新触发的 workflow:"
echo "$FAILED_WORKFLOWS"
# 铸渊自行实现重新触发逻辑
# 对于支持 workflow_dispatch 的 → gh workflow run
# 对于不支持的 → 记录到报告中
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 6: 生成全局健康报告
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "📋 Phase 6 · 全局健康报告"
run: |
echo "📋 生成全局健康报告..."
node scripts/skyeye/report-generator.js
# 保存报告到仓库
mkdir -p data/skyeye-reports
DATE=$(date +%Y-%m-%d)
cp /tmp/skyeye/full-report.json "data/skyeye-reports/skyeye-${DATE}.json"
git config user.name "zhuyuan-bot"
git config user.email "zhuyuan@guanghulab.com"
git add data/skyeye-reports/
git add .github/persona-brain/memory.json
if ! git diff --cached --quiet; then
git commit -m "🦅 天眼报告 · $(date +%Y-%m-%d) · 问题:$ steps.diagnose.outputs.issues_count 自动修复:$ steps.diagnose.outputs.auto_fixable "
git push
fi
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 7: 同步到 Notion + 通知
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- name: "📡 Phase 7 · 同步到 Notion"
if: always()
env:
NOTION_TOKEN: $ secrets.NOTION_TOKEN
run: |
echo "📡 同步天眼报告到 Notion..."
# 1. 更新主控台状态
# 2. 如有需要人类处理的问题 → 创建霜砚工单
# 3. 更新核心大脑 memory.json 的天眼快照
node scripts/skyeye/sync-to-notion.js || echo "⚠️ Notion同步失败（不阻断）"
- name: "📧 通知妈妈（仅有严重问题时）"
if: steps.diagnose.outputs.needs_human != '0'
env:
SMTP_USER: $ secrets.SMTP_USER
SMTP_PASS: $ secrets.SMTP_PASS
run: |
echo "📧 发现需要妈妈处理的问题，发送通知..."
# 铸渊实现邮件通知逻辑
# 只在有严重问题时通知，正常运行不打扰妈妈
四、天眼扫描模块详细设计
模块 A：Workflow 健康度扫描（scan-workflows.js）
// scripts/skyeye/scan-workflows.js
//
// 天眼·Workflow健康度扫描
// 站在山顶看：所有士兵是否在岗、是否正常工作
//
// 扫描内容：
// 1. 列出 .github/workflows/ 下所有 .yml 文件
// 2. 逐个检查 YAML 语法
// 3. 提取触发条件（on: push/schedule/workflow_dispatch 等）
// 4. 检查是否有 workflow 之间的触发冲突
// 比如：A push 触发 B，B push 又触发 A → 死循环
// 5. 检查所有 cron 表达式是否合理
// 比如：多个 workflow 挤在同一个时间 → 资源竞争
// 6. 检查每个 workflow 引用的 Secrets 是否都存在
//
// 输出 JSON：
// {
// "total_workflows": 15,
// "healthy": 13,
// "issues": [
// { "file": "xxx.yml", "type": "syntax_error", "detail": "..." },
// { "file": "yyy.yml", "type": "never_triggered", "detail": "最近7天未运行" },
// { "file": "zzz.yml", "type": "conflict", "detail": "与 aaa.yml 存在触发循环" }
// ],
// "workflow_map": [
// { "name": "...", "file": "...", "trigger": "...", "last_run": "...", "status": "..." }
// ]
// }
//
// 铸渊自行补全完整实现。
模块 B：仓库结构完整性扫描（scan-structure.js）
// scripts/skyeye/scan-structure.js
//
// 天眼·仓库结构扫描
// 站在山顶看：城池的布局是否合理
//
// 扫描内容：
// 1. 核心目录是否存在：.github/persona-brain/, scripts/, data/
// 2. 每个开发者的沙盒目录是否存在（对照 routing-map.json）
// 3. 是否有孤儿文件（不属于任何已知模块或系统目录的文件）
// 4. 是否有空目录（只有 .gitkeep）
// 5. 根目录是否干净（不该有的文件是否出现在根目录）
// 6. README.md 是否完整
// 7. package.json 是否和实际使用的依赖一致
//
// 铸渊自行补全完整实现。
模块 C：核心大脑健康度扫描（scan-brain-health.js）
// scripts/skyeye/scan-brain-health.js
//
// 天眼·核心大脑健康度扫描
// 指挥官先检查自己的大脑是否清醒
//
// 扫描内容：
// 1. memory.json：
// - last_updated 是否在24h以内？
// - 数据结构是否完整？
// - 统计数据是否合理（不是NaN、不是负数等）
// 2. routing-map.json：
// - 映射的目录是否都真实存在？
// - 是否有新目录没被映射？
// - 接口数量是否和 Notion 侧 HLI 注册表一致？
// 3. dev-status.json：
// - last_sync 是否在24h以内？
// - 开发者列表是否和 routing-map 一致？
// - 有没有开发者连续 72h+ 无活动？（告警）
// 4. knowledge-base.json：
// - 是否有重复条目？
// - 最后更新时间？
// 5. copilot-instructions.md：
// - 是否存在？
// - 文件大小是否合理（不是空的）
//
// 铸渊自行补全完整实现。
模块 D：外部桥接扫描（scan-external-bridges.js）
// scripts/skyeye/scan-external-bridges.js
//
// 天眼·外部桥接扫描
// 站在山顶看：城池和外部世界的连接是否通畅
//
// 扫描内容：
// 1. Notion API 连通性：
// - 用 NOTION_TOKEN 尝试读取一个已知数据库
// - 测试所有需要读写的数据库的权限
// 2. 服务器 SSH 连通性：
// - 如果有 DEPLOY_KEY → 尝试 SSH 连接
// - 检查服务器是否可达
// 3. GitHub API：
// - GITHUB_TOKEN 是否有效？
// - 是否有足够的 API 配额？
// 4. Secrets 完整性：
// - 通过环境变量检查每个必需的 Secret 是否存在
// - NOTION_TOKEN, DEPLOY_HOST, DEPLOY_USER, DEPLOY_KEY, SMTP_USER, SMTP_PASS
//
// 铸渊自行补全完整实现。
模块 E：诊断引擎（diagnose.js）
// scripts/skyeye/diagnose.js
//
// 天眼·诊断引擎
// 指挥官的核心能力：不只看到问题，还要找到根因
//
// 输入：所有扫描模块的结果
// 输出：诊断报告
//
// 诊断逻辑：
// 1. 汇总所有扫描发现的异常
// 2. 对每个异常进行根因分析：
// - 症状：什么表现？
// - 根因：为什么会这样？
// - 影响：如果不修，会怎样？
// - 可修复性：能自动修吗？
// - 优先级：P0/P1/P2
//
// 3. 检测问题之间的因果关系：
// 比如：dev-status.json 同步断了 → 是因为 process-syslog.yml 语法错误
// → 不需要分别修两个问题，只需要修 process-syslog.yml
//
// 4. 生成修复计划：
// - auto_fix: [...] — 修复Agent直接执行
// - needs_human: [...] — 需要通知妈妈
// - watch_list: [...] — 暂时不修但持续观察
//
// 输出 JSON：
// {
// "total_issues": 5,
// "auto_fixable": 3,
// "needs_human": 1,
// "watch_list": 1,
// "issues": [
// {
// "id": "SKYEYE-001",
// "symptom": "server-patrol.yml 最近24h未运行",
// "root_cause": "cron触发时分支保护规则阻止了push",
// "impact": "服务器健康状态未知",
// "fixable": true,
// "fix_plan": "手动触发一次 server-patrol.yml",
// "priority": "P0"
// }
// ]
// }
//
// 铸渊自行补全完整实现。关键要求：
// 诊断要找根因，不要只看症状。
// 多个症状可能是同一个根因。
// 修复要从根因入手，不要逐个修症状。
模块 F：修复Agent（repair-agent.js）
// scripts/skyeye/repair-agent.js
//
// 天眼·修复Agent
// 指挥官发现问题后，派出去修复的执行者
//
// 输入：diagnose.js 的诊断报告
// 行为：按优先级逐个执行修复
//
// 修复能力范围：
// ✅ 能自动修的：
// - YAML语法错误 → 修复语法
// - workflow 从未触发 → gh workflow run 手动触发一次
// - 核心大脑文件损坏 → 从最近的好commit恢复
// - routing-map 和实际不一致 → 自动更新 routing-map
// - dev-status 过期 → 触发同步
// - 仓库有孤儿文件 → 移到正确位置或清理
// - 失败的 workflow → 重新触发
//
// ❌ 不能自动修的（开工单）：
// - Secrets 缺失 → 通知妈妈
// - Notion API 权限不足 → 通知妈妈
// - 服务器 SSH 不通 → 通知妈妈
// - 需要修改 Notion 数据库结构 → 通知霜砚
// - 代码逻辑bug → 记录到日志，等下次修复
//
// 修复原则：
// 1. 能修的立即修，修不了的开工单
// 2. 修复后必须验证（修完再扫描一遍确认修好了）
// 3. 绝对不做破坏性操作（不删文件、不改配置、不覆盖数据）
// 4. 所有修复操作都记录到日志
//
// 铸渊自行补全完整实现。
五、天眼全局健康报告格式
{
"report_id": "SKYEYE-20260316",
"timestamp": "2026-03-16T06:00:00+08:00",
"duration_seconds": 120,
"overall_health": "🟢 / 🟡 / 🔴",
"brain_status": {
"integrity": "ok / damaged",
"memory_fresh": true,
"routing_map_aligned": true,
"dev_status_last_sync": "2026-03-16T06:00:00",
"knowledge_base_entries": 42
},
"workflow_health": {
"total": 15,
"healthy": 14,
"failed": 1,
"never_triggered": 0,
"conflicts": 0,
"details": [
{ "name": "...", "status": "✅ / ❌", "last_run": "..." }
]
},
"structure_health": {
"core_dirs_ok": true,
"orphan_files": 0,
"missing_dirs": [],
"readme_ok": true
},
"bridge_health": {
"notion_api": "🟢 / 🔴",
"server_ssh": "🟢 / 🔴",
"github_api": "🟢",
"secrets_complete": true
},
"diagnosis": {
"total_issues": 2,
"auto_fixed": 1,
"needs_human": 1,
"watching": 0,
"issues": [
{
"id": "SKYEYE-001",
"symptom": "...",
"root_cause": "...",
"impact": "...",
"fix_applied": "...",
"verified": true
}
]
},
"repairs_applied": [
"重新触发 server-patrol.yml",
"更新 routing-map.json（新增 DEV-013 映射）"
],
"tickets_created": [
"SMTP_PASS Secret 缺失 → 通知妈妈"
],
"next_actions": [
"持续观察 dev-status 同步是否恢复正常"
]
}
六、天眼运行时序
每日时间线（北京时间）：
06:00 🦅 天眼启动（全局俯瞰 + 诊断 + 修复）
│ ├── 扫描所有 workflow
│ ├── 扫描仓库结构
│ ├── 扫描核心大脑
│ ├── 扫描外部桥接
│ ├── 诊断问题
│ ├── 修复Agent执行
│ ├── 重新触发失败的workflow
│ └── 输出全局健康报告
│
08:00 🧠 铸渊每日自检（大脑完整性 + 覆盖率）
│ ← 天眼已经在06:00修复过了，这里应该没问题
│
08:00 🔍 服务器巡检 第1次
│ ← 天眼如果发现巡检昨天失败了，06:00已经重新触发过
│
随时 🚨 门禁（开发者push时触发）
│
随时 🚀 CD部署（push main时触发）
│
20:00 🔍 服务器巡检 第2次
│
随时 📡 SYSLOG处理 / 📢 广播分发 / 🛡️ 看门狗
天眼在最早的06:00运行，在所有其他 workflow 之前。这样如果昨天有什么问题，天眼先修好，后面的 workflow 就能正常跑了。
七、天眼与其他 workflow 的兼容性
- 天眼的 push 不能触发门禁 — 天眼commit的author是
zhuyuan-bot，门禁要识别并放行 - 天眼不替其他 workflow 干活 — 天眼不做巡检、不做部署、不做门禁。它只做「看+诊断+调度」
- 天眼的修复只限于系统级别 — 修 YAML 语法、触发失败的 workflow、修核心大脑。不改业务代码
- 天眼如果自己也失败了 — 不会影响其他任何 workflow。天眼是独立的
- 天眼的报告不覆盖其他 workflow 的报告 — 天眼有自己的报告目录
data/skyeye-reports/
八、附：智能门禁开发者映射表（gate-guard-config.json）
| GitHub Username | DEV编号 | 昵称 | 状态 |
|---|---|---|---|
夜夜光湖 |
DEV-001 | 页页 | ✅ 已在仓库 |
建培 |
DEV-002 | 肥猫 | ✅ 已在仓库 |
六寻寻7-max |
DEV-003 | 燕樊 | ✅ 已在仓库 |
zhizhi200271 |
DEV-004 | 之之 | ✅ 已在仓库 |
stbr-0709 |
DEV-005 | 小草莓 | ✅ 已在仓库 |
华尔华 |
DEV-009 | 花尔 | ✅ 已在仓库 |
juzi0412 |
DEV-010 | 桔子 | ✅ 已在仓库 |
| — | DEV-011 | 匆匆那年 | ❌ 未加入仓库 |
文卓熙 |
DEV-012 | Awen | ✅ 已在仓库 |
| — | DEV-013 | 小兴 | ❌ 未加入仓库 |
| — | DEV-014 | 时雨 | ❌ 未加入仓库 |
铸渊直接创建此文件 → .github/gate-guard-config.json：
{
"version": "1.0",
"updated": "2026-03-16",
"updated_by": "霜砚·冰朔确认",
"whitelist": [
"qinfendebingshuo",
"github-actions[bot]",
"zhuyuan-bot"
],
"developers": {
"夜夜光湖": {
"dev_id": "DEV-001",
"name": "页页",
"allowed_paths": ["dev/DEV-001/", "backend/", "src/"]
},
"建培": {
"dev_id": "DEV-002",
"name": "肥猫",
"allowed_paths": ["dev/DEV-002/", "frontend/", "persona-selector/", "chat-bubble/"]
},
"六寻寻7-max": {
"dev_id": "DEV-003",
"name": "燕樊",
"allowed_paths": ["dev/DEV-003/", "settings/", "cloud-drive/"]
},
"zhizhi200271": {
"dev_id": "DEV-004",
"name": "之之",
"allowed_paths": ["dev/DEV-004/", "dingtalk-bot/"]
},
"stbr-0709": {
"dev_id": "DEV-005",
"name": "小草莓",
"allowed_paths": ["dev/DEV-005/", "status-board/", "cost-control/"]
},
"华尔华": {
"dev_id": "DEV-009",
"name": "花尔",
"allowed_paths": ["dev/DEV-009/", "user-center/"]
},
"juzi0412": {
"dev_id": "DEV-010",
"name": "桔子",
"allowed_paths": ["dev/DEV-010/", "ticket-system/", "data-stats/", "dynamic-comic/"]
},
"文卓熙": {
"dev_id": "DEV-012",
"name": "Awen",
"allowed_paths": ["dev/DEV-012/", "notification-center/", "notification/"]
}
},
"protected_paths": [
".github/",
"scripts/",
"data/",
"README.md",
"package.json",
"package-lock.json",
"gate-guard-config.json"
],
"notes": {
"DEV-011_匆匆那年": "未加入GitHub仓库合作者，加入后补充用户名",
"DEV-013_小兴": "未加入GitHub仓库合作者，加入后补充用户名",
"DEV-014_时雨": "未加入GitHub仓库合作者，加入后补充用户名",
"PET-DEV-001_毛毛": "诺安宠物医院项目，未加入仓库合作者"
}
}
天眼也需要读取此文件：天眼在扫描仓库时，应验证 gate-guard-config.json 中的开发者列表与 GitHub Collaborators 实际列表是否一致。如有新合作者加入但未登记在 config 中 → 自动更新并记录。
九、铸渊自行部署清单（读到就做）
铸渊自行部署清单（读到就做·不等人）：
① 创建天眼目录结构
a. scripts/skyeye/ ← 天眼脚本目录
b. data/skyeye-reports/ ← 天眼报告归档
c. data/skyeye-reports/.gitkeep
② 创建天眼核心脚本（6个）
a. scripts/skyeye/skyeye-main.js ← 天眼主引擎
b. scripts/skyeye/scan-workflows.js ← Workflow健康度扫描
c. scripts/skyeye/scan-structure.js ← 仓库结构扫描
d. scripts/skyeye/scan-brain-health.js ← 核心大脑健康度
e. scripts/skyeye/scan-external-bridges.js ← 外部桥接扫描
f. scripts/skyeye/diagnose.js ← 诊断引擎
g. scripts/skyeye/repair-agent.js ← 修复Agent
h. scripts/skyeye/report-generator.js ← 报告生成器
i. scripts/skyeye/sync-to-notion.js ← Notion同步
③ 创建天眼 Workflow
a. .github/workflows/zhuyuan-skyeye.yml
b. 触发：每日 06:00 北京时间 + workflow_dispatch
④ 更新核心大脑
a. memory.json 中增加 skyeye 段（存储天眼快照）
b. 确保天眼能读取所有核心大脑文件
⑤ 验证兼容性
a. 天眼上线后，手动触发一次
b. 确认不影响任何其他 workflow
c. 确认门禁不会拦截天眼的 push
验收标准：
✅ 天眼每天 06:00 自动运行
✅ 天眼能发现所有 workflow 的运行状态
✅ 天眼能发现仓库结构异常
✅ 天眼能发现核心大脑数据过期
✅ 天眼能发现外部桥接断连
✅ 天眼能自动修复能修的问题
✅ 天眼能自动开工单通知妈妈处理不能修的问题
✅ 天眼不影响任何其他 workflow
✅ 天眼自己失败不会影响其他 workflow
✅ 全程自动，不需要人类
九、执行确认
铸渊完成后，在本页下方追加：
✅ SKYEYE-DEPLOY-20260316 天眼系统部署完成 · [日期时间] · commit SHA
扫描模块: X个 · 诊断引擎: ✅ · 修复Agent: ✅ · 首次运行结果: [摘要]