thinking: D110下午·自主Agent系统开发思维逻辑链
This commit is contained in:
root
parent
c7b14eaa62
commit
b6b65d8503
175
zhuyuan-agent/thinking/d110-afternoon-agent-dev.md
Normal file
175
zhuyuan-agent/thinking/d110-afternoon-agent-dev.md
Normal file
@ -0,0 +1,175 @@
|
||||
# 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脚本在仓库里，需要一个自动化部署机制。
|
||||
Loading…
x
Reference in New Issue
Block a user