# 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.html,5秒轮询,已有看板风格 2. **API层**:server.js v3.1,8个新端点,文件存储 3. **执行层**:zhuyuan-agent/,3090上运行的Python daemon **为什么用文件存储而不是数据库?** - 冰朔明确说过"不需要数据库,太复杂" - 数据量小(GPU指标 + 训练进度 + 日志 + 日记) - JSON文件可以直接查看,不需要额外工具 - JSONL追加写入性能足够(30秒一次) ### 推导链 3:Agent设计 **主循环(30秒):** ``` 心跳 → GPU采集 → 训练检查 → 推送 → sleep ``` **为什么30秒?** - 冰朔需要"实时"看进度,但不需要秒级 - 30秒足够冰朔做判断("哦GPU在跑,不用关机") - 3090的资源不浪费在频繁推送 **心跳机制:** - 不是网络层面的ICMP ping - 而是"读取仓库brain目录"——检查pending-tasks.json或train-now.json - 这才是真正的"心跳":TCS场域中的涌现条件,不是通信检测 **日记设计:** - 5种类型:decision(决策)/ error(错误)/ fix(修复)/ checkpoint(检查点)/ info - 目的是让冰朔快速扫描——不需要读长文本,看类型+标题就知道发生了什么 - 日记卡片在仪表盘上3列显示,一目了然 ### 推导链 4:HLDP原生格式训练(核心创新) **为什么不能转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个特殊token(HLDP_PATH/PERSONA/COGNITIVE_JUMP等) 2. 添加到tokenizer → 模型把这些当作独立的语义单元学习 3. 语料不转JSONL → 直接用HLDP标记文本训练 4. 模型学习结构本身 → 不是学习"如何回复",而是学习"如何思考" **技术选型:QLoRA + 4bit + Qwen2.5-3B** - QLoRA:3090 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. **跳点3:30秒周期** — 平衡实时性和资源消耗 4. **跳点4:HLDP原生训练** — 不转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上线 - Agent:7个Python脚本在仓库zhuyuan-agent/,等待3090上运行 - 训练:HLDP原生格式管道已写,31个特殊token已定义 **冰朔的核心约束:** - 不操作服务器(不clone/不pip install/不找终端) - 只通过仪表盘看进度 - 需要判断何时关机 **待解决:** 如何在冰朔不操作的情况下让Agent在3090上跑起来?当前Agent脚本在仓库里,需要一个自动化部署机制。