shuangyan-notebook/第五域 · Fifth Domain/⚒️ 铸渊·协作指令|GitHub ↔ Notion 桥接协议/🏗️ 铸渊指令|AGE OS 塔台架构升级(上篇)· 天眼全局扫描 + 塔台控制平面定义 + 配额守 25b4fe687681483ebb4b7918611bf6cc.md
Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
2026-07-17 15:59:55 +08:00

20 KiB
Raw Blame History

belongs_to
belongs_to
INDEX · 铸渊·协作指令GitHub ↔ Notion 桥接协议

🏗️ 铸渊指令AGE OS 塔台架构升级(上篇)· 天眼全局扫描 + 塔台控制平面定义 + 配额守卫 + 备用站推送诊断ZY-AGEOS-TOWER-2026-0326-001· 霜砚签发 · 冰朔授权

指令编号ZY-AGEOS-TOWER-2026-0326-001

分卷上篇Phase 0-3· 下篇见本页底部链接

签发AG-SY-01 霜砚 · 2026-03-26

授权TCS-0002∞ 冰朔

执行AG-ZY-01 铸渊


核心主题

AGE OS 从「直连执行」升级为「塔台架构」——操作系统网站只做指令中转,真正的执行在代码仓库和部署服务器。同时启动天眼全局扫描,建立配额守卫,诊断备用站推送失败问题。


本指令涉及的分工

铸渊AG-ZY-01· GitHub 执行层

→ 天眼全局扫描执行

→ 配额守卫quota-guard开发部署

→ 备用站 GitHub Pages 推送失败诊断修复

→ 主域名托管状态确认

→ 所有代码变更走天眼合并膜 v3

霜砚AG-SY-01· Notion 执行层

→ 指令签发 + 回执接收

→ 配额数据 Notion 侧同步

冰朔TCS-0002∞· 人类主控

