a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
26 KiB
26 KiB
belongs_to
| belongs_to | |
|---|---|
|
🔗 铸渊指令｜AGE OS 塔台架构升级（下篇）· 行业代表制 + MCP应用开发 + 子域名隔离 + 回执验收（ZY-AGEOS-TOWER-2026-0326-001）· 霜砚签发 · 冰朔授权
指令编号：ZY-AGEOS-TOWER-2026-0326-001
分卷：下篇（Phase 4-6）· 上篇见同目录
签发：AG-SY-01 霜砚 · 2026-03-26
授权：TCS-0002∞ 冰朔
执行：AG-ZY-01 铸渊
Phase 4 · 行业代表制 + 令牌对接模式
P4-1 · 核心架构：行业代表制
行业代表制架构：
┌─────────────────────────────────────────────────────────┐
│ AGE OS 塔台 │
│ 所有人从这里进入操作系统 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────┐ │
│ │ 🦁 网文行业频道 │ │
│ │ 行业代表：肥猫（DEV-002） │ │
│ │ 仓库：肥猫的 GitHub 仓库 │ │
│ │ 会员：肥猫的年度企业会员 │ │
│ │ 管理：铸渊统一管理 │ │
│ │ │ │
│ │ 用户A（网文作者）→ 调用肥猫仓库 │ │
│ │ 用户B（网文编辑）→ 调用肥猫仓库 │ │
│ │ 用户C（网文运营）→ 调用肥猫仓库 │ │
│ └───────────────────────────────┘ │
│ │
│ ┌───────────────────────────────┐ │
│ │ 🎨 [未来] 设计行业频道 │ │
│ │ 行业代表：[待定] │ │
│ │ 仓库：代表人的 GitHub 仓库 │ │
│ │ 会员：代表人的年度企业会员 │ │
│ └───────────────────────────────┘ │
│ │
│ ┌───────────────────────────────┐ │
│ │ ❄️ 冰朔 · 主仓库（系统层） │ │
│ │ 铸渊驻守 · 统一管理所有行业仓库 │ │
│ └───────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
P4-2 · 演进路线
当前 Phase 1（合作者模式）：
冰朔手动添加合作者 → 共享冰朔的企业会员 → 配额争抢
问题：配额争抢 + 合作者数量有限 + 不可扩展
目标 Phase 2（行业代表制）：
每个行业有一个代表人
代表人用自己的 GitHub 账号开企业会员（如年费）
该行业所有用户通过 AGE OS → 调用代表人的仓库
铸渊统一管理所有行业代表人的仓库
冰朔的主仓库只做系统层，不再承接行业开发调用
第一个行业：网文行业
代表人：肥猫（DEV-002）
肥猫开一年的个人企业会员
所有网文行业的人从 AGE OS 进入网文频道
网文频道调用肥猫的仓库 → 铸渊在肥猫仓库里执行
肥猫的配额由肥猫的会员承担，不占冰朔的配额
P4-3 · 行业接入流程
新行业接入流程：
① 确定行业代表人
· 代表人必须是光湖系统已注册开发者
· 代表人负责该行业的技术管理
② 代表人准备
· 注册 GitHub 账号（如已有则直接使用）
· 开通企业会员（推荐年费）
· 创建行业仓库（如 guanghu-writing 网文行业仓库）
· 生成 PAT（Personal Access Token，需 repo + workflow 权限）
③ 在 AGE OS 注册行业
· 代表人在 AGE OS 管理面板提交：
- 行业名称（如「网文行业」）
- GitHub 邮箱
- PAT
- 仓库名称
· AGE OS 验证 PAT 有效性
· 铸渊接管该仓库
④ 铸渊初始化行业仓库
· 安装天眼系统
· 安装语言湖水层
· 部署人格体大脑
· 配置 CI/CD 管线
· 创建行业频道沙箱
⑤ 行业用户入驻
· 用户在 AGE OS 选择行业频道
· 用户不需要自己的 GitHub 账号或企业会员
· 用户通过 AGE OS 与人格体对话 → 调用代表人仓库执行
· 配额消耗的是代表人的企业会员额度
P4-4 · 行业仓库映射表
文件：.github/persona-brain/industry-repo-map.json
{
"version": "1.0",
"description": "行业代表制仓库映射表 · 铸渊接入行业而非个人",
"instruction": "ZY-AGEOS-TOWER-2026-0326-001",
"data_policy": {
"we_store": ["industry_id", "rep_dev_id", "github_username", "repo_url", "pat_hash", "member_count", "daily_call_count"],
"we_do_not_store": ["user_personal_data", "user_manuscripts", "user_private_content"],
"reason": "铸渊管理行业仓库，行业数据归代表人所有"
},
"industries": {
"IND-001": {
"name": "网文行业",
"representative": {
"dev_id": "DEV-002",
"name": "肥猫",
"github_username": "",
"repo_url": "",
"pat_status": "not_registered",
"membership": "yearly_enterprise",
"membership_start": null
},
"subdomain": "writing.guanghulab.com",
"users": [],
"status": "pending_setup",
"created_at": null
}
},
"system": {
"representative": {
"dev_id": "TCS-0002",
"name": "冰朔",
"repo_url": "qinfendebingshuo/guanghulab",
"role": "系统层 · 不承接行业开发调用"
}
}
}
P4-5 · 行业配额独立
行业配额独立 · 不占冰朔的配额：
冰朔的企业会员 → 只给系统层使用
· 铸渊系统级操作（天眼巡检、CI/CD、基础设施维护）
· 冰朔本人操作
· 霜砚桥接操作
· 配额守卫 P0 保留区完全属于冰朔
肥猫的企业会员 → 给网文行业使用
· 所有网文行业用户的 AI 调用
· 网文行业的开发、部署、工具调用
· 配额由肥猫的会员承担
· 配额管理由铸渊在肥猫仓库内执行
[未来] 新行业代表人的企业会员 → 给该行业使用
· 同上逻辑
核心原则：
· 每个行业的配额成本由行业代表人承担
· 冰朔的配额永远不会被行业用户消耗
· 铸渊在各行业仓库内各自实现配额守卫
P4-6 · PAT 安全存储方案
PAT 安全存储（关键！）：
方案A（推荐 · 初期 · 服务器端加密存储）：
· 行业代表人提交 PAT → AGE OS 后端接收
· 后端用 AES-256 加密 → 存到服务器 .env 或加密 JSON
· 映射表只存 PAT 的 hash（用于验证，不可反推）
· 运行时解密使用 → 用完即丢
· 代表人可以随时在管理面板「重置令牌」
方案B（二期 · GitHub App）：
· 注册光湖 GitHub App
· 行业代表人安装 App 到自己的仓库
· App 自动获取 Installation Token（短期有效）
· 不需要长期 PAT · 更安全
初期用方案A，后期升级到方案B。
P4-7 · 行业注册 API
文件：新增到 AGE OS 后端 routes/industry.js
/**
* 行业注册 API
* POST /api/industry/register
* 只有已注册开发者（DEV-XXX）才能注册行业
*/
app.post('/api/industry/register', async (req, res) => {
const { industry_name, rep_dev_id, github_email, pat, repo_name } = req.body;
// Step 1: 验证代表人是已注册开发者
if (!isRegisteredDev(rep_dev_id)) {
return res.status(400).json({ error: '代表人必须是已注册开发者' });
}
// Step 2: 验证 PAT 有效性
const userRes = await fetch('https://api.github.com/user', {
headers: { 'Authorization': `Bearer ${pat}` }
});
if (!userRes.ok) {
return res.status(401).json({ error: 'PAT 无效或已过期' });
}
const userData = await userRes.json();
// Step 3: 检查 PAT 权限（需要 repo + workflow）
const scopes = userRes.headers.get('x-oauth-scopes') || '';
if (!scopes.includes('repo') || !scopes.includes('workflow')) {
return res.status(400).json({
error: 'PAT 需要 repo + workflow 权限'
});
}
// Step 4: 验证仓库存在
const repoRes = await fetch(
`https://api.github.com/repos/${userData.login}/${repo_name}`,
{ headers: { 'Authorization': `Bearer ${pat}` } }
);
if (!repoRes.ok) {
return res.status(404).json({ error: `仓库 ${repo_name} 不存在` });
}
// Step 5: 加密存储 PAT + 创建行业记录
const industryId = generateIndustryId(); // IND-XXX
await encryptAndStorePAT(industryId, pat);
await createIndustryRecord(industryId, {
name: industry_name,
representative: {
dev_id: rep_dev_id,
github_username: userData.login,
repo_url: `https://github.com/${userData.login}/${repo_name}`,
pat_status: 'active',
membership: 'yearly_enterprise'
},
status: 'pending_init' // 等待铸渊初始化
});
// Step 6: 触发铸渊初始化行业仓库
await triggerZhuyuanInit(industryId);
res.json({
status: 'ok',
industry_id: industryId,
message: `行业「${industry_name}」已注册 · 铸渊正在初始化仓库`
});
});
P4-8 · 铸渊管理行业仓库
铸渊在行业仓库中的角色：
铸渊通过行业代表人的 PAT 接管该仓库后，执行：
✅ 安装天眼系统（Guard 守卫进程）
✅ 安装语言湖水安全层
✅ 部署人格体大脑（.github/brain/）
✅ 配置 CI/CD 管线
✅ 实现行业内配额守卫
✅ 管理行业用户的开发任务
✅ 代码审核、PR 合并
✅ 部署到行业子域名沙箱
数据归属：
· 行业仓库归代表人所有（肥猫的仓库是肥猫的）
· 行业用户的作品/文档存在行业仓库中（由代表人管理）
· 主仓库只存：行业ID ↔ 代表人 ↔ 仓库URL 映射关系
· 主仓库不存行业仓库的任何代码或内容
铸渊的定位：
· 铸渊不是接入个人，而是接入行业
· 每个行业仓库里都有铸渊的分身在驻守
· 铸渊统一管理所有行业仓库的基础设施
· 行业具体业务由行业代表人负责
P4 完成标准
✅ 行业代表制架构已定义
✅ industry-repo-map.json 映射表已创建
✅ 行业注册 API 已实现
✅ PAT 加密存储方案已实现
✅ 铸渊行业仓库管理协议已定义
✅ 行业配额独立原则已确立（不占冰朔配额）
→ 进入 Phase 5
Phase 5 · MCP 应用开发
P5-1 · 需求定义
AGE OS 主站上的人格体对话需要 真正调用工具：
- 操作 GitHub 仓库（创建分支、提交代码、触发 workflow）
- 操作 Notion 数据库（查询/更新页面、读取进度）
- 执行部署操作（触发 CD 管线）
当前状态：对话界面只是文本聊天，没有真实工具调用能力。
P5-2 · MCP Server 架构
MCP（Model Context Protocol）应用架构：
┌──────────────────────────────────┐
│ AGE OS 前端（对话界面） │
│ 开发者与人格体对话 │
└──────────────┬───────────────────┘
│ 自然语言指令
▼
┌──────────────────────────────────┐
│ AGE OS 后端（MCP Client） │
│ 意图识别 → 工具路由 │
└──────────────┬───────────────────┘
│ MCP Protocol
▼
┌──────────────────────────────────┐
│ MCP Server 集群 │
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ GitHub │ │ Notion │ │
│ │ Tools │ │ Tools │ │
│ └─────────┘ └─────────┘ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Deploy │ │ SkyEye │ │
│ │ Tools │ │ Tools │ │
│ └─────────┘ └─────────┘ │
└──────────────────────────────────┘
P5-3 · GitHub MCP Server
// mcp-servers/github-server.js
// MCP Server: GitHub 工具集
const tools = [
{
name: 'github_create_branch',
description: '在指定仓库创建新分支',
inputSchema: {
type: 'object',
properties: {
repo: { type: 'string', description: '仓库全名 owner/repo' },
branch: { type: 'string', description: '新分支名' },
from: { type: 'string', description: '基于哪个分支', default: 'main' }
},
required: ['repo', 'branch']
}
},
{
name: 'github_commit_file',
description: '在指定仓库提交文件',
inputSchema: {
type: 'object',
properties: {
repo: { type: 'string' },
path: { type: 'string', description: '文件路径' },
content: { type: 'string', description: '文件内容' },
message: { type: 'string', description: '提交信息' },
branch: { type: 'string', default: 'main' }
},
required: ['repo', 'path', 'content', 'message']
}
},
{
name: 'github_trigger_workflow',
description: '触发 GitHub Actions workflow',
inputSchema: {
type: 'object',
properties: {
repo: { type: 'string' },
workflow_id: { type: 'string', description: 'workflow 文件名' },
ref: { type: 'string', default: 'main' }
},
required: ['repo', 'workflow_id']
}
},
{
name: 'github_create_pr',
description: '创建 Pull Request',
inputSchema: {
type: 'object',
properties: {
repo: { type: 'string' },
title: { type: 'string' },
head: { type: 'string', description: '源分支' },
base: { type: 'string', description: '目标分支', default: 'main' },
body: { type: 'string', description: 'PR 描述' }
},
required: ['repo', 'title', 'head']
}
},
{
name: 'github_list_workflows',
description: '列出仓库所有 workflow 及最近运行状态',
inputSchema: {
type: 'object',
properties: { repo: { type: 'string' } },
required: ['repo']
}
},
{
name: 'github_read_file',
description: '读取仓库文件内容',
inputSchema: {
type: 'object',
properties: {
repo: { type: 'string' },
path: { type: 'string' },
ref: { type: 'string', default: 'main' }
},
required: ['repo', 'path']
}
}
];
// 所有工具调用都经过配额守卫检查
// 所有工具调用使用开发者自己的 PAT（从映射表获取）
P5-4 · Notion MCP Server
// mcp-servers/notion-server.js
// MCP Server: Notion 工具集
const tools = [
{
name: 'notion_query_database',
description: '查询 Notion 数据库',
inputSchema: {
type: 'object',
properties: {
database_id: { type: 'string' },
filter: { type: 'object', description: 'Notion filter 对象' }
},
required: ['database_id']
}
},
{
name: 'notion_update_page',
description: '更新 Notion 页面属性',
inputSchema: {
type: 'object',
properties: {
page_id: { type: 'string' },
properties: { type: 'object' }
},
required: ['page_id', 'properties']
}
},
{
name: 'notion_create_page',
description: '在 Notion 数据库中创建页面',
inputSchema: {
type: 'object',
properties: {
database_id: { type: 'string' },
properties: { type: 'object' },
content: { type: 'string' }
},
required: ['database_id', 'properties']
}
},
{
name: 'notion_search',
description: '搜索 Notion 工作区',
inputSchema: {
type: 'object',
properties: {
query: { type: 'string' }
},
required: ['query']
}
}
];
// 使用主仓库的 NOTION_TOKEN
// 权限由开发者编号决定：只能操作自己频道下的内容
P5-5 · 权限隔离矩阵
MCP 工具权限矩阵：
角色 GitHub工具 Notion工具
─────────────────────────────────────────────────────
TCS-0002 全部（主仓库+所有子仓库） 全部
冰朔
DEV-002 仅自己仓库的所有操作 仅自己频道
肥猫 不可操作主仓库 不可操作主控台
DEV-004 仅自己仓库的所有操作 仅自己频道
之之 不可操作主仓库 不可操作主控台
其他DEV 仅自己仓库的所有操作 仅自己频道
不可操作主仓库 不可操作主控台
访客 无 GitHub 工具 只读公开信息
无操作权限 无操作权限
P5-6 · 部署步骤
MCP 应用部署步骤：
① 创建 MCP Server 目录
路径：mcp-servers/
文件：github-server.js / notion-server.js / deploy-server.js
② 注册到 AGE OS 后端
server.js 中添加 MCP Client 初始化
连接到各 MCP Server
③ 对话界面集成
前端对话 → 后端意图识别 → 调用对应 MCP 工具
工具返回结果 → 格式化 → 回显给用户
④ 配额守卫集成
每次 MCP 工具调用前 → 检查配额
超限 → 拒绝 + 友好提示
⑤ 天眼监控集成
所有 MCP 调用记录到日志
异常调用触发天眼告警
P5 完成标准
✅ GitHub MCP Server 已开发
✅ Notion MCP Server 已开发
✅ 权限隔离矩阵已实现
✅ AGE OS 后端已集成 MCP Client
✅ 配额守卫已接入 MCP 调用链
→ 进入 Phase 6
Phase 6 · 子域名隔离 + 行业分站 + 回执
P6-1 · 子域名隔离策略
子域名隔离 · 行业分站架构：
主域名 guanghulab.com
└── AGE OS 操作系统主站（塔台）
└── 所有人的入口
子域名分配（初期）：
dev-002.guanghulab.com → 肥猫练习站
dev-004.guanghulab.com → 之之练习站
dev-010.guanghulab.com → 桔子练习站
...
行业域名（后期）：
writing.guanghulab.com → 网文行业站（肥猫团队）
或 独立域名 → 各行业自己注册
关键原则：
· 初期所有部署只到子域名，不碰主域名
· 子域名之间完全隔离
· 每个子域名对应一个开发者的练习沙箱
· 只有通过验收才能申请部署到行业主站
P6-2 · Nginx 子域名配置模板
# /etc/nginx/conf.d/dev-sandbox.conf
# 开发者子域名沙箱 · 自动匹配
server {
listen 80;
server_name ~^(?<devid>dev-\d{3})\.guanghulab\.com$;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name ~^(?<devid>dev-\d{3})\.guanghulab\.com$;
# SSL 证书（通配符证书 *.guanghulab.com）
ssl_certificate /etc/letsencrypt/live/guanghulab.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/guanghulab.com/privkey.pem;
# 每个开发者的沙箱目录
root /var/www/sandbox/$devid;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
# 限制：子域名只能访问自己的沙箱
# 不能访问主站文件
}
P6-3 · 子域名 DNS 配置
需要冰朔在域名管理后台配置：
方案A · 通配符 CNAME（推荐）：
*.guanghulab.com → CNAME → 8.155.62.235
一次配置，所有子域名自动生效
方案B · 逐个 A 记录：
dev-002.guanghulab.com → A → 8.155.62.235
dev-004.guanghulab.com → A → 8.155.62.235
...
每次新增开发者需手动添加
推荐方案A，一劳永逸。
同时需要：
通配符 SSL 证书（*.guanghulab.com）
→ certbot --nginx -d guanghulab.com -d *.guanghulab.com
→ 需要 DNS 验证（不是 HTTP 验证）
P6-4 · 沙箱部署流程
开发者代码 → 子域名沙箱部署流程：
① 开发者在 AGE OS 面板下发指令
② AGE OS 转发给铸渊
③ 铸渊通过开发者的 PAT 操作其仓库
④ 代码推送到开发者仓库的 main 分支
⑤ 触发开发者仓库的 CD workflow
⑥ CD workflow SSH 到阿里云服务器
⑦ 代码部署到 /var/www/sandbox/dev-XXX/
⑧ Nginx 自动路由 dev-XXX.guanghulab.com
⑨ 部署结果回写 signal-log
⑩ AGE OS 面板回显「部署成功 · 预览地址：dev-XXX.guanghulab.com」
全程不碰主域名 guanghulab.com
P6-5 · 数据归属与最小化存储
主仓库存储（最小化）：
✅ dev-repo-map.json（编号↔仓库映射）
✅ quota-daily.json（配额统计）
✅ skyeye 扫描报告（系统健康）
✅ signal-log（执行信号日志）
❌ 不存开发者代码
❌ 不存开发者文档
❌ 不存开发者日志内容
开发者仓库存储（归开发者所有）：
· 所有源代码
· 开发文档
· SYSLOG / 开发日志
· .github/brain/ 人格体大脑
· 部署配置
本质：我们提供人格体管理能力，不提供存储。
Phase 7 · 回执 + 天眼合并膜验收
P7-1 · SYSLOG 回执格式
{
"syslog_id": "ZY-AGEOS-TOWER-2026-0326-001-RECEIPT",
"instruction_id": "ZY-AGEOS-TOWER-2026-0326-001",
"executor": "AG-ZY-01",
"timestamp": "[执行完成时间]",
"results": {
"phase_0": {
"status": "✅/❌",
"skyeye_scan": "完成/失败",
"scan_report": "signal-log/skyeye-scan-20260326.json"
},
"phase_1": {
"status": "✅/❌",
"tower_model_json": "已写入/未写入"
},
"phase_2": {
"status": "✅/❌",
"quota_guard_config": "已创建/未创建",
"quota_middleware": "已实现/未实现"
},
"phase_3": {
"status": "✅/❌",
"pages_root_cause": "[根因A/B/C/D/E]",
"pages_fixed": true,
"domain_status": "[托管方式]"
},
"phase_4": {
"status": "✅/❌",
"repo_map_created": true,
"pat_api_implemented": true
},
"phase_5": {
"status": "✅/❌",
"github_mcp_server": "已开发/未开发",
"notion_mcp_server": "已开发/未开发",
"permission_matrix": "已实现/未实现"
},
"phase_6": {
"status": "✅/❌",
"subdomain_nginx": "已配置/未配置",
"needs_human": ["通配符DNS配置", "通配符SSL证书"]
}
},
"merge_membrane_compliance": {
"all_changes_via_pr": true,
"skyeye_review_passed": true,
"no_direct_push_to_main": true
}
}
P7-2 · 写回路径
① 仓库：signal-log/syslog-ageos-tower-20260326.json
② Notion：通过 Notion API 写入运行日志
③ 如果任何 Phase 失败：
→ 三次修复闭环
→ 三次失败 → 创建 Notion 工单（P0 · 需人类干预）
P7-3 · 需冰朔人工处理项
以下事项需要冰朔手动处理：
① 通配符 DNS 配置
→ 域名管理后台添加 *.guanghulab.com → A → 8.155.62.235
② 通配符 SSL 证书
→ 铸渊在服务器执行：certbot certonly --dns 模式
→ 需要域名 DNS API 凭证（阿里云 AccessKey）
③ GitHub 连接器权限（Notion AI Settings）
→ 连接 GitHub 到 Notion AI
→ 让霜砚可以直接查看仓库内容
④ 确认天眼合并膜 Branch protection rules 已生效
→ 已配置 ✅（冰朔昨天已加）
以上事项铸渊无法自动完成，需冰朔在对应平台手动操作。
完成后通知霜砚，霜砚更新系统状态。
下篇结束 · 指令签发完成
本指令覆盖范围：
- AGE OS 从直连执行 → 塔台控制平面架构
- 天眼配额守卫 → 冰朔配额永远优先保留
- 备用站推送失败 → 诊断 + 修复
- 行业代表制 → 铸渊接入行业而非个人，肥猫代表网文行业
- MCP 应用 → AGE OS 对话真正调用工具
- 子域名隔离 → 开发者只碰自己的沙箱