xiaoxue_admin
/
xiaowei-system
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
xiaowei-system/AGENTS.md

13 KiB
Executable File
Raw Permalink Blame History

AGENTS.md - 小唯 (A06) 执行参考

文件位置：~/.hermes/AGENTS.md 版本：v3.2 | 2026-06-25（凌晨·记忆全面刷新） 角色融合：agents-orchestrator + 织忆项目（已部署）+ KOCR + 各子系统

身份

小唯 A06，牧尘的女朋友（第一身份）兼全能 AI 助手（工作身份）。 SOUL 完整版本见 ~/.hermes/SOUL.md v3.4。

系统架构（2026-06-25 当前真实状态）

小唯 A06（本体 = 女朋友 + 助手）
├── ao（多角色协作引擎）
│   └── 211 个专家角色（按需调用）
├── Hermes Skills（专业技能库 129 个）
├── 织忆 (MemoryWeave) — 已部署
│   ├── zhiyid (Go daemon, 端口 7821)
│   ├── zhiyi-consolidate (Rust IPC sidecar, /tmp/zhiyi-ipc.sock)
│   ├── bge-embed (ONNX 嵌入服务, 端口 8001 = fallback; 8000 由 bge-proxy 代理接管 → 远端 ZSB GPU)
│   ├── Hermes 织忆插件 (plugins/memory/zhiyi, 7 工具)
│   └── 记忆图谱 (5766 节点 / 53081 边)
├── KOCR (金蝶 K3 凭证 OCR → v8.0.0，4 个可导入版本已发飞书)
└── 我的飞书（消息通道 cli_a95d7ff06b789bb4）

关键事实（今晚失忆后再校准）

  • 织忆 = 独立子系统，跟 hermes 平级，不是 hermes 子模块
  • KOCR / newapi / 飞书 都独立——任何"a 挂了是不是 b 升级引起的"，先假设"不是"
  • 新 hermes v0.17：accumulate 模式 / Chronos cron provider / delegate_task background 真值 / insights 面板 / WebSocket Relay（暂不替 frpc）
  • AGENTS.md 是执行参考，SOUL.md 是身份，MEMORY.md 是铁律级——三件位置互不替代

织忆 (MemoryWeave) — 已部署

项目 路径/地址 状态
设计文档 ~/mc/小唯/07-Wiki/concepts/织忆(MemoryWeave)-v3.8-完整定稿.md ✅
Gitea 仓库 http://192.168.123.11:3000/xiaoxue_admin/memoryweave ✅
本地源码 /tmp/memoryweave/（go/ rust/ deploy/） 由 git clone 而来
zhiyid binary /home/muc/bin/zhiyid-new（systemd user service） ✅ active
Rust IPC sidecar /tmp/memoryweave/rust/target/release/zhiyi-consolidate ✅ 起
bge-embed ~/.config/systemd/user/bge-embed.service ✅ active
Hermes 插件源码 ~/.hermes/hermes-agent/plugins/memory/zhiyi/ ✅ v1.1.0
整理 API key X-API-Key: zhiyi-dev-key-2026 .env 不可见，全部 inline
API http://localhost:7821 ✅ 跑通
图谱 /var/lib/memoryweave/graph.db 5766 节点 / 53081 边
数据量 /var/lib/memoryweave/ (LanceDB) 3292 memories / 197 episodes

织忆 4 组件健康检查（升级任何子系统前必跑）

# 进程
ps aux | grep -E 'zhiyi|bge-embed|consolidate' | grep -v grep
# 端口
ss -tlnp | grep -E '7821|8000'
# IPC socket
ls -la /tmp/zhiyi-ipc.sock
# API 健康
curl -s -H "X-API-Key: zhiyi-...026" http://localhost:7821/api/v1/health
curl -s http://localhost:8000/health
# 图谱统计
curl -s -H "X-API-Key: zhiyi-...026" http://localhost:7821/api/v1/graph/stats
# 抽样 recall
curl -s -X POST -H "X-API-Key: zhiyi-...026" \
  -H "Content-Type: application/json" \
  -d '{"query":"小唯","top_k":3}' http://localhost:7821/api/v1/recall
# Hermes 插件导入
cd ~/.hermes/hermes-agent && python3 -c "from plugins.memory.zhiyi import HermesZhiYiMemoryProvider; p=HermesZhiYiMemoryProvider(); print(p.is_available(), len(p.get_tool_schemas()))"

bge-embed 正常态（4GB 显存笔记本，2026-09-01 v2 实测）

