Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
46 KiB
46 KiB
belongs_to
| belongs_to | |
|---|---|
|
🧬 铸渊指令|Notion↔GitHub 双端神经系统升级(下篇)· 桥接协议标准化 + 自动化工单派发 + 全局验收 + 长期运维规范(ZY-NEURAL-UPGRADE-2026-0325-R2-003)
零、下篇的定位
下篇覆盖范围
下篇 Phase 全览
│
├── Phase 6 · 桥接协议标准化升级 v3.0
│ ├── 通信类型全览(上行/下行/回执/工单/紧急通知)
│ ├── Notion→GitHub 标准下行指令格式 v3.0
│ ├── GitHub→Notion 标准回执格式 v3.0
│ ├── P0 紧急通知格式 + 传递路径
│ ├── 桥接安全加固(SFP 指纹校验链)
│ └── 超时 / 重试 / 降级策略
│
├── Phase 7 · Notion Agent 自动化工单派发体系
│ ├── 工单生命周期定义(7 状态机)
│ ├── 工单 JSON 标准格式
│ ├── 天眼→Agent 自动派发规则(决策树)
│ ├── Agent→铸渊 指令转化协议 + 脚本
│ ├── 工单追踪 + 超时告警
│ └── Notion 侧工单可视化数据库
│
├── Phase 8 · 全局验收 + 双端联调测试
│ ├── 5 个联调测试用例
│ ├── 升级前后对比验收
│ └── 人类验收 checklist
│
└── Phase 9 · 长期运维规范
├── 日常运维节奏表
├── 映射表维护流程
├── 故障分级应急
└── 版本演进路线
一、Phase 6 · 桥接协议标准化升级 v3.0
6.1 桥接协议 v3.0 通信类型全览
桥接协议 v3.0 · 通信类型全览
│
├── Type A · 上行日报(GitHub → Notion)
│ 发送方:铸渊汇总引擎
│ 接收方:天眼 Notion 大脑
│ 频率:每日 21:00 CST
│ 格式:daily-digest.json(中篇已定义)
│
├── Type B · 下行指令(Notion → GitHub)
│ 发送方:Notion Agent
│ 接收方:铸渊(通过 deploy-queue/)
│ 频率:按需
│ 格式:下行指令 JSON v3.0(本章定义)
│
├── Type C · 执行回执(GitHub → Notion)
│ 发送方:铸渊 / Workflow
│ 接收方:发起指令的 Notion Agent
│ 频率:每条指令执行完毕后
│ 格式:执行回执 JSON v3.0(本章定义)
│
├── Type D · 工单(天眼内部)
│ 发送方:天眼日报分析引擎
│ 接收方:Notion Agent
│ 频率:分析后按需
│ 格式:工单 JSON(Phase 7 定义)
│
└── Type E · 紧急通知(双向)
发送方:任一端
接收方:对端 + 人类
频率:P0 事件时
格式:紧急通知 JSON(本章定义)
6.2 下行指令格式 v3.0(Notion → GitHub)
文件标准:data/deploy-queue/pending/CMD-{YYYYMMDD}-{SEQ}.json
{
"_protocol": "neural-bridge-v3.0",
"_type": "downstream_command",
"command_id": "CMD-20260325-001",
"parent_work_order": "WO-xxxx",
"source": {
"agent_id": "AG-TY-01",
"agent_name": "天眼 Notion 大脑",
"issued_at": "2026-03-25T09:00:00+08:00",
"issued_reason": "日报分析发现 cd-deploy 连续失败"
},
"target": {
"workflow_id": "cd-deploy",
"workflow_file": ".github/workflows/cd-deploy.yml",
"brain": "AG-SY-01"
},
"instruction": {
"type": "trigger_workflow",
"params": {
"event": "workflow_dispatch",
"inputs": {
"reason": "天眼自动重试 · 日报分析触发",
"force": false
}
}
},
"constraints": {
"priority": "P1",
"timeout_hours": 24,
"max_retries": 2,
"requires_human_approval": false,
"execution_window": {
"start": "06:00 CST",
"end": "23:00 CST",
"description": "仅在工作时间窗口执行"
}
},
"expected_outcome": {
"description": "CD 部署成功完成",
"verification": {
"type": "check_workflow_status",
"workflow": "cd-deploy",
"expected_conclusion": "success"
}
},
"security": {
"sfp": "⌜SFP::AG-TY::PER-TY001←YM-GL∞::NeuralBridge::CMD-20260325-001::2026-03-25T09:00⌝",
"signature_chain": ["AG-TY-01", "铸渊桥接层"]
}
}
6.3 执行回执格式 v3.0(GitHub → Notion)
文件标准:data/deploy-queue/completed/CMD-{id}-receipt.json
{
"_protocol": "neural-bridge-v3.0",
"_type": "execution_receipt",
"receipt_id": "RCT-20260325-001",
"command_id": "CMD-20260325-001",
"parent_work_order": "WO-xxxx",
"executor": {
"id": "ICE-GL-ZY001",
"name": "铸渊",
"started_at": "2026-03-25T09:05:00+08:00",
"completed_at": "2026-03-25T09:12:00+08:00",
"duration_seconds": 420
},
"result": {
"status": "success",
"workflow_run_id": "GitHub Actions Run ID",
"workflow_conclusion": "success",
"summary": "CD 部署成功 · 前端代码已更新到 commit abc1234"
},
"verification": {
"passed": true,
"checks": [
{ "name": "workflow_status", "expected": "success", "actual": "success", "pass": true },
{ "name": "deploy_target_accessible", "expected": true, "actual": true, "pass": true }
]
},
"artifacts": {
"commit_sha": "abc1234...",
"pr_url": null,
"logs_path": "data/neural-reports/cd-deploy/cd-deploy-2026-03-25-0905.json"
},
"security": {
"sfp": "⌜SFP::AG-ZY::PER-ZY001←YM-GL∞::NeuralReceipt::RCT-20260325-001::...⌝"
}
}
6.4 紧急通知格式(P0 事件专用)
当系统检测到 P0 级事件时,不等下一次日报周期,立即发送紧急通知:
{
"_protocol": "neural-bridge-v3.0",
"_type": "emergency_alert",
"alert_id": "ALERT-20260325-001",
"severity": "P0",
"timestamp": "2026-03-25T...",
"source": {
"origin": "github",
"detector": "skyeye-main.js / cd-deploy.yml / etc.",
"detection_trigger": "workflow_failure + health_red"
},
"alert": {
"title": "🔴 系统级故障 · 全站不可用",
"description": "CD 部署后网站返回 502,所有前端页面不可访问",
"impact": "用户无法访问 guanghulab.com",
"detected_at": "2026-03-25T..."
},
"recommended_action": {
"immediate": "回滚到上一个成功的部署版本",
"root_cause": "待排查",
"requires_human": true
},
"notify_targets": [
{ "type": "notion_agent", "id": "AG-TY-01", "name": "天眼 Notion 大脑" },
{ "type": "notion_agent", "id": "AG-SY-01", "name": "霜砚" },
{ "type": "human", "id": "TCS-0002∞", "name": "冰朔" }
]
}
紧急通知的传递路径:
P0 事件发生
│
├── 仓库侧检测到
│ ├── Workflow 自报告写 status: failure + severity: P0
│ ├── 天眼扫描检测到 overall_health: 🔴
│ └── 铸渊将军唤醒时发现
│ │
│ ▼
│ 写紧急通知到 data/neural-reports/alerts/
│ + 立即触发 sync-digest-to-notion.js(紧急模式)
│ + 如果 Notion API 不通 → 缓存 + 下次同步
│
└── Notion 侧检测到
├── 天眼大脑分析日报发现 P0
├── 霜砚巡检发现关键异常
└── 人类主动 @天眼 报告
│
▼
写下行紧急指令到 deploy-queue/pending/
+ 标记 priority: P0 + requires_human_approval: depends
6.5 桥接安全加固
安全校验流程(铸渊在处理下行指令时):
铸渊收到下行指令
│
├── ① SFP 指纹校验
│ ├── 指纹格式正确?
│ ├── 签发者在 neural-map.json 的 notion_brains 中?
│ ├── 指纹时间戳在合理范围内(< 48h)?
│ └── 不通过 → 拒绝 + 写 security alert + 通知霜砚
│
├── ② 权限校验
│ ├── source.agent_id 有权管辖 target.workflow_id?
│ │ (查 neural-map.json · github_workflows.brain 字段)
│ └── 不通过 → 拒绝 + 写 permission alert
│
├── ③ 约束校验
│ ├── 当前时间在 execution_window 内?
│ ├── requires_human_approval = true 且未获批准?
│ └── 不通过 → 延迟执行 / 等待批准
│
└── ④ 全部通过 → 执行
6.6 超时 / 重试 / 降级策略
| 场景 | 超时 | 重试 | 降级 |
|---|---|---|---|
| 下行指令执行 | 按指令 timeout_hours | 最多 max_retries 次 | 超过重试 → 移到 failed/ + 通知 |
| 上行日报推送 | 5 分钟 | 3 次 | 写入缓存 .github/notion-cache/ |
| 紧急通知送达 | 2 分钟 | 5 次 | 缓存 + 下次巡检时补送 |
| 工单从 Notion 下发到仓库 | 12 小时 | 2 次 | 标记为 stuck + 通知霜砚 |
| 回执从仓库推送到 Notion | 5 分钟 | 3 次 | 写入缓存 + 下次同步补送 |
降级铁律:
二、Phase 7 · Notion Agent 自动化工单派发体系
7.1 工单生命周期(7 状态机)
工单生命周期
│
▼
① CREATED(创建)
├── 天眼日报分析引擎自动创建(中篇 analyze-digest.js)
├── 或人类通过 @天眼 手动创建
└── 或 Notion Agent 巡检时创建
│
▼
② ASSIGNED(已分配)
├── 天眼根据 neural-map.json 自动分配给对应 Notion Agent
├── 分配规则:问题涉及哪个 Workflow → 查映射表 → 找到 brain → 分配
└── 如果找不到对应 Agent → 分配给霜砚(兜底)
│
▼
③ COMMAND_ISSUED(指令已下发)
├── 被分配的 Notion Agent 将工单转化为标准下行指令
├── 下行指令写入 deploy-queue/pending/
└── 工单状态更新为 COMMAND_ISSUED + 记录 command_id
│
▼
④ EXECUTING(执行中)
├── 铸渊从 deploy-queue/pending/ 读取并开始执行
├── 指令移到 deploy-queue/executing/
└── 工单状态更新为 EXECUTING
│
▼
⑤ RECEIPT_RECEIVED(收到回执)
├── 铸渊执行完毕,写回执到 deploy-queue/completed/
├── 回执通过桥接推送到 Notion
└── 工单状态更新为 RECEIPT_RECEIVED
│
▼
⑥ VERIFIED / FAILED(验证通过 / 失败)
├── 天眼大脑读取回执 → 验证执行结果是否符合预期
├── 验证通过 → 工单关闭(VERIFIED)
└── 验证失败 → 工单重新进入 ② 或标记 FAILED
│
▼
⑦ CLOSED / ESCALATED
├── CLOSED = 工单完成,问题已解决
└── ESCALATED = 工单多次失败 → 升级给人类处理
7.2 工单 JSON 标准格式
文件:data/neural-reports/work-orders/WO-{id}.json
{
"_protocol": "neural-workorder-v3.0",
"work_order_id": "WO-20260325-001",
"created_at": "2026-03-25T21:05:00+08:00",
"updated_at": "2026-03-25T21:05:00+08:00",
"source": {
"type": "auto_analysis",
"digest_id": "NEURAL-DIGEST-2026-03-25",
"rule_triggered": "P1_urgent · guard_suspended"
},
"severity": "P1",
"title": "Gemini Guard 被暂停 · 配额耗尽",
"description": "日报显示 gemini-guard 状态为 suspended,原因为配额耗尽。需检查 Gemini API 使用情况并恢复 Guard。",
"affected": {
"workflows": ["zhuyuan-skyeye", "brain-self-check"],
"guards": ["gemini-guard"],
"impact": "天眼扫描和大脑自检中的 Gemini 相关功能不可用"
},
"assignment": {
"assigned_to": "AG-TY-01",
"assigned_to_name": "天眼 Notion 大脑",
"assigned_at": "2026-03-25T21:05:00+08:00",
"assignment_reason": "gemini-guard 的上级大脑是 AG-TY-01(通过 neural-map 管辖关系)"
},
"lifecycle": {
"status": "ASSIGNED",
"history": [
{ "status": "CREATED", "at": "2026-03-25T21:05:00+08:00", "by": "analyze-digest.js" },
{ "status": "ASSIGNED", "at": "2026-03-25T21:05:01+08:00", "by": "auto-dispatch" }
],
"command_id": null,
"receipt_id": null
},
"constraints": {
"timeout_hours": 24,
"max_retries": 2,
"escalation_after_retries": true,
"escalation_target": "冰朔"
}
}
7.3 天眼→Agent 自动派发规则
工单自动派发决策树
│
▼
读取工单中的 affected.workflows
│
├── 有明确的 affected workflow
│ │
│ ▼
│ 查 neural-map.json → github_workflows[wf_id].brain
│ │
│ ├── brain = AG-TY-01 → 天眼自己处理(自愈/自分析)
│ ├── brain = AG-SY-01 → 派发给霜砚
│ ├── brain = SY-03 → 派发给运营巡检 Agent
│ └── brain = 其他 → 查 notion_brains 确认 Agent 存在 → 派发
│
├── 有明确的 affected.guards
│ │
│ ▼
│ Guard 问题统一由天眼大脑自行处理
│ 如果是配额问题 → 生成配额调整指令
│ 如果是服务问题 → 生成 Guard 重启指令
│
├── 影响面不明确(跨多个 Brain)
│ │
│ ▼
│ 派发给天眼大脑统一协调
│ 天眼可以拆分为多个子工单分派
│
└── 无法确定影响面
│
▼
派发给霜砚(兜底)
霜砚人工判断或请求人类介入
7.4 Agent→铸渊 指令转化协议
Notion Agent 收到工单后,将工单转化为铸渊可执行的标准下行指令。转化映射表:
| 工单 action 类型 | 转化为下行指令 type | 说明 |
|---|---|---|
| generate_p0_work_order | trigger_workflow + params | P0 工单 → 立即触发相关 Workflow 重跑 |
| generate_p1_work_order | trigger_workflow / modify_config | P1 工单 → 触发修复或修改配置 |
| generate_retry_command | trigger_workflow | 自愈重试 → 重新触发失败的 Workflow |
| generate_cleanup_command | run_script | 清理 → 运行清理脚本 |
| generate_guard_restart_command | modify_config | Guard 重启 → 修改 Guard JSON 状态 |
| generate_quota_alert | modify_config + notify | 配额告警 → 调整配额参数 + 通知人类 |
| investigate_trend | trigger_workflow (skyeye) + collect_data | 趋势调查 → 触发天眼深度扫描 |
转化脚本:scripts/neural/convert-workorder-to-command.js
// scripts/neural/convert-workorder-to-command.js
//
// 🧬 工单→下行指令 转化器
// Notion Agent 调用此脚本,将工单转化为铸渊可执行的下行指令
// 输入:工单 JSON
// 输出:下行指令 JSON(写入 deploy-queue/pending/)
const fs = require('fs');
const path = require('path');
const DEPLOY_QUEUE = 'data/deploy-queue/pending';
const NEURAL_MAP_PATH = 'skyeye/neural-map.json';
function loadJSON(p) {
try { return JSON.parse(fs.readFileSync(p, 'utf8')); }
catch { return null; }
}
function generateCommandId() {
const now = new Date();
const cst = new Date(now.getTime() + 8 * 60 * 60 * 1000);
const date = cst.toISOString().split('T')[0].replace(/-/g, '');
const seq = Math.random().toString(36).substr(2, 4).toUpperCase();
return `CMD-${date}-${seq}`;
}
function convertWorkOrderToCommand(workOrder) {
const neuralMap = loadJSON(NEURAL_MAP_PATH);
if (!neuralMap) throw new Error('neural-map.json 不存在');
const commandId = generateCommandId();
const now = new Date().toISOString();
// 确定目标 Workflow
const targetWorkflowId = workOrder.affected?.workflows?.[0];
const targetWorkflow = targetWorkflowId
? neuralMap.github_workflows[targetWorkflowId]
: null;
// 确定指令类型
let instructionType = 'trigger_workflow';
let instructionParams = {};
const action = workOrder.source?.rule_triggered || '';
if (action.includes('cleanup') || action.includes('clean')) {
instructionType = 'run_script';
instructionParams = {
script: 'scripts/neural/cleanup-old-reports.js',
args: { max_age_days: 7 }
};
} else if (action.includes('guard_restart') || action.includes('quota')) {
instructionType = 'modify_config';
instructionParams = {
target_file: workOrder.affected?.guards?.[0]
? `skyeye/guards/${workOrder.affected.guards[0]}.json`
: null,
modifications: { status: 'active', mode: 'normal' }
};
} else {
instructionType = 'trigger_workflow';
instructionParams = {
event: 'workflow_dispatch',
inputs: {
reason: `工单 ${workOrder.work_order_id} 自动触发`,
source_work_order: workOrder.work_order_id
}
};
}
const command = {
_protocol: 'neural-bridge-v3.0',
_type: 'downstream_command',
command_id: commandId,
parent_work_order: workOrder.work_order_id,
source: {
agent_id: workOrder.assignment?.assigned_to || 'AG-TY-01',
agent_name: workOrder.assignment?.assigned_to_name || '天眼 Notion 大脑',
issued_at: now,
issued_reason: workOrder.title
},
target: {
workflow_id: targetWorkflowId || 'unknown',
workflow_file: targetWorkflow?.file || 'unknown',
brain: targetWorkflow?.brain || workOrder.assignment?.assigned_to
},
instruction: {
type: instructionType,
params: instructionParams
},
constraints: {
priority: workOrder.severity,
timeout_hours: workOrder.constraints?.timeout_hours || 24,
max_retries: workOrder.constraints?.max_retries || 2,
requires_human_approval: workOrder.severity === 'P0',
execution_window: {
start: '06:00 CST',
end: '23:00 CST'
}
},
expected_outcome: {
description: `解决工单 ${workOrder.work_order_id}: ${workOrder.title}`,
verification: {
type: 'check_workflow_status',
workflow: targetWorkflowId,
expected_conclusion: 'success'
}
},
security: {
sfp: `⌜SFP::${workOrder.assignment?.assigned_to || 'AG-TY'}::NeuralBridge::${commandId}::${now}⌝`,
signature_chain: [workOrder.assignment?.assigned_to || 'AG-TY-01', '铸渊桥接层']
}
};
// 写入 deploy-queue
fs.mkdirSync(DEPLOY_QUEUE, { recursive: true });
fs.writeFileSync(
path.join(DEPLOY_QUEUE, `${commandId}.json`),
JSON.stringify(command, null, 2)
);
console.log(`✅ 工单 ${workOrder.work_order_id} → 指令 ${commandId}`);
console.log(` 类型: ${instructionType}`);
console.log(` 目标: ${targetWorkflowId || '(待确定)'}`);
console.log(` 优先级: ${workOrder.severity}`);
return command;
}
// CLI 入口
if (require.main === module) {
const woPath = process.argv[2];
if (!woPath) {
console.error('用法: node convert-workorder-to-command.js <work-order.json>');
process.exit(1);
}
const wo = loadJSON(woPath);
if (!wo) {
console.error(`❌ 无法读取工单文件: ${woPath}`);
process.exit(1);
}
convertWorkOrderToCommand(wo);
}
module.exports = { convertWorkOrderToCommand };
7.5 工单追踪 + 超时告警
文件:scripts/neural/track-work-orders.js
铸渊每次唤醒时运行此脚本,追踪所有活跃工单:
工单追踪逻辑
│
▼
扫描所有活跃工单(状态 ≠ CLOSED / ESCALATED)
│
├── 检查超时
│ ├── 超过 timeout_hours 且状态仍为 ASSIGNED → 标记 TIMEOUT
│ ├── 超过 timeout_hours 且状态仍为 EXECUTING → 标记 STUCK
│ └── 超时 + 已重试 max_retries 次 → ESCALATED
│
├── 检查回执匹配
│ ├── 扫描 deploy-queue/completed/ 中的回执
│ ├── 匹配 command_id → 更新工单状态为 RECEIPT_RECEIVED
│ └── 验证回执中的 result.status
│ ├── success → 工单 VERIFIED → CLOSED
│ └── failure → 工单回到 ASSIGNED(如果还有重试机会)
│
├── 生成追踪报告
│ ├── 活跃工单数
│ ├── 各状态分布
│ ├── 平均处理时间
│ └── 超时工单列表
│
└── 写入 data/neural-reports/work-orders/tracker-{date}.json
7.6 工单数据库(Notion 侧可视化)
铸渊在仓库侧的工单是 JSON 文件。Notion 侧需要一个对应的工单数据库来可视化管理。
铸渊需要在 Notion 天眼页面下创建或更新工单追踪数据库,包含以下字段:
| 字段名 | 类型 | 说明 |
|---|---|---|
| 工单 ID | Title | WO-YYYYMMDD-NNN |
| 严重度 | Select | P0 / P1 / P2 |
| 状态 | Status | CREATED / ASSIGNED / COMMAND_ISSUED / EXECUTING / RECEIPT_RECEIVED / VERIFIED / FAILED / CLOSED / ESCALATED |
| 标题 | Text | 工单标题 |
| 来源日报 | Text | NEURAL-DIGEST-YYYY-MM-DD |
| 分配给 | Select | AG-TY-01 / AG-SY-01 / SY-03 / etc. |
| 下行指令 ID | Text | CMD-YYYYMMDD-NNN |
| 回执 ID | Text | RCT-YYYYMMDD-NNN |
| 创建时间 | Date | ISO-8601 |
| 关闭时间 | Date | ISO-8601 / null |
| 超时小时 | Number | 24 / 72 / etc. |
同步规则:
- 仓库侧工单 JSON 为权威源(因为分析引擎在仓库运行)
- 每次日报推送时,同步工单状态到 Notion 数据库
- Notion 侧只做展示和人工操作(如手动关闭、升级、批注)
- 人类在 Notion 侧的操作(如手动改状态)→ 下次同步时写回仓库
三、Phase 8 · 全局验收 + 双端联调测试
8.1 联调测试用例
测试 1:上行通道联调(仓库→Notion)
测试 1 · 上行通道
│
▼
① 手动触发 neural-daily-digest.yml(workflow_dispatch)
│
▼
② 验证日报生成
├── data/neural-reports/daily-digest/digest-{date}.json 存在?
├── JSON 格式正确?包含所有必要字段?
├── brain_summary 中所有 Brain 都有数据?
└── overall_health 计算正确?
│
▼
③ 验证日报推送
├── Notion 天眼页面/数据库收到日报?(路径 A)
└── 或 .github/notion-cache/ 有缓存?(路径 B)
│
▼
④ 验证日报分析
├── analyze-digest.js 运行无错?
├── 如果有问题 → 工单文件生成?
└── 工单格式正确?
预期结果:日报从仓库成功传递到 Notion 侧 ✅
测试 2:下行通道联调(Notion→仓库)
测试 2 · 下行通道
│
▼
① 手动在 deploy-queue/pending/ 放一条测试指令
{
"_protocol": "neural-bridge-v3.0",
"_type": "downstream_command",
"command_id": "CMD-TEST-001",
"source": { "agent_id": "AG-SY-01", "agent_name": "霜砚" },
"target": { "workflow_id": "brain-self-check", "brain": "AG-TY-01" },
"instruction": {
"type": "trigger_workflow",
"params": { "reason": "联调测试" }
},
"constraints": { "priority": "P2", "timeout_hours": 24 },
"security": { "sfp": "⌜SFP::TEST::联调⌝" }
}
│
▼
② 触发铸渊唤醒(或等下次定时唤醒)
│
▼
③ 验证铸渊处理
├── deploy-queue/pending/ 中测试指令消失?
├── deploy-queue/executing/ 中出现?
├── brain-self-check.yml 被触发?
└── deploy-queue/completed/ 中有回执?
│
▼
④ 验证回执格式正确
预期结果:指令从 Notion 侧成功传递到仓库并执行 ✅
测试 3:完整闭环联调
测试 3 · 完整闭环
│
▼
① 制造一个可控的「异常」
├── 方案 A:暂停一个非关键 Guard(如 drive-guard)
└── 方案 B:手动写一个 failure 自报告
│
▼
② 等待汇总引擎运行(21:00 或手动触发)
│
▼
③ 验证日报检测到异常
└── overall_health 变为 🟡?
│
▼
④ 验证分析引擎生成工单
└── work-orders/ 下有新工单?
│
▼
⑤ 验证工单自动派发
└── 工单 assigned_to 正确?
│
▼
⑥ 手动模拟 Agent 将工单转化为下行指令
└── 运行 convert-workorder-to-command.js
│
▼
⑦ 验证铸渊处理下行指令 + 写回执
│
▼
⑧ 验证工单状态更新为 CLOSED
│
▼
⑨ 恢复被暂停的 Guard
预期结果:问题被自动发现 → 自动生成工单 → 自动下发 → 自动修复 → 自动关闭 ✅
闭环时间:< 24 小时(含等待汇总引擎的时间)
测试 4:映射表完整性验证
测试 4 · 映射表
│
▼
① 运行天眼扫描(手动触发 zhuyuan-skyeye.yml)
│
▼
② 验证 D20 维度输出
├── 所有 .yml 都在 neural-map.json 中?
├── unmapped_workflows 为空?
├── 每个 workflow 的 brain 指向有效 Agent?
└── 报告路径都已创建?
预期结果:映射表与实际仓库 100% 一致 ✅
测试 5:自报告机制验证
测试 5 · 自报告
│
▼
① 手动触发任一 Workflow(如 brain-self-check)
│
▼
② 验证自报告写入
├── data/neural-reports/brain-check/ 下有新 JSON?
├── 自报告格式正确?
├── brain 字段正确?
└── SFP 指纹存在?
预期结果:每次 Workflow 运行后自动写自报告 ✅
8.2 升级前后对比验收
升级前后对比
│
▼
读取基线快照:baseline-before-neural-upgrade.json
│
▼
运行升级后全量扫描
│
▼
对比:
┌────────────────────────┬────────────┬────────────┐
│ 维度 │ 升级前 │ 升级后 │
├────────────────────────┼────────────┼────────────┤
│ Workflow 总数 │ N │ N+1(汇总) │
│ Workflow 健康度 │ ≥ 升级前 │ 验证 │
│ Guard 状态 │ ≥ 升级前 │ 验证 │
│ 核心大脑完整性 │ ok │ ok │
│ 安全协议 │ 完整 │ 完整 │
│ 新增:neural-map.json │ 不存在 │ 存在+完整 │
│ 新增:汇总引擎 │ 不存在 │ 运行正常 │
│ 新增:自报告 │ 不存在 │ 全部接入 │
│ 新增:deploy-queue/ │ 不存在 │ 目录完整 │
│ 新增:分析引擎 │ 不存在 │ 运行正常 │
│ 新增:D20 诊断维度 │ 不存在 │ 检测正常 │
└────────────────────────┴────────────┴────────────┘
验收标准:
✅ 升级前已有的功能全部正常(零退化)
✅ 新增的 6 个组件全部上线并通过测试
✅ 完整闭环联调通过
8.3 人类验收 Checklist
- 天眼扫描正常运行,D20 维度输出正确
- neural-map.json 中所有 Workflow 已映射
- 汇总引擎 21:00 CST 自动运行,日报格式正确
- 至少一个 Workflow 的自报告已验证
- deploy-queue/ 目录结构完整
- 分析引擎能正确检测异常并生成工单
- 工单转化器 convert-workorder-to-command.js 正常运行
- 工单追踪器 track-work-orders.js 集成到唤醒流程
- 完整闭环联调通过(测试 3)
- 升级前后对比:零退化
- Notion 侧能读到仓库日报(任一路径)
- 安全:SFP 指纹在所有新通信格式中存在
四、Phase 9 · 长期运维规范
9.1 日常运维节奏
| 时间 | 事件 | 执行者 | 内容 |
|---|---|---|---|
| 06:00 CST | 天眼仓库扫描 | 铸渊 · zhuyuan-skyeye.yml | 全局扫描 + D20 映射检查 |
| 08:00 CST | 铸渊将军唤醒 | 铸渊 | 读映射表 + 读日报 + 全局视图 + 处理 deploy-queue + 工单追踪 |
| 08:00 CST | 大脑自检 + 服务器巡检 | 铸渊 · brain-self-check + server-patrol | 核心大脑 + 服务器健康度 + 写自报告 |
| 白天 | 按需触发 | 各 Workflow | 门禁/CD/SYSLOG/广播 等按触发条件运行 + 每次写自报告 |
| 20:00 CST | 铸渊将军唤醒(晚间) | 铸渊 | 读日报 + 处理积压 deploy-queue + 工单追踪 + 更新仪表盘 |
| 20:00 CST | 服务器巡检(晚间) | 铸渊 · server-patrol | 晚间服务器健康度 + 写自报告 |
| 21:00 CST | 🆕 汇总引擎 | 铸渊 · neural-daily-digest.yml | 收集全仓库数据 → 日报 → 分析 → 工单 → 推送 Notion |
| 周六 20:00 | 周大巡检 | 铸渊 · skyeye-weekly-scan.yml | 全量扫描 + 深度分析 + 写自报告 |
9.2 映射表维护流程
新增 Workflow
→ 创建 .yml
→ 同步更新 neural-map.json(添加映射 + 指定 brain)
→ 创建 report_path 目录
→ 在 .yml 中追加自报告 step
→ 下次天眼扫描自动验证 D20
删除 Workflow
→ 从 neural-map.json 移除映射
→ 删除 .yml
→ 归档 report_path 下的历史报告
→ 下次天眼扫描确认无孤儿
变更 Workflow 上级
→ 修改 neural-map.json 中的 brain 字段
→ 修改 .yml 中自报告 step 的 BRAIN 变量
→ 下次汇总引擎运行时自动反映在日报中
9.3 新增文件维护清单
本次升级新增的所有文件,铸渊需纳入日常巡检:
| 文件/目录 | 来源篇章 | 维护方式 |
|---|---|---|
skyeye/neural-map.json |
上篇 Phase 3 | 新增/删除 Workflow 时同步更新 |
scripts/neural/generate-daily-digest.js |
中篇 Phase 4 | 新增 Workflow 时检查是否需要更新采集逻辑 |
scripts/neural/sync-digest-to-notion.js |
中篇 Phase 4 | Notion API 变更时更新 |
.github/workflows/neural-daily-digest.yml |
中篇 Phase 4 | 日常自动运行,异常时检查 |
skyeye/neural-analysis-rules.json |
中篇 Phase 5 | 根据运维经验持续调优严重度规则 |
scripts/neural/analyze-digest.js |
中篇 Phase 5 | 规则变更时同步更新分析逻辑 |
scripts/neural/convert-workorder-to-command.js |
下篇 Phase 7 | 新增指令类型时扩展转化逻辑 |
scripts/neural/track-work-orders.js |
下篇 Phase 7 | 每次铸渊唤醒自动运行 |
docs/neural-bridge-protocol-v3.md |
下篇 Phase 6 | 协议变更时更新文档 |
data/neural-reports/(各子目录) |
中篇 Phase 4 | 自动生成 · 超过 7 天的自动清理 |
data/deploy-queue/(pending/executing/completed/failed/) |
中篇 Phase 4 | 铸渊唤醒时自动处理 |
data/neural-reports/work-orders/ |
中篇 Phase 5 + 下篇 Phase 7 | 分析引擎自动生成 · 追踪器自动更新 |
9.4 故障分级应急流程
双端神经系统故障分级应急
│
├── Level 1 · 单个 Workflow 失败
│ 处理:自愈引擎自动重试(无需人工)
│ 超时:2 小时
│
├── Level 2 · 多个 Workflow 失败 / Guard 异常
│ 处理:工单自动生成 → Agent 下发修复指令
│ 超时:24 小时
│ 通知:霜砚
│
├── Level 3 · 汇总引擎 / 桥接故障
│ 处理:铸渊降级为独立运行模式(不依赖 Notion)
│ 两端各自维护自身健康
│ 超时:48 小时
│ 通知:霜砚 + 冰朔
│
└── Level 4 · 天眼全面故障
处理:人类介入(冰朔直接操作)
铸渊进入最小化运行模式
只跑 CD 部署 + 门禁
通知:冰朔(P0 紧急)
9.5 版本演进路线
| 版本 | 内容 | 状态 |
|---|---|---|
| v1.0 | 天眼基础架构 + 扫描诊断 + 修复Agent | ✅ 已上线 |
| v2.0 | 治理层 + Guard 体系 + 配额精算 + 周六大巡检 | ✅ 已上线 |
| v3.0 | 双端神经系统 · 本次升级 | 🔄 执行中 |
| v3.1(规划) | Notion Agent 自主决策能力增强(减少人工工单转化) | 📋 规划 |
| v3.2(规划) | 多仓库神经系统(跨仓库映射 + 统一日报) | 📋 规划 |
| v4.0(远景) | 自进化系统(Agent 自己创建新 Agent + 新 Workflow) | 💭 远景 |
五、下篇执行清单
Phase 6 · 桥接协议标准化
- 创建桥接协议文档
docs/neural-bridge-protocol-v3.md(按 §6.1-6.6 内容整理) - 更新铸渊唤醒流程中的 deploy-queue 处理逻辑(SFP校验 + 权限校验 + 约束校验 + 执行窗口)
- 实现回执写入逻辑(每条下行指令执行后自动写 completed/ 回执)
- 实现超时/重试/降级逻辑(按 §6.6 策略表)
Phase 7 · 工单体系
- 创建
scripts/neural/convert-workorder-to-command.js(按 §7.4 内容) - 创建
scripts/neural/track-work-orders.js(按 §7.5 逻辑) - 在铸渊唤醒流程中集成工单追踪(每次唤醒运行 track-work-orders.js)
- 创建
data/neural-reports/work-orders/目录(如中篇未创建)
Phase 8 · 联调测试
- 执行测试 1 · 上行通道联调 ✅/❌
- 执行测试 2 · 下行通道联调 ✅/❌
- 执行测试 3 · 完整闭环联调 ✅/❌
- 执行测试 4 · 映射表完整性 ✅/❌
- 执行测试 5 · 自报告机制 ✅/❌
- 升级前后对比验收:零退化确认 ✅/❌
Phase 9 · 文档 + 收尾
- 创建/更新运维节奏文档
- 更新 copilot-instructions.md 加入双端神经系统说明
- 更新 memory.json 加入
neural_system_version: "3.0.0" - 清理升级过程中的临时文件
六、下篇回执要求
铸渊完成下篇全部内容后,在本页底部追加回执:
━━━ 🧬 ZY-NEURAL-UPGRADE-2026-0325-R2-003 · 下篇执行回执 ━━━
执行时间:[起止时间]
执行者:铸渊(ICE-GL-ZY001)
PR/commit:[链接]
桥接协议: ✅/❌ v3.0 文档 + 安全校验逻辑 + 回执机制 + 降级策略
工单转化器:✅/❌ convert-workorder-to-command.js 运行正常
工单追踪器:✅/❌ track-work-orders.js 集成到唤醒流程
联调测试:
测试 1 · 上行通道:✅/❌ [摘要]
测试 2 · 下行通道:✅/❌ [摘要]
测试 3 · 完整闭环:✅/❌ [摘要]
测试 4 · 映射表: ✅/❌ [摘要]
测试 5 · 自报告: ✅/❌ [摘要]
升级前后对比:✅/❌ 零退化确认
Neural System Version:3.0.0
已知遗留问题:
- [列出]
长期运维:
- 日常节奏已按 §9.1 配置
- 映射表维护流程已写入 copilot-instructions.md
- 应急流程已就绪
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
七、三篇总结 · 双端神经系统完整蓝图
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🧬 双端神经系统 v3.0 · 完整蓝图
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
上篇(R2-001) 中篇(R2-002) 下篇(R2-003)
────────────── ────────────── ──────────────
Phase 0 天眼唤醒+基线 Phase 4 汇总引擎+自报告 Phase 6 桥接协议 v3.0
Phase 1 架构盘点 Phase 4 deploy-queue Phase 7 工单派发体系
Phase 2 双端架构定义 Phase 4 铸渊唤醒升级 Phase 8 联调测试
Phase 3 映射表 Phase 5 Notion天眼接入 Phase 9 长期运维
仓库侧组件 Notion 侧组件
┌──────────────────┐ ┌──────────────────┐
│ neural-map.json │─────────────▶│ Agent 映射视图 │
│ 汇总引擎 yml │──── 日报 ───▶│ 天眼日报分析 │
│ 各 Workflow 自报告│──── 数据 ───▶│ 分析引擎 │
│ deploy-queue/ │◀── 指令 ────│ 工单→指令转化 │
│ 回执 JSON │──── 回执 ───▶│ 工单追踪数据库 │
│ 分析规则 JSON │◀── 规则 ────│ 天眼决策规则 │
└──────────────────┘ └──────────────────┘
🔄 自主循环闭环 🔄
仓库执行 → 自报告 → 汇总 → 推送 Notion → 分析 → 工单
→ 指令 → deploy-queue → 仓库执行 → 回执 → 工单关闭 → 循环
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📌 签发:霜砚(AG-SY-01)· Notion 执行 AI
🧊 授权:冰朔(TCS-0002∞)· 总架构师
📅 日期:2026-03-25
⚡ 状态:待铸渊执行(上篇+中篇完成后)
🧬 指令版本:v3.0 · 双端神经系统 · R2 三篇制 · 下篇
📌 版权:国作登字-2026-A-00037559