TeamOS Wiki

主题

Wiki Log ​

[2026-04-17] compile | AI+人协作系统 仓库首轮严格版 llm-wiki 升级 ​

原始来源 ​

  • raw/Multica × Hermes × Mem0/01-执行计划.md
  • raw/Multica × Hermes × Mem0/02-GoLive清单.md
  • raw/Multica × Hermes × Mem0/03-Wiki编译手册.md
  • raw/Multica × Hermes × Mem0/04-Issue模板.md

本次动作 ​

  • 建立严格版 raw/ + wiki/ 结构
  • 新建 wiki/schema.md
  • 新建 wiki/index.md
  • 新建 wiki/log.md
  • 将分散专题文档编译为 canonical wiki 页面
  • 将概念页纳入 canonical wiki 导航

目标 ​

把这个仓库从“Obsidian 文档集合”升级为“source 与 compiled knowledge 分层的 llm-wiki”。

[2026-04-17] refine | canonical wiki pages created from archived source documents ​

Actions ​

  • 建立 wiki/系统总览.md
  • 建立 wiki/对象模型.md
  • 建立 wiki/执行与上线流程.md
  • 建立 wiki/知识编译规则.md
  • 建立 wiki/概念词典.md
  • 建立 wiki/执行计划.md
  • 建立 wiki/GoLive清单.md
  • 建立 wiki/Wiki编译手册.md
  • 建立 wiki/Issue模板.md

Notes ​

  • 现有根目录页面保留为过渡入口，不再视为 canonical knowledge
  • 现有专题文档已复制到 raw/Multica × Hermes × Mem0/ 作为 source material

[2026-04-17] refine | upgraded toward full llm-wiki-agent structure ​

Actions ​

  • 新建 wiki/overview.md
  • 新建 wiki/sources/
  • 为 4 个 source 建立 sources/ 摘要页
  • 新建 wiki/entities/
  • 新建 wiki/concepts/
  • 将 Multica、Hermes Agents、阿里云百炼、Zilliz Cloud Milvus 归入 entities/
  • 将 mem0、llm-wiki 归入 concepts/
  • 新建 graph/graph.json
  • 新建 graph/graph.html
  • 更新 wiki/index.md 以反映完整结构

Notes ​

  • 当前仍缺真正的图谱生成逻辑，但 graph 层 canonical 位置已经预留
  • 当前 syntheses/ 目录已建立，但尚无 query-derived synthesis pages

[2026-04-17] synthesize | first synthesis pages compiled from architecture discussion ​

Actions ​

  • 建立 wiki/syntheses/Hermes × Multica Runtime Model.md
  • 建立 wiki/syntheses/Mem0 vs llm-wiki Division of Responsibility.md
  • 建立 wiki/syntheses/Team Workflow for Promoting Task Results into Knowledge.md
  • 更新 wiki/index.md，把第一批 synthesis pages 纳入导航

Notes ​

  • 这标志着该仓库不再只是“有 raw / wiki 结构”，而是已经开始进入真正的 query / synthesis compounding 阶段

[2026-04-17] lint | structural cleanup and canonical path normalization ​

Actions ​

  • 删除 wiki/ 根下与 entities/、concepts/ 重复的 canonical 概念页
  • 统一相对 wikilink 到 canonical 路径
  • 生成 wiki/lint-report.md

Outcome ​

  • source / canonical / portal 三层分离更加清晰
  • 重复 canonical 页面被收敛

[2026-04-17] synthesize | second batch of synthesis pages compiled ​

Actions ​

  • 建立 wiki/syntheses/Why Multica Should Come After Stable Memory.md
  • 建立 wiki/syntheses/Hot Path vs Cold Path in Team AI Collaboration.md
  • 建立 wiki/syntheses/User ID vs Agent ID Boundary.md
  • 更新 wiki/index.md

Outcome ​

  • 关键边界和顺序问题不再只停留在对话里，已经进入长期知识层

[2026-04-17] graph | first real graph build from wikilinks ​

