企业版自动化运行架构

这是一页运行机制页，负责回答“系统应该怎么跑”。
它不负责定义单个概念本身；涉及概念定义时，应引用对应的 entities/ 和 concepts/ 主权页。

目标

这页定义企业版系统如何自动运行，不只是“有知识库”，而是：

• 能接收任务
• 能执行任务
• 能沉淀记忆
• 能筛出候选知识
• 能编译成 wiki
• 能发布到团队知识库

五层运行模型

1. Multica — 调度层 + 评审 UI
2. Hermes Agents — 执行层
3. mem0 + 阿里云百炼 + Zilliz Cloud Milvus — 记忆层
4. llm-wiki 编译层（输出落 drafts/）
5. Docs-as-Code 发布架构 — 发布层（GitHub 真相源 + VitePress 静态站 + ECS 文件挂载）

自动化流水线

流水线 A：任务执行

Multica Issue / Chat
-> Hermes Agent
-> mem0 搜索上下文
-> Agent 执行
-> 结果输出
-> mem0 写回

流水线 B：候选知识生成

完成的任务 / 关键评论 / 高价值 mem0 记录
-> candidate bundle
-> 等待 review 或 wiki-compile 触发

流水线 C：知识编译

candidate bundle
-> llm-wiki compile
-> canonical wiki
-> index / overview / log update

流水线 D：知识发布（docs-as-code）

wiki-compile 输出
-> drafts/<id>-<title>.md
-> Multica 评审 UI（评论 / AI 改 / 通过）
-> promote.sh: drafts/ → canon/ + git push origin main
-> GitHub main（真相源 `daishiyu1991-hub/wiki-vault`）
-> ECS cron pull → /opt/wiki-vault/canon/
-> 5 个 Hermes /wiki 只读 + VitePress build → wiki.86lux.net

详见 Docs-as-Code 发布架构。 旧的"发布到飞书知识库"链路见 飞书发布同步机制（已 superseded）。

流水线 E：治理

canonical wiki
-> lint
-> graph build
-> review queue

推荐节奏

• 执行与记忆：实时
• 候选知识生成：事件驱动
• wiki 编译：准实时或批处理
• lint / graph：定时批处理

核心规则

• 不是所有执行结果都直接入 wiki
• mem0 是执行连续性层，不是最终知识库
• 真相源是 GitHub 上的 markdown 仓（daishiyu1991-hub/wiki-vault），飞书等渲染端只是消费者
• canon / drafts 双区物理隔离，agent 写不进 canon
• 企业版必须有 review gate，promote.sh 是唯一写真相源入口

关联

• 执行与上线流程
• 企业版Source进入规则
• Docs-as-Code 发布架构 — 当前发布层
• Docs-as-Code over Feishu Publishing — 发布层切换的判断
• Feishu as Publishing Layer — 已 superseded