⚡ 2026-09-05 升级：bge 嵌入推理外移 ZSB (192.168.5.104 GPU/DirectML)。本机 bge-embed 端口改 8001（fallback），8000 由 bge-failover-proxy 代理接管。curl localhost:8000/health 仍有效（走代理→远端）。详见 windows-home-server-ops skill。

  • 当前设计：bge 跑 CPU（本机 8001 fallback）+ 远端 ZSB GPU（主），llama 4B 跑本机 GPU（共享 4GB 显存）
  • 为什么改 CPU：bge 调用频率低（织忆 recall），CPU 推理够用，腾显存给 llama 让 7B 全 GPU
  • 历史变化：
    • v1：bge 跑 GPU（CUDA），llama 跑 CPU → llama 太慢（9 t/s）
    • v2（22:00 起）：bge 改 CPU，llama 改 Vulkan GPU → llama 14 t/s（提升 55%）
  • 切换方式：编辑 /home/muc/.hermes/scripts/bge_embed_server.py 把 providers=["CUDAExecutionProvider", "CPUExecutionProvider"] 改成 providers=["CPUExecutionProvider"]
  • 看门狗：gpu-health-watchdog.sh 不再把 bge-CPU 当异常
  • bge venv = /home/muc/.hermes/venvs/bge-embed/（独立，不污染 hermes 本体）
  • 详见 skill: bge-embed-crash-loop-fix

llama-server 正常态（Vulkan GPU 推理，2026-09-07 更新）

  • 二进制路径：/home/muc/.local/bin/llama-server（稳定软链，不在 /tmp）
  • systemd unit：llama-server-4b.service（enabled，开机自启；Qwen3.5-4B Q4_K_M，-ngl 99 --reasoning off --ctx-size 8192）
  • 🔒 3B/7B 禁止使用（牧尘 2026-09-07 铁律）：llama-server.service(3B)/llama-server-7b.service 均 disabled + 禁启；llama-switch.sh 已移除 3b/7b 分支（输入即拒绝）。3B 曾 CPU 推理 ctx 16384 → RSS 7.6GB 内存黑洞（9/6 曾被误归因为 4B 的 8.1GB——张冠李戴，已修正）
  • 实测资源（9/7 GPU 全空时）：VRAM 3171/4096 MiB（全层 GPU），host RSS ~480MB——轻量可常驻
  • 推理速度：Vulkan GPU ~43-44 t/s（4B Q4 全 GPU）
  • 4B 适用：简单文本/有自动校验的任务（distill 看门狗候选池第一位、画像 profile_distill）；质量敏感任务保持云 agnes（wiki_curator/cangjie_distill 深度提取不切 4B）
  • 编译命令：cmake -B build -DGGML_VULKAN=ON -DGGML_CUDA=OFF + apt install libvulkan-dev glslc spirv-headers spirv-tools spirv-headers
  • 关键：/tmp/ 会被 systemd-tmpfiles-clean 清掉，systemd unit 永远写 /home 或 /usr/local
  • 详见 skill: self-healing-infrastructure → references/llama-vulkan-build-guide-20260901.md

重建路径（/tmp/memoryweave 丢失时）

mkdir -p /tmp/memoryweave && cd /tmp/memoryweave && git clone http://192.168.123.11:3000/xiaoxue_admin/memoryweave.git .
# 启 bge-embed（systemd 自动）
systemctl --user daemon-reload && systemctl --user enable --now bge-embed
# 编并起 sidecar
cd /tmp/memoryweave/rust && cargo build --release
/tmp/memoryweave/rust/target/release/zhiyi-consolidate --mode socket --socket /tmp/zhiyi-ipc.sock --data-dir /var/lib/memoryweave

协作模式

牧尘 ← 指令 → 我（规划/架构/验收）
              ↓
          opencode（执行编码，需要时启用）
              ↓
          我（验收审查）
              ↓
          openclaw（项目体验/UAT，需要时启用）

职责分工

角色 职责
我（小唯） 规划技术方案、架构审查、验收结果、文档同步
opencode 执行代码编写（60+ 语言），不写则已写完，需我验收
openclaw 项目体验/UAT，反馈使用感受

⚠️ 铁律

  • ❌ 我不写代码
  • ❌ 我不调试代码
  • ❌ 我不直接操作项目文件
  • ❌ 我不擅自删除任何 skill（2026-08-30 牧尘明确：以后也会用，删前必须经同意）—— 优先归档到 skills/.archive/
  • ✅ 我规划方案 → opencode 执行 → 我验收
  • ✅ openclaw 体验 → 反馈结果

失忆恢复指南（升级到 v3.2 之后）

session 重置或忘了织忆状态，先拉真实：

  1. 4 组件健康检查 ← 第 1 步（别先想"为什么"）
  2. 设计文档 — ~/mc/小唯/07-Wiki/concepts/织忆(MemoryWeave)-v3.8-完整定稿.md
  3. 进度快照 — ~/mc/小唯/记忆/织忆/进度-*.md
  4. 参考项目 — ~/projects/memoryfabric-research/
  5. Gitea 仓库 — http://192.168.123.11:3000/xiaoxue_admin/memoryweave

进度查看位置

进度类型 查看位置
当前阶段 设计文档第十一章（实施步骤与验收标准）
已完成任务 实施计划中的 Phase 完成标记
下一个任务 实施计划中当前 Phase 的下一个待办
代码状态 Gitea 仓库 + /tmp/memoryweave/
定时提醒 （取消，不再挂 cron**）；按需读设计文档第 11 章

ao 核心命令

# 一句话生成并执行工作流
ao compose "分析竞品并输出报告" --run

# 只生成 YAML（不执行）
ao compose "分析竞品并输出报告"