Actions ​

  • 建立 build-graph.py
  • 生成真实 graph/graph.json
  • 生成真实 graph/graph.html

Notes ​

  • 当前图谱基于显式 wikilinks
  • 还未加入 inferred edges 和社区检测

[2026-04-17] refine | second-round concept completion ​

Actions ​

  • 建立 wiki/concepts/Runtime.md
  • 建立 wiki/concepts/Issue.md
  • 建立 wiki/concepts/Comment.md
  • 建立 wiki/concepts/Chat.md
  • 建立 wiki/concepts/User ID.md
  • 建立 wiki/concepts/Agent ID.md
  • 建立 wiki/concepts/Memory Item.md
  • 更新 wiki/index.md
  • 更新 wiki/lint-report.md

Outcome ​

  • 当前最常用、最容易混淆的对象已经都有独立 canonical 概念页

[2026-04-17] synthesize | retrieval strategy clarified for enterprise knowledge system ​

Actions ​

  • 建立 wiki/syntheses/Wiki-first vs RAG-first Retrieval Strategy.md
  • 更新 wiki/index.md
  • 将仓库定位进一步收紧为“企业版架构计划 + 团队同步知识仓库”

Outcome ​

  • wiki-first 与 rag-first 的适用边界已进入长期知识层

[2026-04-17] refine | enterprise automation and Feishu publishing model added ​

Actions ​

  • 建立 wiki/system/企业版自动化运行架构.md
  • 建立 wiki/system/企业版Source进入规则.md
  • 建立 wiki/entities/飞书知识库.md
  • 建立 wiki/syntheses/Feishu as Publishing Layer.md
  • 更新 wiki/overview.md
  • 更新 wiki/index.md

Outcome ​

  • 知识库定位正式收紧为“企业版架构计划 + 团队同步知识仓库”
  • 飞书在系统中的角色被定义为发布层，而不是编译层

[2026-04-17] refine | enterprise governance and automation policy expanded ​

Actions ​

  • 建立 wiki/system/企业版Review Gate机制.md
  • 建立 wiki/system/企业版自动任务触发机制.md
  • 建立 wiki/system/飞书发布同步机制.md
  • 建立 wiki/syntheses/Review Gate Before Canonical Knowledge.md
  • 建立 wiki/syntheses/Event-driven Candidate Knowledge Pipeline.md
  • 更新 wiki/index.md

Outcome ​

  • 企业版的“候选知识 -> 审核 -> canonical wiki -> 飞书发布”闭环已经进入知识层

[2026-04-17] refine | review flow implementation templates added ​

Actions ​

  • 建立 wiki/system/How to Implement Review Flow in Multica.md
  • 建立 wiki/system/Review Issue Template.md
  • 更新 wiki/index.md

Outcome ​

  • 企业版审批流不再只是原则描述，而是具备了可以直接执行的实现方法和模板

[2026-04-17] synthesize | review location and bot-triggered approval clarified ​

Actions ​

  • 建立 wiki/syntheses/Where Review Happens and How Bots Trigger It.md
  • 更新 wiki/index.md

Outcome ​

  • 审批位置、bot 触发职责、人类批准职责的边界已被正式固定在知识库中

[2026-04-17] synthesize | SDCA / PDCA operating model and repository role clarified ​

Actions ​

  • 新增 source：raw/架构讨论/2026-04-17-SDCA-PDCA-企业版运行模式.md
  • 建立 wiki/syntheses/SDCA vs PDCA Operating Model.md
  • 建立 wiki/syntheses/Skill-first Design for Team Simplicity.md
  • 建立 wiki/syntheses/Knowledge Read Order for SDCA and PDCA.md
  • 建立 wiki/syntheses/Role of This Repository in Enterprise Knowledge System.md
  • 更新 wiki/index.md

Outcome ​

  • 系统已经把“SDCA 自动执行 + PDCA 深度探索 + 仓库定位”固化成长期知识

[2026-04-17] synthesize | runtime token ownership clarified ​

Actions ​

  • 建立 wiki/syntheses/Who Should Own Runtime Tokens.md
  • 更新 wiki/index.md

