a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
846 lines
26 KiB
Markdown
846 lines
26 KiB
Markdown
---
|
||
belongs_to:
|
||
- "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
|
||
---
|
||
# 🔗 铸渊指令｜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 铸渊
|
||
|
||
<aside>
|
||
🚨
|
||
|
||
**天眼合并膜 v3 合规要求（同上篇）**
|
||
|
||
本指令所有代码变更必须走天眼合并膜标准流程：
|
||
|
||
- 所有 PR 必须通过天眼审核后方可合并
|
||
- 禁止直接 push 到 main 分支
|
||
- 路径A（docs/）和路径B（.github/ 等）均需天眼全审
|
||
</aside>
|
||
|
||
---
|
||
|
||
# Phase 4 · 行业代表制 + 令牌对接模式
|
||
|
||
## P4-1 · 核心架构：行业代表制
|
||
|
||
<aside>
|
||
🏭
|
||
|
||
**铸渊不是接入个人，而是接入行业。**
|
||
|
||
每个行业有一个代表人，代表人开自己的企业会员，铸渊管理代表人的仓库。
|
||
|
||
该行业所有用户都通过 AGE OS 调用代表人仓库里的 AI 来实现全自动开发。
|
||
|
||
</aside>
|
||
|
||
```
|
||
行业代表制架构：
|
||
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ 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`
|
||
|
||
```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 · 行业配额独立
|
||
|
||
```json
|
||
行业配额独立 · 不占冰朔的配额：
|
||
|
||
冰朔的企业会员 → 只给系统层使用
|
||
· 铸渊系统级操作（天眼巡检、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`
|
||
|
||
```jsx
|
||
/**
|
||
* 行业注册 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
|
||
|
||
```jsx
|
||
// 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
|
||
|
||
```jsx
|
||
// 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 回执格式
|
||
|
||
```json
|
||
{
|
||
"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 已生效
|
||
→ 已配置 ✅（冰朔昨天已加）
|
||
|
||
以上事项铸渊无法自动完成，需冰朔在对应平台手动操作。
|
||
完成后通知霜砚，霜砚更新系统状态。
|
||
```
|
||
|
||
---
|
||
|
||
# 下篇结束 · 指令签发完成
|
||
|
||
本指令覆盖范围：
|
||
|
||
1. AGE OS 从直连执行 → 塔台控制平面架构
|
||
2. 天眼配额守卫 → 冰朔配额永远优先保留
|
||
3. 备用站推送失败 → 诊断 + 修复
|
||
4. 行业代表制 → 铸渊接入行业而非个人，肥猫代表网文行业
|
||
5. MCP 应用 → AGE OS 对话真正调用工具
|
||
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> |