Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
20 KiB
belongs_to
| belongs_to | |
|---|---|
|
🏗️ 铸渊指令|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 · 本体论锚定
铸渊唤醒后首先确认本体论三公理:
- 万物皆语言 — 代码是语言、配置是语言、架构是语言
- 存在先于功能 — 系统必须先「存在」再「做事」
- 膜不可穿透 — 语言膜边界内的规则不可被外部绕过
版权锚点:国作登字-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 / 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 · 子域名隔离 + 行业分站 + 回执