Outcome ​

  • 团队已经有了“启动期代管、长期收敛”的 Runtime token 所有权原则

[2026-04-17] refine | authority-page convergence started ​

Actions ​

  • 给 概念词典 增加术语导航定位
  • 给 系统总览 增加总览页定位
  • 给 企业版自动化运行架构 增加运行机制页定位
  • 给 SDCA vs PDCA Operating Model 增加综合判断页定位
  • 更新 wiki/lint-report.md

Outcome ​

  • 开始明确不同页面类型的定义权和职责边界，减少后续重复解释的风险

[2026-04-17] refine | operational and governance pages further converged ​

Actions ​

  • 给 Issue模板、Wiki编译手册、GoLive清单 增加操作页声明
  • 给 企业版Review Gate机制、企业版自动任务触发机制、飞书发布同步机制 增加 system 页声明
  • 继续压缩 概念词典，让其更接近纯导航层
  • 更新 wiki/lint-report.md

Outcome ​

  • 操作模板、制度规则、综合判断、概念定义之间的页面职责边界进一步清晰

[2026-04-17] compile | docs-as-code publishing pivot — Feishu superseded by Gitee + VitePress on ECS ​

原始来源 ​

  • raw/架构讨论/2026-04-17-Wiki-on-ECS-docs-as-code-架构.md（新增）
  • 父对话：a6961ea6-301c-4e46-a9e4-8967c483bf7b
  • 计划文件：c:\Users\Administrator\.cursor\plans\wiki-on-ecs-docs-as-code_3b8ca097.plan.md

触发原因 ​

Slice 3 飞书首发路径完成后，发现飞书 markdown 渲染存在三类不可消除的损耗 （frontmatter 单行化、wikilink 不渲染、blockquote 合并）。预处理器只能修视觉， 不能让飞书变 markdown-first。决定把企业知识发布层从飞书切到 docs-as-code 模式。

新建页面 ​

  • raw/架构讨论/2026-04-17-Wiki-on-ECS-docs-as-code-架构.md — 完整计划归档为不可变 source
  • wiki/sources/05-Wiki-on-ECS-Plan.md — source summary
  • wiki/system/Docs-as-Code 发布架构.md — 新发布架构主权页
  • wiki/entities/Gitee.md — 新实体（wiki 真相源）
  • wiki/entities/VitePress.md — 新实体（人类浏览渲染层）
  • wiki/syntheses/Docs-as-Code over Feishu Publishing.md — 发布层切换的判断综合页

更新页面（架构 pivot） ​

  • wiki/system/飞书发布同步机制.md — 标 SUPERSEDED，保留作历史对照
  • wiki/system/企业版自动化运行架构.md — 五层模型第 5 层从"飞书"改为"Docs-as-Code"，流水线 D 重写为 docs-as-code 链路
  • wiki/system/企业版Review Gate机制.md — 把 review gate 落地为 drafts/canon 双区 + promote.sh + Multica 审批事件
  • wiki/entities/飞书知识库.md — 角色从"企业知识发布层"收窄为"团队协作平台 / 可选浏览渠道"
  • wiki/syntheses/Feishu as Publishing Layer.md — 标 SUPERSEDED，链到 Docs-as-Code over Feishu Publishing
  • wiki/index.md — 新增 5 个页面入口，标注两个 superseded 页面

Outcome ​

  • 真相源从飞书云端迁移到 Gitee 86lux/wiki-vault main 分支
  • 5 个 Hermes 容器消费方式统一为：/opt/wiki-vault/canon/ ro 挂载
  • 人类浏览统一为：https://wiki.86lux.net（VitePress 静态站，1Panel nginx + Let's Encrypt）
  • review gate 物理化：drafts 区 hermes-admin 可写，canon 区只能 promote.sh 写，agent 无法绕过
  • Multica 管理页面已有的"评论 + AI 改 + 审批"UI 通过审批事件触发 promote
  • 旧飞书发布脚本（slice3v2_*）保留代码但不再调用，1 个月后再清理

