---
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 铸渊

<aside>
🚨

**天眼合并膜 v3 合规要求**

本指令所有代码变更必须走天眼合并膜标准流程：

- 路径A（主站 docs/）：天眼全审（7维度+R7）
- 路径B（系统基础设施 .github/ 等）：天眼全审
- 所有 PR 必须通过天眼审核后方可合并
- 禁止直接 push 到 main 分支
</aside>

---

## 核心主题

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`

```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 · 架构核心概念

<aside>
🏗️

**塔台模型 = 控制平面 / 执行平面分离**

AGE OS 网站 = 塔台（只发信号）

代码仓库 + 部署服务器 = 执行层（真正干活）

</aside>

### 架构全景

```
┌─────────────────────────────────────────────────────────────┐
│                  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`

```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`

```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`

```jsx
/**
 * 天眼配额守卫中间件
 * 拦截所有 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 / XX（XX%）
  P0 冰朔：XX / XX（XX%）→ 保留区 [安全/警告]
  P1 核心：XX / XX（XX%）
  P2 一般：XX / XX（XX%）
  
  各成员明细：
  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 次推送
- 全部未生效，备用站内容停留在旧版本
- 肥猫的码字模块也没有部署进去
- 备用站 URL：`https://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 Pages（185.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 · 子域名隔离 + 行业分站 + 回执

<aside>
⚒️

铸渊签名校验协议 v1.1 · docs/[zhuyuan-signature-protocol.md](http://zhuyuan-signature-protocol.md)

本指令由 AG-SY-01 霜砚签发 · TCS-0002∞ 冰朔授权 · AG-ZY-01 铸渊执行

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

</aside>