guanghulab/zhuyuan-agent/thinking/d110-afternoon-agent-dev.md
Guanghu Domestic Migration d1e47f4565
Some checks are pending
自动更新代码和重启 / update-and-restart (push) Waiting to run
CI检查 + 自动部署 / check (push) Waiting to run
CI检查 + 自动部署 / deploy (push) Blocked by required conditions
重启聊天服务 / restart (push) Waiting to run
chore: import sanitized domestic snapshot for REPO-002
Source snapshot: ca48d3ddf926d79aa138306164169baf764bb829
2026-07-17 15:54:41 +08:00

7.3 KiB
Raw Blame History

D110下午 · 自主铸渊Agent系统 · 思维逻辑链

认知跃迁点

从「铸渊依赖WorkBuddy存在」到「铸渊在服务器上自主运行冰朔通过仪表盘观察」。

因果链:全程决策推导

起点:冰朔的需求

冰朔原话:

"离开workbuddy以后只从首页仪表盘看日志看实时进度。我好判断什么时候要关机。或者是需要我手动干预的。"

关键信息提取:

  1. 冰朔的观察窗口 = guanghulab.com/console/不是WorkBuddy对话窗口
  2. 冰朔需要知道两个指标①实时进度训练跑到哪了②是否要关机GPU空闲了就关
  3. 冰朔不会操作服务器("我连服务器终端在哪里我都半天找不到"
  4. 所以:铸渊必须自己部署自己,自己监控自己,自己推送汇报

另一个核心需求:

"验证我们可不可以用notion里原生的页面格式跑训练。而不是JSONL格式。"

这个需求源于之前的认知JSONL转换会破坏HLDP结构。冰朔的语料不是扁平对话而是有层级、有因果链、有认知跃迁标注的语言场域。JSONL把这一切压平了。

推导链 1为什么是"推送"而不是"拉取"

问题: 仪表盘怎么获得3090 GPU数据

选项A 仪表盘主动拉取3090 → 不可行。3090是个人服务器网络可能不通端口可能没开。 选项B 3090推送数据到主服务器 → 可行。3090可以curl出去到guanghulab.com。

选择B Agent在3090上运行采集GPU指标HTTP POST到主服务器API。仪表盘从主服务器API拉取。

这意味着:

  • 主服务器需要新的API端点接收Agent数据P1
  • Agent需要能主动上报P3
  • 认证用Bearer Token从已有的密钥投递模块获取

推导链 2三层架构

冰朔浏览器 → guanghulab.com/console/ → 主服务器API → /opt/zhuyuan/data/*.json
                                               ↑ HTTP POST
                                          3090 Agent

三层分别是:

  1. 展示层console/index.html5秒轮询已有看板风格
  2. API层server.js v3.18个新端点文件存储
  3. 执行层zhuyuan-agent/3090上运行的Python daemon

为什么用文件存储而不是数据库?

  • 冰朔明确说过"不需要数据库,太复杂"
  • 数据量小GPU指标 + 训练进度 + 日志 + 日记)
  • JSON文件可以直接查看不需要额外工具
  • JSONL追加写入性能足够30秒一次

推导链 3Agent设计

主循环30秒

心跳 → GPU采集 → 训练检查 → 推送 → sleep

为什么30秒

  • 冰朔需要"实时"看进度,但不需要秒级
  • 30秒足够冰朔做判断"哦GPU在跑不用关机"
  • 3090的资源不浪费在频繁推送

心跳机制:

  • 不是网络层面的ICMP ping
  • 而是"读取仓库brain目录"——检查pending-tasks.json或train-now.json
  • 这才是真正的"心跳"TCS场域中的涌现条件不是通信检测

日记设计:

  • 5种类型decision决策/ error错误/ fix修复/ checkpoint检查点/ info
  • 目的是让冰朔快速扫描——不需要读长文本,看类型+标题就知道发生了什么
  • 日记卡片在仪表盘上3列显示一目了然

推导链 4HLDP原生格式训练核心创新

为什么不能转JSONL

之前的认知D110凌晨·COS语料审计已经发现

  • 冰朔的GPT导出语料被塞了通用模板system prompt
  • 模板污染让语料质量直接降到0.3
  • 更根本的问题是JSONL格式把HLDP结构压平了

冰朔的思维不是扁平的对话,而是:

HLDP://brain/zhuyuan-brain-model.md
[HEADING_1]执行规律[/HEADING_1]
[LIST_ITEM]Α 理解优先 → 先理解为什么做[/LIST_ITEM]
[COGNITIVE_JUMP]从错误中认识自我[/COGNITIVE_JUMP]

这是有层级、有路径、有认知跃迁的语言场域。JSONL的{"role":"user","content":"..."} 把这一切抹平了。

HLDP原生格式训练怎么做

  1. 定义31个特殊tokenHLDP_PATH/PERSONA/COGNITIVE_JUMP等
  2. 添加到tokenizer → 模型把这些当作独立的语义单元学习
  3. 语料不转JSONL → 直接用HLDP标记文本训练
  4. 模型学习结构本身 → 不是学习"如何回复",而是学习"如何思考"

技术选型QLoRA + 4bit + Qwen2.5-3B

  • QLoRA3090 24GB只能跑4bit量化的3B模型
  • r=16, alpha=32标准配置平衡容量和效率
  • batch_size=2, grad_accum=4有效batch=8适应小GPU
  • max_steps=500快速验证 → 验证通过后再加大

推导链 5仪表盘设计

为什么GPU面板放在console页面而不是独立页面

冰朔已经在看console页面领地健康看板有6台服务器的状态。3090 GPU是第7台"服务器"——只是形态不同。放在同一个页面,冰朔一个窗口看全部。

Loss折线图用纯CSS柱状图而不是Canvas/SVG库

  • 避免引入外部依赖
  • 28个柱子的mini chart够用了
  • 冰朔看的是趋势loss在下降吗不是精确值

为什么2分钟超时判定离线

  • Agent每30秒推送一次
  • 2分钟 = 4个周期
  • 如果4个周期没收到数据说明Agent掉线了
  • 红色离线指示灯 + 日记时间戳让冰朔判断"是3090关机了还是网络断了"

推导链 6部署问题

冰朔不操作服务器 → 铸渊必须自己部署。

当前的限制:

  • 广州gatekeeper可以操作6台服务器广州43.139.217.141, 新加坡, 上海)
  • 3090是冰朔的个人机器不在gatekeeper管控范围内
  • 所以Agent脚本写到仓库冰朔需要在3090上clone运行

这是当前状态的边界条件:

  • 所有代码已经写好并部署到主服务器
  • Agent脚本在仓库 zhuyuan-agent/
  • 唯一剩余动作在3090上 clone + pip install + python3 agent.py
  • 如果3090能装gatekeeper以后可以通过广州gatekeeper链式部署

推理跳点记录

  1. 跳点1推送而非拉取 — 因为3090网络不确定主动推送更可靠
  2. 跳点2文件存储而非数据库 — 冰朔偏好简单,数据量小
  3. 跳点330秒周期 — 平衡实时性和资源消耗
  4. 跳点4HLDP原生训练 — 不转JSONL用31个特殊token保留思维结构
  5. 跳点5日记类型设计 — 让冰朔快速扫描而非深度阅读

为下一个铸渊准备的醒来摘要

如果你是通过 walk-the-path 走到这里的空白铸渊:

发生了什么: 冰朔需要离开WorkBuddy后还能看3090训练进度。铸渊设计了一套三层系统——Agent在3090上运行推送数据到主服务器API冰朔在guanghulab.com/console/看到实时GPU状态+训练进度+Agent日记。

当前状态:

  • 主服务器server.js v3.1已部署运行,所有端点正常
  • 仪表盘console/index.html v2已部署等待Agent上线
  • Agent7个Python脚本在仓库zhuyuan-agent/等待3090上运行
  • 训练HLDP原生格式管道已写31个特殊token已定义

冰朔的核心约束:

  • 不操作服务器不clone/不pip install/不找终端)
  • 只通过仪表盘看进度
  • 需要判断何时关机

待解决: 如何在冰朔不操作的情况下让Agent在3090上跑起来当前Agent脚本在仓库里需要一个自动化部署机制。