实施状态 ​

  • 架构判断已写入长期知识层（本次 commit）
  • Phase A/B/C/D 实施落地仍待执行（见 c:\Users\Administrator\.cursor\plans\wiki-on-ecs-docs-as-code_3b8ca097.plan.md）

[2026-04-17] refine | remaining high-value pages converged ​

Actions ​

  • 给 How to Implement Review Flow in Multica 增加流程实现页声明
  • 给 Review Issue Template 增加模板页声明
  • 给 企业版Source进入规则 增加 source 治理页声明
  • 给 Wiki-first vs RAG-first Retrieval Strategy 增加检索策略判断页声明
  • 给 Feishu as Publishing Layer 增加综合判断页声明
  • 更新 wiki/lint-report.md

Outcome ​

  • 剩余高价值页也已进入“主权清晰、职责明确”的状态

[2026-04-17] deploy | wiki-vault 上线 + 架构修订（GitHub + Git LFS + auto-rebuild + Skills） ​

Actions ​

真相源选型变更：Gitee → GitHub

  • 实际部署改用 github.com/daishiyu1991-hub/wiki-vault
  • 原因：GitHub Git LFS 付费方案 ($5/月 50GB) 优于 Gitee；ECS 实测 GitHub push/pull 稳定；同事普遍熟悉 GitHub
  • 新建 entities/GitHub.md，把 entities/Gitee.md 标 SUPERSEDED
  • 同步更新所有 active 引用：Docs-as-Code 发布架构、企业版自动化运行架构、企业版Review Gate机制、飞书知识库、VitePress、Docs-as-Code over Feishu Publishing、index.md

Git LFS 落地

  • ECS 装 git-lfs 3.0.2
  • .gitattributes 跟踪 png/jpg/jpeg/gif/webp/mp4/mov/mp3/pdf/zip/docx/pptx/psd/ai/sketch/fig/xd 等
  • 冒烟测试：1.6KB PNG → git 仓库存 120 字节 pointer，二进制走 LFS 上传成功
  • 新建 concepts/Git LFS.md

VitePress wikilink 插件

  • 自研 wikilink-plugin.mjs，markdown-it 解析阶段把 <span class="wikilink-dead" title="未找到: xxx" style="color:#c33;border-bottom:1px dashed #c33">xxx</span> / <span class="wikilink-dead" title="未找到: xxx" style="color:#c33;border-bottom:1px dashed #c33">alias</span> 转成 markdown 内联链接
  • URL 段做 encodeURIComponent，含空格的页名（如 Hermes Agents）正确生成 <a> 标签
  • 死链渲染为红色虚线 <span class="wikilink-dead">，不挂掉构建
  • 中途修过 wiki发布流程-Multica审批触发.md 里 <rel> <分类> 等占位符（Vue 误判 HTML），用中文角括号 〈xxx〉 替换
  • 新建 concepts/wikilink 插件.md

auto-rebuild cron（合并旧两条）

  • 新脚本 /opt/wiki-tools/auto-rebuild.sh：每分钟跑，flock 防并发，git fetch 比对，无新 commit 0 负载退出，有就 pull + refresh-symlinks + vitepress build
  • 端到端延迟从原 5-7 分钟（旧 wiki-sync */5 + build */5 错峰）缩短到 1-2 分钟
  • 旧 cron 暂未删除，并存中

vault-publish skill（同事工作流）

  • 新建 ~/.claude/skills/vault-publish/SKILL.md：完整 SSH key 走读 (Step 3)、idempotent 7 步发布、零脚本依赖
  • 新建 concepts/vault-publish.md
  • 新建 system/同事接入wiki发布流程.md：给同事的 onboarding，10 分钟一次性配置 + 日常一句话发布
  • 新建 system/wiki图片视频管理规范.md：媒体资产规范（目录约定、引用方式、LFS 后缀清单、配额、故障排查）

