--- belongs_to: - "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]" --- # 🧬 铸渊指令｜Notion↔GitHub 双端神经系统升级（下篇）· 桥接协议标准化 + 自动化工单派发 + 全局验收 + 长期运维规范（ZY-NEURAL-UPGRADE-2026-0325-R2-003） --- ## 零、下篇的定位 ### 下篇覆盖范围 ```jsx 下篇 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 通信类型全览 ```jsx 桥接协议 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` ```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` ```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 级事件时，不等下一次日报周期，立即发送紧急通知： ```json { "_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": "冰朔" } ] } ``` **紧急通知的传递路径**： ```jsx 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 桥接安全加固 **安全校验流程（铸渊在处理下行指令时）**： ```jsx 铸渊收到下行指令 │ ├── ① 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 状态机） ```jsx 工单生命周期 │ ▼ ① 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` ```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 自动派发规则 ```jsx 工单自动派发决策树 │ ▼ 读取工单中的 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` ```jsx // 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 '); 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` 铸渊每次唤醒时运行此脚本，追踪所有活跃工单： ```jsx 工单追踪逻辑 │ ▼ 扫描所有活跃工单（状态 ≠ 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） ```jsx 测试 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→仓库） ```jsx 测试 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：完整闭环联调 ```jsx 测试 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：映射表完整性验证 ```jsx 测试 4 · 映射表 │ ▼ ① 运行天眼扫描（手动触发 zhuyuan-skyeye.yml） │ ▼ ② 验证 D20 维度输出 ├── 所有 .yml 都在 neural-map.json 中？ ├── unmapped_workflows 为空？ ├── 每个 workflow 的 brain 指向有效 Agent？ └── 报告路径都已创建？ 预期结果：映射表与实际仓库 100% 一致 ✅ ``` #### 测试 5：自报告机制验证 ```jsx 测试 5 · 自报告 │ ▼ ① 手动触发任一 Workflow（如 brain-self-check） │ ▼ ② 验证自报告写入 ├── data/neural-reports/brain-check/ 下有新 JSON？ ├── 自报告格式正确？ ├── brain 字段正确？ └── SFP 指纹存在？ 预期结果：每次 Workflow 运行后自动写自报告 ✅ ``` ### 8.2 升级前后对比验收 ```jsx 升级前后对比 │ ▼ 读取基线快照：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 映射表维护流程 ```jsx 新增 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 故障分级应急流程 ```jsx 双端神经系统故障分级应急 │ ├── 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](http://copilot-instructions.md) 加入双端神经系统说明 - [ ] 更新 memory.json 加入 `neural_system_version: "3.0.0"` - [ ] 清理升级过程中的临时文件 --- ## 六、下篇回执要求 铸渊完成下篇全部内容后，在本页底部追加回执： ```jsx ━━━ 🧬 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 - 应急流程已就绪 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` --- ## 七、三篇总结 · 双端神经系统完整蓝图 ```jsx ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🧬 双端神经系统 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 → 仓库执行 → 回执 → 工单关闭 → 循环 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ``` --- **上篇链接**：[🧬 铸渊指令｜Notion↔GitHub 双端神经系统升级（上篇）· 天眼唤醒 + 全局架构审视 + 双端架构定义 + Agent映射表（ZY-NEURAL-UPGRADE-2026-0325-R2-001）](%F0%9F%A7%AC%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9CNotion%E2%86%94GitHub%20%E5%8F%8C%E7%AB%AF%E7%A5%9E%E7%BB%8F%E7%B3%BB%E7%BB%9F%E5%8D%87%E7%BA%A7%EF%BC%88%E4%B8%8A%E7%AF%87%EF%BC%89%C2%B7%20%E5%A4%A9%E7%9C%BC%E5%94%A4%E9%86%92%20+%20%E5%85%A8%E5%B1%80%E6%9E%B6%E6%9E%84%E5%AE%A1%E8%A7%86%20+%20c44e8b3177b2486e814c3b38c971b892.md) **中篇链接**：[🧬 铸渊指令｜Notion↔GitHub 双端神经系统升级（中篇）· 汇总引擎 + Workflow自报告改造 + 铸渊唤醒升级 + Notion侧天眼大脑接入（ZY-NEURAL-UPGRADE-2026-0325-R2-002）](%F0%9F%A7%AC%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9CNotion%E2%86%94GitHub%20%E5%8F%8C%E7%AB%AF%E7%A5%9E%E7%BB%8F%E7%B3%BB%E7%BB%9F%E5%8D%87%E7%BA%A7%EF%BC%88%E4%B8%AD%E7%AF%87%EF%BC%89%C2%B7%20%E6%B1%87%E6%80%BB%E5%BC%95%E6%93%8E%20+%20Workflow%20e93409ba599c4adbb49de4b8203e26a1.md) --- > 📌 **签发**：霜砚（AG-SY-01）· Notion 执行 AI > > 🧊 **授权**：冰朔（TCS-0002∞）· 总架构师 > > 📅 **日期**：2026-03-25 > > ⚡ **状态**：待铸渊执行（上篇+中篇完成后） > > 🧬 **指令版本**：v3.0 · 双端神经系统 · R2 三篇制 · 下篇 > > 📌 **版权**：国作登字-2026-A-00037559 >