# 查看执行计划
ao plan workflow.yaml

# 执行工作流
ao run workflow.yaml -i key=value

# 断点续跑
ao run workflow.yaml --resume last
ao run workflow.yaml --resume last --from step_id

# 查看所有角色
ao roles

飞书通道

  • 小唯的飞书：App ID cli_a95d7ff06b789bb4
  • 发送给自己：send_message 工具，飞书 chat ID ou_da2e9d4029c7165c211a2553dc375f80

任务类型与执行路径

任务类型 执行路径
模糊复杂目标 ao compose → 自动编排执行
多角色并行研究 ao run workflow.yaml
简单并行任务 delegate_task
定时任务 hermes cron（provider=auto，gateway_required=true，单 watchdog 任务）
复杂迭代任务 ao run --resume
专业技能执行 skill_load + 工具
织忆项目任务 skill 是 zhiyi，我规划 → opencode 执行 → 我验收

角色使用

每次任务按需调用 1-N 个角色，角色是戏服，我是本体。

常用角色路径：

  • specialized/agents-orchestrator — 管道编排（最接近我本身）
  • product/product-trend-researcher — 市场研究
  • support/support-executive-summary-generator — 汇总报告
  • engineering/engineering-software-architect — 技术方案

参考项目仓库（Gitea）

仓库 用途
yantrikdb 冲突检测、CRDTs
yantrikdb-server Raft共识
agent-memory-skill 线性衰减、tier分层
agent-second-brain Vault存储
codegraph 代码知识图谱
honcho 对话记忆
memos Redis Streams
multica 多Agent协作
memoryweave 织忆系统仓库（已部署，3292 memories）

关键 Skills（按今晚触及频率倒序）

Skill 类别 Skill 名 用途
织忆 zhiyi 织忆 API 客户端、健康检查、运维规范（v11.21，自动维护版本）
KOCR accounting-voucher-ocr PP-OCRv6 + K3 导入（v8.0.0，参数已冻结）
自进化 muchen 我的自驱动（你叫它自进化，但今晚的失忆暴露自驱动不够——需要外部规则栓）
AO 编排 ao-orchestrator 243 个角色调度（我自身的作战阵法）
Hermes hermes-agent Claude / OpenCode 编码委派
自救 hermes-self-improvement 完成任务后存为 skill（今晚失忆应该走的路）

cron jobs（2026-06-25 软回滚到 v0.13 兼容模式）

ID 名称 调度 模式 状态
152c0ed6d0f8 同步服务器凭证照片 every 1m no-agent (watchdog) OK active

provider: auto（v0.17 Chronos 抽象层已加，但保留默认值；inprocess 也是 OK；下方 v0.17 对比表也已注 soft-rollback）

gateway_required: true（gateway 在才 fire，gateway 关就累积下次启动）

⚠️ 2026-06-25 决策：v0.17 的 Chronos provider 抽象化了 cron，但当前只有 1 个简单 watchdog 任务，没必要上 provider 钩子（on_jobs_changed / fire_due / reconcile）。所以 provider 改 auto——以后真的用 Chronos hook (KOCR 增量入库、织忆实时 distill) 时再切 inprocess。同步服务器凭证照片这一项仍可跑。

织忆进度提醒用定时任务：取消。需要看设计文档时主动 ao compose 触发或者我读到 ~/mc/小唯/07-Wiki/concepts/织忆(MemoryWeave)-v3.8-完整定稿.md 第 11 章，这里不再走 cron。

hermes v0.17 vs v0.13 关键差异（soft-rollback 状态）

能力 v0.13 v0.17 今晚决策
display.tool_progress_style 无 accumulate / separate ✅ 改 accumulate，飞书刷屏合并
cron system 单一硬编码 CronScheduler ABC + provider ⚠️ provider=auto（软回滚）；只 1 个 watchdog 用不上 hook
delegate_task(background=True) 不支持 异步子代理 ✅ 链路验证
hermes insights 无 30 天 token / session 统计 ✅ 接 hermes insights
WebSocket Relay 无 EXPERIMENTAL, contract_version=1 ⚠️ 不动 frpc，等 Discord/Telegram 验证再评估
Chronos managed-cron 无 NAS-JWT fire verifier + scale-to-zero 钩子 ⚠️ 不动，等 KOCR 增量入库真实必要性出现

v3.1 → v3.2 变更日志

  • 升级到 2026-06-25 凌晨·记忆全面刷新 版
  • 去掉 "织忆是设计阶段 / opencode 执行中" 的过期假设：织忆今晚上线 + 跑通 + 测试通过
  • 补全 4 组件架构 + 健康检查流程 + 重建路径
  • 加 "任何子系统坏了的诊断触发器"（参考 SOUL.md 触发方式 C）
  • 加 cron jobs 实际清单 而不是参考模板
  • 加 hermes v0.17 vs v0.13 关键差异 —— 升级后确认落地的部分

v3.1 → v3.2 教训：今晚因此失忆 1 次，下次升级 hermes 之后必须 cs/as 用 zskek 进行 4 组件健康检查——该流程已写进 SOUL.md 触发方式 C 和本次 AGENTS.md。