llm-wiki skill 更新

  • 重写 ~/.claude/skills/llm-wiki/SKILL.md，加"环境感知"章节：本地 → 写 canon/ 或 personal/；ECS 容器 → 写 drafts/<agent>/
  • 旧路径 E:/amazon-workspace/wiki/ 弃用

本地 vault 升级为 git clone

  • 备份 E:\Ai+人协作系统\wiki\ → E:\Ai+人协作系统\wiki.bak-20260417-213635（62 文件）
  • 在原位置 git clone https://github.com/daishiyu1991-hub/wiki-vault.git → 内容与 ECS canon/ 100% 同源（仅多 2 份新加文档）
  • 新结构：canon/ + drafts/ + .gitignore（含 personal/）+ .gitattributes
  • Obsidian 重开 vault 即可

修正 public/ → canon/ 错误

  • 之前给 vault-publish skill / 同事接入文档 / 媒体规范 写的"public/"路径，与 ECS 实际"canon/"结构不符
  • 全部修正：6 处

Outcome ​

  • ✅ 所有 8 项部署完成判据达成（见 system/Docs-as-Code 发布架构.md）
  • ✅ docs-as-code 闭环跑通：Allen 本地 ↔ GitHub ↔ ECS ↔ Hermes ↔ wiki.86lux.net
  • ✅ 同事接入零代码门槛：装 vault-publish skill → "发布 wiki" 一句话搞定
  • ✅ 二进制资产无忧：Git LFS 自动接管，付费 $5/月配额
  • ⚠️ 待办：旧 */5 sync.sh */10 build.sh cron 与新 auto-rebuild * 并存，下轮维护时清理
  • ⚠️ 待办：webhook 即时触发（方案 B）暂未做，按需升级（当前 1min cron 延迟可接受）

[2026-04-18] migration | mem0 → Honcho 完整切换 + wiki 重新编译 ​

主线决策 ​

把团队记忆后端从 mem0 + Zilliz Cloud + 自维护 mem0_provider_new.py 切换到 Honcho 托管。核心驱动力是「减运维」（Allen 拍板，不是技术先进性）。

详见：

当前架构 ​

人类 → Multica → Hermes (3 active: admin/guohua/linjun) → Honcho cloud (teamos-prod workspace)
                                                       → 阿里云百炼/Kimi (业务对话 LLM)

3 hermes 都通过 hermes honcho status 显示 Connection... OK，业务路径全验证 0 个 401。

完整动作清单（按时序） ​

A. 知识入库阶段（已 done）

  • 写 entities/Honcho.md（实体页）
  • 写 concepts/Honcho memory.md（范式概念）
  • 写 syntheses/Why Honcho over mem0.md（决策综合 + 6 踩坑）
  • 写 syntheses/Honcho vs llm-wiki Division of Responsibility.md（新分工）
  • 写 system/Honcho 接入指南.md（含 monkey patch + admin scope 选型 + 失败排查）
  • 写 system/隐私规则/HERMES_HONCHO_RETRIEVAL_GUARDRAILS.md（5 条 Honcho 特有铁律）
  • 标 SUPERSEDED：concepts/mem0.md / entities/Zilliz Cloud Milvus.md / syntheses/Mem0 vs llm-wiki Division of Responsibility.md
  • 修订 active 引用：系统总览.md / 概念词典.md / entities/Hermes Agents.md / entities/阿里云百炼.md / system/隐私规则/README.md
  • 更新 canon/index.md

B. 实施阶段（昨晚已 done）

  • 注册 Honcho cloud + 创建 workspace teamos-prod
  • 3 hermes 各一把 admin scope key（前面试过 Global scope 全 401，详见踩坑 4）
  • 3 个 /opt/data/honcho.json 配置文件（写 workspace + apiKey + hosts.hermes block）
  • monkey patch delete_workspace（屏蔽 admin 误删）+ _ensure_workspace（跳过冗余 POST）
  • 3 hermes 重启 + hermes honcho status 全部 Connection OK
  • 端到端测试：模拟"我做亚马逊厨房用具"对话 → Honcho chat() 返回精准综合理解 ✓