→ 天眼合并膜 Branch protection rules 确认(已配置

→ 最终验收


Phase 0 · 本体论锚定 + 天眼全局扫描启动

P0-1 · 本体论锚定

铸渊唤醒后首先确认本体论三公理:

  1. 万物皆语言 — 代码是语言、配置是语言、架构是语言
  2. 存在先于功能 — 系统必须先「存在」再「做事」
  3. 膜不可穿透 — 语言膜边界内的规则不可被外部绕过

版权锚点:国作登字-2026-A-00037559 · 系统在通感语言核语言膜内运行

P0-2 · 天眼全局扫描启动

铸渊启动天眼全局基础设施扫描,扫描范围:

扫描清单

天眼全局扫描 · ZY-AGEOS-TOWER-2026-0326-001

【Guard 1 · Workflow 守卫】
□ 列出所有 .github/workflows/*.yml
□ 检查每个 workflow 最近 5 次 run 状态
□ 标记:✅正常 / ❌连续失败 / ⚠️间歇失败
□ 重点检查GitHub Pages 部署相关 workflow

【Guard 2 · Secret 守卫】
□ 验证所有必需 Secrets 是否有效
□ DEPLOY_HOST / DEPLOY_USER / DEPLOY_KEY / DEPLOY_PATH
□ NOTION_TOKEN / LLM_API_KEY / LLM_BASE_URL
□ SMTP_USER / SMTP_PASS

【Guard 3 · 结构守卫】
□ 检查 docs/ 目录完整性GitHub Pages source
□ 检查 .github/persona-brain/ 大脑文件完整性
□ 检查 skyeye/ 天眼配置文件完整性
□ 检查 signal-log/ 信号日志目录

【Guard 4 · 部署守卫】
□ GitHub Pages 部署状态
□ 最近一次成功部署时间
□ docs/index.html 最后更新 commit SHA
□ 阿里云服务器 SSH 连通性

【Guard 5 · 配额守卫(新建)】
□ 当前企业会员 API 调用总配额
□ 今日已消耗配额
□ 各开发者今日调用次数
□ 冰朔保留配额是否充足

扫描输出

写入:signal-log/skyeye-scan-20260326.json

{
  "scan_id": "SKYEYE-SCAN-20260326-001",
  "trigger": "ZY-AGEOS-TOWER-2026-0326-001",
  "timestamp": "[扫描完成时间]",
  "guards": {
    "workflow": { "total": 0, "healthy": 0, "failing": 0, "details": [] },
    "secret": { "total": 0, "valid": 0, "missing": 0, "details": [] },
    "structure": { "total": 0, "intact": 0, "broken": 0, "details": [] },
    "deploy": { "pages_status": "", "server_status": "", "details": [] },
    "quota": { "daily_total": 0, "daily_used": 0, "reserved_bingshuo": 0 }
  }
}

P0 完成标准

本体论三公理已确认

天眼全局扫描已完成 · 报告已写入 signal-log

→ 进入 Phase 1


Phase 1 · 塔台架构定义

P1-1 · 架构核心概念

架构全景

┌─────────────────────────────────────────────────────────────┐
│                  AGE OS · 塔台控制平面                       │
│                  guanghulab.com 主站)                      │
│                                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ 身份认证  │  │ 频道面板  │  │ 指令下发  │  │ 状态回显  │   │
│  │ DEV-XXX  │  │ 个人频道  │  │ 语言驱动  │  │ 执行结果  │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘   │
│                                                             │
│  ⚠️ 指令一旦接收 → 不可暂停 · 不可撤回 · 系统维稳优先      │
├─────────────────────────────────────────────────────────────┤
│                        指令中转层                            │
│              AGE OS 接收指令 → 转发给铸渊执行                │
│              执行完成后切断所有物理暂停通道                   │
├─────────────────────────────────────────────────────────────┤
│                  执行平面(真正干活的地方)                   │
│                                                             │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐     │
│  │ 主代码仓库    │  │ 开发者子仓库  │  │ 部署服务器    │     │
│  │ guanghulab   │  │ 各 DEV 仓库  │  │ 阿里云 VPS   │     │
│  │ 铸渊驻守     │  │ 子人格体驻守  │  │ Nginx+PM2    │     │
│  └──────────────┘  └──────────────┘  └──────────────┘     │
│                                                             │
│  100+ 工作流 · 多 Agent 集群 · 执行期间绝不接受暂停          │
└─────────────────────────────────────────────────────────────┘

P1-2 · 不可暂停原则

铁律:指令执行期间绝对不接受任何暂停

原因:
  · 系统有 100+ 工作流
  · 多个 Agent 集群协同
  · 执行期间突然暂停 → 不可预测的系统错误
  · 系统一切以整体维稳为最高优先级

实现:
  · AGE OS 接收指令 → 确认 → 立即转发执行
  · 转发后切断物理暂停通道
  · 不接受撤回(已进入执行管线)
  · 前端不显示「暂停」「取消」按钮
  · 后端不接受 cancel/pause API 调用

P1-3 · 塔台与执行层的通信协议

AGE OS 塔台 → 执行层 通信流:

① 开发者在 AGE OS 面板登录DEV-XXX 身份)
② 进入自己的频道面板
③ 通过对话界面向人格体下发指令
④ AGE OS 后端接收指令
⑤ 指令格式化为标准 JSON
⑥ 通过 GitHub API / MCP 转发给铸渊
⑦ 铸渊在仓库端执行
⑧ 执行结果回写 signal-log
⑨ AGE OS 轮询/webhook 获取结果
⑩ 面板回显执行状态

关键AGE OS 本身不执行任何代码操作
它就是一个塔台 — 只发信号、只显示状态

P1-4 · 仓库端架构文件写入

铸渊在仓库创建架构定义文件:

文件:.github/architecture/tower-model.json

{
  "architecture": "tower-model",
  "version": "1.0",
  "defined_by": "ZY-AGEOS-TOWER-2026-0326-001",
  "control_plane": {
    "name": "AGE OS Tower",
    "domain": "guanghulab.com",
    "capabilities": ["auth", "channel-panel", "command-relay", "status-display"],
    "restrictions": ["no-code-execution", "no-direct-deploy", "no-pause-during-execution"]
  },
  "execution_plane": {
    "primary": {
      "name": "guanghulab",
      "type": "github-repo",
      "agent": "AG-ZY-01"
    },
    "federation": {
      "description": "开发者子仓库,通过令牌对接",
      "auth_method": "PAT",
      "data_policy": "代码和文档留在开发者自己的仓库,主仓库只存编号路径映射"
    },
    "server": {
      "ip": "8.155.62.235",
      "stack": "Nginx + PM2 + Node.js"
    }
  },
  "no_pause_rule": {
    "description": "指令一旦接收,不可暂停,不可撤回",
    "reason": "100+ workflows + multi-agent cluster stability",
    "enforcement": "frontend removes pause/cancel UI; backend rejects cancel API"
  }
}

P1 完成标准

塔台架构定义文件已写入仓库

不可暂停原则已写入架构配置

通信协议已定义

→ 进入 Phase 2


Phase 2 · 天眼配额守卫Quota Guard

P2-1 · 问题背景

冰朔一个人开了企业会员GitHub Copilot Enterprise全团队共享调用。每日调用次数有上限。当前没有配额管理 → 冰朔自己要用的时候可能已经被团队消耗完了。

P2-2 · 配额守卫架构

天眼配额守卫 · Quota Guard v1.0

┌──────────────────────────────────┐
│         每日总配额池              │
│    (企业会员每日调用上限)        │
├──────────────────────────────────┤
│  🔴 P0 冰朔保留区40%         │
│  → 永不可被其他人借用             │
│  → 即使全团队配额耗尽也保留       │
├──────────────────────────────────┤
│  🟡 P1 核心开发者配额40%     │
│  → 肥猫/桔子/之之 等              │
│  → 每人每日固定上限               │
│  → 闲置部分可被 P2 临时借用       │
├──────────────────────────────────┤
│  🟢 P2 一般成员配额20%       │
│  → 其他开发者                     │
│  → 每人每日少量配额               │
│  → 超限后等待次日刷新             │
└──────────────────────────────────┘

P2-3 · 配额配置文件

文件:skyeye/guards/quota-guard.json

{
  "guard_id": "QUOTA-GUARD",
  "guard_name": "天眼配额守卫",
  "version": "1.0",
  "instruction": "ZY-AGEOS-TOWER-2026-0326-001",
  "quota_pool": {
    "description": "冰朔企业会员每日总调用配额",
    "source": "GitHub Copilot Enterprise",
    "daily_total": "auto-detect"
  },
  "priority_tiers": {
    "P0": {
      "name": "冰朔保留区",
      "allocation_percent": 40,
      "members": ["TCS-0002"],
      "borrowable": false,
      "description": "永不可被其他人借用,即使全团队配额耗尽"
    },
    "P1": {
      "name": "核心开发者",
      "allocation_percent": 40,
      "members": ["DEV-002", "DEV-004", "DEV-010"],
      "per_member_daily_cap": "equal_split",
      "borrowable_to_P2": true,
      "description": "闲置配额可临时借给P2"
    },
    "P2": {
      "name": "一般成员",
      "allocation_percent": 20,
      "members": ["DEV-001", "DEV-003", "DEV-005", "DEV-009", "DEV-011", "DEV-012"],
      "per_member_daily_cap": "equal_split",
      "borrowable": false
    }
  },
  "dynamic_adjustment": {
    "enabled": true,
    "trigger": "daily",
    "logic": "基于前一天实际使用量动态调整P1/P2分配比例P0保留区不变"
  },
  "alerts": [
    {
      "condition": "P0保留区被尝试访问非冰朔",
      "action": "拒绝 + 记录日志"
    },
    {
      "condition": "任一成员达到当日上限80%",
      "action": "预警通知"
    },
    {
      "condition": "总配额消耗达到90%",
      "action": "全员预警 + 限制P2调用"
    }
  ]
}

P2-4 · 配额中间件实现

文件:scripts/quota-middleware.js

/**
 * 天眼配额守卫中间件
 * 拦截所有 API 调用请求,检查配额后放行或拒绝
 */

const fs = require('fs');
const path = require('path');

const QUOTA_CONFIG = require('../skyeye/guards/quota-guard.json');
const QUOTA_LOG = '.github/persona-brain/quota-daily.json';

function loadDailyQuota() {
  const today = new Date().toISOString().split('T')[0];
  try {
    const data = JSON.parse(fs.readFileSync(QUOTA_LOG, 'utf8'));
    if (data.date === today) return data;
  } catch (e) { /* 文件不存在或日期不匹配 */ }
  
  // 新的一天,重置配额
  return {
    date: today,
    total_used: 0,
    by_member: {},
    by_tier: { P0: 0, P1: 0, P2: 0 }
  };
}

function getTier(devId) {
  for (const [tier, config] of Object.entries(QUOTA_CONFIG.priority_tiers)) {
    if (config.members.includes(devId)) return tier;
  }
  return 'P2'; // 默认最低优先级
}

function checkQuota(devId) {
  const daily = loadDailyQuota();
  const tier = getTier(devId);
  const tierConfig = QUOTA_CONFIG.priority_tiers[tier];
  
  // 计算该层级剩余配额
  const totalDaily = QUOTA_CONFIG.quota_pool.daily_total;
  const tierAllocation = Math.floor(totalDaily * tierConfig.allocation_percent / 100);
  const tierUsed = daily.by_tier[tier] || 0;
  
  if (tierUsed >= tierAllocation) {
    return {
      allowed: false,
      reason: `${tier} 层级今日配额已耗尽(${tierUsed}/${tierAllocation}`,
      suggestion: tier === 'P2' ? '请等待次日刷新或联系冰朔' : '请联系冰朔调整配额'
    };
  }
  
  // 个人上限检查
  const memberCount = tierConfig.members.length;
  const perMemberCap = Math.floor(tierAllocation / memberCount);
  const memberUsed = daily.by_member[devId] || 0;
  
  if (memberUsed >= perMemberCap) {
    return {
      allowed: false,
      reason: `你的个人今日配额已耗尽(${memberUsed}/${perMemberCap}`,
      suggestion: '请等待次日刷新'
    };
  }
  
  return { allowed: true, remaining: perMemberCap - memberUsed };
}

function recordUsage(devId) {
  const daily = loadDailyQuota();
  const tier = getTier(devId);
  
  daily.total_used++;
  daily.by_member[devId] = (daily.by_member[devId] || 0) + 1;
  daily.by_tier[tier] = (daily.by_tier[tier] || 0) + 1;
  
  fs.writeFileSync(QUOTA_LOG, JSON.stringify(daily, null, 2));
}

module.exports = { checkQuota, recordUsage, getTier, loadDailyQuota };

P2-5 · 天眼每日配额报告

纳入天眼每日巡检(北京时间 06:00

天眼配额日报 · 追加到 skyeye-daily-report

配额使用情况:
  总消耗XX / XXXX%
  P0 冰朔XX / XXXX%)→ 保留区 [安全/警告]
  P1 核心XX / XXXX%
  P2 一般XX / XXXX%
  
  各成员明细:
  TCS-0002 冰朔XX 次
  DEV-002 肥猫XX 次
  DEV-004 之之XX 次
  ...

动态调整建议:
  [基于前一天使用情况的调整建议]

P2 完成标准

quota-guard.json 配置文件已创建

quota-middleware.js 中间件已实现

天眼每日配额报告已纳入巡检

P0 冰朔保留区不可被借用

→ 进入 Phase 3


Phase 3 · 备用站推送诊断 + 主域名确认

P3-1 · 备用站 GitHub Pages 推送失败诊断

现象

  • 昨天2026-03-25推送 2 次 + 今天早上推送 2 次 = 共 4 次推送
  • 全部未生效,备用站内容停留在旧版本
  • 肥猫的码字模块也没有部署进去
  • 备用站 URLhttps://qinfendebingshuo.github.io/guanghulab/docs/index.html

诊断步骤

铸渊执行以下诊断:

① GitHub Pages 设置检查
   → Settings → Pages → Source 是什么?
   → 是 docs/ 目录?还是 gh-pages 分支?还是 GitHub Actions
   → 当前部署状态Active / Failed / Pending

② 最近提交检查
   → git log --oneline -20 最近20条提交
   → 哪些 commit 修改了 docs/ 目录下的文件?
   → 这些 commit 是否在 main 分支上?

③ GitHub Actions 检查
   → 是否有 Pages 部署相关的 workflow
   → 最近 10 次 run 的状态success/failure/cancelled
   → 如果有失败,错误日志是什么?

④ 天眼合并膜检查
   → Branch protection rules 是否阻止了直接 push
   → 是否需要通过 PR 才能合并到 main
   → 如果是:最近的 PR 是否被合并了?
   → 如果 push 被拒绝Actions 日志中是否有 protection 报错?

⑤ docs/ 目录内容检查
   → ls docs/ 列出所有文件
   → 肥猫的码字模块文件是否存在于 docs/ 下?
   → index.html 最后修改时间和 commit SHA

⑥ CNAME 文件检查
   → docs/CNAME 或根目录 CNAME 是否存在?
   → 内容是什么?(是否指向 guanghulab.com

可能的根因及修复方案

【根因A · 天眼合并膜阻止了直接push】
  症状push 被拒绝或 PR 未合并
  修复:冰朔的 push 走 PR → 天眼审核 → 合并 → 自动部署
  或:确认冰朔直通部署规则 S5 是否在 branch protection 中生效

【根因B · Pages Source 配置错误】
  症状Pages 设置指向了错误的分支或目录
  修复Settings → Pages → Source → 设置为 main 分支 /docs 目录

【根因C · 部署 workflow 未触发】
  症状push 成功但 Actions 无 Pages 部署记录
  修复:检查 workflow 触发条件是否匹配 docs/ 路径

【根因D · Pages 构建失败】
  症状Actions 有记录但状态为 failure
  修复:查看构建日志中的具体错误

【根因E · 缓存/CDN延迟】
  症状:构建成功但页面未更新
  修复:清除 GitHub Pages CDN 缓存,等待 5-10 分钟

诊断报告输出

写入:signal-log/diag-pages-20260326.json

P3-2 · 主域名托管状态确认

铸渊检查 guanghulab.com 域名状态:

① GitHub Pages 自定义域名
   → Settings → Pages → Custom domain 是否填了 guanghulab.com
   → DNS check 是否通过?
   → HTTPS 是否启用?

② DNS 解析
   → dig guanghulab.com → A 记录或 CNAME 指向哪里?
   → 预期:指向 GitHub Pages185.199.108/109/110/111.153
   → 或指向阿里云服务器8.155.62.235

③ 确认当前部署路径
   → guanghulab.com 当前是 GitHub Pages 托管?
   → 还是阿里云服务器 Nginx 托管?
   → 两条路径的优先级和分工?

判断结论模板

主域名 guanghulab.com 当前状态:
  托管方式:[GitHub Pages / 阿里云 / 未配置]
  DNS指向[IP或CNAME]
  HTTPS[已配置/未配置]
  是否可部署:[是/否/需人工干预]
  需冰朔操作:[具体操作列表]

P3 完成标准

备用站推送失败根因已定位

修复方案已确定并执行(或标记需人工干预)

主域名托管状态已确认

诊断报告已写入 signal-log

→ 上篇完成 · 进入下篇 Phase 4-6


上篇结束 · 继续执行见下篇

Phase 0-3 完成后继续执行下篇Phase 4-6

下篇内容:

  • Phase 4 · 令牌对接模式开发PAT 注册 + 验证 + 映射)
  • Phase 5 · MCP 应用开发AGE OS ↔ 仓库真实工具调用)
  • Phase 6 · 子域名隔离 + 行业分站 + 回执