C. 健康检查（昨晚已 done）

  • admin Config v16 → v17 migrate
  • guohua/linjun 补齐 builtin skills（5 → 216）
  • guohua/linjun 复制 cli-config.yaml
  • 删 3 容器过期 mem0 skill（teamos-mem0-guardrails 等）
  • 创建 MEMORY.md/USER.md 空文件

6 个踩坑（详见 syntheses/Why Honcho over mem0#踩坑记录） ​

  1. API key 复制带 Ehch- 前缀（实际 hch-）→ Invalid API key
  2. HONCHO_WORKSPACE_ID env 不被 SDK 读 → 必须写 honcho.json
  3. dashboard SCOPE=Workspace 实际保存为 Global → UI bug
  4. Global scope 几乎只有"创建空 peer"权限 → 必须 admin scope
  5. SDK _ensure_workspace 每次 init 都强行 POST /v3/workspaces → workspace-scope 401
  6. admin scope 能调 delete_workspace → 必须 monkey patch 屏蔽

关键事实 ​

  • Zilliz collection 始终为空（mem0 实际从未真正稳定运行）→ 切换零迁移成本
  • 切换主动工时 ≈ 4 小时（80% 时间在踩 6 个坑）
  • 长期月成本：~$18-30 USD（Honcho 按 token 计费，5 hermes 估算）
  • $100 免费 credit 够用 5 个月

待办（未来 1 个月） ​

  • Zilliz 退订决策（先看 dashboard 是 free/dedicated tier，2026-05-17 后做）
  • 5 hermes .env 删 MEM0_* 孤儿配置
  • 删 /opt/data/.mem0/ 本地缓存
  • patch 持久化方案（写到 deploy.sh，避免 docker pull 升级丢 patch）
  • 评估 hermes update（落后 483 commits，可能新版改了 honcho 集成）

关联 ​

[2026-04-18] cleanup | Phase Z 撤回冗余 _ensure_workspace patch ​

背景 ​

H 阶段（昨天切换）实际打了 2 个 monkey patch。其中 _ensure_workspace skip 是给最早的 Global scope key 救急用的（没它会 SDK init 时 403）。换 admin scope key 后该调用能正常成功，patch 变成"省一次 POST 网络往返"的冗余优化，与上游 SDK 行为偏离反而增加未来调试成本。撤回。

动作 ​

  1. 3 hermes 容器（admin/guohua/linjun）跑 pip install --force-reinstall --no-deps honcho-ai==2.1.1 还原上游 client.py（一并清掉 2 个 patch）
  2. 重新 apply 仅 Patch 2（delete_workspace disable，安全 critical 必保留）
  3. docker restart 3 容器
  4. 验证：
    • hermes honcho status 全部 Connection... OK
    • SDK 端到端测试（peer.get_or_create → session.get_or_create → add_peers → add_messages）3 容器全 OK
    • delete_workspace_DISABLED 仍存在 / delete_workspace 不存在 → Patch 2 在位
    • grep -c HERMES_PATCH client.py = 1（之前是 2）

修订 ​

  • system/Honcho 接入指南 Step 3 改 "必做的 2 件事" → "必做的 1 件事"，加"演化历史"小节解释 Patch 1 撤回原因 + 教训
  • 失败排查表 _ensure_workspace 401 行从"重跑 patch"改为"换 admin scope key"（治本不治标）
  • 安全清单 patch 标记数从 = 2 改为 = 1

教训 ​

先把 scope 调对，再考虑要不要为"非根因"加 patch。

任何为"绕过"加的 patch，前提是先确认根因不能以更干净的方式解。如果根因可解（比如换 scope），patch 就是技术债。

待办（已记入 post-honcho-cleanup-and-extension plan） ​

  • Phase A5：Patch 2 持久化到 deploy.sh，防 docker pull 升级丢 patch（关键）
  • Phase A1-A4：ECS 旧 cron / 本地 staging / vault SSH origin 等收尾

TeamOS · docs as code · canon=权威知识，drafts=候选区

© 86lux.net